第 5 章   高度なエントリの管理


ユーザがしばしば必要とするグループを作成したり、共通の属性値を共有したりするなどディレクトリ内のデータの階層構造を超えて、エントリを管理することがあります。iPlanet Directory Server では、グループ、ロール、およびサービスクラス (CoS) を使ってエントリを管理できます。

グループとは、メンバーのリストまたはメンバーに適用するフィルタを使用して、ほかのエントリを指定するエントリです。ロールは、ロールの各メンバーに対して nsrole 属性を生成するメカニズムによって、グループと同等またはそれ以上の機能を提供します。CoS も仮想属性を生成します。これにより、エントリは、各エントリに値を格納することなく共通の属性値を共有できるようになります。

この章では、次のグループ化メカニズムとグループ化の手順について説明します。

• グループの管理

• ロールの割り当て

• サービスクラス (CoS) の定義

ロールとサービスクラスが提供する機能を活用するには、ディレクトリの導入を計画する段階で、ディレクトリのトポロジ (topology) を決定しておく必要があります。詳細は、『iPlanet Directory Server 導入ガイド』を参照してください。

グループの管理

---

グループとは、ACI の定義などのように、管理しやすくするためにエントリを相互に関連付けるメカニズムです。このメカニズムは、Directory Server の以前のバージョンでも提供されており、主に以前のバージョンのサーバとの互換性を維持するために使用されます。同等のロール定義の作成手順については、「ロールの割り当て」を参照してください。

次の節では、静的グループと動的グループの管理方法について説明します。グループの概念については、『iPlanet Directory Server 導入ガイド』を参照してください。グループの管理については、『Managing Servers with Directory Console』を参照してください。

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

静的グループを定義するエントリは、groupOfUniqueNames オブジェクトクラスから継承されます。グループのメンバーは、その DN ごとに uniqueMember 属性の複数値としてリストされます。

動的グループを定義するエントリは、groupOfUniqueNames および groupOfURLs オブジェクトクラスから継承されます。グループのメンバーは、memberURL 属性に指定されたフィルタによって定義されます。動的グループのメンバーは、評価のたびにフィルタにマッチするエントリです。

エントリエディタは、両方のタイプのグループエントリを管理します。このダイアログボックスを使用すると、グループに名前を付けたあと、メンバーのリストまたはフィルタを作成または変更できます。この節では、グループの作成と変更に関する次の手順について説明します。

• 「新しい静的グループの追加」

• 「新しい動的グループの追加」

• 「グループ定義の変更」

• 「グループ定義の削除」

新しい静的グループの追加

1. Directory Server Console で、「ディレクトリ」タブを選択します。

2. ディレクトリツリーで、新しいグループの追加先エントリをマウスの右ボタンでクリックします。「新規」の「グループ」を選択します。

   あるいは、「オブジェクト」メニューで「新規」の「グループ」を選択します。

3. 左側の区画で、「一般」をクリックします。「グループ名」フィールドに新しいグループの名前を入力します。

   グループ名は省略できません。

4. 「説明」フィールドに新しいグループの説明を入力します。

5. 左側の区画で、「メンバー」をクリックします。右側の区画で、「静的グループ」タブを選択します。「追加」をクリックして、グループに新しいメンバーを追加します。

   標準の「ユーザとグループの検索」ダイアログボックスが表示されます。

6. 「検索」ドロップダウンリストで、検索対象のエントリの種類 (ユーザ、グループ、またはその両方) を選択し、「検索」をクリックします。検索結果からエントリを 1 つ以上選択し、「OK」をクリックします。

   
   

   ---

   注	静的グループのメンバーは、連鎖によってリモートに存在する可能性があります。参照整合性プラグインを使用すると、削除されたメンバーのエントリを静的グループのエントリから自動的に削除できます。連鎖と参照整合性を併用する方法については、「連鎖ポリシーの構成」を参照してください。

   ---

   
   

7. 左側の区画で「言語」をクリックし、グループが使用する言語に特有の情報を追加します。

8. 「OK」をクリックすると、新しいグループが作成されます。グループは、そのグループを作成した位置の子の 1 つとして表示されます。

新しい動的グループの追加

1. 「新しい静的グループの追加」の手順 1 〜 4 を実行します。

2. 左側の区画で、「メンバー」をクリックします。右側の区画で、「動的グループ」タブを選択します。「追加」をクリックして、データベースを照会するための LDAP URL を作成します。

   標準の「LDAP URL の構築とテスト」ダイアログボックスが表示されます。

3. テキストフィールドに LDAP URL を入力するか、または「構築」を選択し、ガイドに従って、グループに適用するフィルタを含む LDAP URL を作成します。URL の構築が完了したら「OK」をクリックします。

4. 左側の区画で「言語」をクリックし、グループが使用する言語に特有の情報を追加します。

5. 「OK」をクリックすると、新しいグループが作成されます。

   新しいグループがディレクトリツリーに表示されます。

グループ定義の変更

1. Directory Server Console で、「ディレクトリ」タブを選択します。

2. ディレクトリツリーで、変更するグループを表すエントリをダブルクリックするか、または「オブジェクト」メニューの「開く」を選択します。

   グループ定義エントリの「エントリの編集」ダイアログボックスが表示されます。

3. 「一般」、「メンバー」、「言語」の各カテゴリのグループ情報を変更します。「OK」をクリックします。

   変更を確認するには、「表示」メニューの「再読み込み」を選択します。

グループ定義の削除

いずれかのタイプのグループを削除するには、そのグループを定義するエントリを削除します。

ロールの割り当て

---

ロールは、アプリケーションからより効率的で簡単に使用できる新しいグループ化メカニズムです。ロールは、グループと同じように定義および管理されますが、それに加えて、メンバーエントリにも、所属するロールを示す属性が生成されます。たとえば、アプリケーションでは、グループを選択してメンバーリストを参照しなくても、エントリ (entry) のロールを読み取るだけで済みます。

この節では、次の事項について説明します。

• 「ロールについて」

• 「ロールの制限事項」

• 「Console を使用したロールの管理」

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

• 「ロールの安全な使い方」

ロールについて

各ロールはメンバー、またはそのロールを所有するエントリを持ちます。グループと同じようにロールのメンバーを明示的または動的に指定できます。ロールメカニズムは、エントリが所属するすべてのロール定義の DN を含む、nsRole 属性を自動的に生成します。

ロールのメンバーの指定方法は、使用するロールのタイプによって異なります。iPlanet Directory Server では、次の 3 種類のロールをサポートしています。

• 管理されているロール : 明示的にメンバーエントリにロールを割り当てる

• フィルタを適用したロール : 指定した LDAP フィルタにマッチするエントリを割り当てる。これにより、各エントリに含まれている属性に応じてロールが異なる

• 入れ子状のロール : 別のロールを含むロールを作成できる

