Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java™ System Directory Server 5.2 2005Q1 管理ガイド 

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

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

ディレクトリ配備の計画段階では、全体的なセキュリティポリシーとして利用できるアクセス制御戦略を定義する必要があります。アクセス制御戦略の計画のヒントは、『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 エントリ ("" という 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 の制限事項

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

デフォルト ACI

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

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

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

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

ACI の構文

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

ヒント

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

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

aci: (target)(version 3.0;acl "name";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 "example"; allow (write)
 userdn="ldap:///self";)

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

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

ターゲットの定義

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

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

(keyword = "expression")

(keyword != "expression")

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

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

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

キーワード

有効な式

ワイルドカード使用

ターゲット

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 は、文字列で表された識別名である必要があります (RFC 2253)。したがって、dn に対して構文上有意な文字 (コンマなど) は、1 つの円記号 (¥) を使用してエスケープする必要があります。たとえば、次のようにします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 検索フィルタです。フィルタ構文については、「LDAP 検索フィルタ」を参照してください。

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

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

Netscape の拡張フィルタ構文は ACI でサポートされていません。たとえば、次のターゲットフィルタは指定できません。

(targetfilter = "(locality:fr:=<= Québec)")

ただし、次のような、国際化された値のマッチングルールを説明するフィルタ構文がサポートされます。

(targetfilter = "(locality:2.16.840.1.113730.3.3.2.18.1.4:=Québec)")

ターゲットフィルタでは、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="Op=attr1:F1 [(&& attr2:F2)*][;Op=attr:F [(&& attr:F)*]")

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

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

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

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

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

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

注

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

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

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

targetfilter キーワードを使うことで、目的のエントリだけに含まれる属性値を指定できます。たとえば、Directory Server をインストールすると、次の 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 の変更が必要なことを憶えておき、手動で変更しなければならないことです。

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

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

アクセス権の定義

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

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

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

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

権限の割り当て

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

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

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

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

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

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

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

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

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

インポート: このアクセス権は、DN の変更操作で使用されます。このアクセス権は、エントリを特定の DN にインポートできるかどうかを指定します。

エクスポート: このアクセス権は、DN の変更操作で使用されます。このアクセス権は、エントリを特定の DN からエクスポートできるかどうかを指定します。

すべて: ターゲットエントリに対して、読み取り、書き込み、検索、削除、比較、本人による書き込みの権限が、指定された DN に割り当てられていることを指定します。「すべて」のアクセス権によって、ターゲットエントリにプロキシ、インポート、エクスポートの権限は与えられません。

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

LDAP 操作に必要な権限

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

エントリを追加する場合

エントリを削除する場合

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

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

別のサブツリーにエントリを移動する場合

属性値を比較する場合

エントリを検索する場合

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

(target="ldap:///dc=example,dc=com")
ldapsearch -h host -p port -D "uid=bjensen,dc=example,dc=com" ¥
           -w password -b "dc=example,dc=com"¥
             "(objectclass=*)" mail

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

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

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

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

アクセス権の構文

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

allow|deny (rights)

ここで、rights はカッコで囲んだコンマ区切りのキーワードのリストです。キーワードには read、write、add、delete、search、compare、selfwrite、proxy、import、export、または all が使用できます。

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]

不可

roledn

