第 6 章アクセス制御の管理

安全なディレクトリを作成する上で、ディレクトリの内容へのアクセスを制御することは最も重要です。この章では、ディレクトリに対してどのようなアクセス権をユーザーに許可するかを決定する ACI (アクセス制御命令) について説明します。Directory Server には、特定のユーザーが特定のエントリに対して持っている実効権限を表示する機能があります。この機能を使用すると、複雑で強力なアクセス制御メカニズムを簡単に管理できます。

ディレクトリ導入の計画段階では、全体的なセキュリティポリシーとして利用できるアクセス制御戦略を定義する必要があります。アクセス制御戦略を計画するためのヒントについては、『Directory Server 配備計画ガイド』の第 7 章にある「アクセス制御の設計」を参照してください。

アクセス制御の原則

アクセスを定義するためのメカニズムをアクセス制御と呼びます。サーバーが要求を受け取ると、バインド操作でユーザーが提供する認証情報、およびサーバー内で定義されたACI (アクセス制御命令) を使用して、ディレクトリ情報へのアクセスが許可または拒否されます。サーバーは、読み取り、書き込み、検索、比較などのアクセス権を許可または拒否できます。ユーザーに与えられるアクセス権のレベルは、そのユーザーの認証情報によって決まります。

アクセス制御を使用すると、ディレクトリ全体、ディレクトリのサブツリー、ディレクトリ内の特定エントリ (設定タスクを定義するエントリを含む)、エントリ属性の特別なセット、特定エントリの属性値などに対するアクセスを制御できます。アクセス権は、特定ユーザー、特定のグループまたはロールに属するすべてのユーザー、またはそのディレクトリのすべてのユーザーに対して設定できます。また、IP アドレスや DNS 名などによって特定されるクライアントに対してもアクセス権を定義できます。

ACI の構造

ACI は、エントリの属性としてディレクトリ内に格納されます。aci 属性はオペレーショナル属性です。この属性は、そのエントリのオブジェクトクラス用に定義されたものであるかどうかにかかわらず、ディレクトリ内のすべてのエントリで使用できます。aci 属性は、Directory Server がクライアントから LDAP 要求を受け取るときに、どのアクセス権が与えられ、どのアクセス権が拒否されるかを判定するために使用されます。aci 属性が ldapsearch 処理で返されるように指定することができます。

ターゲット - 権限が適用されるエントリまたは属性を決定します。

権限 - 許可または拒否される処理を定義します。

バインドルール - バインド DN に基づいて、ACI の対象を定義します。

ACI のアクセス権およびバインドルール部分はペアで設定され、ACR (アクセス制御規則) とも呼ばれます。指定されたターゲットにアクセスする権限が与えられるか拒否されるかは、これに付随するルールが true であると判定されるかどうかによって決まります。詳細は、「ACI の構文」を参照してください。

ACI の配置

ACI を含むエントリが子エントリを持たない場合は、ACI はそのエントリだけに適用されます。そのエントリが子エントリを持つ場合は、ACI はそのエントリと、そのエントリよりも下位にあるすべてのエントリに適用されます。したがって、サーバーがエントリに対するアクセス権を評価するときは、要求されたエントリとルートサフィックスのベースの間にあるすべてのエントリの ACI を確認します。

aci 属性には複数の値を設定できます。つまり、同じエントリまたは同じサブツリーに対して、複数の ACI を定義できます。

あるエントリに対して ACI を設定する場合は、そのエントリ自体には ACI を適用せず、そのエントリの下位にある一部またはすべてのエントリに対してだけ適用するように定義することもできます。このように ACI を定義すると、ディレクトリツリーの高いレベルに汎用的な ACI を置き、ツリーの下位に置かれる可能性の高いエントリに対してこの ACI を効果的に適用できます。たとえば、organizationalUnit エントリまたは locality エントリのレベルで、inetorgperson オブジェクトクラスを含むエントリをターゲットとする ACI を作成できます。

この機能を使用すると、汎用的な規則を分岐点のできるだけ高いレベルに置くことによって、ディレクトリツリー内の ACI の数を最小限にできます。より限定的な規則の適用範囲を制限するには、できるだけ最下位のエントリに近い位置にその規則を置きます。

ACI の評価

特定のエントリに対するアクセス権限を評価する場合は、サーバーによって、そのエントリ上と、エントリのルートサフィックスのベースにバックアップされる親エントリの ACI のリストが作成されます。評価中に、この順番でサーバーにより ACI が処理されます。ACI は、エントリとそのルートサフィックスのベースの間にあるすべてのサフィックスとサブサフィックスで評価され、他のサーバー上の連鎖サフィックスでは評価されません。


注	ルート DSE エントリ ("" という DN を持ちます) に置かれた ACI は、そのエントリだけに適用されます。


注	Directory Manager は、アクセス制御の制限を受けない権限を持つ唯一のユーザーです。クライアントが Directory Manager としてディレクトリにバインドされると、サーバーは処理の実行前に ACI を評価しません。このため、Directory Manager としての LDAP 操作は、他のユーザーによる操作とは異なる結果を生じます。ディレクトリのパフォーマンスをテストするときは、常に一般的なユーザーとして実行する必要があります。

デフォルトでは、エントリにどの ACI も適用されない場合、Directory Manager 以外のすべてのユーザーはアクセスを拒否されます。ユーザーがサーバー上のエントリにアクセスするには、ACI によってアクセスが明示的に許可されている必要があります。デフォルト ACI は匿名の読み取りアクセス権を定義し、ユーザーによる各自のエントリの修正を許可します。ただし、セキュリティに必要な属性を変更することはできません。詳細は、「デフォルト ACI」を参照してください。

サーバーは、ターゲットエントリに最も近い ACI から処理を開始しますが、エントリに適用されるすべての ACI が有効です。いずれかの ACI によって許可されるアクセスは、他の ACI が拒否しない場合に限り有効です。アクセスを拒否する ACI は、リストに含まれているかどうかに関係なく、同じリソースへのアクセスを許可する ACI に優先して適用されます。

たとえば、ディレクトリのルートレベルで書き込みアクセス権を拒否すると、ユーザーに特定のアクセス権を与えても、どのユーザーもディレクトリに書き込めなくなります。特定ユーザーにそのディレクトリへの書き込みアクセス権を与えるには、書き込みアクセス権の元の拒否対象を制限し、書き込みアクセス権を付与するユーザーを除外しておく必要があります。

ACI の制限事項

ディレクトリサービスに対するアクセス制御ポリシーを決定するときは、次の制限事項に注意してください。

ディレクトリツリーが連鎖機能によって複数のサーバー上に分散されている場合は、アクセス制御文で使用できるキーワードにいくつかの制約が適用されます。

グループエントリ (groupdn キーワード) に依存する ACI は、グループエントリと同じサーバー上に置く必要がある。ダイナミックグループである場合は、そのメンバーすべても同じサーバー上にエントリを持つ必要がある。スタティックグループである場合は、リモートサーバー上にメンバーのエントリを置くことができる

ロール定義 (roledn キーワード) に依存する ACI は、ロール定義エントリと同じサーバー上に置く必要がある。ロールを持たせる予定のエントリも、すべて同じサーバー上に置く必要がある

CoS によって作成された属性を、すべての ACI キーワードで使用できるとは限りません。特に、アクセス制御規則が機能しないため、userattr および userdnattr キーワードによって CoS で作成した属性を使用しないこと。詳細については、「userattr キーワードの使用」を参照してください。CoS については、第 5 章「ID とロールの管理」を参照してください。

アクセス制御規則の評価は、常にローカルサーバー上で行われるます。このため、ACI キーワードで使用される LDAP URL で、サーバーのホスト名やポート番号を指定してはならない。指定しても、LDAP URL は無視されます。詳細については、『Directory Server Administration Reference』の第 10 章「LDAP URL Reference」を参照してください。

プロキシ権限を与える場合、ユーザーに Directory Manager となるプロキシ権限を与えたり、Directory Manager にプロキシ権限を与えたりすることはできません。

デフォルト ACI

Directory Server をインストールすると、設定時に指定したルートサフィックスに次のデフォルト ACI が定義されます。

すべてのユーザーは、ディレクトリに匿名でアクセスして、検索、比較、および読み取り操作を行うことができる (userpassword 属性を除く)。

バインドユーザーは、ディレクトリ内にある個人のエントリを変更できるが、削除はできない。aci、nsroledn、および passwordPolicySubentry 属性を変更することはできず、各自のリソース制限属性、パスワードポリシー状態属性、アカウントロックアウト状態属性を変更することもできない

構成管理者 (デフォルトでは uid=admin,ou=Administrators, ou=TopologyManagement,o=NetscapeRoot) には、プロキシ権限以外のすべての権限が与えられる

設定管理者グループのすべてのメンバーには、プロキシ権限以外のすべての権限が与えられる

ディレクトリ管理者グループのすべてのメンバーには、プロキシ権限以外のすべての権限が与えられる

SIE グループのすべてのメンバーには、プロキシ権限以外のすべての権限が与えられる。SIE グループは、管理サーバー内の、このディレクトリのサーバーグループの管理者グループである。

ディレクトリに新しいルートサフィックスを作成するたびに、ベースエントリに自己変更 ACI を除く上記デフォルト ACI が設定されます。セキュリティを強化するには、「コンソールを使用した新しいルートサフィックスの作成」で説明している方法でこの ACI を追加します。

管理サーバー用の NetscapeRoot サブツリーには、専用のデフォルト ACI が置かれます。

構成管理者グループのすべてのメンバーには、プロキシ権限以外のすべての NetscapeRoot サブツリーでの権限が与えられる。これにより、このメンバーは設定管理者グループに新しいメンバーを追加できる

すべてのユーザーは NetscapeRoot サブツリーに匿名でアクセスして、検索および読み取り操作を行うことができる

グループ拡張 ACI は、管理グループのメンバーにグループ定義へのアクセスを許可する

次の節では、ユーザーの必要に応じてこれらのデフォルト設定を変更する方法を説明します。

ACI の構文

ACI は、バリエーションに富む複雑な構造をしています。ACI の作成と変更にコンソールを使うか、コマンド行を使うかに関係なく、LDIF 内の ACI の構文を理解しておくことは重要です。次の各項では、ACI の構文について詳細に説明します。


ヒント	ACI はたいへん複雑であるため、Directory Server コンソールはすべての ACI の視覚的な編集には対応していません。ただし、多数のディレクトリエントリに対してアクセス制御を設定する場合は、コマンド行を使用するよりも時間を大幅に短縮できます。このため、効果的なアクセス制御が設定されたソースディレクトリを作成するには、ACI の構文を理解することが重要になります。

target は、アクセス制御の対象となるエントリ、属性、またはエントリと属性のセットを指定する。ターゲットには、識別名、1 つ以上の属性、または 1 つの LDAP フィルタを指定できる。ターゲットは省略できる。ターゲットを指定しないときは、そのエントリに定義されている ACI がエントリ全体とその子に対して適用される

version 3.0 は、ACI バージョンの識別に必要な文字列

name は、ACI の名前。名前には、ACI を識別する任意の文字列を適用できる。ACI の名前は必須であり、その ACI の機能を説明するものが望ましい。



ヒント	名前の付け方に制約はありませんが、ACI には一意の名前を付けることをお勧めします。一意の名前を使用すれば、実行権限の取得制御によって適用される ACI を決定することができます。

permission は、許可または拒否する権限 (読み取り権限や検索権限など) を指定する

bindRules は、ユーザーがアクセス権を許可されるために必要な資格およびバインドパラメータを指定する。バインドルールは、ユーザーまたはグループのメンバーシップ、またはクライアントの接続プロパティに基づいて指定することもできる

複数のターゲットと、権限とバインドルールのペアを利用できます。これにより、対象となるエントリと属性の両方を詳細に指定し、特定のターゲットに対して複数のアクセス制御を効率的に設定できます。たとえば、次のようにします。

この ACI では、bjensen というユーザーに対して、自身のディレクトリ内にあるすべての属性を変更できる書き込み権限を与えています。

ターゲットの定義

ターゲットは、ACI の適用対象を指定します。クライアントがエントリに含まれる属性に対する処理を要求すると、サーバーはターゲットを評価し、その処理の許可または拒否のために ACI の評価が必要であるかどうかを確認します。ターゲットを指定しないと、ACI は aci 属性を含むエントリ内のすべての属性、およびその下位のエントリに適用されます。

keyword は、ターゲットのタイプを示す。表 6-1 のキーワードによって、次のタイプのターゲットが定義される

ディレクトリエントリ、またはそのサブツリー

エントリの属性

LDAP フィルタと一致するエントリまたは属性のセット

LDAP フィルタと一致する属性値、または値の組み合わせ

等号 (=) は、ターゲットが expression で指定されたオブジェクトであることを示し、不等号 (!=) は、ターゲットが expression で指定されたオブジェクトではないことを示す。



注	「不等号」の演算子は targattrfilters キーワードに対してはサポートされていません。

expression はキーワードに依存し、ターゲットを識別する。expression を囲む引用符 ("") は、構文上必要ですが、現在の実装では、targetattr=* などの表現も受け入れられています。ただし、将来的なバージョンにおいて構文検査がより厳密になる可能性があるため、常に引用符を使用する必要があります。

表 6-1 LDIF ターゲットキーワード
キーワード	有効な式	ワイルドカード使用
ターゲット	ldap:///distinguished_name	可
targetattr	属性	可
targetfilter	LDAP_filter	可
targattrfilters	LDAP_operation:LDAP_filter	可

ディレクトリエントリのターゲット指定

特定のディレクトリ、およびその下のエントリを指定するときは、target キーワードと、LDAP URL に含まれる DN を使います。ターゲット DN は、ACI が定義されるエントリの下のサブツリーに指定する必要があります。ターゲットは、次の構文で表記されます。

識別名は、ACI が定義されるエントリをルートとするサブツリーに指定する必要があります。たとえば、ou=People,dc=example,dc=com の ACI では、次のターゲットを使用します。

