ディレクトリ情報ツリー

ディレクトリ情報ツリー( DIT )は、ディレクトリ サービスエントリの識別名(DN)で構成される階層的なツリー構造で表されるデータです。

X.500プロトコルとLightweight Directory Access Protocol (LDAP)はどちらも、基本的なデータ構造としてディレクトリ情報ツリーを使用します。

通常、単一の組織の X.500 または LDAP 展開には、次の 2 つの部分で構成されるディレクトリ情報ツリーが含まれます。

• 組織名自体のトップレベルの名前構造
• 組織内のデータモデル構造の表現

ディレクトリ情報ツリーの最上位レベルは、多くの場合、政治的および地理的な区分を表します。

X.500 の当初の想定では、すべてのディレクトリ サーバーが相互接続されて、単一のグローバルな名前空間が形成されます。ツリーの最上位レベルのエントリは、ISO 3166の2 文字の国コードで識別される国に対応します。国のエントリの下位のエントリは、州または県、および国家組織に対応します。特定の国の命名システムは、その国の国家標準化団体または通信プロバイダーによって決定されます。

元のディレクトリ情報ツリー構造の制限は、特定の組織のエントリを検索するアプリケーションが、まずその組織が拠点を置く特定の国を参照し、次にその組織が拠点を置く地域を参照し、次に組織自体のエントリを見つけ、最後にその組織内で問題のエントリを検索することによって、ディレクトリ ツリーをナビゲートするという想定でした。個人の所在地や組織の詳細がすべてわかっていない場合に、より広範囲に個人を検索できるようにしたいという要望から、Common Indexing Protocolなどのディレクトリの展開と相互接続に関する実験が行われました。

現在、ほとんどの LDAP 展開、特にActive Directory展開は、単一のグローバル命名空間に相互接続されておらず、命名の基礎として国別コードを使用していません。代わりに、これらの展開は、RFC 2247 で説明されているように、最上位レベルでドメイン ネーム システムをミラーリングするディレクトリ構造に従います。たとえば、ドメイン名が「example.com」の組織のエントリには という識別名が付けられdc=example, dc=com、その組織のディレクトリ情報ツリー内のすべてのエントリには、その識別名サフィックスが含まれます。

DIT のディレクトリに表される組織の要素 (人、役割、デバイスなど) は、さまざまな手法でモデル化できます。決定要因には次のものがあります。

• ディレクトリを検索および更新するアプリケーションの要件
• 各エントリに一意の名前を付ける必要がある
• ディレクトリ構造の安定性に対する要望
• ディレクトリ内のエントリの識別名を人間が読めるようにしたいという要望
• 既存のデータベースや他のディレクトリからディレクトリにデータをインポートする容易さ

企業や団体内での初期の X.500 の導入では、組織の従業員を表すエントリが使用されることが多く、組織構造を反映した DIT 構造が使用され、組織単位エントリは組織の部署や課に対応していました。従業員エントリの相対識別名は、個々の従業員の共通名から作成されることがよくありました。初期の X.500/LDAP 導入の DN の例は、次のようになりますcn=Joe Bloggs,ou=Marketing,ou=Operations,o=Example Corporation,st=CA,c=US。このアプローチの欠点は、組織構造が変更された場合、または従業員が正式な名前を変更した場合に、ディレクトリ内のエントリの移動または名前変更が必要になることです。これにより、複雑さとオーバーヘッドの両方が増加し、このような移動を適切に処理するように設計されていないアプリケーションが混乱する可能性もあります。

現在、X.500 または LDAP の多くの大規模な導入では、エントリに単一のフラットな名前空間を使用し、ユーザー名や従業員番号など、組織で割り当てられた識別子である相対識別名に基づいて個人のエントリに名前を付けることを選択しています。現在、DN は に似ている場合がありますuid=00003,ou=People,dc=example,dc=com。この構造の利点は、従業員の名前が変わったり、別の部署に異動になったりしても、エントリを移動する必要がないことです。これらの変更は、属性の変更だけで実行でき、DN を一意の識別子として使用している可能性のあるアプリケーション (データベース内など) を変更する必要はありません。