前へ     目次     索引     DocHome     次へ     
iPlanet Directory Server 5.1 管理者ガイド



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


iPlanet Directory Server には、ディレクトリへのアクセスを制御する機能があります。この章では、アクセス制御のメカニズムについて説明します。

この章は、次の節で構成されています。

アクセス制御メカニズムの機能と柔軟性を活用するには、ディレクトリ導入の計画段階において、全体的なセキュリティポリシーの重要部分として、アクセス制御戦略を決定する必要があります。アクセス制御戦略のヒントについては、『iPlanet Directory Server 導入ガイド』を参照してください。



アクセス制御の原則



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

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


ACI の構造

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

ACI 文は 3 つの主要部分から構成されます。

  • ターゲット

  • アクセス権

  • バインド規則

ACI のアクセス権およびバインド規則部分はペアで設定され、ACR (アクセス制御規則) とも呼ばれます。指定されたアクセス権が与えられるか拒否されるかは、これに付随する規則が true であると判定されるかどうかによって決まります。


ACI の配置

ACI を含むエントリが子エントリを持たない場合は、ACI はそのエントリだけに適用されます。そのエントリが子エントリを持つ場合は、ACI はそのエントリと、そのエントリよりも下位にあるすべてのエントリに適用されます。結果的に、サーバが任意のエントリに対するアクセス権を評価するときは、要求されたエントリとディレクトリ接尾辞の間にあるすべてのエントリの ACI と、そのエントリ自身の ACI を確認します。

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

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

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



 

ルート DSE エントリに置かれた ACI は、そのエントリだけに適用されます。  




ACI の評価

特定のエントリに対するアクセス権を評価する場合は、サーバによって、そのエントリ上と、Directory Server に格納された最上位レベルエントリにバックアップされる親エントリの ACI のリストが作成されます。評価中に、この順番でサーバにより ACI が処理されます。ACI の評価は、特定の Directory Server のすべてのデータベースが対象ですが、複数の Directory Server にわたる評価は行われません。

複数の ACI 間の優先規則は、アクセスを許可する ACI よりもアクセスを拒否する ACI の方が優先するということだけです。アクセスを許可する複数の ACI 間では、和集合の演算が適用され、サーバは、ターゲットエントリに近い ACI から先に処理されたとしても、各 ACI 間の処理に優先規則はありません。

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


ACI の制限事項

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

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

    • グループエントリ (groupdn キーワード) に依存する ACI は、グループエントリと同じサーバ上に置く必要がある。そのグループが動的である場合は、そのメンバーすべても同じサーバ上にエントリを持つ必要がある。グループが静的である場合は、リモートサーバ上にメンバーのエントリを置くことができる

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

    ただし、ターゲットエントリに格納された値と、バインドユーザのエントリに格納された値のマッチングは可能です (userattr キーワードなどを使用)。ACI を持つサーバ上にバインドユーザがエントリを持っていない場合も、通常どおりにアクセスに対する評価が行われます。

    アクセス制御の評価を連続して行う方法については、「データベースリンクとアクセス制御の評価」を参照してください。

  • CoS によって作成された属性を、すべての ACI キーワードで使用できるわけではない。特に、アクセス制御規則が機能しないため、userattrキーワードによって CoS で作成した属性を使用しないこと。このキーワードについての詳細は、「userattr キーワードの使用」を参照。CoS についての詳細は、第 5 章「高度なエントリの管理」を参照。

  • アクセス制御規則の評価は、常にローカルサーバ上で行われる。したがって、ACI キーワードで使用される LDAP URL で、サーバのホスト名やポート番号を指定する必要はない。指定しても、LDAP URL は無視される。LDAP URL については、付録 C「LDAP URLs」を参照。

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



デフォルト ACI

Directory Server をインストールすると、userRoot データベースに格納されたディレクトリ情報に次のデフォルト ACI が適用されます。

  • ユーザは、ディレクトリ内にある個人のエントリを変更できるが、削除はできない。aci 属性と nsroledn 属性は変更できません。

  • ユーザは、ディレクトリに匿名でアクセスして、検索、比較、および読み込み操作を行うことができる

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

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

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

  • SIE グループ

ディレクトリに新しいデータベースを作成すると、最初のエントリには必ず前述のデフォルト ACI が置かれます。

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

  • 構成管理者グループのすべてのメンバーには、プロキシ権限以外のすべての NetscapeRoot サブツリーでの権限が与えられる

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

  • グループの展開

  • 認証されたすべてのユーザには、管理サーバを識別する構成属性に対する検索、比較、および書き込みの権限が与えられる

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



手動による ACI の作成



LDIF 文を使用してアクセス制御命令を手動で作成し、ldapmodify ユーティリティを使用してその命令をディレクトリツリーに追加できます。次の節では、LDIF 文の作成方法について詳しく説明します。



ヒント  

LDIF ACI 文は、非常に複雑になることがあります。ただし、多数のディレクトリエントリに対してアクセス制御を設定する場合は、Console よりも LDIF を使用する方が時間を節約できるので、LDIF をお勧めします。

ただし、LDIF ACI 文に慣れるために、Directory Server Console を使用して、ACI を設定後、アクセス制御エディタの「Edit Manually (手動での編集)」ボタンをクリックするということもできます。正しい LDIF 構文が表示されます。また、オペレーティングシステムが対応している場合は、アクセス制御エディタから LDIF をコピーし、作成中の LDIF ファイルに貼り付けることもできます。  




ACI の構文

aci 属性の構文は次のとおりです。

aci(target)(version 3.0;acl "name";permission bind_rules;)

各要素の意味は次のとおりです。

  • target は、アクセス制御の対象となるエントリ、属性、またはエントリと属性のセットを指定する。ターゲットには、識別名、1 つ以上の属性、または 1 つの LDAP フィルタを指定できる。ターゲット部分は省略可

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

  • "name" は、ACI の名前。名前には、ACI を識別する任意の文字列を適用することができる。ACI 名は省略不可。

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

  • bind_rules は、ユーザがアクセス権を与えられるために必要な資格およびバインドパラメタを指定する。また、バインド規則により、特定のユーザまたはユーザグループへのアクセスを拒否できる

各ターゲットには、複数のアクセス権とバインド規則のペアを設定できます。これによって、ターゲットに対して、複数のアクセス制御を効率的に設定できます。たとえば、次のようにします。

target(permission bind_rule)(permission bind_rule)...

1 つの ACI 文中にいくつかの ACR がある場合は、その構文は次のような形式になります。

aci(target)(version 3.0;acl "name"; permission bind_rule;
permission bind_rule; ... permission bind_rule;)


ACI の例

LDIF ACI の例を次に示します。

aci (target="ldap:///uid=bjensen,dc=siroe,dc=com")(targetattr=*)
(version 3.0; acl "aci1"; allow (write) userdn="ldap:///self";)

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

次の節では、ACI の各部の構文について詳しく説明します。


ターゲットの定義

ターゲットは、ACI の適用対象を指定します。ターゲットを指定しないと、ACI は aci 属性を含むエントリおよびその下位のエントリに適用されます。

ターゲットとして、次のものを指定できます。

ターゲットの一般的な構文は次のとおりです。

(keyword = "expression")

(keyword != "expression")

各オプションは、次のように指定します。

    • keyword は、ターゲットのタイプを示す

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

    • expression はターゲットを示す

expression を囲む引用符 ("") は、省略できません。expression の形式は、ユーザが指定する keyword によって異なります。

次の表に、各キーワードとそれに対応する式を示します。


表 6-1 LDIF ターゲットキーワード