管理されているロールを使用すると、管理者は、対象となるエントリに nsRoleDN 属性を追加することにより、特定のロールを割り当てることができます。この属性の値は、ロール定義エントリの DN です。管理されているロールは、メンバーがロール定義エントリではなく各エントリに定義されていることを除いて、静的グループと同じです。

フィルタを適用したロールは、動的グループと同じです。このロールでは、nsRoleFilter 属性にフィルタ文字列を定義します。ただし、フィルタを適用したロールの適用範囲は、定義エントリの親をルートとする、ロールが位置するサブツリーです。サーバが、フィルタ文字列にマッチする、フィルタを適用したロールの適用範囲内のエントリを返す場合、そのエントリには常にロールを識別する nsRole 属性が含まれています。

nsRole 属性は、算出される属性であるためエントリ自体には格納されませんが、処理結果は通常の属性としてクライアントアプリケーションに返されます。ロールを使って処理を実行すると、グループを使う場合よりもサーバ側でより多くの資源が消費されます。これは、クライアントアプリケーションのためにサーバがその処理を実行するためです。ただし、ロールのメンバーの検査方法は一貫しており、サーバ側で透過的に実行されます。

---

注	1. ロールメカニズムで使用されるのは、nsRole 属性だけで、この属性はすべての変更操作から保護されています。ただし、読み取りは可能です。読み取ることができないようにアクセス制御を定義することもできます。 2. 検索フィルタでは、nsRole 属性を使用できません。アプリケーションが nsRole 属性を読み取るようにするには、まず別のフィルタを使用して検索を実行し、次に検索処理が返したエントリの nsRole 属性の値を読み取ります。

---

ディレクトリでのロールの使用方法については、『iPlanet Directory Server 導入ガイド』を参照してください。

ロールの制限事項

ディレクトリサービスをサポートするロールを作成する場合は、次の制限事項を考慮する必要があります。

ロールと連鎖 : 連鎖機能を使用してディレクトリツリーを複数のサーバに分散している場合は、ロールを定義するエントリをそれらのロールを所有するエントリと同じサーバに配置する必要があります。連鎖を介して、サーバ A が別のサーバ B からエントリを受け取る場合は、それらのエントリにはサーバ B で定義されたロールが含まれますが、サーバ A で定義されたロールは割り当てられません。

フィルタを適用したロールでは、CoS によって生成された属性を使用できない : フィルタを適用したロールでは、CoS 仮想属性の値に基づいたフィルタ文字列を使用できません (「CoS について」を参照)。ただし、CoS 定義の指示子属性は、ロール定義によって生成された nsRole 属性を参照できます (「ロールに基づく属性の作成」を参照)。

Console を使用したロールの管理

ここでは、ロールの作成と変更に関する次の手順について説明します。

• 「管理されているロールの作成」

• 「フィルタを適用したロールの作成」

• 「入れ子状のロールの作成」

• 「エントリのロールの表示と編集」

• 「ロールのエントリの変更」

• 「ロールの無効化」

• 「ロールの再有効化」

• 「ロールの削除」

ロールを作成するときに、ユーザが本人をロールへ追加したり削除したりする権限を付与するかどうかを決めておく必要があります。ロールとアクセス制御については、「ロールの安全な使い方」を参照してください。

管理されているロールの作成

管理されているロールを使用して、メンバーを明示的に列挙するリストを作成できます。管理されているロールは、nsRoleDN 属性をそのエントリに追加することによってエントリに追加されます。

管理されているロールを作成してメンバーを追加するには、次の手順を実行します。

1. Directory Server Console で「ディレクトリ」タブを選択します。

2. ディレクトリツリーから新しいロールの親エントリを選択します。

3. 「オブジェクト」メニューで「新規」の「ロール」を選択します。あるいは、エントリをマウスの右ボタンでクリックして、「新規」の「ロール」を選択することもできます。

   「新規ロールの作成」ダイアログボックスが表示されます。

4. 左側の区画で、「一般」をクリックします。「ロール名」フィールドに新しいロールの名前を入力します。

   ロール名は省略できません。

5. 「説明」フィールドに新しいロールの説明を入力します。

6. 左側の区画で、「メンバー」をクリックします。

7. 右側の区画で、「管理されているロール」を選択します。「追加」をクリックして、メンバーリストに新しいエントリを追加します。

   標準の「ユーザとグループの検索」ダイアログボックスが表示されます。

8. 「検索」ドロップダウンリストから「ユーザ」を選択し、「検索」をクリックします。表示された検索結果からいずれかのエントリを選択し、「OK」をクリックします。

9. ロールへのエントリの追加が完了したら、「OK」をクリックします。

   ディレクトリに新しいロールと管理されているロールのアイコンが表示されます。

フィルタを適用したロールの作成

各エントリに含まれる特定の属性に基づいて、フィルタを適用したロールにエントリを割り当てます。この操作を行うには、LDAP フィルタを指定する必要があります。フィルタにマッチするエントリは、そのロールを所有すると言われます。

フィルタを適用したロールを作成してメンバーを追加するには、次の手順を実行します。

1. 「管理されているロールの作成」の手順 1 〜 5 を実行します。

2. 左側の区画で、「メンバー」をクリックします。

3. 右側の区画で、「フィルタが適用されているロール」を選択します。

4. テキストフィールドに LDAP フィルタを入力するか、または「構築」をクリックし、ガイドに従って LDAP フィルタを作成します。

5. 「構築」をクリックすると、標準の LDAP URL 構築ダイアログボックスが表示されます。「LDAP サーバホスト」、「ポート」、「ベース DN」、および「検索」の各フィールドは無視します (フィルタを適用したロール定義の検索範囲を指定することができないため)。
   1. 「適用先」ドロップダウンリストから、フィルタを適用するエントリのタイプを選択します。

      ユーザ、グループ、またはその両方から選択できます。

   2. 「属性」ドロップダウンリストから属性を選択します。この次の 2 つのフィールドを使用して、修飾子をドロップダウンリストから選択して、検索を詳しく定義し (含む、含まない、同一、同一でないなど)、テキストボックスに属性値を入力します。フィルタを追加するには、「フィルタの追加」をクリックします。不要なフィルタを削除するには、「フィルタの削除」をクリックします。

   3. 「OK」をクリックして、フィルタを保存します。

6. 「テスト」をクリックして、フィルタをテストします。

   「フィルタテスト結果」ダイアログボックスに、フィルタにマッチするエントリが表示されます。

7. 「OK」をクリックします。

   ディレクトリに新しいロールとフィルタを適用したロールのアイコンが表示されます。

入れ子状のロールの作成

入れ子状のロールを使用して、別のロールを含むロールを作成できます。入れ子状のロールを作成する前に、別のロールを作成しておく必要があります。入れ子状のロールを作成する場合は、入れ子にできるロールのリストが表示されます。入れ子状のロール内に含めるロールを指定するには、nsRoleDN 属性を使用します。

入れ子状のロールを作成してメンバーを追加するには、次の手順を実行します。

1. 「管理されているロールの作成」の手順 1 〜 5 を実行します。

