SSSDとLDAPで複数サーバーの認証を集中管理する｜フォールバック設計とキャッシュ挙動の検証

なぜ認証の集中管理が必要になるのか

サーバー台数が増えるにつれて、各ホストにローカルアカウントを個別管理する運用は破綻に向かいます。パスワード変更を全台に反映し忘れる、退職者のアカウントが特定のサーバーだけ残存する、SSH鍵の配布漏れが監査で指摘される——こうした問題は現場でよく報告されるものです。

認証情報をLDAPディレクトリに一元管理し、各サーバーをSSSD（System Security Services Daemon）経由で参照する構成は、この課題に対する現行の標準的な解法です。Active Directory環境ではKerberosと組み合わせることも多いですが、本記事ではOSSスタックのみ（OpenLDAP＋SSSD）に絞り、フォールバックとキャッシュという運用上の要所に焦点を当てます。

SSSDとLDAPの役割分担を理解する

LDAPはディレクトリサービスのプロトコルであり、ユーザー情報・グループ情報・パスワードハッシュを階層的に格納します。OpenLDAPはそのOSSサーバー実装です。一方、SSSDはクライアント側で動くデーモンで、LDAPやKerberos、ローカルファイルなど複数の認証バックエンドを抽象化し、NSS（Name Service Switch）とPAM（Pluggable Authentication Modules）に統一インターフェースを提供します。

重要な点として、SSSDはLDAPへの問い合わせ結果をローカルデータベース（SQLite）にキャッシュします。LDAPサーバーへの疎通が一時的に失われても、キャッシュ期間内であれば認証が継続できます。この挙動が運用安定性の核心であり、同時に設定ミスが混乱を招く原因にもなります。

sssd.conf の基本構成とフォールバック設定

以下は /etc/sssd/sssd.conf の典型的な構成例です。本番環境では2台以上のLDAPサーバーを用意してフォールバックを設定することが推奨されます。

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

[domain/example.com]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap01.example.com, ldap://ldap02.example.com
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = cn=readonly,dc=example,dc=com
ldap_default_authtok = YOUR_BIND_PASSWORD
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

cache_credentials = true
entry_cache_timeout = 3600
offline_credentials_expiration = 2

ldap_uri にカンマ区切りで複数のURIを指定すると、SSSDは先頭から順に接続を試みます。先頭のLDAPサーバーが応答しない場合、次のURIへ自動的にフォールオーバーします。この挙動はSSSD独自の実装であり、LDAPのリファーラル機能とは別物です。混同しないよう注意してください。

offline_credentials_expiration は、LDAPへの疎通が完全に失われた状態（オフライン）でキャッシュ認証を何日間許可するかを指定します。値を 0 にすると期限なしになりますが、アカウント無効化がすぐに反映されないリスクが生まれます。セキュリティポリシーに応じて1〜3日程度に設定するケースが一般的です。

TLS/LDAPS の選択と証明書検証

ldap_tls_reqcert = demand は証明書の検証を必須とする設定です。開発・テスト環境で自己署名証明書を使う場合に never や allow を設定する事例がありますが、本番環境では必ず demand または hard を選択します。2026年現在、主要ディストリビューション（RHEL 9系、Ubuntu 24.04 LTS）ではデフォルトでTLSが必須化されており、demand 以外にすると起動時に警告ログが出力されるケースが増えています。

LDAPS（636番ポート）を使う場合は ldap_uri = ldaps://ldap01.example.com と記述します。StartTLS（389番ポートからTLSに昇格）と混用しないよう、チーム内でポリシーを統一しておくことが重要です。

キャッシュ挙動の検証手順

SSSDのキャッシュは /var/lib/sss/db/ 配下のSQLiteファイルに格納されます。運用中に「LDAPでパスワードを変更したのに反映されない」という問い合わせが発生した場合、まずキャッシュの状態を確認します。

特定ユーザーのキャッシュを即時削除するには sss_cache コマンドを使います。

# 特定ユーザーのキャッシュを無効化
sss_cache -u username

# ドメイン全体のキャッシュを無効化
sss_cache -d example.com

