第 5 章 ID とロールの管理

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

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

Directory Server には、ロールと CoS 仮想属性の値に基づく検索を実行する機能があります。どの操作で使用されるフィルタ文字列にも、nsRole 属性または CoS 定義によって生成された任意の属性を含めることができ、この属性の値について任意の比較演算を実行できます。ただし、CoS 仮想属性にはインデックスを付けることができないため、CoS で生成された属性を使用する検索は、すべてインデックスを使用しない検索となります。これでは時間とメモリの両方についてリソースが大量に消費されます。

ロールとサービスクラスが提供する機能を活用するには、ディレクトリの導入を計画する段階で、ディレクトリのトポロジを決定しておく必要があります。これらのメカニズムの詳細と、それによってトポロジを単純化できるしくみについては、『Directory Server 配備計画ガイド』の第 4 章「ディレクトリ情報ツリー」を参照してください。

グループの管理

ロールの割り当て

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

グループの管理

グループを使用すると、ACI の定義などのように、エントリを相互に関連付けて管理しやすくすることができます。グループ定義は特別なエントリで、スタティックなリストにメンバーの名前を指定するか、またはダイナミックなエントリセットを定義するフィルタを指定します。

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

スタティックグループを定義するエントリは、groupOfNames または groupOfUniqueNames オブジェクトクラスから継承されます。グループのメンバーは、その DN ごとに member または uniqueMember 属性の複数値として一覧表示されます。

ダイナミックグループを定義するエントリは、groupOfURLs オブジェクトクラスから継承されます。グループのメンバーシップは、複数値属性 memberURL に指定された、1 つまたは複数のフィルタによって定義されます。フィルタが評価されたときにそのどれかに一致するエントリが、ダイナミックグループのメンバーとなります。

次の節では、コンソールを使用してスタティックグループとダイナミックグループを作成および変更する方法について説明します。

新しいスタティックグループの追加

Directory Server コンソールの最上位の「ディレクトリ」タブを選択し、ディレクトリツリーで、新しいグループの追加先エントリを右クリックします。次に、「新規」>「グループ」の順に選択します。

または、エントリを選択し、「オブジェクト」メニューから「新規」>「グループ」の順に選択します。

「新規グループの作成」ダイアログボックスで、新しいグループの名前を「グループ名」フィールドに入力します。グループの説明を「説明」フィールドに追加することもできます。このグループ名は、新しいグループエントリの cn (共通名) 属性の値になり、その DN の中に表示されます。

ダイアログボックスの左側のリストで「メンバー」をクリックします。右側のパネルでは、「スタティックグループ」タブがデフォルトで選択されています。

「追加」をクリックして、グループに新しいメンバーを追加します。標準の「ユーザーとグループの検索」ダイアログボックスが表示されます。

「検索」ドロップダウンリストから「ユーザー」を選択し、検索する文字列を入力してから、「検索」をクリックします。特定の属性や属性値を検索するには、「詳細」ボタンをクリックします。

検索結果からエントリを 1 つ以上選択し、「了解」をクリックします。この手順を繰り返して、このスタティックグループに必要なメンバーをすべて追加します。



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

左側のリストで「言語」をクリックし、グループの名前と説明を別の言語で指定します。これらは、その言語に対応するロケールがコンソールで使用される場合に表示されます。

「了解」をクリックすると、新しいグループが作成されます。グループは、そのグループが作成された場所であるエントリの子の 1 つとして表示されます。

新しいダイナミックグループの追加

または、エントリを選択し、「オブジェクト」メニューから「新規」>「グループ」の順に選択します。

ダイアログボックスの左側のリストで「メンバー」をクリックし、右側のパネルで「ダイナミックグループ」タブを選択します。

「追加」をクリックして、グループのメンバーを定義するフィルタ文字列を含んだ LDAP URL を作成します。標準の「LDAP URL の構成とテスト」ダイアログボックスが表示されます。

テキストフィールドに LDAP URL を入力するか、または「構成」を選択し、指示に従って、グループに適用するフィルタを含む LDAP URL を作成します。「テスト」をクリックして、このフィルタで取得されるエントリのリストを表示します。

