| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
前 |
次 |
ディレクトリ情報ツリーによって、エントリが階層的に構成されます。この階層は、グループ化メカニズムの一種です。この階層は、分散したエントリ間の関連付けには適していません(頻繁に変更のある組織の場合、または多くのエントリに反復データが存在する場合)。Directory Serverグループおよびロールによって、エントリ間の関連付けがさらに柔軟になります。
この章では、エントリ同士を関連付けるために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
静的グループは、グループの各メンバーのDNを指定します。静的グループによって、次のオブジェクト・クラスと属性のペアの1つが使用されます。
groupOfNamesオブジェクト・クラスと複数値member属性
groupOfUniqueNamesオブジェクト・クラスと複数値uniqueMember属性
member属性およびuniqueMember属性には、グループのメンバーであるすべてのエントリのDNが含まれています。一意性を保証するために、DNのuniqueMember属性値に、オプションでハッシュ、#および一意の識別子ラベルを続けることができます。
動的グループは、フィルタとこのフィルタに合致するすべてのエントリが、グループのメンバーであることを指定します。このようなグループは、フィルタが評価されるたびにメンバーシップが定義されるため、動的です。
たとえば、御社のビルの3階にすべての経営幹部とそのアシスタントが存在し、各従業員の部屋番号がフロアー番号で始まることを想定してください。3階の従業員のみを含むグループを作成しようとする場合、次の図に示されているように、これらの従業員のみを定義するために部屋番号を使用できます。
次のLDIF抽出は、この動的グループがどのように定義されているかを示しています。
dn: cn=3rd Floor, ou=Groups, dc=example,dc=com ... memberURL: ldap:///dc=example,dc=com??sub?(roomnumber=3*)
動的グループによって、次のオブジェクト・クラスと属性のペアの1つが使用されます。
groupOfURLsオブジェクト・クラスと複数値memberURL属性
groupOfUniqueNamesオブジェクト・クラスとuniqueMember属性
グループ・メンバーは、memberURL属性のLDAP URL値として表示される1つ以上のフィルタ、またはuniqueMember属性値としての1つ以上のDNのいずれかによって、リスト表示されます。
静的および動的グループは、member属性またはuniqueMember属性の値として別のグループのDNを指定することによってネスト可能です。ネストされたグループがACIによってサポートされる深さは、nsslapd-groupevalnestlevel構成パラメータによって制御されます。また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
|
注意: ネストされたグループは、最も効率のよいグループ化メカニズムではありません。動的なネストされたグループによって、パフォーマンスへの影響がさらに増加します。このようなパフォーマンスの問題を避けるために、かわりにロールの使用を検討します。 |
ロールはグループに類似していますが、逆の働きをします(すなわち、グループ・エントリがメンバー・エントリのDNをリスト表示する場合に、各メンバー・エントリに関してロール・エントリのDNがリスト表示されます)。ロール・メカニズムによって、エントリに割り当てられているロールのリストの取得が容易になります。
各ロールにはmembersまたはロールを所有するエントリが含まれます。ロール・メカニズムは、nsRoleDN属性およびnsRole属性によって管理されます。nsRoleDN属性は、ロールにエントリを追加するために使用されます。nsRole属性は読取り専用属性で、ディレクトリ・サーバーによって保持され、エントリが属するロールをリストします。nsRole属性は、エントリが属するすべてのロールを列挙するために、クライアントによる読取りまたは検索が可能です。ロール・メンバーシップを公開しないようにするには、nsRole属性を読取り保護するためのアクセス制御を定義します。
デフォルトでは、ロールの範囲は、これが定義されているサブツリーに制限されます。ロールの範囲は、同じサーバー・インスタンスにおける他のサブツリーに拡張できます。
管理対象ロールは、静的グループと機能的に非常に類似しています。管理対象ロールは、nsRoleDN属性を各メンバー・エントリに追加することで、明示的にロールをそれらのエントリに割り当てます。この属性の値は、ロール定義エントリのDNです。
ロール定義エントリによってのみ、ディレクトリにおけるロールの範囲が定義されます。ロールのメンバーは、ロール定義の範囲内に存在するエントリで、nsRoleDN属性でロール定義エントリを識別するエントリです。
フィルタ処理されたロールは、動的グループに相当します。エントリは、特定の検索フィルタに合致する場合に、ロールに割り当てられます。検索フィルタの値は、nsRoleFilter属性によって定義されます。サーバーがフィルタ処理されたロールの範囲のエントリを戻す際に、このエントリには、ロールを識別する生成済nsRole属性が含まれます。
ネストされたロールは、ネストされたグループに相当します。ネストされたロールによって、他のロールを含むロールを作成し、既存のロールの範囲を拡張することができます。ネストされたロール自体に、他のネストされたロールが含まれます。30レベルまでのネストがサポートされています。
ネストされたロールによって、他のロールの定義エントリがリスト表示され、これらのロールのすべてのメンバーが結合されます。エントリがネストされたロールにリスト表示されているロールのメンバーである場合、このエントリもネストされたロールのメンバーです。
ロールを使用してご使用のディレクトリ・サービスをサポートするには、次の制限事項に注意してください。
フィルタされたロールのフィルタ文字列は、CoS仮想値の値に基づくことはできません。ただし、CoS定義の指定子属性が、ロール定義により生成されたnsRole属性を参照する場合があります。CoSの詳細は、第12章のDirectory Serverのサービス・クラスについての説明を参照してください。
ロールの範囲を別のサブツリーに拡張できますが、これらのロールは同じサーバー・インスタンス上に存在している必要があります。ロールの範囲を他のサーバーへ拡張することはできません。
nsRole属性についての検索nsRole属性は、あらゆる比較演算子とともにあらゆる検索フィルタで使用できます。nsRole属性について検索する際に、次の点を考慮します。
エントリがフィルタ処理可能となる前にすべてのロールが評価される必要があるため、nsRole属性についての検索には、長い時間がかかる場合があります。
Directory Serverは、管理対象ロールにおけるメンバーシップについての等価検索向けに最適化されています。たとえば、この検索は実際の属性についての検索とほぼ同じ速さで行われます。
(&(nsRole=cn=managersRole,ou=People,dc=example,dc=com) (objectclass=person)
nsRoleDN属性は、デフォルトですべてのサフィックスにおいて索引付けされます。索引付けがnsRoleDN属性に対して無効化されている場合、管理対象ロールのメンバーシップ検索の最適化は失われます。
フィルタ処理されたロールを含むエントリの検索には、ロール・フィルタによる内部検索が含まれます。ロール・フィルタに表示されるすべての属性が、このロールの範囲におけるすべてのサフィックスで索引付けされている場合、この内部操作は最速となります。
グループおよびロール・メカニズムの機能は、ある程度重複しています。両方のメカニズムに、長所と短所があります。一般的にロール・メカニズムは、頻繁に必要な機能を効率的に提供するために設計されています。グループ化メカニズムの選択は、サーバーの複雑さに影響し、クライアントがメンバーシップ情報を処理する方法を特定するため、グループ化メカニズムを慎重に計画する必要があります。どのメカニズムがより適切かを判断するには、代表的なメンバーシップ問合せと実行されている管理操作を理解する必要があります。
グループには次の長所があります。
静的グループは唯一の、標準ベースのグループ化メカニズムです。したがって静的グループは、ほとんどのクライアント・アプリケーションおよびLDAPサーバーと相互運用可能です。
メンバーを列挙する場合は、ロールよりも、静的グループをお薦めします。
特定のセットのメンバーを列挙することのみが必要な場合、静的グループでの負荷は高くありません。member属性を取得することによって静的グループのメンバーを列挙することは、ロールを共有するすべてのエントリをリカバリするよりも容易です。Directory Serverでは、大きな複数値属性に関して、パフォーマンスが著しく向上します。これらの属性に関する等価一致および変更操作(特に静的グループ関連)は大きく向上します。グループ・エントリのメンバーシップに関するテストも改善されました。以前は静的グループに対するいくつかの制限がありましたが(特にグループ・サイズの制限)、それらの機能強化によって取り除かれました。
Directory Serverはまた、ユーザー・エントリのグループ・メンバーシップに、isMemberOf操作属性を直接提供します。この機能は、静的グループのみに適用されますが、ネストされたグループを含みます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の管理グループに関する説明を参照してください。
メンバーの割当ておよび削除のような管理操作の場合は、ロールよりも、静的グループをお薦めします。
静的グループは、ユーザーをセットに割り当てたり、ユーザーをセットから削除する場合に、最も平易なメカニズムです。ユーザーをグループに追加するために、特別なアクセス権は不要です。
グループ・エントリを自動的に作成する権限によって、グループにメンバーを割り当てる権限が付与されます。これは、管理対象ロールおよびフィルタ処理されたロールには該当しません。このようなロールでは管理者は、ユーザー・エントリにnsroledn属性を書き込む権限も必要です。ネストされたロールにも、同じアクセス権の制限が、間接的に適用されます。ネストされたロールを作成する機能には、すでに定義されている他のロールをまとめる機能が含まれています。
フィルタベースのACIで使用する場合は、ロールよりも、動的グループをお薦めします。
ACIにおけるバインド・ルールの指定など、フィルタベースのすべてのメンバーの検索のみが必要な場合、動的グループを使用します。フィルタ処理されたロールは動的グループに類似していますが、フィルタ処理されたロールはロール・メカニズムをトリガーし、仮想nsRole属性を生成します。ご使用のクライアントでnsRole値が不要の場合、この計算のオーバーヘッドを回避するために動的グループを使用します。
既存のセットに対してセットを追加または削除する場合、ロールよりもグループをお薦めします。
既存のセットへのセットの追加、または既存のセットからのセットの削除を行う場合、グループ・メカニズムが最も平易です。グループ・メカニズムには、ネスト制限がありません。ロール・メカニズムでは、他のロールを受け入れられるのはネストされたロールに限られています。
エントリのグループ化に関する範囲の柔軟性が重要な場合、ロールよりもグループをお薦めします。
グループ定義エントリの配置場所とは無関係に、可能なメンバーの範囲がディレクトリ全体であるため、範囲に関してはグループが柔軟となっています。ロールも特定のサブツリーを越えて範囲を拡張できますが、ネストされたロールに、範囲拡張属性nsRoleScopeDNを追加することによってのみ、これを実行できます。
ロールには次の長所があります。
セットのメンバーを列挙し、かつ特定のエントリがメンバーであるすべてのセットを検索する場合は、動的グループよりもロールをお薦めします。静的グループによっても、この機能にisMemberOf属性が提供されます。
ロールは、ユーザー・エントリにメンバーシップ情報をプッシュし、ここでこの情報は、後続のメンバーシップに関するテストをさらに効率的にするためにキャッシュされます。サーバーはすべての計算を実行し、クライアントはnsRole属性の値を読み込むことのみを必要とします。さらに、この属性のすべてのロール・タイプが表示され、クライアントはすべてのロールを均一に処理できます。ロールは動的グループよりも、両方の操作をさらに効率的に、そして一層平易なクライアントで実行できます。
ご使用のグループ化メカニズムを既存のDirectory Server機能(CoS、パスワード・ポリシｰ、アカウントの非アクティブ化およびACIなど)と統合する場合、グループよりもロールをお薦めします。
サーバーにおいてセットのメンバーシップを違和感なく使用できるのは、ロールの方です。これは、サーバーが自動的に行うメンバーシップ計算を使用するということを意味します。ロールはリソース指向のACIにおいて、CoSのベースとして、さらに複雑な検索フィルタの一部として、パスワード・ポリシｰやアカウントの非アクティブ化などとともに使用できます。グループではこのような統合はできません。
ロールを使用する際には、次の問題に注意してください。
nsRole属性は、ロール・メカニズムによってのみ割当て可能です。この属性はいかなるディレクトリ・ユーザーによっても割当てや修正ができませんが、潜在的にあらゆるディレクトリ・ユーザーによって読取り可能です。アクセス制御を定義して、権限のないユーザーによってこの属性が読み取られることを防止します。
nsRoleDN属性は、管理対象ロール・メンバーシップを定義します。ユーザーが自身をロールに対して追加または削除できるかどうかを、決定する必要があります。ユーザーが各自のロールを修正できないようにするために、この趣旨でACIを定義する必要があります。
ユーザー・エントリにおける属性の存在またはその値に基づくフィルタを介して、フィルタ処理されたロールがメンバーシップを指定します。フィルタ処理されたロールでメンバーシップを誰が定義できるかを制御するために、これらの属性のユーザー権限を慎重に割り当てます。
