winbindからSSSDへのAD認証移行｜Kerberos・NFSホームディレクトリの断ゼロ切り替え検証手順

Active Directory（AD）との認証連携にwinbindを使い続けてきたLinux環境では、ここ数年でSSSDへの切り替えを検討する機会が増えています。winbindはSambaプロジェクトの実績ある実装ですが、オフライン認証・UID/GIDマッピングの柔軟性・Kerberosチケット管理の統合という3点でSSSD（System Security Services Daemon）が現行の標準として推奨されるケースが増えています。本記事では、既存のAD認証環境をSSSDへ切り替える際にとくに注意が必要なKerberosチケット管理とNFSホームディレクトリのゼロ断（ノーサービスダウン）切り替えに焦点を当て、移行前の確認から検証・切り戻しまでを一連の流れで取り上げます。

winbindからSSSDへの移行が浮上する背景

winbindとSSSDはいずれもLinuxホストをADドメインに参加させるための手段ですが、設計思想が異なります。winbindはSambaのコンポーネントとしてSMB/CIFS連携に最適化されており、LinuxをWindowsファイルサーバーとして動かす用途では今も現役です。対してSSSDはIDプロバイダーの抽象化を目的に設計されており、AD・LDAP・Kerberosを統一的に扱うデーモンです。

SSSD移行のモチベーションとしてよく挙がるのは以下の3点です。

• オフライン認証とキャッシュ：SSSDはIDプロバイダーへの到達が一時的に失われてもキャッシュから認証を継続できます。DC接続が不安定なブランチ拠点などで差が出やすい点です。
• IDマッピングの柔軟性：ADのSIDからLinux UID/GIDへのマッピングをSFU属性なしでもRFC 2307スキーマや自動マッピングで対応でき、UID衝突を整理しやすくなっています。
• Kerberosチケット管理の統合：SSSDはKerberos TGTの取得・更新をデーモン内で管理します。kinit/kdestroy を明示的に呼ばなくても、ログイン時にチケットが取得され期限切れ前に自動更新されます。

一方、winbindが長期稼働している環境ではNFSホームディレクトリや既存のPAM設定など依存関係が積み重なっています。「SSSDに切り替えたらホームディレクトリが見えなくなった」「sudoでKerberosチケットが引き継がれない」といったつまずきは一般的に報告されており、無停止での切り替えには事前の段取りが重要です。

移行前の環境棚卸しと前提条件の整理

移行を始める前に現行環境の依存関係を把握しておくと、切り替え後のトラブルを減らせます。確認すべき主な項目を以下に示します。

• NSS／PAMの現行スタック：/etc/nsswitch.conf の passwd・group・shadow 行が winbind を参照しているか確認します。/etc/pam.d/ 以下の common-auth・common-session も同様に確認してください。
• NFSマウントの方式：/etc/fstab への静的記述か、autofsによる動的マウントかを把握します。autofsの場合は /etc/auto.master と該当マップファイルも手元に控えます。
• Kerberos設定の確認：/etc/krb5.conf の [realms] セクションにKDCが正しく記載されているか確認します。SRVレコードが整備されていれば dns_lookup_kdc = true で自動解決できますが、静的記載の場合は移行後も引き継ぎます。
• 実行中のプロセスとジョブ：cronや常駐デーモンがADユーザーの権限で動いている場合、winbind停止時に認証が切れる可能性があります。リストアップしておきます。

SSSD側の前提として、RHEL/AlmaLinux/Rocky Linux 9系では sssd・sssd-ad・sssd-tools パッケージ、Ubuntu 22.04/24.04 LTS では sssd・sssd-ad・krb5-user をインストールします。realmコマンドを活用する場合は realmd もあわせて導入します。

SSSDのインストールとsmb.conf・krb5.confの調整

SSSDをADプロバイダーとして使う場合、最もシンプルな方法は realm join コマンドでドメイン参加とSSSD設定を一括処理することです。

# Kerberosチケットを取得してからjoin（管理者アカウントで実行）
kinit administrator@EXAMPLE.COM
realm join --membership-software=adcli EXAMPLE.COM

realm join が成功すると /etc/sssd/sssd.conf が自動生成されます。生成内容を確認し、以下の点を必要に応じて調整します。

[sssd]
domains = example.com
config_file_version = 2
services = nss, pam

[domain/example.com]
default_shell = /bin/bash
# NFSホームディレクトリを使う場合はAD側のunixHomeDirectory属性を参照
fallback_homedir = /home/%u
id_provider = ad
auth_provider = ad
access_provider = ad

# Kerberosチケット更新を有効化
krb5_renewable_lifetime = 7d
krb5_renew_interval = 3600

# キャッシュ（オフライン認証のため）
cache_credentials = true

winbindを併用していた環境では smb.conf の [global] セクションに idmap config の設定が残っている場合があります。SambaをファイルサーバーとしてではなくAD参加だけに使っている構成であれば、smb.conf のwinbind関連エントリは不要になります。ただし、SambaファイルサーバーとしてACLを運用している場合は、winbindとSSSDが並走する期間を設けて段階的に移行するほうが安全です。

NFSホームディレクトリのゼロ断切り替え

NFSホームディレクトリの切り替えは、移行でもっとも慎重な作業のひとつです。winbind停止後にUID/GIDのマッピングが変わると、NFS側のUID不一致でホームディレクトリにアクセスできなくなるケースがあります。

UID/GIDの一致を事前確認する

