test

Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド

第 10 章 Directory Server のグループ、ロール、および CoS

ディレクトリのデータの階層構造を超えて、ユーザーを表すエントリを管理するために、多くの場合、共通の属性値を共有するグループを作成する必要があります。Directory Server には、グループ、ロール、サービスクラス (CoS) による高度なエントリ管理機能が備えられています。

この章の内容は次のとおりです。

グループ、ロール、およびサービスクラスについて

グループ、ロール、および CoS は次のように定義されます。

Directory Server には、ロール、グループ、CoS の計算された属性の値に基づいて検索を実行する機能があります。操作で使用するフィルタ文字列には、nsRole 属性または CoS 定義によって生成された任意の属性を含めることができます。さらに、フィルタ文字列を使用して、この属性の値の比較操作を実行することもできます。ただし、計算された CoS 属性にインデックスを作成することはできません。そのため、CoS によって生成された属性を含む検索では、時間とメモリーの面で、大量のリソースを消費する可能性があります。

ロール、グループ、およびサービスクラスが提供する機能を活用するには、ディレクトリの配備を計画する段階で、グループ化の戦略を決定しておく必要があります。これらの機能と、それらによってトポロジを簡単にする方法については、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』の「ディレクトリデータのグループ化と属性の管理」を参照してください。

ロールとグループの仕組みの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 8 章「Directory Server Groups and Roles」を参照し てください。CoS の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 9 章「Directory Server Class of Service」を参照してください。

グループの管理

グループにより、エントリを関連付けて管理を簡単にすることができます。たとえば、グループを使用すると、アクセス制御命令 (ACI) を簡単に定義できます。グループ定義は特別なエントリで、スタティックなリストにメンバーの名前を指定するか、またはダイナミックなエントリセットを定義するフィルタを指定します。

グループに含めることが可能なメンバーの範囲は、グループ定義エントリの位置に関係なく、ディレクトリ全体となります。管理を簡略化するために、すべてのグループ定義エントリは、通常、1 か所に格納されます。通常は、ルートサフィックスの下の ou=Groups に格納されます。

グループにはスタティックグループとダイナミックグループの 2 つのタイプがあります。

Procedure新しいスタティックグループを作成する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 新しいスタティックグループを作成するには、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

  2. 新しいグループが作成され、メンバーが追加されたことを確認します。

    たとえば、Kirsten Vaughan が新しい System Administrators グループに含まれているかを確認するには、次のように入力します。


    $ 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

Procedure新しいダイナミックグループを作成する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. 新しいダイナミックグループを作成するには、ldapmodify コマンドを使用します。

    たとえば、部屋番号が 3 で始まるすべての従業員を含む「3rd Floor」という新しいダイナミックグループを作成するには、次のコマンドを使用できます。


    $ 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」として計算されるので、ユーザー A はサーバーにバインドできません。ただし、ユーザーがバインド済みで、MR ロールに関して現在ロックされているという通知を受けたとします。ユーザーが nsRoleDN 属性に書き込みアクセスできないようにする ACI が存在しなければ、ユーザーは自身のエントリから nsRoleDN 属性を削除し、自身のロックを解除できます。

ユーザーが nsRoleDN 属性を削除できないようにするには、ACI を適用する必要があります。フィルタを適用したロールを使用する場合、ユーザーが属性を変更してフィルタが適用されたロールを放棄することを防ぐために、フィルタの一部を保護する必要があります。フィルタが適用されたロールで使用されている属性をユーザーが追加、削除、または変更できないようにする必要があります。同様に、フィルタ属性の値を計算する場合、フィルタ属性の値を変更できるすべての属性を保護する必要があります。入れ子のロールには、フィルタを適用したロールと管理ロールが含まれることがあるため、入れ子のロールに含まれる各ロールについても上記注意点を考慮する必要があります。

セキュリティー目的で ACI を設定する詳細な手順については、第 7 章「Directory Server のアクセス制御」を参照してください。

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

ロールは、ディレクトリ管理者がコマンド行ユーティリティーを使用してアクセスできるようにエントリに定義されます。ロールの作成が完了したら、次のようにロールにメンバーを割り当てます。

すべてのロール定義は 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 という 1 つの値からなる属性で、既存のロールに追加する範囲の DN を含みます。nsRoleScopeDN 属性を追加できるのは、入れ子のロールだけです。「入れ子のロール定義の例」を参照してください。

Procedureロールの範囲を拡張する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

