6. slapd の設定ファイル
ソフトウェアのインストールが完了したら、インストールしたサイトで利用できるように slapd(8) の設定を行います。 slapd ラインタイム設定は主に slapd.conf(5) ファイルをとおして行います。このファイルは普通 /usr/local/etc/openldap ディレクトリにインストールされています。
slapd(8) や slurpd(8) のコマンドラインオプションを使えば別の設定ファイルを指定できます。この章では設定ファイルの一般的なフォーマットについて説明し、その後によく使われる設定ファイルディレクティブを詳しく説明します。
6.1. 設定ファイルのフォーマット
ファイル slapd.conf(5) は、グローバル、バックエンド固有、データベース固有の３タイプの設定情報から成ります。まず最初に指定するのはグローバル情報であり、その後に特定のバックエンド種別に関連した情報が続き、さらにその後に特定のデータベース実体に関連した情報が続きます。グローバル情報ディレクティブは後のバックエンドやデータベース設定のディレクティブで上書きでき、バックエンド設定ディレクティブはデータベース設定ディレクティブで上書きできます。
ブランク行と '#' 文字で始まるコメント行は無視されます。行が空白で始まっている場合、前の行からの継続であるとみなされます (たとえ前の行がコメントであっても継続であるとみなされます)。
slapd.conf の一般的なフォーマットは次のようになります。
# グローバル設定ディレクティブ
<グローバル設定ディレクティブ>
# バックエンド定義
backend <typeA>
<バックエンド固有ディレクティブ>
# １番目のデータベース定義 & 設定ディレクティブ
database <typeA>
<データベース固有ディレクティブ>
# ２番目のデータベース定義 & 設定ディレクティブ
database <typeB>
<データベース固有ディレクティブ>
# 続きのデータベース定義と設定ディレクティブ
...
設定ディレクティブの中には引数をとるものがあります。引数のある場合には空白で区切って並べます。引数に空白を含めたい場合には、引数を二重引用符で囲みます。引数に二重引用符やバックスラッシュ文字 `\' を含めたい場合には、その文字の前にバックスラッシュ文字 `\' を置きます。
OpenLDAP の配布物の中には設定ファイルのサンプルが付いてきます。これは普通 /usr/local/etc/openldap ディレクトリにインストールされます。スキーマ定義(属性型とオブジェクトクラス)を含んだファイルも /usr/local/etc/openldap/schema ディレクトリに提供されています。
6.2. 設定ファイルのディレクティブ
この節では、よく使われる設定ディレクティブについて詳説します。設定ディレクティブの全リストについては slapd.conf(5) マニュアルページを参照してください。この節では、設定ファイルのディレクティブをグローバル、バックエンド固有、データ固有のカテゴリに分けて、各ディレクティブと(もしあれば) そのデフォルト値について説明し、設定例を示します。
6.2.1. グローバルディレクティブ
この節で説明するディレクティブは、バックエンドまたはデータベースの定義で特に上書きしない限り、すべてのバックエンドとデータベースに適用されます。実際のテキストで置き換えるディレクティブの引数はブラケット <> で示します。
6.2.1.1. access to <what> [ by <who> <accesslevel> <control> ]+
このディレクティブは、エントリや属性の１セット(<what> に指定)に対するアクセス権(<accesslevel> に指定)を１人以上の要求者(<who> に指定)に与えます。基本的な使い方についてはこの章の アクセス制御の節を参照してください。
注記：ディレクティブ access の指定がなければ、デフォルトのアクセス制御ポリシーである access to * by * read を適用します。これは、すべての認証ユーザと匿名ユーザに読取りアクセス権を与えます。
6.2.1.2. attributetype <RFC2252 Attribute Type Description>
このディレクティブは属性型を定義します。このディレクティブの使い方に関しては スキーマ指定の章を参照してください。
6.2.1.3. idletimeout <integer>
アイドル状態のクライアント接続を強制的に切断するまでの秒数を指定します。idletimeout の値が 0 であると(デフォルト) この機能は無効になります。
6.2.1.4. include <filename>
このディレクティブは、slapd が現在のファイルの次の行に進む前に、与えたファイルから追加の設定情報を読み込むことを指定します。取り込むファイルは、通常の slapd 設定ファイルのフォーマットに従います。ファイルの取込みは一般にスキーマ指定の記述されたファイルを取り込むのに使われます。
注記：このディレクティブの取扱いには注意してください - 入れ子になった include ディレクティブに制限はなく、include がループになった場合でも検出されません。
6.2.1.5. loglevel <integer>
このディレクティブは、デバッグ情報と操作の統計値を syslog に出力するレベルを指定します(現在のところ、syslogd(8) の LOG_LOCAL4 ファシリティに記録されます)。このオプションが有効になるようにするには OpenLDAP を --enable-debug 付き(デフォルト)で configure しなければなりません(統計に関する二つのレベルは例外で、これらは常に利用可能です)。どのデバックに何の数が対応しているのかを調べるには -d ? を指定して slapd を起動するか、以下の表を参考にしてください。<integer> に指定可能な値には次のものがあります。
| レベル | 説明 |
| -1 | すべてのデバッグレベルを有効にする |
| 0 | デバッグしない |
| 1 | 関数呼出しのトレース |
| 2 | パケット処理のデバッグ |
| 4 | 詳細なデバッグトレース |
| 8 | 接続管理 |
| 16 | パケット送受信の印字 |
| 32 | 検索フィルタ処理 |
| 64 | 設定ファイル処理 |
| 128 | アクセス制御リスト処理 |
| 256 | 接続/操作/結果の統計ログ |
| 512 | エントリ送信の統計ログ |
| 1024 | shell バックエンドとの通信の印字 |
| 2048 | エントリ解析のデバッグ印字 |
たとえば次のように指定します。
loglevel -1
このように設定すると、大量のデバッグ情報が記録されます。
デフォルトの設定は次のとおりです。
loglevel 256
6.2.1.6. objectclass <RFC2252 Object Class Description>
このディレクティブはオブジェクトクラスを定義します。このディレクティブの使い方に関しては スキーマ指定の章を参照してください。
6.2.1.7. referral <URI>
このディレクティブは、要求を処理するためのローカルデータベースを見つけられなかった場合に、クライアントに戻す紹介先を指定します。
たとえば次のように指定します。
referral ldap://root.openldap.org
これは、OpenLDAP プロジェクトのグローバルルート LDAP サーバに非ローカルな問合せを紹介することを指定します。賢い LDAP クライアントなら戻されるサーバに再要求をするでしょうが、そのようなクライアントのほとんどは、ホスト名の部分とオプションの識別名の部分とを持った単純な LDAP URL の処理方法を知っているだけです。
6.2.1.8. sizelimit <integer>
このディレクティブは、検索操作から返すエントリの最大数を指定します。
デフォルトの設定は次のとおりです。
sizelimit 500
6.2.1.9. timelimit <integer>
このディレクティブは、slapd が検索要求の応答に使う最大秒数(実時間)を指定します。この時間内に要求が達せられなければ、時間制限を超過したことを示す結果を返します。
デフォルトの設定は次のとおりです。
timelimit 3600
6.2.2. 一般バックエンドディレクティブ
この節のディレクティブは、そのディレクティブが定義されているバックエンドにのみ適用されます。これらのディレクティブは全種別のバックエンドでサポートされます。バックエンドディレクティブは、同種別のすべてのデータベース実体に適用しますが、ディレクティブによってはデータベースディレクティブで上書きされます。
6.2.2.1. backend <type>
このディレクティブは、バックエンド宣言の始まりを示します。 <type> には表 6.2 にあげるサポートされているバックエンド種別のいずれかを指定します。
| 種別 | 説明 |
| bdb | Berkeley DB トランザクション制御バックエンド |
| dnssrv | DNS SRV バックエンド |
| hdb | Hierarchical variant of bdb backend |
| ldap | Lightweight Directory Access Protocol (代理)バックエンド |
| ldbm | 軽量 DBM バックエンド |
| meta | メタディレクトリバックエンド |
| monitor | モニタバックエンド |
| passwd | passwd(5) への読取り専用アクセスを提供 |
| perl | Perl プログラム可能なバックエンド |
| shell | Shell (外部プログラム)バックエンド |
| sql | SQL プログラム可能なバックエンド |
たとえば次のように指定します。
backend bdb
これは新しい
6.2.3. 一般データベースディレクティブ
この節のディレクティブは、そのディレクティブが定義されているデータベースにのみ適用されます。これらのディレクティブは全種別のデータベースでサポートされます。
6.2.3.1. database <type>
このディレクティブは新しいデータベース実体宣言の始まりを示します。 <type> には表 6.2 にあげるサポートされているバックエンド種別のいずれかを指定します。
たとえば次のように指定します。
database bdb
この設定は新しい
6.2.3.2. readonly { on | off }
このディレクティブは、データベースを「読取り専用」モードにします。このモードでデータベースを更新しようとすると "unwilling to perform" エラーが返ります。
デフォルトの設定は次のとおりです。
readonly off
6.2.3.3. replica
replica uri=ldap[s]://<hostname>[:<port>] | host=<hostname>[:<port>]
[bindmethod={simple|sasl}]
["binddn=<DN>"]
[saslmech=<mech>]
[authcid=<identity>]
[authzid=<identity>]
[credentials=<password>]
このディレクティブは、このデータベースの複製サイトを指定します。パラメータ uri= は、スレーブ slapd の実体があるところのスキーム、ホスト、ポート(オプション)を指定します。<hostname> はドメイン名あるいは IP アドレスを使って指定します。 <port> が与えられていなければ、標準の LDAP ポート番号(389 か 638)が使われます。
パラメータ host はもう推奨されません。代わりに uri パラメータを使ってください。
パラメータ uri は複製 LDAP サーバの場所を LDAP URI で指定します。たとえば ldap://slave.example.com:389 や ldaps://slave.example.com:636 のように指定します。
パラメータ binddn= は、スレーブ slapd の更新でバインドするための DN を与えます。これは、スレーブ slapd のデータベースに対してアクセス権 read/write を持った DN にしなければなりません。またこの DN は、スレーブ slapd 設定ファイルの updatedn ディレクティブに指定したものと一致していなければなりません。一般にこの DN はマスタデータベースの rootdn と同じにすべきではありません。 DN にはスペースが入っていることが多いので、"binddn=<DN>" 文字列は二重引用符で囲っておくとよいでしょう。
bindmethod は、スレーブ slapd への接続に使う認証がパスワードベースのものか
簡易認証は十分なデータの完全性と機密性の保護(TLS や IPSEC など)が無ければ使うべきではありません。簡易認証は binddn と credentials パラメータの指定を必要とします。
一般には SASL 認証を使うことを勧めます。SASL 認証は saslmech パラメータを使った機構の指定が必要です。指定する機構に依存して、認証アイデンティティや証明書を authcid と credentials を使って指定できます。認可アイデンティティの指定には authzid パラメータを使うかもしれません。
このディレクティブの使い方についてのさらなる情報は slurpd を利用した複製の章を参照してください。
6.2.3.4. replogfile <filename>
このディレクティブは、slapd が 変更を記録する複製ログファイルの名前を指定します。複製ログは通常 slapd が書き出し、slurpd が読み取ります。通常このディレクティブは、データベースを複製するために slurpd が使われている場合にのみ利用します。しかし slurpd を実行していなくても、トランザクションログの生成に使えます。この場合、複製ログファイルは無限に増え続けるので定期的に切り詰める必要があります。
このディレクティブの使い方についてのさらなる情報は slurpd を利用した複製の章を参照してください。
6.2.3.5. rootdn <DN>
このディレクティブは、このデータベースに対するアクセス権制御あるいは管理限度の制限に従わない DN を指定します。この DN は、このデータベースのエントリである必要はありませんし、ディレクトリ中に存在していなくてもかまいません。この DN には SASL アイデンティティを使えます。
エントリベースの例：
rootdn "cn=Manager,dc=example,dc=com"
SASL ベースの例：
rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
SASL 認証アイデンティティについてはSASL 認証の節を参照してください。
6.2.3.6. rootpw <password>
このディレクティブは rootdn の DN のためのパスワードを指定するのに使えます(rootdn がこのデータベースの DN として設定されている場合に限ります)。
たとえば次のように指定します。
rootpw secret
これには、RFC 2307 形式にハッシュ化したパスワードも指定できます。パスワードをハッシュ化するのには slappasswd(8) が使えます。
たとえば次のように指定します。
rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
このハッシュ化したパスワードはコマンド slappasswd -s secret を使って生成しました。
6.2.3.7. suffix <dn suffix>
このディレクティブは、このバックエンドデータベースに渡す問合せの DN 接尾辞を指定します。複数の suffix 行を与えてもよいですが、各データベース定義に少なくとも一つは必要です。
たとえば次のように指定します。
suffix "dc=example,dc=com"
この指定では、DN の末尾に "dc=example, dc=com" の付いた問合せがこのバックエンドに渡されます。
注記：問合せを渡すバックエンドが選択されるとき、slapd は各データベースの suffix 行を設定ファイルに現れる順番に見ていきます。したがって、あるデータベースの接尾辞が別のデータベースの接頭辞になっている場合には、設定ファイルのより後のほうに現れるようにしなければなりません。
6.2.3.8. syncrepl
syncrepl rid=<replica ID>
provider=ldap[s]://<hostname>[:port]
[type=refreshOnly|refreshAndPersist]
[interval=dd:hh:mm:ss]
[retry=[<retry interval> <# of retries>]+]
[searchbase=<base DN>]
[filter=<filter str>]
[scope=sub|one|base]
[attrs=<attr list>]
[attrsonly]
[sizelimit=<limit>]
[timelimit=<limit>]
[schemachecking=on|off]
[bindmethod=simple|sasl]
[binddn=<DN>]
[saslmech=<mech>]
[authcid=<identity>]
[authzid=<identity>]
[credentials=<passwd>]
[realm=<realm>]
[secprops=<properties>]
このディレクティブは、現在のデータベースをマスタの内容の複製であることを指定します。つまり現在の slapd(8) で syncrepl 複製エンジンを動かして複製コンシューマとなります。マスタデータベースは provider パラメータに指定した複製プロバイダサイトにあることになります。レプリカデータベースは LDAP Content Synchronization protocol を用いてマスタの最新の内容と同じになるように維持されます。このプロトコルについてのより詳しい情報は draft-zeilenga-ldup-sync-xx.txt (作業中)を参照してください。
パラメータ rid は、複製コンシューマサーバの設定の中の現在の syncrepl ディレクティブの識別子として利用されます。 <replica ID> は、現在の syncrepl ディレクティブによって記述される syncrepl 指定が一意に識別されるようにします。 <replica ID> には０以上で３桁以内の整数値を指定してください。
パラメータ provider にはマスタ内容を持つ複製プロバイダサイトを URI で指定します。パラメータ provider にはプロバイダ slapd 実体のあるサイトのスキーム、ホスト、ポート(オプション)を指定します。ホストの指定 <hostname> はドメイン名でも IP アドレスでもかまいません。たとえば ldap://provider.example.com:389 や ldaps://192.168.1.1:636 のように指定します。ポートの指定 <port> を省略した場合には標準 LDAP ポート番号(389 または 636)が使われます。 syncrepl はコンシューマ主動のプロトコルを使うので、その指定はコンシューマサイトにあるという点で、プロバイダサイトに指定のある replica とは違っています。 syncrepl と replica ディレクティブは２つの独立した複製機構を定義します。それらは互いの複製ノードとはなりません。
syncrepl の複製対象は、検索指定を使って定義します。コンシューマ slapd は検索指定にしたがってプロバイダ slapd に検索要求を送ります。検索指定は、通常の検索指定と同様に searchbase, scope, filter, attrs, attrsonly, sizelimit, timelimit パラメータを持ちます。 syncrepl の検索指定は ldapsearch(1) クライアント検索ツールのパラメータと同じ値の形式と同じデフォルト値を持ちます。
LDAP Content Synchronization プロトコルには refreshOnly と refreshAndPersist の２種類の操作があります。この操作の種類は type パラメータで指定します。 refreshOnly 操作では定期的に同期検索操作を行います。それぞれの同期検索操作が終わった後に、次の同期検索操作を再スケジューリングします。この時間隔は interval パラメータに指定します。時間隔のデフォルトは１日に設定されています。 refreshAndPersist 操作では、同期検索がプロバイダ slapd で継続されます。プロバイダ slapd に更新があると、継続している同期検索のレスポンスとしてコンシューマ slapd に searchResultEntry を返します。
複製中にエラーが起きると、コンシューマは再トライパラーメータにしたがって再接続を試みます。再トライパラメータは <retry interval> と <# of retries> のペアのリストです。たとえば retry="60 10 300 3" という指定は、最初の10回の再トライが60秒おきに、続く3回が300秒ごとであることを意味します。<# of retries> に + を指定すると、成功するまで限りなく再トライすることを意味します。
schemachecking パラメータの切替えにより、 LDAP Sync コンシューマサイトでスキーマ検査を行うかを指定できます。このパラメータを on にすると、複製に格納されるエントリすべてのスキーマがチェックされます。複製に格納するエントリはどれも、スキーマ定義の要求する属性を持っているべきです。このパラメータを off にすると、エントリがスキーマの適合性の検査なしに格納されます。デフォルトは off です。
binddn パラメータには、プロバイダ slapd に対して syncrepl 検索を行う際の bind に使う DN を指定します。この DN はマスタデータベースの複製対象に対して read アクセス権を持っているべきです。
bindmethod には、プロバイダ slapd に接続する際の認証方式を指定します。パスワードベースの簡易認証を利用するなら simple、
簡易認証は、十分なデータの完全性と機密性の保護(TLS や IPSEC など)が無ければ使うべきではありません。簡易認証は binddn と credentials パラメータの指定を必要とします。
一般には SASL 認証を推奨します。SASL 認証を行うには saslmech パラメータに機構の指定が必要です。指定する機構に依存して、認証 ID や認証情報を authcid や credentials に指定できます。パラメータ authzid は認可 ID を指定するのに使います。
パラメータ realm は特定の機構が認証する ID のレルムを指定します。パラメータ secprops は Cyrus SASL のセキュリティプロパティを指定します。
syncrepl 複製機構は３つのネイティブなバックエンド back-bdb, back-hdb, and back-ldbm でサポートされています。
このディレクティブの使い方についてより詳しくは管理者ガイドのLDAP Sync 複製の章を参照してください。
6.2.3.9. updatedn <dn>
このディレクティブはスレーブの slapd にのみ適用できます。このディレクティブは複製の変更を許す DN を指定します。これには、複製の変更をするときに slurpd(8) がバインドする DN、あるいは SASL アイデンティティと関連した DN を指定します。
エントリベースの例：
updatedn "cn=Update Daemon,dc=example,dc=com"
SASL ベースの例：
updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
このディレクティブの使い方についてのさらなる情報は slurpd を利用した複製の章を参照してください。
6.2.3.10. updateref <URL>
このディレクティブはスレーブの slapd にのみ適用できます。これは複製の更新要求を送るクライアントに戻す URL を指定します。このディレクティブはいくつも指定でき、各
たとえば次のように指定します。
updateref ldap://master.example.net
6.2.4. BDB と HDB データベースのディレクティブ
このカテゴリのディレクティブは
6.2.4.1. directory <directory>
このディレクティブは、データベースと関連するインデックスを含んだ BDB ファイル郡を置くディレクトリを指定します。
デフォルトの設定は次のとおりです。
directory /usr/local/var/openldap-data
6.2.5. LDBM データベースディレクティブ
このカテゴリのディレクティブは、
6.2.5.1. cachesize <integer>
このディレクティブは、LDBM バックエンドデータベースの実体によって管理されるメモリ内キャッシュのエントリ数を指定します。
デフォルトの設定は次のとおりです。
cachesize 1000
6.2.5.2. dbcachesize <integer>
このディレクティブは、オープンされているインデックスファイルそれぞれと関連づけられているメモリ内キャッシュのサイズをバイト数で指定します。基板のデータベース方式でサポートされなければ、このディレクティブは黙って無視されます。この数を増やすとより多くのメモリを使いますが、劇的な性能の向上が得られます。特に 更新とインデックスの作成で性能の向上が顕著です。
デフォルトの設定は次のとおりです。
dbcachesize 100000
6.2.5.3. dbnolocking
このディレクティブが指定されるとデータベースのロックが無効になります。このディレクティブは、データのセキュリティを犠牲にしてでも性能を上げたい場合に使います。
6.2.5.4. dbnosync
このディレクティブは、変更に対するメモリ内の変更をディスク上の内容とすぐには同期をとらないようにします。このディレクティブは、データの完全性を犠牲にしてでも性能を上げたい場合に使います。
6.2.5.5. directory <directory>
このディレクティブは、データベースと関連するインデックスを含んだ LDBM ファイル郡を置くディレクトリを指定します。
デフォルトの設定は次のとおりです。
directory /usr/local/var/openldap-data
6.2.5.6. index {<attrlist> | default} [pres,eq,approx,sub,none]
このディレクティブは、与えた属性について管理するインデックスを指定します。 <attrlist> だけが与えられた場合、デフォルトのインデックスが管理されます。
たとえば次のように指定します。
index default pres,eq
index objectClass,uid
index cn,sn eq,sub,approx
１行目は、インデックスのデフォルトセットを存在(presence)と等価性(equality)を管理するように設定します。２行目は、objectClass と uid 属性型についてデフォルトのインデックス(pres, eq)を管理すように設定します。３行目は、cn と sn 属性型について等価性、部分文字列(substring)、近似(approximate)のインデックスを管理するように設定します。
6.2.5.7. mode <integer>
このディレクティブは、新たに作成されるデータベースインデックスファイルの持つファイル保護モードを指定します。
デフォルトの設定は次のとおりです。
mode 0600
6.3. アクセス制御
slapd のエントリおよび属性へのアクセス権は、設定ファイルの access ディレクティブによって制御されます。access 行の一般的な形式を次に示します。
<access directive> ::= access to <what>
[by <who> <access> <control>]+
<what> ::= * |
[dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
[filter=<ldapfilter>] [attrs=<attrlist>]
<basic-style> ::= regex | exact
<scope-style> ::= base | one | subtree | children
<attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
<attr> ::= <attrname> | entry | children
<who> ::= * | [anonymous | users | self
| dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
[dnattr=<attrname>]
[group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
[peername[.<basic-style>]=<regex>]
[sockname[.<basic-style>]=<regex>]
[domain[.<basic-style>]=<regex>]
[sockurl[.<basic-style>]=<regex>]
[set=<setspec>]
[aci=<attrname>]
<access> ::= [self]{<level>|<priv>}
<level> ::= none | auth | compare | search | read | write
<priv> ::= {=|+|-}{w|r|s|c|x|0}+
<control> ::= [stop | continue | break]
ここで、<what> 部にはアクセス制御されるエントリや属性を指定します。 <who> 部にはアクセス権を与える実体を指定します。 <access> 部には与えるアクセス権を指定します。複数の <who> <access> <control> の指定がサポートされています。これによりエントリと属性のセットに対して、多くの実体に違ったアクセス権を与えることができます。これらのアクセス制御オプションのすべてはここで説明しません。より詳しくは slapd.access(5) man ページを参照してください。
6.3.1. アクセスを制御する対象の指定
アクセス権指定の <what> 部は、アクセス制御するエントリおよび属性を決定します。エントリの指定には一般に二つの手段があります。それはDNによる指定とフィルタによる指定です。次の修飾子は DN によってエントリを選択します。
to *
to dn[.<basic-style>]=<regex>
to dn.<scope-style>=<DN>
１行目の形式はすべてのエントリを選択するのに利用します。２行目の形式は、正規表現を目的のエントリの正規化したDNに一致させることによってエントリを選択するのに利用します。 (２行目の形式について本章ではもうこれ以上取り上げません。) ３行目の形式は、DNの要求したスコープ(scope)内にあるエントリを選択するのに利用します。<DN>はRFC2253に記述のある識別名(Distinguished Name)の文字列表現です。
スコープには base, one, subtree, children のいずれかを指定できます。base を指定すると、与えたDNを持つエントリにのみ一致します。one を指定すると、与えたDNを親とするエントリに一致します。subtree を指定すると、与えたDNをルートとしたサブツリー内のすべてのエントリに一致します。children を指定すると、DN配下のすべてのエントリーに一致します(指定したDNを持つエントリは含まれません)。
たとえばディレクトリが以下の名前のエントリを持っているとします。
0: o=suffix
1: cn=Manager,o=suffix
2: ou=people,o=suffix
3: uid=kdz,ou=people,o=suffix
4: cn=addresses,uid=kdz,ou=people,o=suffix
5: uid=hyc,ou=people,o=suffix
この場合
-
dn.base="ou=people,o=suffix" は 2 に一致します
dn.one="ou=people,o=suffix" は 3 と 5 に一致します
dn.subtree="ou=people,o=suffix" は 2, 3, 4, 5 に一致します
dn.children="ou=people,o=suffix" は 3, 4, 5 に一致します
エントリはフィルタを使って選択することもできます。
to filter=<ldap filter>
ここで、<ldap filter> には RFC2254 に説明のある LDAP 検索フィルタの文字列表現を指定します。たとえば次のように指定します。
to filter=(objectClass=person)
エントリは <what> 節に両方の修飾語を含めることによって、 DNとフィルタの両方で選択することもできます。
to dn.one="ou=people,o=suffix" filter=(objectClass=person)
エントリ中の属性は <what> セレクタに属性名をコンマで区切って列挙することにより選択できます。
attrs=<attribute list>
単一の属性名と値セレクタを用いることにより特定の属性値を選べます。
attrs=<attribute> val[.<style>]=<regex>
二つの擬似属性、entry と children があります。目的のエントリを読み取る(そして返す)ためには、そのエントリの entry 属性への read アクセス権をアクセスする対象が持っていなければなりません。エントリを追加あるいは削除するには、そのエントリの entry 属性への write アクセス権と、そのエントリの親エントリの children 属性への write アクセス権をアクセスする対象が持っていなければなりません。エントリを改名するには、そのエントリの entry 属性への write アクセス権と、そのエントリの新旧両方の親エントリの children 属性への write アクセス権をアクセスする対象が持っていなければなりません。この節の終りでは、この理解の助けになる例を示します。
特殊なエントリセレクタ "*" というものもあります。これは、あらゆるエントリを選択するために使われます。これは他の <what> セレクタを与えない場合に使われます。これは "dn=.*" と指定することと等価です。
6.3.2. アクセス権を与える対象の指定
<who> 部は、アクセス権が与えられる実体(entity)を示します。アクセス権は「実体」に与えられるのであって「エントリ」に与えられるのではありません。次の表に実体指定子について要約します。
| 指定子 | 実体 |
| * | 匿名ユーザも認証されたユーザも含めたすべて |
| anonymous | 匿名(認証されていない)ユーザ |
| users | 認証されたユーザ |
| self | 目的のエントリと結びつけられているユーザ |
| dn[.<basic-style>]=<regex> | 正規表現に一致するユーザ |
| dn.<scope-style>=<DN> | DN のスコープ内のユーザ |
DN 指定子は、<what> 節の DN 指定子とほぼ同様に振る舞います。
その他の制御因子もサポートされています。たとえば <who> はアクセス権が適用されるエントリが持つ DN を値とする属性に格納されているエントリで制限できます。
dnattr=<dn-valued attribute name>
指定子 dnattr は、エントリの属性に DN が格納されているエントリにアクセス権を与えるために使います(たとえば、group エントリの管理者として格納されているものに group エントリへのアクセス権を与えるなど)。
要素の中には環境によって適切でないものがあります。たとえば domain 要素は IP からのドメイン検索に依存していますが、これは容易にだませるので、domain 要素は回避すべきです。
6.3.3. 与えるアクセス権
与える <access> の種類には次のものがあります。
| レベル | 権限 | 説明 |
| none | =0 | アクセス不可 |
| auth | =x | バインドに必要 |
| compare | =cx | 比較に必要 |
| search | =scx | 検索フィルタの適用に必要 |
| read | =rscx | 検索結果の読取りに必要 |
| write | =wrscx | 更新/名前変更に必要 |
各レベルは、より下位レベルのアクセス権のすべてを暗に適用します。たとえば、あるエントリついて誰かに write アクセス権を与えた場合、 read, search, compare, auth アクセス権も与えたことになります。しかし、特定の許可を与えるには権限指定を使えます。
6.3.4. アクセス制御の評価
要求者にエントリや属性に対するアクセス権を与えるかを評価するとき、 slapd はエントリや属性を設定ファイルに与えられている <what> と比較します。各エントリについて、そのエントリを保持するデータベースに与えられているアクセス制御がはじめに適用され、その後にグローバルな access ディレクティブが適用されます。この優先順位で、設定ファイルに現れる順番に access ディレクティブを調べます。slapd は、エントリや属性に一致する最初の <what> セレクタを見つけたところで調査を止めます。該当する access ディレクティブは、slapd がアクセス権を評価するために使うものです。
次に slapd は、上で選択された access ディレクティブの <who> セレクタを出現順に、アクセスを要求する実体と比較します。これは要求者に一致する最初の <who> セレクタを見つけたところで終ります。これは、アクセスを要求する実体がエントリや属性に対して持つアクセス権を決定します。
最後に slapd は、選択された <access> 節に与えられているアクセス権をクライアントによって要求されたアクセスと比較します。アクセス権が実際のアクセス以上のものであれば、アクセスが認められます。さもなければアクセスは認められません。
この access ディレクティブの評価順序により、設定ファイル中での access ディレクティブの位置が重要となります。ある access ディレクティブが別の access ディレクティブよりも限定的であった場合には、設定ファイルの中でより前に現れるようにしなければなりません。同様に、ある <who> セレクタが別の <who> セレクタよりも限定的であった場合には、access ディレクティブの中でより前に現れるようにしなければなりません。後では、この理解の助けになるアクセス制御の例を示します。
6.3.5. アクセス制御の例
前述したアクセス制御機能は実に強力です。この節ではアクセス制御の使い方がより分かりやすくなるよう、いくつかの利用例を示します。
まずは、簡単な例から。
access to * by * read
この access ディレクティブは、あらゆる人に読取り(read)アクセス権を与えます。
access to *
by self write
by anonymous auth
by * read
このディレクティブの利用例は、認証ユーザが自分のエントリを更新できるようにし、匿名ユーザが認証を行えるようにし、その他すべてのユーザが読み取れる(read)ようにします。一致する最初の by <who> 節だけが適用することに注意してください。したがって、匿名(anonymous)ユーザには認証権(auth)が与えられ、読取り権(read)は与えられません。最後の節は "by users read" としたほうがよいでしょう。
適切な保護レベルを基にして操作を制限したいことがよくあります。この目的のために利用できるセキュリティ強度係数(Security Strength Factors: SSF)を利用した例を次に示します。
access to *
by ssf=128 self write
by ssf=64 anonymous auth
by ssf=64 users read
このディレクティブの記述例では、認証ユーザが自分のエントリを更新できるのはセキュリティ保護で 128 以上の強度が確立されている場合であり、匿名ユーザの認証アクセスと認証ユーザの読取りアクセスが許されるのはセキュリティ保護で 64 以上の強度が確立されている場合です。クライアントが十分なセキュリテイ保護を確立していない場合、暗黙の by * none 節が適用されます。
次の例は、DN でエントリを選択するのにスタイル指定を利用しているところを示しています。この二つのアクセス権宣言の順番は重要です。
access to dn.children="dc=example,dc=com"
by * search
access to dn.children="dc=com"
by * read
この例では、読取り(read)アクセス権が dc=com サブツリー配下のエントリに与えられますが、dc=example,dc=com サブツリー配下に限っては検索(search)アクセス権しか与えられません。どちらの access ディレクティブも dc=com には一致しないので、この DN にアクセス権は与えられません。このアクセス権指定の順序を逆にすると、すべての dc=example,dc=com エントリは dc=com エントリでもあるので、後のディレクティブが全く適用されなくなってしまいます。
また、どの access to ディレクティブも一致しない場合あるいはどの by <who> にも一致しない場合に アクセスが拒否されることに注意してください。すなわち、あらゆる access to ディレクティブは暗黙の by * none 節で終っていて、あらゆるアクセスリストは暗黙の access to * by * none ディレクティブで終っているのです。
次の例も順序の重要性を示していますが、今度はアクセス権指定の他に by <who> 節の順序についても示しています。またこの例では、特定の属性へのアクセス権を与える属性セレクタと、さまざまな <who> セレクタの利用法についても示しています。
access to dn.subtree="dc=example,dc=com" attr=homePhone
by self write
by dn.children="dc=example,dc=com" search
by peername.regex=IP:10\..+ read
access to dn.subtree="dc=example,dc=com"
by self write
by dn.children="dc=example,dc=com" search
by anonymous auth
この例は、"dc=example,dc=com" サブツリーのエントリに適用されます。属性 homePhone を除くすべての属性に対し、当該エントリ自体には書込み権(write)を与え、 example.com エントリ配下のエントリには検索権(search)を与え、その他のエントリには認証/認可の場合(常に匿名で行われる)を除きアクセス権を与えません(暗黙の by * none) を適用)。。属性 homePhone に対しては、当該エントリ自体には書込み権(write)を与え、 example.com エントリ配下のエントリには検索権(search)を与え、 example.com ドメイン内のどこからか接続するクライアントには読取り権を与え、その他には参照できないようにします(暗黙の by * none を適用)。その他すべてのアクセスは暗黙の access to * by * none によって拒否されます。
特定の DN に属性の追加と除去を許すことが有用なことがあります。たとえば、あるグループを作成し、人々に member 属性への追加と除去を自分自身の DN に限ってできるようにしたい場合、次のようなアクセス権宣言で実現できます。
access to attr=member,entry
by dnattr=member selfwrite
セレクタ dnattr <who> は、アクセス権が member 属性にリストされているエントリに適用されることを指定します。アクセス権セレクタselfwrite は、そのような member 達が自分自身の DN だけを属性から追加/削除できることを指定します。また、entry 属性を追加しておくことが必要です。なぜなら、エントリのどの属性にアクセスするにせよ、エントリへのアクセス権が必要になるからです。
6.4. 設定ファイルの例
以下は設定ファイルの例です。例の所々には説明をつけてあります。これは二つのデータベースを定義していて、それぞれ
1. # example config file - global configuration section 2. include /usr/local/etc/schema/core.schema 3. referral ldap://root.openldap.org 4. access to * by * read
行 1 はコメントです。行 2 は core スキーマ定義を含んだ別の設定ファイルを取り込みます。行 3 の referral ディレクティブは、後に定義するデータベースのどれかにローカルでない問合せについて、ホスト root.openldap.org で動作している標準ポート(389)の LDAP サーバを参照することを意味します。
行 4 はグローバルなアクセス制御です。これは、すべてのエントリに適用します (データベース固有のアクセス制御の後に適用します)。
設定ファイルの例の次の部分は、ツリーの "dc=example,dc=com" 配下にあるものについての問合せを処理する BDB バックエンドを定義します。このデータベースは二つのスレーブ slapd に複製されます。スレーブの一つは truelies で、もう一つは judgmentday です。いくつかの属性についてインデックスが管理され、userPassword 属性は認可されていないアクセスから保護されます。
5. # BDB definition for the example.com 6. database bdb 7. suffix "dc=example,dc=com" 8. directory /usr/local/var/openldap-data 9. rootdn "cn=Manager,dc=example,dc=com" 10. rootpw secret 11. # replication directives 12. replogfile /usr/local/var/openldap/slapd.replog 13. replica uri=ldap://slave1.example.com:389 14. binddn="cn=Replicator,dc=example,dc=com" 15. bindmethod=simple credentials=secret 16. replica uri=ldaps://slave2.example.com:636 17. binddn="cn=Replicator,dc=example,dc=com" 18. bindmethod=simple credentials=secret 19. # indexed attribute definitions 20. index uid pres,eq 21. index cn,sn,uid pres,eq,approx,sub 22. index objectClass eq 23. # database access control definitions 24. access to attr=userPassword 25. by self write 26. by anonymous auth 27. by dn.base="cn=Admin,dc=example,dc=com" write 28. by * none 29. access to * 30. by self write 31. by dn.base="cn=Admin,dc=example,dc=com" write 32. by * read
行 5 はコメントです。データベース定義の始まりは、行 6 の database キーワードで示します。行 7 は、このデータベースに渡す問合せのための DN 接尾辞を指定します。行 8 は、データベースファイルを置くディレクトリを指定します。
行 9 と 10 は、このデータベースのスーパユーザエントリとそのパスワードを指定します。このエントリはアクセス制御あるいはサイズ/時間制限に従いません。
行 11 から 18 は複製の設定です。行 12 は複製ログファイルを指定します(データベースの変更が記録されます - このファイルには slapd が書き込み、slurpd が読み出します)。行 13 から 15 は複製が作られるホスト、更新を行うときのバインドのための DN、バインド方法(簡易認証)、binddn のための証明書(パスワード)を指定します。行 16 から 18 は、第２の複製サイトを指定します。これらのディレクティブについてより詳しくは slurpd を利用した複製の章を参照してください。
行 20 から 22 は、さまざまな属性のために管理するインデックスを指定します。
行 24 から 32 は、データベース内のエントリのためのアクセス制御を指定します。これは最初のデータベースに指定されていますが、制御はどのデータベースにも保持されないエントリ(ルート DSE など)にも適用します。すべての適切なエントリの userPassword 属性は、そのエントリ自身および "admin" エントリから更新可能です。この属性は認証/認可の目的には使えますが読み取れません。その他すべての属性は、そのエントリ自身および "admin" エントリから更新可能で、認証されたユーザから読み取れます。
設定ファイルの例の次の部分は、別の BDB データベースを定義します。この BDB データベースは dc=example,dc=net サブツリーに関する問合せを処理します。行 39 がないと、行 4 のグローバルアクセス規則により読み取りアクセスが許可されることに注意してください。
33. # BDB definition for example.net 34. database bdb 35. suffix "dc=example,dc=net" 36. directory /usr/local/var/openldap-data-net 37. rootdn "cn=Manager,dc=example,dc=com" 38. index objectClass eq 39. access to * by users read