【OpenLDAP基本講座 補足】実運用で差がつく「パスワードポリシー」と「監査ログ」の完全実装

「構築完了」のその先へ。プロのLDAPはここが違う。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回の「OpenLDAP基本講座」、完走おめでとうございます。
基本編だけで十分に稼働する認証基盤は作れますが、いざ企業のインフラとして運用を始めると、必ずと言っていいほど「追加の要望」が飛んできます。

「パスワードを90日ごとに変更させたい」「5回間違えたらアカウントをロックして」「誰がいつデータを書き換えたかログを残してほしい」。
これらは、OS側の設定だけでは実現困難か、不完全になりがちです。
OpenLDAP自身が持つ拡張機能 Overlay（オーバーレイ） を使いこなすことで、これらの要件をスマートに解決できます。

本記事では、OpenLDAPの機能を拡張するモジュール（Overlay）の中から、実務で特に重要となる「PPolicy（パスワードポリシー）」「Accesslog（監査ログ）」「Refint（参照整合性）」の実装方法を徹底解説します。

---

第1章：パスワードポリシー (PPolicy) の導入。有効期限とロックアウト

Linuxの /etc/login.defs や pam_tally2 でパスワード管理をしている場合、サーバーが100台あれば100台分の設定管理が必要です。
OpenLDAPの PPolicy (Password Policy) 機能を使えば、ポリシーをLDAPサーバー側で一元管理し、全クライアントに強制適用できます。

1. モジュールのロードとスキーマ適用

PPolicyは標準では有効になっていません。モジュールをロードし、専用のスキーマを適用します。

モジュールロード用LDIF (load_ppolicy.ldif)

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy

ldapmodify -Y EXTERNAL -H ldapi:/// -f load_ppolicy.ldif

スキーマの適用
OpenLDAPに同梱されている ppolicy.ldif を適用します。

ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/ppolicy.ldif

2. Overlayの設定

メインのデータベース（MDB）に、PPolicy機能を被せます。

overlay_ppolicy.ldif

dn: olcOverlay=ppolicy,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=Policies,dc=linuxkoubou,dc=com
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: TRUE

• olcPPolicyDefault: ポリシーが指定されていないユーザーに適用するデフォルトポリシーのDN。
• olcPPolicyUseLockout: ロックアウト機能（ログイン失敗によるアカウント停止）を有効にするか。

3. ポリシーオブジェクトの作成

具体的なルール（有効期限や試行回数）を記述したエントリを作成します。
まず、ポリシー格納用のOUを作ります。

dn: ou=Policies,dc=linuxkoubou,dc=com
objectClass: organizationalUnit
ou: Policies

次に、デフォルトポリシーを作成します。

dn: cn=default,ou=Policies,dc=linuxkoubou,dc=com
objectClass: pwdPolicy
objectClass: device
cn: default
pwdAttribute: userPassword
pwdMaxAge: 7776000      # 有効期限: 90日 (秒単位)
pwdExpireWarning: 604800 # 警告開始: 7日前
pwdInHistory: 3         # 過去3回分のパスワードを再利用禁止
pwdCheckQuality: 1      # パスワード品質チェック (モジュール連携が必要)
pwdMinLength: 8         # 最小文字数
pwdMaxFailure: 5        # 5回失敗でロック
pwdLockout: TRUE        # ロックアウト有効化
pwdLockoutDuration: 1800 # 30分間ロック (0なら管理者解除まで永久ロック)
pwdFailureCountInterval: 900 # 15分経過で失敗カウントリセット

これで、LDAP上の全ユーザーに対して「90日で変更必須、5回失敗で30分ロック」というルールが適用されます。
特定ユーザーだけルールを変えたい場合は、そのユーザーエントリに pwdPolicySubentry 属性を追加し、別のポリシーDNを指定します。

---

第2章：監査ログ (Accesslog) の実装。操作履歴をDB化する

loglevel stats で出力されるsyslogは、「誰が接続したか」は分かりますが、「具体的にどの属性をどう変更したか（変更前の値は何だったか）」までは記録されにくいです。
Accesslog Overlay を使うと、LDAPの操作履歴そのものを、別のLDAPデータベースとして詳細に記録できます。

1. 監査ログ用データベースの作成

通常のユーザーデータとは別に、ログ保存用のDBを作成します。

db_accesslog.ldif

# モジュールロード
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: accesslog

# DB作成
dn: olcDatabase={3}mdb,cn=config
changetype: add
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {3}mdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=accesslog
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
olcDbMaxSize: 10737418240  # 10GB

※ /var/lib/ldap/accesslog ディレクトリを作成し、権限を ldap:ldap にしておく必要があります。

2. Overlayの設定

メインDB ({2}mdb) に対する操作を、先ほど作ったログDB (cn=accesslog) に転送する設定です。