キーワード

有効な式

ワイルドカード
使用の可否

ターゲット  

ldap:///distinguished_name  

 

targetattr  

属性  

 

targetfilter  

LDAP_filter  

 

targattrfilters  

LDAP_operation:LDAP_filter  

 

いずれの場合も、エントリに ACI を置くと、そのエントリが最下位のエントリでない限り、下位のエントリすべてにもその ACI が適用されます。たとえば、ou=accounting,dc=siroe,dc=com というエントリをターゲットにした場合は、設定するアクセス権は、siroe.com ツリーの accounting 分岐にあるすべてのエントリに適用されます。ただし、accounting ツリーの下にない uid=sarette,ou=people,dc=siroe,dc=com エントリには適用されません。


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

ディレクトリエントリ (およびその下位のエントリ) をターゲットとして指定するには、target キーワードを使用する必要があります。

target キーワードには、次の形式の値を適用することができます。

target="ldap:///distinguished_name"

これは、アクセス制御規則が適用されるエントリの識別名を示します。たとえば、次のようにします。

(target = "ldap:///uid=bjensen,dc=siroe,dc=com")



 

アクセス制御規則を適用するエントリの DN にコンマが含まれる場合は、1 つのバックスラッシュ (\) を使用して、コンマをエスケープする必要があります。たとえば、次のようにします。 (target="ldap:///uid=lfuentes,o=siroe.com
Bolivia\, S.A.")

 



target キーワードで識別名をターゲットとして指定する場合は、ワイルドカードを使用することもできます。ワイルドカードは、任意の文字、文字列、または部分文字列がそのワイルドカードにマッチすることを示します。パターンマッチングの基本は、ワイルドカードで指定された任意の文字列です。

次に、ワイルドカードの正しい使用例を示します。

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

    siroe.com ツリー内のエントリで、その RDN 内に uid 属性を含むすべてのエントリを示します。

  • (target="ldap:///uid=*Anderson,dc=siroe,dc=com")

    siroe.com ノードの下にあるエントリで、uid の最後に Anderson が付くすべてのエントリを示します。

  • (target="ldap:///*Anderson,dc=siroe,dc=com")

    siroe.com ノードの下にあるエントリで、RDN の最後に Anderson が付くすべてのエントリを示します。

DN の一部にワイルドカードを使用することができます。たとえば、uid=andy*,dc=siroe,dc=com は、これにマッチする uid 属性を持つ siroe.com ツリー全体のディレクトリエントリをターゲットとして指定できます。これは、 dc=siroe,dc=com ノードの直下にあるエントリに限りません。このターゲットは、次の両方の式にマッチします。

uid=andy,ou=eng,dc=siroe,dc=com
uid=andy,ou=marketing,dc=siroe,dc=com
.

uid=*,ou=*,dc=siroe,dc=com のように、複数のワイルドカードを使用できます。この例は、識別名に uidou の両方の属性を含む、siroe.com ツリーのすべてのエントリとマッチします。したがって、次の式にマッチします。

uid=fchen,ou=Engineering,dc=siroe,dc=com
uid=claire,ou=Engineering,ou=people,dc=siroe,dc=com

ただし、次の式にはマッチしません。

uid=bjensen,dc=siroe,dc=com
ou=Engineering,dc=siroe,dc=com



 

識別名の接尾辞部分には、ワイルドカードを使用できません。つまり、ディレクトリの接尾辞が c=USc=GB である場合に、両方の接尾辞を参照させる次のようなターゲットは使用できません。 (target="ldap:///dc=siroe,c=*")

また、uid=bjensen,dc=*.com のようなターゲットも使用できません。  




属性のターゲット指定

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

また、ターゲットが特定の属性と等しい、または等しくないという指定ができます。ここで指定する属性は、スキーマで定義されている必要はありません。スキーマの検査を行わないことにより、作成する ACL が現在のディレクトリの内容に適用されない場合でも、はじめてディレクトリサービスを設定するときにアクセス制御ポリシーを実装できます。

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

(targetattr = "attribute")

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

(targetattr = "attribute1 || attribute2 ... || attributen")

ここで、attribute は、ターゲットとして指定する属性名です。

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

(targetattr = "cn || sn || uid")

targetattr キーワードで指定された属性は、ACI のターゲットになっているエントリと、その下位にあるすべてのエントリに適用されます。つまり、uid=bjensen,ou=Marketing,dc=siroe,dc=com というエントリ上でパスワード属性をターゲットとして指定する場合、ACI の影響を受けるのは、bjensen エントリ上のパスワード属性だけです。これは、bjensen が最下位のエントリであるためです。

ただし、ツリーの分岐点ou=Marketing,dc=siroe,dc=comをターゲットに指定すると、パスワード属性を含むことができる分岐点より下位のすべてのエントリが ACI によって影響を受けることになります。

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


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

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

aci: (targetattr = "uid")(access_control_rules;)

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

aci: (target="ldap:///ou=Marketing, dc=siroe,dc=com")
(targetattr="uid") (
access_control_rules;)

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


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

LDAP フィルタを使用して、一定の基準にマッチするエントリのグループをターゲットとして指定できます。このためには、LDAP フィルタとともに targetfilter を使用する必要があります。

targetfilter キーワードの構文は次のとおりです。

(targetfilter = "LDAP_filter")

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

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

(targetfilter = "(|(employment=contractor)(fulltime<=99))")



 

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

 



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

次の例に示す LDIF では、Engineering Admins グループのメンバーは、engineering 部門のすべてのエントリの departmentNumber 属性と manager 属性を変更できます。この例では、LDAP フィルタを使用して、businessCategory 属性の値が Engineering に設定されたすべてのエントリを選択しています。

dn:dc=siroe,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=siroe,dc=com";)



ヒント  

ディレクトリ内に分散したエントリおよび属性をターゲットとして指定する場合に LDAP フィルタを使用すると便利ですが、アクセス管理の対象となるオブジェクトを直接フィルタが指定するわけではないため、思わぬ結果を招くことがあります。フィルタを適用した ACI のターゲットとなるエントリセットは、属性の追加や削除に応じて変化することがあります。したがって、ACI で LDAP フィルタを使用する場合は、ldapsearch 操作で同じフィルタを使用して、適切なエントリと属性がターゲットとして指定されていることを確認する必要があります。  




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

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

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

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

(targattrfilters="add=attr1:F1 && attr2:F2... && attrn:Fn,
                  del=
attr1:F1 && attr2:F2 ... && attrn:Fn")

各オプションは、次のように指定します。

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

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

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

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

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

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

たとえば、次のような属性フィルタがあるとします。

(targattrfilters="add=nsroleDN:(!(nsRoleDN=cn=superAdmin)) && telephoneNumber:(telephoneNumber=123*)")

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



 

Server Console を使用して値基準の ACI を作成することはできません。  




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

単一のディレクトリエントリをターゲットとして指定することは、アクセス制御メカニズムの設計ポリシーに反するので、容易ではありません。ただし、次の方法で指定することは可能です。

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

  • targetattr および targetfilter キーワードを使用する

targetattr キーワードを使用すると、ターゲットとして指定するエントリだけに含まれ、その下位のエントリには含まれない属性を指定できます。たとえば、ou=people,dc=siroe,dc=com をターゲットとして指定するときに、そのノードの下位に組織単位 (ou) が定義されていない場合は、次の指定を含む ACI を定義できます。

targetattr=ou

より確実な方法としては、argetfilter キーワードを使用して、そのエントリだけに含まれる属性値を明示的に指定する方法があります。たとえば、Directory Server をインストールすると、次の ACI が作成されます。

aci: (targetattr="*")(targetfilter=(o=NetscapeRoot)) (version 3.0; acl "Default anonymous access"; allow (read, search) userdn="ldap:///anyone";)

この ACI は、o=NetscapeRoot エントリだけに適用されます。

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


アクセス権の定義

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

アクセス権の設定には、2 つの手順が必要です。

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

  • 権限の割り当て


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

ディレクトリツリーに対するアクセス権は、明示的に許可または拒否できます。どのようなときにアクセスを許可または拒否するかのガイドラインについては、『iPlanet Directory Server 導入ガイド』を参照してください。



 

Server Console を使用して明示的にアクセスを拒否することはできませんが、アクセス権を与えることはできます。  




権限の割り当て

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

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

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

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

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

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

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

Selfwrite (本人による書き込み):. グループに対する個人の DN の追加や削除を、ユーザ自身によって実行できるかどうかを示します。このアクセス権は、グループ管理専用です。Selfwrite (本人による書き込み) は、プロキシ認証で使用できます。グループ エントリからプロキシ DN を追加または削除するアクセス権を与えます(バインドユーザの DN とは異なる)。

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

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

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


LDAP 操作に必要な権限

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

エントリを追加する場合

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

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

エントリを削除する場合

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

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

エントリの属性を修正する場合

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

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

エントリの RDN を修正する場合

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

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

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

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

属性値を比較する場合

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

エントリを検索する場合

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

  • エントリで使用される属性タイプに対する読み取りアクセス権

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

% ldapsearch -h host -s base -b "uid=bjensen,dc=siroe,dc=com" objectclass=* mail

bkolics というユーザにアクセス権を与えるかどうかは、次に示す ACI を使用して決定します。

aci: (targetattr = "mail")(version 3.0; acl "self access to mail"; allow (read, search) userdn = "ldap:///self";)

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

aci: (targetattr = "mail || objectclass")(version 3.0; acl "self access to mail"; allow (read, search) userdn = "ldap:///self";)


アクセス権の構文

ACI 文におけるアクセス権の構文は、次のとおりです。

allow|deny (rights)

ここで、rights は 1 〜 8 個のキーワードのリストです。キーワードは、コンマで区切り、カッコでくくります。使用できるキーワードは、readwriteadddeletesearchcompareselfwrite、 proxy、または all です。

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

aci: (target="ldap:///dc=siroe,dc=com") (version 3.0; acl "example";
allow (read, search, compare) bind_rule ;)



バインド規則



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

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

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

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

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

  • エンティティがバインドを開始する位置

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

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

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

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


バインド規則の構文

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

keyword = "expression";

keyword!= "expression";

等号 (=) は、バインド規則を true とするには keywordexpression がマッチしなければならないことを示し、非等号 (!=) は、バインド規則を true とするには keywordexpression がマッチしてはならないことを示します。



 

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 || DN  

不可  

roledn  

ldap:///DN || 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 つ以上の有効な識別名が必要です。書式は次のとおりです。

userdn = "ldap:///dn [|| ldap:///dn]...[||ldap:///dn]"

ここで、dn は DN、または anyoneallselfparent の 1 つです。

userdn = "ldap:///anyone" : 匿名によるアクセスを定義

userdn = "ldap:///all" : 汎用アクセスを定義

userdn = "ldap:///self" : 自己アクセスを定義

userdn = "ldap:///parent" : 親エントリへのアクセスを定義

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

ldap:///suffix??sub?(filter)



 

DN にコンマが含まれる場合は、コンマの前にエスケープ文字のバックスラッシュ (\) を付けて区別する必要があります。  




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

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

匿名アクセスは、アクセス制御エディタを使用してServer Consoleから定義します。「Console を使用した ACI の作成」を参照してください。


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

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

匿名アクセスは、アクセス制御エディタを使用して Server Console から定義します。詳細は、「Console を使用した ACI の作成」を参照してください。


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

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

自己アクセスは、アクセス制御エディタを使用して Server Console から設定します。詳細は、「Console を使用した ACI の作成」を参照してください。


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

ユーザのバインド DN がターゲットエントリの親である場合に限り、ユーザはエントリに対するアクセスを許可または拒否されます。

親アクセス制御は、Server Console では設定できません。


LDAP URL

フィルタ付きの URL を使用すると、次のように ACI 内で動的にユーザを指定できます。

userdn = "ldap:///<suffix>??sub?(filter)"

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

userdn = "ldap:///dc=siroe,dc=com??sub?(|(ou=engineering)(ou=accounting))"



 

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



LDAP URL についての詳細は、付録 C「LDAP URLs」を参照してください。


ワイルドカード

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

ユーザアクセスは、アクセス制御エディタを使用して Server Console から設定します。詳細は、「Console を使用した ACI の作成」を参照してください。




この節では、userdn 構文の例を示します。

LDAP URL を含む userdn キーワード

userdn = "ldap:///uid=*,dc=siroe,dc=com";

ユーザが、指定されたパターンの任意の識別名を使用してディレクトリにバインドすると、バインド規則は true であると判定されます。たとえば、次に示すバインド DN は、両方とも true と判定されます。

uid=ssarette,dc=siroe,dc=com
uid=tjaz,ou=Accounting,dc=siroe,dc=com

一方、次に示すバインド DN は、false と判定されます。

cn=Babs Jensen,dc=siroe,dc=com

LDAP URL の論理 OR を含む userdn キーワード

userdn="ldap:///uid=bj,c=siroe.com || ldap:///uid=kc,dc=siroe,dc=com";

クライアントが、与えられた 2 つの識別名のどちらかとしてバインドすると、バインド規則は true と判定されます。

特定の LDAP URL を含まない userdn キーワード

userdn != "ldap:///uid=*,ou=Accounting,dc=siroe,dc=com";

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

self キーワードを含む Userdn キーワード

userdn = "ldap:///self";

ユーザが、ディレクトリにバインドするための DN で表されるエントリにアクセスすれば、バインド規則は true と判定されます。つまり、ユーザが uid=ssarette, dc=siroe,dc=com としてバインドし、uid=ssarette,dc=siroe,dc=com エントリで操作を試行すれば、バインド規則は true と判定されます。

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

aci: (targetattr = "userPassword") (version 3.0;
 acl "write-self"; allow (write) userdn = "ldap:///self";)

all キーワードを含む Userdn キーワード

userdn = "ldap:///all";

バインド DN が有効なものであれば、バインド規則は true であると判定されます。true と判定されるには、バインド操作中にユーザが有効な識別名とパスワードを入力する必要があります。

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

aci: (version 3.0; acl "all-read"; allow (read)
 userdn="ldap:///all";)

anyone キーワードを含む userdn キーワード

userdn = "ldap:///anyone";

すべてのユーザに対して、バインド規則は true と判定されます。ディレクトリへの匿名アクセスを許可する場合は、このキーワードを使用します。

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

aci: (version 3.0; acl "anonymous-read-search";
 allow (read, search) userdn = "ldap:///anyone";)

parent キーワードを含む userdn キーワード

userdn = "ldap:///parent";

バインド DN がターゲットエントリの親であれば、バインド規則は true と判定されます。

たとえば、すべてのユーザの子エントリに書き込みアクセス権を与える場合は、次に示す ACI を dc=siroe,dc=com ノードに作成します。

aci: (version 3.0; acl "parent access";
 allow (write) userdn="ldap:///parent";)

userdn = "ldap:///dc=siroe,dc=com???(|(ou=engineering)(ou=sales))";

ユーザが engineering または sales サブツリーに属していれば、バインド規則は true と判定されます。


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

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

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

groupdn="ldap:///dn [|| ldap:///dn]...[|| ldap:///dn]"

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



 

DN にコンマが含まれる場合、1 つのバックスラッシュ (\) を使用してコンマをエスケープする必要があります。  



指定グループは、アクセス制御エディタを使用して Server Console から定義します。詳細は、「Console を使用した ACI の作成」を参照してください。




この節では、groupdn 構文の例を示します。

LDAP URL を含む groupdn キーワード

groupdn = "ldap:///cn=Administrators,dc=siroe,dc=com";

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

aci: (version 3.0; acl "Administrators-write"; allow (write)
 groupdn="ldap:///cn=Administrators,dc=siroe,dc=com";)

LDAP URL の論理 OR を含む groupdn キーワード

groupdn = "ldap:///cn=Administrators,dc=siroe,dc=com" ||
"ldap:///cn=Mail Administrators,dc=siroe,dc=com";

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


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

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

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

roledn = "ldap:///dn [|| ldap:///dn]... [|| ldap:///dn]"

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



 

DN にコンマが含まれる場合、1 つのバックスラッシュ (\) を使用してコンマをエスケープする必要があります。  



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


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

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

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

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


userattr キーワードの使用

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

次のタイプを指定できます。

  • ユーザ DN

  • グループ DN

  • ロール DN

  • LDAP フィルタ (LDAP URL 内)

  • 任意の属性タイプ

userattr キーワードの LDIF 構文は次のとおりです。

userattr = "attrName#bindType"

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

userattr = "attrName#attrValue"

各オプションは、次のように指定します。

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

  • bindType は、USERDN,GROUPDN,LDAPURL の一つです。

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



     

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



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


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

userattr = "manager#USERDN"

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

次の例では、マネージャは社員のエントリに対するフルアクセス権が与えられています。

aci: (target="ldap:///dc=siroe,dc=com")(targetattr=*)(version 3.0;
 acl "manager-write"; allow (all) userattr = "manager#USERDN";)


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

userattr = "owner#GROUPDN"

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

ポイントするグループを動的なグループにすることも、グループの DN をデータベース内の任意の接尾辞の下に置くこともできます。ただし、サーバでこのタイプの ACI を評価するには、多くの資源を必要とします。

ターゲットエントリと同じ接尾辞の下にある静的グループを使用する場合は、次の式を使用します。

userattr = "ldap:///dc=siroe,dc=com?owner#GROUPDN"

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


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

userattr = "siroeEmployeeReportsTo#ROLEDN"

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



 

この例は、スキーマに siroeEmployeeReportsTo 属性が追加されていて、すべての社員のエントリにこの属性が含まれていることを前提としています。また、この属性値がロールエントリの DN であることも前提です。

スキーマデザインについては、『iPlanet Directory Server 導入ガイド』を参照してください。スキーマへの属性の追加については、「属性の作成」を参照してください。  



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

静的ロール定義を使用するときに、ロールエントリがターゲットエントリと同じ接尾辞の下にある場合は、次の式を使用します。

userattr = "ldap:///dc=siroe,dc=com?employeeReportsTo#ROLEDN"

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


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

userattr = "myfilter#LDAPURL"

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


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

userattr = "favoriteDrink#Beer"

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


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

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

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

userattr = "parent[inheritance_level].attrName#bindType"

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

userattr = "parent[inheritance_level].attrName#attrValue"

ここで :

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

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

  • bindType は、USERDN,GROUPDN,LDAPURL の一つです。

次に例を示します。

userattr = "parent[0,1].manager#USERDN"

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


userattr の継承を含む例
次の図は、bjensen というユーザが、cn=Profiles エントリ、および cn=mailcn=news を含む 1 レベル下の子エントリに対して、読み取りと検索を許可された例を示しています。つまり、このユーザは、自身のメールとニュース ID をすべて検索できます。

図 6-1    userattr キーワードでの継承の使用


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

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

  • cn=mail および cn=news エントリに対して owner 属性を追加し、その値を bjensen にする。さらに cn=mail および cn=news エントリに次の ACI を追加する

    aci: (targetattr="*") (version 3.0; acl "profiles access"; allow (read,search) userattr="owner#USERDN";)


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

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

次のような例を想定します。

aci: (target="ldap:///dc=siroe,dc=com")(targetattr=*) (version 3.0;
 acl "manager-write"; allow (all) userattr = "manager#USERDN";)

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

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

dn: cn= Trojan Horse,ou=Human Resources,dc=siroe,dc=com
objectclass: top
...
cn: Trojan Horse
manager: cn=Joe,ou=eng,dc=siroe,dc=com

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

aci: (target="ldap:///dc=siroe,dc=com")(targetattr=*)
(version 3.0; acl "parent-access"; allow (add)
userattr = "parent[0,1].manager#USERDN";)

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


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

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

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

ip = "IP_address" or ip != "IP_address"

IP アドレスは必ずドット表記で示します。ワイルドカード文字 (*) を使用して、複数のマシンを指定することもできます。たとえば、次のように指定できます。

ip = "12.123.1.*";

ディレクトリにアクセスするクライアントが指定された IP アドレスを持っていれば、バインド規則は true と判定されます。この方法は、一部のディレクトリへのアクセス元を、特定のサブネットまたはマシンに制限する場合に有効です。

たとえば、12.3.45.* などのワイルドカード IP アドレス を使用して、特定のサブネットワークを指定したり、123.45.6.*+255.255.255.115 などを使用して、サブネットワークマスクを指定したりできます。

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


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

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

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

dns = "DNS_Hostname" or dns != "DNS_Hostname"



警告  

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



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

dns = "legend.eng";

名前は、絶対パスで指定します。

dns = "legend.eng.siroe.com";

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

dns = "*.siroe.com";

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


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

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

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

timeofday operator "time"

operator には、次のどれかを指定できます。等号 (=)、非等号 (!=)、大なり記号 (>)、大きいまたは等しい (>=)、小なり記号 (<)、小さいまたは等しい (<=)。

timeofday キーワードでは、24 時間法による「時」と「分」で、時刻を表します (0 〜 2359)。



 

評価にはクライアント上の時刻ではなく、サーバ上の時刻が使用されます。  



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

dayofweek = "day1, day2 ..."

dayofweek キーワードの値には、アルファベット 3 文字で示される曜日の略号が使用されます。(sun, mon, tue, wed, thu, fri, sat)




次に、timeofday および dayofweek 構文の例を示します。

timeofday = "1200";

クライアントが正午ちょうどにディレクトリにアクセスすると、バインド規則は true と判定されます。

timeofday != "0100";

クライアントが午前 1 時以外の任意の時刻にディレクトリにアクセスすると、バインド規則は true と判定されます。

timeofday > "0800";

クライアントが午前 8 時を過ぎてからディレクトリにアクセスすると、バインド規則は true と判定されます。

timeofday < "1800";

クライアントが午後 6 時前にディレクトリにアクセスすると、バインド規則は true と判定されます。

timeofday >= "0800";

クライアントが午前 8 時以後にディレクトリにアクセスすると、バインド規則は true と判定されます。

timeofday <= "1800";

クライアントが午後 6 時以前にディレクトリにアクセスすると、バインド規則は true と判定されます。

dayofweek = "Sun, Mon, Tue";

クライアントが日曜日、月曜日、または火曜日にディレクトリにアクセスすると、バインド規則は true と判定されます。


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

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

  • None:認証は不要です。この値がデフォルトです。匿名アクセスを表します。

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

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

    SSL の場合は、接続は LDAPS の 2 番目のポートに確立されます。TLS の場合は、Start TLS 操作によって接続が確立されます。どちらの場合も証明書が必要です。SSL 設定については、第 11 章「SSL の管理」を参照してください。

  • SASL : クライアントは、SASL (Simple Authentication and Security Layer) 接続を経由して、ディレクトリにバインドする必要があります。iPlanet Directory Serverには SASL モジュールはありません。

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

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

authmethod = "authentication_method"

ここで、authentication_method は、nonesimplessl、または "sasl sasl_mechanism" です。




次にauthmethod キーワードの例を示します。

authmethod = "none";

バインド規則の評価時に認証検査は行われません。

authmethod = "simple";

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

authmethod = "ssl";

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

authmethod = "sasl DIGEST-MD5";

クライアントが SASL DIGEST-MD5 メカニズムを使用してディレクトリ にアクセスすると、バインド規則は true と判定されます。このほかにも EXTERNAL という SASL メカニズムがサポートされています。


論理型バインド規則の使用

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

ブール型バインド規則の LDIF 構文は、次のとおりです。

bind_rule [boolean][bind_rule][boolean][bind_rule]...;)

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

(groupdn = "ldap:///cn=administrators,dc=siroe,dc=com" or
groupdn = "ldap:///cn=mail administrators,dc=siroe,dc=com" and
dns = "*.siroe.com";)

最後のセミコロン (;) は省略できません。この区切り文字は、最後のバインド規則の後に付ける必要があります。

ブール式は、次の順序で評価されます。

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

  • すべての式を左から右へ

  • AND または OR 演算子の前に NOT

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

次のようなブール型バインド規則があるとします。

(bind_rule_A) OR (bind_rule_B)

(bind_rule_B) OR (bind_rule_A)

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

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

(bind_rule_A) AND NOT (bind_rule_B)

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



Console を使用した ACI の作成



Directory Server Console を使用すると、ディレクトリに対するアクセス制御命令を表示、作成、編集、および削除できます。この節では、次の作業の一般的な手順について説明します。

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

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


アクセス制御エディタの表示

  1. Directory Server Console を起動します。特権ユーザのバインド DN とパスワードを使用してログインします。特権ユーザとは、ディレクトリに対して構成された ACI への書き込みアクセス権を持つディレクトリマネージャなどです。

    手順については、「Directory Server Console の使用」を参照してください。

  2. Directory Server Console で「Directory (ディレクトリ)」タブを選択します。

  3. ナビゲーションツリーで、アクセス制御を設定するエントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択します。あるいは、エントリを選択して、「オブジェクト」メニューから「Set Access Permissions (アクセス権の設定)」を選択します。

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

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

図 6-2    「Access Control Management (アクセス制御の管理)」ダイアログボックス


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

図 6-3    「Access Control Editor (アクセス制御エディタ)」ダイアログボックス


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

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


現在の ACI の表示

ディレクトリ内の特定のサブツリーに適用される ACI を表示するには、次の手順を実行します。

  1. 「Directory (ディレクトリ)」タブで、サブツリーの一番上のエントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択します。

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウが表示されます。このウィンドウには、そのエントリに属する ACI のリストが表示されます。

  2. 選択したエントリに適用されるすべての ACI を表示する場合は、「Show Inherited ACIs (継承された ACI の表示)」チェックボックスを選択します。


新しい ACI の作成

新しい ACI を作成するには、次の手順を実行します。

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

    この手順については、「アクセス制御エディタの表示」を参照してください。

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

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

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

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

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

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

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

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

    3. 「OK」をクリックして、「Add Users and Groups (ユーザおよびグループの追加)」ウィンドウを閉じます。

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

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

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

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

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

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

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

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

  7. 「Times (時間)」タブをクリックして、アクセス権が与えられる時刻のテーブルを表示します。

    デフォルトでは、いつでもアクセス権が与えられます。テーブル上でカーソルを操作し、時刻をクリックしてドラッグすることによって、アクセス時間を修正できます。連続していない時間帯を選択することはできません。

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

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



     

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




ACI の編集

ACI を編集するには、次の手順を実行します。

  1. 「Directory (ディレクトリ)」タブで、サブツリーの一番上のエントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択します。

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウが表示されます。このウィンドウには、そのエントリに属する ACI のリストが表示されます。

  2. 「Access Control Manager (アクセス制御マネージャ)」ウィンドウで、編集する ACI を選択し、「Edit (編集)」をクリックします。

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

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

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

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


ACI の削除

ACI を削除するには、次の手順を実行します。

  1. 「Directory (ディレクトリ)」タブで、サブツリーの一番上のエントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択します。

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウが表示されます。このウィンドウには、そのエントリに属する ACI のリストが表示されます。

  2. 「Access Control Manager (アクセス制御マネージャ)」ウィンドウで、削除する ACI を選択します。

  3. 「Remove (削除)」をクリックします。

    削除した ACI は、アクセス制御マネージャに表示されなくなります。



アクセス制御の使用例

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

siroe.com 社の業務は、Web ホスティングサービスとインターネットアクセスの提供です。siroe.com 社の Web ホスティングサービスには、クライアント企業のディレクトリのホスト業務も含まれます。同社は、Company333 および Company999 という 2 つの中規模企業のディレクトリのホスティングと管理の一部を担当しています。また、多数の個人加入者にインターネットへのアクセスを提供しています。

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


匿名アクセスの許可

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

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


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

aci: (targetattr !="userPassword")(version 3.0; acl "Anonymous Siroe"; allow (read, search, compare) userdn= "ldap:///anyone" and dns="*.siroe.com";)

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

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

  1. 「Directory (ディレクトリ)」タブの左側のナビゲーションツリーで siroe.com ノードをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択してアクセス制御マネージャを表示します。

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

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

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

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

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

  6. 「Host (ホスト)」タブの「Add (追加)」をクリックし、「DNS host filter (DNS ホストフィルタ)」フィールドに「*.siroe.com」と入力します。「OK」をクリックしてダイアログボックスを閉じます。

  7. 「Access Control Editor (アクセス制御エディタ)」ウィンドウの「OK」ボタンをクリックします。

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウの ACI リストに、新しい ACI が追加されます。


ACI "Anonymous World"
個人契約者サブツリーの読み取りおよび検索アクセス権を世界中に与え、非公開契約者の情報へのアクセスを拒否するには、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=siroe, dc=com エントリに追加することを仮定しています。また、各契約者のエントリには、yes または no の値を持つ unlistedSubscriber 属性が設定されているものとします。非公開契約者は、この属性値に基づいて、ターゲット定義のフィルタによって除外されます。フィルタ定義については、「フィルタを使用したターゲットの設定」を参照してください。

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

  1. 「Directory (ディレクトリ)」タブの左側のナビゲーションツリーで siroe.com ノードの下にある Subscribers エントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択してアクセス制御マネージャを表示します。

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

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

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

  5. 「Targets (ターゲット)」タブで「This Entry (このエントリ)」をクリックすると、ターゲットディレクトリの入力フィールドに接尾辞 dc=subscribers, dc=siroe,dc=com が表示されます。

    1. 「filter for subentries (サブエントリのフィルタ)」フィールドに、次のフィルタを入力します。

      (!(unlistedSubscriber=yes))

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

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

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

    「 Access Control Manager (アクセス制御マネージャ)」ウィンドウの ACI リストに、新しい ACI が追加されます。


ユーザエントリへの書き込みアクセス権の許可

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

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


ACI "Write siroe.com"



 

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



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

aci: (targetattr="userPassword || homePhone || homePostalAddress") (version 3.0; acl "Write siroe.com"; allow (write) userdn= "ldap:///self" and dns="*.siroe.com";)

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

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

  1. 「Directory (ディレクトリ)」タブの左側のナビゲーションツリーで siroe.com ノードをマウスの右ボタンでクリックし、「Access Control Manager (アクセス権の設定)」を選択してアクセス制御マネージャを表示します。

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

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

    1. 「All Users (すべてのユーザ)」を選択して削除し、「Add (追加)」をクリックします。

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

    2. 「Search area (検索領域)」を「Special Rights (特殊権限)」に設定し、「Search results (検索結果)」リストで「Self (自己)」を選択します。

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

    4. 「OK」をクリックして、「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスを閉じます。

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

  5. 「Targets (ターゲット)」タブで「This Entry (このエントリ)」をクリックすると、ターゲットディレクトリの入力フィールドに接尾辞 dc=siroe,dc=com が表示されます。属性テーブルで、homePhonehomePostalAddress、および userPassword attributes 属性のチェックボックスを選択します。

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

  6. 「Hosts (ホスト)」タブの「Add (追加)」ボタンをクリックして、「Add Host Filter (ホストフィルタの追加)」ダイアログボックスを表示します。「DNS host filter (DNS ホストフィルタ)」フィールドに「*.siroe.com」と入力します。「OK」をクリックしてダイアログボックスを閉じます。

  7. 「Access Control Editor (アクセス制御エディタ)」ウィンドウの「OK」ボタンをクリックします。

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウの ACI リストに、新しい ACI が追加されます。


ACI : Write Subscribers



 

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



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

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

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

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

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

  1. 「Directory (ディレクトリ)」タブの左側のナビゲーションツリーで siroe.com ノードの下にある Subscribers エントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択してアクセス制御マネージャを表示します。

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

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

    1. 「All Users (すべてのユーザ)」を選択して削除し、「Add (追加)」をクリックします。

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

    2. 「Search area (検索領域)」を「Special Rights (特殊権限)」に設定し、「Search results (検索結果)」リストで「Self (自己)」を選択します。

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

    4. 「OK」をクリックして、「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスを閉じます。

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

  5. 「Targets (ターゲット)」タブで「This Entry (このエントリ)」をクリックすると、ターゲットディレクトリの入力フィールドに接尾辞 dc=subscribers, dc=siroe,dc=com が表示されます。

    1. 「filter for subentries (サブエントリのフィルタ)」フィールドに、次のフィルタを入力します。

      (!(unlistedSubscriber=yes))

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

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

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

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

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

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウの ACI リストに、新しい ACI が追加されます。


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

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

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

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


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

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

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

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

  1. 「Directory (ディレクトリ)」タブの左側のナビゲーションツリーで siroe.com ノードをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択してアクセス制御マネージャを表示します。

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

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

    1. 「All Users (すべてのユーザ)」を選択して削除し、「Add (追加)」をクリックします。

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

    2. 「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスの「Search area (検索領域)」を「Special Rights (特殊権限)」に設定し、「Search results (検索結果)」リストで「Self (自己)」を選択します。

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

    4. 「OK」をクリックして、「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスを閉じます。

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

  5. 「Hosts (ホスト)」タブの「Add (追加)」ボタンをクリックして、「Add Host Filter (ホストフィルタの追加)」ダイアログボックスを表示します。「DNS host filter (DNS ホストフィルタ)」フィールドに「*.siroe.com」と入力します。「OK」をクリックしてダイアログボックスを閉じます。

  6. ロール用に値を基準にしたフィルタを作成するには、「Edit Manually (手動での編集)」をクリックして、手動による編集に切り替えます。LDIF 文の先頭に、次の文を追加します。

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

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

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

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

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウの ACI リストに、新しい ACI が追加されます。


接尾辞に対するグループフルアクセスの許可

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

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

siroe.com 社の Human Resources のグループには、ou=siroe-people 分岐へのフルアクセスが許可されています。これによって、このグループのメンバーは社員のデータベースを更新できます。これについては、「ACI : HR」に例を示します。


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

aci: (targetattr="*") (version 3.0; acl "HR"; allow (all) userdn= "ldap:///cn=HRgroup,ou=siroe-people,dc=siroe,dc=com";)

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

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

  1. 「Directory (ディレクトリ)」タブの左側のナビゲーションツリーで siroe.com ノードの下にある siroe.com-people エントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択してアクセス制御マネージャを表示します。

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

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

    1. 「All Users (すべてのユーザ)」を選択して削除し、「Add (追加)」をクリックします。

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

    2. 「Search area (検索領域)」を「Users and Groups (ユーザおよびグループ)」に設定し、「Search (検索)」フィールドに「HRgroup」と入力します。

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

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

    4. 「OK」をクリックして、「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスを閉じます。

  4. 「Rights (権限)」タブで、「Check All (すべてチェック)」をクリックします。

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

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

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウの ACI リストに、新しい ACI が追加されます。


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

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

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


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

aci: (target="ldap:///ou=social committee,dc=siroe,dc=com) (targetattr="*") (targattrfilters="add=objectClass:(objectClass=groupOfNames)") (version 3.0; acl "Create Group"; allow (read,search,add)
(userdn= "ldap:///uid=*,ou=siroe-people,dc=siroe,dc=com") and dns="*.siroe.com";)



 

この ACI は、書き込みアクセス権を与えません。つまり、エントリは作成できても、修正はできないことを示します。  



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

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

  1. 「Directory (ディレクトリ)」タブの左側のナビゲーションツリーで siroe.com ノードの下にある Social Committee エントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択してアクセス制御マネージャを表示します。

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

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

    1. 「All Users (すべてのユーザ)」を選択して削除し、「Add (追加)」をクリックします。

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

    2. 「Search area (検索領域)」を「Special Rights (特殊権限)」に設定し、「Search results (検索結果)」リストで「All Authenticated Users (すべての認証ユーザ)」を選択します。

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

    4. 「OK」をクリックして、「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスを閉じます。

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

  5. 「Targets (ターゲット)」タブで「This Entry (このエントリ)」をクリックすると、ターゲットディレクトリの入力フィールドに接尾辞 ou=social committee, dc=siroe,dc=com が表示されます。

  6. 「Hosts (ホスト)」タブの「Add (追加)」ボタンをクリックして、「Add Host Filter (ホストフィルタの追加)」ダイアログボックスを表示します。「DNS host filter (DNS ホストフィルタ)」フィールドに「*.siroe.com」と入力します。「OK」をクリックしてダイアログボックスを閉じます。

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

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

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

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

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

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウの ACI リストに、新しい ACI が追加されます。


ACI : Delete Group
siroe.com 社の社員が ou=Social Comittee branch 分岐の下のグループエントリを編集または削除できるようにするには、LDIF で次のような文を作成します。

aci: (target="ou=social committee,dc=siroe,dc=com)(targetattr = "*") (targattrfilters="del=objectClass:(objectClass=groupOfNames)") (version 3.0; acl "Delete Group"; allow (write,delete) userattr= "owner#GROUPDN";)

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

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


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

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

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

  • 接続が SSL によって認証されていること

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

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

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


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

aci: (target="ou=Company333,ou=corporate-clients,dc=siroe,dc=com") (targetattr = "*") (version 3.0; acl "Company333"; allow (all) (roledn= "ldap:///cn=DirectoryAdmin,ou=Company333,ou=corporate-clients, dc=siroe,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=siroe,dc=com エントリ に追加しています。

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

  1. 「Directory (ディレクトリ)」タブの左側のナビゲーションツリーで siroe.com ノードの下にある Company333 エントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択してアクセス制御マネージャを表示します。

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

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

    1. 「All Users (すべてのユーザ)」を選択して削除し、「Add (追加)」をクリックします。

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

    2. 「Search area (検索領域)」を「Users and Groups (ユーザおよびグループ)」に設定し、「Search (検索)」フィールドに「DirectoryAdmin」と入力します。

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

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

    4. 「OK」をクリックして、「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスを閉じます。

  4. 「Rights (権限)」タブで、「Check All (すべてチェック)」をクリックします。

  5. 「Targets (ターゲット)」タブで「This Entry (このエントリ)」をクリックすると、ターゲットディレクトリの入力フィールドに接尾辞 ou=Company333,ou=corporate-clients,dc=siroe,dc=com が表示されます。

  6. 「Hosts (ホスト)」タブの「Add (追加)」ボタンをクリックして、「Add Host Filter (ホストフィルタの追加)」ダイアログボックスを表示します。「IP アドレスホストフィルタ」フィールドに「255.255.123.234」と入力します。「OK」をクリックしてダイアログボックスを閉じます。

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

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

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

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

    and (authmethod="ssl")

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

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

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

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウの ACI リストに、新しい ACI が追加されます。


アクセスの拒否

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

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


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

aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Read"; allow (search,read) userdn= "ldap:///self";)

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

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

  1. 「Directory (ディレクトリ)」タブの左側のナビゲーションツリーで siroe.com ノードの下にある Subscribers エントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択してアクセス制御マネージャを表示します。

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

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

    1. 「All Users (すべてのユーザ)」を選択して削除し、「Add (追加)」をクリックします。

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

    2. 「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスの「Search area (検索領域)」を「Special Rights (特殊権限)」に設定し、「Search results (検索結果)」リストで「Self (自己)」を選択します。

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

    4. 「OK」をクリックして、「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスを閉じます。

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

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

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

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

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

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウの ACI リストに、新しい ACI が追加されます。


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

aci: (targetattr="connectionTime || accountBalance") (version 3.0; acl "Billing Info Deny"; deny (write) userdn= "ldap:///self";)

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

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

  1. 「Directory (ディレクトリ)」タブの左側のナビゲーションツリーで siroe.com ノードの下にある Subscribers エントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択してアクセス制御マネージャを表示します。

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

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

    1. 「All Users (すべてのユーザ)」を選択して削除し、「Add (追加)」をクリックします。

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

    2. 「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスの「Search area (検索領域)」を「Special Rights (特殊権限)」に設定し、「Search results (検索結果)」リストで「Self (自己)」を選択します。

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

    4. 「OK」をクリックして、「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスを閉じます。

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

  5. 「Edit Manually (手動での編集)」ボタンをクリックし、表示された LDIF 文の中の allowdeny に修正します。

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

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

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

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

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウの ACI リストに、新しい ACI が追加されます。


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

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

次に、bjensen というユーザに対して、部署番号、自宅の電話番号、自宅住所、JPEG 写真、および経理部門の全メンバーのマネージャ属性に対する書き込みアクセス権を与える手順を示します。

これらのアクセス権を設定する前に、accounting 分岐点 (ou=accounting,dc=siroe,dc=com) を作成する必要があります。組織単位の分岐点は、Directory Server Console の「Directory (ディレクトリ)」タブを使用して作成できます。


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

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

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


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

aci: (targettattr="member")(version 3.0; acl "Group Members";
allow (selfwrite)
(userdn= "ldap:///uid=*,ou=siroe-people,dc=siroe,dc=com") ;)

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

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

  1. 「Directory (ディレクトリ)」タブの左側のナビゲーションツリーで siroe.com ノードの下にある siroe-people エントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択してアクセス制御マネージャを表示します。

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

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

    1. 「All Users (すべてのユーザ)」を選択して削除し、「Add (追加)」をクリックします。

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

    2. 「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスの「Search area (検索領域)」を「Special Rights (特殊権限)」に設定し、「Search results (検索結果)」リストで「All Authenticated Users (すべての認証ユーザ)」を選択します。

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

    4. 「OK」をクリックして、「Add Users and Groups (ユーザおよびグループの追加)」ダイアログボックスを閉じます。

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

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

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

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

    「Access Control Manager (アクセス制御マネージャ)」ウィンドウの ACI リストに、新しい ACI が追加されます。


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

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

dn: dc=siroe.com Bolivia\, S.A.,dc=com
objectClass: top
objectClass:organization
aci: (target="ldap:///dc=siroe.com Bolivia\, S.A.,dc=com")(targetattr="*") (version 3.0; acl "aci 2"; allow (all)
groupdn = "ldap:///cn=Directory Administrators,dc=siroe.com Bolivia\, S.A.,dc=com";)


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

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

この例では、次の条件が満たされているものとします。

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

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

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

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

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

    aci: (target="ldap:///ou=Accounting,dc=siroe,dc=com") (targetattr="*") (version 3.0; acl "allowAll-AcctAdmin"; allow (all)  userdn="uid=AcctAdministrator,ou=Administrators,dc=siroe,dc=com")

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

    aci: (target="ldap:///ou=Accounting,dc=siroe,dc=com") (targetattr="*") (version 3.0; acl "allowproxy-accountingsoftware"; allow (proxy) userdn="uid=MoneyWizAcctSoftware,ou=Applications,dc=siroe,dc=com")

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

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

#ldapmodify -D "uid=MoneyWizAcctSoftware, ou=Applications,dc=siroe,dc=com" -w secretpwd
-y "uid=AcctAdministrator,ou=Administrators,dc=siroe,dc=com"

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



 

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





エントリの ACI の表示



次に示す ldapsearch コマンドを実行することによって、ディレクトリ内の 1 つの接尾辞の下にあるすべての ACI を表示できます。

ldapsearch -h host -p port -b baseDN -D rootDN -w rootPassword (aci=*) aci

ldapsearch ユーティリティの使い方については、『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。

Console のアクセス制御マネージャで、特定のエントリに適用されるすべての ACI を表示できます。

  1. Directory Console の「Directory (ディレクトリ)」タブで、ナビゲーションツリーのエントリをマウスの右ボタンでクリックし、「Set Access Permissions (アクセス権の設定)」を選択します。

    アクセス制御マネージャが表示されます。アクセス制御マネージャには、選択したエントリに属する ACI のリストが表示されます。

  2. 「継承された ACI の表示」チェックボックスを選択すると、選択されたエントリの上にあるエントリに対して作成され、同様に適用されるすべての ACI が表示されます。



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

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

マクロは、ACI の中で DN、または DN の一部を表現するために使用される可変部分です。マクロを使用すると、ACI のターゲット部分またはバインド規則部分、あるいはその両方の DN を表すことができます。実際の処理では、Directory Server が LDAP 操作を受け取ると、LDAP 操作のターゲットとなる資源に対して ACI マクロのマッチングが行われます。マッチした場合、マクロは対象となる資源の DN の値に置き換えられます。続けて、Directory Server は通常どおりに ACI を評価します。


マクロ ACI の例

マクロ ACI の利点と最も効果的に機能させる方法を例を示しながら説明します。図 6-4 は、全体的な ACI の数を減らすために、マクロ ACI を効果的に利用しているディレクトリツリーです。

この例では、同じツリー構造のサブドメインが同じパターンで繰り返されています (ou=groups, ou=people)。siroe.com ディレクトリツリーには、接尾辞 dc=hostedCompany2, dc=siroe,dc=com および dc=hostedCompany3,dc=siroe,dc=comが格納されているので、このパターンはツリー内でも繰り返されています。

ディレクトリツリーに適用される ACI でも、同じパターンが繰り返されています。たとえば、次の ACI は dc=hostedCompany1,dc=siroe,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=siroe, dc=com";)

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

図 6-4    マクロ ACI のディレクトリツリーの例



次の ACI は、dc=hostedCompany1,dc=siroe,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=siroe,dc=com";)

次の ACI は、dc=subdomain1,dc=hostedCompany1, dc=siroe,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=siroe,dc=com";)

次の ACI は、dc=hostedCompany2,dc=siroe,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=siroe,dc=com";)

次の ACI は、dc=subdomain1,dc=hostedCompany2, dc=siroe,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=siroe,dc=com";)

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

aci: (target="ldap:///ou=Groups,($dn),dc=siroe,dc=com") (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=siroe,dc=com";)

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

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


マクロ ACI の構文

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

  • ($dn)

  • [$dn]

  • ($attr.attrName)、attrName はターゲットエントリの属性

ここでは、わかりやすくするために、userdnroledngroupdnuserattr などのバインド資格を与えるために使用される ACI キーワードを、ACI のターゲットに対して、まとめてサブジェクトと呼びます。マクロ ACI は、ACI のターゲット部分またはサブジェクト部分で使用できます。

DN マクロを使用できる ACI の場所を表 6-3 に示します。


表 6-3 ACI キーワード中のマクロ

マクロ

ACI キーワード

($dn)  

target、targetfilter、userdn、roledn、groupdn、userattr  

[$dn]  

targetfilter、userdn、roledn、groupdn、userattr  

($attr.attrName)  

userdn、roledn、groupdn、userattr  

この場合、次のような制限があります。

  • targetfilteruserdnroledngroupdnuserattr で ($dn) を使用する場合は、必ず ($dn) を含むターゲットを定義してください。

  • targetfilteruserdnroledngroupdnuserattr で [$dn] を使用する場合は、必ず ($dn) を含むターゲットを定義してください。

つまり、マクロを使用するときは、ターゲット定義に必ず ($dn) マクロを含める必要があります。

($dn) マクロと ($attr.attrName) マクロは組み合わせることができます。


($dn) に対するマクロマッチング

($dn) マクロは、LDAP 要求のターゲットである資源のマッチング部分に置き換えられます。たとえば、cn=all, ou=groups,dc=subdomain1,dc=hostedCompany1,dc=siroe,dc=com エントリをターゲットとする LDAP 要求がある場合は、ターゲットを定義する ACI は次のようになります。

(target="ldap:///ou=Groups,($dn),dc=siroe,dc=com")

この場合、($dn) マクロは「dc=subdomain1, dc=hostedCompany1」とマッチします。

ACI のサブジェクトも ($dn) を使用すると、サブジェクトの展開には、そのターゲットに一致するサブストリングが使用されます。たとえば、次のようにします。

aci: (targetattr="*") (target="ldap:///ou=*,($dn),dc=siroe,dc=com") (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,($dn),dc=siroe,dc=com";)

この場合、($dn) にマッチするターゲット内の文字列が dc=subdomain1, dc=hostedCompany1 であれば、サブジェクト内でも同じ文字列が使用されます。上の ACI は、次のように展開されます。

aci: (targetattr="*") (target="ldap:///ou=Groups,dc=subdomain1,dc=hostedCompany1, dc=siroe,dc=com") (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=siroe,dc=com";)

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


[$dn] に対するマクロマッチング

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

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

aci: (targetattr="*") (target="ldap:///ou=Groups,($dn),dc=siroe,dc=com") (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=siroe,dc=com";)

この ACI は次の手順で展開されます。

  1. ターゲットの ($dn) が dc=subdomain1,dc=hostedCompany1 にマッチします。

  2. サブジェクトの [$dn] を dc=subdomain1,dc=hostedCompany1 に置き換えます。

    結果は groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=siroe, dc=com" になります。バインド DN がそのグループのメンバーである場合は、マッチングプロセスは中止され、ACI が評価されます。マッチしない場合は、プロセスが続行されます。

  3. サブジェクトの [$dn] を dc=hostedCompany1 に置き換えます。

    結果は groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=siroe,dc=com" になります。この場合、バインド DN がそのグループのメンバーでなければ、ACI は評価されません。メンバーであれば、ACI が評価されます。

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

たとえば、次のような ACI があるとします。

aci: (target="ldap:///ou=*, ($dn),dc=siroe,dc=com") (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=siroe,dc=com";)

この ACI は、cn=DomainAdmins,ou=Groups, dc=hostedCompany1,dc=siroe,dc=com のすべてのメンバーに対して、dc=hostedCompany1 の下にあるすべてのサブドメインへのアクセス権を与えます。したがって、たとえばそのグループに属する管理者は、サブツリー ou=people, dc=subdomain1.1, dc=subdomain1 にアクセスできます。

ただし、同時に、cn=DomainAdmins,ou=Groups, dc=subdomain1.1 のメンバーの ou=people,dc=hostedCompany1 および ou=people,dc=hostedCompany1 ノードに対するアクセスは拒否されます。


($attr.attrName) に対するマクロマッチング

($attr.attrname) マクロは、常に DN のサブジェクト部分で使用されます。たとえば、次のような roledn を定義できます。

roledn = "ldap:///cn=DomainAdmins,($attr.ou)"

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

dn: cn=Heather Blue, ou=People, dc=HostedCompany1, dc=siroe, dc=com
cn: Heather Blue
sn: Blue
ou: Engineering, dc=HostedCompany1, dc=siroe, dc=com
...

ACI の roledn 部分を評価するために、サーバはターゲットエントリ内に格納された ou 属性を探し、この属性値を使用してマクロを展開します。したがって、この例における roledn は次のように展開されます。

roledn = "ldap:///cn=DomainAdmins,ou=Engineering,dc=HostedCompany1, dc=siroe,dc=com"

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

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

次のような例を想定します。

dn: cn=Heather Blue,ou=People,dc=HostedCompany1,dc=siroe,dc=com
cn: Heather Blue
sn: Blue
ou: Engineering, dc=HostedCompany1, dc=siroe, dc=com
ou: People, dc=HostedCompany1,dc=siroe, dc=com
...

この場合、Directory Server は、ACI 評価時に、次のように展開された式に対して論理和を実行します。

roledn = "ldap:///cn=DomainAdmins,ou=Engineering,dc=HostedCompany1, dc=siroe,dc=com"

roledn = "ldap:///cn=DomainAdmins,ou=People,dc=HostedCompany1, dc=siroe,dc=com"



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



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

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



アクセス制御情報のログ



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

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

  1. Console 上で「Directory (ディレクトリ)」タブをクリックし、config ノードをマウスの右ボタンでクリックして、「Property (プロパティ)」を選択します。

    この操作を行うと、cn=config エントリの属性エディタが表示されます。

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

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

    たとえば、8192 (レプリケーションデバッグ) という値が表示されている場合は、8320 に修正します。エラーログレベルについては『iPlanet Directory Server 構成、コマンド、およびファイルのリファレンス』を参照してください。

  4. 「OK」をクリックして属性エディタを閉じます。



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

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

  • userdnattr

  • groupdnattr

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


前へ     目次     索引     DocHome     次へ     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated February 26, 2002