1. Oracle Unified Directoryの管理
  2. 高度な管理: セキュリティ、アクセス制御およびパスワード・ポリシー
  3. データへのアクセス制御

28 データへのアクセス制御

セキュアなディレクトリ・サービスを作成するためには、ディレクトリの内容へのアクセスを制御することが最も重要です。データへのアクセスはアクセス制御命令(ACI)によって管理されます。ACIでは、個々のエントリ、各エントリに属するすべてのサブエントリ、またはグローバル・ベースで全エントリに対するアクセス権を指定します。

多数のACIや複雑なACIを使用すると、少数の単純なACIを使用する場合より多くの処理リソースが必要になります。多数のACIや極端に複雑なACIを指定すると、パフォーマンスが大幅に低下する可能性があります。

Oracle Unified Directoryには、特定のエントリに対する特定のユーザーの実効権限を表示する機能があります。この機能により、複雑で強力なアクセス制御メカニズムの管理が簡素化されます。

ノート:

ACIモデルの概要は、「Oracle Unified Directoryのアクセス制御モデルの理解」を参照してください。

トピック

28.1 dsconfigを使用したグローバルACIの管理

グローバルACIは、部分的なサブツリーではなく、DITのルートへのアクセスを制御します。グローバルACIは、ディレクトリ内のすべてのエントリに適用されます。

グローバルACIは、dsconfigコマンドとldapmodifyコマンドを使用して、設定、リセットおよび削除できます。dsconfigは、管理コネクタを使用してSSLを介してサーバーの構成にアクセスします。dsconfigおよび非グローバルACIの管理の詳細は、次のトピックを参照してください。

28.1.1 デフォルト・グローバルACIについて

Oracle Unified Directoryをインストールするときに、9個のデフォルト・グローバルACIが定義されます。すべてのデフォルト・グローバルACIの効果について、このトピックを確認してください。

デフォルト・グローバルACIの効果は、次を可能にすることです:

  • 特定のコントロールと拡張操作に対して誰もが読取りアクセス権を持ちます。

  • 属性に対して誰もがルートDSEレベルでの検索、比較、および読取りアクセス権を持ちます。特定の属性にアクセスするには明示的なアクセス権が必要となります。

  • 認証されたユーザーはディレクトリ内にある自分自身のエントリ内の属性のサブセットを変更できます。ユーザーは自分自身のエントリを削除できません。

  • ルートDSE内の多くの操作属性とcn=schemaを含む主要な操作属性と、サーバー全体の各エントリ内に現れるその他の属性に対するアクセス権を、すべてのユーザーが持ちます。

プロキシはLDAPリクエストをリモートLDAPサーバーへ転送し、リモートLDAPサーバーがACIを評価します。したがって、プロキシ・バインド・リクエストで使用されるアイデンティティに適用可能なACIをリモートLDAPサーバーで構成する必要があります。

28.1.2 グローバル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";)

28.1.3 グローバルACIの削除

グローバルACIを削除する最も簡単な方法は、dsconfigを対話モードで使用することです。対話モードでは、ガイドに従ってACI構成に対する操作を実行できるため、ここでは操作法を説明しません。非対話モードでグローバルACIを削除する場合は、コマンド行シェルの規則に従って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\" ;)"

28.1.4 グローバル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  \
--add global-aci:"(targetattr!=\"userPassword || authPassword\") \
(version 3.0 ; acl \" Anonymous read access\" ; allow ( read,search,compare ) \
userdn=\"ldap:///anyone\" ;)"

28.2 ldapmodifyによるACIの管理

LDIF文を使用してアクセス制御命令(ACI)を手動で作成し、ldapmodifyコマンドを使用してそのACIをディレクトリに追加することができます。ACIの値は非常に複雑な場合があるため、既存の値を表示してそれをコピーすれば、新しいACIを作成する助けになります。

ここに示されている以外のACIのサンプルについては、「アクセス制御の管理」を参照してください。

LDIF文を使用してACIでタスクを実行する方法については、次の各項で説明します。

28.2.1 ACI属性の値の表示

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.2.2 ACIの追加

ACIを追加するには、LDIFファイル内でACIを指定し、ldapmodifyコマンドを使用してそのLDIFファイルを適用します。LDIFファイルは1つ以上のaci属性を含んでいる必要があり、各aci属性は接頭辞aci:とその後に続くACI指定で構成されます。

