8.2. ロールの使用
ロールは、前述のセクションで説明されている静的および動的グループを統一するエントリーグループ化メカニズムです。ロールは、アプリケーションにより効率的で使いやすいように設計されています。たとえば、アプリケーションはグループを選択し、複数のグループのメンバーリストを参照するのではなく、エントリー自体をクエリーしてメンバーであるロールのリストを取得できます。
8.2.1. ロールの概要
Red Hat には 2 種類のグループがあります。静的グループ には、有限で、定義されたメンバーのリストがあります。動的グループ は、フィルターを使用してどのエントリーがグループのメンバーかを認識するため、グループメンバーシップはグループフィルターの変更に一致するエントリーとして常に変更されます。(両方の種類グループが、「グループの使用」で説明されています。)
ロール はハイブリッドグループで、静的グループと動的グループの両方として機能します。グループを使用すると、エントリーはメンバーとしてグループエントリーに追加されます。ロールを使用すると、role 属性がエントリーに追加され、その属性はロールエントリー内のメンバーを自動的に識別するために使用されます。
ロール メンバー は、ロールを持つエントリーです。メンバーは、明示的に、または動的に指定できます。ロールのメンバーシップの指定方法は、ロールのタイプによって異なります。Directory Server は、以下の 3 種類のロールをサポートします。
- マネージドロール には、メンバーの明示的な列挙リストがあります。
- フィルターされたロール には、LDAP フィルターで指定される各エントリーに含まれる属性に応じて、エントリーがロールに割り当てられます。フィルターに一致するエントリーはロールを持ちます。
- ネストされたロール は、他のロールが含まれるロールです。
マネージドロールは、通常、静的グループで実行可能なものをすべて実行できます。ロールメンバーは、動的グループによるフィルタリングと同様に、フィルターされたロールを使用してフィルタリングできます。ロールはグループよりも使いやすく、実装に柔軟性が高まり、クライアントの複雑さが軽減されます。
ロールの作成時には、ユーザーがロールから追加できるか、ロールから削除できるかどうかを判断します。ロールおよびアクセス制御の詳細は、「セキュアなロールの使用」を参照してください。
注記
サーバーがクライアントアプリケーションに対して機能するため、Directory Server ではロールの評価がグループを評価するよりもリソース集約されます。ロールを使用すると、クライアントアプリケーションは
nsRole 属性を検索してロールのメンバーシップを確認することができます。nsRole 属性は、エントリーが属するロールを識別する計算属性です。nsRole 属性はエントリー自体に保存されません。クライアントアプリケーションの観点からは、メンバーシップを確認する方法は統一されており、サーバー側で実行されます。
ロールの使用に関する考慮事項は、『Red Hat Directory Server デプロイメントガイド』 で説明しています。
8.2.2. コマンドラインを使用したロールの管理
コマンドラインを使用して、ロールを表示、作成、および削除できます。
8.2.2.1. 管理ロールの作成
マネージドロールには、メンバーの明示的な列挙リストがあります。エントリーに
nsRoleDN 属性を追加して、管理ロールがエントリーに追加されます。
8.2.2.1.1. コマンドラインでの管理ロールの作成
ロールは、ITU X.509 標準で定義されている ldapsubentry オブジェクトクラスから継承されます。さらに、各管理ロールには、nsRoleDefinition オブジェクトクラスから継承する 2 つのオブジェクトクラスが必要です。
- nsSimpleRoleDefinition
- nsManagedRoleDefinition
管理ロールでは、任意の
description 属性も許可されます。
管理ロールのメンバーは、エントリーに
nsRoleDN 属性を持ちます。
この例では、マーケティング部門に割り当てることのできるロールを作成します。
-aオプションで ldapmodify を使用して、管理ロールエントリーを追加します。新しいエントリーには、nsManagedRoleDefinition オブジェクトクラスが含まれ、その後に LdapSubEntry、nsRoleDefinition、および nsSimpleRoleDefinition オブジェクトクラスを継承します。dn: cn=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
- ldapmodify を使用して、ロールをマーケティングスタッフメンバーに 1 つずつ割り当てます。
dn: cn=Bob,ou=people,dc=example,dc=com changetype: modify add: nsRoleDN nsRoleDN: cn=Marketing,ou=people,dc=example,dc=com
エントリーのnsRoleDN属性は、エントリーが管理ロール cn=Marketing,ou=people,dc=example,dc=com のメンバーであることを示します。
8.2.2.2. フィルター設定されたロールの作成
エントリーは、エントリーがロールに定義されている特定の属性を持つかどうかに応じて、フィルターされたロールに割り当てられます。ロール定義は、ターゲット属性の LDAP フィルターを指定します。フィルターに一致するエントリーは、ロールを持ちます (ロールのメンバーです)。
8.2.2.2.1. コマンドラインでフィルターされたロールの作成
ロールは、ITU X.509 標準で定義されている ldapsubentry オブジェクトクラスから継承されます。さらに、フィルターが設定された各ロールには、nsRoleDefinition オブジェクトクラスから継承される 2 つのオブジェクトクラスが必要です。
- nsComplexRoleDefinition
- nsFilteredRoleDefinition
フィルタリングされたロールエントリーには、ロールメンバーを判断するために LDAP フィルターを定義する
nsRoleFilter 属性も必要です。任意で、ロールは description 属性を取ることができます。
フィルタリングされたロールのメンバーは、
nsRoleFilter 属性で指定されたフィルターに一致するエントリーです。
この例では、すべての営業マネージャーに適用される、フィルターが設定されたロールを作成します。
-aオプションを指定して ldapmodify を実行して、新規エントリーを追加します。- フィルターされたロールエントリーを作成します。ロールエントリーには nsFilteredRoleDefinition オブジェクトクラスがあり、これは、オブジェクトクラス LdapSubEntry、nsRoleDefinition、および nsComplexRoleDefinition から継承されます。nsRoleFilter 属性は、sales managers の値が含まれる
o(組織) 属性にフィルターを設定します。dn: cn=SalesManagerFilter,ou=people,dc=example,dc=com changetype: add objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: SalesManagerFilter nsRoleFilter: o=sales managers Description: filtered role for sales managers
以下のエントリーはフィルター (sales managers 値を持つ
o 属性) と一致するため、このフィルターが自動的に設定されたロールのメンバーになります)。
dn: cn=Pat Smith,ou=people,dc=example,dc=com objectclass: person cn: Pat sn: Smith userPassword: secret o: sales managers
8.2.2.3. ネスト化されたロールの作成
ネストされたロールは、他のロールが含まれるロールです。ネストされたロールを作成する前に、別のロールが存在している必要があります。ネストされたロール内でネストされたロールは、
nsRoleDN 属性を使用して指定します。
8.2.2.3.1. コマンドラインでのネスト化されたロールの作成
ロールは、ITU X.509 標準で定義されている ldapsubentry オブジェクトクラスから継承されます。さらに、ネスト化された各ロールには、nsRoleDefinition オブジェクトクラスから継承する 2 つのオブジェクトクラスが必要です。
- nsComplexRoleDefinition
- nsNestedRoleDefinition
ネストされたロールエントリーには、コンテナーロール内でネスト化するロールを識別するための
nsRoleDN 属性も必要です。任意で、ロールは description 属性を取ることができます。
ネスト化されたロールのメンバーは、ネストされたロール定義エントリーの
nsRoleDN 属性で指定されたロールのメンバーです。
この例では、管理されたマーケティングのロールとフィルター処理されたセールスマネージャーのロールから 1 つのロールを作成します。
-aオプションを指定して ldapmodify を実行して、新規エントリーを追加します。- ネストされたロールエントリーを作成します。ネストされたロールには 4 つのオブジェクトクラスがあります。
- nsNestedRoleDefinition
- LDAPsubentry (継承)
- nsRoleDefinition (継承)
- nsComplexRoleDefinition (継承)
nsRoleDN属性には、マーケティング管理ロールと営業マネージャーのフィルターが設定されたロールの両方の DN が含まれます。dn: cn=MarketingSales,ou=people,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsNestedRoleDefinition cn: MarketingSales nsRoleDN: cn=SalesManagerFilter,ou=people,dc=example,dc=com nsRoleDN: cn=Marketing,ou=people,dc=example,dc=com
以前の例のユーザー Bob および Pat はどちらも、この新しいネストされたロールのメンバーです。
8.2.2.4. コマンドラインでエントリーのロールの表示
ロール割り当ては、コマンドラインから自動的に返されません。
nsRole 属性は操作の属性です。LDAP では、操作属性を明示的に要求する必要があります。デフォルトでは、エントリーのスキーマに通常の属性が返されません。単一操作属性の一覧を表示することで、明示的に要求するか、
+ を使用して結果オブジェクトの操作属性をすべて出力することができます。たとえば、この ldapsearch コマンドは、エントリーの通常の属性に加えて、uid=user_name がメンバーであるロールのリストを返します。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(uid=user_name)"” \* nsRole dn: uid=user_name,ou=people,dc=example,dc=com ... nsRole: cn=Role for Managers,dc=example,dc=com nsRole: cn=Role for Accounting,dc=example,dc=com
8.2.2.5. ロールの削除の概要
ロールを削除するとロールエントリーが削除されますが、各ロールメンバーの
nsRoleDN 属性は削除されません。各ロールメンバーの nsRoleDN 属性を削除するには、Referential Integrity プラグインを有効にし、nsRoleDN 属性を管理するように設定します。Referential Integrity プラグインの詳細は、5章参照整合性の維持を参照してください。
8.2.3. LDAP ブラウザーを使用したディレクトリーサーバーでのロールの管理
ロールは、静的グループと動的グループを統合するグループ化メカニズムです。
8.2.3.1. LDAP ブラウザーでのロールの作成
Web コンソールで LDAP Browser ウィザードを使用して、Red Hat ディレクトリーサーバーエントリーのロールを作成できます。
前提条件
- Web コンソールへのアクセス。
- Red Hat Directory Server に存在する親エントリー。
手順
- Web コンソールにログインし、Red Hat Directory Server をクリックします。
- Web コンソールが Red Hat Directory Server インターフェイスをロードしたら、LDAP browser をクリックします。
- LDAP エントリーを選択し、Options メニューをクリックします。
- ドロップダウンメニューから New を選択し、Create a new role をクリックします。
- ウィザードの手順に従い、各手順を完了したら Next ボタンをクリックします。
- ロールを作成するには、Create Role の手順でロールの設定を確認し、Create ボタンをクリックします。Back ボタンをクリックしてロールの設定を変更するか、Cancel ボタンをクリックしてロールの作成をキャンセルできます。
- ウィザードウィンドウを閉じるには、Finish ボタンをクリックします。
検証
- LDAP エントリーを展開し、新しいロールがエントリーパラメーターに表示されることを確認します。
8.2.3.2. LDAP ブラウザーでのロールの変更
Web コンソールで LDAP Browser を使用して、Red Hat Directory Server エントリーのロールパラメーターを変更できます。
前提条件
- Web コンソールへのアクセス。
- Red Hat Directory Server に存在する親エントリー。
手順
- Web コンソールにログインし、Red Hat Directory Server をクリックします。
- Web コンソールが Red Hat Directory Server インターフェイスをロードしたら、LDAP browser をクリックします。
- LDAP エントリーを展開し、変更するロールを選択します。
- Options メニューをクリックし、Edit を選択してロールのパラメーターを変更するか、Rename を選択してロールの名前を変更します。
- ウィザードウィンドウで必要なパラメーターを変更し、LDIF Statements の手順が表示されるまで各手順を完了して Next をクリックします。
- 更新されたパラメーターを確認し、Modify Entry または Change Entry Name をクリックします。
- ウィザードウィンドウを閉じるには、Finish ボタンをクリックします。
検証
- LDAP エントリーを展開し、更新されたパラメーターがロールにリストされていることを確認します。
8.2.3.3. LDAP ブラウザーでのロールの削除
Web コンソールで LDAP Browser を使用して、Red Hat Directory Server エントリーからロールを削除できます。
前提条件
- Web コンソールへのアクセス。
- Red Hat Directory Server に存在する親エントリー。
手順
- Web コンソールにログインし、Red Hat Directory Server をクリックします。
- Web コンソールが Red Hat Directory Server インターフェイスをロードしたら、LDAP browser をクリックします。
- LDAP エントリーを展開し、削除するロールを選択します。
- Options メニューを開き、Delete を選択します。
- 削除するロールに関するデータを確認し、Deletion の手順に到達するまで Next ボタンをクリックします。
- スイッチを Yes, I’m sure の位置に切り替え、Delete ボタンをクリックします。
- ウィザードウィンドウを閉じるには、Finish ボタンをクリックします。
検証
- LDAP エントリーを展開し、ロールがエントリーの詳細に含まれていないことを確認します。
8.2.4. セキュアなロールの使用
すべてのロールがセキュリティーコンテキストでの使用に適しているわけではありません。新しいロールを作成するときは、そのロールをエントリーに割り当てたり、エントリーから削除したりするのがどれほど簡単かを考慮してください。ユーザーが自身をロールに簡単に追加または削除できることが適切な場合があります。たとえば、Mountain Biking と呼ばれるグループロールがある場合は、関心のあるユーザーは自身を追加したり、それ自体を簡単に削除したりできます。
ただし、セキュリティー状況によっては、このようなオープンなロールを持つことは不適切です。潜在的なセキュリティーリスクの 1 つは、ロールを非アクティブ化してユーザー アカウントを非アクティブ化することです。非アクティブなロールには、接尾辞に特別な ACI が定義されます。管理者により、ロールを自由に追加および削除することが許可されている場合、状況によっては、アカウントがロックされないように、非アクティブなロールから自身を削除できる場合があります。
たとえば、ユーザー A には管理ロール MR があります。MR ロールは、アカウントの非アクティブ化を使用してロックされています。これは、
nsAccountLock 属性はそのユーザーの true として計算されるため、ユーザー A はサーバーにバインドできないことを意味します。ただし、ユーザー A がすでに Directory Server にバインドされ、MR ロールでロックされたことに気付くと、ユーザーは自分のエントリーから nsRoleDN 属性を削除して、自身を妨げる ACI がない場合は自身のロックを解除します。
ユーザーが
nsRoleDN 属性を削除しないようにするには、使用されているロールのタイプに応じて以下の ACI を使用します。
- マネージドロール。管理ロールのメンバーであるエントリーの場合は、以下の ACI を使用して適切な
nsRoleDNを削除して、ユーザーが自身をロック解除しないようにします。aci: (targetattr="nsRoleDN") (targattrfilters= add=nsRoleDN:(!(nsRoleDN=cn=AdministratorRole,dc=example,dc=com)), del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=example,dc=com))) (version3.0;acl "allow mod of nsRoleDN by self but not to critical values"; allow(write) userdn=ldap:///self;)
- フィルターが設定されたロール。フィルターに含まれる属性は保護されるべきです。これにより、ユーザーは属性を変更してフィルターされたロールを再取得できません。ユーザーは、フィルター処理されたロールによって使用される属性を追加、削除、または変更することを許可されるべきではありません。フィルター属性の値が計算された場合、フィルター属性の値を変更できるすべての属性を同じ方法で保護する必要があります。
- ネストされたロール。ネストされたロールはフィルターされたロールと管理対象のロールで設定されているため、両方の ACI はネストされたロールを設定するロールの属性 (
nsRoleDNまたはその他) の変更について考慮する必要があります。
アカウントのアクティブ化に関する詳しい情報は、「ユーザーおよびロールの手動による非アクティブ化」を参照してください。