2. 左側の区画で、「メンバー」をクリックします。

3. 右側の区画で、「入れ子状態になっているロール」を選択します。

4. 「追加」をクリックして、ロールをリストに追加します。入れ子状のロールのメンバーは、ほかの既存のロールのメンバーです。

   「ロールセレクタ」ダイアログボックスが表示されます。

5. 「使用可能なロール」のリストからロールを選択し、「OK」をクリックします。

6. 「OK」をクリックします。

   ディレクトリに新しいロールと入れ子状のロールのアイコンが表示されます。

エントリのロールの表示と編集

1. Directory Server Console で、「ディレクトリ」タブを選択します。

2. ディレクトリツリーを参照し、ロールを表示または編集するエントリを選択します。「オブジェクト」メニューの「ロールの設定」を選択します。

   「ロール」ダイアログボックスが表示されます。

3. 「管理されているロール」タブを選択すると、このエントリが所属する管理されているロールが表示されます。

4. 新しい管理されているロールを追加するには、「追加」をクリックし、「ロールセレクタ」ウィンドウから使用可能なロールを選択します。「OK」をクリックします。

   管理されているロールを削除するには、削除するロールを選択し、「削除」をクリックします。

   エントリに関連付けられた管理されているロールを編集するには、「編集」をクリックします。「エントリの編集」ダイアログボックスが表示されます。一般情報やメンバーを変更し、「OK」をクリックします。

5. 「その他のロール」タブを選択すると、このエントリが所属する、フィルタを適用したロールや入れ子状のロールが表示されます。

6. 「編集」をクリックすると、エントリに関連付けられた、フィルタを適用したロールや入れ子状のロールを変更できます。「OK」をクリックして、変更を保存します。

7. ロールの変更が完了したら、「OK」をクリックして、変更を保存します。

ロールのエントリの変更

1. Directory Server Console で「ディレクトリ」タブを選択します。

2. ナビゲーションツリーを参照して、既存のロールの定義エントリを検索します。ロールは、そのロールを作成した位置の子エントリになります。ロールをダブルクリックします。

   「エントリの編集」ダイアログボックスが表示されます。

3. ロールの名前と説明を変更するには、左側の区画で「一般」をクリックします。

4. 管理されているロールと入れ子状のロールのメンバーを変更するか、またはフィルタを適用したロールのフィルタを変更する場合は、左側の区画で「メンバー」をクリックします。

5. 「OK」をクリックして、変更を保存します。

ロールの無効化

特定のロールを無効にすることによって、そのロールに所属するメンバーを一時的に無効にすることができます。ロールを無効にすると、そのロールに所属するエントリは無効になりますが、ロール自体は無効になりません。ロールメンバーのエントリがディレクトリユーザを表す場合は、ロールによってエントリが無効になっている間、エントリはディレクトリにアクセスできません。

ロールのメンバーを一時的に無効にするには、次の手順を実行します。

1. Directory Server Console で、「ディレクトリ」タブを選択します。

2. ナビゲーションツリーを参照して、ロールの定義エントリを検索します。ロールは、そのロールを作成した位置の子エントリになります。

3. ロールを選択します。「オブジェクト」メニューの「無効」を選択します。

   あるいは、ロールをマウスの右ボタンでクリックして、メニューから「無効」を選択することもできます。

   ロールが無効になります。

   無効になっているエントリを表示するには、「表示」メニューの「アクティブでない状態」を選択します。ロールメンバーのアイコンの赤い横棒は、そのロールが無効になっていることを示します。

ロールの再有効化

1. Directory Server Console で、「ディレクトリ」タブを選択します。

2. ナビゲーションツリーを参照して、ロールの定義エントリを検出します。ロールは、そのロールを作成した位置の子エントリになります。

3. ロールを選択します。「オブジェクト」メニューの「有効」を選択します。

   あるいは、ロールをマウスの右ボタンでクリックして、メニューから「有効」を選択することもできます。

   ロールが再び有効になります。

   無効になっているエントリを表示するには、「表示」メニューの「アクティブでない状態」を選択します。ロールが正常に表示され、そのロールが有効になっていることを示します。

ロールの削除

ロールを削除すると、ロール定義のエントリだけが削除されます。ロールのメンバーが削除されることはありません。

ロールを削除するには、次の手順を実行します。

1. Directory Server Console で、「ディレクトリ」タブを選択します。

2. ナビゲーションツリーを参照して、ロールの定義エントリを検出します。ロールは、そのロールを作成した位置の子エントリになります。

3. ロールをマウスの右ボタンでクリックし、「削除」を選択します。

   削除の確認を求めるダイアログボックスが表示されます。「はい」をクリックします。

4. ロールが正しく削除されたことを通知する「削除されたエントリ」ダイアログボックスが表示されます。「OK」をクリックします。

   
   

   ---

   注	ロールを削除すると、ロールエントリは削除されますが、各ロールメンバーの nsRoleDN 属性は削除されません。この属性を削除するには、参照整合性プラグインを有効にし、nsRoleDN 属性を設定します。詳細は、「参照整合性の管理」を参照してください。

   ---

   
   

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

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

• 管理されているロールのメンバーのエントリに、nsRoleDN 属性を含める

• フィルタを適用したロールのメンバーは、nsRoleFilter 属性で指定したフィルタにマッチするエントリとなる

• 入れ子状のロールのメンバーは、入れ子状のロール定義エントリの nsRoleDN 属性で指定したロールのメンバーとなる

すべてのロール定義は、LDAPsubentry および nsRoleDefinition オブジェクトクラスから継承されます。次の表に、各ロールタイプに固有のその他のオブジェクトクラスと関連付けられた属性を示します。

ロールタイプ	オブジェクトクラス	属性
管理されているロール	nsSimpleRoleDefinition nsManagedRoleDefinition	Description (省略可能)
フィルタを適用したロール	nsComplexRoleDefinition nsFilteredRoleDefinition	nsRoleFilter Description (省略可能)
入れ子状のロール	nsComplexRoleDefinition nsNestedRoleDefinition	nsRoleDN Description (省略可能)

---

注	場合によっては、ACI を使用して、nsRoleDN 属性の値を保護する必要があります。これは、この属性が書き込み可能であるためです。セキュリティとロールについては、「ロールの安全な使い方」を参照してください。

---

管理されているロール定義の例

すべてのマーケティングスタッフに割り当てるロールを作成するには、次の ldapmodify コマンドを実行します。

ldapmodify -a -D "cn=Directory Manager" -w secret -h host -p 389
dn: cn=Marketing,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass:nsRoleDefinition
objectclass:nsSimpleRoleDefinition
objectclass:nsManagedRoleDefinition
cn: Marketing
description: managed role for marketing staff

nsManagedRoleDefinition オブジェクトクラスは、LDAPsubentry、nsRoleDefinition、および nsSimpleRoleDefinition の各オブジェクトクラスから継承されることに注意してください。

