ディレクトリ情報ツリーは、エントリを階層構造で構成します。この階層は、グループ化メカニズムの 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 で生成されていない実際の値が読み取られるため、より高いパフォーマンスが実現します。