1. OpenLDAP ディレクトリサービスの紹介
この文書は、ディレクトリサービスを提供するソフトウェアである OpenLDAP のインストール、設定、操作の方法について説明します。この文書には、スタンドアローン
1.1. ディレクトリサービスとは？
ディレクトリは特殊なデータベースであり、読取り、ブラウズ、検索の用途に最適化されています。ディレクトリは、記述的で属性ベースの情報を保持し、洗練されたフィルター機能をサポートしています。ディレクトリでは一般に、複雑なトランザクションやロールバック機構をサポートしません。このような機構は、データベース管理システムのように大量の複雑な更新を処理するよう設計されたもので必用とされるものです。ディレクトリの更新は、普通は all-or-nothing の単純な書換えに過ぎません。ディレクトリは、大量の照会あるいは検索操作に即応できるように最適化されています。ディレクトリには情報を広く複製する能力があり、稼働率と信頼性を向上、かつレスポンスタイムを削減できます。ディレクトリ情報が複製されている場合、一時的な不整合が発生するかもしれませんが、定期的に同期をとるようにしておけば問題ありません。
ディレクトリサービスの提供方法には色々な種類があります。このため、ディレクトリに保存する情報の種類が多様になり、一方では情報の参照、問合せ、更新や、認可されないアクセスからどのように情報を守るかなどに関して色々な要求が生じます。ローカルで限られた対象(たとえば、単一のマシンの finger サービスなど)のみへのサービスを提供するようなディレクトリサービスがある一方、グローバルではるかに広い対象(たとえば、インターネット全体)にサービスを提供するようなサービスもあります。グローバルサービスはたいてい分散しています。すなわち、データが多くのマシン(そのすべてがディレクトリサービスを提供するよう協調している)に分割して格納されています。通常、グローバルサービスはデータ自体に関して、あなたがどこにいても問題のない同じデータのビューを与えるよう一定の名前空間を定義しています。インターネット
1.2. LDAP とは？
ディレクトリにはどんな情報を格納できるのか？ LDAP のディレクトリサービスのモデルはエントリを基にしています。エントリとは、識別名 (
情報はどのようになっているのか？ LDAP においてディレクトリのエントリは、階層ツリー構造に配置されます。伝統的に、この階層ツリーには地理、組織などの境界が反映されます。ツリーの最上位には国を表すエントリがあり、その下には全国的な組織を表すエントリがあり、さらにその下には組織単位、人、プリンタ、文書など、考えられるほとんどのものを表すエントリを置きます。伝統的な命名法を使った LDAP ディレクトリツリーの例を図1.1に示します。
図1.1：LDAP ディレクトリツリー(伝統的な命名法)
ツリーはインターネットドメイン名を基にすることもできます。この命名法は、DNS を利用してディレクトリサービスを捜し出せるようにするものとして一般化してきています。図1.2はドメインベースの命名法使った LDAP ディレクトリの例です。
図1.2：LDAP ディレクトリツリー(インターネット命名法)
さらに、LDAP では objectClass という特殊な属性を用いて、エントリに必要な属性と保有できる属性を制御できます。属性 objectClass の値は、エントリが従わなければならない スキーマ規則を決定します。
情報はどのように参照するのか？ エントリはその識別名で参照されます。識別名は、相対識別名(
情報にはどうアクセスするのか？ LDAP はディレクトリに対する質問と更新を行う操作を定義しています。提供される操作には、ディレクトリへのエントリの追加と削除、既存のエントリの変更、エントリの名前の変更があります。しかしほとんどの場合、LDAP はディレクトリ中の情報の検索に使われます。 LDAP の検索操作では、ディレクトリのある部分に対して検索フィルタで指定する条件に一致するエントリを検索できます。条件に一致したエントリのそれぞれに対して情報を要求できます。
たとえば名前が Barbara Jensen である人を dc=example,dc=com のサブツリー全体から検索して、見つかったエントリのそれぞれの電子メールアドレスを取り出したいとします。LDAP でこれを行うのは簡単です。また、名前に Acme という文字列を含み、FAX 番号を持った組織を st=California,c=US エントリの直下から検索したいとします。 LDAP でこれを行うのも簡単です。次の節では、LDAP で何ができるのか、なんの役に立つのかをより詳しく説明します。
認められないアクセスからどう情報を守るのか？ ディレクトリサービスによっては何も保護しないで、だれでも情報を参照できるようにしています。LDAP は、クライアントに認証の機構を提供するか、クライアントの身元をディレクトリサーバに証明してもらうことにより、サーバが保有する情報を保護するための高度なアクセス制御を容易にしています。 LDAP は、機密性と一貫性のセキュリティサービスもサポートしています。
1.3. LDAP はどのように動作するのか？
LDAP ディレクトリサービスは、クライアントサーバモデルを基にしています。一つ以上のディレクトリサーバが、ディレクトリツリー情報(Directory Information Tree: DIT)を構成するデータを保有しています。クライアントは LDAP サーバに接続し、そのサーバに対して質問します。この質問に対してサーバは回答を返したりクライアントが追加情報を探し出せる場所へのポインタ(通常は別のLDAPサーバ)を返したりします。クライアントからは、どの LDAP サーバに接続してもディレクトリは同じように見えます。ある LDAP サーバに提示した名前は別の LDAP サーバでも同じエントリを参照します。これは、LDAP のようなグローバルディレクトリサービスの重要な特性です。
1.4. X.500 とは何か？
技術的に見れば
LDAP はまだゲートウェイを介して X.500 ディレクトリサービスのアクセスに使われていますが、今では X.500 サービス自体で提供するようになってきています。
スタンドアローンの LDAP デーモン(あるいは slapd(8))は、 軽量の X.500 ディレクトリサーバとみなせます。つまり、 X.500 の DAP は提供していません。軽量ディレクトリサーバとして、 slapd(8) は X.500 モデルのサブセットを提供するだけです。
既に X.500 DAP サービスを運用していて今後も継続して利用していくつもりなのであれば、このガイドを読むのをやめたほうがよいかもしれません。このガイドは slapd(8) で LDAP を動作させることについてがすべてであって、X.500 DAP を動作させることはありません。 X.500 DAP まだ利用していないか、X.500 DAP の利用を止めたいか、すぐに X.500 DAP を利用する計画がないのであれば読み進めてください。
LDAP ディレクトリサーバから X.500 DAP
1.5. LDAPv2 と LDAPv3 は何が違うのか？
LDAPv3 は、1990 年代後半に LDAPv2 に代わるものとして開発されました。 LDAPv3 は LDAP に次の機能を追加しています。
SASL を利用した強力な認証TLS (SSL)を利用した一貫性と機密性の保護- Unicode 利用による国際化対応
- 紹介(referral)と継続(continuation)
- スキーマ開示
- 拡張性(コントロールや拡張操作など)
LDAPv2 はもう時代遅れです(RFC3494)。 LDAPv2 をサポートする(slapd(8)を含む)処理系のほとんどは、 LDAPv2 の技術仕様に従っていないので、LDAPv2 で処理系間の相互運用性を確保するのには限界があります。 LDAPv2 は LDAPv3 とかなり異なっているので、LDAPv2 と LDAPv3 の両方を同時に扱うと、かなり厄介なことになります。 LDAPv2 の利用はやめるべきです。LDAPv2 はデフォルトで無効してあります。
1.6. slapd とは何か、何ができるのか？
slapd(8) は多くのプラットフォームで動作する LDAP ディレクトリサーバです。これを使えば独自のディレクトリサービスを提供できます。ディレクトリには置きたいもののほとんどを入れておけます。グローバル LDAP ディレクトリサービスに接続されるようにすることも、ローカルにサービスをすべて提供することもできます。 slapd の興味深い機能と能力のいくつかを次にあげます。
LDAPv3: slapd は
トポロジー制御: slapd では、ネットワークトポロジーを基にしたサーバへのアクセス制限が可能です。この機能には TCP wrappers を利用します。
アクセス制御: slapd は高度で強力なアクセス制御機能を提供します。この機能によりデータベース内の情報へのアクセスを制御できます。LDAP の認可情報、
国際化: slapd は Unicode と言語タグをサポートしています。
データベースバックエンドの選択: slapd には選択可能なさまざまなデータベースバックエンドがあります。これらの中には、高速でトランザクション制御可能なデータベースバックエンド
複数のデータベース実体: slapd は同時に複数のデータベースを扱うように設定できます。つまり、LDAP ツリーの論理的に異なる部分についての要求に単一の slapd で応答できます。この LDAP ツリーの各部には、同じバックエンドデータベースを使ってもよいですし、違うデータベースバックエンドを使ってもかまいません。
汎用モジュール API: さらなるカスタム化が必要な場合を想定して、 slapd では容易に独自のモジュールを書けるようになっています。 slapd はフロントエンドとモジュールの二つの部分から成っています。フロントエンドは LDAP クライアントとのプロトコル通信を処理します。モジュールはデータベース操作のような特定の作業を処理します。これら二つの部分の間では、よくできた
スレッド: slapd は高速化のためにスレッドに対応しています。マルチスレッド化された単一の slapd プロセスが、スレッドのプールを用いてクライアントのすべての要求を処理します。これにより、多くのシステムのオーバヘッドを減らし、高速化を実現します。
複製: slapd は、そのデータベースの複製を管理するように設定できます。このシングルマスター/マルチスレーブの複製機構は、シングルの slapd では、要求される可用性と信頼性を提供できないような負荷の高い状況で必要になります。また slapd では、 マルチマスタ複製の試験的サポートも実装しています。
設定: slapd は高度に設定が可能です。設定は単一の設定ファイルをとおして行い、変更したいとこだけを変更できるようになっています。設定ディレクティブには妥当なデフォルト値を持っているので、設定作業が実に容易になっています。
もちろん slapd にも制限はあります。メインの BDB バックエンドは、範囲問合せや否定問合せをうまく処理できません。
1.7. slurpd とは何か、何ができるのか？
slurpd(8) は、slapd が提供する複製サービスを支援するデーモンです。slurpd の役割は、マスターの slapd データベースに起きた変更を他の複製の slapd に配送することです。slurpd では、変更を送るときに複製の slapd がダウンしていたり通信できない場合はどうするかといった心配もありません。なぜなら slurpd は失敗した要求の再トライを自動的に処理するからです。slapd と slurpd は変更を記録する単純なテキストファイルをとおして情報をやりとりします。
slurpd(8) を設定、実行する方法についての情報は slurpd を利用した複製の章を参照してください。