URL の作成が完了したら、「了解」をクリックします。この手順を繰り返して、ダイナミックグループを定義するフィルタを含んだ URL をすべて追加します。

グループ定義の変更

Directory Server コンソールの最上位の「ディレクトリ」タブで、変更するグループを表すエントリをダブルクリックします。

または、エントリを選択し、「オブジェクト」メニューの「開く」を選択します。

「エントリの編集」ダイアログボックスで、「一般」、「メンバー」、「言語」の各カテゴリのグループ情報を変更します。スタティックグループの場合はメンバーの追加と削除、ダイナミックグループの場合はフィルタを含んだ URL の追加、編集、削除を行うことができます。

グループ定義の変更が完了したら、「了解」をクリックします。

変更内容をコンソールで確認するには、「表示」メニューの「再表示」を選択します。

グループ定義の削除

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

ロールの割り当て

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

デフォルトでは、ロールの適用範囲は、それが定義されているサブツリーに限定されます。Directory Server 5.2 では、入れ子のロールの適用範囲が拡張されたため、ほかのサブツリーにあるロールも入れ子にでき、ディレクトリ内の任意の位置にメンバーを置くことができます。ロールの適用範囲の拡張については、「入れ子のロール定義の例」を参照してください。

ロールについて

各ロールはメンバー (そのロールを所有するエントリ) を持ちます。ディレクトリからエントリが取得されるとき、ロールメカニズムによって自動的に、なんらかのロールに所属するすべてのエントリに nsRole 属性が生成されます。この複数値属性には、そのエントリをメンバーとして持つすべてのロール定義の DN が値として設定されます。nsRole 属性は、算出される属性であるためエントリ自体には格納されませんが、処理結果は通常の属性としてクライアントアプリケーションに返されます。

Directory Server は、次の 3 種類のロールをサポートしています。

管理されているロール : 管理者は、対象となるメンバーエントリに nsRoleDN 属性を追加することにより、管理されているロールを割り当てることができます。この属性の値は、ロール定義エントリの DN です。管理されているロールは、メンバーがロール定義エントリではなく各エントリに定義されていることを除いて、スタティックグループと似ています。

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

入れ子のロール : ほかの入れ子のロールも含め、ほかのロール定義を指定して使用するロールです。入れ子のロールに含まれているロールのすべてのメンバーが、入れ子のロールのメンバーとなります。入れ子のロールでは、その適用範囲を拡張して、ほかのサブツリーにあるロールのメンバーを含めることもできます。

ロールを使用すると、nsRole 属性の内容を直接読み取ることで、エントリのすべてのロールメンバーシップをクライアントアプリケーションが判別できます。これにより、クライアントの処理が簡素化され、ディレクトリの使用が最適化されます。ロールと CoS メカニズムを組み合わせて、ロールメンバーの他の属性を生成することもできます (「ロールに基づく属性の作成」を参照)。ロールは、アクセス制御の定義にも使用できます (「ロールアクセスの定義 : roledn キーワード」を参照)。またロールには、そのロールのすべてのメンバーを一度に有効化または無効化する機能も用意されています (「ユーザーとロールの無効化と有効化」を参照)。

nsRole 属性の検索

Directory Server では、任意の検索フィルタで nsRole 属性を使用できます。任意の比較演算子を使用して、この属性の特定の値を検索できます。nsRole 属性を検索する場合は、次の事項に注意してください。

nsRole 属性を使用する検索では、エントリにフィルタを適用する前にすべてのロールを評価する必要があるため、所要時間がかなり長くなります。

Directory Server は、特に管理されているロールのメンバーシップの等価検索用に最適化されています。たとえば、次の検索は、実際の属性に対する検索とほぼ同じ速さで実行されます。

管理されているロールのメンバーシップを定義する nsRoleDN 属性には、デフォルトではすべてのサフィックスでインデックスが付けられます。Directory Server は管理されているロールのメンバーシップの検索用に最適化されていますが、この属性のインデックス付けが無効になっていると、その効果は失われます。

