ディレクトリに格納するデータの種類によって、ディレクトリの構造、データにアクセスできるユーザー、およびアクセス権限の付与方法が決定されます。特によく利用されるデータの種類には、ユーザー名、電子メールアドレス、電話番号、ユーザーが所属するグループについての情報などがあります。
この章では、データを検索、分類、構造化、および整理する方法について説明します。また、Directory Server のスキーマにデータをマップする方法についても説明します。この章の内容は次のとおりです。
既存のデータを分類する最初のステップでは、データがもともとどこに存在していたものか、またそのデータの所有者がだれであるかを特定します。
ディレクトリに含めるデータを特定するには、既存のデータソースの位置を特定して分析します。
情報を提供する組織を特定する。
企業にとって重要な情報を管理している組織をすべて特定します。通常、これらの組織には、情報サービス部、人事部、給与計算部、および経理部が含まれます。
情報のソースであるツールとプロセスを特定する。
情報の一般的なソースには、次のものがあります。
Windows、Novell Netware、UNIX® NIS などのネットワークオペレーティングシステム
電子メールシステム
セキュリティーシステム
PBX (構内交換機) または電話交換システム
人事アプリケーション
データの集中化が各データに与える影響を判定する。
集中データ管理では、新しいツールとプロセスが必要になることがあります。集中化によって、ある組織のスタッフを増員してほかの組織のスタッフを減らすことが必要になる場合は、問題が生じる可能性もあります。
「データ所有者」とは、データを最新の状態に維持する責任のある個人または組織のことです。データの設計時に、ディレクトリにデータを書き込めるユーザーを決めておきます。データの所有者を決めるには、一般に次の規則に従います。
ディレクトリの内容を管理する少人数のマネージャーグループを除くすべてのユーザーに対して、ディレクトリへの読み取り専用アクセスを許可する。
各ユーザーが自分自身に関する重要な情報を管理できるようにする。
このような情報には、ユーザーのパスワード、ユーザー自身についての説明的情報、組織内でのユーザーのロールなどがあります。
人に関する重要な情報 (連絡先情報や役職など) を上司が書き込めるようにする。
組織の管理者がその組織に関するエントリを作成および管理できるようにする。
これにより、実質的に組織の管理者が、ディレクトリ内容の管理者にもなります。
グループ内のユーザーに読み取りアクセス権または書き込みアクセス権を与えるロールを作成する。
たとえば、人事、財務、経理などのロールを作成します。これらのロールごとに、そのグループが必要とするデータへの読み取りアクセス権、書き込みアクセス権、またはその両方を許可します。このようなデータには、給与情報、政府指定の ID 番号、自宅の電話番号と住所などがあります。
ロールとエントリのグループ化の詳細は、「ディレクトリデータのグループ化と属性の管理」、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 10 章「Directory Server のグループ、ロール、および CoS」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 8 章「Directory Server Groups and Roles」を参照してください。
データに書き込みを許可するユーザーを決定するときに、複数のユーザーに対して同じデータへの書き込み権限が必要になることがあります。たとえば、情報システムまたはディレクトリ管理グループには、従業員のパスワードへの書き込み権限を許可するのが一般的です。同時に、すべての従業員にも自分自身のパスワードへの書き込み権限を許可する場合があります。複数のユーザーに同じ情報への書き込み権限を与えなければならない場合がありますが、このような場合はこのグループを少人数に保ち、容易に特定できるようにします。グループを少人数にすることは、データの完全性の保証に役立ちます。
ディレクトリのアクセス制御の設定については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 7 章「Directory Server のアクセス制御」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「How Directory Server Provides Access Control」を参照してください。
Directory Server やその他の Java Enterprise System サーバーを設定するために使用するデータと、ディレクトリに格納される実際のユーザーデータを区別するには、次の手順に従います。
ユーザーデータと設定データのそれぞれに対して、異なるバックアップ方針を用意します。
ユーザーデータと設定データのそれぞれに対して、異なる高可用性基準を用意します。
設定サーバーをすみやかにシャットダウンし、復元し、再起動します。
ほかの Directory Server インスタンスの保守を実行している間、設定サーバーの稼働を維持します。
データソースを特定するときは、従来のデータソースを含め、ほかのデータソースからのデータを必ず含めるようにしてください。このデータはディレクトリに格納されていない場合もあります。ただし、Directory Server がデータについて何らかの情報を持っている、またはデータを制御できることが必要な場合があります。
Directory Proxy Server には、複数のデータリポジトリからリアルタイムで情報を集約する「仮想ディレクトリ」機能が用意されています。このようなリポジトリには、LDAP ディレクトリ、JDBC 仕様に準拠するデータ、LDIF フラットファイルなどがあります。
仮想ディレクトリは、複数の異なるデータソースからの属性を処理する複合フィルタをサポートします。また、複数の異なるデータソースからの属性を結合する変更もサポートします。
データ分析フェーズの間、複数のアプリケーションが同じデータを異なる形式で必要とすることが判明する場合があります。このような情報 (データ) については、複製するのではなく、アプリケーションの側でそれぞれの要件に合わせて変換させるのが適切な方法です。
ディレクトリ情報ツリー (DIT) は、ディレクトリデータを構造化し、クライアントアプリケーションからデータを参照できるようにするための手段です。DIT は、ディレクトリデータの分散、レプリケート、アクセス制御の方法など、その他の設計判断と緊密に連携します。
適切に設計された DIT は、次のような利点をもたらします。
ディレクトリデータの管理を簡単にする
レプリケーションポリシーとアクセス制御の作成における柔軟性
ディレクトリを使用するアプリケーションをサポートする
ユーザーが簡単にディレクトリを操作できるようにする
DIT の構造は、階層型の LDAP モデルに従います。DIT では、たとえば、グループ、ユーザー、あるいは場所ごとにデータを編成できます。また、ディレクトリツリーによって複数のサーバー間でどのようにデータを分散して配置するかが決まります。
DIT の設計は、レプリケーション設定や、Directory Proxy Server を使用してデータを分散させる方法に影響を及ぼします。DIT の特定部分をレプリケートまたは分散する場合は、レプリケーションおよび Directory Proxy Server の要件について設計時点で検討します。また、分岐点にアクセス制御を適用する必要があるかどうかについても設計時に検討します。
DIT はサフィックス、サブサフィックス、および連鎖サフィックスによって定義されます。「サフィックス」とは分岐またはサブツリーであり、サフィックスの内容全体が管理タスクの単位として扱われます。インデックス生成はサフィックス全体に対して定義され、サフィックス全体を 1 回の操作で初期化できます。サフィックスは通常、レプリケーションの単位でもあります。同じ方法でアクセスおよび管理するデータは、同じサフィックスに格納する必要があります。サフィックスは、「ルートサフィックス」と呼ばれるディレクトリツリーのルートに配置することもできます。
データはサフィックスレベルのみで分割できるため、複数のサーバー間でデータを分散するには、適切なディレクトリツリー構造が必要です。
次の図は、2 つのルートサフィックスを持つディレクトリを示しています。各サフィックスは独立した企業エンティティーを表します。
サフィックスは、他のサフィックスの分岐となることもできます。その場合は「サブサフィックス」と呼ばれます。親サフィックスには、管理操作のためのサブサフィックスの内容は含まれません。サブサフィックスはその親とは別個に管理されます。LDAP 操作の結果にはサフィックスに関する情報は含まれないため、ディレクトリクライアントは、エントリがルートサフィックスの一部であるか、サブサフィックスの一部であるかを認識できません。
次の図に、大規模な企業エンティティーに対して、単一のルートサフィックスと複数のサブサフィックスを配置したディレクトリを示します。
サフィックスは、サーバー内の個々のデータベースに対応します。ただし、データベースとそのファイルはサーバーによって内部的に管理され、データベースの用語は使用されません。
連鎖サフィックスは、仮想 DIT を作成して、別のサーバー上にあるサフィックスを参照します。Directory Server は、連鎖サフィックスを使用してリモートサフィックスに対する操作を実行します。ディレクトリはその後、操作がローカルで実行された場合と同じように結果を返します。データの位置は透過的です。クライアントの側では、サフィックスが連鎖されている、またデータがリモートサーバーから取得されているという認識はありません。あるサーバー上のルートサフィックスが、別のサーバーに連鎖されているサブサフィックスを持つ場合があります。この場合、クライアントは単一のツリー構造を認識します。
カスケード型連鎖の場合、連鎖サフィックスはリモートサーバー上などの別の連鎖サフィックスを参照することがあります。各サーバーは操作を転送し、最終的にクライアントの要求を処理するサーバーへ結果を返します。
DIT の設計では、データを格納するサフィックスの選択、データエントリ間の階層関係の決定、DIT 階層内のエントリのネーミングを行います。次に、設計の各段階について詳しく説明します。
サフィックスは、DIT のルートにあるエントリの名前です。共通のルートを持たない DIT が 2 つ以上ある場合、複数のサフィックスを使用できます。デフォルトの Directory Server のインストールには、複数のサフィックスが含まれています。1 つのサフィックスはユーザーデータの格納に使用されます。その他のサフィックスは、設定情報やディレクトリのスキーマなど、内部的なディレクトリ操作に必要なデータの格納に使用されます。
ディレクトリ内のすべてのエントリは、共通のベースエントリ (サフィックス) の下に格納する必要があります。各サフィックス名は次のように指定する必要があります。
グローバルに一意の名前にする
変更しない、または名前をまれにしか変更しないようにする
そのサフィックスの下にあるエントリがオンラインで読みやすいように短い名前にする
ユーザーが容易に入力および記憶できるものにする
一般的には、企業のドメイン名を識別名 (DN) にマップすることがベストプラクティスと考えられています。たとえば、example.com というドメイン名を持つ企業は「dc=example,dc=com」という DN を使用します。
DIT の構造は、フラットまたは階層型から選択できます。フラットツリーのほうが管理が容易ですが、データのパーティション分割、レプリケーション管理、およびアクセス制御のために、ある程度の階層が必要な場合もあります。
「分岐点」とは、DIT の内部で新しいサブ区分を定義するポイントのことです。分岐点を決定するときは、問題が生じる可能性のある名前の変更は避けてください。名前を変更する確率は、名前が変更される可能性があるコンポーネントが、ネームスペース内に多く含まれているほど高くなります。DIT の階層が深いほどネームスペース内のコンポーネントは多くなり、名前を変更する確率が高くなります。
分岐点を定義および命名するときは、次のガイドラインを使用します。
企業組織内でもっとも大きい部門区分のみを表すようにツリーを分岐させます。
分岐点を部門 (企業情報サービス、カスタマサポート、販売、プロフェッショナルサービスなど) に限定します。部門が安定していることを確認します。企業で組織変更が頻繁に行われる場合は、この種の分岐を実行しないでください。
組織の実際の名前ではなく、機能を表す名前または一般的な名前を使用します。
組織名は変更される可能性があり、企業で部門の名前を変更するたびに DIT の変更が必要になるのは問題です。代わりに、組織の機能を表す一般的な名前を使用します。たとえば、「Widget 研究開発」ではなく「エンジニアリング」を使用します。
似たような機能を持つ組織が複数ある場合は、部門の構成に基づいて分岐点を作成するのではなく、その機能を表す分岐点を 1 つ作成します。
たとえば、特定の製品ラインを担当する複数のマーケティング部門がある場合でも、1 つのマーケティングサブツリーのみを作成します。すべてのマーケティングエントリは、そのツリーに所属させます。
次の表に示した、従来からある分岐点属性のみを使用するようにします。
従来からある属性を使用すると、サードパーティーの LDAP クライアントアプリケーションとの互換性が保たれる可能性が高くなります。加えて、従来からある属性はデフォルトのディレクトリスキーマにとって既知であるため、分岐識別名 (DN) のエントリの構築が簡略化されます。
ディレクトリに格納されるデータの種類に応じた分岐を行います。
たとえば、人、グループ、サービス、およびデバイスのそれぞれに対応する独立した分岐を作成します。
属性名 |
定義 |
---|---|
c |
国名。 |
o |
組織名。この属性は通常、大規模な部門の分岐を表すために使用します。そのような分岐の例には、企業の部門、教育機関の学部、子会社、企業内のその他の主要部門などがあります。また、ドメイン名を表す場合もこの属性を使用することをお勧めします。 |
ou |
組織の構成単位。通常この属性は、組織よりも小さな組織内の部門を表すために使用します。組織単位は、一般にすぐ上の組織に属します。 |
st |
州または県の名前。 |
l |
地域 (都市、地方、オフィス、施設名など)。 |
dc |
ドメインのコンポーネント。 |
分岐点の属性を選択するときは、整合性を保つようにしてください。DIT 全体で DN の形式が統一されていないと、一部の LDAP クライアントアプリケーションで問題が発生する可能性があります。DIT のある部分で l (localityName) が o (organizationName) の下位にある場合、必ず、ディレクトリのその他すべての部分でも l が o の下位にあるようにしてください。
DIT を設計するときは、どのエントリがほかのサーバーにレプリケートされるかを考慮します。エントリの特定グループを同じサーバー集合にレプリケートする場合、それらのエントリを特定のサブツリー下に配置することをお勧めします。レプリケートするエントリの集合を記述するには、サブツリーの頂点で DN を指定します。エントリのレプリケーションの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 4 章「Directory Server Replication」を参照してください。
DIT 階層では、特定のタイプのアクセス制御を有効にできます。レプリケーションの場合と同様に、類似したエントリをグループ化したり、エントリを 1 つの分岐から管理したりすることがさらに容易になります。
また、DIT 階層で管理を分散させることもできます。たとえば、DIT を使用して、マーケティング部門の管理者にはマーケティング関連エントリへのアクセス権を付与し、セールス部門の管理者にはセールス関連のエントリへのアクセス権を付与することができます。
DIT ではなくディレクトリの内容に基づいてアクセス制御を設定することもできます。ACI でフィルタされたターゲット機構を使用して、単一のアクセス制御規則を定義します。この規則では、1 つのディレクトリエントリが、特定の属性値を含むすべてのエントリにアクセスできることを記述します。たとえば、ou=Sales という属性を含むすべてのエントリへのアクセス権を営業部の管理者に与える ACI フィルタを設定できます。
ただし、ACI フィルタは管理が簡単ではありません。対象のディレクトリにもっとも適したアクセス制御方法を決定する必要があります。DIT 階層で組織に対応した分岐を作成する、ACI フィルタを適用する、あるいはこの両者を組み合わせる、などの方法から選択します。
ディレクトリ情報ツリーは、エントリを階層構造で構成します。この階層は、グループ化メカニズムの 1 種です。この階層は、分散しているエントリの関連付け、頻繁に変更される組織、または多数のエントリで繰り返されるデータには適していません。Directory Server のグループとロールは、エントリ間のより柔軟な関連付けを提供します。サービスクラス (CoS) のメカニズムを使用すると、属性がエントリ間で共有されるように各属性を管理できます。この共有は、アプリケーションには見えない方法で実行されます。
これらのエントリのグループ化と属性管理のメカニズムは、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 8 章「Directory Server Groups and Roles」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 9 章「Directory Server Class of Service」で詳細に説明されています。
ここでは、管理戦略の設計には十分なグループ化メカニズムの概要について説明します。ただし、このメカニズムの動作の仕組みや、それらの設定方法については説明していません。
この節は、次の項目で構成されています。
Directory Server は、スタティックグループ、ダイナミックグループ、および入れ子のグループを識別します。
グループが識別するメンバーはディレクトリ内のどこに配置してもかまいませんが、グループ定義自体は ou=Groups のように適切な名前が付けられたノードに配置するようにします。このようにすることで、バインド資格がグループのメンバーである場合にアクセス権を付与または制限するアクセス制御命令 (ACI) を定義するときなどに、グループ定義を簡単に見つけることができます。
スタティックグループは、メンバーエントリの名前を明示的に指定します。たとえば、次の図のように、ディレクトリ管理者のグループにはグループを構成する特定のユーザーの名前が指定されます。
次の LDIF の抜粋は、このスタティックグループのメンバーが定義される方法を示しています。
dn: cn=Directory Administrators, ou=Groups, dc=example,dc=com ... member: uid=kvaughan, ou=People, dc=example,dc=com member: uid=rdaugherty, ou=People, dc=example,dc=com member: uid=hmiller, ou=People, dc=example,dc=com
ダイナミックグループはフィルタを指定し、そのフィルタと一致するすべてのエントリがグループのメンバーとなります。このようなグループは、フィルタが評価されるたびにメンバーが定義されるため、ダイナミックグループと呼ばれます。
たとえば、すべての管理職とそのアシスタントがビルの 3 階におり、各社員の部屋番号がその階の数字で始まるとします。3 階にいる社員のみを含むグループを作成するのであれば、次の図のように、部屋番号を使用してそれらの社員だけを定義することができます。
次の LDIF の抜粋は、このダイナミックグループのメンバーが定義される方法を示しています。
dn: cn=3rd Floor, ou=Groups, dc=example,dc=com ... memberURL: ldap:///dc=example,dc=com??sub?(roomnumber=3*)
入れ子のグループでは、別のグループの DN をスタティックまたはダイナミックグループの uniqueMember 属性として使用して、他のグループの内部にグループを配置します。Directory Server では、個々のエントリ、スタティックグループ、およびダイナミックグループを参照する混合グループもサポートしています。
たとえば、すべてのディレクトリ管理者、およびすべての管理職とそのアシスタントを含むグループを作成するとします。この場合、先ほど定義した 2 つのグループの組み合わせを使用して、次の図のように 1 つの入れ子のグループを作成することができます。
次の LDIF の抜粋は、この入れ子のグループのメンバーが定義される方法を示しています。
dn: cn=Admins and 3rd Floor, ou=Groups, dc=example,dc=com ... member: cn=Directory Administrators, ou=Groups, dc=example,dc=com member: cn=3rd Floor, ou=Groups, dc=example,dc=com
入れ子のグループはグループ化の手法として必ずしも効率的ではありません。ダイナミックな入れ子のグループには、非常に大きなパフォーマンスコストが必要となります。このようなパフォーマンス上の問題を避けるために、グループではなくロールの使用を考慮してください。
ロールは、エントリのグループ化メカニズムです。ロールを使用すると、エントリがディレクトリから取得されるとすぐに、ロールのメンバーシップを決定できます。各ロールはメンバー (そのロールを所有するエントリ) を持ちます。グループと同じようにロールのメンバーを明示的またはダイナミックに指定できます。
Directory Server は、次の 3 種類のロールをサポートしています。
管理されているロール: 明示的にメンバーエントリにロールを割り当てる。
フィルタを適用したロール: エントリが指定された LDAP フィルタに一致した場合は、それらのエントリを自動的にメンバーにする。このため、ロールは各エントリに含まれている属性に依存する。
入れ子のロール: ほかのロールを含むロールを作成できる。
グループとロールのメカニズムは、一部の機能が重なっています。どちらのメカニズムにも利点と欠点があります。一般に、ロールメカニズムのほうが、頻繁に必要となる機能を効率的に提供できるように設計されています。グループ化メカニズムはサーバーの複雑さに影響を及ぼし、グループ化メカニズムを選択することで、クライアントがどのようにメンバー情報を処理するかが決まるため、グループ化メカニズムは慎重に計画する必要があります。どちらのメカニズムがより適しているかを判断するには、実行する標準的なメンバーシップクエリーと管理操作を理解してください。
グループには、次の利点があります。
スタティックグループは、標準に準拠した唯一のグループ化メカニズムである。そのため、スタティックグループは、ほとんどのクライアントアプリケーションおよび LDAP サーバーと相互運用できます。
メンバーを列挙するには、ロールよりスタティックグループの方が適している。
特定のセットのメンバーを列挙するだけでよい場合は、スタティックグループの方がコストが低くなります。member 属性を取得してスタティックグループのメンバーを列挙することは、同じロールを共有するすべてのエントリを調べるより簡単です。Directory Server では、多くの値を持つ複数値属性に対して大幅なパフォーマンス強化が実現されています。特にスタティックグループとの関連では、これらの属性に対する等価照合や変更操作が大幅に機能強化されています。また、グループエントリに対するメンバーシップのテストも機能強化されています。これらの機能強化によって、スタティックグループに対して以前あった制限の一部 (特にグループサイズに対する制限) が解消されています。
また、Directory Server では isMemberOf オペレーショナル属性をユーザーエントリに直接指定することで、そのユーザーがどのグループのメンバーであるかを明示できます。この機能はスタティックグループのみに適用されますが、入れ子のグループも含まれます。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「グループの管理」を参照してください。
メンバーの割り当てや削除などの管理操作には、ロールよりスタティックグループが適している。
スタティックグループは、ユーザーをセットに割り当てたり、ユーザーをセットから削除したりするためのもっとも単純なメカニズムです。ユーザーをグループに追加するために、特殊なアクセス権は必要ありません。
グループエントリを作成する権限があると、そのグループにメンバーを割り当てる権限が自動的に与えられます。これは、管理されているロールやフィルタを適用したロールには当てはまりません。これらのロールでは、管理者が、ユーザーエントリに nsroledn 属性を書き込むための権限も持っている必要があります。アクセス権に関する同じ制約が、入れ子のロールにも間接的に適用されます。入れ子のロールを作成するには、入れ子の対象となるすでに定義されているほかのロールに対する権限が必要となります。
フィルタベースの ACI で使用するには、ロールよりダイナミックグループが適している。
ACI でのバインドルールの指定など、フィルタに基づいてすべてのメンバーを検索するだけの場合は、ダイナミックグループを使用します。フィルタを適用したロールはダイナミックグループと似ていますが、ロールメカニズムを起動して nsRole 仮想属性を生成します。クライアントが nsRole 値を必要としない場合は、ダイナミックグループを使用してこの計算のオーバーヘッドを回避します。
既存のセットに対してセットの追加や削除を行うときは、ロールよりグループが適している。
あるセットを既存のセットに追加したり、あるセットを既存のセットから削除する場合は、グループメカニズムがもっとも単純です。グループメカニズムには、入れ子の制限がありません。ロールメカニズムでは、他のロールを受け入れられるのは入れ子のロールに限られています。
エントリのグループ化範囲の柔軟性が重要になる場合は、ロールよりグループが適している。
グループのメンバー範囲は、グループ定義エントリの場所に関係なくディレクトリ全体であるため、範囲の面ではグループには柔軟性があります。ロールでも、特定のサブツリーを超えて範囲を拡張することができますが、入れ子のロールに範囲拡張属性 nsRoleScopeDN を追加することでしか実現できません。
ロールには、次の利点があります。
セットのメンバーを列挙し、かつ特定のエントリがメンバーになっているすべてのセットを検索する場合は、ダイナミックグループよりロールの方が適している。スタティックグループでも、isMemberOf 属性によってこの機能を提供しています。
ロールはメンバーシップ情報をユーザーエントリにプッシュします。そこでこの情報をキャッシュできるので、以後のメンバーシップのテストをより効率的に行えます。サーバーがすべての計算を実行し、クライアントは nsRole 属性の値を読み取るだけです。さらに、この属性にすべてのタイプのロールが含まれ、クライアントはすべてのロールを均等に処理できます。ダイナミックグループよりもロールの方が、両方の処理をより効率よく実行でき、クライアント側での処理が簡単になります。
CoS、パスワードポリシー、アカウントの無効化、ACI など、Directory Server の既存の機能とグループ化メカニズムを統合する場合は、グループよりロールが適している。
セットのメンバーシップをサーバーで「自然に」使用する場合は、ロールの方が優れたオプションです。ロールを利用するということは、サーバーが自動的に実行するメンバーシップの計算方法を使用することを意味します。ロールは、リソース指向の ACI で、CoS のベースとして、より複雑な検索フィルタの一部として、さらにパスワードポリシーやアカウントの無効化などに使用することができます。グループを使用してこのような統合を行うことはできません。
ロールを使用する場合は、次の問題に注意してください。
nsRole 属性を割り当てることができるのはロールメカニズムだけです。この属性は、どのディレクトリユーザーも割り当てたり、変更したりできませんが、どのディレクトリユーザーも「読み取れる」可能性があります。この属性が、不正なユーザーから読み取られないようにするには、アクセス制御を定義してください。
nsRoleDN 属性は、管理されているロールのメンバーシップを定義します。ユーザーがロールに自分自身を追加したり削除したりできるかどうかを決定してください。自分のロールを変更できないようにするには、そのための ACI を定義してください。
フィルタを適用したロールは、ユーザーエントリ内の属性の存在または値に基づくフィルタを介してメンバーシップを決定します。フィルタを適用したロール内のメンバーシップを定義できるユーザーを制御するには、これらの属性のユーザーアクセス権を慎重に割り当ててください。
サービスクラス (CoS) メカニズムを使用すると、エントリ間で属性を共有できます。ロールメカニズムと同様に、エントリが検出されると、CoS がそのエントリに対して仮想属性を生成します。CoS はメンバーを定義しませんが、一貫性の保持と容量の節約のために、関連するエントリがデータを共有できるようにします。CoS の値は、それらの値が要求されたときに動的に計算されます。CoS 機能や、CoS のさまざまな種類については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference 』で詳細に説明されています。
以降の節では、パフォーマンスの低下を回避しながら、CoS 機能を意図したとおりに使用する方法について詳しく説明します。
CoS の生成は、常にパフォーマンスに影響します。実際に必要とするより多くの属性を検索するクライアントアプリケーションによって、この問題がさらに悪化する可能性があります。
クライアントアプリケーションの記述方法を指示できる場合は、実際に必要な属性値のみを検索するようにクライアントアプリケーションを記述することで、パフォーマンスの大幅な向上が期待できることを開発者に伝えてください。
CoS は、サブツリー内の多数のエントリに同じ属性値を表示する必要がある場合に、比較的低いコストで大きな利点を提供します。
たとえば、ou=People の下のすべてのユーザーエントリに companyName 属性が含まれている、MyCompany, Inc. のディレクトリを考えてみます。請負業者のエントリには companyName 属性に直接値がセットされていますが、すべての正社員の companyName には、CoS で生成された値 MyCompany, Inc. がセットされています。次の図は、この例でポインタ CoS を使用した場合を示しています。CoS によって、すべての正社員の companyName 値が生成されるが、請負業者の従業員用に直接設定されている実際の companyName 値は置き換えられないことに注意してください。会社名は、companyName が許可された属性になっているエントリに対してのみ生成されます。
多数のエントリが同じ値を共有する場合は、ポインタ CoS が特にうまく機能します。正社員に対する companyName の管理が容易になることで、属性値を生成するための追加の処理コストが相殺されます。深いディレクトリ情報ツリー (DIT) は、一般的な特性を共有するエントリをまとめる傾向があります。深い DIT でポインタ CoS を使用すると、ツリー内の適切な分岐に CoS 定義を配置することによって、一般的な属性値を生成できます。
CoS はまた、ディレクトリデータが自然な関係を持っている場合も、データ管理の大きな利点を提供します。
すべての従業員にマネージャーがいる企業ディレクトリを考えてみます。すべての従業員がメールストップと Fax 番号を、もっとも近い管理アシスタントと共有しています。図 4–4 は、間接 CoS を使用して、マネージャーのエントリから部門番号を取得する様子を示しています。図 4–5 では、メールストップと Fax 番号が管理アシスタントのエントリから取得されています。
この実装では、マネージャーのエントリに departmentNumber の実際の値が含まれ、生成されているどの値よりもこの実際の値が優先されます。Directory Server は、CoS で生成された属性値からは属性値を生成しません。そのため、図 4–4 の例では、部門番号の属性値をマネージャーのエントリ上でのみ管理する必要があります。同様に、図 4–5 に示されている例では、メールストップと Fax 番号の属性を管理アシスタントのエントリ上でのみ管理する必要があります。
単一の CoS 定義エントリを使用して、このような関係をディレクトリ内のさまざまなエントリに利用できます。
別の自然な関係に、サービスレベルがあります。顧客にスタンダード、シルバー、ゴールド、およびプラチナのパッケージを提供しているインターネットサービスプロバイダを考えてみます。顧客のディスク割り当て、メールボックスの数、前払いのサポートレベルに対する権限などは、購入したサービスレベルによって異なります。次の図は、クラシック CoS スキーマによってこの機能が可能になるようすを示しています。
1 つの CoS 定義が複数の CoS テンプレートエントリに関連付けられる場合があります。
Directory Server は、1 つのクラシック CoS 定義エントリが複数の CoS テンプレートエントリに関連付けられている場合は CoS を最適化します。Directory Server は、多数の CoS 定義が適用される可能性がある場合は CoS を最適化しません。代わりに、Directory Server は各 CoS 定義をチェックして、この定義が適用されるかどうかを判定します。この動作によって、数千の CoS 定義が存在する場合はパフォーマンスの問題が発生します。
この状況は、図 4–6 で示した例に変更がある場合に発生する可能性があります。顧客に、各顧客のサービスレベルの委任管理を提供しているインターネットサービスプロバイダを考えてみます。各顧客から、スタンダード、シルバー、ゴールド、およびプラチナのサービスレベルの定義エントリが提供されます。顧客数が 1000 に増えると、1000 個のクラシック CoS 定義が作成されることになります。どの定義が適用されるを判定するために 1000 個の CoS 定義のリストがチェックされるため、Directory Server のパフォーマンスが影響を受ける可能性があります。この種の状況で CoS を使用する必要がある場合は、間接 CoS を検討してください。間接 CoS では、顧客のエントリによって、その顧客のサービスクラス割り当てを定義するエントリが特定されます。
1 つまたは 2 つのターゲットエントリごとに別の CoS スキーマを選択することの限界に近づき始めたら、実際の値を更新することをお勧めします。CoS で生成されていない実際の値が読み取られるため、より高いパフォーマンスが実現します。
ディレクトリスキーマは、ディレクトリに格納できるデータの種類を記述します。スキーマ設計により、個々のデータ要素が LDAP 属性にマップされます。関連する要素は LDAP オブジェクトクラスにまとめられます。適切に設計されたディレクトリスキーマは、データ値のサイズ、範囲、および形式を制限することによって、データの整合性の維持に役立ちます。ディレクトリに含めるエントリの種類と、各エントリで使用できる属性を決定します。
Directory Server に付属の定義済みスキーマには、Internet Engineering Task Force (IETF) 標準の LDAP スキーマが含まれます。このスキーマには、サーバーの機能をサポートするための、アプリケーション固有の追加スキーマが含まれます。また、Directory Server 固有のスキーマ拡張も含まれています。定義済みのスキーマは大半のディレクトリの要件を満たしますが、対象のディレクトリに固有のニーズに対応するために、このスキーマを拡張して新しいオブジェクトクラスと属性を追加することが必要な場合もあります。
スキーマ設計では、次のことを行う必要があります。
デフォルトスキーマへのデータのマッピング
既存のデータをデフォルトスキーマにマップするには、各データ要素が記述するオブジェクトの種類を識別してから、類似のオブジェクトクラスをデフォルトスキーマから選択します。group、people、organization などの共通オブジェクトクラスを使用します。データ要素にもっとも一致するオブジェクトクラスから、類似の属性を選択します。
一致しないデータを特定します。
デフォルトスキーマを拡張して、残りの要件を満たす新しい要素を定義します。
デフォルトのディレクトリスキーマで定義されているオブジェクトクラスと属性に一致しないデータ要素がある場合は、スキーマをカスタマイズできます。スキーマを拡張して、既存のスキーマに制約を追加することもできます。詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の「カスタムスキーマについて」を参照してください。
スキーマの保守を計画します。
可能であれば、デフォルトの Directory Server スキーマで定義されている既存のスキーマ要素を使用します。標準のスキーマ要素を使用することにより、ディレクトリ対応アプリケーションとの互換性を保ちやすくなります。このスキーマは LDAP 標準に基づいており、多数のディレクトリユーザーによる検討および合意を経ています。
データの整合性を保つことにより、LDAP クライアントアプリケーションがディレクトリエントリを検索しやすくなります。ディレクトリに格納される情報の種類ごとに、その情報をサポートするために必要なオブジェクトクラスと属性を選択します。常に同じオブジェクトクラスと属性を使用します。整合性のないスキーマオブジェクトを使用すると、情報の検索が難しくなります。
次のようにすると、整合性のあるスキーマを維持できます。
スキーマ検査を使用して、属性とオブジェクトクラスが必ずスキーマ規則にマッチしていることを確認する。
スキーマ検査の詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 12 章「Directory Server のスキーマ」を参照してください。
整合性のあるデータ形式を選択して適用する。
LDAP スキーマを使用して、必要なデータを任意の属性値に格納できます。ただし、LDAP クライアントアプリケーションとディレクトリユーザーに適切な形式を選択して、DIT 内で整合性を維持するようにデータを格納することをお勧めします。Directory Server で LDAP プロトコルを使用する場合、RFC 4517 仕様で定められたデータ形式を使用してデータを表現する必要があります。
標準 LDAP スキーマおよび DIT 設計の詳細は、次のサイトを参照してください。
RFC 4510: Lightweight Directory Access Protocol (LDAP): 技術仕様ロードマップ http://www.ietf.org/rfc/rfc4510.txt
RFC 4511: Lightweight Directory Access Protocol (LDAP): プロトコル http://www.ietf.org/rfc/rfc4511.txt
RFC 4512: Lightweight Directory Access Protocol (LDAP): ディレクトリ情報モデル http://www.ietf.org/rfc/rfc4512.txt
RFC 4513: Lightweight Directory Access Protocol (LDAP): 認証方法とセキュリティー機構 http://www.ietf.org/rfc/rfc4513.txt
RFC 4514: Lightweight Directory Access Protocol (LDAP): 識別名 (DN) の文字列表現 http://www.ietf.org/rfc/rfc4514.txt
RFC 4515: Lightweight Directory Access Protocol (LDAP): 検索フィルタの文字列表現 http://www.ietf.org/rfc/rfc4515.txt
RFC 4516: Lightweight Directory Access Protocol (LDAP): URL http://www.ietf.org/rfc/rfc4516.txt
RFC 4517: Lightweight Directory Access Protocol (LDAP): 構文とマッチングルール http://www.ietf.org/rfc/rfc4517.txt
RFC 4518: Lightweight Directory Access Protocol (LDAP): 国際化された文字列の準備 http://www.ietf.org/rfc/rfc4518.txt
RFC 4519: Lightweight Directory Access Protocol (LDAP): ユーザーアプリケーション用スキーマ http://www.ietf.org/rfc/rfc4519.txt
『Understanding and Deploying LDAP Directory Services』T. Howes, M. Smith, G. Good. Macmillan Technical Publishing, 1999
Directory Server Enterprise Edition でサポートされているすべての RFC および標準規格の一覧は、『Sun Java System Directory Server Enterprise Edition 6.3 Evaluation Guide』の付録 A「Standards and RFCs Supported by Directory Server Enterprise Edition」を参照してください。