| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
この章は、ディレクトリ・サーバーのアクセス制御モデルに関する参照情報を含みます。ディレクトリ・サーバーでのアクセス制御の構成の詳細は、第25章「データへのアクセス制御」を参照してください。
この章では、次のトピックを取り扱います:
この項では、ディレクトリ・サーバーで提供されているアクセス制御メカニズムの原則について説明します。
第25.1項「dsconfigを使用したグローバルACIの管理」も参照してください。
ディレクトリ·サーバーがリクエストを受信すると、バインド操作でユーザーが提供する認証情報、およびサーバーで定義されたアクセス制御命令(ACI)を使用して、ディレクトリ情報へのアクセスが許可または拒否されます。サーバーは、読取り、書込み、検索、比較などの権限を許可または拒否できます。ユーザーに付与される権限のレベルは、ユーザーが入力する認証情報によって異なります。
アクセス制御を利用すると、ディレクトリ全体、ディレクトリのサブツリー、ディレクトリ内の特定のエントリ(構成タスクを定義するエントリを含む)、エントリ属性の特定のセット、あるいは特定のエントリ属性値へのアクセスを制御できます。特定のユーザー、特定のグループまたはロールに属するすべてのユーザー、またはそのディレクトリのすべてのユーザーに対して権限を設定できます。さらに、(そのIPアドレスまたはDNS名で識別される)特定のクライアントのアクセス権を定義できます。
アクセス制御の方法はエントリの属性としてディレクトリに保存されます。aci属性は操作属性で、エントリのオブジェクト・クラス用に定義されているかどうかにかかわらず、ディレクトリ内のすべてのエントリに使用できます。この属性は、ディレクトリ・サーバーがクライアントからLDAPリクエストを受け取るときに、どの権限が付与、または拒否されるかを評価するためにディレクトリ・サーバーに使用されます。明確にリクエストされている場合のみ、aci属性はldapsearch操作で戻されます。
ACI文は3つの主要部分を含みます:
権限が適用されるエントリまたは属性を決定します。
どの操作が許可または拒否されるかを定義します。
バインドDNに基づいて、ACIの対象を決定します。
ACIの権限とバインド・ルールの部分は、ペアで設定されます。これは、アクセス制御ルール(ACR)とも呼ばれています。ターゲットにアクセスするために指定される権限は、付随するルールがtrueと評価されるかどうかによって付与されるか拒否されるかが決定されます。詳細は、第9.2項「ACI構文」を参照してください。
ACIを含むエントリが子エントリを持たない場合は、ACIはそのエントリにのみ適用されます。エントリが子エントリを持つ場合は、ACIはそのエントリ自身およびその下位のすべてのエントリに適用されます。したがって、ディレクトリ・サーバーがエントリへのアクセス権を評価するときは、リクエストされたエントリとそのルート接尾辞のベースとの間のすべてのエントリのACIを検証します。
aci属性は複数値です。つまり、同じエントリまたはサブツリーに対して、複数のACIを定義できます。
直接そのエントリではなく、その下のサブツリー内の一部またはすべてのエントリに適用されるACIを作成することができます。この利点は、ツリーで下位に位置する可能性の高いエントリに効果的に適用する一般的なACIを、ディレクトリ・ツリーの高いレベルに設定できることです。たとえば、organizationalUnitエントリまたはlocalityエントリのレベルでは、inetorgpersonオブジェクト・クラスを含むエントリをターゲットとするACIを作成できます。
この機能を使用すると、高いレベルの分岐点で一般的なルールを設定することでディレクトリ・ツリー内のACIの数を最小にできます。より具体的なルールの範囲を制限するには、できるだけリーフ・エントリに近い位置にそのルールを設定します。
|
注意: ルートのDSEエントリ(DN |
アクセス制御ハンドラのプロパティを変更するdsconfigを使用することによって、一元的にアクセス制御を構成することができます。
ルールではtarget式が指定されないので、次のデフォルトのグローバルACIは、ディレクトリ・サーバーに定義されているすべての接尾辞に適用されます:
Property : Value(s) -----------:------------------------------------------------------------------- global-aci : "(targetattr!="userPassword||authPassword")(version 3.0; acl : "Anonymous read access"; allow (read,search,compare) : userdn="ldap:///anyone";)", (targetattr="*")(version 3.0; acl : "Self entry modification"; allow (write) userdn="ldap:///self";), : "(targetattr="createTimestamp||creatorsName||modifiersName||modify : Timestamp||entryDN||entryUUID||subschemaSubentry")(version 3.0; : acl "User-Visible Operational Attributes"; allow : (read,search,compare) userdn="ldap:///anyone";)",
詳細は、第25.1項「dsconfigを使用したグローバルACIの管理」を参照してください。
特定のエントリへのアクセス権を評価するためには、サーバーはエントリ自身およびエントリのルート接尾辞のベースに戻る親エントリに存在するACIのリストをコンパイルします。評価中、サーバーはこの順番でACIを処理します。ACIは、エントリとそのルート接尾辞のベースの間のすべての接尾辞およびサブ接尾辞内で評価されます(他のサーバー上の連鎖接尾辞間では評価されません)。
|
注意: アクセス制御は |
デフォルトでは、ACIがエントリに適用されない場合、アクセスはbypass-acl権限を持つユーザー以外のすべてのユーザーに拒否されます。ユーザーがディレクトリ内のエントリにアクセスするためには、ACIによってアクセス権が明示的に付与される必要があります。デフォルトACIは匿名の読取りアクセスを定義し、セキュリティのために必要な属性を除いて、ユーザーが自分のエントリを変更することができます。詳細は、第25.1.1項「デフォルトのグローバルACI」を参照してください。
ディレクトリ·サーバーは、最初にターゲット・エントリに最も近いACIを処理しますが、エントリに適用されるすべてのACIの影響は累積されます。他のACIが拒否しないかぎり、任意のACIによって付与されたアクセス権が許可されます。アクセスを拒否するACIは、リストのどこにそれが現れても、同じリソースにアクセスを許可するACIよりも優先されます。
たとえば、ディレクトリのルート・レベルで書込み権限を拒否すると、ユーザーに特定の権限を与えても、どのユーザーもディレクトリに書き込めなくなります。特定のユーザーにディレクトリへの書込み権限を付与するには、そのユーザーを除外するように書込み権限の元の拒否の有効範囲を制限する必要があります。
ディレクトリ・サービスにアクセス制御ポリシーを作成するときは、次の制限事項に注意してください:
ディレクトリ・ツリーが複数のディレクトリ・サーバー上に分散している場合、いくつかの制限はアクセス制御文で使用できるキーワードに適用されます。グループ・エントリ(groupdnキーワード)に依存するACIは、グループ・エントリと同じディレクトリ・サーバー上に配置する必要があります。そのグループが動的である場合は、そのグループのすべてのメンバーはディレクトリ・サーバー上にエントリを持つ必要があります。グループが静的である場合は、メンバーのエントリはリモート・ディレクトリ・サーバー上に配置することができます。ただし、ターゲット·エントリに格納される値とバインド・ユーザーのエントリに格納される値のマッチングを行うことができます(たとえば、userattrキーワードを使用)。ACIを保持するディレクトリ・サーバーにバインド・ユーザーがエントリを持っていなくても、アクセスは通常どおりに評価されます。
アクセス制御ルールは、常にローカル・ディレクトリ・サーバー上で評価されます。ACIキーワードで使用されるLDAP URLでは、ディレクトリ・サーバーのホスト名またはポート番号を指定することはできまん。指定する場合は、LDAP URLはまったく考慮されません。
ACIはエントリの属性として格納されます。したがって、ACIを含んでいるエントリがレプリケートされた接尾辞の一部である場合、ACIは他の属性のようにレプリケートされます。
ACIは多数の可能性のバリエーションを持つ複雑な構造です。次の項では、ACIの構文の詳細を説明します。
aci属性には、次の構文があります:
aci: (target)(version 3.0;acl "name";permissionBindRules;)
ここで:
targetは、アクセス制御するエントリ、属性、またはエントリと属性のセットを指定します。targetには、識別名、1つ以上の属性、または単一のLDAPフィルタを指定できます。targetはオプションです。targetが指定されていない場合は、ACIは定義されているエントリとそのすべての子のエントリ全体に適用されます。
version 3.0はACIバージョンを識別する必須の文字列です。
nameはACIの名前です。nameはACIを識別する任意の文字列です。ACI名は必須であり、ACIの影響を示す必要があります。名前に制約はありませんが、ACIには一意の名前を使用することをお薦めします。一意の名前を使用すると、実効権限取得制御によって、有効になっているACIを判別することができます。
permissionは、許可または拒否する権限(たとえば読取り権限や検索権限)を明示します。
bindRulesは、ユーザーがアクセス権を付与されるために提供する必要がある資格証明およびバインド・パラメータを指定します。バインド・ルールは、ユーザー・メンバーシップ、グループ・メンバーシップ、またはクライアントの接続プロパティに基づいて指定することもできます。
複数のターゲットおよび権限とバインド・ルールのペアを指定することができます。これにより、ターゲットとなるエントリおよび属性の両方を詳細に指定し、ここに示すように、特定のターゲットに対して複数のアクセス制御を効率的に設定できます:
aci: (target)...(target)(version 3.0;acl "name"; permissionBindRule; permissionBindRule; ...; permissionBindRule;)
次の例は、完全なLDIF ACIを示しています:
aci: (target="ldap:///uid=bjensen,dc=example,dc=com") (targetattr="*")(version 3.0; acl "example"; allow (write) userdn="ldap:///self";)
この例では、ACIは、ユーザーbjensenは、自身のディレクトリ・エントリ内のすべての属性を変更する権限を持つことを指定しています。
ターゲットは、ACIの適用対象を識別します。クライアントがエントリ内の属性の操作をリクエストする場合は、ディレクトリ・サーバーはACIが操作を許可または拒否するために評価される必要があるかを確認するためにターゲットを評価します。ターゲットが指定されていない場合は、ACIはaci属性を含むエントリのすべての属性、およびその下位のエントリに適用されます。
次の項では、ターゲットの定義方法を説明します:
ターゲットの一般的な構文は、次のいずれかです:
(keyword = "expression")
(keyword != "expression")
ここで:
keywordはターゲットのタイプを示します。ターゲットの次のタイプは表9-1のキーワードで定義されます。
ディレクトリ・エントリまたはそのサブツリー
エントリの属性
LDAPフィルタとマッチングするエントリまたは属性のセット
LDAPフィルタとマッチングする属性値または値の組合せ
ACIの有効範囲
LDAP制御
拡張操作
等号(=)は、ターゲットが式で指定されたオブジェクトであることを示し、非等号(!=)は、ターゲットが式で指定されていない任意のオブジェクトであることを示します。
|
注意: 非等号演算子は |
expressionは、キーワードに依存し、ターゲットを識別します。構文上、expressionの前後には引用符("")が必要です。ただし、現在の実装では、targetattr=*のような表現も受け入れています。将来のバージョンでは、構文チェックがより厳密になる可能性があるので、常に引用符を使用する必要があります。
次の表は、各キーワードとそれに関連する式を示します。
表9-1 LDIFターゲット・キーワード
| キーワード | 有効な式 | ワイルドカード使用の可否 |
|---|---|---|
|
|
|
使用可能 |
|
|
属性 |
使用可能 |
|
|
LDAPfilter |
使用可能 |
|
|
LDAPoperation |
使用可能 |
|
|
|
使用不可 |
|
|
oid |
使用不可 |
|
|
oid |
使用不可 |
ターゲット・キーワードおよびLDAP URL内部のDNを使用すると、特定のディレクトリ・エントリおよびその下位の任意のエントリをターゲット指定することができます。ターゲットDNは、ACIが定義されているエントリ、またはエントリの下のサブツリーに配置される必要があります。ターゲット式の構文は次のとおりです:
(target = "ldap:///distinguishedName") (target != "ldap:///distinguishedName")
識別名は、ACIが定義されているエントリ、またはエントリの下のサブツリーに配置される必要があります。たとえば、ou=People,dc=example,dc=com上のACIでは、次のようなターゲットを使用できます:
(target = "ldap:///uid=bjensen,ou=People,dc=example,dc=com")
キーワードtargetはオプションです。それが存在しない場合は、ACIのデフォルト・ターゲットはACIが格納されているエントリです。
|
注意: エントリのDNは、文字列表現の識別名とする必要があります(RFC 4514 ( (target="ldap:///uid=cfuentes,o=Example Bolivia\, S.A.") |
LDAP URLに一致する任意の数のエントリをターゲットにするために、DNでワイルドカードを使用することもできます。ワイルドカードの正しい使用例を次に示します:
(target="ldap:///uid=*,dc=example,dc=com")は、エントリのRDNにuid属性を持つexample.com分岐エントリのすべての直近の子と一致します。次に例を示します。
uid=tmorris,dc=example,dc=com uid=yyorgens,dc=example,dc=com uid=bjensen,dc=example,dc=com
(target="ldap:///uid=*,**,dc=example,dc=com")は、エントリのRDNにuid属性を持つexample.com分岐エントリよりも複数レベル下のすべてのエントリと一致します。次に例を示します。
uid=tmorris,ou=sales,dc=example,dc=com uid=yyorgens,ou=marketing,dc=example,dc=com uid=bjensen,ou=eng,ou=east,dc=example,dc=com
(target="ldap:///uid=*Anderson,ou=People,dc=example,dc=com")は、uidがAndersonで終了するou=People分岐エントリのすぐ下のすべてのエントリと一致します。
(target="ldap:///*=*Anderson,ou=People,dc=example,dc=com")は、ネーミング属性に関係なく、AndersonでRDNが終了するou=People分岐のすぐ下のすべてのエントリと一致します。
uid=*,ou=*,dc=example,dc=comのように複数のワイルドカードを使用できます。この例は、指定された位置で識別名がuidおよびou属性を含むexample.comツリーのすべてのエントリと一致します。
ディレクトリ・エントリをターゲットにすることに加えて、ターゲットのエントリに発生する1つ以上の属性をターゲットにすることができます。この機能は、エントリに関する部分的な情報へのアクセスを拒否または許可したい場合に便利です。たとえば、特定のエントリの共通名、名字および電話番号の属性にのみアクセスを許可できます。同様に、個人情報などの機密情報へのアクセスを拒否できます。
targetattrルールがない場合は、デフォルトではどの属性にもアクセスすることはできません。すべての属性にアクセスするには、ルールはtargetattr="*"である必要があります。
ターゲット属性は、ターゲット・エントリまたはそのサブツリーに存在する必要はありませんが、存在すればACIが適用されます。ターゲットにする属性は、このスキーマで定義する必要はありません。スキーマ・チェックを行わないことにより、データとそのスキーマをインポートする前にアクセス制御ポリシーを実装できます。
属性をターゲット指定するには、targetattrキーワードを使用し、属性名を入力します。targetattrキーワードでは、次の構文を使用します:
(targetattr = "attribute") (targetattr != "attribute")
次の構文でtargetattrキーワードを使用することで、複数の属性をターゲットにすることができます:
(targetattr = "attribute1 || attribute2 ... || attributeN") (targetattr != "attribute1 || attribute2 ... || attributeN")
たとえば、エントリの共通名、名字およびUID属性をターゲットにする場合は、次のように指定します:
(targetattr = "cn || sn || uid")
carlicenseを除く、エントリのユーザー属性のすべてをターゲットにするには、次のターゲットを使用します:
(targetattr != "carlicense")
ターゲット属性には、指定された属性のすべてのサブタイプが含まれます。たとえば、(targetattr = "locality")はlocality;lang-frもターゲットになります。たとえば、(targetattr = "locality;lang-fr-ca")のように、具体的にサブタイプをターゲットにすることもできます。
targetattrルール(たとえばtargetattr="*")でスタンドアロン文字としてワイルドカードを使用できますが、特定の目的を果たさず、パフォーマンスに悪影響を与える可能性があるため、この使用はお薦めしません。
デフォルトでは、targetattrキーワードを含むACIにターゲット指定されたエントリは、ACIが配置されたエントリです。つまり、ACI aci: (targetattr = "uid")(accessControlRules;)をou=Marketing, dc=example,dc=comエントリに適用する場合は、ACIはMarketingサブツリー全体に適用されます。ただし、次の例のように、ターゲット・キーワードを使用して明示的にターゲットを指定することもできます:
aci: (target="ldap:///uid=*,ou=Marketing,dc=example,dc=com")
(targetattr="uid") (accessControlRules;)
ターゲットおよびtargetattrキーワードを指定する順番は重要ではありません。
一定基準に一致するエントリのセットをターゲットにするために、LDAPフィルタを使用することができます。このためには、LDAPフィルタとともにtargetfilterキーワードを使用します。ACIは、ターゲットDNのレベルおよびその下位のサブツリーでフィルタに一致するすべてのエントリに適用されます。
targetfilterキーワードは次の構文を使用します:
(targetfilter = "LDAPfilter")
ここで、LDAPfilterは標準のLDAP検索フィルタです。フィルタの構文の詳細は、付録E「検索フィルタ」を参照してください。
たとえば、従業員を示すすべてのエントリには、正社員または契約社員のステータスと、労働時間数を(フルタイムに対する割合として)示す属性があると仮定します。契約社員またはパート社員を示すすべてのエントリをターゲットにするには、次のフィルタを使用できます:
(targetfilter = "(|(status=contractor)(fulltime<=79))")
ACIでは、Netscapeが拡張したフィルタ構文はサポートされません。たとえば、次のターゲット・フィルタは有効ではありません:
(targetfilter = "(locality:fr:=<= Quebec)")
ターゲット・フィルタはACIのターゲットとしてエントリ全体を選択します。ターゲット・エントリの属性のサブセットに適用されるACIを作成するために、targetfilterおよびtargetattrキーワードを組み合せることができます。
次に示すLDIFの例では、Engineering Adminグループのメンバーは、Engineeringのビジネス・カテゴリ内のすべてのエントリのdepartmentNumberおよびmanager属性を変更できます。この例では、LDAPフィルタを使用して、businessCategory属性がEngineeringに設定されたすべてのエントリを選択します:
dn: dc=example,dc=com objectClass: top objectClass: organization aci: (targetattr="departmentNumber || manager") (targetfilter="(businessCategory=Engineering)") (version 3.0; acl "eng-admins-write"; allow (write) groupdn ="ldap:///cn=Engineering Admins, dc=example,dc=com";)
ディレクトリ内に分散したエントリおよび属性をターゲットにする場合、LDAPフィルタの使用は便利ですが、フィルタでは、アクセス管理対象のオブジェクトが直接指定されないので、思わぬ結果を招くことがあります。フィルタ処理済のACIでターゲット指定されたエントリのセットは、属性の追加や削除によって変化することがあります。したがって、ACIでLDAPフィルタを使用する場合は、ldapsearch操作で同じフィルタを使用して適切なエントリと属性がターゲット指定されていることを確認する必要があります。
アクセス制御を使用すると、特定の属性値をターゲットに指定できます。つまり、属性値がACIで定義された条件を満たす場合、属性に対する権限を付与または拒否できます。属性の値に基づいてアセスを許可または拒否するACIは、値ベースACIと呼ばれています。
たとえば、組織内のすべてのユーザーに、ユーザー自身のエントリ内のroomNumber属性を変更する権限を付与することができます。ただし、ユーザーが予約済の部屋番号(12から始まるすべての番号)を指定できないようにすることも必要です。LDAPフィルタは、属性値の条件が満たされていることを確認するために使用されます。
値ベースACIを作成するには、次の構文でtargattrfiltersキーワードを使用する必要があります:
(targattrfilters="Op=attr1:F1[(&& attr2:F2)*][;Op=attr:F[(&& attr:F)*]")
ここで:
Opは、addまたはdelete操作のいずれかです:
addは属性を作成する操作を示します。
deleteは属性を削除する操作を示します。
attrはターゲット属性を示します。
Fは、関連付けられた属性のみに適用する「検索フィルタ」(付録E)を示します。
エントリを作成するとき、フィルタが新しいエントリの属性に適用される場合は、その属性のすべての値はフィルタを満たす必要があります。エントリを削除するとき、フィルタがエントリの属性に適用される場合は、その属性のすべての値もフィルタを満たす必要があります。
エントリを変更するとき、操作で属性を追加する場合は、その属性に適用される追加フィルタを満たす必要があります。操作で属性を削除する場合は、その属性に適用される削除フィルタを満たす必要があります。エントリ内にすでに存在する属性の各値が置き換えられる場合は、追加および削除フィルタの両方を満たす必要があります。
次の例の属性フィルタは、12の接頭辞を持つ予約済の部屋番号を除いて、ユーザー自身のエントリに任意のroomNumber属性を追加することをユーザーに許可します。またこれにより、ユーザーは123という接頭辞を持つ電話番号を追加できます。
(targattrfilters="add=roomNumber:(!(roomNumber=12*)) && telephoneNumber:(telephoneNumber=123*)")
単一のエントリをターゲットとする明示的な方法はありません。ただし、次の2つのうちのいずれかの方法で可能です:
バインド・リクエストでのユーザー入力が、ターゲット・エントリ内に格納された属性値に一致するバインド・ルールを作成する
targetfilterキーワードを使用する
targetfilterキーワードを使用すると、目的のエントリにのみ表示される属性値を指定することができます。たとえば、ディレクトリ・サーバーをインストールする間に次のACIが作成されます:
aci: (targetattr="*")(targetfilter=(o=example)) (version 3.0; acl "Default anonymous access"; allow (read, search) userdn="ldap:///anyone";)
属性oが値exampleを持つ唯一のエントリのため、このACIはo=exampleエントリにのみ適用されます。
これらのメソッドに関連付するリスクは、ディレクトリ・ツリーは、将来変更される可能性があるということと、このACIを変更することを忘れないようにしなければならないことです。
通常、ACIの範囲はサブツリーです。次の構文でtargetscopeキーワードを使用することでACIの有効範囲を制限できます:
(targetscope="expression")
ここで、expressionは次のいずれかです:
baseACIは、ターゲット・リソースにのみ適用されます。
onelevelACIは、ターゲット・リソースの第1世代の子に適用されます。
subtreeACIは、ターゲット・リソースとその下にあるサブツリーに適用されます。
subordinateACIは、ターゲット・リソースの下にあるサブツリーにのみ適用されます。
targetscopeが指定されていない場合、デフォルト値はsubtreeです。次の例では、ACIターゲット一致は、識別名uid=bjensen,ou=People,dc=example,dc=comのエントリ、およびその1レベル下の任意の子のエントリのみに制限されます:
(target = "ldap:///uid=bjensen,ou=People,dc=example,dc=com")(targetscope="onelevel")
|
注意: 非等号演算子は |
LDAP制御をターゲットに指定するには、targetcontrolキーワードを使用し、制御(付録E「オブジェクト識別子」)を入力します。targetcontrolキーワードは次の構文を使用します:
(targetcontrol="oid")
(targetcontrol!="oid")
次の構文でtargetcontrolキーワードを使用することで、複数のLDAP制御をターゲットにすることができます:
(targetcontrol="oid1 || oid2... || oidN")
(targetcontrol!="oid1 || oid2... || oidN")
たとえば、「実効権限取得制御」(付録E)および「プロキシ設定された認可制御」(付録E)の両方をターゲットに指定するには、次のtargetcontrol式を使用します:
(targetcontrol = "1.3.6.1.4.1.42.2.27.9.5.2 || 2.16.840.1.113730.3.4.18")
|
注意: 実効権限取得制御は1.3.6.1.4.1.42.2.27.9.5.2のOID値を持ちます。プロキシ認可V2制御は2.16.840.1.113730.3.4.18のOID値を持ちます。 |
拡張操作をターゲットに指定するには、extopキーワードを使用し、操作(付録E「オブジェクト識別子」)を指定します。extopキーワードは次の構文を使用します:
(extop= "oid")
(extop!= "oid")
次の構文でextopキーワードを使用することにより、複数の拡張操作をターゲットにすることができます:
(extop = "oid1 || oid2... || oidN")
(extop!= "oid1 || oid2... || oidN")
たとえば、「StartTLS拡張操作」(付録E)および「パスワード変更拡張操作」(付録E)の両方をターゲットにするには、次のextop式を使用します:
(extop = "1.3.6.1.4.1.1466.20037 || 1.3.6.1.4.1.4203.1.11.1.")
|
注意: StartTLS拡張操作ターゲットで |
権限では、許可または拒否するアクセスのタイプを指定します。ディレクトリ内で特定の操作を実行する権限を許可または拒否することができます。割り当てられる様々な操作は、権限として知られています。
権限の設定には2つの手順があります:
アクセスの許可または拒否
権限の割当て
次の項では、権限の定義方法を説明します:
allowまたはdenyキーワードを使用して、アクセス権を明示的に許可または拒否できます。
権限は、ユーザーがディレクトリ・データで実行できる特定の操作の詳細を説明します。すべての権限を許可または拒否するか、または次に示す権限の1つ以上を割り当てることができます:
ユーザーがディレクトリ・エントリおよびACIに指定されたエントリの属性を読み取ることができるかを示します。この権限は、検索操作のみに適用されます。(読取り権限を次の検索権限の説明と比較してください。)
ユーザーが属性を追加、変更または削除することでエントリを変更できるかを示します。この権限は、変更およびmodRDN操作に適用されます。
ユーザーがエントリを作成できるかを示します。この権限は、追加操作のみに適用されます。
ユーザーがエントリを削除できるかを示します。この権限は、削除操作のみに適用されます。
ACIに指定されたターゲット上でユーザーが検索できるかを示します。この権限は、検索操作のみに適用されます。検索権限は、一度確認され、検索が許可または拒否された後は再び確認されません。検索が許可された場合、読取り権限は検索の結果として返される各エントリおよび各エントリの各属性に適用されます。
ユーザーは、ユーザーが指定するデータとディレクトリに格納されたデータを比較できるかを示します。比較権限を使用すると、ディレクトリが問合せの応答として成功または失敗のメッセージを返しますが、ユーザーはエントリまたは属性の値を参照できません。この権限は、比較操作のみに適用されます。
ユーザーがターゲット・エントリの属性に自分自身のDNを追加または削除できるかを示します。この属性の構文は、識別名である必要があります。この権限は、グループ管理でのみ使用されます。自己書込みは、プロキシ認可で機能します。これは、(バインドされたユーザーのDNではなく)グループ・エントリからプロキシDNを追加または削除する権限を付与します。
指定されたDNが別のエントリの権限でターゲットにアクセスできるかを示します。ディレクトリ・マネージャDNを除くディレクトリ内の任意のユーザーのDNを使用して、プロキシ・アクセス権を付与できます。なお、ディレクトリ・マネージャにはプロキシ権限を付与できません。第25.6項「プロキシ認可のACI」に例があります。
変更DN操作で使用されます。このアクセス権限は、エントリを特定のDNにインポートできるかどうかを示します。
変更DN操作で使用されます。このアクセス権限は、エントリを特定のDNからエクスポートできるかどうかを示します。
指定されたDNが、ターゲット・エントリに対して次の権限を持つことを示します: 読取り、書込み、検索、削除、比較、自己書込み。すべてのアクセス権限は、ターゲット・エントリに次の権限を与えません: プロキシ、インポートおよびエクスポート。
rightは、互いに独立して付与されます。つまり、たとえば、削除権限が明確に付与されていない場合は、追加権限を付与されるユーザーはエントリを作成することができますが、それを削除することはできません。したがって、ディレクトリに対するアクセス制御ポリシーを計画している場合、ユーザーに対して合理的に権利を付与することを確認することが必要です。たとえば、読取りおよび検索権限を付与せずに書込み権限を付与しても、合理的ではありません。
この項では、実行を許可するLDAP操作のタイプに応じて、ユーザーに付与する必要のある権限について説明します。
エントリの追加
追加されるエントリに対する追加権限を付与します。
エントリの各属性値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限することもできます。
エントリの削除
削除されるエントリに対する削除権限を付与します。
エントリの各属性値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限することもできます。
エントリ内の属性の変更
属性タイプに対する書込み権限を付与します。
各属性タイプの値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限することもできます。
エントリのRDNの変更
エントリに対する書込み権限を付与します。
新しいRDNで使用される属性タイプに対する書込み権限を付与します。
古いRDNを削除する権限を付与する場合、古いRDNで使用される属性タイプに対する書込み権限を付与します。
新しいRDNで使用される属性タイプの値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targattrfiltersキーワードを使用して制限することもできます。
別のサブツリーへのエントリの移動
移動するエントリに対するエクスポート権限を付与します。
移動するエントリの新しい上位エントリに対するインポート権限を付与します。
属性の値の比較
属性タイプに対する比較権限を付与します。
エントリの検索
検索フィルタで使用される各属性タイプに対する検索権限を付与します。
エントリが確実に返されるようにエントリで使用される最低1つの属性タイプに対する読取り権限を付与します。
エントリで返される各属性タイプに対する読取り権限を付与します。
ユーザーがディレクトリを検索するために設定する必要のある権限を簡単に理解できるように、次に例を示します。次の検索について考えてみます:
$ ldapsearch -h host -p port -D "uid=bjensen,dc=example,dc=com" \ -j pwd-file -b "dc=example,dc=com" \ "(objectclass=*)" mail
次のACIは、ユーザーbjensenに、自身のエントリを検索するためのアクセス権を付与できるかどうかを決定します:
aci: (targetattr = "mail")(version 3.0; acl "self access to \ mail"; allow (read, search) userdn = "ldap:///self";)
このACIではbjensenにobjectclass属性で検索する権限を許可していないため、検索結果リストは空になります。正常な検索操作のためには、次の例のようにACIを変更する必要があります:
aci: (targetattr = "mail || objectclass")(version 3.0; acl \ "self access to mail"; allow (read, search) userdn = \ "ldap:///self";)
ACI文において、権限は次の構文を使用します:
allow|deny (rights)
ここで、rightsはカッコで囲まれたコンマ区切りのキーワードのリストです。有効なキーワードは、read、write、add、delete、search、compare、selfwrite、proxy、import、exportまたはallです。
allのアクセス権限は、ターゲット・エントリに次の権限を与えません: proxy、importおよびexport。
次の例では、バインド・ルールがtrueと評価される場合、read、searchおよびcompareのアクセスが許可されます:
aci: (target="ldap:///dc=example,dc=com") (version 3.0;acl \ "example"; allow (read, search, compare) bindRule;)
ディレクトリに対して定義されたACIに応じて、いくつかの操作では、ディレクトリにバインドが必要です。次の項では、バインド・ルールがアクセスを制御するために使用される方法を説明します:
バインドとは、バインドDNおよびパスワードを入力して(SSLを使用する場合は、証明書を提示して)ディレクトリにログインするか、自身の認証を行うことです。バインド操作で提示される資格証明およびバインドの状況によって、ディレクトリへのアクセスが許可されるか拒否されるかが決定されます
ACI内のすべての権限セットには、必要な資格証明およびバインド・パラメータの詳細を示す、対応するバインド・ルールがあります。
単純なバインド・ルールでは、ディレクトリにアクセスするユーザーが特定のグループに属している必要があります。複雑なバインド・ルールでは、ユーザーが特定のグループに属し、特定のIPアドレスのマシンから午前8時から午後5時の間にログインする必要があることを設定できます。
バインド・ルールは、誰が、いつ、どこからディレクトリにアクセスできるかを定義します。具体的には、バインド・ルールは次の内容を指定できます:
アクセス権が付与されるユーザー、グループおよびロール
エンティティがバインドする必要のある場所(ユーザーが認証を受ける場所はなりすましの可能性があるので、信頼できません。この情報のみでACIを判断しないでください。)
バインドを実行する必要がある時間または日付
バインド時に使用する必要がある認証のタイプ
セキュリティ強度係数(つまり、現在使用中の暗号化鍵の長さ)
また、第9.4項「バインドルールの構文」で説明されているように、バインド・ルールは、ブール演算子を使用して、これらの条件を組み合せた複雑な構造にできます。
ディレクトリ・サーバーは、3値ロジックに従って、ACIで使用される論理式を評価します。これは、RFC 4511 (http://www.ietf.org/rfc/rfc4511.txt)「Lightweight Directory Access Protocol (LDAP): The Protocol」で説明されているLDAPフィルタの評価に使用されるものと類似しています。つまり、式の中の任意のコンポーネントが未定義と評価される(たとえば、リソースの制限により、式の評価が中断された場合など)と、ディレクトリ・サーバーはこの状況を正しく処理します。複雑なブール式で未定義値が発生しても、間違ってアクセス権を付与することはありません。
バインド・ルールは、ブール式AND、ORおよびNOTを使用する複合式で、細かいアクセス・ルールを設定できます。ブール・バインド・ルールを作成するときは、評価されるルールの順番を定義するために常にカッコを使用します。末尾のセミコロンは、最終ルールの後に出現する必要のある必須のデリミタです。
たとえば、bindRuleAをbindRuleB、またはbindRuleCおよびbindRuleDとバインドするには、次の構文を使用します:
(bindRuleA and (bindRuleB or (bindRuleC and bindRuleD));)
別の例を使用すると、バインドDNクライアントがexample.comドメイン内からアクセスされ、管理者グループのメンバーまたはメール管理者グループとカレンダ管理者グループの両方のメンバーである場合は、次のバインド・ルールはtrueと評価されます。
(dns = "*.example.com" and (groupdn = "ldap:///cn=administrators,dc=example,dc=com" or (groupdn = "ldap:///cn=mail administrators,dc=example,dc=com" and groupdn = "ldap:///cn=calendar administrators,dc=example,dc=com"));)
||演算子は、groupdnバインド・ルール・キーワード式でのみ、許可されています。その他すべてのバインド・ルール式については、or演算子を使用する必要があります。
アクセスが許可されるか拒否されるかは、ACIのバインド・ルールがtrueであると評価されるかどうかによります。次の項では、バインド・ルールの構文、およびアクセスを許可または拒否するために使用される様々なキーワードについて説明します。
バインド・ルールは、次のパターンのうちのどちらかを使用します:
keyword =" expression";
keyword!=" expression";
ここで、等号(=)は、バインド・ルールをtrueとするにはキーワードと式が一致する必要があることを示し、不等号(!=)は、バインド・ルールをtrueとするにはキーワードと式が一致してはならないことを示します。
式の前後の引用符("")および区切りを示すセミコロン(;)は必須です。使用できる式は、関連付けられたキーワードによります。
timeofdayキーワードは不等式(<、<=、>、>=)もサポートします。timeofdayキーワードはこれらの式をサポートする唯一のキーワードです。
次の表に、各キーワードと関連する式をリストし、式でワイルドカード文字を使用できるかどうかについても示します。
| キーワード | 有効な式 | ワイルドカード使用の可否 |
|---|---|---|
|
|
|
可(DNのみ) |
|
|
|
使用不可 |
|
値マッチングに基づくアクセスの定義( |
attribute |
使用不可 |
|
|
IPaddress |
使用可能 |
|
|
DNShostName |
使用可能 |
|
特定の時刻または曜日におけるアクセスの定義( |
|
使用不可 |
|
特定の時刻または曜日におけるアクセスの定義( |
hhmm、ここでhhは |
使用不可 |
|
認証メソッドに基づくアクセスの定義( |
authenticationMethod |
使用不可 |
|
接続のセキュリティ強度係数に基づくアクセスの定義( |
0-256 |
使用不可 |
次の項では、各キーワードのバインド・ルール構文の詳細を説明します。
userdnキーワード)ユーザー・アクセスは、userdnキーワードを使用して定義されます。userdnキーワードでは、次の書式で1つ以上の有効な識別名が必要です:
userdn = "ldap:///dn [|| ldap:///dn]..."
userdn!= "ldap:///dn [|| ldap:///dn]..."
ここで、dnはDNまたは式(anyone、all、selfまたはparent)の1つです。これらの式は次のユーザーを参照します:
userdn = "ldap:///anyone"匿名ユーザーと認証ユーザーの両方
userdn = "ldap:///all"認証ユーザーのみ
userdn = "ldap:///self"ACIのターゲット・エントリと同じユーザーのみ
userdn = "ldap:///parent"ACIターゲットの親エントリのみ
userdnキーワードは、次の書式でLDAPフィルタとして表すこともできます:
userdn = ldap:///suffix??sub?(filter)
カンマなどのDNの文法的な意味を持つ文字は、単一の円記号(\)でエスケープする必要があります。
次の項では、userdnキーワードを使用してユーザー・アクセスを定義する方法を説明します:
allキーワード)ディレクトリに正常にバインドしたすべてのユーザーに権限が適用されることを示すために、バインド・ルールを使用することができます。したがって、allキーワードはすべての認証ユーザーによるアクセスを許可します。これは、匿名アクセスを防ぐ一方で、汎用アクセスを許可します。
たとえば、すべての認証ユーザーに、ツリー全体に対する読取りアクセスを許可するには、dc=example,dc=comノードに次のACIを作成します:
aci: (version 3.0; acl "all-read"; allow (read) userdn="ldap:///all";)
anyoneキーワード)ディレクトリへの匿名アクセスを許可すると、バインドの状況にかかわりなく、バインドDNやパスワードを入力することなく誰でもそのディレクトリにアクセスすることができます。匿名アクセスを特定のアクセスのタイプ(たとえば、読取り用のアクセスや検索用のアクセスなど)に制限したり、ディレクトリ内の特定のサブツリーや個々のエントリに制限できます。anyoneキーワードを使用した匿名アクセスは、認証ユーザーによるアクセスも許可します。
たとえば、example.comツリー全体に対する匿名の読取りおよび検索アクセスを許可するには、dc=example,dc=comノードに次のACIを作成します:
aci: (version 3.0; acl "anonymous-read-search"; allow (read, search) userdn = "ldap:///anyone";)
selfキーワード)ユーザー自身のエントリに対して、ユーザーがアクセス権を付与または拒否されていることを指定します。この場合、バインドDNがターゲット・エントリのDNと一致しているかどうかで、アクセスが許可または拒否されます。たとえば、example.comツリーのすべてのユーザーにuserPassword属性への書込み権限を付与するには、dc=example,dc=comノードに次のACIを作成します。
aci: (targetattr = "userPassword") (version 3.0; acl "modify own password"; allow (write) userdn = "ldap:///self";)
parentキーワード)ユーザーのバインドDNがターゲット・エントリの親である場合にかぎり、ユーザーがエントリへのアクセスを許可または拒否されることを指定します。たとえば、バインドDNの任意の子エントリをユーザーが変更できるようにするには、dc=example,dc=comノードに次のACIを作成します:
aci: (version 3.0; acl "parent access"; allow (write) userdn="ldap:///parent";)
次の例に示されているようなフィルタ付きのURLを使用して、ACI内で動的にユーザーをターゲットにできます:
userdn = "ldap:///suffix??sub?(filter)"
たとえば、example.comツリーのaccounting分岐とengineering分岐のすべてのユーザーは、次のURLに基づいて動的にターゲット・リソースへのアクセスを許可または拒否されます:
userdn = "ldap:///dc=example,dc=com??sub?(|(ou=eng)(ou=acct))"
LDAP URL内でホスト名またはポート番号を指定しないでください。LDAP URLは常にローカル・ディレクトリ・サーバーに適用されます。
ワイルドカード文字(*)を使用して、ユーザーのセットを指定することもできます。たとえば、uid=b*,dc=example,dc=comのユーザーDNを指定すると、文字bで始まるバインドDNを持つユーザーのみが、設定された権限に基づいてアクセスを許可または拒否されることを示します。
ユーザー・アクセスに複雑なルールを作成するために、いくつかのLDAP URLまたはキーワード式を指定します。例:
userdn = "ldap:///uid=b*,c=example.com || ldap:///cn=b*,dc=example,dc=com";
バインド・ルールは、DNパターンのいずれかでバインドされたユーザーに対して、trueと評価されます。
特定のURLまたはDNを除外するユーザー・アクセスを定義するのに非等号(!=)演算子を使用します。例:
userdn != "ldap:///uid=*,ou=Accounting,dc=example,dc=com";
クライアントがaccountingサブツリー内でUIDベースの識別名としてバインドしていない場合、バインド・ルールはtrueと評価されます。このバインド・ルールは、ターゲット・エントリがディレクトリ・ツリーのaccounting分岐の下にない場合にのみ、意味を持ちます。
groupdnキーワード)特定のグループのメンバーは、ターゲット・リソースにアクセスできます。これはグループ・アクセスと呼ばれています。グループ・アクセスは、ユーザーが特定のグループに属するDNを使用してバインドする場合、ターゲット・エントリへのアクセスが許可または拒否されるのを指定するために、groupdnキーワードを使用して定義されます。
groupdnキーワードは、次の形式で1つ以上の識別名が必要です:
groupdn="ldap:///groupDN [|| ldap:///groupDN]..."
バインドDNが任意のグループDNで指定されたグループに属する場合、バインド・ルールはtrueと評価されます。次の項では、groupdnキーワードを使用した例を示します。
カンマなどのDNの文法的な意味を持つ文字は、単一の円記号(\)でエスケープする必要があります。
groupdn = "ldap:///cn=Administrators,dc=example,dc=com";
バインドDNが管理者グループに属する場合、バインド・ルールはtrueと評価されます。たとえば、管理者グループにディレクトリ・ツリー全体への書込みの権限を付与する場合は、次のACIをdc=example,dc=comノードに作成します:
aci: (version 3.0; acl "Administrators-write"; allow (write) groupdn="ldap:///cn=Administrators,dc=example,dc=com";)
groupdn = "ldap:///cn=Administrators,dc=example,dc=com || ldap:///cn=Mail Administrators,dc=example,dc=com";
バインドDNが管理者グループまたはメール管理者グループに属する場合、バインド・ルールはtrueと評価されます。
userattrキーワード)userattrキーワードは、バインドに使用するエントリ(バインド・エントリ)とターゲット・エントリの間で、一致する必要がある属性値を指定するのに使用できます。userattr式は、バインド・タイプ・フォーマットと属性値フォーマットの2つの形式があります。
次の項では、値マッチングに基づいたアクセスを定義する方法を説明します:
この形式は、一致を評価するときにバインドDN、およびおそらくバインド・エントリを使用するため、バインド・タイプ・フォーマットと名付けられます。これは、2つの形式の中でより複雑な形式です。バインド・タイプ・フォーマットは、次の3つの方法で使用できます:
ターゲット・エントリの属性値をバインドDNに一致するDNとして扱います。
ターゲット・エントリの属性値を、バインドDNがメンバーである必要があるグループDNとして扱います。
バインドDNとバインド·エントリの両方が、ターゲット・エントリの属性値に指定されているLDAP URLと一致している必要があります。
バインド・タイプuserattr形式は、次の構文を使用します:
userattr = "attrName#bindType"
ここで:
ターゲット・エントリの属性の名前です。
次のいずれかを指定する必要があります:
USERDN — attrNameの値はバインドDNと一致する必要があります。
GROUPDN — attrNameの値は、バインドDNを含む必要のあるグループです。
LDAPURL — attrNameの値は、バインドDNとエントリが一致する必要がある検索として扱われる「URL」(付録E)です。検索を実行するためには、URLのdn値がベースDNとして使用されます。ベースDNは、バインドDNと一致するか、またはバインドDNが親DNとしてそれを持つ必要があります。URLのscope値は、ベースDNのどの程度下位までバインドDNが一致できるかを制限します。最終的に、バインド・エントリはURLのfilter値と一致する必要があります。
バインド・タイプuserattr形式は、現在のターゲット・エントリの下のエントリ・レベルのターゲット指定を許可する特別な親キーワードを持っています。このキーワードに関する詳細は、第9.4.4.7項「継承」を参照してください。
属性値フォーマットは、次の2つの条件に一致する必要があります:
userattr式で指定された属性は、ターゲット・エントリおよびバインド・エントリの両方で存在する必要があります。
これらの属性の両方の値は、userattr式で指定された文字列の値に一致する必要があります。この文字列の値には、バインド・タイプのキーワード(USERDN、GROUPDN、LDAPURL)のいずれも指定することはできません。
属性値userattr形式は、次の構文を使用します:
userattr = "attrName#attrValue"
ここで:
ターゲット・エントリとバインド・エントリの両方の属性の名前です。
属性値(USERDN、GROUPDNまたはLDAPURLではない)を示す文字列です。
USERDNバインド・タイプの例バインド・ルールuserattrキーワード式の次の例は、バインドDNとターゲット・エントリの属性managerの値の一致を指定します。
userattr = "manager#USERDN"
バインドDNがターゲット・エントリのmanager属性の値と一致する場合、このバインド・ルールはtrueと評価されます。ターゲット・エントリのmanager属性は、バインドDNと一致する必要があります。ワイルドカードは使用できません。
次の例では、ACIは、DNdc=example, dc=commの下のサブツリーに位置するエントリのすべてのユーザー属性への完全なアクセス権をマネージャに付与します:
aci: (target="ldap:///dc=example,dc=com")(targetattr="*") (version 3.0;acl "manager all access"; allow (all) userattr = "manager#USERDN";)
GROUPDNバインド・タイプの例次は、バインドDNがメンバーである必要があるグループDNを含む属性を指定するバインド・ルールuserattrキーワード式の例です。
userattr = "owner#GROUPDN"
バインドDNがターゲット・エントリのowner属性で指定されたグループのメンバーである場合、バインド・ルールはtrueと評価されます。
LDAPURLバインド・タイプの例これは、バインドDNとエントリが一致している必要がある検索として扱われるLDAP URLを含む属性を指定するバインド・ルールuserattrキーワード式の例です。
userattr = "aciurl#LDAPURL"
属性aciurlは一例です。
バインドDNとバインド・エントリがLDAP URLで指定される検索要件のすべてを満たす場合、バインド・ルールはtrueと評価されます。たとえば、aciurlの値がldap:///dc=example,dc=com??one?(cn=joe*)である場合、バインドDNはdc=example,dc=comのベースDNの下で1レベル検索を満たし、バインド・エントリはフィルタ(cn=joe*)を満たす必要があります。
次は、バインド・エントリとターゲット・エントリの両方が一致する必要がある属性値を指定するバインド・ルールuserattrキーワード式の例です。
userattr = "favoriteBeverage#Water"
バインド・エントリとターゲット・エントリにWaterの値のfavoriteBeverage属性が含まれる場合、バインド・ルールはtrueと評価されます。
userattrキーワードを使用してバインドに使用されるエントリをターゲット・エントリに関連付けると、ACIは指定されたターゲットにのみ適用され、下位のエントリには適用されません。状況によっては、ターゲット・エントリの数レベル下位のACIのアプリケーションを拡張することもできます。これは、parentキーワードを使用し、ACIを継承するターゲットの下のレベルの数を指定することで可能です。
parentキーワードと関連してuserattrキーワードを使用する場合は、構文は次の例のようになります:
userattr = "parent[[inheritanceLevel].attribute#bindType"
ここで:
inheritanceLevelは、カンマ区切りのリストで、ターゲットのいくつ下のレベルまでACIを継承するかを示します。ターゲット・エントリの10レベル[0,1,2,3,4,..,9]下まで含めることができます。0は、ターゲット・エントリを示します。
attributeは、userattrのターゲットとなる属性です。
bindTypeは、USERDNまたはGROUPDNのどちらかです。LDAPURLバインド・タイプは、継承ではサポートされていません。
たとえば、バインドDNがターゲット・エントリのmanager属性と一致する場合、userattr = "parent[[0,1].manager#USERDN"バインドルールはtrueと評価されます。また、バインド・ルールは、バインドDNと一致するmanager属性を持つターゲット・エントリのすぐ下(ターゲットの1レベル下)のすべてのエントリに対して、trueと評価されます。
次の例は、ユーザーbjensenが、cn=Profilesエントリおよびcn=mailとcn=newsを含む子エントリの最初のレベルに対して、読取りと検索を許可されることを示しています。
cn=Profiles aci:(targetattr="*")(version 3.0, acl "profiles access" allow(read, search) userattr="parent[[0,1].owner#USERDN;) owner=cn=bjensen, ou=people, dc=example, dc=com cn=mail, cn=Profiles mailuser: bjensen cn=news, cn=Profiles newuser: bjensen
継承がこの例で使用されない場合は、次のいずれかを実行する必要があります:
ディレクトリ内のcn=Profiles、cn=mailおよびcn=newsエントリに、ユーザーbjensenの読取りおよび検索アクセスを明示的に設定します。
cn=mail、cn=Profilesおよびcn=news,cn=Profilesエントリに所有者属性および次のACIを追加します:
aci: (targetattr="*") (version 3.0; acl "profiles access"; allow (read,search) userattr="owner#USERDN";)
userattrキーワードをallまたはadd権限と組み合せて使用すると、サーバーの動作が想定どおりにならない場合があります。通常、新しいエントリがディレクトリに作成されると、ディレクトリ・サーバーは作成されたエントリのアクセス権を評価し、親エントリのアクセス権は評価しません。ただし、userattrキーワードを使用するACIの場合は、この動作によってセキュリティ・ホールが生じる可能性があるので、これを避けるためにディレクトリ・サーバーの通常動作は変更されます。
次の例ACIを考えてみます:
aci: (target="ldap:///dc=example,dc=com")(targetattr="*") (version 3.0; acl "manager-write"; allow (all) userattr = "manager#USERDN";)
このACIは、部下のエントリに対するすべての権限をマネージャに与えます。ただし、新しく作成されるエントリについてアクセス権が評価されるので、このタイプのACIでは、すべての社員に対して、manager属性が自身のDNに設定されるエントリの作成を許可します。たとえば、会社に不満を抱くJoeという社員(cn=Joe,ou=eng,dc=example,dc=com)は、ツリーのHuman Resources分岐にエントリを作成して、Human Resourcesの社員に付与された権限を使用(悪用)できます。
これは、次のエントリを作成することで可能です:
dn: cn= Trojan Horse,ou=Human Resources,dc=example,dc=com objectclass: top ... cn: Trojan Horse manager: cn=Joe,ou=eng,dc=example,dc=com
このようなセキュリティ上の危険を回避するために、ACIの評価プロセスでは、レベル0の追加権限、つまりエントリ自身に対する追加権限を付与しません。ただし、既存エントリの下位にあるエントリには、parentキーワードを使用して追加アクセス権を付与できます。親のいくつ下のレベルまで追加アクセス権を許可するかを指定する必要があります。たとえば、次のACIでは、バインドDNと一致するmanager属性を持つdc=example,dc=com内の任意のエントリに子エントリを追加できます:
aci: (target="ldap:///dc=example,dc=com")(targetattr="*") (version 3.0; acl "parent-access"; allow (add) userattr = "parent[1].manager#USERDN";)
このACIでは、バインドDNが親エントリのmanager属性と一致しているユーザーのみに追加権限が付与されます。
ipキーワード)バインド・ルールを使用して、バインド操作を特定のIPアドレスから行う必要があることを示すことができます。これは多くの場合、特定のマシンまたはネットワーク・ドメインからすべてのディレクトリの更新が強制的に実行されるようにするために使用されます。
IPアドレスに基づくバインド・ルールを設定するためのLDIF構文は、次のとおりです:
ip = "IPaddressList" ip != "IPaddressList"
IPaddressListは、次のうちの1つ以上のカンマ区切り要素のリストです:
特定のIPv4アドレス(123.45.6.7など)
IPv4/CIDRに準拠したアドレス(192.168.0.0/16など)
サブネットワークを指定するためのワイルドカードを含むIPv4アドレス(12.3.45.*など)
サブネットワーク・マスクを含むIPv4アドレスまたはサブネットワーク(123.45.6.*+255.255.255.192など)
有効な形式で大カッコ([と])を含むIPv6アドレス(RFC 2373 (http://www.ietf.org/rfc/rfc2373.txt)およびRFC 2732 (http://www.ietf.org/rfc/rfc2732.txt)で定義されています)次のアドレスは同等です:
ldap://[12AB:0000:0000:CD30:0000:0000:0000:0000]
ldap://[12AB::CD30:0:0:0:0]
ldap://[12AB:0:0:CD30::]
サブネット接頭辞長を含むIPv6アドレス(ldap://[12AB::CD30:0:0:0:0]/60など)
ディレクトリにアクセスするクライアントが指定されたIPアドレスに位置している場合、バインド・ルールはtrueと評価されます。これは、特定のサブネットまたはマシンのみから特定の種類のディレクトリ・アクセスを可能にするために役立ちます。ユーザーが認証を受けるIPアドレスはなりすまされる可能性があるため、信頼できないことに注意してください。ACIでは、これらの情報のみに依存にしないでください。
dnsキーワード)バインド・ルールによって、バインド操作を特定のドメインまたはホスト・マシンから行う必要があることを指定できます。これは多くの場合、特定のマシンまたはネットワーク・ドメインからすべてのディレクトリの更新が強制的に実行されるようにするために使用されます。
DNSホスト名に基づくバインド・ルールを設定するためのLDIF構文を次に示します:
dns = "DNShostname" dns != "DNShostname"
|
注意:
|
dnsキーワードには、完全修飾DNSドメイン名が必要です。ドメインを指定せずにホストへのアクセスを許可すると、セキュリティの脅威がもたらされる可能性があります。たとえば、次の式は使用できますが、お薦めできません:
dns = "legend.eng";
次のような完全修飾名を使用する必要があります:
dns = "legend.eng.example.com";
dnsキーワードでは、ワイルドカードを使用できます。例:
dns = "*.example.com";
ディレクトリにアクセスするクライアントが指定されたドメインに位置している場合、バインド・ルールはtrueと評価されます。これは、特定のドメインからのアクセスのみを許可する場合に役立ちます。システムでDNS以外のネーミング・サービスを使用している場合、ワイルドカードは機能しません。特定のドメインへのアクセスを制限したい場合は、第9.4.5項「特定のIPアドレスからのアクセスの定義(ipキーワード)」に説明されているように、ipキーワードを使用します。
timeofdayおよびdayofweekキーワード)バインド・ルールを使用して、特定の時刻または曜日だけにバインドするように指定できます。たとえば、月曜日から金曜日の午前8時から午後5時までの間のみ、アクセスを許可するようにルールを設定できます。アクセス権の評価に使用される時刻は、ディレクトリ・サーバー上の時刻で、クライアント上の時刻ではありません。
時刻に基づくバインド・ルールを設定するためのLDIF構文は、次のとおりです:
timeofday operator "time"
ここで、operatorは次の記号のいずれかになります:
=(等しい)
!={等しくない}
>(より大きい)
>=(以上)
<(より小さい)
<=(以下)
時刻は、24時間制で時と分を表す4桁で表現されます(hhmm、ここでhhは00-24の範囲、mmは00-60の範囲です)。例:
timeofday = "1200";は、システム時刻が正午を示す1分間にクライアントがディレクトリにアクセスする場合、trueになります。
timeofday!= "0100";は、午前1時以外の任意の時刻のアクセスに対して、trueになります。
timeofday> "0800";は、午前8:01から午後11:59のアクセスに対して、trueになります。
timeofday>= "0800";は、午前8:00から午後11:59のアクセスに対して、trueになります。
timeofday< "1800";は、夜12:00から午後5:59のアクセスに対して、trueになります。
timeofdayおよびdayofweekバインド・ルールの評価には、ディレクトリ・サーバー上の日付と時刻が使用されます(クライアント上の日時ではありません)。
曜日に基づくバインド・ルールを設定するためのLDIF構文は、次のとおりです:
dayofweek = "day1, day2 ..."
dayofweekキーワードに指定できる値は、英語の曜日の3文字の略語で、sun、mon、tue、wed、thu、fri、satです。アクセスを許可するすべての曜日を指定します。例:
dayofweek = "mon, tue, wed, thu, fri";
リストされているいずれかの曜日にディレクトリにアクセスする場合、バインド・ルールはtrueになります。
authmethodキーワード)クライアントが特定の認証メソッドを使用してディレクトリにバインドする必要があることを示すバインド・ルールを設定できます。次に示す認証メソッドを使用できます:
None認証は不要です。これはデフォルトです。匿名アクセスを示します。
Simpleクライアントは、ディレクトリにバインドするためにユーザー名とパスワードを入力する必要があります。
SSLクライアントは、Secure Sockets Layer (SSL)またはTransport Layer Security (TLS)接続でディレクトリにバインドする必要があります。
SSLの場合、接続はLDAPSの2番目のポートに確立されます。TLSの場合は、接続はStart TLS操作を介して確立されます。どちらの場合も、証明書が提供される必要があります。SSLの設定については、第23.6項「SASL認証の使用」を参照してください。
SASLクライアントは、Simple Authentication and Security Layer (SASL)メカニズム(たとえば、DIGEST-MD5やGSSAPI)を使用してディレクトリにバインドする必要があります。
認証メソッドに基づくバインド・ルールを設定するためのLDIF構文を次に示します:
authmethod = "authentication_method"
ここで、authentication_methodはnone、simple、sslまたはsasl sasl_mechanismです。
次の例は、authmethodキーワードの典型的な仕様を示します:
authmethod = "none"バインド・ルールの評価時に、認証はチェックされません。
authmethod = "simple"クライアントがユーザー名とパスワードを使用してディレクトリにアクセスする場合、バインド・ルールはtrueと評価されます。
authmethod = "ssl"クライアントがLDAPSで証明書を使用してディレクトリに対して認証される場合、バインド・ルールはtrueと評価されます。クライアントがLDAPSで簡易認証(バインドDNとパスワード)を使用して認証される場合、trueにはなりません。
authmethod = "sasl DIGEST-MD5"クライアントがSASL DIGEST-MD5メカニズムを使用してディレクトリにアクセスする場合、バインド・ルールはtrueと評価されます。この他にSASLメカニズムをサポートしているのは、EXTERNALおよびGSSAPIです。
ssfキーワード)バインド・ルールを使用すると、確立された接続で適用されている特定のレベルのセキュリティ強度係数(SSF)のみに基づいてバインドするように指定できます。接続のSSFは、接続で適用されている暗号の鍵の強度に基づいており、TLS/SSLまたはDIGEST-MD5/GSSAPIの機密保護接続または整合性接続のみに関連します。
セキュリティ強度係数に基づくバインド・ルールを設定するためのLDIF構文は、次のとおりです:
ssf operator "strength"
ここで、operatorは次の記号のいずれかになります:
=(等しい)
!=(等しくない)
>(より大きい)
>=(以上)
<(より小さい)
<=(以下)
強度は、接続で必要とされている暗号の鍵の強度を示す値で、0から256の値です。整合性が適用されているDIGEST-MD5/GSSAPI接続は、1のSSFを持ちます。TLS/SSLとDIGEST-MD5/GSSAPIの機密保護接続は、ディレクトリ·サーバーとクライアントとの間で行われる暗号ネゴシエーションに基づいて、SSFの変数の値を持つことができます。接続のネゴシエートされたSSFが大きいほど、接続における暗号化は強力になります。次に例を示します:
ssf = "1";は、整合性ssf = 1のみが接続で適用されている場合のアクセスに対して、trueになります。
ssf!= "40";は、ssf not equal 40が接続で適用されている場合のアクセスに対して、trueになります。
ssf> "128";は、ssf greater than 128が接続で適用されている場合のアクセスに対して、trueになります。
ssf>= "128";は、ssf greater than or equal 128が接続で適用されている場合のアクセスに対して、trueになります。
ssf< "56";は、ssf less than 56が接続で適用されている場合のアクセスに対して、trueになります。
クリアな接続は、SSF0になります。
次の項では、接続のセキュリティ強化係数キーワードに基づいた定義の方法について説明します。
次の表は、キー・サイズ・マッピングを暗号化する保護の品質(QOP)を説明します。
| 暗号 | QOP | 説明 |
|---|---|---|
|
RC4 (40) |
低 |
40ビット・キーを使用したRC4暗号(廃止) |
|
RC4 (56) |
中 |
56ビット・キーを使用したRC4暗号 |
|
DES |
中 |
56ビット・キーを使用した暗号ブロック連鎖(CBC)モードのデータ暗号化規格(DES)の暗号 |
|
RC4 (128) |
高 |
128ビット・キーを使用したRC4暗号 |
|
トリプルDES |
高 |
各Eステージで同じ鍵を持つEDEのCBCモード(2キー・モードとも呼ばれます)のトリプルDES暗号(鍵の長さの合計は112ビット) |
| 暗号 | TLS RFC | キー・サイズ | 説明 |
|---|---|---|---|
|
RC2_CBC_40 |
4346 |
40 |
暗号ブロック連鎖(CBC)モードのRC2暗号(廃止) |
|
RC4_40 |
4346 |
40 |
RC4暗号(廃止) |
|
DES40_CBC |
4346 |
40 |
暗号ブロック連鎖(CBC)モードのDES 40ビット暗号(廃止) |
|
DES_CBC |
4346 |
56 |
暗号ブロック連鎖(CBC)モードのDES 56ビット暗号 |
|
3DES_EDE_CBC |
4346 |
112 |
TDES |
|
RC4_128 |
4346 |
128 |
RC4暗号 |
|
IDEA_CBC |
4346 |
128 |
暗号ブロック連鎖(CBC)モードの国際データ暗号化アルゴリズム(IDEA)の暗号 |
|
SEED_CBC |
4162 |
128 |
暗号ブロック連鎖(CBC)モードのSEED暗号 |
|
CAMELLIA_128_CBC |
4132 |
128 |
暗号ブロック連鎖(CBC)モードのCamellia暗号 |
|
AES_128_CBC |
3268 |
128 |
暗号ブロック連鎖(CBC)モードの拡張暗号化規格(AES) |
|
AES_256_CBC |
3268 |
256 |
暗号ブロック連鎖(CBC)モードの拡張暗号化規格(AES) |
|
CAMELLIA_256_CBC |
4132 |
256 |
暗号ブロック連鎖(CBC)モードのCamellia暗号 |
|
AES_256_GCM |
5288 |
256 |
Galois Counter Mode (GCM)のAES |
次のACIは、SSF強度が128以上の接続を介してのみ、ユーザーに自身のパスワードを変更することを許可します:
(targetattr="userPassword||authPassword")(version 3.0; acl "User change pwd"; (allow (write) userdn="ldap:///self" and ssf >= "128");)
次の項では、Oracle Unified Directoryのアクセス制御モデルがOracle Directory Server Enterprise Editionで提供されるアクセス制御モデルとどのように異なるのかを説明します。
グローバルACIの構成は、2つの点で、Oracle Directory Server Enterprise EditionのグローバルACIの実装と異なります:
ds-config-global-aci属性は、ACIをルートのDSEエントリに配置するのではなく、cn=Access Control Handler,cn=configエントリ(第9.1項「アクセス制御の原則」を参照)のグローバルACIを指定します。
ACIでターゲット・キーワードを指定することで、グローバルACIの有効範囲を絞り込むことができます。たとえば、次のグローバルACIは、接尾辞dc=example,dc=comの下のエントリへの匿名の読取りアクセスを制限します:
ds-cfg-global-aci: (target="dc=example,dc=com") (targetattr!="userPassword||authPassword") (version 3.0; acl "Anonymous read access only under dc=example,dc=com suffix"; allow (read,search,compare) userdn="ldap:///anyone";)
(target="dc=example,dc=com")式の削除は、Oracle Unified Directoryのすべてのエントリに対してACIをグローバルにします。
ACIのDNワイルドカード・マッチングの実装は、次の使用法をサポートしています:
ワイルドカードはいくつでも相対識別名(RDN)の属性値に使用することができ、それらはゼロ個以上の文字と一致します(文字列のフィルタと同様)。たとえば、バインド・ルールは次のDNに一致します。uid=bob jensen,dc=example,dc=comおよびuid=bjensen,dc=example,dc=com:
userdn="ldap:///uid=b*jensen*,dc=example,dc=com"
最初のRDNの属性のタイプが一致しないため、DNcn=bill jensen,dc=example,dc=comと一致しません。
単一のワイルドカードも、任意のRDNの属性タイプと一致させるために使用することができます。(この場合のワイルドカードは、簡略化して省略することができます)。たとえば、これら2つのバインド・ルールは、まったく同じ動作をします:
userdn="ldap:///*=bjensen, dc=example, dc=com" userdn="ldap:///bjensen, dc=example, dc=com"
それらは両方とも、次のDNに一致します: uid=bjensen,dc=example,dc=comおよびcn=bjensen,dc=example,dc=com
単一のワイルドカードは、単一または複数の値を持つことのできる1つのRDNコンポーネントと正確に一致させるのに使用することができます。たとえば、次のバインド・ルールはDNuid=jensen,dc=example,dc=comおよびcn=smith,dc=example,dc=comに一致します:
userdn="ldap:///*,dc=example,dc=com"
ダブル・ワイルドカードは1つ以上のRDNコンポーネントを一致させるのに使用できます。たとえば、次のバインド・ルールはDNuid=jensen,ou=people,dc=example,dc=comおよびuid=jensen,ou=sales,ou=people,dc=example,dc=comに一致します:
userdn="ldap:///uid=bjensen,**,dc=example,dc=com"
Oracle Directory Server Enterprise Editionは権限をサポートしていません。特権サブシステム(第26.2項「rootユーザーと特権サブシステム」を参照してください)は、2つの点でACIに影響を与えます:
ds-privilege-name: bypass-acl権限を持つユーザーは、アクセス制御の評価をバイパスすることができます。
アクセス制御ルールを変更する必要のあるユーザーは、ds-privilege-name: modify-acl権限が必要です。
|
注意: Lightweight Directory Access Protocol (LDAP)のプロキシ設定された認可制御( プロキシ・ユーザーがACIアクセス評価をバイパスするのを許可するため、一般に、ユーザーは |
targetscopeキーワードtargetscopeキーワードは新しいスコープが組み込まれていることにより、Oracle Directory Server Enterprise Editionとは異なります:
subordinateターゲット・リソースの下のサブツリーにのみACIを制限します。
Oracle Unified Directoryは、LDAPの変更増分の拡張(https://opends.dev.java.net/public/standards/rfc4525.txt)をサポートします。この拡張は、Oracle Directory Server Enterprise Editionではサポートされていません。増分される属性は、書込み権限を持っている必要があります。
Oracle Unified DirectoryはACIでマクロをサポートします。
rolednキーワードロールはOracle Unified Directoryでサポートされていないので、rolednキーワードは使用できません。同等の機能は、グループを使用することで得ることができます。
ディレクトリ・ツリー構造を繰り返し使用する組織では、ディレクトリ・ツリー内のACIの数を最適化するためにマクロを使用することにより、パフォーマンスとACIのメモリー使用量を向上させることができます。ディレクトリ・ツリー内のACIの数を減らすことによって、アクセス制御ポリシーの管理が簡単になります。
この項では、マクロACIとその使用法について説明します。この項の内容は、次のとおりです:
マクロは、ACIの中でDN、またはDNの一部を表現するために使用されるプレースホルダです。マクロを使用すると、ACIのターゲット部分またはバインド・ルール部分、あるいはその両方のDNを表せます。実際の処理では、Directory ServerがLDAP操作を受け取ると、LDAP操作のターゲットとなるリソースに対してACIマクロのマッチングが行われます。このマッチングは、一致する部分文字列(存在する場合)を確認するために行われます。一致が検出された場合は、一致した部分文字列を使用してバインド・ルール側のマクロが展開され、その展開バインド・ルールを評価してリソースへのアクセス権が決定されます。
マクロACIを使用する利点と最も効果的に機能させる方法を、例を通して説明します。図9-1は、ACIの合計数を効果的に減らすために、マクロACIを使用しているディレクトリ・ツリーを示しています。
この例では、同じツリー構造のサブドメインが同じパターンで繰り返されています(ou=groups, ou=people)。example.comディレクトリ・ツリーには、dc=hostedCompany2, dc=example,dc=comおよびdc=hostedCompany3,dc=example,dc=comという接尾辞が格納されているので、このパターンはツリー内でも繰り返されています。ただし、前述の図には示されていません。
ディレクトリ・ツリーに適用されるACIでも、同じパターンが繰り返されています。たとえば、次のACIはdc=hostedCompany1,dc=example,dc=com node:上に置かれています。
aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)
このACIは、dc=hostedCompany1,dc=example,dc=comツリー内のすべてのエントリに対する読取りおよび検索権限をDomainAdminsグループに与えます。
次のACIは、dc=hostedCompany1,dc=example,dc=comノード上に置かれています:
aci: (targetattr="*") (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)
次のACIは、dc=subdomain1, dc=hostedCompany1, dc=example, dc=comノード上に置かれています:
aci: (targetattr="*") (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1, dc=example,dc=com";)
次のACIは、dc=hostedCompany2, dc=example, dc=comノード上に置かれています:
aci: (targetattr="*") (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany2, dc=example,dc=com";)
次のACIは、dc=subdomain1, dc=hostedCompany2, dc=example, dc=com node上に置かれています:
aci: (targetattr="*") (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany2, dc=example,dc=com";)
前述の4つのACIの違いは、groupdnキーワード内で指定されているDNのみです。DN用のマクロを使用することによって、これらのACIを、1つのACIにまとめてルート・ツリーのdc=example,dc=comノードに置くことができます。このマクロACIは次のようになります:
aci: (target="ldap:///ou=Groups,($dn),dc=example,dc=com") (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)
以前は使用されなかったtargetキーワードは、新しいACIで使用されます。
この例では、ACIの数が4から1に減っています。本当の決定要因は、ディレクトリ・ツリー全体で繰り返されているパターンの数です。
マクロACIには、DNまたはDNの一部を置き換える次のタイプの式があります:
($dn)
[$dn]
($attr.attrName)。ここで、attrNameはターゲット・エントリに含まれる属性を表します。
この項では、userdn、roledn、groupdnおよびuserattrのようなバインド資格証明を提供するために使用されるACIキーワードをまとめてACIのサブジェクトと呼びます。サブジェクトは、ACIの適用対象を決定します。
表9-2は、特定のACIキーワードの置換に使用できるマクロを示しています。
表9-2 マクロACIキーワード
| マクロ | 説明 | ACIキーワード |
|---|---|---|
|
|
targetでマッチングに使用され、サブジェクト内で直接置き換えられます。たとえば、targetまたはtargetfilterと一致し、一致した値はuserdn、groupdnまたはuserattrに置き換えます。 |
(target、targetfilter)および(userdn、groupdn、userattr) |
|
|
サブジェクトのサブツリー内で機能する複数のRDNに置き換えられます。 |
(targetfilter)および(userdn、groupdn、userattr) |
|
|
ターゲット・エントリの |
userdn、groupdn、userattr |
マクロACIキーワードには、次のような制限が適用されます:
($dn)マクロをサブジェクトで使用する場合は、($dn)を含むターゲットを定義する必要があります。
[$dn]マクロをサブジェクトで使用する場合は、($dn)を含むターゲットを定義する必要があります。
($dn)マクロと[$dn]マクロの両方を、サブジェクトで($attr.attrName)マクロと組み合せることができます。
次の項では、マクロACIの評価メカニズムを説明します。この項の内容は、次のとおりです:
($dn)マッチングACIのtargetに含まれる($dn)マクロを、LDAPリクエストのターゲットとなるエントリと比較することによって、実際に置き換えられる値が決定します。たとえば、このエントリをターゲットとするLDAPリクエストがあるとします:
cn=all, ou=groups, dc=subdomain1, dc=hostedCompany1, dc=example, dc=com
また、次のようなtargetを定義しているACIもあるとします:
(target="ldap:///ou=Groups,($dn),dc=example,dc=com")
($dn)マクロは"dc=subdomain1, dc=hostedCompany1"と一致します。この部分文字列は、その後、ACIのサブジェクトの置換に使用されます。
サブジェクト内での($dn)の置換
ACIのサブジェクト内では、($dn)マクロはターゲット内で一致する部分文字列全体に置き換えられます。例:
groupdn="ldap:///cn=DomainAdmins,ou=Groups,($dn),dc=example,dc=com"
このシナリオでは、ターゲット内の($dn)に一致する文字列がdc=subdomain1, dc=hostedCompany1である場合、同じ文字列がサブジェクト内で使用されます。サブジェクトは次のように展開されます:
groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"
ACIのtargetfilter内では、($dn)マクロはターゲット内で一致する部分文字列全体に置き換えられます。例:
(targetattr="*")(targetfilter=(&(objectClass=nsManagedPerson)(!(memberOf=cn=ServiceAdministrators,ou=Groups,($dn),o=ace industry,c=us))(!(memberOf=cn=Service Help Desk Administrators,ou=Groups,($dn),o=ace industry,c=us))))
targetfilterは次のようになります:
(targetattr="*")(targetfilter=(&(objectClass=nsManagedPerson) (!(memberOf=cn=ServiceAdministrators,ou=Groups,dc=subdomain1, dc=hostedCompany1,o=ace industry,c=us)) (!(memberOf=cn=Service Help Desk Administrators,ou=Groups,dc=subdomain1,dc=hostedCompany1,o=ace industry,c=us))))
マクロが展開されると、通常のプロセスに続いてDirectory ServerがACIを評価し、アクセス権が与えられるかどうかを決定します。
|
注意: 標準のACIとは異なり、マクロ置換を使用したACIはターゲット・エントリの子へのアクセスを許可する必要はありません。これは、子のDNがターゲットとなった場合に、置換によってサブジェクト文字列内に有効なDNが作成されない可能性があるためです。 |
サブジェクト内での[$dn]の置換
[$dn]の置換メカニズムは、($dn)と若干異なっています。一致する対象が見つかるまで、一番左にあるRDNコンポーネントを外しながら、ターゲット・リソースのDNが数回検証されます。
cn=all,ou=groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=comサブツリーをターゲットとするLDAPリクエストで、次のようなACIのシナリオがあるとします:
aci: (targetattr="*") (target="ldap:///ou=Groups,($dn),dc=example,dc=com") (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:/cn=DomainAdmins,ou=Groups,[$dn], dc=example,dc=com";)
サーバーは次のように処理を続け、このACIを展開します:
targetの($dn)とdc=subdomain1, dc=hostedCompany1が一致することをサーバーが確認します。
サブジェクトの[$dn]をdc=subdomain1, dc=hostedCompany1で置き換えます。
この結果、サブジェクトはgroupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"になります。バインドDNがそのグループのメンバーであるため、アクセスが許可される場合は、マクロの展開は停止し、ACIが評価されます。バインドDNがメンバーでない場合は、処理を継続します。
サブジェクトの[$dn]をdc=hostedCompany1で置き換えます。
この結果、サブジェクトはgroupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com"になります。バインドDNはこのグループのメンバーであることを再びテストされ、メンバーである場合は、ACIは完全に評価されます。ただし、バインドDNがメンバーでない場合は、マクロの展開は最後に一致したRDNで置き換えたところで終了し、このACIに対する評価は終了します。
[$dn]マクロの利点は、ドメインレベルの管理者に対して、ディレクトリ・ツリー内のすべてのサブドメインへのアクセス権を柔軟な方法で与えられることです。したがって、[$dn]マクロは、ドメイン間の階層的な関係を表す場合に便利です。
たとえば、次のようなACIがあるとします:
aci: (target="ldap:///ou=*,($dn),dc=example,dc=com") (targetattr="*") (targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn= "ldap:/cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)
このACIは、cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=comのメンバーに対して、dc=hostedCompany1の下にあるすべてのサブドメインへのアクセス権を与えます。したがって、そのグループに属する管理者は、たとえばサブツリーou=people,dc=subdomain1.1,dc=subdomain1にアクセスできます。
ただし、同時に、cn=DomainAdmins,ou=Groups, dc=subdomain1.1のメンバーのou=people,dc=subdomain1, dc=hostedCompany1およびou=people,dc=hostedCompany1ノードに対するアクセスは拒否されます。
($attr.attrname)マクロは、常にACIのサブジェクト部分で使用されます。たとえば、次のgroupdnを定義できます。
groupdn = "ldap:/cn=DomainAdmins,ou=($attr.ou),dc=HostedCompany1,dc=example,dc=com"
ここで、サーバーが次のエントリをターゲットとするLDAP操作を受け取ったとします:
dn: cn=Babs Jensen,ou=People,dc=HostedCompany1,dc=example,dc=com cn: Babs Jensen sn: Jensen ou: Sales ...
ACIのgroupdn部分を評価するために、サーバーはターゲット・エントリに格納されているou属性の値を読み取ります。その後、サブジェクト内でこの値を置換してマクロを展開します。この例では、groupdnは次のように展開されます:
groupdn= "ldap:///cn=DomainAdmins,ou=Sales,dc=HostedCompany1,dc=example,dc=com"
続いて、通常のACI評価アルゴリズムに従って、Directory ServerがACIを評価します。
マクロ内で指定された属性が複数の値を持つ場合は、それぞれの値を使用して順にマクロが展開されます。最初にマッチングに成功した値が使用されます。
この項では、プロキシ・サーバーで提供されているアクセス制御メカニズムの原則について説明します。内容は次のとおりです:
Oracle Unified Directoryでは、データの仮想ディレクトリ・ビューを公開することで仮想化が可能です。したがって、Oracle Unified Directoryはそのデータに誰がアクセスできるか、およびそのデータのどの部分をアクセス可能にするかの制御を担当します。データの仮想ディレクトリ・ビューへのアクセスを制御するために、仮想ACIを定義できます。Oracle Unified Directoryが仮想ディレクトリ・データ・ビューに対するリクエストを受信すると、仮想ACIおよび、ユーザーにより提供された認証情報を使用して、リクエストされた情報へのアクセスを許可または拒否します。
仮想ACIによって、ワークフロー・レベルで適用するACIを定義できます。これは、任意のワークフロー要素を含むワークフローに仮想ACIを適用できることを意味します。
仮想ACIは、ACIと構文が同じですが、この項で定義されているいくつかの制限があります。ACI構文の詳細は、第9.2項「ACI構文」を参照してください。次のキーワードを持つバインド・ルールのみがサポートされます。
userdn
ip
dns
timeofdayおよびdayofweek
authmethod
ssf
これは、セキュリティ強度係数です。詳細は、第9.4.9項「接続のセキュリティ強度係数に基づくアクセスの定義(ssfキーワード)」を参照してください。
仮想ACIは、ネットワーク・グループのワークフローごとに有効化できます。ただし、各ワークフローでは、仮想ACIを使用することも使用しないこともできます。ワークフローのvirtual-aci-modeプロパティによって、仮想ACIを使用する必要があるかどうかを指定できます。virtual-aci-modeがtrueに設定された場合、ACIを処理するすべての操作がこの属性を仮想ACIとして管理します。属性は、ユーザー・データとともに格納されなくなり、cn=virtual acisで知られる特定のディレクトリ情報ツリー(DIT)に格納されます。
ワークフローごとに、access-control-groupプロパティを使用するアクセス制御グループを定義できます。仮想ACIを無効にした場合、ワークフローではローカル・バックエンド・アクセス制御グループしか使用できなくなります。仮想ACI機能を有効にした場合、任意のアクセス制御グループを使用できます。
仮想ACIを実装する場合、次の点を考慮する必要があります。
ディレクトリ・サーバーとしてOracle Unified Directoryをインストールする場合、仮想ACIはサポートされません。
プロキシ・サーバーとしてOracle Unified Directoryをインストールする場合、任意のサポートされているデプロイメントで仮想ACIを使用できます。
仮想ACIではバインド・ルールの一部のタイプがサポートされません。サポートされているバインド・ルールの詳細は、第9.7.2項「仮想ACI構文」を参照してください。
グローバルACIは、仮想ACIが有効な場合に適用されます。
仮想ACIは、cn=virtual acisのレプリケーションを有効化できます。これには、アクセス制御グループの構成をレプリケートされるサーバーで同一にする必要があります。
