|
| |
| Sun Java™ System Directory Server 5 2004Q2 配備計画ガイド | |
第 4 章
ディレクトリ情報ツリーディレクトリ情報ツリー (DIT) を使用することで、ディレクトリに格納されているデータを参照することができます。格納した情報のタイプ、企業の地理的な特性、ディレクトリで使用するアプリケーション、および使用するレプリケーションのタイプによって、ディレクトリツリーの設計方法が決まります。この章では、ディレクトリツリーの設計手順について概要を説明します。説明する内容は次のとおりです。
ディレクトリツリーの概要ディレクトリツリーを使用すると、クライアントアプリケーションからディレクトリデータに名前を付けたり、参照したりできるようになります。ディレクトリツリーは、ディレクトリデータの分散、レプリケート、アクセス制御の方法など、その他の設計判断と緊密に連携します。
適切に設計されたディレクトリツリーでは、次のことが可能になります。
ディレクトリツリーの構造は、階層型の LDAP モデルに従います。ディレクトリツリーでは、たとえば、グループ、ユーザー、あるいは場所ごとにデータを編成できます。また、ディレクトリツリーによって複数のサーバー間でどのようにデータを分散して配置するかが決まります。データはサフィックスレベルのみで分割できるため、複数のサーバー間でデータを分散するには、適切なディレクトリツリー構造が必要です。
ディレクトリツリー設計は、レプリケーション設定にも影響します。ディレクトリツリーの一部だけをレプリケートしたい場合は、ディレクトリツリーの設計時にこれを考慮する必要があります。分岐点にアクセス制御を適用する場合も、設計時にそれを考慮する必要があります。
管理上、ディレクトリツリーは、サフィックス、サブサフィックス、および連鎖サフィックスによって定義されています。サフィックスとは分岐またはサブツリーであり、サフィックスの内容全体が管理タスクの単位として扱われます。たとえば、サフィックス全体に対してインデックスが定義され、サフィックス全体を 1 回の操作で初期化でき、また、サフィックスはレプリケーションの単位となります。同じ方法でアクセスおよび管理したいデータは、同じサフィックスに格納する必要があります。サフィックスはディレクトリツリーのルートに配置することもでき、その場合はルートサフィックスと呼ばれることがあります。
次の図に、2 種類のルートサフィックスを配置したディレクトリを示します。それぞれ、個別の企業エンティティに対応しています。
図 4-1 単一 Directory Server 内の 2 種類のルートサフィックス
サフィックスは、他のサフィックスの分岐となることもできます。その場合はサブサフィックスと呼ばれます。親サフィックスを管理する場合、サブサフィックスの内容は操作対象に含まれません。つまり、サブサフィックスは、親から独立して管理されます。ただし、LDAP 操作の結果には、サフィックスに関する情報は含まれません。また、ディレクトリクライアントは、エントリがルートサフィックスの一部であるか、サブサフィックスの一部であるかを認識できません。
次の図に、大規模な企業エンティティに対して、単一のルートサフィックスと複数のサブサフィックスを配置したディレクトリを示します。
図 4-2 複数のサブサフィックスを持つ単一のルートサフィックス
サフィックスは、サーバー内の個々のデータベースに対応します。ただし、データベースおよびそのファイルは、サーバーが内部的に管理するようになったため、Directory Server 5.2 ではデータベース用語は使用されていません。
連鎖サフィックスは、仮想ディレクトリツリーを作成して、別のサーバー上にあるサフィックスを参照します。連鎖サフィックスを使用すると、Directory Server は、リモートサフィックスに対する操作でも、ローカルで実行したかのように結果を返します。サフィックスが連鎖されていて、データがリモートサーバーから取得されることは、クライアントは認識できないため、データの位置が透過的になります。サーバー上のルートサフィックスが、別のサーバーに連鎖されているサブサフィックスを持つ場合もあります。その場合、クライアントからは、単独のツリー構造が作られているように見えます。
カスケード型連鎖の場合、連鎖サフィックスはリモートサーバー上などの別の連鎖サフィックスを参照することがあります。各サーバーは操作を転送し、最終的にクライアントの要求を処理するサーバーへ結果を返します。
連鎖の一般的な情報については、第 5 章「分散、連鎖、およびリフェラル」を参照してください。
ディレクトリツリーの設計ディレクトリツリーの設計では、データを格納するサフィックスの選択、データエントリ間の階層関係の決定、ディレクトリツリー階層内のエントリのネーミングを行います。次に、設計の各段階について詳しく説明します。
サフィックスの選択
サフィックスは、ディレクトリツリーのルートにあるエントリの名前です。サフィックスの下にディレクトリデータが格納されます。一般的なルートポイントを持たないディレクトリツリーが複数ある場合、複数のサフィックスを使用することもできます。
デフォルトの Directory Server のインストールでは、データの格納用に 1 つのサフィックスが、設定情報やディレクトリのスキーマなど、ディレクトリの内部処理に必要なデータ用に複数のサフィックスが使用されます。デフォルトのディレクトリサフィックスについては、『Directory Server 管理ガイド』の第 3 章「ディレクトリツリーの作成」を参照してください。
サフィックスの命名規則
ディレクトリ内のすべてのエントリは、共通のベースエントリ (サフィックス) の下に格納する必要があります。それぞれのサフィックス名は、次のように指定する必要があります。
1 つの企業環境では、DNS 名またはインターネットドメイン名に合わせてサフィックスを選択します。たとえば、企業が Example.com のようなドメイン名を所有している場合、サフィックスは次のようになります。
dc=example,dc=com
dc (domainComponent) 属性は、ドメイン名をコンポーネントに分割してサフィックスを表します。
サフィックスの名前を付けるときには、任意の属性を使用できます。ただし、ホスト環境では、サフィックスに使用する属性は次のものに限定する必要があります。
これらの属性がサフィックスに含まれていると、顧客のアプリケーションとの相互運用性が高まります。たとえば、ホスティングサービス事業者がこれらの属性を使用して、クライアントの Example.com に、次のようなルートサフィックスを作成する場合を考えてみます。
o=Example.com,st=Washington,c=US
これらの属性については、表 4-1 を参照してください。
組織名のあとに国名コードを使用する指定方法は、X.500 のサフィックスの命名規則に従っています。
複数のサフィックスの使用
定義する各サフィックスは、それぞれ固有のディレクトリツリーを構成します。複数のディレクトリツリーを作成し、別々のデータベースに格納することができます。たとえば、図 4-3 に示すように Example.com と Example2.com 用に別々のサフィックスを作成し、それぞれを異なるデータベースに格納できます。
図 4-3 2 つの異なるデータベースに格納される 2 つのサフィックス
データベースは、リソースの制限に応じて 1 つのサーバーまたは複数のサーバーに格納できます。
ディレクトリツリー構造の作成
ディレクトリツリーの構造は、フラットの場合も階層型の場合もあります。一般には、ディレクトリツリーはできるだけフラットにします。ただし、複数のデータベース間にデータを分散したり、レプリケートできるようにしたり、アクセス制御を設定したりする場合は、ある程度階層化することも必要です。
ディレクトリツリー構造の設計に関しては、次の項目に記載しています。
ディレクトリの分岐点の作成
分岐点は、ディレクトリツリー内の新しい分割を定義する場所です。分岐点を決定するときは、問題が生じる可能性のある名前の変更は避けてください。名前を変更する確率は、名前が変更される可能性があるコンポーネントが、ネームスペース内に多く含まれているほど高くなります。ディレクトリツリーの階層が深いほどネームスペース内のコンポーネントは多くなり、名前を変更する確率が高くなります。
分岐点を定義する際には、次のガイドラインが役に立ちます。
次に、企業とホスト環境のディレクトリツリー構造の例を示します。
企業環境での分岐点の作成
変更される可能性の低い情報に基づいてディレクトリ構造を決定すれば、名前の変更を避けられます。たとえば、組織ではなくツリー内のオブジェクトのタイプに基づいて構造を定義します。次に、ツリー構造の定義に使用するオブジェクトの例を示します。
図 4-4 は、Example.com という企業を例として、これらのオブジェクトを使用したディレクトリツリーの構造を示しています。
図 4-4 5 つの分岐点を持つディレクトリ情報ツリーの例
よく使用されている従来型の分岐点属性だけを使用してください (表 4-1 を参照)。従来からある属性を使用すると、サードパーティの LDAP クライアントアプリケーションとの互換性が保たれる可能性が高くなります。また、従来からある属性は、デフォルトのディレクトリスキーマで認識可能なので、分岐 DN のエントリを作成しやすくなります。
表 4-1 従来からある DN 分岐点の属性
属性名
定義
c
国名
o
組織名。通常、この属性は、企業の部門、教育機関での学部 (人文学部、理学部など)、子会社、企業内の主要部門など、大きな部門を表すために使用する。また、「サフィックスの命名規則」で説明したように、ドメイン名を表す場合もこの属性を使用する必要がある
ou
組織の構成単位。通常この属性は、組織よりも小さな組織内の部門を表すために使用する。組織単位は、一般にすぐ上の組織に属する
st
州または県の名前
l
地域 (都市、地方、オフィス、施設名など)
dc
「サフィックスの命名規則」で説明されているドメインのコンポーネント
ホスト環境での分岐点の作成
ホスト環境では、organization(o) オブジェクトクラスの 2 つのエントリと organizationalUnit(ou) オブジェクトクラスの 1 つのエントリをルートサフィックスの下に含むツリーを作成します。インターネットホスト ExampleHost.com のディレクトリツリーを、例として図 4-5 に示します。
図 4-5 ISP ExampleHost.com のディレクトリ情報ツリー
分岐点属性の特定
ディレクトリツリーを設計するときは、分岐点の特定に使用する属性を決定する必要があります。DN は、属性とデータのペアで構成される一意の文字列です。たとえば、Example.com 社の社員 Barbara Jensen 用のエントリの DN は次のようになります。
cn=Barbara Jensen,ou=people,dc=example,dc=com
各属性とデータのペアは、ディレクトリツリーの分岐点を表します。Example.com 社のディレクトリツリーを、図 4-6 に示します。
図 4-6 Example.com 社のディレクトリ情報ツリー
ExampleHost.com のディレクトリツリーを、 図 4-7 に示します。
図 4-7 ExampleHost.com 社のインターネットホストディレクトリ情報ツリー
ルートサフィックスのエントリ o=ExampleHost.com,c=us の下で、ツリーは 3 つに分岐しています。ISP の分岐には、顧客データと ExampleHost.com の社内情報が含まれています。internet の分岐は、ドメインのツリーです。groups の分岐には、管理グループに関する情報が含まれています。
分岐点の属性を選択するときは、一貫性を持たせることが重要です。ディレクトリツリー全体で識別名 (DN) の形式が統一されていないと、一部の LDAP アプリケーションで混乱が生じる可能性があります。たとえば、ディレクトリツリーのある部分で l (localityName) が o (organizationName) の下位にある場合、ディレクトリのほかの部分でも l が o の下位にあることを確認する必要があります。
よくある間違いに、識別名で使用されている属性に基づいてディレクトリを検索してしまうことがあります。識別名はディレクトリエントリをほかと識別するだけのもので、これを検索対象にすることはできません。ただし、エントリ自体に格納された属性とデータのペアに基づいてエントリを検索することは可能です。
レプリケーションに関する検討事項
ディレクトリツリーを設計するときは、レプリケートするエントリについて検討してください。エントリセットをレプリケートする場合は、サブツリーの頂点で識別名 (DN) を指定し、その下にあるエントリをすべてレプリケートするのが自然な方法です。また、このサブツリーは、ディレクトリデータの一部を含むディレクトリパーティションである、データベースに対応します。
企業環境では自社内のネットワーク名に対応させてディレクトリツリーを編成できます。ネットワーク名が変更されることはほとんどないので、ディレクトリツリー構造は安定したものになります。また、レプリケーションを使用して別の Directory Server を連動させる場合は、ネットワーク名を使用してディレクトリツリーの最上位の分岐点を作成する方法が有効です。
たとえば、Example.com 社に flightdeck.Example.com、 tickets.Example.com、hanger.Example.com という 3 つのプライマリネットワークがあるとします。図 4-8 は、このディレクトリツリーの最初の分岐を示しています。
図 4-8 Example.com 社 DIT の 3 つの主要ネットワーク
ツリーの最初の構造を作成した後、ネットワークをさらに図 4-9 のように分岐させています。
図 4-9 Example.com 社 DIT の 3 つの主要ネットワークの詳細
図 4-10 は、インターネットホスティング会社である ExampleHost.com のディレクトリ分岐の例を示しています。
図 4-10 ExampleHost.com のディレクトリ情報ツリー
ディレクトリツリーの最初の構造を作成した後、ネットワークをさらに図 4-11 のように分岐させています。
図 4-11 ExampleHost.com 社の詳細な DIT
どちらの企業も、あまり変更されることのない情報に基づいてデータ階層を設計しています。
アクセス制御に関する検討事項
ディレクトリツリーを階層化すると、特定のタイプのアクセス制御を使用できるようになります。レプリケーションの場合と同様に、類似したエントリをグループ化すると、それらのエントリを 1 つの分岐点から簡単に管理できます。
また、ディレクトリツリー階層で管理を分散させることもできます。たとえば、営業部の管理者に営業のエントリへのアクセス権を与え、マーケティング部の管理者にマーケティングのエントリへのアクセス権を与える場合は、ディレクトリツリーの設計を通じてアクセス権を付与することができます。
ディレクトリツリーではなくディレクトリの内容に基づいてアクセス制御を設定することもできます。ACI フィルタを適用するターゲットメカニズムを使用すると、ディレクトリエントリが特定の属性値を含むすべてのエントリへのアクセスを持つように規定した、1 つのアクセス制御規則を定義できます。たとえば、ou=Sales という属性を含むすべてのエントリへのアクセス権を営業部の管理者に与える ACI フィルタを設定できます。
ただし、ACI フィルタは管理が簡単ではありません。ディレクトリツリー階層で組織に対応した分岐を作成する、ACI フィルタを適用する、あるいは両者を組み合わせるなどして、ディレクトリにもっとも適したアクセス制御方法を決める必要があります。ACI をより簡単に管理するため、Directory Server 5.2 では、エントリの実効権限を取得できるようにします。これは、ディレクトリのエントリと属性に対するユーザーのアクセス制御権です。実効権限機能により、ユーザー管理、アクセス制御ポリシーの検証、およびデバッグが簡単になります。詳細は、「実効権限に関する情報の取得」を参照してください。
識別名、属性、および構文
ここでは、識別名、属性、および構文の情報を簡単に説明します。
識別名
識別名 (DN) は、LDAP ディレクトリにあるエントリの名前と場所を表す文字列です。DN はディレクトリのエントリへのパスを記述します。社内の各ユーザーとグループは、Directory Server では DN で表されています。ディレクトリにあるユーザーとグループの情報を変更するときは、常に識別名を使用します。
DN は、相対識別名 (RDN) と呼ばれる多数のコンポーネントで構成されます。それぞれの RDN は、ディレクトリ内の特定のエントリを識別します。各ディレクトリエントリを確実に一意なものにするには、LDAP により、１ つの親エントリはその下に 2 つの同じ RDN を持つことはできないと指示します。
通常、ユーザーまたはグループの DN には、少なくとも 3 つのタイプの RDN が含まれています。
その他の一般的な RDN は、組織の構成単位 (ou)、州 (st)、国 (c) などです。
DN の構成は、ディレクトリの構造によって異なります。ほとんどのディレクトリは、国名コードと組織名以外のほかのカテゴリも使用して構成されています。このため、エントリの識別に使われる DN は長くなり、より多くの特定の属性とデータのペアが格納されます。たとえば、同じ会社にいる 3 人の従業員またはユーザーの DN は、次のようになります。
cn=Ben Hurst, ou=Operations, o=Example Corp, st=CA, c=US
cn=Jeff Lee, ou=Marketing, o=Example Corp, st=CA, c=US
cn=Mary Smith, ou=Sales, o=Example Corp, st=MN, c=US
この例では、3 人のユーザーすべてが別々の部門または組織の構成単位 (ou) で、同じ会社または組織 (o) である Example Corp に勤務しています。3 番目のユーザーは、最初の 2 人のユーザーとは別の州 (st) で勤務しています。
LDAP により、組織と組織の構成単位がその他の組織や組織の構成単位を格納でき、複雑な企業を表すことができます。たとえば、大きな会社の中のグループの DN は次のようになります。
cn=Technical Publications, ou=Super Server Group, ou=Server Division, o=Example Corporation, o=MegaCorp, dc=megacorp, dc=com
表 4-2 に、一般的な RDN キーワードのリストを示します。
属性
ディレクトリ属性は、エントリに関する記述的な情報を保持します。たとえば、ユーザーエントリは、ユーザー ID、電子メールアドレス、指定された名前、およびパスワードの属性を保持することがあります。
表 4-3 に、一般的なユーザーおよびグループのディレクトリ属性のリストを示します。
ユーザーエントリには、上記のリストのほかにも多数の属性を含めることができます。また、自社のニーズに合うように新しい属性を作成することもできます。属性については、第 3 章「Directory Serverスキーマ」を参照してください。
DN および属性のガイドラインと構文
ディレクトリのエントリを作成、選択、および使用するときは、次のガイドラインに従ってください。
RDN 値ではコンマをエスケープするか、引用符で囲む
RDN 値にコンマが含まれる場合は、コンマを使用する名前の一部を二重引用符で囲むか、円記号を付けてエスケープします。たとえば、DN に文字列 Ace Industry, Corp を含めるには、次の形式を使用します。
o="Ace Industry, Corp", c=US
次の形式でも、同じ結果になります。
o=Ace Industry¥, Corp, c=US
スキーマ検査が有効になっている場合は、属性がディレクトリスキーマと一致する必要がある
スキーマ検査が有効になっている場合は、Directory Server で認識でき、エントリのオブジェクトクラスに許可されている RDN キーワードと属性を使用します。スキーマ検査が無効になっている場合は、エントリのオブジェクトクラスとは無関係に、すべての属性を使用できます。スキーマ検査については、「スキーマ検査」を参照してください。
RDN を同じシーケンスまたはパスに指定する
DN は、ディレクトリツリーからのパスを表します。RDN キーワードが適切な順序で指定されていないと、Directory Server でエントリを検出できない場合があります。次に例を示します。
cn=Ralph Swenson, ou=Accounting, o=Example Corp, c=US
これは、次のものとは異なります。
cn=Ralph Swenson, o=Example Corp, ou=Accounting, c=US
これは、組織の構成単位 (ou) と組織 (o) のキーワードが、同じ順序で指定されていないためです。
ユーザー ID は一意にする必要がある
ldapmodify コマンドを使用してユーザーを作成するときは十分に注意してください。ディレクトリで属性の一意性プラグインがユーザー ID 属性に対して有効になっていない限り、このユーティリティは重複したユーザー ID をチェックしないためです。詳細は、『Directory Server 管理ガイド』の第 15 章「属性値の一意性の適用」を参照してください。
エントリのネーミング
ディレクトリツリー構造を設計したあとは、ツリー構造内のエントリに名前を付けるときに使用する属性を決定する必要があります。一般に、名前は 1 つ以上の属性値を選び、相対識別名 (RDN) を形成して作成します。名前を付けるエントリのタイプによって使用する属性が変わります。
エントリの名前は、次の規則に従って付ける必要があります。
エントリを作成するときは、エントリ内で RDN を定義します。エントリ内で少なくとも RDN を定義しておけば、簡単にエントリを検出できます。これは、検索が実際の DN を対象にして実行されるのではなく、エントリ自体に格納されている属性値を対象に実行されるからです。
属性名には意味があるので、属性が表すエントリのタイプに合った属性名を使用するようにします。たとえば、組織を表すためにl (locality) を使用したり、組織の構成単位を表すために c (country) を使用したりしないでください。
エントリに名前を付けるときの手法について、次の項目ごとに説明します。
人のエントリのネーミング
人のエントリの名前 (DN) は一意である必要があります。従来、識別名ではその人のエントリに名前を付けるときに、commonName または cn 属性を使用しています。つまり、Babs Jensen という名前のユーザーのエントリには、次のような識別名が付けられます。
cn=Babs Jensen,dc=example,dc=com
このネーミング方法でエントリと関連付けられているユーザーを識別するのは簡単ですが、そのエントリは同じ名前のユーザーが組織に 2 人いる場合は一意にならない場合があります。この場合、DN の名前の衝突として知られている、複数のエントリが同じ識別名を持つ問題が生じます。
共通名の衝突は、一意の識別子を共通名に追加することで避けられます。たとえば、次のようにします。
cn=Babs Jensen+employeeNumber=23,dc=example,dc=com
ただし、このネーミング方法では、管理が難しくなり、大きなディレクトリの場合は扱いにくい共通名となります。
より良い方法は、cn 以外の属性で人のエントリを特定することです。次のいずれかの属性を使用することを検討してください。
人のエントリの RDN の属性とデータのペアにどのような属性値を使用する場合でも、一意で永続的な値を使用する必要があります。
ユーザーがサービスの加入者の場合、そのエントリは inetUser オブジェクトクラスにし、uid 属性を含める必要があります。属性は顧客のサブツリーで一意である必要があります。ユーザーがホスティングサービス事業者に属している場合は、nsManagedPerson オブジェクトクラスの inetOrgPerson として表します。
ディレクトリツリーに人のエントリを配置するときは、次の点を考慮してください。
組織エントリのネーミング
組織エントリ名は、ほかのエントリと同様に一意である必要があります。ほかの属性値と組織の法的な名前を組み合わせて使用すると、名前は確実に一意になります。たとえば、次のように組織エントリに名前を付けます。
o=Example.com+st=Washington,o=ISP,c=US
登録商標を使用することもできますが、一意である保証はありません。
ホスト環境では、組織エントリに次の属性を組み込みます。
その他のエントリのネーミング
地域、州、国、デバイス、サーバー、ネットワーク情報、その他のタイプのデータなど、ディレクトリには多くのものを表すエントリが含まれています。
これらのタイプのエントリには、可能な場合は RDN 内で commonName (cn) 属性を使用してください。たとえば、グループエントリに名前を付ける場合は、次のように名前を付けます。
cn=allAdministrators,dc=example,dc=com
commonName 属性がサポートされていないオブジェクトクラスを持つエントリに名前を付けなければならないこともあります。この場合は、エントリのオブジェクトクラスでサポートされている属性を使用します。
エントリの DN で使用される属性とエントリ内で実際に使用されている属性が対応している必要はありません。ただし、指定する属性を DN で見えるようにすると、ディレクトリツリーを簡単に管理できます。
ディレクトリエントリのグループ化と属性の管理ディレクトリツリーは、エントリの情報を階層構造で構成します。階層もグループ化メカニズムの 1 つですが、分散しているエントリの関連付け、頻繁に変更される組織、または多数のエントリで繰り返されるデータには適していません。Directory Server は、追加のグループ化メカニズムとしてグループとロールの 2 つを提供しています。こちらのほうがエントリ間の関係を柔軟に定義できます。
これらのグループ化メカニズムのほかに、Directory Server ではサービスクラス (CoS) というメカニズムを利用できます。これは、アプリケーションの介入なしでエントリ間で属性を共有できるように、属性を管理するメカニズムです。ロールメカニズムと同様に、エントリが検出されると、CoS がそのエントリに対して仮想属性を生成します。ただし、CoS はメンバーを定義するのではなく、一貫性の保持と容量の節約のために、関連するエントリがデータを共有できるようにします。
次に、エントリのグループ化と属性管理のメカニズム、およびそれぞれの利点と制限について説明します。
スタティックグループとダイナミックグループ
グループとは、そのメンバーであるほかのエントリを特定するエントリです。グループに含めることが可能なメンバーの範囲は、グループ定義エントリの位置に関係なく、ディレクトリ全体となります。グループ名がわかっている場合は、そのすべてのメンバーエントリを簡単に検索できます。次に、スタティックグループとダイナミックグループの特徴と、それぞれのグループをいつ使用するべきかを説明します。
- スタティックグループは、そのメンバーエントリの名前を明示的に指定します。スタティックグループを定義するエントリは、groupOfNames または groupOfUniqueNames オブジェクトクラスを使用し、各メンバーの DN をそれぞれ member または uniqueMember の属性値として含みます。member 属性には、サーバーがグループのメンバーシップを確立するときにチェックする DN が含まれます。uniqueMember 属性には、オプションとしてハッシュ (#) と一意の識別子のラベルが続く DN が含まれます。メンバーシップのチェックは、この DN に対して行われます。
- スタティックグループは、ディレクトリ管理者のグループのようにメンバーの少ないグループに適しており、非常に大きいグループには適していません。パフォーマンスが著しく低下するため、メンバー数が 20,000 を超えるスタティックグループを作成することは避けてください。これ以上のサイズのグループには、ダイナミックグループまたはロールを使用してください。20,000 を超えるメンバーに対してスタティックグループを使用する必要がある場合は、1 つの大きなスタティックグループを使用するのではなく、グループのグループ化を使います。
- ダイナミックグループはフィルタを指定し、そのフィルタと一致するすべてのエントリがグループのメンバーとなります。このようなグループは、フィルタが評価されるたびにメンバーが定義されるため、ダイナミックグループと呼ばれます。ダイナミックグループの定義エントリは、groupOfUniqueNames および groupOfURLs オブジェクトクラスに属します。グループメンバーシップは、memberURL 属性の LDAP URL 値として表される 1 つまたは複数のフィルタ、または uniqueMember 属性の値として表される 1 つまたは複数の DN としてリストされます。
どちらのグループも、ディレクトリ内のどこにいるメンバーでも識別できますが、グループ定義は、ou=Groups などの適切な名前のノードに格納する必要があります。たとえば、このように格納することで、バインドの証明情報がグループのメンバーである場合に、アクセスを許可または制限するアクセス制御命令 (ACI) を定義するときに、検索が簡単になります。
管理されているロール、フィルタを適用したロール、入れ子のロール
ロールはエントリのグループ化メカニズムです。エントリがディレクトリから取得されるとすぐに、ロールのメンバーシップを決定できます。これにより、グループ化メカニズムの主な欠点が解消されます。各ロールはメンバー (そのロールを所有するエントリ) を持ちます。ロールに属しているすべてのエントリに nsRole 仮想属性が指定されます。この属性の値は、そのエントリがメンバーになっているすべてのロールの DN です。グループと同じようにロールのメンバーを明示的またはダイナミックに指定できます。
ディレクトリがロールのメンバーを自動的に算出するため、ロールメカニズムはクライアントから簡単に使用できます。nsRole は、実行中にサーバーによって生成され、実際にはディレクトリに格納されないため、仮想属性と呼ばれています。つまり、ロールを使って処理を実行すると、グループを使う場合よりもサーバー側でより多くのリソースが消費されます。これは、クライアントアプリケーションのためにサーバーがその処理を実行するためです。ただし、ロールのメンバーの検査方法は一貫しており、サーバー側で透過的に実行されます。
Directory Server は、次の 3 種類のロールをサポートしています。
- 管理されているロール : 明示的にメンバーエントリにロールを割り当てる
- フィルタを適用したロール : 指定した LDAP フィルタと一致するエントリを割り当てる。このため、ロールは各エントリに含まれている属性によって異なる
- 入れ子のロール : ほかのロールを含むロールを作成できる
管理されているロール
管理されているロールは、メンバーがロール定義エントリではなく各メンバーエントリ内で定義されていることを除いて、スタティックグループと似ています。管理されているロールを使用すると、管理者は、対象となるエントリに nsRoleDN 属性を追加することにより、ロールを割り当てることができます。この属性の値は、ロール定義エントリの DN です。スタティックロールの定義エントリは、対象の範囲だけを定義します。そのロールのメンバーは指定範囲内で、nsRoleDN 属性がロール定義エントリの DN を指定しているエントリです。
フィルタを適用したロール
フィルタを適用したロールはダイナミックグループと似ており、ロールのメンバーを決定するフィルタを定義します。nsRoleFilter 属性の値は、フィルタを適用したロールを定義します。サーバーが、フィルタ文字列と一致する、フィルタを適用したロールの適用範囲内のエントリを返す場合、そのエントリにはロールを識別する nsRole 属性が常に含まれています。
入れ子のロール
入れ子のロールを使用して、別のロールを含むロールを作成できます。入れ子のロールはほかのロールの定義エントリをリストし、それらのロールのすべてのメンバーを組み合わせます。あるエントリが、入れ子のロールのリストに含まれているロールのメンバーである場合、そのエントリは入れ子のロールのメンバーでもあることになります。
ロールの列挙とロールメンバーシップの列挙
ロールの列挙
nsRole 属性はほかの属性と同様に読み取られます。クライアントはこの属性を使用して、任意のエントリが属しているすべてのロールを列挙することができます。ロールメカニズムで使用されるのは、nsRole 属性だけで、この属性はすべての変更操作から保護されています。ただし、読み取りは可能なので、ロールメンバーシップを公開したくない場合は、アクセス制御を定義して読み取りから保護する必要があります。
ロールメンバーシップの列挙
仮想属性に対する検索が可能なため、nsRole 属性を検索し、ロールのメンバーを列挙することができます。ただし、検索操作でインデックスが付けられていない属性は、パフォーマンスに大きな影響を与える可能性があるため注意が必要です。
等価フィルタに基づく検索の多くにはインデックスが付けられるため効率的ですが、否定検索にはインデックスが付けられず、パフォーマンスの低下を招くことになります。nsRoleDN 属性にはデフォルトでインデックスが付けられるので、管理されているロールに対する検索は比較的効率的です。フィルタを適用したロールと入れ子のロールでは、インデックスが付けられた属性と付けられていない属性の両方がフィルタに含まれている可能性があるため、インデックスが付けられていない検索を行わないように、少なくとも 1 つのインデックス付き属性がフィルタに含まれていることを確認する必要があります。
ロールの範囲
Directory Server では、ロールの範囲をロール定義エントリのサブツリーを超えて拡張するための属性を使用できます。これは、nsRoleScopeDN という 1 つの値からなる属性で、既存のロールに追加する範囲の DN を含みます。nsRoleScopeDN 属性を追加できるのは、入れ子のロールだけです。
nsRoleScopeDN 属性により、あるサブツリーのロールの範囲を拡張して、別のサブツリーにエントリを含めることができます。たとえば、Example.com のディレクトリツリーに、o=eng,dc=example,dc=com (エンジニアリングサブツリー) と o=sales,dc=example,dc=com (販売サブツリー) という 2 つのサブツリーがあると仮定します。エンジニアリングサブツリーのユーザーには、販売サブツリーのロールで管理される販売アプリケーション (SalesAppManagedRole) に対するアクセス権が必要です。ロールの範囲を拡張するには、次のようにします。
- エンジニアリングサブツリーに、たとえば EngineerManagedRole のようにユーザーのロールを作成します。この例では、管理されているロールを使用していますが、フィルタを適用したロールでも、入れ子のロールでもかまいません。
- 販売サブツリーに、たとえば SalesAppPlusEngNestedRole のような入れ子のロールを作成し、新たに作成した EngineerManagedRole と、当初からの SalesAppManagedRole を格納します。
- SalesAppPlusEngNestedRole に nsRoleScopeDN 属性を追加します。属性値には、追加するエンジニアリングサブツリーの範囲の DN を指定します。この例では、o=eng,dc=example,dc=com を指定します。
エンジニアリングユーザーには、SalesAppPlusEngNestedRole ロールにアクセスして販売アプリケーションにアクセスできるよう、適切なアクセス権を与える必要があります。さらに、ロールの範囲全体をレプリケートする必要があります。
注
範囲の拡張は入れ子のロールに限定されているため、これまで 1 つのドメインのロールを管理していた管理者は、その他のドメインにすでに存在するロールを使用する権限だけを持つことになり、その他のドメインで任意のロールを作成することはできなくなります。
ロールの制限事項
ディレクトリサービスをサポートするロールを作成する場合は、次の制限事項を考慮する必要があります。
連鎖機能を使用してディレクトリツリーを複数のサーバーに分散している場合は、ロールを定義するエントリをそれらのロールを所有するエントリと同じサーバーに配置する必要があります。連鎖を介して、サーバー A が別のサーバー B からエントリを受け取る場合は、それらのエントリにはサーバー B で定義されたロールが含まれますが、サーバー A で定義されたロールは割り当てられません。
フィルタを適用したロールでは、CoS 仮想属性の値に基づくフィルタ文字列を使用できません。詳細は、「CoS について」を参照してください。ただし、CoS 定義の指示子属性は、ロール定義によって生成された nsRole 属性を参照できます。ロールベースの属性の作成については、『Directory Server 管理ガイド』の「ロールに基づく属性の作成」を参照してください。
ロールの範囲は異なるサブツリーに拡張できますが、それらは同一サーバーインスタンス上になければなりません。ロールの範囲を別のサーバーにまで拡張することはサポートされていません。
グループとロールのどちらを使用するかの決定
グループとロールのメカニズムは一部の機能が重複していますが、どちらにも利点と欠点があります。一般に、より新しく設計されたロールメカニズムのほうが、頻繁に必要となる機能を効率的に提供できるように設計されています。グループ化メカニズムは、サーバーの複雑さに影響を及ぼし、クライアントによるメンバー情報の処理方法を決めるため、グループ化メカニズムは慎重に計画する必要があります。どのメカニズムが適しているかを判断するには、実行するメンバーシップクエリと管理操作を理解する必要があります。
グループメカニズムの利点
- メンバーシップが 20,000 以下の場合にメンバーを列挙するには、スタティックグループが適している
特定セットのメンバーを列挙するだけであれば、スタティックグループを使用するほうが負担が少なくなります。ただし、メンバー数が 20,000 以下であることが前提となります。20,000 を超えるメンバーを含むスタティックグループはパフォーマンスを低下させます。member 属性を取得してスタティックグループのメンバーを列挙することは、同じロールを共有するすべてのエントリを調べるより簡単です。
- メンバーの割り当てと削除などの管理操作には、スタティックグループが適している
グループにユーザーを追加する上で特別なアクセス権が必要ないため、スタティックグループはユーザーの割り当てや削除を行う場合の最適なグループ化メカニズムです。
グループエントリを作成する権限を持つということは、グループにメンバーを割り当てる権限を持つということになります。これに対して、管理されているロールとフィルタが適用されたロールでは、管理者はユーザーエントリに nsroledn 属性を書き込む権限も持つ必要があります。このアクセス権の制限は、入れ子のロールにも間接的に適用されます。これは、入れ子のロールを作成するということは、すでに定義されているその他のロールをまとめる権限が必要であることを意味するためです。
- フィルタベースの ACI で使用するには、ダイナミックグループが適している
ACI でのバインドルールの指定など、フィルタに基づいてすべてのメンバーを検索するだけの場合は、ダイナミックグループを使用します。フィルタを適用したロールはダイナミックグループと似ていますが、ロールメカニズムを探して確認し、nsRole 仮想属性を生成します。クライアントが nsRole 値を必要としない場合は、ダイナミックグループを選択することで、この計算のオーバーヘッドを回避できます。
- 既存のセットに対してセットの追加や削除を行うときは、グループが適している
既存のセットに対してセットの追加や削除を行う場合は、入れ子の制限がないため、グループメカニズムがもっとも適しています。ロールメカニズムでは、他のロールを受け入れられるのは入れ子のロールに限られています。
- エントリのグループ化範囲の柔軟性が重要になる場合は、グループが適している
グループのメンバー範囲は、グループ定義エントリの場所に関係なくディレクトリ全体であるため、範囲の面ではグループには柔軟性があります。ロールでも、特定のサブツリーを超えて範囲を拡張することができますが、入れ子のロールに範囲拡張属性 nsRoleScopeDN を追加する必要があるため、範囲拡張には制限があります。
ロールメカニズムの利点
- セットのメンバーを列挙し、エントリのすべてのメンバーを検索する場合は、ロールが適している
ロールはメンバーシップ情報をユーザーエントリにプッシュします。そこでは情報をキャッシュできるので、以後のメンバーシップのテストをより効率的に行えます。サーバーがすべての計算を実行し、クライアントは nsRole 属性の値を読み取るだけです。さらに、この属性にすべてのタイプのロールが含まれ、クライアントはすべてのロールを均等に処理できます。グループよりもロールの方が、両方の処理をより効率よく実行でき、クライアント側での処理が簡単になります。
- CoS、パスワードポリシー、アカウントの無効化、ACI など、Directory Server の既存のグループ化メカニズムを統合する場合は、ロールが適している
サーバー上のセットのメンバーシップを「自然に」使用する、つまり、メンバーシップに関する計算をサーバーが自動的に行う利点を活用する場合、ロールメカニズムが最適です。ロールは、リソース指向の ACI で、CoS のベースとして、より複雑な検索フィルタ、パスワードポリシー、アカウントの無効化などの一部として使用することができます。グループを使用してこのような統合を行うことはできません。
サービスクラス (CoS) による属性の管理
CoS メカニズムを使用すると、アプリケーションによる介入なしでエントリ間で属性を共有することができます。CoS は、ロールメカニズムと同じように、エントリの取得時にエントリの仮想属性を生成します。CoS は、メンバーシップを定義しません。ロールメカニズムのようにエントリをグループ化するのではなく、一貫性の保持と容量の節約のために、関連するエントリがデータを共有できるようにします。ここでは、CoS メカニズムについて詳しく説明します。説明する内容は次のとおりです。
CoS について
facsimileTelephoneNumber 属性の値が等しい何千ものエントリがディレクトリに格納されているとします。従来のやり方で FAX 番号を変更するには、各エントリを個別に更新する必要があり、管理者にとっては時間のかかる作業でした。CoS を使用すると、FAX 番号は 1 か所に保存され、Directory Server は、エントリが返されるときに、関係のあるすべてのエントリに対して facsimileTelephoneNumber 属性を自動的に生成します。
クライアントアプリケーションでは、生成された CoS 属性はほかの属性と同じように検出されます。ただし、ディレクトリ管理者が管理するのは 1 つの FAX 番号値だけです。また、ディレクトリに格納される値が少ないため、データベースが使用するデータ領域が少なくて済みます。CoS メカニズムを使用すると、生成された値をエントリで上書きすることも、同じ属性に対して複数の値を生成することも可能です。
生成される CoS 属性には、複数の値が設定されている場合があります。指示子が複数のテンプレートエントリを指定する場合もあれば、同じ属性に複数の CoS 定義がある場合もあります。また、すべてのテンプレートから 1 つの値だけが生成されるように、テンプレートの優先順位を指定することもできます。詳細は、『Directory Server 管理ガイド』の「サービスクラス (CoS) の定義」を参照してください。ロールとクラシック CoS を組み合わせて使用すると、ロールに基づく属性を指定できます。エントリは関連付けられた CoS テンプレートを持つ特定のロールを所有しているため、これらの属性がエントリ上に現れます。たとえば、ロールに基づいた属性を使用して、ロール単位で検索制限を設定できます。
CoS の機能は再帰的に使用できます。つまり、Cos で生成されたほかの属性によって指定される CoS から属性を生成できます。CoS スキーマを複雑にすると、クライアントから情報へのアクセスが単純化され、繰り返し使用する属性を簡単に管理できるようになりますが、同時に管理が複雑になり、サーバーのパフォーマンスが低下します。極端に複雑な CoS スキーマは避けてください。たとえば、多くの間接 CoS スキーマは、クラシック CoS またはポインタ CoS として再定義することができます。
また、CoS 定義を必要以上に変更しないでください。サーバーは CoS 情報をキャッシュに保存するため、CoS 定義への変更がすぐには反映されません。キャッシュを利用することで、生成された属性に高速にアクセスできるようになりますが、CoS 情報が変更されると、サーバーはキャッシュを再構築しなくてはなりません。これは、多少時間のかかるタスク (通常は数秒) です。キャッシュの再構築中は、読み取り操作は新たに変更された情報ではなく、古いキャッシュに残されされている情報に対して行われます。このため、CoS 定義を頻繁に変更した場合、古くなったデータにアクセスする可能性が高くなります。
CoS 定義エントリと CoS テンプレートエントリ
CoS メカニズムは、CoS 定義エントリと CoS テンプレートエントリという 2 種類のエントリに依存します。
CoS 定義エントリ
CoS 定義エントリは、CoS のタイプおよび生成される CoS 属性の名前を特定します。このエントリは、ロール定義エントリと同様に、LDAPsubentry オブジェクトクラスから継承されます。CoS の範囲は、定義エントリの格納場所によって決定されます。この範囲は、CoS 定義エントリの親の下にあるサブツリー全体となります。定義エントリの親の分岐内のすべてのエントリを CoS 定義のターゲットエントリと呼びます。同じ CoS 属性に複数の定義が存在することもあります。この場合は、複数の値が含まれます。
CoS 定義エントリは、cosSuperDefinition オブジェクトクラスのインスタンスです。CoS 定義エントリは、CoS のタイプを指定する、次のオブジェクトクラスのいずれかから継承されます。
CoS 定義エントリには、仮想 CoS 属性、テンプレート DN、およびターゲットエントリの指示子属性を指定できるように、CoS のそれぞれのタイプに固有の属性が含まれています。デフォルトでは、CoS メカニズムは、CoS 属性と同じ名前を持つ既存の属性の値を上書きしません。ただし、CoS 定義エントリの構文を使用することで、この動作を制御できます。
注
スキーマ検査が有効になっている場合は、その Cos 属性を設定できるすべてのターゲットエントリにこの属性が生成されます。スキーマ検査が無効になっている場合は、すべてのターゲットエントリに CoS 属性が生成されます。
CoS テンプレートエントリ
CoS テンプレートエントリには、CoS 属性に生成される値が含まれます。CoS の適用範囲内のすべてのエントリで、ここに定義された値が使用されます。それぞれが異なる値を持つ複数のテンプレートが存在することもあります。この場合、生成される属性は複数の値を持ちます。CoS メカニズムは、定義エントリとターゲットエントリの内容に基づいていずれかの値を選択します。
CoS テンプレートエントリは、cosTemplate オブジェクトクラスのインスタンスです。CoS テンプレートエントリには、CoS メカニズムによって生成された 1 つ以上の値が含まれます。特定の CoS 用のテンプレートエントリは、その CoS 定義と同じレベルのディレクトリツリー内に格納されます。
注
管理を容易にするため、定義エントリとテンプレートエントリはできるだけ同じ場所に格納してください。また、それらが提供する機能を説明するような名前を付けてください。たとえば、定義エントリ DN に "cn=classicCosGenEmployeeType,ou=People,dc=example,dc=com" などの名前を付けると、"cn=ClassicCos1,ou=People,dc=example,dc=com" よりもわかりやすくなります。CoS の各タイプに関連するオブジェクトクラスと属性については、『Directory Server 管理ガイド』の「サービスクラス (CoS) の定義」を参照してください。
CoS の優先順位
属性値を得る上で互いに競合する CoS スキームが作成される場合があります。たとえば、CoS 定義エントリに複数の値を持つ cosSpecifier があると仮定します。このような場合、どのテンプレートが属性値を提供するかを決定するために、各テンプレートエントリにテンプレート優先順位を指定することができます。テンプレート優先順位の設定には、cosPriority 属性を使用します。この属性は、特定のテンプレートのグローバルな優先順位を数字で表します。優先順位 0 は、優先順位がもっとも高いことを示します。
cosPriority 属性を持たないテンプレートは、優先順位がもっとも低いとみなされます。2 つ以上のテンプレートが属性値を提供する状況で、その優先順位が同じまたは設定されていない場合は、任意の値が選択されます。
ポインタ CoS、間接 CoS、クラシック CoS
テンプレートの選択方法が異なり、それによって生成される値が異なる 3 つのタイプの CoS があります。次に、これらの 3 種類の CoS について詳しく説明します。
ポインタ CoS
ポインタ CoS はもっとも単純です。ポインタ CoS 定義エントリによって、cosTemplate オブジェクトクラスの特定のテンプレートエントリの DN が決定されます。すべてのターゲットエントリに、このテンプレートで定義されているものと同じ CoS 属性値が設定されます。
ポインタ CoS の例
図 4-12 に、dc=example,dc=com の下に格納されるすべてのエントリに共通の郵便番号を定義する CoS を示します。ここでは、Cos 定義エントリ、Cos テンプレートエントリ、およびターゲットエントリを示しています。
図 4-12 ポインタ CoS の定義とテンプレートの例
テンプレートエントリは、CoS 定義エントリ内の DN (cn=exampleUS,cn=data) によって特定されます。エントリ dc=example,dc=com で postalCode 属性が照会されるたびに、Directory Server は、テンプレートエントリ cn=exampleUS,cn=data 内の使用可能な値を返します。したがって、郵便コードは、エントリ uid=wholiday,ou=people,dc=example,dc=com と一緒に表示されますが、このエントリには格納されません。
エントリ内に実際に存在する属性の代わりに、CoS によって生成されるいくつかの属性が数千または数百万のエントリで共有される例を考えると、CoS を利用することで節約できる格納のための容量とパフォーマンスの向上を理解することができます。
間接 CoS
間接 CoS を使用すると、ディレクトリ内の任意のエントリをテンプレートにして、CoS 値を指定することができます。間接 CoS 定義エントリは、間接指示子と呼ばれる属性を識別します。ターゲットエントリに含まれるこの属性の値によって、そのエントリで使用されるテンプレートが決定されます。ターゲットエントリ内の間接指示子属性には、DN が含まれています。間接 CoS を使用することで、各ターゲットエントリで異なるテンプレートを使用できるため、CoS 属性に異なる値を指定することができます。
たとえば、departmentNumber 属性を生成する間接 CoS では、指示子として社員の上司を使用できます。ターゲットエントリを検索する場合、CoS メカニズムはテンプレートとして manager 属性の DN 値を使用します。そして、上司の部門番号と同じ値を使用して、社員の departmentNumber 属性を生成します。
間接 CoS の例
図 4-13 では、ターゲットエントリの manager 属性を使用してテンプレートエントリを特定しています。CoS メカニズムでは、この方法で、すべての従業員に対して上司と同じ departmentNumber 属性を生成することにより、常に最新の状態を維持できます。
図 4-13 間接 CoS の定義とテンプレートの例
間接 CoS の定義エントリは、指示子属性の名前を指定します。この例では、manager 属性です。William Holiday のエントリは、この CoS のターゲット エントリの 1 つであり、その manager 属性には、uid=cfuentes,ou=people,dc=example,dc=com の DN が含まれます。したがって、Carla Fuentes のエントリは、departmentNumber 属性値 318842 を提供するテンプレートです。
クラシック CoS
クラシック Coｓ は、ポインタ CoS と間接 Coｓ の動作を組み合わせたものです。クラシック CoS の定義エントリは、テンプレートのベース DN と指示子属性を特定します。次のように、ターゲットエントリの指示子属性の値は、テンプレートエントリの DN の構築に使用されます。
CoS 値を含むテンプレートは、ターゲットエントリの指示子属性の RDN (相対識別名) 値とテンプレートのベース DN を組み合わせることで決定されます。
クラシック CoS テンプレートは、任意の間接 CoS テンプレートに関連するパフォーマンスの問題を回避するための、cosTemplate オブジェクトクラスのエントリです。
クラシック CoS の例
クラシック CoS メカニズムでは、定義エントリで指定されたベース DN とターゲットエントリの指示子属性からテンプレートの DN が決定されます。指示子属性の値は、テンプレート DN の cn 値として使用されます。したがって、クラシック CoS のテンプレート DN は、次のような構造になります。
図 4-14 は、郵便番号属性の値を生成するクラシック CoS の定義を示しています。
図 4-14 クラシック CoS の定義とテンプレートの例
この例では、CoS 定義エントリの cosSpecifier 属性が、employeeType 属性を指定します。この属性とテンプレート DN を組み合わせると、テンプレートエントリを cn=sales,cn=exampleUS,cn=data として識別できます。このテンプレートエントリは、postalCode 属性の値をターゲットエントリに与えます。
CoS の制限事項
CoS 機能は、複雑なメカニズムであり、パフォーマンスおよびセキュリティ上の理由から次の制限事項が適用されます。
CoS 属性の値では、エントリの実際の値とテンプレートの仮想値を組み合わせることはできません。CoS により実際の属性値が上書きされると、実際の値はすべてテンプレートの値に置き換えられます。ただし、CoS メカニズムでは、複数の CoS 定義エントリから仮想値を組み合わせることができます。詳細は、『Directory Server 管理ガイド』の「CoS の制限事項」を参照してください。
フィルタを適用したロールでは、CoS 仮想属性の値に基づくフィルタ文字列を使用できません。ただし、CoS 定義の指示子属性は、ロール定義によって生成された nsRole 属性を参照できます。詳細は、『Directory Server 管理ガイド』の「ロールに基づく属性の作成」を参照してください。
格納されている通常の属性へのアクセスと同様に、CoS によって生成された属性へのアクセスが制御されます。ただし、CoS によって生成された属性値に依存するアクセス制御規則は、「属性タイプの制限」で説明されている条件に従います。
CoS キャッシュは、パフォーマンスを向上させるためにすべての CoS データをメモリに保持する Directory Server の内部構造です。このキャッシュは、仮想属性の算出時に使用される CoS データの取得用に最適化されており、CoS 定義エントリおよびテンプレートエントリの更新中でも使用できます。したがって、定義エントリおよびテンプレートエントリを追加または変更すると、変更内容が反映されるまでわずかに時間がかかる場合があります。この遅延時間は、CoS 定義の数と複雑さ、および現在のサーバーの負荷によって異なりますが、通常は、数秒間かかります。複雑な CoS 設定を行うときは、この遅延時間を考慮してください。
その他のディレクトリツリー関連資料ディレクトリツリーの設計についての関連資料は、次のリンクにあります。
- RFC 2247: Using Domains in LDAP/X.500 Distinguished Names (LDAP/X.500 識別名でドメインを使用する方法)
http://www.ietf.org/rfc/rfc2247.txt- RFC 2253: LDAPv3, UTF-8 String Representation of Distinguished Names (LDAPv3、識別名をUTF-8 文字列で表す方法)
http://www.ietf.org/rfc/rfc2253.txt
