Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド

第 6 章 Directory Server のアクセス制御

安全なディレクトリを作成する上で、ディレクトリの内容へのアクセスを制御することはもっとも重要です。この章では、ディレクトリに対してどのようなアクセス権をユーザーに許可するかを決定する ACI ( アクセス制御命令) について説明します。

ディレクトリ配備の計画段階では、全体的なセキュリティーポリシーとして利用できるアクセス制御戦略を定義します。アクセス制御戦略の計画のヒントは、『Sun Java System Directory Server Enterprise Edition 6.1 配備計画ガイド』を参照してください。

ACI の構文やバインドルールなど、ACI のその他の情報については、『Sun Java System Directory Server Enterprise Edition 6.1 Reference』を参照してください。

この章の内容は次のとおりです。

ACI の作成、表示、および変更

ACI は、Directory Service Control Center (DSCC) を使用するかコマンド行を使用することで作成できます。どちらの方法を選択するとしても、たいていの場合、新しい ACI を最初から作成するよりも、既存の ACI 値を表示しコピーするほうが簡単です。

aci 属性値は、DSCC で表示および変更できます。DSCC による ACI の変更方法については、DSCC のオンラインヘルプを参照してください。

ACI を作成、変更、および削除する

コマンド行を使用して ACI を作成するには、最初に LDIF 文を使ってファイル内に ACI を作成します。次に、ldapmodify コマンドを使用して ACI をディレクトリツリーに追加します。

DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。

LDIF ファイル内に ACI を作成します。
dn: dc=example,dc=com changetype: modify add: aci aci: (target)(version 3.0; acl "name";permission bindrules;)
この例は ACI の追加方法を示しています。ACI を変更または削除する場合は、add を replace または delete に置き換えます。

よく使われるその他の ACI の例については、「アクセス制御の使用例」を参照してください。

LDIF ファイルを使って変更を加えます。

$ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - -f ldif-file

ACI 属性値を表示する

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

DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。

次の ldapsearch コマンドを実行して、エントリの ACI 属性値を表示します。
$ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \ -b entryDN -s base "(objectclass=*)" aci
このコマンドで得られた LDIF テキストを、新しい LDIF ACI 定義にコピーして編集できます。ACI の値は長い文字列なので、ldapsearch 操作からの出力は複数行にわたって表示されることがあります。この場合、最初の空白は継続マーカーになります。LDIF の出力に継続マーカーを入れないようにするには、-T オプションを使用します。LDIF の出力をコピーおよびペーストする場合は、出力形式について考慮してください。

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

ACI をルートレベルで表示する

サフィックスを作成すると、いくつかのデフォルトの ACI が最上位またはルートレベルで作成されます。これらの ACI により、デフォルトの管理者ユーザー cn=admin,cn=Administrators,cn=config が、ディレクトリマネージャーと同じディレクトリデータへのアクセス権限を持つことができます。

DSCC を使用してこの作業を実行できます。詳細は、「Directory Service Control Center のインタフェース」と DSCC のオンラインヘルプを参照してください。

デフォルトのルートレベル ACI を表示します。

$ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \
 -b "" -s base "(objectclass=*)" aci

アクセス制御の使用例

この節で示す例では、架空の ISP である Example.com 社が、アクセス制御ポリシーを決定していきます。

また、インストールに付属のサンプルの LDIF ファイルに、install_path/ds6/ldif/Example.ldif というサンプルの ACI もあります。

すべての例では、LDIF ファイルを使用して、与えられたタスクをどのように処理するかを説明しています。次の図で、example.com 社のディレクトリ情報ツリーを示します。

サンプルのディレクトリツリーの概略最上位エントリと、最上位エントリのすぐ下のエントリを示します。

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

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

