ロールは、アプリケーションでより効率的かつ簡単に使用できるように設計された代替のグループ化メカニズムです。ロールはグループと同様に定義し、管理しますが、各メンバーエントリの生成されたロール属性は自動的にエントリのロールを示します。たとえば、アプリケーションでは、グループを選択してメンバーリストを参照しなくても、エントリのロールを読み取ることができます。
デフォルトでは、ロールの適用範囲は、その範囲が定義されているサブツリーに限定されます。ただし、入れ子のロールの範囲は拡張できます。ほかのサブツリーにあるロールを入れ子にしたり、ディレクトリの任意の場所のメンバーを含めたりすることができます。詳細については、「ロールの範囲を拡張する」および 「入れ子のロール定義の例」を参照してください。
この節では、ロールを安全に使用する方法とコマンド行からロールを管理する方法を説明します。
ロールを安全に使用するには、アクセス制御命令 (ACI) を設定して、該当する属性を保護する必要があります。たとえば、ユーザー A が、管理ロール MR を所有しているとします。管理ロールはスタティックグループと同じで、nsRoleDN 属性をエントリに追加することによって、各メンバーエントリにロールを明示的に割り当てます。MR ロールは、コマンド行からアカウントの無効化を使用して、ロックされています。つまり、ユーザー A の nsAccountLock 属性は「true」として計算されるので、ユーザー A はサーバーにバインドできません。ただし、ユーザーがバインド済みで、MR ロールに関して現在ロックされているという通知を受けたとします。ユーザーが nsRoleDN 属性に書き込みアクセスできないようにする ACI が存在しなければ、ユーザーは自身のエントリから nsRoleDN 属性を削除し、自身のロックを解除できます。
ユーザーが nsRoleDN 属性を削除できないようにするには、ACI を適用する必要があります。フィルタを適用したロールを使用する場合、ユーザーが属性を変更してフィルタが適用されたロールを放棄することを防ぐために、フィルタの一部を保護する必要があります。フィルタが適用されたロールで使用されている属性をユーザーが追加、削除、または変更できないようにする必要があります。同様に、フィルタ属性の値を計算する場合、フィルタ属性の値を変更できるすべての属性を保護する必要があります。入れ子のロールには、フィルタを適用したロールと管理ロールが含まれることがあるため、入れ子のロールに含まれる各ロールについても上記注意点を考慮する必要があります。
セキュリティー目的で ACI を設定する詳細な手順については、第 7 章「Directory Server のアクセス制御」を参照してください。
ロールは、ディレクトリ管理者がコマンド行ユーティリティーを使用してアクセスできるようにエントリに定義されます。ロールの作成が完了したら、次のようにロールにメンバーを割り当てます。
管理ロールのメンバーのエントリに、nsRoleDN 属性を含めます。
フィルタを適用したロールのメンバーは、nsRoleFilter 属性で指定したフィルタに一致するエントリとなります。
入れ子のロールのメンバーは、入れ子のロール定義エントリの nsRoleDN 属性で指定したロールのメンバーとなります。
すべてのロール定義は LDAPsubentry および nsRoleDefinition オブジェクトクラスから継承されます。次の例に、各ロールタイプに固有のその他のオブジェクトクラスと関連付けられた属性を示します。
マーケティング担当者全員のロールを作成するには、次の ldapmodify コマンドを使用します。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - 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 staff |
nsManagedRoleDefinition オブジェクトクラスは、LDAPsubentry、nsRoleDefinition 、および nsSimpleRoleDefinition オブジェクトクラスから継承されます。
Bob という名前のマーケティング担当者のメンバーにロールを割り当てるには、次のようにエントリを更新します。
$ ldapmodify -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - 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 属性を変更できるようにするが、nsManagedDisabledRole を追加または削除できないようにするには、次の 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 host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - 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 managers |
nsFilteredRoleDefinition オブジェクトクラスは、LDAPsubentry、nsRoleDefinition、および nsComplexRoleDefinition オブジェクトクラスから継承されます。nsRoleFilter 属性は、下位組織を持つ ou=sales 組織のすべての従業員を検索するフィルタを指定します。たとえば、次のように指定します。
$ 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=sales,ou=People,dc=example,dc=comcn: Carla Fuentes isManager: TRUE... nsRole: cn=ManagerFilter,ou=sales,ou=People, dc=example,dc=com |
フィルタを適用したロールのフィルタ文字列には、任意の属性を使用できます。ただし、CoS メカニズムによって生成される計算された属性は使用できません 。
フィルタを適用したロールのメンバーがユーザーエントリである場合、それらが自身をロールに追加または削除する機能を制限することができます。ACI によってフィルタを適用した属性を保護します。
入れ子のロール内に入れ子にするロールは nsRoleDN 属性を使用して指定します。前の例で作成したロールのマーケティング担当者と営業マネージャーのメンバーの両方を含むロールを作成するには、次のコマンドを使用します。
$ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - 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=com |
nsNestedRoleDefinition オブジェクトクラスは LDAPsubentry、nsRoleDefinition、および nsComplexRoleDefinition オブジェクトクラスから継承されます。nsRoleDN 属性には、マーケティングの管理ロールとセールスマネージャーのフィルタが適用されたロールの DN が含まれます。前述の例のユーザー Bob と Carla は、どちらもこの新しい入れ子のロールのメンバーになります。
このフィルタの範囲には、フィルタが存在するサブツリーと nsRoleScopeDN 属性の値以下のサブツリーであるデフォルトの範囲が含まれます。この例では、ManagerFilter が ou=sales,ou=People,dc=example,dc=com サブツリーにあります。このサブツリーを範囲に追加する必要があります。
Directory Server では、ロールの範囲をロール定義エントリのサブツリーを超えて拡張するための属性を使用できます。これは、nsRoleScopeDN という 1 つの値からなる属性で、既存のロールに追加する範囲の DN を含みます。nsRoleScopeDN 属性を追加できるのは、入れ子のロールだけです。「入れ子のロール定義の例」を参照してください。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
nsRoleScopeDN 属性により、あるサブツリーのロールの範囲を拡張して、別のサブツリーにエントリを含めることができます。たとえば、example.com ディレクトリツリーに次の 2 つのメインサブツリーがあるとします。 o=eng,dc=example,dc=com ( エンジニアリングサブツリー) および o=sales,dc=example,dc=com (販売サブツリー)。エンジニアリングサブツリーのユーザーには、販売サブツリーのロール (SalesAppManagedRole) で管理される販売アプリケーションに対するアクセス権が必要です。ロールの範囲を拡張するには、次を実行します。
エンジニアリングサブツリーのユーザーのロールを作成します。
たとえば、EngineerManagedRole のロールを作成します。この例では、管理されるロールを使用していますが、フィルタが適用されたロールや入れ子のロールであってもかまいません。
販売サブツリーに、たとえば SalesAppPlusEngNestedRole のような入れ子のロールを作成し、新たに作成した EngineerManagedRole と、元からある SalesAppManagedRole を格納します。
SalesAppPlusEngNestedRole に nsRoleScopeDN 属性を追加します。属性値には、追加するエンジニアリングサブツリーの範囲の DN を指定します。この例では、o=eng,dc=example,dc=com を指定します。
エンジニアリングユーザーには、SalesAppPlusEngNestedRole ロールにアクセスして販売アプリケーションにアクセスできるよう、適切なアクセス権を与える必要があります。さらに、ロールの範囲全体をレプリケートする必要があります。
拡張する範囲を入れ子のロールに制限することは、以前に、あるドメインのロールを管理していた管理者は、その他のドメインに既に存在するロールの使用権限しか持たないことを意味します。管理者はその他のドメインに任意のロールを作成することはできません。