Red Hat Training

A Red Hat training course is available for Red Hat Directory Server

管理ガイド

Red Hat Directory Server 10

Directory Server 10.6 の更新

概要

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

このドキュメントは維持されなくなりました。詳細は、非推奨のドキュメントを参照してください。

非推奨のドキュメント

重要

2020 年 11 月 30 日にて、Red Hat Directory Server 10 のサポート終了は終了しました。詳細は、「「Red Hat Directory Server Life Cycle policy」」を参照してください。Red Hat は、Directory Server 10 を最新バージョンに更新することを推奨します。

本製品のメンテナンスフェーズの終了により、本ドキュメントは更新されなくなりました。参照資料としてのみご使用ください。

第1章 Red Hat Directory Server の基本設定

Red Hat Directory Server にはディレクトリーサービス、複数のサーバーインスタンスを管理する管理サーバー、およびグラフィカルインターフェースを使用してサーバーインスタンスを管理するための Java ベースのコンソールが含まれています。本章では、ディレクトリーサービスを管理する基本的なタスクの概要を説明します。

Directory Server は、ユーザーおよびリソースのエンタープライズ全体のディレクトリーを管理するために設計された、堅牢でスケーラブルなサーバーです。LDAP(Lightweight Directory Access Protocol)と呼ばれるオープンシステムサーバープロトコルに基づいています。サーバーはディレクトリーデータベースを管理し、クライアント要求に応答します。

Directory Server は、連携する複数のコンポーネントで構成されています。

Directory Server は、コア LDAP サーバーデーモンです。これは LDAP v3 標準に準拠しています。このコンポーネントには、データベースのエクスポートやバックアップなどの一般的な操作を行うためのコマンドラインサーバー管理プログラムおよびスクリプトが含まれます。
Directory Server コンソールは、ユーザー、グループ、およびその他の LDAP データの管理を簡素化するユーザーインターフェースです。コンソールは、バックアップ、セキュリティー、レプリケーション、データベース設定、サーバーの監視、統計の表示など、サーバー管理のすべての側面に使用されます。
管理サーバーは、Directory Server インスタンスを管理する管理エージェントです。Directory Server コンソールと通信し、Directory Server インスタンスで操作を実行します。また、簡単な HTML インターフェースおよびオンラインヘルプページも提供します。

コマンドラインユーティリティーを使用して Directory Server を管理できますが、Directory Server コンソールを使用することもできます。

1.1. システム要件

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

1.2. ファイルの場所

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

1.3. Directory Server 管理コンソールの起動

管理コンソールは、以下のような管理タスクを実行できるグラフィカルユーザーインターフェースを提供します。

Directory Server インスタンスの管理
管理サーバーの管理
ユーザーおよびグループの管理

注記

管理コンソールは Java を使用します。サポートされる Java ランタイム環境およびバージョンの詳細は、『『Red Hat Directory Server リリースノート』を参照してください』。

管理コンソールを開くには、次のコマンドを入力します。

# redhat-idm-console

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

1.3.1. Directory Server コンソールを開く

Directory Server 管理コンソールを起動します。
```
# redhat-idm-console
```
cn=Directory Manager ユーザーとしてログインします。
Servers and Applications タブで administration_domain_namehost_name → Server GroupDirectory Server(instance_name) に移動し、Open をクリックします。

1.3.2. 管理コンソールを開く

Directory Server 管理コンソールを起動します。
```
# redhat-idm-console
```
cn=Directory Manager ユーザーとしてログインします。
Servers and Applications タブで administration_domain_namehost_name → Server Group → Administration Server に移動し、Open をクリックします。

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

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

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

インスタンスを起動するには、以下のコマンドを実行します。
```
# systemctl start dirsrv@instance_name
```
インスタンスを停止するには、以下のコマンドを実行します。
```
# systemctl stop dirsrv@instance_name
```
インスタンスを再起動するには、以下のコマンドを実行します。
```
# systemctl restart dirsrv@instance_name
```

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

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

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

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

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

重要

SELinux を Enforcing モードで実行する場合は、コンソールを使用してインスタンスの起動または停止を行うことはできません。この問題を回避するには、コマンドラインを使用してサービスを管理します。「Directory Server インスタンスの起動および停止」を参照してください。

重要

インスタンスの TLS 暗号化を有効にすると、インスタンスの起動時に Directory Server は TLS 証明書のパスワードを要求します。Directory Server コンソールでは、GUI にこのパスワードプロンプトを表示できません。この問題を回避するには、以下を実行します。

コマンドラインを使用してサービスを管理します。「コマンドラインを使用した Directory Server インスタンスの起動および停止」を参照してください。
パスワードファイルを作成します。「Directory Server のパスワードファイルの作成」を参照してください。

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

Directory Server コンソールを起動し、cn=Directory Manager ユーザー名を使用してログインします。
詳細は、「管理コンソールを開く」を参照してください。
Servers and Applications タブで administration_domain_namehost_name → Server GroupDirectory Server(instance_name) に移動し、Open をクリックします。
Tasks タブで、実行するタスクをクリックします。
Yes をクリックして確定します。

タスクが終了すると、操作が成功したか、失敗した場合に、コンソールにメッセージが表示されます。

1.5. Directory Server 管理サーバーサービスの起動と停止

管理コンソールは、Directory Server コンソール（Directory Server を管理する GUI）を提供します。

1.5.1. コマンドラインを使用した管理サーバーサービスの起動と停止

systemctl ユーティリティーを使用して、管理サーバーサービスを起動、停止、または再起動します。

サービスを起動するには、以下を実行します。
```
# systemctl start dirsrv-admin
```
サービスを停止するには、以下を実行します。
```
# systemctl stop dirsrv-admin
```
サービスを再起動するには、以下を実行します。
```
# systemctl restart dirsrv-admin
```

必要に応じて、システムの起動時に管理サーバーが自動的に起動するようにします。

# systemctl enable dirsrv-admin

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

1.5.2. コンソールを使用した管理サーバーのサービスの再起動および停止

管理サーバーサービスを再起動または停止するには、以下を実行します。

Directory Server コンソールを起動し、cn=Directory Manager ユーザー名を使用してログインします。
詳細は、「管理コンソールを開く」を参照してください。
Servers and Applications タブで administration_domain_namehost_name → Server Group → Administration Server に移動し、Open をクリックします。
Tasks タブで、実行するタスクをクリックします。
Yes をクリックして確定します。

タスクが終了すると、操作が成功したか、失敗した場合に、コンソールにメッセージが表示されます。

1.6. LDAPI の有効化

IPC( Inter-process communication )は、Unix マシン上のプロセスや、ネットワークが互いに直接通信するための方法です。LDAPI により、LDAP 接続は IPC 接続で実行できます。つまり、LDAP 操作は Unix ソケット上で実行できます。これらの接続は、通常の LDAP 接続よりもはるかに高速で、より安全です。

LDAPI は、2 つの設定属性を使用して有効になります。

nsslapd-ldapilisten Directory Server の LDAPI を有効にするには、以下を実行します。
nsslapd-ldapifilepath Unix ソケットファイルを参照する

LDAPI を有効にするには、以下を実行します。

nsslapd-ldapilisten を変更して LDAPI をオンにし、ソケットファイル属性を追加します。

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

dn: cn=config
changetype: modify
replace: nsslapd-ldapilisten
nsslapd-ldapilisten: on
-
add: nsslapd-ldapifilepath
nsslapd-ldapifilepath: /var/run/slapd-example.socket

サーバーを再起動して、新しい設定を適用します。
```
# systemctl restart dirsrv@instance
```

1.7. Directory Server ポート番号の変更

Directory Server が使用する標準およびセキュアな LDAP ポート番号は、Directory Server Console で変更するか、dse.ldif の cn=config エントリー下の nsslapd-port または nsslapd-secureport 属性の値を変更することで変更できます。

注記

o=NetscapeRoot サブツリーを維持する Configuration Directory Server の標準またはセキュアなポート番号を変更することは、Directory Server コンソールを介して行う必要があります。

1.7.1. 標準ポート番号の変更

Directory Server コンソールの Configuration タブを選択し、左側のペインのナビゲーションツリーでトップエントリーを選択します。
右側のペインで Settings タブを選択します。
ポート番号を変更します。Port フィールドで TLS 以外の通信に使用するサーバーのポート番号。デフォルト値は 389 です。
Save をクリックします。
コンソールは警告を返します。設定ディレクトリーのポート番号を変更します。これは、このディレクトリーを使用するすべての管理サーバーに影響が及ぶため、新しいポート番号で更新する必要があります。ポート番号を変更してもよろしいですか？Yes をクリックします。
その後、サーバーが再起動するまで変更が反映されないことを示すダイアログが表示されます。OK をクリックします。
注記
この時点で Directory Server を再起動しないでください。有効にすると、コンソールを介して管理コンソールに必要な変更を加えることはできません。
管理コンソールを開きます。
Configuration タブで Configuration DS タブを選択します。
LDAP ポートフィールドで、Directory Server インスタンスの新しい LDAP ポート番号を入力します。
Directory Server ポートの SELinux ラベルを変更し、新しいポート番号を Directory Server ポリシーで使用できるようにします。以下に例を示します。
```
# semanage port -a -t ldap_port_t -p tcp 1389
```
警告
SELinux ラベルがリセットされない場合、Directory Server は再起動できなくなります。
Directory Server コンソールの Tasks タブで、Restart Directory Server をクリックします。サーバーを再起動することを確認するダイアログ。Yes をクリックします。
管理コンソールの Configuration DS タブを開き、Save を選択します。
ダイアログが表示され、読み取り Directory Server 設定が変更されました。変更を有効にするには、管理サーバーとサーバーグループのすべてのサーバーをシャットダウンする必要があります。OK をクリックします。
管理コンソールの Tasks タブで、Restart Admin Server をクリックします。管理サーバーが正常に再起動したことを示すダイアログが開きます。Close をクリックします。
注記
コンソールで その他の操作を行う前に、コンソールを閉じて再度開く必要があります。更新してもコンソールを更新できず、何も実行しようとすると、Unable to contact LDAP server という警告が表示されます。

1.7.2. LDAPS ポート番号の変更

設定ディレクトリーまたはユーザーディレクトリーのポートを変更するか、またはポート番号の変更には以下のような要件があります。

また、管理サーバー設定で Directory Server のポート番号も更新する必要があります。
設定またはユーザーディレクトリーを参照するその他の Directory Server インスタンスがある場合は、これらのサーバーを更新して新しいポート番号を指定します。

LDAPS ポートを変更するには、以下を実行します。

Directory Server インスタンスの証明書を発行するために使用する CA 証明書が Administration Server 証明書データベースにあることを確認します。Administration Server の CA 証明書のインポートは、「CA 証明書のインストール」で説明されている Directory Server プロセスと同じです。
「標準ポート番号の変更」のプロセスと同様に、Directory Server Console を使用してセキュアなポートを設定できます（暗号化ポートフィールドに値のみの設定のみ）。ただし、同じマシンに複数の Directory Server インスタンスがある場合など、Directory Server コンソールからポート番号を変更できない場合があります。ldapmodify を使用してポート番号を変更 することが推奨されます。
以下に例を示します。
```
# ldapmodify -x -h server.example.com -p 1389 -D "cn=Directory Manager" -W
dn: cn=config
replace: nsslapd-securePort
nsslapd-securePort: 1636
```

Administration Server 設定(o=netscaperoot)で Directory Server インスタンスの対応するポート設定を編集します。

まず、現在の設定を検索します。

# ldapsearch -x -h config-ds.example.com -p 389 -D "cn=Directory Manager" -W -b "cn=slapd-ID,cn=389 Directory Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot" -s base "(objectclass=*)"
nsSecureServerPort

dn: cn=slapd-ID,cn=389 Directory Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot
nsSecureServerPort: 636

次に、設定を編集します。

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

dn: cn=slapd-ID,cn=389 Directory Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot
replace: nsSecureServerPort
nsSecureServerPort: 1636

インスタンスの Directory Server コンソールを起動し、新しい LDAPS ポート番号が Configuration タブに一覧表示されていることを確認します。
必要に応じて、Console で SSL を使用するチェックボックスを選択します。
Directory Server ポートの SELinux ラベルを変更し、新しいポート番号を Directory Server ポリシーで使用できるようにします。以下に例を示します。
```
# semanage port -a -t ldap_port_t -p tcp 1636
```
警告
SELinux ラベルがリセットされない場合、Directory Server は再起動できなくなります。
Directory Server インスタンスを再起動します。

1.8. Directory Server インスタンスの管理

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

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

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

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

その他のインスタンスをすべてアンインストールしたり、管理サーバーインスタンスを削除したり、パッケージを削除したりせずに Directory Server の 1 つのインスタンスを削除できます。

# remove-ds.pl -i slapd-instance_name -a

remove-ds.pl スクリプトは、- a (all)オプションが指定されている場合は、関連するファイルおよびディレクトリーを削除します。ただし、Directory Server インスタンスは、設定 Directory Server から登録解除されません。

デフォルトでは、鍵と証明書 ファイルは インスタンス設定ディレクトリーに残り、設定ディレクトリーの名前が slapd-instance-name.removed になります。（以下に示すように） -a オプションを使用すると、セキュリティーデータベースも削除されます。

注記

インストールの失敗やサーバーを再起動するなど、Directory Server に問題が発生した場合には、remove-ds.pl スクリプトの実行に失敗します。この場合は、- f オプションを試して、強制的に削除プロセスを実行します。

1.8.2.1.1. Directory Server インスタンスおよび管理サーバーの削除

Directory Server と管理サーバーの両方を削除できます（同じシステムに設定されている場合）。

削除操作を実行するには、- y オプションが必要です。それ以外の場合は、remove-ds-admin.pl スクリプトはドライランを実行しますが、サーバーは削除されません。

-a オプションは必須ではありませんが、Directory Server または管理 Server インスタンスが後で再設定できる場合は推奨されます。デフォルトでは、すべてのセキュリティーデータベースは削除スクリプトで保持されます。-a オプションは、セキュリティーデータベースも削除します。

注記

サーバーにバインドするスクリプトには、Directory Server インスタンスが実行している必要があります。

注記

インストールの失敗やサーバーを再起動するなど、Directory Server に問題が発生した場合には、remove-ds-admin.pl スクリプトの実行に失敗します。この場合は、- f オプションを試して、強制的に削除プロセスを実行します。

1.8.3. コンソールを使用した Directory Server インスタンスの削除

Directory Server コンソールを開きます。詳細は、「Directory Server コンソールを開く」を参照してください。
サーバーインスタンスを右クリックし、Remove Server を選択します。
Yes をクリックして確定します。

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

Directory Server には、レプリケーション、サービスのクラス、属性構文などのコア Directory Server 機能を設定するデフォルトプラグインが多数含まれています。コアプラグインはデフォルトで有効になり、完全に設定されます。

他のデフォルトプラグインは、一貫したユーザー定義で、DNA、属性の一意性、および属性リンクを提供することにより、Directory Server の機能を拡張します。これらのプラグインは利用可能ですが、すべてのプラグインがデフォルトで有効または設定される訳ではありません。

プラグインを使用すると、Directory Server を簡単に拡張できるため、お客様は独自のサーバープラグインを作成してデプロイし、特定のデプロイメントに必要なディレクトリー操作を実行することができます。

詳細は、以下を参照してください。

1.9.1. プラグインを動的に有効化

Directory Server は、Directory Server を再起動せずに有効にできる動的プラグインをサポートします。動的な有効化されたプラグインを可能にすると、サーバーの管理がより容易になります。動的プラグインを使用すると、サーバーを複数回再起動して、プラグインをインストールおよび設定することができます。これにより、Directory Server のソフトウェアアプリケーションをデプロイする方がはるかに速くなります。

各プラグインは、nsslapd-pluginEnabled 属性の値を切り替えることで有効または無効にできます。以下に例を示します。

# ldapmodify -x -D 'cn=Directory Manager' -W
dn: cn=Plug-in_name,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on

cn=config エントリーで nsslapd-dynamic-plugins スイッチを指定した場合、プラグインを再設定するときに Directory Server を再起動する必要はありません。動的プラグイン機能を有効にするには、nsslapd-dynamic-plugins 属性を on に設定します。

dn: cn=config
nsslapd-dynamic-plugins: on

動的プラグイン機能を無効にするには、nsslapd-dynamic-plugins 属性を off に設定します。

dn: cn=config
nsslapd-dynamic-plugins: off

デフォルトでは、nsslapd-dynamic-plugins は off に設定されます。

1.9.2. プラグインの有効化

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

コマンドラインでプラグインを無効化または有効にするには、ldapmodify ユーティリティーを使用して nsslapd-pluginEnabled 属性の値を編集します。以下に例を示します。

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

dn: cn=ACL Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on

1.9.2.2. Directory Server コンソールでプラグインの有効化

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

Directory Server コンソールで、Configuration タブを選択します。
ナビゲーションツリーの Plugins フォルダーをダブルクリックします。
Plugins 一覧からプラグインを選択します。
プラグインを無効にするには、有効のチェックボックスの選択を解除します。プラグインを有効にするには、このチェックボックスを選択します。
Save をクリックします。
Directory Server を再起動します。
```
# systemctl restart dirsrv@instance
```

注記

プラグインが無効になっていると、そのバージョンやベンダーなど、プラグインに関する詳細はすべて Directory Server コンソールに表示されません。すべての詳細フィールドには NONE が表示されます。