[ldap:///DN]

不可

userattr

attribute#bindType or
attribute#value

不可

ip

IP_address

可

dns

DNS_host_name

可

dayofweek

sun
mon
tue
wed
thu
fri
sat

不可

timeofday

0 - 2359

不可

authmethod

none
simple
ssl
sasl authentication_method

不可

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

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

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

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

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

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

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

注

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LDAP URL

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

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

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

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

注

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

LDAP URL の詳細は、『Directory Server Administration Reference』を参照してください。

ワイルドカード

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

LDAP URL の論理 OR

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

userdn = "ldap:///uid=b*,c=example.com ||
 ldap:///cn=b*,dc=example,dc=com";

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

特定の LDAP URL の除外

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

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

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

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

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

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

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

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

注

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

単一の LDAP URL

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

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

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

注

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

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

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

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

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

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

userattr キーワードの使用

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

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

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

userattr = "attrName#bindType"

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

userattr = "attrName#attrValue"

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

次の節では、考えられるさまざまなバインドタイプを指定した 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"

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

たとえば、次のとおりです。

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

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

userattr の継承を含む例

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

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

userattr キーワードでの継承を使用する ACI を示した図

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

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 つまたは複数の要素です (複数の要素はコンマで区切られる)。

ディレクトリにアクセスするクライアントが指定された IP アドレスを持っていれば、バインドルールは true と判定されます。この方法は、一部のディレクトリへのアクセス元を、特定のサブネットまたはマシンに制限する場合に有効です。ユーザーが認証を行う IP アドレスはスプーフィングされる可能性があるので、信頼できません。ACI がこの情報だけに基づいたものにならないようにします。

ACI の適用対象を特定のコンピュータに制限するには、アクセス制御エディタを使用して Server Console から定義します。詳細は、「コンソールを使用した 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 には、次のどれかを指定できます。等号 (=)、不等号 (!=)、大なり記号 (>)、大きいまたは等しい (>=)、小なり記号 (<)、小さいまたは等しい (<=)。時間は、24 時間法による「時」と「分」を表す 4 桁 (0 から 2359) で表されます。たとえば、次のようにします。

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

dayofweek = "day1, day2 ..."

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

たとえば、次のようになります。dayofweek = "Mon, Tue, Wed, Thu, Fri";

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

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

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

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

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

authmethod = "authentication_method"

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

例

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

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

AND、OR、およびNOT のブール式を使用して細かいアクセスルールを設定すると、複雑なバインドルールを作成できます。

ブール型バインドルールは、Directory Server Console では作成できません。LDIF 文を作成する必要があります。

ブール型バインドルールを作成する場合、必ずカッコを使用して規則を評価する順序を定義してください。

最後のセミコロンは最後のルールの後に表示する必要があるため、省略できません。

たとえば、bindRuleA とのバインド、bindRuleB とのバインド、または bindRuleC と bindRuleD とのバインドには、次の構文を使用します。

(bindRuleA and (bindRuleB or (bindRuleC and bindRuleD));)

別の例では、次のバインドルールを評価して、バインド DN クライアントに example.com ドメイン内からアクセスできる場合、またバインド DN クライアントが管理者グループのメンバーか、メール管理者グループとカレンダ管理者グループのメンバーであれば true とします。

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

コマンド行からの 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 "(objectclass=*)" aci

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

注

値 aci が権限を与えるか拒否するかを確認する場合は、「実効権限の表示」を参照してください。

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

Directory Server コンソール は、ディレクトリ内で aci 属性を持つエントリを表示するように設定できます。この表示の有効と無効を切り替えるには、「表示」>「表示」>「ACI カウント」の順に選択または選択解除します。「ディレクトリ」タブの先頭に表示されるエントリは、aci 属性で定義される ACI の番号で追加されます。この場合、ディレクトリのアクセス制御命令の表示、作成、編集、削除に Directory Server コンソール を使用できます。

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

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

エントリの ACI の表示

  1. Directory Server コンソールの最上位レベルにある「ディレクトリ」タブでディレクトリツリーを表示し、アクセス制御を設定するエントリを探します。ACI を編集するには、ディレクトリ管理者または Directory Manager としての権限が必要です。
  2. このエントリをマウスの右ボタンでクリックし、ポップアップメニューから「アクセス権を設定」を選択します。あるいは、エントリをクリックして選択し、「オブジェクト」メニューから「アクセス権を設定」を選択します。

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

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

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

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

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

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

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

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

新しい ACI の作成

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

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

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

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

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

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

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

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

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

    2. 検索結果リストで必要なエントリを選択し、「追加」ボタンをクリックして、アクセス権が与えられたエントリのリストにそれらを追加します。
    3. 「了解」をクリックして、「ユーザーおよびグループの追加」ウィンドウを閉じます。

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

  4. アクセス制御エディタで「権限」タブをクリックし、チェックボックスを使用して与える権限を選択します。
  5. 「ターゲット」タブをクリックし、「このエントリ」をクリックして、ACI のターゲットとして指定されているノードを表示します。

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

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

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

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

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

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

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

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

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

    注

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

ACI の編集

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

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

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

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

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

  3. アクセス制御エディタの各種タブを使用して、必要な変更を加えます。
  4. ACI の修正が完了したら、「了解」をクリックします。

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

ACI の削除

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

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

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

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

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

アクセス制御の使用例

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

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

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

匿名アクセスの許可

ほとんどのディレクトリは、読み取り、検索、または比較を行うために、少なくとも 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 の対象に含まれていません。

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

  1. 「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。
  2. 「新規」をクリックして、アクセス制御エディタを表示します。
  3. 「ユーザー/グループ」タブの ACI 名フィールドに、「Anonymous example.com」と入力します。アクセス権が与えられたユーザーのリストに、「すべてのユーザー」と表示されていることを確認します。
  4. 「権限」タブで、読み取り (read)、比較 (compare)、および検索 (search) の各権限のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。
  5. 「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス dc=example,dc=com が表示されます。属性テーブルで userPassword 属性を検索し、対応するチェックボックスの選択を解除します。

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

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

    8. 「アクセス制御の管理」ウィンドウの 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 属性が設定されているものとします。非公開契約者は、この属性値に基づいて、ターゲット定義のフィルタによって除外されます。フィルタ定義については、「フィルタを使用したターゲットの設定」を参照してください。

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

  1. 「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある Subscribers エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。
  2. 「新規」をクリックして、アクセス制御エディタを表示します。
  3. 「ユーザーおよびグループ」タブの ACI 名フィールドに、「Anonymous World」と入力します。アクセス権が与えられたユーザーのリストに、「すべてのユーザー」と表示されていることを確認します。
  4. 「権限」タブで、読み取り (read) と検索 (search) の各権限のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。
  5. 「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス dc=subscribers, dc=example,dc=com が表示されます。
    1. 「サブエントリのフィルタ」フィールドに、次のフィルタを入力します。

      2. (!(unlistedSubscriber=yes))

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

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

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

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

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

  1. 「ディレクトリ」タブの左側のナビゲーションツリーで ou=People,dc=example,dc=com エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。
  2. 「新規」をクリックして、アクセス制御エディタを表示します。
  3. 「ユーザー/グループ」タブの ACI 名フィールドに、「Write example.com」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。
    1. 「すべてのユーザー」を選択して削除し、「追加」をクリックします。

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

    2. 「検索領域」を「特殊権限」に設定し、「検索結果」リストで「自己」を選択します。
    3. 「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「自己」が追加されます。
    4. 「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。
  4. 「権限」タブで、書き込みアクセス権 (write) のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。
  5. 「ターゲット」タブで「このエントリ」をクリックし、ターゲットディレクトリの入力フィールドに ou=People,dc=example,dc=com と入力します。属性テーブルで、homePhone、homePostalAddress、および userPassword 属性のチェックボックスを選択します。

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

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

    8. 「アクセス制御の管理」ウィンドウの 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 社からの請求に必要な情報で、この情報を削除する可能性があるので、契約者にはこの属性への書き込みアクセス権は与えられていません。つまり、自宅住所はビジネス的に重要な情報なのです。

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

  1. 「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある Subscribers エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。
  2. 「新規」をクリックして、アクセス制御エディタを表示します。
  3. 「ユーザー/グループ」タブの ACI 名フィールドに、「Write Subscribers」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。
    1. 「すべてのユーザー」を選択して削除し、「追加」をクリックします。

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

    2. 「検索領域」を「特殊権限」に設定し、「検索結果」リストで「自己」を選択します。
    3. 「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「自己」が追加されます。
    4. 「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。
  4. 「権限」タブで、書き込みアクセス権 (write) のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。
  5. 「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス dc=subscribers, dc=example,dc=com が表示されます。
    1. 「サブエントリのフィルタ」フィールドに、次のフィルタを入力します。

      2. (!(unlistedSubscriber=yes))

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

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

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

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

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

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

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

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

  1. 「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。
  2. 「新規」をクリックして、アクセス制御エディタを表示します。
  3. 「ユーザー/グループ」タブの ACI 名フィールドに、「Roles」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。
    1. 「すべてのユーザー」を選択して削除し、「追加」をクリックします。

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

    2. 「ユーザーおよびグループの追加」ダイアログボックスの「検索領域」を「特殊権限」に設定し、「検索結果」リストで「自己」を選択します。
    3. 「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「自己」が追加されます。
    4. 「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。
  4. 「権限」タブで、書き込みアクセス権 (write) のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。
  5. 「ホスト」タブの「追加」ボタンをクリックして、「ホストフィルタの追加」ダイアログボックスを表示します。「DNS ホストフィルタ」フィールドに「*.example.com」と入力します。「了解」をクリックして、ダイアログボックスを閉じます。
  6. ロール用に値に基づくフィルタを作成するには、「手動での編集」ボタンをクリックして、手動による編集に切り替えます。LDIF 文の先頭に、次の文を追加します。

    7. (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");)

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

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

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

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

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

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

ACI「HR」

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

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

この例では、ACI を次のエントリに追加することを仮定しています。

ou=People,dc=example,dc=com

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

  1. 「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある example.com-people エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。
  2. 「新規」をクリックして、アクセス制御エディタを表示します。
  3. 「ユーザー/グループ」タブの ACI 名フィールドに、「HR」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。
    1. 「すべてのユーザー」を選択して削除し、「追加」をクリックします。

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

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

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

    3. 「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに HR のグループが追加されます。
    4. 「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。
  4. 「権限」タブで、「すべてチェック」ボタンをクリックします。

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

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

    6. 「アクセス制御の管理」ウィンドウの 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)(objectClass=top))")
 (version 3.0; acl "Create Group"; allow (read,search,add)
 userdn= "ldap:///uid=*,ou=People,dc=example,dc=com")
 and dns="*.example.com";)

