Language:
Format:

管理ガイド

Red Hat Directory Server 11

Directory Server の基本および高度な管理

概要

本ガイドでは、Directory Server インスタンスおよびデータベースを管理する GUI およびコマンドラインの手順を説明します。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、「Red Hat CTO である Chris Wright のメッセージ」をご覧ください。

第1章一般的な Directory Server 管理タスク

本章では、Directory Server インスタンスを管理する一般的なタスクを説明します。

1.1. システム要件

『Red Hat Directory Server 11 リリースノート』の該当するセクションを参照してください。

1.2. ファイルの場所

『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』の該当するセクションを参照してください。

1.3. Directory Server を設定するサポート対象のメソッド

以下を使用して Directory Server を設定できます。

Directory Server が提供するコマンドラインユーティリティー
Web コンソール

重要

コンソールのウィンドウの外でユーザーが設定を変更すると、Web コンソールでは最新の設定が自動的に表示されません。たとえば、Web コンソールが開いている間にコマンドラインを使用して設定を変更すると、Web コンソールで新しい設定が自動的に更新されません。これは、別のコンピューターの Web コンソールを使用して設定を変更する場合でも当てはまります。この問題を回避するには、コンソールウィンドウ外で設定が変更した場合に、ブラウザーで Web コンソールを手動で更新します。

1.4. Web コンソールを使用した Directory Server へのログイン

Web コンソールは、ユーザーが管理タスクを実行できるブラウザーベースのグラフィカルユーザーインターフェイス (GUI) です。Directory Server パッケージは、Web コンソールの Directory Server ユーザーインターフェイスを自動的にインストールします。

Web コンソールで Directory Server を開くには、以下を実行します。

ブラウザーを使用して、Directory Server ホストのポート 9090 で実行している Web コンソールに接続します。以下に例を示します。
```
https://server.example.com:9090
```
root ユーザーまたは sudo 権限を持つユーザーとしてログインします。
Red Hat Directory Server エントリーを選択します。

1.5. Directory Server インスタンスの起動および停止

1.5.1. コマンドラインを使用した Directory Server インスタンスの起動および停止

dsctl ユーティリティーを使用して、インスタンスを開始、停止、または再起動します。

インスタンスを起動するには、以下を実行します。
```
# dsctl instance_name start
```
インスタンスを停止するには、以下を実行します。
```
# dsctl instance_name stop
```
インスタンスを再起動するには、以下を実行します。
```
# dsctl instance_name restart
```

必要に応じて、システムの起動時に Directory Server インスタンスが自動的に起動するようにすることができます。

単一のインスタンスの場合:
```
# systemctl enable dirsrv@instance_name
```
サーバー上のすべてのインスタンスの場合:
```
# systemctl enable dirsrv.target
```

詳細は、『Red Hat システム管理者』ガイドのシステムサービスの管理セクションを参照してください。

1.5.2. Web コンソールを使用した Directory Server インスタンスの起動および停止

コマンドラインを除き、Web コンソールを使用してインスタンスの起動、停止、再起動を行うことができます。

Directory Server インスタンスを起動、停止、または再起動するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Actions ボタンをクリックして、実行するアクションを選択します。
- Start Instance
- Stop Instance
- Restart Instance

1.6. 新規 Directory Server インスタンスの作成

詳細は、『Red Hat Directory Server インストールガイド』の該当するセクションを参照してください。

1.7. Directory Server インスタンスの削除

サーバーで複数のインスタンスを実行する場合は、そのインスタンスを個別に削除できます。

インスタンスを削除すると、/var/lib/dirsrv/slapd-instance_name/ および /etc/dirsrv/slapd-instance_name/ ディレクトリーの内容が削除されます。

重要

/var/lib/dirsrv/slapd-instance_name/ ディレクトリーには、データベース、バックアップおよびエクスポートディレクトリーが含まれています。/etc/dirsrv/slapd-instance_name/ ディレクトリーには、インスタンス設定とネットワークセキュリティーサービス (NSS) データベースが含まれています。インスタンスを削除する前に、このデータのバックアップを作成します。

1.7.1. コマンドラインを使用したインスタンスの削除

コマンドラインを使用してインスタンスを削除するには、以下を実行します。

# dsctl instance_name remove --do-it
Removing instance ...
Completed instance removal

1.7.2. Web コンソールを使用したインスタンスの削除

Web コンソールを使用してインスタンスを削除するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Actions ボタンをクリックし、Remove instance を選択します。

1.8. Directory Server の設定パラメーターの設定

Directory Server は、その設定を cn=config ディレクトリーエントリーに保存します。各設定パラメーターは LDAP 属性で、パラメーターの値はこの属性に設定した値になります。

1.8.1. 設定パラメーターの管理

以下を使用すると、設定パラメーターを設定、更新、および削除することができます。

dsconf ユーティリティーの使用:
注記
Red Hat は、dsconf ユーティリティーを使用して、Directory Server 設定を管理することを推奨しています。
例1.1 dsconf を使用した設定パラメーターの設定
たとえば、エラーログレベルを 16384 に設定するには、dsconf ユーティリティーを使用して、nsslapd-errorlog-level パラメーターを更新します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-errorlog-level=16384
```
dsconf の使用の詳細については、dsconf(8) man ページを参照してください。
LDAP インターフェイスの使用:
例1.2 LDAP インターフェイスを使用した設定パラメーターの設定
たとえば、エラーログレベルを 16384 に設定するには、LDAP インターフェイスを使用して、nsslapd-errorlog-level パラメーターを更新します。
```
# ldapmodify -D "cn=Directory Manager" -W -x -H ldap://server.example.com:389

dn: cn=config
replace: nsslapd-errorlog-level
nsslapd-errorlog-level: 16384
```
/etc/dirsrv/slapd-instance_name/dse.ldif ファイルを編集します。
警告
インスタンスが正常に起動している限り、このファイルは手動で編集しないでください。これは、Directory Server が想定どおりに機能しないか、インスタンスの起動に失敗する可能性があるためです。

1.8.2. Directory Server が設定を保存する場所

Directory Server は、cn=config エントリーからの設定を /etc/dirsrv/slapd-instance_name/dse.ldif ファイルに保存します。サーバーは、このファイルで変更したパラメーターのみを保存します。リストにない属性には、デフォルト値を使用します。これにより、/etc/dirsrv/slapd-instance_name/dse.ldif ファイルを表示して、このインスタンスに設定したすべての設定パラメーターを識別できます。

重要

インスタンスが正常に起動するかぎり、/etc/dirsrv/slapd-instance_name/dse.ldif ファイルを手動で編集しないでください。

設定パラメーターの編集方法は、「設定パラメーターの管理」を参照してください。

1.8.3. デフォルト値を使用する利点

パラメーターが設定されていない場合、Directory Server はこのパラメーターのデフォルト値を使用します。デフォルト値を使用すると、新しいバージョンで最適化された設定が提供され、セキュリティーが強化されます。

たとえば、passwordStorageScheme 属性を指定すると、Directory Server は、サポートされている利用可能な最も強力なパスワード保存スキームを自動的に使用します。今後の更新で、セキュリティーを向上させるデフォルト値を変更すると、パスワードを設定する際に、新しいストレージスキームを使用してパスワードが自動的に暗号化されます。

1.8.3.1. デフォルト値を使用するパラメーターの削除

パラメーターが設定され、代わりにデフォルト値を使用する場合は、パラメーターを削除します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com config delete parameter_name

重要

nsslapd-secureport など、特定のパラメーターは、削除して、デフォルトにリセットすることはできません。それらを削除しようとすると、サーバーは Server is unwilling to perform (53) エラーでリクエストを拒否します。

1.8.4. `dsconf config backend` コマンドの制限事項

dsconf config backend コマンドは、バックエンド設定を取得および設定します。このコマンドには次の引数があります。

dsconf config backend get コマンドは、設定された値を持つすべてのサーバーバックエンド設定属性を取得します。次に例を示します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com:389 backend config get

nsslapd-lookthroughlimit: 5000
nsslapd-mode: 600
nsslapd-idlistscanlimit: 2147483646
…

注記

dsconf config backend get コマンドを使用すると、指定された属性の値ではなく、属性値の完全なセットのみを取得できます。

dsconf config backend set コマンドは、バックエンド設定属性を個別に設定します。値を設定するには、LDAP 属性名に一致するオプションを指定します。たとえば、次のように指定します。

# dsconf -D "cn=Directory Manager"  ldap://server.example.com:389 backend config set --lookthroughlimit 4000  --cache-autosize-split 24

以下に、dsconf backend config set コマンドのオプションと LDAP 属性名のマッピングを示します。

表1.1 dsconf backend config set コマンドのオプションと LDAP 属性名のマッピング

`dsconf backend config set` コマンドのオプション	LDAP 属性名
--lookthroughlimit	nsslapd-lookthroughlimit
--mode	nsslapd-mode
--idlistscanlimit	nsslapd-idlistscanlimit
--directory	nsslapd-directory
--dbcachesize	nsslapd-dbcachesize
--logdirectory	nsslapd-db-logdirectory
--txn-wait	nsslapd-db-transaction-wait
--checkpoint-interval	nsslapd-db-checkpoint-interval
--compactdb-interval	nsslapd-db-compactdb-interval
--compactdb-time	nsslapd-db-compactdb-time
--txn-batch-val	nsslapd-db-transaction-batch-val
--txn-batch-min	nsslapd-db-transaction-batch-min-wait
--txn-batch-max	nsslapd-db-transaction-batch-max-wait
--logbufsize	nsslapd-db-logbuf-size
--locks	nsslapd-db-locks
--locks-monitoring-enabled	nsslapd-db-locks-monitoring-enabled
--locks-monitoring-threshold	nsslapd-db-locks-monitoring-threshold
--locks-monitoring-pause	nsslapd-db-locks-monitoring-pause
--import-cache-autosize	nsslapd-import-cache-autosize
--import-cachesize	nsslapd-import-cachesize
--cache-autosize	nsslapd-cache-autosize
--cache-autosize-split	nsslapd-cache-autosize-split
--exclude-from-export	nsslapd-exclude-from-export
--pagedlookthroughlimit	nsslapd-pagedlookthroughlimit
--pagedidlistscanlimit	nsslapd-pagedidlistscanlimit
--rangelookthroughlimit	nsslapd-rangelookthroughlimit
--backend-opt-level	nsslapd-backend-opt-level
--deadlock-policy	nsslapd-db-deadlock-policy
--db-home-directory	nsslapd-db-home-directory
--db-lib	nsslapd-backend-implement

1.9. LDAP および LDAPS ポート番号の変更

デフォルトでは、Directory Server は LDAP にポート 389 を使用し、有効な場合は LDAPS プロトコルにポート 636 を使用します。たとえば、1 台のホストで複数の Directory Server インスタンスを実行するなど、これらのポート番号を変更できます。

重要

インスタンス用のプロトコルに割り当てた新しいポートは、他のサービスで使用することができません。

1.9.1. コマンドラインを使用したポート番号の変更

コマンドラインを使用してポート番号を変更するには、以下のパラメーターを更新します。

nsslapd-port: インスタンスが LDAP プロトコルに使用するポート番号を保存します。
nsslapd-secureport: インスタンスが LDAPS プロトコルに使用するポート番号を保存します。

コマンドラインを使用して LDAP プロトコルおよび LDAPS プロトコルのポート番号を変更するには、次を実行します。

必要に応じて、インスタンスに現在設定されているポート番号を表示します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com config get nsslapd-port nsslapd-secureport
nsslapd-port: 389
nsslapd-secureport: 636

LDAP ポートを変更するには、以下を行います。
1. LDAP プロトコルのポートを設定します。たとえば、1389 に設定するには、以下を実行します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-port=1389
Successfully replaced "nsslapd-port"
```
2. 前の手順で割り当てた LDAP ポートの ldap_port_t タイプを設定します。
```
# semanage port -a -t ldap_port_t -p tcp 1389
```
LDAPS ポートを変更するには、以下を実行します。
1. LDAPS プロトコルのポートを設定します。たとえば、1636 に設定するには、以下を実行します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-secureport=1636
Successfully replaced "nsslapd-secureport"
```
2. 前の手順で割り当てた LDAPS ポートの ldap_port_t タイプを設定します。
```
# semanage port -a -t ldap_port_t -p tcp 1636
```
インスタンスを再起動します。
```
# dsctl instance_name restart
```

1.9.2. Web コンソールを使用したポート番号の変更

Web コンソールを使用して LDAP プロトコルおよび LDAPS プロトコルのポート番号を変更するには、以下を行います。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
LDAP ポートを変更するには、以下を行います。
1. Server Settings メニューを開きます。
2. Server Settings タブで、新しいポート番号を LDAP Port フィールドに入力します。
3. Save をクリックします。
LDAPS ポートを変更するには、以下を実行します。
1. Server Settings メニューを開きます。
2. General Settings タブで、新しいポート番号を LDAPS Port フィールドに入力します。
3. Save をクリックします。
インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。

1.10. Directory Server プラグインの使用

Directory Server は、レプリケーション、サービスのクラス、属性構文の検証など、コアプラグインを複数提供します。コアプラグインはデフォルトで有効になっています。

さらに、Directory Server パッケージには、属性の一意性や属性リンクなど機能を強化するプラグインが含まれます。ただし、これらすべてのプラグインがデフォルトで有効になっている訳ではありません。

詳細は、『Red Hat Directory Server 設定、コマンド、およびファイルリファレンス』の『プラグイン実装サーバー機能リファレンス』の章を参照してください。

1.10.1. 利用可能なプラグインのリスト表示

1.10.1.1. コマンドラインを使用した利用可能なプラグインのリスト表示

コマンドラインを使用して利用可能なプラグインのリストを表示するには、次のコマンドを実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin list
7-bit check
Account Policy Plugin
...

たとえば、コマンドラインでこれを有効または無効にするには、プラグインの正確な名前が必要です。

1.10.1.2. Web コンソールを使用した利用可能なプラグインのリスト表示

Web コンソールを使用して利用可能なプラグインをすべて表示するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを選択します。

オプションで、Filter Plugins フィールドに名前を入力して、プラグインをフィルタリングできます。

1.10.2. プラグインの有効化および無効化

1.10.2.1. コマンドラインでプラグインの有効化および無効化

コマンドラインを使用してプラグインを有効または無効にするには、dsconf ユーティリティーを使用します。

注記

dsconf コマンドでは、プラグインの名前を指定する必要があります。すべてのプラグインの名前を表示する場合は、「コマンドラインを使用した利用可能なプラグインのリスト表示」を参照してください。

たとえば、Automember プラグインを有効にするには、次のようにします。

プラグインを有効にします。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin automember enable

インスタンスを再起動します。
```
# dsctl instance_name restart
```

1.10.2.2. Web コンソールを使用したプラグインの有効化および無効化

Web コンソールを使用してプラグインを有効または無効にするには、以下を行います。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを選択します。
All Plugins タブを選択します。
有効または無効にするプラグインの右側にある Edit Plugin ボタンをクリックします。
ステータスを ON に変更してプラグインを有効にするか、OFF に変更して無効にします。
インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。

1.10.3. プラグインの設定

1.10.3.1. コマンドラインでプラグインの設定

プラグイン設定を行うには、dsconf plugin コマンドを使用します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin \
     plug-in-specific_subcommand ...

設定可能なプラグインのリストを表示するには、以下を実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin --help

1.10.3.2. Web コンソールを使用したプラグインの設定

Web コンソールを使用してプラグインを設定するには、以下を行います。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを選択します。
All Plugins タブを選択します。
プラグインを選択し、Show Advanced Settings をクリックします。
プラグイン固有のタブを開きます。
適切な設定を行います。
インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。

1.10.4. プラグインの優先順位の設定

プラグインの優先順位は、プラグインの実行順序にある優先順位です。操作前および操作後のプラグインでは、次のプラグインの開始前にプラグインを実行して完了し、次のプラグインが、その前に実行したプラグインの結果を活用できるようにします。

優先順位は、1 (最高の優先順位) から 99 (最低の優先順位) までの値に設定できます。優先順位が設定されていない場合、デフォルトは 50 です。

警告

カスタムプラグインでのみ優先順位を設定します。コアプラグインの値を更新すると、Directory Server は期待通りに機能しなくなり、Red Hat では対応していません。

1.10.4.1. コマンドラインを使用したプラグインの優先順位の設定

コマンドラインを使用してプラグインの優先順位を更新するには、次のコマンドを実行します。

プラグインの優先順位を設定します。たとえば、example プラグインの優先順位を 1 に設定するには、次のようにします。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin edit example --precedence 1
```
インスタンスを再起動します。
```
# dsctl instance_name restart
```

1.10.4.2. Web コンソールを使用したプラグインの優先順位の設定

Web コンソールを使用してプラグインの優先順位を更新するには、以下を行います。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを開きます。
All Plugins を選択します。
優先順位の値を設定するプラグインの横にある Edit Plugin ボタンを押します。
Plugin Precedence フィールドの値を更新します。
Save をクリックします。
インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。

1.11. .dsrc ファイルを作成して使用し、Directory Server コマンドラインユーティリティーのデフォルトオプションを設定する

~/.dsrc ファイルは、Directory Server コマンドラインユーティリティーを使用するコマンドを簡素化します。デフォルトでは、これらのユーティリティーでは、LDAP URL やバインド識別名 (DN) などをコマンドに渡す必要があります。これらの設定を ~/dsrc ファイルに保存すると、毎回これらの設定を指定しなくても、コマンドラインユーティリティーを使用できます。

1.11.1. .dsrc ファイルがコマンドを簡素化する方法

以下は、インスタンスの LDAP URL とバインド DN を指定する ~/.dsrc ファイルの例です。

[server1]
uri = ldap://server1.example.com
binddn = cn=Directory Manager
basedn = dc=example,dc=com

これらの設定により、より短い Directory Server コマンドを使用できます。たとえば、ユーザーアカウントを作成するには、次のようにします。

# dsidm server1 user create

~/.dsrc ファイルがない場合は、コマンドでバインド DN、LDAP URL、およびベース DN を指定する必要があります。

# dsidm -D cn=Directory Manager ldap://server1.example.com -b "dc=example,dc=com" user create

1.11.2. dsctl ユーティリティーを使用して .dsrc ファイルを作成する

~/.dsrc ファイルを手動で作成する代わりに、dsctl ユーティリティーを使用して作成できます。

# dsctl instance_name dsrc create ...

次のオプションをコマンドに渡すことができます。

--uri: protocol://host_name_or_IP_address_or_socket の形式で URL をインスタンスに設定します。
例 :
- --uri ldap://server.example.com
- --uri = ldaps://server.example.com
- --uri = ldapi://%%2fvar%%2frun%%2fslapd-instance_name.socket
  Directory Server ソケットへのパスを設定する場合は、パスにスラッシュ (/) ではなく %%02 を使用します。
  重要
  ldapi URL を使用すると、サーバーは、Directory Server コマンドラインユーティリティーを実行するユーザーのユーザー ID (UID) とグループ ID (GID) を識別します。root ユーザーとしてコマンドを実行すると、UID と GID の両方が 0 になり、Directory Server は、対応するパスワードを入力しなくても、cn=Directory Manager としてユーザーを自動的に認証します。
--starttls: LDAP ポートに接続し、STARTTLS コマンドを送信して、暗号化された接続に切り替えるように、ユーティリティーを設定します。
--basedn: 基本識別名 (DN) を設定します。例: --basedn dc=example,dc=com
--binddn: バインド DN を設定します。例: --binddn cn=Directory Manager
--pwdfile: バインド DN のパスワードを含むファイルへのパスを設定します。例: --pwdfile /root/rhds.pwd
--tls-cacertdir: LDAPS 接続を使用する場合、このパラメーターに設定されたパスは、サーバーの証明書を検証するために必要な認証局 (CA) 証明書を含むディレクトリーを定義します。例: --tls-cacertdir /etc/pki/CA/certs/
指定したディレクトリーに CA 証明書をコピーした後、c_rehash /etc/pki/CA/certs/ コマンドを使用する必要があることに注意してください。
--tls-cert: サーバーの証明書への絶対パスを設定します。例: --tls-cert /etc/dirsrv/slapd-instance_name/Server-Cert.crt
--tls-key: サーバーの秘密鍵への絶対パスを設定します。例: --tls-key /etc/dirsrv/slapd-instance_name/Server-Cert.key
--tls-reqcert: クライアントユーティリティーが TLS セッションでサーバー証明書に対して実行するチェックを設定します。例: --tls-reqcert hard
以下のパラメーターを利用することができます。
- never: ユーティリティーはサーバー証明書を要求または確認しません。
- allow: ユーティリティーは証明書エラーを無視し、接続はとにかく確立されます。
- hard: ユーティリティーは証明書エラーで接続を終了します。
--saslmech: 使用する SASL メカニズムを PLAIN または EXTERNAL に設定します。例: --saslmech PLAIN

1.11.3. Directory Server ユーティリティー使用時のリモートおよびローカル接続の解決

Directory Server 接続を保護する場合、Directory Server コマンドのリモート呼び出しとローカル呼び出しを区別することが重要です。

LDAP URL を指定して Directory Server コマンドを実行すると、サーバーは、それをリモート接続と見なし、コマンドを続行するために、システム全体の設定とともに /etc/openldap/ldap.conf 設定ファイルをチェックします。

インスタンス名を指定して Directory Server コマンドを実行すると、サーバーは、~/.dsrc ファイルが存在するかどうかを確認し、次のロジックを適用して続行します。

~/.dsrc ファイルが存在し、インスタンス名と LDAP URL の両方が含まれている場合、Directory Server は、それをリモート接続と見なし、/etc/openldap/ldap.conf 設定ファイルとシステム全体の設定をチェックします。
~/.dsrc ファイルが存在し、指定されたインスタンス名のみが含まれている場合、または ~/.dsrc ファイルが存在しない場合、Directory Server は、それをローカル接続と見なし、ローカルの dse.ldif ファイルの nsslapd-certdir 設定を使用して、接続を保護します。nsslapd-certdir が存在しない場合、サーバーは、デフォルトパス /etc/dirsrv/slapd-instance_name/ を使用して、インスタンスの Network Security Services (NSS) データベースを保存します。

nsslapd-certdir パラメーターの詳細については、nsslapd-certdir (証明書と鍵のデータベースディレクトリー) セクションを参照してください。

第2章ディレクトリーデータベースの設定

ディレクトリーはデータベースに保存され、ディレクトリーツリーはデータベース全体に分散されます。本章では、接尾辞 の作成、ディレクトリーツリーの分岐点、および各接尾辞に関連付けられたデータベースの作成方法を説明します。本章では、リモートサーバーでデータベースを参照するデータベースリンクを作成する方法と、参照を使用してクライアントにディレクトリーデータの外部ソースを指定する方法も説明します。

2.1. 接尾辞の作成および維持

ディレクトリーツリーのさまざまな部分をさまざまなデータベースに保存でき、そのデータベースを複数のサーバーに分散できます。ディレクトリーツリーには、ノード と呼ばれる分岐点が含まれます。このノードはデータベースに関連付けられている可能性があります。接尾辞は、特定のデータベースに関連するディレクトリーツリーのノードです。以下は、簡単なディレクトリーツリーです。

図2.1 1 つのルート接尾辞があるディレクトリーツリー

ou=people 接尾辞とその下のすべてのエントリーとノードが 1 つのデータベースに保存され、ou=groups 接尾辞が別のデータベースに保存され、ou=contractors 接尾辞がさらに別のデータベースに保存される場合があります。

2.1.1. 接尾辞の作成

ルートの接尾辞 は、従属接尾辞の親です。これは、Directory Server 用に設計された大規模なツリーの一部になります。下位スキーム は、ルート接尾辞の配下にあるブランチです。ディレクトリーツリーのコンテンツの編成には、ルート接尾辞と従属接尾辞の両方が使用されます。ルートおよびサブスキームのデータはデータベースに保存されます。

2.1.1.1. ルート接尾辞の作成

ディレクトリーには、複数のルート接尾辞を含めることができます。たとえば、example.com 用と redhat.com 用の複数の Web サイトをホスティングするインターネットサービスプロバイダーなどです。このシナリオでは、2 つのルート接尾辞が必要です。次の図に示すように、1 つは dc=example,dc=com 命名コンテキストに対応し、もう 1 つは dc=redhat,dc=com 命名コンテキストに対応します。

図2.2 2 つのルート接尾辞があるディレクトリー

また、検索操作からディレクトリーツリーの一部を除外するために、ルート接尾辞を作成することもできます。たとえば、Example Corporation が、一般的な Example Corporation ディレクトリーの検索から、ヨーロッパオフィスを除外する場合などです。これを実装するには、ディレクトリーに 2 つのルート接尾辞が必要です。1 つのルート接尾辞は一般的な Example Corporation ディレクトリーツリー dc=example,dc=com に対応し、もう 1 つのルート接尾辞はディレクトリーツリーのヨーロッパブランチ ou=europe,dc=example,dc=com に対応します。クライアントアプリケーションの観点では、ディレクトリーツリーは以下の図のように示されます。

図2.3 検索操作への制限がオフのルート接尾辞があるディレクトリー

ディレクトリーの dc=example,dc=com ブランチでクライアントアプリケーションによって実行される検索では、ディレクトリーの ou=europe,dc=example,dc=com ブランチからのエントリーは返されません。これは、別のルート接尾辞であるためです。

2.1.1.1.1. コマンドラインでルート接尾辞の作成

dsconf backend create コマンドを使用して、新しいルート接尾辞を作成します。

必要に応じて、使用中の接尾辞およびバックエンドデータベースを指定します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
dc=example,dc=com (userroot)
```
括弧内の名前は、対応する接尾辞のデータを保存するバックエンドデータベースです。次の手順でルートの接尾辞を作成する場合は、既存のデータベース名を使用することはできません。

example バックエンドデータベースに dc=example,dc=net ルート接尾辞を作成します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com backend create \
     --suffix="dc=example,dc=net" --be-name="example"

2.1.1.1.2. Web コンソールを使用したルート接尾辞の作成

Web コンソールを使用して新しいルート接尾辞を作成するには、以下を行います。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Database メニューを開きます。
Create Suffix をクリックします。
接尾辞 DN およびバックエンド名を入力します。以下に例を示します。
Create The Top Suffix Entry を選択します。
Create Suffix をクリックします。

2.1.1.2. 従属接尾辞の作成

特定のシナリオでは、管理者はディレクトリーツリーのブランチを別のデータベースに保存するとします。たとえば、管理者が ou=europe,dc=example,dc=com エントリーをサブ接尾辞として作成すると、この接尾辞は別のデータベースに保存されます。同時に、dc=example,com ルート接尾辞とそのすべてのサブエントリー (ou=europe,dc=example,dc=com とサブエントリーを除く) も別のデータベースに保存されます。

図2.4 従属接尾辞が含まれるディレクトリーツリー

2.1.1.2.1. コマンドラインを使用した従属接尾辞の作成

dsconf backend create コマンドを使用して、新しいサブ接尾辞を作成します。たとえば、dc=example,dc=com ルート接尾辞の下にある people という名前の新しいデータベースに ou=People,dc=example,dc=com サブ接尾辞を作成するには、次のようにします。

必要に応じて、使用中の接尾辞およびバックエンドデータベースを指定します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
dc=example,dc=com (userroot)
```
括弧内の名前は、対応する接尾辞のデータを保存するバックエンドデータベースです。次の手順で従属接尾辞を作成する場合は、既存のデータベース名を使用することはできません。
従属接尾辞を作成します。たとえば、example バックエンドデータベースとともに ou=People,dc=example,dc=com サブ接尾辞を作成するには、次のように入力します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend create \
     --suffix="ou=People,dc=example,dc=com" --be-name="example" \
     --parent-suffix="dc=example,dc=com"