プラグインを有効にすると、Directory Server が再起動（新しいプラグイン設定のロード）後、Directory Server コンソールが更新されるまで、これらの詳細がコンソールに表示されません。

1.9.3. プラグインの設定

Directory Server 9 以前では、nsslapd-pluginarg* 属性を使用してプラグインを設定しました。Directory Server 10 は、特定のプラグインに特定の設定属性のサポートを追加しました。

重要

プラグイン固有の設定属性と非推奨の nsslapd-pluginarg* 属性がプラグインの設定に設定されている場合、Directory Server はプラグイン固有の属性の設定のみを使用します。

以下の 2 つの例は、Referential Integrity プラグインで同じ設定を使用しますが、異なる設定オプションを使用します。

例1.1 設定属性を使用したプラグイン設定

referint-update-delay: 0
referint-logfile: /var/log/dirsrv/slapd-localhost/referint
referint-logchanges: 0
referint-membership-attr: member
referint-membership-attr: uniquemember
referint-membership-attr: owner
referint-membership-attr: seeAlso

注記

Red Hat は、設定プラグイン固有の属性のみを使用することを推奨します。プラグイン固有の属性については、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンスの該当するセクションを参照してください』。

例1.2 プラグイン引数属性を使用したプラグイン設定（非推奨）

nsslapd-pluginarg0: 0
nsslapd-pluginarg1: /var/log/dirsrv/slapd-localhost/referint
nsslapd-pluginarg2: 0
nsslapd-pluginarg3: member
nsslapd-pluginarg4: uniquemember
nsslapd-pluginarg5: owner
nsslapd-pluginarg6: seeAlso

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

ldapmodify ユーティリティーを使用してプラグインを設定するには、以下を実行します。

プラグイン設定の識別名(DN)を特定します。詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンスの該当するセクションを参照してください』。

新しい値を設定します。たとえば、Referential Integrity プラグインの更新遅延を 0 に設定するには、次のコマンドを実行します。

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

dn: cn=referential integrity postoperation,cn=plugins,cn=config
changetype: modify
replace: referint-update-delay
referint-update-delay: 0

Directory Server インスタンスを再起動します。
```
# systemctl restart dirsrv@instance_name
```

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

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

Directory Server コンソールを起動し、cn=Directory Manager ユーザー名を使用してログインします。
詳細は、「管理コンソールを開く」を参照してください。
Servers and Applications タブで administration_domain_namehost_name → Server GroupDirectory Server(instance_name) に移動し、Open をクリックします。
プラグインに移動し、設定するプラグインを選択します。
右側のパネルで Advanced ボタンをクリックします。
注記
Red Hat は、プラグイン固有の属性を使用する Property Editor を使用してプラグインを設定することを推奨します。
プラグイン固有の属性を設定します。
OK をクリックして、Property Editor を閉じます。
Directory Server を再起動します。詳細は、「コンソールを使用した管理サーバーのサービスの再起動および停止」を参照してください。

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

プラグインの優先順位は、プラグインの実行順序にある優先順位です。操作前および操作後のプラグインでは、次のプラグインの開始前に 1 つのプラグインを実行して完了することができます。これにより、2 番目のプラグインが最初のプラグインの結果を活用できるようになります。

プラグインの設定エントリーの優先順位は、プラグインの設定エントリーの nsslapd-pluginPrecedence 属性で設定されます。この属性の値は、1（最も高い優先度）から 99（最も低い優先度）です。属性が設定されていない場合、デフォルト値は 50 になります。

重要

Red Hat サポートから指示されない限り、デフォルトの Directory Server プラグインにプラグインの優先順位を設定しないでください。プラグインの優先順位属性は、主にコア Directory Server プラグイン の動作を変更しない、カスタムプラグインの動作を管理することです。

nsslapd-pluginPrecedence 属性は ldapmodify コマンドを使用して設定されます。以下に例を示します。

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

dn: cn=My Example Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginPrecedence
nsslapd-pluginPrecedence: 1

1.10. サーバー設定属性

Directory Server は、cn=config エントリーで維持される設定を /etc/dirsrv/slapd-instance_name/dse.ldif ファイルに保存します。新規インスタンスを設定すると、Directory Server はこのファイルで変更された設定属性のみを保存します。一覧にない属性には、デフォルト値を使用します。

これを使用すると、以下が可能になります。

/etc/dirsrv/slapd-instance_name/dse.ldif ファイルを表示して、このインスタンスに設定したすべての設定パラメーターを特定します。
パラメーターを削除してデフォルト値を復元します。
設定パラメーターを削除すると、このパラメーターは /etc/dirsrv/slapd-instance_name/dse.ldif ファイルに一覧表示されなくなりました。ただし、LDAP プロトコルを使用して cn=config エントリーのパラメーターを検索すると、パラメーターとそのデフォルト値が表示されます。
表1.1「削除できない設定属性」に記載のパラメーターを削除して、デフォルトにリセットすることはできません。削除を試みると、サーバーは要求を拒否し、Server is unwilling to perform(53) エラーを発生させます。
新しい Directory Server バージョンで提供される最新のデフォルト値を使用します。
多くの場合、新しいバージョンは最適化された設定を提供し、セキュリティーが強化されます。たとえば、passwordStorageScheme 属性を設定しないと、Directory Server は、サポートされていて利用可能な、そして最も強力なパスワードストレージスキームを使用します。今後の更新で、セキュリティーを向上させるためにデフォルト値を変更すると、パスワードを設定する際に、新しいストレージスキームを使用してパスワードが自動的に暗号化されます。
注記
パラメーターを手動でデフォルトと同じ値に設定すると、値は更新されません。これは、新しいバージョンのデフォルト値が異なる場合に発生します。

表1.1 削除できない設定属性

`nsslapd-accesslog`	`nsslapd-auditlog`	`nsslapd-bakdir`
`nsslapd-certdir`	`nsslapd-certmap-basedn`	`nsslapd-conntablesize`
`nsslapd-errorlog`	`nsslapd-instancedir`	`nsslapd-ldifdir`
`nsslapd-localhost`	`nsslapd-localuser`	`nsslapd-lockdir`
`nsslapd-rootpw`	`nsslapd-referral`	`nsslapd-referralmode`
`nsslapd-rundir`	`nsslapd-saslpath`	`nsslapd-schemadir`
`nsslapd-tmpdir`	`nsslapd-workingdir`

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

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

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

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

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

ou=people 接尾辞と、その下のすべてのエントリーおよびノードは 1 つのデータベースに保存され、ou=groups 接尾辞は別のデータベースに保存され、ou=contractors 接尾辞はまた別のデータベースに保存される可能性があります。

2.1.1. 接尾辞の作成

root 接尾辞は、 サブ接尾辞の親です。これは、Directory Server 用に設計された大規模なツリーの一部になります。サブ接尾辞は、root 接尾辞の下にあるブランチです。root 接尾辞とサブ接尾辞はどちらも、ディレクトリーツリーのコンテンツを整理するために使用されます。root 接尾辞およびサブ接尾辞のデータはデータベースに含まれます。

ディレクトリーには、複数のルート接尾辞が含まれる場合があります。たとえば、ISP は複数の Web サイト（example.com 用）と redhat .com 用など、複数の Web サイトをホストする場合があります。ここでは、2 つのルート接尾辞が必要です。1 つは dc=example,dc=com 命名コンテキストに対応し、図2.2「2 つのルート接尾辞があるディレクトリーツリー」のように、dc =redhat,dc=com 命名コンテキストに対応するものになります。

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

また、検索操作からディレクトリーツリーの一部を除外するために、ルート接尾辞を作成することもできます。たとえば、Example Corporation は、一般的な Example Corporation ディレクトリーの検索から、ヨーロッパのオフィスを除外します。これを実行するには、2 つのルート接尾辞を作成します。1 つのルート接尾辞は、一般的な Example Corporation ディレクトリーツリー dc=example,dc=com に対応します。また、1 つのルート接尾辞は、ディレクトリーツリーのヨーロッパブランチ l=europe,dc=example,dc=com に対応します。クライアントアプリケーションの観点では、ディレクトリーツリーは図2.3「検索操作に対するルート接尾辞の Off 制限があるディレクトリーツリー」で説明されています。

図2.3 検索操作に対するルート接尾辞の Off 制限があるディレクトリーツリー

クライアントアプリケーションがディレクトリーの dc=example,dc=com ブランチで検索を実行すると、ディレクトリーの l=europe,dc=example,dc=com ブランチは別のルート接尾辞となるため、エントリーを返しません。

一般的な検索で、ディレクトリーツリーのヨーロッパブランチにエントリーを含める場合は、ヨーロッパのブランチに、一般的なブランチのサブ接尾辞を指定します。これには、Example Corporation、dc =example,dc=com のルート接尾辞を作成し、ヨーロッパのディレクトリーエントリー l=europe,dc=example,dc=com の下にサブ接尾辞を作成します。クライアントアプリケーションの観点からは、ディレクトリーツリーは図2.4「従属接尾辞が含まれるディレクトリーツリー」に示されるように表示されます。

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

本セクションでは、Directory Server Console またはコマンドラインのいずれかを使用して、ディレクトリーの root およびサブ接尾辞を作成する方法を説明します。

2.1.1.1. コンソールを使用した新規ルート接尾辞の作成

Directory Server コンソールで、Configuration タブを選択します。
左側のナビゲーションペインで Data を右クリックし、ポップアップメニューから New Root Suffix を選択します。
New suffix フィールドに一意の接尾辞を入力します。
接尾辞は、dc =example,dc=com などの dc 命名規則を持つ行に指定する必要があります。
Create associated database automatically を選択して、新しいルート接尾辞と同時にデータベースを作成し、example2 などの Database name フィールドに新規データベースの一意の名前を入力します。名前は、英数字、ダッシュ(-)、およびアンダースコア(_)の組み合わせになります。他の文字は使用できません。
チェックボックスの選択を解除して、後で新しいルート接尾辞のデータベースを作成します。このオプションは、データベースが作成されるディレクトリーを指定します。新しいルート接尾辞は、データベースが作成されるまで無効になります。

新しいルート接尾辞が Data フォルダーに表示されます。

2.1.1.2. コンソールを使用した新しい従属接尾辞の作成

Directory Server コンソールで、Configuration タブを選択します。
左側のナビゲーションペインの Data で、新しいサブ接尾辞を追加する接尾辞を選択します。接尾辞を右クリックし、ポップアップメニューから New Sub Suffix を選択します。
Create new sub suffix ダイアログボックスが表示されます。
New suffix フィールドに一意の接尾辞名を入力します。接尾辞の名前は、dc の命名規則 （例： ou=groups）を持つ行に指定する必要があります。
root 接尾辞は名前に自動的に追加されます。たとえば、サブ接尾辞 ou=groups が dc=example,dc=com 接尾辞の下に作成される場合、コンソールには ou=groups,dc=example,dc=com という名前が自動的に付けられます。
Create associated database automatically チェックボックスを選択し、新しいサブ接尾辞と同時にデータベースを作成し、example2 などの Database name フィールドに新規データベースの一意の名前を入力します。名前は、英数字、ダッシュ(-)、およびアンダースコア(_)の組み合わせになります。他の文字は使用できません。
このチェックボックスを選択しないと、新しいサブ接尾辞のデータベースよりも後で作成する必要があります。データベースが作成されるまで、新しいサブ接尾辞が無効になります。

接尾辞は、左側のナビゲーションペインの Data ツリーのルート接尾辞の下に自動的に表示されます。

2.1.1.3. コマンドラインでのルート接尾辞およびサブ接尾辞の作成

接尾辞の設定情報は cn=mapping tree,cn=config エントリーに保存されます。ldapmodify ユーティリティーを使用して、新しい接尾辞をディレクトリーに追加します。

接尾辞の作成時に設定できるすべてのパラメーターの一覧は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンスの該当するセクションを参照してください』。

ルート接尾辞の作成

たとえば、dc =example,dc=com のルート接尾辞を追加するには、以下を実行します。

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

dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: add
cn: dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: UserData

従属接尾辞の作成

サブ接尾辞の作成は、root 接尾辞の作成と同様です。違いは、nsslapd-parent-suffix に親接尾辞を設定する点です。

たとえば、dc= example,dc =com ルート接尾辞の下に ou= groups サブ接尾辞を作成するには、以下を実行します。

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

dn: cn="ou=groups,dc=example,dc=com",cn=mapping tree,cn=config
changetype: add
cn: ou=groups,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: GroupData
nsslapd-parent-suffix: dc=example,dc=com

2.1.2. 接尾辞の維持

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

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

多くのディレクトリーツリーには複数の命名コンテキストがあり、異なるタイプのエントリーや論理データ分割で使用されます。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. コマンドラインでの接尾辞の無効化

コマンドラインで接尾辞を無効にするには、対応する接尾辞エントリーの nsslapd-state 属性を disabled に設定します。

# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=suffix_DN,cn=mapping tree,cn=config
changetype: modify
replace: nsslapd-state
nsslapd-state: disabled

2.1.2.2.2. コンソールを使用した接尾辞の無効化

コンソールを使用して接尾辞を無効にするには、以下を実行します。

Directory Server コンソールで、Configuration タブを選択します。
左側のナビゲーションペインで Data で、接尾辞をクリックして無効にします。
Suffix Setting タブをクリックし、Enable this suffix チェックボックスの選択を解除します。

2.1.2.3. 接尾辞の削除

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

警告

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

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

コマンドラインで接尾辞を削除するには、以下を実行します。

マッピングツリーから接尾辞を削除します。

# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "cn="suffix_DN",cn=mapping tree,cn=config"

接尾辞が別のデータベースを使用する場合は、データベースを削除します。

# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "cn=database_name,cn=ldbm database,cn=plugins,cn=config"

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

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

Directory Server コンソールで、Configuration タブを選択します。
左側のナビゲーションペインで Data の下で、削除する接尾辞を選択します。
接尾辞を右クリックし、メニューから Delete を選択します。
Delete this suffix およびそのサブ接尾辞のすべてを選択するか、この接尾辞のみを削除します。

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

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

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. コンソールを使用した既存の接尾辞の新規データベースの作成

Directory Server コンソールで、Configuration タブを選択します。
左側のペインで Data を展開し、新しいデータベースを追加する接尾辞をクリックします。
接尾辞を右クリックし、ポップアップメニューから New Database を選択します。
example2 などのデータベースの一意の名前を入力します。データベース名は、英数字、ダッシュ(-)、およびアンダースコア(_)の組み合わせになります。
Create database in フィールドには、デフォルトのデータベースディレクトリー(/var/lib/dirsrv/slapd-instance/db)と新規データベースの名前が自動的に入力されます。また、別のディレクトリーの場所を入力またはブラウズすることもできます。