詳細は、「アクセス制御命令の構文の理解」を参照してください。

ACIを追加するには:

  1. 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";)
  2. 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

28.2.3 ACIの削除

ACIを削除するには、LDIFファイル内のACIの値を指定し、ldapmodifyコマンドを使用してその値を削除します。

ACIを削除するには:

  1. 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";)
  2. 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

28.3 OUDSMを使用したアクセス制御の管理

OUDSMを使用すると、使いやすいインタフェースで、サーバー内で構成されている既存のACIを表示したり、新規のアクセス制御ポイントを作成したり、新規のACIを作成することができます。

OUDSMを使用してアクセス制御を管理する方法については、次の各項で説明します。

28.3.1 構成済ACIの表示

Oracle Unified Directoryは、デフォルトで複数の事前構成済アクセス制御命令(ACI)をサポートしています。Oracle Unified Directory Services Manager (OUDSM)を使用して、サーバーに構成されているすべてのACIを表示できます。

OUDSMを使用して、サーバーに構成されているすべてのACIを表示するには:

  1. 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
  2. 「セキュリティ」タブを選択します。
  3. 「ディレクトリACL」要素を開きます。
  4. 構成済ACIはすべて、そのACIが定義されているアクセス制御ポイントの下に表示されます。ACIを表示するには、そのACIが定義されているアクセス制御ポイントを開きます。たとえば、ルート・エントリに適用されるACIのリストを表示するには、ルート・エントリを開きます。
  5. ACIを選択すると、そのプロパティが右側のペインに表示されます。

28.3.2 アクセス制御ポイントの作成

アクセス制御ポイントは、その中にACIが定義されているエントリです。つまり、対応するaci属性を含んでいるエントリです。

OUDSMを使用して新規のアクセス制御ポイントを定義するには:

  1. 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
  2. 「セキュリティ」タブを選択します。
  3. 「ディレクトリACL」要素を開きます。
  4. 「作成」アイコンをクリックします。
  5. 新しいアクセス制御ポイントとなるエントリのDNを「場所」フィールドに入力するか、「選択」をクリックしてディレクトリからエントリを選択します。
  6. 1つまたは複数のACIをアクセス制御ポイントに追加するには、「ACIの作成」をクリックします。
  7. ACIの詳細を入力します。これらのフィールドの詳細は、「ACIの追加」を参照してください。
  8. アクセス制御ポイントに必要なACIを追加し終わったら、「作成」をクリックします。

28.3.3 既存のアクセス制御ポイントに基づくアクセス制御ポイントの作成

Oracle Unified Directory Services Manager (OUDSM)を使用すると、既存のアクセス制御ポイントに基づいた新規アクセス制御ポイントを定義できます。

OUDSMを使用して新規アクセス制御ポイントを定義するには:

  1. 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
  2. 「セキュリティ」タブを選択します。
  3. 「ディレクトリACL」要素を開きます。
  4. 新しいアクセス制御ポイントのベースにするアクセス制御ポイントを選択します。
  5. 「類似作成」アイコンをクリックします。
  6. 新しいアクセス制御ポイントとなるエントリのDNを「場所」フィールドに入力するか、「選択」をクリックしてディレクトリからエントリを選択します。
  7. ベースにしたアクセス制御ポイントと同じACLを持つ新しいアクセス制御ポイントが自動的に作成されます。
  8. 新しいアクセス制御ポイントに対して既存のACIの追加、編集または削除を行うには、それぞれ「作成」、「編集」または「削除」をクリックします。
  9. ACIを追加または編集する場合は、必要な詳細を入力します。これらのフィールドの詳細は、「ACIの追加」を参照してください。
  10. 新しいアクセス制御ポイントのACIの変更が終わったら、「作成」をクリックします。

28.3.4 アクセス制御ポイントの削除

Oracle Unified Directory Services Managerを使用すると、アクセス制御ポイントを削除できます。

OUDSMを使用してアクセス制御ポイントを削除するには:

  1. 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
  2. 「セキュリティ」タブを選択します。
  3. 「ディレクトリACL」要素を開きます。
  4. 削除するアクセス制御ポイントを選択し、「削除」アイコンをクリックします。
  5. 「OK」をクリックして、削除を確定します。