フィルタが適用されたロールを含むエントリの検索には、ロールフィルタを使用した内部検索が関連します。この内部処理が最も速くなるのは、ロールフィルタ内に表示されるすべての属性に、ロールの適用範囲内にあるすべてのサフィックスでインデックスが付けられている場合です。

nsRole 属性に対するアクセス権

nsRole 属性はロールメカニズムによってだけ割り当てられ、ディレクトリユーザーが書き込みや変更を行うことはできません。ただし、次の事項に注意してください。

ディレクトリユーザーなら誰でも、基本的には nsRole 属性を読み取ることができますが、管理者はアクセス制御を定義してこれを防止できます。

nsRoleDN 属性は、管理されているロールのメンバーシップを定義します。自身をロールに追加したり削除したりする許可をユーザーに与えるかどうかは、管理者が決定します。ユーザーが自身のロールを変更できないようにする ACI については、「管理されているロール定義の例」を参照してください。

フィルタを適用したロールでは、ユーザーエントリ内に特定の属性値が存在するかどうかに基づいてメンバーが定義されます。フィルタを適用したロールでメンバーシップを定義できるユーザーを制御するには、これらの属性のユーザー権限を慎重に定義します。

コンソールを使用したロールの割り当て

ここでは、Directory Server コンソールを使用してロールを作成および変更するための手順について説明します。

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

管理されているロールにはロール定義エントリが 1 つあり、メンバーエントリに nsRoleDN 属性を追加することでメンバーが定義されます。コンソールを使用して、管理されているロールを作成してメンバーを追加するには、次の手順を実行します。

Directory Server コンソールの最上位の「ディレクトリ」タブを選択し、ディレクトリツリーで、新しいロール定義の追加先エントリを右クリックします。次に、「新規」>「ロール」の順に選択します。

または、エントリを選択し、「オブジェクト」メニューから「新規」>「ロール」の順に選択します。

「新規ロールの作成」ダイアログボックスで、新しいロールの名前を「ロール名」フィールドに入力します。ロールの説明を「説明」フィールドに追加することもできます。このロール名は、新しいロールエントリの cn (共通名) 属性の値になり、その DN の中に表示されます。

ダイアログボックスの左側のリストで「メンバー」をクリックします。右側のパネルでは、「管理されているロール」ラジオボタンがデフォルトで選択されています。

このロールに新しいメンバーを追加するために、メンバーリストの下の「追加」をクリックします。標準の「ユーザーとグループの検索」ダイアログボックスが表示されます。

検索結果からエントリを 1 つ以上選択し、「了解」をクリックします。この手順を繰り返して、この管理されているロールに必要なメンバーをすべて追加します。

ロールへのエントリの追加が完了したら、「了解」をクリックします。管理されているロールを表すアイコンとともに、この新しいロールがディレクトリツリーに表示されます。また、すべてのメンバーエントリに nsRoleDN 属性が追加され、この新しいロールエントリの DN の値が設定されます。

ロールを作成したら、このロールを任意のエントリに割り当てることができます。それには、目的のエントリに nsRoleDN 属性を追加し、ロールエントリの DN の値を設定します。

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

フィルタを適用したロールでは、ロール定義の LDAP フィルタに選択される属性や属性値を持つエントリが、このロールのメンバーとなります。

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


注	フィルタを適用したロールのフィルタ文字列には、任意の属性を使用できます。ただし、CoS メカニズムによって生成されるその他の仮想属性は使用できません (「CoS について」を参照)。

または、エントリを選択し、「オブジェクト」メニューから「新規」>「ロール」の順に選択します。

ダイアログボックスの左側のリストで「メンバー」をクリックし、右側のパネルで「フィルタを適用したロール」ラジオボタンを選択します。

ロールのメンバーを決定するための LDAP フィルタをテキストフィールドに入力します。または、「構成」をクリックし、指示に従って LDAP フィルタを作成します。

「構成」をクリックすると、「LDAP フィルタの構成」ダイアログが表示されます。フィルタを適用したロールの定義では、「LDAP サーバーホスト」、「ポート」、「ベース DN」、および「検索」の各フィールドを指定できないので、これらは無視します。