注

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

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

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

  1. 「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある Social Committee エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。
  2. 「新規」をクリックして、アクセス制御エディタを表示します。
  3. 「ユーザー/グループ」タブの ACI 名フィールドに、「Create Group」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。
    1. 「すべてのユーザー」を選択して削除し、「追加」をクリックします。

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

    2. 「検索領域」を「特殊権限」に設定し、「検索結果」リストで「すべての認証ユーザー」を選択します。
    3. 「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「すべての認証ユーザー」が追加されます。
    4. 「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。
  4. 「権限」タブで、読み取り (read)、検索 (search)、および追加 (add) のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。
  5. 「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス ou=social committee, dc=example,dc=com が表示されます。
  6. 「ホスト」タブの「追加」ボタンをクリックして、「ホストフィルタの追加」ダイアログボックスを表示します。「DNS ホストフィルタ」フィールドに「*.example.com」と入力します。「了解」をクリックして、ダイアログボックスを閉じます。
  7. 値に基づくフィルタを作成して、社員がこのサブツリーにグループエントリだけを追加できるようにするには、「手動での編集」ボタンをクリックして、手動による編集に切り替えます。LDIF 文の先頭に、次の文を追加します。

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

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

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

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

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

ACI「Delete Group」

example.com 社の社員が ou=Social Committee branch 分岐の下に所有しているグループエントリを変更または削除できるようにするには、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 は、ディレクトリツリーのそれぞれの分岐に関してすべての権限を持っていますが、このアクセス権を行使するには次の条件を満たす必要があります。

