【OpenLDAP基本講座 第8回】クライアント連携と運用。SSSDによるオフライン認証と鉄壁のバックアップ術

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

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

しかし、サーバーは「使われて」初めて価値を持ちます。
今回は、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章：クライアント構築。authselectによるPAM設定

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

1. インストール

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

• sssd: 本体デーモン。
• sssd-ldap: LDAP連携用プロバイダ。
• 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. oddjobdの起動

ホームディレクトリ作成サービスを起動します。

systemctl enable --now oddjobd

---

第3章：SSSDの設定。sssd.confの完全解説

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

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

第6回で構築したLDAPS対応のOpenLDAPサーバーに接続する設定です。

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

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

# LDAP接続設定
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.crt

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

# スキーマ設定 (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

動作確認

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

id taro

uid=1001(taro) gid=1001(taro) groups=1001(taro)... のように表示されれば、NSS（名前解決）の連携は成功です。
この状態で su - taro や SSHログインを試してみてください。

---

第4章：運用トラブル。キャッシュの罠と削除方法

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/*
rm -f /var/lib/sss/mc/*
systemctl start sssd

これは荒療治ですが、最も確実にクライアントの状態をリセットできます。

---

第5章：バックアップ戦略。slapcatの正しい使い方

ここからはサーバー側（OpenLDAP）の話に戻ります。
システム運用において、バックアップは命綱です。
しかし、OpenLDAPのバックアップには「やってはいけない方法」があります。

NG: ディレクトリのコピー (cp -r)

/var/lib/ldap/ をそのままコピーする方法は、サービス停止中ならギリギリOKですが、稼働中に行うとデータベース不整合（破損）の原因になります。
Berkeley DBやLMDBはメモリ上にデータをキャッシュしているため、ディスク上のファイルだけコピーしても完全ではないのです。

OK: slapcat による論理バックアップ

OpenLDAP標準の slapcat コマンドを使います。
これは稼働中でも実行可能で、データベースの中身をテキスト形式（LDIF）でダンプします。

バックアップ対象は2つある

OpenLDAPには「設定(config)」と「データ(data)」の2つのDBがあります。両方バックアップが必要です。

# 設定 (cn=config) のバックアップ
slapcat -n 0 -l /backup/config_$(date +%Y%m%d).ldif

# データ (メインDB) のバックアップ
slapcat -n 2 -l /backup/data_$(date +%Y%m%d).ldif

※ -n 2 は環境によって異なります。/etc/openldap/slapd.d/cn=config/ を見て確認してください。

自動バックアップスクリプト例

これをcronに仕込んでおけば安心です。

#!/bin/bash
BACKUP_DIR="/var/backup/ldap"
DATE=$(date +%Y%m%d)

mkdir -p $BACKUP_DIR

# 設定とデータをダンプ
slapcat -n 0 -l $BACKUP_DIR/config_$DATE.ldif
slapcat -n 2 -l $BACKUP_DIR/data_$DATE.ldif

# 7日以上前のファイルを削除
find $BACKUP_DIR -name "*.ldif" -mtime +7 -exec rm -f {} \;

---

第6章：リストア手順。壊れたデータベースを復旧する

バックアップがあっても、戻し方を知らなければ意味がありません。
障害発生時、焦らず以下の手順を実行してください。

1. サービスの停止

リストアは必ずサービスを停止した状態で行います。

systemctl stop slapd

2. 既存データの退避・削除

壊れたデータを残しておくとリストアできません。
ディレクトリごと退避するか、中身を空にします。

# 設定ディレクトリのクリア（設定を戻す場合）
rm -rf /etc/openldap/slapd.d/*

# データディレクトリのクリア
rm -rf /var/lib/ldap/*

3. データの流し込み (slapadd)

slapadd コマンドを使って、LDIFファイルからデータベースを再構築します。

# 設定のリストア (-F で設定ディレクトリを指定)
slapadd -n 0 -F /etc/openldap/slapd.d -l /backup/config_20230101.ldif

# データのリストア
slapadd -n 2 -l /backup/data_20230101.ldif

4. 権限の修正（最重要！）

slapadd をrootで実行すると、作成されたファイルの所有者が root になってしまいます。
これでは ldap ユーザーで動くサービスが読み込めず、起動に失敗します。
必ず権限を修正してください。

chown -R ldap:ldap /etc/openldap/slapd.d
chown -R ldap:ldap /var/lib/ldap

5. サービスの起動

systemctl start slapd

これで元通りです。

---

最終回まとめ：OpenLDAPはインフラの背骨である

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

本講座で得たもの：

1. 理論： DITやスキーマといった、ディレクトリサービスの根幹概念。
2. 技術： cn=config 操作、LDIFの読み書き、TLS化、レプリケーション構築。
3. 運用： SSSDによるクライアント連携、バックアップ・リストア手法。

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