JavaScriptが検索に必要です。
ナビゲーション・リンクをスキップ
印刷ビューの終了
Oracle Directory Server Enterprise Edition管理ガイド 11gリリース1(11.1.1.5.0)
検索フィルタ・アイコン
検索アイコン

ドキュメント情報

はじめに

第1部 Directory Serverの管理

1.  Directory Serverのツール

2.  Directory Serverのインスタンスと接尾辞

3.  Directory Serverの構成

4.  Directory Serverのエントリ

5.  Directory Serverのセキュリティ

6.  Directory Serverのアクセス制御

7.  Directory Serverのパスワード・ポリシー

8.  Directory Serverのバックアップとリストア

9.  Directory Serverのグループ、ロールおよびCoS

グループ、ロールおよびCoSについて

グループの管理

新しい静的グループを作成するには:

新しい動的グループを作成するには:

ロールの管理

ロールのセキュアな使用方法

コマンドラインからのロールの管理

管理対象ロール定義の例

フィルタ処理されたロール定義の例

ネストされたロール定義の例

ロールの範囲の拡張

ロールの範囲を拡張するには:

サービス・クラス

CoSのセキュアな使用方法

CoS定義エントリの保護

CoSテンプレート・エントリの保護

CoSのターゲット・エントリの保護

その他の依存関係の保護

コマンドラインからのCoS管理

コマンドラインからのCoS定義エントリの作成

コマンドラインからのCoSテンプレート・エントリの作成

ロールベース属性の作成

CoSプラグインの監視

CoSロギングの設定

参照整合性の維持

参照整合性の仕組み

参照整合性プラグインを構成するには:

10.  Directory Serverのレプリケーション

11.  Directory Serverのスキーマ

12.  Directory Serverの索引作成

13.  Directory Serverの属性値の一意性

14.  Directory Serverのロギング

15.  Directory Serverの監視

第2部 Directory Proxy Serverの管理

16.  Directory Proxy Serverのツール

17.  Directory Proxy Serverのインスタンス

18.  LDAPデータ・ビュー

19.  Directory Proxy Serverの証明書

20.  Directory Proxy Serverのロード・バランシングとクライアント・アフィニティ

21.  Directory Proxy Serverの配布

22.  Directory Proxy Serverによる仮想化

23.  仮想データ変換

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の管理

29.  Directory Service Control Centerの構成

索引

サービス・クラス

サービス・クラス(CoS)のメカニズムは、クライアント・アプリケーション用にエントリが取得されると、算出属性を生成します。これによりエントリ管理が簡素化され、記憶域の必要量が減少します。CoSメカニズムにより属性をエントリ間で共有できるようになります。グループおよびロールと同様に、CoSもヘルパー・エントリに依存します。

デプロイメントでのCoSの使用方法は、Oracle Directory Server Enterprise Editionリファレンスの第12章「Directory Serverのサービス・クラス」を参照してください。


注意: すべての検索操作で、CoSで生成された属性の有無をテストしたり、属性値を比較できます。算出属性の名前は、クライアントの検索操作からあらゆるフィルタ文字列で使用できますが、フィルタ処理されたロールで使用される内部フィルタでは例外です。

新しいCoS定義を反映させるには、Directory Serverインスタンスを再起動する必要があります。


CoSのセキュアな使用方法

次の各項では、各CoSエントリのデータ読取り/書込み保護についての一般的な原則を説明します。個々のアクセス制御命令(ACI)を定義する詳細手順は、第6章「Directory Serverのアクセス制御」で説明しています。

CoS定義エントリの保護

CoS定義エントリは生成された属性の値を含みませんが、その値を検索するための情報提供を行います。CoS定義エントリの読込みにより、その値を含むテンプレート・エントリの検索方法がわかります。このエントリへの書込みにより、算出属性の生成方法が変更されます。

したがって、CoS定義エントリに対して読込みと書込みの両方のACIを定義する必要があります。

CoSテンプレート・エントリの保護

CoSテンプレート・エントリには、生成されたCoS属性の値が含まれます。しかがって、少なくとも読込みと更新については、テンプレートのCoS属性をACIで保護する必要があります。

