この章では、データへのアクセスを制御するACIの作成方法について説明します。
セキュアなディレクトリ・サービスを作成するためには、ディレクトリの内容へのアクセスを制御することが最も重要です。データへのアクセスはアクセス制御命令(ACI)によって管理されます。ACIでは、個々のエントリ、各エントリに属するすべてのサブエントリ、またはグローバル・ベースで全エントリに対するアクセス権を指定します。
多数のACIや複雑なACIを使用すると、少数の単純なACIを使用する場合より多くの処理リソースが必要になります。多数のACIや極端に複雑なACIを指定すると、パフォーマンスが大幅に低下する可能性があります。
Oracle Unified Directoryには、特定のエントリに対する特定のユーザーの実効権限を表示する機能があります。この機能により、複雑で強力なアクセス制御メカニズムの管理が簡素化されます。
この章の構成は、次のとおりです。
dsconfig
を使用したグローバルACIの管理グローバルACIは、部分的なサブツリーではなく、DITのルートへのアクセスを制御します。グローバルACIは、ディレクトリ内のすべてのエントリに適用されます。グローバルACIは、dsconfig
コマンドとldapmodify
コマンドを使用して、設定、リセットおよび削除できます。dsconfig
は、管理コネクタを使用してSSLを介してサーバーの構成にアクセスします。dsconfig
の詳細は、第17.1項「dsconfig
を使用したサーバー構成の管理」を参照してください。
サブツリー内のエントリに適用されるACIを、dsconfig
を使用して管理することはできません。グローバルではないACIの管理方法は、第28.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 5444 -D cn="Directory Manager" -j pwd-file.txt -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||su : pportedExtension||supportedFeatures||supportedLDAPVersion||support : edSASLMechanisms||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="obje : ctClass||attributeTypes||dITContentRules||dITStructureRules||ldapS : yntaxes||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="*")(version : 3.0; acl "Replication backend access"; deny (all) : userdn="ldap:///anyone";), : (targetattr="audio||authPassword||description||displayName||givenN : ame||homePhone||homePostalAddress||initials||jpegPhoto||labeledURI : ||mobile||pager||postalAddress||postalCode||preferredLanguage||tel : ephoneNumber||userPassword")(version 3.0; acl "Self entry : modification"; allow (write) userdn="ldap:///self";), : "(targetattr="createTimestamp||creatorsName||modifiersName||modify : Timestamp||entryDN||entryUUID||subschemaSubentry||orclguid||nsuniq : ueid")(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 /tmp/passwd.txt -X -n \ set-access-control-handler-prop \ --remove global-aci: "(targetattr="createTimestamp||creatorsName||modifiersName||modifyTimestamp||entryDN||entryUUID||subschemaSubentry") \ (version 3.0;acl "User-Visible Operational Attributes"; allow (read,search,compare) \ userdn=\"ldap:///anyone\";)"
グローバルACIを追加するときには、コマンド行シェルの規則に従ってACI指定内の特殊文字をすべてエスケープしてください。
次の例では、dsconfig
を非対話モードで使用して、前の手順で削除したグローバルACIを追加しています:
dsconfig
コマンドは次のように実行します。
$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j /tmp/passwd.txt -X -n \ set-access-control-handler-prop \ --add global-aci:"(targetattr="*")(version 3.0; acl "Self entry modification"; allow (write) \ userdn=\"ldap:///self\";)"
ldapmodify
によるACIの管理LDIF文を使用してアクセス制御命令(ACI)を手動で作成し、ldapmodify
コマンドを使用してそのACIをディレクトリに追加することができます。ACIの値は非常に複雑な場合があるため、既存の値を表示してそれをコピーすれば、新しいACIを作成する助けになります。
ここに示されている以外のACIのサンプルについては、第28.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の値によってどのような権限が付与または拒否されているかを表示する方法は、第28.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を使用して次の手順で表示できます:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
構成済ACIはすべて、そのACIが定義されているアクセス制御ポイントの下に表示されます。ACIを表示するには、そのACIが定義されているアクセス制御ポイントを開きます。たとえば、ルート・エントリに適用されるACIのリストを表示するには、ルート・エントリを開きます。
ACIを選択すると、そのプロパティが右側のペインに表示されます。
アクセス制御ポイントは、その中にACIが定義されているエントリです(つまり、対応するaci
属性を含んでいるエントリです)。
ODSMを使用して、新規のアクセス制御ポイントを次の手順で定義できます:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
「作成」アイコンをクリックします。
新しいアクセス制御ポイントとなるエントリのDNを「場所」フィールドに入力するか、「選択」をクリックしてディレクトリからエントリを選択します。
1つまたは複数のACIをアクセス制御ポイントに追加するには、「ACIの作成」をクリックします。
ACIの詳細を入力します。これらのフィールドの詳細は、第28.3.5項「ACIの追加」を参照してください。
アクセス制御ポイントに必要なACIを追加し終わったら、「作成」をクリックします。
ODSMを使用して、既存のアクセス制御ポイントに基づく新規のアクセス制御ポイントを次の手順で定義できます:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
新しいアクセス制御ポイントのベースにするアクセス制御ポイントを選択します。
「類似作成」アイコンをクリックします。
新しいアクセス制御ポイントとなるエントリのDNを「場所」フィールドに入力するか、「選択」をクリックしてディレクトリからエントリを選択します。
ベースにしたアクセス制御ポイントと同じACLを持つ新しいアクセス制御ポイントが自動的に作成されます。
新しいアクセス制御ポイントに対して既存のACIの追加、編集または削除を行うには、それぞれ「作成」、「編集」または「削除」をクリックします。
ACIを追加または編集する場合は、必要な詳細を入力します。これらのフィールドの詳細は、第28.3.5項「ACIの追加」を参照してください。
新しいアクセス制御ポイントのACIの変更が終わったら、「作成」をクリックします。
ODSMを使用して、アクセス制御ポイントを次の手順で削除できます:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
削除するアクセス制御ポイントを選択し、「削除」アイコンをクリックします。
「OK」をクリックして、削除を確定します。
ODSMを使用して、次の手順でACIを既存のアクセス制御ポイントに追加できます:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、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を次の手順で追加できます:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
コピーするACIが含まれているアクセス制御ポイントを開きます。
コピーするACIを選択します。
「類似追加」アイコンをクリックします。
変更が必要なACIの要素を、「テキスト・エディタ・ビュー」または「詳細の表示」で編集します。
ACI定義が完成したら、「作成」をクリックします。
ODSMを使用して、既存のACIを次の手順で変更できます:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」要素を開きます。
変更するACIが含まれているアクセス制御ポイントを開きます。
変更するACIを選択します。
「テキスト・エディタ・ビュー」または「詳細の表示」で、ACIの要素を編集します。
変更が完了したら、「適用」をクリックします。
ODSMを使用して、target、targetFilter、userDn、groupDN
およびuserAttr
属性にマクロ式を入力できます。マクロACIの詳細は、第9.6項「高度なアクセス制御のためのマクロACIの使用」を参照してください。
このセクションには次のトピックが含まれます:
この項では、ターゲットにマクロACIを入力する方法について説明します。
ターゲットを編集してマクロACIを入力するには:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」リストから、編集するACIを選択します。
「ターゲット」表から「ターゲット」行を選択します。
「編集」をクリックします。
「ターゲット」フィールドにマクロ式を入力します。
「OK」をクリックします。
この項では、ターゲット・フィルタにマクロACIを入力する方法について説明します。
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」リストから、編集するACIを選択します。
「ターゲット」表から「ターゲット・フィルタ」行を選択します。
「編集」をクリックします。
「ターゲット」フィールドに、マクロ式を使用してフィルタを入力します。
「OK」をクリックします。
この項では、ターゲット・リソースに対する特定のユーザーまたは特定のグループのアクセス権を定義する方法について説明します。
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」リストから、編集するACIを選択します。
「権限」表から「バインド・ルール」行を選択します。
「編集」をクリックします。
「バインド・ルール・タイプ」リストから、目的のバインド・ルールを選択します。
「アクセス先」タブで、「ユーザーDN」リストから「ユーザーの指定」を選択します。
「ユーザー」表で次のステップを実行します:
「追加」をクリックします。
ユーザー・アクセスを定義するマクロ式を入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。
ターゲット・リソースに対する特定のグループのアクセス権を指定するには、「グループDN演算子」表で次のステップを実行します:
「追加」をクリックします。
グループ・アクセスを定義するマクロ式を入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。
「OK」をクリックします。
注意: 個々のバインド・ルールを編集することもできます。バインド・ルールを変更するには、「権限」表で必要なバインド・ルールを選択してから「編集」をクリックする必要があります。 |
この項では、ユーザー属性のバインド・ルールを編集する方法について説明します。
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ディレクトリACL」リストから、編集するACIを選択します。
「権限」表から「バインド・ルール」行を選択します。
「編集」をクリックします。
「ユーザー属性」タブをクリックします。
「バインド・ルール・タイプ」リストから、目的のバインド・ルールを選択します。
「エントリ選択」プロパティの値として、「特定のエントリ」を選択します。
「エントリ・ベースDN」フィールドで、ベースDNを入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。
「ユーザー属性」フィールドで、属性名を入力するか、「選択」をクリックして属性名のリストから属性名を選択します。
「バインド・タイプ・フォーマット」をクリックします。
「バインド・タイプ値」リストから、目的の値を選択します。
「OK」をクリックします。
注意: 個々のバインド・ルールを編集することもできます。バインド・ルールを変更するには、「権限」表で必要なバインド・ルールを選択してから「編集」をクリックする必要があります。 |
この項では、アクセス制御ポリシーの実装に使用できるサンプルACIをいくつか示します。
顧客がuserpassword
およびauthPassword
属性を除いてすべてのユーザー属性の匿名ACIを事前に付与しているとします。
次の例では、dsconfigを非対話モードで使用して、同じグローバルACIを削除しています。
dsconfig
コマンドを次のように実行します:
$ dsconfig -h localhost -p 4444 -D cn="Directory Manager" -j /tmp/passwd.txt -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は、ユーザー自身のエントリの属性の限られたサブセットに対する書込みアクセスを許可します。これには次の属性が含まれます:
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では書込み権限を付与しません。つまり、エントリ作成者はエントリを変更できません。サーバーは暗黙的にtop という値を追加するため、targattrfilters にobjectClass=top を指定する必要があります。 |
"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のターゲットと一致する必要があります。クライアントは自身としてバインドしますが、プロキシ・エントリの権限を付与されます。クライアントには、プロキシ・エントリのパスワードは不要です。
詳細は、第18.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
-- 指定された属性に対する実効権限も検索結果に含められます。このオプションは、エントリに関する検索結果に通常は含まれない属性を指定するために使用できます。たとえば、このオプションを使用すると、エントリ内に現在存在しない属性を追加する権限をユーザーが持っているかどうかを調べられます。
注意: -e オプションは-g オプションとともに使用する必要があります。また、-J オプションとともには使用できません。
|
この2つの方法のいずれかを使用して実効権限取得制御を指定する以外に、表示する情報のタイプも指定する必要があります。すなわち、単純な権限を表示するか、それともそれらの権限がどのように付与または拒否されるかを説明する詳細なログ情報を表示するかを指定します。情報のタイプは、検索結果で返す属性として、aclRights
またはaclRightsInfo
をそれぞれ追加することで特定します。両方の属性をリクエストすると、実効権限の情報をすべて取得できます。ただし、単純な権限情報は詳細なログ情報と重複します。
注意: 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
(権限が付与される)です。
エントリ・レベルの権限 | 説明 |
---|---|
add およびdelete |
ユーザーがエントリ全体を追加および削除する権限。 |
read |
ユーザーがエントリ内の属性の読取りおよび検索を行う権限。 |
write |
ユーザーがエントリ内の属性値の追加、削除および置換を行う権限。 |
proxy |
ユーザーがエントリの権限でディレクトリにアクセスする権限。 |
属性レベルの権限としては、read
、search
、compare
、write
、selfwrite_add
、selfwrite_delete
およびproxy
があります。それぞれの権限が取り得る値は、0
(権限は付与されない)と1
(権限が付与される)です。write権限の場合は、値?
も使用できます。
属性レベルの権限 | 説明 |
---|---|
read |
ユーザーがエントリ内の属性値を読み取る権限。 |
search |
ユーザーがエントリ内の属性値を検索する権限。 |
compare |
ユーザーがエントリ内の属性値を自身が指定した値と比較する権限。 |
write |
ユーザーがエントリ内の属性値の追加、削除および置換を行う権限。これは、authorization dn 以外のすべての属性に適用されます。 |
selfwrite_add |
ユーザーが属性authorization dn を追加する権限。 |
selfwrite_delete |
ユーザーが属性authorization dn を削除する権限。 |
proxy |
ユーザーがエントリ内の属性の権限でディレクトリにアクセスする権限。 |
注意: write 、selfwrite_add およびselfwrite_delete 権限は特に複雑です。権限の値が? になっている場合は、ログ情報を確認して、なぜその権限が付与される(またはされない)かを明確にしてください。詳細については、表28-1を参照してください。 |
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
権限の間の相互依存性は非常に複雑です。その概要を次の表で説明します。
表28-1 実効権限の相互依存性
write | selfwrite_add | selfwrite_delete | 実効権限の説明 |
---|---|---|---|
|
|
|
この属性のどの値も、追加も削除もできません。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
この属性のすべての値を追加または削除できます。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
実効権限のログ情報は、アクセス制御の問題の理解とデバッグに役立ちます。ログ情報には、acl_summary
と呼ばれるアクセス制御サマリー文が含まれています。このサマリーには、アクセス制御がなぜ許可または拒否されたかが示されます。アクセス制御サマリー文には、次の情報が含まれています:
アクセスが許可されたか、それとも拒否されたか
付与された権限
権限のターゲット・エントリ
ターゲット属性の名前
リクエストされている権限のサブジェクト
リクエストの発行元がプロキシかどうか(プロキシの場合はプロキシ認証DN)
アクセスを許可または拒否する理由(次の表で説明しているように、デバッグが目的の場合に重要です)
次の表に、実効権限のログ情報の理由とその説明を示します。
表28-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";)