【389 Directory Server講座 第1回】OpenLDAP vs 389 DS。アーキテクチャの違いから学ぶ、次世代LDAPの選定基準

そのLDAPサーバー、惰性で「OpenLDAP」を選んでいませんか？

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
Linux環境での認証基盤（ID管理）構築において、長年デファクトスタンダードとして君臨してきたのが「OpenLDAP」です。

多くのエンジニアにとって、「LDAPサーバーを構築する＝OpenLDAPをインストールする」は、疑う余地のない常識でした。
しかし、RHEL (Red Hat Enterprise Linux) 8以降、Red Hat社はOpenLDAPサーバーパッケージのサポートを終了し、自身のID管理ソリューションであるIdM (Identity Management)への移行を強く推奨しています。
そのIdMの中核エンジンとして稼働しているのが、今回紹介する「389 Directory Server」です。

本シリーズでは、OpenLDAPに代わる選択肢として注目の「389 Directory Server」について、全8回で構築から運用までを解説します。
第1回は、技術選定の基礎となる「OpenLDAPとの比較とアーキテクチャ」です。

---

第1章：389 Directory Serverとは何か？ その系譜

比較に入る前に、389 DSの立ち位置を整理しておきましょう。
これは、ぽっと出の新しいソフトウェアではありません。非常に長い歴史と実績を持つソフトウェアです。

歴史的背景：NetscapeからRed Hatへ

389 Directory Serverの起源は、インターネット黎明期にWebブラウザで覇権を握っていたNetscape社が開発した「Netscape Directory Server」にあります。
当時、商用LDAPサーバーとして最高峰の性能と安定性を誇っていました。

1. Netscape Directory Server: 起源。商用製品。
2. Red Hat Directory Server (RHDS): Red Hat社がNetscapeの部門を買収し、RHEL向けの商用製品として販売。
3. Fedora Directory Server: RHDSのソースコードをオープンソース化。
4. 389 Directory Server: 名称変更。現在に至る。

つまり、FedoraがRHELのアップストリーム（開発版）であるように、389 DSはRHDSのアップストリームにあたります。
エンタープライズ製品のベースとして長年鍛え上げられているため、大規模環境での実績と安定性は折り紙付きです。

---

第2章：徹底比較 OpenLDAP vs 389 Directory Server

ここが本題です。
「設定のしやすさ」「性能」「機能」など、エンジニアが気になるポイントごとに、両者を徹底比較します。

比較項目	OpenLDAP	389 Directory Server
設定管理	OLC (cn=config) 設定をLDAPツリー内に持つ。 変更には ldapmodify が必須。 動的反映は得意だが、可読性は低い。	dse.ldif (テキストファイル) /etc/dirsrv/.../dse.ldif を直接編集可能。 vimで編集し、再起動で反映。 従来のLinux設定に近い感覚で管理できる。
管理ツール	基本はCLI (ldap* コマンド)。 標準GUIはなく、サードパーティ製 (phpLDAPadmin等) に依存。	Cockpit (Web GUI) が標準付属。 CLIも dsconf, dsidm などPython製で、JSON出力対応など自動化に強い。
レプリケーション	Syncrepl / MirrorMode 柔軟だが設定が複雑。 マルチマスター構築時の競合解決が難しい。	Multi-Master Replication (MMR) 4台以上のマルチマスターを容易に構築可能。 競合解決ロジックが強固で、大規模環境向き。
バックエンドDB	MDB (LMDB) が主流。 読み取り速度は世界最速クラス。 メモリ効率が極めて良い。	Berkeley DB (BDB/LMDB)。 書き込みトランザクションに強い。 更新頻度が高い環境で安定する。
アクセス制御	ACL (slapd.conf/olc) 設定ファイルまたはconfig DBに記述。 サーバー全体の設定として管理。	ACI (Access Control Instructions) ディレクトリデータ内に「属性」として保持。 レプリケーションで権限設定も同期される。

比較1：設定ファイルの「可読性」と「復旧性」

OpenLDAPの最大のハードルは、設定ファイル（slapd.conf）が廃止され、設定自体をLDAPデータベースの中に入れてしまったこと（OLC / cn=config）です。
「設定を1行変えるために、LDIFファイルを書いて ldapmodify コマンドを打つ」という手順は、Ansibleなどで自動化する分には良いですが、障害時に「設定ファイルを目視確認して修正する」ことが困難です。

対して、389 DSは dse.ldif というテキストファイルで設定を管理します。
これは単なるテキストファイルです。
設定ミスで起動しなくなっても、バックアップしておいた dse.ldif を cp コマンドで戻すだけで復旧できます。
「設定が見える、触れる」という安心感は、運用担当者にとって絶大です。