Example.com 社の社員に、Example.com ツリー全体を対象とした読み取り、検索、および比較のための匿名アクセス権を与える。「匿名アクセスの許可」を参照。
Example.com 社の社員に、homeTelephoneNumber、homeAddress などの個人情報への書き込みアクセス権を与える。「個人のエントリへの書き込みアクセス権の許可」を参照。
Example.com 社の契約者に、会社の連絡先情報のエントリ dc=example,dc=com の読み取り権限を与える。ただし、その下のエントリの読み取り権限は与えない。「特定のレベルへのアクセスの許可」を参照。
Example.com 社の社員が個人のエントリにロールを追加するアクセス権を与える。ただし、一部の重要なロールは除く。「重要なロールに対するアクセスの制限」を参照。
特定の管理者に、サフィックスに関してディレクトリマネージャーと同じ権限を与える。「サフィックス全体に対するすべてのアクセス権のロールへの許可」を参照。
Example.com 社の人事部グループに、People 分岐のエントリを対象としたすべての権限を与える。「サフィックスに対するすべてのアクセス権のグループへの許可」を参照。
Example.com 社のすべての社員に対し、ディレクトリの Social Committee エントリの下にグループエントリを作成し、社員が所有するグループエントリを削除するアクセス権を与える。「グループエントリの追加および削除権限の許可」を参照。
Example.com 社のすべての社員に対し、Social Committee エントリの下のグループエントリに、自身を追加するアクセス権を与える。「ユーザー自身の操作によるグループへの参加とグループからの退会」を参照。
一定の条件付きで、ディレクトリツリーのそれぞれのエントリへのアクセス権を Company333 および Company999 のディレクトリ管理者 (ロール) に与える。これらの条件には、SSL 認証、日時の制約、位置の指定などが含まれる。「グループまたはロールへの条件付きアクセスの許可」を参照。
個人契約者に対し、個人のエントリへのアクセス権を与える。「個人のエントリへの書き込みアクセス権の許可」を参照。
個人契約者が個人のエントリ内の課金情報にアクセスできないようにする。「アクセスの拒否」を参照。
世界のユーザーに対し、個人契約者のサブツリーへの匿名アクセス権を与える。ただし、非公開を希望している契約者は除く。ディレクトリのこの部分は、必要に応じてファイアウォール外部から読み取り専用サーバーになることがあり、毎日 1 回更新される。「匿名アクセスの許可」および「フィルタを使用したターゲットの設定」を参照。

匿名アクセスの許可

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

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

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

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

注 –

機密属性や表示すべきではない属性は、前の例でパスワード属性を保護しているのと同じように、「(targetattr !="attribute-name ")」の構文を用いて保護してください。

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 社のディレクトリ管理者は、ユーザーが変更できる対象を、パスワード、自宅の電話番号、自宅住所だけに制限しようとしています。これについては、「ACI「Write Example.com」」で例を示しています。

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

ACI「Write Example.com」

注 –

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

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

aci: (targetattr="homePhone ||
 homePostalAddress")(version 3.0; acl "Write Example.com";
 allow (write) userdn="ldap:///self" ;)

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

ACI「Write Subscribers」

注 –

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

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

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

この例では、aci を ou=subscribers,dc=example, dc=com エントリに追加し、ユーザーは SSL を使用してバインドする必要があると仮定しています。

Example.com 社の契約者は、その住所の属性を削除する可能性があるため、住所への書き込みアクセス権は与えられていません。住所は Example.com 社からの請求に重要な情報です。

特定のレベルへのアクセスの許可

ディレクトリツリー内のさまざまなレベルに影響を及ぼす ACI の範囲を設定して、許可するアクセスのレベルを微調整できます。対象の ACI の範囲は、次のいずれかに設定できます。

base: エントリ自体
onelevel: エントリ自体と 1 レベル下のすべてのエントリ
subtree: エントリ自体と、そのエントリの下のすべてのエントリ

ACI 「Read Example.com only」

Example.com 社の契約者に、会社の連絡先情報についてのエントリ dc=example,dc=com の読み取り権限は与えても、その下にあるエントリへのアクセスは許可しないようにするには、LDIF で次のような文を作成します。

aci: (targetscope="base") (targetattr="*")(version 3.0;
 acl "Read Example.com only";  allow (read,search,compare)
 userdn="ldap:///cn=*,ou=subscribers,dc=example,dc=com";)

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

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

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

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

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

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

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

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