これらの条件は、各社の 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 エントリに追加することを仮定しています。

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

  1. 「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある Company333 エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。
  2. 「新規」をクリックして、アクセス制御エディタを表示します。
  3. 「ユーザー/グループ」タブの ACI 名フィールドに、「Company333」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。
    1. 「すべてのユーザー」を選択して削除し、「追加」をクリックします。

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

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

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

    3. 「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに管理者ロールが追加されます。
    4. 「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。
  4. 「権限」タブで、「すべてチェック」ボタンをクリックします。
  5. 「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス ou=Company333,ou=corporate-clients,dc=example,dc=com が表示されます。
  6. 「ホスト」タブの「追加」ボタンをクリックして、「ホストフィルタの追加」ダイアログボックスを表示します。「IP アドレスホストフィルタ」フィールドに「255.255.123.234」と入力します。「了解」をクリックして、ダイアログボックスを閉じます。

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

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

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

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

    9. 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"); )

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

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

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

  1. 「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある Subscribers エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。
  2. 「新規」をクリックして、アクセス制御エディタを表示します。
  3. 「ユーザー/グループ」タブの ACI 名フィールドに、「Billing Info Read」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。
    1. 「すべてのユーザー」を選択して削除し、「追加」をクリックします。

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

    2. 「ユーザーおよびグループの追加」ダイアログボックスの「検索領域」を「特殊権限」に設定し、「検索結果」リストで「自己」を選択します。
    3. 「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「自己」が追加されます。
    4. 「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。
  4. 「権限」タブで、検索 (search) と読み取り (read) の各権限のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。
  5. 「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス ou=subscribers, dc=example,dc=com が表示されます。属性テーブルで、connectionTime および accountBalance 属性のチェックボックスを選択します。

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

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

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

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

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

  1. 「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある Subscribers エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。
  2. 「新規」をクリックして、アクセス制御エディタを表示します。
  3. 「ユーザー/グループ」タブの ACI 名フィールドに、「Billing Info Deny」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。
    1. 「すべてのユーザー」を選択して削除し、「追加」をクリックします。

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

    2. 「ユーザーおよびグループの追加」ダイアログボックスの「検索領域」を「特殊権限」に設定し、「検索結果」リストで「自己」を選択します。
    3. 「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「自己」が追加されます。
    4. 「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。
  4. 「権限」タブで、書き込みアクセス権 (write) のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。
  5. 「手動での編集」ボタンをクリックし、表示された LDIF 文の中の allow を deny に変更します。
  6. 「ターゲット」タブで「このエントリ」をクリックすると、ターゲットディレクトリの入力フィールドにサフィックス ou=subscribers, dc=example,dc=com が表示されます。属性テーブルで、connectionTime および accountBalance 属性のチェックボックスを選択します。

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

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

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

    8. 「アクセス制御の管理」ウィンドウの 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=People,dc=example,dc=com") ;)

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

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

  1. 「ディレクトリ」タブの左側のナビゲーションツリーで example.com ノードの下にある People エントリを右クリックし、ポップアップメニューから「アクセス権を設定」を選択して、アクセス制御の管理を表示します。
  2. 「新規」をクリックして、アクセス制御エディタを表示します。
  3. 「ユーザー/グループ」タブの ACI 名フィールドに、「Group Members」と入力します。アクセス権が与えられたユーザーのリストで、次の手順を実行します。
    1. 「すべてのユーザー」を選択して削除し、「追加」をクリックします。

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

    2. 「ユーザーおよびグループの追加」ダイアログボックスの「検索領域」を「特殊権限」に設定し、「検索結果」リストで「すべての認証ユーザー」を選択します。
    3. 「追加」ボタンをクリックすると、アクセス権が与えられたユーザーのリストに「すべての認証ユーザー」が追加されます。
    4. 「了解」をクリックして、「ユーザーおよびグループの追加」ダイアログボックスを閉じます。
  4. 「権限」タブで、書き込み (write) アクセス権のチェックボックスを選択します。これ以外のチェックボックスは、選択が解除されていることを確認してください。
  5. 「ターゲット」タブのターゲットディレクトリ入力フィールドに、「dc=example,dc=com」というサフィックスを入力します。属性テーブルで、member 属性のチェックボックスを選択します。

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

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

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

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

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

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

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

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

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

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

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

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