CoSのターゲット・エントリの保護

計算されたCoS属性が生成されるCoS定義の範囲内にあるすべてエントリも、その値の算出に役立ちます。

CoS属性がすでにターゲット・エントリに存在する場合、デフォルトで、CoSメカニズムはこの値をオーバーライドしません。この動作が不要な場合、ターゲット・エントリをオーバーライドするようCoSを定義するか、すべてのターゲット・エントリのCoS属性を保護します。

間接CoSおよびクラシックCoSはターゲット・エントリの指示子属性にも依存します。この属性により、使用するテンプレート・エントリのDNまたはRDNが指定されます。ACIを使用して、CoS範囲全体でグローバルに、または必要に応じて各ターゲット・エントリに対して個別に、この属性を保護する必要があります。

その他の依存関係の保護

計算されたCoS属性は、生成されたその他のCoS属性やロールに関して定義できます。計算されたCoS属性を保護するには、これらの依存関係を理解して保護する必要があります。

たとえば、ターゲット・エントリのCoS指示子属性が、nsRoleになることがあります。したがってロール定義もACIで保護する必要があります。

一般に、算出属性値の算出に関係する属性またはエントリは、読取りと書込みの両方のアクセス制御用のACIを持つ必要があります。このため、複合的な依存関係は十分に計画するか、簡素化して、続くアクセス制御実装の煩雑性を軽減する必要があります。その他の算出属性との依存関係を最小限に抑えることで、ディレクトリのパフォーマンスを向上させ、メンテナンスを軽減できます。

コマンドラインからのCoS管理

構成情報とテンプレート・データはすべてディレクトリ内にエントリとして格納されるので、LDAPコマンドライン・ツールを使用して、CoS定義を構成および管理できます。この項では、コマンドラインからのCoS定義エントリおよびCoSテンプレート・エントリを作成する方法を示します。

コマンドラインからのCoS定義エントリの作成

すべてのCoS定義のエントリは、LDAPsubentryオブジェクト・クラスを持ち、cosSuperDefinitionオブジェクト・クラスから継承されます。また、CoSの各タイプは特定のオブジェクト・クラスから継承され、対応する属性を含みます。次の表に、各タイプのCoS定義エントリに関連付けられたオブジェクト・クラスと属性を示します。

表9-1 CoS定義エントリのオブジェクト・クラスと属性

CoSのタイプ
CoS定義のエントリ
ポインタCoS
objectclass: top

objectclass: LDAPsubentry

objectclass: cosSuperDefinition

objectclass: cosPointerDefinition

cosTemplateDN: DN

cosAttribute: attributeName override merge

間接CoS
objectclass: top

objectclass: LDAPsubentry

objectclass: cosSuperDefinition

objectclass: cosIndirectDefinition

cosIndirectSpecifier: attributeName

cosAttribute: attributeName override merge

クラシックCoS
objectclass: top

objectclass: LDAPsubentry

objectclass: cosSuperDefinition

objectclass: cosClassicDefinition

cosTemplateDN: DN

cosSpecifier: attributeName

cosAttribute: attributeName override merge

いずれの場合も、cosAttributeは複数値となります。各値は、CoSメカニズムにより生成される属性を定義します。

CoS定義エントリでは、次の属性が使用できます。これらの各属性については、Oracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスの各属性を参照してください。

表9-2 CoS定義エントリの属性

属性
CoS定義エントリ内での目的
cosAttribute

attributeName override merge

値を生成する算出属性の名前を定義します。この属性は複数値となります。それぞれの値は、値がテンプレートから生成される属性の名前を表します。overrideおよびmerge修飾子により、次の表で説明するような特別な場合のCoS属性値の算出方法を指定します。

attributeNameにサブタイプを含めることはできません。サブタイプを伴う属性名は無視されますが、cosAttributeのその他の値は処理されます。

cosIndirectSpecifier

attributeName

ターゲット・エントリの属性名を定義します。間接CoSはこの属性の値を使用してテンプレート・エントリを識別します。名前が指定された属性は指示子と呼ばれ、各ターゲット・エントリに完全DN文字列を含める必要があります。この属性は単一の値ですが、attributeNameを複数値にすることで、複数のテンプレートを指定できます。
cosSpecifier

