【389 Directory Server講座 第8回】クライアント連携。SSSDによるオフライン認証と統合管理のゴール

「サーバーと通信できません」でも、ログインだけはさせてくれ。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
ついに最終回です。ここまで本当にお疲れ様でした。
第1回から第7回までで、堅牢で高速、かつセキュアなLDAPサーバー（389 DS）が完成しました。

しかし、サーバーは「使われて」初めて価値を持ちます。
今回は、Linuxクライアント（WebサーバーやAPサーバー）から、このLDAPサーバーを使ってユーザー認証を行う設定をします。
ここで登場するのが、現代のLinux認証のデファクトスタンダード、「SSSD」です。

本記事では、SSSDのアーキテクチャ、authselect によるPAM設定の自動化、ホームディレクトリの自動作成、そしてトラブルシューティングまで、クライアント設定の全てを解説します。

---

第1章：なぜ nslcd ではなく SSSD なのか？

以前のLinuxでは、LDAP連携といえば nss-pam-ldapd (nslcd) が主流でした。
しかし、これには致命的な弱点がありました。

nslcd の弱点

• オフラインに弱い： ネットワーク障害時、認証がタイムアウトするまでログイン画面で待たされる。ログイン済みのセッションも固まる。
• 高負荷に弱い： ユーザー数が多いと、LDAPサーバーへの問い合わせが殺到し、レスポンスが悪化する。
• 単一機能： 基本的にLDAPしか話せない。ADやKerberosとの連携は別のツールが必要。

SSSD (System Security Services Daemon) の強み

• 強力なキャッシュ： ユーザー情報やパスワードハッシュ（設定による）をローカルにキャッシュします。LDAPサーバーがダウンしても、キャッシュ有効期限内ならログイン可能です。
• 統合管理： LDAP, Kerberos, Active Directory, IPA など、複数の認証プロバイダを統一的に扱えます。
• 負荷分散： 複数のLDAPサーバーを指定でき、自動的にフェイルオーバーします。

---

第2章：実践！SSSDのインストールと authselect

クライアントOSは RHEL 9 / AlmaLinux 9 / Rocky Linux 9 を想定します。
まず、必要なパッケージをインストールします。

1. インストール

dnf install sssd sssd-ldap sssd-tools oddjob-mkhomedir

• sssd: 本体デーモン。
• sssd-tools: キャッシュ削除コマンド(sss_cache)などが含まれる。
• oddjob-mkhomedir: 初回ログイン時にホームディレクトリを自動作成するツール。

2. PAM/NSS設定の適用 (authselect)

