Sun ONE Directory Server 管理ガイド: 第 6 章アクセス制御の管理

Sun ONE Directory Server 管理ガイド

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

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

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

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

アクセス制御の原則

デフォルト ACI

ACI の構文

バインドルール

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

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

アクセス制御の使用例

実効権限の表示

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

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

アクセス制御情報のログ

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


アクセス制御の原則

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

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

ACI の構造

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

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

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

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

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

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

ACI の配置

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

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

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

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

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

ACI の評価

特定のエントリに対するアクセス権限を評価する場合は、サーバーによって、そのエントリ上と、エントリのルートサフィックスのベースにバックアップされる親エントリの ACI のリストが作成されます。評価中に、この順番でサーバーにより ACI が処理されます。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 は、ロール定義エントリと同じサーバー上に置く必要がある。ロールを持たせる予定のエントリも、すべて同じサーバー上に置く必要がある

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

アクセス制御の評価を連続して行う方法については、「連鎖サフィックスのアクセス制御」を参照してください。

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

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

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


デフォルト ACI

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

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

バインドユーザーは、ディレクトリ内にある個人のエントリを変更できるが、削除はできない。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 の構文を理解することが重要になります。

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

aci: (target)(version 3.0;acl "name";permission bindRules;)

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

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

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

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

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

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

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

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

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

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

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

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

ターゲットの定義

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

ターゲットの一般的な構文は、次のいずれかです。

((keyword = "expression")

((keyword != "expression")

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

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

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

エントリの属性

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

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

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

expression はキーワードに依存し、ターゲットを識別する。expression を囲む引用符 ("") は省略できない

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

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

キーワード

有効な式

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

target

ldap:///distinguished_name

可

targetattr

属性

可

targetfilter

LDAP_filter

可

targattrfilters

LDAP_operation:LDAP_filter

可


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

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

(target = "ldap:///distinguished_name")
(target != "ldap:///distinguished_name")

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

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

注
アクセス制御規則を適用するエントリの DN にコンマが含まれる場合は、1 つの円記号 (\) を使用して、コンマをエスケープする必要があります。たとえば、次のようにします。

(target="ldap:///uid=cfuentes,o=Example Bolivia\, S.A.")

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

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

example.com ツリー内のエントリで、その RDN 内に uid 属性を含むすべてのエントリを示します。次の例に示すように、このターゲットは、ツリーの下のすべての階層のエントリと一致します。

uid=tmorris,ou=sales,dc=example,dc=com
uid=yyorgens,ou=marketing,dc=example,dc=com
uid=bjensen,ou=eng,ou=east,dc=example,dc=com

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

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 ツリーのすべてのエントリと一致します。

注
識別名のサフィックス部分には、ワイルドカードを使用できません。つまり、ディレクトリのサフィックスが c=US と c=GB である場合に、両方のサフィックスを参照させる次のようなターゲットは使用できません。

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

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

属性のターゲット指定

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

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

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

(targetattr = "attribute")
(targetattr != "attribute")

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

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

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

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

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

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

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

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

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

aci: (target="ldap:///uid=*,ou=Marketing,dc=example,dc=com")
(targetattr="uid") (accessControlRules;)

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

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

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

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

(targetfilter = "LDAPfilter")

ここで、LDAPfilter は、標準的な LDAP 検索フィルタです。フィルター構文の詳細については、『Sun ONE Directory Server Getting Started Guide』の第 4 章にある「LDAP Search Filters」を参照してください。

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

(targetfilter = "(|(status=contractor)(fulltime<=79))")

注
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 キーワードを使用する必要があります。構文は次のとおりです。

(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 が付く電話番号を追加することもできます。

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

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

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

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

targetfilter キーワードを使用する

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

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

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

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

アクセス権の定義

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

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

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

権限の割り当て


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

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

注
サーバーコンソールを使用して明示的にアクセスを拒否することはできませんが、アクセス権を与えることはできます。

権限の割り当て

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

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

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

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

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

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

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

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

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

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

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

LDAP 操作に必要な権限

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

エントリを追加する場合

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

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

エントリを削除する場合

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

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

エントリの属性を変更する場合

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

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

エントリの RDN を変更する場合

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

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

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

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

属性値を比較する場合

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

エントリを検索する場合

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

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

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

% ldapsearch -h host -s suffix -b "uid=bjensen,dc=example,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 個のキーワードのリストです。キーワードは、コンマで区切り、カッコでくくります。使用できるキーワードは、read、write、add、delete、search、compare、selfwrite、 proxy、または all です。

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

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

バインドルール

ディレクトリに対して定義された 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 とするには 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 || 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、つまり anyone、all、self、parent の 1 つです。これらの式は、次のユーザーを示します。

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

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

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

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

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

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

注
DN にコンマが含まれる場合は、コンマの前にエスケープ文字の円記号 (\) を付けて区別する必要があります。

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

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

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

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

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

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

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

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

LDAP URL

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

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

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

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

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

LDAP URL については、『Sun ONE Directory Server Getting Started Guide』の該当する章を参照してください。

ワイルドカード

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

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

例

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

LDAP URL を含む userdn キーワード

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

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

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

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

cn=Babs Jensen,dc=example,dc=com

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

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

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

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

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

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

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

userdn = "ldap:///self";

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

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

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

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

userdn = "ldap:///anyone";

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

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

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

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

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

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

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

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

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

注
DN にコンマが含まれる場合、1 つの円記号 (\) を使用してコンマをエスケープする必要があります。

特定のグループの定義には、サーバーコンソールとしてアクセス制御エディタを使用します。詳細は、「コンソールを使用した ACI の作成」を参照してください。

例

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

LDAP URL を含む groupdn キーワード

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

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

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

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

groupdn = "ldap:///cn=Administrators,dc=example,dc=com ||
ldap:///cn=Mail Administrators,dc=example,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 の 1 つ

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

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

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

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

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

userattr = "manager#USERDN"

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

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

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

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

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

userattr = "owner#GROUPDN"

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

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

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

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

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

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

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

userattr = "exampleEmployeeReportsTo#ROLEDN"

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

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

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].attribute#bindType"

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

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

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

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

次に例を示します。

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

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

userattr の継承を含む例

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

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

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

ディレクトリ内のcn=Profiles、cn=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=example,dc=com")(targetattr=*) (version 3.0;
acl "manager-write"; allow (all) userattr = "manager#USERDN";)

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

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

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

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

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

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

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

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

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

ip = "IPaddressList" または ip != "IPaddressList"

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 と判定されます。この方法は、一部のディレクトリへのアクセス元を、特定のサブネットまたはマシンに制限する場合に有効です。

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

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

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

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

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

警告

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

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

dns = "legend.eng";

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

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

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

dns = "*.example.com";

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

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

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

時刻に基づくバインドルールを設定するための 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 章「セキュリティの実装」を参照してください。

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

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

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

authmethod = "authentication_method"

ここで、authentication_method は、none、 simple、 ssl、または "sasl sasl_mechanism" です。

例

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

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 のブール式を使用して細かいアクセスルールを設定すると、複雑なバインドルールを作成できます。ブール型バインドルールは、サーバーコンソールでは作成できません。LDIF 文を作成する必要があります。

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

bindRule [boolean][bindRule][boolean][bindRule]...;)

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

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