overlay_accesslog.ldif

dn: olcOverlay=accesslog,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes    # 書き込み操作のみ記録 (readsを入れると爆発的に増えるので注意)
olcAccessLogSuccess: TRUE  # 成功した操作のみ記録
olcAccessLogPurge: 30+00:00 1+00:00 # 30日経過したログを毎日削除

3. ログの確認方法

監査ログもLDAPエントリとして保存されているため、ldapsearch で検索できます。

# 昨日以降の変更履歴を検索
ldapsearch -x -b "cn=accesslog" "(reqStart>=20231001000000Z)"

検索結果には、reqType: modify や reqMod: mail:+ new@example.com のように、具体的な変更内容が表示されます。
「いつの間にかデータが変わっている！」というミステリーを解く最強のツールです。

---

第3章：データ整合性の維持 (Refint / Unique)。ゴミデータを残さない

RDBMSの「外部キー制約」や「ユニーク制約」に相当する機能も、Overlayで実現できます。

Refint (参照整合性)

「ユーザー (uid=taro) を削除した時、グループ (cn=developers) の member 属性に残っている uid=taro のDNを自動で削除する」機能です。
これを入れないと、グループメンバーに「存在しないユーザー」が残り続け、アプリケーションのエラー原因になります。

overlay_refint.ldif

# モジュールロード
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: refint

# Overlay設定
dn: olcOverlay=refint,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
olcOverlay: refint
olcRefintAttribute: member memberOf manager owner

olcRefintAttribute に、連動して更新したい属性名を列挙します。

Unique (ユニーク制約)

「メールアドレス (mail) は全ユーザーで重複してはいけない」というルールを強制します。

overlay_unique.ldif

# モジュールロード
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: unique

# Overlay設定
dn: olcOverlay=unique,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: unique
olcUniqueURI: ldap:///?mail?sub

これにより、既に使われているメールアドレスを登録しようとすると、LDAPサーバーがエラー（Constraint Violation）を返し、登録を拒否します。

---

第4章：LMDBの真実。スパースファイルとディスク容量の罠

現在のOpenLDAPの標準バックエンドである MDB (LMDB) は非常に優秀ですが、1点だけ運用者が知っておくべき仕様があります。
それは「スパースファイル（疎なファイル）」の扱いです。

data.mdb のサイズ問題

設定で olcDbMaxSize: 10737418240 (10GB) と指定すると、ls -l で見た時に、作成直後から data.mdb が 10GB のサイズに見えることがあります。
「データが入っていないのにディスクがいっぱい！？」と焦らないでください。

# 見かけのサイズ (10GBに見える)
ls -lh /var/lib/ldap/data.mdb

# 実際のディスク消費量 (数MBしかない)
du -h /var/lib/ldap/data.mdb

LMDBは、あらかじめ巨大なメモリ空間をマッピングするためにスパースファイルを使用します。
実際のディスク消費量はデータ量に比例して増えていきますが、cp コマンドなどで単純コピーすると、スパース性が失われて本当に10GB消費してしまうことがあるので注意が必要です。

対策： バックアップやコピーには必ず slapcat を使うか、スパースファイルを扱えるオプション（cp --sparse=always や rsync -S）を使用してください。

---

第5章：便利なツール紹介。ldapviで快適編集

LDIFファイルを書いて ldapmodify するのが正攻法ですが、ちょっとした修正には面倒です。
Linuxエンジニアなら ldapvi を使いましょう。

ldapvi とは？

検索結果を vim エディタで開き、編集して保存すると、その差分を自動的にLDAPサーバーに反映してくれるツールです。

# インストール (EPELリポジトリ等が必要)
dnf install ldapvi

# 実行例（全ユーザーを検索して編集）
ldapvi -Y EXTERNAL -H ldapi:/// -b "ou=People,dc=linuxkoubou,dc=com"

実行すると、エディタが起動します。
電話番号などを修正して :wq で保存すると、確認画面が出た後、変更が適用されます。
cn=config の修正にも使えるため、管理者の必須ツールと言えます。

---

まとめ：OpenLDAPは「育てていく」システム

お疲れ様でした！
補足記事では、本編では触れられなかった「実運用のための高度な機能」を紹介しました。

今回の重要ポイント：

• PPolicyを使えば、パスワード有効期限やロックアウトを一元管理できる。
• Accesslog Overlayは、トラブル調査や監査対応の強力な武器になる。
• Refintを設定しておけば、グループ情報の整合性を気にする必要がなくなる。
• LMDBのサイズは見かけ上のもの。du コマンドで実容量を確認する。

これで「OpenLDAP基本講座」の全コンテンツ（本編8回＋補足記事）が完結しました。
長期間のお付き合い、ありがとうございました。
また別の技術講座でお会いしましょう！