4.2. ディレクトリーツリーの設計
ディレクトリーツリー設計には、いくつかの主要な決定があります。
- データを含めるための接尾辞を選択する。
- データエントリー間での階層関係を決定する。
- ディレクトリーツリー階層のエントリーに名前を付ける。
4.2.1. 接尾辞の選択
接尾辞は、ディレクトリーツリーの root にあるエントリーの名前で、ディレクトリーデータはその下に保存されます。ディレクトリーには、複数の接尾辞を含めることができます。自然共通の root を持たない情報のディレクトリーツリーが 2 つ以上ある場合には、複数の接尾辞を使用できます。
デフォルトでは、標準の Directory Server のデプロイメントには複数の接尾辞が含まれています。1 つはデータの保管用で、残りは内部ディレクトリー操作に必要なデータ (例: 設定情報、ディレクトリースキーマなど) 用です。これらの標準ディレクトリー接尾辞の詳細は、『Red Hat Directory Server 管理ガイド』を参照してください。
4.2.1.1. 接尾辞の命名規則
ディレクトリーのすべてのエントリーは、共通のベースエントリー (root 接尾辞) 下に置く必要があります。root ディレクトリー接尾辞の名前を選択する際には、名前を効率的にするために以下の 4 つのポイントを検討してください。
- グローバルに一意であること
- 静的であること、したがって、ほとんど変更されないこと。
- ルートディレクトリーの下にあるエントリーが画面で読みやすいように、短いこと
- 入力と覚えておくのが簡単なこと
単一のエンタープライズ環境では、企業の DNS 名またはインターネットドメイン名に対応するディレクトリー接尾辞を選択します。たとえば、エンタープライズが example.com のドメイン名を所有する場合、ディレクトリーの接尾辞は論理的に dc=example,dc=com になります。
dc 属性は、ドメイン名をコンポーネント部分に分割することで接尾辞を表します。
通常、任意の属性を使用して root 接尾辞に名前を付けることができます。ただし、ホスト組織では、root 接尾辞を以下の属性に制限します。
dcドメイン名のコンポーネントを定義します。cISO で定義されている国名を表す 2 桁のコードが含まれます。lエントリーが配置されている、またはエントリーに関連付けられている国、都市、またはその他の地理的エリアを識別します。stエントリーが存在する州または地区を識別します。oエントリーが属する組織の名前を識別します。
これらの属性が存在すると、サブスクライバーアプリケーションとの相互運用が可能になります。たとえば、ホスト組織はこれらの属性を使用して、そのいずれかのクライアント example_a に root 接尾辞を作成します（例： o=example_a, st=Washington,c=US ）。
組織名の後に国の指定を続けて使用することは、接尾辞の X.500 命名規則の典型です。
4.2.1.2. 複数接尾辞の命名
ディレクトリーと一緒に使用される各接尾辞は、一意のディレクトリーツリーです。ディレクトリーサービスに複数のツリーを含む方法は複数あります。1 つ目は、Directory Server が提供する個別のデータベースに保存される複数のディレクトリーツリーを作成することです。
たとえば、example_a と example_b の個別の接尾辞を作成し、それらを別のデータベースに保存します。
図4.1 データベースへの複数のディレクトリーツリーの追加
データベースは、リソースの制約に応じて、1 台のサーバーまたは複数のサーバーに格納できます。
4.2.2. ディレクトリーツリー構造の作成
フラットなツリー構造または階層ツリー構造を使用するかどうかを決定します。一般的なルールとして、ディレクトリーツリーを可能な限りフラットとして作成してみてください。ただし、情報を複数のデータベース間でパーティション化する場合、レプリケーションを準備する場合、またはアクセス制御を設定する場合に、ある程度の階層化が重要になります。
ツリーの構造では、以下の手順および考慮事項が必要です。
4.2.2.1. ディレクトリーの分岐
問題のある名前の変更を避けるように、階層を設計します。名前空間がフラットであるほど、名前を変更する可能性は低くなります。名前変更の可能性は、変更する可能性のある名前のコンポーネントの数に概ね比例します。ディレクトリーツリーが階層的であるほど、名前のコンポーネントが多くなり、名前が変更される可能性が高くなります。
ディレクトリーツリー階層を設計するためのガイドラインを以下に示します。
- 企業内の最大下部組織を表すツリーだけを分岐します。このような分岐点は、法務サービス、カスタマーサポート、セールス、エンジニアリングなどの部門に制限する必要があります。ディレクトリーツリーの分岐に使用される部門を一定にいます。企業が頻繁に再編成する場合は、このような分岐は実行しないでください。
- 分岐点には、実際の組織名ではなく、機能または汎用名を使用します。名前の変更サブツリーの名前を変更できますが、多くの子エントリーを持つ大きな接尾辞では、長くリソースを必要とするプロセスになります。組織の機能を表す汎用名（例： Widget Research and Developmentの代わりに Engineering を使用）を使用すると、組織またはプロジェクトの変更後にサブツリーの名前を変更する必要がはるかに低くなります。
- 同様の機能を実行する組織が複数になる場合は、部門をベースに分岐するのではなく、その機能に対して分岐点を 1 つ作成してみてください。たとえば、特定の製品ラインを担当するマーケティング組織が複数存在する場合でも、ou=Marketing サブツリーを 1 つ作成します。すべてのマーケティングエントリーはそのツリーに属します。
エンタープライズ環境における分岐
ディレクトリーツリー構造が変更されない情報に基づいている場合、名前の変更は回避できます。たとえば、組織ではなくツリー内のオブジェクトのタイプを構造のベースとします。これは、組織ユニット間でエントリーをシャッフルするのを回避するのに役立ちます。シャッフルする場合、コストのかかる操作である識別名 (DN) の変更が必要になります。
構造の定義するのに使用すると良い、便利な共通のオブジェクトがあります。
- ou=people
- ou=groups
- ou=services
このオブジェクトを使用して整理されたディレクトリーツリーは、以下のように表示されます。
図4.2 環境ディレクトリーツリーの例
ホスト環境でのブランチング
ホスト環境の場合は、ルート接尾辞の下に、オブジェクトクラス organization oの 2 つのエントリーとオブジェクトクラスの 1 つのエントリーを含むツリーを作成します。organizationalUnit ouたとえば、Example ISP は、ディレクトリーを以下のように分岐します。
図4.3 ホストディレクトリーツリーの例
4.2.2.2. 分岐点の特定
ディレクトリーツリー内のブランチをプランニングする際に、分岐点の特定に使用する属性を決定します。DN は属性/データのペアで設定される一意の文字列です。たとえば、Example Corp. の従業員である Barbara Jensen のエントリーの DN は uid=bjensen,ou=people,dc=example,dc=com です。
各属性とデータのペアは、エンタープライズ Example Corp のディレクトリーツリーの 図4.4「Example Corp のディレクトリーツリー」 に示すように、ディレクトリーツリー内のブランチポイントを表します。
図4.4 Example Corp のディレクトリーツリー
図4.5「Example ISP のディレクトリーツリー」 インターネットホストの Example ISP のディレクトリーツリーを表示します。
図4.5 Example ISP のディレクトリーツリー
接尾辞エントリー c=US,o=example の下には、ツリーは 3 つのブランチに分割されます。ISP ブランチには、Example ISP の顧客データおよび内部情報が含まれます。インターネットブランチは、ドメインツリーです。groups ブランチには、管理グループに関する情報が含まれます。
分岐点の属性を選択する場合は、以下を考慮してください。
- 一貫性を持たせる必要があります。ディレクトリーツリー全体で識別名 (DN) 形式に一貫性がない場合、一部の LDAP クライアントアプリケーションは混同する可能性があります。つまり、ディレクトリーツリーの 1 つで
lがouに従属する場合、ディレクトリーサービスの他の部分でlがouに従属するようにします。 - 従来の属性 (「分岐点の特定」に示す) のみの使用を試みます。従来の属性を使用すると、サードパーティーの LDAP クライアントアプリケーションとの互換性を維持する可能性が高まります。従来の属性を使用すれば、デフォルトのディレクトリースキーマに認識されるため、ブランチ DN のエントリーの構築が容易になります。
表4.1 従来の DN 分岐点属性
| 属性 | 定義 |
|---|---|
dc | dc=example などのドメイン名の要素。これは、dc=example,dc=com や dc= mtv, dc=example,dc=com など、ドメインに応じてペアまたはそれ以上で指定されます。 |
c | 国名。 |
o | 組織名。この属性は、通常、「接尾辞の命名規則」のように、企業の部門、学問 (人間、サイエンス)、子会社、または企業内のその他の主要なブランチなど、大規模な部門の分岐を表すために使用されます。 |
ou | 組織単位。この属性は、通常、組織よりも小さな企業部門のブランチを表すために使用されます。通常、組織単位は前述の組織に従属します。 |
st | 州または地区名。 |
l または、以下を実行します。 locality | 都市、国、オフィス、またはファシリティー名などのローカリティー。 |
注記
一般的な間違いは、識別名で使用される属性に基づいてディレクトリーを検索することを仮定することです。識別名はディレクトリーエントリーの一意の識別子であり、検索キーとして使用できません。代わりに、エントリー自体に保存されている属性とデータのペアに基づいてエントリーを検索します。したがって、エントリーの識別名が uid=bjensen,ou=People,dc=example,dc=com の場合、dc=example の検索は、そのエントリーの属性として dc:example が明示的に追加されない限り、そのエントリーと一致しません。
4.2.2.3. レプリケーションに関する考慮事項
ディレクトリーツリーの設計プロセスで、どのエントリーがレプリケートされるかを考慮してください。レプリケートするエントリーセットを記述する自然な方法は、サブツリーの上部に DN を指定し、その下のすべてのエントリーを複製することです。このサブツリーはデータベース (ディレクトリーデータの一部が含まれるディレクトリーパーティション) にも対応しています。
たとえば、エンタープライズ環境では、1 つの方法は、企業のネットワーク名に対応するようにディレクトリーツリーを整理することです。ネットワーク名は変更されないため、ディレクトリーツリー構造は安定します。さらに、ネットワーク名を使用してディレクトリーツリーのトップレベルブランチを作成するのは、レプリケーションを使用して異なる Directory Server を連携させる場合に役立ちます。
たとえば、Example Corp. には flightdeck.example.com、tickets.example.com、および hangar.example.com として知られる 3 つの主要ネットワークがあります。主要な組織部門用に、当初はディレクトリーツリーを 3 つのメイングループに分岐します。
図4.6 Example Corp. のディレクトリーツリーの初期分岐
ツリーの初期構造を作成した後、各組織グループの詳細を表示する追加のブランチを作成します。
図4.7 Example Corp. の拡張ブランチ
Example ISP は、組織をミラーリングする非対称ツリーのディレクトリーを分岐します。
図4.8 Example ISP のディレクトリーの分岐
ディレクトリーツリーの初期構造を作成したら、論理サブグループ用に追加のブランチが作成されます。
図4.9 Example ISP の拡張ブランチ
エンタープライズとホスト組織の両方が、頻繁に変更されない情報に基づいて、データ階層をデザインします。
4.2.2.4. アクセス制御に関する考慮事項
ディレクトリーツリーに階層を導入すると、特定タイプのアクセス制御が可能になります。レプリケーションと同様に、類似したエントリーをグループ化して、1 つのブランチから管理するのが簡単になります。
階層ディレクトリーツリーを通じて、管理の分配を有効にすることもできます。たとえば、マーケティング部門の管理者にマーケティングエントリーへのアクセス権を付与し、営業部門の管理者に営業のエントリーへのアクセス権を付与するには、これらの部門に従ってディレクトリーツリーを設計します。
アクセス制御は、ディレクトリーツリーではなくディレクトリーコンテンツに基づいている可能性があります。フィルターされたメカニズムは、ディレクトリーエントリーが特定の属性値を含むすべてのエントリーにアクセスできることを示す単一のアクセス制御ルールを定義できます。たとえば、営業管理者に属性値 ou=Sales を含むすべてのエントリーへのアクセス権を付与する ACI フィルターを設定します。
ただし、ACI フィルターは管理が困難な場合があります。ディレクトリーツリー階層組織分岐、ACI フィルター、またはこの組み合わせなど、ディレクトリーに最も適しているアクセス制御の方法を決定します。
4.2.3. エントリーの命名
ディレクトリーツリーの階層を設計したら、構造内のエントリーに名前を付ける時に使用する属性を決定します。通常、1 つ以上の属性値を選択して 相対識別名 (RDN) を形成することで、名前は作成されます。RDN は DN 内の単一のコンポーネントです。これは最初に表示されるコンポーネントであるため、そのコンポーネントに使用される属性は、エントリーに一意の名前を設定するため、命名属性 になります。使用する属性は、名前が付けられるエントリーのタイプによって異なります。
エントリー名は、以下のルールに従う必要があります。
- 命名用に選択される属性は、変更されてないけません。
- この名前は、ディレクトリー全体で一意でなければなりません。一意の名前により、DN は最大でも 1 つのディレクトリー内のエントリーを確認できるようになります。
エントリーの作成時に、エントリー内で RDN を定義します。エントリー内で最小限の RDN を定義することで、エントリーを簡単に見つけることができます。これは、検索は実際の DN に対しては実行されませんが、エントリー自体に保存されている属性値に対して実行されるためです。
属性名には意味があります。したがって、表現するエントリーのタイプとマッチする属性名を使用します。たとえば、組織を表すのに
l を使用しないでください。また、組織単位を表すのに c を使用しないでください。
4.2.3.1. 人物エントリーの命名
人物エントリーの名前、DN は一意である必要があります。従来、識別名は
commonName または cn 属性を使用して人物エントリーに名前を付けます。つまり、Babs Jensen という名前のユーザーのエントリーは、cn=Babs Jensen,dc=example,dc=com の識別名になります。
共通名を使用すると、エントリーと人物の関連付けが容易になりますが、同じ名前のユーザーを除外するほど十分に一意ではない可能性があります。これにより、直ぐに DN 名の競合 と呼ばれる、同じ識別名を持つ複数のエントリーが存在する問題が発生します。
cn=Babs Jensen+employeeNumber=23,dc=example,dc=com など、一意識別子を共通名に追加して、一般的な名前の競合を回避します。
ただし、これにより、大規模なディレクトリーでは共通名が不便になり、管理が困難になる可能性があります。
より良い方法は、
cn 以外の属性を持つ個人のエントリーを特定することです。以下の属性のいずれかを使用することを検討してください。
uiduid属性を使用して、個人の一意の値を指定します。可能性としては、ユーザーログイン ID または従業員番号が含まれます。ホスト環境のサブスクライバーは、uid属性で識別する必要があります。mailmail属性には、常に一意のユーザーのメールアドレスが含まれます。このオプションを使用すると、重複した属性値（例： mail=bjensen@example.com,dc=example,dc=com）を含む awkward DN が発生する可能性があるため、uid属性で使用する他の一意の値がない場合に限りこのオプションを使用します。たとえば、企業が一時的または契約社員に従業員番号やユーザー ID を割り当てない場合は、mail属性の代わりにuid属性を使用します。employeeNumberinetOrgPerson オブジェクトクラスの従業員の場合は、employeeNumberなどの勤務担当者が割り当てた属性値を使用することを検討してください。
人物エントリー RDN に使用される属性/データのペアに関係なく、それらが一意の永続的値であることを確認してください。人物エントリー RDN も読み取り可能でなければなりません。たとえば、uid=bjensen,dc=example,dc=com は、uid=b12r56A,dc=example,dc=com よりも推奨されます。これは、認識可能な DN が、識別名に基づいてディレクトリーエントリーを変更するなど、一部のディレクトリータスクを簡素化するためです。また、一部のディレクトリークライアントアプリケーションは、
uid および cn 属性に人間が判読できる名前が使用されることを想定しています。
ホストされる環境の人物エントリーに関する考慮事項
人物がサービスへのサブスクライバーである場合、エントリーはオブジェクトクラス inetUser になり、エントリーに uid 属性が含まれている必要があります。属性は、顧客サブツリー内で一意である必要があります。
人物がホスト組織の一部である場合は、nsManagedPerson オブジェクトクラスを持つ inetOrgPerson として表現します。
DIT への人物エントリーの配置
以下は、ディレクトリーツリーに人物エントリーを配置するためのガイドラインです。
- エンタープライズ内のユーザーは、組織のエントリー下のディレクトリーツリーに置く必要があります。
- ホスティング組織をお持ちのお客様は、ホストされた組織の ou=people ブランチの下になければなりません。
4.2.3.2. グループエントリーの命名
グループを表す 4 つの方法があります。
- 静的グループ は、明示的にメンバーを定義します。groupOfNames または groupOfUniqueNames オブジェクトクラスには、グループのメンバーに名前を付ける値が含まれます。静的グループは、ディレクトリー管理者のグループなど、メンバーの少ないグループに適しています。静的グループは、数千のメンバーを持つグループには適していません。uniqueMember は groupOfUniqueNames オブジェクトの必須の属性であるため、静的グループエントリーには uniqueMember 属性値が含まれている必要があります。このオブジェクトクラスは、グループエントリーの DN を形成するために使用できる
cn属性を必要とします。 - 動的グループ は、検索フィルターとサブツリーを含むグループを表すエントリーを使用します。フィルターにマッチするエントリーはグループのメンバーです。
- ロール は、静的グループおよび動的グループの概念を統一します。詳細は、「ディレクトリーエントリーのグループ化」を参照してください。
ホストされている組織を含むデプロイメントでは、groupOfUniqueNames オブジェクトクラスを使用して、ディレクトリー管理で使用されるグループのメンバーに名前を付ける値を含めることを検討してください。ホストされる組織では、ディレクトリー管理に使用されるグループエントリーを ou=Groups ブランチの下に配置することが推奨されます。
4.2.3.3. 組織エントリーの命名
他のエントリー名と同様に、組織エントリー名は一意である必要があります。他の属性値と共に組織の有効な名前を使用すると、名前が一意になるようにすることができます（例： o=example_a+st=Washington,o=ISP,c=US ）。
商標も使用できますが、一意である保証はありません。
ホスト環境では、
organization (o)属性を命名属性として使用します。
4.2.3.4. その他の種類のエントリーの命名
このディレクトリーには、地域、州、国、デバイス、サーバー、ネットワーク情報など、その他の種類のデータ等を表すエントリーが含まれます。
このようなエントリータイプでは、可能であれば RDN で
cn 属性を使用します。次に、グループエントリーに名前を付けるために、cn=administrators,dc=example,dc=com のように名前を付けます。
ただし、エントリーのオブジェクトクラスが
commonName 属性をサポートしない場合があります。代わりに、エントリーのオブジェクトクラスがサポートする属性を使用します。
エントリーの DN に使用される属性は、エントリーで実際に使用されている属性に対応する必要はありません。ただし、DN 属性とエントリーで使用される属性の間で相関がある場合、ディレクトリーツリーの管理が簡素化されます。
4.2.4. エントリーおよびサブツリーの名前変更
「エントリーの命名」では、Red Hat Directory Server でエントリーの命名が重要であることについて説明します。エントリー名は、ある意味ディレクトリーツリーの構造を定義します。各分岐点 (その下にエントリーがあるエントリー) は、階層に新しいリンクを作成します。
例4.1 エントリー DN のビルド
dc=example,dc=com => root suffix
ou=People,dc=example,dc=com => org unit
st=California,ou=People,dc=example,dc=com => state/province
l=Mountain View,st=California,ou=People,dc=example,dc=com => city
ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com => org unit
uid=jsmith,ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com => leaf entry
エントリーの命名属性 (DN の左端にある要素) が変更されると、これは modrdn 操作 になります。ディレクトリーツリー内のエントリーを移動するため、ある意味特別な変更操作です。リーフエントリー (子を持たないエントリー) の場合、modrdn 操作は横方向の移動です。エントリーは同じ親を持ち、名前が新しいだけです。
図4.10 リーフエントリーに対する modrdn 操作
サブツリーエントリーの場合、modrdn 操作はサブツリーエントリー自体の名前を変更するだけでなく、サブツリーの 下にある すべての子エントリーの DN コンポーネントも変更します。
図4.11 サブツリーエントリーに対する modrdn 操作
重要
サブツリーの modrdn 操作も、サブツリーエントリーの下にあるすべての子エントリーを移動し、名前を変更します。サブツリーが大きい場合、これは時間とリソースを必要とするプロセスになります。ディレクトリーツリー階層の命名構造を計画し、サブツリーの名前変更操作が頻繁に要求されないようにします。
サブツリーの名前を変更する同様のアクションは、エントリーをあるサブツリーから別のサブツリーに移動することです。これは modrdn 操作の拡張タイプで、同時にエントリーの名前を変更し（同じ名前の場合でも）、
newsuperior 属性を設定して、エントリーを別の親に移動します。
図4.12 新しい親エントリーに対する modrdn 操作
エントリーが
entryrdn.db インデックスに保存される方法が原因で、新しい上位操作とサブツリーの名前変更操作の両方が可能です。各エントリーは、独自のキー (自己リンク) で、続いてその親 (親リンク) と子を特定するサブキーで識別されます。これには、親と子をエントリーに対する属性として処理することでディレクトリーツリー階層を配置する形式があり、すべてのエントリーが完全な DN ではなく一意の ID とその RDN によって記述されます。
numeric_id:RDN => self link
ID: #; RDN: "rdn"; NRDN: normalized_rdn
P#:RDN => parent link
ID: #; RDN: "rdn"; NRDN: normalized_rdn
C#:RDN => child link
ID: #; RDN: "rdn"; NRDN: normalized_rdn
たとえば、ou=people サブツリーには、親の dc=example,dc=com と子の uid=jsmith があります。
4:ou=people ID: 4; RDN: "ou=People"; NRDN: "ou=people" P4:ou=people ID: 1; RDN: "dc=example,dc=com"; NRDN: "dc=example,dc=com" C4:ou=people ID: 10; RDN: "uid=jsmith"; NRDN: "uid=jsmith"
名前変更操作を実行する際に留意すべき事項があります。
- root 接尾辞の名前を変更することはできません。
- サブツリー名前変更操作によるレプリケーションへの影響は最小限に抑えられます。レプリカ合意は、データベースのサブツリーではなく、データベース全体に適用されます。したがって、サブツリーの名前変更操作ではレプリカ合意の再設定は必要ありません。サブツリーの名前変更操作後のすべての名前の変更は、通常どおり複製されます。
- サブツリーの名前を変更し、同期合意を再設定する必要がある 場合があります。同期合意は、接尾辞またはサブツリーレベルで設定されるため、サブツリーの名前を変更すると、同期が破損してしまう可能性があります。
- サブツリーの名前を変更するには、サブツリーに設定されたサブツリーレベルの ACI を手動で再設定し、サブツリーの子エントリーに設定されたエントリーレベルの ACI (エントリーレベルの ACI) を手動で再設定する 必要があります。
- 子を持つサブツリーの名前を変更できますが、子を持つサブツリーを削除できません。
ouからdcへの移行など、サブツリーのコンポーネントを変更しようとすると、スキーマ違反で失敗する可能性があります。たとえば、organizationalUnit オブジェクトクラスにはou属性が必要です。サブツリーの名前変更の一部としてその属性を削除すると、操作は失敗します。