nsRoleScopeDN 属性により、あるサブツリーのロールの範囲を拡張して、別のサブツリーにエントリを含めることができます。たとえば、example.com ディレクトリツリーに次の 2 つのメインサブツリーがあるとします。 o=eng,dc=example,dc=com ( エンジニアリングサブツリー) および o=sales,dc=example,dc=com (販売サブツリー)。エンジニアリングサブツリーのユーザーには、販売サブツリーのロール (SalesAppManagedRole) で管理される販売アプリケーションに対するアクセス権が必要です。ロールの範囲を拡張するには、次を実行します。

  1. エンジニアリングサブツリーのユーザーのロールを作成します。

    たとえば、EngineerManagedRole のロールを作成します。この例では、管理されるロールを使用していますが、フィルタが適用されたロールや入れ子のロールであってもかまいません。

  2. 販売サブツリーに、たとえば SalesAppPlusEngNestedRole のような入れ子のロールを作成し、新たに作成した EngineerManagedRole と、元からある SalesAppManagedRole を格納します。

  3. SalesAppPlusEngNestedRole に nsRoleScopeDN 属性を追加します。属性値には、追加するエンジニアリングサブツリーの範囲の DN を指定します。この例では、o=eng,dc=example,dc=com を指定します。

    エンジニアリングユーザーには、SalesAppPlusEngNestedRole ロールにアクセスして販売アプリケーションにアクセスできるよう、適切なアクセス権を与える必要があります。さらに、ロールの範囲全体をレプリケートする必要があります。

    注 –

    拡張する範囲を入れ子のロールに制限することは、以前に、あるドメインのロールを管理していた管理者は、その他のドメインに既に存在するロールの使用権限しか持たないことを意味します。管理者はその他のドメインに任意のロールを作成することはできません。

サービスクラス

サービスクラス (CoS) メカニズムは、クライアント アプリケーションがエントリを取り出すときに計算された属性を生成し、エントリの管理を簡単にして、必要なストレージ容量を削減します。CoS メカニズムにより、エントリ間で属性を共有できます。グループやロールの場合と同様に、CoS はヘルパーエントリに依存しています。

配備でCoS を使う方法については、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』の「サービスクラスによる属性の管理」を参照してくだ さい。

CoS を Directory Server に実装する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 9 章「Directory Server Class of Service」を参照してください。

注 –

すべての検索操作で、CoS で生成された属性の有無を調べたり、属性の値を比較したりできます。フィルタを適用したロールに使用されている内部フィルタを除き、クライアントの検索操作のすべてのフィルタ文字列に、計算された属性の名前を使用できます。

CoS の安全な使い方

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

CoS 定義のエントリの保護

CoS 定義のエントリには、生成された属性の値は含まれません。このエントリは、値を検索するための情報を提供します。CoS 定義エントリを読み取ると、値を含むテンプレートエントリを見つける方法が分かります。このエントリに書き込むと、計算された属性の生成方法が変更されます。

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

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

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

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

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

CoS 属性がターゲットエントリにすでに存在する場合は、デフォルトでは、CoS メカニズムはこの値を上書きしません。この動作を変更する場合は、ターゲットエントリを上書きするように CoS を定義するか、すべてのターゲットエントリで CoS 属性を保護します。

間接 CoS とクラシック CoS は、ターゲットエントリの specifier 属性に依存します。この属性は、使用するテンプレートエントリの DN または RDN を指定します。ACI を使用してこの属性を保護する場合は、CoS の適用範囲全体でグローバルに保護するか、または各ターゲットエントリで必要に応じて個別に保護する必要があります。

その他の従属関係の保護

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

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

一般に、計算された属性値の算出に関係する属性またはエントリには、読み取りおよび書き込みアクセス制御の ACI を設定します。このため、複雑な従属関係は、十分に計画してから設定するか、以後のアクセス制御の実装の複雑さを軽減できるように簡素化する必要があります。その他の計算された属性との従属関係を最小限に抑えると、ディレクトリのパフォーマンスを向上させ、管理作業を削減することができます。

コマンド行からの CoS の管理

設定情報とテンプレートデータはすべてディレクトリ内にエントリとして格納されるので、LDAP コマンド行ツールを使用して CoS 定義を設定、管理できます。ここでは、コマンド行を使用して CoS 定義エントリと CoS テンプレートエントリを作成する方法について説明します。

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

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

表 10–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 定義エントリには次の属性を使用できます。これらの各属性の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Man Page Reference』の各属性を参照してください。

表 10–2 CoS 定義のエントリの属性

属性 

CoS 定義のエントリ内の目的 

cosAttribute

attributeName override merge

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

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

cosIndirectSpecifier

attributeName

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

cosSpecifier

attributeName

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

cosTemplateDN

DN

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

注 –

isMemberOf 属性を CosSpecifier として使用することで、共通の計算された属性値から自動的にスタティックグループのメンバー全員に継承させることはできません。

cosAttribute 属性には、CoS 属性の名前のあとに、override 修飾子と merge 修飾子の 2 つの修飾子を指定できます。

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 定義のエントリでは、このポインタ CoS が、postalCode 属性の値を生成するテンプレートエントリ cn=exampleUS,cn=data に関連付けられています。override 修飾子が指定されているので、この値がターゲットエントリに存在する場合は、その postalCode 属性値よりも、この値が優先されます。

注 –

CoS 属性に operational または override 修飾子を定義すると、CoS 適用範囲内のエントリでは、その属性の「実際」の値に対して書き込み操作を行うことはできなくなります。

複数の値を持つ CoS 属性

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

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

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

merge-schemes 修飾子は、ターゲットに定義された「実際」の値とテンプレートから生成された値をマージしません。merge 修飾子は override 修飾子に依存しません。あらゆる組み合わせが可能で、それぞれが示す動作は有効です。また、修飾子は属性名のあとに任意の順序で指定できます。