2.2.1.2. コマンドラインから単一の接尾辞用の新規データベースの作成

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

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
```
追加されたエントリーは、root またはサブ接尾辞 ou=people,dc=example,dc=com のデータが含まれる UserData という名前のデータベースに対応します。
「コマンドラインでのルート接尾辞およびサブ接尾辞の作成」の説明に従って、ルートまたは従属接尾辞を作成します。DN 属性で指定されるデータベース名は、接尾辞エントリーの nsslapd-backend 属性の値に対応している必要があります。

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

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

注記

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

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

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

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

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

2.2.1.3.1. Directory Server コンソールを使用したカスタムディストリビューション機能の接尾辞への追加

Directory Server コンソールで、Configuration タブを選択します。
左側のナビゲーションペインで Data を展開します。ディストリビューション機能を適用する接尾辞を選択します。
右側のウィンドウで Databases タブを選択します。
接尾辞に関連付けられているデータベースは、Databases タブにすでにリストされています。Add をクリックして、追加のデータベースを接尾辞に関連付けます。
ディストリビューションライブラリーへのパスを入力します。
Function name フィールドにディストリビューション機能の名前を入力します。

2.2.1.3.2. コマンドラインを使用したカスタムディストリビューション機能の接尾辞への追加

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 属性は、ディストリビューション機能自体の名前を提供します。

ldapmodify コマンドラインユーティリティーの使用に関する詳細は、「コマンドラインでエントリーの管理」を参照してください。

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

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

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

「コンソールを使用したデータベースの読み取り専用の設定」
「コマンドラインからデータベースの読み取り専用の設定」
「読み取り専用モードでの Directory Server の配置」

2.2.2.1.1. コンソールを使用したデータベースの読み取り専用の設定

Directory Server コンソールで、Configuration タブを選択します。
左側のペインで Data を展開します。データベースが含まれる接尾辞を展開して、読み取り専用モードにします。
読み取り専用モードに設定するデータベースを選択します。
右側のペインで、Database Settings タブを選択します。
データベースが読み取り専用チェックボックスにチェックマークを入れます。

この変更は即座に有効になります。

データベースをインポートまたは復元する前に、操作の影響を受けるデータベースが読み取り専用モード ではないことを確認してください。

読み取り専用モードを無効にするには、Directory Server Console でデータベースを再度開き、データベースが読み取り専用チェックボックスの選択を解除します。

2.2.2.1.2. コマンドラインからデータベースの読み取り専用の設定

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

ldapmodify を実行します。

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

read-only 属性を on に変更します。

dn: cn=database_name,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsslapd-readonly
nsslapd-readonly: on

注記

デフォルトでは、インストール時に作成されるデータベースの名前は userRoot です。

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

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

警告

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

注記

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

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

Directory Server コンソールの Configuration タブを選択し、左側のペインのナビゲーションツリーでトップエントリーを選択します。
右側のペインで Settings タブを選択します。
Make Entire Server Read-Only チェックボックスを選択します。
Save をクリックし、サーバーを再起動します。

2.2.2.2. データベースの削除

データベースを削除すると、そのデータベースの設定情報とエントリーのみが削除され、物理データベース自体は削除されません。

Directory Server コンソールで、Configuration タブを選択します。
Data フォルダーを展開し、接尾辞を選択します。
削除するデータベースを選択します。
データベースを右クリックし、ポップアップメニューから Delete を選択します。
Delete Database ダイアログボックスでデータベースを削除する必要があることを確認します。

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

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

注記

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

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

Directory Server インスタンスを停止します。
```
# systemctl stop dirsrv@instance_name
```
トランザクションログ用に新しい場所を作成します。以下に例を示します。
```
# 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/
```
インスタンスを起動します。
```
# systemctl start dirsrv@instance_name
```

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

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

「新規データベースリンクの作成」
「シャーシポリシーの設定」
「データベースリンクの維持」
「データベースリンクのデフォルトの設定」
「データベースリンクの削除」
「データベースリンクおよびアクセス制御評価」

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

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

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

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

注記

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

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

Directory Server コンソールで、Configuration タブを選択します。
「接尾辞の作成」の説明に従って、新しい接尾辞を作成します。
Create associated database automatically のチェックボックスの選択を解除します。データベースとデータベースリンクにディレクトリーデータを配布するカスタムディストリビューション機能が必要になるため、データベースとデータベースリンクに、接尾辞にデータベースリンクを設定するのが簡単になります。
左側のペインで、新しい接尾辞を右クリックし、ポップアップメニューから New Database Link を選択します。
データベースリンク名を入力します。名前は、英数字、ダッシュ(-)、およびアンダースコア(_)の組み合わせになります。スペースなどの他の文字は使用できません。
認証に適切な方法にラジオボタンを設定します。
認証方法は 4 つあります。
- simple は、サーバーが、暗号化なしで標準ポートで接続することを意味します。必要な情報は、サーバーがリモートサーバーに接続するユーザーのバインド DN およびパスワードです。
- サーバーの TLS/SSL 証明書は、ローカルサーバーの TLS 証明書を使用して、リモートサーバーに対して認証します。証明書は、証明書ベースの認証用にローカルサーバーにインストールされ、リモートサーバーに証明書マッピングが設定され、ローカルサーバーの証明書のサブジェクト DN を対応するユーザーエントリーにマッピングできるように、証明書マッピングを設定する必要があります。
  TLS および証明書マッピングの設定については、「TLS の有効化」を参照してください。
  注記
  データベースリンクとリモートサーバーが TLS を使用して通信するよう設定されている場合は、操作要求を行うクライアントアプリケーションも TLS を使用して通信する必要があるわけではありません。クライアントは、通常のポートを使用してバインドできます。
- SASL/DIGEST-MD5 では、認証を行うためにバインド DN およびパスワードのみが必要になります。
- SASL/GSSAPI では、ローカルサーバーに Kerberos キータブ（「KDC サーバーおよびキータブの概要」にあるように）があり、リモートサーバーにローカルサーバーのプリンシパルを実際のユーザーエントリーにマッピングする SASL マッピングが必要です。「コンソールからの SASL アイデンティティーマッピングの設定」
Remote Server Information セクションで、ローカルサーバーがリモートサーバーへの接続に使用する接続タイプを選択します。以下の 3 つのオプションがあります。
- LDAP を使用します。これにより、標準の暗号化されていない接続が設定されます。
- TLS/SSL を使用します。これは、636 などのサーバーのセキュアな LDAPS ポートを介したセキュアな接続を使用します。この設定は、TLS/TLS を使用するために必要です。
  TLS を使用する場合は、リモートサーバーのポート番号がセキュアなポートに設定されていることを確認します。
- Start TLS を使用します。Start TLS を使用して、サーバーの標準ポートでセキュアな接続を確立します。
注記
シンプルなパスワード認証 (「セキュアなバインドの要求」) にセキュアなバインドが必要な場合は、セキュアな接続で行われる場合を除き、チェーン操作は失敗します。セキュアな接続（TLS および Start TLS 接続または SASL 認証）の使用が推奨されます。
Remote Server Information セクションで、リモートサーバーの名前（ホスト名、IPv4 アドレス、または IPv6 アドレス）とポート番号を入力します。
フェイルオーバーサーバーの場合は、ホスト名とポート番号を入力し、追加ボタンをクリックします。フェイルオーバーサーバーはバックアップサーバーであるため、プライマリーリモートサーバーが失敗すると、データベースリンクはフェイルオーバーサーバー一覧の最初のサーバーに接続し、サーバーがアクセスされるまでリストを循環します。

新しいデータベースリンクは、データベースの代わりに接尾辞の下に一覧表示されます。

注記

コンソールは、正常にバインドするためにデータベースリンクが リモートサーバー に存在する必要がある情報のチェックリストを提供します。このチェックリストを表示するには、新しいデータベースリンクをクリックし、Authentication タブをクリックします。このチェックボックスは、リモートサーバーのチェックボックスにチェックを記入します。

2.3.1.2. コマンドラインからのデータベースリンクの作成

ldapmodify コマンドラインユーティリティーを使用して、新しいデータベースリンクを作成します。新しいインスタンスは、cn=chaining database,cn=plugins,cn=config エントリーに配置する必要があり ます。
```
# ldapmodify -a -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
```

データベースリンクの設定情報を指定します。

dn: cn=examplelink,cn=chaining database,cn=plugins,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: ou=people,dc=example,dc=com suffix being chained
nsfarmserverurl: ldap://people.example.com:389/  LDAP URL to remote server  
nsMultiplexorBindDN: cn=proxy admin,cn=config bind DN
nsMultiplexorCredentials: secret bind password
cn: examplelink

注記

デフォルト設定属性は cn=default instance config,cn=chaining database,cn=plugins,cn=config エントリーに含まれます。これらの設定属性は、作成時にすべてのデータベースリンクに適用されます。デフォルト設定の変更は、新しいデータベースリンクにのみ影響します。既存のデータベースリンクのデフォルト設定属性を変更することはできません。

各データベースリンクには、データベースリンクエントリー自体(cn= database_link , cn=chaining database,cn=plugins,cn= config )で保存される独自の設定情報が含まれます。設定属性の詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンスを参照してください』。

「接尾辞情報の提供」
「バインド認証情報の提供」
「LDAP URL の提供」
「フェイルオーバーサーバーの一覧の提供」
「異なるバインドメカニズムの使用」
「データベースリンクの設定属性の概要」
「データベースリンクの設定例」

2.3.1.2.1. 接尾辞情報の提供

nsslapd-suffix 属性を使用して、データベースリンクが管理する接尾辞を定義します。たとえば、データベースリンクが会社のリモートサイトの人情報を参照する場合は、以下の接尾辞情報を入力します。

nsslapd-suffix: l=Zanzibar,ou=people,dc=example,dc=com

接尾辞情報は、cn=database_link, cn =chaining database,cn=plugins,cn=config エントリーに保存されます。

注記

データベースリンクの作成後、nsslapd-nsslapd-suffix 属性の変更は、データベースリンクを含むサーバーが再起動しないと適用されません。

2.3.1.2.2. バインド認証情報の提供

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

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

リモートサーバーで以下を行います。
- データベースリンクの管理ユーザーを作成します。
  エントリーの追加に関する詳細は、「3章ディレクトリーエントリーの管理」を参照してください。
- データベースリンクによってチェーンされたサブツリーの手順 1 で作成した管理ユーザーのプロキシーアクセス権限を指定します。
  ACI の設定に関する詳細は、「18章アクセス制御の管理」を参照してください。
データベースリンクを含むサーバーで ldapmodify を使用して、cn= database_link , cn=chaining database,cn= plugins,cn=configエントリーの nsMultiplexorBindDN 属性にデータベースリンクのユーザー DN を提供します。
警告
nsMultiplexorBindDN は、Directory Manager に含めることはできません。
ldapmodify を使用して、cn= database_link , cn=chaining database,cn= plugins,cn=configエントリーの nsMultiplexorCredentials 属性に、データベースリンクのユーザーパスワードを提供します。

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

サーバー A のデータベースリンクは、nsMultiplexorBindDN 属性で定義されている特別なユーザーと nsMultiplexorCredentials 属性で定義されているユーザーパスワードを使用してサーバー B にバインドされます。この例では、サーバー A は以下のバインド認証情報を使用します。

nsMultiplexorBindDN: cn=proxy admin,cn=config
nsMultiplexorCredentials: secret

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

警告

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

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

注記

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

2.3.1.2.3. LDAP URL の提供

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

nsFarmServerURL 属性を使用したリモートサーバーの URL は、設定ファイルの cn=database_link, cn=chaining database,cn=plugins,cn=config エントリーに設定されます。

nsFarmServerURL: ldap://example.com:389/

注記

URL の最後で末尾のスラッシュ(/)を使用することを忘れないでください。

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

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

注記

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

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

2.3.1.2.4. フェイルオーバーサーバーの一覧の提供

障害発生時に使用するサーバーには、追加の LDAP URL が存在する可能性があります。nsFarmServerURL 属性に代替サーバーを追加し、空白で区切って追加します。

nsFarmServerURL: ldap://example.com us.example.com:389 africa.example.com:1000/

このサンプル LDAP URL では、データベースリンクは最初に標準ポートで example.com サーバーに問い合わせ、操作を処理します。応答しない場合、データベースリンクはポート 389 でサーバー us.example.com に問い合わせます。このサーバーが失敗した場合は、ポート 1000 で africa.example.com にお問い合わせください。

2.3.1.2.5. 異なるバインドメカニズムの使用

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

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

標準の LDAP ポートを使用する場合
専用の LDAPS ポートを使用する場合
Start TLS（標準ポートでのセキュアな接続）の使用

注記

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

接続タイプは nsUseStartTLS 属性で識別されます。これを有効にすると、サーバーは標準ポートで Start TLS 接続を開始します。これがオフの場合、サーバーは nsFarmServerURL 属性のリモートサーバーに設定されたものに応じて LDAP ポートまたは LDAPS ポートを使用します。

たとえば、Start TLS を使用するには、以下を実行します。

nsUseStartTLS: on

たとえば、標準接続または TLS 接続を使用するには、以下を実行します。

nsUseStartTLS: off

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

empty.バインドメカニズムが設定されていない場合、サーバーは簡易認証を実行し、バインド情報を付与する nsMultiplexorBindDN 属性および nsMultiplexorCredentials 属性を必要とします。
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 接続で確立できます。

以下に例を示します。

nsBindMechanism: EXTERNAL

注記

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

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

dn: cn=config,cn=chaining database,cn=plugins,cn=config
changetype: modify
add: nsActiveChainingComponents
nsActiveChainingComponents: cn=password policy,cn=components,cn=config
-
add: nsActiveChainingComponents
nsActiveChainingComponents: cn=sasl,cn=components,cn=config
^D

2.3.1.2.6. データベースリンクの設定属性の概要

以下の表は、データベースリンクの設定に使用できる属性を表しています。これらの属性の一部は、先のセクションで説明されました。すべてのインスタンス属性は、cn=database_link, cn =chaining database,cn=plugins,cn=config エントリーで定義されます。

特定のデータベースリンクに定義されている値は、グローバル属性値よりも優先されます。

表2.1 データベースリンクの設定属性

属性	値
nsTransmittedControls ^[†]	リモートデータサーバーへデータベースリンクによって転送される LDAP コントロールの OID を指定します。
nsslapd-suffix	データベースリンクで管理される接尾辞。エントリーの作成後にこの属性への変更は、データベースリンクを含むサーバーが再起動しないと反映されません。
nsslapd-timelimit	データベースリンクの検索時間制限のデフォルト（秒単位）。デフォルト値は 3600 秒です。
nsslapd-sizelimit	エントリーの数で指定するデータベースリンクのデフォルトサイズ制限。デフォルト値は 2000 エントリーです。
nsFarmServerURL	データが含まれるリモートサーバー（またはファームサーバー）の LDAP URL を指定します。この属性には、空白で区切られた、フェイルオーバーのオプションサーバーを含めることができます。カスケード連鎖を使用する場合、この URL は別のデータベースリンクを参照できます。
nsUseStartTLS	Start TLS を使用して標準ポートでセキュアな接続を確立するかどうかを設定します。デフォルトは off で、単純な（標準）接続と TLS 接続の両方に使用されます。
nsBindMechanism	リモートサーバーの認証（バインド）に使用する認証方法を設定します。空の値を設定する場合は、単純なバインド(LDAP_SASL_SIMPLE)が使用されます。
nsMultiplexorBindDN	リモートサーバーと通信するために使用される管理エントリーの DN。属性名の `multiplexor` という用語は、データベースリンクが含まれ、リモートサーバーと通信するサーバーを意味します。このバインド DN は Directory Manager にすることはできません。この属性が指定されていない場合、データベースリンクは anonymous としてバインドします。
nsMultiplexorCredentials	管理ユーザーのパスワード（プレーンテキストで指定されます）。パスワードが提供されない場合、ユーザーは anonymous としてバインドできることを意味します。パスワードは設定ファイルで暗号化されます。
nsCheckLocalACI	高度な使用のために予約されます。ACI がデータベースリンクとリモートデータサーバーで評価されるかどうかを制御します。on または off の値を取ります。この属性への変更は、サーバーの再起動後にのみ行われます。デフォルト値は off です。
nsProxiedAuthorization	高度な使用のために予約されます。プロキシー化された承認を無効にします。off を指定すると、プロキシー認証が無効になります。デフォルト値は on です。
nsActiveChainingComponents^[†]	は、チェーンを使用するコンポーネントを一覧表示します。コンポーネントとは、サーバー内の機能的な単位です。データベースリンクインスタンスのこの属性の値は、グローバル設定属性の値を上書きします。特定のデータベースインスタンスでチェーンを無効にするには、値 none を使用します。デフォルトのポリシーはチェーンを許可しません。詳細は、「コンポーネントの動作の連鎖」を参照してください。
nsReferralOnScopedSearch	スコープ指定の検索によって参照を返すかどうかを制御します。この属性は、スコープ指定された検索に対して応答された参照を返す方がより効率的であるため、ディレクトリーを最適化します。on または off の値を取ります。デフォルト値は off です。
nsHopLimit	あるデータベースリンクから別のデータベースリンクに要求を転送できる最大回数。デフォルト値は 10 です。
^[†] グローバル属性およびインスタンス属性の両方を指定できます。このグローバル設定属性は、cn =config,cn=chaining database,cn=plugins,cn=config エントリーにあります。グローバル属性は動的であるため、その属性への変更はディレクトリー内のデータベースリンクのすべてのインスタンスに対して自動的に有効になります。

詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンスのパラメーターの説明を参照してください』。

2.3.1.2.7. データベースリンクの設定例

us.example.com ドメイン内のサーバーに、データベースのサブツリー l=Walla Walla,ou=people,dc=example,dc=com が含まれており、l=Zanzibar,ou=people,dc=example,dc=com サブツリーの操作要求を、africa.example.com ドメインの別のサーバーにチェーンする必要があります。

ldapmodify を実行して、サーバー A にデータベースリンクを追加します。
```
# ldapmodify -a -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
```
データベースリンクの設定情報を指定します。
```
dn: cn=DBLink1,cn=chaining database,cn=plugins,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: c=africa,ou=people,dc=example,dc=com
nsfarmserverurl: ldap://africa.example.com:389/
nsMultiplexorBindDN: cn=proxy admin,cn=config
nsMultiplexorCredentials: secret
cn: DBLink1