フィルタを適用したロールのユーザーだけを検索します。これにより、(objectclass=person) というコンポーネントがフィルタに追加されます。このコンポーネントを使用しない場合は、「新規ロールの作成」ダイアログボックスのテキストフィールドで LDAP フィルタを編集する必要があります。

「場所」ドロップダウンリストから属性を選択し、一致条件を設定して、このフィルタを詳しく定義します。フィルタを追加するには、「フィルタの追加」をクリックします。不要なフィルタを削除するには、「フィルタの削除」をクリックします。

「了解」をクリックして、フィルタを適用したロールの定義にこのフィルタを追加します。その後、必要に応じてフィルタのコンポーネントをテキストフィールドで編集できます。

「テスト」をクリックして、フィルタをテストします。「フィルタテスト結果」ダイアログボックスに、その時点でフィルタに一致するエントリが表示されます。

「了解」をクリックして、この新しいロールエントリを作成します。フィルタを適用したロールを表すアイコンとともに、この新しいロールがディレクトリツリーに表示されます。

入れ子のロールの作成

入れ子のロールを使用すると、別のロールを含むロールを作成でき、既存のロールの適用範囲を拡張できます。入れ子のロールを作成する前に、別のロールを作成しておく必要があります。入れ子のロールを作成する場合は、入れ子にできるロールのリストが表示されます。入れ子のロールには、最大で 30 の段階まで、さらに入れ子のロールが含まれている可能性があります。この制限を超えた入れ子構造が含まれると、ロールの評価時にサーバーがエラーを記録します。

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

または、エントリを選択し、「オブジェクト」メニューから「新規」>「ロール」の順に選択します。

ダイアログボックスの左側のリストで「メンバー」をクリックし、右側のパネルで「入れ子になっているロール」ラジオボタンを選択します。

「追加」をクリックして、既存のロールを入れ子のロールのリストに追加します。「ロールセレクタ」ダイアログボックスで、利用可能なロールのリストから 1 つまたは複数のロールを選択し、「了解」をクリックします。

「了解」をクリックして、入れ子のロールエントリを作成します。ディレクトリに新しいロールと入れ子のロールのアイコンが表示されます。

入れ子のロールの適用範囲を変更するには、「入れ子のロール定義の例」の手順をコマンド行から実行します。

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

Directory Server コンソールの最上位レベルにある「ディレクトリ」タブでディレクトリツリーを表示し、表示または編集するエントリを探します。

このエントリをマウスの右ボタンでクリックし、ポップアップメニューから「ロールを設定」を選択します。あるいは、エントリをクリックして選択し、「オブジェクト」メニューから「ロールを設定」を選択します。

「ロールを設定」ダイアログが表示されます。

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

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

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

エントリに関連付けられた管理されているロールを編集するには、テーブルからロールを選び、「編集」をクリックします。ロールのカスタムエディタにロールが表示されます。ロールに変更を加え、「了解」をクリックして新しいロール定義を保存します。

「その他のロール」タブを選択すると、このエントリが所属する、フィルタを適用したロールや入れ子のロールが表示されます。フィルタを適用したロールまたは入れ子のロールのロールのメンバーシップを変更するときは、ロール定義を編集する必要があります。

ロールを選択して「編集」をクリックし、そのロールのカスタムエディタを表示します。ロールに変更を加え、「了解」をクリックして新しいロール定義を保存します。

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

ロールのエントリの変更

Directory Server コンソールで、「ディレクトリ」タブを選択します。

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

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

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

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

「了解」をクリックして、変更を保存します。

ロールの削除

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

Directory Server コンソールで、「ディレクトリ」タブを選択します。

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

ロールを右クリックし、「削除」を選択します。

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

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



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

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

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

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

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

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

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

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

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

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

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

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

エントリ内の nsRoleDN 属性は、そのエントリが管理されているロールのメンバーであることを示します。これは、そのロール定義の DN で判別されます。ユーザーが自分の nsRoleDN 属性は変更できるが、nsManagedDisabledRole の追加や削除はできないようにするには、次の ACI (アクセス制御命令) を追加します。

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

セールスマネージャ用にフィルタを適用したロールを設定するには、全員が isManager 属性を持っていると仮定し、次の ldapmodify コマンドを実行します。

