名前付きコンテキストの作成

ディレクトリに格納する情報の種類を定義したら、情報をどのような名前付きコンテキストに分割するかを決める必要があります。分割する基準としては、次のものが考えられます。

• 地域。たとえば、会社の地域ごとに作成する。

• 会社の組織

• DNS メールドメイン

• ユーザーの種類

• サービスの種類 (NIS、RADIUS など)

• 上記の組み合わせ。たとえば、NIS サービスを使用すると、デフォルトでは、人に対して 1 つの名前付きコンテキストが作成され、サービスに対して別の名前付きコンテキストが作成されます。RADIUS サービスを使用する場合は、リモートユーザーに対して 1 つ、ネットワークアクセスサーバーに対し 1 つの名前付きコンテキストを持つことをお勧めします。さらに、会社の所在地ごとに 1 つの名前付きコンテキストを作成できます。

情報を名前付きコンテキストに分割する基準は、情報の場所とは無関係に定義できます。名前付きコンテキストのどの部分でもネットワークの任意のサーバーに複製できるからです。

ただし、リソースのマスターエントリはディレクトリに 1 つだけでなければなりません。複数あると、1 つの情報リポジトリを持つという大きな利点が失われます。

例: XYZ Corporation の名前付きコンテキスト

XYZ Corporation は、米国のボストンに本社がある国際的な薬品会社です。ボストンとロンドンに 1 箇所ずつ製造拠点があります。また、ニューヨークとパリに研究グループがあり、それぞれにはマーケティングと営業部門も置かれています。香港にも営業オフィスがあります。米国関係はボストン、ヨーロッパとその他の地域はロンドンでそれぞれ人事部門を管理しています。

図 3-1 は、XYZ Corporation の機能的な構造を示しています。

図 3-1 XYZ Corporation の機能構造

図 3-2 は、XYZ Corporation の地理的な構造を示しています。

図 3-2 XYZ Corporation の地理的な構造

XYZ Corporation の主要な機能がいろいろな場所にあるため、組織的なディレクトリ情報ツリー構造も機能的な ディレクトリ情報ツリー構造もこの会社のディレクトリ構造の要件を完全には満たしません。さらに、XYZ Corporation は、NIS ネーミングサービスを使って、メールユーザーとネットワークリソースに関する情報を集中的に管理しています。この情報は会社の運営にとって不可欠であるため、ネットワーク管理チームは、組織や地理的な区分とは無関係にこの情報を集中的に管理したいと思っています。しかし、重要性が比較的低く、頻繁に更新される可能性のある情報については、場所ごとに保守を行なってもよいと思っています。たとえば、ネットワークアクセスサーバーを経由してネットワークにリモートアクセスすることを許可されたユーザーの情報がこれにあたります。

その結果、ディレクトリ情報ツリー構造は図 3-3 のようになります。

図 3-3 XYZ Corporation のディレクトリ情報ツリー構造

この ディレクトリ情報ツリー構造では、会社は、10 の名前付きコンテキストに対応する 6 つの組織単位 (ou) と 4 つの場所 (l) に分割されています。表 3-1 に、各名前付きコンテキストの相対識別名と識別名を格納するサーバーを示します。表 3-2 には、他のサーバーに複製される名前付きコンテキストのマスターサーバーを示します。