注 –

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

CoS 属性の優先順位

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

cosPriority 属性は、対象となるすべてのテンプレートの中での特定のテンプレートのグローバルな優先順位を表します。優先順位 0 は、優先順位がもっとも高いことを示します。cosPriority 属性を含まないテンプレートは、もっとも優先順位が低いとみなされます。2 つ以上のテンプレートによって属性値が指定されているが、優先順位が同じまたは設定されていない場合は、任意の値が選択されます。

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 内に specifier 属性値を持つテンプレートエントリを検索します。この例では、Babs Jensen に B07 ビルが割り当てられていれば、住所は次のように表示されます。


$ 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 と、nsRole の値 (ロールの DN) の組み合わせである必要があります。次に例を示します。


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 エントリに格納されます。このエントリの各属性の詳細とそれらが提供する情報については、『Sun Java System Directory Server Enterprise Edition 6.3 Man Page Reference』を参照してください。

CoS ログの設定

ディレクトリサーバーは、複数の該当する定義エントリ間で何らかの区別を付ける必要がある場合に、警告メッセージを記録します。それらの警告メッセージは次の形式になります。


Definition /defDN1/ and definition /defDN2/ compete to provide attribute
 '/type/' at priority /level/

さらに、ディレクトリサーバーが複数の該当する可能性のある定義エントリ間で何らかの区別を付ける必要がある場合に、情報メッセージを記録するように、サーバーを設定することもできます。このためには、プラグインからのメッセージを含めるようにエラーログを設定します。

注 –

追加のログレベルを設定すると、ログの負荷が増す可能性があるため、本稼働用サーバーではログを設定しない方がよいです。

情報メッセージの内容は次の形式になります。


Definition /defDN1/ and definition /defDN2/ potentially compete 
to provide attribute '/type/' at priority /level/

次に、定義エントリに CoS の優先順位を適切に設定することによって、CoS のあいまいな状況を解決するかどうかを選択できます。

参照の完全性の管理

参照の完全性はエントリ間の関係を維持するためのプラグインメカニズムです。グループのメンバーシップなど、一部のタイプの属性には別のエントリの DN が含まれています。参照の完全性を利用することで、エントリを削除したときに、そのエントリの DN を含むすべての属性も削除できます。

たとえば、参照の完全性が有効になっているときに、あるユーザーのエントリがディレクトリから削除されると、そのユーザーは、所属しているあらゆるグループからも削除されます。参照の完全性が無効な状態では、管理者はグループからユーザーを手動で削除する必要があります。これは、Directory Server を、ユーザーとグループの管理にディレクトリを使用するほかの Sun Java System 製品に統合する場合に重要な機能です。

参照の完全性の仕組み

参照の完全性プラグインが有効になっているときに削除操作や名前変更、または移動の操作を実行すると、指定された属性に対する完全性更新がただちに実行されます。ただし、デフォルトでは、参照の完全性プラグインは無効になっています。

ディレクトリ内のユーザーエントリまたはグループエントリの削除、名前の変更、移動を行なった場合、常に操作が参照の完全性のログファイルに記録されます。

instance-path/logs/referint

更新間隔と呼ばれる指定した時間が経過すると、参照の完全性が有効になっているすべての属性が検索され、検索結果のエントリと、ログファイル内に記録された削除または変更されたエントリの DN が照合されます。特定のエントリが削除されたことがログファイルに記録されている場合は、対応する属性が削除されます。特定のエントリが変更されたことがログファイルに記録されている場合は、対応する属性値が記録に従って変更されます。

参照の完全性プラグインのデフォルトの設定が有効になっている場合に、削除、名前変更、移動操作を行うと、ただちに member、uniquemember、 owner、seeAlso、および nsroledn 属性に対する完全性更新が実行されます。ただし、参照の完全性プラグインの動作は、次のような用途に合わせてユーザーが自由に設定できます。次の動作を設定できます。

Procedure参照の完全性プラグインを設定する

注 –

参照の完全性プラグインで使用される全データベースのすべての属性に、インデックスを設定する必要があります。インデックスはすべてのデータベースの設定内で作成する必要があります。旧バージョン形式の更新履歴ログが有効になっている場合、cn=changelog サフィックスにインデックスを設定する必要があります。詳細については、第 13 章「Directory Server のインデックス」を参照してください。

レプリケートされた環境では、特定の制限が参照の完全性プラグインの使用に関連付けられています。これらの制限の一覧については、「レプリケーションと参照の完全性」を参照してください。

このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。

  1. すべてのレプリカが設定され、すべてのレプリケーションアグリーメントが定義されていることを確認します。

  2. 参照の完全性を維持する一連の属性を定義し、マスターサーバーで使用する更新間隔を決定します。

  3. 同じ属性セットと同じ更新間隔を使用して、すべてのマスターサーバーで参照の完全性プラグインを有効にします。

    • 参照の完全性の属性を定義するには、次のコマンドを使用します。


      $ 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

  4. すべてのコンシューマサーバー上で参照の完全性プラグインが無効になっていることを確認します。