nsFilteredRoleDefinition オブジェクトクラスは、LDAPsubentry、nsRoleDefinition、および nsComplexRoleDefinition の各オブジェクトクラスから継承されることに注意してください。たとえば次のように、nsRoleFilter 属性は、ou=sales という組織に含まれ、下位組織を持つすべての従業員を検索するフィルタを指定します。

フィルタを適用したロールのメンバーがユーザーエントリである場合、ユーザーが自身をロールに追加したり削除したりできないように制限するには、フィルタを適用した属性を ACI (アクセス制御命令) で保護します。

入れ子のロール定義の例


注	フィルタを適用したロールのフィルタ文字列には、任意の属性を使用できます。ただし、CoS メカニズムによって生成されるその他の仮想属性は使用できません (「CoS について」を参照)。

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

nsNestedRoleDefinition オブジェクトクラスは、LDAPsubentry、nsRoleDefinition、および nsComplexRoleDefinition の各オブジェクトクラスから継承されることに注意してください。nsRoleDN 属性は、マーケティングの管理されているロールの DN とセールスマネージャのフィルタを適用したロールの DN を含みます。前述の例のユーザー Bob と Carla は、どちらもこの新しい入れ子のロールのメンバーになります。

このフィルタの適用範囲としては、デフォルトの適用範囲 (フィルタが置かれているサブツリー) に加え、nsRoleScopeDN 属性のすべての値の下にあるサブツリーが含まれます。この例では、ManagerFilter は ou=sales,ou=People,dc=example,dc=com サブツリーに置かれているため、このサブツリーも適用範囲に追加されます。

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

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

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

CoS について

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


注	すべての検索操作で、CoS で生成された属性の有無を調べたり、その値を比較したりできます。クライアントの検索操作で使用されるフィルタや、フィルタを適用したロールで使用される内部フィルタなど、どのフィルタ文字列にも仮想属性の名前を使用できます。Directory Server では、VLV (仮想リスト表示) 操作やサーバー側ソート制御でも、実際の属性と同様に仮想属性がサポートされています。

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

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

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

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

間接 CoS : CoS 定義は、間接的な指示子と呼ばれる属性を識別する。ターゲットエントリのこの属性の値には、テンプレートの DN を指定する必要がある。間接 CoS を使用することで、各ターゲットエントリで異なるテンプレートを使用できるため、CoS 属性に異なる値を指定することができます。

クラシック CoS : CoS 定義は、テンプレートのベース DN と指示子 (ターゲットエントリの属性名) を識別する。指示子属性には RDN (相対識別名) を指定する必要がある。この RDN とテンプレートのベース DN との組み合わせによって、CoS 値を含むテンプレートが決定される

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

cosPointerDefinition

cosIndirectDefinition

cosClassicDefinition

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

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

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

CoS の制限事項

CoS 定義エントリとテンプレートエントリの作成と管理には、次のような制限事項があります。CoS 仮想属性の導入に関する制限事項の詳細については、『Directory Server 配備計画ガイド』の第 4 章にある「CoS の制限事項」を参照してください。

CoS で生成された属性を使用する検索は、インデックスを使用しない検索となる : どの検索フィルタでも、仮想属性の有無を調べたり、その値を比較したりできます。ただし、仮想属性にはインデックスを付けることができないため、CoS で生成された属性をフィルタコンポーネントで使用するとインデックスを使用しない検索となり、パフォーマンスがかなり低下します。Directory Server 5.2 では、10 を超えるクラシック CoS テンプレートエントリによるスキーム上での検索速度を上げるハッシュテーブルが導入されています。この機能はデフォルトで有効になっています。この機能を無効にする方法については、『Directory Server Administration Reference』の第 2 章にある「Class of Service Plug-in」を参照してください。

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

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

userPassword : CoS で生成されたパスワード値は、ディレクトリサーバーへのバインドに使用できない

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

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

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

サポートしていない属性サブタイプ : CoS メカニズムは、言語やバイナリなど、サブタイプを持つ属性を生成しません。