一部のユーザーに、サフィックスに対してディレクトリマネージャーと同じ権限を許可すると、便利な場合があります。Example.com 社の Kirsten Vaughan は Directory Server の管理者です。彼女は superAdmin のロールを持っています。このロールには、次のような利点があります。

管理者としてバインドし、SSL のような強力な認証を強制的に使用できることによって、セキュリティーが向上する
ディレクトリマネージャーパスワードを知っている人が減ることによって、セキュリティーが向上する
ログによる追跡容易性の向上

注 –

Kirsten Vaughan を cn=Administrators,cn=config グループに追加すると、ディレクトリマネージャーと同じ権限が与えられます。

サーバー全体に対してディレクトリマネージャーと同じ権限をユーザーに与える際は、「ルートアクセス権を持つ管理ユーザーを作成する」の手順に従ってください。

ACI「Full Access」

Kirsten Vaughan という管理者にディレクトリマネージャーと同じ権限を許可するには、LDIF で次のような文を使用します。

aci: (targetattr="*") (version 3.0; acl "Full Access";
 allow (all) groupdn= "ldap:///cn=SuperAdmin,dc=example,dc=com"
 and authmethod="ssl" ;)

この例では、ACI がルートエントリ "" (テキストなし) に追加されると仮定しています。

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

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

たとえば、Directory Server インスタンスを作成すると、ディレクトリへのすべてのアクセス権を持つ cn=Administrators,cn=config という管理者グループがデフォルトで作成されます。

Example.com 社の人事部グループには、ディレクトリの ou=People エントリへのすべてのアクセス権が許可されています。これによって、このグループのメンバーは、「ACI 「HR」」に示すように社員のディレクトリを更新できます。

ACI 「HR」

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

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

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

ou=People,dc=example,dc=com

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

一部の企業では、業務の効率化や企業全体の活力向上につなげるため、社員自身がツリー内にエントリを作成できるようにしています。たとえば、Example.com 社には、テニス、水泳、スキー、演劇などのさまざまなクラブが組織された社内委員会があります。

Example.com 社の社員はだれでも、「ACI「Create Group」」に示すように、新しいクラブを表すグループエントリを作成できます。

「ユーザー自身の操作によるグループへの参加とグループからの退会」に示すように、Example.com 社の社員であれば、これらのグループのどれか 1 つのメンバーになることができます。

「ACI「Delete Group」」に示すように、グループエントリの変更や削除ができるのは、グループの所有者のみです。

ACI「Create Group」

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

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

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

注 –

この ACI は、書き込みアクセス権を与えないので、エントリを変更できません。
サーバーが top という値を追加するので、targattrfilters キーワードで objectClass=top を指定する必要があります。
この ACI は、example.com ドメイン内のクライアントマシンにのみ適用されます。

ACI「Delete Group」

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