28.3.5 ACIの追加

Oracle Unified Directory Services Manager (OUDSM)を使用すると、既存のアクセス制御ポイントにアクセス制御命令(ACI)を追加できます。

OUDSM:を使用して既存のアクセス制御ポイントにACIを追加するには:

  1. 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。

  2. 「セキュリティ」タブを選択します。

  3. 「ディレクトリACL」要素を開きます。

  4. 新しいACIを追加するアクセス制御ポイントを開きます。

  5. アクセス制御リストからACIを1つ選択します。

  6. 「追加」アイコンをクリックします。

  7. 使いやすいインタフェースを使用してACIを作成する場合は、「詳細の表示」タブを選択します。

  8. 「範囲」で、ACIの範囲を選択します。

    通常、ACIの範囲はサブツリーです。ACIの範囲は、次のいずれかの値を選択して制限できます:

    • 「ベース」。ACIは、ターゲット・リソースにのみ適用されます。

    • 「1」。ACIは、ターゲット・リソースの第1世代の子に適用されます。

    • 「サブツリー」。ACIは、ターゲット・リソースとその下にあるサブツリーに適用されます。

    • 「下位」。ACIは、ターゲット・リソースの下にあるサブツリーにのみ適用されます。

  9. 「ターゲット」フィールドで、ACIの各要素を選択して「編集」をクリックし、そのプロパティを定義します。

    ACIターゲットの定義方法の詳細は、「ターゲットの定義」を参照してください。

    ターゲットのエントリに出現する1つ以上の属性を対象にして、エントリに関する情報の一部へのアクセスを拒否または許可できるようになりました。次のステップを実行します。

    1. 「ターゲット」フィールドで、「ターゲット属性」を選択して「編集」をクリックします。

    2. 「演算子」に目的の値を選択します。

    3. 「属性」で、目的のオプションを選択します。

    4. 「追加」をクリックして、1つ以上のACI属性とサブタイプを入力します。「検索」をクリックして、属性名を検索することもできます。

      「サブタイプ(オプション)」フィールドに属性のサブタイプを入力することもできます。同じ属性に対して複数のサブタイプを入力できます。

    5. 「OK」をクリックします。

    詳細は、「ターゲット・エントリ内の属性のターゲット指定」を参照してください。

  10. 「権限」フィールドで、「追加」アイコンをクリックして権限とバインド・ルールを定義します。

    ACI権限の定義方法の詳細は、「パーミッションの設定」を参照してください。

    バインド・ルールの定義方法の詳細は、「バインド・ルールの理解」を参照してください。

    バインド・ルールを定義するには:

    1. 「バインド・ルール・タイプ」リストから、目的のバインド・ルールを選択します。

    2. 「ユーザー属性」タブをクリックし、ユーザー属性バインド・ルールを作成します。

    3. 「ユーザー属性演算子」プロパティの値を選択します。

    4. 「エントリ選択」プロパティの値として、「ターゲット・エントリとそのサブツリー」を選択します。

    5. 「継承レベル」リストから、継承レベルの値を選択します。

    6. 「ユーザー属性」フィールドで、属性を入力するか、「選択」をクリックしてエントリを検索します。

    7. 「ユーザー属性タイプ」プロパティとして、「バインド・タイプ・フォーマット」をクリックします。

    8. 「バインド・タイプ値」リストから、バインド・タイプ値を選択します。

    9. 「OK」をクリックします。

  11. ACIを手動で定義する場合は、「テキスト・エディタ・ビュー」タブをクリックしてACIの詳細を入力します。

    「検証」をクリックして、作成中のACIがACI構文に従っているかどうかチェックします。

    このビューを使用して、既存のACIをコピーして貼り付けることもできます。

  12. ACI定義が完成したら、「作成」をクリックします。

28.3.6 既存のACIに基づくACIの追加

Oracle Unified Directory Services Manager (OUDSM)を使用すると、既存のACIに基づいたアクセス制御命令(ACI)を追加できます。

  1. 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
  2. 「セキュリティ」タブを選択します。
  3. 「ディレクトリACL」要素を開きます。
  4. コピーするACIが含まれているアクセス制御ポイントを開きます。
  5. コピーするACIを選択します。
  6. 「類似追加」アイコンをクリックします。
  7. 変更が必要なACIの要素を、「テキスト・エディタ・ビュー」または「詳細の表示」で編集します。
  8. ACI定義が完成したら、「作成」をクリックします。