DN にワイルドカードを使用して、LDAP URL と一致する複数のエントリをターゲットにすることもできます。次に、ワイルドカードの正しい使用例を示します。


注	エントリの DN は、文字列で表された識別名である必要があります。(RFC 2253)。したがって、dn に対して構文上有意な文字 (コンマなど) は、1 つの円記号 (¥) を使用してエスケープする必要があります。たとえば、次のようにします。 (target="ldap:///uid=cfuentes,o=Example Bolivia¥, S.A.")

(target="ldap:///uid=*,dc=example,dc=com")

(target="ldap:///uid=*Anderson,ou=People,dc=example,dc=com")

ou=People 分岐内で、uid が Anderson で終わるすべてのエントリと一致します。

(target="ldap:///*Anderson,ou=People,dc=example,dc=com")

ou=People 内で、ネーミング属性に関係なく RDN が Anderson で終わるすべてのエントリと一致します。

uid=*,ou=*,dc=example,dc=com のように、複数のワイルドカードを使用できます。この例は、識別名に uid と ou の属性を含む、example.com ツリーのすべてのエントリと一致します。

属性のターゲット指定

ディレクトリエントリをターゲットとして指定できるだけでなく、ターゲットとして指定したエントリに含まれる 1 つ以上の属性 (または、1 つ以上の属性を除くすべての属性) をターゲットとすることもできます。これは、エントリに関する部分的な情報へのアクセスを許可または拒否するときに便利です。たとえば、あるエントリの共通名、名字、および電話番号の属性に限ってアクセスを限定できます。あるいは、個人データなど、取り扱いに注意を要する情報へのアクセスを一括して拒否することもできます。


注	識別名のサフィックス部分には、ワイルドカードを使用できません。つまり、ディレクトリのサフィックスが c=US と c=GB である場合に、両方のサフィックスを参照させる次のようなターゲットは使用できません。 (target="ldap:///dc=example,c=") また、uid=bjensen,o=.com のようなターゲットも使用できません。

targetattr 規則が存在しない場合は、デフォルトでは属性にアクセスできません。すべての属性にアクセスするには、targetattr="*" 規則を使用する必要があります。

ターゲットエントリ、またはそのサブツリーにターゲット属性が存在する必要はありません。ただし、指定されている ACI は常に適用されます。ターゲット属性は、スキーマで定義されている必要はありません。スキーマ検査が行われなければ、データとスキーマをインポートする前にアクセス制御ポリシーを実装できます。

属性をターゲットとして指定するには、targetattr キーワードを使用して、属性名を指定します。targetattr キーワードの構文は次のとおりです。

targetattr キーワードにより、複数の属性をターゲットとして指定できます。構文は次のとおりです。

たとえば、エントリの共通名、名字、および uid 属性をターゲットとして指定するには、次のように入力します。

ターゲットに指定された属性には、名前が付けられた属性のすべてのサブタイプが含まれます。たとえば、(targetattr = "locality") と指定すると、locality;lang-fr もターゲットに指定できます。また、(targetattr = "locality;lang-fr-ca") のように、サブタイプをターゲットに指定することもできます。

targetattr 規則ではワイルドカードを使用できますが、特に意義はなく、またパフォーマンスに悪影響を及ぼす可能性があるため、使用しないことをお勧めします。

属性とエントリ両方によるターゲット指定

デフォルトでは、targetattr キーワードを含む ACI のターゲットに指定されたエントリに ACI が置かれます。

という ACI を ou=Marketing、dc=example,dc=com エントリに置いた場合は、ACI は Marketing サブツリー全体に適用されます。ただし、次のように target キーワードを使用して、ターゲットを明示的に指定することもできます。

target および targetattr キーワードを指定する順番は、特に重要ではありません。

LDAP フィルタを使用したエントリまたは属性のターゲット指定

LDAP フィルタを使用して、一定の基準に一致するエントリのセットをターゲットとして指定できます。このためには、LDAP フィルタとともに targetfilter キーワードを使用する必要があります。ACI を含むエントリの下のサブツリーに含まれるフィルタと一致するすべてのエントリに ACI が適用されます。

ここで、LDAPfilter は、標準的な LDAP 検索フィルタです。フィルタ構文については、「LDAP 検索フィルタ」を参照してください。

たとえば、従業員を表すすべてのエントリに、正社員または契約社員の状態と、勤務時間数の全就業時間に対する割合を表す属性が設定されているとします。契約社員またはパート社員を表すすべてのエントリをターゲットとして指定するには、次のフィルタを使用できます。


注	ACI では、国際化値のマッチングルールに対応したフィルタ構文はサポートされていません。たとえば、次のターゲットフィルタは指定できません。 (targetfilter = "(locality:fr:=<= Quebec)")

ターゲットフィルタでは、ACI のターゲットとしてエントリ全体が選択されます。targetfilter キーワードおよび targetattr キーワードを組み合わせて、ターゲットエントリの属性のサブセットに適用される ACI を作成できます。

次の例に示す LDIF では、Engineering Admins グループのメンバーは、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 操作で同じフィルタを使用して、適切なエントリと属性がターゲットとして指定されていることを確認する必要があります。

LDAP フィルタを使用した属性値のターゲット指定

アクセス制御を使用すると、特定の属性値をターゲットとして指定できます。つまり、属性値と ACI 内で定義された基準が一致する場合は、その属性に対するアクセス権を許可または拒否できます。属性値に基づいてアクセスを許可または拒否する ACI は、値に基づく ACI と呼ばれます。

たとえば、組織内のすべてのユーザーに、ユーザー自身のエントリ内の nsRoleDN 属性を変更できるアクセス権を与えるとします。ただし、同時に、これらのユーザーが、自身に対して「最上位レベルの管理者」のような重要なロールを割り当てることができないようにします。LDAP フィルタは、このような場合に属性値の条件が満たされているかどうかを確認するために使用されます。

値に基づく ACI を作成するには、targattrfilters キーワードを使用する必要があります。構文は次のとおりです。

add は、属性を作成する操作を示す

del は、属性を削除する操作を示す

attrn は、ターゲットの属性を示す

Fn は、対応する属性だけに適用されるフィルタを示す

エントリを作成するときに、新しいエントリ内の属性に対してフィルタを適用する場合は、その属性の各インスタンスはすべてフィルタの条件を満たす必要があります。エントリを削除するときに、エントリ内の属性に対してフィルタを適用する場合も、その属性の各インスタンスはすべてフィルタの条件を満たす必要があります。

エントリを変更するときに、属性を追加する場合は、その属性に適用される追加フィルタの条件を満たす必要があります。属性を削除する場合は、その属性に適用される削除フィルタの条件を満たす必要があります。すでにエントリ内にある属性の個々の値を置き換える場合は、追加フィルタと削除フィルタの両方の条件を満たす必要があります。

このフィルタを使用すると、ユーザーは、個人のエントリに superAdmin 以外の任意のロール (nsRoleDN 属性) を追加できます。また、先頭に 123 が付く電話番号を追加することもできます。

単一のディレクトリエントリのターゲット指定

単一のエントリを明示的にターゲットとすることはできません。ただし、次の方法で指定することは可能です。


注	Directory Server コンソールを使用して値に基づく ACI を作成することはできません。

ターゲットエントリ内に格納された属性値を使用して、バインド要求時のユーザー入力に一致するバインドルールを作成する。詳細は、「値マッチングに基づくアクセスの定義」を参照してください。

targetfilter キーワードを使用する

targetfilter キーワードを使うことで、目的のエントリだけに含まれる属性値を指定できます。たとえば、Directory Server をインストールすると、次の ACI が作成されます。

o 属性の値が NetscapeRoot のエントリは o=NetscapeRoot だけなので、ACI はこのエントリだけに適用されます。

これらの方法に関する問題点は、今後ディレクトリツリーを変更するときに、この ACI の変更が必要なことを憶えておき、手動で変更しなければならないことです。

マクロを使用したターゲットの定義

マクロを使用すると、ACI のターゲット部分の DN を表すことができます。これによってディレクトリ内で使用されている ACI の数が最適化されます。詳細は、「高度なアクセス制御: マクロ ACI の使用」を参照してください。

アクセス権の定義

アクセス権は、許可または拒否するアクセスのタイプを指定します。ディレクトリ内で特定の操作を実行するためのアクセス権を許可または拒否できます。割り当てることのできる各操作は、アクセス権と呼ばれます。

アクセスの許可または拒否

権限の割り当て

アクセスの許可または拒否

ディレクトリツリーに対するアクセス権は、明示的に許可または拒否できます。いつアクセスを許可し、いつアクセスを拒否するかについて、詳しいガイドラインは『Directory Server 配備計画ガイド』の第 7 章にある「アクセス制御の設計」を参照してください。

権限の割り当て

権限は、ディレクトリデータに対してユーザーが実行できる特定の操作を詳細に定義します。すべての権限を許可または拒否するか、次に示す 1 つ以上の権限を割り当てることができます。

読み取り : ユーザーがディレクトリデータを読み込めるかどうかを示します。このアクセス権は、検索操作だけに適用されます。

書き込み : ユーザーが属性を追加、変更、または削除することによって、エントリを変更できるかどうかを示します。このアクセス権は、変更および modrdn 操作に適用されます。

追加 : ユーザーがエントリを追加できるかどうかを示します。このアクセス権は、追加操作だけに適用されます。

削除 : ユーザーがエントリを削除できるかどうかを示します。このアクセス権は、削除操作だけに適用されます。

検索 : ユーザーがディレクトリデータを検索できるかどうかを示します。ユーザーが検索結果の一部として返されたデータを参照するには、検索権限および読み取り権限が必要です。このアクセス権は、検索操作だけに適用されます。

比較 : ユーザーが入力したデータと、ディレクトリに格納されているデータを比較できるかどうかを示します。比較権限を持っている場合は、照会に対して成功または失敗を示すメッセージが返されますが、エントリまたは属性の値を表示することはできません。このアクセス権は、比較操作だけに適用されます。

本人による書き込み : ユーザーが、ターゲットエントリの属性に含まれる本人の DN を追加または削除できるかどうかを示します。この属性の構文は「識別名」である必要があります。このアクセス権は、グループ管理専用です。Selfwrite (本人による書き込み) は、プロキシ承認で使用できます。グループエントリからプロキシ DN を追加または削除するアクセス権を与えます (バインドユーザーの DN とは異なる)。

プロキシ承認 : 指定された DN が、他のエントリの権限でターゲットにアクセスできるかどうかを示します。Directory Manager DN を除く、ディレクトリ内の任意のユーザーの DN を使用して、プロキシ権限を与えることができます。なお、Directory Manager には、プロキシ権限を与えることはできません。参考例については、「プロキシ承認を使用した ACI の例」を参照してください。

すべて : 指定された DN が、ターゲットエントリに対して、プロキシ権限以外のすべての権限 (読み取り、書き込み、検索、削除、比較、本人による書き込み) を持つことを示します。

これらの権限は個別に与えられます。たとえば、追加権限を与えられたユーザーがエントリを作成しても、そのユーザーに削除権限が与えられていなければ、そのエントリを削除できません。したがって、ディレクトリのアクセス制御ポリシーを決定するときは、ユーザーに対して理にかなった権限を与える必要があります。たとえば、読み取りおよび検索アクセス権を与えずに書き込みアクセス権だけを与えても、通常は意味がありません。

LDAP 操作に必要な権限

この節では、ユーザーに許可する LDAP 操作のタイプに応じて、そのユーザーに与える必要がある権限について説明します。

追加されるエントリに対する追加アクセス権

エントリ内の各属性値に対する書き込みアクセス権。このアクセス権はデフォルトで与えられているが、targattrfilters キーワードを使用して制限できる

削除されるエントリに対する削除アクセス権

目的の属性タイプに対する書き込みアクセス権

各属性タイプの値に対する書き込みアクセス権。このアクセス権はデフォルトで与えられているが、targattrfilters キーワードを使用して制限できる

そのエントリに対する書き込みアクセス権

新しい RDN で使用される属性タイプに対する書き込みアクセス権

古い RDN を削除する書き込みアクセス権を与える場合は、古い RDN 属性タイプに対する書き込みアクセス権

新しい RDN で使用される属性タイプの値に対する書き込みアクセス権。このアクセス権はデフォルトで与えられているが、targattrfilters キーワードを使用して制限できる

目的の属性タイプに対する比較アクセス権

検索フィルタで使用される各属性タイプに対する検索アクセス権

エントリが確実に返されるようにするためにエントリで使用される少なくとも 1 つの属性タイプに対する読み取りアクセス権

エントリと一緒に返される各属性タイプに対する読み取りアクセス権

ユーザーにディレクトリを検索させるために設定する必要があるアクセス権について理解するには、次の例を参照してください。次のような検索を想定します。

bjensen というユーザーに、自分のエントリを検索するためのアクセス権を与えるかどうかは、次に示す ACI を使用して決定します。

この ACI は bjensen に objectclass 属性を検索する権限を与えないので、検索結果のリストには何も表示されません。前述した検索操作を正常に実行するには、次のように ACI を変更する必要があります。

アクセス権の構文

ここで、rights は 1 ～ 8 個のキーワードのリストです。キーワードは、コンマで区切り、カッコでくくります。使用できるキーワードは、read、write、add、delete、search、compare、selfwrite、proxy、または all です。

次の例では、バインドルールが true であると判定された場合は、読み取り、検索、および比較アクセスが許可されます。

バインドルール

ディレクトリに対して定義された ACI に応じて、一部の操作では、ディレクトリに対するバインドが必要です。バインドとは、バインド DN とパスワードを入力して、ディレクトリに対して、ログインまたは自身の認証を行うことです。SSL を使用する場合は、証明書が必要です。ディレクトリに対するアクセスが許可されるか拒否されるかは、バインド操作で与えられる資格とバインドの状況によって決まります。

ACI 内のすべてのアクセス権のセットには、対応するバインドルールが存在します。

