目次 | 上位のトピック | 前のトピック | 次のトピック
ホーム | カタログ


5. slapd の設定

ソフトウェアのインストールが完了したら、インストールしたサイトで利用できるように slapd(8) の設定を行います。以前の OpenLDAP リリースと違い、2.3 では slapd の実行時設定が完全に LDAP で可能であり、標準の LDAP 操作により LDIF を使って管理できます。 LDAP 設定エンジンでは slapd の実行時に設定変更が可能です。一般には設定を反映するためのサーバ再起動も必要ありません。古いスタイルの slapd.conf(5) もまだサポートしていますが、実行時の変更が反映されるようにするには新しい slapd.d(5) 形式に変換しておかなければなりません。古いスタイルの設定では、普通は /usr/local/etc/openldap/slapd.conf としてインストールされる単一のファイルを使っていましたが、新しいスタイルでは設定を格納するために slapd バックエンドデータベースを使います。設定データベースは普通 /usr/local/etc/openldap/slapd.d ディレクトリに置かれます。

slapd(8) や slurpd(8) のコマンドラインオプションを使えば別の設定ファイルを指定できます。この章では設定システムの一般的なフォーマットについて説明し、その後によく使われる設定について詳しく説明します。

注記：バックエンドやオーバレイの一部にはまだ実行時設定に対応していないものがあります。未対応のものを使うには古いスタイルの slapd.conf(5) ファイルを使わなければなりません。

注記：slurpd の現バージョンは新しい設定エンジンに対応していません。複製に slurpd を使う場合には古いスタイルの slapd.conf ファイルを使い続けなければなりません。

5.1. 設定ツリーのレイアウト

slapd の設定は既定のスキーマと DIT を持つ特別な LDAP ディレクトリとして格納されます。グローバル設定、スキーマ定義、バックエンドとデータベースの定義、その他雑多な項目を入れるための特定のオブジェクトクラスがあります。設定ツリーの一例を図5.1に示します。

図5.1: 設定ツリーの例

設定については他のオプジェクトも関係していますが、図を簡略化するためにあえて省略しています。

slapd.d 設定ツリーは特殊な構造を持っています。ツリーのルートは cn=config という名前で、グローバル設定を持っています。その他の設定は、別の子エントリに持ちます。

LDIF ファイルの一般的な規則は設定情報にも適用されます。コメント行は '#' 文字で始まり、この行は無視されます。空白文字で始まる行は直前の行からの継続とみなされ(直前の行がコメントであっても継続とみなされます)、先頭にある空白文字が取り除かれます。エントリを区切るには空行を挿入します。

設定 LDIF の一般的な形式は次のようになります。

        # グローバル設定
        dn: cn=config
        objectClass: olcGlobal
        cn: config
        <global config settings>

        # スキーマ定義
        dn: cn=schema,cn=config
        objectClass: olcSchemaConfig
        cn: schema
        <システムスキーマ>

        dn: cn={X}core,cn=schema,cn=config
        objectClass: olcSchemaConfig
        cn: {X}core
        <コアスキーマ>

        # ユーザ定義のスキーマの追加
        ...

        # バックエンド定義
        dn: olcBackend=<typeA>,cn=config
        objectClass: olcBackendConfig
        olcBackend: <typeA>
        <backend-specific settings>

        # データベース定義
        dn: olcDatabase={X}<typeA>,cn=config
        objectClass: olcDatabaseConfig
        olcDatabase: {X}<typeA>
        <database-specific settings>

        # 続きの定義と設定
        ...

上記のエントリの中には名前に数字の添字 "{X}" のついたものがあります。ほとんどの設定には本質的に順序に依存するところがありますが、データベースでは本質的に順序づけられていません。数字の添字は、設定データベースにおいて一貫した順序をつけるためのもので、これによりすべての順序の依存性を維持します。ほとんどの場合において添字を与える必要はなく、エントリを作成するときの順番を元に自動的に生成します。

設定ディレクティブは個別の属性値として指定します。 slapd で利用する属性とオブジェクトクラスのほとんどには名前に接頭辞 "olc" (OpenLDAP Configuration)が付いています。一般に、属性と古いスタイルの slapd.conf 設定キーワードは１対１に対応していて、キーワードに接頭辞 "olc" を付け加えたものが属性名になります。

設定ディレクティブの中には引数をとるものがあります。引数のある場合には空白で区切って並べます。引数に空白を含めたい場合には、引数を二重引用符で囲みます。実際のテキストで置き換えるディレクティブの引数はブラケット <> で示します。

OpenLDAP の配布物には設定ファイルの例も含まれていて、 /usr/local/etc/openldap にインストールします。スキーマ定義(属性型とオブジェクトクラス)を持つファイルも /usr/local/etc/openldap/schema ディレクトリに置いています。

5.2. 設定ディレクティブ

この節では、よく使われる設定ディレクティブについて詳説します。設定ディレクティブの全リストについては slapd.d(5) マニュアルページを参照してください。この節では、設定ファイルのディレクティブを cn=config エントリのグローバルディレクティブから始め、トップダウン順で説明していきます。各ディレクティブと(もしあれば)そのデフォルト値について説明し、設定例を示します。

5.2.1. cn=config

