【389 Directory Server講座 付録】OpenLDAPとの決別。徹底比較表と移行のための「現場の知恵」

「なんとなくOpenLDAP」を卒業するための、最後の授業。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回の「389 Directory Server講座」、完走おめでとうございます。
ここまでで、あなたはRHEL/CentOS系OSにおける次世代の認証基盤を構築するスキルを手に入れました。

しかし、実際の現場には「10年前に構築されたOpenLDAP」が鎮座しており、リプレースの提案書を書こうにも「何がどう違うのか、表で説明してくれ」と上司に言われて詰まる……そんな経験はありませんか？

本記事では、OpenLDAPと389 DSの機能・アーキテクチャ徹底比較表、移行時のスキーマ設計の注意点、そしてトラブルシューティングの深層まで、本編に入りきらなかった「現場の知恵」を余すことなく公開します。

---

第1章：【保存版】OpenLDAP vs 389 Directory Server 徹底比較表

技術選定の根拠となる比較表です。
単なる○×ではなく、現場での「運用実感」に基づいた評価を記載しました。

比較項目	OpenLDAP (Slapd)	389 Directory Server	プロの評価・コメント
設定管理	OLC (cn=config) LDAPツリー内に設定を持つ。 変更には ldapmodify が必須。 ファイル直接編集不可。	DSE (dse.ldif) テキストファイル管理。 vim で編集して再起動で反映可能。 設定の可視性が高い。	障害時に設定ファイルを手動修正できる389 DSの方が、復旧の難易度が低い。OpenLDAPは設定ミスで起動しなくなると修復が困難。
管理ツール	CLI中心 標準GUIなし。 ldap* コマンドは多機能だが引数が複雑。	Cockpit / CLI Web GUI標準搭載。 dsconf, dsidm は人間が読みやすい構文。	専任エンジニアがいない現場では、GUIがある389 DS一択。引き継ぎコストも安い。
レプリケーション	Syncrepl 柔軟だが設定が難解。 マルチマスター(MirrorMode)は競合解決が弱く、運用難易度が高い。	Multi-Master 4台以上のMMRを標準サポート。 CSNによる競合解決が強力で、大規模環境でも安定。	書き込み頻度が高い環境や、拠点が分散している場合は389 DSが圧倒的に有利。
バックエンドDB	LMDB (MDB) 読み取り世界最速。 メモリ効率が極めて良い。 クラッシュに強い。	Berkeley DB (BDB/LMDB) トランザクション処理に強い。 書き込み性能が高い。 チューニング項目が多い。	「1億件のデータを検索する」ような特化型用途ならOpenLDAP。一般的な認証基盤なら389 DSで十分すぎる性能が出る。
アクセス制御	ACL 設定ファイルに記述。 レプリケーションされない（サーバーごとの設定）。	ACI データ内に属性として保持。 データと共にレプリケーションされる。	ACIはデータと一緒に同期されるため、スレーブサーバー構築時の設定漏れを防げる。大規模運用向き。
OSサポート	RHEL 9以降で非推奨/削除。 ソースビルドか、サードパーティ製が必要。	RHEL/CentOS系の標準。 dnf で導入・更新可能。 Red Hatのサポート対象。	エンタープライズLinuxを使うなら、OS標準の389 DSを選ぶのがセキュリティパッチ適用の観点から正解。

---

第2章：移行の壁を越える。スキーマとパスワードハッシュの互換性

「OpenLDAPから389 DSへ移行したい」。
その時、最大の障壁となるのが「スキーマの違い」と「パスワードハッシュ」です。
単純にLDIFをエクスポート/インポートするだけでは、99%の確率でエラーになります。

1. スキーマの差異 (nis vs rfc2307)

OpenLDAPでは nis.schema を使うことが多いですが、389 DSはより厳密な rfc2307bis を推奨しています。
特に問題になるのが memberOf 属性です。

• OpenLDAP: Overlay機能で動的に生成するか、静的に持たせる。
• 389 DS: MemberOfプラグインで動的に管理する。

移行テクニック：
移行元のLDIFから memberOf 属性を削除してからインポートしてください。
389 DS側でMemberOfプラグインを有効にし、Fixupタスクを実行すれば、グループ所属情報（member属性）を元に自動的に再生成されます。

2. パスワードハッシュの互換性 ({SSHA}, {CRYPT})

ユーザーのパスワード（userPassword属性）は、暗号化（ハッシュ化）されています。
幸いなことに、389 DSはOpenLDAPで標準的な {SSHA} (Salted SHA-1) をサポートしています。
そのため、LDIF内の userPassword: {SSHA}xxxx... という行は、そのままインポートして使用可能です。

ただし、非常に古い {CRYPT} や {MD5} を使っている場合は注意が必要です。
389 DS側でレガシーハッシュのサポートを有効にするか、移行を機にユーザーにパスワード変更を強制する（次回ログイン時変更）運用にするのがセキュリティ上好ましいです。

3. 独自のObject ClassとAttribute

OpenLDAPで /etc/openldap/schema/local.schema などを独自定義していた場合、それに対応するスキーマファイルを389 DS側にも作成する必要があります。
389 DSのスキーマファイルは /etc/dirsrv/slapd-{instance}/schema/99user.ldif に配置します。
書式はほぼ同じ（RFC準拠）なので、コピー＆ペーストで微調整すれば通ることが多いです。