次のように ldapmodify コマンドを実行して、Bob のエントリを更新することによって、Bob というマーケティングスタッフメンバーにロールを割り当てます。

ldapmodify -D "cn=Directory Manager" -w secret -h host -p 389
dn: cn=Bob,ou=people,dc=siroe,dc=com
changetype: modify
add:nsRoleDN
nsRoleDN: cn=Marketing,ou=people,dc=siroe,dc=com

エントリ内の nsRoleDN 属性は、そのエントリが管理されているロールのメンバーであることを示します。これは、次のロール定義の DN で判別されます。cn=Marketing,ou=people,dc=siroe,dc=com

フィルタを適用したロール定義の例

セールスマネージャ用にフィルタを適用したロールを設定するには、次の ldapmodify コマンドを実行します。

ldapmodify -a -D "cn=Directory Manager" -w secret -h host -p 389
dn: cn=SalesManagerFilter,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass:nsRoleDefinition
objectclass:nsComplexRoleDefinition
objectclass:nsFilteredRoleDefinition
cn: SalesManagerFilter
nsRoleFilter: o=sales managers
Description: filtered role for sales managers

nsFilteredRoleDefinition オブジェクトクラスは、LDAPsubentry、nsRoleDefinition、および nsComplexRoleDefinition の各オブジェクトクラスから継承されることに注意してください。nsRoleFilter 属性は、sales managers という値を持つ o (組織) 属性がある同一サブツリー内のすべてのエントリがロールのメンバーになることを示します。

入れ子状のロール定義の例

前述の例で作成したロールに含まれるマーケティングスタッフとセールスマネージャの両方を含むロールを作成するには、次の ldapmodify コマンドを使用します。

ldapmodify -a -D "cn=Directory Manager" -w secret -h host -p 389
dn: cn=MarketingSales,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass:nsRoleDefinition
objectclass:nsComplexRoleDefinition
objectclass:nsNestedRoleDefinition
cn: MarketingSales
nsRoleDN: cn=SalesManagerFilter,ou=people,dc=siroe,dc=com
nsRoleDN: cn=Marketing,ou=people,dc=siroe,dc=com

nsNestedRoleDefinition オブジェクトクラスは、LDAPsubentry、nsRoleDefinition、および nsComplexRoleDefinition の各オブジェクトクラスから継承されることに注意してください。nsRoleDN 属性は、マーケティングの管理されているロールの DN とセールスマネージャのフィルタを適用したロールの DN を含みます。

前述の例のユーザ Bob と Pat は、どちらもこの新しい入れ子状のロールのメンバーになります。

ロールの安全な使い方

セキュリティの状況によっては、ロールの使用が適していない場合があります。新しいロールを作成するときは、エントリへのロールの割り当てやエントリからのロールの削除がどの程度簡単にできるかを考慮します。ロールへのユーザの追加やロールから削除をユーザ自身が簡単に実行できることが望ましい場合もあります。たとえば、Mountain Biking という名前の同好会のロールがある場合は、興味のあるユーザが自身を簡単に追加または削除できるようにする必要があります。

ただし、セキュリティの状況によっては、このようなオープンなロールが適していない場合があります。たとえば、アカウントの無効化に関するロールがあるとします。デフォルトでは、アカウントの無効化に関するロールには、その接尾辞に対して定義された ACI が含まれています。アカウントの無効化については、「ユーザとロールの無効化」を参照してください。サーバ管理者は、ロールを作成するときに、ロールへのユーザの追加やロールからの削除をユーザ自身が実行できるようにするかどうかを決めます。

たとえば、ユーザ A が、管理されているロール MR を持っているとします。さらに、MR ロールが、コマンド行からアカウントの無効化を使用してロックされたとします。つまり、ユーザ A の nsAccountLock 属性は「true」として計算されるので、ユーザ A はサーバにバインドできません。ただし、ユーザがバインド済みで、MR ロールに関して現在ロックされているという通知を受けたとします。ユーザの行為を禁止する ACI がない場合は、ユーザは、自分のエントリから nsRoleDN 属性を削除し、自分でロックを解除できます。

ユーザが nsRoleDN 属性を削除できないようにするには、使用中のロールのタイプに応じて、次の ACI を使用します。

管理されているロール : 管理されているロールのメンバーになっているエントリの場合は、次の ACI を使用し、該当する nsRoleDN を削除することによってユーザが自分でロック解除できないようにします。

aci： (targetattr="nsRoleDN")
     (targattrfilters="
 add=nsRoleDN:(!(nsRoleDN=cn=AdministratorRole,dc=siroe,dc=com)),
 del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=siroe,dc=com)
     ")
     (version3.0;aci "allow mod of nsRoleDN by self
        except for critical values";
        allow(write)
         userdn="ldap:///self";)

フィルタを適用したロール : フィルタの一部になっている属性を保護することで、ユーザが属性を変更してフィルタを適用したロールを放棄できないようにします。フィルタを適用したロールで使用する属性をユーザが追加、削除、および変更できないようにする必要があります。フィルタ属性の値が計算される場合は、フィルタ属性値を変更する可能性のあるすべての属性を同様に保護する必要があります。

入れ子状のロール : 入れ子状のロールは、フィルタを適用したロールと管理されているロールで構成されます。したがって、入れ子状のロールを構成する各ロールについて、前述のすべての注意点を考慮する必要があります。

サービスクラス (CoS) の定義

---

サービスクラス (CoS) メカニズムを使用すると、エントリに格納されない仮想属性を作成できます。属性値は、エントリがクライアントアプリケーションに送信される時に、CoS メカニズムによって生成されます。CoS を使用すると、エントリの管理が簡素化され、格納領域の必要量が減少します。

グループやロールと同じように、CoS はディレクトリのヘルパーエントリに依存し、Console またはコマンド行を使用して構成できます。次の節では、CoS について詳しく説明し、Console およびコマンド行を使用して CoS を管理するための手順について説明します。

• 「CoS について」

• 「CoS の制限事項」

• 「Console を使用した CoS の管理」

• 「コマンド行からの CoS の管理」

• 「ロールに基づく属性の作成」

• 「CoS のセキュリティ保護」

CoS について

CoS は、仮想属性とその値を CoS の適用範囲内のあらゆるエントリであるターゲットエントリすべてに定義します。各 CoS は、ディレクトリ内の次のエントリから構成されています。

• CoS 定義のエントリ : 使用中の CoS のタイプおよび生成される CoS 属性の名前を特定する。このエントリは、ロール定義のエントリと同様に、LDAPsubentry オブジェクトクラスから継承される。CoS の適用範囲は、CoS 定義のエントリの親の下のサブツリー全体である。同じ CoS 属性に複数の定義が存在する場合は、複数の値が含まれることがある

• テンプレートエントリ : 1 つ以上の仮想属性の値が含まれる。CoS の適用範囲内のすべてのエントリに、ここで定義された値が使用される。複数のテンプレートエントリがある場合は、生成された属性も複数の値を持つことがある