# 全キャッシュを無効化（SSSDを再起動せずに実行可能）
sss_cache -E

sss_cache はキャッシュエントリを削除するのではなく「無効化（expire）」します。次回のアクセス時にSSSDがLDAPへ問い合わせを行い、新しい情報でキャッシュを更新します。LDAPが応答できない状態で sss_cache -E を実行すると、全ユーザーのキャッシュが失効し、LDAPへの疎通が戻るまでログインできなくなる可能性があります。実行タイミングには注意が必要です。

ログとデバッグレベルの活用

SSSDは debug_level をドメインセクションに追加することで詳細なログを出力できます。

[domain/example.com]
debug_level = 6

ログは /var/log/sssd/sssd_example.com.log に出力されます。フォールバック動作の確認には、LDAPサーバー1台を意図的に停止させた状態でログを観察する手法が有効です。debug_level = 6 程度であれば、接続試行・フォールバック・キャッシュヒットの流れがログから読み取れます。本番運用時は debug_level = 0（デフォルト）または 1 に戻すことを忘れないでください。ディスクへの書き込みが著しく増加します。

切り戻しと障害時の対応

SSSD設定に誤りがあって認証が全停止するシナリオは、運用上最も避けたいリスクです。以下の点をあらかじめ押さえておくことが重要です。

• rootアカウントのローカルログインを確保しておく：/etc/nsswitch.conf の passwd 行は通常 files sss の順になっており、files（ローカルの /etc/passwd）が先に参照されます。rootとメンテナンス用アカウントをローカルに残しておくことで、SSSDが完全に停止しても管理者ログインが維持されます。
• sssd.conf のバックアップと差分管理：設定変更前後で diff を保存するか、Ansibleなどで構成管理に組み込んでおくと、切り戻しが容易になります。
• SSSDサービスの再起動と設定再読み込み：systemctl restart sssd はキャッシュを保持したまま再起動します。設定変更を反映させるだけであれば再起動が基本ですが、キャッシュごとリセットしたい場合は /var/lib/sss/db/ 以下のファイルを削除してから再起動します。

フォールバック先のLDAPサーバーがレプリカ構成になっている場合、プライマリとレプリカの同期遅延（レプリケーションラグ）にも注意が必要です。パスワードをプライマリで変更した直後にフォールバックが発動し、古いパスワードで認証成功してしまうケースが報告されています。同期間隔の設定とモニタリングはLDAP側の運用課題として別途管理します。

2026年現在の環境差分と今後の動向

2026年時点での主な環境変化として、以下の点が運用に影響しています。

RHEL 9 / AlmaLinux 9 / Rocky Linux 9：authselect コマンドが認証プロファイルの標準管理ツールとして定着しています。以前のように authconfig や手動でのPAM設定変更は推奨されず、authselect select sssd によってNSSとPAMの設定を一括適用するのが現行の標準手順です。sssd.conf を手書きした後に authselect を実行し忘れると、SSSDが起動していても認証に使われないという混乱が生じます。

Ubuntu 24.04 LTS：sssd パッケージの依存関係が整理され、以前は別途インストールが必要だった sssd-ldap プロバイダが標準パッケージに含まれるようになりました。また、libnss-sss と libpam-sss を個別インストールしてNSS/PAMに組み込む従来の手順は、pam-auth-update ベースの管理に移行しています。

SSSD 2.9以降のキャッシュ改善：2024〜2025年リリースのSSSD 2.9系では、キャッシュの整合性チェックが強化されました。特に entry_cache_nowait_percentage オプション（バックグラウンドでのキャッシュ更新を開始するしきい値）の既定値が変更されており、旧設定をそのまま移植した環境でパフォーマンス挙動が変わるケースがあります。アップグレード時はリリースノートの確認が欠かせません。

FreeIPA（Identity Management）やRed Hat Identity Managementを採用している環境では、SSSDのLDAP直接参照ではなくIPA/AD向けプロバイダを使うことが推奨されています。本記事で扱ったOpenLDAP直接参照は、FreeIPAを導入するほどではない規模の自社インフラや、既存のOpenLDAP資産を流用するケースで有効な選択肢として引き続き使われています。