```

2.1.1.2.2. Web コンソールを使用した副接尾辞の作成

Web コンソールを使用して新しい従属接尾辞を作成するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Database メニューを開きます。
サブ接尾辞を作成する接尾辞を選択し、Suffix Tasks をクリックして、Create Sub-Suffix を選択します。
従属接尾辞 DN およびバックエンド名を入力します。以下に例を示します。
Create The Top Sub-Suffix Entry を選択します。
Create Sub-Suffix をクリックします。

2.1.2. 接尾辞の維持

2.1.2.1. デフォルトの命名コンテキストの表示

命名コンテキストは接尾辞に類似しており、命名ディレクトリーエントリーのルート構造です。ディレクトリーとデータ構造によっては、複数の命名コンテキストが存在する場合があります。たとえば、標準の Directory Server 設定には、dc=example,dc=com などのユーザー接尾辞や cn=config の設定接尾辞があります。

多くのディレクトリーツリーには複数の命名コンテキストがあり、異なるタイプのエントリーや論理データ分割で使用されます。Directory Server にアクセスするクライアントは、使用する必要がある命名コンテキストを認識しない場合があります。Directory Server には、デフォルトの命名コンテキストが他に認識されていない場合に、デフォルトの命名コンテキストがクライアントに通知するサーバー設定属性があります。

デフォルトの命名コンテキストは、cn=config の nsslapd-defaultnamingcontext 属性に設定されます。この値はルート DSE (Directory Server Agent Service Entry) に伝播され、ルート DSE の defaultnamingcontext 属性を確認してクライアントが匿名でクエリーできます。

# ldapsearch -p 389 -h server.example.com -x -b "" -s base | egrep namingcontext
namingContexts: dc=example,dc=com
namingContexts: dc=example,dc=net
namingContexts: dc=redhat,dc=com
defaultnamingcontext: dc=example,dc=com

重要

設定の整合性を維持するには、nsslapd-allowed-to-delete-attrs 一覧から nsslapd-defaultnamingcontext 属性を削除しないでください。

デフォルトでは、nsslapd-defaultnamingcontext 属性は、nsslapd-allowed-to-delete-attrs 属性に削除 できる 属性の一覧に含まれます。これにより、現在のデフォルトの接尾辞を削除してから、適切にサーバー設定を更新できます。

何らかの理由で削除可能な設定属性の一覧から nsslapd-defaultnamingcontext 属性を削除すると、その属性への変更は保持されません。デフォルトの接尾辞を削除すると、その変更はサーバー設定に伝播できません。つまり、nsslapd-defaultnamingcontext 属性は、空白 (削除) ではなく古い情報を保持することを意味します。これは正しい現在の設定です。

2.1.2.2. 接尾辞の無効化

特定の状況では、ディレクトリーの接尾辞を無効にする必要があります。接尾辞が無効になっていると、その接尾辞に関連するデータベースのコンテンツは、クライアントがアクセスできなくなります。

2.1.2.2.1. コマンドラインでの接尾辞の無効化

コマンドラインで接尾辞を無効にするには、バックエンドデータベース名を dsconf backend suffix set --disable コマンドに渡します。たとえば、o=test 接尾辞を無効にするには、以下を実行します。

接尾辞とそれに対応するバックエンドを表示します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
dc=example,dc=com (userroot)
o=test (test_database)
```
このコマンドにより、各接尾辞の横にバックエンドデータベースが表示されます。次の手順で、接尾辞のデータベース名が必要です。

接尾辞を無効にします。

# dsconf -D "cn=Directory Manager" ldap://server.example.com backend \
     suffix set --disable "test_database"

2.1.2.3. 接尾辞の削除

接尾辞が不要になった場合、管理者はその接尾辞をデータベースから削除できます。

警告

接尾辞を削除すると、その接尾辞に関連するデータベースエントリーおよびレプリケーション情報もすべて削除されます。

2.1.2.3.1. コマンドラインを使用した接尾辞の削除

コマンドラインで接尾辞を削除するには、dsconf backend delete コマンドを使用します。たとえば、o=test 接尾辞を削除するには、以下を実行します。

接尾辞とそれに対応するバックエンドを表示します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
dc=example,dc=com (userroot)
o=test (test_database)
```
このコマンドにより、各接尾辞の横にバックエンドデータベースが表示されます。次の手順で、接尾辞のデータベース名が必要です。

バックエンドデータベースと対応する接尾辞を削除します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com backend delete test_database
Deleting Backend cn=test_database,cn=ldbm database,cn=plugins,cn=config :
Type 'Yes I am sure' to continue: Yes I am sure
The database, and any sub-suffixes, were successfully deleted

2.1.2.3.2. Web コンソールを使用した接尾辞の削除

Web コンソールを使用して接尾辞を削除するには、以下を行います。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Database メニューを開きます。
接尾辞を選択し、Suffix Tasks をクリックして Delete Suffix. を選択します。
Yes をクリックして確定します。

2.2. データベースの作成および維持

ディレクトリーデータを整理するための接尾辞を作成したら、そのディレクトリーのデータを含むデータベースを作成します。

注記

dsconf ユーティリティーまたは Web コンソールを使用して接尾辞を作成すると、Directory Server はデータベースを自動的に作成していました。

2.2.1. データベースの作成

ディレクトリーツリーは、複数の Directory Server データベースに配布できます。複数のデータベースにデータを分散する方法は 2 つあります。

各接尾辞に 1 つのデータベース各接尾辞のデータは個別のデータベースに含まれます。: 個別の接尾辞に含まれるデータを格納するために、3 つのデータベースが追加されます。
このツリーユニットの分割は、たとえば次の 3 つのデータベースに対応しています。
この例では、DB1 には ou=people のデータおよび dc=example,dc=com のデータが含まれ、クライアントが dc=example,dc=com に基づいて検索を実行できるようにします。ただし、DB2 には ou=groups のデータのみが含まれ、DB3 には ou=contractors のデータのみが含まれます。
1 つの接尾辞に複数のデータベースがあります。: ディレクトリーツリーの ou=people ブランチ内のエントリー数が非常に大きくなると、2 つのデータベースを格納しなければならないとします。この場合、ou=people に含まれているデータは 2 つのデータベースに分散できます。
DB1 には A-K からの名前の人が含まれ、DB2 には L-Z からの名前が含まれます。DB3 には ou=groups のデータが含まれ、DB4 には ou=contractors のデータが含まれます。
カスタムプラグインは、複数のデータベースにまたがってデータを単一の接尾辞から分散します。Directory Server のディストリビューションロジックの作成方法は、Red Hat コンサルティングにお問い合わせください。

2.2.1.1. コマンドラインを使用した単一の接尾辞用の新規データベースの作成

ldapmodify コマンドラインユーティリティーを使用して、ディレクトリー設定ファイルに新しいデータベースを追加します。データベース設定情報は cn=ldbm database,cn=plugins,cn=config エントリーに保存されます。新しいデータベースを追加するには、以下を実行します。

ldapmodify を実行して、新規データベースのエントリーを作成します。
```
# ldapmodify -a -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=UserData,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: ou=people,dc=example,dc=com
```
追加されたエントリーは UserData という名前のデータベースに対応します。このデータベースには root 接尾辞または副接尾辞 ou=people,dc=example,dc=com のデータが含まれます。
「コマンドラインでルート接尾辞の作成」および「コマンドラインを使用した従属接尾辞の作成」で説明されているように、ルートまたは従属接尾辞を作成します。DN 属性に指定されたデータベース名は、接尾辞エントリーの nsslapd-backend 属性の値に対応している必要があります。

2.2.1.2. 単一の接尾辞に複数のデータベースの追加

1 つの接尾辞は、複数のデータベースに分散できます。ただし、接尾辞を配布するには、ディレクトリーを拡張するためにカスタムディストリビューション機能を作成する必要があります。カスタムディストリビューション機能の作成に関する詳細は、Red Hat コンサルティングにお問い合わせください。

注記

エントリーが分散されたら、再分散できません。以下の制限が適用されます。

ディストリビューション機能は、エントリーディストリビューションのデプロイ後は変更できません。
エントリーを異なるデータベースに分散させる可能性がある場合は、LDAP modrdn 操作を使用してエントリーの名前を変更することができません。
分散ローカルデータベースは複製できません。
エントリーを異なるデータベースに分散させる可能性がある場合は、ldapmodify 操作を使用してエントリーを変更することができません。

これらの制限に違反すると、Directory Server はエントリーを正しく特定して返さないようにします。

カスタムディストリビューションロジックプラグインを作成したら、そのプラグインをディレクトリーに追加します。

ディストリビューションロジックは、接尾辞で宣言された関数です。この関数は、この接尾辞に到達するすべての操作に対して呼び出されます。これには、接尾辞の前に開始するサブツリー検索操作が含まれます。ディストリビューション機能は、Web コンソールとコマンドラインインターフェイスの両方を使用して接尾辞に挿入できます。

カスタムディストリビューション機能を接尾辞に追加するには、以下を指定します。

ldapmodify を実行します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

以下の属性を接尾辞エントリー自体に追加し、カスタムディストリビューションロジックに関する情報を提供します。
```
dn: suffix
changetype: modify
add: nsslapd-backend
nsslapd-backend: Database1
-
add: nsslapd-backend
nsslapd-backend: Database2
-
add: nsslapd-backend
nsslapd-backend: Database3
-
add: nsslapd-distribution-plugin
nsslapd-distribution-plugin: /full/name/of/a/shared/library
-
add: nsslapd-distribution-funct
nsslapd-distribution-funct: distribution-function-name
```
nsslapd-backend 属性は、この接尾辞に関連付けられたすべてのデータベースを指定します。nsslapd-distribution-plugin 属性は、プラグインが使用するライブラリーの名前を指定します。nsslapd-distribution-funct 属性は、ディストリビューション機能自体の名前を提供します。

2.2.2. Directory データベースの維持

2.2.2.1. 読み取り専用モードでのデータベースの設定

データベースが読み取り専用モードの場合は、エントリーを作成、変更、または削除することはできません。読み取り専用モードが役立つ状況の 1 つは、コンシューマーを手動で初期化する場合や、Directory Server からデータをバックアップまたはエクスポートする前です。読み取り専用モードは、特定の時点でのこれらのデータベースの状態の正確なイメージを保証します。

コマンドラインユーティリティーと Web コンソールは、エクスポートまたはバックアップの操作の前に読み取り専用モードでディレクトリーを自動的に配置しません。これは、ディレクトリーの更新で利用できなくなるためです。ただし、マルチサプライヤーレプリケーションでは、これは問題ではない可能性があります。

2.2.2.1.1. コマンドラインを使用した読み取り専用モードでのデータベースの設定

データベースを読み取り専用モードで設定するには、dsconf backend suffix set コマンドを使用します。たとえば、o=test 接尾辞のデータベースを読み取り専用モードで設定するには、以下を実行します。

接尾辞とそれに対応するバックエンドを表示します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
dc=example,dc=com (userroot)
o=test (test_database)
```
このコマンドにより、各接尾辞の横にバックエンドデータベースが表示されます。次の手順で、接尾辞のデータベース名が必要です。

データベースを読み取り専用モードで設定します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix set --enable-readonly "test_database"

2.2.2.1.2. Web コンソールを使用した読み取り専用モードでのデータベースの設定

データベースを読み取り専用モードで設定するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Database メニューを開きます。
接尾辞エントリーを選択します。
Database Read-Only Mode を選択します。
Save Configuration をクリックします。

2.2.2.2. 読み取り専用モードでの Directory Server の配置

Directory Server が複数のデータベースを維持しており、すべてのデータベースを読み取り専用モードで配置する必要がある場合は、1 回の操作で実行できます。

警告

この操作により、Directory Server 設定が読み取り専用になるため、サーバー設定の更新、プラグインの有効化または無効化、読み取り専用モードの場合は Directory Server を再起動することはできません。読み取り専用モードを有効にすると、設定ファイルを手動で変更しない限り、元に戻すことは できません。

注記

Directory Server にレプリカが含まれている場合は、レプリケーションを無効にするため、読み取り専用モードを使用 しないでください。

2.2.2.2.1. コマンドラインを使用した読み取り専用モードでの Directory Server の配置

Directory Server に対して読み取り専用モードを有効にするには、以下を実行します。

nsslapd-readonly パラメーターを on に設定します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-readonly=on

インスタンスを再起動します。
```
# dsctl instance_name restart
```

2.2.2.2.2. Web コンソールを使用した読み取り専用モードでの Entire Directory Server の配置

Directory Server に対して読み取り専用モードを有効にするには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Server Settings メニューを開き、Server Settings エントリーを選択します。
Advanced Settings タブで Server Read-Only を選択します。
Save をクリックします。

2.2.2.3. データベースの削除

接尾辞が不要になった場合は、接尾辞を保存するデータベースを削除できます。

2.2.2.3.1. コマンドラインを使用したデータベースの削除

データベースを削除するには、dsconf backend delete コマンドを使用します。たとえば、o=test 接尾辞のデータベースを削除するには、以下を実行します。

接尾辞とそれに対応するバックエンドを表示します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
dc=example,dc=com (userroot)
o=test (test_database)
```
次の手順で、接尾辞の横に表示されるバックエンドデータベースの名前が必要です。

データベースを削除します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com backend delete "test_database"

2.2.2.3.2. Web コンソールを使用したデータベースの削除

Web コンソールを使用してデータベースを削除するには、以下を行います。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Database メニューを開きます。
削除する接尾辞を選択し、Suffix Tasks をクリックして Delete Suffix を選択します。
Yes をクリックして確定します。

2.2.2.4. トランザクションログディレクトリーの変更

トランザクションログにより、Directory Server は、インスタンスが予期せずにシャットダウンした後にデータベースを復元できます。特定の状況では、管理者はトランザクションログへのパスを変更したい場合があります。たとえば、Directory Server データベースとは異なる物理ディスクに保存するには、次を実行します。

注記

パフォーマンスを向上させるには、場所を変更する代わりに、トランザクションログが含まれるディレクトリーに高速ディスクをマウントします。詳細は、『Red Hat Directory Server パフォーマンスチューニングガイド』の該当するセクションを参照してください。

トランザクションログディレクトリーの場所を変更するには、以下を行います。

Directory Server インスタンスを停止します。
```
# dsctl instance_name stop
```
トランザクションログ用に新しい場所を作成します。以下に例を示します。
```
# mkdir -p /srv/dirsrv/instance_name/db/
```
Directory Server のみがディレクトリーにアクセスできるように、パーミッションを設定します。
```
# chown dirsrv:dirsrv /srv/dirsrv/instance_name/db/
# chmod 770 /srv/dirsrv/instance_name/db/
```
以前のトランザクションログディレクトリーからすべての __db.* ファイルを削除します。以下に例を示します。
```
# rm /var/lib/dirsrv/slapd-instance_name/db/__db.*
```
以前のトランザクションログディレクトリーから新しいトランザクションログディレクトリーに、すべての log.* ファイルを移動します。以下に例を示します。
```
# mv /var/lib/dirsrv/slapd-instance_name/db/log.* \
     /srv/dirsrv/instance_name/db/
