| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
セキュアなディレクトリ・サービスを作成するためには、ディレクトリの内容へのアクセスを制御することが最も重要です。データへのアクセスはアクセス制御命令(ACI)によって管理されます。ACIでは、個々のエントリ、各エントリに属するすべてのサブエントリ、またはグローバル・ベースで全エントリに対するアクセス権を指定します。
多数のACIや複雑なACIを使用すると、少数の単純なACIを使用する場合より多くの処理リソースが必要になります。多数のACIや極端に複雑なACIを指定すると、パフォーマンスが大幅に低下する可能性があります。
Oracle Unified Directoryには、特定のエントリに対する特定のユーザーの実効権限を表示する機能があります。この機能により、複雑で強力なアクセス制御メカニズムの管理が簡素化されます。
ACIモデルの概要は、第9章「Oracle Unified Directoryのアクセス制御モデルの理解」を参照してください。
次の各項では、データへのアクセスを制御するACIを作成する方法について説明します:
dsconfigによるグローバルACIの管理グローバルACIは、部分的なサブツリーではなく、DITのルートへのアクセスを制御します。グローバルACIは、ディレクトリ内のすべてのエントリに適用されます。グローバルACIは、dsconfigコマンドとldapmodifyコマンドを使用して、設定、リセットおよび削除できます。dsconfigは、管理コネクタを使用してSSLを介してサーバーの構成にアクセスします。dsconfigの詳細は、第17.1項「dsconfigを使用したサーバー構成の管理」を参照してください。
サブツリー内のエントリに適用されるACIを、dsconfigを使用して管理することはできません。グローバルではないACIの管理方法は、第25.2項「ldapmodifyによるACIの管理」を参照してください。
Oracle Unified Directoryをインストールするときに、9個のデフォルト・グローバルACIが定義されます。デフォルト・グローバルACIの効果は、次を可能にすることです:
特定のコントロールと拡張操作に対して誰もが読取りアクセス権を持ちます。
属性に対して誰もがルートDSEレベルでの検索、比較、および読取りアクセス権を持ちます。特定の属性にアクセスするには明示的なアクセス権が必要となります。
認証されたユーザーはディレクトリ内にある自分自身のエントリ内の属性のサブセットを変更できます。ユーザーは自分自身のエントリを削除できません。
ルートDSE内の多くの操作属性とcn=schemaを含む主要な操作属性と、サーバー全体の各エントリ内に現れるその他の属性に対するアクセス権を、すべてのユーザーが持ちます。
プロキシはグローバルACIを評価しません。プロキシはLDAPリクエストをリモートLDAPサーバーへ転送し、リモートLDAPサーバーがACIを評価します。
グローバルACIはすべて、アクセス制御ハンドラのglobal-aciプロパティの値です。サーバー上で現在構成されているグローバルACIを表示するには、dsconfigを使用してglobal-aciプロパティを表示します。
dsconfigコマンドは次のように実行します(出力の書式は読みやすいように変更してあります)。
$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -X -n \
get-access-control-handler-prop --property global-aci
Property : Value(s)
-----------:-----------------------------------------------------------------------------------
global-aci : (extop="1.3.6.1.4.1.26027.1.6.1 || 1.3.6.1.4.1.26027.1.6.3 ||
: 1.3.6.1.4.1.4203.1.11.1 || 1.3.6.1.4.1.1466.20037 ||
: 1.3.6.1.4.1.4203.1.11.3") (version 3.0; acl "Anonymous extended operation access";
: allow(read) userdn="ldap:///anyone";),
: "(target="ldap:///")(targetscope="base")(targetattr="objectClass||namingContexts||
: supportedAuthPasswordSchemes||supportedControl||supportedExtension||
: supportedFeatures||supportedLDAPVersion||supportedSASLMechanisms||vendorName||
: vendorVersion")(version 3.0; acl "User-Visible Root DSE Operational Attributes";
: allow (read,search,compare) userdn="ldap:///anyone";)",
: (target="ldap:///cn=changelog")(targetattr="*")(version 3.0; acl "External changelog
: access"; deny (all) userdn="ldap:///anyone";),
: "(target="ldap:///cn=schema")(targetscope="base")(targetattr="objectClass||
: attributeTypes||dITContentRules||dITStructureRules||ldapSyntaxes||matchingRules||
: matchingRuleUse||nameForms||objectClasses")(version 3.0; acl "User-Visible Schema
: Operational Attributes"; allow (read,search,compare) userdn="ldap:///anyone";)",
: (target="ldap:///dc=replicationchanges")(targetattr="*")(version3.0; acl
: "Replication backend access"; deny (all) userdn="ldap:///anyone";),
: (targetattr="audio||authPassword||description||displayName||givenName||homePhone||
: homePostalAddress||initials||jpegPhoto||labeledURI||mobile||pager||postalAddress||
: postalCode||preferredLanguage||telephoneNumber||userPassword")(version 3.0; acl
: "Self entry modification"; allow (write) userdn="ldap:///self";),
: "(targetattr="createTimestamp||creatorsName||modifiersName||modifyTimestamp||entryDN||
: entryUUID||subschemaSubentry||orclguid")(version 3.0; acl "User-Visible Operational
: Attributes"; allow (read,search,compare) userdn="ldap:///anyone";)",
: "(targetattr="userPassword||authPassword")(version 3.0; acl "Self entry read";
: allow (read,search,compare) userdn="ldap:///self";)",
: (targetcontrol="1.3.6.1.1.12 || 1.3.6.1.1.13.1 || 1.3.6.1.1.13.2||
: 1.2.840.113556.1.4.319 || 1.2.826.0.1.3344810.2.3 || 2.16.840.1.113730.3.4.18 ||
: 2.16.840.1.113730.3.4.9 ||1.2.840.113556.1.4.473 || 1.3.6.1.4.1.42.2.27.9.5.9")
: (version 3.0; acl "Authenticated users control access"; allow(read)
: userdn="ldap:///all";), (targetcontrol="2.16.840.1.113730.3.4.2 ||
: 2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 ||1.3.6.1.4.1.4203.1.10.2 ||
: 1.3.6.1.4.1.42.2.27.8.5.1 ||2.16.840.1.113730.3.4.16 || 2.16.840.1.113894.1.8.31")
: (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";)
グローバルACIを削除する最も簡単な方法は、dsconfigを対話モードで使用することです。対話モードでは、ガイドに従ってACI構成に対する操作を実行できるため、ここでは操作法を説明しません。非対話モードでグローバルACIを削除する場合は、コマンド行シェルの規則に従ってACI指定内の特殊文字をすべてエスケープしてください。
次の例では、dsconfigを非対話モードで使用して、匿名アクセスを許可するグローバルACIを削除しています。
dsconfigコマンドは次のように実行します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-access-control-handler-prop \ --remove global-aci:\(targetattr!=\"userPassword\|\|authPassword\"\) \ \(version\ 3.0\;\ acl\ \"Anonymous\ read\ access\"\;\ allow\(read,search,compare\) \ \ userdn=\"ldap:///anyone\"\;\)
グローバルACIを追加するときには、コマンド行シェルの規則に従ってACI指定内の特殊文字をすべてエスケープしてください。
次の例では、dsconfigを非対話モードで使用して、前の手順で削除したグローバルACIを追加しています:
dsconfigコマンドは次のように実行します。
$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -n \ set-access-control-handler-prop \ --add global-aci:\(targetattr!=\"userPassword\|\|authPassword\"\) \ \(version\ 3.0\;\ acl\ \"Anonymous\ read\ access\"\;\ allow\ \(read,search,compare\) \ userdn=\"ldap:///anyone\"\;\)
ldapmodifyによるACIの管理LDIF文を使用してアクセス制御命令(ACI)を手動で作成し、ldapmodifyコマンドを使用してそのACIをディレクトリに追加することができます。ACIの値は非常に複雑な場合があるため、既存の値を表示してそれをコピーすれば、新しいACIを作成する助けになります。
ここに示されている以外のACIのサンプルについては、第25.5項「アクセス制御の使用例」を参照してください。
ACIは、エントリのaci属性の1つ以上の値として保存されます。aci属性は、ディレクトリ・ユーザーによる読取りと変更が可能な複数値操作属性であり、それ自体をACIによって保護する必要があります。
通常、管理ユーザーにはaci属性への完全アクセス権が付与されます。
aci属性の値を表示するには、次のldapsearchコマンドを実行します:
$ ldapsearch -h host -p port -D "cn=Directory Manager" -j pwd-file \ -b entryDN -s base "(objectclass=*)" aci
その結果、新しいLDIF ACI定義にコピーして編集できるLDIFテキストが出力されます。ACIの値は長い文字列になるため、ldapsearch操作による出力は、多くの場合数行にわたって表示されます(先頭の空白が継続マーカーになります)。LDIF出力をコピーして貼り付ける場合は、これを考慮してください。
設定されているACIの値によってどのような権限が付与または拒否されているかを表示する方法は、第25.7項「実効権限の表示」を参照してください。
ACIを追加するには、LDIFファイル内でACIを指定し、ldapmodifyコマンドを使用してそのLDIFファイルを適用します。LDIFファイルは1つ以上のaci属性を含んでいる必要があり、各aci属性は接頭辞aci:とその後に続くACI指定で構成されます。詳細は、第9.2項「ACI構文」を参照してください。
LDIFファイルにACIを作成します。
次のサンプルLDIFファイル(aci.ldif)は、特定のユーザー(csmith)にディレクトリへの完全なアクセス権を付与するACIを追加します:
dn: ou=people,dc=example,dc=com changetype: modify add: aci aci: (targetattr="*")(version 3.0; acl "give csmith full rights"; allow(all) userdn = "ldap:///uid=csmith,ou=People,dc=example,dc=com";)
ldapmodifyコマンドを使用して、ACIをディレクトリに適用します。
次のコマンドは、aci.ldifファイルに含まれているACIをディレクトリに適用します:
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --filename aci.ldif Processing MODIFY request for ou=people,dc=example,dc=com MODIFY operation successful for DN ou=people,dc=example,dc=com
ACIを削除するには、LDIFファイル内のACIの値を指定し、ldapmodifyコマンドを使用してその値を削除します。
LDIFファイル内のACIを削除します。
次のサンプルLDIFファイル(remove-aci.ldif)は、前の手順で追加したACIを削除します:
dn: ou=people,dc=example,dc=com changetype: modify delete: aci aci: (targetattr="*")(version 3.0; acl "give csmith full rights"; allow(all) userdn = "ldap:///uid=csmith,ou=People,dc=example,dc=com";)
ldapmodifyコマンドを使用して、変更をディレクトリに適用します。
次のコマンドは、remove-aci.ldifファイルに含まれている変更をディレクトリに適用します:
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --filename remove-aci.ldif Processing MODIFY request for ou=people,dc=example,dc=com MODIFY operation successful for DN ou=people,dc=example,dc=com
ODSMを使用すると、使いやすいインタフェースで、サーバー内で構成されている既存のACIを表示したり、新規のアクセス制御ポイントを作成したり、新規のACIを作成することができます。次の各トピックでは、ODSMを使用してアクセス制御を管理する方法について説明します。
Oracle Unified Directoryは、デフォルトで複数の事前構成済ACIをサポートしています。サーバー内で構成されているすべてのACIを、ODSMを使用して次の手順で表示できます:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
構成済ACIはすべて、そのACIが定義されているアクセス制御ポイントの下に表示されます。ACIを表示するには、そのACIが定義されているアクセス制御ポイントを開きます。たとえば、ルート・エントリに適用されるACIのリストを表示するには、ルート・エントリを開きます。
ACIを選択すると、そのプロパティが右側のペインに表示されます。
アクセス制御ポイントは、その中にACIが定義されているエントリです(つまり、対応するaci属性を含んでいるエントリです)。
ODSMを使用して、新規のアクセス制御ポイントを次の手順で定義できます:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
「作成」アイコンをクリックします。
新しいアクセス制御ポイントとなるエントリのDNを「場所」フィールドに入力するか、「選択」をクリックしてディレクトリからエントリを選択します。
1つまたは複数のACIをアクセス制御ポイントに追加するには、「ACIの作成」をクリックします。
ACIの詳細を入力します。これらのフィールドの詳細は、「ACIの追加」の項を参照してください。
アクセス制御ポイントに必要なACIを追加し終わったら、「作成」をクリックします。
ODSMを使用して、既存のアクセス制御ポイントに基づく新規のアクセス制御ポイントを次の手順で定義できます:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
新しいアクセス制御ポイントのベースにするアクセス制御ポイントを選択します。
「類似作成」アイコンをクリックします。
新しいアクセス制御ポイントとなるエントリのDNを「場所」フィールドに入力するか、「選択」をクリックしてディレクトリからエントリを選択します。
ベースにしたアクセス制御ポイントと同じACLを持つ新しいアクセス制御ポイントが自動的に作成されます。
新しいアクセス制御ポイントに対して既存のACIの追加、編集または削除を行うには、それぞれ「作成」、「編集」または「削除」をクリックします。
ACIを追加または編集する場合は、必要な詳細を入力します。これらのフィールドの詳細は、第25.3.5項「ACIの追加」を参照してください。
新しいアクセス制御ポイントのACIの変更が終わったら、「作成」をクリックします。
ODSMを使用して、アクセス制御ポイントを次の手順で削除できます:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
削除するアクセス制御ポイントを選択し、「削除」アイコンをクリックします。
「OK」をクリックして、削除を確定します。
ODSMを使用して、次の手順でACIを既存のアクセス制御ポイントに追加できます:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
新しいACIを追加するアクセス制御ポイントを開きます。
アクセス制御リストからACIを1つ選択します。
「追加」アイコンをクリックします。
使いやすいインタフェースを使用してACIを作成する場合は、「詳細の表示」タブを選択します。
「範囲」で、ACIの範囲を選択します。
通常、ACIの範囲はサブツリーです。ACIの範囲は、次のいずれかの値を選択して制限できます:
ベース。ACIは、ターゲット・リソースにのみ適用されます。
1。ACIは、ターゲット・リソースの第1世代の子に適用されます。
サブツリー。ACIは、ターゲット・リソースとその下にあるサブツリーに適用されます。
下位。ACIは、ターゲット・リソースの下にあるサブツリーにのみ適用されます。
「ターゲット」フィールドで、ACIの各要素を選択して「編集」をクリックし、そのプロパティを定義します。
ACIターゲットの定義方法の詳細は、第9.2.2項「ターゲットの定義」を参照してください。
ターゲットのエントリに出現する1つ以上の属性を対象にして、エントリに関する情報の一部へのアクセスを拒否または許可できるようになりました。次の手順を実行します。
「ターゲット」フィールドで、「ターゲット属性」を選択して「編集」をクリックします。
次の詳細を入力します:
「演算子」で必要な値を選択します。「属性」で必要なオプションを選択します。
「追加」をクリックして、1つ以上のACI属性とサブタイプを入力します。「検索」をクリックして、属性名を検索することもできます。
「サブタイプ(オプション)」フィールドに属性のサブタイプを入力することもできます。同じ属性に対して複数のサブタイプを入力できます。
「OK」をクリックします。
詳細は、第9.2.2.2項「ターゲット属性」を参照してください。
「権限」フィールドで、「追加」アイコンをクリックして権限とバインド・ルールを定義します。
ACI権限の定義方法の詳細は、第9.2.3項「権限の定義」を参照してください。
バインド・ルールの定義方法の詳細は、第9.3項「バインド・ルール」を参照してください。
バインド・ルールを定義するには、次の手順を実行します:
「バインド・ルール・タイプ」リストから、目的のバインド・ルールを選択します。
「ユーザー属性」タブをクリックし、ユーザー属性バインド・ルールを作成します。
次のステップを実行します:
「ユーザー属性演算子」プロパティの値を選択します。
「エントリ選択」プロパティの値として、「ターゲット・エントリとそのサブツリー」を選択します。
「継承レベル」リストから、継承レベルの値を選択します。
「ユーザー属性」フィールドで、属性を入力するか、「選択」をクリックしてエントリを検索します。
「ユーザー属性タイプ」プロパティとして、「バインド・タイプ・フォーマット」をクリックします。
「バインド・タイプ値」リストから、バインド・タイプ値を選択します。
「OK」をクリックします。
ACIを手動で定義する場合は、「テキスト・エディタ・ビュー」タブをクリックしてACIの詳細を入力します。
「検証」をクリックして、作成中のACIがACI構文に従っているかどうかチェックします。
このビューを使用して、既存のACIをコピーして貼り付けることもできます。
ACI定義が完成したら、「作成」をクリックします。
ODSMを使用して、既存のACIに基づく新規のACIを次の手順で追加できます:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
コピーするACIが含まれているアクセス制御ポイントを開きます。
コピーするACIを選択します。
「類似追加」アイコンをクリックします。
変更が必要なACIの要素を、「テキスト・エディタ・ビュー」または「詳細の表示」で編集します。
ACI定義が完成したら、「作成」をクリックします。
ODSMを使用して、既存のACIを次の手順で変更できます:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
変更するACIが含まれているアクセス制御ポイントを開きます。
変更するACIを選択します。
「テキスト・エディタ・ビュー」または「詳細の表示」で、ACIの要素を編集します。
変更が完了したら、「適用」をクリックします。
ODSMを使用して、target、targetFilter、userDn、groupDNおよびuserAttr属性にマクロ式を入力できます。マクロACIの詳細は、第9.6項「高度なアクセス制御のためのマクロACIの使用」を参照してください。
この項には次のトピックが含まれます:
この項では、ターゲットにマクロACIを入力する方法について説明します。
ターゲットを編集してマクロACIを入力するには:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」リストから、編集するACIを選択します。
「ターゲット」表から「ターゲット」行を選択します。
「編集」をクリックします。
「ターゲット」フィールドにマクロ式を入力します。
「OK」をクリックします。
この項では、ターゲット・フィルタにマクロACIを入力する方法について説明します。
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」リストから、編集するACIを選択します。
「ターゲット」表から「ターゲット・フィルタ」行を選択します。
「編集」をクリックします。
「ターゲット」フィールドに、マクロ式を使用してフィルタを入力します。
「OK」をクリックします。
この項では、ターゲット・リソースに対する特定のユーザーまたは特定のグループのアクセス権を定義する方法について説明します。
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」リストから、編集するACIを選択します。
「権限」表から「バインド・ルール」行を選択します。
「編集」をクリックします。
「バインド・ルール・タイプ」リストから、目的のバインド・ルールを選択します。
「アクセス先」タブで、「ユーザーDN」リストから「ユーザーの指定」を選択します。
「ユーザー」表で次の手順を実行します:
「追加」をクリックします。
ユーザー・アクセスを定義するマクロ式を入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。
ターゲット・リソースに対する特定のグループのアクセス権を指定するには、「グループDN演算子」表で次の手順を実行します:
「追加」をクリックします。
グループ・アクセスを定義するマクロ式を入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。
「OK」をクリックします。
|
注意: 個々のバインド・ルールを編集することもできます。バインド・ルールを変更するには、「権限」表で必要なバインド・ルールを選択してから「編集」をクリックする必要があります。 |
この項では、ユーザー属性のバインド・ルールを編集する方法について説明します。
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」リストから、編集するACIを選択します。
「権限」表から「バインド・ルール」行を選択します。
「編集」をクリックします。
「ユーザー属性」タブをクリックします。
「バインド・ルール・タイプ」リストから、目的のバインド・ルールを選択します。
「エントリ選択」プロパティの値として、「特定のエントリ」を選択します。
「エントリ・ベースDN」フィールドで、ベースDNを入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。
「ユーザー属性」フィールドで、属性名を入力するか、「選択」をクリックして属性名のリストから属性名を選択します。
「バインド・タイプ・フォーマット」をクリックします。
「バインド・タイプ値」リストから、目的の値を選択します。
「OK」をクリックします。
|
注意: 個々のバインド・ルールを編集することもできます。バインド・ルールを変更するには、「権限」表で必要なバインド・ルールを選択してから「編集」をクリックする必要があります。 |
この項では、アクセス制御ポリシーの実装に使用できるサンプルACIをいくつか示します。
ディレクトリ・サーバーは、デフォルトでは匿名アクセスを許可します。匿名アクセス(特にディレクトリ内の機密データへの)を無効にする必要が生じる場合があります。
次のデフォルトACIは、userpassword属性およびauthPassword属性以外のすべてのユーザー属性に対する匿名読取りアクセスを許可します:
aci: (targetattr!="userPassword||authPassword")(version 3.0; acl " Anonymous read access"; allow (read,search,compare) userdn="ldap:///anyone";)
匿名アクセスを無効にするには、次の例のように、デフォルト・アクセス制御ハンドラからこのACIを削除します:
$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j pwd-file -n \ set-access-control-handler-prop \ --remove global-aci:'(targetattr!="userPassword||authPassword") \ (version 3.0; acl "Anonymous read access"; \ allow (read,search,compare) userdn="ldap:///anyone";)'
使用されているシェルによっては、ACI自体の中の引用符をエスケープする必要があります。
デフォルトのグローバルACIは、ユーザー自身のエントリの属性の限られたサブセットに対する書込みアクセスを許可します。これには次の属性が含まれます:
audio
authPassword
description
displayName
givenName
homePhone
homePostalAddress
initials
jpegPhoto
labeledURI
mobile
pager
postalAddress
postalCode
preferredLanguage
telephoneNumber
userPassword
ユーザー自身のエントリについて上記以外の属性に対する書込みアクセスをユーザーに許可するには、この項で説明する手順を実行します。
次のサンプルACIは、example.com内でユーザーが自分自身のビジネス・カテゴリと部屋番号を変更できるようにします。
前述のように、書込みアクセスを許可すると、属性値を削除する権限もユーザーに付与することになります。
aci: (targetattr="businessCategory || roomNumber") (version 3.0; acl "Write example.com"; allow (write) userdn="ldap:///self" and dns="*.example.com";)
この例では、ACIがou=People,dc=example,dc=comエントリに追加されることを前提としています。
次の例は、ディレクトリへのSSL接続が確立されている場合に、すべてのユーザーがexample.comツリー内の自分自身の全個人情報を更新できるようにします。
この権限を設定すると、ユーザーに属性値を削除する権限も付与することになります。
aci: (targetattr="*") (version 3.0; acl "Write SSL"; allow (write) userdn= "ldap:///self" and authmethod="ssl";)
この例では、aciがou=subscribers,dc=example,dc=comエントリに追加されることを前提としています。
ほとんどのディレクトリには、特定の業務機能を識別するためのグループがあります。これらのグループにディレクトリの全体または一部へのアクセス権を付与できます。グループにアクセス権を適用することで、メンバーに個別にアクセス権を設定せずにすみます。かわりにグループにユーザーを追加することで、そのユーザーにアクセス権を付与します。
次のサンプルACIは、HRgroupという名前のグループに、ディレクトリのou=Peopleブランチに対する完全アクセスを許可し、そのグループのメンバーが従業員情報を更新できるようにします:
aci: (targetattr="*") (version 3.0; acl "HR"; allow (all) groupdn= "ldap:///cn=HRgroup,ou=People,dc=example,dc=com";)
この例では、ACIがou=People,dc=example,dc=comエントリに追加されることを前提としています。
一部の組織では、それによる従業員の効率の向上やコーポレート・ダイナミクスへの貢献が見込まれる場合に、従業員にツリー内のエントリの作成を許可します。次のそれぞれの例では、example.comの社会委員会が様々なクラブ(テニス、水泳、スキーなど)に編成されていることを前提としています。
"Create Group" ACIの作成このサンプルACIは、example.comのあらゆる従業員が新しいクラブを表すグループ・エントリをou=social committeeブランチの下に作成することを許可します。
aci: (target = "ldap:///dc=ou=social committee,dc=example,dc=com") (targetfilter="(|(objectClass=groupOfNames)(objectClass=top))") (version 3.0; acl"Create Group"; allow (search,read,add) (userdn = @ "ldap:///uid=*,ou=People,dc=example,dc=com" and dns = "*.example.com");)
この例では、ACIがou=social committee,dc=example,dc=comエントリに追加されることを前提としています。
|
注意: このACIでは書込み権限を付与しません。つまり、エントリ作成者はエントリを変更できません。サーバーは暗黙的に |
"Delete Group" ACIの作成このサンプルACIは、グループの所有者のみがou=Social Committeeブランチの下にあるグループ・エントリを変更または削除できるようにします。
aci: (target="ou=social committee,dc=example,dc=com") (targetattr = "*") (targattrfilters="del=objectClass:(objectClass=groupOfNames)") (version 3.0; acl "Delete Group"; allow (write,delete) userattr="owner#GROUPDN";)
この例では、ACIがou=social committee,dc=example,dc=comエントリに追加されることを前提としています。
多くのディレクトリで、グループに対するユーザー自身の追加または削除をユーザーに許可するACIが設定されています。これは、たとえばユーザーが自分自身をメーリング・リストに追加したりそこから削除できるようにする場合などに役立ちます。次のサンプルACIは、すべての従業員がou=social committeeサブツリーの下にある任意のグループ・エントリに自分自身を追加できるようにします:
aci: (targettattr="member")(version 3.0; acl "Group Members"; allow (selfwrite) (userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") ;)
この例では、ACIがou=social committee,dc=example,dc=comエントリに追加されることを前提としています。
多くの場合、グループにディレクトリへのアクセス権を付与する際には、正しい権限を持つユーザーを偽装しようとする侵入者からこれらの権限を確実に保護する必要があります。そのため、グループまたはロールに重要なアクセスを許可するアクセス制御ルールには、たいてい多くの条件が関連付けられます。
次のサンプルACIは、次の条件が満たされた場合に、ディレクトリ・ツリーのcorporate-clientsブランチへの完全アクセスをDirectory Administratorsグループに許可します:
証明書を使用して、SSL経由の接続が認証される
月曜日から木曜日の08:00から18:00の間にアクセスがリクエストされる
指定されたIPアドレスからアクセスがリクエストされる
aci: (target="ou=corporate-clients,dc=example,dc=com") (targetattr = "*") (version 3.0; acl "corporate-clients"; allow (all) (groupdn="ldap:///cn=DirectoryAdmin,ou=corporate-clients,dc=example,dc=com") and (authmethod="ssl") and (dayofweek="Mon,Tue,Wed,Thu") and (timeofday >= "0800" and timeofday <= "1800") and (ip="255.255.123.234"); )
この例では、ACIがou=corporate-clients,dc=example,dc=comエントリに追加されることを前提としています。
ディレクトリ内にビジネスにとって重要な情報がある場合は、そのディレクトリへのアクセスを特に拒否する必要が生じることがあります。次のサンプルACIは、ユーザーが自分自身のエントリの下にある特定の請求情報(接続時間や勘定残高など)を読み取れるようにしますが、その情報の変更は禁止します。
このACIは、ユーザーが情報を読み取れるようにします。この例は、該当する属性がすでにスキーマ内に作成されていることを前提としています。
aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Read"; allow (search,read) userdn="ldap:///self";)
このACIは、ユーザーが情報を変更できないようにします。この例は、該当する属性がすでにスキーマ内に作成されていることを前提としています。
aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Deny"; deny (write) userdn="ldap:///self";)
LDIF ACI文の中にあるカンマを含むDNには、特別な処理が必要です。ACI文のターゲットとバインド・ルールの部分で、1つの円記号(\)を使用して、カンマをエスケープする必要があります。次の例でこの構文を示します:
dn: o=example.com Bolivia\, S.A. objectClass: top objectClass: organization aci: (target="ldap:///o=example.com Bolivia\,S.A.") (targetattr="*") (version 3.0; acl "aci 2"; allow (all) groupdn = "ldap:///cn=Directory Administrators, o=example.com Bolivia\, S.A.";)
プロキシ認可方式は特殊な形の認証で、自分自身のIDを使用してディレクトリにバインドするユーザーに、プロキシ認可を通じて別のユーザーの権限が付与されます。
この例では、次のことを想定しています:
クライアント・アプリケーションのバインドDNは、uid=MoneyWizAcctSoftware, ou=Applications,dc=example,dc=comです。
クライアント・アプリケーションがアクセスをリクエストするターゲット・サブツリーは、ou=Accounting,dc=example,dc=comです。
ou=Accounting,dc=example,dc=comサブツリーに対するアクセス権を持つAccounting Administratorが、ディレクトリ内に存在します。
クライアント・アプリケーションがAccountingサブツリーにアクセスできるようにするには(Accounting Administratorと同じアクセス権を使用して)、そのアプリケーションが次の権限と制御を持っている必要があります:
Accounting Administratorは、ou=Accounting,dc=example,dc=comサブツリーに対するアクセス権限を持つ必要があります。次のACIは、Accounting Administratorエントリにすべての権限を付与します:
aci: (target="ldap:///ou=Accounting,dc=example,dc=com") (targetattr="*") (version 3.0; acl "allow All-AcctAdmin"; allow (all) userdn="ldap:///uid=AcctAdministrator,ou=Administrators, dc=example,dc=com";)
クライアント・アプリケーションはプロキシ権限を持っている必要があります。次のACIは、クライアント・アプリケーションにプロキシ権限を付与します:
aci: (target="ldap:///ou=Accounting,dc=example,dc=com") (targetattr="*") (version 3.0; acl "allow proxy- accounting software"; allow (proxy) userdn= "ldap:///uid=MoneyWizAcctSoftware,ou=Applications, dc=example,dc=com";)
クライアント・アプリケーションはプロキシ認可制御を使用する許可を得る必要があります。次のACIは、クライアント・アプリケーションがプロキシ認可制御を使用することを許可します:
aci: (targetcontrol = "2.16.840.1.113730.3.4.18") (version 3.0; acl "allow proxy auth - accounting software"; allow (all) userdn="ldap:///uid=MoneyWizAcctSoftware,ou=Applications, dc=example,dc=com";)
これらのACIが定義されていれば、MoneyWizAcctSoftwareクライアント・アプリケーションは、ディレクトリにバインドし、プロキシDNのアクセス権を必要とするldapsearchやldapmodifyなどのLDAPコマンドを送信できます。
この例では、クライアントがldapsearchコマンドを実行する場合、そのコマンドには次のような制御が含まれます:
$ ldapsearch -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" \ -j pwd-file -Y "dn:uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" \ -b "ou=Accounting,dc=example,dc=com" "objectclass=*"\ ...
検索のベースはACIのターゲットと一致する必要があります。クライアントは自身としてバインドしますが、プロキシ・エントリの権限を付与されます。クライアントには、プロキシ・エントリのパスワードは不要です。
詳細は、第20.5.3.13項「プロキシ設定された認可制御を使用した検索」を参照してください。
ディレクトリのエントリのアクセス制御ポリシーを管理するときには、定義したACIのセキュリティへの影響を把握しておくと役に立ちます。ディレクトリ・サーバーで、既存のACIを評価して、それらのACIによって特定のエントリ上の特定のユーザーに付与された実効権限に関するレポートを生成できます。
ディレクトリ・サーバーは、検索操作に含めることができる実効権限取得制御に応答します。この制御に対するレスポンスは、検索結果のエントリおよび属性に関する実効権限情報を返すことです。この追加情報としては、各エントリとその中の各属性に対する読取り権限および書込み権限などがあります。検索や任意のDNに使用されるバインドDNについて権限をリクエストすることで、管理者がディレクトリ・ユーザーの権限をテストできます。
実効権限の機能は、LDAP制御に依存します。プロキシ・サーバーを通過するときに実効権限を表示するには、プロキシ・チェーン・ポリシー内でこの制御を有効にする必要があります。また、リモート・サーバーとのバインドに使用されるプロキシ・アイデンティティにも、実効権限属性へのアクセスを許可する必要があります。
実効権限取得制御の動作は、次の点でインターネット・ドラフトの実効権限取得制御(http://tools.ietf.org/html/draft-ietf-ldapext-acl-model-08)とは異なります:
検索結果とともに返されるレスポンス制御はありません。かわりに、権限情報が結果エントリに追加されます。また、権限情報の書式はドラフトと完全に異なっています(この書式については後述します)。
リクエスト制御はauthzidのみを取ります。
ldapsearchコマンドで実効権限取得制御を指定するには、2つの方法があります:
-J "1.3.6.1.4.1.42.2.27.9.5.2"オプションまたはより簡単な-J effectiverightsを使用します。実効権限取得制御のauthzidの値としてNULL値を指定すると、authzidとしてバインド・ユーザーが使用され、現在のldapsearch操作で返される属性およびエントリに対する権限が取得されます。
より単純で優先される方法は、-eオプションありまたはなしで-gオプションを使用することです:
-g "dn: DN"-- 指定されたDNにバインドしているユーザーの実効権限が検索結果に示されます。管理者は、このオプションを使用して他のユーザーの実効権限をチェックできます。オプション-g "dn:"を指定すると、匿名認証に対する実効権限が表示されます。
-e attributeName1 -e attributeName2 -- 指定された属性に対する実効権限も検索結果に含められます。このオプションは、エントリに関する検索結果に通常は含まれない属性を指定するために使用できます。たとえば、このオプションを使用すると、エントリ内に現在存在しない属性を追加する権限をユーザーが持っているかどうかを調べられます。
|
注意:
|
この2つの方法のいずれかを使用して実効権限取得制御を指定する以外に、表示する情報のタイプも指定する必要があります。すなわち、単純な権限を表示するか、それともそれらの権限がどのように付与または拒否されるかを説明する詳細なログ情報を表示するかを指定します。情報のタイプは、検索結果で返す属性として、aclRightsまたはaclRightsInfoをそれぞれ追加することで特定します。両方の属性をリクエストすると、実効権限の情報をすべて取得できます。ただし、単純な権限情報は詳細なログ情報と重複します。
|
注意:
|
実効権限機能は、アクセス制御に影響する他のパラメータ(時刻、認証方式、マシン・アドレス、マシン名など)を、検索操作を開始したユーザーから継承します。
次の例は、Carla Fuenteというユーザーがディレクトリ内の自分自身の権限をどのようにして表示するかを示しています。結果表示の中で、1は権限が付与されていることを意味し、0は権限が拒否されたことを意味します。
$ ldapsearch -J effectiverights -h rousseau.example.com -p 1389 \ -D "uid=cfuente,ou=People,dc=example,dc=com" -j pwd-file \ -b "dc=example,dc=com" "(objectclass=*)" aclRights dn: dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: ou=Groups, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=Accounting Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=HR Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=bjensen,ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=cfuente, ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0
この結果には、Carla Fuenteが少なくとも読取り権限を持つディレクトリ内のエントリが表示されており、彼女が自分自身のエントリを変更できることが示されています。実効権限制御は通常のアクセス権限をバイパスしないため、ユーザー自身が読取り権限を持たないエントリは表示されません。次の例で、ディレクトリ・マネージャは、Carla Fuenteが読取り権限を持たないエントリを確認できます:
$ ldapsearch -h rousseau.example.com -p 1389 -D "cn=Directory Manager" \ -j pwd-file -g "dn: uid=cfuente,ou=People,dc=example,dc=com" \ -b "dc=example,dc=com" "(objectclass=*)" aclRights dn: dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: ou=Groups, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=Directory Administrators, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0 dn: ou=Special Users,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0 dn: ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=Accounting Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=HR Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=bjensen,ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: uid=cfuente, ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0
この出力で、ディレクトリ・マネージャは、Carla Fuenteがディレクトリ・ツリーのSpecial UsersブランチもDirectory Administratorsブランチも表示できないことを確認できます。次の例で、ディレクトリ・マネージャは、Carla Fuenteが自分自身のエントリ内のmail属性とmanager属性を変更できないことを確認できます:
$ ldapsearch -h rousseau.example.com -p 1389 -D "cn=Directory Manager" \
-j pwd-file -g "dn: uid=cfuente,ou=People,dc=example,dc=com" \
-b "dc=example,dc=com" "(uid=cfuente)" aclRights "*"
version: 1
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;attributeLevel;mail: search:1,read:1,compare:1,
write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
mail: cfuente@example.com
aclRights;attributeLevel;uid: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
uid: cfuente
aclRights;attributeLevel;givenName: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
givenName: Carla
aclRights;attributeLevel;sn: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
sn: Fuente
aclRights;attributeLevel;cn: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
cn: Carla Fuente
aclRights;attributeLevel;userPassword: search:0,read:0,
compare:0,write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
userPassword: {SSHA}wnbWHIq2HPiY/5ECwe6MWBGx2KMiZ8JmjF80Ow==
aclRights;attributeLevel;manager: search:1,read:1,compare:1,
write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
manager: uid=bjensen,ou=People,dc=example,dc=com
aclRights;attributeLevel;telephoneNumber: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
telephoneNumber: (234) 555-7898
aclRights;attributeLevel;objectClass: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
実効権限リクエストに指定したオプションに応じて、次の情報が返されます:
実効権限情報は、次のサブタイプに従って示されます:
aclRights;entrylevel - エントリ・レベルの権限情報を示します
aclRights;attributelevel - 属性レベルの権限情報を示します
aclRightsInfo;entrylevel - エントリ・レベルのログ情報を示します
aclRightsInfo;attributelevel - 属性レベルのログ情報を示します
aclRights文字列の書式は次のとおりです:
aclRights;entryLevel: 権限:値(権限:値)*
および
aclRights;attributeLevel: 権限:値(権限:値)*
エントリ・レベルの権限としては、add、delete、read、writeおよびproxyがあります。それぞれの権限が取り得る値は、0(権限は付与されない)と1(権限が付与される)です。
| エントリ・レベルの権限 | 説明 |
|---|---|
|
|
ユーザーがエントリ全体を追加および削除する権限。 |
|
|
ユーザーがエントリ内の属性の読取りおよび検索を行う権限。 |
|
|
ユーザーがエントリ内の属性値の追加、削除および置換を行う権限。 |
|
|
ユーザーがエントリの権限でディレクトリにアクセスする権限。 |
属性レベルの権限としては、read、search、compare、write、selfwrite_add、selfwrite_deleteおよびproxyがあります。それぞれの権限が取り得る値は、0(権限は付与されない)と1(権限が付与される)です。write権限の場合は、値?も使用できます。
| 属性レベルの権限 | 説明 |
|---|---|
|
|
ユーザーがエントリ内の属性値を読み取る権限。 |
|
|
ユーザーがエントリ内の属性値を検索する権限。 |
|
|
ユーザーがエントリ内の属性値を自身が指定した値と比較する権限。 |
|
|
ユーザーがエントリ内の属性値の追加、削除および置換を行う権限。これは、 |
|
|
ユーザーが属性 |
|
|
ユーザーが属性 |
|
|
ユーザーがエントリ内の属性の権限でディレクトリにアクセスする権限。 |
|
注意:
|
aclRightsInfo文字列の書式は次のとおりです:
aclRightsInfo;logs;entryLevel;permission: acl_summary(main):permission-string
および
aclRightsInfo;logs;attributeLevel;permission;attribute: acl_summary(main):permission-string
エントリ・レベルと属性レベルの権限については、前の項で説明しています。
permission-stringには、エントリ・レベルと属性レベルの実効権限に関する詳細情報が含まれています。
write、selfwrite_addおよびselfwrite_delete権限属性レベルのwrite権限の値は、0、1または?です。属性レベルのwrite権限のみが値として?を取ることができますが、この値は通常はACIコンポーネントtargattrfiltersに由来します。add権限とdelete権限の場合、変更できるエントリは、そのエントリ内の属性の値によって決まります。エントリに対する権限の値としては、0または1のみが返されますが、これは値がldapsearch操作で返されるためです。
authorization dn以外のすべての属性値については、write権限の値が1の場合、追加と削除の両方の権限が付与されます。同様に、authorization dn以外のすべての属性値については、write権限の値が0の場合、ldapmodify操作の追加と削除のどちらについても権限を付与されないことを意味します。authorization dnの値に対して有効になっている権限は、selfwrite権限の1つ(つまりselfwrite_addまたはselfwrite_delete)として明示的に返されます。
属性レベルの権限selfwrite_addおよびselfwrite_deleteはACIのコンテキスト内には存在しませんが、ACIのセットは、変更操作の追加の部分または削除の部分についてのみselfwrite権限を付与できます。selfwrite権限の場合、変更の対象となる属性の値はauthorization dnです。write権限については同じ区別は行われません。write権限では変更の対象となる属性の値が未定義だからです。
実効権限がtargattrfilters ACIに依存する場合、値?は権限の詳細を知るためにログ情報を参照する必要があることを意味します。write、selfwrite_addおよびselfwrite_delete権限の間の相互依存性は非常に複雑です。その概要を次の表で説明します。
表25-1 実効権限の相互依存性
| write | selfwrite_add | selfwrite_delete | 実効権限の説明 |
|---|---|---|---|
|
|
|
|
この属性のどの値も、追加も削除もできません。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
この属性のすべての値を追加または削除できます。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
実効権限のログ情報は、アクセス制御の問題の理解とデバッグに役立ちます。ログ情報には、acl_summaryと呼ばれるアクセス制御サマリー文が含まれています。このサマリーには、アクセス制御がなぜ許可または拒否されたかが示されます。アクセス制御サマリー文には、次の情報が含まれています:
アクセスが許可されたか、それとも拒否されたか
付与された権限
権限のターゲット・エントリ
ターゲット属性の名前
リクエストされている権限のサブジェクト
リクエストの発行元がプロキシかどうか(プロキシの場合はプロキシ認証DNも報告されます)
アクセスを許可または拒否する理由(次の表で説明しているように、デバッグが目的の場合に重要です)
次の表に、実効権限のログ情報の理由とその説明を示します。
表25-2 実効権限ログ情報の理由とその説明
| ログ情報の理由 | 説明 |
|---|---|
|
|
アクセスがなぜ許可または拒否されたかを説明するための理由がありません。 |
|
|
|
|
|
キャッシュされた情報を使用して、アクセス拒否が決定されました。 |
|
|
キャッシュされた情報を使用して、アクセス許可が決定されました。 |
|
|
ACIが評価されて、アクセス許可が決定されました。ACIの名前がログ情報に含められます。 |
|
|
ACIが評価されて、アクセス拒否が決定されました。ACIの名前がログ情報に含められます。 |
|
|
リソースまたはターゲットに一致するACIがないため、アクセスが拒否されます。 |
|
|
アクセス制御をリクエストしているサブジェクトに一致するACIがないため、アクセスが拒否されます。 |
|
|
|
|
|
|
|
|
ユーザーがルートDNであるため、アクセスを許可されます。 |
|
注意: 仮想属性については書込み権限は付与されず、関連するログ評価情報も提供されません。仮想属性は更新できないためです。 |
実効権限を表示する操作はそれ自体が、保護と適切な制限を必要とするディレクトリ操作です。
デフォルトのACIでは、実効権限を返すために使用されるaclRightsおよびaclRightsInfo操作属性に対する読取りアクセスは許可されません。ディレクトリ・ユーザーがこの情報にアクセスできるように、これらの属性のために新しいACIを作成してください。
たとえば次のACIは、Directory Administratorsグループのメンバーに実効権限の取得を許可します:
aci: (targetattr = "aclRights||aclRightsInfo")(version 3.0; acl "getEffectiveRights"; allow(all) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)
さらに、実効権限取得制御を使用するためのアクセス権も必要です。
実効権限取得制御にディレクトリ・ユーザーがアクセスできるようにするには、この制御のOID (1.3.6.1.4.1.42.2.27.9.5.2)を使用して新しいACIターゲットを作成します。ACI構文の詳細は、第9.2.2項「ターゲットの定義」を参照してください。
たとえば次のACIは、Directory Administratorsグループのメンバーが実効権限取得制御を使用することを許可します:
aci: (targetcontrol = "1.3.6.1.4.1.42.2.27.9.5.2")(version 3.0; acl "getEffectiveRights control access"; allow(all) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)
