サービスクラス

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

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

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

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

CoS の安全な使い方

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

CoS 定義のエントリの保護

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

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

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

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

• ポインタ CoS の場合は、1 つのテンプレートエントリの名前の変更が禁止されています。通常、テンプレートエントリ全体を保護するのがもっとも簡単な方法です。

• クラシック CoS では、すべてのテンプレートエントリは、定義エントリで指定された共通の親を持ちます。この親エントリにテンプレートを格納するだけで、親エントリに対するアクセス制御によってテンプレートが保護されます。ただし、親の下のほかのエントリにアクセスする場合は、テンプレートエントリを個別に保護する必要があります。

• 間接 CoS の場合は、アクセスする必要があるユーザーエントリを含む、ディレクトリ内の任意のエントリにテンプレートを指定できます。必要に応じて、ディレクトリ全体の CoS 属性に対するアクセスを制御するか、またはテンプレートとして使用される各エントリの CoS 属性のセキュリティーを保護することができます。

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 定義エントリに関連付けられたオブジェクトクラスと属性を一覧表示します。

cosAttribute は複数値属性です。各値は CoS メカニズムによって生成される属性を定義します。

CoS 定義エントリには次の属性を使用できます。これらの各属性の詳細については、『Sun Java System Directory Server Enterprise Edition 6.1 Man Page Reference』の各属性を参照してください。

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

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

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

• default (または修飾子なし): エントリに計算された属性と同じタイプの実際の属性が存在する場合、サーバーはエントリに格納されている実際の属性値を上書きしません。

• override: 値がすでにエントリに格納されている場合でもサーバーは CoS によって生成された値を常に返すことを示します。

• operational: 検索で属性が明示的に要求されている場合にのみ、属性を返すことを示します。operational 属性の場合は、この属性を取得するために、スキーマ検査を渡す必要はありません。operational 修飾子の動作は override 修飾子と同じです。

  属性を operational にすることができるのは、その属性がスキーマ内でも operational と定義されている場合だけです。たとえば、description 属性は、スキーマ内で operational としてマークされていないので、CoS を使用して description 属性の値を生成する場合は、operational 修飾子を使用できません。

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 つの方法で複数の値を指定できます。

• 間接 CoS またはクラシック CoS では、ターゲットエントリの specifier 属性に複数の値を指定できます。この場合、それぞれの値によってテンプレートが決定され、各テンプレートの値は生成された値の一部になります。

• 任意のタイプの複数の CoS 定義のエントリで、cosAttribute に同じ属性名を含めることができます。この場合、すべての定義に merge-schemes 修飾子が含まれているときは、各定義によって算出されたすべての値が生成された属性に含まれます。

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.1 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 のあいまいな状況を解決するかどうかを選択できます。