---

第3章：プロのトラブルシューティング。DB破損とログ解析

長く運用していると、停電やディスクフルでデータベースファイル（Berkeley DB）が破損することがあります。
「サービスが起動しない」「特定のエントリを検索すると落ちる」。
そんな時の、冷や汗ものの復旧手順を伝授します。

1. データベースのエクスポート（db2ldif）

サービスが起動しなくても、DBファイルが生きていればコマンドラインツールでデータを救出できます。

# サービス停止状態で実行
db2ldif -Z localhost -n userRoot -a /tmp/rescue.ldif

-Z はインスタンス名、-n はバックエンド名です。
これでLDIF形式でデータが抜け出せれば勝ちです。

2. データベースの再作成とインポート（ldif2db）

破損したDBファイルを再作成し、救出したデータを流し込みます。

# 既存DBの退避（念のため）
mv /var/lib/dirsrv/slapd-localhost/db/userRoot /var/lib/dirsrv/slapd-localhost/db/userRoot.bak

# インポート（同時にDB再作成が行われる）
ldif2db -Z localhost -n userRoot -i /tmp/rescue.ldif

これでインデックスも再生成され、クリーンな状態で復旧します。

3. アクセスログの詳細解析

「誰かが大量のクエリを投げてサーバーを落とした」。犯人を特定するにはログ解析が必須です。
389 DSのアクセスログ（/var/log/dirsrv/slapd-{instance}/access）には、以下の重要情報が含まれています。

• conn=1234: 接続ID。これをキーにgrepすれば、接続から切断までの一連の流れが追えます。
• etime=0.005: 処理時間（秒）。これが大きい行を探せば、重いクエリが見つかります。
• notes=U: Unindexed（インデックスなし）。これが出ている検索はサーバー殺しです。即座に対策が必要です。

ワンライナー解析例：

# 処理に1秒以上かかった検索を抽出
grep "SRCH" access | awk -F'etime=' '$2 > 1.0 {print $0}'

---

第4章：運用自動化のヒント。バックアップと監視

「壊れても大丈夫」な状態を作ることこそ、エンジニアの仕事です。

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

389 DSには db2bak というオンラインバックアップコマンドがあります。
これをCronで回しましょう。

#!/bin/bash
BACKUP_DIR="/var/lib/dirsrv/slapd-localhost/bak/$(date +%Y%m%d)"
dsconf localhost backup create $BACKUP_DIR
# 古いバックアップの削除（7日分保存）
find /var/lib/dirsrv/slapd-localhost/bak/ -maxdepth 1 -type d -mtime +7 -exec rm -rf {} \;

監視項目（Zabbix / Prometheus）

プロセス監視だけでは不十分です。
以下の項目を監視することで、障害の予兆を検知できます。

1. LDAP応答時間: 定期的にダミー検索を行い、応答時間を計測する。
2. ファイルディスクリプタ使用数: 接続数が増えすぎていないか。
3. レプリケーション遅延: dsconf localhost replication monitor の結果をパースし、遅延が発生していないか確認する。

---

第5章：エンジニアのキャリア戦略。なぜ今389 DSなのか

最後に、少しメタな話をしましょう。
なぜ、これほど詳細に389 DSを学ぶ必要があるのでしょうか？

1. 「ID管理」はインフラの最重要スキル

クラウド時代になっても、IAM（Identity and Access Management）の重要性は増すばかりです。
AWSのIAMも、Azure ADも、基本思想はLDAPとKerberosです。
オンプレミスのLDAPを深く理解しているエンジニアは、クラウドの認証基盤設計でも強い力を発揮します。

2. Red Hatエコシステムの中心

企業システムにおいてRHELのシェアは依然として巨大です。
そのRHELが標準採用している389 DS（およびFreeIPA）を扱えることは、エンタープライズ案件での市場価値を高めます。
「OpenLDAPしか触れません」というエンジニアよりも、「389 DSでマルチマスター組めます」「SSSDでキャッシュ制御できます」というエンジニアの方が、単価も信頼度も高いのは明白です。

3. レガシーからの脱却案件

現在、多くの企業が「塩漬けにされた古いOpenLDAP」のリプレースに頭を抱えています。
この「389 DSへの移行スキル」は、今後数年間、ニッチですが確実に需要がある分野です。
本講座で学んだ知識は、あなたの強力な武器になるはずです。

---

まとめ：技術選定は「未来への投資」である

全8回＋付録、本当にお疲れ様でした。
389 Directory Serverは、OpenLDAPの弱点を克服し、現代的な運用に耐えうるように設計された強力なソフトウェアです。

しかし、ツールはあくまでツールです。
重要なのは、あなたがそのツールの特性を理解し、組織の要件に合わせて適切に設計・運用することです。
「なんとなく」で選ぶのではなく、「理由があって」選ぶ。
そのための判断材料として、この比較表とノウハウを活用してください。

これで「389 Directory Server講座」はすべて終了です。
また別の技術講座でお会いしましょう。
Good Luck, and Happy Hacking!