| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
前 |
次 |
ディレクトリのデータ階層構造を超えて、ユーザーを表すエントリの管理では、共通の属性値を共有するグループの作成が必要になることが多くあります。Directory Serverでは、グループ、ロールおよびサービス・クラス(CoS)による高度なエントリ管理機能を用意しています。
この章の内容は、次のとおりです。
グループ、ロールおよびCoSは、次のように定義されます。
グループは、他のエントリをメンバーのリストまたはメンバーに対するフィルタとして指定するエントリです。メンバーのリストから構成されるグループの場合、Directory Serverはユーザー・エントリごとにisMemberOf属性の値を生成します。したがって、ユーザー・エントリのisMemberOf属性には、そのエントリが属するすべてのグループが示されます。
ロールは、ロールの各メンバーに対してnsrole属性を生成するメカニズムによって、グループと同等またはそれ以上の機能を提供します。
CoSは算出属性を生成することで、各エントリに属性を格納しなくても、エントリで共通の属性値を共有できます。
isMemberOf属性を使用して、共通の算出属性値から自動的に静的グループのメンバーすべてに継承させることはできません。
Directory Serverは、ロール、グループおよびCoSの算出属性の値に基づいて検索を実行する機能を備えています。操作で使用するフィルタ文字列には、nsRole属性またはCoS定義で生成された任意の属性を含めることができます。フィルタ文字列を使用して、この属性の値の比較操作も実行できます。ただし、CoSの演算属性の索引は作成できません。したがって、CoSで生成された属性を含む検索では、時間およびメモリーの面で、リソースを大量に消費する場合があります。
ロール、グループおよびCoSにより提供される機能を十分に活用するには、ディレクトリ・デプロイメントの計画段階でグループ化の戦略を決定します。これらの機能の説明およびこれらによってトポロジを簡素化する方法については、Oracle Directory Server Enterprise Editionのリファレンスの第11章のDirectory Serverのグループとロールについての章を参照してください。
ロールとグループの仕組みをより深く理解するためには、Oracle Directory Server Enterprise Editionのリファレンスの第11章Directory Serverのグループとロールについての章を参照してください。CoSの詳細は、Oracle Directory Server Enterprise Editionのリファレンスの第12章のDirectory Serverのサービス・クラスについての章を参照してください。
グループによってエントリを関連付けて管理を容易にできます。たとえば、グループを使用すると、アクセス制御命令(ACI)の定義が簡単になります。グループ定義は、静的リストのメンバーに名前を付けるか、動的エントリ・セットを定義するフィルタを提供する特別なエントリです。
グループに含めることができるメンバーの範囲は、グループ定義エントリの配置場所とは無関係に、ディレクトリ全体となります。管理を簡素化するために、通常グループ定義エントリはすべて1か所に格納されます。通常は、ルート接尾辞の下のou=Groupsに格納されます。
グループには、静的グループおよび動的グループの2種類があります。
静的グループ。静的グループを定義するエントリはgroupOfNamesまたはgroupOfUniqueNamesオブジェクト・クラスのいずれかから継承されます。グループのメンバーは、memberまたはuniqueMember属性の複数値として、それぞれのDNでリストされます。
または、静的グループにはisMemberOf属性も使用できます。isMemberOf属性は検索開始時に計算され、ユーザー・エントリに追加されます。その後、検索が終了すると再び削除されます。この機能により、グループ管理が簡単になり、読取りアクセスが速くなります。
動的グループ。動的グループを定義するエントリはgroupOfURLsオブジェクト・クラスから継承されます。グループ・メンバーシップは、複数値のmemberURL属性で指定される1つ以上のフィルタで定義されます。動的グループのメンバーは、フィルタが評価されたときにそのいずれかに一致するエントリです。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
ldapmodifyコマンドを使用して、新しい静的グループを作成します。
たとえば、System Administratorsという新しい静的グループを作成して、メンバーをいくつか追加するには、次のコマンドを使用できます。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=System Administrators, ou=Groups, dc=example,dc=com changetype: add cn: System Administrators objectclass: top objectclass: groupOfNames ou: Groups 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
新しいグループが作成され、かつメンバーが追加されたことを確認します。
たとえば、新しいSystem AdministratorsグループにKirsten Vaughanが含まれていることを確認するには、次を入力します。
$ ldapsearch -b "dc=example,dc=com" uid=kvaughan isMemberOf uid=kvaughan,ou=People,dc=example,dc=com isMemberOf: cn=System Administrators, ou=Groups, dc=example,dc=com isMemberOf: cn=HR Managers,ou=groups,dc=example,dc=com
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
ldapmodifyコマンドを使用して、新しい動的グループを作成します。
たとえば3rd Floorという新しい動的グループ(部屋番号が3で始まる部屋の全従業員が含まれる)を作成するには、次のコマンドを使用できます。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=3rd Floor, ou=Groups, dc=example,dc=com changetype: add cn: 3rd Floor objectclass: top objectclass: groupOfUrls ou: Groups memberURL: ldap:///dc=example,dc=com??sub?(roomnumber=3*)
ロールは、より効率的かつ簡単なアプリケーションの使用を目的に設計された代替のグループ化メカニズムです。ロールの定義および管理はグループと同様ですが、各メンバー・エントリに生成されるロール属性は自動的にエントリのロールを示します。たとえば、アプリケーションではグループの選択およびメンバー・リストの参照を必要とせずに、エントリのロールの読込みが可能となります。
デフォルトでは、ロールの範囲は、範囲が定義されているサブツリーに制限されます。しかし、ネストされたロールの範囲は拡張できます。他のサブツリーにあるロールをネストしたり、ディレクトリの任意の場所のメンバーを含めることもできます。詳細は、「ロールの範囲を拡張するには:」および「ネストされたロール定義の例」を参照してください。
この項では、ロールのセキュアな使用方法、およびコマンドラインからのロールの管理方法を説明します。
ロールをセキュアに使用するために、アクセス制御命令(ACI)を設定して、該当する属性を保護する必要があります。たとえば、ユーザーAが管理対象ロールであるMRを所有するとします。管理対象ロールは静的グループに相当するもので、nsRoleDN属性を各メンバー・エントリに追加することで、明示的にロールをそれらのエントリに割り当てます。MRロールは、コマンドラインによるアカウントの非アクティブ化を使用してロックされています。これは、ユーザーAはサーバーにバインドできないことを意味します(このユーザーに対してnsAccountLock属性がtrueとして計算されるため)。ただし、このユーザーはすでにバインド済で、現在はMRロールによりロックされていると通知されたものとします。このユーザーがnsRoleDN属性に書込みアクセスできないようにするためのACIが存在しない場合、このユーザーはnsRoleDN属性を自分のエントリから削除して、自身のロックを解除できます。
ユーザーによるnsRoleDN属性の削除を防止するには、ACIを適用する必要があります。フィルタ処理されたロールでは、属性変更によりユーザーがフィルタ処理されたロールを放棄できないよう、フィルタを一部保護する必要があります。フィルタ処理されたロールで使用する属性をユーザーが追加、削除および変更できないようにする必要があります。フィルタ属性値の計算の場合も同様に、フィルタ属性値の変更が可能な属性はすべて保護する必要があります。ネストされたロールにはフィルタ処理されたロールおよび管理対象ロールを含むことができるので、ネストされたロールに含まれる各ロールについても前述の事項を考慮する必要があります。
セキュリティに対するACI設定の詳細な手順は、第6章「Directory Serverのアクセス制御」を参照してください。
ロールは、コマンドライン・ユーティリティによりディレクトリ管理者がアクセス可能なエントリで定義されます。ロールを作成した後、次のようにメンバーをロールに割り当てます。
管理対象ロールのメンバーは各自のエントリにnsRoleDN属性を持ちます。
フィルタ処理されたロールのメンバーは、nsRoleFilter属性で指定するフィルタと一致するエントリとなります。
ネストされたロールのメンバーは、ネストされたロール定義エントリのnsRoleDN属性で指定するロールのメンバーとなります。
すべてのロール定義はLDAPsubentryおよびnsRoleDefinitionオブジェクト・クラスから継承されます。次の例では、各タイプのロールに固有の追加オブジェクト・クラスと関連付けられた属性を示します。
すべてのマーケティング・スタッフのロールを作成するには、次のようにldapmodifyコマンドを使用します。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsSimpleRoleDefinition objectclass: nsManagedRoleDefinition cn: Marketing description: managed role for marketing staff
nsManagedRoleDefinitionオブジェクト・クラスは、LDAPsubentry、nsRoleDefinitionおよびnsSimpleRoleDefinitionオブジェクト・クラスから継承されることに注意してください。
Bobという名前のマーケティング・スタッフのメンバーにロールを割り当てるには、次のようにエントリを更新します。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=Bob Arnold,ou=marketing,ou=People,dc=example,dc=com changetype: modify add: nsRoleDN nsRoleDN: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com
nsRoleDN属性では、エントリが管理対象ロールのメンバーであることを示しています。管理対象ロールは、そのロール定義のDNにより識別されます。ユーザーが自身のnsRoleDN属性を変更できるようにしつつも、nsManagedDisabledRoleの追加や削除はできないようにするには、次のACIを追加します。
aci: (targetattr="nsRoleDN")(targattrfilters="add=nsRoleDN: (!(nsRoleDN=cn=AdministratorRole,dc=example,dc=com)), del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=example, dc=com)") (version3.0;aci "allow mod of nsRoleDN by self except for critical values"; allow(write) userdn="ldap:///self";)
セールス・マネージャのフィルタ処理されたロールを設定するには、すべてのセールス・マネージャがisManager属性を持つものとして、次のldapmodifyコマンドを使用します。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=ManagerFilter,ou=sales,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: ManagerFilter nsRoleFilter: (isManager=True) Description: filtered role for sales managers
nsFilteredRoleDefinitionオブジェクト・クラスは、LDAPsubentry、nsRoleDefinition、およびnsComplexRoleDefinitionオブジェクト・クラスから継承されることに注意してください。nsRoleFilter属性は、下位組織を持つou=sales組織の従業員すべてを検索するフィルタを指定し、たとえば次のようになります。
$ 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=sales,ou=People,dc=example,dc=comcn: Carla Fuentes isManager: TRUE... nsRole: cn=ManagerFilter,ou=sales,ou=People, dc=example,dc=com
|
注意: フィルタ処理されたロールのフィルタ文字列は任意の属性に基づくことができますが、CoSメカニズムで生成される算出属性については例外となります。 |
フィルタ処理されたロールのメンバーがユーザー・エントリである場合、それらのメンバーがロールに自分自身を追加または削除する機能を制限することが可能です。ACIでフィルタ処理された属性を保護してください。
ネストされたロール内にネストされるロールは、nsRoleDN属性を使用して指定します。次のコマンドを使用して、前の例で作成したロールのマーケティング・スタッフおよびセールス・マネージャの両方のメンバーを含むロールを作成します。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - dn: cn=MarketingSales,ou=marketing,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsNestedRoleDefinition cn: MarketingSales nsRoleDN: cn=ManagerFilter,ou=sales,ou=People,dc=example,dc=com nsRoleDN: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com nsRoleScopeDN: ou=sales,ou=People,dc=example,dc=com
nsNestedRoleDefinitionオブジェクト・クラスは、LDAPsubentry、nsRoleDefinitionおよびnsComplexRoleDefinitionオブジェクト・クラスから継承されることに注意してください。nsRoleDN属性は、マーケティングの管理対象ロール、およびセールス・マネージャのフィルタ処理されたロールのDNを含んでいます。前述の例のユーザーBobとCarlaはどちらもこの新しくネストされたロールのメンバーとなります。
このフィルタの範囲には、デフォルトの有効範囲が含まれ、これはフィルタがあるサブツリー、およびnsRoleScopeDN属性の値の下にあるサブツリーのことです。この場合、ManagerFilterはou=sales,ou=People,dc=example,dc=comサブツリーにあります。このサブツリーを範囲に追加する必要があります。
Directory Serverでは、ロールの範囲をロール定義エントリのサブツリーを超えて拡張できる属性が用意されています。この単一値属性nsRoleScopeDNは、既存ロールに追加する範囲のDNを含みます。nsRoleScopeDN属性は、ネストされたロールにのみ追加できます。「ネストされたロール定義の例」を参照してください。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
nsRoleScopeDN属性により、あるサブツリーのロールの範囲を拡張して、他のサブツリーのエントリを含めることができます。たとえば、example.comディレクトリ・ツリーの2つの主要サブツリーである、o=eng,dc=example,dc=com(エンジニアリング・サブツリー)およびo=sales,dc=example,dc=com(セールス・サブツリー)を考えます。エンジニアリング・サブツリーのユーザーは、セールス・サブツリーのロール(SalesAppManagedRole)で管理されるセールス・アプリケーションへのアクセス権が必要になります。ロールの範囲を拡張するには、次を実行します。
エンジニアリング・サブツリーのユーザーのロールを作成します。
たとえば、ロールEngineerManagedRoleを作成します。この例では、管理対象ロールを使用しますが、フィルタ処理されたロールまたはネストされたロールでも同様にできます。
セールス・サブツリーにネストされたロール、たとえばSalesAppPlusEngNestedRoleを作成して、新たに作成したEngineerManagedRoleと元からあるSalesAppManagedRoleを収容します。
追加するエンジニアリング・サブツリーの範囲のDN(この場合はo=eng,dc=example,dc=com)で、nsRoleScopeDN属性をSalesAppPlusEngNestedRoleに追加します。
エンジニアリング・ユーザーには必要な権限を付与して、SalesAppPlusEngNestedRoleロール、さらにはセールス・アプリケーションにアクセスできるようにする必要があります。さらに、ロールの範囲全体をレプリケートする必要があります。
|
注意: 拡張する範囲をネストされたロールに制限することは、以前あるドメインでロールを管理していた管理者は、他のドメインの既存ロールを使用する権限しか持たないことを意味します。管理者は他のドメインで任意のロールを作成できません。 |
サービス・クラス(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定義エントリのオブジェクト・クラスと属性
| CoSのタイプ | CoS定義のエントリ |
|---|---|
|
ポインタCoS |
|
|
間接CoS |
|
|
クラシックCoS |
|
いずれの場合も、cosAttributeは複数値となります。各値は、CoSメカニズムにより生成される属性を定義します。
CoS定義エントリでは、次の属性が使用できます。これらの各属性については、Oracle Directory Server Enterprise Editionのマニュアル・ページ・リファレンスの各属性を参照してください。
表9-2 CoS定義エントリの属性
| 属性 | CoS定義エントリ内での目的 |
|---|---|
|
attributeName override merge |
値を生成する算出属性の名前を定義します。この属性は複数値となります。それぞれの値は、値がテンプレートから生成される属性の名前を表します。overrideおよびmerge修飾子により、次の表で説明するような特別な場合のCoS属性値の算出方法を指定します。 attributeNameにサブタイプを含めることはできません。サブタイプを伴う属性名は無視されますが、 |
|
attributeName |
ターゲット・エントリの属性名を定義します。間接CoSはこの属性の値を使用してテンプレート・エントリを識別します。名前が指定された属性は指示子と呼ばれ、各ターゲット・エントリに完全DN文字列を含める必要があります。この属性は単一の値ですが、attributeNameを複数値にすることで、複数のテンプレートを指定できます。 |
|
attributeName |
ターゲット・エントリの属性名を定義します。クラシックCoSはこの属性の値を使用してテンプレート・エントリを識別します。名前が指定された属性は指示子と呼ばれ、テンプレート・エントリのRDN内で検出可能な文字列を含める必要があります。この属性は単一の値ですが、attributeNameを複数値にすることで、複数のテンプレートを指定できます。 |
|
DN |
ポインタCoS定義用にテンプレート・エントリの完全DNを、クラシックCoS用にテンプレート・エントリのベースDNを指定します。この属性は単一の値です。 |
|
注意:
|
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属性を |
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テンプレート・エントリで定義されます。
|
注意:
|
ポインタ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が曖昧となるようなケースを解消するかどうかを選択できます。
参照整合性とは、エントリ間の関係を確実に維持するプラグイン・メカニズムです。グループ・メンバーシップの属性など、いくつかの属性には他のエントリのDNが含まれています。参照整合性を使用すれば、あるエントリを削除したときに、そのエントリのDNを含むすべての属性も削除できます。
たとえば、あるユーザーのエントリがディレクトリから削除された場合、参照整合性が有効になっていれば、そのユーザーはサーバーによって、所属しているすべてのグループからも削除されます。参照整合性が有効でない場合は、管理者がユーザーをグループから手動で削除する必要があります。Directory Serverをユーザーおよびグループの管理にディレクトリに依存するSunの他製品と統合する場合には、この機能が重要となります。
参照整合性プラグインが有効な場合、削除、名前変更または移動の各操作の直後に、指定された属性に対する整合性更新が実行されます。デフォルトでは、参照整合性プラグインは無効となります。
ディレクトリ内にあるユーザー・エントリまたはグループ・エントリの削除、名前変更、移動のたびに、その操作が参照整合性ログ・ファイルに記録されます。
instance-path/logs/referint
指定した時間(通称更新間隔)が経過すると、サーバーは参照整合性が有効なすべての属性を検索して、検索結果のエントリと、ログ・ファイルに存在する削除または変更済エントリのDNを照合します。特定のエントリが削除されたことがログ・ファイルに記録されていれば、対応する属性が削除されます。特定のエントリが変更されたことがログ・ファイルに記録されていれば、対応する属性値がそれに応じて変更されます。
参照整合性プラグインのデフォルト構成を有効にした場合、削除、名前変更、移動の操作を実行した直後に、member、uniquemember、owner、seeAlsoおよびnsrolednの各属性に対する整合性更新が実行されます。ただし、参照整合性プラグインの動作はユーザー自身の要件に合わせて構成できます。次のような動作を構成できます。
参照整合性の更新を別ファイルに記録する。
更新間隔を変更する。
参照整合性の更新によるシステムへの影響を少なくする場合は、更新間隔を長くできます。
参照整合性を適用する属性を選択する。
DN値を含む属性を使用または定義する場合、参照整合性プラグインでそれらを監視することもできます。
|
注意: 参照整合性プラグインで使用する全データベースのすべての属性に、索引を作成する必要があります。索引はすべてのデータベースの構成で作成する必要があります。レトロ変更ログが有効になっている場合、 |
レプリケートされた環境では、特定の制限が参照整合性プラグインの使用に関連付けられています。それらの制限事項のリストは、「レプリケーションおよび参照整合性」を参照してください。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
すべてのレプリカが構成されていること、およびすべてのレプリケーション承諾が定義されていることを確認します。
参照整合性を維持する一連の属性を定義し、マスター・サーバーで使用する更新間隔を決定します。
同じ属性セットと同じ更新間隔を使用して、すべてのマスター・サーバーで参照整合性を有効にします。
参照整合性の属性を定義するには、次のコマンドを使用します。
$ dsconf set-server-prop -h host -p port ref-integrity-attr:attribute-name \ ref-integrity-attr:attribute-name
参照整合性の属性を既存の属性リストに追加するには、次のコマンドを使用します。
$ dsconf set-server-prop -h host -p port ref-integrity-attr+:attribute-name
参照整合性の更新間隔を定義するには、次のコマンドを使用します。
$ dsconf set-server-prop -h host -p port ref-integrity-check-delay:duration
参照整合性を有効にするには、次のコマンドを使用します。
$ dsconf set-server-prop -h host -p port ref-integrity-enabled:on
すべてのコンシューマ・サーバーで参照整合性プラグインが無効になっていることを確認します。