28.3.7 ACIの変更

Oracle Unified Directory Services Manager (OUDSM)を使用すると、既存のアクセス制御命令(ACI)を変更できます。

OUDSMを使用して既存のACIを変更するには:

  1. 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
  2. 「セキュリティ」タブを選択します。
  3. 「ディレクトリACL」要素を開きます。
  4. 変更するACIが含まれているアクセス制御ポイントを開きます。
  5. 変更するACIを選択します。
  6. 「テキスト・エディタ・ビュー」または「詳細の表示」で、ACIの要素を編集します。
  7. 変更が完了したら、「適用」をクリックします。

28.4 OUDSMを使用したマクロACIの管理

OUDSMを使用して、target、targetFilter、userDn、groupDNおよびuserAttr属性にマクロ式を入力できます。

マクロACIの詳細は、「高度なアクセス制御のためのマクロACIの使用」を参照してください。

この項では、次の項目について説明します。

28.4.1 ターゲットの編集

Oracle Unified Directory Services Managerを使用すると、ターゲットを編集してマクロ・アクセス制御命令を入力できます。

ターゲットを編集してマクロACIを入力するには:

  1. 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
  2. 「セキュリティ」タブを選択します。
  3. 「ディレクトリACL」リストから、編集するACIを選択します。
  4. 「ターゲット」表から「ターゲット」行を選択します。
  5. 「編集」をクリックします。
  6. 「ターゲット」フィールドにマクロ式を入力します。
  7. 「OK」をクリックします。

28.4.2 ターゲット・フィルタの編集

Oracle Unified Directory Services Managerを使用すると、ターゲット・フィルタを編集できます。

ターゲット・フィルタを編集するには:

  1. 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
  2. 「セキュリティ」タブを選択します。
  3. 「ディレクトリACL」リストから、編集するACIを選択します。
  4. 「ターゲット」表から「ターゲット・フィルタ」行を選択します。
  5. 「編集」をクリックします。
  6. 「ターゲット」フィールドに、マクロ式を使用してフィルタを入力します。
  7. 「OK」をクリックします。

28.4.3 ユーザーDNまたはグループDNのバインド・ルールの編集

Oracle Unified Directory Services Managerを使用すると、特定のユーザーまたは特定のグループに対してターゲット・リソースへのアクセスを定義できます。

ユーザーDNまたはグループDNのバインド・ルールを編集するには:

  1. 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。

  2. 「セキュリティ」タブを選択します。

  3. 「ディレクトリACL」リストから、編集するACIを選択します。

  4. 「権限」表から「バインド・ルール」行を選択します。

  5. 「編集」をクリックします。

  6. 「バインド・ルール・タイプ」リストから、目的のバインド・ルールを選択します。

  7. 「アクセス先」タブで、「ユーザーDN」リストから「ユーザーの指定」を選択します。

  8. 「ユーザー」表で次のステップを実行します:

    1. 「追加」をクリックします。

    2. ユーザー・アクセスを定義するマクロ式を入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。

  9. ターゲット・リソースに対する特定のグループのアクセス権を指定するには、「グループDN演算子」表で次のステップを実行します:

    1. 「追加」をクリックします。

    2. グループ・アクセスを定義するマクロ式を入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。

  10. 「OK」をクリックします。

ノート:

個々のバインド・ルールを編集することもできます。バインド・ルールを変更するには、「権限」表で必要なバインド・ルールを選択してから「編集」をクリックする必要があります。

28.4.4 ユーザー属性のバインド・ルールの編集

Oracle Unified Directory Services Manager (OUDSM)を使用すると、ユーザー属性のバインド・ルールを編集できます。

ユーザー属性のバインド・ルールを編集するには:

  1. 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
  2. 「セキュリティ」タブを選択します。
  3. 「ディレクトリACL」リストから、編集するACIを選択します。
  4. 「権限」表から「バインド・ルール」行を選択します。
  5. 「編集」をクリックします。
  6. 「ユーザー属性」タブをクリックします。
  7. 「バインド・ルール・タイプ」リストから、目的のバインド・ルールを選択します。
  8. 「エントリ選択」プロパティの値として、「特定のエントリ」を選択します。
  9. 「エントリ・ベースDN」フィールドで、ベースDNを入力するか、「選択」をクリックしてエントリを検索し、選択したエントリにマクロ式を追加します。
  10. 「ユーザー属性」フィールドで、属性名を入力するか、「選択」をクリックして属性名のリストから属性名を選択します。
  11. 「バインド・タイプ・フォーマット」をクリックします。
  12. 「バインド・タイプ値」リストから、目的の値を選択します。
  13. 「OK」をクリックします。