CoS には次の 3 つのタイプがあり、それぞれが CoS 定義のエントリとテンプレートエントリ間の様々な相互作用に対応しています。

• ポインタ CoS : CoS 定義のエントリは、テンプレート DN を使用してテンプレートエントリを直接識別する。すべてのターゲットエントリに、テンプレートで指定されているものと同じ CoS 属性値が設定される

• 間接 CoS : CoS 定義は、間接的な指示子と呼ばれる属性を識別する。ターゲットエントリのこの属性の値によって、そのエントリで使用されるテンプレートが決まる。ターゲットエントリのこの属性には、DN が含まれている。間接 CoS を使うと、各ターゲットエントリで異なるテンプレートを使用できるため、CoS 属性に異なる値を指定できる

• クラシック CoS : CoS 定義は、テンプレートのベース DN と指示子 (ターゲットエントリの属性名) を識別する。CoS 値を含むテンプレートは、ターゲットの指示子属性の RDN (relative domain name) 値とテンプレートのベース DN (base DN) を組み合わせることにより決まる

  
  

  ---

  注	サーバでは、CoS 仮想属性を参照するフィルタを含む LDAP 検索要求はサポートされません。LDAP 検索フィルタでは、エントリに格納されている実際の属性だけがサポートされます。この属性には、CoS 属性や nsRole 属性は含まれません。CoS 定義を使用して生成する属性を決定するときは、十分に注意してください。 仮想属性の値に基づいてエントリを検索するには、ディレクトリクライアントでエントリのスーパーセット (分岐全体など) を取得し、それらを並べ替えて希望するエントリを選択する必要があります。

  ---

  
  

次の節では、CoS 定義のエントリとテンプレートエントリについてさらに詳しく説明し、CoS のタイプごとに例を示します。

CoS 定義のエントリとテンプレートエントリ

CoS 定義のエントリは、cosSuperDefinition オブジェクトクラスのインスタンスです。CoS 定義のエントリは、CoS のタイプを指定する、次のオブジェクトクラスのいずれかから継承されます。

• cosPointerDefinition

• cosIndirectDefinition

• cosClassicDefinition

CoS 定義のエントリには、必要に応じて、仮想 CoS 属性、テンプレート DN、およびターゲットエントリの指示子属性を指定できるように、CoS のそれぞれのタイプに固有の属性が含まれています。デフォルトでは、CoS メカニズムは、CoS 属性と同じ名前を持つ既存の属性の値を上書きしません。ただし、CoS 定義エントリ (CoS definition entry) の構文を使用すると、この処理を制御できます。

CoS テンプレートエントリは、cosTemplate オブジェクトクラスのインスタンスです。CoS テンプレートエントリ (CoS template entry) には、CoS メカニズムによって生成された 1 つ以上の値があります。特定の CoS 用のテンプレートエントリは、その CoS 定義と同じレベルのディレクトリツリー内に格納されます。

管理を容易にするため、可能なかぎり、定義エントリ、テンプレート、およびテンプレートエントリを同じ場所に置いてください。また、それらが提供する機能を説明するような名前を付けてください。たとえば、定義エントリ DN に "cn=classicCosGenerateEmployeeType,ou=People,dc=siroe,dc=com" などの名前を付けると、"cn=ClassicCos1,ou=People,dc=siroe,dc=com" よりもわかりやすくなります。

各 CoS タイプに関連するオブジェクトクラスと属性については、「コマンド行からの CoS の管理」を参照してください。

ポインタ CoS の例

この例では、dc=siroe,dc=com の下に格納されるすべてのエントリに共通の郵便番号を定義する CoS を示します。この例の 3 つのエントリを次の図に示します。

図 5-1    ポインタ CoS 定義とテンプレートの例

テンプレートエントリ (template entry) は、CoS 定義エントリ (CoS definition entry) 内でテンプレートエントリの DN、cn=siroeUS,cn=data によって識別されます。エントリ dc=siroe,dc=com で postalCode 属性が照会されるたびに、Directory Server は、テンプレートエントリ cn=siroeUS,cn=data 内の使用可能な値を返します。したがって、郵便コードは、エントリ uid=wholiday,ou=people,dc=siroe,dc=com と一緒に表示されますが、このエントリには格納されません。このメカニズムでは、CoS によっていくつかの共有属性が生成されるため、数千または数百万ものエントリのために記憶容量を大幅に節約できます。

間接 CoS の例

この間接 CoS (indirect CoS) の例では、ターゲットエントリ (target entry) の manager 属性を使用してテンプレートエントリ (template entry) を識別します。CoS メカニズムでは、この方法を使って、すべての従業員に対してマネージャと同じ部署番号を生成することにより、常に最新の状態を維持できます。この例の 3 つのエントリを次の図に示します。

図 5-2    間接 CoS 定義とテンプレートの例

間接 CoS 定義のエントリは、指示子属性の名前を指定します。この例では、manager 属性です。William Holiday のエントリは、この CoS のターゲット エントリの 1 つであり、その manager 属性には、cn=Carla Fuentes,ou=people,dc=siroe,dc=com の DN が含まれます。したがって、Carla Fuentes のエントリは、departmentNumber 属性値 318842 を提供するテンプレートです。

間接指示子を使用することにより、間接 CoS はディレクトリ内のエントリをテンプレートとして使用できます。セキュリティおよび性能上の理由から、このタイプの CoS は注意深く使用してください。多くの場合、クラシック CoS 使用してターゲットエントリの位置を制限するか、柔軟性の低いポインタ CoS メカニズムを使用することにより、同じ結果を得ることができます。

クラシック CoS の例

クラシック CoS メカニズムでは、定義エントリで指定されたベース DN とターゲットエントリの指示子からテンプレートの DN が決まります。指示子属性の値は、テンプレート DN の cn 値として使用されます。したがって、クラシック CoS のテンプレート DN は、次のような構造になります。

cn=specifierValue,baseDN

次の図の例は、郵便番号の値を生成するクラシック CoS (classic CoS) 定義を示しています。

図 5-3    クラシック CoS 定義とテンプレートの例

この例では、CoS 定義エントリの cosSpecifier 属性が、employeeType 属性を指定します。この属性とテンプレート DN を組み合わせると、cn=sales,cn=siroeUS,cn=data としてテンプレートエントリ (template entry) を識別できます。このテンプレートエントリは、postalCode 属性の値をターゲットエントリに与えます。

CoS の制限事項

CoS 機能は、複雑なメカニズムであり、性能およびセキュリティ上の理由から次の制限事項が適用されます。

サブツリーの制限 : cn=config または cn=schema サブツリーでは、CoS 定義を作成できません。したがって、これらのエントリには仮想属性を含めることができません。

属性タイプの制限 : 次の属性タイプは、同じ名前の実際の属性と動作が異なるため、CoS メカニズムでは生成できません。

• userPassword : CoS で生成されたパスワード値は、Directory Server へのバインドに使用できない