実際の属性値と仮想の属性値 : CoS メカニズムで複数値属性が生成される場合、エントリに定義されている「実際」の値と、CoS テンプレートで定義されている「仮想」の値とが混在することはありません。1 つの属性が持つ値は、エントリに格納されている値か、CoS メカニズムで生成された値のどちらかになります。詳細は、「実際の属性値の上書き」および「複数の値を持つ CoS 属性」を参照してください。

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

コンソールを使用した CoS の管理

ここでは、Directory Server コンソールを使った CoS 定義の作成および編集方法について説明します。

また、CoS 値を保護する必要がある場合は、CoS 定義エントリとテンプレートエントリ、およびターゲットエントリの指示子属性について ACI (アクセス制御命令) を定義してください。CoS セキュリティに関する注意事項については『Directory Server 配備計画ガイド』の第 7 章にある「CoS の安全な使い方」、コンソールを使用した ACI の作成手順については、第 6 章「アクセス制御の管理」を参照してください。

新しい CoS の作成

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

Directory Server コンソールの最上位の「ディレクトリ」タブを選択し、ディレクトリツリーで、新しいテンプレートエントリの追加先エントリを右クリックして、ポップアップメニューから「新規」>「その他」を順に選択します。

または、親エントリを選択し、「オブジェクト」メニューから「新規」>「その他」を順に選択します。

「新規オブジェクト」ダイアログが表示されるので、オブジェクトクラスのリストから「costemplate」を選択します。「汎用エディタ」ダイアログボックスが表示され、新しいテンプレートのいくつかの属性にデフォルト値が表示されます。

次の手順で新しいテンプレートオブジェクトを編集します。

objectclass 属性に LDAPsubentry 値および extensibleobject 値を追加する

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

ネーミング属性を新しい cn 属性に変更する

ほかの属性を追加して、それをネーミング属性として使用することもできるが、通常は cn を使用する

整数の値を設定することにより cosPriority 属性を変更するか、必要がない場合は優先順位属性を削除する。詳細は、「CoS 属性の優先順位」を参照してください。

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

「汎用エディタ」ダイアログの「了解」をクリックして、テンプレートエントリを作成します。

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

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

Directory Server コンソールの最上位の「ディレクトリ」タブを選択し、ディレクトリツリーで、新しい CoS 定義の追加先エントリを右クリックして、ポップアップメニューから「新規」>「サービスクラス」を順に選択します。

または、親エントリを選択し、「オブジェクト」メニューから「新規」>「サービスクラス」を順に選択します。

サービスクラスエントリのカスタムエディタが表示されます。

新しいサービスクラスの名前と、必要に応じてその説明を入力します。CoS 定義のエントリの cn ネーミング属性に名前が表示されます。

左側のリストで「属性」タブをクリックします。ダイアログに、CoS メカニズムによりターゲットエントリに生成される属性のリストが表示されます。

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

リストに属性を追加すると、「サービスクラスの動作」列にドロップダウンリストが表示されます。このセルをクリックし、次の上書き動作のうちどれかを選択します。

ターゲットエントリ属性をオーバーライドしない : ターゲットエントリの同じ属性に対応する属性値が格納されていない場合にだけ、CoS 属性値が生成される

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

ターゲットエントリ属性をオーバーライド (操作可能): 明示的に要求した場合を除きクライアントアプリケーションに表示されないようにするため、CoS 属性値をターゲットの値に上書きし、属性を operational にする



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

「マージ ?」列には merge-schemes のチェックボックスが表示されます。このチェックボックスを選択して、この CoS 属性が同じ属性の他の CoS 値とマージできるようにします。ただし、CoS 属性は既存の値とはマージしません。前の列によって定義されたように、既存の値が置き換えられるか、生成されないかのどちらかです。

左側のリストで「テンプレート」タブをクリックします。テンプレートエントリの識別方法を選択し、対応するフィールドに必要事項を入力します。これにより、定義する CoS のタイプを決定できます。

DN による : これを選択すると、ポインタ CoS を定義できます。「テンプレート DN」フィールドにテンプレートエントリの DN を入力します。「参照」をクリックして、ディレクトリからテンプレート DN を選択するか、または Ctrl + V キーを押して、テンプレートエントリの作成後にコピーした DN をペーストします。

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

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

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