ノート:

個々のバインド・ルールを編集することもできます。バインド・ルールを変更するには、「権限」表で必要なバインド・ルールを選択してから「編集」をクリックする必要があります。

28.5 アクセス制御の管理

アクセス制御ポイントに関連するタスクについては、これらのトピックを参照してください。

28.5.1 個人エントリへの書込みアクセスの許可

デフォルトのグローバルACIは、ユーザー自身のエントリの属性の限られたサブセットに対する書込みアクセスを許可します。

これには次の属性が含まれます:

  • audio

  • authPassword

  • description

  • displayName

  • givenName

  • homePhone

  • homePostalAddress

  • initials

  • jpegPhoto

  • labeledURI

  • mobile

  • pager

  • postalAddress

  • postalCode

  • preferredLanguage

  • telephoneNumber

  • userPassword

次の各トピックでは、ユーザーが独自に値を入力できるその他の属性への書込みアクセスをユーザーに許可する手順を示します。

28.5.1.1 DNSに基づく書込みアクセスの許可

次のサンプル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エントリに追加されることを前提としています。

28.5.1.2 認証方式に基づく書込みアクセスの許可

次の例は、ディレクトリへの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エントリに追加されることを前提としています。

28.5.2 グループに対する接尾辞への完全アクセスの許可

ほとんどのディレクトリには、特定の業務機能を識別するためのグループがあります。これらのグループにディレクトリの全体または一部へのアクセス権を付与できます。グループにアクセス権を適用することで、メンバーに個別にアクセス権を設定せずにすみます。かわりにグループにユーザーを追加することで、そのユーザーにアクセス権を付与します。

次のサンプル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エントリに追加されることを前提としています。

28.5.3 グループ・エントリを追加および削除する権限の付与

一部の組織では、それによる従業員の効率の向上やコーポレート・ダイナミクスへの貢献が見込まれる場合に、従業員にツリー内のエントリの作成を許可します。

次のそれぞれの例では、example.comの社会委員会が様々なクラブ(テニス、水泳、スキーなど)に編成されていることを前提としています。

28.5.3.1 "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を指定する必要があります。

28.5.3.2 "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エントリに追加されることを前提としています。

28.5.4 ユーザーに対するグループへの自身の追加または削除の許可

多くのディレクトリで、グループに対するユーザー自身の追加または削除をユーザーに許可する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エントリに追加されることを前提としています。

28.5.5 グループへの条件付きアクセスの許可

通常、グループにディレクトリへのアクセス権を付与する際には、正しい権限を持つユーザーを偽装しようとする侵入者からこれらの権限を確実に保護する必要があります。そのため、グループまたはロールに重要なアクセスを許可するアクセス制御ルールには、たいていいくつかの条件が関連付けられます。

次のサンプル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エントリに追加されることを前提としています。

28.5.6 アクセスの拒否

ディレクトリ内にビジネスにとって重要な情報がある場合は、そのディレクトリへのアクセスを特に拒否する必要が生じることがあります。次のサンプル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";)

28.5.7 カンマを含むDNの権限の定義

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.";)

28.6 プロキシ認可ACIについて

プロキシ認可方式は特殊な形の認証で、自分自身の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のターゲットと一致する必要があります。クライアントは自身としてバインドしますが、プロキシ・エントリの権限を付与されます。クライアントには、プロキシ・エントリのパスワードは不要です。

詳細は、「プロキシ設定された認可制御を使用した検索」を参照してください。

28.7 実効権限の表示

ディレクトリのエントリのアクセス制御ポリシーを管理するときには、定義したACIのセキュリティへの影響を把握しておくと役に立ちます。ディレクトリ・サーバーで、既存のACIを評価して、それらのACIによって特定のエントリ上の特定のユーザーに付与された実効権限に関するレポートを生成できます。

次の各トピックでは、実効権限について詳しく説明しています。