• aci : Directory Server では、CoS によって定義された仮想 ACI 値の内容に基づいてアクセス制御を適用しない

• objectclass : Directory Server では、CoS によって定義された仮想オブジェクトクラスの値を検査するスキーマが実行されない

• nsRoleDN : CoS によって生成された nsRoleDN 値は、サーバによるロールの生成に使用されない

すべてのテンプレートをローカルに配置する必要がある : CoS 定義またはターゲットエントリの指示子に指定されているテンプレートエントリの DN は、Directory Server のローカルエントリを参照する必要があります。テンプレートとそこに含まれる値は、ディレクトリ連鎖またはレフェラルからは取得できません。

CoS 仮想値と実際の値を組み合わせることはできない : CoS 属性の値では、エントリの実際の値とテンプレートの仮想値を組み合わせることはできません。CoS により実際の属性値が上書きされると、実際の値はすべてテンプレートの値に置き換えられます (「実際の属性値の上書き」を参照)。ただし、「複数の値を持つ CoS 属性」で説明しているように、CoS メカニズムでは、複数の CoS 定義の仮想値を組み合わせることができます。

フィルタを適用したロールでは、CoS によって生成された属性を使用できない : フィルタを適用したロールでは、CoS 仮想属性の値に基づくフィルタ文字列を使用できません。ただし、CoS 定義の指示子属性は、ロール定義によって生成された nsRole 属性を参照できます (「ロールに基づく属性の作成」を参照)。

ACI (Access Control Instruction) : 格納されている通常の属性へのアクセスと同様に、CoS によって生成された属性へのアクセスが制御されます。ただし、CoS によって生成された属性値に依存するアクセス制御規則は、「CoS の制限事項」で説明されている条件に従います。

CoS キャッシュ応答時間 : CoS キャッシュは、性能を向上させるためにすべての CoS データをメモリに保持する Directory Server の内部構造です。このキャッシュは、仮想属性の算出時に使用される CoS データの取得用に最適化されており、CoS 定義エントリおよびテンプレートエントリの更新中でも使用できます。したがって、定義エントリおよびテンプレートエントリを追加または変更すると、変更内容が反映されるまでわずかに時間がかかる場合があります。この遅延時間は、CoS 定義の数と複雑さ、および現在のサーバの負荷によって異なりますが、通常、数秒しかかかりません。

Console を使用した CoS の管理

ここでは、Directory Server Console を使った CoS 定義の作成および編集方法について説明します。この章は、次の節で構成されています。

• 「新しい CoS の作成」

• 「既存の CoS の編集」

• 「CoS の削除」

新しい CoS の作成

ポインタ CoS およびクラシック CoS の場合は、定義エントリの前にテンプレートエントリを作成する必要があります。

1. Directory Server Console で、「ディレクトリ」タブを選択します。

2. ディレクトリツリーから、テンプレートエントリを格納する親エントリを選択します。

3. 「オブジェクト」メニューをクリックするか、またはエントリをマウスの右ボタンでクリックし、「新規」の「その他」を選択します。次に「新規オブジェクト」ダイアログボックスのリストから「costemplate」を選択します。

   「属性エディタ」ダイアログボックスが表示され、新しいテンプレートのいくつかの属性にデフォルト値が表示されます。

4. 次の手順で新しいテンプレートオブジェクトを編集します。
   1. objectclass 属性に LDAPsubentry 値および extensibleobject 値を追加する

   2. cn 属性を追加し、この属性にテンプレートを識別する値 (例 : cosTemplateForHeadquartersFax) を指定する

   3. 命名属性を新しい cn 属性に変更する

      ほかの属性を追加して、それを命名属性として使用することもできるが、通常は cn を使用する

   4. 整数値を設定することにより cosPriority 属性を変更するか、必要がない場合は優先順位属を削除する

   5. CoS メカニズムを使ってターゲットエントリに生成する属性とその値を追加する

5. 「属性エディタ」ダイアログボックスの「OK」をクリックしてテンプレートエントリを作成します。

6. このテンプレートにポインタ CoS を定義する場合は、ディレクトリツリーで新しいテンプレートエントリを選択し、メニューから「編集」の「DN のコピー」を選択します。

定義エントリの作成手順は、すべてのタイプの CoS の作成手順と同じです。

1. ディレクトリツリーから、新しいサービスクラスを有効にする親エントリを選択します。

2. 「オブジェクト」メニューをクリックするか、またはエントリをマウスの右ボタンでクリックし、「新規」の「サービスクラス」を選択します。

   「サービスの新規クラスの作成」ダイアログボックスが表示されます。

3. 左側の区画で、「一般」を選択します。右側の区画で、「クラス名」フィールドに新しいサービスクラスの名前を入力します。CoS 定義のエントリの cn 命名属性に名前が表示されます。「説明」フィールドにクラスの説明を入力します。

4. 左側の区画で、「属性」をクリックします。右側の区画に、CoS メカニズムによりターゲットエントリに生成される属性のリストが表示されます。

   使用可能な属性のリストを表示し、属性をリストに追加するには、「追加」をクリックします。

5. リストに属性を追加すると、「サービスクラスの動作」列にドロップダウンリストが表示されます。このセルをクリックし、次の上書き動作のいずれかを選択します。
   • ターゲットエントリ属性を上書きしない : ターゲットエントリの同じ属性に対応する属性値が格納されていない場合にだけ、CoS 属性値が生成される

   • ターゲットエントリ属性を上書きする : CoS によって生成された属性値によって、ターゲットエントリ内の対応する属性値がすべて上書きされる

   • ターゲットエントリ属性を上書きし、operational な状態にする : 明示的に要求した場合を除き、クライアントアプリケーションに表示されないようにするためCoS 属性値をターゲットの値より上書きし、属性を operational にする。

     
     

     ---

     注	属性を operational にすることができるのは、その属性がスキーマ内でも operational と定義されている場合だけです。

     ---

     
     

6. 左側の区画で、「テンプレート」をクリックします。右の区画でテンプレートエントリの識別方法を選択し、対応するフィールドに必要事項を入力します。これにより定義する CoS のタイプを決定できます。
   • DN による : これを選択すると、ポインタ CoS を定義できます。「テンプレート DN」フィールドにテンプレートエントリの DN を入力します。「参照」をクリックして、ディレクトリからテンプレート DN を選択するか、または Ctrl + V キーを押して、テンプレートエントリの作成後にコピーした DN を貼り付けます。

   • ターゲットエントリの属性値の 1 つを使用する : これを選択すると、間接 CoS を定義できます。「属性名」フィールドに指示子属性の名前を入力します。DN 値を含む属性を選択してください。リストから属性を選択するには、「変更」をクリックします。

   • DN およびターゲットエントリの属性値の 1 つを使用する : これを選択すると、クラシック CoS を定義できます。テンプレートの DN と属性名の両方を入力します。「参照」をクリックして、ターゲットエントリの親エントリを選択します。次に「変更」をクリックして、リストから属性を選択します。