既存の CoS の編集

Directory Server コンソールの最上位にある「ディレクトリ」タブで、CoS 定義のエントリをダブルクリックするか、そのエントリをマウスの右ボタンでクリックして、ポップアップメニューから「カスタムエディタで編集」を選択します。

サービスクラスエントリのカスタムエディタが表示されます。

必要に応じて名前と説明のフィールドを編集します。

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

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

「了解」をクリックして、変更を保存します。

CoS の削除

Directory Server コンソールの最上位の「ディレクトリ」タブで、ディレクトリツリーを展開し、CoS 定義のエントリを選択します。

この CoS エントリをマウスの右ボタンでクリックし、ポップアップメニューから「削除」を選択します。削除の確認を求めるダイアログボックスが表示されます。「はい」をクリックします。

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

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

また、CoS 値を保護する必要がある場合は、CoS 定義エントリとテンプレートエントリ、およびターゲットエントリの指示子属性について ACI (アクセス制御命令) を定義してください。CoS セキュリティに関する注意事項については『Directory Server 配備計画ガイド』の第 7 章にある「CoS の安全な使い方」、コマンド行からの ACI の作成手順については、第 6 章「アクセス制御の管理」を参照してください。

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

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

表 5-2 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 定義のエントリ内で使用できます (属性については、『Directory Server Administration Reference』の第 10 章にある「Attribute Reference」を参照)。

表 5-3 CoS 定義のエントリの属性
属性	CoS 定義のエントリ内の目的
cosAttribute: attributeName override merge	値を生成する対象となる仮想属性の名前を定義する。この属性には複数の値を指定できる。それぞれの値には属性の名前が指定され、この属性値はテンプレートから生成される。override 修飾子と merge 修飾子により、次の表に示す特殊な場合での CoS 属性値の算出方法を指定する attributeName にはサブタイプが含まれない可能性がある。サブタイプを持つ属性値は無視されるが、cosAttribute のその他の値は処理される
cosIndirectSpecifier: attributeName	ターゲットエントリの属性名を定義する。間接 CoS は、この属性の値を使用してテンプレートエントリを識別する。名前が指定された属性は指示子と呼ばれ、各ターゲットエントリに完全 DN 文字列を含める必要がある。この属性には値を 1 つしか指定できないが、指示子属性には複数の値を指定して複数のテンプレートを指定できる
cosSpecifier: attributeName	ターゲットエントリの属性名を定義する。クラシック CoS は、この属性の値を使用してテンプレートエントリを識別する。名前が指定された属性は指示子と呼ばれ、ターゲットエントリの RDN になる文字列を含める必要がある。この属性には値を 1 つしか指定できないが、指示子属性には複数の値を指定して複数のテンプレートを指定できる
cosTemplateDN: DN	ポインタ CoS 定義用にテンプレートエントリの完全 DN、またはクラシック CoS 用にテンプレートエントリのベース DN を指定する

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

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

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

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

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

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

実際の属性値の上書き

override 修飾子を含むポインタ CoS 定義のエントリの作成例を次に示します。

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

複数の値を持つ CoS 属性


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

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

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

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

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

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

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

CoS 属性の優先順位


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

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

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

merge-schemes 修飾子を使用する場合は、テンプレートの優先順位は考慮されません。マージするときに、定義する優先順位に関係なく、対象となるすべてのテンプレートが値を定義します。次の節で説明するように、cosPriority 属性は CoS テンプレートエントリに対して定義されます。

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


注	cosPriority 属性は、負の値を持つ必要があります。また、間接 CoS が生成する属性は優先順位をサポートしていません。間接 CoS 定義のテンプレートエントリでは、cosPriority を使用しないでください。

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

間接 CoS メカニズムのテンプレートは、ディレクトリ内の任意の既存テンプレートエントリです。事前にターゲットを指定する必要はなく、LDAPsubentry オブジェクトクラスを指定する必要もありませんが、任意の cosTemplate オブジェクトクラスが含まれている必要があります。間接 CoS テンプレートには、CoS を評価して仮想属性とその値を生成する場合にだけアクセスします。

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

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

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

ポインタ CoS の例

