Red Hat Summit第2章 アクセス制御の管理
Red Hat Directory Server で接尾辞およびエントリーに対して特定のアクションを実行できるユーザーを定義する方法を説明します。当該タスクは、アクセス制御命令 (ACI) によって制御されます。さまざまな ACI タイプ、ACI のユースケース、バインドルール、およびエントリーのアクセス権を確認する方法を説明します。
2.1. アクセス制御命令の管理
Directory Server が要求を受信すると、バインド操作でユーザーによって提供される認証情報、およびディレクトリーに定義されているアクセス制御命令 (ACI) を使用し、要求されたエントリーまたは属性へのアクセスを許可または拒否します。サーバーは、read、write、search、compare などのアクションのパーミッションを許可または拒否できます。ユーザーに付与されたパーミッションレベルは、指定される認証情報によって異なります。
Directory Server のアクセス制御により、ACI が適用される場合に正確なルールを設定できます。
- ディレクトリー全体、サブツリー、または特定のエントリーの場合
- 特定のユーザー、特定のユーザーまたはグループに属するすべてのユーザー、またはディレクトリー内のすべてのユーザーの場合
IP アドレス、IP 範囲、または DNS 名などの特定の場所。
ロードバランサーは場所固有のルールに影響を及ぼす可能性があることに注意してください。
複雑な ACI の読み取りと理解は難しくなります。1 つの複雑な ACI の代わりに、同じ効果を達成するために複数の単純なルールを作成できます。ただし、ACI が多いほど、ACI 処理のコストも増加します。
2.1.1. ACI 配置
Directory Server は、アクセス制御命令 (ACI) をディレクトリーエントリーの複数値 aci 操作属性に保存します。ACI を設定するには、aci 属性を対応するディレクトリーエントリーに追加します。Directory Server は ACI を適用します。
ACI を含むエントリー (子エントリーがない場合) にのみ適用されます。たとえば、クライアントが
uid=user_name,ou=People,dc=example,dc=comオブジェクトへのアクセスを必要とし、ACI がdc=example,dc=comにのみ設定されており、子エントリーには設定されていない場合は、この ACI のみが適用されます。注記addパーミッションを持つ ACI は、今後作成される子エントリーにも適用されます。ACI を含むエントリーと、(子エントリーがある場合は) その下のすべてのエントリーへ。これにより、サーバーが指定のエントリーに対するアクセスパーミッションを評価すると、リクエストされたディレクトリー接尾辞と、エントリー自体の ACI との間のすべてのエントリーについて ACI を検証します。
たとえば、ACI は
dc=example,dc=comおよびou=People,dc=example,dc=comエントリーに設定されます。ACI が設定されていないuid=user_name,ou=People,dc=example,dc=comオブジェクトにクライアントがアクセスする場合、Directory Server はまずou=People,dc=example,dc=comエントリー上の ACI を検証します。この ACI がアクセスを許可する場合は、評価は停止し、アクセスを許可します。そうでない場合は、Directory Server はou=People,dc=example,dc=com上の ACI を検証します。この ACI がクライアントを正常に承認すると、オブジェクトにアクセスできます。
rootDSE エントリーに設定された ACI は、このエントリーにのみ適用されます。
エントリーで作成された ACI は、そのエントリーに直接適用するのではなく、以下のサブツリーの一部のエントリーまたはすべてのエントリーに適用できます。この方法の利点は、一般的な ACI をディレクトリーツリーの上位において、下位にあるエントリーに影響を与えることができることです。たとえば、inetOrgPerson オブジェクトクラスを含むエントリーをターゲットにする ACI は、organizationalUnit エントリーまたは locality エントリーのレベルで作成できます。
一般的なルールを高レベルのブランチポイントに配置し、ディレクトリーツリー内の ACI の数を最小限にします。より具体的なルールの範囲を制限するには、できるだけ早くリーフエントリーに配置します。
2.1.2. ACI の構造
aci 属性は以下の構文を使用します。
(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)
(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)-
target_ruleは、アクセスを制御するためのエントリー、属性、またはエントリーと属性のセットを指定します。 -
version 3.0は、アクセス制御命令 (ACI) バージョンを特定する必須文字列です。 -
acl "ACL name"は、ACI を記述する名前または文字列を設定します。 -
permission_ruleは、readまたはwriteなど、どの権限を許可または拒否するかを設定します。 -
bind_rulesは、アクセスを許可または拒否するために、バインド時に一致するルールを指定します。
パーミッションとバインドルールのペアはアクセス制御ルールと呼ばれます。
特定のターゲットに複数のアクセス制御を効率的に設定するには、ターゲットごとに複数のアクセス制御ルールを設定します。
(target_rule)(version 3.0; acl "ACL_name"; permission_rule bind_rules; permission_rule bind_rules; ... ;)
(target_rule)(version 3.0; acl "ACL_name"; permission_rule bind_rules; permission_rule bind_rules; ... ;)2.1.3. ACI 評価
特定のエントリーに対するアクセス権を評価するには、サーバーによりエントリー自体に存在するアクセス制御命令 (ACI) のリストと、親エントリーにある ACI のリストが Directory Server に保存されている最上位のエントリーに再び作成されます。ACI は、特定のインスタンス用のデータベース全体で評価されますが、異なるインスタンスもすべて評価されます。
Directory Server は、ディレクトリーツリー内の配置ではなく、ACI のセマンティクスに基づいてこのリストを評価します。これは、ディレクトリーツリーのルートに近い ACI が、ディレクトリーツリーのリーフに近い ACI よりも優先されないことを意味しています。
Directory Server では、ACI の deny パーミッションは allow パーミッションよりも優先されます。たとえば、ディレクトリーのルートレベルで書き込みパーミッションを拒否する場合は、他の ACI がこのパーミッションを付与していても、ユーザーはディレクトリーに書き込むことができません。特定のユーザーにディレクトリーへの書き込みパーミッションを付与するには、ユーザーがそのディレクトリーに書き込むことができるように、元の拒否ルールに例外を追加する必要があります。
ACI を改善するには、deny ルールの代わりに、粒度の細かい allow ルールを使用します。
2.1.4. ACI の制限
アクセス制御命令 (ACI) を設定する場合は、以下の制限が適用されます。
ディレクトリーデータベースが複数のサーバーに分散されている場合は、ACI で使用できるキーワードに以下の制限が適用されます。
groupdnキーワードを使用したグループエントリーに依存する ACI は、グループエントリーと同じサーバーに配置する必要があります。グループが動的の場合、グループのすべてのメンバーに、サーバーのエントリーが必要です。静的グループのメンバーエントリーは、リモートサーバーに配置できます。
-
rolednキーワードを使用したロール定義に依存する ACI は、ロール定義エントリーと同じサーバーに配置する必要があります。ロールを持つすべてのエントリーは、同じサーバーに配置する必要があります。
ただし、ターゲットエントリーに保存されている値を、たとえば
userattrキーワードを使用して、バインドユーザーのエントリーに保存されている値と一致させることができます。この場合、通常、バインドユーザーに ACI を格納するサーバーにエントリーがない場合でも、アクセスが評価されます。以下の ACI キーワードでは、Class of Service (CoS) 属性などの仮想属性を使用することはできません。
-
targetfilter -
targattrfilters -
userattr
-
- アクセス制御ルールは、ローカルサーバーでのみ評価されます。たとえば、ACI キーワードの LDAP URL にサーバーのホスト名を指定すると、URL は無視されます。
2.1.5. Directory Server がレプリケーショントポロジーで ACI を処理する方法
アクセス制御命令 (ACI) は、エントリーの aci 属性に保存されます。したがって、ACI を含むエントリーが複製されたデータベースの一部である場合、ACI は複製されます。
ACI は、受信 LDAP 要求を解決するサーバーで常に評価されます。コンシューマーサーバーが更新要求を受け取ると、サプライヤーサーバーに参照を返してから、その要求がサプライヤーでサービスを提供できるかどうかを評価します。
2.1.6. ACI の表示、追加、削除、および更新
ldapsearch ユーティリティーを使用して検索でき、ldapmodify ユーティリティーを使用してアクセス制御命令 (ACI) を追加、削除、および更新できます。
ACI の表示
たとえば、dc=example,dc=com およびサブエントリーに設定された ACI を表示するには、以下のコマンドを実行します。
ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b "dc=example,dc=com" -s sub '(aci=*)' aci
# ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b "dc=example,dc=com" -s sub '(aci=*)' aciACI の追加
たとえば、ACI を ou=People,dc=example,dc=com エントリーに追加するには、次のコマンドを実行します。
ACI の削除
ACI を削除するには、以下を実行します。
エントリーに 1 つの
aci属性のみが設定されているか、エントリーからすべての ACI を削除する場合は、次のコマンドを実行します。ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x
# ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -x dn: ou=People,dc=example,dc=com changetype: delete delete: aciCopy to Clipboard Copied! Toggle word wrap Toggle overflow 複数の ACI がエントリーに存在し、特定の ACI を削除する場合は、実際の ACI を指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ACI の更新
ACI を更新するには、以下を実行します。
- 既存の ACI を削除します。
- 更新された設定で新しい ACI を追加します。
2.1.7. ACI ターゲットの定義
アクセス制御命令 (ACI) のターゲットルールは、Directory Server が ACI を適用するエントリーを定義します。ターゲットを設定しない場合、ACI は aci 属性が含まれるエントリーと以下のエントリーに適用されます。
ACI では、以下の強調表示された部分がターゲットルールになります。
(target_rule)(version 3.0; acl "ACL_name"; permission_rule bind_rules;)
(target_rule)(version 3.0; acl "ACL_name"; permission_rule bind_rules;)複雑な ACI の場合、Directory Server は ACI で異なるキーワードを持つ複数のターゲットルールをサポートします。
(target_rule_1)(target_rule_2)(...)(version 3.0; acl "ACL_name"; permission_rule bind_rules;)
(target_rule_1)(target_rule_2)(...)(version 3.0; acl "ACL_name"; permission_rule bind_rules;)複数のターゲットルールを指定した場合に、その順番は関係ありません。以下のキーワードはそれぞれ、ACI で一度だけ使用できることに注意してください。
-
target -
targetattr -
targetattrfilters -
targetfilter -
target_from -
target_to
2.1.7.1. ターゲットルールの構文
ターゲットルールの一般的な構文は、以下のとおりです。
(keyword comparison_operator "expression")
(keyword comparison_operator "expression")-
keyword: ターゲットのタイプを設定します。 comparison_operator: 有効な値は=および!=で、ターゲットが式で指定されたオブジェクトであるかどうかを示します。警告セキュリティー上の理由から、Red Hat では
!=演算子を使用しないことを推奨しています。これは、指定された操作が他のすべてのエントリーまたは属性に対して許可されるためです。以下に例を示します。(targetattr != "userPassword");(version 3.0; acl "example"); allow (write) ... );
(targetattr != "userPassword");(version 3.0; acl "example"); allow (write) ... );Copy to Clipboard Copied! Toggle word wrap Toggle overflow 前の例では、ACI を設定する識別名 (DN) の下にある
userPassword属性以外の属性の設定、更新、または削除を行うことができます。ただし、これによりユーザーは、たとえば、この属性への書き込みアクセスを許可するaci属性を追加することもできます。-
expression: ターゲットを設定し、引用符で囲む必要があります。式自体は使用するキーワードによって異なります。
2.1.7.2. ディレクトリーエントリーのターゲット
識別名 (DN) およびその下のエントリーに基づいてアクセスを制御するには、アクセス制御命令 (ACI) の target キーワードを使用します。target キーワードを使用するターゲットルールは、DN を式として取ります。
(target comparison_operator "ldap:///distinguished_name")
(target comparison_operator "ldap:///distinguished_name")
対象となる DN またはその上位 DN に、target キーワードで ACI を設定する必要があります。たとえば、ou=People,dc=example,dc=com をターゲットにする場合、ACI を ou=People,dc=example,dc=com または dc=example,dc=com のいずれかに設定する必要があります。
例2.1 target キーワードの使用
ou=People,dc=example,dc=com エントリーに保存されているユーザーを有効にして、独自のエントリー内の全属性を検索および表示するには、以下を実行します。
target キーワードでのワイルドカードの使用
* ワイルドカード文字ターゲットに複数のエントリーを使用できます。
以下のターゲットルールの例は、uid 属性が a の文字で始まる値に設定される ou=People,dc=example,dc=com のすべてのエントリーと一致します。
(target = "ldap:///uid=a*,ou=People,dc=example,dc=com")
(target = "ldap:///uid=a*,ou=People,dc=example,dc=com")ワイルドカードの位置に応じて、ルールは属性値だけでなく、完全な DN にも適用されます。そのため、ワイルドカードを DN の一部の代わりに使用できます。
例2.2 ワイルドカードを使用したディレクトリーエントリーのターゲット
次のルールは、dc=example,dc=com エントリー自体に格納されているエントリーだけでなく、dc=example,dc=com ツリー内のすべての uid 属性が一致するエントリーを対象とします。
(target = "ldap:///uid=user_name*,dc=example,dc=com")
(target = "ldap:///uid=user_name*,dc=example,dc=com")以前のターゲットルールは、以下のような複数のエントリーと一致します。
-
uid=user_name,dc=example,dc=com -
uid=user_name,ou=People,dc=example,dc=com -
uid=user_name2,dc=example,dc=com
Directory Server は、DN の接尾辞部分でのワイルドカードをサポートしません。たとえば、ディレクトリーの接尾辞が dc=example,dc=com の場合、この接尾辞では、(target = "ldap:///dc=*.com") などのようにワイルドカードを含むターゲットを使用できません。
2.1.7.3. ターゲット属性
アクセス制御命令 (ACI) のアクセスを特定の属性に制限するには、targetattr キーワードを使用します。たとえば、このキーワードは以下を定義します。
- 読み取り操作では、どの属性がクライアントに返されるか
- 検索操作では、どのような属性が検索されるのか
- 書き込み操作では、どの属性がオブジェクトに書き込むことができるか
- add 操作では、新規オブジェクトの作成時に追加できる属性
特定の状況では、targetattr キーワードを使用して、他のターゲットキーワードを targetattr と組み合わせることで、ACI をセキュアにすることができます。ターゲットルールの高度な使用方法 を参照してください。
read および search 操作では、属性はデフォルトではターゲットになりません。targetattr キーワードのない ACI は、add または delete などの完全なエントリーに影響する権限を持つ ACI にのみ役立ちます。
targetattr キーワードを使用するターゲットルールで複数の属性を分離するには、|| を使用します。
(targetattr comparison_operator "attribute_1 || attribute_2 || ...")
(targetattr comparison_operator "attribute_1 || attribute_2 || ...")式に設定された属性はスキーマに定義する必要があります。
式に指定される属性は、ACI の作成先となるエントリーと、さらにターゲットルールによって制限されない場合は、それ以下のすべてのエントリーに適用されます。
例2.3 targetattr キーワードの使用
dc=example,dc=com に保存されているユーザーとすべてのサブエントリーで、独自のエントリー内の userPassword 属性を更新するには、以下を実行します。
targetattr キーワードでのワイルドカードの使用
* ワイルドカード文字を使用すると、たとえば、すべての属性をターゲットにすることができます。
(targetattr = "*")
(targetattr = "*")
セキュリティー上の理由から、targetattr ではワイルドカードを使用しないでください。これは、操作属性を含むすべての属性へのアクセスが許可されるためです。たとえば、ユーザーがすべての属性を追加または変更できると、ユーザーは追加の ACI を作成し、独自の権限を増やす可能性があります。
2.1.7.4. LDAP フィルターを使用したエントリーと属性の対象
特定の基準に一致するエントリーのグループを対象にするには、LDAP フィルターで targetfilter キーワードを使用します。
(targetfilter comparison_operator "LDAP_filter")
(targetfilter comparison_operator "LDAP_filter")フィルター式は、標準の LDAP 検索フィルターです。
例2.4 targetfilter キーワードの使用
department 属性が Engineering または Sales に設定されているすべてのエントリーを変更するために、cn=Human Resources,dc=example,dc.com グループのメンバーにパーミッションを付与するには、以下を実行します。
targetfilter キーワードはエントリー全体を対象にします。これを targetattr キーワードと組み合わせると、アクセス制御命令 (ACI) はターゲットエントリーの属性のサブセットにのみ適用されます。フィルターに一致するエントリーの特定の属性をターゲットにする を参照してください。
LDAP フィルターは、ディレクトリーに分散されるエントリーおよび属性をターゲットにする場合に便利です。ただし、フィルターにはアクセスを管理するオブジェクトの名前を直接付けないため、結果が予測できないことがあります。フィルターが設定された ACI がターゲットとするエントリーのセットは、属性が追加または削除される際に変更する可能性が高くなります。したがって、ACI で LDAP フィルターを使用する場合は、ldapsearch 操作などで同じフィルターを使用して、正しいエントリーおよび属性を対象としていることを確認してください。
targetfilter キーワードでのワイルドカードの使用
targetfilter キーワードは、標準の LDAP フィルターと同様にワイルドカードをサポートします。たとえば、値が adm で始まるすべての uid 属性をターゲットにするには、次のコマンドを実行します。
(targetfilter = "(uid=adm*) ...)
(targetfilter = "(uid=adm*) ...)2.1.7.5. LDAP フィルターを使用した属性値のターゲット
アクセス制御を使用すると、属性の特定値を対象にできます。つまり、ある属性の値がアクセス制御命令 (ACI) で定義されている基準を満たしていれば、その属性に対してパーミッションを付与したり、拒否したりすることができるのです。属性の値に基づいてアクセスを許可または拒否する ACI は、値ベースの ACI と呼ばれます。これは、ADD および DEL 操作にのみ適用されます。検索権限を持つユーザーは、特定の値で制限できません。
値ベースの ACI を作成するには、以下の構文で targattrfilters キーワードを使用します。
1 つの属性とフィルターの組み合わせが含まれる操作の場合:
(targattrfilters="operation=attribute:filter")
(targattrfilters="operation=attribute:filter")Copy to Clipboard Copied! Toggle word wrap Toggle overflow 複数の属性とフィルターの組み合わせのある操作の場合:
(targattrfilters="operation=attribute_1:filter_1 && attribute_2:filter_2 ... && attribute_m:filter_m")
(targattrfilters="operation=attribute_1:filter_1 && attribute_2:filter_2 ... && attribute_m:filter_m")Copy to Clipboard Copied! Toggle word wrap Toggle overflow 複数の属性とフィルターを組み合わせた 2 つの操作の場合。
(targattrfilters="operation_1=attribute_1_1:filter_1_1 && attribute_1_2:filter_1_2 ... && attribute_1_m:filter_1_m , operation_2=attribute_2_1:filter_2_1 && attribute_2_2:filter_2_2 ... & attribute_2_n:filter_2_n ")
(targattrfilters="operation_1=attribute_1_1:filter_1_1 && attribute_1_2:filter_1_2 ... && attribute_1_m:filter_1_m , operation_2=attribute_2_1:filter_2_1 && attribute_2_2:filter_2_2 ... & attribute_2_n:filter_2_n ")Copy to Clipboard Copied! Toggle word wrap Toggle overflow
上記の構文の例では、オペレーションを add または del のいずれかに設定できます。attribute:filter の組み合わせは、フィルターと、フィルターが適用される属性を設定します。
以下では、フィルターを一致させる方法を説明します。
- エントリーを作成する際に、新しいエントリーの属性にフィルターが適用されると、その属性の各インスタンスがフィルターに一致する必要があります。
- エントリーとフィルターを削除するとエントリーの属性に適用される場合、その属性の各インスタンスはフィルターと一致する必要があります。
-
エントリーを変更し、操作が属性を追加する場合は、その属性に適用される
addフィルターが一致している必要があります。 -
操作によって属性が削除される場合、その属性に適用される
delフィルターが一致する必要があります。エントリー内にすでに存在する属性の個々の値が置き換えられる場合、addフィルターとdelフィルターの両方が一致する必要があります。
例2.5 targattrfilters キーワードの使用
ユーザーによる独自のエントリーへの Admin ロール以外の任意のロールの追加、および telephone 属性 (値が 123 接頭辞で始まる限り) の追加を可能にする ACI を作成するには、以下を実行します。
2.1.7.6. ソースおよび宛先 DN のターゲット
特定の状況では、管理者がディレクトリーエントリーを移動できるようにします。アクセス制御命令 (ACI) で target_from および target_to キーワードを使用すると、ユーザーを有効にしなくても、操作の送信元および宛先を指定できます。
- ACI に設定される別のソースからエントリーを移動します。
- エントリーを ACI のセットとして別の宛先に移動するには、以下のコマンドを実行します。
- ソースの識別名 (DN) から既存のエントリーを削除します。
- 宛先 DN に新規エントリーを追加するには、以下を行います。
例2.6 target_from および target_to キーワードの使用
uid=user,dc=example,dc=com アカウントがユーザーアカウントを cn=staging,dc=example,dc=com エントリーから cn=people,dc=example,dc=com に移動するようにするには、以下を実行します。
ACI は、それらが定義されているサブツリーにのみ適用されます。前の例では、ACI は dc=example,dc=com サブツリーにのみ適用されます。
target_from または target_to キーワードが設定されていない場合は、ACI がソースまたは宛先と一致します。
2.1.8. ターゲットルールの高度な使用方法
複数のキーワードを組み合わせることで、複雑なターゲットルールを作成できます。このセクションでは、ターゲットルールの高度な使用例を紹介します。
2.1.8.1. グループの作成およびメンテナンスへのパーミッションの委譲
特定の状況では、管理者はパーミッションを他のアカウントまたはグループに委譲する必要があることがあります。ターゲットキーワードを組み合わせることで、この要求を解決するセキュアなアクセス制御命令 (ACI) を作成できます。
例2.7 グループの作成およびメンテナンスへのパーミッションの委譲
uid=user,ou=People,dc=example,dc=com" アカウントが ou=groups,dc=example,dc=com エントリーでグループを作成および更新できるようにするには、以下を実行します。
前述の例は、セキュリティー上の理由から、特定の制限を追加します。uid=test,ou=People,dc=example,dc=com ユーザー:
-
topおよびgroupOfUniqueNamesオブジェクトクラスを含む必要があるオブジェクトを作成できます。 -
accountなどの追加のオブジェクトクラスを追加できません。たとえば、ローカル認証に Directory Server アカウントを使用する場合、rootユーザーの場合は0など、無効なユーザー ID を持つ新しいユーザーを作成できなくなります。
targetfilter ルールは、ACI エントリーが groupofuniquenames オブジェクトクラスを持つエントリーにのみ適用され、targetattrfilter ルールは、他のオブジェクトクラスが追加されないようにします。
2.1.8.2. エントリーと属性の両方をターゲットに設定
target は、識別名 (DN) に基づいてアクセスを制御します。ただし、ワイルドカードと targetattr キーワードを組み合わせて使用する場合は、エントリーと属性の両方をターゲットにすることができます。
例2.8 エントリーと属性の両方をターゲットに設定
uid=user,ou=People,dc=example,dc.com ユーザーが、dc=example,dc=com サブツリー内のすべての組織単位でグループのメンバーを読み取り、検索できるようにするには、以下を実行します。
2.1.8.3. フィルターに一致するエントリーの特定の属性をターゲットにする
2 つのターゲットルールで targetattr および targetfilter キーワードを組み合わせる場合は、フィルターに一致するエントリーの特定の属性をターゲットにすることができます。
例2.9 フィルターに一致するエントリーの特定の属性をターゲットにする
department 属性が Engineering に設定されているすべてのエントリーの jpegPhoto 属性および manager 属性を cn=Engineering Admins,dc=example,dc=com グループのメンバーが変更できるようにするには、以下を実行します。
2.1.8.4. 単一ディレクトリーエントリーのターゲット設定
単一ディレクトリーエントリーを対象にするには、targetattr および targetfilter キーワードを組み合わせます。
例2.10 単一ディレクトリーエントリーのターゲット設定
uid=user,ou=People,dc=example,dc=com ユーザーが u=Engineering,dc=example,dc=com エントリーで ou および cn 属性を読み取り、検索できるようにするには、以下を実行します。
以前の例が ou=Engineering,dc=example,dc=com エントリーのみを対象にできるようにするには、ou=Engineering,dc=example,dc=com のサブエントリーでは ou 属性を Engineering に設定しないでください。
ディレクトリーの構造が変更すると、これらの種類の ACI が失敗する可能性があります。
または、ターゲットエントリーに保存される属性値を使用して、バインド要求のユーザー入力に一致するバインドルールを作成できます。値の一致に基づくアクセスの定義 を参照してください。
2.1.9. ACI パーミッションの定義
パーミッションルールは、アクセス制御命令 (ACI) に関連付けられた権限と、アクセスを許可または拒否されるかどうかを定義します。
ACI では、以下の強調表示された部分はパーミッションルールになります。
(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)
(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)2.1.9.1. パーミッションルールの構文
パーミッションルールの一般的な構文は、以下のとおりです。
permission (rights)
permission (rights)-
permission: アクセス制御命令 (ACI) がパーミッションを許可するか、拒否するかを設定します。 -
rights: ACI が許可または拒否する権限を設定します。パーミッションルールのユーザー権限 を参照してください。
例2.11 パーミッションの定義
ou=People,dc=example,dc=com エントリーに保存されているユーザーが、独自のエントリー内のすべての属性を検索し、表示するには、以下を実行します。
2.1.9.2. パーミッションルールのユーザー権限
パーミッションルールの権限は、付与または拒否される操作を定義します。ACI では、以下の権限の 1 つまたは複数を設定できます。
| 権利 | 説明 |
|---|---|
|
| ユーザーがディレクトリーデータを読み込めるかどうかを設定します。このパーミッションは、LDAP の検索操作にのみ適用されます。 |
|
|
属性を追加、変更、または削除してユーザーがエントリーを変更できるかどうかを設定します。このパーミッションは、LDAP の |
|
|
ユーザーがエントリーを作成できるかどうかを設定します。このパーミッションは、LDAP の |
|
|
ユーザーがエントリーを削除できるかどうかを設定します。このパーミッションは、LDAP の |
|
|
ユーザーがディレクトリーデータを検索できるかどうかを設定します。検索結果の一部として返されたデータを表示するには、 |
|
|
ユーザーが提供したデータとディレクトリーに保存されているデータを比較できるかどうかを設定します。 |
|
| ユーザーがグループから独自の識別名 (DN) を追加または削除できるかどうかを設定します。この権限は、グループ管理にのみ使用されます。 |
|
|
指定した DN が他のエントリーの権限でターゲットにアクセスできるかどうかを設定します。 |
|
|
|
2.1.9.3. LDAP 操作に必要な権限
This section describes the rights you must grant to users depending on the type of LDAP operation you want to authorize them to perform.
This section describes the rights you must grant to users depending on the type of LDAP operation you want to authorize them to perform.エントリーの追加:
-
追加するエントリーの
addパーミッションを付与します。 -
エントリーの各属性の値に
writeパーミッションを付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限できます。
-
追加するエントリーの
エントリーの削除:
-
削除するエントリーの
deleteパーミッションを付与します。 -
エントリーの各属性の値に
writeパーミッションを付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限できます。
-
削除するエントリーの
エントリーの属性の変更:
-
属性タイプで
writeパーミッションを付与します。 -
各属性タイプの値に
writeパーミッションを付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限できます。
-
属性タイプで
エントリーの RDN の変更:
-
エントリーで
writeパーミッションを付与します。 -
新しい RDN で使用される属性タイプの
writeパーミッションを付与します。 -
古い RDN を削除する権限を付与する場合は、古い RDN で使用されている属性タイプに
writeパーミッションを付与します。 -
新しい RDN で使用される属性タイプの値に
writeパーミッションを付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限できます。
-
エントリーで
属性の値を比較します。
-
属性タイプで
compareパーミッションを付与します。
-
属性タイプで
エントリーの検索:
-
検索フィルターで使用される各属性タイプの
searchパーミッションを付与します。 -
エントリーで使用される属性タイプの
readパーミッションを付与します。
-
検索フィルターで使用される各属性タイプの
2.1.10. ACI バインドルールの定義
アクセス制御命令 (ACI) のバインドルールは、Directory Server が ACI を適用するのに必要なバインドパラメーターを定義します。たとえば、以下に基づいてバインドルールを設定できます。
- DNS
- グループメンバーシップまたは割り当てられたロール
- エントリーがバインドする場所
- バインド時に使用する必要のある認証の種類
- バインドが実行される回数または日数
ACI では、以下の強調表示された部分はバインドルールになります。
(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)
(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)2.1.10.1. バインドルールの構文
バインドルールの一般的な構文は以下のとおりです。
keyword comparison_operator "expression"
keyword comparison_operator "expression"-
keyword: バインド操作のタイプを設定します。 -
comparison_operator: 有効な値は=および!=で、ターゲットが式で指定されたオブジェクトであるかどうかを示します。キーワードが追加の比較演算子に対応している場合は、該当するセクションで説明されます。 -
expression: 式を設定し、引用符で囲む必要があります。式自体は使用するキーワードによって異なります。
2.1.10.2. ユーザーベースのアクセスの定義
userdn キーワードを使用すると、1 つまたは複数の DN に基づいてアクセスを許可または拒否でき、以下の構文を使用します。
userdn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."
userdn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."式の DN を以下のように設定します。
- DN: userdn キーワードでの DN の使用 を参照してください。
- LDAP フィルター: Using the userdn keyword with an LDAP filter を参照してください。
-
anyoneエイリアス: 匿名アクセスの付与 を参照してください。 -
allエイリアス: 認証済みユーザーへのアクセスの付与 を参照してください。 -
selfエイリアス: ユーザーが自身のエントリーにアクセスできるようにする を参照してください。 -
parentエイリアス: ユーザーの子エントリーへのアクセス設定 を参照してください。
LDAP URL 内でホスト名またはポート番号を指定しないでください。URL は常にローカルサーバーに適用されます。
2.1.10.2.1. userdn キーワードでの DN の使用
userdn キーワードを識別名 (DN) に設定して、ACI を一致するエントリーのみに適用します。複数のエントリーを一致させるには、DN で * ワイルドカードを使用します。
DN で userdn キーワードを使用する場合は、次の構文と一致する必要があります。
userdn comparison_operator ldap:///distinguished_name
userdn comparison_operator ldap:///distinguished_name例2.12 userdn キーワードでの DN の使用
uid=admin,ou=People,dc=example,dc=com ユーザーが ou=People,dc=example,dc=com エントリーで他のすべてのユーザーの manager 属性を読み取るようにするには、以下を実行します。
2.1.10.2.2. LDAP フィルターで userdn キーワードの使用
ユーザーへのパーミッションを動的に許可または拒否するには、LDAP フィルターで userdn キーワードを使用します。
userdn comparison_operator "ldap:///distinguished_name??scope?(filter)"
userdn comparison_operator "ldap:///distinguished_name??scope?(filter)"
LDAP フィルターは * ワイルドカードをサポートします。
例2.13 LDAP フィルターで userdn キーワードの使用
department 属性が Human Resources に設定されているユーザーが、ou=People,dc=example,dc=com エントリー内のユーザーの homePostalAddress 属性を更新できるようにするには、次の手順を実行します。
2.1.10.2.3. 匿名アクセスの付与
特定の状況では、管理者はディレクトリー内のデータへの匿名アクセスを設定します。匿名アクセスは、以下を指定してディレクトリーにバインドできることを意味します。
- バインド DN およびパスワードなし
- 有効なバインド DN およびパスワード
匿名アクセスを設定するには、バインドルールの userdn キーワードで ldap:///anyone 式を使用します。
userdn comparison_operator "ldap:///anyone"
userdn comparison_operator "ldap:///anyone"例2.14 匿名アクセスの付与
認証なしですべてのユーザーが ou=People,dc=example,dc=com エントリーで sn、givenName、および telephoneNumber 属性を読み取りおよび検索できるようにするには、以下を行います。
2.1.10.2.4. 認証済みユーザーへのアクセスの付与
特定の状況では、管理者は匿名バインドを除き、Directory Server に正常にバインドできるユーザーにパーミッションを付与します。この機能を設定するには、バインドルールの userdn キーワードで ldap:///all 式を使用します。
userdn comparison_operator "ldap:///all"
userdn comparison_operator "ldap:///all"例2.15 認証済みユーザーへのアクセスの付与
認証されたユーザーが自分自身をメンバーとして ou=example,ou=groups,dc=example,dc=com グループに追加およびグループから削除できるようにするには、以下を実行します。
2.1.10.2.5. ユーザーが自身のエントリーにアクセスできるようにする
ユーザーの独自のエントリーへのアクセスを許可または拒否する ACI を設定するには、バインドルールの userdn キーワードで ldap:///self 式を使用します。
userdn comparison_operator "ldap:///self"
userdn comparison_operator "ldap:///self"例2.16 ユーザーが自身のエントリーにアクセスできるようにする
ou=People,dc=example,dc=com エントリーのユーザーが独自の userPassword 属性を更新できるようにするには、以下を実行します。
2.1.10.2.6. ユーザーの子エントリーへのアクセス設定
ユーザーのバインド DN がターゲットエントリーの親である場合にのみ、エントリーへのアクセスを許可または拒否するように指定するには、バインドルールで userdn キーワードを含む self:///parent 式を使用します。
userdn comparison_operator "ldap:///parent"
userdn comparison_operator "ldap:///parent"例2.17 ユーザーの子エントリーへのアクセス設定
cn=user,ou=People,dc=example,dc=com ユーザーが独自のサブエントリー (cn=example,cn=user,ou=People,dc=example,dc=com など) の manager 属性を更新できるようにするには、以下を実行します。
2.1.10.3. グループベースのアクセスの定義
グループベースのアクセス制御命令 (ACI) を使用すると、グループへのユーザーの追加、またはグループからのユーザーの削除により、アクセスを管理できます。グループメンバーシップに基づく ACI を設定するには、groupdn キーワードを使用します。ユーザーが指定された 1 つまたは複数のグループのメンバーである場合は、ACI が一致します。
groupdn キーワードを使用すると、Directory Server は以下の属性に基づいてグループメンバーシップを検証します。
- member
- uniqueMember
- memberURL
- memberCertificateDescription
groupdn キーワードでルールをバインドするには、以下の構文を使用します。
groupdn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."
groupdn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."式の識別名 (DN) を次のように設定します。
- DN。groupdn キーワードでの DN の使用 を参照してください。
- LDAP フィルター。LDAP フィルターで groupdn キーワードの使用 を参照してください。
1 つのバインドルールに複数の DN を設定する場合は、認証されたユーザーがこれらのグループのいずれかのメンバーの場合、Directory Server は ACI を適用します。ユーザーを複数のグループのメンバーとして設定するには、複数の groupdn キーワードを使用し、ブール値 and 演算子を使用してそれらを組み合わせます。詳細は、ブール演算子を使用したバインドルールの組み合わせ を参照してください。
LDAP URL 内でホスト名またはポート番号を指定しないでください。URL は常にローカルサーバーに適用されます。
2.1.10.3.1. groupdn キーワードでの DN の使用
ACI をグループのメンバーに適用するには、groupdn キーワードをグループの DN に設定します。
DN に設定された groupdn キーワードは、以下の構文を使用します。
groupdn comparison_operator ldap:///distinguished_name
groupdn comparison_operator ldap:///distinguished_name例2.18 groupdn キーワードでの DN の使用
cn=example,ou=Groups,dc=example,dc=com グループのメンバーが ou=People,dc=example,dc=com のエントリーの manager 属性を検索および読み取るようにするには、以下を実行します。
2.1.10.3.2. LDAP フィルターで groupdn キーワードの使用
groupdn キーワードを使用した LDAP フィルターを使用すると、ACI に一致させるために、認証されたユーザーがフィルター検索で返されるグループの少なくとも 1 つのメンバーでなければならないことを定義できます。
LDAP フィルターが含まれる groupdn キーワードは以下の構文を使用します。
groupdn comparison_operator "ldap:///distinguished_name??scope?(filter)"
groupdn comparison_operator "ldap:///distinguished_name??scope?(filter)"
LDAP フィルターは * ワイルドカードをサポートします。
例2.19 LDAP フィルターで groupdn キーワードの使用
dc=example,dc=com のグループのメンバーや、manager 属性が example に設定されているサブツリーを有効にするには、ou=People,dc=example,dc=com のエントリーの homePostalAddress を更新します。
2.1.10.4. 値の一致に基づくアクセスの定義
バインドルールの userattr キーワードを使用して、ディレクトリーとターゲットエントリーにバインドするのに使用されるエントリー間でどの属性が一致するかを指定します。
userattr キーワードは、以下の構文を使用します。
userattr comparison_operator "attribute_name#bind_type_or_attribute_value
userattr comparison_operator "attribute_name#bind_type_or_attribute_value詳細は、以下を参照してください。
デフォルトでは、Directory Server は、作成したエントリーに対するアクセス権限を評価します。ただし、同じレベルのユーザーオブジェクトを防ぐために、Directory Server は、userattr キーワードを使用した場合には、アクセス制御命令 (ACI) を設定したエントリーに add パーミッションを付与しません。この動作を設定するには、parent キーワードとともに userattr キーワードを使用して、レベル 0 で追加のパーミッションを付与します。
継承の詳細は、Defining access based on value matching を参照してください。
2.1.10.4.1. USERDN バインドタイプの使用
バインディングユーザーの識別名 (DN) が属性に保存されている DN と一致する場合に ACI を適用するには、USERDN バインドタイプを使用します。
USERDN バインドタイプの userattr キーワードには、以下の構文が必要です。
userattr comparison_operator "attribute_name#USERDN"
userattr comparison_operator "attribute_name#USERDN"例2.20 USERDN バインドタイプの使用
マネージャーに対し、すべてのパーミッションを独自の関連付けの telephoneNumber 属性に付与するには、以下を実行します。
前述の ACI は、ou=People,dc=example,dc=com のエントリーに対して操作を行ったユーザーの DN が、このエントリーの manager 属性に格納されている DN と一致すれば、true と評価されます。
2.1.10.4.2. GROUPDN バインドタイプの使用
バインディングユーザー DN が属性に設定されたグループのメンバーである場合に ACI を適用するには、GROUPDN バインドタイプを使用します。
GROUPDN バインドタイプの userattr キーワードには、以下の構文が必要です。
userattr comparison_operator "attribute_name#GROUPDN"
userattr comparison_operator "attribute_name#GROUPDN"例2.21 GROUPDN バインドタイプの使用
ou=Social Committee,ou=Groups,dc=example,dc=com の下に所有するグループエントリーを削除するパーミッションをユーザーに付与するには、以下を実行します。
操作を実行するユーザーの DN が owner 属性で指定されたグループのメンバーである場合に、以前の ACI は true と評価されます。
指定のグループは動的グループで、グループの DN はデータベースの任意の接尾辞にすることができます。しかし、このタイプの ACI をサーバーが評価するには、リソースを大量に必要とします。
ターゲットエントリーと同じ接尾辞の下にある静的グループを使用している場合は、パフォーマンスを改善するために以下の式を使用します。
userattr comparison_operator "ldap:///distinguished_name?attribute_name#GROUPDN"
userattr comparison_operator "ldap:///distinguished_name?attribute_name#GROUPDN"2.1.10.4.3. ROLEDN バインドタイプの使用
バインディングユーザーが属性で指定されたロールに属する場合に ACI を適用するには、ROLEDN バインドタイプを使用します。
ROLEDN バインドタイプの userattr キーワードには、以下の構文が必要です。
userattr comparison_operator "attribute_name#ROLEDN"
userattr comparison_operator "attribute_name#ROLEDN"例2.22 ROLEDN バインドタイプの使用
cn=Administrators,dc=example,dc=com ロールを持つユーザーが ou=People,dc=example,dc=com のエントリーの manager 属性を検索および読み取るようにするには、以下を実行します。
指定のロールはデータベースの任意の接尾辞の下に置くことができます。フィルターされたロールも使用している場合、このタイプの ACI の評価は、サーバー上の多くのリソースを使用します。
静的ロール定義を使用し、ロールエントリーがターゲットエントリーと同じ接尾辞下にある場合は、パフォーマンスを向上させるために以下の式を使用します。
2.1.10.4.4. SELFDN バインドタイプの使用
SELFDN バインドタイプを使用すると、バインドされたユーザーの DN がエントリーの単一値属性に設定されている場合にパーミッションを付与できます。
SELFDN バインドタイプの userattr キーワードには、以下の構文が必要です。
userattr comparison_operator "attribute_name#SELFDN"
userattr comparison_operator "attribute_name#SELFDN"例2.23 SELFDN バインドタイプの使用
ipatokenOwner 属性にバインドユーザーの DN が設定されている ipatokenuniqueid=*,cn=otp,dc=example,dc=com エントリーをユーザーが追加できるようにするには、以下を実行します。
2.1.10.4.5. LDAPURL バインドタイプの使用
バインド DN がターゲットエントリーの属性で指定されたフィルターと一致する場合に ACL を適用するには、LDAPURL バインドタイプを使用します。
LDAPURL バインドタイプの userattr キーワードには、以下の構文が必要です。
userattr comparison_operator "attribute_name#LDAPURL"
userattr comparison_operator "attribute_name#LDAPURL"例2.24 LDAPURL バインドタイプの使用
aciurl 属性が ldap:///ou=People,dc=example,dc=com??one?(uid=user*) に設定されているユーザーオブジェクトに読み取りおよび検索パーミッションを付与するには、以下を実行します。
2.1.10.4.6. 継承による userattr キーワードの使用
userattr キーワードを使用してターゲットエントリーにバインドするために使用されるエントリーを関連付ける場合、ACI は指定されたターゲットにのみ適用され、その下のエントリーには適用されません。特定の状況下では、管理者は ACI の適用範囲を、対象となるエントリーよりも数レベル広げたいと考えます。これは、parent キーワードを使用して、ACI を継承するターゲットの下のレベル数を指定することによって可能になります。
parent キーワードで userattr キーワードを使用する場合、構文は以下のようになります。
userattr comparison_operator "parent[inheritance_level].attribute_name#bind_type_or_attribute_value
userattr comparison_operator "parent[inheritance_level].attribute_name#bind_type_or_attribute_value-
inheritance_level: ターゲットのどれくらい下のレベルが ACI を継承するかを示すコンマ区切りのリスト。ターゲットエントリーの下に、5 つのレベル (0、1、2、3、4) を追加できます。ゼロ (0) はターゲットエントリーを示します。 -
attribute_name:userattrまたはgroupattrのキーワードでターゲットとなる属性。 -
bind_type_or_attribute_value:USERDNなどの属性値またはバインドタイプを設定します。
以下に例を示します。
userattr = "parent[0,1].manager#USERDN"
userattr = "parent[0,1].manager#USERDN"このバインドルールは、バインド DN がターゲットエントリーのマネージャー属性と一致する場合に true になります。バインドルールが true であるときに付与されるパーミッションは、ターゲットエントリーと、その下のすべてのエントリーに適用されます。
例2.25 継承による userattr キーワードの使用
ユーザーの DN が owner 属性に設定されている cn=Profiles,dc=example,dc=com エントリー、および cn=mail,cn=Profiles,dc=example,dc=com と cn=news,cn=Profiles,dc=example,dc=com を含む第 1 レベルの子エントリーの読み取りと検索をユーザーができるようにするには、以下を実行します。
2.1.10.5. 特定の IP アドレスまたは範囲からのアクセスの定義
バインドルールの ip キーワードを使用すると、特定の IP アドレスまたは IP アドレスの範囲からのアクセスを許可または拒否できます。
ip キーワードでルールをバインドするには、以下の構文を使用します。
ip comparison_operator "IP_address_or_range"
ip comparison_operator "IP_address_or_range"例2.26 バインドルールでの IPv4 アドレス範囲の使用
192.0.2.0/24 ネットワークから dc=example,dc=com エントリーへのアクセスを拒否するには、以下のコマンドを実行します。
例2.27 バインドルールでの IPv6 アドレス範囲の使用
2001:db8::/64 ネットワークから dc=example,dc=com エントリーへのアクセスを拒否するには、以下のコマンドを実行します。
2.1.10.6. 特定のホストまたはドメインからアクセスの定義
バインドルールの dns キーワードを使用すると、特定のホストまたはドメインからのアクセスを許可または拒否できます。
DNS を使用して Directory Server が完全修飾ドメイン名 (FQDN) への接続 IP アドレスを解決できない場合、サーバーはこのクライアントの dns バインドルールを持つアクセス制御命令 (ACI) を適用しません。
クライアント IP アドレスが DNS を使用して解決できない場合は、代わりに ip キーワードおよび IP アドレスを使用してください。特定の IP アドレスまたは範囲からのアクセスの定義 を参照してください。
dns キーワードを使用したバインドルールでは、次の構文を使用します。
dns comparison_operator "host_name_or_domain_name"
dns comparison_operator "host_name_or_domain_name"例2.28 特定のホストからのアクセスの定義
client.example.com ホストから dc=example,dc=com エントリーへのアクセスを拒否するには、以下を実行します。
例2.29 特定のドメインからアクセスの定義
example.com ドメイン内のすべてのホストから dc=example,dc=com エントリーへのアクセスを拒否するには、以下を実行します。
2.1.10.7. 接続に一定レベルのセキュリティーの要求
接続のセキュリティーは、操作を処理するために必要な最低限の鍵の強度を設定する Security Strength Factor (SSF) によって決定されます。バインドルールで ssf キーワードを使用すると、接続で特定のレベルのセキュリティーを使用する必要があるように設定できます。これにより、パスワード変更などの操作を強制的に、暗号化された接続上で実行できます。
すべての操作の SSF 値は、TLS 接続と SASL バインドの間の値が高くなります。これは、サーバーが TLS で実行されるように設定され、レプリカ合意が SASL/GSSAPI に対して設定されている場合は、操作の SSF が利用可能な暗号化タイプがよりセキュアであることを意味します。
ssf キーワードを使用したバインドルールでは、次の構文を使用します。
ssf comparison_operator key_strength
ssf comparison_operator key_strength以下の比較演算子を使用できます。
-
=(等しい) -
!(等しくない) -
<(より小さい) -
>(より大きい) -
⇐(より小さいか等しい) -
>=(より大きいか等しい)
key_strength パラメーターが 0 に設定されている場合、LDAP 操作にセキュアな操作は必要ありません。
例2.30 接続に一定レベルのセキュリティーの要求
dc=example,dc=com エントリーのユーザーが、SSF が 128 以上の場合にのみ、userPassword 属性を更新できるように設定する場合は、以下を実行します。
2.1.10.8. 曜日の特定の日におけるアクセスの定義
バインドルールの dayofweek キーワードを使用すると、曜日に基づいてアクセスを許可または拒否できます。
Directory Server はサーバー上で時間を使用してアクセス制御命令 (ACI) を評価しますが、クライアントの時間ではありません。
dayofweek キーワードを含むバインドルールでは、次の構文を使用します。
dayofweek comparison_operator "comma-separated_list_of_days"
dayofweek comparison_operator "comma-separated_list_of_days"例2.31 特定の曜日にアクセスの付与
毎週土曜日と日曜日に uid=user,ou=People,dc=example,dc=com ユーザーエントリーがサーバーにバインドされるアクセスを拒否するには、以下を実行します。
2.1.10.9. 特定の時刻におけるアクセスの定義
バインドルールの timeofday キーワードを使用すると、時間帯に基づいてアクセスを許可または拒否できます。
Directory Server はサーバー上で時間を使用してアクセス制御命令 (ACI) を評価しますが、クライアントの時間ではありません。
timeofday キーワードを含むバインドルールでは、次の構文を使用します。
timeofday comparison_operator "time"
timeofday comparison_operator "time"以下の比較演算子を使用できます。
-
=(等しい) -
!(等しくない) -
<(より小さい) -
>(より大きい) -
⇐(より小さいか等しい) -
>=(より大きいか等しい)
timeofday キーワードには、24 時間形式で時間を指定する必要があります。
例2.32 特定の時刻におけるアクセスの定義
uid=user,ou=People,dc=example,dc=com ユーザーエントリーへのアクセスを拒否するには、6pm から 0am までの間にサーバーにバインドします。
2.1.10.10. 認証方法に基づいたアクセスの定義
バインドルールの authmethod キーワードは、サーバーに接続する際にクライアントが使用する認証方法を設定し、アクセス制御命令 (ACI) を適用します。
authmethod キーワードを含むバインドルールでは、次の構文を使用します。
authmethod comparison_operator "authentication_method"
authmethod comparison_operator "authentication_method"以下の認証方法を設定できます。
-
none: 認証は不要で、匿名のアクセスを表します。これがデフォルトです。 -
simple: クライアントは、ディレクトリーにバインドするためにユーザー名とパスワードを提供する必要があります。 -
SSL: クライアントは、データベース、スマートカード、または他のデバイスのいずれかで TLS 証明書を使用してディレクトリーにバインドする必要があります。 -
SASL: クライアントは、Simple Authentication and Security Layer (SASL) 接続を介して、ディレクトリーにバインドする必要があります。バインドルールでこの認証方法を使用する場合は、EXTERNALなどの SASL メカニズムも追加で指定します。
例2.33 EXTERNAL SASL 認証方法を使用した接続でのみアクセスのみの有効化
接続が証明書ベースの認証メソッドまたは SASL を使用していない場合にサーバーへのアクセスを拒否するには、以下を実行します。
2.1.10.11. ロールに基づくアクセスの定義
バインドルールの roledn キーワードを使用すると、1 つまたは複数のロールセットが設定されたユーザーへのアクセスを許可または拒否できます。
Red Hat は、ロールの代わりにグループを使用することを推奨します。
roledn キーワードを使用したバインドルールでは、次の構文を使用します。
roledn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."
roledn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."識別名 (DN) にコンマが含まれている場合は、バックスラッシュでエスケープしてください。
例2.34 ロールに基づくアクセスの定義
nsRole 属性で cn=Human Resources,ou=People,dc=example,dc=com ロールを設定したユーザーが ou=People,dc=example,dc=com のエントリーの manager 属性を検索および読み取るようにするには、以下を実行します。
2.1.10.12. ブール演算子を使用したバインドルールの組み合わせ
複雑なバインドルールを作成する場合は、AND、OR、および NOT のブール値演算子を使用すると、複数のキーワードを組み合わせることができます。
バインドルールとブール演算子を組み合わせた構文は以下の通りです。
bind_rule_1 boolean_operator bind_rule_2...
bind_rule_1 boolean_operator bind_rule_2...例2.35 ブール演算子を使用したバインドルールの組み合わせ
cn=Administrators,ou=Groups,dc=example,com および cn=Operators,ou=Groups,dc=example,com の両方のグループのメンバーであるユーザーが、ou=People,dc=example,dc=com のエントリーに対して `read、search、add、update、および delete の操作を実行できるようにするには、次のコマンドを実行します。
Directory Server によるブール値演算子の評価方法
Directory Server は以下のルールを使用してブール値演算子を評価します。
左から右へのすべての式。
以下の例では、
bind_rule_1が最初に評価されます。(bind_rule_1) OR (bind_rule_2)
(bind_rule_1) OR (bind_rule_2)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 一番内側から外側に向かって、親表現が優先されます。
以下の例では、,
bind_rule_2を最初に評価し、次にbind_rule_3を評価します。(bind_rule_1) OR ((bind_rule_2) AND (bind_rule_3))
(bind_rule_1) OR ((bind_rule_2) AND (bind_rule_3))Copy to Clipboard Copied! Toggle word wrap Toggle overflow ANDまたはOR演算子の前にNOT。以下の例では、bind_rule_2 が最初に評価されます。
(bind_rule_1) AND NOT (bind_rule_2)
(bind_rule_1) AND NOT (bind_rule_2)Copy to Clipboard Copied! Toggle word wrap Toggle overflow ANDおよびOR演算子には優先順位がありません。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}