7. 「OK」をクリックして、CoS 定義のエントリを作成します。

既存の CoS の編集

1. Directory Server Console で、「ディレクトリ」タブを選択します。

2. ディレクトリツリーから、CoS 定義を含む親エントリを選択します。CoS エントリがこの親エントリの子として表示されます。

3. CoS をダブルクリックします。

   「エントリの編集」ダイアログボックスが表示されます。

4. CoS の名前と説明を変更するには、左側の区画で「一般」をクリックします。

5. CoS メカニズムによって生成される仮想属性を追加または削除するには、左側の区画で「属性」をクリックします。

6. テンプレートの指示子属性またはテンプレートエントリ DN の名前を再定義するには、左側の区画の「テンプレート」をクリックします。このダイアログボックスを使うと、CoS 定義のタイプを再定義できます。

7. 「OK」をクリックして、変更を保存します。

CoS の削除

1. Directory Server Console で、「ディレクトリ」タブを選択します。

2. ディレクトリツリーから、CoS 定義を含む親エントリを選択します。CoS エントリがこの親エントリの子として表示されます。

3. CoS をマウスの右ボタンでクリックし、「削除」を選択します。削除の確認を求めるダイアログボックスが表示されます。「はい」をクリックします。

4. CoS が正しく削除されたことを通知する「削除されたエントリ」ダイアログボックスが表示されます。「OK」をクリックします。

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

構成情報とテンプレートデータはすべてディレクトリ内にエントリとして格納されるので、標準的な LDAP ツールを使用して、CoS の構成と管理を行うことができます。この節では、次の事項について説明します。

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

• 「コマンド行からの CoS テンプレートエントリの作成」

• 「ポインタ CoS の例」

• 「間接 CoS の例」

• 「クラシック CoS の例」

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

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

表 5-1 CoS 定義のエントリ

CoS のタイプ	CoS 定義のエントリ
ポインタ CoS	objectclass: top objectclass: LDAPsubentry objectclass:cosSuperDefinition objectclass:cosPointerDefinition cosTemplateDN: DN_string cosAttribute: list_of_attributes qualifier
間接 CoS	objectclass: top objectclass: LDAPsubentry objectclass:cosSuperDefinition objectclass:cosIndirectDefinition cosIndirectSpecifier: attribute_name cosAttribute: list_of_attributes qualifier
クラシック CoS	objectclass: top bbjectclass: LDAPsubentry objectclass:cosSuperDefinition objectclass:cosClassicDefinition cosTemplateDn: DN_string cosSpecifier: attribute_name cosAttribute: list_of_attributes qualifier

次の属性が CoS 定義のエントリ内で使用できます (属性については、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照)。

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

属性	CoS 定義のエントリ内の目的
cosAttribute:  attribute_name override merge	値を生成する対象となる仮想属性の名前を定義する。この属性には複数の値を指定できる。それぞれの値には属性の名前が指定され、この属性値はテンプレートから生成される。特別な状況下では、修飾子により CoS 属性値の算出方法を指定する
cosIndirectSpecifier:  attribute_name	ターゲットエントリの属性名を定義する。間接 CoS は、この属性の値を使ってテンプレートエントリ (template entry) を識別する。名前が指定された属性は指示子と呼ばれ、各ターゲットエントリに完全 DN 文字列を含める必要がある。この属性には値を 1 つしか指定できないが、指示子属性には複数の値を指定して複数のテンプレートを指定できる
cosSpecifier:  attribute_name	ターゲットエントリの属性名を定義する。クラシック CoS は、この属性の値を使ってテンプレートエントリ (template entry) を識別する。名前が指定された属性は指示子と呼ばれ、ターゲットエントリの RDN になる文字列を含める必要がある。この属性には値を 1 つしか指定できないが、指示子属性には複数の値を指定して複数のテンプレートを指定できる
cosTemplateDn:  DN_string	ポインタ CoS 定義用にテンプレートエントリ (template entry) の完全 DN、またはクラシック CoS 用にテンプレートエントリ (template entry) のベース DN を指定する

cosAttribute 属性を使用すると、CoS 属性名のあとに修飾子を 2 つ付けることができます。override 修飾子では、次のいずれかの値を使用できます。

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

• override : 属性値がエントリとともに格納されている場合も含め、サーバは常に CoS によって生成された値を返す

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

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

merge 修飾子は指定しないか、または次の値を指定します。

• merge-schemes : 複数テンプレートまたは複数 CoS 定義から、仮想 CoS 属性に複数の値を指定できる。詳細は、「複数の値を持つ CoS 属性」を参照

実際の属性値の上書き
override 修飾子を含むポインタ CoS 定義のエントリの作成例を次に示します。

dn: cn=pointerCoS,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass:cosSuperDefinition
objectclass:cosPointerDefinition
cosTemplateDn:cn=siroeUS,cn=data
cosAttribute: postalCode override

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

---

注	CoS 属性に operational または override 修飾子を定義すると、その属性が通常の属性としても存在する CoS 適用範囲内のエントリでは、その属性を手動で更新できなくなります。

---

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

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

• cosAttribute に同じ属性名を持つ任意のタイプの CoS 定義のエントリが複数存在することが可能である。この場合、すべての定義に 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 テンプレートエントリに定義されます。

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

ポインタ CoS またはクラシック CoS を使用する場合、テンプレートエントリは LDAPsubentry オブジェクトクラスから継承され、cosTemplate オブジェクトクラスのインスタンスでもあります。このエントリは、特に CoS 定義用に作成する必要があります。CoS テンプレートエントリを LDAPsubentry オブジェクトクラスのインスタンスにすることで、構成エントリの影響を受けずに、通常の検索を実行できるようになります。

間接 CoS メカニズムは、ディレクトリ内の任意の既存テンプレートエントリを参照します。テンプレートエントリをあらかじめ識別したり、LDAPsubentry オブジェクトクラスを指定する必要はありません。間接 CoS テンプレートには、CoS を評価して仮想属性とその値を生成する場合にのみアクセスします。

どのような場合でも CoS テンプレートエントリには、ターゲットエントリ上の CoS によって生成された属性と値を含める必要があります。属性名は、CoS 定義のエントリの cosAttribute 属性に指定されています。

次の例は、postalCode 属性を生成するポインタ CoS の優先順位がもっとも高いテンプレートエントリを示します。

dn: cn=siroeUS,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
postalCode: 44438
cosPriority: 0

次の節では、テンプレートエントリの例と CoS 定義のエントリの各タイプの例を紹介します。

ポインタ CoS の例

dc=siroe,dc=com ツリーのすべてのエントリで共通の郵便番号を共有させるポインタ CoS (pointer CoS) を作成するには、次の ldapmodify コマンドを実行します。

ldapmodify -a -D "cn=directory manager" -w secret -h host -p 389

dn: cn=pointerCoS,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass:cosSuperDefinition
objectclass:cosPointerDefinition
cosTemplateDn: cn=siroeUS,cn=data,dc=siroe,dc=com
cosAttribute: postalCode