ldapsearch¥
-D "uid=MoneyWizAcctSoftware,ou=Applications,dc=example,dc=com"¥
-wpassword¥
-y "uid=AcctAdministrator,ou=Administrators,dc=example,dc=com"¥ ...

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

注

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

実効権限の表示

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

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

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

実行権限取得制御へのアクセスの制限

実効権限を表示することはそれ自体がディレクトリ操作なので、適切に保護し、制限する必要があります。

この情報にディレクトリユーザーがアクセスするのを制限するには、getEffectiveRights 属性のデフォルトの ACI を変更し、getEffectiveRightsInfo 属性に新しい ACI を作成します。

たとえば、次の ACI では、ディレクトリ管理者グループのメンバーのみが実行権限取得へのアクセスを許可されます。

aci: (targetattr != "aci")(version 3.0; acl "getEffectiveRights"; allow(all) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)

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

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

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

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

注

aclRights 属性と aclRightsInfo 属性は、仮想オペレーショナル属性として動作します。これらの属性はディレクトリには格納されず、これらを取得するには明示的に要求する必要があります。これらの属性は、実行権限の取得制御に対する応答として Directory Server で生成されます。

このため、どちらの属性も、フィルタや何らかの検索操作に使用することはできません。

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

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

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

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

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

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

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

dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entrylevel add:0,delete:0,read:1,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;entrylevel

エントリレベルの権限情報を提供する

aclRights;attributelevel

属性レベルの権限情報を提供する

aclRightsInfo;entrylevel

エントリレベルのログ情報を提供する

aclRightsInfo;attributelevel

属性レベルのログ情報を提供する

aclRights 文字列の形式: permission:value(permission:value)*

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

これらの権限の値は次のいずれかになります。

Write、Selfwrite_add、Selfwrite_delete 権限

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

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

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

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

表 6-3 実効権限の相互依存関係 

write

selfwrite_
add

selfwrite_
delete

実効権限の説明

0

0

0

この属性のどの値も追加、削除できません。

0

0

1

承認 DN 値の削除だけが可能です。

0

1

0

承認 DN 値の追加だけが可能です。

0

1

1

承認 DN 値の追加、削除だけが可能です。

1

0

0

承認 DN 値を除くすべての値の追加、削除が可能です。

1

0

1

承認 DN 値を含むすべての値の削除と、承認 DN 値を除くすべての値の追加が可能です。

1

1

0

承認 DN 値を含むすべての値の追加と、承認 DN 値を除くすべての値の削除が可能です。

1

1

1

この属性のすべての値の追加、削除が可能です。

?

0

0

承認 DN 値を追加、削除することはできませんが、その他の値を追加、削除できる可能性があります。書き込み権限の詳細を確認するには、ログ情報を調べます。

?

0

1

承認 DN 値の削除は可能ですが、追加はできません。また、その他の値を追加、削除できる可能性があります。書き込み権限の詳細を確認するには、ログ情報を調べます。

?

1

0

承認 DN 値の追加は可能ですが、削除はできません。また、その他の値を追加、削除できる可能性があります。書き込み権限の詳細を確認するには、ログ情報を調べます。

?

1

1

承認 DN 値の追加、削除が可能です。また、その他の値を追加、削除できる可能性があります。書き込み権限の詳細を確認するには、ログ情報を調べます。

ログ情報

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

実際のログファイルの形式については、『Directory Server Administration Reference』を参照してください。

高度なアクセス制御: マクロ 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 例で使用されるディレクトリツリーを示した図

次の 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 マクロを使用できる ACI の場所を表 6-5 に示します。

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

マクロ

ACI キーワード

($dn)

target、targetfilter、userdn、roledn、groupdn、userattr

[$dn]

targetfilter、userdn、roledn、groupdn、userattr

($attr.attrName)

userdn、roledn、groupdn、userattr

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

ターゲットでの ($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 を展開します。

  1. ターゲットの ($dn) が dc=subdomain1,dc=hostedCompany1 に一致します。
  2. サブジェクトの [$dn] を dc=subdomain1,dc=hostedCompany1 で置き換えます。

    3. この結果、サブジェクトは groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com" になります。バインド DN がそのグループのメンバーであるためにアクセスが許可される場合は、マクロの展開は中止され、ACI が評価されます。メンバーでない場合は、プロセスが続行されます。

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

    4. この結果、サブジェクトは 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 上で行われます。つまり、コンシューマサーバーが更新要求を受け取ると、その要求がマスター上で実行されるかどうかを評価する前に、コンシューマサーバーがマスターサーバーにリフェラルを返します。

アクセス制御と連鎖

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

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

アクセス制御情報のログ

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

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

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

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

  2. 属性値の組み合わせリストをスクロールして、nsslapd-errorlog-level 属性を探します。
  3. nsslapd-errorlog-level フィールドに表示されている値に 128 を加えます。

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

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

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

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

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

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



前へ      目次      索引      次へ     

Part No: 819-2011.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.