単純なバインドルールでは、ディレクトリにアクセスするユーザーが特定のグループに属していることが必要とされます。複雑なバインドルールでは、ユーザーが特定のグループに属し、特定の IP アドレスを持つコンピュータで、午前 8 時から午後 5 時の間にログインする必要があることを指定できます。

バインドルールにより、誰が、いつ、どこからディレクトリにアクセスできるかを定義できます。具体的には、バインドルールで次の内容を指定できます。

アクセス権が与えられたユーザー、グループ、およびロール

エンティティがバインドを開始する位置。ユーザーが認証を行う位置はスプーフィングされる可能性があるので、信頼できません。ACI がこの情報だけに基づいたものにならないようにします。

バインドを実行できる時刻または日付

バインド時に使用する認証のタイプ

さらに、ブール演算子を使用してこれらの条件を組み合わせると、複雑なバインドルールを定義できます。詳細は、「ブール型バインドルールの使用」を参照してください。

サーバーでは、LDAP フィルタの評価で使用したものと似た 3 値論理に従って、ACI で使用する論理式が評価されます (「RFC 2251 Lightweight Directory Access Protocol (v3)」を参照)。つまり、式の構成要素が未定義と評価された場合 (リソースの制約によって、式の評価が中断された場合など) は、サーバーは適切に対応します。複雑なブール式で未定義値が発生しても、間違ってアクセス権を与えることはありません。

バインドルールの構文

アクセスが許可されるか拒否されるかは、ACI のバインドルールが true であると判定されるかどうかによって決まります。バインドルールには、次の 2 つのパターンのうちどちらかが使用されます。

等号 (=) は、バインドルールを true とするには keyword と expression が一致しなければならないことを示し、不等号 (!=) は、バインドルールを true とするには keyword と expression が一致してはならないことを示します。


注	timeofday キーワードでは、不等式表現 (<、<=、>、>=) もサポートしています。timeofday は、これらの表現をサポートする唯一のキーワードです。

expression を囲む引用符 ("") と区切りを示すセミコロン (;) は省略できません。使用できる式は、対応する keyword によって決まります。

次の表に、各キーワードとそれに対応する式を示します。式でワイルドカードが使用できるかどうかについても示します。