dn: cn=siroeUS,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
postalCode: 44438

ここで作成した CoS テンプレートエントリ cn=siroeUS,dn=cata,dc=siroe,dc=com は、dc=siroe,dc=com 接尾辞の下に置かれているすべてのエントリに対して、その postalCode 属性に格納されている値を提供します。

間接 CoS の例

ここで説明する間接 CoS (indirect CoS) は、ターゲットエントリ (target entry) の team 属性を使用して、CoS テンプレートエントリを識別するものです。新しい間接 CoS 定義のエントリを dc=siroe,dc=com 接尾辞に追加するには、次の ldapmodify コマンドを実行します。

ldapmodify -a -D "cn=directory manager" -w secret -h host -p 389

dn: cn=indirectCoS,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass:cosSuperDefinition
objectclass:cosIndirectDefinition
cosIndirectSpecifier: manager
cosAttribute: departmentNumber

さらに、マネージャ Carla Fuentes 用のテンプレートエントリを作成します。

dn:cn=Carla Fuentes,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
departmentNumber: 318842

最後に、マネージャ Sue Jacobs 用の 2 番目のテンプレートエントリを作成します。

dn:cn=Sue Jacobs,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
departmentNumber: 71776

定義エントリは、dc=siroe,dc=com の下にあるターゲットエントリを調べて、manager 属性を含むエントリを探します。これは、定義エントリの cosIndirectSpecifier 属性内にこの属性が指定されているためです。ターゲットエントリの manager 属性は、cn=Carla Fuentes,cn=data,dc=siroe,dc=com と cn=Sue Jacobs,cn=data,dc=siroe,dc=com という 2 つのテンプレートのどちらかをポイントすることができます。部門番号は、マネージャによって異なります。

クラシック CoS の例

次の例では、テンプレートの DN と cosSpecifier 属性内で指定された属性の組み合わせを使用して、自動的に郵便番号を生成するクラシック CoS (classic CoS) です。クラシック CoS 定義のエントリを作成するには、次の ldapmodify コマンドを実行します。

ldapmodify -a -D "cn=directory manager" -w secret -h host -p 389

dn: cn=classicCoS,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass:cosSuperDefinition
objectclass:cosClassicDefinition
cosTemplateDn: cn=siroeUS,cn=data,dc=siroe,dc=com
cosSpecifier: employeeType
cosAttribute: postalCode override

最後に、セールス部門とマーケティング部門用のテンプレートエントリを作成します。

dn: cn=sales,cn=siroeUS,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
postalCode: 44438

dn: cn=marketing,cn=siroeUS,cn=data,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
postalCode: 99111

ここで作成したクラシック CoS 定義のエントリは、dc=siroe,dc=com 接尾辞の下にあるすべてのエントリに適用されます。使用されるテンプレートには、エントリ内で検出された employeeType 属性と cosTemplate の DN の組み合わせに応じて、2 つのテンプレートのどちらかが指定されます。セールス部門のテンプレートは、セールス部門の社員に固有の郵便コードを提供します。マーケティング部門のテンプレートは、マーケティング部門の社員に固有の郵便コードを提供します。

ロールに基づく属性の作成

クラシック CoS スキーマとして、エントリが持つロールに基づいてエントリの属性値を生成するものも作成できます。たとえば、ロールに基づく属性 (role-based attributes) を使用して、サーバのロックをエントリごとに設定できます。

ロールに基づく属性を作成するには、クラシック CoS の CoS 定義のエントリ内で cosSpecifier として nsRole 属性を使用します。nsRole 属性には複数の値を指定できるので、複数の使用可能なテンプレートエントリを含む CoS スキーマを定義できます。使用するテンプレートエントリ (template entry) を明確に決定するには、cosPriority 属性をCoS テンプレートエントリ (CoS template entry) に追加します。

たとえば、マネージャロールのメンバーであれば、標準のメールボックス容量の割り当てを超えて使用できるようにする CoS を作成できます。次のようなマネージャロールが存在するとします。

dn: cn=ManagerRole,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass:nsRoleDefinition
objectclass:nsComplexRoleDefinition
objectclass:nsFilteredRoleDefinition
cn: ManagerRole
nsRoleFilter: o=managers
Description: filtered role for managers

次のようにクラシック CoS 定義エントリ (CoS definition entry) を指定します。

dn: cn=managerCOS,dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass:cosSuperDefinition
objectlass:cosClassicDefinition
cosTemplateDn: cn=managerCOS,dc=siroe,dc=com
cosSpecifier: nsRole
cosAttribute: mailboxquota override

cosTemplateDn 属性が提供する値と cosSpecifier 属性内に指定された属性 (例では、ターゲットエントリの nsRole 属性) を組み合わせて、CoS テンプレートエントリ (CoS template entry) が識別されます。CoS テンプレートエントリは、mailboxquota 属性値を提供します。追加で指定した override 修飾子は、CoS がターゲットエントリ内にある既存のすべての mailboxquota 属性値に上書きするように指定します。

対応する CoS テンプレートエントリは、次のように定義されます。

dn:cn="cn=ManagerRole,ou=people,dc=siroe,dc=com",cn=managerCOS,
  dc=siroe,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectlass: cosTemplate
mailboxquota: 1000000

テンプレートエントリは、mailboxquota 属性値として、1000000 を提供します。

---

注	ロール (role) エントリおよび CoS 定義のエントリは、適用範囲に同じターゲットエントリを指定できるように、ディレクトリツリーの同じ位置に置く必要があります。CoS ターゲットエントリも、検索や管理を簡単に実行できるように、同じ位置に置く必要があります。

---

CoS のセキュリティ保護

読み取り用のアクセス制御は、エントリの実際の属性と仮想属性の両方に適用されます。サービスクラスメカニズムによって生成された仮想属性は、通常の属性として読み取ることができるので、読み取り保護も同様の方法で指定します。

ただし、CoS 値をセキュリティで保護するには、定義エントリ、テンプレートエントリ、ターゲットエントリなど、使用するすべての情報のソースを保護する必要があります。これは更新処理でも同様です。情報のソースから生成された値を保護するために、各情報のソースに対する書き込みを制御する必要があります。

次の節では、各 CoS エントリのデータに読み取りおよび書き込み保護を設定する際の一般的な原則について説明します。個別の ACI (Access Control Instruction) の定義手順については、第 6 章「アクセス制御の管理」を参照してください。

CoS 定義のエントリの保護

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

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

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

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

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

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

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

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

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

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

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

その他の従属関係の保護

最後に、生成されたその他の CoS 属性およびロールに関して仮想 CoS 属性を定義することができます。仮想 CoS 属性を確実に保護するために、これらの従属関係を理解し保護する必要があります。

たとえば、ターゲットエントリの CoS 指示子属性には nsRole を指定できます。したがってロール定義も保護する必要があります。詳細は、「ロールの安全な使い方」を参照してください。

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