|
| Sun ONE Directory Server 管理ガイド |
ユーザーを表すエントリを管理するには、ディレクトリ内のデータの階層構造を超えて、グループを作成したり、共通の属性値を共有したりすることがしばしば 必要になります。Sun ONE Directory Server では、グループ、ロール、およびサービスクラス (CoS) を使ってエントリを高度に管理できます。
グループとは、メンバーのリストまたはメンバーに適用するフィルタを使用して、ほかのエントリを指定するエントリです。ロールは、ロールの各メンバーに対して nsrole 属性を生成するメカニズムによって、グループと同等またはそれ以上の機能を提供します。CoS も仮想属性を生成します。これにより、エントリは、各エントリに値を格納することなく、共通の属性値を共有できるようになります。
ロールとサービスクラスが提供する機能を活用するには、ディレクトリの導入を計画する段階で、ディレクトリのトポロジを決定しておく必要があります。これらのメカニズムの詳細と、それによってトポロジを単純化できるしくみについては、『Sun ONE Directory Server Deployment Guide』の第 4 章「Designing the Directory Tree」を参照してください。
この章は、次の節で構成されています。
グループの管理
グループとは、ACI の定義などのように、管理しやすくするためにエントリを相互に関連付けるメカニズムです。グループ定義は特別なエントリで、スタティックなリストにメン バーの名前を指定するか、またはダイナミックなエントリセットを定義するフィルタを指定します。同等のロール定義を作成する手順については、「ロールの割り当て」を参照してください。
グループに含めることが可能なメンバーの範囲は、グループ定義エントリの位置に関係なく、ディレクトリ全体となります。管理を簡略化するために、すべてのグループ定義エントリは、通常、1 か所に格納されます。通常は、ルートサフィックスの下の ou=Groups に格納されます。
スタティックグループを定義するエントリは、groupOfUniqueNames オブジェクトクラスから継承されます。グループのメンバーは、その DN ごとに uniqueMember 属性の複数値として一覧表示されます。
ダイナミックグループを定義するエントリは、groupOfUniqueNames および groupOfURLs オブジェクトクラスから継承されます。グループのメンバーシップは、複数値属性 memberURL に指定された、1 つまたは複数のフィルタによって定義されます。フィルタが評価されたときにそのどれかに一致するエントリが、ダイナミックグループのメンバーとなります。
次の節では、コンソールを使用してスタティックグループとダイナミックグループを作成および変更する方法について説明します。
新しいスタティックグループの追加
- Directory Server コンソールの最上位の「ディレクトリ」タブを選択し、ディレクトリツリーで、新しいグループの追加先エントリを右クリックします。次に、「新規」>「グループ」の順に選択します。
または、エントリを選択し、「オブジェクト」メニューから「新規」>「グループ」の順に選択します。
- 「新規グループの作成」ダイアログボックスで、新しいグループの名前を「グループ名」フィールドに入力します。グループの説明を「説明」フィールドに追加することもできます。このグループ名は、新しいグループエントリの cn (共通名) 属性の値になり、その DN の中に表示されます。
- ダイアログボックスの左側のリストで「メンバー」をクリックします。右側のパネルでは、「スタティックグループ」タブがデフォルトで選択されています。
- 「追加」をクリックして、グループに新しいメンバーを追加します。標準の「ユーザーとグループの検索」ダイアログボックスが表示されます。
- 「検索」ドロップダウンリストから「ユーザー」を選択し、検索する文字列を入力してから、「検索」をクリックします。特定の属性や属性値を検索するには、「詳細」ボタンをクリックします。
検索結果からエントリを 1 つ以上選択し、「了解」をクリックします。この手順を繰り返して、このスタティックグループに必要なメンバーをすべて追加します。
注 スタティックグループのメンバーは、連鎖によってリモートに存在する可能性があります。参照整合性検査プラグインを使用すると、削除されたメンバーのエントリをスタティックグループのエントリから自動的に削除できます。連鎖と参照整合性を併用する方法については、「連鎖ポリシーの設定」を参照してください。
- 左側のリストで「言語」をクリックし、グループの名前と説明を別の言語で指定します。これらは、その言語に対応するロケールがコンソールで使用される場合に表示されます。
- 「了解」をクリックすると、新しいグループが作成されます。グループは、そのグループが作成された場所であるエントリの子の 1 つとして表示されます。
新しいダイナミックグループの追加
- Directory Server コンソールの最上位の「ディレクトリ」タブを選択し、ディレクトリツリーで、新しいグループの追加先エントリを右クリックします。次に、「新規」>「グループ」の順に選択します。
または、エントリを選択し、「オブジェクト」メニューから「新規」>「グループ」の順に選択します。
- 「新規グループの作成」ダイアログボックスで、新しいグループの名前を「グループ名」フィールドに入力します。グループの説明を「説明」フィールドに追加することもできます。このグループ名は、新しいグループエントリの cn (共通名) 属性の値になり、その DN の中に表示されます。
- ダイアログボックスの左側のリストで「メンバー」をクリックし、右側のパネルで「ダイナミックグループ」タブを選択します。
- 「追加」をクリックして、グループのメンバーを定義するフィルタ文字列を含んだ LDAP URL を作成します。標準の「LDAP URL の構成とテスト」ダイアログボックスが表示されます。
- テキストフィールドに LDAP URL を入力するか、または「構成」を選択し、指示に従って、グループに適用するフィルタを含む LDAP URL を作成します。「テスト」をクリックして、このフィルタで取得されるエントリのリストを表示します。
URL の作成が完了したら、「了解」をクリックします。この手順を繰り返して、ダイナミックグループを定義するフィルタを含んだ URL をすべて追加します。
- 左側のリストで「言語」をクリックし、グループの名前と説明を別の言語で指定します。これらは、その言語に対応するロケールがコンソールで使用される場合に表示されます。
- 「了解」をクリックすると、新しいグループが作成されます。グループは、そのグループが作成された場所であるエントリの子の 1 つとして表示されます。
グループ定義の変更
- Directory Server コンソールの最上位の「ディレクトリ」タブで、変更するグループを表すエントリをダブルクリックします。
または、エントリを選択し、「オブジェクト」メニューの「開く」を選択します。
- 「エントリの編集」ダイアログボックスで、「一般」、「メンバー」、「言語」の各カテゴリのグループ情報を変更します。スタティックグループの場合はメンバーの追加と削除、ダイナミックグループの場合はフィルタを含んだ URL の追加、編集、削除を行うことができます。
- グループ定義の変更が完了したら、「了解」をクリックします。
変更内容をコンソールで確認するには、「表示」メニューの「再表示」を選択します。
グループ定義の削除
グループのタイプのどれかを削除するには、そのグループを定義するエントリを削除します。
ロールの割り当て
ロールは、アプリケーションでより効率的に簡単に使用できる新しいグループ化メカニズムです。ロールは、グループと同じように定義および管理されますが、 それに加えて、メンバーエントリにも、所属するロールを示す属性が生成されます。たとえば、アプリケーションでは、グループを選択してメンバーリストを参 照しなくても、エントリのロールを読み取るだけで済みます。
デフォルトでは、ロールの適用範囲は、それが定義されているサブツリーに限定されます。Sun ONE Directory Server 5.2 では、入れ子のロールの適用範囲が拡張されたため、ほかのサブツリーにあるロールも入れ子にでき、ディレクトリ内の任意の位置にメンバーを置くことができ ます。
ロールについて
各ロールはメンバー、つまりそのロールを所有するエントリを持ちます。ディレクトリからエントリが取得されるとき、ロールメカニズムによって自動的に、なんらかのロールに所属するすべてのエントリに nsRole 属性が生成されます。この複数値属性には、そのエントリをメンバーとして持つすべてのロール定義の DN が値として設定されます。nsRole 属性は、算出される属性であるためエントリ自体には格納されませんが、処理結果は通常の属性としてクライアントアプリケーションに返されます。
Sun ONE Directory Server は、次の 3 種類のロールをサポートしています。
- 管理されているロール : 管理者は、対象となるメンバーエントリに nsRoleDN 属性を追加することにより、管理されているロールを割り当てることができます。この属性の値は、ロール定義エントリの DN です。管理されているロールは、メンバーがロール定義エントリではなく各エントリに定義されていることを除いて、スタティックグループと似ています。
- フィルタを適用したロール : このロールはダイナミックグループと同じです。このロールでは、nsRoleFilter 属性にフィルタ文字列を定義します。フィルタを適用したロールの適用範囲は、定義エントリの親をルートとする、ロールが位置するサブツリーです。サーバー が、フィルタ文字列に一致した、フィルタを適用したロールの適用範囲内のエントリを返す場合、そのエントリにはロールを識別する nsRole 属性が含まれています。
- 入れ子のロール : ほかの入れ子のロールも含め、ほかのロール定義を指定して使用するロールです。入れ子のロールに含まれているロールのすべてのメンバーが、入れ子のロール のメンバーとなります。入れ子のロールでは、その適用範囲を拡張して、ほかのサブツリーにあるロールのメンバーを含めることもできます。
ロールは、nsRole 属性の内容を直接読み取ることで、エントリのすべてのロールメンバーシップをクライアント アプリケーションに知らせます。これにより、クライアントの処理が簡素化され、ディレクトリの使用が最適化されます。ロールと CoS メカニズムを組み合わせて、ロールメンバーの他の属性を生成することもできます (「ロールに基づく属性の作成」を参照)。ロールは、アクセス制御の定義にも使用できます (「ロールアクセスの定義 : roledn キーワード」を参照)。またロールには、そのロールのすべてのメンバーを一度に有効化または無効化する機能も用意されています (「ユーザーとロールの無効化と有効化」を参照)。
nsRole 属性の検索
Sun ONE Directory Server 5.2 では、任意の検索フィルタで nsRole 属性を使用できるようになりました。任意の比較演算子を使用して、この属性の特定の値を検索できます。ただし、次の事項に注意してください。
- nsRole 属性を使用する検索では、エントリにフィルタを適用する前にすべてのロールを評価する必要があるため、所要時間がかなり長くなります。
- Directory Server は、特に管理されているロールのメンバーシップの等価検索用に最適化されています。たとえば、次の検索は、実際の属性に対する検索とほぼ同じ速さで実行されます。
(&(objectclass=person)
(nsRole=cn=managersRole,ou=People,dc=example,dc=com)
- 管理されているロールのメンバーシップを定義する nsRoleDN 属性には、デフォルトではすべてのサフィックスでインデックスが付けられます。Directory Server は管理されているロールのメンバーシップの検索用に最適化されていますが、この属性のインデックス付けが無効になっていると、その効果は失われます。
- フィルタが適用されたロールを含むエントリの検索には、ロールフィルタを使用した内部検索が関連します。この内部処理が最も速くなるの は、ロールフィルタ内に表示されるすべての属性に、ロールの適用範囲内にあるすべてのサフィックスでインデックスが付けられている場合です。
nsRole 属性に対するアクセス権
nsRole 属性はロールメカニズムによってだけ割り当てられ、ディレクトリユーザーが書き込みや変更を行うことはできません。ただし、次の事項に注意してください。
- ディレクトリユーザーなら誰でも、基本的には nsRole 属性を読み取ることができますが、管理者はアクセス制御を定義してこれを防止できます。
- nsRoleDN 属性は、管理されているロールのメンバーシップを定義します。自身をロールに追加したり削除したりする許可をユーザーに与えるかどうかは、管理者が決定します。ユーザーが自身のロールを変更できないようにする ACI については、「管理されているロール定義の例」を参照してください。
- フィルタを適用したロールでは、ユーザーエントリ内に特定の属性値が存在するかどうかに基づいてメンバーが定義されます。フィルタを適用 したロールでは、そのメンバーシップを定義できるユーザーを制限するために、これらの属性のユーザー権限を慎重に定義する必要があります。
ディレクトリでのロールの使用方法については、『Sun ONE Directory Server Deployment Guide』の第 4 章「Designing the Directory Tree」を参照してください。
コンソールを使用したロールの割り当て
ここでは、ロールの作成と変更に関する次の手順について説明します。
管理されているロールの作成
管理されているロールにはロール定義エントリが 1 つあり、メンバーエントリに nsRoleDN 属性を追加することでメンバーが定義されます。コンソール を使用して、管理されているロールを作成してメンバーを追加するには、次の手順を実行します。
- Directory Server コンソールの最上位の「ディレクトリ」タブを選択し、ディレクトリツリーで、新しいロール定義の追加先エントリを右クリックします。次に、「新規」>「ロール」の順に選択します。
または、エントリを選択し、「オブジェクト」メニューから「新規」>「ロール」の順に選択します。
- 「新規ロールの作成」ダイアログボックスで、新しいロールの名前を「ロール名」フィールドに入力します。ロールの説明を「説明」フィールドに追加することもできます。このロール名は、新しいロールエントリの cn (共通名) 属性の値になり、その DN の中に表示されます。
- ダイアログボックスの左側のリストで「メンバー」をクリックします。右側のパネルでは、「管理されているロール」ラジオボタンがデフォルトで選択されています。
- このロールに新しいメンバーを追加するために、メンバーリストの下の「追加」をクリックします。標準の「ユーザーとグループの検索」ダイアログボックスが表示されます。
- 「検索」ドロップダウンリストから「ユーザー」を選択し、検索する文字列を入力してから、「検索」をクリックします。特定の属性や属性値を検索するには、「詳細」ボタンをクリックします。
検索結果からエントリを 1 つ以上選択し、「了解」をクリックします。この手順を繰り返して、このスタティックロールに必要なメンバーをすべて追加します。
- ロールへのエントリの追加が完了したら、「了解」をクリックします。管理されているロールを表すアイコンとともに、この新しいロールがディレクトリツリーに表示されます。また、すべてのメンバーエントリに nsRoleDN 属性が追加され、この新しいロールエントリの DN の値が設定されます。
- ロールを作成したら、このロールを任意のエントリに割り当てることができます。それには、目的のエントリに nsRoleDN 属性を追加し、ロールエントリの DN の値を設定します。
フィルタを適用したロールの作成
フィルタを適用したロールでは、ロール定義の LDAP フィルタに選択される属性や属性値を持つエントリが、このロールのメンバーとなります。
注 フィルタを適用したロールのフィルタ文字列には、任意の属性を使用できます。ただし、CoS メカニズムによって生成されるその他の仮想属性は使用できません (「CoS について」を参照)。
コンソールを使用して、フィルタを適用したロールを作成してメンバーを追加するには、次の手順を実行します。
- Directory Server コンソールの最上位の「ディレクトリ」タブを選択し、ディレクトリツリーで、新しいロール定義の追加先エントリを右クリックします。次に、「新規」>「ロール」の順に選択します。
または、エントリを選択し、「オブジェクト」メニューから「新規」>「ロール」の順に選択します。
- 「新規ロールの作成」ダイアログボックスで、新しいロールの名前を「ロール名」フィールドに入力します。ロールの説明を「説明」フィールドに追加することもできます。このロール名は、新しいロールエントリの cn (共通名) 属性の値になり、その DN の中に表示されます。
- ダイアログボックスの左側のリストで「メンバー」をクリックし、右側のパネルで「フィルタを適用したロール」ラジオボタンを選択します。
- ロールのメンバーを決定するための LDAP フィルタをテキストフィールドに入力します。または、「構成」をクリックし、指示に従って LDAP フィルタを作成します。
- 「構成」をクリックすると、「LDAP フィルタの構成」ダイアログが表示されます。フィルタを適用したロールの定義では、「LDAP サーバーホスト」、「ポート」、「ベース DN」、および「検索」の各フィールドを指定できないので、これらは無視します。
- フィルタを適用したロールのユーザーだけを検索します。これにより、(objectclass=person) というコンポーネントがフィルタに追加されます。このコンポーネントを使用しない場合は、「新規ロールの作成」ダイアログボックスのテキストフィールドで LDAP フィルタを編集する必要があります。
- 「場所」ドロップダウンリストから属性を選択し、一致条件を設定して、このフィルタを詳しく定義します。フィルタを追加するには、「フィルタの追加」をクリックします。不要なフィルタを削除するには、「フィルタの削除」をクリックします。
- 「了解」をクリックして、フィルタを適用したロールの定義にこのフィルタを追加します。その後、必要に応じてフィルタのコンポーネントをテキストフィールドで編集できます。
- 「テスト」をクリックして、フィルタをテストします。「フィルタテスト結果」ダイアログボックスに、その時点でフィルタに一致するエントリが表示されます。
- 「了解」をクリックして、この新しいロールエントリを作成します。フィルタを適用したロールを表すアイコンとともに、この新しいロールがディレクトリツリーに表示されます。
入れ子のロールの作成
入れ子のロールを使用すると、別のロールを含むロールを作成でき、既存のロールの適用範囲を拡張できます。入れ子のロールを作成する前に、別のロールを作 成しておく必要があります。入れ子のロールを作成する場合は、入れ子にできるロールのリストが表示されます。入れ子のロールには、最大で 30 の段階まで、さらに入れ子のロールが含まれている可能性があります。この制限を超えた入れ子構造が含まれると、ロールの評価時にサーバーがエラーを記録し ます。
コンソールを使用して、入れ子のロールを作成してメンバーを追加するには、次の手順を実行します。
- Directory Server コンソールの最上位の「ディレクトリ」タブを選択し、ディレクトリツリーで、新しいロール定義の追加先エントリを右クリックします。次に、「新規」>「ロール」の順に選択します。
または、エントリを選択し、「オブジェクト」メニューから「新規」>「ロール」の順に選択します。
- 「新規ロールの作成」ダイアログボックスで、新しいロールの名前を「ロール名」フィールドに入力します。ロールの説明を「説明」フィールドに追加することもできます。このロール名は、新しいロールエントリの cn (共通名) 属性の値になり、その DN の中に表示されます。
- ダイアログボックスの左側のリストで「メンバー」をクリックし、右側のパネルで「入れ子になっているロール」ラジオボタンを選択します。
- 「追加」をクリックして、既存のロールを入れ子のロールのリストに追加します。「ロールセレクタ」ダイアログボックスで、利用可能なロールのリストから 1 つまたは複数のロールを選択し、「了解」をクリックします。
- 「了解」をクリックして、入れ子のロールエントリを作成します。ディレクトリに新しいロールと入れ子のロールのアイコンが表示されます。
- 入れ子のロールの適用範囲を変更するには、「入れ子のロール定義の例」の手順をコマンド行から実行します。
エントリのロールの表示と編集
- Directory Server コンソールの最上位レベルにある「ディレクトリ」タブでディレクトリツリーを表示し、表示または編集するエントリを探します。
- このエントリをマウスの右ボタンでクリックし、ポップアップメニューから「ロールを設定」を選択します。あるいは、エントリをクリックして選択し、「オブジェクト」メニューから「ロールを設定」を選択します。
「ロールを設定」ダイアログが表示されます。
- 「管理されているロール」タブを選択すると、このエントリが所属する管理されているロールが表示されます。次の処理を実行できます。
- 新しい管理されているロールを追加するには、「追加」をクリックし、「ロールセレクタ」ウィンドウから使用可能なロールを選択します。「ロールセレクタ」ウィンドウで「了解」をクリックします。
- 管理されているロールを削除するには、削除するロールを選択し、「削除」をクリックします。
- エントリに関連付けられた管理されているロールを編集するには、テーブルからロールを選び、「編集」をクリックします。ロールのカスタムエディタにロールが表示されます。ロールに変更を加え、「了解」をクリックして新しいロール定義を保存します。
- 「その他のロール」タブを選択すると、このエントリが所属する、フィルタを適用したロールや入れ子のロールが表示されます。フィルタを適用したロールまたは入れ子のロールのロールのメンバーシップを変更するときは、ロール定義を編集する必要があります。
- ロールを選択して「編集」をクリックし、そのロールのカスタムエディタを表示します。ロールに変更を加え、「了解」をクリックして新しいロール定義を保存します。
- ロールの変更が完了したら、「了解」をクリックして、変更を保存します。
ロールのエントリの変更
- Directory Server コンソールで、「ディレクトリ」タブを選択します。
- ナビゲーションツリーを参照して、既存のロールの定義エントリを検索します。ロールは、そのロールを作成した位置の子エントリになります。ロールをダブルクリックします。
「ロールの編集」ダイアログボックスが表示されます。
- ロールの名前と説明を変更するには、左側のパネルで「一般」をクリックします。
- 管理されているロールと入れ子のロールのメンバーを変更するか、またはフィルタを適用したロールのフィルタを変更する場合は、左側のパネルで「メンバー」をクリックします。
- 「了解」をクリックして、変更を保存します。
ロールの削除
ロールを削除すると、ロール定義のエントリだけが削除されます。ロールのメンバーが削除されることはありません。
ロールを削除するには、次の手順を実行します。
- Directory Server コンソールで、「ディレクトリ」タブを選択します。
- ナビゲーションツリーを参照して、ロールの定義エントリを検出します。ロールは、そのロールを作成した位置の子エントリになります。
- ロールを右クリックし、「削除」を選択します。
削除の確認を求めるダイアログボックスが表示されます。「はい」をクリックします。
- ロールが正しく削除されたことを通知する「削除されたエントリ」ダイアログボックスが表示されます。「了解」をクリックします。
注 ロールを削除すると、ロールエントリは削除されますが、各ロールメンバーの nsRoleDN 属性は削除されません。この属性を削除するには、参照整合性検査プラグインを有効にし、nsRoleDN 属性を管理します。詳細は、「参照整合性の管理」を参照してください。
コマンド行からのロールの管理
ロールは、ディレクトリ管理者がコマンド行ユーティリティを使用してアクセスできるようにエントリに定義されます。ロールの作成が完了したら、次のようにロールにメンバーを割り当てます。
- 管理されているロールのメンバーのエントリに、nsRoleDN 属性を含める
- フィルタを適用したロールのメンバーは、nsRoleFilter 属性で指定したフィルタに一致するエントリとなる
- 入れ子のロールのメンバーは、入れ子のロール定義エントリの nsRoleDN 属性で指定したロールのメンバーとなる
すべてのロール定義は、LDAPsubentry および nsRoleDefinition オブジェクトクラスから継承されます。次の表に、各ロールタイプに固有のその他のオブジェクトクラスと関連付けられた属性を示します。
表 5-1 ロールを定義するオブジェクトクラスと属性
管理されているロール定義の例
すべてのマーケティングスタッフに割り当てるロールを作成するには、次の ldapmodify コマンドを実行します。
ldapmodify -a -h host -p port -D "cn=Directory Manager" -w password
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 staffnsManagedRoleDefinition オブジェクトクラスは、LDAPsubentry、nsRoleDefinition、および nsSimpleRoleDefinition の各オブジェクトクラスから継承されることに注意してください。
次のように ldapmodify コマンドを実行して、Bob のエントリを更新することによって、Bob というマーケティングスタッフメンバーにロールを割り当てます。
ldapmodify -D "cn=Directory Manager" -w secret -h host -p 389
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 属性を変更できると、管理されているロールに自身を追加したり削除したりできます。これを防ぐには、次の 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 host -p port -D "cn=Directory Manager" -w password
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 managersnsFilteredRoleDefinition オブジェクトクラスは、LDAPsubentry、nsRoleDefinition、および nsComplexRoleDefinition の各オブジェクトクラスから継承されることに注意してください。たとえば次のように、nsRoleFilter 属性は、ou=sales という組織に含まれ、下位組織を持つすべての従業員を検索するフィルタを指定します。
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=sales,ou=People,dc=example,dc=com
cn: Carla Fuentes
isManager: TRUE
...
nsRole: cn=ManagerFilter,ou=sales,ou=People,dc=example,dc=com
注 フィルタを適用したロールのフィルタ文字列には、任意の属性を使用できます。ただし、CoS メカニズムによって生成されるその他の仮想属性は使用できません (「CoS について」を参照)。
フィルタを適用したロールのメンバーがユーザーエントリである場合、ユーザーが自身をロールに追加したり削除したりできないように制限するには、フィルタを適用した属性を ACI (アクセス制御命令) で保護します。
入れ子のロール定義の例
入れ子のロール内に含めるロールを指定するには、nsRoleDN 属性を使用します。前述の例で作成したロールに含まれるマーケティングスタッフとセールスマネージャの両方を含むロールを作成するには、次のコマンドを使用します。
ldapmodify -a -h host -p port -D "cn=Directory Manager" -w password
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=comnsNestedRoleDefinition オブジェクトクラスは、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 定義のエントリ : 使用中の 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 よりもわかりやすくなります。
『Sun ONE Directory Server Deployment Guide』の第 4 章にある「Managing Attributes with Class of Service」は、CoS の各タイプを詳細に説明し、例と導入上の注意点を記載しています。各 CoS タイプに関連するオブジェクトクラスと属性については、「コマンド行からの CoS の管理」を参照してください。
CoS の制限事項
CoS 定義エントリとテンプレートエントリの作成と管理には、次のような制限事項があります。CoS 仮想属性の導入に関する制限事項の詳細については、『Sun ONE Directory Server Deployment Guide』の第 4 章にある「CoS Limitations」を参照してください。
CoS で生成された属性を使用する検索は、インデックスを使用しない検索となる : どの検索フィルタでも、仮想属性の有無を調べたり、 その値を比較したりできます。ただし、仮想属性にはインデックスを付けることができないため、CoS で生成された属性をフィルタコンポーネントで使用するとインデックスを使用しない検索となり、パフォーマンスがかなり低下します。
サブツリーの制限 : 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 セキュリティに関する注意事項については『Sun ONE Directory Server Deployment Guide』、コンソールを使用して 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 と定義されている場合だけです。
- 左側のリストで「テンプレート」タブをクリックします。テンプレートエントリの識別方法を選択し、対応するフィールドに必要事項を入力します。これにより、定義する 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 (アクセス制御命令) を定義してください。コマンド行から ACI を作成する手順については、第 6 章「アクセス制御の管理」を参照してください。
コマンド行からの CoS 定義のエントリの作成
すべての CoS 定義のエントリは、LDAPsubentry オブジェクトクラスを持ち、cosSuperDefinition オブジェクトクラスから継承されます。さらに、CoS の各タイプは、特定のオブジェクトクラスから継承され、対応する属性を含みます。次の表に、各タイプの CoS 定義エントリ に関連付けられたオブジェクトクラスと属性を一覧表示します。
表 5-2 CoS 定義エントリのオブジェクトクラスと属性
すべての cosAttribute は複数値を持ち、それぞれの値が CoS メカニズムによって生成される属性を定義します。
次の属性が CoS 定義のエントリ内で使用できます (属性については、『Sun ONE Directory Server Reference Manual』を参照)。
表 5-3 CoS 定義のエントリの属性
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=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 属性に複数の値を指定できます。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 テンプレートエントリに対して定義されます。
注 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 host -p port -D "cn=Directory Manager" -w password
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 host -p port -D "cn=Directory Manager" -w password \
-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 は、ターゲットエントリの manager 属性を使用して、CoS テンプレートエントリを識別するものです。テンプレートエントリはマネージャのユーザーエントリで、生成する属性の値を含んでいる必要があります。
次のコマンドは、cosIndirectDefinition オブジェクトクラスを含む間接 CoS 定義エントリを作成します。
ldapmodify -a -h host -p port -D "cn=Directory Manager" -w password
dn: cn=generateDeptNum,ou=People,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosIndirectDefinition
cosIndirectSpecifier: manager
cosAttribute: departmentNumber次に、テンプレートエントリに cosTemplate オブジェクトクラスを追加し、生成する属性が定義されていることを確認します。この例では、すべてのマネージャエントリはテンプレートです。
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
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 属性は、サーバー上に存在せず、ターゲットエントリの一部として返されるだけなので、ターゲットエントリの仮想属性となります。たとえば、Babs Jensen のマネージャを Carla Fuentes として定義した場合、このマネージャの部署番号は次のように表示されます。
ldapsearch -h host -p port -D "cn=Directory Manager" -w password \
-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 host -p port -D "cn=Directory Manager" -w password
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 内に指示子属性値を持つテンプレートエントリを検索します。この例では、Babs Jensen に B07 ビルが割り当てられていれば、住所は次のように表示されます。
ldapsearch -h host -p port -D "cn=Directory Manager" -w password \
-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
postalAddres: 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
objectlass: cosClassicDefinition
cosTemplateDn: cn=managerCOS,dc=example,dc=com
cosSpecifier: nsRole
cosAttribute: mailboxquota overrideCoS テンプレートの名前は、cosTemplateDn と、nsRole の値 (ロールの DN) の組み合わせである必要があります。次に例を示します。
dn:cn="cn=ManagerRole,ou=People,dc=example,dc=com",ou=People,
dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectlass: cosTemplate
mailboxquota: 1000000CoS テンプレートエントリは、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 ターゲットエントリも、検索や管理を簡単に実行できるように、同じ位置に置く必要があります。