winbindとSSSDではSIDからUID/GIDを導出するアルゴリズムが異なる場合があります。移行前に id <ユーザー名> をwinbind環境で実行し、SSSDに切り替えた後の値と一致するかを検証します。

# winbind環境での確認（移行前）
id DOMAIN\\testuser

# SSSD設定を有効化した後の確認
id testuser@example.com

UID/GIDが変わる場合は、NFSサーバー側でエクスポートしているディレクトリ以下のファイルオーナーを find と chown で付け替える必要があります。想定例として、旧UID 10001から新UID 20001に変わる場合は find /srv/nfs/homes -uid 10001 -exec chown 20001 {} \; のような操作になります。この変更はサービス影響が大きいため、必ずメンテナンスウィンドウ内で実施します。

autofsとSSSDの連携設定

autofsでADユーザーのホームディレクトリを動的マウントする構成では、SSSDが解決するユーザー名がautofsのキーと一致している必要があります。sssd.conf の use_fully_qualified_names = False を設定すると、testuser という短縮形でもNSSが応答するようになります。ただし、同名ユーザーが複数ドメインに存在する環境では重複のリスクがあるため、単一ドメイン構成に限って使用することが推奨されます。

Kerberos認証でNFS v4を使う場合（sec=krb5 または sec=krb5i）、ユーザーログイン時にSSSDが取得したTGTがnfsサービスチケットの取得に使われます。/etc/krb5.keytab にNFSサービスキーが登録されているかを klist -k /etc/krb5.keytab で確認し、nfs/hostname@REALM エントリが存在することを確認してください。

動作検証とよくあるつまずき

SSSDを有効化したら、以下の順番で動作を確認します。

# SSSDサービスの起動と自動起動設定
systemctl enable --now sssd

# ID解決の確認
id testuser@example.com
getent passwd testuser@example.com

# Kerberosチケットの確認（ログイン後）
klist

一般的に報告されているつまずきとしては次の点が挙げられます。

• sssd.conf のパーミッションエラー：sssd.conf は chmod 600・所有者 root:root でないとSSSDが起動を拒否します。systemctl status sssd と journalctl -u sssd でエラーメッセージを確認してください。
• NSS切り替えのタイミング：/etc/nsswitch.conf から winbind を外してSSSDに変えた直後、winbindのキャッシュが残っていると一時的にユーザー解決が二重になることがあります。wbinfo -u と sss_cache -U でそれぞれキャッシュをクリアします。
• sudoers のドメインユーザー記法：winbind環境では DOMAIN\user 形式で記述されていた場合、SSSD環境では user@example.com、または use_fully_qualified_names = False 設定下では user に変更が必要です。
• 動的DNSアップデートの失敗ログ：dyndns_update = true にしているとDNSへの書き込み権限がない場合にエラーログが大量に出ます。動的DNS更新が不要な環境では dyndns_update = false に設定します。

切り戻し手順と2026年時点の推奨設定差分

切り戻し手順

SSSDへの切り替えが想定通りに動作しない場合、winbindへの切り戻しは次の手順で実施します。

# SSSDを停止・無効化
systemctl stop sssd
systemctl disable sssd

# nsswitch.confをwinbind参照に戻す
# passwd: files winbind
# group:  files winbind

# winbindを再起動
systemctl enable --now winbind

# PAMをwinbindに戻す（authselectを使っている場合）
authselect select winbind --force

切り戻し後は wbinfo -u と id DOMAIN\\testuser でwinbindが正常に動作していることを確認します。NFSホームディレクトリのUID/GIDを変更していた場合は、切り戻し時に旧値への再変更が必要になります。変更前のUID/GIDは移行前のスナップショット（getent passwd の出力を保存しておくと有効）を参照します。

2026年時点の推奨設定差分

2025年以降のディストリビューションでは、以下の点が以前の設定ガイドと差異があります。

• RHEL 9 / AlmaLinux 9 / Rocky Linux 9：authselectが標準のPAM設定管理ツールとなっており、authselect select sssd --force 一コマンドでPAMと nsswitch.conf の両方がSSSD向けに書き換わります。手動でPAMファイルを個別編集する方法は非推奨です。
• Ubuntu 24.04 LTS：realm join 後に sssd-ad が自動設定される動作は変わりませんが、pam-auth-update コマンドでSSSDモジュールが選択済みになっているかを確認する手順が追加で必要な場合があります。
• sssd 2.9 以降：ldap_idmap_range_size のデフォルト値が変更されています。winbindのidmap rangeと合わせて設定していた場合は、SSSDに引き継ぐ際に明示的に指定することでUID/GIDのズレを防げます。
• Kerberos FAST（Flexible Authentication Secure Tunneling）：Windows Server 2019以降のADを使う環境では、FAST対応がデフォルト設定で有効になるケースが増えています。SSSD 2.7以降ではFASTに対応していますが、krb5_use_fast = try と明示的に設定しておくと、FASTを要求するDC環境でも認証失敗を回避できます。

winbindからSSSDへの移行は、一度の作業で全ユーザーを切り替えようとするより、まず非本番環境や特定グループの認証から段階的に切り替えて動作を確認し、問題がなければ本番への適用を進める進め方が一般的に安全です。UID/GIDマッピングとNFSの組み合わせは移行後のトラブルが集中しやすい箇所のため、移行前の getent passwd 出力と klist の状態を必ず手元に保存してから作業を開始することをお勧めします。