このエントリが持つディレクティブは当該サーバの全体に適用されます。多くはシステムやネットワークに関するものであり、データベース関連のものはありません。このエントリは olcGlobal オブジェクトクラスを持たなければなりません。

5.2.1.1. olcIdleTimeout: <integer>

アイドル状態のクライアント接続を強制的に切断するまでの秒数を指定します。idletimeout の値が 0 であると(デフォルト) この機能は無効になります。

5.2.1.2. olcLogLevel: <level>

このディレクティブは、デバッグ情報と操作の統計値を syslog に出力するレベルを指定します(現在のところ、syslogd(8) の LOG_LOCAL4 ファシリティに記録されます)。このオプションが有効になるようにするには OpenLDAP を --enable-debug 付き(デフォルト)で configure しなければなりません(統計に関する二つのレベルは例外で、これらは常に利用可能です)。ログレベルは整数またはキーワードで指定できます。<integer> に指定可能な値には次のものがあります。

表5.1: デバッグレベル
レベル キーワード 説明
-1 Any すべてのデバッグレベルを有効にする
0   デバッグしない
1 Trace 関数呼出しのトレース
2 Packets パケット処理のデバッグ
4 Args 詳細なデバッグトレース
8 Conns 接続管理
16 BER パケット送受信の印字
32 Filter 検索フィルタ処理
64 Config 設定の処理
128 ACL アクセス制御リスト処理
256 Stats 接続/操作/結果の統計ログ
512 Stats2 エントリ送信の統計ログ
1024 Shell shell バックエンドとの通信の印字
2048 Parse エントリ解析のデバッグ印字
4096 Cache データベースキャッシュ処理
8192 Index データベースインデックスの処理
16384 Sync syncrepl コンシューマ処理

たとえば次のように指定します。

 olcLogLevel: -1

このように設定すると、大量のデバッグ情報が記録されます。

 olcLogLevel: Conns Filter

このように設定すると、接続と検索フィルタ処理だけが記録されます。

デフォルトの設定は次のとおりです。

 olcLogLevel: Stats

5.2.1.3. olcReferral <URI>

このディレクティブは、要求を処理するためのローカルデータベースを見つけられなかった場合に、クライアントに戻す紹介先を指定します。

たとえば次のように指定します。

        olcReferral: ldap://root.openldap.org

これは、OpenLDAP プロジェクトのグローバルルート LDAP サーバに非ローカルな問合せを紹介することを指定します。賢い LDAP クライアントなら戻されるサーバに再要求をするでしょうが、そのようなクライアントのほとんどは、ホスト名の部分とオプションの識別名の部分とを持った単純な LDAP URL の処理方法を知っているだけです。

5.2.1.4. エントリの例

dn: cn=config
objectClass: olcGlobal
cn: config
olcIdleTimeout: 30
olcLogLevel: Stats
olcReferral: ldap://root.openldap.org

5.2.2. cn=include

include エントリは１つのインクルードファイルのパス名を持ちます。インクルードファイルは古いスタイルの slapd.conf 設定システムの一部であり、slapd.conf のフォーマットである必要があります。インクルードファイルは主にスキーマ指定のロードに使われていたもので、まだサポートされていますが、利用することは既に時代遅れとなっています。 include エントリは olcIncludeFile オブジェクトクラスを持たなければなりません。

5.2.2.1. olcInclude: <filename>

このディレクティブは、与えたファイルから追加の設定情報を読み込むことを指定します。

注記：このディレクティブの取扱いには注意してください - 入れ子になった include ディレクティブに制限はなく、include がループになった場合でも検出されません。

5.2.2.2. エントリの例

dn: cn=include{0},cn=config
objectClass: olcIncludeFile
cn: include{0}
olcInclude: ./schema/core.schema

dn: cn=include{1},cn=config
objectClass: olcIncludeFile
cn: include{1}
olcInclude: ./schema/cosine.schema

5.2.3. cn=module

slapd の構築で動的ロードモジュールのサポートが有効にした場合、エントリ cn=module にロードするモジュールを設定できます。

5.2.3.1. olcModuleLoad: <filename>

ロードする動的ロード可能モジュールの名前を指定します。引数の <filename> には絶対パス名か単純なファイルを指定できます。絶対パス名で指定しない場合には olcModulePath ディレクティブに指定したディレクトリからモジュールを探します。

5.2.3.2. olcModulePath: <pathspec>

動的ロード可能モジュールを検索するディレクトリのリストを指定します。典型的にパスはコロンで区切りますが、何で区切るかは OS に依存します。

5.2.3.3. エントリの例

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: /usr/local/lib/smbk5pwd.la

dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /usr/local/lib:/usr/local/lib/slapd
olcModuleLoad: accesslog.la
olcModuleLoad: pcache.la

5.2.4. cn=schema

エントリ cn=schema は、slapd に組込みのスキーマ定義のすべてを持ちます。このエントリ中の値は slapd が生成するので、設定ファイルにスキーマ定義を与える必要はありません。それでもこのエントリを定義しなければならないのは、下方に追加するユーザ定義のスキーマのベースとなるためです。 schema エントリは olcSchemaConfig オブジェクトクラスを持たなければなりません。

5.2.4.1. olcAttributeTypes: <RFC2252 Attribute Type Description>

このディレクティブは属性型を定義します。このディレクティブの使い方に関しては スキーマ指定の章を参照してください。