次のコマンドは、cosPointerDefinition オブジェクトクラスを持つポインタ CoS 定義エントリを作成します。この定義エントリは、上の CoS テンプレートエントリを使用して、 ou=People,dc=example,dc=com ツリーのすべてのエントリに共通する郵便番号を共有します。

ここで作成した CoS テンプレートエントリ cn=ZipTemplate,ou=People,dc=example,dc=com は、ou=People,dc=example,dc=com サフィックスの下に置かれているすべてのエントリに対して、その postalCode 属性に格納されている値を提供します。同じサブツリーで郵便番号を持たないエントリを検索すると、生成される属性の値は次のようになります。

間接 CoS の例

間接 CoS は、各ターゲットに固有のテンプレートを特定するために、cosIndirectSpecifier 属性内の属性に名前をつけます。ここで説明する間接 CoS は、ターゲットエントリの manager 属性を使用して、CoS テンプレートエントリを識別するものです。テンプレートエントリはマネージャのユーザーエントリで、生成する属性の値を含んでいる必要があります。

次のコマンドは、cosIndirectDefinition オブジェクトクラスを含む間接 CoS 定義エントリを作成します。

次に、テンプレートエントリに cosTemplate オブジェクトクラスを追加し、生成する属性が定義されていることを確認します。この例では、すべてのマネージャエントリはテンプレートです。

この CoS では、manager 属性を含むターゲットエントリ (ou=People,dc=example,dc=com の下のエントリ) は、自動的にマネージャの部署番号を持ちます。departmentNumber 属性は、サーバー上に存在せず、ターゲットエントリの一部として返されるだけなので、ターゲットエントリの仮想属性となります。たとえば、Babs Jensen のマネージャを Carla Fuentes として定義した場合、このマネージャの部署番号は次のように表示されます。

クラシック CoS の例

この例は、クラシック CoS を使用して住所を生成する方法を示しています。生成される値は、CoS 定義内の cosTemplateDN と、ターゲットエントリ内の cosSpecifier 属性の値の組み合わせで、テンプレートエントリの形式で表示されます。次のコマンドは、cosClassicDefinition オブジェクトクラスを使用して定義エントリを作成します。

引き続き同じコマンドを使用して、各ビルの住所を持つテンプレートエントリを作成します。

この CoS では、building 属性を含むターゲットエントリ (ou=People,dc=example,dc=com の下のエントリ) は、自動的に対応する住所を持ちます。CoS メカニズムは、RDN 内に指示子属性値を持つテンプレートエントリを検索します。この例では、Babs Jensen に B07 ビルが割り当てられていれば、住所は次のように表示されます。

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

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

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

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

次のようなクラシック CoS 定義のエントリが作成されます。

CoS テンプレートの名前は、cosTemplateDn と、nsRole の値 (ロールの DN) の組み合わせである必要があります。たとえば、次のようにします。

CoS テンプレートエントリは、mailboxquota 属性値を提供します。追加で指定した override 修飾子は、CoS がターゲットエントリ内にある既存のすべての mailboxquota 属性値を上書きするように指定します。ロールのメンバーであるターゲットエントリは、たとえば次のような、ロールと CoS が生成する仮想属性を持ちます。

ldapsearch -h host -p port -D "cn=Directory Manager" -w password ¥
-b "ou=People,dc=example,dc=com" -s sub "(cn=*Fuentes)"
dn:cn=Carla Fuentes,ou=People,dc=example,dc=com
cn:Carla Fuentes
isManager:TRUE
...
nsRole:cn=ManagerRole,ou=People,dc=example,dc=com
mailboxquota: 1000000



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

CoS プラグインの監視

Directory Server 5.2 を使用すると、CoS プラグインの特定の側面を監視できます。CoS 監視属性は、cn=monitor,cn=Class of Service,cn=plugins,cn=config エントリ下で保持されています。これらの属性の詳細と、これらの属性によって提供される情報については、『Directory Server Administration Reference』の第 2 章にある「cn=monitor,cn=Class of Service,cn=plugins, cn=config」を参照してください。

前へ目次索引次へ
Sun Java™ System Directory Server 5 2004Q2 管理ガイド