| ナビゲーション・リンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Directory Server Enterprise Edition管理ガイド 11gリリース1(11.1.1.5.0) |
2. Directory Serverのインスタンスと接尾辞
7. Directory Serverのパスワード・ポリシー
8. Directory Serverのバックアップとリストア
9. Directory Serverのグループ、ロールおよびCoS
16. Directory Proxy Serverのツール
17. Directory Proxy Serverのインスタンス
19. Directory Proxy Serverの証明書
20. Directory Proxy Serverのロード・バランシングとクライアント・アフィニティ
22. Directory Proxy Serverによる仮想化
24. Directory Proxy ServerとバックエンドLDAPサーバーの接続
25. クライアントとDirectory Proxy Serverの接続
26. Directory Proxy Serverのクライアント認証
27. Directory Proxy Serverのロギング
28. Directory Proxy Serverの監視とアラート
第3部 Directory Service Control Centerの管理
ACIを作成するには、Directory Service Control Center(DSCC)を使用するか、コマンドラインを使用します。どちらの方法を選択するにしても、一般的には最初から新しいACIを作成するより、既存のACI値を表示してコピーしたほうが簡単です。
DSCCではaci属性値を表示および変更できます。DSCCを介したACIの変更方法は、DSCCのオンライン・ヘルプを参照してください。
コマンドラインを使用してACIを作成するには、まずファイルの中でLDIF文を使用してACIを作成します。その後、ldapmodifyコマンドを使用して、ACIをディレクトリ・ツリーに追加します。
このタスクの実行には、DSCCが使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。
dn: dc=example,dc=com changetype: modify add: aci aci: (target)(version 3.0; acl "name";permission bindrules;)
次の例は、ACIの追加方法を示します。ACIを変更または削除するには、addをreplaceまたはdeleteに置き換えます。
一般的に使用されるACIの例は、「アクセス制御の使用例」を参照してください。
$ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - -f ldif-file
ACIは、エントリのaci属性の1つ以上の値として保存されます。aci属性は、ディレクトリ・ユーザーが読取りおよび変更できる複数値操作属性です。そのため、ACI属性自身がACIで保護される必要があります。通常、管理ユーザーには、aci属性への完全アクセス権が付与されます。
このタスクの実行には、DSCCが使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。
$ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -b entryDN -s base "(objectclass=*)" aci
その結果、新しいLDIF ACI定義にコピーして編集できるLDIFテキストが出力されます。ACIの値は長い文字列になるため、ldapsearch操作による出力は、多くの場合数行にわたって表示されます。また、最初の空白は継続マーカーです。LDIF出力に継続マーカーが含まれないようにするには、-Tオプションを使用します。LDIF出力をコピーして貼り付ける場合は、出力形式を考慮してください。
接尾辞を作成すると、最上位(ルート)レベルでいくつかのデフォルトACIが作成されます。これらのACIにより、デフォルト管理ユーザーcn=admin,cn=Administrators,cn=configは、ディレクトリ・マネージャと同じディレクトリ・データへのアクセス権を持つことができます。
このタスクの実行には、DSCCが使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。
$ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -b "" -s base "(objectclass=*)" aci
aci属性には、次の構文があります。
aci: [list of (target)](version 3.0; acl "name";[list of "permission bindRules;"])
ACI構文では次の値が使用されます。
アクセス制御するエントリ、属性、またはエントリと属性のセットを指定します。targetには、識別名、1つ以上の属性、または単一のLDAPフィルタを指定できます。targetはオプションです。targetが指定されない場合、ACIは定義されているエントリとそのサブツリーに適用されます。ターゲットの詳細は、「ACIターゲット」を参照してください。
ACIバージョンを識別する必須の文字列。
ACIを識別する必須の文字列。名前に制約はありませんが、ACIには一意でわかりやすい名前を使用することをお薦めします。一意の名前を使用すると、実効権限取得によって適用するACIを決定できます。
許可または拒否する権限を指定します。権限の詳細は、「ACI権限」を参照してください。
ユーザーがアクセス権を付与されるために提供する必要がある資格証明およびバインド・パラメータを指定します。バインド・ルールは、ユーザー・メンバーシップ、グループ・メンバーシップ、またはクライアントの接続プロパティに基づいて指定することもできます。バインド・ルールの詳細は、「ACIバインド・ルール」を参照してください。
ACIの権限とバインド・ルールの部分は、ペアで設定されます。これは、アクセス制御ルール(ACR)とも呼ばれています。ターゲットにアクセスするために指定される権限は、付随するバインド・ルールがtrueかfalseかによって、付与されるか拒否されるかが決定されます。
複数のターゲットおよび、複数の権限とバインド・ルールのペアを使用できます。これにより、ターゲットとなるエントリおよび属性の両方を詳細に指定し、特定のターゲットに対して複数のアクセス制御を効率的に設定できます。次の例は、複数のターゲットおよび、複数の権限とバインド・ルールのペアを持つACIを示します。
aci: (targetdefinition)...(targetdefinition)(version 3.0;acl "name"; permission bindRule; ...; permission bindRule;)
次の例で、ACIは、bjensenが自身のディレクトリ・エントリ内のすべての属性を変更する権限を持つことを指定しています。
aci: (target="ldap:///uid=bjensen,dc=example,dc=com") (targetattr="*")(targetscope="subtree")(version 3.0; acl "example"; allow (write) userdn="ldap:///self";)
次の各項では、ターゲット、権限およびバインド・ルールの構文について説明します。
ACIターゲット文では、アクセス制御するエントリ、属性、またはエントリと属性のセットを指定します。
ACIターゲット文には、次のような構文があります。
(keyword = "expression")
ターゲットでは、次の値が使用されます。
ターゲットのタイプを示します。
ターゲットを識別します。構文上、expressionの前後には引用符("")が必要です。ただし、現在の実装では、targetattr=*のような表現も受け入れています。
ターゲットが、expressionで指定されたオブジェクトであるか、そうでないかを示します。
!=演算子は、targettrfiltersキーワードまたはtargetscopeキーワードでは使用できません。
ターゲット・キーワードの詳細は、次の項を参照してください。
次の表は、ターゲット・キーワードとそれに関連する式を示します。
表6-1 ターゲット・キーワードとその式
|
targetキーワードは、ディレクトリ・エントリに対してACIが定義されることを指定します。targetキーワードでは、次の構文を使用します。
(target = "distinguished_name")
または
(target != "distinguished_name")
識別名は、ACIが定義されるエントリをルートとするサブツリー内に存在する必要があります。たとえば、ou=People,dc=example,dc=com上のACIでは、次のようなターゲットを使用できます。
(target = "ldap:///uid=bjensen,ou=People,dc=example,dc=com")
エントリのDNは、文字列表現の識別名とする必要があります(RFC 4514)。そのため、カンマなど、DNの文法的な意味を持つ文字は、単一の円記号(\)でエスケープする必要があります。
targetキーワードの式では、アスタリスク文字で表されるワイルドカードを使用できます。アスタリスクは、属性値、値のサブストリングまたはDNコンポーネントと一致します。たとえば、次の式はすべてuid=bjensen,ou=people,dc=example,dc=comと一致します。
target= "ldap:///uid=bj*,ou=people,dc=example,dc=com"
target= "ldap:///uid=*,ou=people,dc=example,dc=com"
target= "ldap:///*,ou=people,dc=example,dc=com"
target= "ldap:///uid=bjensen,*,dc=com"
target= "ldap:///uid=bjensen*"
また、次の例のようにワイルドカードを使用することもできます。
target="ldap:///uid=*,dc=example,dc=com"
このターゲットは、example.comツリー全体の中でエントリのRDNにUID属性を持つ各エントリと一致します。
target="ldap:///*Anderson,ou=People,dc=example,dc=com"
このターゲットは、ネーミング属性に関係なく、ou=Peopleブランチ内のRDNがAndersonで終わる各エントリと一致します。
target="ldap:///uid=*,ou=*,dc=example,dc=com"
このターゲットは、example.comツリー内で、識別名にuidとou属性を含む各エントリと一致します。
また、target="ldap:///uid=bjensen,o*,dc=com"のようにワイルドカードを使用しても受け入れられますが、非推奨です。
targetattrキーワードは、ターゲット・エントリの1つ以上の属性に対してACIが定義されることを示します。targetattrキーワードでは、次の構文を使用します。
(targetattr = "attribute")
または
(targetattr != "attribute")
targetattrキーワードがない場合、属性はターゲットになりません。すべての属性をターゲットにするには、targetattrキーワードをtargetattr="*"と指定する必要があります。
ターゲット属性は、ターゲット・エントリまたはそのサブツリー内に存在する必要はありませんが、存在すればACIが適用されます。
ターゲット属性は、スキーマで定義されている必要はありません。スキーマ・チェックを行わないことにより、データとそのスキーマをインポートする前にアクセス制御ポリシーを実装できます。
次の構文を使用して、複数の属性を対象にtargetattrキーワードを使用できます。
(targetattr = "attribute1 || attribute2|| ... attributeN")
注意: 属性別名を構成する場合、属性名とtargetattrキーワードの別名の両方を指定して、ACIでそれらを認識させる必要があります。
ターゲット属性には、指定された属性のすべてのサブタイプが含まれます。たとえば、(targetattr = "locality")はlocality;lang-frもターゲットになります。
targetattrキーワードの式でワイルドカードを使用できますが、意味はなく、パフォーマンスが低下するのみです。
targetfilterキーワードは、LDAPフィルタと一致するエントリをターゲットとするACIで使用されます。このACIは、LDAPフィルタと一致し、かつACIの範囲内にあるすべてのエントリに適用されます。targetfilterキーワードでは、次の構文を使用します。
(targetfilter = "(standard LDAP search filter)")
例6-1 特定のエントリをターゲットとするtargetfilterキーワードの使用方法
次の例は、有給者または契約者のステータスを持つ従業員と勤務時間(正社員に対する割合)の属性を示します。このフィルタは、契約者あるいはパートタイム従業員のエントリをターゲットにしています。
(targetfilter = "(|(status=contractor)(fulltime<=79))")
ACIでは、Netscapeが拡張したフィルタ構文はサポートされません。たとえば、次のターゲット・フィルタは有効ではありません。
(targetfilter = "(locality:fr:=<= Québec)")
国際化された値に関するマッチング・ルールを記述するフィルタ構文はサポートされます。たとえば、次のターゲット・フィルタは有効です。
(targetfilter = "(locality:2.16.840.1.113730.3.3.2.18.1.4:=Québec)")
targetfilterキーワードは、ACIのターゲットとしてすべてのエントリを選択します。targetfilterキーワードとtargetattrキーワードを一緒に使用して、ターゲット・エントリの属性のサブセットに適用するACIを作成できます。
targattrfiltersキーワードは、LDAPフィルタを使用することで特定の属性値をターゲットとするACIで使用されます。targattrfiltersキーワードを使用することで、属性値がACIで定義された条件を満たすときに属性に対する権限を許可または拒否できます。属性の値に基づいてアセス権を付与または拒否するACIは、値ベースACIと呼ばれています。targattrfiltersキーワードでは、次の構文を使用します。
(targattrfilters="add=attr1:F1 && attr2:F2... && attrn:Fn, \ del=attr1:F1 && attr2:F2 ... && attrn:Fn")
それぞれの意味は次のとおりです。
属性を作成する操作を示します。
属性を削除する操作を示します。
ターゲット属性を示します。
関連付けられた属性のみに適用するフィルタを示します。
フィルタをエントリに適用して、それらのエントリを作成、削除または変更する場合に、次の条件を満たす必要があります。
エントリを作成または削除する場合、その属性の各インスタンスはフィルタを満たす必要があります。
エントリを変更する際に、その操作で属性を追加する場合、その属性に適用される追加フィルタが満たされる必要があります。その操作で属性を削除する場合、その属性に適用する削除フィルタが満たされる必要があります。
エントリ内にすでに存在する属性の各値が置き換えられる場合、追加および削除フィルタが満たされる必要があります。
例6-2 targattrfiltersキーワードを使用して、ユーザーに対し自身のエントリへのロールの追加を許可する
次のACIを使用すると、ユーザーはsuperAdminロール以外の任意のロールを自身のエントリに追加できます。またこれにより、ユーザーは123という接頭辞を持つ電話番号を追加できます。
(targattrfilters="add=nsroleDN:(!(nsRoleDN=cn=superAdmin)) \ && telephoneNumber:(telephoneNumber=123*)")
targetscopeキーワードは、ACIの範囲を指定するACIで使用されます。targetscopeキーワードでは、次の構文を使用します。
(targetscope="base")
targetscopeキーワードは、次のいずれかの値を持ちます。
ACIは、ターゲット・リソースのみに適用されます。
ACIは、ターゲット・リソースとその第1世代の子に適用されます。
ACIは、ターゲット・リソースとそのサブツリーに適用されます。
targetscopeキーワードが指定されない場合、デフォルト値はsubtreeになります。
権限は、ACIで許可または拒否されるアクセスのタイプを指定します。バインド・ルールの詳細は、次の項を参照してください。
ACI権限文には、次のような構文があります。
allow|deny (right1, right2 ...)
rightは、ディレクトリ・データに実行できる操作を定義します。ACI文のrightは、カッコで括られたカンマ区切りのキーワードのリストです。
rightは、互いに独立して付与されます。たとえば、add権限を持つがdelete権限を持たないユーザーは、エントリの作成はできますが削除はできません。ディレクトリに対するアクセス制御ポリシーを計画している場合、ユーザーに対して合理的に権利を付与するようにします。たとえば、readおよびsearch権限を付与せずにwrite権限を付与しても、合理的ではありません。
ACI権限文では、次の権限を許可または拒否できます。
ディレクトリ・データを読み取る権限。この権限は、検索操作のみに適用されます。
属性を追加、変更または削除することでエントリを変更する権限。この権限は変更およびDN変更操作に適用されます。
エントリを作成する権限。この権限は、追加操作のみに適用されます。
エントリを削除する権限。この権限は、削除操作のみに適用されます。
ディレクトリ・データを検索する権限。ユーザーが検索結果の一部として返されたデータを参照するためには、SearchおよびRead権限が必要です。この権限は、検索操作のみに適用されます。
ディレクトリに格納されているデータとユーザーが入力したデータを比較する権限。比較権限を使用すると、ディレクトリが問合せの応答として成功または失敗のメッセージを返しますが、ユーザーはエントリまたは属性の値を参照できません。この権限は、比較操作のみに適用されます。
ユーザーがターゲット・エントリの属性内で自身のDNを追加または削除する権限。この属性の構文は、distinguished nameである必要があります。この権限は、グループ管理でのみ使用されます。Selfwrite権限は、プロキシ認可で機能します。これは、(バインドされたユーザーのDNではなく)グループ・エントリからプロキシDNを追加または削除する権限を付与します。
指定されたDNが別のエントリの権限でターゲットにアクセスする権限。ディレクトリ・マネージャDNを除くディレクトリ内の任意のユーザーのDNを使用して、プロキシ・アクセス権を付与できます。ディレクトリ・マネージャにはプロキシ権限を付与できません。
エントリを指定されたDNにインポートする権限。この権限は、DN変更操作に適用されます。
エントリを指定されたDNからエクスポートする権限。この権限は、DN変更操作に適用されます。
指定されたDNがターゲット・エントリに対して、read、write、search、delete、compareおよびselfwriteの権限を持つ権限。Allアクセス権は、ターゲット・エントリに対するproxy、importおよびexportの権限については制御しません。
この項では、一連のLDAP操作の実行に必要な権限について説明します。
追加されるエントリに対する追加権限を付与します。
エントリの各属性値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targettrfiltersキーワードを使用して制限することもできます。
削除されるエントリに対する削除権限を付与します。
エントリの各属性値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targettrfiltersキーワードを使用して制限することもできます。
属性タイプに対する書込み権限を付与します。
各属性タイプの値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targettrfiltersキーワードを使用して制限することもできます。
エントリに対する書込み権限を付与します。
新しいRDNで使用される属性タイプに対する書込み権限を付与します。
古いRDNを削除する権限を付与する場合、古いRDNで使用される属性タイプに対する書込み権限を付与します。
新しいRDNで使用される属性タイプの値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、targettrfiltersキーワードを使用して制限することもできます。
移動するエントリに対するエクスポート権限を付与します。
移動するエントリの新しい上位エントリに対するインポート権限を付与します。
属性タイプに対する比較権限を付与します。
検索フィルタで使用される各属性タイプに対する検索権限を付与します。
エントリが確実に返されるようにエントリで使用される最低1つの属性タイプに対する読取り権限を付与します。
エントリで返される各属性タイプに対する読取り権限を付与します。
例6-3 検索を実行するためのACI権限の付与
次の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が適用されるユーザーのセットを特定します。ACIの権限とバインド・ルールの部分は、ペアで設定されます。ターゲットにアクセスするために指定される権限は、付随するバインド・ルールがtrueかfalseかによって、付与されるか拒否されるかが決定されます。
バインド・ルールの詳細は、次の項を参照してください。
バインド・ルールでは、次の方法を使用してユーザーのセットを特定します。
アクセス権が付与されるユーザー、グループおよびロール。
エンティティがバインドする必要がある場所。ユーザーが認証する場所は、偽装される可能性があり、信頼できません。ACIでは、これらの情報のみに依存にしないでください。
バインドを実行する必要がある時間または日付。
バインド時に使用する必要がある認証のタイプ。
単純なバインド・ルールでは、ディレクトリにアクセスするユーザーが特定のグループに属している昼用があります。複雑なバインド・ルールでは、ユーザーが特定のグループに属し、特定のIPアドレスのマシンから午前8時～午後5時にログインする必要があります。またバインド・ルールは、ブール演算子を使用して、これらの条件を組み合せた複雑な構造にできます。
サーバーは、3値ロジックに従って、ACIで使用される論理式を評価します。これは、RFC 4511 『Lightweight Directory Access Protocol (v3)』の第4.5.1.7項で説明されているLDAPフィルタの評価に使用されるものと類似しています。そのため、式の中の任意のコンポーネントが未定義と評価されると(たとえば、リソースの制限により、式の評価が中断された場合など)、サーバーはこの状況を正しく処理します。複雑なブール式で未定義の値が発生することでサーバーが誤ってアクセス権を付与することはありません。
ACIバインド・ルールには、次のような構文があります。
keyword = "expression";
または
keyword != "expression";
バインド・ルールでは次の値が使用されます。
バインド・ルールのタイプを示します。
バインド・ルールを特定します。
バインド・ルールのキーワードの詳細は、次の項を参照してください。
次の表に、バインド・ルールのキーワードの概要を示します。
表6-2 バインド・ルールのキーワードとその式
|
userdnキーワードを使用して、指定されたユーザーに対してアクセスを許可または拒否します。次の各項では、userdnキーワードに関する詳細な情報について説明します。
userdnキーワードでは、次の構文を使用します。
userdn = "ldap:///dn [|| ldap:///dn]..." userdn != "ldap:///dn [|| ldap:///dn]..."
また、userdnキーワードはLDAP URLフィルタとして表すこともできます。userdnキーワードをLDAP URLとして表す方法については、「userdnキーワード内のLDAP URL」を参照してください。
dnは、次の値を指定できます。
完全修飾されたDN。カンマなどのDNの文法的な意味を持つ文字は、単一の円記号(\)でエスケープする必要があります。ワイルドカード*は、ユーザーのセットの指定に使用できます。たとえば、次のユーザーDNが指定されている場合、文字bから始まるバインドDNを持つユーザーに対してアクセスが許可または拒否されます。
uid=b*,dc=example,dc=com
バインドの環境にかかわらず、匿名ユーザーおよび認証されたユーザーに対してアクセスを許可または拒否します。
このアクセスは、特定のアクセスのタイプ(たとえば、読取り用のアクセスや検索用のアクセスなど)に制限することも、ディレクトリ内の特定のサブツリーや個々のエントリに制限することもできます。dc=example,dc=comノード上の次のACIでは、匿名ユーザーにdc=example,dc=comツリー全体の読取りおよび検索を行うアクセスを許可しています。
aci: (version 3.0; acl "anonymous-read-search"; allow (read, search) userdn = "ldap:///anyone";)
認証されたユーザーに対してアクセスを許可または拒否します。このallの値は、匿名のアクセスは除かれます。dc=example,dc=comノード上の次のACIでは、認証されたユーザーにdc=example,dc=comツリー全体の読取りを許可しています。
aci: (version 3.0; acl "all-read"; allow (read) userdn="ldap:///all";)
バインドDNがターゲット・エントリのDNと一致した場合に、ユーザーに対して、そのユーザー自身のエントリへのアクセスを許可または拒否します。dc=example,dc=comノード上の次のACIでは、dc=example,dc=comツリー内の認証されたユーザーに対して、自身のuserPassword属性への書込みを許可しています。
aci: (targetattr = "userPassword") (version 3.0; acl "modify own password"; allow (write) userdn = "ldap:///self";)
バインドDNがターゲット・エントリの親である場合に、そのエントリへのユーザー・アクセスを許可または拒否します。
dc=example,dc=comノード上の次のACIでは、dc=example,dc=comツリー内の認証されたユーザーに対して、そのバインドDNの任意の子エントリの変更を許可します。
aci: (version 3.0; acl "parent access"; allow (write) userdn="ldap:///parent";)
また、userdnキーワードは、次の構文を使用して、フィルタ付きのLDAP URLとして表すこともできます。
userdn = ldap:///suffix??sub?(filter)
LDAP URLは、常にローカル・サーバーに適用されます。LDAP URL内でホスト名またはポート番号を指定しないでください。
dc=example,dc=comノード上の次のACIでは、example.comツリーのaccountingおよびengineeringブランチ内のすべてのユーザーに対して、次のURLに基づいて動的にターゲット・リソースへのアクセスを許可しています。
userdn = "ldap:///dc=example,dc=com??sub?(|(ou=eng)(ou=acct))"
LDAP URLは、次の例に示すように、論理OR演算子および不等演算子を使用できます。
例6-4 userdnキーワードでLDAP URLに論理OR演算子を使用する
このバインド・ルールは、指定されたDNパターンのいずれかでバインドされたユーザーに対して、trueと評価されます。
userdn = "ldap:///uid=b*,c=example.com || ldap:///cn=b*,dc=example,dc=com";
例6-5 userdnキーワードでLDAP URLに不等演算子を使用する
クライアントがaccountingサブツリー内UIDベースのDNとしてバインドしていない場合、このバインド・ルールはtrueと評価されます。このバインド・ルールは、ターゲット・エントリがディレクトリ・ツリーのaccountingブランチの下にない場合にのみ、意味を持ちます。
userdn != "ldap:///uid=*,ou=Accounting,dc=example,dc=com";
groupdnキーワードは、ユーザーが特定のグループに属するDNを使用してバインドをする場合、ターゲット・エントリへのアクセスを許可するか拒否するかを指定します。groupdnキーワードでは、次の構文を使用します。
groupdn="ldap:///groupDN [|| ldap:///groupDN]..."
バインドDNがgroupDNのいずれかの値で指定されたグループに属する場合、バインド・ルールはtrueと評価されます。
次の例では、バインドDNがAdministratorsグループに属する場合、バインド・ルールはtrueと評価されます。
aci: (version 3.0; acl "Administrators-write"; allow (write) groupdn="ldap:///cn=Administrators,dc=example,dc=com";)
カンマなどのDNの文法的な意味を持つ文字は、単一の円記号(\)でエスケープする必要があります。
rolednキーワードは、ユーザーが特定のロールに属するDNを使用してバインドする場合、ターゲット・エントリへのアクセスを許可するか拒否するかを指定します。rolednキーワードでは、1つ以上の有効な識別名を次の形式で指定する必要があります。
roledn = "ldap:///dn [|| ldap:///dn]... [|| ldap:///dn]"
バインドDNが指定されたロールに属する場合、バインド・ルールはtrueと評価されます。
カンマなどのDNの文法的な意味を持つ文字は、単一の円記号(\)でエスケープする必要があります。
rolednキーワードはgroupdnキーワードと同じ構文を持ち、使用方法も同様です。
userattrキーワードは、バインドに使用されていたエントリ内の属性値がターゲット・エントリのものと一致する必要があることを指定します。userattrキーワードは、次の属性に使用できます。
ユーザーDN
グループDN
ロールDN
LDAP URL内のLDAPフィルタ
任意の属性タイプ
サービス・クラス(CoS)定義で生成された属性は、userattrキーワードでは使用できません。CoSで生成された属性値に依存するバインド・ルールを含むACIは、機能しません。
userattrキーワードでは、次の構文を使用します。
userattr = "attrName#bindType"
また、ユーザーDN、グループDN、ロールDNまたはLDAPフィルタ以外の値が必要な属性タイプを使用する場合、userattrキーワードでは次の構文を使用します。
userattr = "attrName#attrValue"
userattrキーワードは、次のいずれかの値を持つことができます。
値のマッチングに使用される属性の名前
USERDN、GROUPDN、ROLEDN、LDAPURLのいずれかのバインドのタイプ
属性値を表す任意の文字列
例6-6 userattrキーワードとUSERDNバインド・タイプの使用方法
次に、ユーザーDNに基づいてバインドと関連付けられるuserattrキーワードの例を示します。
userattr = "manager#USERDN"
バインドDNがターゲット・エントリのmanager属性の値と一致する場合、バインド・ルールはtrueと評価されます。これを使用して、ユーザーのマネージャに対して従業員の属性の変更を許可できます。このメカニズムは、ターゲット・エントリのmanager属性が完全DNで表されている場合にのみ機能します。
次の例では、マネージャに対して部下のエントリへの完全なアクセス権を与えます。
aci: (target="ldap:///dc=example,dc=com")(targetattr="*") (version 3.0;acl "manager-write"; allow (all) userattr = "manager#USERDN";)
例6-7 userattrキーワードとGROUPDNバインド・タイプの使用方法
次に、グループDNに基づいてバインドと関連付けられるuserattrキーワードの例を示します。
userattr = "owner#GROUPDN"
バインドDNがターゲット・エントリのowner属性で指定されたグループのメンバーである場合、バインド・ルールはtrueと評価されます。たとえば、このメカニズムを使用して、あるグループに対して従業員のステータス情報の管理を許可できます。使用する属性にグループ・エントリのDNが含まれていれば、owner以外の属性を使用できます。
指定するグループは動的なグループにでき、グループのDNはディレクトリ内の任意の接尾辞の下にできます。ただし、サーバーによるこのタイプのACIの評価では、大量のリソースが消費されます。
ターゲット・エントリと同じ接尾辞の下の静的グループを使用する場合、次の式を使用できます。
userattr = "ldap:///dc=example,dc=com?owner#GROUPDN"
この例では、グループ・エントリはdc=example,dc=com接尾辞の下になります。サーバーは、この構文のタイプの方が前の例のものより高速に処理できます。
例6-8 userattrキーワードとROLEDNバインド・タイプの使用方法
次に、ロールDNに基づいてバインドと関連付けられるuserattrキーワードの例を示します。
userattr = "exampleEmployeeReportsTo#ROLEDN"
バインドDNがターゲット・エントリのexampleEmployeeReportsTo属性で指定されたロールに属する場合、バインド・ルールはtrueと評価されます。たとえば、会社のすべてのメンバーに対してネストされたロールを作成する場合、このメカニズムを使用して、すべてのレベルのマネージャに対して部下に関する情報へのアクセスを許可できます。
ロールのDNは、ディレクトリ内の任意の接尾辞の下にできます。また、フィルタ処理されたロールを使用する場合、このタイプのACIの評価には、サーバー上のリソースを大量に使用します。
例6-9 userattrキーワードとLDAPURLバインド・タイプの使用方法
次に、LDAPフィルタに基づいてバインドと関連付けられるuserattrキーワードの例を示します。
userattr = "myfilter#LDAPURL"
バインドDNがターゲット・エントリのmyfilter属性で指定されたフィルタと一致する場合、バインド・ルールはtrueと評価されます。myfilter属性は、LDAPフィルタを含む任意の属性で置き換えられます。
例6-10 userattrキーワードと任意の属性値の使用方法
次に、任意の属性値に基づいてバインドと関連付けられるuserattrキーワードの例を示します。
userattr = "favoriteDrink#Milk"
バインドDNとターゲットDNにMilkの値のfavoriteDrink属性が含まれる場合、バインド・ルールはtrueと評価されます。
userattrキーワードとparentキーワードを一緒に使用して、ACIを継承するターゲットの下のレベル数を指定できます。userattrキーワードとparentキーワードは、次の構文を使用します。
userattr = "parent[inheritance_level].attribute#bindType"
userattrキーワードとparentキーワードは、次の値を持つことができます。
ターゲットの下のレベル数を示すカンマ区切りリストは、ACIを継承する必要があります。このターゲット・エントリの下のレベルは、[0,1,2,3,4]のように指定できます。0は、ターゲット・エントリを示します。
userattrまたはgroupattrキーワードのターゲットとなる属性
バインドのタイプは、USERDNまたはGROUPDNを指定できます。LDAPURLおよびROLEDNバインドでは、継承を使用できません。
次の例は、継承にuserattrキーワードでparentキーワードを使用する方法を示します。
userattr = "parent[0,1].manager#USERDN"
bindDNがターゲット・エントリのmanager属性と一致する場合、このバインド・ルールはtrueと評価されます。バインド・ルールがtrueと評価されたときに付与される権限は、ターゲット・エントリとその直下のすべてのエントリに適用されます。
userattrキーワードをallまたはadd権限と組み合せて使用すると、サーバーの動作が想定どおりにならない場合があります。通常、新しいエントリがディレクトリに作成されると、Directory Serverは作成されるエントリのアクセス権を評価し、親エントリのアクセス権は評価しません。ただし、userattrキーワードを使用する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[0,1].manager#USERDN";)
このACIでは、バインドDNが親エントリのmanager属性と一致しているユーザーのみに追加権限が付与されます。
ipキーワードを使用して、特定のIPアドレスからバインド操作するように指定します。ipキーワードでは、次の構文を使用します。
ip = "IPaddressList" or ip != "IPaddressList"
IPaddressList値は、次のうち1つ以上のカンマ区切り要素のリストです。
特定のIPv4アドレス: 123.45.6.7
サブネットワークを指定するためのワイルドカードを含むIPv4アドレス: 12.3.45.*
サブネット・マスクを含むIPv4アドレスまたはサブネットワーク: 123.45.6.*, 255.255.255.0
RFC 2373で定義される、大カッコ[と]で囲んだ任意の有効な形式のIPv6アドレス。
次の2つのアドレスは同等です。
12AB:0000:0000:CD30:0000:0000:0000:0000
12AB::CD30:0:0:0:0
12AB:0:0:CD30::
サブネット接頭辞長を含むIPv6アドレス: 12AB::CD30:0:0:0:0/60
ディレクトリにアクセスするクライアントが指定されたIPアドレスに位置している場合、バインド・ルールはtrueと評価されます。
ipキーワードを使用して、特定のマシンまたはネットワーク・ドメインから強制的にすべてのディレクトリの更新を実行できます。ただし、ユーザーが認証するIPアドレスはスプーフィングされる可能性があるため、信頼できません。ACIでは、これらの情報のみに依存にしないでください。
ワイルドカード*を使用して、IPアドレスのセットを指定できます。
ワイルドカード*は、IPv6アドレスには使用できません。
注意: dnsキーワードを使用する場合、マシンで使用されるネーミング・サービスはDNSである必要があります。ネーミング・サービスがDNSでない場合、かわりにipキーワードを使用する必要があります。
dnsキーワードを使用して、特定のドメインまたはホスト・マシンからバインド操作するように指定します。dnsキーワードでは、次の構文を使用します。
dns = "DNS_Hostname" or dns != "DNS_Hostname"
dnsキーワードには、完全修飾DNSドメイン名が必要です。ドメインを指定せずにホストへのアクセスを許可すると、セキュリティの脅威がもたらされる可能性があります。たとえば、次の式は使用できますが、お薦めできません。
dns = "legend.eng";
次のような完全修飾名を使用する必要があります。
dns = "legend.eng.example.com";
dnsキーワードでは、ワイルドカードを使用できます。
dns = "*.example.com";
ディレクトリにアクセスするクライアントが指定されたドメインに位置している場合、バインド・ルールはtrueと評価されます。これは、特定のドメインからのアクセスのみを許可する場合に役立ちます。システムでDNS以外のネーミング・サービスを使用している場合、ワイルドカードは機能しません。
timeofdayキーワードを使用して、特定の時間にアクセスできることを指定します。timeofdayおよびdayofweekバインド・ルールの評価には、サーバー上の日付と時刻が使用されます(クライアント上の日時ではありません)。timeofdayキーワードでは、次の構文を使用します。
timeofday operator "time"
timeofdayキーワードは、次のいずれかの値を持つことができます。
等しい(=)
等しくない(!=)
以上(>=)
より小さい(<)
以下(<=)
24時間法で時と分を表す4桁の数字(0～2359)
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になります。
dayofweekキーワードを使用して、特定の曜日にアクセスできることを示します。timeofdayおよびdayofweekバインド・ルールの評価には、サーバー上の日付と時刻が使用されます(クライアント上の日時ではありません)。dayofweekキーワードでは、次の構文を使用します。
dayofweek = "day1, day2 ..."
リストされているいずれかの曜日にディレクトリにアクセスする場合、バインド・ルールはtrueになります。
dayofweekキーワードは、sun、mon、tue、wed、thu、fri、satのうち1つ以上の値を持つことができます。
authmethodキーワードを使用して、クライアントが特定の認証方式を使用してディレクトリにバインドする必要があることを指定します。authmethodキーワードでは、次の構文を使用します。
authmethod = "authentication_method"
authmethodキーワードは、次の値を持つことができます。
バインド・ルールの評価時に、認証はチェックされません。これはデフォルト設定です。
クライアントがユーザー名とパスワードを使用してディレクトリにアクセスする場合、このバインド・ルールはtrueと評価されます。
クライアントは、Secure Sockets Layer(SSL)またはTransport Layer Security(TLS)接続でディレクトリにバインドする必要があります。
クライアントがLDAPSで証明書を使用してディレクトリに対して認証する場合、バインド・ルールはtrueと評価されます。クライアントがLDAPSで簡易認証(バインドDNとパスワード)を使用して認証する場合、trueにはなりません。
クライアントがDIGEST-MD5、GSSAPIまたはEXTERNALのいずれかのSASLメカニズムを使用してディレクトリに対して認証する場合、バインド・ルールはtrueと評価されます。
バインド・ルールは、ブール式AND、ORおよびNOTを使用する複合式とし、細かいアクセス・ルールを設定できます。ブール・バインド・ルールでは、次の構文を使用します。
(bindRuleA and (bindRuleB or (bindRuleC and bindRuleD));)
カッコにより、ルールを評価する順序を定義します。最後のルールの後にセミコロンを付ける必要があります。
例6-11 ブール・バインド・ルール
次の2つの条件が満たされる場合、バインド・ルールはtrueになります。
バインドDNクライアントが、example.comドメイン内からアクセスされている
バインドDNクライアントがadministratorsグループのメンバーであるか、あるいはmail administratorsとcalendar administratorsグループの両方のメンバーである
(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"));)
$ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - -c dn: cn=config changetype: modify add: aci aci: (targetattr="*")(version 3.0; acl "Allow the Suffix Manager to browse the tree"; \ allow (read,search,compare)userdn = "ldap:///$USERSFXADMIN";) aci: (targetattr="nsslapd-rootpw")\ (version 3.0; acl "Prevent the Suffix Manager from accessing passwords"; \ deny (all)userdn = "ldap:///$USERSFXADMIN";) aci: (targetattr="userPassword")\ (version 3.0; acl "Prevent the Suffix Manager from accessing passwords"; \ deny (all)userdn = "ldap:///$USERSFXADMIN";) aci: (targetattr="dsKeyedPassword")\ (version 3.0; acl "Prevent the Suffix Manager from accessing passwords"; \ deny (all)userdn = "ldap:///$USERSFXADMIN";)
dsutilコマンドの詳細は、「dsutil(1M)」を参照してください。
 
|