attributeName

ターゲット・エントリの属性名を定義します。クラシックCoSはこの属性の値を使用してテンプレート・エントリを識別します。名前が指定された属性は指示子と呼ばれ、テンプレート・エントリのRDN内で検出可能な文字列を含める必要があります。この属性は単一の値ですが、attributeNameを複数値にすることで、複数のテンプレートを指定できます。
cosTemplateDN

DN

ポインタCoS定義用にテンプレート・エントリの完全DNを、クラシックCoS用にテンプレート・エントリのベースDNを指定します。この属性は単一の値です。

注意: isMemberOf属性をCosSpecifierとして使用して、静的グループのメンバーすべてに、共通の算出属性値から自動的に継承させることはできません。


cosAttribute属性には、CoS属性の名前の後に2つの修飾子(override修飾子およびmerge修飾子)を付けることができます。

override修飾子は、CoSにより動的に生成される属性がすでにエントリ内で物理的に存在する場合の動作を記述します。override修飾子は、次のいずれかにできます。

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範囲内のエントリで、その属性の実際の値に書込み操作を実行することはできません。


複数値のCoS属性

merge-schemes修飾子を指定する場合、次の2つの方法により、生成されたCoS属性に複数の値を指定できます。

2つの状況が同時に発生して、さらに多くの値を定義する場合もあります。ただし、いずれの場合でも、重複した値が生成された属性に返されるのは一度のみです。

merge-schemes修飾子を指定しない場合は、テンプレート・エントリのcosPriority属性を使用して、生成された属性のすべてのテンプレートの中から1つの値を決定します。このシナリオについては、次の項で説明します。

merge-schemes修飾子は、ターゲットで定義された実際の値とテンプレートから生成された値をマージしません。merge修飾子は、override修飾子に依存しません。すべての組合せが可能で、それぞれが含んでいる動作は相補的なものとなります。また、修飾子は属性名の後に任意の順序で指定できます。


注意: 同じ属性に複数のCoS定義が存在する場合は、その定義すべてが同じoverride修飾子およびmerge修飾子を持つ必要があります。CoS定義に修飾子の組合せが複数ある場合は、すべての定義の中から1つの組合せが任意に選択されます。


CoS属性の優先順位

複数のCoS定義または複数値の指示子は存在するが、merge-schemes修飾子が指定されていない場合、Directory Serverでは優先順位属性を使用して、算出属性の単一の値を定義する単一のテンプレートを選択します。

cosPriority属性は、対象となるすべてのテンプレートの中での特定のテンプレートのグローバルな優先順位を表します。優先順位0が最高の優先順位となります。cosPriority属性を含まないテンプレートは、最低の優先順位とみなされます。複数のテンプレートが属性値を指定していても、同一の優先順位または設定なしの場合は、任意の値が選択されます。

merge-schemes修飾子を使用する場合は、テンプレートの優先順位は考慮されません。マージする際に、テンプレートで定義される優先順位に関係なく、対象となるすべてのテンプレートで値が定義されます。cosPriority属性は、次項で説明するように、CoSテンプレート・エントリで定義されます。


注意: cosPriority属性を負の値にしないでください。また、間接CoSにより生成される属性では、優先順位がサポートされません。間接CoS定義のテンプレート・エントリでは、cosPriorityを使用しないでください。


コマンドラインからのCoSテンプレート・エントリの作成

ポインタ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定義エントリの例を示します。

ポインタ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の例

間接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による住所の生成方法を示します。生成される値は、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ターゲット・エントリも、検索やメンテナンスを容易にするため、同し場所に配置する必要があります。


CoSプラグインの監視

Directory Serverでは、CoSプラグインの特定の面を監視できます。CoS監視属性は、cn=monitor,cn=Class of Service,cn=plugins,cn=configエントリに格納されます。このエントリの下の各属性およびそれらが提供する情報の詳細は、Oracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスを参照してください。

CoSロギングの設定

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が曖昧となるようなケースを解消するかどうかを選択できます。