比較2：レプリケーションの「堅牢性」

OpenLDAPでもマルチマスター構成（MirrorMode）は可能ですが、ネットワーク分断（スプリットブレイン）が発生した際の復旧手順が複雑です。
また、設定ミスにより「循環レプリケーション」が起きるリスクもあります。

389 DSのマルチマスターレプリケーションは、商用環境で鍛えられた非常に堅牢な仕組みを持っています。
CSN (Change Sequence Number) と呼ばれるタイムスタンプベースの管理IDを用いて、どのサーバーで行われた変更が最新かを厳密に判定します。
「4拠点にマスターを置き、どこが落ちても書き込みを継続させる」といった構成も、GUIから数クリックで設定可能です。

比較3：管理ツールの「モダンさ」

389 DSは、RHELの標準管理コンソールであるCockpitにプラグインとして統合されています。
Webブラウザから、サービスの起動停止、レプリケーションの状態監視、ログの確認、さらにはスキーマの拡張まで、クリック操作で行えます。

また、コマンドラインツールも刷新されました。
従来の ldapsearch 等に加え、Pythonで書かれた管理コマンド（dsconf, dsidm）が提供されています。
これらは --json オプションで結果をJSON形式で出力できるため、jq コマンドと組み合わせたスクリプト作成が劇的に楽になります。

---

第3章：アーキテクチャの違い。プラグイン方式の優位性

389 DSの設計思想の核にあるのが「プラグインアーキテクチャ」です。
OpenLDAPの「Overlay」に近い概念ですが、より独立性が高く、管理が容易です。

すべてはプラグインである

389 DSでは、LDAPのコア機能以外の多くが「プラグイン」として実装されており、動的にON/OFFが可能です。
例えば：

• MemberOf プラグイン: ユーザーエントリ側に「所属グループ情報（memberOf属性）」を自動的に持たせる機能。Active Directory互換の挙動を実現するために必須です。
• Retro Changelog プラグイン: 変更履歴を保存し、レプリケーションや監査に利用する機能。
• Account Lockout プラグイン: パスワード試行回数によるロックアウト機能。
• Attribute Uniqueness プラグイン: 「社員番号の重複を許さない」といった制約を強制する機能。

これらの設定もすべて dse.ldif または dsconf コマンドで管理でき、再コンパイルなどは不要です。

---

第4章：選定基準。あなたはどちらを選ぶべきか？

ここまで389 DSのメリットを強調しましたが、OpenLDAPが劣っているわけではありません。
現場の要件に合わせて、適切な方を選ぶべきです。

OpenLDAPを選ぶべきケース

• 極限の読み取りパフォーマンスが必要: 読み取り速度（Read）に関しては、OpenLDAPのMDBバックエンドは世界最速クラスです。数千万件のエントリを捌く超大規模な参照専用サーバーには適しています。
• リソースが極小: IoTデバイスやコンテナなど、メモリリソースが極端に少ない環境では、C言語で書かれたOpenLDAPの方が軽量です。
• Debian/Ubuntu系OSを使用: これらのディストリビューションでは、依然としてOpenLDAPが主流であり、パッケージ管理も容易です。

389 Directory Serverを選ぶべきケース

• RHEL系OS (Alma/Rocky/CentOS) を使用: OS標準のサポートが手厚く、dnf で簡単に導入できます。将来的なIdM (FreeIPA) への移行パスも確保できます。
• 運用管理を楽にしたい: CockpitによるGUI管理や、直感的なCLIツールを使いたい場合。専任のLDAP管理者がいない組織に向いています。
• Active Directoryと連携したい: パスワード同期機能（Winsync）や、ADライクなスキーマ構成が必要な場合。
• 書き込み負荷が高い: 更新頻度が高い環境や、堅牢なマルチマスター構成が必要な場合。

---

第5章：まとめ。次世代の標準へ移行しよう

お疲れ様でした！
第1回は、OpenLDAPと389 DSの違いについて、アーキテクチャの視点から解説しました。

今回の重要ポイント：

• 389 DSは「商用レベルの管理機能」を持つOSSのLDAPサーバーであり、RHELの標準である。
• 設定ファイルがテキスト形式（dse.ldif）であり、OpenLDAPのLDIF地獄から解放される。
• マルチマスターレプリケーションが強力で、可用性設計が容易。
• 読み取り特化ならOpenLDAP、管理性と書き込み耐性なら389 DS。

次回、第2回は「爆速インストール。CockpitによるWeb GUI管理環境の構築」です。
dnf コマンドでのインストールから、インスタンスの作成、そしてブラウザからアクセスして初期設定を行うまでを、ステップバイステップで解説します。お楽しみに！