サービスクラス (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 エントリのデータに読み取りおよび書き込み保護を設定する際の一般的な原則について説明します。各アクセス制御命令 (ACI) を定義する詳細な手順については、第 7 章「Directory Server のアクセス制御」で説明しています。
CoS 定義のエントリには、生成された属性の値は含まれません。このエントリは、値を検索するための情報を提供します。CoS 定義エントリを読み取ると、値を含むテンプレートエントリを見つける方法が分かります。このエントリに書き込むと、計算された属性の生成方法が変更されます。
したがって、CoS 定義のエントリに読み取りと書き込みの両方の ACI を定義する必要があります。
CoS テンプレートエントリには、生成された CoS 属性の値が含まれます。したがって、少なくともテンプレートの CoS 属性の読み取りと更新を ACI によって 保護する必要があります。
ポインタ CoS の場合は、1 つのテンプレートエントリの名前の変更が禁止されています。通常、テンプレートエントリ全体を保護するのがもっとも簡単な方法です。
クラシック CoS では、すべてのテンプレートエントリは、定義エントリで指定された共通の親を持ちます。この親エントリにテンプレートを格納するだけで、親エントリに対するアクセス制御によってテンプレートが保護されます。ただし、親の下のほかのエントリにアクセスする場合は、テンプレートエントリを個別に保護する必要があります。
間接 CoS の場合は、アクセスする必要があるユーザーエントリを含む、ディレクトリ内の任意のエントリにテンプレートを指定できます。必要に応じて、ディレクトリ全体の CoS 属性に対するアクセスを制御するか、またはテンプレートとして使用される各エントリの CoS 属性のセキュリティーを保護することができます。
計算された CoS 属性が生成される、CoS 定義の適用範囲内のすべてのエントリも値の算出に役立ちます。
CoS 属性がターゲットエントリにすでに存在する場合は、デフォルトでは、CoS メカニズムはこの値を上書きしません。この動作を変更する場合は、ターゲットエントリを上書きするように CoS を定義するか、すべてのターゲットエントリで CoS 属性を保護します。
間接 CoS とクラシック CoS は、ターゲットエントリの specifier 属性に依存します。この属性は、使用するテンプレートエントリの DN または RDN を指定します。ACI を使用してこの属性を保護する場合は、CoS の適用範囲全体でグローバルに保護するか、または各ターゲットエントリで必要に応じて個別に保護する必要があります。
計算された CoS 属性は、ほかの生成された CoS 属性やロールを基に定義できます。計算された CoS 属性を保護するには、これらの従属関係を理解し、保護する必要があります。
たとえば、ターゲットエントリの CoS 指定子属性が nsRole になることがあります。したがって、ロール定義も ACI によって保護する必要があります。
一般に、計算された属性値の算出に関係する属性またはエントリには、読み取りおよび書き込みアクセス制御の ACI を設定します。このため、複雑な従属関係は、十分に計画してから設定するか、以後のアクセス制御の実装の複雑さを軽減できるように簡素化する必要があります。その他の計算された属性との従属関係を最小限に抑えると、ディレクトリのパフォーマンスを向上させ、管理作業を削減することができます。
設定情報とテンプレートデータはすべてディレクトリ内にエントリとして格納されるので、LDAP コマンド行ツールを使用して 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 修飾子は次のいずれかを指定できます。
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 適用範囲内のエントリでは、その属性の「実際」の値に対して書き込み操作を行うことはできなくなります。
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 定義または複数値指示子が存在するが、merge-schemes 修飾子が存在しない場合、Directory Server は優先順位属性を使用して、計算された属性の 1 つの値を定義する 1 つのテンプレートを選択します。
cosPriority 属性は、対象となるすべてのテンプレートの中での特定のテンプレートのグローバルな優先順位を表します。優先順位 0 は、優先順位がもっとも高いことを示します。cosPriority 属性を含まないテンプレートは、もっとも優先順位が低いとみなされます。2 つ以上のテンプレートによって属性値が指定されているが、優先順位が同じまたは設定されていない場合は、任意の値が選択されます。
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 内に 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 ターゲットエントリも、検索や管理を簡単に実行できるように、同じ位置に置く必要があります。
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』を参照してください。
ディレクトリサーバーは、複数の該当する定義エントリ間で何らかの区別を付ける必要がある場合に、警告メッセージを記録します。それらの警告メッセージは次の形式になります。
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 のあいまいな状況を解決するかどうかを選択できます。