表 6-2 LDIF バインドルールキーワード
キーワード	有効な式	ワイルドカード使用
userdn	ldap:///distinguished_name ldap:///all ldap:///anyone ldap:///self ldap:///parent ldap:///suffix??sub?(filter)	可 (ただし DN に限る)
groupdn	[ldap:///DN]	不可
roledn	[ldap:///DN]	不可
userattr	attribute#bindType or attribute#value	不可
ip	IP_address	可
dns	DNS_host_name	可
dayofweek	sun mon tue wed thu fri sat	不可
timeofday	0 - 2359	不可
authmethod	none simple ssl sasl authentication_method	不可

次の節では、各キーワードのバインドルールの構文を詳しく説明します。

ユーザーアクセスの定義: userdn キーワード

ユーザーアクセスは userdn キーワードを使用して定義します。userdn キーワードには、1 つ以上の有効な識別名が必要です。書式は次のとおりです。

ここで、dn は DN、つまり anyone、all、self、または parent の 1 つです。これらの式は、次のユーザーを示します。

userdn = "ldap:///anyone" : 匿名ユーザーと認証ユーザーの両方

userdn = "ldap:///all" : 認証ユーザーのみ

userdn = "ldap:///self" : ACI のターゲットエントリと同じユーザーのみ

userdn = "ldap:///parent" : ACI ターゲットの親エントリのみ

userdn キーワードは、LDAP フィルタとして表すこともできます。書式は次のとおりです。

匿名アクセス (anyone キーワード)


注	dn に対して構文上有意な文字 (コンマなど) は、1 つの円記号 (¥) を使用してエスケープする必要があります。

ディレクトリへの匿名アクセス権を与えると、バインド状況にかかわりなく、バインド DN やパスワードなしで、誰でもそのディレクトリにアクセスできます。匿名アクセスは、特定タイプのアクセス (たとえば、読み取りのためのアクセスや検索のためのアクセス)、あるいは特定のサブツリーやディレクトリ内の個々のエントリに、アクセスの対象を制限できます。anyone キーワードを使った匿名アクセスは、すべての認証ユーザーによるアクセスも許可します。

たとえば、example.com ツリー全体への匿名による読み取りアクセスと検索アクセスを許可する場合は、次に示す ACI を dc=example,dc=com ノードに作成します。

汎用アクセス (all キーワード)

バインドルールを使用すると、ディレクトリに対して正常にバインドしたすべてのユーザーに対してアクセス権を許可できます。このため、all キーワードは、すべての認証ユーザーによるアクセスを許可します。これは、匿名アクセスを防ぐ一方、一般的なアクセスを許可する

たとえば、認証されたすべてのユーザーに対してツリー全体の読み取りアクセス権を与える場合は、次に示す ACI を dc=example,dc=com ノードに作成します。

自己アクセス (self キーワード)

ユーザー自身が所有するエントリに対して、アクセス権を許可または拒否します。つまり、バインド DN がターゲットエントリの DN と一致するかどうかで、エントリへのアクセス権が許可または拒否されます。

たとえば、example.com ツリー内のすべてのユーザーに対して、userPassword 属性への書き込みアクセス権を与える場合は、dc=example,dc=com ノード上に次の ACI を作成します。

親アクセス (parent キーワード)

ユーザーのバインド DN がターゲットエントリの親である場合に限り、ユーザーはエントリに対するアクセスを許可または拒否されます。parent キーワードを使うには、Server Console で ACI を手動で編集する必要があります。

たとえば、ユーザーがバインド DN の任意の子エントリを変更できるようにする場合は、次に示す ACI を dc=example,dc=com ノードに作成します。

LDAP URL

フィルタ付きの URL を使用すると、次のように ACI 内でダイナミックにターゲットユーザーを指定できます。

たとえば、example.com ツリーの accounting および engineering の分岐に含まれる、すべてのユーザーのターゲットリソースに対するアクセスを、次の URL に基づいてダイナミックに許可または拒否できます。


注	LDAP URL では、ホスト名またはポート番号を指定しないでください。LDAP URL は、常にローカルサーバーに適用されます。

LDAP URL の詳細については、『Directory Server Administration Reference』の第 10 章にある「LDAP URL Reference」を参照してください。

ワイルドカード

ワイルドカード文字 (*) を使用して、ユーザーのセットを指定することもできます。たとえば、uid=b*,dc=example,dc=com というユーザー DN を指定すると、設定したアクセス権に基づいて、b という文字で始まるバインド DN を持つユーザーのアクセスだけを許可または拒否できます。

LDAP URL の論理 OR

複数の LDAP URL またはキーワード式を指定して、ユーザーアクセスのための複雑な規則を作成します。たとえば、次のようにします。

いずれかの DN パターンとバインドするユーザーの場合に、バインドルールは true と判定されます。

特定の LDAP URL の除外

不等号 (!=) 演算子を使用して、特定の URL または DN を除外するユーザーアクセスを定義します。たとえば、次のようにします。

accounting サブツリーで、クライアントが UID を基にした識別名としてバインドしない場合に、バインドルールは true と判定されます。このバインドルールは、ターゲットエントリがディレクトリツリーの accounting 分岐の下にはない場合に限り意味を持ちます。

グループアクセスの定義 : groupdn キーワード

指定されたグループのメンバーは、ターゲットリソースにアクセスできます。これは、グループアクセスと呼ばれます。グループアクセスは groupdn キーワードを使用して定義され、ユーザーが特定のグループに属する DN を使用してバインドすれば、ターゲットエントリへのアクセスが許可または拒否されます。

groupdn キーワードには、1 つ以上のグループの識別名が必要です。書式は次のとおりです。

バインド DN が groupDNs のいずれかによって指定されたグループに属している場合に、バインドルールは true と判定されます。次の項では、groupdn キーワードの使用例を示します。

単一の LDAP URL


注	dn に対して構文上有意な文字 (コンマなど) は、1 つの円記号 (¥) を使用してエスケープする必要があります。

バインド DN が Administrators グループに属していれば、バインドルールは true と判定されます。Administrators グループに対してディレクトリツリー全体への書き込みアクセス権を与える場合は、次の ACI を dc=example,dc=com ノードに作成します。

LDAP URL の論理 OR

バインド DN が Administrators グループまたは Mail Administrators グループに属していれば、バインドルールは true と判定されます。

ロールアクセスの定義 : roledn キーワード

指定されたロールのメンバーは、ターゲットリソースにアクセスできます。これは、ロールアクセスと呼ばれます。ロールアクセスは roledn キーワードを使用して定義され、ユーザーが特定のロールに属する DN を使用してバインドすれば、ターゲットエントリへのアクセスが許可または拒否されます。

roledn キーワードには、1 つ以上の有効な識別名が必要です。書式は次のとおりです。

バインド DN が指定されたロールに属していれば、バインドルールは true と判定されます。


注	dn に対して構文上有意な文字 (コンマなど) は、1 つの円記号 (¥) を使用してエスケープする必要があります。

roledn キーワードの構文と使い方は、groupdn キーワードと同じです。

値マッチングに基づくアクセスの定義

バインドルールを設定することによって、ディレクトリへのバインドに使用するエントリの属性値が、ターゲットエントリの属性値に一致するように指定できます。

たとえば、ACI が適用されるように、バインド DN がユーザーエントリの manager 属性の DN に一致するように指定できます。この場合は、ユーザーのマネージャだけがエントリにアクセスできます。

この例は、DN マッチングに基づいています。したがって、ターゲットエントリとのバインドに使用されるエントリの任意の属性を一致させることができます。たとえば、favoriteDrink 属性に「Beer」という値を持つユーザーに対し、同じ値の favoriteDrink 属性を持つほかのユーザーのすべてのエントリの読み取りを許可する ACI を作成できます。

userattr キーワードの使用

userattr キーワードは、バインド操作に使用するエントリとターゲットエントリの間で、どの属性値が一致する必要があるかを指定するのに使用できます。

ユーザー DN

グループ DN

ロール DN

LDAP フィルタ (LDAP URL 内)

任意の属性タイプ

ユーザー DN、グループ DN、ロール DN、または LDAP フィルタ以外の値が必要な属性タイプを使用する場合は、次の構文になります。

attrName は、値マッチングに使用される属性の名前

bindType は、USERDN,GROUPDN,ROLEDN,LDAPURL の 1 つ

attrValue は、属性値を表す任意の文字列



注	CoS (サービスクラス) 定義で作成された属性は、userattr キーワードと一緒に使用できません。Cos によって作成された属性値に依存するバインドルールを含む ACI は機能しません。

次の節では、考えられるさまざまなバインドタイプを指定した userattr キーワードの例を示します。

USERDN バインドタイプを指定した例

次に、ユーザー DN に基づくバインドに関連する userattr キーワードの例を示します。

バインド DN がターゲットエントリの manager 属性値と一致すれば、バインドルールは true と判定されます。これによって、ユーザーのマネージャが社員の属性を変更できるようになります。このメカニズムは、ターゲットエントリの manager 属性が、絶対 DN として指定されている場合にだけ機能します。

次の例では、マネージャは社員のエントリに対してすべてのアクセス権が許可されています。

GROUPDN バインドタイプを指定した例

次に、グループ DN に基づくバインドに関連する userattr キーワードの例を示します。

バインド DN がターゲットエントリの owner 属性で指定されたグループのメンバーであれば、バインドルールは true と判定されます。たとえば、このメカニズムを使用して、社員の役職に関する情報の管理アクセス権を、あるグループに許可できます。使用する属性にグループエントリの DN が含まれていれば、owner 以外の属性も使用できます。

指定するグループをダイナミックグループにすることも、グループの DN をディレクトリ内の任意のサフィックスの下に置くこともできます。ただし、サーバーでこのタイプの ACI を評価するには、多くのリソースを必要とします。

ターゲットエントリと同じサフィックスの下にあるスタティックグループを使用する場合は、次の式を使用します。

この例では、グループエントリは dc=example,dc=com というサフィックスの下にあります。サーバーによるこのタイプの構文の処理時間は、前述の例の処理時間よりも短くなります。

ROLEDN バインドタイプを指定した例

次に、ロール DN に基づくバインドに関連する userattr キーワードの例を示します。

バインド DN がターゲットエントリの exampleEmployeeReportsTo 属性で指定されたロールに属していれば、バインドルールは true と判定されます。たとえば、社内のすべてのマネージャに対して階層化されたロールを作成する場合は、このメカニズムを使用して、マネージャよりも下の役職にある社員に関する情報へのすべてのレベルのアクセス権を、マネージャに与えることができます。

ロールの DN を、ディレクトリ内の任意のサフィックスの下に置くことができます。さらに、フィルタを適用したロールを使用する場合は、サーバーがこのタイプの ACI を評価するためには、多くのリソースを必要とします。

LDAPURL バインドタイプを指定した例

次に、LDAP フィルタに基づくバインドに関連する userattr キーワードの例を示します。

バインド DN とターゲットエントリの myfilter 属性で指定されたフィルタが一致すれば、バインドルールは true と判定されます。myfilter 属性は、LDAP フィルタを含む任意の属性に置き換えることができます。

任意の属性値を指定した例

次に、任意の属性値に基づくバインドに関連する userattr キーワードの例を示します。

バインド DN とターゲット DN の両方に favoriteDrink 属性が含まれ、その値がともに Beer であれば、バインドルールは true と判定されます。

継承を含む userattr キーワードの使用

userattr キーワードを使用して、バインド操作に使用されるエントリをターゲットエントリと関連付けると、ACI は指定されたターゲットだけに適用され、下位のエントリには適用されません。ただし、状況によっては、ターゲットエントリよりも下位のエントリにも、ACI の適用が必要になることもあります。このためには、parent キーワードを使用して、ターゲットのいくつ下のレベルまで ACI を継承するかを指定します。

userattr キーワードとともに parent キーワードを使用する場合の構文は次のとおりです。

inheritance_level は、ターゲットのいくつ下のレベルまで ACI を継承するかを示すリストで、各レベルはコンマで区切る。レベルはターゲットエントリの 5 レベル [0,1,2,3,4] 下まで指定できる。0 はターゲットエントリを示す

attribute は、userattr または groupattr キーワードのターゲットとなる属性

bindType には、USERDN、GROUPDN のいずれかを指定する。LDAPURL および ROLEDN のバインドタイプは、継承ではサポートされない

バインド DN とターゲットエントリの manager 属性が一致すれば、このバインドルールは true と判定されます。バインドルールが true と判定されると、アクセス権が与えられます。このアクセス権は、ターゲットエントリおよびその直下にあるすべてのエントリに適用されます。

userattr の継承を含む例

次の図は、bjensen というユーザーが、cn=Profiles エントリ、および cn=mail と cn=news を含む 1 レベル下の子エントリに対して、読み取りと検索を許可された例を示しています。

この例において、継承を使用せずに同じ結果を得るには、次のどちらかの操作を実行する必要があります。

ディレクトリ内のcn=Profiles、cn=mail、および cn=news エントリに対するユーザー bjensen の読み取りアクセスと検索アクセスを明示的に設定する

cn=mail,cn=Profiles および cn=news,cn=Profiles エントリに対して owner 属性と次の ACI を追加する

userattr キーワードによる追加アクセス権の許可

all または add アクセス権とともに userattr キーワードを使用すると、サーバーが期待どおりに動作しないことがあります。通常、ディレクトリ内に新しいエントリを作成すると、Directory Server は作成されているエントリのアクセス権限を確認しますが、親エントリのアクセス権限は確認されません。ただし、userattr キーワードを使用する ACI の場合は、この動作によってセキュリティホールが生じる可能性があるので、これを避けるためにサーバーの通常動作は変更されます。

この ACI は、部下のエントリに対するすべての権限をマネージャに与えます。ただし、新しく作成されるエントリについてもアクセス権限が確認されるので、このタイプの ACI では、すべての社員がエントリを作成でき、そのエントリについては manager 属性を社員自身の DN に設定できます。たとえば、会社に不満を持つ Joe という社員 (cn=Joe,ou=eng,dc=example,dc=com) がツリーの Human Resources 分岐にエントリを作成した場合、Human Resources の社員に与えられているアクセス権を所有し、そのアクセス権を使用する (あるいは悪用する) ことが可能になります。

このような行為は、次のようなエントリを作成することで実現できてしまいます。

このようなセキュリティ上の危険を回避するために、ACI の評価プロセスでは、レベル 0 の追加権限、つまりエントリ自身に対する追加権限を与えません。ただし、既存エントリの下位にあるエントリには、parent キーワードを使用して追加アクセス権を与えることができます。親のいくつ下のレベルまで追加アクセス権を許可するかを指定する必要があります。たとえば、次の ACI によって、dc=example,dc=com 内にあってバインド DN に一致する manager 属性を持つ任意のエントリに、子エントリを追加できます。

この ACI は、バインド DN と親エントリの manager 属性が一致するユーザーだけに追加アクセス権を与えます。

特定 IP アドレスからのアクセスの定義

バインドルールを使用して、特定の IP アドレスからバインドするように指定できます。これは、ディレクトリへのすべての更新が、特定のマシンまたはネットワークドメインから行われるように強制する場合によく使用される

IP アドレスに基づくバインドルールを設定するための LDIF 構文は、次のとおりです。

IPaddressList は、次の項目からなる 1 つまたは複数の要素です (複数の要素はコンマで区切られる)。

特定の IPv4 アドレス (123.45.6.7 など)

ワイルドカードを使用してサブネットワークを指定した IPv4 アドレス (12.3.45.* など)

サブネットワークマスクを持つ IPv4 アドレスまたはサブネットワーク (123.45.6.*+255.255.255.115 など)

RFC 2373 (http://www.ietf.org/rfc/rfc2373.txt) の定義に従った、有効な形式で指定された IPv6 アドレス。次のアドレスは、どれもが同等と見なされる

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 アドレスはスプーフィングされる可能性があるので、信頼できません。ACI がこの情報だけに基づいたものにならないようにします。

ACI の適用対象を特定のコンピュータに制限するには、アクセス制御エディタを使用して Server Console から定義します。詳細は、「コンソールを使用した ACI の作成」を参照してください。

特定ドメインからのアクセスの定義

バインドルールを使用して、特定のドメインまたは特定のホストマシンだけからバインドできるように指定できます。これは、ディレクトリへのすべての更新が、特定のマシンまたはネットワークドメインから行われるように強制する場合によく使用される

DNS ホスト名に基づくバインドルール設定のための LDIF 構文は、次のとおりです。


警告	dns キーワードを使用するためには、マシンで使用されるネームサービスは DNS である必要があります。ネームサービスが DNS でない場合、dns キーワードの代わりにipキーワードを使用します。

dns キーワードには、完全修飾による DNS ドメイン名が必要です。ドメインを指定せずにホストへのアクセス権を与えると、セキュリティ上の問題が発生する可能性があります。たとえば、次のような式を使用することもできますが、このような方法はできるだけ避けてください。

dns キーワードではワイルドカードを使用できます。たとえば、次のようにします。

ディレクトリにアクセスするクライアントが指定されたドメインにあれば、バインドルールは true と判定されます。これは、アクセスを特定ドメインに制限する場合に有効です。使用しているシステムのネームサービスが DNS でなければ、ワイルドカードは使用できません。ネームサービスが DNS でない場合、特定ドメインからのアクセスに制限するには、「特定 IP アドレスからのアクセスの定義」の説明に従って、ip キーワードを使用します。

特定の時刻または曜日におけるアクセスの定義

バインドルールを使用して、特定の時刻または曜日だけにバインドするように制限できます。たとえば、月曜日から金曜日の朝 8 時から午後 5 時までの間にアクセスを制限するようなルールを設定できます。アクセス権限の評価に使用される時刻はディレクトリサーバー上の時刻で、クライアント上の時刻ではありません。

時刻に基づくバインドルールを設定するための LDIF 構文は、次のとおりです。

operator には、次のどれかを指定できます。等号 (=)、不等号 (!=)、大なり記号 (>)、大きいまたは等しい (>=)、小なり記号 (<)、小さいまたは等しい (<=)。時間は、24 時間法による「時」と「分」を表す 4 桁 (0 から 2359) で表されます。たとえば、次のようにします。

timeofday = "1200"; システム時刻が正午を示しているときに、クライアントがディレクトリにアクセスしている場合に true となります。

timeofday != "0100"; 1 a.m. 以外の時間にアクセスしている場合に true となります。

timeofday > "0800"; 8:01 a.m. から 11:59 p.m. の間にアクセスしている場合に true となります。

timeofday >= "0800"; 8:00 a.m. から 11:59 p.m. の間にアクセスしている場合に true となります。

timeofday < "1800"; 深夜 12 時から 5:59 p.m. の間にアクセスしている場合に true となります。



注	timeofday バインドルールおよび dayofweek バインドルールの評価には、クライアント上の時刻ではなく、サーバー上の時刻と日付が使用されます。

曜日に基づくバインドルールを設定するための LDIF 構文は、次のとおりです。

dayofweek キーワードの値には、アルファベット 3 文字で示される sun、mon、tue、wed、thu、fri、および sat の曜日の略号が使用されます。アクセス権を与えるすべての曜日を指定します。たとえば、次のようになります。

一覧表示された曜日のいずれかにディレクトリがアクセスされていれば、バインドルールは true になります。

認証方法に基づくアクセスの定義

クライアントが特定の認証方法でディレクトリにバインドするように、バインドルールを設定できます。次に示す認証方法を使用できます。

None: 認証は不要です。これはデフォルトです。匿名アクセスを表しています。

Simple : クライアントはユーザー名とパスワードを入力し、ディレクトリにバインドする必要があります。

SSL : クライアントは、SSL (Secure Socket Layer) または TLS (Transport Layer Security) 接続により、ディレクトリにバインドする必要があります。

SASL : クライアントは、DIGEST-MD5 や GSSAPI などの SASL (Simple Authentication and Security Layer) 接続により、ディレクトリにバインドする必要があります。

認証方法に基づくバインドルールは、アクセス制御エディタでは設定できません。

認証方法に基づくバインドルールを設定するための LDIF 構文は、次のとおりです。

ここで、authentication_method は、none、simple、ssl、または sasl sasl_mechanism です。たとえば、次のようになります。

例

authmethod = "none" : バインドルールの評価時に認証検査は行われません。

authmethod = "simple" : クライアントがユーザー名とパスワードを使用してディレクトリにアクセスすると、バインドルールは true と判定されます。

authmethod = "ssl" : クライアントが LDAPS を経由した証明書を使用してディレクトリに対する認証を行うと、バインドルールは true と判定されます。クライアントが LDAPS を経由した単純認証 (バインド DN とパスワード) を行うと、バインドルールは false と判定されます。

authmethod = "sasl DIGEST-MD5" : クライアントが SASL DIGEST-MD5 メカニズムを使用してディレクトリにアクセスすると、バインドルールは true と判定されます。サポートされている SASL メカニズムには、これ以外に EXTERNAL (すべてのプラットフォーム) と GSSAPI があります (Solaris システムのみ)。

ブール型バインドルールの使用

AND、OR、およびNOT のブール式を使用して細かいアクセスルールを設定すると、複雑なバインドルールを作成できます。ブール型バインドルールは、Server Console では作成できません。LDIF 文を作成する必要があります。

たとえば、バインド DN が管理者のグループまたはメール管理者のグループのメンバーで、クライアントが example.com ドメイン内から実行されていれば、次のバインドルールは true と判定されます。

内側のカッコでくくられた式から外側のカッコでくくられた式へ

すべての式を左から右へ

AND または OR 演算子の前に NOT ブール演算子

ブール演算子 OR とブール演算子 AND の優先順位はありません。

ブール式は左から右へ評価されるので、上の例ではバインドルール B の前にバインドルール A が評価され、下の例ではバインドルール A の前にバインドルール B が評価されます。

ただし、ブール演算子 NOT は、ブール演算子 OR またはブール演算子 AND よりも先に評価されます。たとえば、次のような式があるとします。

ここでは、「左から右へ」の原則は適用されず、バインドルール A よりも先にバインドルール B が評価されます。

コマンド行からの ACI の作成

LDIF 文を使用してアクセス制御命令を手動で作成し、ldapmodify コマンドを使用して、その命令をディレクトリツリーに追加できます。ACI の値は複雑であるため、新しい ACI を作成するときは、既存の値を表示してコピーすると便利です。

aci 属性値の表示

ACI は aci 属性の値として、エントリに格納されます。aci は複数の値を持つオペレーショナル属性であり、ディレクトリユーザーはこの属性の読み取りや変更を行うことができます。この属性自体が ACI で保護される必要があります。通常、管理ユーザーには aci 属性へのすべてのアクセス権が許可されるので、管理ユーザーは次の方法のどれかでこの属性の値を表示できます。

汎用エディタを使用して、他の属性値と同様に aci 属性値を表示できます。Directory Server コンソールの最上位の「ディレクトリ」タブで、ACI が格納されているエントリを右クリックし、メニューから「汎用エディタで編集」を選択します。ただし、aci の値は長い文字列であることが多く、このダイアログでは表示や編集が困難な場合があります。

代わりに、ディレクトリツリー内でエントリを右クリックし、「アクセス権を設定」を選択すると、アクセス制御エディタを起動できます。ACI を選択して「編集」をクリックし、「手動での編集」をクリックして、対応する aci 値を表示します。ACI エディタの手動モードとビジュアルモードを切り替えることで、aci 値の構文とその設定を比較できます。

また、オペレーティングシステムが対応している場合は、汎用エディタまたは手動モードのアクセス制御エディタから aci 値をコピーし、作成中の LDIF ファイルにペーストすることもできます。管理ユーザーは次の ldapsearch コマンドを実行して、エントリの aci 属性を表示することもできます。

このコマンドで得られた LDIF テキストを、新しい LDIF ACI 定義にコピーして編集できます。ACI の値は長い文字列なので、ldapsearch 操作からの出力は複数行にわたって表示されることがあります。この場合、最初の空白は継続マーカーになります。LDIF の出力をコピーおよびペーストする場合は、この点を考慮してください。


注	aci の値によってアクセス権限がどのように許可または拒否されるかを確認するには、「実効権限の表示」を参照してください。

コンソールを使用した ACI の作成

Directory Server コンソールを設定して、ディレクトリのどのエントリが aci 属性を持っているかを表示できます。この表示の有効と無効を切り替えるには、「表示」>「表示」>「ACI カウント」の順に選択または選択解除します。最上位の「ディレクトリ」タブに一覧表示されるエントリの末尾に、その aci 属性に定義されている ACI の数が表示されます。Directory Server コンソールを使用して、ディレクトリの ACI の表示、作成、編集、削除を行うことができます。

Directory Server のセキュリティポリシーに使用される一般的なアクセス制御規則と、その規則を作成するための Directory Server コンソールの使い方の手順については、「アクセス制御の使用例」を参照してください。

アクセス制御エディタがビジュアル編集モードになっている場合は、複雑な ACI を作成できません。特に、アクセス制御エディタから次の操作を実行できません。

アクセスの拒否 (「アクセス権の構文」を参照)

値に基づいた ACI の作成 (「LDAP フィルタを使用した属性値のターゲット指定」を参照)

親アクセスの定義 (「親アクセス (parent キーワード)」を参照)

ブール型バインドルールを含む ACI の作成 (「ブール型バインドルールの使用」を参照)

一般的に、次のキーワードを使用する ACI の作成 : roledn, userattr, authmethod



ヒント	アクセス制御エディタで「手動での編集」ボタンをクリックすると、グラフィカルインタフェースで変更した内容をいつでも LDIF で確認できます。

エントリの ACI の表示

Directory Server コンソールの最上位レベルにある「ディレクトリ」タブでディレクトリツリーを表示し、アクセス制御を設定するエントリを探します。ACI を編集するには、ディレクトリ管理者または Directory Manager としての権限が必要です。

このエントリをマウスの右ボタンでクリックし、ポップアップメニューから「アクセス権を設定」を選択します。あるいは、エントリをクリックして選択し、「オブジェクト」メニューから「アクセス権を設定」を選択します。

次の図に示すように、「アクセス制御の管理」ダイアログが表示されます。このダイアログボックスには、選択したエントリで定義されたすべての ACI についての説明が一覧表示され、ACI を修正、削除、および新しく作成できます。

図 6-2 「アクセス制御の管理」ダイアログボックス
「ou=People,dc=example,dc=com のアクセス制御の管理」ウィンドウと、このエントリで定義された ACI 文字列の説明の一覧表示

「継承された ACI の表示」チェックボックスを選択すると、選択したエントリの親によって定義され、エントリに適用されるすべての ACI が一覧表示されます。継承された ACI を修正または削除することはできません。エントリは定義された場所で管理する必要があります。

「新規」をクリックし、選択したオブジェクトとそのサブツリー全体に対する新しいアクセス権を定義します。図 6-3 に示すように、ACI エディタが表示されます。

図 6-3 ACI エディタダイアログ
「ou=People,dc=example,dc=com の ACI の編集」ウィンドウと、ACI を定義するためのグラフィカルインタフェースの表示

ダイアログボックス最上部の「ACI 名」には、「アクセス制御の管理」ダイアログボックスに表示される ACI の記述が表示されます。ACI にわかりやすい名前を付けると、ディレクトリで ACI を管理しやすくなります。最下位のエントリ上の継承された ACI を表示する場合には特にそうです。

「アクセス制御エディタ」のタブを使うと、アクセスを受け入れまたは拒否されたユーザー、アクセス中またはアクセス制限中のターゲット、許可されたホスト名および操作時間などの詳細なパラメータを指定できます。「アクセス制御」タブの各フィールドについては、オンラインヘルプを参照してください。

ACI エディタのタブには、ACI 値の内容がグラフィック表示されます。ACI 値を表示してテキストとして編集するには、「手動での編集」ボタンをクリックします。テキストエディタを使用して、タブでは定義できない高度な ACI を定義できます。ただし、ACI 値を編集すると、高度な機能を利用するかどうかに関係なく、それ以後は ACI を視覚的に編集できなくなることがあります。

新しい ACI の作成

アクセス制御エディタを表示します。

この手順については、「エントリの ACI の表示」を参照してください。

表示画面が図 6-3 と異なる場合は、「ビジュアル編集」ボタンをクリックします。

「ACI 名」テキストボックスに ACI の名前を入力します。

ACI 名には任意の文字列を指定できます。ほかの ACI と重複しない名前を付けてください。名前を指定しない場合は、自動的に「名前のない ACI」という名前が付けられます。

「ユーザー/グループ」タブで「すべてのユーザー」を強調表示してアクセス権を与えるユーザーを選択するか、「追加」ボタンをクリックして追加するユーザーのディレクトリを検索します。

「ユーザーおよびグループの追加」ウィンドウで、次の手順を実行します。

ドロップダウンリストから検索領域を選択し、「検索」フィールドに検索文字列を入力してから、「検索」ボタンをクリックします。

下のリストに検索結果が表示されます。

検索結果リストで必要なエントリを選択し、「追加」ボタンをクリックして、アクセス権が与えられたエントリのリストにそれらを追加します。

「了解」をクリックして、「ユーザーおよびグループの追加」ウィンドウを閉じます。

選択したエントリが ACI エディタの「ユーザー/グループ」タブに一覧表示されます。

アクセス制御エディタで「権限」タブをクリックし、チェックボックスを使用して与える権限を選択します。

「ターゲット」タブをクリックし、「このエントリ」をクリックして、ACI のターゲットとして指定されているノードを表示します。

ターゲット DN の値は変更できますが、新しい DN は、選択したエントリの直接的または間接的な子である必要があります。

このノードの下にあるサブツリー内の一部のエントリを ACI のターゲットから外す場合は、「サブエントリのフィルタ」フィールドにフィルタを入力する必要があります。

さらに、ターゲットとして指定する属性を属性リストから選択することによって、ACI の範囲を特定の属性だけに制限できます。

「ホスト」タブをクリックしてから「追加」ボタンをクリックして、「ホストフィルタの追加」ダイアログボックスを表示します。

ホスト名または IP アドレスを指定できます。IP アドレスを指定する場合は、ワイルドカード文字 (*) を使用できます。

「時間」タブをクリックして、アクセスが許可される時刻のテーブルを表示します。

デフォルトでは、常時アクセスが許可されています。テーブル上でカーソルを操作し、時刻をクリックしてドラッグすることによって、アクセス時間を変更できます。連続していない時間帯を選択することはできません。

ACI の修正が完了したら、「了解」をクリックします。

ACI エディタが閉じられ、ACI マネージャのウィンドウに新しい ACI のリストが表示されます。



注	ACI の作成中に「手動での編集」ボタンをクリックすると、入力した内容に対応する LDIF 文をいつでも表示できます。この文は変更できますが、加えた変更は必ずしもグラフィカルインタフェースに反映されません。

ACI の編集

「ディレクトリ」タブで、サブツリーの一番上のエントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択します。

「アクセス制御の管理」ウィンドウが表示されます。このウィンドウには、そのエントリに属する ACI のリストが表示されます。

「アクセス制御の管理」ウィンドウで、編集する ACI を選択し、「編集」をクリックします。

アクセス制御エディタが表示されます。このダイアログボックスで編集できる情報については、オンラインヘルプを参照してください。

アクセス制御エディタの各種タブを使用して、必要な変更を加えます。

ACI の修正が完了したら、「了解」をクリックします。

ACI エディタが閉じられ、ACI マネージャのウィンドウに変更された ACI のリストが表示されます。

ACI の削除

「ディレクトリ」タブで、サブツリーの一番上のエントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択します。

「アクセス制御の管理」ウィンドウが表示されます。このウィンドウには、そのエントリに属する ACI のリストが表示されます。

「アクセス制御の管理」ウィンドウで、削除する ACI を選択します。

「削除」をクリックします。

削除した ACI は、アクセス制御の管理に表示されなくなります。

アクセス制御の使用例

この節で示す例では、架空の ISP である example.com 社が、アクセス制御ポリシーを決定していきます。すべての例では、コンソールまたは LDIF ファイルを使用して、与えられたタスクをどのように処理するかを説明しています。

Example.com 社の業務は、Web ホスティングサービスとインターネットアクセスの提供です。Example.com の Web ホストサービスには、クライアント企業のディレクトリのホスティングが含まれます。Example.com は実際に 2 つの中規模企業のディレクトリ Company333 と Company999 をホストし、部分的に管理を行なっています。また、多数の個人加入者にインターネットへのアクセスを提供しています。

現在、example.com 社は、次のようなアクセス制御規則を設定しようとしています。

example.com 社の社員に、example.com ツリー全体を対象とした読み取り、検索、および比較のための匿名アクセス権を与える (「匿名アクセスの許可」を参照)

example.com 社の社員に、homeTelephoneNumber、homeAddress などの個人情報への書き込みアクセス権を与える (「個人のエントリへの書き込みアクセス権の許可」を参照)

example.com 社の社員が個人のエントリにロールを追加するアクセス権を与える。ただし、一部の重要なロールは除く (「重要なロールに対するアクセスの制限」を参照)

example.com 社の Human Resources グループに、People 分岐のエントリを対象としたすべての権限を与える (「サフィックスに対するすべてのアクセス権のグループへの許可」を参照)

example.com 社のすべての社員に対し、ディレクトリのSocial Committee 分岐の下にグループエントリを作成し、自身が所有するグループエントリを削除するアクセス権を与える (「グループエントリの追加および削除権限の許可」を参照)

example.com 社のすべての社員に対し、Social Committee 分岐の下のグループエントリに、自身を追加するアクセス権を与える (「ユーザー自身の操作によるグループへの参加と不参加」を参照)

SSL 認証、日時の制約、位置の指定などの一定の条件付きで、ディレクトリツリーのそれぞれの分岐へのアクセス権を Company333 および Company999 のディレクトリ管理者 (ロール) に与える (「グループまたはロールへの条件付きアクセスの許可」を参照)

個人契約者に対し、個人のエントリへのアクセス権を与える (「個人のエントリへの書き込みアクセス権の許可」を参照)

個人契約者が個人のエントリ内の課金情報にアクセスできないようにする (「アクセスの拒否」を参照)

世界のユーザーに対し、個人契約者のサブツリーへの匿名アクセス権を与える。ただし、特に非公開を希望している契約者は除く (ディレクトリのこの部分は、ファイアウォール外部のスレーブサーバーとなることがあり、毎日 1 回更新される)。「匿名アクセスの許可」および「フィルタを使用したターゲットの設定」を参照

匿名アクセスの許可

ほとんどのディレクトリは、読み取り、検索、または比較を行うために、少なくとも 1 つのサフィックスに匿名でアクセスできるように設定されています。たとえば、電話帳のように、企業内の個人情報を収めたディレクトリを管理している場合に、社員がその内容を検索できるようにするには、そのためのアクセス権の設定が必要になることがあります。これは example.com 社内のケースであり、「ACI「Anonymous example.com」」にその例が示されています。

example.com 社では、ISP として、世界中からアクセス可能な公開電話帳を作成し、契約者全員の連絡先情報を公開することも計画しています。これについては、「ACI「Anonymous World」」で例を示しています。

ACI「Anonymous example.com」

example.com 社の社員に example.com ツリー全体を対象とした読み取り、検索、および比較アクセス権を与えるには、LDIF で次のような文を作成します。

この例では、aci を dc=example,dc=com エントリに追加することを仮定しています。userPassword 属性は ACI の対象に含まれていません。

このアクセス権を設定するには、コンソールを使用して次の手順を実行します。

「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。

「新規」をクリックして、アクセス制御エディタを表示します。

「ユーザー/グループ」タブの ACI 名フィールドに、「Anonymous example.com」と入力します。アクセス権が与えられたユーザーのリストに、「すべてのユーザー」と表示されていることを確認します。

「権限」タブで、読み取り (read)、比較 (compare)、および検索 (search) の各権限のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。

「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス dc=example,dc=com が表示されます。属性テーブルで userPassword 属性を検索し、対応するチェックボックスの選択を解除します。

これ以外のチェックボックスは選択されている必要があります。「名前」ヘッダーをクリックして属性リストをアルファベット順に並べ替えると、userPassword 属性の検索が簡単になります。

「ホスト」タブの「追加」をクリックし、「DNS ホストフィルタ」フィールドに「*.example.com」と入力します。「了解」をクリックして、ダイアログボックスを閉じます。

「アクセス制御エディタ」ウィンドウの「了解」ボタンをクリックします。

「アクセス制御の管理」ウィンドウの ACI リストに、新しい ACI が追加されます。

ACI「Anonymous World」

個人契約者サブツリーの読み取りおよび検索アクセス権を世界中に与え、非公開契約者の情報へのアクセスを拒否するには、LDIF で次のような文を作成します。

この例では、ACI を ou=subscribers,dc=example, dc=com エントリに追加することを仮定しています。また、各契約者のエントリには、yes または no の値を持つ unlistedSubscriber 属性が設定されているものとします。非公開契約者は、この属性値に基づいて、ターゲット定義のフィルタによって除外されます。フィルタ定義については、「フィルタを使用したターゲットの設定」を参照してください。

このアクセス権を設定するには、コンソールを使用して次の手順を実行します。

「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある Subscribers エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。

「新規」をクリックして、アクセス制御エディタを表示します。

「ユーザーおよびグループ」タブの ACI 名フィールドに、「Anonymous World」と入力します。アクセス権が与えられたユーザーのリストに、「すべてのユーザー」と表示されていることを確認します。

「権限」タブで、読み取り (read) と検索 (search) の各権限のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。

「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス dc=subscribers, dc=example,dc=com が表示されます。

「サブエントリのフィルタ」フィールドに、次のフィルタを入力します。

(!(unlistedSubscriber=yes))

属性テーブルで、homePhone、homePostalAddress、および mail 属性のチェックボックスを選択します。

ただし、これ以外のチェックボックスの選択は、解除されている必要があります。「チェックしない」ボタンをクリックしてテーブル内のすべての属性のチェックボックスの選択を解除し、次に「名前」ヘッダーをクリックしてアルファベット順に属性を並べ替えると、この作業が簡単になります。

「了解」をクリックします。

「アクセス制御の管理」ウィンドウの ACI リストに、新しい ACI が追加されます。

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

多くの場合、内部ユーザーが個人で変更できるエントリの属性は、ディレクトリ管理者によって一部だけに制限されています。example.com 社のディレクトリ管理者は、ユーザーが変更できる対象を、パスワード、自宅の電話番号、自宅住所だけに制限しようとしています。これについては、「ACI「Write example.com」」で例を示しています。

また、契約者がディレクトリに対して SSL 接続を確立することを条件に、example.com ツリー内にある個人情報を更新できるようにするというポリシーもあります。これについては、「ACI「Write Subscribers」」で例を示しています。

ACI「Write example.com」

example.com 社の社員が、個人のパスワード、自宅の電話番号、自宅住所を変更できるようにするには、LDIF で次のような文を作成します。


注	このアクセス権を設定することによって、ユーザーは属性値の削除アクセス権も与えられます。

この例では、ACI を ou=People,dc=example,dc=com エントリに追加することを仮定しています。

このアクセス権を設定するには、コンソールを使用して次の手順を実行します。

「ディレクトリ」タブの左側のナビゲーションツリーで ou=People,dc=example,dc=com エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。

「新規」をクリックして、アクセス制御エディタを表示します。

「ユーザー/グループ」タブの ACI 名フィールドに、「Write example.com」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。

「すべてのユーザー」を選択して削除し、「追加」をクリックします。

「ユーザーおよびグループの追加」ダイアログボックスが表示されます。

「検索領域」を「特殊権限」に設定し、「検索結果」リストで「自己」を選択します。

「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「自己」が追加されます。

「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。

「権限」タブで、書き込みアクセス権 (write) のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。

「ターゲット」タブで「このエントリ」をクリックし、ターゲットディレクトリの入力フィールドに ou=People,dc=example,dc=com と入力します。属性テーブルで、homePhone、homePostalAddress、および userPassword 属性のチェックボックスを選択します。

「ホスト」タブの「追加」ボタンをクリックして、「ホストフィルタの追加」ダイアログボックスを表示します。「DNS ホストフィルタ」フィールドに「*.example.com」と入力します。「了解」をクリックして、ダイアログボックスを閉じます。

「アクセス制御エディタ」ウィンドウの「了解」ボタンをクリックします。

「アクセス制御の管理」ウィンドウの ACI リストに、新しい ACI が追加されます。

ACI「Write Subscribers」

example.com 社の契約者が個人のパスワードと自宅の電話番号を変更できるようにするには、LDIF で次のような文を作成します。


注	このアクセス権を設定することによって、ユーザーは属性値の削除アクセス権も与えられます。

この例では、aci を ou=subscribers,dc=example, dc=com エントリに追加することを仮定しています。

住所は example.com 社からの請求に必要な情報で、この情報を削除する可能性があるので、契約者にはこの属性への書き込みアクセス権は与えられていません。つまり、自宅住所はビジネス的に重要な情報なのです。

このアクセス権を設定するには、コンソールを使用して次の手順を実行します。

「新規」をクリックして、アクセス制御エディタを表示します。

「ユーザー/グループ」タブの ACI 名フィールドに、「Write Subscribers」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。

「すべてのユーザー」を選択して削除し、「追加」をクリックします。

「ユーザーおよびグループの追加」ダイアログボックスが表示されます。

「検索領域」を「特殊権限」に設定し、「検索結果」リストで「自己」を選択します。

「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「自己」が追加されます。

「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。

「サブエントリのフィルタ」フィールドに、次のフィルタを入力します。

(!(unlistedSubscriber=yes))

属性テーブルで、homePhone、homePostalAddress、および mail 属性のチェックボックスを選択します。

ユーザーが SSL を使用して認証するように設定する場合は、「手動での編集」ボタンをクリックして、手動による編集に切り替え、次のように LDIF 文に authmethod=ssl を追加します。

(targetattr="homePostalAddress || homePhone || mail")
(version 3.0; acl "Write Subscribers"; allow (write)
(userdn= "ldap:///self") and authmethod="ssl";)

これは継続した行であり、読みやすいように分割してあります。

「了解」をクリックします。

「アクセス制御の管理」ウィンドウの ACI リストに、新しい ACI が追加されます。

重要なロールに対するアクセスの制限

ディレクトリ内のロール定義を使用して、業務やネットワーク、ディレクトリの管理などに含まれている重要な機能を特定できます。

たとえば、国際的な企業のサイトで特定の時間と曜日に有効なシステム管理者のサブセットを指定する superAdmin ロールを作成する必要があるかもしれません。あるいは、特定のサイト上に、応急手当のトレーニングを受けたすべてのスタッフを含む First Aid ロールの作成が必要になることもあるかもしれません。ロール定義を作成する方法については、「ロールの割り当て」を参照してください。

ロールによって、業務上あるいはビジネス上重要な機能に関するユーザー特権を与える場合は、そのロールに対するアクセス制限を考慮する必要があります。たとえば、example.com の社員は、superAdmin ロール以外の任意のロールを個人のエントリに追加できます。これについては、「ACI「Roles」」で例を示しています。

ACI「Roles」

example.com の社員が、superAdmin 以外の任意のロールを個人のエントリに追加できるようにするには、LDIF で次のような文を作成します。

この例では、ACI を ou=People,dc=example, dc=com エントリに追加することを仮定しています。

このアクセス権を設定するには、コンソールを使用して次の手順を実行します。

「新規」をクリックして、アクセス制御エディタを表示します。

「ユーザー/グループ」タブの ACI 名フィールドに、「Roles」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。

「すべてのユーザー」を選択して削除し、「追加」をクリックします。

「ユーザーおよびグループの追加」ダイアログボックスが表示されます。

「ユーザーおよびグループの追加」ダイアログボックスの「検索領域」を「特殊権限」に設定し、「検索結果」リストで「自己」を選択します。

「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「自己」が追加されます。

「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。

ロール用に値に基づくフィルタを作成するには、「手動での編集」ボタンをクリックして、手動による編集に切り替えます。LDIF 文の先頭に、次の文を追加します。

(targattrfilters="add=nsRoleDN:
(nsRoleDN != "cn=superAdmin, dc=example,dc=com")")

追加後の LDIF 文は次のようになります。

(targetattr="*") (targattrfilters="add=nsRoleDN:
(nsRoleDN != "cn=superAdmin, dc=example,dc=com")")
(target = "ldap:///dc=example,dc=com")
(version 3.0; acl "Roles"; allow (write)
(userdn = "ldap:///self") and (dns="*.example.com");)

「了解」をクリックします。

「アクセス制御の管理」ウィンドウの ACI リストに、新しい ACI が追加されます。

サフィックスに対するすべてのアクセス権のグループへの許可

ほとんどのディレクトリには、業務上の固有の職務を特定するためのグループがあります。このグループには、ディレクトリのすべてまたは一部に対してすべてのアクセス権を与えることができます。グループにアクセス権限を与えることにより、グループメンバーに個別にアクセス権限を設定する必要がなくなります。また、グループにメンバーを追加するだけで、グループに認められたアクセス権限をそのメンバーに与えることができます。

たとえば、標準インストールプロセスを使用して Directory Server をインストールすると、ディレクトリへのすべてのアクセス権を持つ Administrators グループがデフォルトで作成されます。

example.com 社の Human Resources のグループには、ディレクトリの ou=People 分岐へのすべてのアクセス権が許可されています。これによって、このグループのメンバーは社員のディレクトリを更新できます。これについては、「ACI「HR」」で例を示しています。

ACI「HR」

ディレクトリの employee 分岐に対するすべての権限を HR のグループに与えるには、LDIF で次のような文を作成します。

この例では、ACI を ou=People,dc=example,dc=com エントリに追加することを仮定しています。

このアクセス権を設定するには、コンソールを使用して次の手順を実行します。

「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある example.com-people エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。

「新規」をクリックして、アクセス制御エディタを表示します。

「ユーザー/グループ」タブの ACI 名フィールドに、「HR」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。

「すべてのユーザー」を選択して削除し、「追加」をクリックします。

「ユーザーおよびグループの追加」ダイアログボックスが表示されます。

「検索領域」を「ユーザーおよびグループ」に設定し、「検索」フィールドに「HRgroup」と入力します。

この例は、HR のグループまたはロールがすでに作成されていることを前提としています。グループおよびロールについては、第 5 章「ID とロールの管理」を参照してください。

「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに HR のグループが追加されます。

「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。

「権限」タブで、「すべてチェック」ボタンをクリックします。

プロキシ権限 (proxy) 以外のすべてのチェックボックスが選択されます。

「了解」をクリックします。

「アクセス制御の管理」ウィンドウの ACI リストに、新しい ACI が追加されます。

グループエントリの追加および削除権限の許可

一部の企業では、業務の効率化や企業全体の活力向上につながる場合、社員自身がツリー内にエントリを作成できるようにしています。

たとえば、example.com 社には、活発に活動している社内委員会があり、テニス、水泳、スキー、演劇などのさまざまなクラブが組織されています。example.com の社員は、誰でも新しいクラブのグループエントリを作成できます。これについては、「ACI「Create Group」」で例を示しています。example.com 社の社員であれば、これらのグループのどれか 1 つのメンバーになることができます。これについては、「ユーザー自身の操作によるグループへの参加と不参加」の「ACI「Group Members」」に例を示します。グループエントリの変更や削除ができるのは、グループの所有者だけです。これについては、「ACI「Delete Group」」で例を示しています。

ACI「Create Group」

example.com 社の社員が ou=Social Committee 分岐の下にグループエントリを作成できるようにするには、LDIF で次のような文を作成します。


注	この ACI は、書き込みアクセス権を与えないので、エントリを変更できません。サーバーが「top」という値をシーンの後に追加するので、targattrfilters キーワードで objectclass=top を指定する必要があります。

この例では、ACI を ou=social committee, dc=example,dc=com エントリに追加しています。

このアクセス権を設定するには、コンソールを使用して次の手順を実行します。

「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある Social Committee エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。

「新規」をクリックして、アクセス制御エディタを表示します。

「ユーザー/グループ」タブの ACI 名フィールドに、「Create Group」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。

「すべてのユーザー」を選択して削除し、「追加」をクリックします。

「ユーザーおよびグループの追加」ダイアログボックスが表示されます。

「検索領域」を「特殊権限」に設定し、「検索結果」リストで「すべての認証ユーザー」を選択します。

「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「すべての認証ユーザー」が追加されます。

「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。

「権限」タブで、読み取り (read)、検索 (search)、および追加 (add) のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。

「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス ou=social committee, dc=example,dc=com が表示されます。

値に基づくフィルタを作成して、社員がこのサブツリーにグループエントリだけを追加できるようにするには、「手動での編集」ボタンをクリックして、手動による編集に切り替えます。LDIF 文の先頭に、次の文を追加します。

(targattrfilters="add=objectClass:(objectClass=groupOfNames)
|(objectClass=top)")

追加後の LDIF 文は次のようになります。

(targetattr = "*") (targattrfilters="add=objectClass:(objectClass=groupOfNames)
|(objectClass=top)") (target="ldap:///ou=social committee,dc=example,dc=com) (version 3.0; acl "Create Group";
allow (read,search,add) (userdn= "ldap:///all") and
(dns="*.example.com"); )

「了解」をクリックします。

「アクセス制御の管理」ウィンドウの ACI リストに、新しい ACI が追加されます。

ACI「Delete Group」

example.com 社の社員が ou=Social Committee branch 分岐の下に所有しているグループエントリを変更または削除できるようにするには、LDIF で次のような文を作成します。

この例では、aci を ou=social committee, dc=example,dc=com エントリに追加しています。

コンソールを使用してこの ACI を作成すると、手動編集モードでのターゲットフィルタの作成とグループ所有権の確認が必要なので、あまり効率的ではありません。

グループまたはロールへの条件付きアクセスの許可

多くの場合、ディレクトリへのアクセス特権をグループやロールに与える場合、それらの特権が、特権ユーザーになりすました侵入者から保護されていることを確認する必要があります。したがって、多くの場合、グループまたはロールへの重要なアクセス権を与えるようなアクセス制御規則には、数多くの条件が付けられます。

たとえば、example.com 社では、ホスティングサービスの提供先企業である Company333 および Company999 に対して、それぞれ Directory Administrator ロールを作成しました。example.com 社では、侵入者からデータを保護するために、それぞれの企業が各自でデータを管理し、独自のアクセス制御規則を決定することが求められています。このため、Company333 と Company999 は、ディレクトリツリーのそれぞれの分岐に関してすべての権限を持っていますが、このアクセス権を行使するには次の条件を満たす必要があります。

証明書を使用して、SSL 経由の接続が認証されること

アクセス要求は月曜日から木曜日の午前 8 時から午後 6 時までの間に限ること

それぞれの企業に割り当てられた特定の IP アドレスからアクセスが要求されること

これらの条件は、各社の ACI である「Company333」と「Company999」に示されています。これらの ACI の内容は同等なので、「Company333」という ACI だけを次に示します。

ACI「Company333」

Company333 に対して、前述した条件に従ったディレクトリの自社の分岐へのすべてのアクセス権を与えるには、LDIF で次のような文を作成します。

この例では、ACI を ou=Company333, ou=corporate-clients,dc=example,dc=com エントリに追加することを仮定しています。

このアクセス権を設定するには、コンソールを使用して次の手順を実行します。

「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある Company333 エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。

「新規」をクリックして、アクセス制御エディタを表示します。

「ユーザー/グループ」タブの ACI 名フィールドに、「Company333」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。

「すべてのユーザー」を選択して削除し、「追加」をクリックします。

「ユーザーおよびグループの追加」ダイアログボックスが表示されます。

「検索領域」を「ユーザーおよびグループ」に設定し、「検索」フィールドに「DirectoryAdmin」と入力します。

この例では、cn を DirectoryAdmin とした管理者ロールがすでに作成されていることを前提としています。

「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに管理者ロールが追加されます。

「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。

「権限」タブで、「すべてチェック」ボタンをクリックします。

「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス ou=Company333,ou=corporate-clients,dc=example,dc=com が表示されます。

「ホスト」タブの「追加」ボタンをクリックして、「ホストフィルタの追加」ダイアログボックスを表示します。「IP アドレスホストフィルタ」フィールドに「255.255.123.234」と入力します。「了解」をクリックして、ダイアログボックスを閉じます。

ここで入力する IP アドレスは、Company333 の管理者が example.com ディレクトリに接続するために使用するホストマシンの有効な IP アドレスである必要があります。

「時間」タブで、月曜日から木曜日の午前 8 時から午後 6 時に対応する時間ブロックを選択します。

テーブルの下に、選択した時間ブロックを示すメッセージが表示されます。

Company333 の管理者が SSL 認証を行うようにするには、「手動での編集」ボタンをクリックして、手動による編集に切り替えます。LDIF 文の末尾に次の内容を追加します。

and (authmethod="ssl")

追加後の LDIF 文は次のようになります。

aci:(targetattr = "*")(target="ou=Company333,
ou=corporate-clients,dc=example,dc=com") (version 3.0; acl
"Company333"; allow (all) (roledn="ldap:///cn=DirectoryAdmin,
ou=Company333,ou=corporate-clients, dc=example,dc=com") and
(dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and
timeofday <= "1800") and (ip="255.255.123.234") and
(authmethod="ssl"); )

「了解」をクリックします。

「アクセス制御の管理」ウィンドウの ACI リストに、新しい ACI が追加されます。

アクセスの拒否

ディレクトリ内に業務上重要な情報が含まれている場合は、その情報へのアクセスを拒否する必要があります。

たとえば、example.com 社では、すべての契約者に対し、契約者自身のエントリにある接続時間や料金内訳などの課金情報の読み取りアクセス権を与え、書き込みアクセス権を拒否する必要があります。これについては、それぞれ「ACI「Billing Info Read」」と「ACI「Billing Info Deny」」で説明しています。

ACI「Billing Info Read」

個人のエントリ内にある課金情報の読み取りアクセス権を契約者に与えるには、LDIF で次のような文を作成します。

この例は、関連する属性がスキーマ内で作成済みであり、ACI を ou=subscribers,dc=example,dc=com エントリに追加しています。

このアクセス権を設定するには、コンソールを使用して次の手順を実行します。

「新規」をクリックして、アクセス制御エディタを表示します。

「ユーザー/グループ」タブの ACI 名フィールドに、「Billing Info Read」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。

「すべてのユーザー」を選択して削除し、「追加」をクリックします。

「ユーザーおよびグループの追加」ダイアログボックスが表示されます。

「ユーザーおよびグループの追加」ダイアログボックスの「検索領域」を「特殊権限」に設定し、「検索結果」リストで「自己」を選択します。

「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「自己」が追加されます。

「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。

「権限」タブで、検索 (search) と読み取り (read) の各権限のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。

「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス ou=subscribers, dc=example,dc=com が表示されます。属性テーブルで、connectionTime および accountBalance 属性のチェックボックスを選択します。

この例は、スキーマに connectionTime および accountBalance 属性が追加されていることを前提としています。

「了解」をクリックします。

「アクセス制御の管理」ウィンドウの ACI リストに、新しい ACI が追加されます。

ACI「Billing Info Deny」

各契約者に対し、契約者個人のエントリ内にある課金情報の変更アクセス権を拒否するには、LDIF で次のような文を作成します。

この例は、関連する属性がスキーマ内で作成済みであり、ACI を ou=subscribers,dc=example,dc=com エントリに追加しています。

このアクセス権を設定するには、コンソールを使用して次の手順を実行します。

「新規」をクリックして、アクセス制御エディタを表示します。

「ユーザー/グループ」タブの ACI 名フィールドに、「Billing Info Deny」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。

「すべてのユーザー」を選択して削除し、「追加」をクリックします。

「ユーザーおよびグループの追加」ダイアログボックスが表示されます。

「ユーザーおよびグループの追加」ダイアログボックスの「検索領域」を「特殊権限」に設定し、「検索結果」リストで「自己」を選択します。

「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「自己」が追加されます。

「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。

「手動での編集」ボタンをクリックし、表示された LDIF 文の中の allow を deny に変更します。

この例は、スキーマに connectionTime および accountBalance 属性が追加されていることを前提としています。

「了解」をクリックします。

「アクセス制御の管理」ウィンドウの ACI リストに、新しい ACI が追加されます。

フィルタを使用したターゲットの設定

ディレクトリ内に分散した多数のエントリに対して、アクセス制御の設定が必要な場合は、フィルタを使用してターゲットを設定できます。ただし、検索フィルタは、アクセス管理の対象となるオブジェクトを直接指定するわけではないので、予想外のオブジェクトへのアクセスを許可または拒否してしまうことがあります。ディレクトリ構造が複雑になるほど、この問題は発生しやすくなります。さらに、フィルタによって、ディレクトリ内のアクセス制御に関する問題解決が難しくなる場合もあります。

ユーザー自身の操作によるグループへの参加と不参加

多くのディレクトリの ACI は、ユーザーが自分でグループへの参加と不参加を設定できるようになっています。これは、メーリングリストへの参加や不参加を許可する場合に便利です。

example.com 社では、社員であれば ou=social committee サブツリーの下のどのグループエントリにも参加できます。これについては、「ACI「Group Members」」で例を示しています。

ACI「Group Members」

example.com 社の社員が自分でグループへの参加や不参加を設定できるようにするには、LDIF で次のような文を作成します。

この例では、ACI を ou=social committee, dc=example,dc=com エントリに追加することを仮定しています。

このアクセス権を設定するには、コンソールを使用して次の手順を実行します。

「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある People エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。

「新規」をクリックして、アクセス制御エディタを表示します。

「ユーザー/グループ」タブの ACI 名フィールドに、「Group Members」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。

「すべてのユーザー」を選択して削除し、「追加」をクリックします。

「ユーザーおよびグループの追加」ダイアログボックスが表示されます。

「ユーザーおよびグループの追加」ダイアログボックスの「検索領域」を「特殊権限」に設定し、「検索結果」リストで「すべての認証ユーザー」を選択します。

「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「すべての認証ユーザー」が追加されます。

「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。

「権限」タブで、書き込み (write) アクセス権のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。

「ターゲット」タブのターゲットディレクトリ入力フィールドに、「dc=example,dc=com」というサフィックスを入力します。属性テーブルで、member 属性のチェックボックスを選択します。

「了解」をクリックします。

「アクセス制御の管理」ウィンドウの ACI リストに、新しい ACI が追加されます。

コンマを含む DN のアクセス権の定義

DN にコンマが含まれている場合、LDIF ACI 文内で特別な処理が必要です。ACI 文のターゲット部分とバインドルール部分で、1 つの円記号 (¥) を使用して、コンマをエスケープする必要があります。次に、この構文の例を示します。

プロキシ承認を使用した ACI の例

プロキシ承認方式は、特殊な形式の認証です。自分のユーザー ID を使用してディレクトリにバインドするユーザーには、プロキシ承認を使用して他のユーザーの権限が与えられます。

クライアントアプリケーションのバインド DN は uid=MoneyWizAcctSoftware, ou=Applications,dc=example,dc=com

クライアントアプリケーションがアクセスを要求するターゲットサブツリーは ou=Accounting,dc=example,dc=com

ディレクトリ内に、ou=Accounting,dc=example,dc=com サブツリーへのアクセス権を持つ Accounting Administrator が存在する

クライアントアプリケーションが Accounting サブツリーへのアクセス権を取得するには、次の条件が満たされている必要があります (Accounting Administrator と同じアクセス権を使用)。

Accounting Administrator は、ou=Accounting,dc=example,dc=com サブツリーへのアクセス権を持っている必要がある。たとえば、次の ACI は Accounting Administrator エントリに対するすべての権限を与える

クライアントアプリケーションに対するプロキシ権限を与える次の ACI が、ディレクトリ内に存在する必要がある

この ACI が設定されていれば、MoneyWizAcctSoftware クライアントアプリケーションがディレクトリにバインドし、プロキシ DN のアクセス権限を要求する ldapsearch や ldapmodify などの LDAP コマンドを送信できます。

前述の例で、クライアントが ldapsearch コマンドを実行する場合は、このコマンドに次の制御が含まれます。

クライアントはそのままバインドしますが、プロキシエントリの特権が与えられます。クライアントには、プロキシエントリのパスワードは必要ありません。


注	Directory Manager の DN をプロキシ DN として使用することはできません。また、Directory Manager にプロキシ権限を与えることはできません。同じバインド操作中に Directory Server が複数のプロキシ認証を受け取った場合は、クライアントアプリケーションにエラーが返され、バインド試行は失敗します。

実効権限の表示

ディレクトリのエントリに対するアクセスポリシーを管理するとき、定義した ACI がセキュリティに与える影響を知ることができれば役立ちます。Directory Server は、既存の ACI を評価して、特定のユーザーが特定のエントリに対して持つ実効権限について報告することができます。

この実行権限の取得制御は検索操作で使用され、Directory Server はそれに対して応答します。この制御に対する応答として、エントリと属性に対する実効権限の情報が検索結果の中で返されます。この追加情報としては、各エントリとその中の各属性に対する読み取り権限および書き込み権限などがあります。検索に使用されるバインド DN や任意の DN では権限が必要とされることがあるので、管理者はディレクトリユーザーの権限を検査できます。


警告	実効権限を表示することはそれ自体がディレクトリ操作なので、適切に保護し、制限する必要があります。aclRights 属性と aclRightsInfo 属性に対する ACI を追加で作成して、ディレクトリユーザーによるこの情報へのアクセスを制限します。

実効権限を表示する機能は、LDAP 制御を利用しています。連鎖サフィックスに対する実効権限を表示するには、連鎖ポリシーの中でこの制御を有効にする必要があります。詳細は、「連鎖ポリシーの設定」を参照してください。また、リモートサーバーとのバインドに使用されるプロキシ ID にも、実効権限の属性へのアクセスが許可されていることを確認してください。

実行権限の取得制御の使用

実行権限の取得制御を指定するには、ldapsearch コマンドに -J "1.3.6.1.4.1.42.2.27.9.5.2" オプションを指定して実行します。デフォルトでは、エントリと属性に対してバインド DN エントリが持っている実効権限が検索結果の中で返されます。デフォルトの動作を変更するには、次のオプションを使用します。

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

-X "attributeName ..." : 検索結果には、指定された属性に対する実効権限も表示されます。このオプションは、検索結果に表示されない属性を指定する場合に使用します。たとえば、このオプションを使用すると、現在はエントリに存在していない属性について、ユーザーがその属性を追加する権限を持っているかどうかを調べることができます。

-c 属性または -X 属性、あるいはその両方を使用するときは、-J オプションに実行権限の取得制御の OID が暗黙的に指定されるため、このオプションを指定する必要はありません。実効権限制御に NULL 値を指定すると、現在のユーザーの権限と、現在の ldapsearch 操作によって返される属性とエントリの権限を取得できます。

次に、表示する情報の種類を選択する必要があります。権限だけを表示するか、権限がどのように許可または拒否されているかを示す詳細なログ情報を表示できます。情報の種類を指定するには、検索結果で返す属性として aclRights または aclRightsInfo を追加します。両方の属性を要求すると、実効権限の情報をすべて取得できます。ただし、単純な権限情報は詳細なログ情報にも含まれています。

実効権限機能は、アクセス制御に影響するその他のパラメータ (時刻、認証方法、マシンのアドレスと名前など) を、検索操作を開始したユーザーから継承します。


注	aclRights 属性と aclRightsInfo 属性は、仮想オペレーショナル属性として動作します。これらの属性はディレクトリには格納されず、これらを取得するには明示的に要求する必要があります。これらの属性は、実行権限の取得制御に対する応答として Directory Server で生成されます。このため、どちらの属性も、フィルタや何らかの検索操作に使用することはできません。

次の例は、ユーザーがディレクトリでの自身の権限を確認する方法を示しています。結果の中で、1 は権限が与えられていることを示し、0 は拒否されていることを示します。

ldapsearch -J "1.3.6.1.4.1.42.2.27.9.5.2" ¥
           -h rousseau.example.com -p 389 ¥
           -D "uid=cfuente,ou=People,dc=example,dc=com" ¥
           -w password -b "dc=example,dc=com" ¥
           "(objectclass=*)" aclRights

dn:dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,write:0,proxy:0

dn:ou=Groups, dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,write:0,proxy:0

dn:ou=People, dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,write:0,proxy:0

dn:cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,write:0,proxy:0

dn:cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,writef,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 にはディレクトリ内のエントリに少なくとも読み取り権限が与えられていて、自分のエントリを変更できることを示しています。実効権限制御で指定されていないと通常のアクセス権は有効ではないため、ユーザーは読み取り権限が与えられていないエントリを見ることはできません。次の例で、Directory Manager は、Carla Fuente に読み取り権限が与えられていないエントリを確認できます。

ldapsearch -h rousseau.example.com -p 389 ¥
           -D "cn=Directory Manager" -w password ¥
           -c "dn:uid=cfuente,ou=People,dc=example,dc=com" ¥
           -b "dc=example,dc=com" ¥
           "(objectclass=*)" aclRights

dn:dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,write:0,proxy:0

dn:ou=Groups, dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,write:0,proxy:0

dn:cn=Directory Administrators, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0

dn:ou=Special Users,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0

dn:ou=People, dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,write:0,proxy:0

dn:cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,write:0,proxy:0

dn:cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,write:0,proxy:0

dn:uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,write:0,proxy:0

dn:uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel:add:0,delete:0,read:1,write:1,proxy:0

上記の出力で、Directory Manager は、Carla Fuente がディレクトリツリーの Special Users 分岐と Directory Administrators 分岐のどちらも表示できないことを確認できます。次の例では、Directory Manager は、Carla Fuente が自身のエントリの mail 属性と manager 属性を変更できないことを確認できます。

ldapsearch -h rousseau.example.com -p 389 ¥
           -D "cn=Directory Manager" -w password ¥
           -c "dn:uid=cfuente,ou=People,dc=example,dc=com" ¥
           -b "dc=example,dc=com" ¥
           "(uid=cfuente)" aclRights "*"

version: 1
dn:uid=cfuente, ou=People, dc=example,dc=com

aclRights;attributeLevel;mail:search:1,read:1,compare:1,
write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
mail:cfuente@example.com

aclRights;attributeLevel;uid:search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
uid: 123456789cfuente

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

実効権限検索結果の内容

実行権限の要求では、指定したオプションに従って次の情報が返されます。

権限情報

Write、Selfwrite_add、Selfwrite_delete 権限

ログ情報

権限情報

実行権限情報は、次のサブタイプに基づいて提供されます。

aclRights;entrylevel	エントリレベルの権限情報を提供する
aclRights;attributelevel	属性レベルの権限情報を提供する
aclRightsInfo;entrylevel	エントリレベルのログ情報を提供する
aclRightsInfo;attributelevel	属性レベルのログ情報を提供する

エントリレベルの権限には、add、delete、read、write、および proxy があります。属性レベルの権限には、read、search、compare、write、selfwrite_add、selfwrite_delete、および proxy があります。

0 : 権限が与えられている

1 : 権限が与えられていない

? : 追加、削除、置換する属性の値に応じて権限が与えられる。? が表示される場合は、ログ情報を調べ、権限が与えられる、または与えられない理由を確認する

- : 属性は仮想属性であり、更新することはできない。仮想属性を変更する唯一の方法は、それを生成するメカニズムを変更することである

Write、Selfwrite_add、Selfwrite_delete 権限

Directory Server 5.2 では、書き込み属性レベルの権限だけが「?」とマークされます。追加と削除の権限では、追加、削除できるエントリは、そのエントリの属性値によって異なります。ldapsearch の実行結果としては、「?」ではなく、権限の状態 (0 または 1) がエントリで返されます。

write 権限の値が 1 であれば、承認 DN 値を除くすべての値について、追加と削除の両方の ldapmodify 操作が許可されます。write 権限の値が 0 であれば、承認 DN の値を除くすべての値について、追加、削除いずれの ldapmodify 操作も許可されません。承認 DN の値に適用される権限は、いずれかの selfwrite 権限によって明示的に返されます。この権限には、selfwrite_add と selfwrite_delete があります。

selfwrite-add および selfwrite-delete 属性レベルの権限は ACI のコンテキストには存在しませんが、ACI を組み合わせることで、追加だけ、または削除だけの変更操作を行う selfwrite 権限をユーザーに与えることができます。selfwrite 権限では、変更する属性の値は承認 DN になります。write 権限では、変更する属性の値は定義されないため、この区別は適用されません。

実行権限が targattrfilters ACI に依存する場合は、「?」の値によって、権限の詳細を確認するにはログ情報を参照する必要があることが示されます。write、selfwrite_add、selfwrite_delete 権限の相互依存関係は複雑です。表 6-3 は、この 3 つの権限の考えられる組み合わせと、それぞれの意味を示しています。

表 6-3 実効権限の相互依存関係
write	selfwrite_ add	selfwrite_ delete	実効権限の説明
0	0	0	この属性のどの値も追加、削除できない
0	0	1	承認 DN 値の削除だけが可能
0	1	0	承認 DN 値の追加だけが可能
0	1	1	承認 DN 値の追加、削除だけが可能
1	0	0	承認 DN 値を除くすべての値の追加、削除が可能
1	0	1	承認 DN 値を含むすべての値の削除と、承認 DN 値を除くすべての値の追加が可能
1	1	0	承認 DN 値を含むすべての値の追加と、承認 DN 値を除くすべての値の削除が可能
1	1	1	この属性のすべての値の追加、削除が可能
?	0	0	承認 DN 値を追加、削除することはできないが、その他の値を追加、削除できる可能性がある。書き込み権限の詳細を確認するには、ログ情報を調べる
?	0	1	承認 DN 値の削除は可能であるが、追加はできない。また、その他の値を追加、削除できる可能性がある。書き込み権限の詳細を確認するには、ログ情報を調べる
?	1	0	承認 DN 値の追加は可能であるが、削除はできない。また、その他の値を追加、削除できる可能性がある。書き込み権限の詳細を確認するには、ログ情報を調べる
?	1	1	承認 DN 値の追加、削除が可能。また、その他の値を追加、削除できる可能性がある。書き込み権限の詳細を確認するには、ログ情報を調べる

ログ情報

実効権限のログ情報を使用すると、アクセス制御の不具合について理解して、デバッグできるようになります。ログ情報には、acl_summary というアクセス制御の概要文が含まれ、アクセス制御が許可または拒否された理由を確認することができます。アクセス制御の概要文には次の情報が含まれています。

アクセスが許可されるか、拒否されるか

与えられている権限

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

ターゲット属性の名前

照会した権限のサブジェクト

照会がプロキシとして行われたかどうか (行われた場合はプロキシの認証 DN)

アクセスが許可または拒否される理由 (デバッグに重要)。考えられる理由については表 6-4 を参照

表 6-4 実効権限のログ情報に表示される理由とその説明
ログ情報に表示される理由	説明
no reason available	アクセスがどのような理由で許可または拒否されたのかは不明である
no allow acis	許可 ACI が存在しないため、アクセス拒否が返された
result cached deny	キャッシュされた情報を使用してアクセスの拒否が決定された
result cached allow	キャッシュされた情報を使用してアクセスの許可が決定された
evaluated allow	ACI の評価によってアクセスの許可が決定された。ACI の名前はログ情報に含まれる
evaluated deny	ACI の評価によってアクセスの拒否が決定された。ACI の名前はログ情報に含まれる
no acis matched the resource	リソースまたはターゲットと一致する ACI が存在しないため、アクセス拒否が返された
no acis matched the subject	アクセス制御を照会するサブジェクトと一致する ACI が存在しないため、アクセス拒否が返された
allow anyone aci matched anon user	userdn = "ldap:///anyone" サブジェクトが指定された ACI が存在するため、匿名ユーザーによるアクセスが許可された
no matching anyone aci for anon user	userdn = "ldap:///anyone" サブジェクトが指定された ACI が存在しないため、匿名ユーザーによるアクセスが拒否された
user root	ユーザーがルート DN であるため、アクセスが許可された



注	仮想属性は更新不可能であるため、仮想属性に対する書き込み権限は与えられません。また、それに関連するログ情報も記録されません。

高度なアクセス制御: マクロ ACI の使用

同じようなディレクトリツリー構造をいくつも持つ組織では、マクロによってディレクトリ内で使用する ACI の数を最適化できます。ディレクトリツリー内の ACI の数を減らすことによって、アクセス制御ポリシーの管理が簡単になり、ACI によるメモリ使用の効率が向上します。

マクロは、ACI の中で DN、または DN の一部を表現するために使用される可変部分です。マクロを使用すると、ACI のターゲット部分またはバインドルール部分、あるいはその両方の DN を表すことができます。実際の処理では、Directory Server が LDAP 操作を受け取ると、一致する部分文字列の存在を確認するために、LDAP 操作のターゲットとなるリソースに対して ACI マクロのマッチングが行われます。一致が検出された場合は、一致した部分文字列を使用してバインドルール側のマクロが展開され、その展開バインドルールを評価してリソースにアクセスします。

マクロ ACI の例

マクロ ACI の利点ともっとも効果的に機能させる方法を例を示しながら説明します。図 6-4 は、全体的な 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 ノード上に置かれています。

この ACI は、dc=hostedCompany1,dc=example,dc=com ツリー内のすべてのエントリに対する読み取り権限および書き込み権限を DomainAdmins グループに与えます。

次の ACI は、dc=hostedCompany1,dc=example,dc=com ノード上に置かれています。

次の ACI は、dc=subdomain1,dc=hostedCompany1, dc=example,dc=com ノード上に置かれています。

次の ACI は、dc=hostedCompany2,dc=example,dc=com ノード上に置かれています。

次の ACI は、dc=subdomain1,dc=hostedCompany2, dc=example,dc=com ノード上に置かれています。

前述の 4 つの ACI の違いは、groupdn キーワード内で指定されている DN だけです。DN 用のマクロを使用することによって、これらの ACI を、ルートツリーの dc=example,dc=com ノードに置かれた 1 つの ACI で置き換えることができます。この ACI は次のようになります。

ターゲットキーワードが未使用の場合は、これを設定する必要があります。

前述の例では、ACI の数が 4 つから 1 つに減っています。ただし、本当の利点は、ディレクトリツリー全体に複数の繰り返しパターンを含めることができることです。

マクロ ACI の構文

ここでは、わかりやすくするために、userdn、roledn、groupdn、userattr などのバインド資格を与えるために使用される ACI キーワードをまとめてサブジェクトと呼びます。サブジェクトは、ACI の適用対象を決定します。

マクロ ACI では、次のような式を使用して、DN または DN の一部を置き換えることができます。

($dn) - ターゲット内のマッチングと、サブジェクト内の直接置換

[$dn] - サブジェクトのサブツリーで機能する複数の RDN の置換

($attr.attributeName) - ターゲットエントリの attributeName 属性からサブジェクトへの置換

表 6-5 ACI キーワード中のマクロ
マクロ	ACI キーワード
($dn)	target、targetfilter、userdn、roledn、groupdn、userattr
[$dn]	targetfilter、userdn、roledn、groupdn、userattr
($attr.attrName)	userdn、roledn、groupdn、userattr

サブジェクトで ($dn) マクロおよび [$dn] マクロを使用するときは、($dn) マクロを含むターゲットを定義する必要があります。

サブジェクトで ($attr.attrName) マクロと ($dn) マクロを組み合わせることができますが、[$dn] マクロを組み合わせることはできません。

ターゲットでの ($dn) との一致

ACI のターゲットに含まれる ($dn) マクロは、LDAP 要求のターゲットとなるエントリとの比較によって、置換値を決定します。たとえば、cn=all,ou=groups,dc=subdomain1, dc=hostedCompany1,dc=example,dc=com エントリをターゲットとする LDAP 要求がある場合は、ターゲットを定義する ACI は次のようになります。

この場合、($dn) マクロは dc=subdomain1, dc=hostedCompany1 と一致します。この部分文字列は、ACI のサブジェクト内で置換値として使用されます。

サブジェクト内での ($dn) の置換

ACI のサブジェクト内では、($dn) マクロはターゲット内で一致する部分文字列全体に置き換えられます。たとえば、次のようにします。

マクロが展開されると、通常のプロセスに続いて Directory Server が ACI を評価し、アクセス権が与えられるかどうかを決定します。

サブジェクト内での [$dn] の置換


注	標準の ACI とは異なり、マクロ置換を使った ACI はターゲットエントリの子へのアクセスを許可する必要はありません。これは、子の DN がターゲットとなった場合に、置換によってサブジェクト文字列内に有効な DN が作成されない可能性があるためです。

[$dn] の置換メカニズムは ($dn) のものと少し異なります。ターゲットリソースの DN は数回にわたって確認されますが、一致する対象が見つかるまで、一番左にある RDN コンポーネントは外されます。

たとえば、cn=all,ou=groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com サブツリーをターゲットとする LDAP 要求で、次のような ACI があるとします。

サーバーは次のように処理を続け、この ACI を展開します。

ターゲットの ($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] を dc=hostedCompany1 で置き換えます。

この結果、サブジェクトは groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=example,dc=com" になります。バインド DN がこのグループのメンバーであるかどうかが再び検証され、メンバーである場合は ACI が完全に評価されます。メンバーでない場合は、マクロの展開は一致した値の最後の RDN で中止され、この ACI の ACI 評価は完了します。

[$dn] マクロの利点は、ドメインレベルの管理者に対して、ディレクトリツリー内のすべてのサブドメインへのアクセス権を柔軟な方法で与えることができることです。したがって、このマクロは、ドメイン間の階層的な関係を表す場合に便利です。

この 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 を定義できます。

ここで、サーバーが次のエントリをターゲットとする LDAP 操作を受け取ったとします。

ACI の roledn の部分を評価するために、サーバーはターゲットエントリの ou 属性の値を読み取り、サブジェクト内でこの値を置換してマクロを展開します。この例では、roledn は次のように展開されます。

続いて、通常の ACI 評価アルゴリズムに従って、Directory Server が ACI を評価します。

マクロ内で名前が指定された属性が複数の値を持つ場合は、それぞれの値を使用してマクロが展開され、最初にマッチングに成功した値が使用されます。

アクセス制御とレプリケーション

ACI は、エントリの属性として格納されます。したがって、レプリケートされるサフィックスの一部に ACI を含むエントリがあれば、ほかの属性と同じように ACI もレプリケートされます。

ACI の評価は、着信 LDAP 要求を実行する Directory Server 上で行われます。つまり、コンシューマサーバーが更新要求を受け取ると、その要求がマスター上で実行されるかどうかを評価する前に、コンシューマサーバーがマスターサーバーにリフェラルを返します。

アクセス制御と連鎖

ディレクトリツリーが連鎖によって複数のサーバー上に分散されている場合は、アクセス制御文で使用できるキーワードに特定の制約が適用されます。詳細は、「ACI の制限事項」を参照してください。

認証ユーザーが連鎖サフィックスにアクセスすると、サーバーはユーザーの ID をリモートサーバーに送信します。ここでのアクセス制御は、常にリモートサーバーで評価されます。リモートサーバーで評価される LDAP 操作では、プロキシ承認制御により渡されたクライアントアプリケーションのオリジナル ID が使用されます。ユーザーが、リモートサーバーに含まれるサブツリーに対して正しいアクセス制御を持っている場合にだけ、リモートサーバーで操作が成功します。つまり、リモートサーバーには、通常のアクセス制御を追加しておく必要があります。これには次のような制約があります。詳細は、「連鎖サフィックスのアクセス制御」を参照してください。

アクセス制御情報のログ

エラーログに記録されているアクセス制御に関する情報を取得するには、適切なログレベルを設定する必要があります。

コンソールからエラーログレベルを設定するには、次の手順を実行します。

Directory Server コンソールの最上位の「ディレクトリ」タブで cn=config ノードをマウスの右ボタンでクリックし、ポップアップメニューから「汎用エディタで編集」を選択します。

cn=config エントリの内容を表示した状態で汎用エディタが起動されます。

属性値の組み合わせリストをスクロールして、nsslapd-errorlog-level 属性を探します。

nsslapd-errorlog-level フィールドに表示されている値に 128 を加えます。

たとえば、8192 (レプリケーションデバッグ) という値が表示されている場合は、8320 に変更します。エラーログレベルについては、『Directory Server Administration Reference』を参照してください。

「了解」をクリックして変更を保存し、汎用エディタを閉じます。

以前のリリースとの互換性

Directory Server の以前のリリースで使用されていた一部の ACI キーワードは、Directory Server 5.2 ではお勧めできません。ただし、下位互換の観点から、これらのキーワードも引き続きサポートされています。対象となるキーワードを次に示します。

userdnattr

groupdnattr

このため、旧バージョンのサプライヤサーバーと Directory Server 5.2 のコンシューマの間にレプリケーションアグリーメントを設定する場合でも、ACI のレプリケーションに関する問題が発生することはありません。

前へ目次索引次へ
Sun Java™ System Directory Server 5 2004Q2 管理ガイド