```
SELinux が enforcing モードで実行している場合は、ディレクトリーに dirsrv_var_lib_t コンテキストを設定します。
```
# semanage fcontext -a -t dirsrv_var_lib_t /srv/dirsrv/instance_name/db/
# restorecon -Rv /srv/dirsrv/instance_name/db/
```
/etc/dirsrv/slapd-instance_name/dse.ldif ファイルを編集し、cn=config,cn=ldbm database,cn=plugins,cn=config エントリーの nsslapd-db-logdirectory パラメーターを更新します。以下に例を示します。
```
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
...
nsslapd-db-logdirectory: /srv/dirsrv/instance_name/db/
```
インスタンスを起動します。
```
# dsctl instance_name start
```

2.3. データベースリンクの作成および維持

チェーン とは、サーバーがクライアントアプリケーションの代わりに他のサーバーに接続し、組み合わせた結果を返すことを意味します。チェーンは データベースリンク を介して実装され、リモートで保存されたデータを参照します。クライアントアプリケーションがデータベースリンクからデータを要求すると、データベースリンクはリモートデータベースからデータを取得し、クライアントに返します。

チェーンに関する一般的な情報は、『Red Hat Directory Server デプロイメントガイド』のディレクトリートポロジーの設計の章を参照してください。「データベースリンクアクティビティーの監視」では、データベースリンクアクティビティーを監視する方法を説明します。

2.3.1. 新規データベースリンクの作成

基本的なデータベースリンクの設定には、以下の情報が必要です。

接尾辞の情報。接尾辞は、通常のデータベースではなく、データベースリンクが管理するディレクトリーツリーに作成されます。この接尾辞は、データが含まれるリモートサーバーの接尾辞に対応します。
バインド認証情報。データベースリンクがリモートサーバーにバインドされると、ユーザーのなりすましが行われ、リモートサーバーとバインドするために使用する各データベースリンクの DN および認証情報を指定します。
LDAP URL。これは、データベースリンクが接続するリモートサーバーの LDAP URL を提供します。URL はプロトコル (ldap または ldaps)、サーバーのホスト名または IP アドレス (IPv4 または IPv6)、およびポートで設定されます。
フェイルオーバーサーバーのリスト。これは、障害発生時にデータベースリンクが接続するための代替サーバーのリストを提供します。この設定項目は任意です。

注記

シンプルなパスワード認証 (「セキュアなバインドの要求」) にセキュアなバインドが必要な場合は、セキュアな接続で行われる場合を除き、チェーン操作は失敗します。いずれの場合も、セキュアな接続 (TLS および STARTTLS 接続または SASL 認証) の使用が推奨されます。

2.3.1.1. コマンドラインを使用した新規データベースリンクの作成

新しいデータベースリンクを作成するには、dsconf chaining link-create コマンドを使用します。以下に例を示します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining link-create --suffix="ou=Customers,dc=example,dc=com" --server-url="ldap://remote_server.example.com:389" --bind-mech="" --bind-dn="cn=proxy_user,cn=config" --bind-pw="password" "example_chain_name"

これにより、ou=Customers,dc=example,dc=com の example_chain_name という名前のデータベースリンクが作成されます。リンクはサーバー ldap://remote_server.example.com:389 を参照し、指定のバインド DN とパスワードを使用して認証を行います。--bind-mech が空に設定されているため、リンクは簡易認証を使用します。

注記

proxy_user にデータへのアクセス権を付与するには、リモートサーバーの dc=example,dc=com 接尾辞にプロキシー ACI エントリーを作成する必要があります。その方法については、「データベースリンクの作成時に必要な設定に関する追加情報」セクションを参照してください。

データベースリンクの作成時に設定できる追加設定を表示するには、以下を参照してください。

# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining link-create --help

詳細は、「データベースリンクの作成時に必要な設定に関する追加情報」を参照してください。

2.3.1.2. Web コンソールを使用した新規データベースリンクの作成

新規データベースリンクを作成するには、以下を行います。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Database メニューを開きます。
「接尾辞の作成」で説明されているように、新しい接尾辞を作成します。
接尾辞を選択し、Suffix Tasks をクリックして Create Database Link を選択します。
フィールドに、リモートサーバーへのコネクションの詳細を入力します。以下に例を示します。
詳細は、「データベースリンクの作成時に必要な設定に関する追加情報」を参照してください。
Create Database Link をクリックします。

2.3.1.3. 新規データベースリンクのデフォルト設定の管理

dsconf chaining コマンドを使用すると、データベースリンクのデフォルト設定を管理できます。

現在のデフォルト値を表示するには、以下を参照してください。

# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-get-def

新しいデータベースリンク設定を変更するには、dsconf chaining config-set-def コマンドを使用します。たとえば、response-delay パラメーターを 30 に設定するには、以下を実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-set-def --response-delay 30

このサンプルコマンドは、すべてのチェーン接続にデフォルトの応答タイムアウトを設定します。dsconf instance chaining link-set コマンドを使用すると、特定のチェーンリンクの応答タイムアウトを上書きできます。

設定可能なすべてのパラメーターの一覧を表示するには、以下を実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-set-def --help

2.3.1.4. データベースリンクの作成時に必要な設定に関する追加情報

接尾辞情報

接尾辞は、データベースリンクで管理される接尾辞を定義します。

バインド認証情報

クライアントアプリケーションからの要求がリモートサーバーにチェーンされるようにするには、クライアントアプリケーションに特別なバインド認証情報を指定できます。これにより、リモートサーバーでチェーン操作に必要なプロキシー認証権限が付与されます。バインド認証情報がないと、データベースリンクは anonymous としてリモートサーバーにバインドされます。

たとえば、クライアントアプリケーションは要求をサーバー A に送信します。サーバー A には、サーバー B のデータベースに要求をチェーンするデータベースリンクが含まれています。

サーバー A のデータベースリンクは、特別なユーザーとパスワードを使用してサーバー B にバインドされます。

サーバー B にはユーザーエントリーが含まれ、このユーザーのプロキシー認証権限を設定する必要があります。プロキシー承認を正しく設定するには、プロキシー ACI をその他の ACI として設定します。

警告

ディレクトリーの制限された領域へのアクセス権限を付与しないようにチェーンを有効にする場合は、アクセス制御を慎重に検討します。たとえば、ブランチにデフォルトのプロキシー ACI が作成されると、データベースリンクを使用して接続するユーザーは、そのブランチの下にあるすべてのエントリーを表示できるようになります。ユーザーがすべてのサブツリーを表示する必要がない場合もあります。セキュリティーホールを回避するには、追加の ACI を作成して、サブツリーへのアクセスを制限します。

ACI の詳細は、18章アクセス制御の管理を参照してください。

注記

エントリーの作成または変更にクライアントアプリケーションでデータベースリンクを使用する場合、creatorsName 属性および modifiersName 属性にはエントリーの実際の作成者または修正者が反映されません。これらの属性には、リモートデータサーバーでプロキシー認証権限が付与されている管理ユーザーの名前が含まれています。

バインド認証情報を指定するには、リモートサーバーで以下の手順が必要です。

データベースリンク用に、cn=proxy_user,cn=config などの管理ユーザーを作成します。エントリーの追加に関する詳細は、3章ディレクトリーエントリーの管理を参照してください。
データベースリンクによってチェーンされたサブツリーの直前の手順で作成した管理ユーザーのプロキシーアクセス権限を提供します。ACI の設定に関する詳細は、18章アクセス制御の管理を参照してください。
たとえば、以下の ACI は、ACI が設定されたサブツリー内のみにリモートサーバーに含まれるデータにアクセスするために、cn=proxy_admin,cn=config ユーザーへの読み取り専用アクセスを付与します。
```
aci: (targetattr = "*")(version 3.0; acl "Proxied authorization
     for database links"; allow (proxy) userdn = "ldap:///cn=proxy_admin
     ,cn=config";)
```

注記

ユーザーがデータベースリンクにバインドすると、ユーザーのアイデンティティーがリモートサーバーに送信されます。アクセス制御は、常にリモートサーバーで評価されます。ユーザーがリモートサーバーにデータを変更または書き込みできるようにするには、リモートサーバーに正しいアクセス制御を設定します。チェーン操作のコンテキストでアクセス制御がどのように評価されるかについての詳細は、「データベースリンクおよびアクセス制御評価」を参照してください。

LDAP URL

データベースリンクが含まれるサーバーで、データベースリンクが LDAP URL を使用して接続するリモートサーバーを特定します。標準の LDAP URL 形式とは異なり、リモートサーバーの URL は接尾辞を指定しません。ldap://host_name:port の形式を取ります。

データベースリンクが TLS 経由で LDAP を使用してリモートサーバーに接続する場合、リモートサーバーの LDAP URL は URL の LDAP ではなくプロトコル LDAP を使用し、サーバーのセキュアなポートを参照します。たとえば、以下のようになります。

ldaps://africa.example.com:636/

注記

TLS を介してチェーンするには、ローカル Directory Server とリモート Directory Server で TLS を有効にする必要があります。TLS の有効化に関する詳細は、「TLS の有効化」を参照してください。

データベースリンクとリモートサーバーが TLS を使用して通信するよう設定されている場合は、操作要求を行うクライアントアプリケーションも TLS を使用して通信する必要があるわけではありません。クライアントは、通常のポートを使用してバインドできます。

バインドメカニズム

ローカルサーバーは、複数の異なる接続タイプと認証メカニズムを使用してリモートサーバーに接続できます。

ローカルサーバーがリモートサーバーに接続する方法は 3 つあります。

標準の LDAP ポートを使用する場合
専用の LDAPS ポートを使用する場合
STARTTLS (標準ポートでのセキュアな接続) の使用

注記

最終的に 2 つの接続設定があります。TLS オプションでは、サーバーの両方が TLS 経由の接続を実行および許可するように設定されますが、TLS を強制する別の設定属性はありません。

ローカルサーバーがファームサーバーへの認証に使用できる 4 つの方法があります。

empty: バインドメカニズムが設定されていない場合、サーバーは単純な認証を実行し、バインド DN とパスワードが必要になります。
EXTERNAL: これは TLS 証明書を使用して、ファームサーバーをリモートサーバーに認証します。ファームサーバーをセキュアな URL (ldaps) に設定するか、nsUseStartTLS 属性を on に設定する必要があります。
さらに、『Red Hat Directory Server 設定、コマンド、およびファイルリファレンス』の『certmap.conf』セクションで説明されているように、ファームサーバーの証明書をバインド ID にマッピングするようにリモートサーバーを設定する必要があります。
DIGEST-MD5: DIGEST-MD5 暗号化での SASL 認証を使用します。簡易認証と同様、バインド情報を付与するには、nsMultiplexorBindDN および nsMultiplexorCredentials 属性が必要です。
GSSAPI: SASL 上で Kerberos ベースの認証を使用します。
ファームサーバーは Kerberos キータブで設定する必要があるため、リモートサーバーには、そのファームサーバーのバインド ID に対して定義された SASL マッピングが必要です。Kerberos キータブおよび SASL マッピングの設定は、「SASL Identity マッピングの設定」に記載されています。

注記

SASL 接続は、標準の接続または TLS 接続で確立できます。

注記

SASL を使用する場合は、SASL およびパスワードポリシーコンポーネントをチェーンするようにローカルサーバーを設定する必要もあります。「シャーシポリシーの設定」で説明されているように、データベースリンク設定のコンポーネントを追加します。

2.3.2. シャーシポリシーの設定

この手順では、クライアントアプリケーションによって行われた要求を、データベースリンクを含む Directory Server に、Directory Server が連鎖させる方法の設定を説明します。このチェーンポリシーは、Directory Server で作成されたすべてのデータベースリンクに適用されます。

2.3.2.1. コンポーネントの動作の連鎖

コンポーネントは、内部操作を使用するサーバーの機能ユニットです。たとえば、プラグインはフロントエンドの機能のようにコンポーネントとみなされます。ただし、プラグインは実際には複数のコンポーネントで設定される場合があります (例: ACI プラグイン)。

一部のコンポーネントは、ローカルデータのみにアクセスできることを想定し、内部 LDAP 要求をサーバーに送信します。このようなコンポーネントの場合、チェーンポリシーを制御し、コンポーネントが操作を正常に完了できるようにします。一例として、証明書の検証機能が挙げられます。証明書をチェックするために関数によって行われる LDAP 要求を連鎖させると、リモートサーバーが信頼されていることを意味します。リモートサーバーが信頼されていない場合は、セキュリティーの問題があります。

デフォルトでは、すべての内部操作はチェーンされず、チェーンにはコンポーネントは許可されませんが、これは上書きできます。

また、指定したプラグインがリモートサーバーで操作を実行できるようにするには、リモートサーバーに ACI を作成する必要があります。ACI は、データベースリンクに割り当てられた 接尾辞 に存在している必要があります。

以下は、コンポーネント名、内部操作をチェーンできるようにする可能性のある副次的な影響、およびリモートサーバーの ACI で必要なパーミッションをリスト表示します。

ACI プラグイン

このプラグインはアクセス制御を実装します。ACI 属性の取得および更新に使用される操作は、ローカルおよびリモートの ACI 属性を混在することは安全ではないため、連鎖されません。ただし、ユーザーエントリーの取得に使用されるリクエストは、チェーンコンポーネント属性を設定することでチェーンすることができます。

nsActiveChainingComponents: cn=ACI Plugin,cn=plugins,cn=config

権限: 読み取り、検索、および比較

リソース制限コンポーネント

このコンポーネントは、ユーザーバインド DN に応じてサーバー制限を設定します。リソース制限コンポーネントを連鎖させることが可能であれば、リソース制限をリモートユーザーに適用できます。リソース制限コンポーネント操作を連鎖させるには、連鎖コンポーネント属性を追加します。

nsActiveChainingComponents: cn=resource limits,cn=components,cn=config

権限: 読み取り、検索、および比較

証明書ベースの認証チェックコンポーネント

このコンポーネントは、外部バインドメソッドが使用される場合に使用します。リモートサーバーのデータベースからユーザー証明書を取得します。このコンポーネントの連鎖を許可すると、証明書ベースの認証がデータベースリンクと連携できることを意味します。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。

nsActiveChainingComponents: cn=certificate-based authentication,cn=components,cn=config

権限: 読み取り、検索、および比較

パスワードポリシーコンポーネント

このコンポーネントは、リモートサーバーへの SASL バインドを許可するために使用されます。SASL 認証の形式によっては、ユーザー名とパスワードを使用した認証が必要になります。パスワードポリシーを有効にすると、サーバーは要求された特定の認証方法を検証および実装し、適切なパスワードポリシーを適用できます。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。

nsActiveChainingComponents: cn=password policy,cn=components,cn=config

権限: 読み取り、検索、および比較

SASL コンポーネント

このコンポーネントは、リモートサーバーへの SASL バインドを許可するために使用されます。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。

nsActiveChainingComponents: cn=password policy,cn=components,cn=config

権限: 読み取り、検索、および比較

参照整合性プラグイン

このプラグインは、DN を含む属性の更新が、属性へのポインターを含むすべてのエントリーに伝播されるようにします。たとえば、グループのメンバーであるエントリーが削除されると、そのエントリーはグループから自動的に削除されます。このプラグインをチェーンで使用すると、グループメンバーが静的グループ定義にリモートになる場合に静的グループの管理を簡素化できます。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。

nsActiveChainingComponents: cn=referential integrity postoperation,cn=plugins,cn=config

権限: 読み取り、検索、および比較

Attribute Uniqueness プラグイン

このプラグインは、指定された属性のすべての値が一意 (重複なし) のものであることを確認します。このプラグインが連鎖されている場合は、データベースリンクで変更された属性でも属性値が一意であることを確認します。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。

nsActiveChainingComponents: cn=attribute uniqueness,cn=plugins,cn=config

権限: 読み取り、検索、および比較

ロールのコンポーネント

このコンポーネントは、データベースのエントリーのロールおよびロール割り当てを連鎖させます。このコンポーネントの連鎖は、連鎖されたデータベースであってもロールを維持します。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。

nsActiveChainingComponents: cn=roles,cn=components,cn=config

権限: 読み取り、検索、および比較

注記

以下のコンポーネントはチェーンできません。

Roles プラグイン
パスワードポリシーコンポーネント
レプリケーションプラグイン
参照整合性プラグイン

連鎖要求を発行しているサーバーで Referential Integrity プラグインを有効にする場合は、パフォーマンス、リソース、時間のニーズ、整合性のニーズを分析してください。整合性チェックは時間がかかり、メモリーと CPU を浪費する可能性があります。ACI および連鎖関連の制限の詳細は、「ACI の制限」を参照してください。

2.3.2.1.1. コマンドラインを使用したコンポーネント操作の連鎖

チェーンに許可されているコンポーネントを追加するには、以下を実行します。

チェーンに追加するコンポーネントを指定します。たとえば、整合性コンポーネントが連鎖操作を実行できるように設定するには、次のコマンドを実行します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-set \
     --add-comp="cn=referential integrity postoperation,cn=components,cn=config"
```
連鎖が可能なコンポーネントのリストは、「コンポーネントの動作の連鎖」を参照してください。
インスタンスを再起動します。
```
# dsctl instance_name restart
```

操作を連鎖させるリモートサーバーの接尾辞に ACI を作成します。たとえば、Rerefer Integrity プラグインに ACI を作成するには、次のコマンドを実行します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h remoteserver.example.com -x
dn: ou=People,dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr = "*")(target="ldap:///ou=customers,l=us,dc=example,dc=com")
 (version 3.0; acl "RefInt Access for chaining"; allow
 (read,write,search,compare) userdn = "ldap:///cn=referential
 integrity postoperation,cn=plugins,cn=config";)

2.3.2.1.2. Web コンソールを使用したコンポーネントの操作の連鎖

チェーンに許可されているコンポーネントを追加するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Database タブを開きます。
左側のナビゲーションで、Chaining Configuration エントリーを選択します。
Components to Chain フィールドの下にある Add ボタンをクリックします。
コンポーネントを選択し、Add & Save New Components をクリックします。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h remoteserver.example.com -x
dn: ou=People,dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr = "*")(target="ldap:///ou=customers,l=us,dc=example,dc=com")
 (version 3.0; acl "RefInt Access for chaining"; allow
 (read,write,search,compare) userdn = "ldap:///cn=referential
 integrity postoperation,cn=plugins,cn=config";)

2.3.2.2. LDAP 制御チェーン

LDAP 制御による操作リクエストを連鎖させることは できません。デフォルトでは、以下の制御で行われる要求は、データベースリンクによってリモートサーバーに転送されます。

仮想リストビュー (VLV)。この制御は、すべてのエントリー情報を返すのではなく、エントリーの一部のリストを提供します。
サーバー側のソート。この制御では、通常は特定のマッチングルールを使用して、エントリーを属性値に従ってソートます。
逆参照。この制御は、検索内のエントリー属性の参照を上書きし、参照されるエントリーから指定された属性情報をプルし、残りの検索結果とともに返します。
管理 DSA。この制御は、参照に従うのではなく、スマート参照をエントリーとして返します。そのため、スマートの参照自体は変更または削除できます。
ループ検出。この制御では、別のサーバーとのサーバー連鎖の回数を追跡します。数が設定された数に達すると、ループが検出され、クライアントアプリケーションに通知が送信されます。この制御の使用方法は、「ループの検出」を参照してください。

注記

サーバー側のソートおよび VLV 制御は、1 つのデータベースにクライアントアプリケーション要求が行われている場合にのみサポートされます。データベースリンクは、クライアントアプリケーションが複数のデータベースに要求を行う場合に、これらの制御をサポートしません。

チェーン可能な LDAP 制御とその OID を以下の表に示します。

表2.1 LDAP コントロールとその OID

コントロール名	OID
仮想リストビュー (VLV)	2.16.840.1.113730.3.4.9
サーバー側のソート	1.2.840.113556.1.4.473
管理 DSA	2.16.840.1.113730.3.4.2
ループ検出	1.3.6.1.4.1.1466.29539.12
検索の逆参照	1.3.6.1.4.1.4203.666.5.16

2.3.2.2.1. コマンドラインを使用した LDAP コントロールの連鎖

LDAP 制御をチェーンするには、dsconf chaining config-set --add-control コマンドを使用します。たとえば、仮想リストビューコントロールを転送するには、以下を実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining \
     config-set --add-control="2.16.840.1.113730.3.4.9"

Directory Server のクライアントが独自の制御を作成し、その操作をリモートサーバーにチェーンする必要がある場合は、カスタムコントロールのオブジェクト識別子 (OID) を追加します。

連鎖可能な LDAP コントロールとその OID のリストは、表2.1「LDAP コントロールとその OID」を参照してください。

2.3.2.2.2. Web コンソールを使用した LDAP 制御の連鎖

Web コンソールを使用して LDAP コントロールを連鎖するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Database メニューを開きます。
Chaining Configuration エントリーを選択します。
Forwarded LDAP Controls フィールドの下にある Add ボタンをクリックします。
LDAP コントロールを選択し、Add & Save New Controls をクリックします。
Directory Server のクライアントが独自の制御を作成し、その操作をリモートサーバーにチェーンする必要がある場合は、カスタムコントロールのオブジェクト識別子 (OID) を追加します。
連鎖可能な LDAP コントロールとその OID のリストは、表2.1「LDAP コントロールとその OID」を参照してください。
Save をクリックします。

2.3.3. データベースリンクおよびアクセス制御評価

ユーザーがデータベースリンクを含むサーバーにバインドすると、データベースリンクがユーザーの ID をリモートサーバーに送信します。アクセス制御は、常にリモートサーバーで評価されます。リモートサーバーで評価されるすべての LDAP 操作は、プロキシーが設定された承認コントロールを使用して渡されたクライアントアプリケーションの元の ID を使用します。ユーザーがリモートサーバーに含まれるサブツリーに正しいアクセス制御がある場合に限り、リモートサーバーで操作に成功します。これには、いくつかの制限があるリモートサーバーに通常のアクセス制御を追加する必要があります。

すべての種類のアクセス制御を使用できるわけではありません。
たとえば、ロールベースまたはフィルターベースの ACI はユーザーエントリーへのアクセスを必要とします。データベースリンクを介してデータにアクセスするため、プロキシーコントロールのデータのみが検証できます。ユーザーエントリーがユーザーのデータと同じデータベースに配置されるように、ディレクトリーを設計することを検討してください。
クライアントの IP アドレスまたは DNS ドメインに基づくすべてのアクセス制御は、チェーン中にクライアントの元のドメインが失われるためです。リモートサーバーは、クライアントアプリケーションをデータベースリンクと同じ IP アドレスと、同じ DNS ドメインにある表示します。
注記
Directory Server は、IPv4 と IPv6 の IP アドレスの両方に対応します。

データベースリンクで使用される ACI には、以下の制限が適用されます。

ACI は、使用する任意のグループと共に配置する必要があります。グループが動的である場合は、グループ内のすべてのユーザーが ACI およびグループで配置される必要があります。グループが静的である場合は、リモートユーザーにリンクされます。
ACI は、使用するロール定義とそれらのロールを持つユーザーに対して配置する必要があります。
ユーザーのエントリーの値 (例: userattr サブジェクトルール) にリンクする ACI は、ユーザーがリモートの場合に機能します。

アクセス制御は常にリモートサーバーで評価されますが、データベースリンクとリモートサーバーの両方が含まれるサーバーでも評価できます。これにはいくつかの制限があります。

アクセス制御の評価時に、ユーザーエントリーの内容は必ずしも利用できるとは限りません (たとえば、データベースリンクを含むサーバーでアクセス制御が評価され、エントリーがリモートサーバーにある場合)。
パフォーマンス上の理由から、クライアントはリモート問い合わせを実行してアクセス制御を評価することはできません。
データベースリンクは、クライアントアプリケーションによって変更されるエントリーに必ずしもアクセスできるとは限りません。
変更操作を実行する場合、データベースリンクはリモートサーバーに保存されている全エントリーにアクセスできません。削除操作を実行すると、データベースリンクはエントリーの DN のみを認識します。アクセス制御が特定の属性を指定する場合、データベースリンクを介して実行すると削除操作は失敗します。

注記

デフォルトでは、データベースリンクが含まれるサーバーに設定されたアクセス制御は評価されません。このデフォルトをオーバーライドするには、cn=database_link, cn=chaining database,cn=plugins,cn=config エントリーの nsCheckLocalACI 属性を使用します。ただし、データベースリンクを含むサーバーでアクセス制御を評価することは、カスケード連鎖を使用する場合を除いて推奨されません。

2.4. カスケード連鎖の設定

データベースリンクは、別のデータベースリンクに指定するように設定でき、カスケード連鎖操作を作成します。ディレクトリーツリー内の全データにアクセスするのに、複数のホップが必要になるとカスケード連鎖がいつでも発生します。

2.4.1. カスケード連鎖の概要

ディレクトリーがクライアントアプリケーションの要求を処理するために必要なホップが複数使用されると、カスケード連鎖が発生します。

クライアントアプリケーションは変更要求を Server 1 に送信します。Server 1 には、別のデータベースリンクが含まれる Server 2 に操作を転送するデータベースリンクが含まれています。Server 2 のデータベースリンクは、クライアントがデータベースに変更するデータが含まれる Server 3 に転送します。クライアントが変更するデータの一部にアクセスするには、2 つのホップが必要になります。

通常の操作要求時に、クライアントはサーバーにバインドし、そのクライアントに適用された ACI が評価されます。カスケード連鎖では、クライアントバインド要求は Server 1 で評価されますが、上の例の Server 2 クライアントに適用される ACI は、要求が宛先サーバーへチェーンされた後にのみ評価されます。

たとえば、サーバー A では、ディレクトリーツリーが分割されます。

ルート接尾辞 dc=example,dc=com ならびに ou=people および ou=groups のサブ接尾辞は、サーバー A に保存されます。ou=europe,dc=example,dc=com および ou=groups の接尾辞は、サーバー B に保存され、ou=europe,dc=example,dc=com 接尾辞の ou=people ブランチはサーバー C に保存されます。

サーバー A、B、および C に設定されたカスケードでは、以下のように ou=people,ou=europe,dc=example,dc=com エントリーでターゲットとなるクライアント要求が以下のようにルーティングされます。

まず、クライアントは、Database Link 1 を使用して Server A にバインドし、Server B に連鎖します。その後、Server B は、Database Link 2 を使用して ou=people,ou=europe,dc=example,dc=com ブランチのデータにアクセスする Server C のターゲットデータベースに連鎖されます。ディレクトリーがクライアント要求を処理するには少なくとも 2 つのホップが必要であるため、これはカスケード連鎖とみなされます。

2.4.2. コマンドラインを使用したカスケード連鎖の設定

本セクションでは、以下の図に示すように、3 つのサーバーを使用してカスケード連鎖を設定する方法を説明します。

Server 1 の設定手順

接尾辞 c=africa,ou=people,dc=example,dc=com を作成します。

# dsconf -D "cn=Directory Manager" ldap://server1.example.com backend create --parent-suffix="ou=people,dc=example,dc=com" --suffix="c=africa,ou=people,dc=example,dc=com"

DBLink1 データベースリンクを作成します。

# dsconf -D "cn=Directory Manager" ldap://server1.example.com chaining link-create --suffix="c=africa,ou=people,dc=example,dc=com" --server-url="ldap://africa.example.com:389/" --bind-mech="" --bind-dn="cn=server1 proxy admin,cn=config" --bind-pw="password" --check-aci="off" "DBLink1"

ループ検出を有効にします。

# dsconf -D "cn=Directory Manager" ldap://server1.example.com chaining config-set --add-control="1.3.6.1.4.1.1466.29539.12"

Server 2 上の設定手順

Server 1 をプロキシー承認に使用するプロキシー管理ユーザーを Server 2 に作成します。

# ldapadd -D "cn=Directory Manager" -W -p 389 -h server2.example.com -x
dn: cn=server1 proxy admin,cn=config
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: server1 proxy admin
sn: server1 proxy admin
userPassword: password
description: Entry for use by database links

重要

セキュリティー上の理由から、cn=Directory Manager アカウントは使用しないでください。

接尾辞 ou=Zanzibar,c=africa,ou=people,dc=example,dc=com を作成します。

# dsconf -D "cn=Directory Manager" ldap://server2.example.com backend create --parent-suffix="c=africaou=people,dc=example,dc=com" --suffix="ou=Zanzibar,c=africa,ou=people,dc=example,dc=com"

DBLink2 データベースリンクを作成します。
```
# dsconf -D "cn=Directory Manager" ldap://server2.example.com chaining link-create --suffix="ou=Zanzibar,c=africa,ou=people,dc=example,dc=com" --server-url="ldap://zanz.africa.example.com:389/" --bind-mech="" --bind-dn="server2 proxy admin,cn=config" --bind-pw="password" --check-aci="on "DBLink2"
```
DBLink2 リンクはカスケード連鎖設定の中間データベースリンクであるため、ACL チェックを有効にして、クライアントとプロキシーの管理ユーザーによるデータベースリンクへのアクセスを許可するかどうかをサーバーが確認できるようにします。

ループ検出を有効にします。

# dsconf -D "cn=Directory Manager" ldap://server2.example.com chaining config-set --add-control="1.3.6.1.4.1.1466.29539.12"

プロキシー認証制御を有効にします。

# dsconf -D "cn=Directory Manager" ldap://server2.example.com chaining config-set --add-control="2.16.840.1.113730.3.4.12"

ローカルプロキシー認証 ACI を追加します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server2.example.com -x
dn: c=africa,ou=people,dc=example,dc=com
changetype: modify
add: aci
aci:(targetattr="*")(target="lou=Zanzibar,c=africa,ou=people,dc=example,dc=com")
     (version 3.0; acl "Proxied authorization for database links"; allow (proxy)
     userdn = "ldap:///cn=server1 proxy admin,cn=config";)

Server 1 の c=us,ou=people,dc=example,dc=com にいる uid 属性セットを持つユーザーが、Server 3 の ou=Zanzibar,c=africa,ou=people,dc=example,dc=com の接尾辞ツリーに対して、任意のタイプの操作を実行できるようにする ACI を追加します。
```
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server2.example.com -x
dn: c=africa,ou=people,dc=example,dc=com
changetype: modify
add: aci
aci:(targetattr="*")(target="ou=Zanzibar,c=africa,ou=people,dc=example,dc=com")
     (version 3.0; acl "Client authorization for database links"; allow (all)
     userdn = "ldap:///uid=*,c=us,ou=people,dc=example,dc=com";)
```
Server 3 に、Server 3 で追加の権限を必要とする別の接尾辞のユーザーが存在する場合は、Server 2 にさらにクライアント ACI を追加する必要があります。

Server 3 の設定手順

Server 3 でプロキシー管理ユーザーを作成し、Server 2 をプロキシー承認に使用するプロキシー管理ユーザーを作成します。

# ldapadd -D "cn=Directory Manager" -W -p 389 -h server3.example.com -x
dn: cn=server2 proxy admin,cn=config
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: server2 proxy admin
sn: server2 proxy admin
userPassword: password
description: Entry for use by database links

重要

セキュリティー上の理由から、cn=Directory Manager アカウントは使用しないでください。

ローカルプロキシー認証 ACI を追加します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server3.example.com -x
dn: ou=Zanzibar,ou=people,dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr = "*")(version 3.0; acl "Proxied authorization
     for database links"; allow (proxy) userdn = "ldap:///cn=server2
     proxy admin,cn=config";)

Server 1 の c=us,ou=people,dc=example,dc=com にいる uid 属性セットを持つユーザーが、Server 3 の ou=Zanzibar,c=africa,ou=people,dc=example,dc=com の接尾辞ツリーに対して、任意のタイプの操作を実行できるようにする ACI を追加します。
```
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server3.example.com -x
dn: ou=Zanzibar,ou=people,dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr ="*")(target="ou=Zanzibar,c=africa,ou=people,dc=example,dc=com")
     (version 3.0; acl "Client authentication for database link users"; allow (all)
     userdn = "ldap:///uid=*,c=us,ou=people,dc=example,dc=com";)
```
Server 3 に、Server 3 で追加の権限を必要とする別の接尾辞のユーザーが存在する場合は、Server 2 にさらにクライアント ACI を追加する必要があります。

これで、カスケード連鎖は設定されました。このカスケード設定により、ユーザーは Server 1 にバインドし、Server 3 の ou=Zanzibar,c=africa,ou=people,dc=example,dc=com ブランチの情報を変更できます。セキュリティーのニーズに応じて、アクセス制御をより詳細に提供する必要があります。

2.4.3. ループの検出

Directory Server に含まれる LDAP 制御により、ループが回避されます。サーバーは、最初にチェーンを試行するときに、このコントロールを、使用できる最大ホップ数または連鎖接続に設定します。後続の各サーバーでカウントが減ります。サーバーが 0 の数を受信すると、ループが検出されたと判断し、クライアントアプリケーションに通知します。

コントロールを使用するには、1.3.6.1.4.1.1466.29539.12 OID を追加します。LDAP コントロールの追加に関する詳細は、「LDAP 制御チェーン」を参照してください。各データベースリンクの設定ファイルに制御がない場合、ループ検出は実装されません。

許可されるホップ数は、nsHopLimit パラメーターを使用して定義されます。デフォルトでは、パラメーターは 10 に設定されます。たとえば、example チェーンのホップ制限を 5 に設定するには、以下のコマンドを実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining link-set --hop-limit 5 example

2.5. 参照の使用

リファーラルは、特定の情報についてどのサーバーに接続するかをクライアントアプリケーションに通知します。このリダイレクトは、クライアントアプリケーションが、ローカルサーバーに存在しないディレクトリーエントリーを要求するか、メンテナンスのためにデータベースがオフラインになったときに発生します。本セクションでは、リファーラルに関する以下の情報を提供します。

「リファーラルモードでのサーバーの起動」
「デフォルト参照の設定」
「スマートリファーラルの作成」
「バグ修正参照の作成」

ディレクトリーでリファーラル部分を使用する方法に関する概念情報は、『Red Hat Directory Server デプロイメントガイド』を参照してください。

2.5.1. リファーラルモードでのサーバーの起動

リファーラルは、現在のサーバーが利用できない場合や、クライアントが現在のサーバーに保持されない情報を要求する場合に、クライアントアプリケーションを別のサーバーにリダイレクトするために使用されます。たとえば、Directory Server の設定変更中に Directory Server を起動すると、そのサーバーが利用できない場合に、すべてのクライアントを別のサプライヤーへ参照します。リファーラルモードで Directory Server を起動するには、refer コマンドを使用します。

refer オプションを指定して nsslapd を実行します。

# ns-slapd refer -D /etc/dirsrv/slapd-instance_name [-p port] -r referral_url

/etc/dirsrv/slapd-instance_name/ は、Directory Server 設定ファイルがあるディレクトリーです。これは、Red Hat Enterprise Linux でのデフォルトの場所です。
port は、リファーラルモードで開始する Directory Server のオプションのポート番号です。
referral_url は、クライアントに返される参照先です。LDAP URL の形式は、付録C LDAP URLを参照してください。

2.5.2. デフォルト参照の設定

Directory Server は、ディレクトリーが維持する接尾辞にない DN で操作を送信するクライアントアプリケーションにデフォルトのリファーラル情報を返します。以下の手順では、コマンドラインを使用してディレクトリーのデフォルトリファーラル情報を設定する方法を説明します。

2.5.2.1. コマンドラインを使用したデフォルトのリファーラルの設定

dsconf config replace コマンドを使用して、nsslapd-referral パラメーターのデフォルトのリファーラルを設定します。たとえば、ldap://directory.example.com/ をデフォルトのリファーラルとして設定するには、以下のコマンドを実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-referral="ldap://directory.example.com/"

2.5.3. スマートリファーラルの作成

スマートリファーラルは、ディレクトリーエントリーまたはディレクトリーツリーを特定の LDAP URL にマッピングします。スマートリファーラルを使用すると、クライアントアプリケーションは特定のサーバーまたは特定のサーバーの特定のエントリーを参照できます。

たとえば、クライアントアプリケーションは、ディレクトリーエントリー uid=jdoe,ou=people,dc=example,dc=com を要求します。サーバー directory.europe.example.com のエントリー cn=john doe,o=people,ou=europe,dc=example,dc=com を参照するクライアントにスマートリファーラルが返されます。

ディレクトリーがスマートリファーラルを使用する方法は、RFC 2251 セクション 4.1.11 で指定された標準仕様に準拠します。RFC は、http://www.ietf.org/rfc/rfc2251.txt でダウンロードできます。

2.5.3.1. コマンドラインを使用したスマートリファーラルの作成

スマートリファーラルを作成するには、referral オブジェクトクラスで関連ディレクトリーエントリーを作成し、ref 属性をリファーラル LDAP URL に設定します。

たとえば、ldap://directory.europe.example.com/cn=user,ou=people,ou=europe,dc=example,dc=com を参照する uid=user,ou=people,dc=example,dc=com という名前のスマートカードを作成するには、次のコマンドを実行します。

# ldapadd -D "cn=Directory Manager" -W -p 389 -h server2.example.com -x
dn: uid=user,ou=people,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: referral
sn: user
uid: user
cn: user
ref: ldap://directory.europe.example.com/cn=user,ou=people,ou=europe,dc=example,dc=com

注記

Directory Server は、LDAP URL 領域後の情報を無視します。このため、リファーラルとして使用する LDAP URL 内の領域の代わりに %20 を使用します。

DN パスにすでにリファーラルがある場合は、ldapadd に -M オプションを使用します。スマートリファーラルの詳細は、『Directory Server デプロイメントガイド』を参照してください。

2.5.4. バグ修正参照の作成

以下の手順では、接尾辞 にリファーラルを作成する方法を説明します。これは、接尾辞のプロセスがデータベースまたはデータベースリンクではなく、リファーラルを使用して処理されることを意味します。

警告

リファーラルを返すように接尾辞を設定すると、接尾辞に関連付けられたデータベースに含まれる ACI は無視されます。

2.5.4.1. コマンドラインを使用した接尾辞リファーラルの作成

接尾辞リファーラルを作成するには、以下を実行します。

必要に応じて、ルートまたは従属接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」を参照してください。

接尾辞にリファーラルを追加します。以下に例を示します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix set --add-referral="ldap://directory.example.com/" database_name

2.5.4.2. Web コンソールを使用した接尾辞リファーラルの作成

接尾辞リファーラルを作成するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Database メニューを開きます。
必要に応じて、ルートまたは従属接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」を参照してください。
一覧で接尾辞を選択し、Referrals タブを開きます。
Create Referral をクリックします。
リファーラル URL を作成するために、フィールドに入力します。
Create Referral をクリックします。

2.6. バックエンドデータベースの整合性の確認

dsctl dbverify コマンドを使用すると、管理者はバックエンドデータベースの整合性を検証できます。たとえば、userroot データベースを確認するには、以下のコマンドを実行します。

必要に応じて、インスタンスのバックエンドデータベースをリスト表示します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list
dc=example,dc=com (userroot)
```
後のステップでデータベースの名前が必要になります。
Directory Server インスタンスを停止します。
```
# dsctl instance_name stop
```

データベースを確認します。

# dsctl instance_name dbverify userroot
[04/Feb/2020:13:11:02.453624171 +0100] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000
[04/Feb/2020:13:11:02.465339507 +0100] - WARN - ldbm_instance_add_instance_entry_callback - ldbm instance userroot already exists
[04/Feb/2020:13:11:02.468060144 +0100] - ERR - ldbm_config_read_instance_entries - Failed to add instance entry cn=userroot,cn=ldbm database,cn=plugins,cn=config
[04/Feb/2020:13:11:02.471079045 +0100] - ERR - bdb_config_load_dse_info - failed to read instance entries
[04/Feb/2020:13:11:02.476173304 +0100] - ERR - libdb - BDB0522 Page 0: metadata page corrupted
[04/Feb/2020:13:11:02.481684604 +0100] - ERR - libdb - BDB0523 Page 0: could not check metadata page
[04/Feb/2020:13:11:02.484113053 +0100] - ERR - libdb - /var/lib/dirsrv/slapd-instance_name/db/userroot/entryrdn.db: BDB0090 DB_VERIFY_BAD: Database verification failed
[04/Feb/2020:13:11:02.486449603 +0100] - ERR - dbverify_ext - verify failed(-30970): /var/lib/dirsrv/slapd-instance_name/db/userroot/entryrdn.db
dbverify failed

検証プロセスで問題が報告された場合は、手動で修正するか、バックアップを復元します。
Directory Server インスタンスを起動します。
```
# dsctl instance_name start
```

第3章ディレクトリーエントリーの管理

コマンドラインまたは Web コンソールを使用してディレクトリーエントリーを管理できます。

3.1. コマンドラインを使用したディレクトリーエントリーの管理

コマンドラインを使用して LDAP 操作を実行するには、openldap-clients パッケージをインストールします。このパッケージによりインストールされるユーティリティーを使用すると、以下が可能になります。

新規エントリーの追加
既存のエントリーへの新規属性の追加
既存のエントリーおよび属性の更新
エントリーからエントリーおよび属性を削除します
一括操作の実行

openldap-clients パッケージをインストールするには、以下を実行します。

# yum install openldap-clients

注記

LDAP 操作を実行するには、適切なパーミッションが必要です。アクセス制御の詳細は、18章アクセス制御の管理を参照してください。

3.1.1. ldapadd、ldapmodify、および ldapdelete ユーティリティーへの入力の指定

ディレクトリー内のエントリーまたは属性を追加、更新、または削除する場合は、ユーティリティーのインタラクティブモードを使用して LDAP データ交換形式 (LDIF) ステートメントを入力するか、LDIF ファイルをこれらのファイルに渡します。

LDIF の詳細は、「LDIF ファイルの形式の概要」を参照してください。

3.1.1.1. インタラクティブモードでの入力の提供

インタラクティブモードでは、ldapadd、ldapmodify、および ldapdelete ユーティリティーはコマンドラインから入力を読み取ります。インタラクティブモードを終了するには、Ctrl+D (^D) のキーの組み合わせを押して、end-of-file (EOF) エスケープシーケンスを送信します。

インタラクティブモードでは、ユーティリティーは、Enter を 2 回押したときに、または EOF シーケンスを送信するときに、ステートメントを LDAP サーバーに送信します。

対話型モードを使用します。

ファイルを作成せずに LDIF ステートメントに入るには、次を実行します。
例3.1 ldapmodify インタラクティブモードを使用した LDIF ステートメントの開始
以下の例では、インタラクティブモードで ldapmodify を開始し、telephoneNumber 属性を削除し、cn=manager_name,ou=people,dc=example,dc=com 値を持つ manager 属性を uid=user,ou=people,dc=example,dc=com エントリーに追加します。最後のステートメントの後に Ctrl+D を押して、インタラクティブモードを終了します。
```
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=people,dc=example,dc=com
changetype: modify
delete: telephoneNumber
-
add: manager
manager: cn=manager_name,ou=people,dc=example,dc=com
^D
```
別のコマンドで出力される LDIF ステートメントを Directory Server にリダイレクトするには、次を実行します。
例3.2 リダイレクトされたコンテンツでの ldapmodify インタラクティブモードの使用
以下の例では、command_that_outputs_LDIF コマンドの出力を ldapmodify にリダイレクトします。対話モードは、リダイレクトされたコマンドの終了後に自動的に終了します。
```
# command_that_outputs_LDIF | ldapmodify -D "cn=Directory Manager" \
     -W -p 389 -h server.example.com -x
```

3.1.1.2. LDIF ファイルを使用した入力の提供

インタラクティブモードでは、ldapadd、ldapmodify、および ldapdelete ユーティリティーは、ファイルから LDIF ステートメントを読み取ります。このモードを使用して、多数の LDIF ステートメントを Directory Server に送信します。

例3.3 LDIF ステートメントを持つファイルを ldapmodify に渡す

LDIF ステートメントでファイルを作成します。たとえば、以下のステートメントで ~/example.ldif ファイルを作成します。
```
dn: uid=user,ou=people,dc=example,dc=com
changetype: modify
delete: telephoneNumber
-
add: manager
manager: cn=manager_name,ou=people,dc=example,dc=com
```
この例では、telephoneNumber 属性を削除し、cn=manager_name,ou=people,dc=example,dc=com 値を持つ manager 属性を uid=user,ou=people,dc=example,dc=com エントリーに追加します。

-f file_name オプションを使用して、ファイルを ldapmodify コマンドに渡します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x \
     -f ~/example.ldif

3.1.2. 継続的操作モード

複数の LDIF ステートメントを Directory Server に送信し、1 回の操作に失敗すると、プロセスは停止します。ただし、エラーが発生する前に処理されるエントリーは、正常に追加、変更、または削除されています。

エラーを無視してバッチでさらに LDIF ステートメントの処理を続けるには、-c オプションを ldapadd および ldapmodify に渡します。以下に例を示します。

# ldpamodify -c -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

3.1.3. エントリーの追加

新しいエントリーをディレクトリーに追加するには、ldapadd ユーティリティーまたは ldapmodify ユーティリティーを使用します。ldapadd は /bin/ldapmodify へのシンボリックリンクであることに注意してください。そのため、ldapadd は ldapmodify -a と同じ操作を実行します。

注記

親エントリーがすでに存在する場合のみ、新しいディレクトリーエントリーを追加できます。たとえば、ou=people,dc=example,dc=com の親エントリーが存在しない場合は、cn=user,ou=people,dc=example,dc=com エントリーを追加できません。

3.1.3.1. ldapadd を使用したエントリーの追加

ldapadd ユーティリティーを使用して、たとえば cn=user,ou=people,dc=example,dc=com ユーザーエントリーを追加するには、以下を実行します。

# ldapadd -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
uid: user
givenName: given_name
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: surname
cn: user

注記

ldapadd を実行すると、changetype: add 操作が自動的に実行されます。そのため、LDIF ステートメントで changetype: add を指定する必要はありません。

このコマンドで使用されるパラメーターの詳細は、ldapadd(1) の man ページを参照してください。

3.1.3.2. ldapmodify を使用したエントリーの追加

ldapmodify ユーティリティーを使用して、たとえば cn=user,ou=people,dc=example,dc=com ユーザーエントリーを追加するには、以下を実行します。

# ldapmodify -a -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
uid: user
givenName: given_name
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: surname
cn: user

注記

-a オプションを ldapmodify コマンドに渡すと、ユーティリティーは changetype: add 操作を自動的に実行します。そのため、LDIF ステートメントで changetype: add を指定する必要はありません。

このコマンドで使用されるパラメーターの詳細は、ldapmodify(1) の man ページを参照してください。

3.1.3.3. ルートエントリーの作成

dc=example,dc=com などのデータベース接尾辞のルートエントリーを作成するには、cn=Directory Manager ユーザーとしてバインドし、エントリーを追加します。

DN は、データベースのルートまたは従属接尾辞の DN に対応します。

たとえば、dc=example,dc=com 接尾辞を追加するには、次のコマンドを実行します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: dc=example,dc=com
changetype: add
objectClass: top
objectClass: domain
dc: example

注記

ルートオブジェクトは、接尾辞に 1 つのデータベースがある場合にのみ追加できます。複数のデータベースに保存されている接尾辞を作成する場合は、-n back_end オプションを指定して ldif2db ユーティリティーを使用し、新しいエントリーを保持するデータベースを設定する必要があります。詳細については、「コマンドラインでのインポート」を参照してください。

3.1.4. ディレクトリーエントリーの更新

ディレクトリーエントリーを変更する場合は、changetype: modify ステートメントを使用します。change 操作に応じて、エントリーから属性を追加、変更、または削除できます。

ldapmodify ユーティリティーを使用して、LDIF ステートメントを Directory Server に送信します。たとえば、インタラクティブモードでは、以下のようになります。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

ldapmodify コマンドで使用されるパラメーターの詳細は、ldapmodify(1) の man ページを参照してください。

3.1.4.1. エントリーへの属性の追加

エントリーに属性を追加するには、add 操作を使用します。

たとえば、uid=user,ou=People,dc=example,dc=com エントリーに 555-1234567 の値を持つ telephoneNumber 属性:

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
add: telephoneNumber
telephoneNumber: 555-1234567

属性が多値である場合、属性名を複数回指定して、1 つの操作ですべての値を追加できます。たとえば、uid=user,ou=People,dc=example,dc=com に 2 つの telephoneNumber 属性を同時に追加するには、以下のコマンドを実行します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
add: telephoneNumber
telephoneNumber: 555-1234567
telephoneNumber: 555-7654321

3.1.4.2. 属性の値の更新

属性の値を更新する手順は、属性が単値であるか多値であるかによって異なります。

単値属性の更新

単値属性を更新する場合は、replace 操作を使用して既存の値を上書きします。次のコマンドは、uid=user,ou=People,dc=example,dc=com エントリーの manager 属性:

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
replace: manager
manager: uid=manager_name,ou=People,dc=example,dc=com

多値属性の特定値の更新

多値属性の特定の値を更新するには、最初に置き換えるエントリーを削除してから、新しい値を追加する必要があります。次のコマンドは、uid=user,ou=People,dc=example,dc=com エントリーで現在 555-1234567 に設定されている telephoneNumber 属性:

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
delete: telephoneNumber
telephoneNumber: 555-1234567
-
add: telephoneNumber
telephoneNumber: 555-9876543

3.1.4.3. エントリーからの属性の削除

エントリーから属性を削除するには、delete 操作を実行します。

属性の削除

たとえば、uid=user,ou=People,dc=example,dc=com エントリーの manager 属性:

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
delete: manager

注記

属性に複数の値が含まれる場合、この操作によりすべての値が削除されます。

多値属性から特定の値の削除

多値属性から特定の値を削除する場合は、LDIF ステートメントに属性とその値をリスト表示します。たとえば、uid=user,ou=People,dc=example,dc=com エントリーから 555-1234567 に設定されている telephoneNumber 属性:

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
delete: telephoneNumber
telephoneNumber: 555-1234567

3.1.5. エントリーの削除

エントリーを削除すると、ディレクトリーからエントリーが削除されます。

注記

子エントリーのないエントリーのみを削除できます。たとえば、uid=user,ou=People,dc=example,dc=com エントリーがまだ存在している場合は、ou=People,dc=example,dc=com エントリーを削除できません。

3.1.5.1. ldapdelete を使用したエントリーの削除

ldapdelete ユーティリティーを使用すると、1 つまたは複数のエントリーを削除できます。たとえば、uid=user,ou=People,dc=example,dc=com エントリーを削除するには、次のコマンドを実行します。

# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "uid=user,ou=People,dc=example,dc=com"

1 つの操作で複数のエントリーを削除するには、コマンドに追加します。以下に例を示します。

# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x \
     "uid=user1,ou=People,dc=example,dc=com" \
     "uid=user2,ou=People,dc=example,dc=com"

使用されるパラメーターの詳細は、ldapdelete(1) の man ページを参照してください。

3.1.5.2. ldapmodify を使用したエントリーの削除

ldapmodify ユーティリティーを使用してエントリーを削除するには、changetype: delete 操作を使用します。たとえば、uid=user,ou=People,dc=example,dc=com エントリーを削除するには、次のコマンドを実行します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
changetype: delete

3.1.6. エントリーの名前変更および変更

本セクションでは、エントリーの名前変更または移動の方法を説明します。

注記

moddn アクセス制御リスト (ACL) を使用して、エントリーを移動するパーミッションを付与します。詳細については、「ソースおよび宛先 DN のターゲット」を参照してください。

以下の名前変更操作が存在します。

エントリーの名前変更: エントリーの名前を変更すると、modrdn 操作によってエントリーの相対識別名 (RDN) が変更されます。
サブエントリーの名前変更: サブツリーエントリーの場合、modrdn 操作はサブツリーと子エントリーの DN コンポーネントの名前を変更します。
大規模なサブツリーでは、このプロセスに多くの時間とリソースが必要になる可能性があることに注意してください。
エントリーを新しい親へ移動: サブツリーの名前を変更する同様のアクションは、エントリーをあるサブツリーから別のサブツリーに移動することです。これは、modrdn 操作の拡張タイプで、エントリーの名前を同時に変更し、newSuperior 属性を設定して、エントリーを別の親に移動します。

3.1.6.1. エントリーの名前変更に関する考慮事項

名前変更の操作を実行する場合は、以下の点に留意してください。

root 接尾辞の名前を変更することはできません。
サブツリー名前変更操作によるレプリケーションへの影響は最小限に抑えられます。レプリカ合意は、データベースのサブツリーではなく、データベース全体に適用されます。そのため、サブツリーの名前変更操作ではレプリカ合意の再設定は必要ありません。サブツリーの名前変更操作後のすべての名前の変更は、通常どおり複製されます。
サブツリーの名前を変更し、同期合意を再設定する必要がある場合があります。同期合意は、接尾辞またはサブツリーレベルで設定されます。そのため、サブツリーの名前を変更すると、同期が中断する可能性があります。
サブツリーの名前を変更するには、サブツリーに設定されたサブツリーレベルのアクセス制御命令 (ACI) を手動で再設定し、サブツリーの子エントリーに設定されたエントリーレベルの ACI (エントリーレベルの ACI) を手動で再設定する必要があります。
ou から dc への移行など、サブツリーのコンポーネントを変更しようとすると、スキーマ違反で失敗する可能性があります。たとえば、organizationalUnit オブジェクトクラスには ou 属性が必要です。この属性がサブツリーの名前の一部として削除されると、操作は失敗します。
グループを移動すると、MemberOf プラグインは memberOf 属性を自動的に更新します。ただし、グループが含まれるサブツリーを移動する場合は、cn=memberof task エントリーでタスクを手動で作成するか、fixup-memberof.pl を使用して関連する memberOf 属性を更新する必要があります。
memberOf 属性参照のクリーンアップに関する詳細は、「memberOf 値の再生成」を参照してください。

3.1.6.2. ユーザー、グループ、POSIX グループ、および OU の名前変更

dsidm ユーティリティーは、複数のタイプのオブジェクトの名前を変更できます。

ユーザー:
```
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" user rename current_user_name new_user_name
```
dsidm user rename コマンドは、指定したベース DN の前に ou=People を自動的に配置することに注意してください。
グループ:
```
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" group rename current_group_name new_group_name
```
dsidm group rename コマンドは、指定したベース DN の前に ou=Groups を自動的に配置することに注意してください。
POSIX グループ:
```
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" posixgroup rename current_posix_group_name new_posix_group_name
```
dsidm posixgroup rename コマンドは、指定したベース DN の前に ou=Groups を自動的に配置することに注意してください。
組織単位 (OU)
```
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" organizationalunit rename current_ou_name new_ou_name
```
dsidm organizationalunit rename コマンドは、指定したベース DN で直接名前変更の操作を実行します。

3.1.6.3. LDIF ステートメントを使用してエントリーの名前を変更する際の `deleteOldRDN` パラメーター

エントリーの名前を変更すると、deleteOldRDN パラメーターは古い RDN が削除されるかどうかを制御します。

deleteOldRDN: 0

既存の RDN は、新しいエントリーの値として保持されます。生成されるエントリーには、古い属性と新しい共通名 (CN) を持つ 2 つの cn 属性が含まれます。

たとえば、以下の属性は、deleteOldRDN: 0 パラメーターを設定して、cn=old_group,dc=example,dc=com からcn=new_group,dc=example,dc=com に名前を変更したグループに属しています。

dn: cn=new_group,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: old_group
cn: new_group

deleteOldRDN: 1

Directory Server は古いエントリーを削除し、新しい RDN を使用して新しいエントリーを作成します。新しいエントリーには、新しいエントリーの cn 属性のみが含まれます。

たとえば、以下のグループは、deleteOldRDN: 1 パラメーターを設定して、cn=new_group,dc=example,dc=com に名前を変更しました。

dn: cn=new_group,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupofuniquenames
cn: new_group

3.1.6.4. LDIF ステートメントを使用したエントリーまたはサブツリーの名前変更

エントリーまたはサブツリーの名前変更には、changetype: modrdn 操作を使用し、newrdn 属性に新しい RDN を設定します。

たとえば、cn=demo1,dc=example,dc=com エントリーの名前を cn=example_user,dc=example,dc=com に変更するには、次のようにします。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=example_user,cn=ldap_connect,dc=example,dc=com
changetype: modrdn
newrdn: cn=example_user
deleteOldRDN: 1
newSuperior: dc=example,dc=com

deleteOldRDN の詳細は、「LDIF ステートメントを使用してエントリーの名前を変更する際の deleteOldRDN パラメーター」を参照してください。

3.1.6.5. LDIF ステートメントを使用した新しい親へのエントリーの移動

エントリーを新しい親に移動するには、changetype: modrdn 操作を使用して、以下の属性を設定します。

newrdn: 移動したエントリーの RDN を設定します。RDN が同じままであっても、このエントリーを設定する必要があります。
newSuperior: 新しい親エントリーの DN を設定します。

たとえば、cn=demo エントリーを ou=Germany,dc=example,dc=com から ou=France,dc=example,dc=com に移動するには、以下のコマンドを実行します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=demo,ou=Germany,dc=example,dc=com
changetype: modrdn
newrdn: cn=demo
deleteOldRDN: 1
newSuperior: ou=France,dc=example,dc=com

deleteOldRDN の詳細は、「LDIF ステートメントを使用してエントリーの名前を変更する際の deleteOldRDN パラメーター」を参照してください。

3.1.7. 特殊文字の使用

コマンドラインを使用する場合は、スペース ( )、アスタリスク (*)、バックスラッシュ (\) などのコマンドラインインタープリターに特別な意味を持つ文字を引用符で囲みます。コマンドラインインタープリターに応じて、一重引用符または二重引用符を使用します。

たとえば、cn=Directory Manager ユーザーとして認証するには、ユーザーの DN を引用符で囲みます。

# ldapmodify -a -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

また、DN にコンポーネントのコンマが含まれる場合は、バックスラッシュを使用してエスケープします。たとえば、uid=user,ou=People,dc=example.com Chicago, IL ユーザーとして認証するには、次のコマンドを実行します。

# ldapmodify -a -D "cn=uid=user,ou=People,dc=example.com Chicago\, IL" \
     -W -p 389 -h server.example.com -x

3.1.8. Binary 属性の使用

特定の属性は、jpegPhoto 属性などのバイナリー値をサポートします。このような属性を追加または更新すると、ユーティリティーはファイルから属性の値を読み取ります。このような属性を追加または更新するには、ldapmodify ユーティリティーを使用できます。

たとえば、uid=user,ou=People,dc=example,dc=com エントリーに jpegPhoto 属性を追加し、/home/user_name/photo.jpg ファイルから属性の値を読み取るには、次のコマンドを実行します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
add: jpegPhoto
jpegPhoto:< file:///home/user_name/photo.jpg

重要

: と < の間には、スペースがないことに注意してください。

3.1.9. 国際化されたディレクトリーにおけるエントリーの更新

属性の値を英語以外の言語で使用するには、属性の値を言語タグに関連付けます。

ldapmodify を使用して言語タグが設定されている属性を更新する場合は、値と言語タグを正確に一致させる必要があります。そうでないと、操作は失敗します。

たとえば、lang-fr 言語タグが設定された属性値を変更するには、modify 操作にタグを追加します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
replace: homePostalAddress;lang-fr
homePostalAddress;lang-fr: 34 rue de Seine

3.2. Web コンソールを使用したディレクトリーエントリーの管理

Web コンソールを使用して、LDAP エントリーを追加、編集、削除、および名前の変更を実行できます。

3.2.1. Web コンソールを使用した LDAP エントリーの追加

Web コンソールで LDAP ブラウザーを使用して、ディレクトリーサーバーデータベースのエントリーを検索できます。

Web コンソールを使用して、次のエントリーを作成できます。

ユーザー
グループ
roles
組織単位 (OU)
カスタムエントリー

たとえば、cn=John Smith,ou=people,dc=example,dc=com のパスワードを使用して POSIX ユーザーを作成するとします。

前提条件

ディレクトリーサーバー Web コンソールにログインしている。
親エントリーが存在する。例: ou=people,dc=example,dc=com

手順

Web コンソールで LDAP Browser メニューを開き、既存の接尾辞のリストを表示します。
Tree ビューまたは Table ビューを使用して、ユーザーを作成する親エントリー ou=people,dc=example,dc=com を展開します。
Options メニュー (⫶) をクリックし、New を選択してウィザードウィンドウを開きます。
Create a new User オプションを選択し、Next をクリックします。
ユーザーエントリーで Posix Account タイプを選択し、Next をクリックします。
オプション: userPassword のような追加属性を選択し、Next をクリックします。ステップ名の近くにあるドロップダウンリストを展開すると、選択されたすべての属性を表示できます。
各属性の値を設定します。
1. 属性の鉛筆ボタンをクリックし、値を追加します。
  userPassword 値を設定すると、別のメニューが開くことに注意してください。プレーンテキストを非表示にするために、値にはアスタリスク (*) が入力されます。
2. チェックボタンをクリックして変更を保存します。
3. オプション: Options メニュー (⫶) → Add Another Value をクリックして、追加の属性値を設定します。
4. すべての値を設定したら、Next をクリックします。
エントリーの詳細がすべて正しいことを確認し、Create User をクリックします。ディレクトリーサーバーは、POSIX ユーザーの必須属性を持つエントリーを作成し、それにパスワードを設定します。Back をクリックしてエントリーの設定を変更するか、Cancel をクリックしてエントリーの作成をキャンセルできます。
Result for Entry Creation 表示し、Finish をクリックします。

検証

LDAP Browser → Search に移動します。
エントリーを含むデータベース接尾辞 (例: dc=example,cd=com) を選択します。
検索基準 (例: John) をフィールドに入力し、Enter を押します。
エントリーのリストで最近作成したエントリーを見つけます。

3.2.2. Web コンソールを使用した LDAP エントリーの編集

Web コンソールを使用してディレクトリーエントリーを変更できます。この例では、ユーザーエントリー cn=John Smith,ou=people,dc=example,dc=com を次のとおり変更します。

電話番号 556778987 および 556897445 を追加します。
電子メール jsmith@example.com を追加します。
パスワードを変更します。

前提条件

ディレクトリーサーバー Web コンソールにログインしている。

手順

Web コンソールで LDAP Browser メニューを開き、既存の接尾辞のリストを表示します。
Tree ビューまたは Table ビューを使用して、編集するエントリー (例: cn=John Smith,ou=people,dc=example,dc=com) を展開します。
Options メニュー (⫶) をクリックし、Edit を選択してウィザードウィンドウを開きます。
オプション: Select ObjectClasses の手順で、エントリーのオブジェクトクラスを追加または削除します。Next をクリックします。
Select Attributes の手順で、エントリーに telephoneNumber と mail の属性を追加し、Next をクリックします。エントリーに追加する属性が表示されない場合は、前の手順で対応するオブジェクトクラスを追加していないことを意味します。
注記
この手順では、選択したオブジェクトクラスの必須属性は 削除できません。
Edit Attribute Values の手順で、telephoneNumber を 556778987 および 556897445、mail を jsmith@example.com に設定し、userPassword 値を変更します。
1. 属性の鉛筆ボタンをクリックして、新しい値を追加または変更します。
2. チェックボタンをクリックして変更を保存します。
3. オプション: Options メニュー (⫶) → Add Another Value をクリックして、属性に追加の値を設定します。この例では、telephoneNumber 属性には値が 2 つあります。すべての値を設定したら、Next をクリックします。
変更内容を確認し、Next をクリックします。
エントリーを編集するには、Modify Entry をクリックします。Back をクリックしてエントリーの設定を変更するか、Cancel をクリックしてエントリーの編集をキャンセルできます。
Result for Entry Modification 表示し、Finish をクリックします。

検証

エントリーの詳細を展開し、エントリー属性に表示される新しく変更された内容を確認します。

3.2.3. Web コンソールを使用した LDAP エントリーまたはサブツリーの名前変更と再配置

Web コンソールを使用して、ディレクトリーエントリーまたはサブツリーの名前を変更または再配置できます。この例では、エントリー cn=John Smith,ou=people,dc=example,dc=com の名前と配置を cn=Tom Smith,ou=clients,dc=example,dc=com に変更します。

前提条件

ディレクトリーサーバー Web コンソールにログインしている。

手順

Web コンソールで LDAP Browser メニューを開き、既存の接尾辞のリストを表示します。
Tree ビューまたは Table ビューを使用して、変更するエントリー (例: cn=John Smith,ou=people,dc=example,dc=com) を展開します。
Options メニュー (⫶) をクリックし、Rename を選択してウィザードウィンドウを開きます。
Select The Naming Attribute And Value の手順で以下を実行します。
1. 命名属性 cn に新しい値 Tom Smith を設定し、Next をクリックします。
2. オプション: ドロップダウンメニューから別の命名属性を選択します。
3. オプション: 古いエントリーを削除し、新しい RDN を使用して新規エントリーを作成する場合は、Delete the old RDN をオンにします。
Select The Entry Location の手順で新しい場所の親エントリーを選択し、Next をクリックします。
エントリーに加えた変更を確認し、Next をクリックします。
エントリーの詳細が正しい場合は、Change Entry Name をクリックします。Back をクリックしてエントリーに別の変更を加えるか、Cancel をクリックしてエントリーの変更をキャンセルできます。
Result for Entry Modification を表示し、Finish をクリックします。

検証

エントリーの詳細を展開し、更新されたエントリーを確認します。

3.2.4. Web コンソールを使用した LDAP エントリーの削除

Web コンソールを使用して、ディレクトリーエントリーまたはサブツリーを削除できます。この例では、エントリー cn=Tom Smith,ou=clients,dc=example,dc=com を削除します。

前提条件

ディレクトリーサーバー Web コンソールにログインしている。

手順

Web コンソールで LDAP Browser メニューを開き、既存の接尾辞のリストを表示します。
Tree ビューまたは Table ビューを使用して、削除するエントリー (例: cn=Tom Smith,ou=clients,dc=example,dc=com) を展開します。
Options メニュー (⫶) をクリックし、Delete を選択してウィザードウィンドウを開きます。
削除するエントリーに関するデータを確認し、Next をクリックします。
Deletion の手順でスイッチを Yes, I’m sure の位置に切り替え、Delete をクリックします。Cancel をクリックすると、エントリーの削除をキャンセルできます。
Result for Entry Deletion を表示し、Finish をクリックします。

検証

LDAP Browser → Search に移動します。
前にエントリーが存在していた接尾辞 (例: dc=example,cd=com) を選択します。
検索基準 (例: Tom) をフィールドに入力し、Enter を押します。
削除されたエントリーが存在しないことを確認します。

第4章ディレクトリーエントリーの変更の追跡

特定の状況では、エントリーに変更が加えられるタイミングを追跡すると便利です。Directory Server が追跡するエントリーの変更には、以下の 2 つの側面があります。

変更シーケンス番号を使用してデータベースへの変更を追跡します。これは、レプリケーションおよび同期で使用されるシーケンス番号の変更に類似しています。通常のディレクトリー操作はすべて、シーケンス番号がトリガーされます。
作成および変更の情報を割り当てます。これらの属性は、エントリーを作成して直近に変更したユーザーの名前と、エントリーの作成および修正時のタイムスタンプを記録します。

注記

エントリー更新シーケンス番号 (USN)、時間および名前の変更、および時間および作成はすべて操作属性であり、通常の ldapsearch では返されません。操作属性の検索実行に関する詳細は、「操作属性の検索」を参照してください。

4.1. 更新シーケンス番号でデータベースへの変更の追跡

USN プラグインにより、エントリーが変更されたかどうかを LDAP クライアントおよびサーバーが特定できるようになります。

4.1.1. エントリーシーケンス番号の概要

USN プラグインが有効な場合は、エントリーに対して書き込み操作を実行するたびに、エントリーに割り当てられるシーケンス番号 (USN) を更新します。書き込み操作には、add、modify、modrdn、および delete 操作が含まれます。エクスポート操作などの内部データベース操作は、更新シーケンスでカウントされません。 USN カウンターは、最近割り当てられた USN を追跡します。

4.1.1.1. ローカルおよびグローバルの USN

USN は、単一のエントリーではなく、データベース全体に対してグローバルに評価されます。USN は、データベースまたはディレクトリーの変更を追跡するために単に上向きにチェックするという点で、レプリケーションと同期の変更シーケンス番号に似ています。ただし、エントリー USN は CSN と別個に維持され、USN は複製されません。

このエントリーには、entryUSN 操作属性のエントリーへの最後の変更の変更番号が表示されます。操作属性の詳細は、「操作属性の検索」を参照してください。

例4.1 エントリー USN の例

uid=example,ou=People,dc=example,dc=com ユーザーエントリーの entryusn 属性を表示するには、以下のコマンドを実行します。

# ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com:389 -x -b "uid=example,ou=People,dc=example,dc=com" -s base -x entryusn

dn: uid=example,ou=People,dc=example,dc=com
entryusn: 17653

USN プラグインには、ローカルモードとグローバルモードという 2 つのモードがあります。

ローカルモードでは、各バックエンドデータベースには、そのバックエンドデータベースに固有の USN カウンターを持つ USN プラグインのインスタンスがあります。これはデフォルト設定です。
グローバルモードでは、ディレクトリー全体に追加された変更に適用されるグローバル USN カウンターを使用する USN プラグインのグローバルインスタンスがあります。

USN プラグインをローカルモードに設定すると、結果はローカルのバックエンドデータベースに限定されます。USN プラグインをグローバルモードに設定すると、返される結果はディレクトリー全体に対して行われます。

ルート DSE は、lastusn 属性のデータベースのエントリーに割り当てられた最新の USN を表示します。USN プラグインがローカルモードに設定されているため、各データベースに独自のローカル USN カウンターがある場合、lastUSN は、USN が割り当てられているデータベースと、USN の両方を表示します。

lastusn;database_name:USN

以下に例を示します。

lastusn;example1: 2130
lastusn;example2: 2070

グローバルモードでは、データベースが共有 USN カウンターを使用する場合、lastUSN 属性は最新の USN のみを表示します。

lastusn: 4200

4.1.1.2. USN エントリーのインポート

エントリーがインポートされると、USN プラグインは nsslapd-entryusn-import-initval 属性を使用して、エントリーに USN が割り当てられているかどうかを確認します。nsslapd-entryusn-import-initval の値が数値である場合、インポートされたエントリーはこの数字をエントリーの USN として使用します。nsslapd-entryusn-import-initval の値が数値でない場合、USN プラグインは lastUSN 属性の値を使用して、インポートしたエントリーの USN で増やします。

4.1.2. USN プラグインの有効化

本セクションでは、USN プラグインがエントリーに USN を記録できるようにする方法を説明します。

4.1.2.1. コマンドラインで USN プラグインの有効化

コマンドラインを使用して USN プラグインを有効にするには、以下を実行します。

dsconf ユーティリティーを使用してプラグインを有効にします。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin usn enable
```
インスタンスを再起動します。
```
# dsctl instance_name restart
```

4.1.2.2. Web コンソールを使用した USN プラグインの有効化

Web コンソールを使用して USN プラグインを有効にするには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを選択します。
USN プラグインを選択します。
ステータスを ON に変更し、プラグインを有効にします。
インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。

4.1.3. グローバルの USN

デフォルト設定では、Directory Server は各バックエンドデータベースに一意の更新シーケンス番号 (USN) を使用します。あるいは、すべてのバックエンドデータベースで一意の USN を有効にすることができます。

注記

この機能を使用するには、USN プラグインを有効にする必要があります。「USN プラグインの有効化」を参照してください。

4.1.3.1. グローバル USN が有効になっているかどうかの特定

本セクションでは、すべてのバックエンドデータベースで USN を有効にするかどうかを特定する方法を説明します。

4.1.3.1.1. コマンドラインでグローバル USN が有効になっているかどうかの特定

コマンドラインを使用して、グローバル USN 機能の現在のステータスを表示するには、次のコマンドを実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin usn global
USN global mode is disabled

4.1.3.1.2. Web コンソールを使用してグローバル USN が有効になっているかどうかの特定

Web コンソールを使用してグローバル USN 機能の現在のステータスを表示するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを選択します。
USN プラグインを選択します。
USN Global スイッチが On に設定されていることを確認します。

4.1.3.2. グローバル USN の有効化

4.1.3.2.1. コマンドラインでグローバル USN の有効化

コマンドラインを使用してグローバル USN を有効にするには、以下を実行します。

グローバル USN を有効にします。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin usn global on

インスタンスを再起動します。
```
# dsctl instance_name restart
```

4.1.3.2.2. Web コンソールを使用したグローバル USN の有効化

Web コンソールを使用してグローバル USN を有効にするには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを開きます。
USN プラグインを選択します。
プラグインのステータスを On に変更します。
USN Global ステータスを On に変更します。
インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。

4.1.4. USN Tombstone エントリーのクリーンアップ

エントリーが削除されると、USN プラグインは、エントリーを tombstone エントリーに移動します。レプリケーションが有効な場合は、USN および Replication プラグインによって個別の tombstone エントリーが保持されます。tombstone エントリーはレプリケーションプロセスで削除されますが、サーバーのパフォーマンスには、USN tombstones を削除することが有益です。

サーバーをレプリカに変換する前に
サーバーのメモリーを解放する

4.1.4.1. コマンドラインを使用した USN tombstone エントリーのクリーンアップ

コマンドラインで、dc=example,dc=com 接尾辞から USN tombstone エントリーをすべて削除するには、次のコマンドを実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin usn cleanup -s "dc=example,dc=com"

必要に応じて、-o max_USN オプションをコマンドに渡して、指定した値まで USN tombstone エントリーを削除します。

4.1.4.2. Web コンソールを使用した USN tombstone エントリーのクリーンアップ

Web コンソールを使用して、dc=example,dc=com 接尾辞からすべての USN tombstone エントリーを削除するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを開きます。
USN プラグインを選択します。
Run Fixup Task ボタンをクリックします。
フィールドを入力し、Run を押します。

4.2. 操作属性によるエントリー変更の追跡

デフォルト設定を使用すると、Directory Server は、全エントリーで以下の操作属性を追跡します。

creatorsName: エントリーを最初に作成したユーザーの識別名 (DN) です。
createTimestamp: エントリーの作成時にグリニッジ標準時 (GMT) 形式のタイムスタンプ。
modifiersName: エントリーを最後に変更したユーザーの識別名。
modifyTimestamp: エントリーが最後に修正された時点の GMT 形式のタイムスタンプ。

デフォルトの検索では操作属性が返されないことに注意してください。これらの属性はクエリーで明示的に要求する必要があります。詳細については、「操作属性の検索」を参照してください。

重要

これらの操作属性の追跡は、無効にしないことが推奨されます。無効にすると、エントリーは nsUniqueID 属性に割り当てられた一意の ID を取得しなくなり、レプリケーションは機能しません。

4.2.1. データベースリンクにより変更されたエントリーまたは作成済みエントリー

データベースリンク上でエントリーが作成または変更されると、creatorsName および modifiersName 属性には、リモートサーバーのプロキシー認可権限を付与されたユーザー名が含まれます。この場合、属性はエントリーの元の作成者または最新の変更者を表示しません。ただし、アクセスログには、プロキシーユーザー (dn) と元のユーザー (authzid) の両方が表示されます。以下に例を示します。

[23/May/2018:18:13:56.145747965 +051800] conn=1175 op=0 BIND dn="cn=proxy admin,ou=People,dc=example,dc=com" method=128 version=3
[23/May/2018:18:13:56.575439751 +051800] conn=1175 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=proxy admin,ou=people,dc=example,dc=com"
[23/May/2018:18:13:56.744359706 +051800] conn=1175 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(objectClass=*)" attrs=ALL authzid="uid=user_name,ou=People,dc=example,dc=com"

4.2.2. 変更のトラッキングの有効化

デフォルトでは、Directory Server は操作属性の変更を追跡します。

注記

Red Hat は、この機能を無効にしないことが推奨されます。

本セクションでは、この機能を無効にした場合は変更の追跡を再度有効にする方法を説明します。

4.2.2.1. コマンドラインを使用した変更の追跡の有効化

コマンドラインでエントリー変更の追跡を再度有効にするには、次のコマンドを実行します。

nsslapd-lastmod パラメーターを on に設定します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-lastmod=on

必要に応じて、不足している nsUniqueID 属性を再生成するには、以下を実行します。
1. データベースを LDAP データ交換形式 (LDIF) ファイルにエクスポートします。「コマンドラインを使用した LDIF ファイルへのデータのエクスポート」を参照してください。
2. LDIF ファイルからデータベースをインポートします。「コマンドラインでのインポート」を参照してください。

4.3. プラグイン開始更新のバインド DN の追跡

エントリーへの変更の 1 つで、ディレクトリーツリー全体で、他の自動変更をトリガーすることができます。たとえば、ユーザーが削除されると、そのユーザーは Referential Integrity Postoperation プラグインが属するグループから自動的に削除されます。

最初のアクションは、サーバーにバインドされているユーザーアカウントによって実行されているものとしてエントリーに表示されますが、関連するすべての更新 (デフォルト) はプラグインによって実行されているものとして表示され、どのユーザーがその更新を開始したかについての情報はありません。たとえば、MemberOf プラグインを使用してグループメンバーシップでユーザーエントリーを更新し、グループアカウントの更新はバインドされたユーザーが実行済みとして表示されますが、ユーザーエントリーの編集は MemberOf プラグインによって実行されると表示されます。

dn: cn=example_group,ou=groups,dc=example,dc=com
modifiersname: uid=example,ou=people,dc=example,dc=com

dn: uid=example,ou=people,dc=example,dc=com
modifiersname: cn=memberOf plugin,cn=plugins,cn=config

nsslapd-plugin-binddn-tracking パラメーターにより、サーバーは、更新操作を開始したユーザーと、実際に実行した内部プラグインを追跡できます。バインドされたユーザーは modifiersname 操作属性および creatorsname 操作属性に表示されますが、実行されたプラグインは internalModifiersname 操作属性および internalCreatorsname 操作属性に表示されます。以下に例を示します。

dn: uid=example,ou=people,dc=example,dc=com
modifiersname: uid=admin,ou=people,dc=example,dc=com
internalModifiersname: cn=memberOf plugin,cn=plugins,cn=config

nsslapd-plugin-binddn-tracking パラメーターは、バインドされたユーザーと、その接続に対して実行される更新の関係を追跡し、維持します。

注記

internalModifiersname 属性および internalCreatorsname 属性は、常にプラグインをアイデンティティーとして表示します。このプラグインは、MemberOf プラグインなどの追加のプラグインである可能性があります。コア Directory Server により変更が加えられると、プラグインはデータベースプラグイン (cn=ldbm database,cn=plugins,cn=config) になります。

4.3.1. コマンドラインで開始した更新のバインド DN の追跡の有効化

コマンドラインを使用して、プラグインを開始する更新のバインド DN の追跡を有効にするには、以下を実行します。

nsslapd-plugin-binddn-tracking パラメーターを on に設定します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-plugin-binddn-tracking=on

インスタンスを再起動します。
```
# dsctl instance_name restart
```

4.3.2. Web コンソールを使用したプラグイン開始の更新のバインド DN の追跡の有効化

Web コンソールを使用して、プラグインを開始する更新のバインド DN の追跡を有効にするには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Server Settings メニューを開き、Server Settings エントリーを選択します。
Advanced Settings タブで Enable Plugin Bind DN Tracking を選択します。
Save をクリックします。
インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。

4.4. パスワード変更時間の追跡

パスワードの変更操作は、通常、エントリーに対するその他の変更として扱われるため、更新時間は lastModified 操作属性に記録されます。ただし、Active Directory 同期におけるパスワードの更新や、他の LDAP クライアントへの接続を容易にするため、パスワード変更の時間は別々に記録しないといけない場合があります。

パスワードポリシー内の passwordTrackUpdateTime 属性は、エントリーのパスワードが最後に更新された日時のタイムスタンプを記録するようサーバーに指示します。パスワードの変更時間はユーザーエントリーで pwdUpdateTime 操作属性 (modifyTimestamp または lastModified 操作属性とは別) として保存されます。

passwordTrackUpdateTime 属性は、パスワード変更時間にアクセスする必要があるクライアントに応じて、グローバルパスワードポリシー、サブツリー、またはユーザーレベルのポリシーの一部として設定できます。パスワードポリシーの設定は、「パスワードポリシーの管理」を参照してください。

第5章参照整合性の維持

参照整合性 は、関連するエントリー間の関係を維持するデータベースメカニズムです。Directory Server では、参照整合性を使用して、ディレクトリー内の 1 つのエントリーへの更新が、更新されたエントリーを参照するその他のエントリーに適切に反映されるようにします。

たとえば、ユーザーのエントリーがディレクトリーから削除され、参照整合性が有効になると、サーバーはユーザーがメンバーとなるグループからユーザーも削除します。参照整合性が有効になっていないと、ユーザーは管理者が手動で削除するまでグループのメンバーのままになります。これは、ユーザーおよびグループの管理のディレクトリーに依存する他の製品と Directory Server を統合する場合に重要な機能です。

5.1. 参照整合性の仕組み

Referential Integrity Postoperation プラグインを有効にすると、削除または名前変更の操作直後に、指定した属性で整合性の更新を実行します。デフォルトでは、Referential Integrity Postoperation プラグインは無効になっています。

注記

マルチサプライヤーレプリケーション環境では、すべてのサプライヤーで Referential Integrity Postoperation プラグインを有効にする必要があります。

ディレクトリー内のユーザーまたはグループエントリーを削除、名前変更、または移動すると、その操作は Referential Integrity ログファイルに記録されます。ログファイル内の識別名 (DN) の場合、Directory Server はプラグイン設定に設定された属性を定期的に検索および更新します。

エントリーの場合は、ログファイルで削除済みと表示され、ディレクトリーの対応する属性が削除されます。
エントリーの場合は、ログファイルで名前が変更または移動済みと表示され、ディレクトリーの対応する属性の名前が変わります。

デフォルトでは、Referential Integrity Postoperation プラグインを有効にすると、削除または 名前変更 操作の直後に member、uniquemember、owner、およびseeAlso 属性の整合性更新が実行されます。ただし、Referential Integrity Postoperation プラグインの動作は、ディレクトリーのニーズに応じて複数の方法で設定できます。

レプリケーション変更ログに整合性の更新を記録します。
更新間隔を変更します。
参照整合性を適用する属性を選択します。
参照整合性を無効にします。

参照整合性で使用される属性はすべて存在、等価性、従属文字列のために、必ずインデックス化する必要があります。これらの属性をインデックス化しないと、変更操作および削除操作のためにサーバーのパフォーマンスが低下します。

nsIndexType: pres
nsIndexType: eq
nsIndexType: sub

インデックスの確認および作成に関する詳細は、「標準インデックスの作成」を参照してください。

5.2. レプリケーションによる参照整合性の使用

レプリケーション環境で Referential Integrity Postoperation プラグインを使用する場合は、特定の制限があります。

専用のコンシューマーサーバー (読み取り専用レプリカのみが含まれるサーバー) では有効に しないでください。
読み書きレプリカと読み取り専用レプリカの組み合わせが含まれるサーバーで有効に しないでください。
読み取り/書き込みレプリカのみを含むサプライヤーサーバーで有効にします。
マルチサプライヤーレプリケーショントポロジーの各サプライヤーサーバーに対してプラグインを有効にします。プラグイン設定は、すべてのサプライヤーサーバーで同じである必要があります。

注記

サプライヤーサーバーが Referential Integrity Postoperation プラグインの変更をコンシューマーサーバーに送信するため、コンシューマーサーバーとハブサーバーで Referential Integrity Postoperation プラグインを実行する必要はありません。

5.3. 参照整合性の有効化

このセクションでは、Referential Integrity Postoperation プラグインを有効にする方法を説明します。

5.3.1. コマンドラインを使用した参照整合性の有効化

コマンドラインを使用して Referential Integrity Postoperation プラグインを有効にするには、以下を実行します。

dsconf ユーティリティーを使用してプラグインを有効にします。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity enable

インスタンスを再起動します。
```
# dsctl instance_name restart
```

5.3.2. Web コンソールを使用した参照整合性の有効化

Web コンソールを使用して Referential Integrity プラグインを有効にするには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを選択します。
Referential Integrity プラグインを選択し、Show Advanced Settings をクリックします。
ステータスを ON に変更し、プラグインを有効にします。

5.4. 参照整合性の更新間隔

デフォルトでは、サーバーは、削除または 名前変更 操作の直後に Referential Integrity の更新を実行します。操作の量によっては、パフォーマンスに影響する可能性があります。パフォーマンスへの影響を軽減するために、更新間の時間を増やすことができます。

更新間隔を秒単位で設定できます。あるいは、以下の値を設定できます。

0: 参照整合性の確認は即座に実行されます。
-1: 参照整合性の確認は実行されません。

重要

マルチサプライヤーのレプリケーション環境では、Red Hat はすべてのサプライヤーで更新間隔を 0 に設定することを推奨しています。

注記

サプライヤーで間隔を 0 より大きい値 (たとえば 5) に設定すると、サプライヤーが直接の削除または 名前変更 操作を受け取り、その操作を複製して、ターゲットエントリーへの参照をクリーンアップする前に オフライン になる可能性があります。このような場合、トポロジーの残りの部分には、サーバーが再び稼働するまで (おそらく 5 秒超) ターゲットエントリーへの参照が含まれます。

5.4.1. コマンドラインを使用した更新間隔の表示

コマンドラインを使用して更新間隔を表示するには、以下を行います。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity show
referint-update-delay: 0
...

5.4.2. Web コンソールを使用した更新間隔の表示

Web コンソールを使用して更新間隔を表示するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを開きます。
Referential Integrity プラグインを選択します。
更新間隔については、Update Delay フィールドを参照してください。

5.4.3. コマンドラインを使用した更新間隔の変更

たとえば、コマンドラインを使用して更新間隔を即座更新に設定するには、次を実行します。

更新間隔を 0 に設定します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --update-delay=0

インスタンスを再起動します。
```
# dsctl instance_name restart
```

5.4.4. Web コンソールを使用した更新間隔の変更

たとえば、Web コンソールを使用して更新間隔を即座更新に設定するには、次を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを開きます。
Referential Integrity プラグインを選択します。
Update Delay フィールドに間隔を設定します。
Save Config を押します。
インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。

5.5. 属性リストの表示および修正

デフォルトでは、参照整合性プラグインは member 属性、uniquemember 属性、owner 属性、および seeAlso 属性を確認し、更新します。コマンドラインまたは Web コンソールを使用して、更新する属性を追加または削除できます。

注記

Referential Integrity プラグインのパラメーターリストに設定される属性には、全データベースで等価インデックスが必要です。そうでない場合、プラグインは削除済みまたは変更された DN に一致するためにデータベースのすべてのエントリーをスキャンします。これにより、パフォーマンスに大きく影響する可能性があります。インデックスの確認および作成に関する詳細は、「標準インデックスの作成」を参照してください。

5.5.1. コマンドラインを使用した属性リストの表示

コマンドラインを使用して属性リストを表示するには、以下を実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity show

5.5.2. Web コンソールを使用した属性リストの表示

Web コンソールを使用して属性リストを表示するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを開きます。
Referential Integrity プラグインを選択します。
属性のリストは、Membership Attribute フィールドを参照してください。

5.5.3. コマンドラインで属性リストの設定

コマンドラインを使用して属性リストを更新するには、以下を実行します。

必要に応じて、属性の現在のリストを表示します。「コマンドラインを使用した属性リストの表示」を参照してください。
属性リストを更新します。
- プラグインが確認および更新される必要がある属性リストを設定するには、以下を実行します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --membership-attr attribute_name_1 attribute_name_2
```
- プラグインで確認および更新されなくなった属性をすべて削除するには、以下を実行します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --membership-attr delete
```
インスタンスを再起動します。
```
# dsctl instance_name restart
```

5.5.4. Web コンソールを使用した属性リストの設定

Web コンソールを使用して属性リストを更新するには、以下を行います。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを開きます。
Referential Integrity プラグインを選択します。
Membership Attribute フィールドを更新して、属性を設定します。
- 属性を追加するには、Membership Attribute フィールドに名前を入力します。
- 属性を削除するには、Membership Attribute フィールドの属性名の横にある X ボタンをクリックします。
Save Config を押します。

5.6. 参照整合性のためのスコープの設定

エントリーを削除すると、エントリーへの参照は削除または変更されます。この更新がすべてのエントリーおよびすべてのグループに適用されると、パフォーマンスに影響が及ぶ可能性があり、選択されたサブツリーに参照整合性を制限できなくなる可能性があります。この問題の スコープ アドレスを定義します。

たとえば、接尾辞 dc=example,dc=com に ou=active users,dc=example,dc=com と ou=deleted users,dc=example,dc=com の 2 つのサブツリーが含まれる場合があります。deleted users のエントリーは、参照整合性の確保のために処理しないでください。

5.6.1. 参照整合性の範囲を制御するパラメーター

Referential Integrity Postoperation プラグイン設定でスコープを定義するために、以下の 3 つのパラメーターを使用することができます。

nsslapd-pluginEntryScope: この多値パラメーターは、削除または名前変更のエントリーの範囲を制御します。これは、Referential Integrity Postoperation プラグインがユーザーエントリーの削除操作または名前変更操作を検索するサブツリーを定義します。定義されたサブツリーに存在しないユーザーを削除または名前変更した場合、プラグインは操作を無視します。このパラメーターを使用すると、プラグインが操作を適用するデータベースのブランチを指定できます。
nsslapd-pluginExcludeEntryScope: このパラメーターは、削除または名前変更のエントリーの範囲も制御します。これは、Referential Integrity Postoperation プラグインがユーザーの削除や名前変更の操作を無視するサブツリーを定義します。
nsslapd-pluginContainerScope: このパラメーターは、参照を更新するグループのスコープを制御します。ユーザーの削除後、Referential Integrity Postoperation プラグインはユーザーが属するグループを検索し、それに応じて更新します。このパラメーターは、プラグインがユーザーが属するグループを検索するブランチを指定します。Referential Integrity Postoperation プラグインは、指定のコンテナーブランチにあるグループのみを更新し、その他のグループは更新されないままにします。

5.6.2. コマンドラインを使用した参照整合性範囲の表示

以下のコマンドは、コマンドラインを使用してスコープ設定を表示する方法を示しています。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity show
...
nsslapd-pluginEntryScope: DN
nsslapd-pluginExcludeEntryScope: DN
nsslapd-pluginContainerScope: DN

5.6.3. Web コンソールを使用した参照整合性範囲の表示

以下の手順では、Web コンソールを使用してスコープ設定を表示する方法を説明します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを開きます。
Referential Integrity プラグインを選択します。
現在設定されているスコープについては、Entry Scope フィールド、Exclude Entry Scope フィールド、および Container Scope フィールドを参照してください。

5.6.4. コマンドラインを使用した参照整合性範囲の設定

コマンドラインを使用して参照整合性の範囲を設定するには、次のコマンドを実行します。

必要に応じて、スコープ設定を表示します。「コマンドラインを使用した参照整合性範囲の表示」を参照してください。
以下のコマンドは、コマンドラインを使用して個別の参照整合性スコープを設定する方法を示しています。
- 識別名 (DN) を設定するには、以下を実行します。
  - nsslapd-pluginEntryScope パラメーターに対して以下を実行します。
    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --entry-scope="DN"
  - nsslapd-pluginExcludeEntryScope パラメーターに対して以下を実行します。
    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --exclude-entry-scope="DN"
  - nsslapd-pluginContainerScope パラメーターに対して以下を実行します。
    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --container-scope="DN"
- DN を削除するには、以下を実行します。
  - nsslapd-pluginEntryScope パラメーターから、以下を行います。
    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --entry-scope=delete
  - nsslapd-pluginExcludeEntryScope パラメーターから、以下を行います。
    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --exclude-entry-scope=delete
  - nsslapd-pluginContainerScope パラメーターから、以下を行います。
    # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --container-scope=delete
インスタンスを再起動します。
```
# dsctl instance_name restart
```

5.6.5. Web コンソールを使用した参照整合性範囲の設定

Web コンソールを使用して参照整合性スコープを設定するには、以下を行います。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを選択します。
Referential Integrity プラグインを選択します。
Entry Scope フィールド、Exclude Entry Scope フィールドおよび Container Scope フィールドにスコープを設定します。
Save Config をクリックします。

第6章 Directory Database への入力

データベースには、Red Hat Directory Server が管理するディレクトリーデータが含まれます。

6.1. データのインポート

Directory Server には、以下を行ってデータベースにデータを入力できます。

データのインポート
重要
データをインポートするには、インポートする LDIF ファイルを /var/lib/dirsrv/slapd-instance_name/ldif/ ディレクトリーに保存する必要があります。Directory Server はデフォルトで PrivateTmp systemd ディレクティブを使用します。そのため、LDIF ファイルを /tmp/ または /var/tmp/ システムディレクトリーにエクスポートすると、Directory Server はインポート中にこれらの LDIF ファイルを認識しません。PrivateTmp の詳細は、systemd.exec(5) の man ページを参照してください。
レプリケーションのデータベースの初期化

次の表に、データベースのインポートと初期化の違いを示します。

表6.1 インポート方法の比較

動作	インポート	データベースの初期化
データベースの上書き	いいえ	はい
LDAP 操作	追加、変更、削除	追加のみ
パフォーマンス	より時間がかかる	速い
パーティション特長	すべてのパーティションで機能	ローカルパーティションのみ
サーバー障害への応答	ベストエフォート (障害が発生した時点までに行われたすべての変更が残る)	アトミック (障害発生後にすべての変更が失われる)
LDIF ファイルの場所	Web コンソールへのローカル	Web コンソールまたはローカルサーバーへのローカル
設定情報 (cn=config) をインポートする	はい	いいえ

6.1.1. インポート中の EntryUSN 初期値の設定

エントリーがサーバーからエクスポートされ、別のサーバーにインポートされた場合には、エントリーの更新シーケンス番号 (USN) が保持されません。「更新シーケンス番号でデータベースへの変更の追跡」で説明されているように、エントリー USN はローカルサーバーで発生する操作に割り当てられるため、これらの USN を別のサーバーにインポートすることは意味がありません。

ただし、データベースのインポート時やデータベースの初期化時にエントリーに USN 値を設定することが可能です (レプリカがレプリケーションに対して初期化される場合など)。これは、nsslapd-entryusn-import-initval パラメーターを設定します。これにより、インポートされたすべてのエントリーの USN が開始されます。

nsslapd-entryusn-import-initval には 2 つの値を指定することができます。

整数。インポートされたすべてのエントリーに使用される明示的な開始番号です。
next。つまり、インポートされたエントリーはすべて、インポート操作の前にサーバー上にあった最大のエントリー USN 値を、1 つずつインクリメントして使用します。

nsslapd-entryusn-import-initval が設定されていない場合、すべてのエントリー USN はゼロで始まります。

例6.1 nsslapd-entryusn-import-initval パラメーターの仕組み

たとえば、インポートまたは初期化操作の前にサーバーの最大値が 1000 で、nsslapd-entryusn-import-initval の値が next の場合、インポートされたすべてのエントリーには 1001 の USN が割り当てられます。

# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "(cn=*)" entryusn

dn: dc=example,dc=com
entryusn: 1001
dn: ou=Accounting,dc=example,dc=com
entryusn: 1001
dn: ou=Product Development,dc=example,dc=com
entryusn: 1001
...
dn: uid=user_name,ou=people,dc=example,dc=com
entryusn: 1001
...

エントリー USN の初期値を設定するには、nsslapd-entryusn-import-initval パラメーターを、データをインポートするサーバーまたは初期化を実行するサプライヤーサーバーに追加します。以下に例を示します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-entryusn-import-initval=next

注記

マルチサプライヤーレプリケーションでは、nsslapd-entryusn-import-initval パラメーターはサーバー間で複製 されません。つまり、値は、レプリカの初期化に使用しているすべてのサプライヤーサーバーに対して設定する必要があります。

たとえば、Supplier1 ホストの nsslapd-entryusn-import-initval が next に設定され、レプリカの初期化に使用される場合は、インポートされたエントリーのエントリー USN は最も高い値に 1 が追加されます。Supplier2 ホストに nsslapd-entryusn-import-initval が設定されておらず、レプリカの初期化に使用される場合は、Supplier1 および Supplier2 にマルチサプライヤーレプリカ合意がある場合でも、インポートされたエントリーのすべてのエントリー USN はゼロで始まります。

6.1.2. コマンドラインでのインポート

Directory Server は、インスタンスの実行中またはオフライン時にデータのインポートをサポートします。

インスタンスが実行している場合には、以下のいずれかの方法を使用します。
- dsconf backend import コマンドを使用します。「dsconf backend import コマンドを使用したインポート」を参照してください。
- cn=tasks エントリーを作成します。「cn=tasks エントリーを使用したデータのインポート」を参照してください。
インスタンスがオフラインの場合は、dsctl ldif2db コマンドを使用します。「サーバーがオフライン時のデータのインポート」を参照してください。

警告

インポート操作を開始すると、Directory Server はまずデータベースから既存のデータをすべて削除し、その後 LDIF ファイルからデータをインポートします。LDIF ファイルが存在しない場合など、インポートに失敗すると、サーバーは以前のデータをデータベースから削除しています。

インポート操作に使用される LDIF ファイルは、UTF-8 文字セットエンコーディングを使用する必要があります。インポート操作は、データをローカル文字セットエンコーディングから UTF-8 に変換しません。また、インポートされたすべての LDIF ファイルにルート接尾辞エントリーが含まれている必要があります。

Directory Server は、dirsrv ユーザーとしてインポート操作を実行します。したがって、LDIF ファイルのパーミッションにより、このユーザーがファイルの読み取りを許可する必要があります。

6.1.2.1. サーバーの実行中にデータのインポート

本セクションでは、Directory Server の実行中にデータをインポートする方法を説明します。

6.1.2.1.1. dsconf backend import コマンドを使用したインポート

dsconf backend import コマンドを使用して、LDIF ファイルからデータをインポートするタスクを自動的に作成します。たとえば、/var/lib/dirsrv/slapd-instance_name/ldif/instance_name-database_name-time_stamp.ldif ファイルを userRoot データベースにインポートするには、以下のコマンドを実行します。

接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」を参照してください。
インポートする LDIF に接尾辞エントリーを追加するステートメントが含まれていない場合は、「ルートエントリーの作成」で説明されているように、このエントリーを手動で作成します。

LDIF ファイルをインポートします。

# dsconf -D "cn=Directory Manager" ldap://server.example.com backend import userRoot /var/lib/dirsrv/slapd-instance_name/ldif/instance_name-database_name-time_stamp.ldif
The import task has finished successfully

dsconf backend import コマンドは、特定の接尾辞を除外するなど、追加オプションに対応します。利用可能なオプションをすべて表示するには、以下を入力します。

# dsconf ldap://server.example.com backend import --help

6.1.2.1.2. cn=tasks エントリーを使用したデータのインポート

Directory Server 設定の cn=tasks,cn=config エントリーは、サーバーがタスクの管理に使用する一時的なエントリー用のコンテナーエントリーです。インポート操作を開始するには、cn=import,cn=tasks,cn=config エントリーにタスクを作成します。

インポートタスクエントリーには以下の属性が必要です。

cn: タスクの一意の名前を設定します。
nsFilename: インポートする LDIF ファイルの名前を設定します。
nsInstance: ファイルをインポートするデータベースの名前を設定します。

インポートタスクは、接尾辞を除外するための追加パラメーターをサポートします。完全な一覧は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』の『cn=import』セクションを参照してください。

たとえば、/var/lib/dirsrv/slapd-instance_name/ldif/example.ldif ファイルの内容を userRoot データベースにインポートするタスクを追加するには:

接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」を参照してください。
インポートする LDIF に接尾辞エントリーを追加するステートメントが含まれていない場合は、「ルートエントリーの作成」で説明されているように、このエントリーを手動で作成します。

インポートタスクを追加します。

# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x

dn: cn=example_import,cn=import,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn: example_import
nsFilename: /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif
nsInstance: userRoot

タスクが完了すると、エントリーはディレクトリー設定から削除されます。

6.1.2.2. サーバーがオフライン時のデータのインポート

データのインポート時にサーバーがオフラインの場合は、dsctl ldif2db コマンドを使用します。

接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」を参照してください。
インポートする LDIF に接尾辞エントリーを追加するステートメントが含まれていない場合は、「ルートエントリーの作成」で説明されているように、このエントリーを手動で作成します。
インスタンスを停止します。
```
# dsctl instance_name stop
```
LDIF ファイルからデータをインポートします。たとえば、/var/lib/dirsrv/slapd-instance_name/ldif/example.ldif ファイルを userRoot データベースにインポートするには、以下を実行します。
```
# dsctl instance_name ldif2db userroot /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif 
OK group dirsrv exists
OK user dirsrv exists
[17/Jul/2018:13:42:42.015554231 +0200] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000
...
[17/Jul/2018:13:42:44.302630629 +0200] - INFO - import_main_offline - import userroot: Import complete.  Processed 160 entries in 2 seconds. (80.00 entries/sec)
ldif2db successful
```
警告
コマンドで指定したデータベースが、LDIF ファイルに含まれる接尾辞と一致しない場合は、データベースに含まれるすべてのデータが削除され、インポートに失敗します。
インスタンスを起動します。
```
# dsctl instance_name start
```

6.1.3. Web コンソールを使用したデータのインポート

Web コンソールを使用して LDIF ファイルからデータをインポートするには、以下を行います。

接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」を参照してください。
インポートする LDIF に接尾辞エントリーを追加するステートメントが含まれていない場合は、「ルートエントリーの作成」で説明されているように、このエントリーを手動で作成します。
インポートする LDIF ファイルを /var/lib/dirsrv/slapd-instance_name/ldif/ ディレクトリーに保存します。
Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Database メニューを開きます。
接尾辞エントリーを選択します。
Suffix Tasks をクリックし、Initialize Suffix を選択します。
インポートする LDIF ファイルを選択するか、ファイルへの完全パスを入力します。
Yes, I am sure を選択し、Initialize Database をクリックして確定します。

6.2. データのエクスポート

LDAP データ交換形式 (LDIF) ファイルは、Directory Server データベースからデータベースエントリーをエクスポートするために使用されます。LDIF は RFC 2849 で説明されている標準形式です。

注記

エクスポート操作は、設定情報 (cn=config)、スキーマ情報 (cn=schema)、または監視情報 (cn=monitor) をエクスポートしません。

データのエクスポートは、以下の場合に役に立ちます。

データベースのデータのバックアップを作成します。
別の Directory Server にデータをコピーします。
別のアプリケーションへのデータのエクスポート。
ディレクトリートポロジーの変更後にデータベースを再作成します。
たとえば、ディレクトリーに 1 つのデータベースが含まれ、その内容を 2 つのデータベースに分割する必要がある場合は、図6.1「データベースコンテンツの 2 つのデータベースへの分割」で説明されるように、2 つの新しいデータベースのコンテンツをエクスポートし、それを 2 つの新しいデータベースにインポートます。
図6.1 データベースコンテンツの 2 つのデータベースへの分割

警告

エクスポート操作中はサーバーを停止しないでください。

Directory Server は、エクスポート操作を dirsrv ユーザーとして実行します。したがって、移行先ディレクトリーのパーミッションでは、このユーザーがこのファイルを作成できるようにする必要があります。

6.2.1. コマンドラインを使用した LDIF ファイルへのデータのエクスポート

Directory Server は、インスタンスの実行中またはオフライン時にデータのエクスポートをサポートします。

インスタンスが実行している場合には、以下のいずれかの方法を使用します。
- dsconf backend export コマンドを使用します。「dsconf backend export コマンドを使用したデータベースのエクスポート」を参照してください。
- cn=tasks エントリーを作成します。「cn=tasks エントリーを使用したデータベースのエクスポート」を参照してください。
インスタンスがオフラインの場合は、dsctl db2ldif コマンドを使用します。「サーバーがオフライン時のデータベースのエクスポート」を参照してください。

重要

LDIF ファイルを /tmp または /var/tmp/ ディレクトリーにエクスポートしないでください。理由は以下のとおりです。

Directory Server は、デフォルトで systemd の PrivateTmp 機能を使用します。LDIF ファイルを /tmp または /var/tmp/ システムディレクトリーに配置すると、Directory Server はインポート中にこれらの LDIF ファイルを認識しません。PrivateTmp の詳細は、systemd.exec(5) の man ページを参照してください。
LDIF ファイルには、しばしばユーザーパスワードなどの機密データが含まれます。したがって、これらのファイルを保存するために一時システムディレクトリーを使用しないでください。

6.2.1.1. サーバーの実行中にデータベースのエクスポート

6.2.1.1.1. dsconf backend export コマンドを使用したデータベースのエクスポート

dsconf backend export コマンドを使用して、LDIF ファイルにデータをエクスポートするタスクを自動的に作成します。

たとえば、userRoot データベースをエクスポートするには、以下のコマンドを実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com backend export userRoot
The export task has finished successfully

デフォルトでは、dsconf は、エクスポートを /var/lib/dirsrv/slapd-instance_name/export/ ディレクトリーの instance_name_database_name-time_stamp.ldif という名前のファイルに保存します。または、コマンドに -l file_name オプションを追加して、別の場所を指定します。

dsconf backend export コマンドは、特定の接尾辞を除外するなど、追加オプションに対応します。利用可能なオプションをすべて表示するには、以下を入力します。

# dsconf ldap://server.example.com backend export --help

6.2.1.1.2. cn=tasks エントリーを使用したデータベースのエクスポート

Directory Server 設定の cn=tasks,cn=config エントリーは、サーバーがタスクの管理に使用する一時的なエントリー用のコンテナーエントリーです。エクスポート操作を開始するには、cn=export,cn=tasks,cn=config エントリーにタスクを作成します。

タスクエントリーを使用すると、サーバーの実行中にデータをエクスポートできます。

エクスポートタスクエントリーには以下の属性が必要です。

cn: タスクの一意の名前を設定します。
nsInstance: エクスポートするデータベースの名前を設定します。
nsFilename: エクスポートを保存するファイルの名前を設定します。

エクスポートタスクは、接尾辞を除外するなどの追加のパラメーターをサポートします。完全なリストは、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』の『cn=export』セクションを参照してください。

たとえば、userRoot データベースのコンテンツを /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif ファイルにエクスポートするタスクを追加するには、次のようにします。

# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x

dn: cn=example_export,cn=export,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn: example_export
nsInstance: userRoot
nsFilename: /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif

タスクが完了すると、エントリーはディレクトリー設定から削除されます。

6.2.1.2. サーバーがオフライン時のデータベースのエクスポート

データのエクスポート時にサーバーがオフラインの場合は、dsctl db2ldif コマンドを使用します。

インスタンスを停止します。
```
# dsctl instance_name stop
```

データベースを LDIF ファイルにエクスポートします。たとえば、userRoot データベースを /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif ファイルにエクスポートするには:

# dsctl instance_name db2ldif userroot /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif 
OK group dirsrv exists
OK user dirsrv exists
ldiffile: /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif
[18/Jul/2018:10:46:03.353656777 +0200] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000
[18/Jul/2018:10:46:03.383101305 +0200] - INFO - ldbm_back_ldbm2ldif - export userroot: Processed 160 entries (100%).
[18/Jul/2018:10:46:03.391553963 +0200] - INFO - dblayer_pre_close - All database threads now stopped
db2ldif successful

インスタンスを起動します。
```
# dsctl instance_name start
```

6.2.2. Web コンソールを使用した LDIF ファイルへの接尾辞のエクスポート

Web コンソールを使用して接尾辞をエクスポートするには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Database メニューを開きます。
接尾辞エントリーを選択します。
Suffix Tasks をクリックし、Export Suffix を選択します。
エクスポートを保存する LDIF ファイルの名前を入力します。Directory Server は、指定したファイル名を使用して、ファイルを /var/lib/dirsrv/slapd-instance_name/ldif/ ディレクトリーに保存します。
Export Database をクリックします。

6.2.3. グループのメンバーがデータをエクスポートすることの許可、およびグループメンバーの 1 つとしてのエクスポートの実行

グループのメンバーに、データをエクスポートするパーミッションを設定できます。スクリプトに cn=Directory Manager の認証情報を設定する必要がなくなるため、セキュリティーが向上します。また、グループを変更して、エクスポートのパーミッションを簡単に許可し、取り消しすことができます。

6.2.3.1. グループがデータをエクスポートすることの許可

この手順を使用して、cn=export_users,ou=groups,dc=example,dc=com グループを追加し、このグループのメンバーがエクスポートタスクを作成することを許可します。

手順

cn=export_users,ou=groups,dc=example,dc=com グループを作成します。

# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" group create --cn export_users

cn=export_users,ou=groups,dc=example,dc=com グループのメンバーがエクスポートタスクを作成するのを許可するアクセス制御手順 (ACI) を追加します。

# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com

dn: cn=config
changetype: modify
add: aci
aci: (target = "ldap:///cn=export,cn=tasks,cn=config")(targetattr="*")
 (version 3.0 ; acl "permission: Allow export_users
  group to export data" ; allow (add, read, search) groupdn
  = "ldap:///cn=export_users,ou=groups,dc=example,dc=com";)
-
add: aci
aci: (target = "ldap:///cn=config")(targetattr =
  "objectclass || cn || nsslapd-suffix || nsslapd-ldifdir")
 (version 3.0 ; acl "permission: Allow export_users
  group to access ldifdir attribute" ; allow
  (read,search) groupdn = "ldap:///cn=export_users,ou=groups,dc=example,dc=com";)

ユーザーを作成します。

ユーザーアカウントを作成します。

# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" user create --uid="example" --cn="example" --uidNumber="1000" --gidNumber="1000" --homeDirectory="/home/example/" --displayName="Example User"

ユーザーアカウントのパスワードを設定します。

# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account reset_password "uid=example,ou=People,dc=example,dc=com" "password"

uid=example,ou=People,dc=example,dc=com ユーザーを cn=export_users,ou=groups,dc=example,dc=com グループに追加します。

# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" group add_member export_users uid=example,ou=People,dc=example,dc=com

検証

cn=config に設定した ACI を表示します。

# ldapsearch -o ldif-wrap=no -LLLx -D "cn=Directory Manager" -W -H ldap://server.example.com -b cn=config aci=* aci -s base
dn: cn=config
aci: (target = "ldap:///cn=export,cn=tasks,cn=config")(targetattr="*")(version 3.0 ; acl "permission: Allow export_users group to export data" ; allow (add, read, search) groupdn = "ldap:///cn=export_users,ou=groups,dc=example,dc=com";)
aci: (target = "ldap:///cn=config")(targetattr = "objectclass || cn || nsslapd-suffix || nsslapd-ldifdir")(version 3.0 ; acl "permission: Allow export_users group to access ldifdir attribute" ; allow (read,search) groupdn = "ldap:///cn=export_users,ou=groups,dc=example,dc=com";)
...

6.2.3.2. 通常のユーザーとしてのエクスポートの実行

cn=Directory Manager ではなく、通常のユーザーとしてエクスポートを実行できます。

前提条件

cn=export_users,ou=groups,dc=example,dc=com グループのメンバーがデータをエクスポートすることを許可している。「グループがデータをエクスポートすることの許可」を参照してください。
エクスポートの実行に使用するユーザーが cn=export_users,ou=groups,dc=example,dc=com グループのメンバーである。

手順

以下の方法のいずれかを使用してエクスポートタスクを作成します。

dsconf backend export コマンドの使用:

# dsconf -D "uid=example,ou=People,dc=example,dc=com" ldap://server.example.com backend export userRoot

タスクの手動での作成:

# ldapadd -D "uid=example,ou=People,dc=example,dc=com" -W -H ldap://server.example.com

dn: cn=userRoot-2021_07_23_12:55_00,cn=export,cn=tasks,cn=config
changetype: add
objectClass: extensibleObject
nsFilename: /var/lib/dirsrv/slapd-instance_name/ldif/None-userroot-2021_07_23_12:55_00.ldif
nsInstance: userRoot
cn: export-2021_07_23_12:55_00

検証

バックアップが作成されたことを確認します。

# ls -l /var/lib/dirsrv/slapd-instance_name/ldif/*.ldif
total 0
-rw-------. 1 dirsrv dirsrv 10306 Jul 23 12:55 None-userroot-2021_07_23_12_55_00.ldif
...

6.3. Directory Server のバックアップ

Directory Server のバックアップには、以下が含まれます。

これらのデータベース内に格納されているデータを含むすべてのデータベースファイル
注記
Directory Server は、個別のデータベースのバックアップをサポートしません。
トランザクションログ
インデックス

バックアップとは対照的に、「データのエクスポート」で説明されているように、データをエクスポートできます。エクスポート機能を使用して、LDAP Data Interchange Format (LDIF) 形式のサーバーからサブツリーなどの特定のデータをエクスポートします。

警告

バックアップ操作中にサーバーを停止しないでください。

Directory Server は、バックアップタスクを dirsrv ユーザーとして実行します。したがって、移行先ディレクトリーのパーミッションでは、このユーザーがファイルを作成できるようにする必要があります。

6.3.1. コマンドラインを使用した全データベースのバックアップ

Directory Server は、インスタンスの実行中またはオフライン時にデータベースのバックアップをサポートします。

インスタンスが実行している場合には、以下のいずれかの方法を使用します。
- dsconf backup create コマンドを使用します。「dsconf backup create コマンドを使用した全データベースのバックアップ」を参照してください。
- cn=tasks エントリーを作成します。「cn=tasks エントリーを使用した全データベースのバックアップ」を参照してください。
インスタンスがオフラインの場合は、dsctl db2bak コマンドを使用します。「サーバーがオフライン時のすべてのデータベースのバックアップ」を参照してください。

重要

これらのメソッドはデータベースのみのバックアップを作成します。設定などの他の重要なファイルのバックアップに関する詳細は、「設定ファイル、証明書データベース、およびカスタムスキーマファイルのバックアップ」を参照してください。

6.3.1.1. サーバーの実行中にすべてのデータベースのバックアップ

6.3.1.1.1. dsconf backup create コマンドを使用した全データベースのバックアップ

dsconf backup create コマンドを使用して、全データベースをバックアップするタスクを自動的に作成します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com backup create
The backup create task has finished successfully

デフォルトでは、dsconf は、バックアップを /var/lib/dirsrv/slapd-instance_name/bak/ ディレクトリーの instance_name-time_stamp というサブディレクトリーに保存します。別の場所を指定するには、コマンドにディレクトリー名を追加します。

6.3.1.1.2. cn=tasks エントリーを使用した全データベースのバックアップ

Directory Server 設定の cn=tasks,cn=config エントリーは、サーバーがタスクの管理に使用する一時的なエントリー用のコンテナーエントリーです。バックアップ操作を開始するには、cn=backup,cn=tasks,cn=config エントリーでタスクを作成します。

タスクエントリーを使用すると、サーバーの実行中にデータベースのバックアップを作成できます。

バックアップタスクエントリーには以下の属性が必要です。

cn: タスクの一意の名前を設定します。
nsDatabaseType: バックアップするデータベースのタイプを設定します。Directory Server は、この属性の ldbm database 値のみをサポートします。

バックアップタスクは、デフォルトとして別の宛先ディレクトリーを指定するなど、追加のパラメーターをサポートします (/var/lib/dirsrv/slapd-instance_name/bak/)。完全なリストは、『Red Hat Directory Server Configuration, Command, and File Reference』の『cn=backup』セクションを参照してください。

たとえば、すべてのデータベースをバックアップし、アーカイブをデフォルトのバックアップディレクトリーに保存するには、以下を実行します。

# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x

dn: cn=example_backup,cn=export,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn: example_backup
nsDatabaseType: ldbm database

nsArchiveDir 属性を指定しないと、サーバーは /var/lib/dirsrv/slapd-instance_name/bak/ ディレクトリーの instance_name-time_stamp という名前のサブディレクトリーにバックアップを保存します。

タスクが完了すると、エントリーはディレクトリー設定から削除されます。

6.3.1.2. サーバーがオフライン時のすべてのデータベースのバックアップ

データベースのバックアップ時にサーバーがオフラインの場合は、dsctl db2bak コマンドを使用します。

インスタンスを停止します。
```
# dsctl instance_name stop
```
データベースのバックアップを作成します。
```
# dsctl instance_name db2bak
db2bak successful
```
注記
dsctl db2bak コマンドは、dirsrv ユーザーとしてバックアップとして実行されます。したがって、インストール先ディレクトリーのパーミッションでは、このユーザーがファイルとディレクトリーを作成できるようにする必要があります。
宛先ディレクトリーをコマンドに追加しないと、サーバーは、/var/lib/dirsrv/slapd-instance_name/bak/ ディレクトリーのサブディレクトリー instance_name-time_stamp にバックアップを保存します。
インスタンスを起動します。
```
# dsctl instance_name start
```

6.3.2. Web コンソールを使用した全データベースのバックアップ

Web コンソールを使用してインスタンスのデータベースをすべてバックアップするには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Actions ボタンをクリックして、Manage Backup を選択します。
Create Backup をクリックします。
バックアップの作成日時を示すタイムスタンプなど、バックアップの名前を入力します。
Create Backup をクリックします。

サーバーは、バックアップを /var/lib/dirsrv/slapd-instance_name/bak/ ディレクトリー内の指定した名前のサブディレクトリーに保存します。

6.3.3. 設定ファイル、証明書データベース、およびカスタムスキーマファイルのバックアップ

Directory Server に統合されているバックアップメカニズムは、データベースのみのバックアップを作成します。ただし、/etc/dirsrv/slapd-instance_name/ ディレクトリーには追加のファイルが保存されています。これらのファイルは、たとえば、ハードウェア障害後に別のサーバー上でインスタンスを復元するのに必要になります。

注記

Web コンソールで設定ディレクトリーのバックアップはサポートされていません。

例6.2 /etc/dirsrv/slapd-instance_name/ ディレクトリーのバックアップ方法

/etc/dirsrv/slapd-instance_name/ のコンテンツをバックアップするには、ディレクトリーをコピーするか、アーカイブファイルに保存します。たとえば、/etc/dirsrv/slapd-instance_name/ ディレクトリーのコンテンツを /root/config_slapd-instance_name_time_stamp.tar.gz ファイルに保存するには、次のコマンドを実行します。

# cd /etc/dirsrv/
# tar -zcvf /root/config_slapd-instance_name_$(date +%Y-%m-%d_%H-%M-%S).tar.gz slapd-instance_name/

重要

バックアップ時に、証明書データベースを更新しないでください。更新してしまうと、バックアップ内のデータベースで一貫性がなくなる可能性があります。

6.3.4. グループのメンバーが Directory Server をバックアップすることの許可、およびグループメンバーの 1 つとしてのバックアップの実行

グループのメンバーに、インスタンスをバックアップしバックアップを実施するパーミッションを設定できます。バックアップスクリプトまたは cron ジョブに cn=Directory Manager の認証情報を設定する必要がなくなるため、セキュリティーが向上します。また、グループを変更して、バックアップのパーミッションを簡単に許可し、取り消しすことができます。

6.3.4.1. グループが Directory Server をバックアップすることの許可

この手順を使用して、cn=backup_users,ou=groups,dc=example,dc=com グループを追加し、このグループのメンバーがバックアップタスクを作成するのを許可します。

手順

cn=backup_users,ou=groups,dc=example,dc=com グループを作成します。

# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" group create --cn backup_users

cn=backup_users,ou=groups,dc=example,dc=com グループのメンバーがバックアップタスクを作成するのを許可するアクセス制御手順 (ACI) を追加します。

# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com

dn: cn=config
changetype: modify
add: aci
aci: (target = "ldap:///cn=backup,cn=tasks,cn=config")(targetattr="*")
 (version 3.0 ; acl "permission: Allow backup_users
  group to create backup tasks" ; allow (add, read, search) groupdn
  = "ldap:///cn=backup_users,ou=groups,dc=example,dc=com";)
-
add: aci
aci: (target = "ldap:///cn=config")(targetattr = "nsslapd-bakdir || objectClass")
 (version 3.0 ; acl "permission: Allow backup_users group
  to access bakdir attribute" ; allow (read,search) groupdn
  = "ldap:///cn=backup_users,ou=groups,dc=example,dc=com";)

ユーザーを作成します。

ユーザーアカウントを作成します。

# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" user create --uid="example" --cn="example" --uidNumber="1000" --gidNumber="1000" --homeDirectory="/home/example/" --displayName="Example User"

ユーザーアカウントのパスワードを設定します。

# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account reset_password "uid=example,ou=People,dc=example,dc=com" "password"

uid=example,ou=People,dc=example,dc=com ユーザーを cn=backup_users,ou=groups,dc=example,dc=com グループに追加します。

# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" group add_member backup_users uid=example,ou=People,dc=example,dc=com

検証

cn=config エントリーに設定された ACI を表示します。

# ldapsearch -o ldif-wrap=no -LLLx -D "cn=directory manager" -W -H ldap://server.example.com -b cn=config aci=* aci -s base
dn: cn=config
aci: (target = "ldap:///cn=backup,cn=tasks,cn=config")(targetattr="*")(version 3.0 ; acl "permission: Allow backup_users group to create backup tasks" ; allow (add, read, search) groupdn = "ldap:///cn=backup_users,ou=groups,dc=example,dc=com";)
aci: (target = "ldap:///cn=config")(targetattr = "nsslapd-bakdir || objectClass")(version 3.0 ; acl "permission: Allow backup_users group to access bakdir attribute" ; allow (read,search) groupdn = "ldap:///cn=backup_users,ou=groups,dc=example,dc=com";)
...

6.3.4.2. 通常のユーザーとしてのバックアップの実行

cn=Directory Manager ではなく、通常のユーザーとしてバックアップを実行できます。

前提条件

cn=backup_users,ou=groups,dc=example,dc=com グループのメンバーがデータをバックアップするのを許可している。「グループが Directory Server をバックアップすることの許可」を参照してください。
バックアップの実行に使用するユーザーが cn=backup_users,ou=groups,dc=example,dc=com グループのメンバーである。

手順

以下の方法のいずれかを使用してバックアップタスクを作成します。

dsconf backup create コマンドの使用:

# dsconf -D uid=example,ou=People,dc=example,dc=com ldap://server.example.com backup create

タスクの手動での作成:

# ldapadd -D uid=example,ou=People,dc=example,dc=com -W -H ldap://server.example.com

dn: cn=backup-2021_07_23_12:55_00,cn=backup,cn=tasks,cn=config
changetype: add
objectClass: extensibleObject
nsarchivedir: /var/lib/dirsrv/slapd-instance_name/bak/backup-2021_07_23_12:55_00
nsdatabasetype: ldbm database
cn: backup-2021_07_23_12:55_00

検証

バックアップが作成されたことを確認します。

# ls -l /var/lib/dirsrv/slapd-instance_name/bak/
total 0
drwx------. 3 dirsrv dirsrv 108 Jul 23 12:55 backup-2021_07_23_12_55_00
...

6.4. Directory Server の復元

特定の状況では、管理者がハードウェア障害後など Directory Server を復元する必要があります。本セクションでは、サポートされている復元方法を説明します。

注記

Directory Server は、個別のデータベースの復元には対応していません。

Directory Server は、復元操作を dirsrv ユーザーとして実行します。そのため、バックアップを含むディレクトリーのパーミッションにより、このユーザーがファイルを読み取ることができます。

6.4.1. コマンドラインでのすべてのデータベースの復元

Directory Server は、インスタンスの実行中またはオフライン時にデータベースの復元をサポートします。

インスタンスが実行している場合には、以下のいずれかの方法を使用します。
- dsconf backup restore コマンドを使用します。「dsconf backup restore コマンドを使用した全データベースの復元」を参照してください。
- cn=tasks エントリーを作成します。「cn=tasks エントリーを使用した全データベースの復元」を参照してください。
インスタンスがオフラインの場合は、dsctl bak2db コマンドを使用します。「サーバーがオフライン時の全データベースの復元」を参照してください。

6.4.1.1. サーバーの実行中にすべてのデータベースの復元

6.4.1.1.1. dsconf backup restore コマンドを使用した全データベースの復元

dsconf backup restore コマンドを使用して、バックアップディレクトリーからすべてのデータベースを復元するタスクを自動的に作成します。

たとえば、/var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/ ディレクトリーに保存されているバックアップを復元するには、次のコマンドを実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com backup restore /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/
The backup restore task has finished successfully

6.4.1.1.2. cn=tasks エントリーを使用した全データベースの復元

Directory Server 設定の cn=tasks,cn=config エントリーは、サーバーがタスクの管理に使用する一時的なエントリー用のコンテナーエントリーです。復元操作を開始するには、cn=restore,cn=tasks,cn=config エントリーでタスクを作成します。

警告

復元タスクを使用すると、インスタンス内のすべてのデータが上書きされます。

復元タスクエントリーには以下の属性が必要です。

cn: タスクの一意の名前を設定します。
nsArchiveDir: バックアップが含まれるディレクトリーへのパスを設定します。
nsDatabaseType: 復元するデータベースのタイプを設定します。Directory Server は、この属性の ldbm database 値のみをサポートします。

たとえば、/var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/ ディレクトリーに保存されているバックアップからすべてのデータベースを復元するタスクを追加するには、次のコマンドを実行します。

# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x

dn: cn=example_restore,cn=import,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn: example_restore
nsArchiveDir: /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/
nsDatabaseType: ldbm database

タスクが完了すると、エントリーはディレクトリー設定から削除されます。

6.4.1.2. サーバーがオフライン時の全データベースの復元

データベースの復元時にサーバーがオフラインの場合は、dsctl bak2db コマンドを使用します。

インスタンスを停止します。
```
# dsctl instance_name stop
```
データベースを復元します。たとえば、/var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/ ディレクトリーに保存されているバックアップからすべてのデータベースを復元するタスクを追加するには、次のコマンドを実行します。
```
# dsctl instance_name bak2db /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/
bak2db successful
```
注記
dsctl bak2db コマンドは、dirsrv ユーザーとして復元として実行されます。したがって、ソースディレクトリーのパーミッションでは、このユーザーがファイルとディレクトリーを読み取りできるようにする必要があります。
インスタンスを起動します。
```
# dsctl instance_name start
```

6.4.2. Web コンソールを使用した全データベースの復元

Web コンソールを使用してすべてのデータベースを復元するには、以下を行います。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Actions ボタンをクリックして、Manage Backups を選択します。
表示されるウィンドウには、/var/lib/dirsrv/slapd-instance_name/bak/ ディレクトリーで利用可能なバックアップが表示されます。
復元するバックアップの横にある Actions メニューを開き、Restore Backup を選択します。
Yes をクリックして確定します。

6.4.3. 複製されたエントリーが含まれるデータベースの復元

サプライヤーサーバーを復元すると、いくつかの状況が発生する可能性があります。

コンシューマーサーバーも復元される。
(データが同期されるように) 全く同じ時間に作成されたバックアップからすべてのデータベースを復元するような非常にまれな状況においては、コンシューマーはサプライヤーと同期が取れた状態のままであるため、特に何もする必要はありません。レプリケーションは中断せずに再開します。
サプライヤーだけが復元します。
サプライヤーのみが復元された場合や、コンシューマーが別のバックアップから復元された場合は、サプライヤーがコンシューマーを再初期化して、データベースのデータを更新します。サプライヤーのみが復元された場合や、コンシューマーが別のバックアップから復元された場合は、サプライヤーがコンシューマーを再初期化して、データベースのデータを更新します。
サプライヤーサーバーでチェンジログエントリーの有効期限が切れていません。
データベースのバックアップの取得後にサプライヤーの変更ログが期限切れになっていない場合は、ローカルコンシューマーを復元し、通常の操作を継続します。この状態は、cn=changelog5,cn=config エントリーで、最大 changelog age 属性 nsslapd-changelogmaxage に設定された値よりも短い期間内にバックアップを取得した場合に限り発生します。このオプションの詳細は、『Red Hat Directory Server 設定、コマンド、およびファイルリファレンス』を参照してください。
Directory Server は、レプリカとその変更ログの間の互換性を自動的に検出します。不一致が検出されると、サーバーは古い変更ログファイルを削除し、空のファイルを新たに作成します。
変更ログエントリーが、ローカルバックアップを作成した後にサプライヤーサーバー上で期限切れになる。
変更ログエントリーの有効期限が切れている場合は、コンシューマーが再初期化される。コンシューマーの再初期化に関する詳細は、「コンシューマーの初期化」を参照してください。

例6.3 Directory Server のレプリケーショントポロジーの復元

たとえば、2 つのサプライヤーと 2 つのコンシューマーサーバーで設定されるレプリケーション環境のサーバーをすべて復元するには、以下を実行します。

最初のサプライヤーを復元します。dsconf backend import コマンドを使用して、データをインポートします。「コマンドラインでのインポート」を参照してください。
レプリケーションを使用して残りのサーバーをオンラインに初期化します。
1. 最初のサプライヤーから 2 番目のサプライヤーを初期化します。
2. サプライヤーからコンシューマーを初期化します。
詳細については、「コンシューマーの初期化」を参照してください。
各サーバーでレプリケーションのステータスを表示し、レプリケーションが正しく機能していることを確認します。詳細については、「特定のレプリカ合意の状態の表示」を参照してください。

復元操作中に、復元されたデータベースに関連する変更ログが削除されます。再初期化が必要であることを示すメッセージが、サプライヤーサーバーのログファイルに記録されます。

レプリケーションの管理に関する情報は、15章レプリケーションの管理を参照してください。

第7章属性および値の管理

Red Hat Directory Server は、ディレクトリーエントリーで一部の属性タイプを動的かつ自動的に維持するためのさまざまなメカニズムを提供します。これらのプラグインおよび設定オプションを使用すると、ディレクトリーデータの管理やエントリー間の関係の表現が容易になります。

エントリーの特徴の一部は、相互関係です。とうぜん。マネージャーには従業員がいるため、この 2 つのエントリーには関連性があります。グループはメンバーに関連付けられます。共通の物理的な場所を共有するエントリー間のように、あまり明白でない関係もあります。

Red Hat Directory Server は、このようなエントリー間の関係をスムーズにかつ一貫して維持する方法を複数提供します。複数のプラグインは、ディレクトリー内のデータの一部として属性を自動的に適用または生成できます。これには、サービスのクラス、属性のリンク、一意の数値属性値の生成が含まれます。

7.1. 属性の一意性の有効化

ディレクトリーまたはサブツリー全体で属性の値が一意になるように、Attribute Uniqueness プラグインを使用します。

複数の属性を一意にしたい場合や、異なる条件を使用する場合は、プラグインに複数の設定レコードを作成します。

7.1.1. Attribute Uniqueness プラグインの新規設定レコードの作成

値が一意である必要がある属性ごとに、Attribute Uniqueness プラグインの新しい設定レコードを作成します。

注記

コマンドラインからプラグインの新しい設定レコードのみを作成できます。

Example Attribute Uniqueness という名前のプラグインの設定解除および無効にした新しい設定レコードを作成するには、以下を実行します。

dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq add "Example" --attr-name uid

7.1.2. 接尾辞またはサブツリーにおける属性一意の設定

Attribute Uniqueness プラグインを設定して、特定の接尾辞、サブツリー、または接尾辞およびサブツリーで属性の値が一意になるようにすることができます。

7.1.2.1. コマンドラインで接尾辞またはサブツリーに対する属性一意の設定

たとえば、mail 属性に保存される値が一意となるように設定するには、以下を実行します。

たとえば mail Attribute Uniqueness という名前の Attribute Uniqueness プラグインの新たな設定レコードを作成します。詳細については、「Attribute Uniqueness プラグインの新規設定レコードの作成」を参照してください。

プラグイン設定レコードを有効にします。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq enable "mail Attribute Uniqueness"

mail 属性に保存されている値は、内部で一意である必要があります。たとえば、ou=Engineering,dc=example,dc=com および ou=Sales,dc=example,dc=com サブツリーなどです。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq set "mail Attribute Uniqueness" --attr-name mail --subtree ou=Engineering,dc=example,dc=com ou=Sales,dc=example,dc=com
```
必要に応じて、このプラグイン設定レコードに設定されたすべてのサブツリーで一意性を設定するには、以下を実行します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq set "mail Attribute Uniqueness" --across--all-subtrees=on
```
インスタンスを再起動します。
```
# dsctl instance_name restart
```

7.1.2.2. Web コンソールを使用した接尾辞またはサブツリーに対する属性の一意の設定

たとえば、mail 属性に保存される値が一意となるように設定するには、以下を実行します。

Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
インスタンスを選択します。
Plugins メニューを開きます。
Attribute Uniqueness プラグインを選択します。
Add Config をクリックします。
フィールドを入力し、設定を有効にします。以下に例を示します。
図7.1 属性一意設定の追加
インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。

7.1.3. オブジェクトクラスに対する属性の一意性の設定

Attribute Uniqueness プラグインを設定して、特定のオブジェクトクラスが含まれるサブツリーエントリーで属性の値が一意になるようにすることができます。Directory Server は、更新されたオブジェクトの親エントリーでこのオブジェクトクラスを検索します。Directory Server でオブジェクトクラスが見つからなかった場合、検索はディレクトリーツリーのルートまで次の上位レベルのエントリーで続行されます。オブジェクトクラスが見つかった場合、Directory Server は、uniqueness-attribute-name に設定された属性の値がこのサブツリー内で一意であることを確認します。

たとえば、mail 属性に保存されている値が、nsContainer オブジェクトクラスが含まれるエントリーで一意となるように設定するには、以下を実行します。

たとえば mail Attribute Uniqueness という名前の Attribute Uniqueness プラグインの新たな設定レコードを作成します。詳細については、「Attribute Uniqueness プラグインの新規設定レコードの作成」を参照してください。

プラグイン設定レコードを有効にします。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq enable "mail Attribute Uniqueness"

mail 属性に保存される値は、nsContainer オブジェクトクラスが含まれるエントリーで一意である必要があります。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq set "mail Attribute Uniqueness" --top-entry-oc=nsContainer
```
必要に応じて、チェックされるオブジェクトの範囲を制限できます。サーバーが nsContainer オブジェクトクラスを含むエントリーの下にあるエントリーのサブセットのみをチェックするようにするには、uniqueness-subtree-entries-oc パラメーターに追加のオブジェクトクラスを設定します。この追加クラスも存在している必要があります。
たとえば、nsContainer オブジェクトクラスセットが含まれるエントリーにあるすべてのエントリーで mail 属性を一意にする必要があります。ただし、プラグインは、inetOrgPerson など、この属性を提供するオブジェクトクラスが含まれるエントリーで mail のみを検索します。この場合は、以下を入力します。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq set "mail Attribute Uniqueness" --subtree-entries-oc=inetOrgPerson
```
インスタンスを再起動します。
```
# dsctl instance_name restart
```

7.1.4. 属性の一意性プラグイン設定パラメーター

Attribute Uniqueness プラグインの設定レコードを設定するには、cn=attribute_uniqueness_configuration_record_name,cn=plugins,cn=config エントリーでプラグインの設定属性を設定します。

例7.1 プラグイン固有の属性を使用した属性の一意性プラグイン設定

dn: cn=Example Attribute Uniqueness,cn=plugins,cn=config
nsslapd-pluginEnabled: on
uniqueness-attribute-name: attribute_name
uniqueness-top-entry-oc: objectclass1 
uniqueness-subtree-entries-oc: objectclass2

Attribute Uniqueness プラグインを設定するために設定できるパラメーターの一覧は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』の該当するセクションを参照してください。

7.2. サービスのクラスの割り当て

サービス定義 (CoS) は、アプリケーションに透過的な方法でエントリー間で属性を共有します。CoS はエントリー管理を簡素化し、ストレージ要件を削減します。

Directory Server のクライアントは、ユーザーのエントリーの属性を読み取ります。CoS では、一部の属性値はエントリー自体に保存されない可能性があります。代わりに、エントリーがクライアントアプリケーションに送信されるため、これらの属性の値はサービスロジックのクラスによって生成されます。

各 CoS は、ディレクトリー内に 2 種類のエントリーで設定されます。

CoS 定義エントリー。CoS 定義エントリーは、使用される CoS のタイプを識別します。ロール定義エントリーと同様に、LDAPsubentry オブジェクトクラスから継承されます。CoS 定義エントリーは、有効なブランチの下にあります。
テンプレートエントリー。CoS テンプレートエントリーには、共有属性値のリストが含まれます。テンプレートエントリー属性値への変更は、CoS の範囲内のすべてのエントリーに自動的に適用されます。1 つの CoS に、複数のテンプレートエントリーが関連付けられている場合があります。

CoS 定義エントリーとテンプレートエントリーは、CoS の範囲内で任意のターゲットエントリーに属性情報を提供するために対話します。

7.2.1. CoS 定義エントリーの概要

CoS 定義エントリーは、cosSuperDefinition オブジェクトクラスのインスタンスです。CoS 定義エントリーには、エントリーを生成するために使用するテンプレートエントリーのタイプを指定する 3 つのオブジェクトクラスのいずれか 1 つも含まれています。CoS と対話するターゲットエントリーは、CoS 定義エントリーと同じ親を共有します。

CoS には 3 つのタイプの CoS 定義エントリーを使用して定義されます。

ポインター CoS。ポインター CoS は、テンプレート DN のみを使用してテンプレートエントリーを特定します。
間接的な CoS。間接 CoS は、ターゲットエントリーの属性の 1 つを使用してテンプレートエントリーを識別します。たとえば、間接的な CoS はターゲットエントリーの manager 属性を指定する場合があります。次に、manager 属性の値を使用してテンプレートエントリーを特定します。
ターゲットエントリーの属性は単値であり、DN が含まれる必要があります。
Classic CoS。Classic CoS は、テンプレートエントリーのベース DN とターゲットエントリーの属性の 1 つの値を使用してテンプレートエントリーを特定します。

CoS の各タイプのオブジェクトクラスおよび属性に関する詳細は、「コマンドラインでの CoS の管理」を参照してください。

CoS ロジックが、CoS が値を生成する属性を含むことを検出すると、デフォルトでは CoS が値を生成する属性を検出すると、クライアントアプリケーションにエントリー自体の属性値が提供されます。ただし、CoS 定義エントリーはこの動作を制御できます。

7.2.2. CoS テンプレートエントリーの概要

CoS テンプレートエントリーには、CoS ロジックによって生成された属性の値 (1 つまたは複数) が含まれます。CoS テンプレートエントリーには、一般的なオブジェクトクラス cosTemplate が含まれます。特定の CoS テンプレートエントリーは、CoS 定義とともにディレクトリーツリーに保存されます。

テンプレートエントリーの相対識別名 (RDN) は、以下のいずれかで決定されます。

テンプレートエントリーの DN のみ。このタイプのテンプレートは Pointer CoS 定義に関連付けられます。
ターゲットエントリーの属性の 1 つの値。テンプレートエントリーに相対 DN を提供するために使用される属性は、cosIndirectSpecifier 属性を使用して CoS 定義エントリーに指定されます。このタイプのテンプレートは、間接 CoS 定義に関連付けられます。
CoS がテンプレートの 1 つのレベル検索を実行するサブツリーの DN と、ターゲットエントリーの属性の 1 つの値の組み合わせ。このタイプのテンプレートは、Classic CoS 定義に関連付けられます。

7.2.3. Pointer CoS の仕組み

管理者は、dc=example,dc=com に保存されているすべてのエントリーと共通の郵便番号を共有するポインター CoS を作成します。図7.2「Pointer CoS のサンプル」に示されるように、この CoS の 3 つのエントリーが表示されます。

図7.2 Pointer CoS のサンプル

この例では、テンプレートエントリーが CoS 定義エントリーの DN cn=exampleUS,cn=data で識別されます。postalCode 属性がエントリー cn=wholiday,ou=people,dc=example,dc=com に対してクエリーされるたびに、Directory Server は、テンプレートエントリー cn=exampleUS,cn=data で使用可能な値を返します。

7.2.4. 間接的な CoS の仕組み

管理者は、ターゲットエントリーの manager 属性を使用してテンプレートエントリーを識別する間接的な CoS を作成します。図7.3「間接的な CoS の例」に示されるように、3 つの CoS エントリーが表示されます。

図7.3 間接的な CoS の例

この例では、Wiiam Holiday のターゲットエントリーには間接指定子 (manager 属性) が含まれます。William のマネージャーは Carla Fuentes であるため、manager 属性にはテンプレートエントリーの DN へのポインター cn=Carla Fuentes,ou=people,dc=example,dc=com が含まれます。テンプレートエントリーは次に、318842 の departmentNumber 属性値を提供します。

7.2.5. Classic CoS の仕組み

管理者は、テンプレート DN と CoS 指定子の組み合わせを使用して、有番号を含むテンプレートエントリーを特定します。図7.4「Classic CoS のサンプル」に示されるように、3 つの CoS エントリーが表示されます。

図7.4 Classic CoS のサンプル

この例では、CoS 定義エントリーの cosSpecifier 属性は、employeeType 属性を指定しています。この属性は、テンプレート DN と組み合わせて、テンプレートエントリーを cn=sales,cn=exampleUS,cn=data として特定します。その後、テンプレートエントリーは、postalCode 属性値をターゲットエントリーに提供します。

7.2.6. 物理属性値の処理

cosAttribute 属性には、サービスのクラスによって管理される別の属性の名前が含まれます。この属性は、属性値の後に override 修飾子を許可します。属性値の生成時に、CoS がエントリーの既存の属性値を処理する方法を設定します。

cosAttribute: attribute_name override

override 修飾子は 4 つあります。

default: エントリーに対応する属性値が格納されてない場合のみ、生成された値を返します。
override: エントリーに値が保存されている場合でも、常に CoS によって生成された値を返します。
operational: 生成された属性が検索で明示的に要求されている場合にのみ、生成された属性を返します。操作属性は、返されるためにスキーマチェックに合格する必要はありません。operational を使用すると、既存の属性値も上書きされます。
注記
属性は、スキーマで操作可能として定義されている場合にのみ操作可能にすることができます。たとえば、CoS が description 属性の値を生成する場合、この属性はスキーマで稼働していないため、operational 修飾子を使用することはできません。
operational-default: エントリーに対応する属性値が格納されておらず、検索で明示的に要求された場合にのみ、生成された値を返します。

修飾子が設定されていない場合は、default と仮定されます。

たとえば、このポインター CoS 定義エントリーは、postalCode 属性の値を生成するテンプレートエントリー cn=exampleUS,ou=data,dc=example,dc=com に関連付けられていることを示しています。override 修飾子は、この値が postalCode 属性のエントリーによって保存される値よりも優先されることを示しています。

dn: cn=pointerCoS,dc=example,dc=com
objectclass: top
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn=exampleUS,ou=data,dc=example,dc=com
cosAttribute: postalCode override

注記

エントリーに CoS によって生成された属性値が含まれる場合、操作修飾子または上書き修飾子で定義された場合には、属性の値を手動で更新することは できません。

CoS 属性の詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』を参照してください。

7.2.7. CoS を使用した多値属性の処理

属性は、サービスのクラスを使用して生成できます。これには複数値の属性が含まれます。これにより、混乱を生じさせる可能性があります。どの CoS が値を提供しますか。これらのいずれか、またはすべてですか。競合 CoS テンプレートからどのように値が選択されていますか。生成された属性は単値または多値を使用しますか。

これを解決する方法は 2 つあります。

複数の CoS が生成する属性をターゲットエントリーにマージするルールを作成。これにより、ターゲットエントリーの値が複数表示されます。
競合する CoS 定義の中から 1 つの CoS 値を選択するように優先度を設定。これにより、ターゲットエントリーに 1 つの値が生成されます。

注記

Indirect CoS は cosPriority 属性をサポートしません。

CoS が CoS 属性の複数の値を処理する方法は、merge-schemes 修飾子を使用するかどうかで定義されます。

cosAttribute: attribute override merge-schemes

注記

merge-schemes 修飾子は、CoS による物理属性値や override 修飾子の処理方法に影響を与えません。競合する CoS テンプレートまたは定義が複数ある場合は、競合するすべての CoS 定義のすべての cosAttribute に、同じ merge-schemes および override 修飾子を設定する必要があります。それ以外の場合は、1 つの組み合わせが可能なすべての CoS 定義から任意に選択されます。

merge-schemes 修飾子を使用すると、CoS に、マネージド属性に対して複数の値を生成する、または生成できることを通知します。多値 CoS 属性を持つシナリオは 2 つあります。

1 つの CoS テンプレートエントリーに管理 CoS 属性のインスタンスが複数含まれるため、ターゲットエントリーに多値が作成されます。以下に例を示します。
```
dn: cn=server access template,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: cosTemplate
accessTo: mail.example.com
accessTo: irc.example.com
```
注記
このメソッドは、Classic CoS でのみ動作します。

複数の CoS 定義が同じターゲット属性にサービスクラスを定義する可能性があるため、複数のテンプレートエントリーがあります。以下に例を示します。

dn: cn=mail template,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: cosTemplate
accessTo: mail.example.com

dn: cn=chat template,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: cosTemplate
accessTo: irc.example.com

ただし、CoS 定義が複数ある場合でも、属性には 1 つの値のみが生成されることがあります。CoS 定義が複数ある場合、値は任意に選択されます。これは予測不可で、意図しないオプションです。どの CoS テンプレートを使用するかを制御する方法は、テンプレートに順位 (優先順位) を設定することであり、優先順位の高い CoS が常に勝ち、値を提供します。

値を提供するために複数のテンプレートが完成することはかなり一般的です。たとえば、CoS 定義エントリーには複数値の cosSpecifier 属性を使用できます。テンプレートの優先度は、cosPriority 属性を使用して設定します。この属性は、特定のテンプレートのグローバル優先度を表します。0 の優先度が最も優先されます。

たとえば、部門番号を生成する CoS テンプレートエントリーは、以下のようになります。

dn: cn=data,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: cosTemplate
departmentNumber: 71776
cosPriority: 0

このテンプレートエントリーには、departmentNumber 属性の値が含まれます。優先度はゼロであるため、このテンプレートは、別の departmentNumber 値を定義する他の競合するテンプレートよりも優先されます。

cosPriority 属性が含まれないテンプレートは、優先度が最も低いとみなされます。2 つ以上のテンプレートが属性値を提供し、優先度が同じ (または優先順位がない) 場合は、値が任意に選択されます。

注記

負の cosPriority 値の動作は Directory Server では定義されないため、負の値を入力しないでください。

7.2.8. CoS 指定の属性の検索

CoS 定義はエントリーで属性の値を指定します。たとえば、CoS はサブツリー内のすべてのエントリーに postalCode 属性を設定できます。ただし、これらの CoS 定義属性に対する検索は、通常のエントリーに対する検索のように動作しません。

CoS が定義する属性が、あらゆる種類のインデックス (存在を含む) でインデックス化されている場合、CoS によって設定される値を持つ属性は検索で返されません。以下に例を示します。

Ted Morris の postalCode 属性は、CoS によって定義されます。
Barbara Jensen の postalCode 属性は、Barbara Jensen 自身のエントリーに設定されます。
postalCode 属性はインデックス化されます。

ldapsearch コマンドでフィルター (postalCode=*) が使用される場合、Barbara Jensen のエントリーが返されますが、Tedris のエントリーは返されません。

CoS が定義されている属性がインデックス化されて いない 場合には、属性の値がローカルで設定されるか、CoS と設定されている場合にかかわらず、一致するすべてのエントリーが検索で返されます。以下に例を示します。

Ted Morris の postalCode 属性は、CoS によって定義されます。
Barbara Jensen の postalCode 属性は、Barbara Jensen 自身のエントリーに設定されます。
postalCode 属性はインデックス化 されません。

ldapsearch コマンドでフィルター (postalCode=*) を使用する場合は、Barbara Jensen のエントリーと Ted Morris のエントリーの両方が返されます。

CoS は override を許可します。これは、CoS エントリーの cosAttribute 属性に指定された ID です。つまり、属性のローカル値は CoS 値を上書きできます。CoS に上書きが設定されていると、エントリーのローカル値があるかぎり、ldapsearch 操作は属性がインデックス化された場合でもエントリーの値を返します。CoS を持ち、ローカル値を持たない他のエントリーは、ldapsearch 操作では返されません。

CoS で定義した属性で LDAP 検索要求を実行する際に問題が発生する可能性があるため、CoS を使用して生成する属性を決定する際には注意してください。

7.2.9. アクセス制御と CoS

サーバーは、通常の保存属性と同じように、CoS が生成した属性へのアクセスを制御します。ただし、CoS によって生成された属性の値によってはアクセス制御ルールは機能しません。これは、検索フィルターで CoS が生成する属性の使用に適用される制限と同じです。

7.2.10. コマンドラインでの CoS の管理

すべての設定情報とテンプレートデータはディレクトリーにエントリーとして格納されるため、標準の LDAP ツールを使用して CoS 設定および管理に使用できます。

「コマンドラインでの CoS 定義エントリーの作成」
「コマンドラインでの CoS テンプレートエントリーの作成」
「Pointer CoS の例」
「間接的な CoS の例」
「Classic CoS の例」
「CoS エントリーの検索」

7.2.10.1. コマンドラインでの CoS 定義エントリーの作成

各タイプの CoS では、定義エントリーに特定のオブジェクトクラスを指定する必要があります。すべての CoS 定義オブジェクトクラスは、LDAPsubentry オブジェクトクラスと cosSuperDefinition オブジェクトクラスから継承されます。

ポインター CoS は cosPointerDefinition オブジェクトクラスを使用します。例7.2「Pointer CoS エントリーの例」に示されるように、このオブジェクトクラスは、cosTemplateDn 属性で指定されたエントリー DN 値を使用してテンプレートエントリーを識別します。

例7.2 Pointer CoS エントリーの例

 dn: cn=pointerCoS,dc=example,dc=com
 objectclass: top
 objectclass: cosSuperDefinition
 objectclass: cosPointerDefinition  
 cosTemplateDn:DN_string  
 cosAttribute:list_of_attributes qualifier  
 cn: pointerCoS

間接 CoS は cosIndirectDefinition オブジェクトクラスを使用します。このタイプの CoS は、cosIndirectSpecifier 属性で指定されているターゲットエントリーの属性のいずれかの値に基づいてテンプレートエントリーを識別します。これは、例7.3「間接的な CoS エントリーの例」で説明されています。

例7.3 間接的な CoS エントリーの例

 dn: cn=indirectCoS,dc=example,dc=com
 objectclass: top
 objectclass: cosSuperDefinition
 objectclass: cosIndirectDefinition  
 cosIndirectSpecifier:attribute_name  
 cosAttribute:list_of_attributes qualifier  
 cn: indirectCoS

クラス CoS は cosClassicDefinition オブジェクトクラスを使用します。これは、テンプレートエントリーの DN (cosTemplateDn 属性に設定) と、ターゲットエントリーの属性のいずれかの値 (cosSpecifier 属性に設定) の両方を使用してテンプレートエントリーを特定します。これは、例7.4「Classic CoS エントリーの例」で説明されています。

例7.4 Classic CoS エントリーの例

 dn: cn=classicCoS,dc=example,dc=com
 objectclass: top
 objectclass: cosSuperDefinition
 objectclass: cosClassicDefinition  
 cosTemplateDn:DN_string  
 cosSpecifier:attribute_name  
 cosAttribute:list_of_attributes qualifier  
 cn: classicCoS

サービスのクラスの場合、オブジェクトクラスは CoS のタイプを定義し、サポート属性は CoS テンプレートを定義することで影響を受けるディレクトリーエントリーを識別します。各 CoS には、定義できる属性が 1 つあります (cosAttribute)。CoS の目的は、複数のエントリーに属性値を提供することです。cosAttribute 属性は、CoS が生成する属性を定義します。

7.2.10.2. コマンドラインでの CoS テンプレートエントリーの作成

各テンプレートエントリーは、cosTemplate オブジェクトクラスのインスタンスです。

注記

新しいテンプレートエントリーに LDAPsubentry オブジェクトクラスを追加することを検討してください。CoS テンプレートエントリーを LDAPsubentry オブジェクトクラスのインスタンスに設定すると、通常の検索を設定エントリーに妨げられずに実行することができます。ただし、テンプレートエントリーがすでに存在し、ユーザーエントリーなどの他のものに使用される場合は、LDAPsubentry オブジェクトクラスをテンプレートエントリーに追加する必要はありません。

CoS テンプレートエントリーには、CoS (CoS 定義エントリーの cosAttribute 属性で指定) によって生成された属性とその属性の値も含まれます。

たとえば、postalCode 属性の値を提供する CoS テンプレートエントリーは、以下のようになります。

dn:cn=exampleUS,ou=data,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: cosTemplate
postalCode: 44438

以下のセクションでは、テンプレートエントリーの例と、各タイプの CoS 定義エントリーの例を示します。

「Pointer CoS の例」
「間接的な CoS の例」
「Classic CoS の例」

7.2.10.3. Pointer CoS の例

Corporation の管理者の例では、dc=example,dc=com ツリー内のすべてのエントリーと共通の郵便番号コードを共有するポインター CoS を作成します。

ldapmodify を使用して、新しい pointer CoS 定義エントリーを dc=example,dc=com 接尾辞に追加します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=pointerCoS,dc=example,dc=com
changetype: add
objectclass: top
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn=exampleUS,ou=data,dc=example,dc=com
cosAttribute: postalCode

テンプレートエントリーを作成します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=exampleUS,ou=data,dc=example,dc=com
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: cosTemplate
postalCode: 44438

CoS テンプレートエントリー (cn=exampleUS,ou=data,dc=example,dc=com) は、 postalCode 属性に保存された値を dc=example,dc=com 接尾辞に置かれているエントリーに提供します。これらのエントリーはターゲットエントリーです。

7.2.10.4. 間接的な CoS の例

この間接 CoS は、ターゲットエントリーの manager 属性を使用して CoS テンプレートエントリーを識別します。これは、属性の値によって異なります。

ldapmodify を使用して、dc=example,dc=com 接尾辞に新しい間接 CoS 定義エントリーを追加します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=indirectCoS,dc=example,dc=com
changetype: add
objectclass: top
objectclass: cosSuperDefinition
objectclass: cosIndirectDefinition
cosIndirectSpecifier: manager
cosAttribute: departmentNumber

ディレクトリーまたはマネージャーエントリーに departmentNumber 属性がすでに含まれる場合は、他の属性をマネージャーエントリーに追加する必要はありません。この属性は定義エントリーの cosIndirectSpecifier 属性に指定されるため、定義エントリーは manager 属性が含まれるエントリーのターゲット接尾辞 (dc=example,dc=com 下のエントリー) を検索します。次に、一覧表示された manager エントリーの departmentNumber 値を確認します。departmentNumber 属性の値は、manager 属性を持つマネージャーの下位すべてに自動的にリレーされます。departmentNumber の値は、異なるマネージャーのエントリーに記載されている部門番号によって異なります。

7.2.10.5. Classic CoS の例

Corporation の例の管理者は、テンプレート DN と cosSpecifier 属性で指定された属性の組み合わせを使用して、郵便番号コードを自動的に生成する Classic CoS を作成します。

ldapmodify を使用して、新しいクラス CoS 定義エントリーを dc=example,dc=com 接尾辞に追加します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=classicCoS,dc=example,dc=com
changetype: add
objectclass: top
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: cn=classicCoS,dc=example,dc=com
cosSpecifier: businessCategory
cosAttribute: postalCode override

営業部門およびマーケティング部門のテンプレートエントリーを作成します。CoS 属性をテンプレートエントリーに追加します。テンプレートの cn は、ターゲットエントリーの businessCategory 属性の値を設定し、テンプレートの値に応じて属性を追加または上書きされます。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=sales,cn=classicCoS,dc=example,dc=com
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: cosTemplate
postalCode: 44438
-
dn: cn=marketing,cn=classicCoS,dc=example,dc=com
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: cosTemplate
postalCode: 99111

Classic CoS 定義エントリーは、dc=example,dc=com 接尾辞の下にあるすべてのエントリーに適用されます。エントリー内の businessCategory 属性と cosTemplateDn の組み合わせによって、2 つのテンプレートのいずれかに到達できます。1 つ目は営業テンプレートで、営業部門に従業員固有の郵便番号コードを提供します。マーケティングテンプレートは、マーケティング部門の従業員固有の郵便番号コードを提供します。

7.2.10.6. CoS エントリーの検索

CoS 定義エントリーは 操作上 のエントリーで、デフォルトでは、通常の検索では返されません。検索の CoS 定義エントリーを返すには、ldapSubEntry オブジェクトクラスを CoS 定義エントリーに追加します。以下に例を示します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=pointerCoS,ou=People,dc=example,dc=com
changetype: add
objectclass: ldapSubEntry

次に、ldapsearch ユーティリティーで (objectclass=ldapSubEntry) フィルターを使用して、ldapSubEntry オブジェクトクラスを含むエントリーを検索します。以下に例を示します。

# ldapsearch -x -s sub -b ou=People,dc=example,dc=com "(|(objectclass=*)(objectclass=ldapSubEntry))"

この検索は、ou=People,dc=example,dc=com サブツリーの CoS 定義エントリーに加えて、すべての通常のエントリーを返します。

7.2.10.7. costargettree 属性

costargettree 属性は、CoS スキーマが適用されるサブツリーを定義します。スキーマと複数の CoS スキーマの costargettree の値は、任意にターゲットツリーと重複する可能性があります。

表7.1 costargettree 属性

OID	2.16.840.1.113730.3.1.552
Syntax	DirectoryString
多値または単一値	単一値
定義される場所	Directory Server

7.2.11. ロールベースの属性の作成

Classic CoS スキームは、エントリーが所有するロールに基づいてエントリーの属性値を生成します。たとえば、ロールベースの属性を使用して、エントリーごとにサーバーのルックスルー制限を設定できます。

ロールベースの属性を作成するには、Classic CoS の CoS 定義エントリーで nsRole 属性を cosSpecifier として使用します。nsRole 属性が多値指定できるため、複数のテンプレートエントリーを持つ CoS スキームを定義できます。使用するテンプレートエントリーの曖昧さを解決するには、CoS テンプレートエントリーに cosPriority 属性を追加します。

たとえば、この CoS は manager ロールのメンバーが標準のメールボックスクォータを超過できるようにします。マネージャーのロールエントリーは次のとおりです。

dn: cn=ManagerRole,ou=people,dc=example,dc=com
objectclass: top
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: ManagerRole
nsRoleFilter: ou=managers
Description: filtered role for managers

警告

nsRoleFilter 属性は仮想属性の値を受け付けません。

仮想属性値にインデックスを付けないでください。仮想属性で検索を実行すると、予期しないシステム動作や不正確な検索結果が発生する可能性があります。インデックス付けされていない検索は、検索フィルターで仮想属性を使用する検索アクションを中断します。仮想属性は動的に生成され、Directory Server バックエンドには保存されません。したがって、仮想属性はインデックス付けをサポートしていません。

Classic CoS 定義エントリーは以下のようになります。

dn: cn=managerCOS,dc=example,dc=com
objectclass: top
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDn: cn=managerCOS,dc=example,dc=com
cosSpecifier: nsRole
cosAttribute: mailboxquota override

cosTemplateDn 属性は、cosSpecifier 属性で指定された属性 (ターゲットエントリーの nsRole 属性) とともに CoS テンプレートエントリーを識別する値を提供します。CoS テンプレートエントリーは、mailboxquota 属性の値を提供します。override の他の修飾子は、ターゲットエントリーの既存の mailboxquota 属性値をオーバーライドするように、CoS に指示します。

対応する CoS テンプレートエントリーは以下のようになります。

dn:cn="cn=ManagerRole,ou=people,dc=example,dc=com",cn=managerCOS,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: cosTemplate
mailboxquota: 1000000

テンプレートは、mailboxquota 属性の値 1000000 を指定します。

注記

ロールエントリーと CoS 定義およびテンプレートエントリーは、ディレクトリーツリーの同じレベルにある必要があります。

7.3. 属性値の管理属性のリンク

サービスのクラスは、住所、郵便番号コード、主なオフィス番号など、すべて 同じ値 の属性を持つエントリーの属性値を動的に提供します。これらは共有属性値であり、単一のテンプレートエントリーで更新されます。

多くの場合、エントリー間には、それらの間のリンクを表現する方法が必要な関係がありますが、その関係を表現する値 (および場合によっては属性) は異なります。Red Hat Directory Server は、指定された属性を繋ぎ合わせる方法を提供するため、1 つのエントリーの属性が変更すると、関連するエントリーの対応する属性が自動的に更新されます。(リンクおよび管理属性の両方に DN の値があります。リンク属性の値には、更新するプラグインのエントリーの DN が含まれます。2 つ目のエントリーの管理属性には、元のリンクエントリーを参照する DN の値があります。)

7.3.1. リンク元属性の概要

リンク先属性プラグインは、プラグインの複数のインスタンスを許可します。各インスタンスは、管理者によって手動で維持される 1 つの属性 (linkType) およびプラグインによって自動的に維持される 1 つの属性 (managedType) を設定します。

図7.5 リンク先属性の基本設定

注記

データの一貫性を維持するには、プラグインプロセスのみが管理属性を維持する必要があります。管理属性へのすべての書き込みアクセスを制限する ACI の作成を検討してください。ACI の設定に関する詳細は、「ACI の追加」を参照してください。

リンク先属性プラグインインスタンスは、ディレクトリー内の単一のサブツリーに制限できます。これにより、属性の組み合わせと影響を受けるエントリーのより柔軟なカスタマイズが可能になります。スコープが設定されていない場合、プラグインはディレクトリー全体で動作します。

図7.6 リンク先属性プラグインを特定のサブツリーに制限

リンク先属性プラグインインスタンスを設定する場合は、特定の設定が必要です。

管理属性とリンク先属性の両方で、属性定義で識別名の構文が必要です。リンク先属性は基本的にクロス参照で管理されます。プラグインがこれらの相互参照を処理する方法は、属性値からエントリーの DN をプルすることで行われます。
カスタムスキーマ要素のプランニングに関する情報は、12章ディレクトリースキーマの管理を参照してください。
各リンク先属性プラグインインスタンスはローカルで、管理属性は一部レプリケーションを使用してレプリケーションからブロックする必要があります。
あるサプライヤーに加えられた変更は、プラグインが自動的に発生し、対応するディレクトリーエントリーの値を管理するため、データはサーバー全体で一貫性を維持します。ただし、リンクされたエントリー間でデータの一貫性を保つには、プラグインインスタンスで管理属性を維持する必要があります。つまり、管理属性値は、マルチサプライヤーレプリケーション環境であっても、レプリケーションプロセスではなく、プラグインプロセスによってのみ維持される必要があります。
一部レプリケーションの使用方法は、「一部レプリケーションを使用した属性のサブセットの複製」を参照してください。

7.3.2. リンク元属性プラグイン構文の確認

デフォルトのリンク先属性プラグインエントリーは、各プラグインインスタンスのコンテナーエントリーです。これは、次のセクションの password 構文プラグインや DNA プラグインに類似します。このコンテナーエントリーの下にある各エントリーは、異なるリンク管理属性ペアを定義します。

新しいリンク元属性ペアを作成するには、コンテナーエントリーの下に新しいプラグインインスタンスを作成します。基本的なリンク元属性プラグインインスタンスでは、以下の 2 つの項目を定義する必要があります。

linkType 属性において、管理者が手動で管理する属性
managedType 属性に含まれる、プラグインによって動的に作成される属性
必要に応じて、プラグインを linkScope 属性のディレクトリーツリーの特定の部分に制限するスコープ

例7.5 リンク先属性のプラグインインスタンスエントリーの例

dn: cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: Manager Link
linkType: directReport
managedType: manager
linkScope: ou=people,dc=example,dc=com

Linked Attributes プラグインのインスタンスで利用可能な属性の一覧は、Red Hat Directory Server Configuration, Command, and File Referenceの該当するセクションを参照してください。

7.3.3. 属性リンクの設定

これが有効になっていない場合は、Linked Attributes プラグインを有効にします。詳細については、「プラグインの有効化および無効化」を参照してください。
プラグインインスタンスを作成します。--managed-type パラメーターおよび --link-type パラメーターの両方が必要です。以下の例は、dsconf を使用して作成したプラグインインスタンスを示しています。
```
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin linked-attr config "Manager Link" add --link-type=directReport --managed-type=manager
```
インスタンスを再起動します。
```
# dsctl instance_name restart
```

7.3.4. 属性リンクのクリーンアップ

管理属性とリンク先属性は同期しなくなる可能性があります。たとえば、リンク先属性をサーバーにインポートまたは複製できましたが、リンク属性が適切に設定されていなかったため、対応するマネージド属性はインポートされませんでした。管理属性とリンク先属性ペアは、dsconf plugin linked-attr fixup コマンドを実行するか、修正タスクを起動することで修正できます。

修正タスクは、参照エントリーに対応するリンク属性 (管理者が管理する属性) のない管理属性 (プラグインによって管理される属性) を削除します。逆に、エントリーにリンク属性が存在する場合は、タスクで不明な管理属性が追加されます。

7.3.4.1. リンク先属性の再生成

dsconf plugin linked-attr fixup コマンドは特殊なタスクを起動し、ディレクトリーエントリー上の管理属性とリンク属性のペアをすべて再生成します。特定の状況では、1 つまたはもう 1 つが失われる可能性があります。リンク属性がエントリーに存在する場合、タスクは利用可能な属性でクロス参照されている DN を追跡し、参照されたエントリーで対応する管理属性を作成します。対応するリンク属性のない管理属性が存在する場合は、管理属性値が削除されます。

プラグインのスコープ全体に設定されたリンク属性ペアをすべて修復するには、Directory Manager で以下のコマンドを実行します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin linked-attr fixup

また、ベース DN をコマンドに渡して、修正タスクを単一のリンク管理属性ペアに制限することもできます。以下に例を示します。

# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin linked-attr fixup "cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config"

7.3.4.2. ldapmodify を使用したリンク先属性の再生成

リンクされた属性の修復は、特別なタスク設定エントリーで管理できるタスクの 1 つです。タスクエントリーは、dse.ldif ファイルの cn=tasks 設定エントリーで発生するため、ldapmodify を使用してエントリーを追加してタスクを開始することもできます。タスクが完了すると、エントリーはディレクトリーから削除されます。

このタスクは、実行時に dsconf plugin linked-attr fixup コマンドによって自動的に作成されるタスクと同じです。

リンク付きの属性修正タスクを開始するには、cn=fixup linked attributes,cn=tasks,cn=config エントリーの下にエントリーを追加します。必要な属性は特定タスクの cn のみですが、ttl 属性にはタイムアウト期間を設定できます。ldapmodify の使用:

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=example,cn=fixup linked attributes,cn=tasks,cn=config
changetype: add
cn:example
ttl: 5

タスクが完了すると、エントリーは dse.ldif 設定から削除されるため、同じタスクエントリーを継続的に再利用できます。

cn=fixup linked attributes タスク設定は、『Configuration, Command, and File Reference』を参照してください。

7.4. 一意の数値属性値の割り当ておよび管理

エントリー属性によっては、uidNumber や gidNumber などの一意の番号が必要です。Directory Server は、DNA (Distributed Numeric Assignment) プラグインを使用して、指定された属性に一意の番号を自動的に生成して提供できます。

注記

属性の一意性 は、DNA プラグインで維持されるとは限りません。プラグインは、オーバーランディングの範囲のみを割り当てますが、管理属性に手動で割り当てる数字を許可し、手動で割り当てられた数字が一意であることを検証せず、必要とされません。

一意の数字を割り当てる問題は、数字の生成ではなく、レプリケーションの競合を回避することで問題となります。DNA プラグインは、単一のバックエンド全体に一意の番号を割り当てます。マルチプライヤーレプリケーションの場合、各プライヤーがローカル DNA プラグインインスタンスを実行しているときに、各インスタンスが真に一意の番号セットを使用していることを確認する方法が必要です。これは、割り当てる各サーバーに異なる範囲を割り当てることで行われます。

7.4.1. 動的番号の割り当ての概要

サーバーの DNA プラグインは、そのインスタンスが発行することのできる利用可能な数字の範囲を割り当てます。範囲の定義は非常にシンプルで、サーバーの次に利用可能な番号 (範囲の下限) と最大値 (範囲の最後) の 2 つの属性で設定されます。初期の下限範囲は、プラグインインスタンスを設定する際に設定されます。その後、下部の値はプラグインによって更新されます。利用可能な数を各レプリカの複数の範囲に分割することで、サーバーはすべて、互いに重複することなく、継続的に番号を割り当てることができます。

7.4.1.1. フィルター、検索、およびターゲットエントリー

(「標準インデックスの作成」で説明されているように) サーバーは、内部的にソートされた検索を実行し、次に指定された範囲がすでに取得されているかどうかを確認し、管理属性に適切な順序のマッチングルールと同じインデックスを割り当てる必要があります。

DNA プラグインは、常にディレクトリーツリーの特定領域 (スコープ) と、そのサブツリー内の特定のエントリータイプ (フィルター) に適用されます。

重要

DNA プラグインは 1 つのバックエンドでのみ機能します。複数のデータベースの番号割り当ては管理できません。DNA プラグインは、DNA プラグイン以外で値がすでに割り当てられているかどうかを確認する際に、ソートコントロールを使用します。この検証は、ソートコントロールを使用して単一のバックエンドでのみ機能します。

7.4.1.2. 範囲および割り当て番号

Directory Server が属性値の生成を処理する方法は複数あります。

最も単純なケースでは、属性がない場合に、unique-number 属性を必要とするオブジェクトクラスを持つディレクトリーにユーザーエントリーが追加されます。管理属性に値を持たないエントリーを追加すると、DNA プラグインによる値の割り当てが発生します。このオプションは、一意の値を 1 つの属性に割り当てるように DNA プラグインが設定されている場合に限り機能します。
同様の管理可能なオプションは、マジック番号 を使用することです。このマジックナンバーは、マネージド属性のテンプレート値であり、サーバーの範囲外のもの、数字、または単語でさえあり、プラグインは新しい割り当て値に置き換える必要があると認識します。マジック値でエントリーが追加され、エントリーが設定された DNA プラグインの範囲およびフィルター内にある場合は、プラグインでマジック番号を使用した新しい値の生成が自動的に発生します。下の例では、ldapmodify の使用に基づいて、0 をマジックナンバーとして追加します。
```
dn: uid=jsmith,ou=people,dc=example,dc=com
 changetype: add
 objectClass: top
 objectClass: person
 objectClass: posixAccount
 uid: jsmith
 cn: John Smith
 uidNumber: 0
 gidNumber: 0
 ....
```
DNA プラグインは、新規の一意の値のみを生成します。DNA プラグインが制御する属性に特定の値を使用するためにエントリーを追加または変更した場合には、指定した番号が使用されます。DNA プラグインは、その番号を上書きしません。

7.4.1.3. 同じ範囲の複数の属性

DNA プラグインは、1 つの属性タイプに、または 1 つの範囲の一意の番号から複数の属性タイプに一意の番号を割り当てることができます。

これにより、属性に一意の数字を割り当てるためのオプションが複数提供されます。

一意の番号の 1 つの範囲から、1 つの属性タイプに割り当てられた 1 つの番号。
1 つのエントリーの 2 つの属性に割り当てられた同じ一意の番号。
2 つの異なる属性は、同じ範囲の一意の数字から 2 つの異なる数字を割り当てていました。

多くの場合は、属性タイプごとに一意の番号を割り当てるだけで十分です。新しい従業員エントリーに employeeID を割り当てる際には、各従業員エントリーに一意の employeeID が割り当てられます。

ただし、同じ範囲の数字から複数の属性に一意の番号を割り当てることが役に立つ場合もあります。たとえば、uidNumber と gidNumber を posixAccount エントリーに割り当てると、DNA プラグインは同じ数を両方の属性に割り当てます。これを行うには、マジック値を指定して、両方の管理属性を変更操作に渡します。ldapmodify の使用:

#  ldapmodify -D "cn=Directory Manager" -W -x

dn: uid=jsmith,ou=people,dc=example,dc=com
changetype: modify
add: uidNumber
uidNumber: 0
-
add:gidNumber
gidNumber: 0

DNA プラグインで複数の属性を処理する場合は、オブジェクトクラスが 1 つしか許可されない場合、プラグインはこれらの属性の 1 つにのみ一意の値を割り当てることができます。たとえば、posixGroup オブジェクトクラスは uidNumber 属性を許可しませんが、gidNumber を許可します。DNA プラグインが uidNumber と gidNumber の両方を管理する場合は、posixGroup エントリーが作成されると、gidNumber の一意の番号が uidNumber および gidNumber 属性と同じ範囲から割り当てられます。プラグインが管理するすべての属性に同じプールを使用すると、一意の数字の割り当てを維持し、異なるエントリーの uidNumber と gidNumber が異なる範囲から割り当てられ、同じ一意の番号になる状況を防ぐことができます。

複数の属性が DNA プラグインで処理される場合は、1 つの変更操作のエントリーで指定の管理属性のすべてに同じ値が割り当てられます。同じ範囲から別の数字を割り当てるには、別の変更操作を実施する必要があります。以下の例では、ldapmodify を使用してこれを行います。

# ldapmodify -D "cn=Directory Manager" -W -x
dn: uid=jsmith,ou=people,dc=example,dc=com
changetype: modify
add: uidNumber
uidNumber: 0
^D

# ldapmodify -D "cn=Directory Manager" -W -x
dn: uid=jsmith,ou=people,dc=example,dc=com
changetype: modify
add: employeeId
employeeId: magic

重要

DNA プラグインが一意の数字を複数の属性に割り当てるように設定する場合は、一意の番号を必要とする各属性にマジック値を指定する必要があります。1 つの属性に一意の番号を提供するように DNA プラグインが設定されている場合には、これは必須ではありませんが、複数の属性に必要です。エントリーが範囲に対して定義された各タイプの属性を許可しない場合や、さらに重要なことに、定義されたすべての属性タイプをエントリーが許可しますが、属性のサブセットのみが一意の値を必要とする場合があります。

例7.6 DNA および一意の銀行口座番号

銀行の例では、顧客の primaryAccount 属性および customerID 属性に同じ一意の番号を使用します。銀行の例の管理者は、DNA プラグインが同じ範囲から両方の属性に一意の値を割り当てるよう設定していました。

また、銀行では、顧客 ID とプライマリーの口座番号と同じ範囲のセカンダリー口座に番号を割り当てますが、これらの数字をプライマリーの口座番号と同じにすることはできません。銀行の例の管理者は、DNA プラグインも secondaryAccount 属性を管理するように設定しますが、エントリーの作成、secondaryAccount 属性および primaryAccount 属性の割り当ての後にのみ customerID 属性を追加します。これにより、primaryAccount および customerID は、同じ一意の番号を共有し、secondaryAccount 番号は完全に一意ですが、それでも同じ範囲の番号からのものです。

Language and Page Formatting Options

管理ガイド

Directory Server の基本および高度な管理

多様性を受け入れるオープンソースの強化

第1章 一般的な Directory Server 管理タスク

1.1. システム要件

1.2. ファイルの場所

1.3. Directory Server を設定するサポート対象のメソッド

1.4. Web コンソールを使用した Directory Server へのログイン

1.5. Directory Server インスタンスの起動および停止

1.5.1. コマンドラインを使用した Directory Server インスタンスの起動および停止

1.5.2. Web コンソールを使用した Directory Server インスタンスの起動および停止

1.6. 新規 Directory Server インスタンスの作成

1.7. Directory Server インスタンスの削除

1.7.1. コマンドラインを使用したインスタンスの削除

1.7.2. Web コンソールを使用したインスタンスの削除

1.8. Directory Server の設定パラメーターの設定

1.8.1. 設定パラメーターの管理

1.8.2. Directory Server が設定を保存する場所

1.8.3. デフォルト値を使用する利点

1.8.3.1. デフォルト値を使用するパラメーターの削除

1.8.4. dsconf config backend コマンドの制限事項

1.9. LDAP および LDAPS ポート番号の変更

1.9.1. コマンドラインを使用したポート番号の変更

1.9.2. Web コンソールを使用したポート番号の変更

1.10. Directory Server プラグインの使用

1.10.1. 利用可能なプラグインのリスト表示

1.10.1.1. コマンドラインを使用した利用可能なプラグインのリスト表示

1.10.1.2. Web コンソールを使用した利用可能なプラグインのリスト表示

1.10.2. プラグインの有効化および無効化

1.10.2.1. コマンドラインでプラグインの有効化および無効化

1.10.2.2. Web コンソールを使用したプラグインの有効化および無効化

1.10.3. プラグインの設定

1.10.3.1. コマンドラインでプラグインの設定

1.10.3.2. Web コンソールを使用したプラグインの設定

1.10.4. プラグインの優先順位の設定

1.10.4.1. コマンドラインを使用したプラグインの優先順位の設定

1.10.4.2. Web コンソールを使用したプラグインの優先順位の設定

1.11. .dsrc ファイルを作成して使用し、Directory Server コマンドラインユーティリティーのデフォルトオプションを設定する

1.11.1. .dsrc ファイルがコマンドを簡素化する方法

1.11.2. dsctl ユーティリティーを使用して .dsrc ファイルを作成する

1.11.3. Directory Server ユーティリティー使用時のリモートおよびローカル接続の解決

第2章 ディレクトリーデータベースの設定

2.1. 接尾辞の作成および維持

2.1.1. 接尾辞の作成

2.1.1.1. ルート接尾辞の作成

2.1.1.1.1. コマンドラインでルート接尾辞の作成

2.1.1.1.2. Web コンソールを使用したルート接尾辞の作成

2.1.1.2. 従属接尾辞の作成

2.1.1.2.1. コマンドラインを使用した従属接尾辞の作成

2.1.1.2.2. Web コンソールを使用した副接尾辞の作成

2.1.2. 接尾辞の維持

2.1.2.1. デフォルトの命名コンテキストの表示

2.1.2.2. 接尾辞の無効化

2.1.2.2.1. コマンドラインでの接尾辞の無効化

2.1.2.3. 接尾辞の削除

2.1.2.3.1. コマンドラインを使用した接尾辞の削除

2.1.2.3.2. Web コンソールを使用した接尾辞の削除

2.2. データベースの作成および維持

2.2.1. データベースの作成

2.2.1.1. コマンドラインを使用した単一の接尾辞用の新規データベースの作成

2.2.1.2. 単一の接尾辞に複数のデータベースの追加

2.2.2. Directory データベースの維持

2.2.2.1. 読み取り専用モードでのデータベースの設定

2.2.2.1.1. コマンドラインを使用した読み取り専用モードでのデータベースの設定

2.2.2.1.2. Web コンソールを使用した読み取り専用モードでのデータベースの設定

2.2.2.2. 読み取り専用モードでの Directory Server の配置

2.2.2.2.1. コマンドラインを使用した読み取り専用モードでの Directory Server の配置

2.2.2.2.2. Web コンソールを使用した読み取り専用モードでの Entire Directory Server の配置

2.2.2.3. データベースの削除

2.2.2.3.1. コマンドラインを使用したデータベースの削除

2.2.2.3.2. Web コンソールを使用したデータベースの削除

2.2.2.4. トランザクションログディレクトリーの変更

2.3. データベースリンクの作成および維持

2.3.1. 新規データベースリンクの作成

2.3.1.1. コマンドラインを使用した新規データベースリンクの作成

2.3.1.2. Web コンソールを使用した新規データベースリンクの作成

2.3.1.3. 新規データベースリンクのデフォルト設定の管理

2.3.1.4. データベースリンクの作成時に必要な設定に関する追加情報

接尾辞情報

第1章一般的な Directory Server 管理タスク

1.8.4. `dsconf config backend` コマンドの制限事項

第2章ディレクトリーデータベースの設定

第3章ディレクトリーエントリーの管理