最後のセミコロン (;) は省略できません。

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

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

すべての式を左から右へ

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

OR と AND の優先順位はありません。

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

(bindRule_A) OR (bindRule_B)

(bindRule_B) OR (bindRule_A)

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

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

(bindRule_A) AND NOT (bindRule_B)

ここでは、「左から右へ」の原則は適用されず、バインドルール 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 属性を表示することもできます。

% ldapsearch -h host -p port -D "cn=Directory Manager" -w password \
             -b entryDN -s base aci

このコマンドで得られた LDIF テキストを、新しい LDIF ACI 定義にコピーして編集できます。

注
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    「アクセス制御の管理」ダイアログボックス

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

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

図 6-3    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 のリストが表示されます。

「アクセス制御の管理」ウィンドウで、削除する 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: (targetattr !="userPassword")(version 3.0; acl "Anonymous
example"; allow (read, search, compare) userdn= "ldap:///anyone" and
dns="*.example.com";)

この例では、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: (targetfilter= "(!(unlistedSubscriber=yes))")
(targetattr="homePostalAddress || homePhone || mail") (version 3.0;
acl "Anonymous World"; allow (read, search) userdn=
"ldap:///anyone";)

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

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

「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある 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: (targetattr="userPassword || homePhone || homePostalAddress")
(version 3.0; acl "Write example.com"; allow (write) userdn=
"ldap:///self" and dns="*.example.com";)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ACI「Write Subscribers」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(!(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: (targetattr="*") (targattrfilters="add=nsRoleDN:(nsRoleDN !=
"cn=superAdmin, dc=example, dc=com")") (version 3.0; acl "Roles";
allow (write) userdn= "ldap:///self" and dns="*.example.com";)

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

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

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

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

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

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

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

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

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

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

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

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

ロール用に値に基づくフィルタを作成するには、「手動での編集」ボタンをクリックして、手動による編集に切り替えます。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=example-people 分岐へのすべてのアクセス権が許可されています。これによって、このグループのメンバーは社員のディレクトリを更新できます。これについては、「ACI「HR」」で例を示しています。

ACI「HR」

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

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

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

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

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

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

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

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

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

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

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

「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに 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: (target="ldap:///ou=social committee,dc=example,dc=com)
(targetattr="*")(targattrfilters="add=objectClass:
(objectClass=groupOfNames)") (version 3.0; acl "Create Group";
allow (read,search,add) (userdn= "ldap:///uid=*,ou=example-people,
dc=example,dc=com") and dns="*.example.com";)

注
この ACI は、書き込みアクセス権を与えないので、エントリを変更できません。

この例では、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 が表示されます。

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

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

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

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

(targetattr = "*") (targattrfilters="add=objectClass:(objectClass=groupOfNames)") (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 Comittee 分岐の下に所有しているグループエントリを変更または削除できるようにするには、LDIF で次のような文を作成します。

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

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

コンソールを使用してこの 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: (target="ou=Company333,ou=corporate-clients,dc=example,dc=com")
(targetattr = "*") (version 3.0; acl "Company333"; allow (all)
(roledn="ldap:///cn=DirectoryAdmin,ou=Company333,
ou=corporate-clients,dc=example,dc=com") and (authmethod="ssl") and
(dayofweek="Mon,Tues,Wed,Thu") and (timeofday >= "0800" and
timeofday <= "1800") and (ip="255.255.123.234"); )

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

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

「ディレクトリ」タブの左側のナビゲーションツリーで 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: (targetattr="connectionTime || accountBalance") (version 3.0;
acl "Billing Info Read"; allow (search,read)
userdn="ldap:///self";)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「アクセス制御の管理」ウィンドウの 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=example,dc=com エントリに追加しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ACI「Group Members」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プロキシ承認を使用した 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: (target="ldap:///ou=Accounting,dc=example,dc=com")
(targetattr="*") (version 3.0; acl "allowAll-AcctAdmin"; allow
(all) userdn="uid=AcctAdministrator,ou=Administrators,
dc=example,dc=com")

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

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

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

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

# ldapsearch -w password \
-D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com" \
-y "uid=AcctAdministrator,ou=Administrators,dc=example,dc=com" ...

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

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

実効権限の表示

ディレクトリのエントリに対するアクセスポリシーを管理するとき、定義した ACI がセキュリティに与える影響を知ることができれば非常に役立ちます。Sun ONE Directory Server 5.2 には、既存の 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 が暗黙的に指定されるため、このオプションを指定する必要はありません。

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

注
aclRights 属性と aclRightsInfo;logs 属性は、仮想オペレーショナル属性として動作します。これらの属性はディレクトリには格納されず、これらを取得するには明示的に要求する必要があります。これらの属性は、実行権限の取得制御に対する応答として 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,write:0,proxy:0

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

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

この結果は、Carla Fuente にはディレクトリ内のエントリに少なくとも読み取り権限が与えられていて、自分のエントリを変更できることを示しています。実効権限制御で指定されていないと通常のアクセス権は有効ではないため、ユーザーは読み取り権限が与えられていないエントリを見ることはできません。次の例で、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: cfuente

aclRights;attributeLevel;givenName: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
givenName: Carla

aclRights;attributeLevel;sn: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
sn: Fuente

aclRights;attributeLevel;cn: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
cn: Carla Fuente

aclRights;attributeLevel;userPassword: search:0,read:0,
compare:0,write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
userPassword: {SSHA}wnbWHIq2HPiY/5ECwe6MWBGx2KMiZ8JmjF80Ow==

aclRights;attributeLevel;manager: search:1,read:1,compare:1,
write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
manager: uid=bjensen,ou=People,dc=example,dc=com

aclRights;attributeLevel;telephoneNumber: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
telephoneNumber: (234) 555-7898

aclRights;attributeLevel;objectClass: search:1,read:1,compare:1,
write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson

aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

aclRights 属性と aclRightsInfo;logs 属性の形式については、『Sun ONE Directory Server Deployment Guide』の第 7 章にある「Understanding the Effective Rights Results」を参照してください。

高度なアクセス制御 : マクロ 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: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search) groupdn=
"ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,
dc=com";)

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

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

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

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

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

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

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

aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany2,
dc=example,dc=com";)

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

aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain))
(version 3.0; acl "Domain access"; allow (read,search)
groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,
dc=hostedCompany2,dc=example,dc=com";)

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

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

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

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

マクロ ACI の構文

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

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

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

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

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

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

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

サブジェクトで ($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 は次のようになります。

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

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

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

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

groupdn="ldap:///cn=DomainAdmins,ou=Groups,($dn),dc=example,dc=com"

これは次のようになります。

groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,
dc=hostedCompany1,dc=example,dc=com"

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

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

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

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

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

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

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

ターゲットの ($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 があるとします。

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

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

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

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

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

roledn = "ldap:///cn=DomainAdmins,($attr.ou),dc=HostedCompany1, dc=example,dc=com"

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

dn: cn=Babs Jensen,ou=People,dc=HostedCompany1, dc=example,dc=com
cn: Babs Jensen
sn: Jensen
ou: Sales
...

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

roledn = "ldap:///cn=DomainAdmins,ou=Sales,dc=HostedCompany1, dc=example,dc=com"

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

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

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

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

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

アクセス制御情報のログ

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

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

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

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

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

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

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

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

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

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

userdnattr

groupdnattr

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

ただし、「値マッチングに基づくアクセスの定義」で説明している手順に従って、これらのキーワードを userattr キーワードの機能に置き換えることをお勧めします。

キーワード	有効な式	ワイルドカード使用の可否
target	ldap:///distinguished_name	可
targetattr	属性	可
targetfilter	LDAP_filter	可
targattrfilters	LDAP_operation:LDAP_filter	可

キーワード	有効な式	ワイルドカード使用
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	不可

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

前へ目次索引ドキュメントホーム次へ
Copyright 2003 Sun Microsystems, Inc. All rights reserved.