| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
前 |
次 |
ディレクトリに対するアクセス制御は、セキュアなディレクトリを構築するうえで不可欠な部分です。この章では、ディレクトリにアクセスするユーザーに対し、どのような権限を付与するかを決定するアクセス制御命令(ACI)について説明します。
ディレクトリ・デプロイメントの計画段階では、全体的なセキュリティ・ポリシーを提供するアクセス制御戦略を定義します。アクセス制御戦略の計画のヒントは、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』を参照してください。
ACI構文やバインド・ルールなど、ACIの追加情報は、Oracle Directory Server Enterprise Editionのリファレンスを参照してください。
この章の内容は、次のとおりです。
ACIを作成するには、Directory Service Control Center(DSCC)を使用するか、コマンドラインを使用します。どちらの方法を選択するにしても、一般的には最初から新しいACIを作成するより、既存のACI値を表示してコピーしたほうが簡単です。
DSCCではaci属性値を表示および変更できます。DSCCを介したACIの変更方法は、DSCCのオンライン・ヘルプを参照してください。
コマンドラインを使用してACIを作成するには、まずファイルの中でLDIF文を使用してACIを作成します。その後、ldapmodifyコマンドを使用して、ACIをディレクトリ・ツリーに追加します。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
LDIFファイルにACIを作成します。
dn: dc=example,dc=com
changetype: modify
add: aci
aci: (target)(version 3.0; acl "name";permission bindrules;)
次の例は、ACIの追加方法を示します。ACIを変更または削除するには、addをreplaceまたはdeleteに置き換えます。
一般的に使用されるACIの例は、「アクセス制御の使用例」を参照してください。
LDIFファイルを使用して変更を行います。
$ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - -f ldif-file
ACIは、エントリのaci属性の1つ以上の値として保存されます。aci属性は、ディレクトリ・ユーザーが読取りおよび変更できる複数値操作属性です。そのため、ACI属性自身がACIで保護される必要があります。通常、管理ユーザーには、aci属性への完全アクセス権が付与されます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
次のldapsearchコマンドを実行して、エントリのACI属性値を表示します。
$ 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によって、デフォルト管理ユーザーname="DirAdminDN" content="cn=admin,cn=Administrators,cn=config"は、ディレクトリ・マネージャと同じディレクトリ・データへのアクセス権を持つことができます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
デフォルトのルート・レベルACIを表示します。
$ 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 ターゲット・キーワードとその式
| キーワード | ターゲットのタイプ | 式 |
|---|---|---|
|
|
ディレクトリ・エントリまたはそのサブツリー |
ldap:///distinguished_name |
|
|
エントリの属性 |
attribute |
|
|
LDAPフィルタとマッチングするエントリまたは属性のセット |
LDAP_filter |
|
|
LDAPフィルタとマッチングする属性値または値の組合せ |
LDAP_operation:LDAP_filter |
|
|
ターゲットの範囲 |
|
targetキーワード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キーワードtargetattrキーワードは、ターゲット・エントリの1つ以上の属性に対してACIが定義されることを示します。targetattrキーワードでは、次の構文を使用します。
(targetattr = "attribute")
または
(targetattr != "attribute")
targetattrキーワードがない場合、属性はターゲットになりません。すべての属性をターゲットにするには、targetattrキーワードをtargetattr="*"と指定する必要があります。
ターゲット属性は、ターゲット・エントリまたはそのサブツリー内に存在する必要はありませんが、存在すればACIが適用されます。
ターゲット属性は、スキーマで定義されている必要はありません。スキーマ・チェックを行わないことにより、データとそのスキーマをインポートする前にアクセス制御ポリシーを実装できます。
次の構文を使用して、複数の属性を対象にtargetattrキーワードを使用できます。
(targetattr = "attribute1||attribute2||... attributeN")
|
注意: 属性別名を構成する場合、属性名と |
ターゲット属性には、指定された属性のすべてのサブタイプが含まれます。たとえば、(targetattr = "locality")はlocality;lang-frもターゲットになります。
targetattrキーワードの式でワイルドカードを使用できますが、意味はなく、パフォーマンスが低下するのみです。
targetfilterキーワード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キーワードtargattrfiltersキーワードは、LDAPフィルタを使用することで特定の属性値をターゲットとするACIで使用されます。targattrfiltersキーワードを使用することで、属性値がACIで定義された条件を満たすときに属性に対する権限を許可または拒否できます。属性の値に基づいてアクセス権を付与または拒否するACIは、値ベースACIと呼ばれています。targattrfiltersキーワードでは、次の構文を使用します。
(targattrfilters="add=attr1:F1 && attr2:F2... && attrn:Fn, \ del=attr1:F1 && attr2:F2 ... && attrn:Fn")
説明:
add属性を作成する操作を示します。
del属性を削除する操作を示します。
attrnターゲット属性を示します。
Fn関連付けられた属性のみに適用するフィルタを示します。
フィルタをエントリに適用して、それらのエントリを作成、削除または変更する場合に、次の条件を満たす必要があります。
エントリを作成または削除する場合、その属性の各インスタンスはフィルタを満たす必要があります。
エントリを変更する際に、その操作で属性を追加する場合、その属性に適用される追加フィルタが満たされる必要があります。その操作で属性を削除する場合、その属性に適用する削除フィルタが満たされる必要があります。
エントリ内にすでに存在する属性の各値が置き換えられる場合、追加および削除フィルタが満たされる必要があります。
targetscopeキーワードtargetscopeキーワードは、ACIの範囲を指定するACIで使用されます。targetscopeキーワードでは、次の構文を使用します。
(targetscope="base")
targetscopeキーワードは、次のいずれかの値を持ちます。
baseACIは、ターゲット・リソースのみに適用されます。
onelevelACIは、ターゲット・リソースとその第1世代の子に適用されます。
subtreeACIは、ターゲット・リソースとそのサブツリーに適用されます。
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キーワードを使用して制限することもできます。
属性タイプに対する書込み権限を付与します。
エントリに対する書込み権限の評価によって、すべてのエントリへのtargetattr指定が緩和されることに注意してください。したがって、エントリ全体へ適用されるルールを拒否します。
各属性タイプの値に対する書込み権限を付与します。この権限はデフォルトで付与されますが、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では、これらの情報のみに依存にしないでください。
バインドを実行する必要がある時間または日付。
バインド時に使用する必要がある認証のタイプ。
単純なバインド・ルールでは、ディレクトリにアクセスするユーザーが特定のグループに属している昼用があります。複雑なバインド・ルールでは、ユーザーが特定のグループに属し、午前8時から午後5時の間に特定のIPアドレスのマシンからログインする必要があります。またバインド・ルールは、ブール演算子を使用して、これらの条件を組み合せた複雑な構造にできます。
サーバーは、3値ロジックに従って、ACIで使用される論理式を評価します。これは、RFC 4511 『Lightweight Directory Access Protocol (v3)』の第4.5.1.7項で説明されているLDAPフィルタの評価に使用されるものと類似しています。そのため、式の中の任意のコンポーネントが未定義と評価されると(たとえば、リソースの制限により、式の評価が中断された場合など)、サーバーはこの状況を正しく処理します。複雑なブール式で未定義の値が発生することでサーバーが誤ってアクセス権を付与することはありません。
ACIバインド・ルールには、次のような構文があります。
keyword = "expression";
または
keyword != "expression";
バインド・ルールでは次の値が使用されます。
バインド・ルールのタイプを示します。
バインド・ルールを特定します。
バインド・ルールのキーワードの詳細は、次の項を参照してください。
次の表に、バインド・ルールのキーワードの概要を示します。
表6-2 バインド・ルールのキーワードとその式
| キーワード | アクセス権を定義するベース | 式 |
|---|---|---|
|
|
指定されたユーザー |
ldap:///distinguished_name ldap:///all ldap:///anyone ldap:///self ldap:///parent ldap:///suffix??sub?(filter) |
|
|
指定されたグループ |
|
|
|
指定されたロール |
|
|
|
一致した属性値 |
attribute#bindType または attribute#value |
|
|
指定されたIPアドレス |
IP_address |
|
|
指定されたドメイン |
DNS_host_name |
|
|
指定された時刻 |
0 - 2359 |
|
|
指定された曜日 |
|
|
|
指定された認証方式 |
|
userdnキーワードuserdnキーワードを使用して、指定されたユーザーに対してアクセスを許可または拒否します。次の各項では、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
anyoneバインドの環境にかかわらず、匿名ユーザーおよび認証されたユーザーに対してアクセスを許可または拒否します。
このアクセスは、特定のアクセスのタイプ(たとえば、読取り用のアクセスや検索用のアクセスなど)に制限することも、ディレクトリ内の特定のサブツリーや個々のエントリに制限することもできます。dc=example,dc=comノード上の次のACIでは、匿名ユーザーにdc=example,dc=comツリー全体の読取りおよび検索を行うアクセスを許可しています。
aci: (version 3.0; acl "anonymous-read-search"; allow (read, search) userdn = "ldap:///anyone";)
all認証されたユーザーに対してアクセスを許可または拒否します。このallの値は、匿名のアクセスは除かれます。dc=example,dc=comノード上の次のACIでは、認証されたユーザーにdc=example,dc=comツリー全体の読取りを許可しています。
aci: (version 3.0; acl "all-read"; allow (read) userdn="ldap:///all";)
selfバインド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";)
parentバインド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 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演算子および不等演算子を使用できます。
groupdnキーワード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キーワードrolednキーワードは、ユーザーが特定のロールに属するDNを使用してバインドする場合、ターゲット・エントリへのアクセスを許可するか拒否するかを指定します。rolednキーワードでは、1つ以上の有効な識別名を次の形式で指定する必要があります。
roledn = "ldap:///dn [|| ldap:///dn]... [|| ldap:///dn]"
バインドDNが指定されたロールに属する場合、バインド・ルールはtrueと評価されます。
カンマなどのDNの文法的な意味を持つ文字は、単一の円記号(\)でエスケープする必要があります。
rolednキーワードはgroupdnキーワードと同じ構文を持ち、使用方法も同様です。
userattrキーワード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のいずれかのバインドのタイプ
属性値を表す任意の文字列
userattrキーワードと各種バインド・タイプの例例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の評価には、サーバー上のリソースを大量に使用します。
userattrキーワードとparentキーワードの使用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キーワードを使用した追加権限の付与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キーワードでは、次の構文を使用します。
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 (http://www.ietf.org/rfc/rfc2373.txt)で定義される、大カッコ[と]で囲んだ正規の形式の任意の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キーワードでは、次の構文を使用します。
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キーワードを使用して、特定の時間にアクセスできることを指定します。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キーワードdayofweekキーワードを使用して、特定の曜日にアクセスできることを示します。timeofdayおよびdayofweekバインド・ルールの評価には、サーバー上の日付と時刻が使用されます(クライアント上の日時ではありません)。dayofweekキーワードでは、次の構文を使用します。
dayofweek = "day1, day2 ..."
リストされているいずれかの曜日にディレクトリにアクセスする場合、バインド・ルールはtrueになります。
dayofweekキーワードは、sun、mon、tue、wed、thu、fri、satのうち1つ以上の値を持つことができます。
authmethodキーワード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"));)
dsutilコマンドを使用して通常ユーザーにユーザー・アカウントを管理させるには次のACIを追加すると、ユーザーはdsutilコマンドを使用して他のユーザー・アカウントを管理できます。
$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を参照してください。
この項の例では、架空のISP会社Example.comが会社のアクセス制御ポリシーを実装する様子を示します。
またACIの例は、インストールinstall_path/resources/ldif/Example.ldifに用意されているサンプルのLDIFファイルの中にもあります。
すべてのサンプルでは、LDIFファイルを使用して特定のタスクを実行する方法を説明しています。次の図は、example.comのディレクトリ情報ツリーをグラフィカルに示したものです。
Example.comでは、Webホスティング・サービスおよびインターネット・アクセスを提供します。Example.comのWebホスティング・サービスの一部では、クライアント企業のディレクトリをホストします。Example.comは、Company333とCompany999という2つの中規模企業のディレクトリを実際にホストし、部分的に管理しています。Example.comは、多数の個人サブスクライバにインターネット・アクセスも提供しています。
Example.comは、次のアクセス・ルールを設定しようとしています。
Example.comの従業員に対して、Example.comツリー全体に対する匿名の読取り、検索および比較アクセスを許可する。「匿名アクセスの許可」を参照してください。
Example.comの従業員に対して、homeTelephoneNumberやhomeAddressなどの個人情報への書込みアクセスを許可する。「個人エントリへの書込みアクセスの許可」を参照してください。
Example.comサブスクライバに対して、エントリdc=example,dc=comの企業問合せ情報を読み取る権限を付与する(その下のエントリは読めない)。「特定のレベルへのアクセス権の付与」を参照してください。
Example.comの従業員に対して、特定の重要なロール以外の任意のロールを自身のエントリに追加する権限を付与する。「キー・ロールへのアクセス権の制限」を参照してください。
特定の管理者に対して、接尾辞のディレクトリ・マネージャと同じ権限を付与する。「ロールに対する接尾辞全体への完全アクセスの許可」を参照してください。
Peopleブランチのエントリに対するすべての権限をExample.comのHuman Resourcesグループに付与する。「グループに対する接尾辞への完全アクセスの許可」を参照してください。
Example.comの全従業員に対して、ディレクトリのSocial Committeeブランチの下にグループ・エントリを作成する権限、および従業員が所有するグループ・エントリを削除する権限を付与する。「グループ・エントリを追加および削除する権限の付与」を参照してください。
Example.comの全従業員に対して、ディレクトリのSocial Committeeブランチの下のグループ・エントリに自身を追加する権限を付与する。「ユーザーに対する自身のグループへの追加またはグループからの削除の許可」を参照してください。
Company333およびCompany999のディレクトリ管理者(ロール)に対して、一定の条件の下でディレクトリ・ツリーのそれぞれのブランチへのアクセスを許可する。これらの条件には、SSL認証、日時の制約および指定された場所が含まれます。「グループまたはロールへの条件付きアクセスの許可」を参照してください。
個人サブスクライバに対して、自身のエントリへのアクセスを許可する。「個人エントリへの書込みアクセスの許可」を参照してください。
個人サブスクライバに対して、自身のエントリの課金情報へのアクセスを拒否する。「アクセスの拒否」を参照してください。
特に非公開を希望するサブスクライバを除く世界中のユーザーに対して、個人サブスクライバ・サブツリーへの匿名アクセスを許可する。必要に応じて、このディレクトリの部分はファイアウォールの外側で読取り専用にして、1日に一度更新できます。「匿名アクセスの許可」および「フィルタを使用したターゲットの設定」を参照してください。
多くのディレクトリは、少なくとも1つの接尾辞に匿名アクセスで読取り、検索、または比較できるように構成されています。社員が検索できる電話帳のような、企業内の個人情報を収めたディレクトリを管理している場合、そのためのアクセス権の設定が必要になることがあります。これは、Example.com社内のケースで、「ACI "Anonymous Example.com"」で説明されています。
また、Example.comはISPとして世界中からアクセス可能な公開電話帳を作成して、すべてのサブスクライバの連絡先情報を公開することも考えています。これについては、「ACI "Anonymous World"」に説明があります。
Example.comの従業員に対してExample.comツリー全体の読取り、検索および比較権限を付与するには、LDIFで次の文を記述します。
aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous example"; allow (read, search, compare) userdn= "ldap:///anyone") ;)
この例では、aciがdc=example,dc=com entryに追加されることを前提としています。userPassword属性は、ACIの範囲に含まれていません。
|
注意: パスワード属性を保護するサンプルで使用された構文 |
世界中のユーザーに対して個人サブスクライバ・サブツリーへの読取りおよび検索アクセスを許可し、公開しないサブスクライバの情報へのアクセスを拒否するには、LDIFで次の文を記述します。
aci: (targetfilter= "(!(unlistedSubscriber=yes))") (targetattr="homePostalAddress || homePhone || mail") (version 3.0; acl "Anonymous World"; allow (read, search) userdn="ldap:///anyone";)
この例では、ACIがou=subscribers,dc=example, dc=comエントリに追加されることを前提としています。また、それぞれのサブスクライバ・エントリに、yesまたはnoの値を持つunlistedSubscriber属性が設定されていることを前提としています。ターゲット定義により、この属性の値に基づいて、公開しないサブスクライバが除外されます。フィルタ定義の詳細は、「フィルタを使用したターゲットの設定」を参照してください。
多くのディレクトリ管理者は、内部ユーザーに対して、ユーザー自身のエントリの属性のすべてではなく、一部の変更のみを許可します。Example.comのディレクトリ管理者は、ユーザー自身のパスワード、自宅の電話番号、自宅の住所の変更のみを各ユーザーに許可します。これについては、「ACI "Write Example.com"」に説明があります。
またExample.comには、サブスクライバがディレクトリに対してSSL接続を確立した場合に、Example.comツリー内の自身の個人情報を更新できるポリシーもあります。これについては、「ACI "Write Subscribers"」に説明があります。
|
注意: この権限を設定すると、ユーザーに属性値を削除する権限も付与することになります。 |
Example.comの従業員に対して、自身の電話番号および自宅の住所を更新する権限を付与するには、LDIFで次の文を記述します。
aci: (targetattr="homePhone || homePostalAddress")(version 3.0; acl "Write Example.com"; allow (write) userdn="ldap:///self" ;)
この例では、ACIがou=People,dc=example,dc=comエントリに追加されることを前提としています。
|
注意: この権限を設定すると、ユーザーに属性値を削除する権限も付与することになります。 |
Example.comのサブスクライバに対して、自身の電話番号を更新する権限を付与するには、LDIFで次の文を記述します。
aci: (targetattr="homePhone") (version 3.0; acl "Write Subscribers"; allow (write) userdn= "ldap://self" and authmethod="ssl";)
この例では、ou=subscribers,dc=example, dc=comエントリにaciが追加され、ユーザーはSSLを使用してバインドする必要があることを前提としています。
Example.comのサブスクライバは、自宅の住所への書込みアクセス権はありません(その属性を削除できてしまうため)。自宅の住所は、Example.comが請求の目的で必要となる、ビジネスの上で重要な情報です。
ディレクトリ・ツリー内で各種レベルに作用するACIの範囲を設定して、許可するアクセスのレベルを微調整できます。ターゲットACIの範囲は、次のいずれかに設定できます。
baseエントリ自体
onelevelエントリ自体と1レベル下のすべてのエントリ
subtreeエントリ自体とそのエントリの下のすべてのエントリ(深さは無制限)
Example.comサブスクライバに対して、会社の連絡先情報についてのエントリdc=example,dc=comの読取り権限は与えても、それより下のエントリへのアクセスを拒否するには、LDIFで次の文を記述します。
aci: (targetscope="base") (targetattr="*")(version 3.0; acl "Read Example.com only"; allow (read,search,compare) userdn="ldap:///cn=*,ou=subscribers,dc=example,dc=com";)
この例では、ACIがdc=example,dc=com entryエントリに追加されることを前提としています。
ディレクトリ内のロール定義を使用して、ネットワークおよびディレクトリの管理など、ビジネスに重要な機能を特定できます。
たとえば、世界規模の企業サイトで特定の曜日の特定の時間に対応できるシステム管理者のサブセットを特定して、superAdminロールを作成できます。または、特定の場所で応急処置訓練を受けたすべてのスタッフ・メンバーを含むFirst Aidロールを作成できます。ロール定義の作成の詳細は、「ロールの管理」を参照してください。
ロールによって、業務上あるいはビジネス上重要な機能に関するユーザー特権を与える場合は、そのロールに対するアクセス制限を考慮してください。たとえば、次の例に示すように、Example.comの従業員はsuperAdmin以外の任意のロールを自身のエントリに追加できます。
Example.com従業員に対して、superAdmin以外の任意のロールを自身のエントリに追加する権限を付与するには、LDIFで次の文を記述します。
aci: (targetattr="*") (targattrfilters="add=nsRoleDN: (nsRoleDN !="cn=superAdmin, dc=example, dc=com")") (version 3.0; acl "Roles"; allow (write) userdn= "ldap:///self" ;)
この例では、ACIがou=People,dc=example,dc=comエントリに追加されることを前提としています。
特定のユーザーに、接尾辞に対してディレクトリ・マネージャと同じ権限を付与すると、便利な場合があります。Example.comで、Kirsten VaughanはDirectory Serverの管理者です。彼女にはsuperAdminのロールがあります。このロールには、次の利点があります。
管理者としてバインドし、SSLのような強力な認証を強制的に使用できることによって、セキュリティが向上する
ディレクトリ・マネージャのパスワードを知るユーザーを少数に抑えられるため、セキュリティが向上する
ロギングによりトレーサビリティが向上する
|
注意: Kirsten Vaughanを |
サーバー全体に対して、ユーザーにディレクトリ・マネージャと同じ権限を付与する場合、「ルート・アクセス権を持つ管理ユーザーを作成するには:」の手順に従ってください。
管理者Kirsten Vaughanにディレクトリ・マネージャと同じ権限を付与するには、LDIFで次の文を使用します。
aci: (targetattr="*") (version 3.0; acl "Full Access"; allow (all) groupdn= "ldap:///cn=SuperAdmin,dc=example,dc=com" and authmethod="ssl" ;)
この例では、ACIがルート・エントリ"" (テキストなし)に追加されることを前提としています。
多くのディレクトリには、固有の業務機能の特定するためのグループがあります。グループにディレクトリの全体または一部へのアクセス権を付与できます。グループにアクセス権を適用することで、メンバーに個別にアクセス権を設定せずにすみます。かわりにグループにメンバーを追加することで、ユーザーにアクセス権を付与します。
たとえば、Directory Serverインスタンスを作成する場合、ディレクトリへの完全なアクセス権を持つAdministratorsグループcn=Administrators,cn=configがデフォルトで作成されます。
Example.comのHuman Resourcesグループは、ディレクトリのou=Peopleブランチへの完全なアクセスが許可され、このグループのメンバーは、「ACI "HR"」に示すように、従業員ディレクトリを更新できます。
HRグループに対して、ディレクトリのemployeeブランチへのすべての権限を付与するには、LDIFで次の文を使用します。
aci: (targetattr="*") (version 3.0; acl "HR"; allow (all) groupdn= "ldap:///cn=HRgroup,ou=Groups,dc=example,dc=com";)
この例では、ACIが次のエントリに追加されることを前提としています。
ou=People,dc=example,dc=com
一部の組織では、従業員にツリー内のエントリの作成を許可し、従業員の効率を向上させ、従業員にコーポレート・ダイナミクスへの貢献を促します。たとえばExample.comでは、社会委員会に、テニス、水泳、スキー、ロールプレイなど様々なクラブが編成されています。
Example.comのすべての従業員は、「ACI "Create Group"」に示すように、新しいクラブを表すグループ・エントリを作成できます。
Example.comの従業員はだれでも、「ユーザーに対するグループへの自身の追加または削除の許可」に示すように、これらのいずれかのグループのメンバーになれます。
「ACI "Delete Group"」に示すように、グループ所有者のみがグループ・エントリを変更または削除できます。
Example.comの従業員に対して、ou=Social Committeeブランチの下にグループ・エントリを作成する権限を付与するには、LDIFで次の文を記述します。
aci: (targetattr="*") (targattrfilters="add=objectClass: (|(objectClass=groupOfNames)(objectClass=top))") (version 3.0; acl "Create Group"; allow (read,search,add) userdn= "ldap:///uid=*,ou=People,dc=example,dc=com") and dns="*.Example.com";)
この例では、ACIがou=Social Committee,dc=example,dc=comエントリに追加されることを前提としています。
|
注意:
|
Example.comの従業員に対して、ou=Social Committeeブランチの下の、自身が属するグループのグループ・エントリを変更または削除する権限を付与するには、LDIFで次の文を記述します。
aci: (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エントリに追加されることを前提としています。
DSCCを使用してこれを作成するのはあまり効率的ではありません。手動の編集モードを使用してターゲット・フィルタを作成し、さらにグループの所有権をチェックする必要があります。
多くのディレクトリでは、ユーザーに対してメーリング・リストなどのグループへのユーザー自身の追加またはここからの削除を許可するACIを設定しています。
Example.comでは、従業員はou=Social Committeeサブツリーの下の任意のグループ・エントリに自身を追加できます(「ACI "Group Members"」を参照)。
Example.comの従業員に対して、自身をグループに追加する権限を付与するには、LDIFで次の文を記述します。
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エントリに追加されることを前提としています。
多くの場合、グループまたはロールにディレクトリへのアクセス権を付与する際に、正しい権限を持つユーザーを偽装しようとする侵入者からこれらの権限を確実に保護する必要があります。そのため、グループまたはロールに重要なアクセスを許可するアクセス制御ルールには、たいてい多くの条件が関連付けられます。
たとえばExample.comでは、ホストしている企業Company333とCompany999のそれぞれにDirectory Administratorロールを作成しています。Example.comでは、これらの企業が自身のデータを管理し、自身のアクセス制御ルールを実装できるようにする一方、侵入者からデータを保護する必要があると考えています。
そのため、次の条件を満たしていれば、Company333とCompany999はディレクトリ・ツリーのそれぞれのブランチに対する完全な権限が付与されます。
証明書を使用して、SSL経由の接続が認証されること。
月曜から木曜の8:00から18:00の間にアクセスがリクエストされること。
各会社の指定されたIPアドレスからアクセスがリクエストされること。
これらの条件は、各会社のACI (ACI "Company333"およびACI "Company999")で示されています。両方のACIの内容は同じであるため、次の例では"Company333" ACIのみを使用します。
Company333に対して、前述の条件の下でディレクトリの自身のブランチへの完全なアクセス権を付与するには、LDIFで次の文を記述します。
aci: (targetattr = "*") (version 3.0; acl "Company333"; allow (all) (roledn="ldap:///cn=DirectoryAdmin,ou=Company333, ou=corporate clients,dc=example,dc=com") and (authmethod="ssl") and (dayofweek="Mon,Tues,Wed,Thu") and (timeofday>= "0800" and timeofday <= "1800") and (ip="255.255.123.234"); )
この例では、ACIがou=Company333,ou=corporate clients,dc=example,dc=comエントリに追加されることを前提としています。
接尾辞の大部分にアクセスをすでに許可している場合、既存のACIの下で接尾辞の一部へのアクセスを拒否できます。
|
注意: アクセスを拒否すると、アクセス制御の動作が予期しない、または複雑なものになる可能性があるため、可能であれば避けてください。アクセスは、範囲、属性リスト、ターゲット・フィルタなどを組み合せて制限します。 また、アクセス拒否ACIを削除しても、権限が削除されるのではなく、他のACIで設定された権限が拡大されます。 |
Directory Serverでアクセス権を評価する場合、最初にdeny権限を読み取り、次にallow権限を読み取ります。
次の例で、Example.comは、すべてのサブスクライバが自身のエントリの下で接続時間やアカウント残高などの課金情報を確認できるようにしたいと考えています。また、その情報への書込みアクセスについては明示的に拒否したいと考えています。readアクセスについては、「ACI "Billing Info Read"」に説明があります。denyアクセスについては、「ACI "Billing Info Deny"」に説明があります。
サブスクライバに対して、自身のエントリの課金情報を読み取る権限を付与するには、LDIFで次の文を記述します。
aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Read"; allow (search,read) userdn="ldap:///self";)
この例では、関連の属性がスキーマに作成されており、ACIがou=subscribers,dc=example,dc=comエントリに追加されることを前提としています。
サブスクライバに対して、自身のエントリの課金情報を変更する権限を拒否するには、LDIFで次の文を記述します。
aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Deny"; deny (write) userdn="ldap:///self";)
この例では、関連の属性がスキーマに作成されており、ACIがou=subscribers,dc=example,dc=comエントリに追加されることを前提としています。
プロキシ認可方式は、認証の特殊な形式です。自身のIDを使用してディレクトリにバインドするユーザーは、プロキシ認可により別のユーザーの権限が付与されます。
プロキシ・リクエストを許可するようにDirectory Serverを構成するには、次を実行する必要があります。
管理者に別のユーザーとしてのプロキシ権限を付与する。
一般ユーザーに対して、アクセス制御ポリシーで定義される通常のアクセス権を付与する。
|
注意: プロキシ権限は、ディレクトリ・マネージャを除くディレクトリの任意のユーザーに付与できます。また、ディレクトリ・マネージャのDNはプロキシDNとして使用できません。プロキシ権限を付与する際は、(ディレクトリ・マネージャDNを除く)任意のDNをプロキシDNとして指定する権限を付与することになるため、細心の注意を払う必要があります。Directory Serverが同一の操作で複数のプロキシ認証の制御を受けた場合、クライアント・アプリケーションにエラーが返され、操作の試行は失敗します。 |
Example.comでは、MoneyWizAcctSoftwareとしてバインドするクライアント・アプリケーションに、LDAPデータに対してAccounting Administratorと同じアクセス権を与えたいと考えています。
次のパラメータが適用されます。
クライアント・アプリケーションのバインド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: (targetattr="*") (version 3.0; acl "allowAll-AcctAdmin"; allow (all) userdn="ldap:///uid=AcctAdministrator,ou=Administrators, dc=example,dc=com";)
クライアント・アプリケーションに対してプロキシ権限を付与する次のACIは、ディレクトリ内に存在する必要がある。
aci: (targetattr="*") (version 3.0; acl "allowproxy- accountingsoftware"; allow (proxy) 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" -w - \ -Y "dn: uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" ...
クライアントがldapmodifyコマンドを実行する場合、そのコマンドには次のような制御が含まれます。
$ ldapmodify -h hostname -p port \ -D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" -w - \ -Y"dn: uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" dn: uid=AcctAdministrator,ou=Administrators,dc=example,dc=com changetype: modify delete: userpassword - add: userpassword userpassword: admin1
クライアントは自身としてバインドしますが、プロキシ・エントリの権限が付与されます。クライアントには、プロキシ・エントリのパスワードは不要です。
ディレクトリ全体にわたる多数のエントリへのアクセスを許可するアクセス制御を設定する場合、フィルタを使用してターゲットを設定できます。
フィルタを使用して、HRのすべてのユーザーに従業員エントリへのアクセスを許可するには、LDIFで次の文を記述します。
aci: (targetattr="*") (targetfilter=(objectClass=employee)) (version 3.0; acl "HR access to employees"; allow (all) groupdn= "ldap:///cn=HRgroup,ou=People,dc=example,dc=com";)
この例では、ACIがou=People,dc=example,dc=comエントリに追加されることを前提としています。
|
注意: 検索フィルタは、アクセス管理の対象となるオブジェクトを直接指定するわけではないので、誤ったオブジェクトへのアクセスを許可または拒否しないようにしてください。ディレクトリ構造が複雑になるほど、誤ったオブジェクトへのアクセスを許可または拒否してしまうリスクが大きくなります。さらに、フィルタによって、ディレクトリ内のアクセス制御に関する問題の解決が難しくなる場合もあります。 |
DNにカンマが含まれている場合、LDIF ACI文の中で特別な処理が必要です。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.";)
ディレクトリのエントリのアクセス・ポリシーを管理する場合、定義したACIのセキュリティへの影響を把握する必要があります。Directory Serverでは、ACIで特定のエントリ上の特定のユーザーに付与した実効権限を確認して、既存のACIを評価できます。
Directory Serverは、検索操作に含めることができる「実効権限取得」制御に応答します。この制御に対するレスポンスは、検索結果のエントリおよび属性に関する実効権限情報を返すことです。この追加情報としては、各エントリとその中の各属性に対する読取り権限および書込み権限などがあります。検索に使用されるバインドDNや任意のDNでは権限をリクエストできます。これを選択することで、管理者はディレクトリ・ユーザーの権限をテストできます。
実効権限の機能は、LDAP制御に依存します。リモート・サーバーとのバインドに使用されるプロキシ・アイデンティティにも、実効権限属性へのアクセスを許可する必要があります。
実効権限を表示する操作は、保護されていることおよび適切に制限されていることが必要なディレクトリ操作になります。
実効権限情報へのアクセスを制限するには、getEffectiveRights属性のデフォルトACIを変更します。その後、getEffectiveRightsInfo属性の新しいACIを作成します。
たとえば次のACIは、Directory Administratorsグループのメンバーのみに実効権限の取得を許可しています。
aci: (targetattr != "aci")(version 3.0; acl "getEffectiveRights"; allow(all) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)
実効権限情報を取得するには、実効権限制御を使用するアクセス制御権限およびaclRights属性の読取りアクセス権が必要です。このような二重の層のアクセス制御により、基本的なセキュリティを必要に応じて微調整できます。プロキシと同様に、エントリのaclRights属性への読取りアクセス権があれば、任意のユーザーのエントリとその属性に対する権限に関する情報をリクエストできます。つまり、リソースを管理するユーザーは、誰がそのリソースに対する権限を持っているかを特定できます。これは、そのユーザーが実際にはその権限を使用してリソースを管理していない場合も同様です。
権限情報をリクエストしているユーザーに実効権限制御を使用する権限がない場合、操作は失敗し、エラー・メッセージが返されます。ただし、権限情報をリクエストしているユーザーに制御を使用する権限はあってもaclRights属性を読み取る権限がない場合、返されるエントリの中にaclRights属性はありません。この動作は、Directory Serverの通常の検索動作を反映しています。
実効権限取得制御を指定するには、ldapsearchコマンドで-J "1.3.6.1.4.1.42.2.27.9.5.2"オプションを使用します。デフォルトでは、検索結果でエントリとその属性に対するバインドDNエントリの実効権限が返されます。
次のオプションを使用して、デフォルトの動作を変更します。
-c "dn: bind DN " — 検索結果には、指定されたDNにバインドされているユーザーの実効権限が示されます。管理者は、このオプションを使用して他のユーザーの実効権限をチェックできます。オプション-c "dn:"を指定すると、匿名認証に対する実効権限が表示されます。
-X "attributeName ... " — 検索結果に、指定された属性に対する実効権限も含まれます。このオプションを使用して、検索結果にない属性を指定します。たとえば、このオプションを使用して、エントリ内に現在存在しない属性を追加する権限をユーザーが持つかどうかを特定できます。
-cオプションまたは-Xオプションまたはその両方を使用する場合、-Jオプションに実効権限取得制御のOIDが暗黙的に指定されるため、このオプションを指定する必要はありません。実効権限制御でNULL値を指定すると、現在のユーザーの権限が取得されます。また、現在のldapsearch操作で返される属性およびエントリに対する権限も取得されます。
その後、表示する情報のタイプを選択する必要があります。権限のみを表示するか、権限がどのように許可または拒否されているかを示す詳細なロギング情報を表示するか、いずれかを選択します。情報のタイプは、検索結果で返す属性として、aclRightsまたはaclRightsInfoをそれぞれ追加することで特定します。両方の属性をリクエストすると、実行権限の情報をすべて取得できます。ただし、単純な権限情報は基本的には詳細なロギング情報の写しです。
|
注意:
このため、これらの属性を、フィルタやなんらかの検索操作に使用することはできません。 |
実効権限機能は、アクセス制御に影響するその他のパラメータを継承します。これらのパラメータには、時刻、認証方式、マシンのアドレスおよび名前が含まれます。
次の例は、Carla Fuenteというユーザーがディレクトリ内の自身の権限を表示する方法を示します。その結果において、1は権限が付与されていること、0は権限が拒否されていることを意味します。
$ ldapsearch -J "1.3.6.1.4.1.42.2.27.9.5.2" -h host1.Example.com -p 389 \ -D "uid=cfuente,ou=People,dc=example,dc=com" -w - -b "dc=example,dc=com" \ "(objectclass=*)" aclRights Enter bind password: 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 host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \ -c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \ "(objectclass=*)" aclRights Enter bind password: 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 host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \
-c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \
"(uid=cfuente)" aclRights "*"
Enter bind password:
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
同じようなディレクトリ・ツリー構造を持つ組織では、マクロによってディレクトリ内で使用するACIの数を最適化できます。ディレクトリ・ツリー内のACIの数を減らすことによって、アクセス制御ポリシーの管理が簡単になります。また、ACIによるメモリー使用の効率も向上します。
マクロは、ACIの中でDN、またはDNの一部を表現するために使用されるプレースホルダです。マクロを使用すると、ACIのターゲット部分またはバインド・ルール部分、あるいはその両方のDNを表せます。実際の処理では、Directory ServerがLDAP操作を受け取ると、LDAP操作のターゲットとなるリソースに対してACIマクロのマッチングが行われます。このマッチングは、一致する部分文字列の存在を確認するために行われます。一致が検出された場合は、一致した部分文字列を使用してバインド・ルール側のマクロが展開され、その展開バインド・ルールを評価してリソースへのアクセス権が決定されます。
この項では、マクロACIの例とマクロACIの構文について説明します。
マクロACIの利点と最も効果的に機能させる方法を、例を示しながら説明します。図6-1は、全体的なACIの数を減らすために、マクロACIを効果的に利用しているディレクトリ・ツリーです。
この例では、同じツリー構造のサブドメインが同じパターンで繰り返されています(ou=groups,ou=people)。Example.comディレクトリ・ツリーには、dc=hostedCompany2,dc=example,dc=comおよびdc=hostedCompany3,dc=example,dc=comという2つの接尾辞が格納されているので、このパターンはツリー内でも繰り返されています。ただし、図には示されていません。
ディレクトリ・ツリーにあるACIでも、同じパターンが繰り返されています。たとえば、次の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=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ノード上に置かれています。
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";)
前述の個々のACIでは使用されていなかったtargetキーワードをここでは新たに使用していることに注意してください。
この例では、ACIの数が4つから1つに減っています。ただし、本当の利点はそれのみではなく、ディレクトリ・ツリー全体で複数繰り返されているパターンをまとめられるところにあります。
ここでは、わかりやすくするために、userdn、roledn、groupdn、userattrなどのバインド資格証明を与えるために使用されるACIキーワードをまとめて、サブジェクトと呼びます。サブジェクトは、ACIの適用対象を決定します。
次の表に、特定のACIキーワードの置換に使用できるマクロを示します。
表6-3 マクロACIキーワード
| マクロ | 説明 | ACIキーワード |
|---|---|---|
|
|
targetでマッチング要素として使用されます。サブジェクト内では、実際に($dn)と一致した文字列に置き換えられます。 |
|
|
|
サブジェクトのサブツリー内で機能する複数のRDNに置き換えられます。 |
|
|
|
ターゲット・エントリのattributeName属性に設定されている値に置き換えられて、サブジェクトに設定されます。 |
|
マクロACIキーワードには、次のような制限が適用されます。
サブジェクトで($dn)マクロや[$dn]マクロを使用するときは、($dn)マクロを含むtargetを定義する必要があります。
サブジェクトで($attr.attrName)マクロと($dn)マクロを組み合せることはできますが、[$dn]マクロと組み合せることはできません。
($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)はこの部分文字列に置き換えられます。
($dn)の置換ACIのサブジェクト内では、($dn)マクロはターゲット内で一致する部分文字列全体に置き換えられます。次に例を示します。
groupdn="ldap:///cn=DomainAdmins,ou=Groups,($dn),dc=example,dc=com"
サブジェクトは次のようになります。
groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com"
マクロが展開されると、通常のプロセスに続いて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)に対するマクロのマッチング($attr.attrname)マクロは、常にDNのサブジェクト部分で使用されます。たとえば、次のようなrolednを定義できます。
roledn = "ldap:///cn=DomainAdmins,($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のroledn部分を評価するために、サーバーはターゲット・エントリに格納されているou属性の値を読み取ります。その後、サブジェクト内でこの値を置換してマクロを展開します。この例では、rolednは次のように展開されます。
roledn = "ldap:///cn=DomainAdmins,ou=Sales,dc=HostedCompany1,dc=example,dc=com"
続いて、通常のACI評価アルゴリズムに従って、Directory ServerがACIを評価します。
マクロ内で指定された属性が複数の値を持つ場合は、それぞれの値を使用して順にマクロが展開されます。最初にマッチングに成功した値が使用されます。
エラー・ログでアクセス制御についての情報を取得するには、適切なログ・レベルを設定する必要があります。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
ACI処理を考慮するよう、ログ・レベルを設定します。
$ dsconf set-log-prop -h host -p port error level:err-acl
接続がTCPレベルで受け入れまたは拒否されるホストやIPアドレスは、TCPラッパーを使用して制御できます。TCPラップにより、クライアント・ホストのアクセスを制限できます。これにより、Directory Serverへの初期TCP接続に対して、ホストベースではない保護が可能になります。
Directory Serverに対するTCPラップ設定も可能ですが、TCPラップは、特にサービス拒否攻撃の際に、パフォーマンスを著しく低下させる可能性があります。最良のパフォーマンスは、Directory Serverの外部で保守されるホストベースのファイアウォールを使用するか、IPポートのフィルタリングによって得られます。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
インスタンス・パス内の任意の場所に、hosts.allowファイルまたはhosts.denyファイルを作成します。
たとえば、instance-path/configにファイルを作成します。作成するファイルの形式は必ずhosts_accessに準拠させてください。
アクセス・ファイルのパスを設定します。
$ dsconf set-server-prop -h host -p port host-access-dir-path:path-to-file
次に例を示します。
$ dsconf set-server-prop -h host -p port \ host-access-dir-path:/local/ds1/config "host-access-dir-path" property has been set to "/local/ds1/config". The "/local/ds1/config" directory on host1 must contain valid hosts.allow and/or hosts.deny files. Directory Server must be restarted for changes to take effect.
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
ホストのアクセス・パスを""に設定します。
$ dsconf set-server-prop -h host -p port host-access-dir-path:""
