2. Directory Serverのインスタンスと接尾辞
7. Directory Serverのパスワード・ポリシー
8. Directory Serverのバックアップとリストア
9. Directory Serverのグループ、ロールおよびCoS
16. Directory Proxy Serverのツール
17. Directory Proxy Serverのインスタンス
19. Directory Proxy Serverの証明書
20. Directory Proxy Serverのロード・バランシングとクライアント・アフィニティ
22. Directory Proxy Serverによる仮想化
24. Directory Proxy ServerとバックエンドLDAPサーバーの接続
25. クライアントとDirectory Proxy Serverの接続
26. Directory Proxy Serverのクライアント認証
27. Directory Proxy Serverのロギング
28. Directory Proxy Serverの監視とアラート
第3部 Directory Service Control Centerの管理
サービス・クラス(CoS)のメカニズムは、クライアント・アプリケーション用にエントリが取得されると、算出属性を生成します。これによりエントリ管理が簡素化され、記憶域の必要量が減少します。CoSメカニズムにより属性をエントリ間で共有できるようになります。グループおよびロールと同様に、CoSもヘルパー・エントリに依存します。
デプロイメントでのCoSの使用方法は、Oracle Directory Server Enterprise Editionリファレンスの第12章「Directory Serverのサービス・クラス」を参照してください。
注意: すべての検索操作で、CoSで生成された属性の有無をテストしたり、属性値を比較できます。算出属性の名前は、クライアントの検索操作からあらゆるフィルタ文字列で使用できますが、フィルタ処理されたロールで使用される内部フィルタでは例外です。
新しいCoS定義を反映させるには、Directory Serverインスタンスを再起動する必要があります。
次の各項では、各CoSエントリのデータ読取り/書込み保護についての一般的な原則を説明します。個々のアクセス制御命令(ACI)を定義する詳細手順は、第6章「Directory Serverのアクセス制御」で説明しています。
CoS定義エントリは生成された属性の値を含みませんが、その値を検索するための情報提供を行います。CoS定義エントリの読込みにより、その値を含むテンプレート・エントリの検索方法がわかります。このエントリへの書込みにより、算出属性の生成方法が変更されます。
したがって、CoS定義エントリに対して読込みと書込みの両方のACIを定義する必要があります。
CoSテンプレート・エントリには、生成されたCoS属性の値が含まれます。しかがって、少なくとも読込みと更新については、テンプレートのCoS属性をACIで保護する必要があります。
ポインタCoSの場合、1つのテンプレート・エントリの名前変更は許可できません。ほとんどの場合において、テンプレート・エントリ全体を保護することが最も簡単な方法です。
クラシックCoSでは、すべてのテンプレート・エントリが定義エントリで指定された共通の親を持ちます。テンプレートをこの親エントリに格納すれば、親エントリへのアクセス制御によりテンプレートが保護されます。ただし、親の下にある他のエントリがアクセスを要求した場合、テンプレート・エントリを個別に保護する必要があります。
間接CoSの場合、テンプレートはディレクト内の任意のエントリにできます。これにはアクセスされる必要があるユーザー・エントリも含まれます。必要に応じて、ディレクトリ全体のCoS属性に対してアクセスを制御するか、またはテンプレートとして使用する各エントリでのCoS属性のセキュリティを確保できます。
計算されたCoS属性が生成されるCoS定義の範囲内にあるすべてエントリも、その値の算出に役立ちます。
CoS属性がすでにターゲット・エントリに存在する場合、デフォルトで、CoSメカニズムはこの値をオーバーライドしません。この動作が不要な場合、ターゲット・エントリをオーバーライドするようCoSを定義するか、すべてのターゲット・エントリのCoS属性を保護します。
間接CoSおよびクラシックCoSはターゲット・エントリの指示子属性にも依存します。この属性により、使用するテンプレート・エントリのDNまたはRDNが指定されます。ACIを使用して、CoS範囲全体でグローバルに、または必要に応じて各ターゲット・エントリに対して個別に、この属性を保護する必要があります。
計算されたCoS属性は、生成されたその他のCoS属性やロールに関して定義できます。計算されたCoS属性を保護するには、これらの依存関係を理解して保護する必要があります。
たとえば、ターゲット・エントリのCoS指示子属性が、nsRoleになることがあります。したがってロール定義もACIで保護する必要があります。
一般に、算出属性値の算出に関係する属性またはエントリは、読取りと書込みの両方のアクセス制御用のACIを持つ必要があります。このため、複合的な依存関係は十分に計画するか、簡素化して、続くアクセス制御実装の煩雑性を軽減する必要があります。その他の算出属性との依存関係を最小限に抑えることで、ディレクトリのパフォーマンスを向上させ、メンテナンスを軽減できます。
構成情報とテンプレート・データはすべてディレクトリ内にエントリとして格納されるので、LDAPコマンドライン・ツールを使用して、CoS定義を構成および管理できます。この項では、コマンドラインからのCoS定義エントリおよびCoSテンプレート・エントリを作成する方法を示します。
すべてのCoS定義のエントリは、LDAPsubentryオブジェクト・クラスを持ち、cosSuperDefinitionオブジェクト・クラスから継承されます。また、CoSの各タイプは特定のオブジェクト・クラスから継承され、対応する属性を含みます。次の表に、各タイプのCoS定義エントリに関連付けられたオブジェクト・クラスと属性を示します。
表9-1 CoS定義エントリのオブジェクト・クラスと属性
|
いずれの場合も、cosAttributeは複数値となります。各値は、CoSメカニズムにより生成される属性を定義します。
CoS定義エントリでは、次の属性が使用できます。これらの各属性については、Oracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスの各属性を参照してください。
表9-2 CoS定義エントリの属性
|
注意: isMemberOf属性をCosSpecifierとして使用して、静的グループのメンバーすべてに、共通の算出属性値から自動的に継承させることはできません。
cosAttribute属性には、CoS属性の名前の後に2つの修飾子(override修飾子およびmerge修飾子)を付けることができます。
override修飾子は、CoSにより動的に生成される属性がすでにエントリ内で物理的に存在する場合の動作を記述します。override修飾子は、次のいずれかにできます。
default(または修飾子なし): 算出属性と同じタイプの属性である場合、サーバーではエントリに格納されている実際の属性値をオーバーライドしないことを示します。
override: 値がエントリとともに格納されている場合でも、サーバーは常にCoSで生成される値を返すことを示します。
operational: 検索で明示的に要求された場合にのみ、属性が返されることを示します。操作属性では、返されるスキーマ・チェックを渡す必要はありません。operational修飾子はoverride修飾子と同じ動作をします。
スキーマにおいても属性が操作属性として定義されている場合のみ、属性を操作属性にできます。たとえば、CoSによりdescription属性の値を生成する場合、operational修飾子を使用できません。これは、description属性がスキーマ内で操作属性としてマークされていないためです。
merge修飾子は指定しないか、merge-schemesとします。この修飾子では、複数テンプレートまたは複数CoS定義から、計算されたCoS属性に複数の値を指定できます。詳細は、「複数値のCoS属性」を参照してください。
override修飾子を含むポインタCoS定義エントリを次のように作成できます。
dn: cn=pointerCoS,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=exampleUS,cn=data cosAttribute: postalCode override
このポインタCoS定義エントリでは、エントリが、postalCode属性の値を生成するテンプレート・エントリcn=exampleUS,cn=dataに関連付けられていることを示しています。override修飾子は、この属性がターゲット・エントリに存在する場合は、postalCode属性の値よりもこの値が優先されることを示しています。
注意: CoS属性をoperationalまたはoverride修飾子で定義した場合、CoS範囲内のエントリで、その属性の実際の値に書込み操作を実行することはできません。
merge-schemes修飾子を指定する場合、次の2つの方法により、生成されたCoS属性に複数の値を指定できます。
間接CoSまたはクラシックCoSでは、ターゲット・エントリの指示子属性に複数の値を指定できます。この場合、それぞれの値によりテンプレートが決定され、各テンプレートの値は生成された値の一部となります。
任意のタイプの複数のCoS定義エントリで、cosAttributeに同じ属性名を含めることができます。この場合、すべての定義にmerge-schemes修飾子が含まれていれば、生成された属性には各定義によって算出された値すべてが含まれます。
2つの状況が同時に発生して、さらに多くの値を定義する場合もあります。ただし、いずれの場合でも、重複した値が生成された属性に返されるのは一度のみです。
merge-schemes修飾子を指定しない場合は、テンプレート・エントリのcosPriority属性を使用して、生成された属性のすべてのテンプレートの中から1つの値を決定します。このシナリオについては、次の項で説明します。
merge-schemes修飾子は、ターゲットで定義された実際の値とテンプレートから生成された値をマージしません。merge修飾子は、override修飾子に依存しません。すべての組合せが可能で、それぞれが含んでいる動作は相補的なものとなります。また、修飾子は属性名の後に任意の順序で指定できます。
注意: 同じ属性に複数のCoS定義が存在する場合は、その定義すべてが同じoverride修飾子およびmerge修飾子を持つ必要があります。CoS定義に修飾子の組合せが複数ある場合は、すべての定義の中から1つの組合せが任意に選択されます。
複数のCoS定義または複数値の指示子は存在するが、merge-schemes修飾子が指定されていない場合、Directory Serverでは優先順位属性を使用して、算出属性の単一の値を定義する単一のテンプレートを選択します。
cosPriority属性は、対象となるすべてのテンプレートの中での特定のテンプレートのグローバルな優先順位を表します。優先順位0が最高の優先順位となります。cosPriority属性を含まないテンプレートは、最低の優先順位とみなされます。複数のテンプレートが属性値を指定していても、同一の優先順位または設定なしの場合は、任意の値が選択されます。
merge-schemes修飾子を使用する場合は、テンプレートの優先順位は考慮されません。マージする際に、テンプレートで定義される優先順位に関係なく、対象となるすべてのテンプレートで値が定義されます。cosPriority属性は、次項で説明するように、CoSテンプレート・エントリで定義されます。
注意: cosPriority属性を負の値にしないでください。また、間接CoSにより生成される属性では、優先順位がサポートされません。間接CoS定義のテンプレート・エントリでは、cosPriorityを使用しないでください。
ポインタCoSまたはクラシックCoSを使用する場合、テンプレート・エントリにはLDAPsubentryおよびcosTemplateオブジェクト・クラスが含まれます。このエントリは、CoS定義専用に作成する必要があります。CoSテンプレート・エントリをLDAPsubentryオブジェクト・クラスのインスタンスにすることで、構成エントリの影響を受けずに、通常の検索が実行できるようになります。
間接CoSメカニズムのテンプレートは、ディレクトリ内の任意の既存エントリとなります。ターゲットをあらかじめ指定したり、LDAPsubentryオブジェクト・クラスを指定する必要はありませが、ターゲットには予備のcosTemplateオブジェクト・クラスが含まれている必要があります。間接CoSテンプレートには、CoSを評価して算出属性とその値を生成する場合にのみアクセスします。
すべての場合において、CoSテンプレート・エントリには、ターゲット・エントリのCoSによって生成された属性および値を含める必要があります。属性名はCoS定義のエントリのcosAttribute属性で指定されます。
次の例では、postalCode属性を生成するポインタCoSに対する優先順位が最も高いテンプレート・エントリを示します。
dn: cn=ZipTemplate,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: extensibleobject objectclass: cosTemplate postalCode: 95054 cosPriority: 0
次の各項では、テンプレート・エントリの例、および各種CoS定義エントリの例を示します。
次のコマンドは、cosPointerDefinitionオブジェクト・クラスを持つポインタCoS定義エントリを作成します。この定義エントリでは、前項の例で述べたCoSテンプレート・エントリを使用して、ou=People,dc=example,dc=comツリーのすべてのエントリで共通の郵便番号を共有しています。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=pointerCoS,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=ZipTemplate,ou=People,dc=example,dc=com cosAttribute: postalCode
CoSテンプレート・エントリ(cn=ZipTemplate,ou=People,dc=example,dc=com)は、ou=People,dc=example,dc=com接尾辞の下のすべてのエントリに対して、postalCode属性に格納されている値を提供します。同じサブツリー内で郵便番号を持たないエントリを検索すると、生成される属性の値は次のようになります。
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)" dn: cn=Babs Jensen,ou=People,dc=example,dc=com cn: Babs Jensen ... postalCode: 95054
間接CoSでは、各ターゲットに固有のテンプレートを見つけるために、cosIndirectSpecifier属性内の属性に名前が付けられます。間接CoSのテンプレート・エントリは、他のユーザー・エントリを含むディレクトリ内の任意のエントリにできます。この例の間接CoSでは、ターゲット・エントリのmanager属性を使用して、CoSテンプレート・エントリを識別します。テンプレート・エントリはマネージャのユーザー・エントリです。マネージャのユーザー・エントリには、生成する属性の値が含まれます。この場合、その値はdepartmentNumberの値となります。
次のコマンドは、cosIndirectDefinitionオブジェクト・クラスを含む間接CoS定義エントリを作成します。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=generateDeptNum,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosIndirectDefinition cosIndirectSpecifier: manager cosAttribute: departmentNumber
次に、cosTemplateオブジェクト・クラスをテンプレート・エントリに追加して、生成される属性が定義されていることを確認します。この例では、マネージャのエントリは次のようにすべてテンプレートとなります。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=Carla Fuentes,ou=People,dc=example,dc=com changetype: modify add: objectclass objectclass: cosTemplate - add: departmentNumber departmentNumber: 318842
このCoSでは、manager属性を含むターゲット・エントリ(ou=People,dc=example,dc=comの下のエントリ)には、自動的にマネージャの部署番号が含まれます。departmentNumber属性はサーバーに存在しないため、ターゲット・エントリで算出されます。ただし、departmentNumber属性はターゲット・エントリの一部として返されます。たとえば、Babs JensenのマネージャをCarla Fuentesとして定義する場合、このマネージャの部署番号は次のように表示されます。
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)" dn: cn=Babs Jensen,ou=People,dc=example,dc=com cn: Babs Jensen ... manager: cn=Carla Fuentes,ou=People,dc=example,dc=com departmentNumber: 318842
この例では、クラシックCoSによる住所の生成方法を示します。生成される値は、CoS定義のcosTemplateDNおよびターゲット・エントリのcosSpecifier属性の値の組合せで検索されるテンプレート・エントリに指定されます。次のコマンドは、cosClassicDefinitionオブジェクト・クラスを使用して、定義エントリを作成します。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=classicCoS,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: ou=People,dc=example,dc=com cosSpecifier: building cosAttribute: postalAddress
同じコマンドを使用して、各ビルの住所を提供するテンプレート・エントリを作成します。
dn: cn=B07,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: extensibleobject objectclass: cosTemplate postalAddres: 7 Old Oak Street, Anytown, CA 95054
このCoSでは、building属性を含むターゲット・エントリ(ou=People,dc=example,dc=comの下のエントリ)には、自動的に対応する住所が含まれます。CoSメカニズムは、RDNに指示子属性値を持つテンプレート・エントリを検索します。この例では、Babs JensenがビルB07に割り当てられると、Jensenの住所は次のように生成されます。
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - \ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Jensen)" dn: cn=Babs Jensen,ou=People,dc=example,dc=com cn: Babs Jensen ... building: B07 postalAddress: 7 Old Oak Street, Anytown, CA 95054
エントリが所有するロールに基づくエントリに対して属性値を生成するクラシックCoSスキーマを作成できます。たとえば、ロールベースの属性を使用して、サーバーの検索制限をエントリごとに設定できます。
ロールベース属性を作成するには、クラシックCoSのCoS定義エントリ内でcosSpecifierとしてnsRole属性を使用します。nsRole属性には複数の値を指定できるので、複数の使用可能なテンプレート・エントリを持つCoSスキーマを定義できます。どのテンプレー・トエントリを使用するかを明確にするには、cosPriority属性をCoSテンプレート・エントリに含めることができます。
たとえば、マネージャ・ロールのメンバーが標準のメールボックス割当て量を超えて使用できるようにするCoSを作成できます。マネージャ・ロール次のようになります。
dn: cn=ManagerRole,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: ManagerRole nsRoleFilter: (isManager=True) Description: filtered role for managers
クラシックCoS定義エントリは次のように作成します。
dn: cn=generateManagerQuota,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: cn=managerCOS,ou=People,dc=example,dc=com cosSpecifier: nsRole cosAttribute: mailboxquota override
CoSテンプレート名は、cosTemplateDnとロールのDNであるnsRoleの値の組合せにする必要があります。たとえば、次のようになります。
dn:cn="cn=ManagerRole,ou=People,dc=example,dc=com",\ cn=managerCOS,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: extensibleobject objectclass: cosTemplate mailboxquota: 1000000
CoSテンプレート・エントリは、mailboxquota属性の値を提供します。追加のoverride修飾子は、CoSに対してターゲット・エントリ内の既存のすべてのmailboxquota属性をオーバーライドするよう指定します。ロールのメンバーであるターゲット・エントリは、たとえば、次のように、ロールとCoSにより生成される算出属性を持ちます。
$ ldapsearch -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -\ -b "ou=People,dc=example,dc=com" -s sub "(cn=*Fuentes)" dn: cn=Carla Fuentes,ou=People,dc=example,dc=comcn: Carla Fuentes isManager: TRUE...nsRole: cn=ManagerRole,ou=People,dc=example,dc=com mailboxquota: 1000000
注意: ロール・エントリおよびCoS定義エントリは、適用範囲に同じターゲット・エントリを持つように、ディレクトリ・ツリー内の同じ場所に配置する必要があります。CoSターゲット・エントリも、検索やメンテナンスを容易にするため、同し場所に配置する必要があります。
Directory Serverでは、CoSプラグインの特定の面を監視できます。CoS監視属性は、cn=monitor,cn=Class of Service,cn=plugins,cn=configエントリに格納されます。このエントリの下の各属性およびそれらが提供する情報の詳細は、Oracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスを参照してください。
Directory Serverでは、適用可能な複数の定義エントリの間でなんらかの区別を付ける必要がある場合、警告メッセージがログに記録されます。それらの警告メッセージは次の形式となります。
Definition /defDN1/ and definition /defDN2/ compete to provide attribute '/type/' at priority /level/
さらに、ディレクトリサーバーが複数の該当する可能性のある定義エントリ間でなんらかの区別を付ける必要がある場合に、情報メッセージを記録するように、Directory Serverを構成することもできます。このためには、プラグインからのメッセージを取り込むようにエラー・ログを設定します。
注意: ログ・レベルの追加設定は、ロギングにより負荷が増す可能性があるので、本番サーバーではロギングを設定しないことをお薦めします。
情報メッセージの内容は次の形式となります。
Definition /defDN1/ and definition /defDN2/ potentially compete to provide attribute '/type/' at priority /level/
これで、定義エントリにCoS優先順位を適切に設定することで、CoSが曖昧となるようなケースを解消するかどうかを選択できます。