28.7.1 実効権限取得制御について

ディレクトリ・サーバーは、検索操作に含めることができる実効権限取得制御に応答します。この制御に対するレスポンスは、検索結果のエントリおよび属性に関する実効権限情報を返すことです。この追加情報としては、各エントリとその中の各属性に対する読取り権限および書込み権限などがあります。

検索や任意のDNに使用されるバインドDNについて権限をリクエストすることで、管理者がディレクトリ・ユーザーの権限をテストできます。

実効権限の機能は、LDAP制御に依存します。プロキシ・サーバーを通過するときに実効権限を表示するには、プロキシ・チェーン・ポリシー内でこの制御を有効にする必要があります。また、リモート・サーバーとのバインドに使用されるプロキシ・アイデンティティにも、実効権限属性へのアクセスを許可する必要があります。

28.7.2 実効権限取得制御の使用方法

実効権限取得制御の動作は、インターネット・ドラフトの実効権限取得制御とは異なります。方法の違いについては、このトピックを参照してください。

インターネット・ドラフトの実効権限取得制御の詳細は、http://tools.ietf.org/html/draft-ietf-ldapext-acl-model-08を参照してください。

  • 検索結果とともに返されるレスポンス制御はありません。かわりに、権限情報が結果エントリに追加されます。また、権限情報の書式はドラフトと完全に異なっています(この書式については後述します)。

  • リクエスト制御はauthzidのみを取ります。

ldapsearchコマンドで実効権限取得制御を指定するには、2つの方法があります:

  1. -J "1.3.6.1.4.1.42.2.27.9.5.2"オプションまたはより簡単な-J effectiverightsを使用します。実効権限取得制御のauthzidの値としてNULL値を指定すると、authzidとしてバインド・ユーザーが使用され、現在のldapsearch操作で返される属性およびエントリに対する権限が取得されます。
  2. より単純で優先される方法は、-eオプションありまたはなしで-gオプションを使用することです:

    • -g "dn: DN"-- 指定されたDNにバインドしているユーザーの実効権限が検索結果に示されます。管理者は、このオプションを使用して他のユーザーの実効権限をチェックできます。オプション-g "dn:"を指定すると、匿名認証に対する実効権限が表示されます。

    • -e attributeName1 -e attributeName2 -- 指定された属性に対する実効権限も検索結果に含められます。このオプションは、エントリに関する検索結果に通常は含まれない属性を指定するために使用できます。たとえば、このオプションを使用すると、エントリ内に現在存在しない属性を追加する権限をユーザーが持っているかどうかを調べられます。

      ノート:

      -eオプションは-gオプションとともに使用する必要があります。また、-Jオプションとともには使用できません。

      -gオプションを使用する場合は、実効権限取得制御のOIDとともに-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

28.7.3 実効権限の結果の理解

実効権限へのリクエストがあるたびに、指定したオプションに応じて結果が生成されます。

28.7.3.1 実効権限情報

実効権限情報は、次のサブタイプに従って示されます:

表28-1 実効権限情報のサブタイプ

サブタイプ 説明

clRights;entrylevel

エントリ・レベルの権限情報を示します

aclRights;attributelevel

属性レベルの権限情報を示します

aclRightsInfo;entrylevel

エントリ・レベルのログ情報を示します

aclRightsInfo;attributelevel

属性レベルのログ情報を示します

aclRights文字列の書式は次のとおりです:

aclRights;entryLevel: 権限:値(権限:値)*

および

aclRights;attributeLevel: 権限:値(権限:値)*

エントリ・レベルの権限としては、add、delete、read、writeおよびproxyがあります。それぞれの権限が取り得る値は、0(権限は付与されない)と1(権限が付与される)です。

エントリ・レベルの権限 説明

addおよびdelete

ユーザーがエントリ全体を追加および削除する権限。

read

ユーザーがエントリ内の属性の読取りおよび検索を行う権限。

write

ユーザーがエントリ内の属性値の追加、削除および置換を行う権限。

proxy

ユーザーがエントリの権限でディレクトリにアクセスする権限。

ノート:

ACIでのこれらの権限の割当ての詳細は、「アクセス制御命令の構文の理解」を参照してください。

属性レベルの権限としては、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-2を参照してください。

aclRightsInfo文字列の書式は次のとおりです:

aclRightsInfo;logs;entryLevel;permission: acl_summary(main):permission-string

および

aclRightsInfo;logs;attributeLevel;permission;attribute: acl_summary(main):permission-string

エントリ・レベルと属性レベルの権限については、前の項で説明しています。

permission-stringには、エントリ・レベルと属性レベルの実効権限に関する詳細情報が含まれています。

28.7.3.2 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-2 実効権限の相互依存性

write selfwrite_add selfwrite_delete 実効権限の説明

0

0

0

この属性のどの値も、追加も削除もできません。

0

0

1

authorization dnの値のみ削除できます。

0

1

0

authorization dnの値のみ追加できます。

0

1

1

authorization dnの値のみ追加または削除できます。

1

0

0

authorization dn以外のすべての値を追加または削除できます。

1

0

1

authorization dnを含めたすべての値を削除でき、authorization dn以外のすべての値を追加できます。

1

1

0

authorization dnを含めたすべての値を追加でき、authorization dn以外のすべての値を削除できます。

1

1

1

この属性のすべての値を追加または削除できます。

?

0

0

authorization dn値の追加または削除はできませんが、その他の値の追加または削除はできる場合があります。write権限に関する詳細は、ログ情報を参照してください。

?

0

1

authorization dnの値を削除できますが、追加はできません。さらに、それ以外の値を追加または削除できる場合があります。write権限に関する詳細は、ログ情報を参照してください。

?

1

0

authorization dnの値を追加できますが、削除はできません。さらに、それ以外の値を追加または削除できる場合があります。write権限に関する詳細は、ログ情報を参照してください。

1

?

1

authorization dnの値を追加および削除できます。さらに、それ以外の値を変更、追加または削除できる場合があります。write権限に関する詳細は、ログ情報を参照してください。

28.7.3.3 実効権限ログ情報

実効権限のログ情報は、アクセス制御の問題の理解とデバッグに役立ちます。ログ情報には、acl_summaryと呼ばれるアクセス制御サマリー文が含まれています。このサマリーには、アクセス制御がなぜ許可または拒否されたかが示されます。アクセス制御サマリー文には、次の情報が含まれています:

  • アクセスが許可されたか、それとも拒否されたか

  • 付与された権限

  • 権限のターゲット・エントリ

  • ターゲット属性の名前

  • リクエストされている権限のサブジェクト

  • リクエストの発行元がプロキシかどうか(プロキシの場合はプロキシ認証DN)

  • アクセスを許可または拒否する理由(次の表で説明しているように、デバッグが目的の場合に重要です)

次の表に、実効権限のログ情報の理由とその説明を示します。

表28-3 実効権限ログ情報の理由とその説明

ログ情報の理由 説明

no reason available

アクセスがなぜ許可または拒否されたかを説明するための理由がありません。

no allow acis

allow ACIが存在しないため、アクセスが拒否されます。

result cached deny

キャッシュされた情報を使用して、アクセス拒否が決定されました。

result cached allow

キャッシュされた情報を使用して、アクセス許可が決定されました。

evaluated allow

ACIが評価されて、アクセス許可が決定されました。ACIの名前がログ情報に含められます。

evaluated deny

ACIが評価されて、アクセス拒否が決定されました。ACIの名前がログ情報に含められます。

no acis matched the resource

リソースまたはターゲットに一致するACIがないため、アクセスが拒否されます。

no acis matched the subject

アクセス制御をリクエストしているサブジェクトに一致するACIがないため、アクセスが拒否されます。

allow anyone aci matched anon user

userdn = "ldap:///anyone"サブジェクトを持つACIが、匿名ユーザーに対してアクセスを許可しました。

no matching anyone aci for anon user

userdn= "ldap:///anyone"サブジェクトを持つACIが見つからなかったため、匿名ユーザーのアクセスが拒否されました。

user root

ユーザーがルートDNであるため、アクセスを許可されます。

ノート:

仮想属性については書込み権限は付与されず、関連するログ評価情報も提供されません。仮想属性は更新できないためです。

28.7.4 実効権限取得制御へのアクセス制限

実効権限を表示する操作はそれ自体が、保護と適切な制限を必要とするディレクトリ操作です。デフォルトの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構文の詳細は、「ターゲットの定義」を参照してください。

たとえば次の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";)