5.2.4.2. olcObjectClasses: <RFC2252 Object Class Description>

このディレクティブはオブジェクトクラスを定義します。このディレクティブの使い方に関しては スキーマ指定の章を参照してください。

5.2.4.3. エントリの例

dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema

dn: cn=test,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: test
olcAttributeTypes: ( 1.1.1
  NAME 'testAttr'
  EQUALITY integerMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
olcAttributeTypes: ( 1.1.2 NAME 'testTwo' EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
olcObjectClasses: ( 1.1.3 NAME 'testObject'
  MAY ( testAttr $ testTwo ) AUXILIARY )

5.2.5. バックエンド固有のディレクティブ

バックエンドのディレクティブは、同じ種別のデータベース実体のすべてに適用するもので、ディレクティブによっては、データベースのディレクティブで上書きできます。backend エントリは olcBackendConfig オブジェクトクラスを持たなければなりません。

5.2.5.1. olcBackend: <type>

このディレクティブは、バックエンド固有の設定エントリを決めます。 <type> には表 5.2 にあげるサポートされているバックエンド種別のいずれかを指定します。

表 5.2: データベースバックエンド
種別 説明
bdb BBerkeley DB トランザクション制御バックエンド
config slapd 設定バックエンド
dnssrv DNS SRV バックエンド
hdb Hierarchical variant of bdb backend
ldap Lightweight Directory Access Protocol (代理)バックエンド
ldbm L軽量 DBM バックエンド
ldif LDIF バックエンド
meta メタディレクトリバックエンド
monitor モニタバックエンド
passwd  passwd(5) への読取り専用アクセスを提供
perl Perl プログラム可能なバックエンド
shell Shell (外部プログラム)バックエンド
sql SSQL プログラム可能なバックエンド

たとえば次のように指定します。

        olcBackend: bdb

このエントリには他のディレクティブが無いので、一般にこのエントリは不要です。特定のバックエンドが、利用形態により追加の属性を定義している可能性がありますが、今のところそのようなものはまだ定義されていません。したがって、このようなディレクティブは実際の設定には普通は登場しません。

5.2.5.2. エントリの例

 dn: olcBackend=bdb,cn=config
 objectClass: olcBackendConfig
 olcBackend: bdb

5.2.6. データベース固有のディレクティブ

本節のディレクティブはあらゆる種別のデータベースでサポートされています。 database エントリは olcDatabaseConfig オブジェクトクラスを持たなければなりません。

5.2.6.1. olcDatabase: [{<index>}]<type>

このディレクティブはデータベース実体を指定します。数字の {<index>} は同じ種別のデータベースを複数利用する場合に、それらを区別するために指定します。このディレクティブは新しいデータベース実体宣言の始まりを示します。 <type> には表 5.2 にあげるサポートされているバックエンド種別のいずれかか frontend を指定します。

frontend は、他のデータベース全体に適用するデータベースレベルのオプションを保持するために使われます。後続のデータベース定義では frontend での設定を上書きできます。

config データベースも特殊なものです。 config と frontend データベースは、設定に明示せずとも常に暗黙に作成されますし、他のデータベースに先だって作成されます。

たとえば次のように指定します。

        olcDatabase: bdb

この設定は新しい BDB バックエンドデータベース実体の始まりを示します。

5.2.6.2. olcAccess: to <what> [ by <who> <accesslevel> <control> ]+

このディレクティブは、エントリや属性の１セット(<what> に指定)に対するアクセス権(<accesslevel> に指定)を１人以上の要求者(<who> に指定)に与えます。基本的な使い方についてはこの章の アクセス制御の節を参照してください。

注記：ディレクティブ {EX:olcAccess の指定がなければ、デフォルトのアクセス制御ポリシーである to * by * read を適用します。これは、すべての認証ユーザと匿名ユーザに読取りアクセス権を与えます。

frontend に定義したアクセス制御は、その他すべてのデータベースの制御に付加されます。

5.2.6.3. olcReadonly { TRUE | FALSE }

このディレクティブは、データベースを「読取り専用」モードにします。このモードでデータベースを更新しようとすると "unwilling to perform" エラーが返ります。

デフォルトの設定は次のとおりです。

        olcReadonly: FALSE

5.2.6.4. olcReplica

        olcReplica: 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>" 文字列は二重引用符で囲っておくとよいでしょう。

to the slave slapd. bindmethod は、スレーブ slapd への接続に使う認証がパスワードベースのものか SASL かによって simple か sasl になります。

簡易認証は十分なデータの完全性と機密性の保護(TLS や IPSEC など)が無ければ使うべきではありません。簡易認証は binddn と credentials パラメータの指定を必要とします。

一般には SASL 認証を使うことを勧めます。SASL 認証は saslmech パラメータを使った機構の指定が必要です。指定する機構に依存して、認証アイデンティティや証明書を authcid と credentials を使って指定できます。認可アイデンティティの指定には authzid パラメータを使うかもしれません。

このディレクティブの使い方についてのさらなる情報は slurpd を利用した複製の章を参照してください。

5.2.6.5. olcReplogfile: <filename>

このディレクティブは、slapd が 変更を記録する複製ログファイルの名前を指定します。複製ログは通常 slapd が書き出し、slurpd が読み取ります。通常このディレクティブは、データベースを複製するために slurpd が使われている場合にのみ利用します。しかし slurpd を実行していなくても、トランザクションログの生成に使えます。この場合、複製ログファイルは無限に増え続けるので定期的に切り詰める必要があります。

このディレクティブの使い方についてのさらなる情報は slurpd を利用した複製の章を参照してください。

5.2.6.6. olcRootDN: <DN>

このディレクティブは、このデータベースに対するアクセス権制御あるいは管理限度の制限に従わない DN を指定します。この DN は、このデータベースのエントリである必要はありませんし、ディレクトリ中に存在していなくてもかまいません。この DN には SASL アイデンティティを使えます。

エントリベースの例：

        olcRootDN: "cn=Manager,dc=example,dc=com"

SASL ベースの例：

        olcRootDN: "uid=root,cn=example.com,cn=digest-md5,cn=auth"

SASL 認証アイデンティティについてはSASL 認証の節を参照してください。

5.2.6.7. olcRootPW: <password>

このディレクティブは rootdn の DN のためのパスワードを指定するのに使えます(rootdn がこのデータベースの DN として設定されている場合に限ります)。

たとえば次のように指定します。

        olcRootPW: secret

これには、RFC 2307 形式にハッシュ化したパスワードも指定できます。パスワードをハッシュ化するのには slappasswd(8) が使えます。

たとえば次のように指定します。

        olcRootPW: {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN

このハッシュ化したパスワードはコマンド slappasswd -s secret を使って生成しました。

5.2.6.8. olcSizeLimit: <integer>

このディレクティブは、検索操作から返すエントリの最大数を指定します。

デフォルトの設定は次のとおりです。

        olcSizeLimit: 500

5.2.6.9. olcSuffix: <dn suffix>

このディレクティブは、このバックエンドデータベースに渡す問合せの DN 接尾辞を指定します。複数の suffix 行を与えてもよいですが、各データベース定義に少なくとも１つは必要です。 (frontend や monitor など、バックエンドの種別によっては既定の接尾辞を利用していて、このディレクティブで設定を変更できないことがあります。)

たとえば次のように指定します。

        olcSuffix: "dc=example,dc=com"

この指定では、DN の末尾に "dc=example,dc=com" の付いた問合せがこのバックエンドに渡されます。

注記：問合せを渡すバックエンドが選択されるとき、slapd は各データベースの suffix 行を設定ファイルに現れる順番に見ていきます。したがって、あるデータベースの接尾辞が別のデータベースの接頭辞になっている場合には、設定の中のより後のほうに現れるようにしなければなりません。

5.2.6.10. olcSyncrepl

        olcSyncrepl: 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、SASL認証を利用するならsaslを指定します。

簡易認証は、十分なデータの完全性と機密性の保護(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 複製の章を参照してください。

5.2.6.11. olcTimeLimit: <integer>

このディレクティブは、slapd が検索要求の応答に使う最大秒数(実時間)を指定します。この時間内に要求が達せられなければ、時間制限を超過したことを示す結果を返します。

デフォルトの設定は次のとおりです。

        olcTimeLimit: 3600

5.2.6.12. olcUpdateDN: <DN>

このディレクティブはスレーブの slapd にのみ適用できます。このディレクティブは複製の変更を許す DN を指定します。これには、複製の変更をするときに slurpd(8) がバインドする DN、あるいは SASL アイデンティティと関連した DN を指定します。

エントリベースの例：

        olcUpdateDN: "cn=Update Daemon,dc=example,dc=com"

SASL ベースの例：

        olcUpdateDN: "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"

このディレクティブの使い方についてのさらなる情報は slurpd を利用した複製の章を参照してください。

5.2.6.13. olcUpdateref: <URL>

このディレクティブはスレーブの slapd にのみ適用できます。これは複製の更新要求を送るクライアントに戻す URL を指定します。このディレクティブはいくつも指定でき、各 URL が戻されます。

たとえば次のように指定します。

        olcUpdateref:   ldap://master.example.net

5.2.6.14. エントリの例

dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
olcReadOnly: FALSE

dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootDN: cn=Manager,dc=example,dc=com

5.2.7. BDB と HDB のデータベースディレクティブ

このカテゴリのディレクティブは BDB と HDB の両方に適用します。このエントリでは先に説明した一般的なデータベースディレクティブと olcDatabase に指定した種別に固有のディレクティブを利用します。 BDB/HDB 設定ディレクティブの完全なリファレンスについては slapd-bdb(5) を参照してください。 BDB と HDB の database エントリは olcDatabaseConfig に加えてそれぞれ olcBdbConfig または olcHdbConfig オブジェクトクラスを持たなければなりません。

5.2.7.1. olcDbDirectory: <directory>

このディレクティブは、データベースと関連するインデックスを含んだ BDB ファイル郡を置くディレクトリを指定します。

デフォルトの設定は次のとおりです。

        olcDbDirectory: /usr/local/var/openldap-data

5.2.7.2. olcDbCachesize: <integer>

このディレクティブは、BDB バックエンドデータベースの実体によって管理されるメモリ内キャッシュのエントリ数を指定します。

デフォルトの設定は次のとおりです。

        olcDbCachesize: 1000

5.2.7.3. olcDbCheckpoint: <kbyte> <min>

このディレクティブは BDB トランザクションログををチェックポイントする頻度を指定します。チェックポイントは、データベースバッファをディスクにフラッシュし、チェックポイントレコードをログに書き出します。直前のチェックポイントから <kbyte> のデータが書き込まれるか <min> 分が経過するとチェックポイントが起きます。２つの引数ともデフォルトは０で、この場合にはチェックポインントが起きません。引数 <min> がゼロでなければ、チェックポイントを行う内部タスクが <min> 分毎に起動します。より詳しくは Berkeley DB reference guide を参照してください。

たとえば次のように指定します。

        olcDbCheckpoint: 1024 10

5.2.7.4. olcDbConfig: <DB_CONFIG setting>

この属性は、データベースディレクトリのファイル DB_CONFIG の設定ディレクティブを指定します。サーバの起動時に DB_CONFIG ファイルが無ければ作成し、この属性での設定を書き込みます。ファイルが有れば、その内容が読み込まれ、この属性の値となります。複数の設定ディレクティブに対応するために、この属性では複数値の設定が可能になっています。デフォルトでは値を持ちませんが、サーバ性能をベストとするためには、ここで適切な設定をしておくことが重要です。

たとえば次のように指定します。

        olcDbConfig: set_cachesize 0 10485760 0
        olcDbConfig: set_lg_bsize 2097512
        olcDbConfig: set_lg_dir /var/tmp/bdb-log
        olcDbConfig: set_flags DB_LOG_AUTOREMOVE

この例では、BDB キャッシュに 10MB、BDB トランザクションログのバッファサイズとして 2MB を割り当て、トランザクションログは /var/tmp/bdb-log ディレクトリに置くように設定しています。また、チェックポイントにより必要のなくなったトランザクションはすぐに削除するフラグも設定しています。このフラグの設定が無ければ、他の何らかの整除処理がファイルを除去するまで、トランザクションログが残ります。

理想的には、BDB キャッシュは最低でもデータベースのワーキングセットと同等のサイズにし、ログバッファサイズはほとんどのトランザクションでオーバフローすることのないよう十分に大きくし、ログディレクトリはメインのデータベースファイルとは別の物理ディスクに置くようにします。データベースディレクトリもログディレクトリも、root, boot, swap ファイルシステムといった通常のシステム用に使っているのとは別のディスクにしておくべきです。詳細は FAQ-o-Matic と SleepyCat の文書を参照してください。

5.2.7.5. olcDbNosync: { TRUE | FALSE }

このディレクティブは、変更に対するメモリ内の変更をディスク上の内容とすぐには同期をとらないようにします。データの完全性を犠牲にしてでも性能を上げたい場合にはこのディレクティブに TRUE を指定します。このディレクティブは次の設定と同じ効果を持ちます。

        olcDbConfig: set_flags DB_TXN_NOSYNC

5.2.7.6. olcDbIDLcacheSize: <integer>

メモリ内索引キャッシュのサイズを索引数単位で指定します。デフォルトは 0 です。この値を大きくすると、索引のついたエントリの頻繁な検索が高速化します。最適なサイズはデータベースのデータや検索特性に依存しますが、エントリキャッシュのサイズの３倍を目安にするとよいでしょう。

たとえば次のように指定します。

        olcDbIDLcacheSize: 3000

5.2.7.7. olcDbIndex: {<attrlist> | default} [pres,eq,approx,sub,none]

このディレクティブは、与えた属性について管理するインデックスを指定します。 <attrlist> だけが与えられた場合、デフォルトのインデックスが管理されます。

たとえば次のように指定します。

        olcDbIndex: default pres,eq
        olcDbIndex: uid
        olcDbIndex: cn,sn pres,eq,sub
        olcDbIndex: objectClass eq

１行目は、インデックスのデフォルトセットを存在(presence)と等価性(equality)を管理するように設定します。２行目は uid 属性型についてデフォルトのインデックス(pres, eq)を管理すように設定します。３行目は、cn と sn 属性型について存在、等価性、部分文字列(substring)のインデックスを管理するように設定します。４行目は objectClass 属性型について等価性のインデックスを管理するように設定します。

デフォルトではインデックスを管理しませんが、最低でも objectClass について等価性のインデックスを管理するよう勧めます。

        olcDbindex: objectClass eq

slapd が動作中にインデックスを変更した場合には、内部タスクが変更したインデックスのデータを生成します。このタスクが動いている間も、すべてのサーバ操作が通常どおり動いています。インデックスを更新するタスクが完了する前に slapd を停止した場合には、 slapindex ツールを使って手作業でインデックスの更新を完了させなければなりません。

5.2.7.8. olcDbLinearIndex: { TRUE | FALSE }

これを TRUE に設定すると、slapindex は１度に１つの属性のインデックスを処理します。デフォルトの設定は FALSE で、この場合には１エントリ中のインデックスのついた属性をすべて同時に処理します。TRUE に設定している場合には、データベース全体にわたる複数パスを用いてインデックスのついた属性はそれぞれ別個に処理されます。このオプションは、データベースサイズが BDB キャッシュサイズを超えている場合に slapindex の性能を改善します。BDB キャッシュサイズが十分に大きければ、このオプションを設定する必要はありませんし、設定すると性能の低下をまねきます。また通常は slapadd を行えば必要なインデックスは生成されるので、別途 slapindex を起動する必要はありません。このオプションを利用した場合、slapadd はインデックスを生成しないので、別途 slapindex を起動しなければなりません。

5.2.7.9. olcDbMode: <integer>

このディレクティブは、新たに作成されるデータベースインデックスファイルの持つファイル保護モードを指定します。

デフォルトの設定は次のとおりです。

        olcDbMode: 0600

5.2.7.10. olcDbSearchStack: <integer>

検索フィルタの評価で使うスタックの深さを指定します。検索フィルタは入れ子の AND / OR 節に対応するためにスタック上で評価されます。スタックは各サーバスレッドごとに割り当てられます。スタックの深さは、追加のメモリ確保を要求せずにどれだけ複雑なフィルタを評価できるかを決めます。フィルタの入れ子の深さが検索スタックの深さより大きい場合には、その検索操作のための特別のスタックを確保します。このような領域確保はサーバの性能に悪い影響を与えますが、大き過ぎるスタックを指定することも巨大なメモリの消費につながります。個々の検索は、32ビットマシンであれば各棚で 512K バイトを使い、 64ビットマシンであれば各棚で 1024K バイトを使います。デフォルトのスタックの深さは 16 であるので、１スレッドあたり 32ビットマシンであれば各棚で 8MB、64ビットマシンであれば 16MB を使います。またスタックの棚のサイズはコンパイル時の定数で設定しているので、変更するのであれば再コンパイルする必要があります。

デフォルトの設定は次のとおりです。

        olcDbSearchStack: 16

5.2.7.11. olcDbShmKey: <integer>

共有メモリ BDB 環境のキーを指定します。デフォルトで BDB 環境はメモリマップドファイルを利用します。このオプションの指定が 0 でなければ、その値を環境を保持する共有メモリ領域を識別するキーとして利用します。

たとえば次のように指定します。

        olcDbShmKey: 42

5.2.7.12. エントリの例

dn: olcDatabase=hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: hdb
olcSuffix: "dc=example,dc=com"
olcDbDirectory: /usr/local/var/openldap-data
olcDbCacheSize: 1000
olcDbCheckpoint: 1024 10
olcDbConfig: set_cachesize 0 10485760 0
olcDbConfig: set_lg_bsize 2097152
olcDbConfig: set_lg_dir /var/tmp/bdb-log
olcDbConfig: set_flags DB_LOG_AUTOREMOVE
olcDbIDLcacheSize: 3000
olcDbIndex: objectClass eq

5.3. アクセス制御

slapd のエントリおよび属性へのアクセス権は、olcAccess 属性によって制御されます。olcAccess 属性の一般的な形式を次に示します。

        olcAccess: <access directive>
        <access directive> ::= 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 ページを参照してください。

5.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

この場合

エントリはフィルタを使って選択することもできます。

        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=.*" と指定することと等価です。

5.3.2. アクセス権を与える対象の指定

<who> 部は、アクセス権が与えられる実体(entity)を示します。アクセス権は「実体」に与えられるのであって「エントリ」に与えられるのではありません。次の表に実体指定子について要約します。

表5.3: アクセス権の実体指定子
指定子 実体
* 匿名ユーザも認証されたユーザも含めたすべて
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 要素は回避すべきです。

5.3.3. 与えるアクセス権

与える <access> の種類には次のものがあります。

表5.4: アクセス権レベル
レベル 権限 説明
none =0 アクセス不可
auth =x バインドに必要
compare =cx 比較に必要
search =scx 検索フィルタの適用に必要
read =rscx 検索結果の読取りに必要
write =wrscx 更新/名前変更に必要

各レベルは、より下位レベルのアクセス権のすべてを暗に適用します。たとえば、あるエントリついて誰かに write アクセス権を与えた場合、 read, search, compare, auth アクセス権も与えたことになります。しかし、特定の許可を与えるには権限指定を使えます。

5.3.4. アクセス制御の評価

要求者にエントリや属性に対するアクセス権を与えるかを評価するとき、 slapd はエントリや属性を設定ファイルに与えられている <what> と比較します。各エントリについて、そのエントリを保持するデータベースに与えられているアクセス制御がはじめに適用され、その後にグローバルな access ディレクティブが適用されます。この優先順位で、設定ファイルに現れる順番に access ディレクティブを調べます。slapd は、エントリや属性に一致する最初の <what> セレクタを見つけたところで調査を止めます。該当する access ディレクティブは、slapd がアクセス権を評価するために使うものです。

次に slapd は、上で選択された olcAccess ディレクティブの <who> セレクタを出現順に、アクセスを要求する実体と比較します。これは要求者に一致する最初の <who> セレクタを見つけたところで終ります。これは、アクセスを要求する実体がエントリや属性に対して持つアクセス権を決定します。

最後に slapd は、選択された <access> 節に与えられているアクセス権をクライアントによって要求されたアクセスと比較します。アクセス権が実際のアクセス以上のものであれば、アクセスが認められます。さもなければアクセスは認められません。

この olcAccess ディレクティブの評価順序により、設定ファイル中での access ディレクティブの位置が重要となります。ある access ディレクティブが別の access ディレクティブよりも限定的であった場合には、設定ファイルの中でより前に現れるようにしなければなりません。同様に、ある <who> セレクタが別の <who> セレクタよりも限定的であった場合には、access ディレクティブの中でより前に現れるようにしなければなりません。後では、この理解の助けになるアクセス制御の例を示します。

5.3.5. アクセス制御の例

前述したアクセス制御機能は実に強力です。この節ではアクセス制御の使い方がより分かりやすくなるよう、いくつかの利用例を示します。

まずは、簡単な例から。

        olcAccess: to * by * read

この access ディレクティブは、あらゆる人に読取り(read)アクセス権を与えます。

        olcAccess: to *
                by self write
                by anonymous auth
                by * read

このディレクティブの利用例は、認証ユーザが自分のエントリを更新できるようにし、匿名ユーザが認証を行えるようにし、その他すべてのユーザが読み取れる(read)ようにします。一致する最初の by <who> 節だけが適用することに注意してください。したがって、匿名(anonymous)ユーザには認証権(auth)が与えられ、読取り権(read)は与えられません。最後の節は "by users read" としたほうがよいでしょう。

適切な保護レベルを基にして操作を制限したいことがよくあります。この目的のために利用できるセキュリティ強度係数(Security Strength Factors: SSF)を利用した例を次に示します。

        olcAccess: to *
                by ssf=128 self write
                by ssf=64 anonymous auth
                by ssf=64 users read

このディレクティブの記述例では、認証ユーザが自分のエントリを更新できるのはセキュリティ保護で 128 以上の強度が確立されている場合であり、匿名ユーザの認証アクセスと認証ユーザの読取りアクセスが許されるのはセキュリティ保護で 64 以上の強度が確立されている場合です。クライアントが十分なセキュリテイ保護を確立していない場合、暗黙の by * none 節が適用されます。

次の例は、DN でエントリを選択するのにスタイル指定を利用しているところを示しています。この二つのアクセス権宣言の順番は重要です。

        olcAccess: to dn.children="dc=example,dc=com"
                by * search
        olcAccess: 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> セレクタの利用法についても示しています。

        olcAccess: 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
        olcAccess: 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 に限ってできるようにしたい場合、次のようなアクセス権宣言で実現できます。

        olcAccess: to attr=member,entry
                by dnattr=member selfwrite

セレクタ dnattr <who> は、アクセス権が member 属性にリストされているエントリに適用されることを指定します。アクセス権セレクタselfwrite は、そのような member 達が自分自身の DN だけを属性から追加/削除できることを指定します。また、entry 属性を追加しておくことが必要です。なぜなら、エントリのどの属性にアクセスするにせよ、エントリへのアクセス権が必要になるからです。

5.3.6. アクセス制御の順序

olcAccess ディレクティブの順序は適切な評価のために重要ですが、 LDAP の属性は一般に値の順序を維持しないので、OpenLDAP では値の固定順序を管理するために特殊なスキーマ拡張を使います。この順序は、それぞれの値の前に順序を示す添字 "{X}" を付けることにより管理します。これは設定エントリの順序づけで使っているアプローチと同じものです。この添字はタグは slapd が自動的に管理するので、値を設定するときに添字を指定する必要はありません。たとえば次の設定を行ったとします。

        olcAccess: to attr=member,entry
                by dnattr=member selfwrite
        olcAccess: to dn.children="dc=example,dc=com"
                by * search
        olcAccess: to dn.children="dc=com"
                by * read

slapcat や ldapsearch で設定を読み出すと次のようになります。

        olcAccess: {0}to attr=member,entry
                by dnattr=member selfwrite
        olcAccess: {1}to dn.children="dc=example,dc=com"
                by * search
        olcAccess: {2}to dn.children="dc=com"
                by * read

添字は、ldapmodify を使ってアクセス規則を編集するときに、変更する値を指定するのに利用できます。この場合に、添字は実際にアクセスする値の代わりに使うこともできますし、値に加えても指定できます。この添字の扱いは、複数のアクセス規則を管理しているときにたいへん便利です。

たとえば、上記のアクセス規則で２番目のもののアクセス件を search から write に変更するとします。普通に更新しようとすれば、次のような LDIF になります。

        changetype: modify
        delete: olcAccess
        olcAccess: to dn.children="dc=example,dc=com" by * search
        -
        add: olcAccess
        olcAccess: to dn.children="dc=example,dc=com" by * write
        -

しかし、この例では既存の値が元の順序のままに残るという保証がない ので、セキュリティの設定を崩してしまうことになりかねません。代わりに添字を使えば次のように書けます。

        changetype: modify
        delete: olcAccess
        olcAccess: {1}
        -
        add: olcAccess
        olcAccess: {1}to dn.children="dc=example,dc=com" by * write
        -

この例は、olcAccess 属性の値 #1 の規則を削除し、新しい値を元の #1 の値のところに挿入します。結果は次のようになり、意図したとおりになります。

        olcAccess: {0}to attr=member,entry
                by dnattr=member selfwrite
        olcAccess: {1}to dn.children="dc=example,dc=com"
                by * write
        olcAccess: {2}to dn.children="dc=com"
                by * read

5.4. 設定の例

以下は設定の例です。例の所々には説明をつけてあります。これは二つのデータベースを定義していて、それぞれ X.500 ツリーの別々の部分を処理します。両方ともデータベースには BDB を使っています。説明の都合上、例には行番号をつけていますが、実際のファイルには行番号をつけません。まずはグローバル設定セクションから説明します。

  1.    # example config file - global configuration entry
  2.    dn: cn=config
  3.    objectClass: olcGlobal
  4.    cn: config
  5.    olcReferral: ldap://root.openldap.org
  6.

行 1 はコメントです。行 2-4 は、これがグローバル設定エントリであることを示しています。行 5 の olcReferral ディレクティブは、後に定義するデータベースのどれかにローカルでない問合せについて、ホスト root.openldap.org で動作している標準ポート(389)の LDAP サーバを参照することを意味します。行 6 はブランク行で、このエントリの終わりを示します。

  7.    # internal schema
  8.    dn: cn=schema,cn=config
  9.    objectClass: olcSchemaConfig
 10.    cn: schema
 11.

行 7 はコメントです。行 8-10 は、これがスキーマサブツリーのルートであることを示しています。このエントリ中の実際のスキーマの定義は slapd に組込み済であるので、ここで追加で指定する属性はありません。行 11 はブランク行で、このエントリの終わりを示します。

 12.    # include the core schema
 13.    include: file:///usr/local/etc/openldap/schema/core.ldif
 14.

行 12 はコメントです。行 13 は LDIF をインクルードするディレクティブで、 LDIF 形式の core スキーマ定義を取り込みます。行 14 はブランク行です。

次にくるのがデータベース定義です。最初のデータベースは特殊な frontend データベースであり、ここの設定は他のデータベース全体に適用されます。

 15.    # global database parameters
 16.    dn: olcDatabase=frontend,cn=config
 17.    objectClass: olcDatabaseConfig
 18.    olcDatabase: frontend
 19.    olcAccess: to * by * read
 20.

行 15 はコメントです。行 16-18 は、これがグローバルデータベースのエントリであることを示します。行 19 はグローバルアクセス制御です。この設定は(データベース固有のアクセス制御の後に)すべてのエントリに適用します

次のエントリは、ツリーの "dc=example,dc=com" 配下にあるものについての問合せを処理する BDB バックエンドを定義します。いくつかの属性についてインデックスが管理され、userPassword 属性は認可されていないアクセスから保護されます。

 21.    # BDB definition for example.com
 22.    dn: olcDatabase=bdb,cn=config
 23.    objectClass: olcDatabaseConfig
 24.    objectClass: olcBdbConfig
 25.    olcDatabase: bdb
 26.    olcSuffix: "dc=example,dc=com"
 27.    olcDbDirectory: /usr/local/var/openldap-data
 28.    olcRootDN: "cn=Manager,dc=example,dc=com"
 29.    olcRootPW: secret
 30.    olcDbIndex: uid pres,eq
 31.    olcDbIndex: cn,sn,uid pres,eq,approx,sub
 32.    olcDbIndex: objectClass eq
 33.    olcAccess: to attr=userPassword
 34.      by self write
 35.      by anonymous auth
 36.      by dn.base="cn=Admin,dc=example,dc=com" write
 37.      by * none
 38.    olcAccess: to *
 39.      by self write
 40.      by dn.base="cn=Admin,dc=example,dc=com" write
 41.      by * read
 42.

行 21 はコメントです。行 22-25 は、このエントリが BDB データベース定義であることを示しています。行 26 は、このデータベースに渡す問合せのための DN 接尾辞を指定します。行 27 は、データベースファイルを置くディレクトリを指定します。

行 28 と 29 は、このデータベースのスーパユーザエントリとそのパスワードを指定します。このエントリはアクセス制御あるいはサイズ/時間制限に従いません。

行 30 から 32 は、さまざまな属性のために管理するインデックスを指定します。

行 33 から 41 は、データベース内のエントリのためのアクセス制御を指定します。これは最初のデータベースに指定されていますが、制御はどのデータベースにも保持されないエントリ(ルート DSE など)にも適用します。すべての適切なエントリの userPassword 属性は、そのエントリ自身および "admin" エントリから更新可能です。この属性は認証/認可の目的には使えますが読み取れません。その他すべての属性は、そのエントリ自身および "admin" エントリから更新可能で、認証されたユーザから読み取れます。

行 42 はブランク行で、このエントリの終わりを示します。

設定ファイルの例の次の部分は、別の BDB データベースを定義します。この BDB データベースは dc=example,dc=net サブツリーに関する問合せを処理します。行 51 がないと、行 19 のグローバルアクセス規則により読み取りアクセスが許可されることに注意してください。

 42.    # BDB definition for example.net
 43.    dn: olcDatabase=bdb,cn=config
 44.    objectClass: olcDatabaseConfig
 45.    objectClass: olcBdbConfig
 46.    olcDatabase: bdb
 47.    olcSuffix: "dc=example,dc=net"
 48.    olcDbDirectory: /usr/local/var/openldap-data-net
 49.    olcRootDN: "cn=Manager,dc=example,dc=com"
 50.    olcDbIndex: objectClass eq
 51.    olcAccess: to * by users read

目次 | 上位のトピック | 前のトピック | 次のトピック
ホーム | カタログ

________________
© Copyright 2005, OpenLDAP Foundation, info@OpenLDAP.org