/etc/nsswitch.conf や /etc/pam.d/* を手動で編集してはいけません。
authselect コマンドを使って、安全にプロファイルを適用します。

# 現在のプロファイル確認
authselect current

# SSSDプロファイルを適用し、ホームディレクトリ作成機能を有効化
authselect select sssd with-mkhomedir --force

--force オプションは、既存の設定ファイルを上書き（バックアップ作成）します。
これにより、OS全体が「認証にはSSSDを使う」という設定に書き換わります。

---

第3章：設定ファイル sssd.conf の完全解説

SSSDの挙動は、たった一つの設定ファイル /etc/sssd/sssd.conf で決まります。
デフォルトでは存在しない場合があるため、新規作成します。

/etc/sssd/sssd.conf の作成例

第6回で構築したTLS対応の389 DSに接続する設定です。

[domain/default]
# デバッグレベル (0-9)。トラブル時は高くする。
debug_level = 2

# プロバイダ設定
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

# LDAP接続設定 (HA構成)
ldap_uri = ldaps://ldap01.linuxkoubou.com, ldaps://ldap02.linuxkoubou.com
ldap_search_base = dc=linuxkoubou,dc=com

# TLS設定 (証明書検証を強制)
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

# キャッシュ設定 (オフライン認証の肝)
cache_credentials = True
# エントリの有効期限 (秒)。デフォルトは長いのでテスト時は短くすると吉。
entry_cache_timeout = 600

# スキーマ設定 (389DS/OpenLDAP標準のRFC2307)
ldap_schema = rfc2307

[sssd]
services = nss, pam
domains = default

[nss]
filter_groups = root
filter_users = root

[pam]

権限設定と起動

sssd.conf にはパスワードなどが含まれる可能性があるため、権限は厳格にチェックされます。
600 (rootのみ読み書き可) でないと、SSSDは起動しません。

chmod 600 /etc/sssd/sssd.conf
systemctl enable --now sssd
systemctl enable --now oddjobd

動作確認

LDAP上のユーザー taro がOSから見えるか確認します。

id taro

uid=1001(taro) gid=1001(taro) groups=1001(taro)... のように表示されれば、NSS（名前解決）の連携は成功です。

---

第4章：ホームディレクトリの自動作成 (oddjob-mkhomedir)

LDAPユーザーは、各サーバー上にホームディレクトリを持っていません。
ログインした瞬間に /home/taro が存在しないと、エラーになったり、ルートディレクトリに放り出されたりします。

これを防ぐのが oddjob-mkhomedir です。
先ほどの authselect select sssd with-mkhomedir でPAMの設定は完了していますが、サービスが動いていないと機能しません。

確認事項

1. oddjobd サービスが起動していること。
2. /etc/pam.d/system-auth に pam_oddjob_mkhomedir.so の行が含まれていること（authselectが自動挿入します）。

これで、LDAPユーザーが初めてサーバーにログインした時、/etc/skel の内容をコピーして自動的にホームディレクトリが作成されます。

---

第5章：運用トラブル。キャッシュの削除とデバッグ

SSSDを運用していて最もハマるのが「キャッシュ問題」です。
「LDAP側でグループを追加したのに、クライアント側で反映されない！」「パスワードを変えたのに、古いパスワードでログインできてしまう！」
これらは全てSSSDの強力なキャッシュが原因です。

キャッシュの強制削除 (sss_cache)

管理者の必須コマンドです。何か変更したら、とりあえずこれを叩きましょう。

# すべてのキャッシュ（ユーザー、グループ、ネットグループなど）を破棄
sss_cache -E

特定のユーザーだけ更新したい場合：

sss_cache -u taro

データベースの物理削除

sss_cache でも直らない重症の場合、キャッシュDBファイル（LDB）を直接消して再起動します。

systemctl stop sssd
rm -f /var/lib/sss/db/*
systemctl start sssd

ログによるデバッグ

認証エラーの原因が分からない場合、/etc/sssd/sssd.conf の [domain/default] セクションで debug_level = 9 に設定し、再起動します。
/var/log/sssd/sssd_default.log や sssd_ldap.log に、LDAPとの通信内容やPAMのエラー詳細が爆発的な量で出力されます。
ここを見れば、証明書エラーなのか、パスワード間違いなのか、フィルタリングで弾かれたのかが必ず分かります。

---

第6章：アクセス制御。特定のグループのみログインさせる

「全LDAPユーザーが、この重要なWebサーバーにSSHできては困る」。
アクセス制御もSSSDで行えます。

LDAPフィルタによる制限

sssd.conf にアクセスフィルタを記述します。
例えば、「sysadmins グループのメンバーだけログイン許可」したい場合。

access_provider = ldap
ldap_access_filter = (memberOf=cn=sysadmins,ou=Groups,dc=linuxkoubou,dc=com)

これにより、認証（パスワードOK）は通っても、認可（Access Control）で弾かれるようになります。
サーバーごとに許可するグループを変えたい場合に非常に便利です。

---

第7章：障害試験。LANケーブルを抜いてみる

最後に、可用性のテストを行います。
これが成功して初めて、本番投入が可能になります。

シナリオ：LDAP全停止時の挙動

1. ユーザー taro でクライアントにログインし、ログアウトする（キャッシュを作る）。
2. LDAPサーバー側のサービスを停止する（またはファイアウォールで遮断する）。
3. 再度、taro でログインを試みる。

結果：
ログインできれば、オフライン認証（cache_credentials = True）が正常に機能しています。
この時、/var/log/secure や journalctl には「LDAPサーバーに接続できないため、キャッシュされた認証情報を使用しました」という旨のログが記録されます。

もしログインできなければ、sssd.conf の設定を見直してください。
この機能こそが、389 DS + SSSD を選んだ最大の理由なのです。

---

最終回まとめ：389 DSで描く未来のインフラ

全8回の長期連載、完走お疲れ様でした！
これで、あなたの手元には「商用レベルの堅牢な認証基盤」と、それを自在に操る「知識とスキル」が残りました。

今回の重要ポイント：

• クライアント設定は nslcd ではなく SSSD が現代の標準。
• authselect を使えば、PAM設定を壊さずに安全にLDAP連携できる。
• オフラインキャッシュ機能により、LDAP障害時でも業務を継続できる。
• トラブル時は sss_cache -E と debug_level で戦う。

この講座が、皆様のエンジニアライフの一助となれば幸いです。
また別の技術講座でお会いしましょう！