Sun Java System Communications Services 6 2005Q4 配備計画ガイド

LDAP ディレクトリ情報ツリーの要件

ディレクトリ情報ツリー (DIT) は、ドメイン、サブドメイン、ユーザー、およびグループを表すノードを使用して、ディレクトリエントリをツリー構造またはスキーマ に編成するための方法です。Sun Java Enterprise System では、1 ツリー構造を実装することにより、ディレクトリを構造化する方法の基本的な変更が行われています。

DIT 構造の変更

Messaging Server と Calendar Server は 1 ツリー構造を導入しており、この構造にはドメインコンポーネント (DC) ツリーがありません。すべてのドメイン情報が組織ツリーのドメインノードに保持されます。新しい 1 DIT 構造では、エイリアスはまったく異なる方法で処理されます。

図 3–2 の下半分では、1 ツリー LDAP 構造を示しています。

図 3–2 2 ツリー LDAP 構造と 1 ツリー構造との比較

この図では、Messaging Server 6.0 で導入された 1 ツリー LDAP 構造と以前の 2 ツリー構造とを比較します。

1 ツリー DIT 構造の利点

1 ツリー構造のスキーマ 2 ネイティブモードを使用する主な利点は次のとおりです。

次の図に示されているとおり、2 ツリー構造では一部のノードが組織ツリーのノードを直接指定しています (inetDomainBaseDN 属性を使用)。そのほかのノードは、組織ツリーノードを直接指定する代わりに、aliasedObjectName 属性を使用して別の DC ツリーノードを指定するエイリアスノードです。

図 3–3 aliasedDomainNameinetDomainBaseDN を持つ 2 ツリーエイリアス

この図は、aliasedObjectName が設定された 2 ツリー LDAP を示します。

この図では、DC ツリーの sesta.com は、aliasedObjectName を使用して DC ツリーの siroe.com を指定し、siroe.com は、inetDomainBaseDN を使用して組織ツリーの同様の名前が付けられたノードを指定します。

さらに、図 3–4 に示されるように、DC ツリーには、inetDomainBaseDN を使用して組織ツリー内の同じノードを直接指す 1 つまたは複数のノードが存在する可能性があります。この場合、「実際」のドメイン名 (メールが実際に配置され、メールがルーティングされるドメイン) を指定するために、DC ツリーノードのいずれかに「連結遮断」属性 inetCanonicalDomainName が必要になります。

図 3–4 inetCanonicalDomainName 属性を持つ 2 ツリーエイリアス

この図では、inetCanonicalDomainName を使用して同じ組織ツリーノードを指している 2 つの DC ツリーノードがある 2 ツリー LDAP を示しています。

それに対して、下図に示すように 1 ツリー構造は組織ツリーのみで構成されます。

図 3–5 associatedDomain を持つ 1 ツリーエイリアス

この図は、Sun ONE スキーマ, v.2 でエイリアスの処理を行う簡単な方法を示しています。

1 ツリー構造では、以前 DC ツリーにあったすべてのドメイン属性が組織ツリーのドメインノードに含まれます。各ドメインノードは、sunManagedOrganization オブジェクトクラスと、DNS ドメイン名を含む sunPreferredDomain 属性によって識別されます。また、ドメインノードは、このドメインを識別するエイリアス名をリスト表示する 1 つまたは複数の associatedDomain 属性を持つことができます。2 ツリー構造とは反対に、エイリアス名の重複ノードはありません。

1 ツリー DIT 構造は、組織固有のアクセス制御のためのデータを区分する方法として役立ちます。つまり、各組織は、ユーザーおよびグループエントリが配置される独立したサブツリーを DIT に持つことができます。このデータへのアクセスは、そのサブツリーの一部にあるユーザーに制限されます。これにより、ローカライズされたアプリケーションを安全に実行することができます。

さらに、Calendar Server または Messaging Server の新しい配備では、1 ツリー構造の方が、既存の単一の DIT LDAP アプリケーションに、より適切にマッピングされます。