aci: (targetattr = "*") (targattrfilters="del=objectClass:
(objectClass=groupOfNames)")
 (version 3.0; acl "Delete Group"; allow (write,delete)
 userattr="owner#GROUPDN";)

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

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

ユーザー自身の操作によるグループへの参加とグループからの退会

多くのディレクトリの ACI は、ユーザーがメーリングリストなどのグループへの参加とグループからの退会を自分で設定できるようになっています。

Example.com 社では、「ACI「Group Members」」に示すように、社員であれば ou=Social Committee サブツリーの下のどのグループエントリにも参加できます。

ACI「Group Members」

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

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

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

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

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

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

このため、Company333 と Company999 は、ディレクトリツリーのそれぞれのエントリに関してすべての権限を持っていますが、このアクセス権を行使するには次の条件を満たす必要があります。

証明書を使用して、SSL 経由の接続が認証されること
アクセス要求は月曜日から木曜日の午前 8 時から午後 6 時までの間に限ること
それぞれの企業に割り当てられた特定の IP アドレスからアクセスが要求されること

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

ACI「Company333」

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

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

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

アクセスの拒否

サフィックスの大半の部分に対してのアクセスをすでに許可している場合に、既存の ACI の配下にあるサフィックスの限定された範囲に対してアクセスを拒否させることもできます。

注 –

アクセスを拒否すると、アクセス制御の振る舞いが予期しないものや複雑なものになる可能性があるため、可能な限り回避してください。アクセスは、範囲、属性リスト、ターゲットフィルタなどの組み合わせを使って制限してください。

また、アクセス拒否 ACI を削除しても、権限が削除されるのではなく、ほかの ACI で設定された権限の幅が広げられます。

Directory Server は、アクセス権限を評価するとき、最初に deny 権限を読み取り、次に allow 権限を読み取ります。

次の例で、Example.com 社では、すべての契約者に対し、契約者自身のエントリにある接続時間や料金内訳などの課金情報の読み取りアクセス権を与えています。また、Example.com 社では、その情報に対する書き込みアクセス権は拒否するようにしています。読み取りアクセス権については、「ACI「Billing Info Read」」で例を示しています。deny アクセス権については、「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 エントリに追加しています。

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 エントリに追加しています。

プロキシ承認

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

プロキシ要求を許可するように Directory Server を設定するには、次のことを行う必要があります。

管理者には、ほかのユーザーとしてのプロキシ権限を与える。
一般ユーザーには、アクセス制御ポリシーで定義されている通常のアクセス権限を与える。

注 –

ディレクトリマネージャーを除く、ディレクトリのすべてのユーザーにプロキシ権限を与えることができます。また、ディレクトリマネージャーの DN をプロキシ DN として使用することはできません。プロキシ権限により、すべての DN (ディレクトリマネージャー DN を除く) をプロキシ DN として指定する権限が与えられるので、プロキシ権限を与える場合には十分な注意が必要です。同じ操作中に Directory Server が複数のプロキシ認証の制御を受け取った場合は、クライアントアプリケーションにエラーが返され、操作の試行は失敗します。

プロキシ認証の例

Example.com 社は、MoneyWizAcctSoftware としてバインドするクライアントアプリケーションに、Accounting Administrator と同じ LDAP データへのアクセス権限を与えようとしています。

次の条件が適用されます。

クライアントアプリケーションのバインド DN は uid=MoneyWizAcctSoftware, ou=Applications,dc=example,dc=com。
クライアントアプリケーションがアクセスを要求するターゲットサブツリーは ou=Accounting,dc=example,dc=com。
ディレクトリ内に、ou=Accounting,dc=example,dc=com サブツリーへのアクセス権を持つ Accounting Administrator が存在する。

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

Accounting Administrator は、ou=Accounting,dc=example,dc=com サブツリーへのアクセス権を持っている必要がある。たとえば、次の ACI は Accounting Administrator エントリに対するすべての権限を与えます。
aci: (targetattr="*") (version 3.0; acl "allowAll-AcctAdmin"; allow (all) userdn="ldap:///uid=AcctAdministrator,ou=Administrators, dc=example,dc=com";)

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

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

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

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

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

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

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

ディレクトリ内に分散した多数のエントリに対して、アクセス制御の設定が必要な場合は、フィルタを使用してターゲットを設定することもできます。

フィルタを使って HR のすべてのユーザーに従業員エントリへのアクセスを許可するには、LDIF で次のような文を作成します。

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

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

注 –

検索フィルタは、アクセス管理の対象となるオブジェクトを直接指定するわけではないので、誤ったオブジェクトへのアクセスを許可または拒否しないようにしてください。ディレクトリ構造が複雑になるほど、誤ったオブジェクトへのアクセスを許可または拒否してしまうリスクが大きくなります。さらに、フィルタによって、ディレクトリ内のアクセス制御に関する問題解決が難しくなる場合もあります。

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

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

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

実行権限の表示

ディレクトリのエントリに対するアクセスポリシーを管理するとき、定義した ACI がセキュリティーに与える影響を把握しておく必要があります。Directory Server は、ACI が特定のエントリに対して特定のユーザーに与える実行権限を確認することで、既存の ACI を評価します。

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

実行権限を表示する機能は、LDAP 制御を利用しています。リモートサーバーとのバインドに使用されるプロキシアイデンティティーにも、実行権限の属性へのアクセスが許可されていることを確認してください。

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

実行権限を表示するという操作はディレクトリ操作であり、保護し、適切に制限する必要があります。

実行権限情報へのアクセスを制限するには、getEffectiveRights 属性のデフォルトの ACI を変更します。次に、getEffectiveRightsInfo 属性に新しい ACI を作成します。

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

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

実行権限情報を取得するには、実行権限制御を使用するためのアクセス制御権と、aclRights 属性に対する読み取りアクセス権が必要です。このような二重の層に成すアクセス制御により、基本的なセキュリティーを必要に応じて微調整できます。プロキシ承認のように、aclRights に対する読み取りアクセス権があれば、エントリと属性に対するどのユーザーの権限に関する情報でも要求することができます。つまり、リソースを管理するユーザーは、だれがそのリソースに対する権限を持つかを決定できます。これは、そのユーザーが実際にはその権限を使って管理していない場合も同様です。

権限情報を照会しようとしているユーザーが実行権限制御を使用する権限を持たない場合、操作は失敗し、エラーメッセージが返されます。一方、権限情報を照会しようとしているユーザーがこの制御を使用する権限は持つが、aclRights 属性に対する読み取りアクセス権を持たない場合は、返されるエントリから aclRights 属性が省略されます。この動作は、Directory Server の通常の検索動作を反映しています。

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

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

デフォルトの動作を変更するには、次のオプションを使用します。

-c "dn: bind DN " — 検索結果には、指定された DN にバインドされているユーザーの実行権限が表示されます。管理者はこのオプションを使用して、別のユーザーの実行権限を確認できます。-c "dn:" オプションを指定すると、匿名認証用の実行権限が表示されます。
-X "attributeName ..."— 検索結果には、指定された属性に対する実行権限も表示されます。このオプションは、検索結果に表示されない属性を指定する場合に使用します。たとえば、このオプションを使用すると、現在はエントリに存在していない属性について、ユーザーがその属性を追加する権限を持っているかどうかを調べることができます。
-c オプションまたは -X オプション、あるいはその両方を使用するときは、-J オプションに実行権限の取得制御の OID が暗黙的に指定されるため、このオプションを指定する必要はありません。実行権限制御に NULL 値を指定すると、現在のユーザーの権限を取得できます。また、現在の ldapsearch 操作によって返される属性とエントリの権限も取得できます。

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

注 –

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

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

実行権限機能は、アクセス制御に影響を与えるその他のパラメーターを継承します。これらのパラメータには、時刻、認証方法、マシンアドレス、名前が含まれます。

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

$ ldapsearch -J "1.3.6.1.4.1.42.2.27.9.5.2 -h host1.Example.com -p 389 \
 -D "uid=cfuente,ou=People,dc=example,dc=com" -w - -b "dc=example,dc=com" \
 "(objectclass=*)" aclRights
Enter bind password:
dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

この結果は、Carla Fuente にはディレクトリ内のエントリに少なくとも読み取り権限が与えられていて、自分のエントリを変更できることを示しています。実行権限制御は、通常のアクセス権をバイパスしないため、ユーザーは読み取り権限が与えられていないエントリを見ることはできません。次の例で、ディレクトリマネージャーは、Carla Fuente に読み取り権限が与えられていないエントリを確認できます。

$ ldapsearch -h host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \
 -c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \
 "(objectclass=*)" aclRights
Enter bind password:
dn: dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: ou=Groups, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Directory Administrators, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0
dn: ou=Special Users,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:0,write:0,proxy:0
dn: ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=Accounting Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: cn=HR Managers,ou=groups,dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=bjensen,ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0

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

$ ldapsearch -h host1.Example.com -p 389 -D cn=admin,cn=Administrators,cn=config -w - \
 -c "dn: uid=cfuente,ou=People,dc=example,dc=com" -b "dc=example,dc=com" \
 "(uid=cfuente)" aclRights "*"
Enter bind password:
version: 1
dn: uid=cfuente, ou=People, dc=example,dc=com
aclRights;attributeLevel;mail: search:1,read:1,compare:1,
 write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
mail: cfuente@Example.com
aclRights;attributeLevel;uid: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
uid: cfuente
aclRights;attributeLevel;givenName: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
givenName: Carla
aclRights;attributeLevel;sn: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
sn: Fuente
aclRights;attributeLevel;cn: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
cn: Carla Fuente
aclRights;attributeLevel;userPassword: search:0,read:0,
 compare:0,write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
userPassword: {SSHA}wnbWHIq2HPiY/5ECwe6MWBGx2KMiZ8JmjF80Ow==
aclRights;attributeLevel;manager: search:1,read:1,compare:1,
 write:0,selfwrite_add:0,selfwrite_delete:0,proxy:0
manager: uid=bjensen,ou=People,dc=example,dc=com
aclRights;attributeLevel;telephoneNumber: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
telephoneNumber: (234) 555-7898
aclRights;attributeLevel;objectClass: search:1,read:1,compare:1,
 write:1,selfwrite_add:1,selfwrite_delete:1,proxy:0
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0

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

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

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

この節では、マクロ ACI の例とマクロ ACI 構文についての情報を示します。

マクロ ACI の例

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

この例では、同じツリー構造のサブドメインが同じパターンで繰り返されています (ou=groups,ou=people)。Example.com ディレクトリツリーには、dc=hostedCompany2,dc=example,dc=com および dc=hostedCompany3,dc=example,dc=com という 2 つのサフィックスが格納されているので、このパターンはツリー内でも繰り返されています。ただし、図には示されていません。

ディレクトリツリーにある ACI でも、同じパターンが繰り返されています。たとえば、次の ACI は dc=hostedCompany1,dc=example,dc=com ノード上に置かれています。

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

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

図 6–1 マクロ ACI のディレクトリツリーの例

dc=hostedcompany1,dc=example,dc=com を示すサンプルのディレクトリツリーと、さまざまなサブドメインの概要

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

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

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

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

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

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

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

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

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

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

前述の個々の ACI では使われていなかった target キーワードをここでは新たに使っていることに注意してください。

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

マクロ ACI の構文

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

次の表に、特定の ACI キーワードの置換に使用できるマクロを示します。

表 6–1 マクロ ACI キーワード


マクロ	説明	ACI キーワード
`($dn)`	target 文でマッチング要素として用いられます。サブジェクト内では、実際に ($dn} と一致した文字列に置き換えられます。	`target、targetfilter、userdn、roledn、groupdn、userattr`
`[$dn]`	サブジェクトのサブツリー内のあらゆる RDN に置き換えられます。	`targetfilter、userdn、roledn、groupdn、userattr`
`($attr.attrName)`	ターゲットエントリの `attrName` 属性に設定されている値に置き換えられて、サブジェクトに設定されます。	`userdn、roledn、groupdn、userattr`

マクロ ACI キーワードには、次のような制限が適用されます。

サブジェクトで ($dn) マクロや [$dn] マクロを使用するときは、($dn) マクロを含む target 文を定義する必要があります。
サブジェクトで ($attr.attrName ) マクロと ($dn) マクロを組み合わせることはできますが、[$dn] マクロと組み合わせることはできません。

ターゲットエントリでの `($dn)` とのマッチング処理

ACI の target 文に含まれる ($dn) マクロを、LDAP 要求のターゲットとなるエントリと比較することによって、実際に置き換えられる値が決定します。たとえば、このエントリをターゲットとする LDAP 要求があるとします。

cn=all,ou=groups,dc=subdomain1, dc=hostedCompany1,dc=example,dc=com

また、次のような target 文を定義している ACI もあるとします。

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

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

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

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

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

サブジェクトは次のようになります。

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

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

注 –

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

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

[$dn] の置換メカニズムは ($dn) のものと少し異なります。一致する対象が見つかるまで、一番左にある RDN コンポーネントを外しながらマクロの展開を継続して行い、ターゲットリソースの DN の検証を繰り返します。

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

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

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

target 文の ($dn) が dc=subdomain1,dc=hostedCompany1 に一致します。
サブジェクトの [$dn] を dc=subdomain1,dc=hostedCompany1 で置き換えます。

この結果、サブジェクトは groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com" になります。バインド DN がそのグループのメンバーであるためにアクセスが許可される場合は、マクロの展開を停止し、ACI を評価します。バインド DN がメンバーでない場合は、処理を継続します。
サブジェクトの [$dn] を dc=hostedCompany1 で置き換えます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アクセス制御情報のログ

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

ACI のログを設定する

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

ACI の処理を考慮に入れるようにログレベルを設定します。
$ dsconf set-log-prop -h host -p port error level:err-acl

TCP ラップによるクライアントホストのアクセス制御

接続が TCP レベルで受け入れまたは拒否されるホストや IP アドレスは、TCP ラッパーを使用して制御できます。TCP ラップにより、クライアントホストのアクセスを制限できます。これにより、Directory Server への初期の TCP 接続に対する、ホストベースではない保護が可能になります。

Directory Server に対して TCP ラップを設定することはできますが、TCP ラップは、特にサービス拒否攻撃の際に、パフォーマンスを著しく低下させる可能性があります。最良のパフォーマンスは、Directory Server の外部で保守されるホストベースのファイアウォールを使用するか、IP ポートのフィルタリングによって得られます。

TCP ラップを使用可能にする

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

インスタンスパス内のどこかに hosts.allow ファイルまたは hosts.deny ファイルを作成します。

たとえば、このファイルを instance-path/config 内に作成します。作成するファイルの形式は、必ず hosts_access(4) に従うようにしてください。

アクセスファイルへのパスを設定します。

$ dsconf set-server-prop -h host -p port host-access-dir-path:path-to-file

次に例を示します。

$ dsconf set-server-prop -h host -p port host-access-dir-path:/local/ds1/config
"host-access-dir-path" property has been set to "/local/ds1/config".
The "/local/ds1/config" directory on host1 must contain valid hosts.allow
and/or hosts.deny files.
Directory Server must be restarted for changes to take effect.

TCP ラップを使用不可にする

DSCC を使用してこの作業を実行することはできません。この手順で説明しているように、コマンド行を使用してください。

ホストアクセスパスを "" に設定します。

$ dsconf set-server-prop -h host -p port host-access-dir-path:""

第 6 章 Directory Server のアクセス制御

ACI の作成、表示、および変更

ACI を作成、変更、および削除する

ACI 属性値を表示する

ACI をルートレベルで表示する

アクセス制御の使用例

匿名アクセスの許可

ACI「Anonymous Example.com」

ACI「Anonymous World」

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

ACI「Write Example.com」

ACI「Write Subscribers」

特定のレベルへのアクセスの許可

ACI 「Read Example.com only」

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

ACI「Roles」

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

ACI「Full Access」

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

ACI 「HR」

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

ACI「Create Group」

ACI「Delete Group」

ユーザー自身の操作によるグループへの参加とグループからの退会

ACI「Group Members」

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

ACI「Company333」

アクセスの拒否

ACI「Billing Info Read」

ACI「Billing Info Deny」

プロキシ承認

プロキシ認証の例

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

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

実行権限の表示

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

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

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

マクロ ACI の例

図 6–1 マクロ ACI のディレクトリツリーの例

マクロ ACI の構文

ターゲットエントリでの ($dn) とのマッチング処理

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

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

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

アクセス制御情報のログ

ACI のログを設定する

TCP ラップによるクライアントホストのアクセス制御

TCP ラップを使用可能にする

TCP ラップを使用不可にする

ターゲットエントリでの `($dn)` とのマッチング処理

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

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

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