dn: cn="c=africa,ou=people,dc=example,dc=com",cn=mapping tree,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: DBLink1
nsslapd-parent-suffix: ou=people,dc=example,dc=com
cn: c=africa,ou=people,dc=example,dc=com
```
最初のエントリーでは、nsslapd-suffix 属性には、サーバー A からチェーンするサーバー B の接尾辞が含まれます。nsFarmServerURL 属性には、サーバー B の LDAP URL が含まれます。
2 番目のエントリーは新しい接尾辞を作成し、サーバーが新しいデータベースリンクに行われた要求をルーティングできるようにします。cn 属性には、データベースリンクの nsslapd-suffix 属性に指定された同じ接尾辞が含まれます。nsslapd-backend 属性には、データベースリンクの名前が含まれます。nsslapd-parent-suffix 属性は、この新しい接尾辞 ou=people,dc=example,dc=com の親を指定します。
以下のように、サーバー B で管理ユーザーを作成します。
```
dn: cn=proxy admin,cn=config
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: proxy admin
sn: proxy admin
userPassword: secret
description: Entry for use by database links
```
警告
Directory Manager ユーザーは、リモートサーバーのプロキシー管理ユーザーとして使用しないでください。これにより、セキュリティーホールが作成されます。
サーバー B の l=Zanzibar,ou=people,dc=example,dc=com エントリーに、以下のプロキシー承認 ACI を追加します。
```
aci: (targetattr = "*")(version 3.0; acl "Proxied authorization
     for database links"; allow (proxy) userdn = "ldap:///cn=proxy
     admin,cn=config";)
```
この ACI は、l=Zanzibar,ou=people,dc=example,dc=com サブツリー内に含まれるリモートサーバーに含まれるデータに、プロキシー admin ユーザーの読み取り専用アクセスのみを提供します。
注記
ユーザーがデータベースリンクにバインドすると、ユーザーのアイデンティティーがリモートサーバーに送信されます。アクセス制御は、常にリモートサーバーで評価されます。ユーザーがリモートサーバーにデータを変更または書き込みできるようにするには、リモートサーバーに正しいアクセス制御を設定します。チェーン操作のコンテキストでアクセス制御がどのように評価されるかについての詳細は、「データベースリンクおよびアクセス制御評価」を参照してください。

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. コンソールを使用したコンポーネントの操作の連鎖

Directory Server コンソールで、Configuration タブを選択します。
左側のペインで Data を展開し、Database Link Settings をクリックします。
右側のウィンドウで Settings タブを選択します。
チェーン可能な Components の Add ボタンをクリックします。
一覧からチェーンするコンポーネントを選択し、OK をクリックします。
変更を反映するためにサーバーを再起動します。

コンポーネントが連鎖した後、操作が連鎖されるリモートサーバーの接尾辞に ACI を作成します。たとえば、これにより Referential Integrity プラグインの 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. コマンドラインでのコンポーネントの操作の連鎖

設定ファイルの cn=config,cn=chaining database,cn=plugins,cn=config エントリーの nsActiveChainingComponents 属性を使用して、チェーンに追加するコンポーネントを指定します。
たとえば、参照整合性コンポーネントがチェーン操作を実行できるようにするには、以下をデータベースリンク設定ファイルに追加します。
```
nsActiveChainingComponents: cn=referential integrity postoperation,cn=components,cn=config
```
連鎖が可能なコンポーネントの一覧は、「コンポーネントの動作の連鎖」を参照してください。
変更を有効にするためにサーバーを再起動します。
```
# systemctl restart dirsrv@instance_name
```

操作を連鎖させるリモートサーバーの接尾辞に ACI を作成します。たとえば、これにより Referential Integrity プラグインの 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 つのデータベースにクライアントアプリケーション要求が行われている場合にのみサポートされます。データベースリンクは、クライアントアプリケーションが複数のデータベースに要求を行う場合に、これらの制御をサポートしません。

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

Directory Server コンソールで、Configuration タブを選択します。
左側のペインで Data フォルダーを展開し、Database Link Settings をクリックします。
右側のウィンドウで Settings タブを選択します。
データベースリンクセクションによって転送される LDAP Controls の Add ボタンをクリックして、LDAP コントロールを一覧に追加します。
リストに追加するコントロールの OID を選択し、OK をクリックします。

2.3.2.2.2. コマンドラインでの LDAP 制御の連鎖

チェーン制御には、cn=config,cn= chaining database,cn=plugins,cn=config エントリーの nsTransmittedControls 属性を変更して、データベースリンクが転送するコントロールを変更します。たとえば、仮想リストビュー制御を転送するには、以下を設定ファイルのデータベースリンクエントリーに追加します。

nsTransmittedControls: 2.16.840.1.113730.3.4.9

さらに、Directory Server のクライアントが独自の制御を作成し、その操作をリモートサーバーにチェーンする必要がある場合は、nsTransmittedControls 属性にカスタム制御の OID を追加します。

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

表2.2 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.3. データベースリンクの維持

リモートサーバーへの接続用のデータベースリンクのすべての情報。

Directory Server コンソールで、Configuration タブを選択します。
左側のペインで、Data フォルダーを展開し、接尾辞の下にあるデータベースリンクを選択します。
右側のペインで、Authentication タブをクリックします。
接続情報を変更します。
- リモートサーバーの LDAP URL。^[]
- リモートサーバーにバインドするためにデータベースリンクで使用されるバインド DN およびパスワード。

2.3.4. データベースリンクのデフォルトの設定

データベースリンクのデフォルト設定は、カスケード連鎖に使用される設定（クライアント要求に許可されるホップの数）、リモートサーバーの接続ルール、およびサーバーがクライアントリクエストに応答する方法を定義します。

Configuration タブを選択します。
左側のペインで Data フォルダーを展開し、Database Link Settings をクリックします。デフォルトの作成パラメータータブを開きます。
新しい設定パラメーターを入力します。

注記

データベースリンクのデフォルト設定への変更は、再度適用されません。デフォルト設定に変更を加えた後に作成されたデータベースリンクのみが変更を反映します。

2.3.5. データベースリンクの削除

データベースリンクを削除するには、データベースリンクを右クリックし、ポップアップメニューから Delete を選択します。プロンプトが表示されたら、削除を確認します。

Directory Server コンソールで、Configuration タブを選択します。
左側のナビゲーションペインで Data の下で接尾辞を開き、削除するデータベースリンクを選択します。
データベースリンクを右クリックし、メニューから Delete を選択します。

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

ユーザーがデータベースリンクを含むサーバーにバインドすると、データベースリンクがユーザーの 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 属性を使用します。ただし、データベースリンクを含むサーバーでアクセス制御を評価することは、カスケード連鎖を使用する場合を除いて推奨されません。

^[] 標準の LDAP URL 形式とは異なり、リモートサーバーの URL は接尾辞を指定しません。これには ldap://server:port/ の形式があり、server にはホスト名、IPv4 アドレス、または IPv6 アドレスを指定できます。

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 に保存されます。l=europe,dc=example,dc=com および ou=groups 接尾辞は Server B に保存され、l =europe,dc=example,dc=com 接尾辞の ou= people ブランチはサーバー C に保存されます。

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

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

2.4.2. コンソールを使用したカスケード連鎖の設定

Configuration タブを選択します。左側のペインで Data フォルダーを展開し、接尾辞を選択してからデータベースリンクを選択します。
右側のペインで Limits and Controls タブをクリックします。
Check local ACI チェックボックスを選択して、カスケードチェーンに関連する中間データベースリンクのローカル ACI の評価を有効にします。このチェックボックスを選択すると、適切なローカル ACI をデータベースリンクに追加する必要がある場合があります。
Maximum hops フィールドで、データベースリンクが別のデータベースリンクをポイントする最大回数を入力します。
デフォルトでは、最大値は 10 ホップです。10 ホップ後、サーバーによってループが検出され、クライアントアプリケーションにエラーが返されます。

2.4.3. コマンドラインからのカスケード連鎖の設定

コマンドラインでデータベースリンクのカスケードを設定するには、以下を実行します。

中間データベースリンクが含まれるサーバーの URL に 1 つのデータベースリンクを指定します。
カスケード連鎖を作成するには、あるデータベースリンクの nsFarmServerURL 属性には、別のデータベースリンクが含まれるサーバーの URL が含まれている必要があります。example1.com と呼ばれるサーバーのデータベースリンクが、africa.example.com と呼ばれるサーバーのデータベースリンクを参照するとします。たとえば、Server 1 のデータベースリンクの cn= database_link, cn=chaining database,cn=plugins,cn=configエントリーには以下が含まれます。
```
nsFarmServerURL: ldap://africa.example.com:389/
```
プロキシー認証制御を送信するように、中間データベースリンクまたはリンク（例： Server 2）を設定します。
デフォルトでは、データベースリンクは Proxy Authorization Control を送信しません。ただし、1 つのデータベースリンクが別の接続する場合、このコントロールは最終的な送信先サーバーに必要な情報を送信するために使用されます。中間データベースリンクはこの制御を送信する必要があります。プロキシー承認制御を送信するようにデータベースリンクを設定するには、中間データベースリンクの cn=config,cn=chaining database,cn=plugins,cn=config エントリーに以下を追加します。
```
nsTransmittedControls: 2.16.840.1.113730.3.4.12
```
OID 値は Proxy Authorization Control を表します。LDAP 制御チェーンの詳細は、「LDAP 制御チェーン」を参照してください。
すべての中間データベースリンクに、プロキシー管理ユーザー ACI を作成します。
ACI は、要求を別のサーバーに変換する前に、最初のデータベースリンクの権限を確認する中間データベースリンクが含まれるサーバーに存在している必要があります。たとえば、Server 2 が Server 1 の認証情報を確認しない場合、ユーザーは匿名としてバインドし、プロキシー認証制御を渡し、適切よりも多くの管理権限を許可できます。プロキシー ACI はこのセキュリティー違反を防ぎます。
1. 中間データベースリンクが含まれるサーバーにデータベースがない場合は、データベースを作成します。このデータベースには、admin ユーザーエントリーおよび ACI が含まれます。データベースの作成に関する詳細は、「データベースの作成」を参照してください。
2. データベースの管理ユーザーに対応するエントリーを作成します。
3. 適切な接尾辞をターゲットとする管理ユーザーの ACI を作成します。これにより、管理者はデータベースリンクの接尾辞にのみアクセスできます。以下に例を示します。
```
aci: (targetattr = "*")(version 3.0; acl "Proxied authorization for database links";
      allow (proxy) userdn = "ldap:///cn=proxy admin,cn=config";)
```
  この ACI は、簡単なチェーンの設定時にリモートサーバーに作成された ACI と似ています。
警告
ディレクトリーの制限された領域へのアクセス権限を付与しないようにチェーンを有効にする場合は、アクセス制御を慎重に検討します。たとえば、ブランチにデフォルトのプロキシー ACI が作成されると、データベースリンク経由で接続するユーザーは、ブランチの下にあるすべてのエントリーを表示できます。ユーザーがすべてのサブツリーを表示する必要がない場合もあります。セキュリティーホールを回避するには、追加の ACI を作成して、サブツリーへのアクセスを制限します。
すべての中間データベースリンクで、ローカル ACI 評価を有効にします。
プロキシー管理 ACI が使用されていることを確認するには、チェーンに関連するすべての中間データベースリンクのローカル ACI の評価を有効にします。以下の属性を、各中間データベースリンクの cn=database_link, cn=chaining database,cn=plugins,cn=config エントリーに追加します。
```
nsCheckLocalACI: on
```
cn =default instance config,cn=chaining database,cn=plugins,cn=config エントリーでこの属性を on に設定すると、すべての新規データベースリンクインスタンスが cn= database_link, cn=chaining database, cn=plugins,cn=config エントリーで nsCheckLocalACI 属性が設定されることを意味します。
すべての中間データベースリンクおよび最終的な宛先データベースにクライアント ACI を作成します。
ローカル ACI の評価が有効になっているため、適切なクライアントアプリケーション ACI をすべての中間データベースリンクおよび最終的な宛先データベースに作成する必要があります。中間データベースリンクでこれを行うには、まず最終的な宛先接尾辞のルート接尾辞を表す接尾辞が含まれるデータベースを作成します。
たとえば、c =africa,ou=people,dc=example,dc=com 接尾辞に対して行われたクライアントの要求がリモートサーバーにチェーンされている場合、すべての中間データベースリンクに dc=example,dc=com 接尾辞に関連付けられたデータベースを含める必要があります。
この上位接尾辞エントリーにクライアント ACI を追加します。以下に例を示します。
```
aci: (targetattr = "*")(version 3.0; acl "Client authentication for database link users";
      allow (all) userdn = "ldap:///uid=* ,cn=config";)
```
この ACI により、Server 1 の cn=config エントリーに uid を持つクライアントアプリケーションが、サーバー 3 の ou=people,dc=example,dc=com 接尾辞の下にあるデータに対して、あらゆる種類の操作を実行できます。

2.4.4. ループの検出

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

許可されるホップ数は、nsHopLimit 属性を使用して定義されます。指定されていない場合、デフォルト値は 10 になります。

コントロールを使用するには、cn=config,cn= chaining database,cn=plugins,cn=config エントリーの nsTransmittedControl 属性に以下の OID を追加します。

nsTransmittedControl: 1.3.6.1.4.1.1466.29539.12

各データベースリンクの設定ファイルに制御がない場合、ループ検出は実装されません。

2.4.5. カスケード連鎖設定属性の概要

以下に、カスケードチェーンで中間データベースリンクを設定するために使用される属性を説明します。

nsFarmServerURL

カスケードチェーンに次のデータベースリンクが含まれるサーバーの URL。

nsTransmittedControls

カスケードチェーンに関連するデータベースリンクに以下の OID を入力します。

nsTransmittedControls: 2.16.840.1.113730.3.4.12
nsTransmittedControls: 1.3.6.1.4.1.1466.29539.12

aci

この属性には以下の ACI が含まれる必要があります。

aci: (targetattr = "*")(version 3.0; acl "Proxied
 authorization for database links";
 allow (proxy) userdn = "ldap:///cn=proxy admin,cn=config";)

nsCheckLocalACI

チェーンに関連するすべてのデータベースリンクでローカル ACI の評価を有効にするには、以下のようにローカルの ACI 評価を実行します。

nsCheckLocalACI: on

2.4.6. カスケード連鎖設定の例

以下の図のように 3 つのサーバーに関連するカスケード連鎖を作成するには、チェーンコンポーネントを 3 つのサーバーすべてに設定する必要があります。

「サーバーを 1 台設定」
「Server Two の設定」
「サーバーの 3 つの設定」

2.4.6.1. サーバーを 1 台設定

ldapmodify を実行し、サーバー 1 でデータベースリンク DBLink1 の設定情報を指定します。

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

dn: cn=DBLink1,cn=chaining database,cn=plugins,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: c=africa,ou=people,dc=example,dc=com
nsfarmserverurl: ldap://africa.example.com:389/
nsMultiplexorBindDN: cn=server1 proxy admin,cn=config
nsMultiplexorCredentials: secret
cn: DBLink1
nsCheckLocalACI:off

dn: cn="c=africa,ou=people,dc=example,dc=com",cn=mapping tree,cn=config
changetype: add
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: DBLink1
nsslapd-parent-suffix: ou=people,dc=example,dc=com
cn: c=africa,ou=people,dc=example,dc=com

最初のセクションでは、DB Link1 に関連付けられた エントリーを作成します。2 つ目のセクションでは、新しい接尾辞を作成し、サーバーが正しいサーバーにデータベースリンクに行われた要求を指示できるようにします。nsCheckLocalACI 属性は、ローカル ACI をチェックするように設定する必要はありません。これは、Server 2 のデータベースリンク DBLink2 でのみ必要です。

ループ検出を実装するには、Server 1 の cn=config,cn=chaining database,cn=plugins,cn=config エントリーに保存されている nsTransmittedControl 属性にループ検出制御の OID を指定します。
```
dn: cn=config,cn=chaining database,cn=plugins,cn=config
changetype: modify
add: nsTransmittedControl
nsTransmittedControl: 1.3.6.1.4.1.1466.29539.12
```
nsTransmittedControl 属性は通常、ループ検出 OID 1.3.6.1.4.1.1466.29539.12 の値でデフォルトで設定されているので、事前に確認してから、その属性が存在するかどうかを確認します。存在する場合は、この手順は必要ありません。

2.4.6.2. Server Two の設定

Server 2 でプロキシー管理ユーザーを作成します。この管理ユーザーは、サーバー 1 がバインドし、サーバー 2 への認証を許可するために使用されます。Server 1 に固有のプロキシー管理ユーザー名を選択すると便利です。これは、サーバー 2 にバインドできる プロキシー管理ユーザーです。以下のようにプロキシー管理ユーザーを作成します。
```
dn: cn=server1 proxy admin,cn=config
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: server1 proxy admin
sn: server1 proxy admin
userPassword: secret
description: Entry for use by database links
```
警告
Directory Manager または管理者 ID ユーザーをリモートサーバーのプロキシー管理ユーザーとして使用しないでください。これにより、セキュリティーホールが作成されます。

Server 2 でデータベースリンク DBLink2 を設定します。

dn: cn=DBLink2,cn=chaining database,cn=plugins,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: l=Zanzibar,c=africa,ou=people,dc=example,dc=com
nsfarmserverurl: ldap://zanz.africa.example.com:389/
nsMultiplexorBindDN: cn=server2 proxy admin,cn=config
nsMultiplexorCredentials: secret
cn: DBLink2
nsCheckLocalACI:on

dn: cn="l=Zanzibar,c=africa,ou=people,dc=example,dc=com",cn=mapping tree,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: DBLink2
nsslapd-parent-suffix: c=africa,ou=people,dc=example,dc=com
cn: l=Zanzibar,c=africa,ou=people,dc=example,dc=com

データベースリンク DBLink2 はカスケード連鎖設定の中間データベースリンクであるため、nsCheckLocalACI 属性を on に設定して、クライアントとプロキシーの管理ユーザーによるデータベースリンクへのアクセスを許可するかどうかをサーバーが確認できるようにします。

Server 2 のデータベースリンクは、プロキシー承認制御とループ検出制御を送信するように設定する必要があります。プロキシー認証制御とループ検出制御を実装するには、対応する OID の両方を指定します。以下の情報を Server 2 の cn=config,cn=chaining database,cn=plugins,cn=config エントリーに追加します。
```
dn: cn=config,cn=chaining database,cn=plugins,cn=config
changetype: modify
add: nsTransmittedControl
nsTransmittedControl: 2.16.840.1.113730.3.4.12
nsTransmittedControl: 1.3.6.1.4.1.1466.29539.12
```
nsTransmittedControl: 2.16.840.1.113730.3.4.12 は、プロキシー承認コントロールの OID です。nsTransmittedControl: 1.3.6.1.4.1.1466.29539.12 はループ検出制御になります。
ループ検出制御が設定されているかどうかについて確認し、それに応じて上記のコマンドを調整します。
ACI を設定します。Server 2 で、l=Zanzibar,c=africa,ou=people,dc=example,dc=com 接尾辞の上に接尾辞が存在することを確認し、以下のアクションが利用できるようにします。
- データベースリンク接尾辞の追加
- サーバー 2 で作成されたプロキシー認証ユーザーを使用してサーバー 1 が接続できるようにローカルプロキシー認証 ACI を追加します。
- ローカルクライアントの ACI を追加し、クライアント操作が Server 2 で成功し、サーバー 3 に転送できます。ローカルの ACI チェックが DBLink2 データベースリンクに対して有効になっているため、このローカル ACI が必要です。
どちらの ACI も c=africa,ou=people,dc=example,dc=com 接尾辞が含まれるデータベースに配置されます。
注記
これらの ACI を作成するには、エントリーを保持するために、c =africa,ou=people,dc=example,dc=com 接尾辞に対応するデータベースがすでに存在している必要があります。このデータベースは、各データベースリンクの nsslapd-suffix 属性で指定された接尾辞上の接尾辞と関連付ける必要があります。つまり、最終的な宛先サーバーの接尾辞は、中間サーバーで指定された接尾辞のサブ接尾辞になります。
1. ローカルプロキシー認証 ACI を c=africa,ou=people,dc=example,dc=com エントリーに追加します。
```
aci:(targetattr="*")(target="l=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";)
```
2. 次に、ACI チェックが有効になっているとクライアント操作をサーバー 2 で成功できるようにするローカルクライアント ACI を追加します。この ACI は、l=Zanzibar,c=africa,ou=people,dc=example,dc=com ブランチへのアクセスを提供するために、宛先サーバーで作成された ACI と同じです。c=us,ou=people,dc=example,dc=com 内のすべてのユーザーには、サーバー 3 の l=Zanzibar,c=africa,ou=people,dc=example,dc=com のエントリーへの更新アクセス権が必要になる場合があります。c=africa,ou=people,dc=example,dc=com 接尾辞に以下の ACI を作成し、これを許可します。
```
aci:(targetattr="*")(target="l=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";)
```
  この ACI は、Server 1 の c=us,ou=people,dc=example,dc=com の UID を持つクライアントが、サーバーの l=Zanzibar,c=africa,ou=people,dc=example,dc=com 接尾辞ツリーであらゆる種類の操作を実行できます。Server 2 に、サーバー 3 に追加の権限を必要とする別の接尾辞にユーザーがある場合は、Server 2 に追加のクライアント ACI を追加する必要がある場合があります。

2.4.6.3. サーバーの 3 つの設定

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

dn: cn=server2 proxy admin,cn=config
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: server2 proxy admin
sn: server2 proxy admin
userPassword: secret
description: Entry for use by database links

次に、同じローカルプロキシー承認 ACI を Server 2 にある 3 つのサーバーに追加します。以下のプロキシー承認 ACI を l=Zanzibar,ou=people,dc=example,dc=com エントリーに追加します。
```
aci: (targetattr = "*")(version 3.0; acl "Proxied authorization
     for database links"; allow (proxy) userdn = "ldap:///cn=server2
     proxy admin,cn=config";)
```
この ACI は、l=Zanzibar,ou=people,dc=example,dc=com サブツリー内に含まれるデータに、Server 2 プロキシー管理者にのみ読み取り専用アクセスできるようにします。
元のクライアントアプリケーションに対応する l=Zanzibar,ou=people,dc=example,dc=com サブツリーにローカルクライアント ACI を作成します。Server 2 でクライアントに作成されたものと同じ ACI を使用します。
```
aci: (targetattr ="*")(target="l=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 1 にバインドし、Server 3 の l=Zanzibar,c=africa,ou=people,dc=example,dc=com ブランチの情報を変更できます。セキュリティーのニーズによっては、より詳細なアクセス制御を提供する必要がある場合があります。

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 7 上のデフォルトの場所です。
port は、参照モードで開始する Directory Server のオプションのポート番号です。
referral_url は、クライアントに返される参照先です。LDAP URL の形式は、「付録C LDAP URL」を参照してください。

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

デフォルトの参照は、ディレクトリーが維持する接尾辞内に含まれていない DN に操作を送信するクライアントアプリケーションに返されます。以下の手順では、コンソールおよびコマンドラインユーティリティーを使用して、ディレクトリーのデフォルトリファーラルを設定する方法を説明します。

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

Directory Server コンソールで、Configuration タブを選択します。
左側のペインで、ナビゲーションツリーでトップエントリーを選択します。
右側のペインで Settings タブを選択します。
参照の LDAP URL を入力します。
複数の参照 URL をスペースで区切って入力します。
```
"ldap://dir1.example.com:389/dc=example,dc=com" "ldap://dir2.example.com/"
```
LDAP URL の詳細は、付録C LDAP URL を参照してください。

2.5.2.2. コマンドラインからのデフォルトリファーラルの設定

ldapmodify は、ディレクトリーの設定ファイルの cn=config エントリーにデフォルトの参照を追加できます。たとえば、1 つの Directory Server の dir1.example.com から dir2.example.com という名前のサーバーに新しいデフォルトリファーラルを追加するには、新しい行を cn=config エントリーに追加します。

ldapmodify ユーティリティーを実行し、デフォルトの参照を dir2.example.com サーバーに追加します。

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

dn: cn=config
changetype: modify
replace: nsslapd-referral
nsslapd-referral: ldap://dir2.example.com/

ディレクトリーの cn=config エントリーにデフォルトの参照を追加した後、ディレクトリーはクライアントアプリケーションによるリクエストに対してデフォルトの参照を返します。Directory Server を再起動する必要はありません。

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

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

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

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

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

Directory Server コンソールで、Directory タブを選択します。
左側のナビゲーションペインでツリーを参照して、参照を追加するエントリーを選択します。
エントリーを右クリックし、Set Smart Referrals を選択します。
Enable Smart Referral チェックボックスを選択します。（オプションにチェックを入れると、エントリーからすべてのスマート参照を削除し、エントリーから参照オブジェクトクラスを削除します。）
Enter a new Smart Referral フィールドに、LDAP URL 形式でリファーラルを入力し、Add をクリックします。LDAP URL は以下の形式である必要があります。
```
ldap://server:port/[optional_dn]
```
Server は、サーバーのホスト名、IPv4 アドレス、または IPv6 アドレスになります。optional_dn は、サーバーが要求するクライアントアプリケーションに戻るための明示的な DN です。
構成は、参照の追加プロセスを指示するウィザードが開きます。
スマート参照リストは、選択したエントリーに対して現在参照情報を一覧表示します。参照のリスト全体が、すべてのオペレーションの場合は Return Referrals リクエストに対応してクライアントアプリケーションに返されます。また、Suffix Settings タブの Update Operations オプションの場合は Return Referrals が返されます。これは Configuration タブで利用できます。
一覧を変更するには、Edit をクリックして選択したリファーラルを編集するか、Delete をクリックして選択した参照を削除します。
別の認証情報を使用するように参照を設定するには、Authentication をクリックし、適切な DN とパスワードを指定します。この認証は、コンソールが閉じられるまでのみ有効です。その後、コンソールへのログインに使用されるのと同じ認証にリセットされます。

2.5.3.2. コマンドラインからのスマートリファーラルの作成

ldapmodify コマンドラインユーティリティーを使用して、コマンドラインからスマートリファーラルを作成します。

スマートリファーラルを作成するには、関連するディレクトリーエントリーを作成し、参照オブジェクトクラスを追加します。このオブジェクトクラスは単一の属性 ref を許可します。ref 属性には LDAP URL が含まれている必要があります。

たとえば、以下を追加して、既存のエントリー uid=jdoe のスマートリファーラルを返します。

dn: uid=jdoe,ou=people,dc=example,dc=com
objectclass: referral
ref: ldap://directory.europe.example.com/cn=john%20doe,ou=people,l=europe,dc=example,dc=com

注記

LDAP URL のスペースに続く情報は、サーバーで無視されます。このため、参照として使用する LDAP URL 内の領域の代わりに %20 を使用します。

directory.europe .example.com にリファーラルを持つ uid=jdoe,ou=people,dc= example,dc=com エントリーを追加するには、インポート前に LDIF ファイルに以下を追加します。

dn: uid=jdoe,ou=people,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: referral
cn: john doe
sn: doe
uid: jdoe
ref: ldap://directory.europe.example.com/cn=john%20doe,ou=people,l=europe,dc=example,dc=com

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

2.5.4. バグ修正参照の作成

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

警告

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

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

参照を使用して、クライアントアプリケーションを別のサーバーに一時的にポイントできます。たとえば、接尾辞にリファーラルを追加して、接尾辞と関連したデータベースを、Directory Server データベースのユーザーに影響を与えずに、メンテナンスのために、接尾辞に関連付けられたデータベースをオフにできます。

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

Directory Server コンソールで、Configuration タブを選択します。
左側のペインの Data で、参照を追加する接尾辞を選択します。
Suffix Settings タブをクリックし、Return Referrals for ... を選択します。operations ラジオボタン。
Update Operations で Return Referrals を選択すると、ディレクトリーは更新および書き込みリクエストのみを読み取り専用データベースにリダイレクトします。たとえば、ディレクトリーデータのローカルコピーがあり、そのデータは検索に利用できますが、更新には利用できないため、複数のサーバーに複製されます。Directory Server が更新要求に対してのみ参照を有効にすると、クライアントがエントリーの更新を要求すると、クライアントはデータを所有するサーバー（変更要求を続行できる）と呼ばれます。
Referrals タブをクリックします。LDAP URL を入力します。^[1] Enter a new referral フィールドで、Construct をクリックして LDAP URL を作成します。
Add をクリックして、参照を一覧に追加します。
複数の参照を入力できます。ディレクトリーは、クライアントアプリケーションからのリクエストに対応して参照のリスト全体を返します。

2.5.4.2. コマンドラインからの接尾辞リファーラルの作成

cn=mapping tree,cn=config ブランチ下のディレクトリー設定ファイルの root またはサブ接尾辞エントリーに接尾辞リファーラルを追加します。

ldapmodify を実行し、接尾辞リファーラルを ou=people,dc=example,dc=com root 接尾辞に追加します。

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

dn: cn=ou=people,dc=example,dc=com,cn=mapping tree,cn=config
changetype: add
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: referral
nsslapd-referral: ldap://zanzibar.com/

nsslapd-state 属性は reference に設定されます。つまり、この接尾辞に作成されたリクエストに対して参照が返されます。nsslapd-referral 属性には、接尾辞によって返される参照の LDAP URL が含まれます（この場合は、za nzibar.com サーバーへの参照 ）。

nsslapd-state 属性は、更新時に参照に 設定することもできます。つまり、更新リクエスト以外のすべての操作にデータベースが使用されます。クライアントアプリケーションが更新時に 参照セットに設定された接尾辞の更新リクエストを行うと、 クライアントは参照を受け取ります。

接尾辞設定属性の詳細は、「コマンドラインでのルート接尾辞およびサブ接尾辞の作成」を参照してください。

^[1] 付録C LDAP URL には、LDAP URL の構造に関する詳細が記載されています。

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

本章では、Directory Server Console および ldapmodify および ldapdelete コマンドラインユーティリティーを使用して、ディレクトリーの内容を変更する方法を説明します。

Active Directory に保存されているエントリーは、Windows Sync を介して Directory Server に追加できます。Windows User Sync で同期されたエントリーを追加または変更する方法は、16章Red Hat Directory Server と Microsoft Active Directory の同期 を参照してください。

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 操作を使用します。

たとえば、555-1234567 の値を持つ telephoneNumber 属性を uid=user,dc=people,dc=example,dc=com エントリーに追加するには、以下を実行します。

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

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

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

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

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

3.1.4.2. 属性の値の更新

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

単値属性の更新

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

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

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

多値属性の特定値の更新

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

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

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

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

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

属性の削除

たとえば、uid=user,dc=people,dc=example,dc=com エントリーから manager 属性を削除するには、以下のコマンドを実行します。

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

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

注記

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

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

多値属性から特定の値を削除する場合は、LDIF ステートメントに属性とその値を一覧表示します。たとえば、uid=user,dc=people,dc=example,dc=com エントリーから 555-1234567 に設定されている telephoneNumber 属性だけを削除するには、以下のコマンドを実行します。

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

dn: uid=user,dc=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,dc=people,dc=example,dc=com
changetype: delete

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

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

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

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

注記

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

3.1.6.1. 名前変更操作のタイプ

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

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

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

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

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

3.1.6.3. `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. エントリーまたはサブツリーの名前変更

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

たとえば、cn=old_group,ou=Groups,dc=example,dc=com エントリーの名前を cn= new_group,ou=Groups,dc=example,dc=com に変更するには、次のコマンドを実行します。

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

dn: cn=old_group,ou=Groups,dc=example,dc=com
changetype: modrdn
newrdn: cn=new_group
deleteOldRDN: 1

deleteOldRDN の詳細は、「deleteOldRDN パラメーター」を参照してください。

3.1.6.5. エントリーを新しい親へ移動

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

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

たとえば、uid=ユーザーエントリーを ou= Engineering,ou=People,dc=example,dc=com から ou= Marketing,ou=People,dc=example,dc=com に移動するには、以下を実行します。

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

dn: uid=user,ou=Engineering,ou=People,dc=example,dc=com
changetype: modrdn
newrdn: uid=user
newSuperior= ou=Marketing,ou=People,dc=example,dc=com
deleteOldRDN: 1

deleteOldRDN の詳細は、「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. ディレクトリーコンソールを使用したエントリーの管理

Directory Server コンソールの Directory タブおよび Property Editor を使用して、エントリーを個別に追加、変更、または削除できます。

複数のエントリーを同時に追加するには、「コマンドラインでエントリーの管理」で説明されているコマンドラインユーティリティーを使用します。

「ルートエントリーの作成」
「ディレクトリーエントリーの作成」
「ディレクトリーエントリーの変更」
「ディレクトリーエントリーの削除」

注記

適切なアクセス制御ルールが設定されない限り、ディレクトリーは変更できません。ディレクトリーのアクセス制御ルールを作成する方法は、18章アクセス制御の管理 を参照してください。

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

新しいデータベースが作成されるたびに、データベースに保存される接尾辞に関連付けられます。その接尾辞を表すディレクトリーエントリーは自動的に作成されません。

データベースの root エントリーを作成するには、以下を実行します。

Directory Server コンソールで、Configuration タブを選択します。
左側のメニューの Data エントリーを右クリックし、メニューから New Root Suffix を選択します。
新しい接尾辞およびデータベース情報を入力します。
Directory タブで、Directory Server を表す最上位オブジェクトを右クリックし、New Root Object を選択します。
New Root Object のセカンダリーメニューは、対応するディレクトリーエントリーのない新しい接尾辞を表示します。作成するエントリーに対応する接尾辞を選択します。
New Object ウィンドウで、新規エントリーに対応するオブジェクトクラスを選択します。
オブジェクトクラスには、接尾辞に名前を付けるために使用される属性が含まれている必要があります。たとえば、エントリーが ou=people,dc=example,dc=com の接尾辞に対応している場合は、または ou 属性を許可する別のオブジェクトクラスを選択します。
New Object ウィンドウで OK をクリックします。

新しいエントリーのプロパティーエディターが開きます。「ディレクトリーエントリーの変更」で説明されているように、OK をクリックして現在の値を使用するか、エントリーを変更します。

3.2.2. ディレクトリーエントリーの作成

Directory Server コンソールは、新しいディレクトリーエントリー用に事前に設定したフォームとともに事前定義されたテンプレートを提供します。表3.1「エントリーテンプレートと対応するオブジェクトクラス」は、各テンプレートに使用されるオブジェクトクラスのタイプを表示します。

表3.1 エントリーテンプレートと対応するオブジェクトクラス

Template	オブジェクトクラス
ユーザー	inetOrgPerson
グループ	groupOfUniqueNames
組織単位	organizationalUnit
ロール	nsRoleDefinition
サービスのクラス	cosSuperDefinition

別のタイプ Other では、ユーザーが特定のオブジェクトクラスおよび属性を適用できるようにして、あらゆる種類のエントリーを作成できます。

Directory Server コンソールで、Directory タブを選択します。
左側のペインで、メインエントリーを右クリックして新しいエントリーを追加し、エントリーのタイプ（ User、Group、OrganizationalUnit、Role、Class of Service、または Other ）を選択します。
新しいエントリータイプが Other の場合、オブジェクトクラスの一覧が開きます。一覧からオブジェクトクラスを選択して新規エントリーを定義します。
一覧表示されているすべての属性の値を指定します。必要な属性にはアスタリスク(*)が付いています。
オブジェクトクラス（エントリータイプ）で利用可能な属性の詳細一覧を表示するには、Advanced ボタンをクリックします。
Property Editor で追加の属性を選択し、属性値を入力します。
OK をクリックしてエントリーを保存します。新しいエントリーが右側のペインに表示されます。

3.2.3. ディレクトリーエントリーの変更

Directory Server コンソールのディレクトリーエントリーを変更するには、Property Editor と呼ばれるダイアログウィンドウを使用します。Property Editor には、エントリーに属するオブジェクトクラスおよび属性のリストが含まれ、オブジェクトクラス、属性、属性値、および属性サブタイプを追加および削除することで、そのエントリーに属するオブジェクトクラスおよび属性の編集に使用できます。

プロパティーエディターは、複数の方法で開くことができます。

Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced Properties を選択します。
Directory タブから、エントリーをダブルクリックして、詳細ボタンをクリックします。
Create... new entry フォームから Advanced ボタンをクリックします。
OKをクリックして、新規オブジェクトウィンドウから

3.2.3.1. オブジェクトクラスのエントリーへの追加または削除

オブジェクトクラスをエントリーに追加するには、以下を実行します。

Directory Server コンソールの Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced を選択します。
オブジェクトクラスフィールドを選択し、Add Value をクリックします。
Add Object Class ウィンドウが開きます。これは、エントリーに追加できるオブジェクトクラスの一覧を表示します。
追加するオブジェクトクラスを選択し、OK をクリックします。

エントリーからオブジェクトクラスを削除するには、削除するオブジェクトクラスのテキストボックスに、Delete Value をクリックします。

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

エントリーに属性を追加する前に、エントリーに属性を必要とするか、許可するオブジェクトクラスを含める必要があります。詳細は、「オブジェクトクラスのエントリーへの追加または削除」および 12章ディレクトリースキーマの管理 を参照してください。

エントリーに属性を追加するには、以下を実行します。

Directory Server コンソールの Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced を選択します。
Add Attribute をクリックします。
一覧から追加する属性を選択し、OK をクリックします。
注記
追加する属性が一覧にない場合は、最初に属性が含まれるオブジェクトクラスを追加し、続いて属性を追加します。オブジェクトクラスの追加方法は、「オブジェクトクラスのエントリーへの追加または削除」を参照してください。必要な属性を含むオブジェクトクラスが見つからない場合は、『Red Hat Directory Server 10 Configuration, Command, and File Reference』（この属性を使用するオブジェクトクラスの一覧）の属性を検索します。
属性名の右側にあるフィールドの新しい属性の値を入力します。

エントリーから属性とすべての値を削除するには、Edit メニューから Delete Attribute を選択します。

3.2.3.3. 大きな属性の追加

設定属性 nsslapd-maxbersize は LDAP 要求の最大サイズ制限を設定します。Directory Server のデフォルト設定では、この属性を 2 メガバイトに設定します。要求で 2 メガバイトより大きい非常に大きな属性を追加しようとすると、LDAP の追加または修正操作は失敗します。ただし、この制限はレプリケーションプロセスには適用されません。

非常に大きな属性を追加するには、まず nsslapd-maxbersize 設定属性の設定を、実行する最大の LDAP 要求よりも大きい値に変更します。

設定する値を決定する際には、1 つの属性だけでなく、属性を追加するのに使用される LDAP add および modify 操作 のすべての要素 を考慮してください。考慮すべき要因には、以下が含まれます。

リクエストの各属性名のサイズ
リクエストの各属性の値のサイズ
要求内の DN のサイズ
オーバーヘッド（通常は 10 キロバイト）

nsslapd-maxbersize 設定を増やす必要がある一般的な問題の 1 つは、CRL 値（ certificateRevocationList、authorityRevocationList、および deltaRevocationList など）を保持する属性を使用することです。

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

3.2.3.4. 属性値の追加

多値属性は、1 つの属性に対して複数の値をエントリーに追加できます。

Directory Server コンソールの Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced を選択します。
値を追加する属性を選択し、値の追加をクリックします。
新しい属性値を入力します。

エントリーから属性値を削除するには、削除する属性値のテキストボックスに、Delete Value をクリックします。

3.2.3.5. 属性サブタイプの追加

サブタイプでは、外部文字のセットバージョンを提供するなど、同じエントリー値をさまざまな方法で表すことができます。エントリーに追加できる属性には、言語、バイナリー、および発音の 3 種類のサブタイプがあります。

サブタイプをエントリーに追加するには、次のコマンドを実行します。

Directory Server コンソールの Directory タブで、エントリーを右クリックし、ポップアップメニューから Properties を選択します。
Add Attribute をクリックし、一覧から追加する属性を選択します。
言語ドロップダウンリストから値を選択して、言語サブタイプを追加します。Subtype ドロップダウンリストから値を選択して、バイナリーまたはプローブのサブタイプを追加します。

言語サブタイプ

ユーザーの名前は、デフォルト言語以外の言語の文字でより正確に表現できる場合があります。たとえば、ユーザーである Noriko は日本語の名前を持ち、可能な限り日本語の文字で表現します。指定のname 属性の 言語サブタイプとして日本語を選択して、他のユーザーが日本語と英語で名前を検索できるようにします。以下に例を示します。

givenname;lang-ja

属性に言語サブタイプを指定するには、以下のようにサブタイプを属性名に追加します。

attribute;lang-subtype:attribute value

attribute はエントリーに追加される属性です。サブタイプ は、言語の略語の 2 文字です。サポートされる言語のサブタイプは、表D.1「サポートされる言語サブタイプ」に記載されています。

エントリーの属性 インスタンスごとに 1 つの言語サブタイプのみを追加できます。複数の言語のサブタイプを割り当てるには、別の属性インスタンスをエントリーに追加してから、新しい言語のサブタイプを割り当てます。たとえば、以下は不正なものです。

cn;lang-ja;lang-en-GB:value

代わりに以下を使用します。

cn;lang-ja:ja-value
cn;lang-en-GB:value

バイナリーサブタイプ

バイナリーサブタイプを属性に割り当てると、ユーザー証明書(usercertificate;binary)などの属性値がバイナリーであることを示します。

バイナリーデータ はバイナリー サブタイプ（例： jpegphoto）を含まない属性に保存できますが、バイナリー サブタイプは、属性タイプの複数のバリアントが存在する可能性があるクライアントに対して指定します。

Pronunciation サブタイプ

属性に pronunciation サブタイプを割り当てると、属性値が電話番号であることを示します。サブタイプは、属性名に attribute;phonetic として追加されます。このサブタイプは、一般的に、複数のアルファベットを持つ言語サブタイプと組み合わせて使用されます。1 つは電話番号です。

このサブタイプは、cn や givenname などのユーザー名が含まれることが想定される属性に便利です。たとえば、anyname;lang-ja;phonetic は、属性値がユーザーの日本語名の電話番号であることを示します。

3.2.4. ディレクトリーエントリーの削除

Directory Server コンソールで、Directory タブを選択します。
エントリーを右クリックして削除するメニューから Delete を選択します。

警告

サーバーは、エントリーまたはエントリーを即座に削除します。削除操作を元に戻す方法はありません。

第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 の例

 dn: uid=jsmith,ou=People,dc=example,dc=com
 mail: jsmith@example.com
 uid: jsmith
 givenName: John
 objectClass: top
 objectClass: person
 objectClass: organizationalPerson
 objectClass: inetorgperson
 sn: Smith
 cn: John Smith
 userPassword: {SSHA}EfhKCI4iKl/ipZMsWlITQatz7v2lUnptxwZ/pw==
 entryusn: 1122

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 プラグインの設定

「Directory Server コンソールでプラグインの有効化」で説明されているように、USN プラグインをエントリーに記録するには有効にする必要があります。プラグインは、Directory Server Console またはコマンドラインを使用して有効にできます。以下に例を示します。

# ldapmodify -D "cn=Directory Manager" -W -x
dn: cn=USN,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on

次にサーバーを再起動して変更を適用します。

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

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

USN プラグインを有効にします。「USN プラグインの設定」を参照してください。

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

# ldapmodify -D "cn=Directory Manager" -W -x
dn: cn=config
changetype: modify
replace: nsslapd-entryusn-global
nsslapd-entryusn-global: on

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

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

usn-tombstone-cleanup.pl コマンドは、特定のデータベースバックエンドまたは特定の接尾辞の USN tombstone エントリーを削除します。必要に応じて、特定の USN までの tombstone エントリーをすべて削除できます。以下に例を示します。

# /usr/lib64/dirsrv/instance/usn-tombstone-cleanup.pl -D "cn=Directory Manager" -w secret -s "ou=people,dc=example,dc=com" -m 1100

バックエンドは、- s オプションを使用して、- n オプションまたは接尾辞を使用して指定する必要があります。両方を指定すると、- s オプション の接尾辞が使用されます。

usn-tombstone-cleanup.pl コマンドのオプションは、表4.1「USN-tombstone-cleanup.pl オプション」に一覧表示されます。このツールの詳細は、設定、『コマンド、およびファイルリファレンスを参照してください』。

表4.1 USN-tombstone-cleanup.pl オプション

オプション	詳細
-D rootdn	Directory Manager などの root 権限でユーザー DN を指定します。デフォルトは、Directory Manager の DN です。これは、cn=config 下の `nsslapd-root` 属性から読み取られます。
-m maximum_USN	削除するエントリーの上限を設定します。指定された最大値(inclusive)までの `entryUSN` 値を持つすべての tombstone エントリーは削除されますが、USN 値を超えると削除されます。最大 USN 値が設定されていない場合、すべてのバックエンド tombstone エントリーが削除されます。
-n backendInstance	クリーニングするエントリーが含まれるデータベースの名前を指定します（削除）。
-s suffix	クリーニングするエントリーを含む接尾辞の名前を指定します（削除）。
-w password	ユーザー DN に関連付けられたパスワード。

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

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

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

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

重要

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

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

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

[23/May/2011: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/2011: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/2011: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. コマンドラインを使用した変更の追跡を有効にする方法

変更追跡はデフォルトで有効になっています。Red Hat は、この機能を無効にしないことを推奨します。コマンドラインでエントリー変更の追跡を再度有効にするには、次のコマンドを実行します。

nsslapd-lastmod を on に設定します。

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

dn: cn=config
nsslapd-lastmod: on

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

4.2.3. コンソールを使用した変更の追跡を有効にする方法

変更追跡はデフォルトで有効になっています。Red Hat は、この機能を無効にしないことを推奨します。コンソールを使用してエントリー変更の追跡を再度有効にするには、以下を実行します。

Directory Server コンソールを開きます。「Directory Server コンソールを開く」を参照してください。
Configuration タブでサーバー名を選択します。
Settings タブで Track Entry Modification Times チェックボックスを選択します。
必要に応じて、不足している nsUniqueID 属性を再生成するには、以下を実行します。
1. データベースを LDAP データ交換形式(LDIF)ファイルにエクスポートします。「コマンドラインを使用した LDIF へのデータベースのエクスポート」を参照してください。
2. LDIF ファイルからデータベースをインポートします。「コマンドラインからのインポート」を参照してください。

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

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

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

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

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

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

dn: uid=bjensen,ou=people,dc=example,dc=com
modifiersname: uid=jsmith,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 になります。

nsslapd-plugin-binddn-tracking 属性はデフォルトで無効になっています。サーバーがバインド DN に基づいて操作を追跡できるようにするには、ldapmodify を使用してその属性を有効にします。

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

dn: cn=config
changetype: modify
replace: nsslapd-plugin-binddn-tracking
nsslapd-plugin-binddn-tracking: on

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 プラグインは無効になっています。

注記

プラグインによって生成された操作が複製されるため、マルチマスターレプリケーション環境の 1 つのサプライヤーレプリカでのみ Referential Integrity Postoperation プラグインを有効にします。複数のマスターでプラグインを有効にする場合は、サーバーですでに実行された操作を管理し、再適用する必要があります。

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

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

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

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

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

nsIndexType: pres
nsIndexType: eq
nsIndexType: sub

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

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

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

専用のコンシューマーサーバー (読み取り専用レプリカのみが含まれるサーバー) では有効に しないでください。
読み書きレプリカと読み取り専用レプリカの組み合わせが含まれるサーバーで有効に しないでください。
読み書きレプリカのみが含まれるサプライヤーサーバーで有効にできます。
マルチマスターレプリケーションでは、1 つのサプライヤーでプラグインを有効にします。

レプリケーション環境がこれらのすべての条件を満たす場合は、Referential Integrity Postoperation プラグインを有効にすることができます。

「参照整合性の有効化および無効化」の説明に従って、Referential Integrity Postoperation プラグインを有効にします。
変更ログに整合性の更新を記録するようにプラグインを設定します。
すべてのコンシューマーサーバーで、Referential Integrity Postoperation プラグインが無効になっていることを確認します。
注記
サプライヤーサーバーが Referential Integrity Postoperation 整合性プラグインの変更をコンシューマーサーバーに送信するため、コンシューマーサーバーで Referential Integrity Postoperation プラグインを実行する必要はありません。

5.3. 参照整合性の有効化および無効化

5.3.1. コマンドラインから参照整合性の有効化および無効化

Referential Integrity Postoperation プラグインを有効または無効にするには、プラグインの設定エントリーに nsslapd-pluginEnabled パラメーターを設定します。

たとえば、プラグインを有効にするには、以下を実行します。

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

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

dn: cn=,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on

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

5.3.2. コンソールでの参照整合性の有効化および無効化

Referential Integrity Postoperation プラグインを有効にするには、「Directory Server コンソールでプラグインの有効化」の手順に従います。

5.4. 更新間隔の変更

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

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

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

重要

更新間隔を 0 に設定すると、Referential Integrity Postoperation プラグインの更新間隔を 0 に設定する場合に限り、マルチマスターレプリケーション環境のすべてのマスターでプラグインを有効にすることができます。ただし、1 つのマスターに正の値を設定する場合は、レプリケーションループとディレクトリーの不整合を防ぐために、他のマスターでプラグインを有効にしないでください。

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

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

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

referint-update-delay パラメーターで間隔を秒単位で設定します。

# ldapmodify -D "cn=Directory Manager" -W -x
dn: cn=referential integrity postoperation,cn=plugins,cn=config
changetype: modify
replace: referint-update-delay
referint-update-delay: 0

Directory Server インスタンスを再起動します。
```
# systemctl restart dirsrv@instance_name
```

参照整合性は 1 つのマスターでのみ有効にできます。この間隔を 0 に設定すると、Directory Server は上記の変更をすべてのコンシューマーに即座に複製します。間隔を 0 よりも大きい値に設定し、Referential Integrity が有効なマスターがオフラインである場合は、このマスターが再び起動する前に参照はクリーンアップされません。

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

コンソールを使用して更新間隔を設定するには、以下を行います。

Referential Integrity Postoperation プラグインの設定で Property Editor を開きます。詳細は、「コンソールを使用したプラグインの設定」を参照してください。
referint-update-delay パラメーターで間隔を秒単位で設定します。
Directory Server インスタンスを再起動します。「コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。

5.5. 属性一覧の変更

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

注記

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

5.5.1. コンソールを使用した属性一覧の変更

Referential Integrity Postoperation プラグインの設定で Property Editor を開きます。詳細は、「コンソールを使用したプラグインの設定」を参照してください。
referint-membership-attr 属性の属性を更新します。
値の追加および値の削除ボタンを使用して、値を追加したり、既存の値を削除したりできます。
Directory Server インスタンスを再起動します。「コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。

5.5.2. コマンドラインでの属性一覧の設定

属性リストを更新します。

プラグインが確認および更新される必要があるその他の属性を追加するには、以下を実行します。

# ldapmodify -D "cn=Directory Manager" -W -x

dn: cn=referential integrity postoperation,cn=plugins,cn=config
add: referint-membership-attr
referint-membership-attr: attribute_name

プラグインが確認および更新されなくなった属性を削除するには、以下を実行します。

# ldapmodify -D "cn=Directory Manager" -W -x

dn: cn=referential integrity postoperation,cn=plugins,cn=config
delete: referint-membership-attr
referint-membership-attr: attribute_name

Directory Server インスタンスを再起動します。
```
# systemctl restart dirsrv@instance_name
```

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

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

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

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

nsslapd-pluginEntryScope 属性

この多値属性は、削除または名前変更のエントリーの範囲を制御します。これは、Referential Integrity Postoperation プラグインがユーザーエントリーの削除操作または名前変更操作を検索するサブツリーを定義します。定義されたサブツリーに存在しないユーザーを削除または名前変更した場合、プラグインは操作を無視します。この属性を使用すると、プラグインが操作を適用するデータベースのブランチを指定できます。

nsslapd-pluginEntryScope: dn

nsslapd-pluginExcludeEntryScope 属性

この属性は、削除または名前変更のエントリーの範囲も制御します。これは、Referential Integrity Postoperation プラグインがユーザーの削除や名前変更の操作を無視するサブツリーを定義します。

nsslapd-pluginExcludeEntryScope: dn

nsslapd-pluginContainerScope 属性

この属性は、参照を更新するグループの範囲を制御します。ユーザーの削除後、Referential Integrity Postoperation プラグインはユーザーが属するグループを検索し、それに応じて更新します。この属性は、プラグインがユーザーが属するグループを検索するブランチを指定します。Referential Integrity Postoperation プラグインは、指定のコンテナーブランチにあるグループのみを更新し、その他のグループは更新されないままにします。

nsslapd-pluginContainerScope: dn

第6章 Directory Database への入力

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

6.1. データのインポート

Directory Server には、データをインポートする（Directory Server Console またはインポートツールを使用）、またはレプリケーション用にデータベースを初期化することで、以下のいずれかの方法でデータベースにデータを作成できます。

表6.1「インポート方法の比較」では、インポートとデータベースの初期化の相違点を説明します。

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

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

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

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

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

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

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

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

たとえば、インポートまたは初期化操作の前にサーバーの最大値が 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=jsmith,ou=people,dc=example,dc=com
entryusn: 1001
...

エントリー USN の初期値を設定するには、データをインポートするサーバーまたは初期化を実行するマスターサーバーに nsslapd-entryusn-import-initval 属性を追加するだけです。

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

dn: cn=config
changetype: modify
add: nsslapd-entryusn-import-initval
nsslapd-entryusn-import-initval: next

注記

マルチマスターレプリケーションでは、nsslapd-entryusn-import-initval 属性はサーバー間で 複製されません。つまり、値は、レプリカの初期化に使用しているすべてのサプライヤーサーバーに対して設定する必要があります。

たとえば、Supplier1 に nsslapd-entryusn-import-initval が next に設定され、レプリカの初期化に使用される場合は、インポートされたエントリーのエントリー USN は最も高い値に 1 が追加されます。Supplier2 に nsslapd-entryusn-import-initval が設定されておらず、レプリカの初期化に使用される場合は、Supplier1 および Supplier 2 にマルチマスターレプリカ合意がある場合でも、インポートされたエントリーのすべてのエントリー USN はゼロで始まります。

6.1.2. コンソールからのデータベースのインポート

Directory Server コンソールからインポート操作を実行すると、ldapmodify 操作はデータを追加し、エントリーの変更や削除を行います。この操作は、Directory Server が管理するすべてのデータベースと、Directory Server が設定したデータベースリンクを持つリモートデータベースで実行されます。

インポート操作は、Directory Server コンソールに対してローカルとなるサーバーインスタンスまたは別のホストマシン（リモートインポート操作）で実行できます。

インポートを実行するには、Directory Manager としてログインしている必要があります。

注記

インポート操作に使用される LDIF ファイルは、UTF-8 文字セットエンコーディングを使用する必要があります。インポート操作は、データをローカル文字セットエンコーディングから UTF-8 文字セットエンコーディングに変換しません。

警告

インポートされたすべての LDIF ファイルには、root 接尾辞も含まれている必要があります。

Directory Server コンソールからデータをインポートするには、以下を実行します。

Tasks タブを選択します。画面の下部までスクロールし、Import Database を選択します。
または、Configuration タブを開き、Console メニューから Import を選択します。
Import Database ダイアログボックスで、LDIF ファイルフィールドでインポートする LDIF ファイルへの完全パスを入力するか、Browse をクリックしてインポートするファイルを選択します。
コンソールがマシンのリモートで実行している場合、フィールド名は LDIF ファイルとして表示されます（コンソールを実行するマシン上）。ファイルを参照する場合、Directory Server ホストの現在のディレクトリーは参照されませんが、コンソールを実行しているマシンのファイルシステムも参照しません。
リモートコンソールを使用してデータベースをインポートする場合 は、データベースへの相対パスを使用しないでください。リモートインポートでは、ファイルに相対パス が指定されている場合に Cannot write to file... というエラーで操作に失敗します。リモートインポート操作には常に絶対パスを使用します。
オプションボックスで、以下のオプションのいずれかまたは両方を選択します。
- のみを追加します。LDIF ファイルには、デフォルトの追加手順に加えて、変更および削除手順を含めることができます。サーバーが add 以外の操作を無視するには、Add only チェックボックスを選択します。
- Error に進みます。エラーが発生した場合でもインポートを続行するには、サーバーの Continue on error チェックボックスを選択します。たとえば、このオプションを使用して、新しいものに加えて、データベースにすでに存在するエントリーが含まれる LDIF ファイルをインポートします。サーバーノートでは、すべての新規エントリーの追加中に rejects ファイルの既存のエントリーがあります。
File for Rejects フィールドに、サーバーがインポートできないすべてのエントリーを記録するファイルへの完全パスを入力するか、Browse をクリックして拒否が含まれるファイルを選択します。
拒否は、データベースにインポートできないエントリーです。たとえば、サーバーは、データベースにすでに存在するエントリーや、親オブジェクトのないエントリーをインポートできません。コンソールは、サーバーによって送信されたエラーメッセージが rejects ファイルに書き込みます。
このフィールドを空白のままにすると、サーバーは拒否されたエントリーを記録しません。

サーバーはインポートを実行し、インデックスも作成します。

注記

末尾のスペースは、リモートコンソールのインポート時に破棄されますが、ローカルコンソールまたは ldif2db インポート操作時に保持されます。

6.1.3. コンソールからのデータベースの初期化

データベース内の既存のデータは、データベースを初期化することで上書きできます。

Directory Manager (root DN)を除き、ルートエントリーが含まれる LDIF ファイルをデータベースにインポートできないため、データベースを初期化するために Directory Manager としてログインしている必要があります。Directory Manager のみが、dc =example,dc=com などのルートエントリーにアクセスできます。

警告

LDIF ファイルからデータベースを初期化する場合は、データを復元しない限り、o=NetscapeRoot 接尾辞を上書きしないように注意してください。それ以外の場合は、データベースの初期化により情報が削除され、Directory Server の再インストールが必要になる場合があります。

Directory Server コンソールを使用してデータベースを初期化するには、以下を実行します。

Configuration タブを選択します。
左側のナビゲーションペインで Data tree を展開します。初期化するデータベースの接尾辞を展開し、データベース自体をクリックします。
データベースを右クリックし、Initialize Database を選択します。
または、Object メニューから Initialize Database を選択します。
LDIF file フィールドにインポートする LDIF ファイルへの完全パスを入力するか、Browse をクリックします。
コンソールが、インポートされているファイルのマシンから実行中の場合は、OK をクリックして、即座にインポートに進みます。Console がマシンリモートから LDIF ファイルを含むサーバーに実行している場合は、以下のオプションのいずれかを選択して OK をクリックします。
- ローカルマシンからいる。LDIF ファイルがローカルマシンにあることを示します。
- サーバーマシンから。LDIF ファイルがリモートサーバーにあることを示します。
デフォルトの LDIF ディレクトリーは /var/lib/dirsrv/slapd-instance/ldif です。

6.1.4. コマンドラインからのインポート

コマンドラインでデータをインポートする方法は 4 つあります。

ldif2db の使用。このインポートメソッドはデータベースの内容を上書きし、サーバーを停止する必要があります。「ldif2db コマンドラインユーティリティーを使用したインポート」を参照してください。
Using ldif2db.pl.このインポート方法は、サーバーの実行中にデータベースの内容を上書きします。「ldif2db.pl Perl スクリプトを使用したインポート」を参照してください。
ldif2ldap の使用。このメソッドは、LDAP を介して LDIF ファイルを追加します。このメソッドは、全データベースにデータを追加する場合に便利です。「ldif2ldap コマンドラインスクリプトを使用したインポート」を参照してください。
cn=tasks エントリーの作成。このメソッドは、インポート操作を自動的に起動する一時タスクエントリーを作成します。これは、ldif2db の実行に似ています。「cn=tasks エントリーを使用したインポート」を参照してください。

注記

警告

インポートされたすべての LDIF ファイルには、root 接尾辞も含まれている必要があります。

注記

暗号化したデータベースをインポートするには、スクリプトで -E オプションを使用します。詳細は、「暗号化したデータベースのエクスポートおよびインポート」を参照してください。

6.1.4.1. ldif2db コマンドラインユーティリティーを使用したインポート

ldif2db スクリプトは、指定したデータベースのデータを上書きします。また、このスクリプトでは、インポートの開始時に Directory Server を停止する必要があります。

デフォルトでは、スクリプトは最初に保存してから、既存の o=NetscapeRoot 設定情報を、インポートするファイルの o=NetscapeRoot 設定情報とマージします。

警告

このスクリプトは、データベースのデータを上書きします。

LDIF をインポートするには、以下を行います。

サーバーを停止します。
```
# systemctl stop dirsrv@instance
```
ldif2db コマンドラインスクリプトを実行します。
```
# ldif2db -Z instance_name -n Database1 -i /var/lib/dirsrv/slapd-instance/ldif/demo.ldif -i /var/lib/dirsrv/slapd-instance/ldif/demo2.ldif
```
この例で使用されるパラメーターの詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンスの ldif2db スクリプトの説明を参照してください』。
警告
-n オプションで指定したデータベースが LDIF ファイルに含まれる接尾辞と一致しない場合は、データベースに含まれるすべてのデータが削除され、インポートに失敗します。データベース名が間違っていることがないことを確認してください。
サーバーを起動します。
```
# systemctl start dirsrv@instance
```

6.1.4.2. ldif2db.pl Perl スクリプトを使用したインポート

ldif2db スクリプトと同様に、ldif2db.pl スクリプトは、指定されたデータベースのデータを上書きします。このスクリプトでは、インポートを実行するためにサーバーを実行する必要があります。

警告

このスクリプトは、データベースのデータを上書きします。

ldif2db.pl スクリプトを実行します。

# ldif2db.pl -Z instance_name -D "cn=Directory Manager" -w secret -i /var/lib/dirsrv/slapd-instance/ldif/demo.ldif -n Database1

この例で使用されるパラメーターの詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンスの ldif2db.pl スクリプトの説明を参照してください』。

注記

スクリプトを実行するには root 権限は必要ありませんが、Directory Manager として認証する必要があります。

6.1.4.3. ldif2ldap コマンドラインスクリプトを使用したインポート

ldif2ldap スクリプトは、LDAP を介して LDIF ファイルを追加します。このスクリプトを使用すると、データはすべてのディレクトリーデータベースに同時にインポートされます。ldif2ldap を使用してインポートするには、サーバーが稼働している必要があります。

ldif2ldap を使用して LDIF をインポートするには、以下を実行します。

[root@server ~]# ldif2ldap -Z instance_name -D "cn=Directory Manager" -w secretpwd /var/lib/dirsrv/slapd-instance/ldif/demo.ldif

ldif2ldap スクリプトでは、管理ユーザーの DN、管理ユーザーのパスワード、およびインポートする LDIF ファイルの絶対パスおよびファイル名が必要です。

この例で使用されるパラメーターの詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンスの ldif2ldap スクリプトの説明を参照してください』。

6.1.4.4. cn=tasks エントリーを使用したインポート

Directory Server 設定の cn=tasks,cn=config エントリーは、サーバーがタスクの管理に使用する一時的なエントリーのコンテナーエントリーです。複数の共通ディレクトリータスクには、cn=tasks,cn=config の下にコンテナーエントリーがあります。一時タスクエントリーは、cn=import,cn=tasks,cn=config の下に作成し、インポート操作を開始できます。

ldif2db および ldif2db.pl スクリプトと同様に、cn=tasks のインポート操作はデータベースのすべての情報を上書きします。

このタスクエントリーには以下の 3 つの属性が必要です。

一意の名前(cn)
インポートする LDIF ファイルのファイル名(nsFilename)
ファイルをインポートするデータベースの名前(nsInstance)

ldif2db および ldif2db.pl スクリプトで、- s オプションおよび -x オプションと同様に、インポートを包含または除外する接尾辞の DN を指定することもできます。

エントリーは、「ldapmodify を使用したエントリーの追加」で説明されているように ldapmodify を使用して追加されます。以下に例を示します。

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

dn: cn=example import,cn=import,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn: example import
nsFilename: /home/files/example.ldif
nsInstance: userRoot
nsIncludeSuffix: ou=People,dc=example,dc=com
nsExcludeSuffix: ou=Groups,dc=example,dc=com

タスクが完了するとすぐに、エントリーはディレクトリー設定から削除されます。

この例で使用される属性と、このエントリーに設定できるその他の属性の詳細は、Red Hat Directory Server 設定、コマンド、およびファイルリファレンスの cn=import,cn=tasks,cn=config エントリーの説明を参照してください。『』

6.2. データのエクスポート

LDAP データ交換形式 (LDIF) ファイルは、Directory Server データベースからデータベースエントリーをエクスポートするために使用されます。LDIF は、RFC 2849, 『The LDAP Data Interchange Format(LDIF)- Technical Specification』に記載されている標準形式です。

データのエクスポートは、以下の場合に役に立ちます。

データベースのデータのバックアップを作成します。
別の Directory Server にデータをコピーします。
別のアプリケーションへのデータのエクスポート。
ディレクトリートポロジーの変更後にデータベースを再作成します。

たとえば、ディレクトリーに 1 つのデータベースが含まれ、その内容が 2 つのデータベースに分割されている場合、2 つの新しいデータベースは、古いデータベースの内容をエクスポートし、これを 2 つの新しいデータベースにインポートして、これを 2 つの新しいデータベースにインポートします。図6.1「データベースコンテンツの 2 つのデータベースへの分割」

注記

エクスポート操作は、設定情報 (cn=config)、スキーマ情報 (cn=schema)、または監視情報 (cn=monitor) をエクスポートしません。

図6.1 データベースコンテンツの 2 つのデータベースへの分割

Directory Server コンソールまたはコマンドラインユーティリティーを使用して、データをエクスポートすることができます。

「コンソールを使用したディレクトリーデータの LDIF へのエクスポート」
「コンソールを使用した単一データベースの LDIF へのエクスポート」
「コマンドラインを使用した LDIF へのデータベースのエクスポート」

警告

エクスポート操作中はサーバーを停止しないでください。

6.2.1. コンソールを使用したディレクトリーデータの LDIF へのエクスポート

最終的なエクスポートされたファイルの場所に応じて、一部またはすべてのディレクトリーデータを LDIF にエクスポートできます。LDIF ファイルがサーバーにある場合は、サーバーにローカルにあるデータベースに含まれるデータのみをエクスポートできます。LDIF ファイルがサーバーへのリモートである場合は、すべてのデータベースおよびデータベースリンクをエクスポートすることができます。

エクスポート操作を実行して、Directory Server Console または別のホストマシン（リモートエクスポート操作）にローカルとなるサーバーインスタンスからデータを取得できます。

サーバーの実行中に、Directory Server Console から LDIF にディレクトリーデータをエクスポートします。

Tasks タブを選択します。画面の下部までスクロールし、Export Database(s) をクリックします。
または、Configuration タブを選択して、Console メニューから Export をクリックします。
LDIF File フィールドに LDIF ファイルの完全パスおよびファイル名を入力するか、Browse をクリックしてファイルを見つけます。
コンソールがリモートサーバーで実行している場合、参照は有効になりません。参照ボタンが有効になっていないと、ファイルはデフォルトのディレクトリー /var/lib/dirsrv/slapd-instance/ldif に保存されます。
Console がマシンのリモート上で稼働している場合は、LDIF File フィールドの下に 2 つのラジオボタンが表示されます。
- To local machine を選択して、コンソールを実行しているマシンの LDIF ファイルにデータをエクスポートします。
- To server machine to export to an LDIF file in the server's machine を選択します。
ディレクトリー全体をエクスポートするには、Entire データベースラジオボタンを選択します。
データベースに含まれる接尾辞の単一のサブツリーのみをエクスポートするには、Subtree ラジオボタンを選択してから、Subtree テキストボックスに接尾辞の名前を入力します。このオプションは、複数のデータベースに含まれるサブツリーをエクスポートします。
または、Browse をクリックして接尾辞またはサブツリーを選択します。

6.2.2. コンソールを使用した単一データベースの LDIF へのエクスポート

1 つのデータベースを LDIF にエクスポートすることもできます。サーバーの実行中に以下を行います。

Configuration タブを選択します。
左側のナビゲーションペインで Data tree を展開します。接尾辞を展開し、接尾辞の下にあるデータベースを選択します。
データベースを右クリックし、Export Database を選択します。
または、Object メニューから Export Database を選択します。
LDIF file フィールドで、LDIF ファイルへの完全パスを入力するか、Browse をクリックします。
参照ボタンが有効になっていないと、ファイルはデフォルトのディレクトリー /var/lib/dirsrv/slapd-instance/ldif に保存されます。

6.2.3. コマンドラインを使用した LDIF へのデータベースのエクスポート

Directory Server は、データを LDIF ファイルにエクスポートする方法をサポートします。

6.2.3.1. Directory Server の実行中にデータベースのエクスポート

Directory Server の実行中にデータベースをエクスポートするには、エクスポートタスクを作成します。db2ldif.pl スクリプトを使用してこれを作成するか、手動でタスクを作成することができます。タスクが完了すると、Directory Server は、cn =export,cn=tasks,cn=config エントリーからタスクエントリーを自動的に削除します。

タスクエントリーの属性を設定する db2ldif.pl コマンドラインオプションを比較する場合は、『Red Hat Directory Server Configuration, Command, and File Referenceを参照してください』。

6.2.3.1.1. db2ldif.pl スクリプトを使用したデータベースのエクスポート

db2ldif.pl スクリプトは、Directory Server の実行中にデータベースをエクスポートするタスクを作成します。たとえば、userRoot データベースをエクスポートするには、以下のコマンドを実行します。

# db2ldif.pl -Z instance_name -D "cn=Directory Manager" -w - -n userRoot

デフォルトでは、スクリプトは、エクスポートされたデータを /var/lib/dirsrv/slapd-instance_name/ldif/ ディレクトリーに保存します。作成されたファイルには instance_name -database_or_suffix_name -time_ stamp.ldif という名前が付けられ ます。または、- a file_name オプションをスクリプトに渡して別の場所を設定することもできます。Directory Server ユーザーには、宛先ディレクトリーに書き込みパーミッションが必要になることに注意してください。

利用可能なコマンドラインオプションの詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンスのスクリプトの説明を参照してください』。

暗号化されたデータベースをエクスポートするには、「暗号化したデータベースのエクスポートおよびインポート」を参照してください。

6.2.3.1.2. エクスポートタスクの手動作成

db2ldif.pl スクリプトを使用してエクスポートタスクを作成する代わりに、タスクエントリーを手動で作成できます。たとえば、userRoot データベースを /tmp/export.ldif ファイルにエクスポートするタスクを作成するには、以下を実行します。

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

dn: cn=task_name,cn=export,cn=tasks,cn=config
objectclass: extensibleObject
cn: task_name
nsInstance: userRoot
nsFilename: /tmp/export.ldif

エクスポートタスクエントリーに使用できる設定の一覧は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンスを参照してください』。

6.2.3.2. Directory Server が Stopped 中にデータベースのエクスポート

Directory Server インスタンスが停止している間にデータベースをエクスポートするには、db 2ldif スクリプトを使用します。このスクリプトは、db 2ldif.pl スクリプトと同じオプションを取ります。これは、インスタンスの実行中にデータをエクスポートできます。

たとえば、インスタンスの停止中に userRoot データベースをエクスポート するには、以下を実行します。

# db2ldif -Z instance_name -n userRoot

6.3. データのバックアップおよび復元

データベースは、Directory Server コンソールまたはコマンドラインスクリプトを使用してバックアップおよび復元できます。バックアップには以下が含まれます。以下に例を示します。

それらのデータベース内に格納されているデータを含む、userRoot および NetscapeRoot などの全データベースファイル
トランザクションログ
インデックス

バックアップとは対照的に、「データのエクスポート」の説明に従ってデータをエクスポートできます。エクスポート機能を使用して、LDAP Data Interchange Format (LDIF) 形式のサーバーからサブツリーなどの特定のデータをエクスポートします。

本セクションでは、以下の手順について説明します。

「すべてのデータベースのバックアップ」
「dse.ldif 設定ファイルのバックアップ」
「すべてのデータベースの復元」
「単一データベースの復元」
「複製されたエントリーが含まれるデータベースの復元」
「dse.ldif 設定ファイルの復元」

警告

バックアップまたは復元操作中にサーバーを停止しないでください。

6.3.1. すべてのデータベースのバックアップ

以下の手順では、Directory Server コンソールとコマンドラインから、ディレクトリー内のすべてのデータベースのバックアップを説明します。

注記

これらのバックアップメソッドは、データベースリンクを使用してチェーンされるリモートサーバーのデータベースに含まれるデータのバックアップには使用できません。

6.3.1.1. コンソールからのすべてのデータベースのバックアップ

Directory Server コンソールからデータベースをバックアップする場合、サーバーはすべてのデータベースコンテンツおよび関連するインデックスファイルをバックアップの場所にコピーします。サーバーの実行中にバックアップを実行できます。

Directory Server コンソールからデータベースをバックアップするには、以下を実行します。

Tasks タブを選択します。
Directory Server のバックアップをクリックします。
Directory テキストボックスにバックアップファイルを保存するディレクトリーの完全パスを入力するか、Use default をクリックすると、サーバーはバックアップディレクトリーの名前を指定します。
コンソールがディレクトリーと同じマシンで実行されている場合は、Browse をクリックしてローカルディレクトリーを選択します。
デフォルトの場所で、バックアップファイルは /var/lib/dirsrv/slapd-instance/bak に配置されます。デフォルトでは、バックアップディレクトリー名にはサーバーインスタンスの名前が含まれ、バックアップが作成された日時(instance-YYYY_MM_DD_hhmmss)が含まれます。

6.3.1.2. コマンドラインでのすべてのデータベースのバックアップ

データベースは、db2bak コマンドラインスクリプトまたは db2bak.pl Perl スクリプトを使用してコマンドラインからバックアップできます。コマンドラインスクリプトは、サーバーの実行時またはサーバーが停止しているときに機能します。Perl スクリプトは、サーバーが実行されているときにのみ使用できます。

重要

バックアップされるデータベースがマスターデータベース（つまり changelog）である場合は、db 2bak.pl Perl スクリプトを使用してバックアップするか、サーバーが実行中の場合は Directory Server Console を使用してバックアップする必要があります。changelog は、サーバーのシャットダウン時に RUV エントリーをデータベースに書き込みます。サーバーの実行中に changelog はその変更をメモリーに保持します。Perl スクリプトとコンソールの場合、これらの changelog RUV は、バックアッププロセスの実行前にデータベースに書き込まれます。ただし、この手順はコマンドラインスクリプトでは実行されません。

db2bak は、実行中のマスターサーバーでは実行しないでください。Perl スクリプトを使用するか、またはサーバーを停止してからバックアップを実行します。

このバックアップ方法で設定情報をバックアップ することはできません。設定情報をバックアップする方法は、「dse.ldif 設定ファイルのバックアップ」を参照してください。

db2bak.pl スクリプトを使用してコマンドラインからディレクトリーをバックアップするには、バックアップのファイル名とディレクトリーを指定して、Perl スクリプト db2bak.pl を実行します。

# db2bak.pl -Z instance_name -D "cn=Directory Manager" -w password -a /var/lib/dirsrv/slapd-example/bak/instance-2020_04_30_16_27_5-custom-name

注記

-a オプションを使用して nsslapd-bakdir ディレクティブで設定したデフォルトのバックアップディレクトリーを指定する場合は、末尾のスラッシュ("/")を使用しないでください。以下に例を示します。

# db2bak.pl -Z instance_name -D "cn=Directory Manager" -w password -a /var/lib/dirsrv/slapd-example/bak

slapd-example/bak の後にスラッシュがないことに注意してください。

この制限は、nsslapd-bakdir で設定されるディレクトリーと同じディレクトリーを指定する場合にのみ適用されます。デフォルトのバックアップディレクトリー（ bak/custom-name/など）内であっても、他のディレクトリーは、末尾のスラッシュの有無でも指定できます。

サーバーがバックアップしたデータベースを保存するバックアップディレクトリーは、スクリプトで指定できます。ディレクトリーを指定しないと、バックアップファイルは /var/lib/dirsrv/slapd-instance/bak に保存されます。デフォルトでは、バックアップディレクトリーは Directory Server インスタンス名とバックアップの日付(serverID-YYYY_MM_DD_hhmmss)で名前が付けられます。

ldif2db の詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンスのスクリプトの説明を参照してください』。

6.3.1.3. cn=tasks エントリーを使用したデータベースのバックアップ

Directory Server 設定の cn=tasks,cn=config エントリーは、サーバーがタスクの管理に使用する一時的なエントリーのコンテナーエントリーです。複数の共通ディレクトリータスクには、cn=tasks,cn=config の下にコンテナーエントリーがあります。一時タスクエントリーは、cn=backup,cn=tasks,cn=config の下に作成し、バックアップ操作を開始できます。

バックアップタスクエントリーには以下の 3 つの属性が必要です。

一意の名前(cn)
バックアップファイルを書き込むディレクトリー(nsArchiveDir)。バックアップファイルには、Directory Server インスタンス名とバックアップの日付(serverID-YYYY_MM_DD_hhmmss)という名前が付けられます。
データベースのタイプ(nsDatabaseType)。唯一のオプションは ldbm データベース です。

エントリーは、「ldapmodify を使用したエントリーの追加」で説明されているように ldapmodify を使用して追加されます。以下に例を示します。

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

dn: cn=example backup,cn=backup,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn: example backup
nsArchiveDir: /export/backups/
nsDatabaseType: ldbm database

タスクが完了するとすぐに、エントリーはディレクトリー設定から削除されます。

この例で使用される属性と、このエントリーに設定できるその他の属性の詳細は、Red Hat Directory Server 設定、コマンド、およびファイルリファレンスの cn=backup,cn=tasks,cn=config エントリーの説明を参照してください。『』

6.3.2. dse.ldif 設定ファイルのバックアップ

Directory Server は、dse.ldif 設定ファイルを自動的にバックアップします。Directory Server が起動すると、ディレクトリーは、/etc/dirsrv/slapd-instance ディレクトリーの dse.ldif.startOK という名前のファイルに dse.ldif ファイルのバックアップ を自動的に作成します。

dse.ldif ファイルが変更されると、ファイルが最初に /etc/dirsrv/slapd-instance ディレクトリーの dse.ldif.bak というファイルにバックアップされ、ディレクトリーが dse.ldif ファイルに変更が書き込まれます。

6.3.3. すべてのデータベースの復元

以下の手順では、Directory Server コンソールとコマンドラインから、ディレクトリー内のすべてのデータベースを復元する方法を説明します。

注記

バックアップからデータベースを復元すると、changelog も復元します。

重要

データベースの復元中、サーバーが稼働している必要があります。ただし、復元中にデータベースが処理操作の対象になります。

したがって、データベースを復元する前に、すべてのレプリケーションプロセスを停止します。詳細は、「レプリカ合意の無効化および再有効化」を参照してください。

6.3.3.1. コンソールからのすべてのデータベースの復元

データベースが破損したら、Directory Server コンソールを使用して、以前に生成されたバックアップからデータを復元します。このプロセスは、サーバーを停止し、データベースおよび関連するインデックスファイルをバックアップの場所からデータベースディレクトリーにコピーすることで構成されます。

警告

データベースの復元は、既存のデータベースファイルを上書きします。

重要

データベースの復元中、サーバーが稼働している必要があります。ただし、復元中にデータベースが処理操作の対象になります。

以前に作成したバックアップからデータベースを復元するには、以下を行います。

Directory Server コンソールで、Tasks タブを選択します。
Directory Server のリストアをクリックします。
Available Backups リストからバックアップを選択するか、Directory テキストボックスに既存のバックアップへの完全パスを入力します。
利用可能なバックアップの一覧には、デフォルトのディレクトリー /var/lib/dirsrv/slapd-instance/bak/backup_directory にあるバックアップがすべて表示されます。backup_directory は、serverID-YYYY_MM_DD_hhmmss 形式の最新のバックアップのディレクトリーです。

6.3.3.2. コマンドラインでのデータベースの復元

コマンドラインからデータベースを復元する方法は 3 つあります。

bak2db コマンドラインスクリプトの使用このスクリプトでは、サーバーをシャットダウンする必要があります。
Perl スクリプト bak2db.pl の使用。このスクリプトは、サーバーの実行中に機能します。
cn=restore,cn=tasks,cn=config に一時的なエントリーを作成します。この方法は、サーバーの実行中に実行することもできます。

重要

データベースの復元中はサーバーが実行されている必要があります（ bak2db コマンドラインスクリプトの実行を除く）。ただし、復元中にデータベースが処理操作の対象になります。

6.3.3.2.1. bak2db コマンドラインユーティリティーの使用

Directory Server を実行している場合は、停止します。
```
# systemctl stop dirsrv@instance
```
bak2db コマンドラインスクリプトを実行します。bak2db スクリプトには、入力ファイルの完全パスおよび名前が必要です。
```
# bak2db -Z instance_name /var/lib/dirsrv/slapd-instance/bak/instance-2020_04_30_11_48_30
```
この例で使用されるパラメーターの詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンスの bak2db スクリプトの説明を参照してください』。

6.3.3.2.2. bak2db.pl Perl スクリプトの使用

bak2db.pl Perl スクリプトを実行します。

# bak2db.pl -Z instance_name -D "cn=Directory Manager" -w secret -a /var/lib/dirsrv/slapd-instance/bak/instance-2020_04_30_11_48_30

この例で使用されるパラメーターの詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンスの bak2db.pl スクリプトの説明を参照してください』。

重要

データベースの復元中、サーバーが稼働している必要があります。ただし、復元中にデータベースが処理操作の対象になります。

6.3.3.2.3. cn=tasks エントリーを使用したデータベースの復元

Directory Server 設定の cn=tasks,cn=config エントリーは、サーバーがタスクの管理に使用する一時的なエントリーのコンテナーエントリーです。複数の共通ディレクトリータスクには、cn=tasks,cn=config の下にコンテナーエントリーがあります。一時タスクエントリーは、cn=restore,cn=tasks,cn=config の下に作成し、復元操作を開始できます。

重要

データベースの復元中、サーバーが稼働している必要があります。ただし、復元中にデータベースが処理操作の対象になります。

復元タスクエントリーには、バックアップタスクと同じ 3 つの属性が必要です。

一意の名前(cn)
バックアップファイルを取得するディレクトリー(nsArchiveDir)
データベースのタイプ(nsDatabaseType)。唯一のオプションは ldbm データベース です。

エントリーは、「ldapmodify を使用したエントリーの追加」で説明されているように ldapmodify を使用して追加されます。以下に例を示します。

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

dn: cn=example restore,cn=restore,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn: example restore
nsArchiveDir: /export/backups/
nsDatabaseType: ldbm database

タスクが完了するとすぐに、エントリーはディレクトリー設定から削除されます。

この例で使用される属性と、このエントリーに設定できるその他の属性の詳細は、Red Hat Directory Server 設定、コマンド、およびファイルリファレンスの cn=restore,cn=tasks,cn=config エントリーの説明を参照してください。『』

6.3.4. 単一データベースの復元

Directory Server コンソールではなく、コマンドラインで単一のデータベースを復元することが可能です。単一データベースを復元するには、以下を実行します。

Directory Server が実行している場合は停止します。
```
# systemctl stop dirsrv@instance
```
-n パラメーターを使用してデータベース名を指定し、 /var/lib/dirsrv/slapd-instance/bak アーカイブからバックエンドを復元します。以下に例を示します。
```
# bak2db -Z instance_name /var/lib/dirsrv/slapd-instance/bak/backup_file -n userRoot
```
Directory Server を再起動します。
```
# systemctl start dirsrv@instance
```
注記
Directory Server の起動に失敗した場合は、/var/lib/dirsrv/slapd-instance/db/log.### のデータベーストランザクションログファイルを削除してから、サーバーの起動を再試行します。

6.3.5. 複製されたエントリーが含まれるデータベースの復元

サプライヤーサーバーを復元すると、いくつかの状況が発生する可能性があります。

コンシューマーサーバーも復元します。
非常にまれな状況では、すべてのデータベースで、(データが同期されるため)、コンシューマーはサプライヤーと同期したままとなり、他に何もする必要はありません。レプリケーションは中断せずに再開します。
サプライヤーだけが復元します。
サプライヤーのみが復元された場合や、コンシューマーが別のバックアップから復元された場合は、サプライヤーがコンシューマーを再初期化して、データベースのデータを更新します。サプライヤーのみが復元された場合や、コンシューマーが別のバックアップから復元された場合は、サプライヤーがコンシューマーを再初期化して、データベースのデータを更新します。
サプライヤーサーバーでチェンジログエントリーの有効期限が切れていません。
データベースのバックアップの取得�

Language:

Language and Page Formatting Options

Language:

Red Hat Training

管理ガイド

Directory Server 10.6 の更新

非推奨のドキュメント

第1章 Red Hat Directory Server の基本設定

1.1. システム要件

1.2. ファイルの場所

1.3. Directory Server 管理コンソールの起動

1.3.1. Directory Server コンソールを開く

1.3.2. 管理コンソールを開く

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

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

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

1.5. Directory Server 管理サーバーサービスの起動と停止

1.5.1. コマンドラインを使用した管理サーバーサービスの起動と停止

1.5.2. コンソールを使用した管理サーバーのサービスの再起動および停止

1.6. LDAPI の有効化

1.7. Directory Server ポート番号の変更

1.7.1. 標準ポート番号の変更

1.7.2. LDAPS ポート番号の変更

1.8. Directory Server インスタンスの管理

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

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

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

1.8.2.1.1. Directory Server インスタンスおよび管理サーバーの削除

1.8.3. コンソールを使用した Directory Server インスタンスの削除

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

1.9.1. プラグインを動的に有効化

1.9.2. プラグインの有効化

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

1.9.2.2. Directory Server コンソールでプラグインの有効化

1.9.3. プラグインの設定

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

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

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

1.10. サーバー設定属性

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

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

2.1.1. 接尾辞の作成

2.1.1.1. コンソールを使用した新規ルート接尾辞の作成

2.1.1.2. コンソールを使用した新しい従属接尾辞の作成

2.1.1.3. コマンドラインでのルート接尾辞およびサブ接尾辞の作成

ルート接尾辞の作成

従属接尾辞の作成

2.1.2. 接尾辞の維持

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

2.1.2.2. 接尾辞の無効化

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

2.1.2.2.2. コンソールを使用した接尾辞の無効化

2.1.2.3. 接尾辞の削除

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

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

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

2.2.1. データベースの作成

2.2.1.1. コンソールを使用した既存の接尾辞の新規データベースの作成

2.2.1.2. コマンドラインから単一の接尾辞用の新規データベースの作成

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

2.2.1.3.1. Directory Server コンソールを使用したカスタムディストリビューション機能の接尾辞への追加

2.2.1.3.2. コマンドラインを使用したカスタムディストリビューション機能の接尾辞への追加

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

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

2.2.2.1.1. コンソールを使用したデータベースの読み取り専用の設定

2.2.2.1.2. コマンドラインからデータベースの読み取り専用の設定

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

2.2.2.2. データベースの削除

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

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

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

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

2.3.1.2. コマンドラインからのデータベースリンクの作成

2.3.1.2.1. 接尾辞情報の提供

2.3.1.2.2. バインド認証情報の提供

2.3.1.2.3. LDAP URL の提供

2.3.1.2.4. フェイルオーバーサーバーの一覧の提供

2.3.1.2.5. 異なるバインドメカニズムの使用

2.3.1.2.6. データベースリンクの設定属性の概要

2.3.1.2.7. データベースリンクの設定例

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

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