管理ガイド
Directory Server 10.6 の更新
概要
非推奨のドキュメント
第1章 Red Hat Directory Server の基本設定
- Directory Server は、コア LDAP サーバーデーモンです。これは LDAP v3 標準に準拠しています。このコンポーネントには、データベースのエクスポートやバックアップなどの一般的な操作を行うためのコマンドラインサーバー管理プログラムおよびスクリプトが含まれます。
- Directory Server コンソールは、ユーザー、グループ、およびその他の LDAP データの管理を簡素化するユーザーインターフェースです。コンソールは、バックアップ、セキュリティー、レプリケーション、データベース設定、サーバーの監視、統計の表示など、サーバー管理のすべての側面に使用されます。
- 管理サーバーは、Directory Server インスタンスを管理する管理エージェントです。Directory Server コンソールと通信し、Directory Server インスタンスで操作を実行します。また、簡単な HTML インターフェースおよびオンラインヘルプページも提供します。
1.1. システム要件
1.2. ファイルの場所
1.3. Directory Server 管理コンソールの起動
- Directory Server インスタンスの管理
- 管理サーバーの管理
- ユーザーおよびグループの管理
# redhat-idm-console
1.3.1. Directory Server コンソールを開く
- Directory Server 管理コンソールを起動します。
# redhat-idm-console
cn=Directory Manager
ユーザーとしてログインします。- Servers and Applications タブで → に移動し、 をクリックします。
1.3.2. 管理コンソールを開く
- Directory Server 管理コンソールを起動します。
# redhat-idm-console
cn=Directory Manager
ユーザーとしてログインします。- Servers and Applications タブで → → に移動し、 をクリックします。
1.4. Directory Server インスタンスの起動および停止
1.4.1. コマンドラインを使用した Directory Server インスタンスの起動および停止
- インスタンスを起動するには、以下のコマンドを実行します。
# systemctl start dirsrv@instance_name
- インスタンスを停止するには、以下のコマンドを実行します。
# systemctl stop dirsrv@instance_name
- インスタンスを再起動するには、以下のコマンドを実行します。
# systemctl restart dirsrv@instance_name
- 単一のインスタンスの場合:
# systemctl enable dirsrv@instance_name
- サーバー上のすべてのインスタンスの場合:
# systemctl enable dirsrv.target
1.4.2. コンソールを使用した Directory Server インスタンスの起動および停止
- コマンドラインを使用してサービスを管理します。「コマンドラインを使用した Directory Server インスタンスの起動および停止」 を参照してください。
- パスワードファイルを作成します。「Directory Server のパスワードファイルの作成」を参照してください。
- Directory Server コンソールを起動し、
cn=Directory Manager
ユーザー名を使用してログインします。詳細は、「管理コンソールを開く」 を参照してください。 - Servers and Applications タブで → に移動し、 をクリックします。
- Tasks タブで、実行するタスクをクリックします。
1.5. Directory Server 管理サーバーサービスの起動と停止
1.5.1. コマンドラインを使用した管理サーバーサービスの起動と停止
- サービスを起動するには、以下を実行します。
# systemctl start dirsrv-admin
- サービスを停止するには、以下を実行します。
# systemctl stop dirsrv-admin
- サービスを再起動するには、以下を実行します。
# systemctl restart dirsrv-admin
# systemctl enable dirsrv-admin
1.5.2. コンソールを使用した管理サーバーのサービスの再起動および停止
- Directory Server コンソールを起動し、
cn=Directory Manager
ユーザー名を使用してログインします。詳細は、「管理コンソールを開く」 を参照してください。 - Servers and Applications タブで → → に移動し、 をクリックします。
- Tasks タブで、実行するタスクをクリックします。
1.6. LDAPI の有効化
nsslapd-ldapilisten
Directory Server の LDAPI を有効にするには、以下を実行します。nsslapd-ldapifilepath
Unix ソケットファイルを参照する
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 ポート番号の変更
dse.ldif
の cn=config エントリー下の nsslapd-port
または nsslapd-secureport
属性の値を変更することで変更できます。
1.7.1. 標準ポート番号の変更
- Directory Server コンソールの Configuration タブを選択し、左側のペインのナビゲーションツリーでトップエントリーを選択します。
- 右側のペインで Settings タブを選択します。
- ポート番号を変更します。Port フィールドで TLS 以外の通信に使用するサーバーのポート番号。デフォルト値は 389 です。
- コンソールは警告を返します。設定ディレクトリーのポート番号を変更します。これは、このディレクトリーを使用するすべての管理サーバーに影響が及ぶため、新しいポート番号で更新する必要があります。ポート番号を変更してもよろしいですか? をクリックします。
- その後、サーバーが再起動するまで変更が反映されないことを示すダイアログが表示されます。をクリックします。注記この時点で 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 をクリックします。サーバーを再起動することを確認するダイアログ。 をクリックします。
- 管理コンソールの Configuration DS タブを開き、 を選択します。ダイアログが表示され、読み取り Directory Server 設定が変更されました。変更を有効にするには、管理サーバーとサーバーグループのすべてのサーバーをシャットダウンする必要があります。 をクリックします。
- 管理コンソールの Tasks タブで、Restart Admin Server をクリックします。管理サーバーが正常に再起動したことを示すダイアログが開きます。 をクリックします。注記コンソールで その他の操作を行う前に、コンソールを閉じて再度開く必要があります。更新してもコンソールを更新できず、何も実行しようとすると、Unable to contact LDAP server という警告が表示されます。
1.7.2. LDAPS ポート番号の変更
- また、管理サーバー設定で Directory Server のポート番号も更新する必要があります。
- 設定またはユーザーディレクトリーを参照するその他の Directory Server インスタンスがある場合は、これらのサーバーを更新して新しいポート番号を指定します。
- 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 インスタンスの作成
1.8.2. Directory Server インスタンスの削除
1.8.2.1. コマンドラインを使用した Directory Server インスタンスの削除
# remove-ds.pl -i slapd-instance_name -a
a
(all)オプションが指定されている場合は、関連するファイルおよびディレクトリーを削除します。ただし、Directory Server インスタンスは、設定 Directory Server から登録解除されません。
鍵と証明書
ファイルは
インスタンス設定ディレクトリーに残り、設定ディレクトリーの名前が slapd-instance-name.removed になります
。(以下に示すように) -a
オプションを使用すると、セキュリティーデータベースも削除されます。
f
オプションを試して、強制的に削除プロセスを実行します。
1.8.2.1.1. Directory Server インスタンスおよび管理サーバーの削除
y
オプションが必要です。それ以外の場合は、remove-ds-admin.pl スクリプトはドライランを実行しますが、サーバーは削除されません。
-a
オプションは必須ではありませんが、Directory Server または管理 Server インスタンスが後で再設定できる場合は推奨されます。デフォルトでは、すべてのセキュリティーデータベースは削除スクリプトで保持されます。-a
オプションは、セキュリティーデータベースも削除します。
f
オプションを試して、強制的に削除プロセスを実行します。
1.8.3. コンソールを使用した Directory Server インスタンスの削除
- Directory Server コンソールを開きます。詳細は、「Directory Server コンソールを開く」 を参照してください。
- サーバーインスタンスを右クリックし、Remove Server を選択します。
- Yes をクリックして確定します。
1.9. Directory Server プラグインの使用
1.9.1. プラグインを動的に有効化
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
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. コマンドラインでプラグインの有効化
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 コンソールで、Configuration タブを選択します。
- ナビゲーションツリーの Plugins フォルダーをダブルクリックします。
- Plugins 一覧からプラグインを選択します。
- プラグインを無効にするには、有効 の チェックボックスの選択を解除 します。プラグインを有効にするには、このチェックボックスを選択します。
- Directory Server を再起動します。
# systemctl restart dirsrv@instance
1.9.3. プラグインの設定
nsslapd-pluginarg*
属性を使用してプラグインを設定しました。Directory Server 10 は、特定のプラグインに特定の設定属性のサポートを追加しました。
nsslapd-pluginarg*
属性がプラグインの設定に設定されている場合、Directory Server はプラグイン固有の属性の設定のみを使用します。
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
例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. コマンドラインでプラグインの設定
- プラグイン設定の識別名(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 コンソールを起動し、
cn=Directory Manager
ユーザー名を使用してログインします。詳細は、「管理コンソールを開く」 を参照してください。 - Servers and Applications タブで → に移動し、 をクリックします。
- 右側のパネルでボタンをクリックします。注記Red Hat は、プラグイン固有の属性を使用する Property Editor を使用してプラグインを設定することを推奨します。
- プラグイン固有の属性を設定します。
- Property Editor を閉じます。をクリックして、
- Directory Server を再起動します。詳細は、「コンソールを使用した管理サーバーのサービスの再起動および停止」 を参照してください。
1.9.4. プラグインの優先順位の設定
nsslapd-pluginPrecedence
属性で設定されます。この属性の値は、1(最も高い優先度)から 99(最も低い優先度)です。属性が設定されていない場合、デフォルト値は 50 になります。
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. サーバー設定属性
/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 は、サポートされていて利用可能な、そして最も強力なパスワードストレージスキームを使用します。今後の更新で、セキュリティーを向上させるためにデフォルト値を変更すると、パスワードを設定する際に、新しいストレージスキームを使用してパスワードが自動的に暗号化されます。注記パラメーターを手動でデフォルトと同じ値に設定すると、値は更新されません。これは、新しいバージョンのデフォルト値が異なる場合に発生します。
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 つのルート接尾辞があるディレクトリーツリー
ou=people
接尾辞と、その下のすべてのエントリーおよびノードは 1 つのデータベースに保存され、ou=groups
接尾辞は別のデータベースに保存され、ou=contractors 接尾辞はまた別のデータベースに保存される可能性があります。
2.1.1. 接尾辞の作成
redhat .com
用など
、複数の Web サイトをホストする場合があります。ここでは、2 つのルート接尾辞が必要です。1 つは dc=example,dc=com
命名コンテキストに対応し、図2.2「2 つのルート接尾辞があるディレクトリーツリー」 のように、dc =redhat,dc=com
命名コンテキストに対応するものになります。
図2.2 2 つのルート接尾辞があるディレクトリーツリー
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,dc=com
のルート接尾辞を作成し、ヨーロッパのディレクトリーエントリー l=europe,dc=example,dc=com
の下にサブ接尾辞を作成します。クライアントアプリケーションの観点からは、ディレクトリーツリーは 図2.4「従属接尾辞が含まれるディレクトリーツリー」 に示されるように表示されます。
図2.4 従属接尾辞が含まれるディレクトリーツリー
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 フィールドに新規データベースの一意の名前を入力します。名前は、英数字、ダッシュ(-)、およびアンダースコア(_)
の組み合わせになります。
他の文字は使用できません。チェックボックスの選択を解除して、後で新しいルート接尾辞のデータベースを作成します。このオプションは、データベースが作成されるディレクトリーを指定します。新しいルート接尾辞は、データベースが作成されるまで無効になります。
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 フィールドに新規データベースの一意の名前を入力します。名前は、英数字、ダッシュ(-)、およびアンダースコア(_)
の組み合わせになります。
他の文字は使用できません。このチェックボックスを選択しないと、新しいサブ接尾辞のデータベースよりも後で作成する必要があります。データベースが作成されるまで、新しいサブ接尾辞が無効になります。
2.1.1.3. コマンドラインでのルート接尾辞およびサブ接尾辞の作成
cn=mapping tree,cn=config
エントリーに保存されます。ldapmodify ユーティリティーを使用して、新しい接尾辞をディレクトリーに追加します。
ルート接尾辞の作成
# 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
従属接尾辞の作成
nsslapd-parent-suffix
に親接尾辞を設定する点です。
# 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. デフォルトの命名コンテキストの表示
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. データベースの作成
- 各接尾辞に 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. 単一の接尾辞に複数のデータベースの追加
- ディストリビューション機能は、エントリーディストリビューションのデプロイ後は変更できません。
- エントリーを異なるデータベースに分散させる可能性がある場合は、LDAP modrdn 操作を使用してエントリーの名前を変更することができません。
- 分散ローカルデータベースは複製できません。
- エントリーを異なるデータベースに分散させる可能性がある場合は、ldapmodify 操作を使用してエントリーを変更することができません。
2.2.1.3.1. Directory Server コンソールを使用したカスタムディストリビューション機能の接尾辞への追加
- Directory Server コンソールで、Configuration タブを選択します。
- 左側のナビゲーションペインで Data を展開します。ディストリビューション機能を適用する接尾辞を選択します。
- 右側のウィンドウで Databases タブを選択します。
- 接尾辞に関連付けられているデータベースは、Databases タブにすでにリストされています。 をクリックして、追加のデータベースを接尾辞に関連付けます。
- ディストリビューションライブラリーへのパスを入力します。
- 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
属性は、ディストリビューション機能自体の名前を提供します。
2.2.2. Directory データベースの維持
2.2.2.1. 読み取り専用モードでのデータベースの配置
2.2.2.1.1. コンソールを使用したデータベースの読み取り専用の設定
- Directory Server コンソールで、Configuration タブを選択します。
- 左側のペインで Data を展開します。データベースが含まれる接尾辞を展開して、読み取り専用モードにします。
- 読み取り専用モードに設定するデータベースを選択します。
- 右側のペインで、Database Settings タブを選択します。
- データベースが読み取り専用 チェックボックスにチェックマークを入れます。
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
2.2.2.1.3. 読み取り専用モードでの Directory Server の配置
- Directory Server コンソールの Configuration タブを選択し、左側のペインのナビゲーションツリーでトップエントリーを選択します。
- 右側のペインで Settings タブを選択します。
- Make Entire Server Read-Only チェックボックスを選択します。
2.2.2.2. データベースの削除
- Directory Server コンソールで、Configuration タブを選択します。
- Data フォルダーを展開し、接尾辞を選択します。
- 削除するデータベースを選択します。
- データベースを右クリックし、ポップアップメニューから Delete を選択します。
- Delete Database ダイアログボックスでデータベースを削除する必要があることを確認します。
2.2.2.3. トランザクションログディレクトリーの変更
- 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. データベースリンクの作成および維持
2.3.1. 新規データベースリンクの作成
- 接尾辞の情報。接尾辞は、通常のデータベースではなく、データベースリンクが管理するディレクトリーツリーに作成されます。この接尾辞は、データが含まれるリモートサーバーの接尾辞に対応します。
- バインド認証情報。データベースリンクがリモートサーバーにバインドされると、ユーザーのなりすましが行われ、リモートサーバーとバインドするために使用する各データベースリンクの DN および認証情報を指定します。
- LDAP URL。これは、データベースリンクが接続するリモートサーバーの LDAP URL を提供します。URL はプロトコル (ldap または ldaps)、サーバーのホスト名または IP アドレス (IPv4 または IPv6)、およびポートで構成されます。
- フェイルオーバーサーバーの一覧。これは、障害発生時にデータベースリンクが接続するための代替サーバーの一覧を提供します。この設定項目は任意です。
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 アドレス)とポート番号を入力します。フェイルオーバーサーバーの場合は、ホスト名とポート番号を入力し、ボタンをクリックします。フェイルオーバーサーバーはバックアップサーバーであるため、プライマリーリモートサーバーが失敗すると、データベースリンクはフェイルオーバーサーバー一覧の最初のサーバーに接続し、サーバーがアクセスされるまでリストを循環します。
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
2.3.1.2.1. 接尾辞情報の提供
nsslapd-suffix
属性を使用して、データベースリンクが管理する接尾辞を定義します。たとえば、データベースリンクが会社のリモートサイトの人情報を参照する場合は、以下の接尾辞情報を入力します。
nsslapd-suffix: l=Zanzibar,ou=people,dc=example,dc=com
nsslapd-nsslapd-suffix
属性の変更は、データベースリンクを含むサーバーが再起動しないと適用されません。
2.3.1.2.2. バインド認証情報の提供
- リモートサーバーで以下を行います。
- データベースリンクの管理ユーザーを作成します。エントリーの追加に関する詳細は、「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
属性に、データベースリンクのユーザーパスワードを提供します。
nsMultiplexorBindDN
属性で定義されている特別なユーザーと nsMultiplexorCredentials
属性で定義されているユーザーパスワードを使用してサーバー B にバインドされます。この例では、サーバー A は以下のバインド認証情報を使用します。
nsMultiplexorBindDN: cn=proxy admin,cn=config nsMultiplexorCredentials: secret
nsMultiplexorBindDN
に対応するユーザーエントリーが含まれ、このユーザーのプロキシー認証権限を設定する必要があります。プロキシー承認を正しく設定するには、プロキシー ACI をその他の ACI として設定します。
creatorsName
属性および modifiersName
属性にはエントリーの実際の作成者または修正者が反映されません。これらの属性には、リモートデータサーバーでプロキシー認証権限が付与されている管理ユーザーの名前が含まれています。
2.3.1.2.3. LDAP URL の提供
nsFarmServerURL
属性を使用したリモートサーバーの URL は、設定ファイルの cn=database_link, cn=chaining database,cn=plugins,cn=config エントリーに設定されます。
nsFarmServerURL: ldap://example.com:389/
nsFarmServerURL: ldaps://africa.example.com:636/
2.3.1.2.4. フェイルオーバーサーバーの一覧の提供
nsFarmServerURL
属性に代替サーバーを追加し、空白で区切って追加します。
nsFarmServerURL: ldap://example.com us.example.com:389 africa.example.com:1000/
2.3.1.2.5. 異なるバインドメカニズムの使用
- 標準の LDAP ポートを使用する場合
- 専用の LDAPS ポートを使用する場合
- Start TLS(標準ポートでのセキュアな接続)の使用
nsUseStartTLS
属性で識別されます。これを有効にすると、サーバーは標準ポート で Start TLS 接続を開始します。これが オフ の場合、サーバーは nsFarmServerURL
属性のリモートサーバーに設定されたものに応じて LDAP ポートまたは LDAPS ポートを使用します。
nsUseStartTLS: on
nsUseStartTLS: off
- empty.バインドメカニズムが設定されていない場合、サーバーは簡易認証を実行し、バインド情報を付与する
nsMultiplexorBindDN
属性およびnsMultiplexorCredentials
属性を必要とします。 - EXTERNAL。これは TLS 証明書を使用して、ファームサーバーをリモートサーバーに認証します。ファームサーバーをセキュアな URL (ldaps) に設定するか、
nsUseStartTLS
属性を on に設定する必要があります。 - DIGEST-MD5。これは、DIGEST-MD5 暗号化での SASL 認証を使用します。単純な認証と同様に、バインド情報を付与するには
nsMultiplexorBindDN
属性およびnsMultiplexorCredentials
属性が必要です。 - GSSAPI.SASL 上で Kerberos ベースの認証を使用します。ファームサーバーは Kerberos キータブで設定する必要があるため、リモートサーバーには、そのファームサーバーのバインド ID に対して定義された SASL マッピングが必要です。Kerberos キータブおよび SASL マッピングの設定は、「SASL Identity マッピングの設定」に記載されています。
nsBindMechanism: EXTERNAL
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. データベースリンクの設定属性の概要
属性 | 値 |
---|---|
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 エントリーにあります。グローバル属性は動的であるため、その属性への変更はディレクトリー内のデータベースリンクのすべてのインスタンスに対して自動的に有効になります。
|
2.3.1.2.7. データベースリンクの設定例
- 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. シャーシポリシーの設定
2.3.2.1. コンポーネントの動作の連鎖
- 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 プラグイン
- パスワードポリシーコンポーネント
- レプリケーションプラグイン
- 参照整合性プラグイン
2.3.2.1.1. コンソールを使用したコンポーネントの操作の連鎖
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 制御チェーン
- 仮想リストビュー (VLV)。この制御は、すべてのエントリー情報を返すのではなく、エントリーの一部のリストを提供します。
- サーバー側のソート。この制御では、通常は特定のマッチングルールを使用して、エントリーを属性値に従ってソートます。
- 逆参照。この制御は、検索内のエントリー属性の参照を上書きし、参照されるエントリーから指定された属性情報をプルし、残りの検索結果とともに返します。
- 管理 DSA。この制御は、参照に従うのではなく、スマート参照をエントリーとして返します。そのため、スマートの参照自体は変更または削除できます。
- ループ検出。この制御では、別のサーバーとのサーバー連鎖の回数を追跡します。数が設定された数に達すると、ループが検出され、クライアントアプリケーションに通知が送信されます。この制御の使用方法は、「ループの検出」を参照してください。
2.3.2.2.1. コンソールを使用した LDAP 制御の連鎖
- Directory Server コンソールで、Configuration タブを選択します。
- 左側のペインで Data フォルダーを展開し、Database Link Settings をクリックします。
- 右側のウィンドウで Settings タブを選択します。
- データベースリンクセクションによって転送される LDAP Controls の ボタンをクリックして、LDAP コントロールを一覧に追加します。
- リストに追加するコントロールの OID を選択し、をクリックします。
2.3.2.2.2. コマンドラインでの LDAP 制御の連鎖
nsTransmittedControls
属性を変更して、データベースリンクが転送するコントロールを変更します。たとえば、仮想リストビュー制御を転送するには、以下を設定ファイルのデータベースリンクエントリーに追加します。
nsTransmittedControls: 2.16.840.1.113730.3.4.9
nsTransmittedControls
属性にカスタム制御の 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. データベースリンクの削除
- Directory Server コンソールで、Configuration タブを選択します。
- 左側のナビゲーションペインで Data の下で接尾辞を開き、削除するデータベースリンクを選択します。
- データベースリンクを右クリックし、メニューから Delete を選択します。
2.3.6. データベースリンクおよびアクセス制御評価
- すべての種類のアクセス制御を使用できるわけではありません。たとえば、ロールベースまたはフィルターベースの ACI はユーザーエントリーへのアクセスを必要とします。データベースリンクを介してデータにアクセスするため、プロキシーコントロールのデータのみが検証できます。ユーザーエントリーがユーザーのデータと同じデータベースに配置されるように、ディレクトリーを設計することを検討してください。
- クライアントの IP アドレスまたは DNS ドメインに基づくすべてのアクセス制御は、チェーン中にクライアントの元のドメインが失われるためです。リモートサーバーは、クライアントアプリケーションをデータベースリンクと同じ IP アドレスと、同じ DNS ドメインにある表示します。注記Directory Server は、IPv4 と IPv6 の IP アドレスの両方に対応します。
- ACI は、使用する任意のグループと共に配置する必要があります。グループが動的である場合は、グループ内のすべてのユーザーが ACI およびグループで配置される必要があります。グループが静的である場合は、リモートユーザーにリンクされます。
- ACI は、使用するロール定義とそれらのロールを持つユーザーに対して配置する必要があります。
- ユーザーのエントリーの値 (例: userattr サブジェクトルール) にリンクする ACI は、ユーザーがリモートの場合に機能します。
- アクセス制御の評価時に、ユーザーエントリーの内容は必ずしも利用できるとは限りません (たとえば、データベースリンクを含むサーバーでアクセス制御が評価され、エントリがリモートサーバーにある場合)。パフォーマンス上の理由から、クライアントはリモート問い合わせを実行してアクセス制御を評価することはできません。
- データベースリンクは、クライアントアプリケーションによって変更されるエントリーに必ずしもアクセスできるとは限りません。変更操作を実行する場合、データベースリンクはリモートサーバーに保存されている全エントリーにアクセスできません。削除操作を実行すると、データベースリンクはエントリーの DN のみを認識します。アクセス制御が特定の属性を指定する場合、データベースリンクを介して実行すると削除操作は失敗します。
nsCheckLocalACI
属性を使用します。ただし、データベースリンクを含むサーバーでアクセス制御を評価することは、カスケード連鎖を使用する場合を除いて推奨されません。
2.4. カスケード連鎖の設定
2.4.1. カスケード連鎖の概要
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 はこのセキュリティー違反を防ぎます。
- 中間データベースリンクが含まれるサーバーにデータベースがない場合は、データベースを作成します。このデータベースには、admin ユーザーエントリーおよび ACI が含まれます。データベースの作成に関する詳細は、「データベースの作成」 を参照してください。
- データベースの管理ユーザーに対応するエントリーを作成します。
- 適切な接尾辞をターゲットとする管理ユーザーの 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. ループの検出
nsHopLimit
属性を使用して定義されます。指定されていない場合、デフォルト値は 10 になります。
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. カスケード連鎖設定の例
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
属性で指定された接尾辞上の接尾辞と関連付ける必要があります。つまり、最終的な宛先サーバーの接尾辞は、中間サーバーで指定された接尾辞のサブ接尾辞になります。- ローカルプロキシー認証 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";)
- 次に、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";)
2.5. 参照の使用
2.5.1. リファーラルモードでのサーバーの起動
# 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. デフォルト参照の設定
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 ユーティリティーを実行し、デフォルトの参照を 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/
2.5.3. スマートリファーラルの作成
2.5.3.1. Directory Server コンソールを使用したスマートリファーラルの作成
- Directory Server コンソールで、Directory タブを選択します。
- 左側のナビゲーションペインでツリーを参照して、参照を追加するエントリーを選択します。
- エントリーを右クリックし、Set Smart Referrals を選択します。
- Enable Smart Referral チェックボックスを選択します。(オプションにチェックを入れると、エントリーからすべてのスマート参照を削除し、エントリーから 参照 オブジェクトクラスを削除します。)
- Enter a new Smart Referral フィールドに、LDAP URL 形式でリファーラルを入力し、 をクリックします。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. コマンドラインからのスマートリファーラルの作成
ref
を許可します。ref
属性には LDAP URL が含まれている必要があります。
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
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
-M
オプションを使用します。スマートリファーラルの詳細は、『 『Red Hat Directory Server デプロイメントガイド』を参照してください』。
2.5.4. バグ修正参照の作成
2.5.4.1. コンソールを使用した接尾辞リファーラルの作成
- 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 を作成します。
- 複数の参照を入力できます。ディレクトリーは、クライアントアプリケーションからのリクエストに対応して参照のリスト全体を返します。
2.5.4.2. コマンドラインからの接尾辞リファーラルの作成
# 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
属性は、更新時に参照に 設定することもできます。つまり、更新リクエスト以外のすべての操作にデータベースが使用されます。クライアントアプリケーションが更新時に 参照セットに設定された接尾辞の更新リクエストを行うと、 クライアントは参照を受け取ります。
第3章 ディレクトリーエントリーの管理
3.1. コマンドラインでエントリーの管理
- 新規エントリーの追加
- 既存のエントリーへの新規属性の追加
- 既存のエントリーおよび属性の更新
- エントリーからエントリーおよび属性を削除します
- 一括操作の実行
# yum install openldap-clients
3.1.1. ldapadd、ldapmodify、および ldapdelete ユーティリティーへの入力の提供
3.1.1.1. インタラクティブモードでの入力の提供
- ファイルを作成せずに 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 ファイルを使用した入力の提供
例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. 継続的操作モード
-c
オプションを ldapadd および ldapmodify に渡します。以下に例を示します。
# ldpamodify -c -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
3.1.3. エントリーの追加
/bin/ldapmodify
へのシンボリックリンクであることに注意してください。そのため、ldapadd は ldapmodify -a と同じ操作を実行します。
3.1.3.1. ldapadd を使用したエントリーの追加
# 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
3.1.3.2. ldapmodify を使用したエントリーの追加
# 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 を指定する必要はありません。
3.1.3.3. ルートエントリーの作成
cn=Directory Manager
ユーザーとしてバインドし、エントリーを追加します。
# 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
-n back_end
オプションを指定して ldif2db ユーティリティーを使用し、新しいエントリーを保持するデータベースを設定する必要があります。詳細は、「コマンドラインからのインポート」 を参照してください。
3.1.4. ディレクトリーエントリーの更新
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
3.1.4.1. エントリーへの属性の追加
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
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. 属性の値の更新
単値属性の更新
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
多値属性の特定値の更新
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. エントリーからの属性の削除
属性の削除
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
多値属性から特定の値の削除
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. エントリーの削除
3.1.5.1. ldapdelete を使用したエントリーの削除
# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "uid=user,ou=People,dc=example,dc=com"
# 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"
3.1.5.2. ldapmodify を使用したエントリーの削除
# 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 -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
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. エントリーまたはサブツリーの名前変更
newrdn
属性に新しい RDN を設定します。
# 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. エントリーを新しい親へ移動
newrdn
- 移動したエントリーの RDN を設定します。RDN が同じままであっても、このエントリーを設定する必要があります。
newSuperior
- 新しい親エントリーの DN を設定します。
# 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
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 ユーティリティーを使用できます。
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 -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. ディレクトリーコンソールを使用したエントリーの管理
3.2.1. ルートエントリーの作成
- 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 ウィンドウでをクリックします。
3.2.2. ディレクトリーエントリーの作成
Template | オブジェクトクラス |
---|---|
ユーザー | inetOrgPerson |
グループ | groupOfUniqueNames |
組織単位 | organizationalUnit |
ロール | nsRoleDefinition |
サービスのクラス | cosSuperDefinition |
- Directory Server コンソールで、Directory タブを選択します。
- 左側のペインで、メインエントリーを右クリックして新しいエントリーを追加し、エントリーのタイプ( User、Group、OrganizationalUnit、Role、Class of Service、または Other )を選択します。
- 新しいエントリータイプが Other の場合、オブジェクトクラスの一覧が開きます。一覧からオブジェクトクラスを選択して新規エントリーを定義します。
- 一覧表示されているすべての属性の値を指定します。必要な属性にはアスタリスク(*)が付いています。
- オブジェクトクラス(エントリータイプ)で利用可能な属性の詳細一覧を表示するには、Advanced ボタンをクリックします。Property Editor で追加の属性を選択し、属性値を入力します。
3.2.3. ディレクトリーエントリーの変更
- Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced Properties を選択します。
- Directory タブから、エントリーをダブルクリックして、詳細 ボタンをクリックします。
- Create... new entry フォームから Advanced ボタンをクリックします。
- ウィンドウからをクリックして、新規オブジェクト
3.2.3.1. オブジェクトクラスのエントリーへの追加または削除
- Directory Server コンソールの Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced を選択します。
- オブジェクトクラスフィールドを選択し、Add Value をクリックします。Add Object Class ウィンドウが開きます。これは、エントリーに追加できるオブジェクトクラスの一覧を表示します。
- 追加するオブジェクトクラスを選択し、をクリックします。
3.2.3.2. エントリーへの属性の追加
- Directory Server コンソールの Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced を選択します。
- Add Attribute をクリックします。
- 一覧から追加する属性を選択し、をクリックします。注記追加する属性が一覧にない場合は、最初に属性が含まれるオブジェクトクラスを追加し、続いて属性を追加します。オブジェクトクラスの追加方法は、「オブジェクトクラスのエントリーへの追加または削除」 を参照してください。必要な属性を含むオブジェクトクラスが見つからない場合は、『Red Hat Directory Server 10 Configuration, Command, and File Reference』 (この属性を使用するオブジェクトクラスの一覧)の属性を検索します。
- 属性名の右側にあるフィールドの新しい属性の値を入力します。
3.2.3.3. 大きな属性の追加
nsslapd-maxbersize
は LDAP 要求の最大サイズ制限を設定します。Directory Server のデフォルト設定では、この属性を 2 メガバイトに設定します。要求で 2 メガバイトより大きい非常に大きな属性を追加しようとすると、LDAP の追加または修正操作は失敗します。ただし、この制限はレプリケーションプロセスには適用されません。
nsslapd-maxbersize
設定属性の設定を、実行する最大の LDAP 要求よりも大きい値に変更します。
- リクエストの各属性名のサイズ
- リクエストの各属性の値のサイズ
- 要求内の DN のサイズ
- オーバーヘッド(通常は 10 キロバイト)
nsslapd-maxbersize
設定を増やす必要がある一般的な問題の 1 つは、CRL 値( certificateRevocationList
、authorityRevocationList
、および deltaRevocationList
など)を保持する属性を使用することです。
nsslapd-maxbersize
属性の詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス の該当するセクションを参照してください』。
3.2.3.4. 属性値の追加
- Directory Server コンソールの Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced を選択します。
- 値を追加する属性を選択し、値 の追加 をクリックします。
- 新しい属性値を入力します。
3.2.3.5. 属性サブタイプの追加
言語サブタイプ
ユーザーの名前は、デフォルト言語以外の言語の文字でより正確に表現できる場合があります。たとえば、ユーザーである Noriko は日本語の名前を持ち、可能な限り日本語の文字で表現します。指定のname 属性の 言語サブタイプとして日本語を選択して、他のユーザーが日本語と英語で名前を検索できるようにします。以下に例を示します。
givenname;lang-ja
attribute;lang-subtype:attribute value
cn;lang-ja;lang-en-GB
:value
cn;lang-ja
:ja-value cn;lang-en-GB
:value
Pronunciation サブタイプ
属性に pronunciation サブタイプを割り当てると、属性値が電話番号であることを示します。サブタイプは、属性名に attribute;phonetic として追加されます。このサブタイプは、一般的に、複数のアルファベットを持つ言語サブタイプと組み合わせて使用されます。1 つは電話番号です。
3.2.4. ディレクトリーエントリーの削除
- Directory Server コンソールで、Directory タブを選択します。
- エントリーを右クリックして削除するメニューから Delete を選択します。
第4章 ディレクトリーエントリーの変更の追跡
- 変更シーケンス番号を使用してデータベースへの変更を追跡します。これは、レプリケーションおよび同期で使用されるシーケンス番号の変更に類似しています。通常のディレクトリー操作はすべて、シーケンス番号がトリガーされます。
- 作成および変更の情報を割り当てます。これらの属性は、エントリーを作成して直近に変更したユーザーの名前と、エントリーの作成および修正時のタイムスタンプを記録します。
4.1. 更新シーケンス番号でデータベースへの変更の追跡
4.1.1. エントリーシーケンス番号の概要
4.1.1.1. ローカルおよびグローバルの 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 カウンターを持つ USN プラグインのインスタンスがあります。これはデフォルト設定です。
- グローバルモードでは、ディレクトリー全体に追加された変更に適用されるグローバル USN カウンターを使用する USN プラグインのグローバルインスタンスがあります。
lastusn
属性のデータベースのエントリーに割り当てられた最新の USN を表示します。USN プラグインがローカルモードに設定されているので、各データベースに独自のローカル USN カウンターがある場合、lastUSN
は、USN が割り当てられているデータベースと、USN の両方を表示します。
lastusn;database_name:USN
lastusn;example1: 2130 lastusn;example2: 2070
lastUSN
属性は最新の USN のみを表示します。
lastusn: 4200
4.1.1.2. USN エントリーのインポート
nsslapd-entryusn-import-initval
属性を使用して、エントリーに USN が割り当てられているかどうかを確認します。nsslapd-entryusn-import-initval
の値が数値である場合、インポートされたエントリーはこの数字をエントリーの USN として使用します。nsslapd-entryusn-import-initval
の値が数値でない場合、USN プラグインは lastUSN
属性の値を使用して、インポートしたエントリーの USN で増やします。
4.1.2. USN プラグインの設定
# 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 の有効化
- 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 エントリーのクリーンアップ
# /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 オプション
の接尾辞が使用されます。
オプション | 詳細 |
---|---|
-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. 操作属性によるエントリー変更の追跡
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. コマンドラインを使用した変更の追跡を有効にする方法
nsslapd-lastmod
を on に設定します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config nsslapd-lastmod: on
- 必要に応じて、不足している
nsUniqueID
属性を再生成するには、以下を実行します。- データベースを LDAP データ交換形式(LDIF)ファイルにエクスポートします。「コマンドラインを使用した LDIF へのデータベースのエクスポート」 を参照してください。
- LDIF ファイルからデータベースをインポートします。「コマンドラインからのインポート」 を参照してください。
4.2.3. コンソールを使用した変更の追跡を有効にする方法
- Directory Server コンソールを開きます。「Directory Server コンソールを開く」 を参照してください。
- Configuration タブでサーバー名を選択します。
- Settings タブで Track Entry Modification Times チェックボックスを選択します。
- 必要に応じて、不足している
nsUniqueID
属性を再生成するには、以下を実行します。- データベースを LDAP データ交換形式(LDIF)ファイルにエクスポートします。「コマンドラインを使用した LDIF へのデータベースのエクスポート」 を参照してください。
- LDIF ファイルからデータベースをインポートします。「コマンドラインからのインポート」 を参照してください。
4.3. プラグイン開始更新のバインド DN の追跡
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章 参照整合性の維持
5.1. 参照整合性の仕組み
- エントリーの場合は、ログファイルで削除済みと表示され、ディレクトリーの対応する属性が削除されます。
- エントリーの場合は、ログファイルで更新済みと表示され、ディレクトリーの対応する属性が更新されます。
- エントリーの場合は、ログファイルで名前が変更または移動済みと表示され、ディレクトリーの対応する属性の名前が変わります。
member
、uniquemember
、owner
、および seeAlso
属性で整合性の更新を実行します。ただし、Referential Integrity Postoperation プラグインの動作は、ディレクトリーのニーズに応じて複数の方法で設定できます。
- レプリケーション変更ログに整合性の更新を記録します。
- 更新間隔を変更します。
- 参照整合性を適用する属性を選択します。
- 参照整合性を無効にします。
nsIndexType: pres nsIndexType: eq nsIndexType: subインデックスの確認および作成に関する詳細は、「標準インデックスの作成」を参照してください。
5.2. レプリケーションによる参照整合性の使用
- 専用のコンシューマーサーバー (読み取り専用レプリカのみが含まれるサーバー) では有効に しないでください。
- 読み書きレプリカと読み取り専用レプリカの組み合わせが含まれるサーバーで有効に しないでください。
- 読み書きレプリカのみが含まれるサプライヤーサーバーで有効にできます。
- マルチマスターレプリケーションでは、1 つのサプライヤーでプラグインを有効にします。
- 「参照整合性の有効化および無効化」 の説明に従って、Referential Integrity Postoperation プラグインを有効にします。
- 変更ログに整合性の更新を記録するようにプラグインを設定します。
- すべてのコンシューマーサーバーで、Referential Integrity Postoperation プラグインが無効になっていることを確認します。注記サプライヤーサーバーが Referential Integrity Postoperation 整合性プラグインの変更をコンシューマーサーバーに送信するため、コンシューマーサーバーで Referential Integrity Postoperation プラグインを実行する必要はありません。
5.3. 参照整合性の有効化および無効化
5.3.1. コマンドラインから参照整合性の有効化および無効化
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. コンソールでの参照整合性の有効化および無効化
5.4. 更新間隔の変更
- 0: 参照整合性の確認は即座に実行されます。
- -1: 参照整合性の確認は実行されません。
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
5.4.2. コンソールを使用した更新間隔の変更
- Referential Integrity Postoperation プラグインの設定で Property Editor を開きます。詳細は、「コンソールを使用したプラグインの設定」 を参照してください。
referint-update-delay
パラメーターで間隔を秒単位で設定します。- Directory Server インスタンスを再起動します。「コンソールを使用した Directory Server インスタンスの起動および停止」 を参照してください。
5.5. 属性一覧の変更
member
属性、uniquemember
属性、owner
属性、および seeAlso
属性を確認し、更新します。コマンドラインまたはコンソールを使用して、更新する属性を追加または削除できます。
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
のエントリーは、参照整合性の確保のために処理しないでください。
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 への入力
6.1. データのインポート
動作 | インポート | データベースの初期化 |
---|---|---|
データベースの上書き | いいえ | はい |
LDAP 操作 | 追加、変更、削除 | 追加のみ |
パフォーマンス | より時間がかかる | 速い |
パーティション特長 | すべてのパーティションで機能 | ローカルパーティションのみ |
サーバー障害への応答 | ベストエフォート (障害が発生した時点までに行われたすべての変更が残る) | アトミック (障害発生後にすべての変更が失われる) |
LDIF ファイルの場所 | コンソールへのローカル | サーバーに対するコンソールまたはローカルへのローカル |
設定情報 (cn=config) をインポートする | Yes | いいえ |
6.1.1. インポート中の EntryUSN 初期値の設定
nsslapd-entryusn-import-initval
属性を設定して行います。これにより、インポートされたすべてのエントリーの USN が開始されます。
nsslapd-entryusn-import-initval
には 2 つの値を指定することができます。
- 整数。インポートされたすべてのエントリーに使用される明示的な開始番号です。
- 次に、インポートされたすべてのエントリーは、インポート操作前にサーバー上の最も大きなエントリー USN 値を使用し、1 つずつ増分します。
nsslapd-entryusn-import-initval
が設定されていない場合、すべてのエントリー USN はゼロで始まります。
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 ...
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
属性はサーバー間で 複製されません。つまり、値は、レプリカの初期化に使用しているすべてのサプライヤーサーバーに対して設定する必要があります。
nsslapd-entryusn-import-initval
が next に設定され、レプリカの初期化に使用される場合は、インポートされたエントリーのエントリー USN は最も高い値に 1 が追加されます。Supplier2 に nsslapd-entryusn-import-initval
が設定されておらず、レプリカの初期化に使用される場合は、Supplier1 および Supplier 2 にマルチマスターレプリカ合意がある場合でも、インポートされたエントリーのすべてのエントリー USN はゼロで始まります。
6.1.2. コンソールからのデータベースのインポート
- Tasks タブを選択します。画面の下部までスクロールし、Import Database を選択します。または、Configuration タブを開き、Console メニューから Import を選択します。
- Import Database ダイアログボックスで、LDIF ファイル フィールドでインポートする LDIF ファイルへの完全パスを入力するか、 をクリックしてインポートするファイルを選択します。コンソールがマシンのリモートで実行している場合、フィールド名は LDIF ファイルとして表示されます(コンソールを実行するマシン上)。ファイルを参照する場合、Directory Server ホストの現在のディレクトリーは参照されませんが、コンソールを実行しているマシンのファイルシステムも参照しません。リモートコンソールを使用してデータベースをインポートする場合 は、データベースへの相対パスを使用しないでください。リモートインポートでは、ファイルに相対パス が指定されている場合に Cannot write to file... というエラーで操作に失敗します。リモートインポート操作には常に絶対パスを使用します。
- オプション ボックスで、以下のオプションのいずれかまたは両方を選択します。
- のみを追加します。LDIF ファイルには、デフォルトの追加手順に加えて、変更および削除手順を含めることができます。サーバーが add 以外の操作を無視するには、Add only チェックボックスを選択します。
- Error に進みます。エラーが発生した場合でもインポートを続行するには、サーバーの Continue on error チェックボックスを選択します。たとえば、このオプションを使用して、新しいものに加えて、データベースにすでに存在するエントリーが含まれる LDIF ファイルをインポートします。サーバーノートでは、すべての新規エントリーの追加中に rejects ファイルの既存のエントリーがあります。
- File for Rejects フィールドに、サーバーがインポートできないすべてのエントリーを記録するファイルへの完全パスを入力するか、 をクリックして拒否が含まれるファイルを選択します。拒否は、データベースにインポートできないエントリーです。たとえば、サーバーは、データベースにすでに存在するエントリーや、親オブジェクトのないエントリーをインポートできません。コンソールは、サーバーによって送信されたエラーメッセージが rejects ファイルに書き込みます。このフィールドを空白のままにすると、サーバーは拒否されたエントリーを記録しません。
6.1.3. コンソールからのデータベースの初期化
- Configuration タブを選択します。
- 左側のナビゲーションペインで Data tree を展開します。初期化するデータベースの接尾辞を展開し、データベース自体をクリックします。
- データベースを右クリックし、Initialize Database を選択します。または、Object メニューから Initialize Database を選択します。
- LDIF file フィールドにインポートする LDIF ファイルへの完全パスを入力するか、 をクリックします。
- コンソールが、インポートされているファイルのマシンから実行中の場合は、をクリックして、即座にインポートに進みます。Console がマシンリモートから LDIF ファイルを含むサーバーに実行している場合は、以下のオプションのいずれかを選択して をクリックします。
- ローカルマシンからいる。LDIF ファイルがローカルマシンにあることを示します。
- サーバーマシン から。LDIF ファイルがリモートサーバーにあることを示します。
デフォルトの LDIF ディレクトリーは/var/lib/dirsrv/slapd-instance/ldif
です。
6.1.4. コマンドラインからのインポート
- ldif2db の使用。このインポートメソッドはデータベースの内容を上書きし、サーバーを停止する必要があります。「ldif2db コマンドラインユーティリティーを使用したインポート」 を参照してください。
- Using ldif2db.pl.このインポート方法は、サーバーの実行中にデータベースの内容を上書きします。「ldif2db.pl Perl スクリプトを使用したインポート」 を参照してください。
- ldif2ldap の使用。このメソッドは、LDAP を介して LDIF ファイルを追加します。このメソッドは、全データベースにデータを追加する場合に便利です。「ldif2ldap コマンドラインスクリプトを使用したインポート」 を参照してください。
- cn=tasks エントリーの作成。このメソッドは、インポート操作を自動的に起動する一時タスクエントリーを作成します。これは、ldif2db の実行に似ています。「cn=tasks エントリーを使用したインポート」 を参照してください。
6.1.4.1. ldif2db コマンドラインユーティリティーを使用したインポート
- サーバーを停止します。
# 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.pl -Z instance_name -D "cn=Directory Manager" -w secret -i /var/lib/dirsrv/slapd-instance/ldif/demo.ldif -n Database1
ldif2db.pl
スクリプトの説明を参照してください』。
6.1.4.3. ldif2ldap コマンドラインスクリプトを使用したインポート
[root@server ~]# ldif2ldap -Z instance_name -D "cn=Directory Manager" -w secretpwd /var/lib/dirsrv/slapd-instance/ldif/demo.ldif
ldif2ldap
スクリプトの説明を参照してください』。
6.1.4.4. cn=tasks エントリーを使用したインポート
- 一意の名前(
cn
) - インポートする LDIF ファイルのファイル名(
nsFilename
) - ファイルをインポートするデータベースの名前(
nsInstance
)
s
オプションおよび -x
オプションと同様に、インポートを包含または除外する接尾辞の DN を指定することもできます。
# 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
6.2. データのエクスポート
- データベースのデータのバックアップを作成します。
- 別の Directory Server にデータをコピーします。
- 別のアプリケーションへのデータのエクスポート。
- ディレクトリートポロジーの変更後にデータベースを再作成します。
図6.1 データベースコンテンツの 2 つのデータベースへの分割
6.2.1. コンソールを使用したディレクトリーデータの LDIF へのエクスポート
- Tasks タブを選択します。画面の下部までスクロールし、Export Database(s) をクリックします。または、Configuration タブを選択して、Console メニューから Export をクリックします。
- LDIF File フィールドに LDIF ファイルの完全パスおよびファイル名を入力するか、 をクリックしてファイルを見つけます。コンソールがリモートサーバーで実行している場合、は有効になりません。 ボタンが有効になっていないと、ファイルはデフォルトのディレクトリー
/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 テキストボックスに接尾辞の名前を入力します。このオプションは、複数のデータベースに含まれるサブツリーをエクスポートします。または、をクリックして接尾辞またはサブツリーを選択します。
6.2.2. コンソールを使用した単一データベースの LDIF へのエクスポート
- Configuration タブを選択します。
- 左側のナビゲーションペインで Data tree を展開します。接尾辞を展開し、接尾辞の下にあるデータベースを選択します。
- データベースを右クリックし、Export Database を選択します。または、Object メニューから Export Database を選択します。
- LDIF file フィールドで、LDIF ファイルへの完全パスを入力するか、 をクリックします。
/var/lib/dirsrv/slapd-instance/ldif
に保存されます。
6.2.3. コマンドラインを使用した LDIF へのデータベースのエクスポート
6.2.3.1. Directory Server の実行中にデータベースのエクスポート
6.2.3.1.1. db2ldif.pl スクリプトを使用した データベースのエクスポート
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 ユーザーには、宛先ディレクトリーに書き込みパーミッションが必要になることに注意してください。
6.2.3.1.2. エクスポートタスクの手動作成
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
6.2.3.2. Directory Server が Stopped 中にデータベースのエクスポート
userRoot データベースをエクスポート
するには、以下を実行します。
# db2ldif -Z instance_name -n userRoot
/var/lib/dirsrv/slapd-instance_name/ldif/
ディレクトリーに保存します。作成されたファイルには instance_name -database_or_suffix_name -time_ stamp.ldif という名前が付けられ
ます。または、- a file_name
オプションをスクリプトに渡して別の場所を設定することもできます。Directory Server ユーザーには、宛先ディレクトリーに書き込みパーミッションが必要になることに注意してください。
6.3. データのバックアップおよび復元
- それらのデータベース内に格納されているデータを含む、
userRoot
およびNetscapeRoot
などの全データベースファイル - トランザクションログ
- インデックス
6.3.1. すべてのデータベースのバックアップ
6.3.1.1. コンソールからのすべてのデータベースのバックアップ
- Tasks タブを選択します。
- Directory Server のバックアップ をクリックします。
- Directory テキストボックスにバックアップファイルを保存するディレクトリーの完全パスを入力するか、 をクリックすると、サーバーはバックアップディレクトリーの名前を指定します。コンソールがディレクトリーと同じマシンで実行されている場合は、をクリックしてローカルディレクトリーを選択します。デフォルトの場所で、バックアップファイルは
/var/lib/dirsrv/slapd-instance/bak
に配置されます。デフォルトでは、バックアップディレクトリー名にはサーバーインスタンスの名前が含まれ、バックアップが作成された日時(instance-YYYY_MM_DD_hhmmss)が含まれます。
6.3.1.2. コマンドラインでのすべてのデータベースのバックアップ
#
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)で名前が付けられます。
6.3.1.3. cn=tasks エントリーを使用したデータベースのバックアップ
- 一意の名前(
cn
) - バックアップファイルを書き込むディレクトリー(
nsArchiveDir
)。バックアップファイルには、Directory Server インスタンス名とバックアップの日付(serverID-YYYY_MM_DD_hhmmss)という名前が付けられます。 - データベースのタイプ(
nsDatabaseType
)。唯一のオプションは ldbm データベース です。
# 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
6.3.2. dse.ldif 設定ファイルのバックアップ
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. すべてのデータベースの復元
6.3.3.1. コンソールからのすべてのデータベースの復元
- 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. コマンドラインでのデータベースの復元
- bak2db コマンドラインスクリプトの使用このスクリプトでは、サーバーをシャットダウンする必要があります。
- Perl スクリプト bak2db.pl の使用。このスクリプトは、サーバーの実行中に機能します。
- cn=restore,cn=tasks,cn=config に一時的なエントリーを作成します。この方法は、サーバーの実行中に実行することもできます。
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 -Z instance_name -D "cn=Directory Manager" -w secret -a /var/lib/dirsrv/slapd-instance/bak/instance-2020_04_30_11_48_30
bak2db.pl
スクリプトの説明を参照してください』。
6.3.3.2.3. cn=tasks エントリーを使用したデータベースの復元
- 一意の名前(
cn
) - バックアップファイルを取得するディレクトリー(
nsArchiveDir
) - データベースのタイプ(
nsDatabaseType
)。唯一のオプションは ldbm データベース です。
# 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
6.3.4. 単一データベースの復元
- 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. 複製されたエントリーが含まれるデータベースの復元
- コンシューマーサーバーも復元します。非常にまれな状況では、すべてのデータベースで、(データが同期されるため)、コンシューマーはサプライヤーと同期したままとなり、他に何もする必要はありません。レプリケーションは中断せずに再開します。
- サプライヤーだけが復元します。サプライヤーのみが復元された場合や、コンシューマーが別のバックアップから復元された場合は、サプライヤーがコンシューマーを再初期化して、データベースのデータを更新します。サプライヤーのみが復元された場合や、コンシューマーが別のバックアップから復元された場合は、サプライヤーがコンシューマーを再初期化して、データベースのデータを更新します。
- サプライヤーサーバーでチェンジログエントリーの有効期限が切れていません。データベースのバックアップの取得後にサプライヤーの変更ログが期限切れになっていない場合は、ローカルコンシューマーを復元し、通常の操作を継続します。この状態は、cn=changelog5,cn=config エントリーで、最大 changelog age 属性
nsslapd-changelogmaxage
に設定された値よりも短い期間内にバックアップを取得した場合に限り発生します。このオプションの詳細は、『Red Hat Directory Server 設定、コマンド、およびファイルリファレンス』 を参照してください。Directory Server は、レプリカとその changelog 間の互換性を自動的に検出します。不一致が検出されると、サーバーは古い changelog ファイルを削除し、空のファイルを新たに作成します。 - changelog エントリーは、ローカルバックアップの時間以降、サプライヤーサーバーで期限切れです。changelog エントリーの有効期限が切れている場合は、コンシューマーを再初期化します。コンシューマーの再初期化に関する詳細は、「コンシューマーの初期化」 を参照してください。
例6.1 Directory Server のレプリケーショントポロジーの復元
- レプリケーションを使用して残りのサーバーをオンラインに初期化します。
- 最初のマスターから 2 番目のマスターを初期化します。
- マスターからコンシューマーを初期化します。
詳細は、「コンシューマーの初期化」 を参照してください。 - 各サーバーで
nsds5replicaLastUpdateStatus
属性を表示し、レプリケーションが正しく機能していることを確認します。# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "cn=example_agreement,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config" nsds5replicaLastUpdateStatus
可能なステータスの詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンス の付録 『レプリカ合意の状況』 を参照してください』。
6.3.6. dse.ldif 設定ファイルの復元
/etc/dirsrv/slapd-instance
ディレクトリーの dse.ldif
ファイルの 2 つのバックアップコピーを作成します。dse.ldif.startOK
ファイルは、サーバーの起動時に dse.ldif
ファイルのコピーを記録します。dse.ldif.bak
ファイルには、dse.ldif
ファイルへの最新の変更のバックアップが含まれます。最新の変更でバージョンを使用して、ディレクトリーを復元します。
dse.ldif
設定ファイルを復元するには、以下を実行します。
- サーバーを停止します。
# systemctl stop dirsrv@instance
- 「単一データベースの復元」 で説明されているようにデータベースを復元し、
dse.ldif
ファイルのバックアップコピーをそのディレクトリーにコピーします。 - サービスを再起動します。
# systemctl restart dirsrv@instance
第7章 属性および値の管理
7.1. 属性の一意性の有効化
7.1.1. Attribute Uniqueness プラグインの新規設定レコードの作成
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Example Attribute Uniqueness,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: Example Attribute Uniqueness nsslapd-pluginPath: libattr-unique-plugin nsslapd-pluginInitfunc: NSUniqueAttr_Init nsslapd-pluginType: betxnpreoperation nsslapd-pluginEnabled: off nsslapd-plugin-depends-on-type: database nsslapd-pluginId: NSUniqueAttr nsslapd-pluginVersion: none nsslapd-pluginVendor: 389 Project nsslapd-pluginDescription: Enforce unique attribute values uniqueness-attribute-name: uid
7.1.2. サフィックスまたはサブツリーにおける属性一意の設定
7.1.2.1. コマンドラインでサフィックスまたはサブツリーに対する属性一意の設定
- たとえば mail Attribute Uniqueness という名前の Attribute Uniqueness プラグインの新たな設定レコードを作成します。詳細は 「Attribute Uniqueness プラグインの新規設定レコードの作成」を参照してください。
- プラグイン設定レコードを有効にし、
mail
属性に保存される値が内部で一意である必要があります。たとえば、ou=Engineering,dc=example,dc=com および ou=Sales, dc=example,dc=com サブツリーなどです。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=mail Attribute Uniqueness,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on - add: uniqueness-attribute-name uniqueness-attribute-name: mail - add: uniqueness-subtrees uniqueness-subtrees: ou=Engineering,dc=example,dc=com uniqueness-subtrees: ou=Sales,dc=example,dc=com
- 必要に応じて、このプラグイン設定レコードに設定されたすべてのサブツリーで一意性を設定するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=mail Attribute Uniqueness,cn=plugins,cn=config changetype: modify add: uniqueness-across-all-subtrees uniqueness-across-all-subtrees: on
- インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
7.1.2.2. コンソールを使用したサフィックスまたはサブツリーに対する属性一意の設定
- Attribute Uniqueness プラグインの新しい設定レコードを作成します。「Attribute Uniqueness プラグインの新規設定レコードの作成」 を参照してください。
- プラグイン設定レコードの設定で Property Editor を開きます。詳細は、「コンソールを使用したプラグインの設定」 を参照してください。
- プラグインを有効にするには、以下を設定します。
nsslapd-pluginEnabled: on
- mail 属性を一意である必要があります。
uniqueness-attribute-name: mail
- 属性の値が一意である必要があるサブツリーを設定します。
uniqueness-subtrees: ou=Engineering,dc=example,dc=com uniqueness-subtrees: ou=Sales,dc=example,dc=com
uniqueness-subtrees
属性の値フィールドを選択し、値を追加 2 番目のuniqueness-subtrees
属性を追加します。 - 必要に応じて、このプラグイン設定レコードに設定されたすべてのサブツリーで一意性を設定するには、
uniqueness-across-all-subtrees
属性を追加し、これを以下に設定します。uniqueness-across-all-subtrees: on
- Property Editorを閉じます。をクリックして、
- Directory Server インスタンスを再起動します。「コンソールを使用した Directory Server インスタンスの起動および停止」 を参照してください。
7.1.3. オブジェクトクラスに対する属性の一意性の設定
uniqueness-attribute-name
に設定された属性の値がこのサブツリー内で一意であることを確認します。
- たとえば mail Attribute Uniqueness という名前の Attribute Uniqueness プラグインの新たな設定レコードを作成します。詳細は 「Attribute Uniqueness プラグインの新規設定レコードの作成」を参照してください。
- プラグイン設定レコードを有効にし、
mail
属性に保存される値は、nsContainer オブジェクトクラスが含まれるエントリーで一意である必要があります。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=mail Attribute Uniqueness,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on - add: uniqueness-top-entry-oc uniqueness-top-entry-oc: nsContainer
- 必要に応じて、チェックされるオブジェクトの範囲を制限できます。サーバーが nsContainer オブジェクトクラスを含むエントリーの下にあるエントリーのサブセットのみをチェックするようにするには、
uniqueness-subtree-entries-oc
パラメーターに追加のオブジェクトクラスを設定します。この追加クラスも存在している必要があります。たとえば、nsContainer オブジェクトクラスセットが含まれるエントリーにあるすべてのエントリーでmail
属性を一意にする必要があります。ただし、プラグインは、inetOrgPerson など、この属性を提供するオブジェクトクラスが含まれるエントリーでmail
のみを検索します。この場合は、以下を入力します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=mail Attribute Uniqueness,cn=plugins,cn=config add: uniqueness-subtree-entries-oc uniqueness-subtree-entries-oc: inetOrgPerson
- インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
7.1.4. 属性の一意性プラグイン設定パラメーター
nsslapd-plugarg*
属性(例7.2「nsslapd-pluginarg*
属性を使用した属性の一意性プラグイン設定」)を使用して、このプラグインを設定できます。
例7.1 プラグイン固有の属性を使用した属性の一意性プラグイン設定
dn: cn=Example Attribute Uniqueness,cn=plugins,cn=config nsslapd-pluginEnabled: on uniqueness-attribute-name: attribute_name uniqueness-top-entry-oc: objectclass1 uniqueness-subtree-entries-oc: objectclass2
例7.2 nsslapd-pluginarg*
属性を使用した属性の一意性プラグイン設定
dn: cn=Example Attribute Uniqueness,cn=plugins,cn=config nsslapd-pluginEnabled: on nsslapd-pluginarg0: attribute=mail nsslapd-pluginarg1: markerObjectClass=objectclass1 nsslapd-pluginarg2: requiredObjectClass=objectclass2
パラメーター | 新規または古い構文 | 定義 |
---|---|---|
cn | both | Attribute Uniqueness プラグインの設定レコードの名前を設定します。どの文字列も使用できますが、Red Hat では設定レコードの attribute_name Attribute Uniqueness という名前を付けることを推奨します。 |
nsslapd-pluginEnabled | both | プラグイン設定レコードを有効(オン)または無効(無効)します。 |
uniqueness-attribute-name | 新規 | 値が一意である必要がある属性の名前を設定します。この属性は多値です。 |
uniqueness-subtrees | 新規 | プラグインが属性の値の一意性をチェックする DN を設定します。この属性は多値です。 |
uniqueness-across-all-subtrees | 新規 | 有効な場合は(on)、プラグインは属性セット全体で属性が一意であることを確認します。属性を off に設定すると、一意性は更新されたエントリーのサブツリー内でのみ適用されます。 |
uniqueness-top-entry-oc | 新規 | Directory Server は、更新されたオブジェクトの親エントリーでこのオブジェクトクラスを検索します。これが見つからない場合、検索はディレクトリーツリーのルートまでの次のレベルエントリーで続行されます。オブジェクトクラスが見つかった場合、Directory Server は、uniqueness-attribute-name に設定された属性の値がこのサブツリー内で一意であることを確認します。 |
uniqueness-subtree-entries-oc | 新規 | 任意で、uniqueness-top-entry-oc パラメーターを使用する場合は、エントリーにこのパラメーターに設定されたオブジェクトクラスが含まれる場合に限り、Attribute Uniqueness プラグインが属性が一意であるかどうかを確認することができます。詳細は、「オブジェクトクラスに対する属性の一意性の設定」 を参照してください。 |
nsslapd-pluginarg0 | old |
この
nsslapd-pluginarg* パラメーターと同等のプラグイン固有の属性は uniqueness-attribute-name です。説明については、このパラメーターを参照してください。
属性を attribute =attribute_name に設定します。
|
nsslapd-pluginarg[1-9] | old |
この
nsslapd-pluginarg* パラメーターと同等のプラグイン固有の属性は uniqueness-top-entry-oc です。説明については、このパラメーターを参照してください。
属性を markerObjectClass=object_class に設定します。
|
nsslapd-pluginarg[1-9] | old |
同等のプラグイン固有の属性は
uniqueness-subtree-entries-oc です。説明については、このパラメーターを参照してください。
属性を requiredObjectClass=object_class に設定します。
|
7.2. サービスのクラスの割り当て
- CoS 定義エントリー。CoS 定義エントリーは、使用される CoS のタイプを識別します。ロール定義エントリーと同様に、LDAPsubentry オブジェクトクラスから継承されます。CoS 定義エントリーは、有効なブランチの下にあります。
- テンプレートエントリー。CoS テンプレートエントリーには、共有属性値の一覧が含まれます。テンプレートエントリー属性値への変更は、CoS の範囲内のすべてのエントリーに自動的に適用されます。1 つの CoS に、複数のテンプレートエントリーが関連付けられている場合があります。
7.2.1. CoS 定義エントリーの概要
- ポインター CoS。ポインター CoS は、テンプレート DN のみを使用してテンプレートエントリーを特定します。
- 間接的な CoS。間接 CoS は、ターゲットエントリーの属性の 1 つを使用してテンプレートエントリーを識別します。たとえば、間接的な CoS はターゲットエントリーの
manager
属性を指定する場合があります。次に、manager
属性の値を使用してテンプレートエントリーを特定します。ターゲットエントリーの属性は単値であり、DN が含まれる必要があります。 - Classic CoS。Classic CoS は、テンプレートエントリーのベース DN とターゲットエントリーの属性の 1 つの値を使用してテンプレートエントリーを特定します。
7.2.2. CoS テンプレートエントリーの概要
- テンプレートエントリーの DN のみ。このタイプのテンプレートは Pointer CoS 定義に関連付けられます。
- ターゲットエントリーの属性の 1 つの値。テンプレートエントリーに相対 DN を提供するために使用される属性は、
cosIndirectSpecifier
属性を使用して CoS 定義エントリーに指定されます。このタイプのテンプレートは、間接 CoS 定義に関連付けられます。 - CoS がテンプレートの 1 つのレベル検索を実行するサブツリーの DN と、ターゲットエントリの属性の1つの値の組み合わせ。このタイプのテンプレートは、Classic CoS 定義に関連付けられます。
7.2.3. Pointer CoS の仕組み
図7.1 Pointer CoS のサンプル
postalCode
属性がエントリー cn=wholiday,ou=people,dc=example,dc=com に対してクエリーされるたびに、Directory Server は、テンプレートエントリー cn=exampleUS,cn=data で使用可能な値を返します。
7.2.4. 間接的な CoS の仕組み
manager
属性を使用してテンプレートエントリーを識別する間接的な CoS を作成します。図7.2「間接的な CoS の例」に示されるように、3 つの CoS エントリーが表示されます。
図7.2 間接的な CoS の例
manager
属性) が含まれます。William のマネージャーは Carla Fuentes であるため、manager
属性にはテンプレートエントリーの DN へのポインター cn=Carla Fuentes,ou=people,dc=example,dc=com が含まれます。テンプレートエントリーは次に、318842 の departmentNumber
属性値を提供します。
7.2.5. Classic CoS の仕組み
図7.3 Classic CoS のサンプル
cosSpecifier
属性は、employeeType
属性を指定しています。この属性は、テンプレート DN と組み合わせて、テンプレートエントリーを cn=sales,cn=exampleUS,cn=data として特定します。その後、テンプレートエントリーは、postalCode
属性値をターゲットエントリーに提供します。
7.2.6. 物理属性値の処理
cosAttribute
属性には、サービスのクラスによって管理される別の属性の名前が含まれます。この属性は、属性値の後に override 修飾子を許可します。属性値の生成時に、CoS がエントリーの既存の属性値を処理する方法を設定します。
cosAttribute: attribute_name override
- default: エントリーに対応する属性値が格納されてない場合のみ、生成された値を返します。
- override: エントリーに値が保存されている場合でも、常に CoS によって生成された値を返します。
- operational: 生成された属性が検索で明示的に要求されている場合にのみ、生成された属性を返します。操作属性は、返されるためにスキーマチェックに合格する必要はありません。operational を使用すると、既存の属性値も上書きされます。注記属性は、スキーマで操作可能として定義されている場合にのみ操作可能にすることができます。たとえば、CoS が
description
属性の値を生成する場合、この属性はスキーマで稼働していないため、operational 修飾子を使用することはできません。 - operational-default: エントリーに対応する属性値が格納されておらず、検索で明示的に要求された場合にのみ、生成された値を返します。
postalCode
属性の値を生成するテンプレートエントリー cn=exampleUS,ou=data,dc=example,dc=com に関連付けられていることを示しています。override 修飾子は、この値が postalCode
属性のエントリーによって保存される値よりも優先されることを示しています。
dn: cn=pointerCoS,dc=example,dc=com
objectclass: top
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn=exampleUS,ou=data,dc=example,dc=com
cosAttribute: postalCode override
7.2.7. CoS を使用した多値属性の処理
- 複数の CoS が生成する属性をターゲットエントリーにマージするルールを作成。これにより、ターゲットエントリーの値が複数表示されます。
- 競合する CoS 定義の中から 1 つの CoS 値を選択するように優先度を設定。これにより、ターゲットエントリーに 1 つの値が生成されます。
cosPriority
属性をサポートしません。
cosAttribute: attribute override merge-schemes
cosAttribute
に、同じ merge-schemes と override 修飾子を設定する必要があります。それ以外の場合は、1 つの組み合わせが可能なすべての CoS 定義から任意に選択されます。
- 1 つの CoS テンプレートエントリーに管理 CoS 属性のインスタンスが複数含まれるため、ターゲットエントリーに多値が作成されます。以下に例を示します。
dn: cn=server access template,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate accessTo: mail.example.com accessTo: irc.example.com
注記このメソッドは、Classic CoS でのみ動作します。 - 複数の CoS 定義が同じターゲット属性にサービスクラスを定義する可能性があるため、複数のテンプレートエントリーがあります。以下に例を示します。
dn: cn=mail template,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate accessTo: mail.example.com dn: cn=chat template,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate accessTo: irc.example.com
cosSpecifier
属性を使用できます。テンプレートの優先度は、cosPriority
属性を使用して設定します。この属性は、特定のテンプレートのグローバル優先度を表します。0 の優先度が最も優先されます。
dn: cn=data,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate departmentNumber: 71776 cosPriority: 0
departmentNumber
属性の値が含まれます。優先度はゼロであるため、このテンプレートは、別の departmentNumber
値を定義する他の競合するテンプレートよりも優先されます。
cosPriority
属性が含まれないテンプレートは、優先度が最も低いとみなされます。2 つ以上のテンプレートが属性値を提供し、優先度が同じ (または優先順位がない) 場合は、値が任意に選択されます。
cosPriority
値の動作は Directory Server では定義されないため、負の値を入力しないでください。
7.2.8. CoS 指定の属性の検索
postalCode
属性を設定できます。ただし、これらの CoS 定義属性に対する検索は、通常のエントリーに対する検索のように動作しません。
- Ted Morris の
postalCode
属性は、CoS によって定義されます。 - Barbara Jensen の
postalCode
属性は、Barbara Jensen 自身のエントリーに設定されます。 postalCode
属性はインデックス化されます。
- Ted Morris の
postalCode
属性は、CoS によって定義されます。 - Barbara Jensen の
postalCode
属性は、Barbara Jensen 自身のエントリーに設定されます。 postalCode
属性はインデックス化 されません。
cosAttribute
属性に指定された ID です。つまり、属性のローカル値は CoS 値を上書きできます。CoS に上書きが設定されていると、エントリーのローカル値がある限り、ldapsearch 操作は属性がインデックス化された場合でもエントリーの値を返します。CoS を持ち、ローカル値を持たない他のエントリーは、ldapsearch 操作では返されません。
7.2.9. アクセス制御と CoS
7.2.10. コンソールを使用した CoS の管理
7.2.10.1. 新規 CoS の作成
- Directory Server コンソールで、Directory タブを選択します。
- 左側のナビゲーションペインでツリーを参照し、新しいクラスの親エントリーを選択します。
- Object メニューに移動し、New > Class of Service を選択します。または、エントリーを右クリックし、New > Class of Service を選択します。
- 左側のペインで General を選択します。右側のペインで、Class Name フィールドに新しいクラスのサービスの名前を入力します。Description フィールドにクラスの説明を入力します。
- 左側のペインで 属性 をクリックします。右側のペインには、ターゲットエントリーで生成された属性の一覧が表示されます。
- リストに属性が追加されると、サービス の動作 列にドロップダウンリストが表示されます。
- Does not override target entry attribute を選択して、エントリーとともに対応する属性値が保存されていない場合に限り、ディレクトリーに対して生成された値を返すよう指示します。
- Overrides target entry attribute を選択して、CoS が生成した属性の値がローカル値をオーバーライドします。
- Overrides target entry attribute を選択し、 属性がローカル値を上書きして、属性が機能しないようにするため、明示的に要求されない限り、クライアントアプリケーションに表示されないようにすることができます。
- Does not override target entry attribute を選択し、エントリーに対応する属性値が格納されておらず、属性が機能しなくなった(明示的に要求されない限りクライアントアプリケーションに表示されない)場合にのみ、生成された値を返すようにディレクトリーに指示する 機能です。
注記属性は、スキーマで操作可能としても定義されている場合にのみ操作できます。たとえば、CoS がdescription
属性の値を生成する場合、Overrides ターゲットエントリー属性を選択することはできません。この属性はスキーマで稼働してい ないためです。 - 左側のペインで Template をクリックします。右側のペインで、テンプレートエントリーの特定方法を選択します。
- DN です。DN(ポインター CoS)のみで識別されるテンプレートエントリーを指定するには、Template DN フィールドにテンプレートの DN を入力します。 をクリックして、ローカルサーバーで DN を見つけます。これは、cn=CoS template,ou=People,dc=example,dc=com などの DN の正確な DN になります。
- ターゲットエントリーの属性の 1 つの値の使用。ターゲットエントリーの属性の 1 つ(間接的な CoS)の値で識別されるテンプレートエントリーが識別されるようにするには、Attribute Name フィールドに属性名を入力します。 をクリックして、利用可能な属性の一覧から別の属性を選択します。
- その DN とターゲットエントリーの属性の 1 つの値の両方を使用します。DN とターゲットエントリーの属性のいずれかの値(classic CoS)の両方によって識別されるテンプレートエントリーを設定するには、テンプレート DN と属性名の両方を入力します。Classic CoS のテンプレート DN はポインター CoS に対してより一般的です。テンプレートエントリーが存在するサフィックスまたは従属接尾辞を参照します。Classic CoS には複数のテンプレートが存在する場合があります。
7.2.10.2. CoS テンプレートエントリーの作成
cosTemplateDn
属性がその DN を反映しますが、テンプレートエントリーを CoS 自体に配置するのが最善の方法です。
- ポインター CoS の場合は、このエントリーが CoS の作成時に与えられた正確な DN を反映していることを確認します。
- Classic CoS の場合、テンプレート DN は、テンプレートのベース接尾辞として CoS エントリー自体を参照する再帰的である必要があります。
- Directory Server コンソールで、Directory タブを選択します。
- 左側のナビゲーションペインでツリーを参照し、サービスのクラスが含まれる親エントリーを選択します。CoS が他のエントリーと共に右側のペインに表示されます。
- CoS を右クリックし、New > Other の順に選択します。または、右側のペインで CoS を選択し、上部のメニューの Object をクリックし、New > Other を選択します。
- オブジェクトクラスの一覧から cosTemplate を選択します。注記LDAPsubentry オブジェクトクラスは新規テンプレートエントリーに追加できます。CoS テンプレートエントリーを LDAPsubentry オブジェクトクラスのインスタンスに設定すると、通常の検索を設定エントリーによって妨げられません。ただし、テンプレートエントリーがすでに存在し、その他(ユーザーエントリーである場合など)に使用される場合は、LDAPsubentry オブジェクトクラスをテンプレートエントリーに追加する必要はありません。
- オブジェクトクラス属性を選択し、をクリックします。
- extensibleObject オブジェクトクラス を追加します。これにより、ディレクトリーで利用可能な属性を追加できます。
cn
属性を追加し、ターゲットエントリーの属性値に対応する値を指定します。たとえば、従来の CoS の値を設定するためにmanager
属性を使用する場合は、cn
に uid=bparker,ou=people,dc=example,dc=com などのマネージャーの DN の値を指定します。または、cn=QA Role,dc=example,dc=com や通常の属性値などのロールに設定します。たとえば、employeeType
属性が選択された場合は、完全な時間または 一時的 になります。- 右下のボタンをクリックして naming 属性を変更します。
- エントリーの
cospriority
を、cn
ではなく naming 属性として使用します。 cospriority
を設定します。エントリーの特定の属性に適用される CoS が複数ある場合があります。cospriority
属性は、その特定の CoS の重要性をランク付けします。cospriority
が高いものは競合に優先します。最も高い優先度は 0 です。cosPriority
属性が含まれないテンプレートは、優先度が最も低いとみなされます。2 つ以上のテンプレートが属性値を指定し、優先度が同じ(または優先順位がない)場合、値は任意に選択されます。注記負のcosPriority
値の動作は Directory Server では定義されないため、負の値を入力しないでください。注記cosPriority
属性は、間接的な CoS ではサポートされていません。
7.2.11. コマンドラインでの CoS の管理
7.2.11.1. コマンドラインでの CoS 定義エントリーの作成
cosTemplateDn
属性で指定されたエントリー DN 値を使用してテンプレートエントリーを識別します。
例7.3 Pointer CoS エントリーの例
dn: cn=pointerCoS,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass:cosPointerDefinition
cosTemplateDn
:DN_string cosAttribute:list_of_attributes qualifier cn: pointerCoS
cosIndirectSpecifier
属性で指定されているターゲットエントリーの属性のいずれかの値に基づいてテンプレートエントリーを識別します。これは 例7.4「間接的な CoS エントリーの例」で説明されています。
例7.4 間接的な CoS エントリーの例
dn: cn=indirectCoS,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass:cosIndirectDefinition
cosIndirectSpecifier
:attribute_name cosAttribute:list_of_attributes qualifier cn: indirectCoS
cosTemplateDn
属性に設定) と、ターゲットエントリーの属性のいずれかの値 (cosSpecifier
属性に設定) の両方を使用してテンプレートエントリーを特定します。これは 例7.5「Classic CoS エントリーの例」で説明されています。
例7.5 Classic CoS エントリーの例
dn: cn=classicCoS,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass:cosClassicDefinition
cosTemplateDn
:DN_stringcosSpecifier
:attribute_name cosAttribute:list_of_attributes qualifier cn: classicCoS
cosAttribute
)。CoS の目的は、複数のエントリーに属性値を提供することです。cosAttribute
属性は、CoS が生成する属性を定義します。
7.2.11.2. コマンドラインでの CoS テンプレートエントリーの作成
cosAttribute
属性で指定) によって生成された属性とその属性の値も含まれます。
postalCode
属性の値を提供する CoS テンプレートエントリーは、以下のようになります。
dn:cn=exampleUS,ou=data,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 44438
7.2.11.3. Pointer CoS の例
- ldapmodify を使用して、新しい pointer CoS 定義エントリーを dc=example,dc=com 接尾辞に追加します。
dn: cn=pointerCoS,dc=example,dc=com changetype: add objectclass: top objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=exampleUS,ou=data,dc=example,dc=com cosAttribute: postalCode
- テンプレートエントリーを作成します。
dn: cn=exampleUS,ou=data,dc=example,dc=com changetype: add objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 44438
postalCode
属性に保存された値を dc=example,dc=com サフィックスに置かれているエントリーに提供します。これらのエントリーはターゲットエントリーです。
7.2.11.4. 間接的な CoS の例
manager
属性を使用して CoS テンプレートエントリーを識別します。これは、属性の値によって異なります。
- ldapmodify を使用して、dc=example,dc=com サフィックスに新しい間接 CoS 定義エントリーを追加します。
dn: cn=indirectCoS,dc=example,dc=com changetype: add objectclass: top objectclass: cosSuperDefinition objectclass: cosIndirectDefinition cosIndirectSpecifier: manager cosAttribute: departmentNumber
departmentNumber
属性がすでに含まれる場合は、他の属性をマネージャーエントリーに追加する必要はありません。この属性は定義エントリーの cosIndirectSpecifier
属性で指定されるので、定義エントリーは manager
属性が含まれるエントリーのターゲットサフィックス (dc=example,dc=com のエントリー) を検索します。次に、一覧表示された manager エントリーの departmentNumber
値を確認します。departmentNumber
属性の値は、manager
属性を持つマネージャーの下位すべてに自動的にリレーされます。departmentNumber
の値は、異なるマネージャーのエントリーに記載されている部門番号によって異なります。
7.2.11.5. Classic CoS の例
cosSpecifier
属性で指定された属性の組み合わせを使用して、郵便番号コードを自動的に生成するClassic CoS を作成します。
- ldapmodify を使用して、新しいクラス CoS 定義エントリーを dc=example,dc=com サフィックスに追加します。
dn: cn=classicCoS,dc=example,dc=com changetype: add objectclass: top objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: cn=classicCoS,dc=example,dc=com cosSpecifier: businessCategory cosAttribute: postalCode override
- 営業部門およびマーケティング部門のテンプレートエントリーを作成します。CoS 属性をテンプレートエントリーに追加します。テンプレートの
cn
は、ターゲットエントリーのbusinessCategory
属性の値を設定し、テンプレートの値に応じて属性を追加または上書きされます。dn: cn=sales,cn=classicCoS,dc=example,dc=com changetype: add objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 44438 dn: cn=marketing,cn=classicCoS,dc=example,dc=com changetype: add objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 99111
businessCategory
属性と cosTemplateDn
属性の組み合わせによって、2 つのテンプレートのいずれかに到達することができます。1 つ目は営業テンプレートで、営業部門に従業員固有の郵便番号コードを提供します。マーケティングテンプレートは、マーケティング部門の従業員固有の郵便番号コードを提供します。
7.2.11.6. CoS エントリーの検索
ldapsearch -x -s sub -b ou=People,dc=example,dc=com "(objectclass=*)"
dn: cn=pointerCoS,ou=People,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass: cosPointerDefinition objectclass: ldapSubEntry cosTemplateDn: cn=exampleUS,ou=data,dc=example,dc=com cosAttribute: postalCode override
ldapsearch -x -s sub -b ou=People,dc=example,dc=com "(|(objectclass=*)(objectclass=ldapSubEntry))"
7.2.12. ロールベースの属性の作成
nsRole
属性を cosSpecifier
として使用します。nsRole
属性が多値指定できるため、複数のテンプレートエントリーを持つ CoS スキームを定義できます。使用するテンプレートエントリーの曖昧さを解決するには、CoS テンプレートエントリーに cosPriority
属性を追加します。
dn: cn=ManagerRole,ou=people,dc=example,dc=com objectclass: top objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: ManagerRole nsRoleFilter: ou=managers Description: filtered role for managers
nsRoleFilter
属性は仮想属性の値を受け付けません。
dn: cn=managerCOS,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: cn=managerCOS,dc=example,dc=com cosSpecifier: nsRole cosAttribute: mailboxquota override
cosTemplateDn
属性は、cosSpecifier
属性で指定された属性 (ターゲットエントリーの nsRole
属性) とともに CoS テンプレートエントリーを識別する値を提供します。CoS テンプレートエントリーは、mailboxquota
属性の値を提供します。override の他の修飾子は、ターゲットエントリーの既存の mailboxquota
属性値を上書きするよう CoS に指示します。
dn:cn="cn=ManagerRole,ou=people,dc=example,dc=com",cn=managerCOS,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate mailboxquota: 1000000
mailboxquota
属性の値 1000000 を指定します。
7.3. 属性値の管理属性のリンク
7.3.1. リンク属性の概要
linkType
) およびプラグインによって自動的に維持される 1 つの属性 (managedType
) を設定します。
図7.4 リンク先属性の基本設定
図7.5 リンク先属性プラグインを特定のサブツリーに制限
- 管理属性とリンク先属性の両方で、属性定義で識別名の構文が必要です。リンク先属性は基本的にクロス参照で管理されます。プラグインがこれらの相互参照を処理する方法は、属性値からエントリーの DN をプルすることで行われます。カスタムスキーマ要素のプランニングに関する情報は、「12章ディレクトリースキーマの管理」を参照してください。
- 各リンク先属性プラグインインスタンスはローカルで、管理 属性は一部レプリケーションを使用してレプリケーションからブロックする必要があります。あるサプライヤーに加えられた変更は、プラグインが自動的に発生し、対応するディレクトリーエントリーの値を管理するため、データはサーバー全体で一貫性を維持します。ただし、リンクされたエントリー間でデータを一貫性を保つには、プラグインインスタンスで管理属性を維持する必要があります。つまり、管理属性の値は、マルチマスターレプリケーション環境であってもレプリケーションプロセスではなく、プラグインプロセスによってのみ維持される必要があります。一部レプリケーションの使用方法は、「一部レプリケーションを使用した属性のサブセットの複製」を参照してください。
7.3.2. リンク元属性プラグイン構文の確認
linkType
属性において、管理者が手動で管理する属性managedType
属性に含まれる、プラグインによって動的に作成される属性- 必要に応じて、プラグインを
linkScope
属性のディレクトリーツリーの特定の部分に制限するスコープ
例7.6 リンク先属性のプラグインインスタンスエントリーの例
dn: cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: Manager Link linkType: directReport managedType: manager linkScope: ou=people,dc=example,dc=com
プラグイン属性 | 詳細 |
---|---|
cn | プラグインインスタンスの一意の名前を指定します。 |
linkScope | プラグインインスタンスの機能を制限する接尾辞の DN が含まれます。 |
linkType | 管理者が維持する属性を指定します。この属性は手動で維持され、プラグインの参照として使用されます。この属性には DN 値の形式が必要です。属性を追加、変更、または削除されると、その値には、更新するプラグインのターゲットエントリーの DN が含まれます。 |
managedType | プラグインによって維持される属性を指定します。この属性は、ターゲットエントリーで作成され、更新されます。この属性には DN 値の形式が必要です。属性がエントリーに追加されると、その値は管理エントリーへの相互参照として表されます。 |
7.3.3. 属性リンクの設定
- これが有効になっていない場合は、「Directory Server コンソールでプラグインの有効化」 または 「プラグインを動的に有効化」 の説明に従って、リンク先属性プラグインを有効にします。
- プラグインインスタンスを作成します。
managedType
およびlinkType
属性の両方が必要です。プラグインの構文については、「リンク元属性プラグイン構文の確認」 を参照してください。以下の例は、ldapmodify を使用して作成したプラグインインスタンスを示しています。dn: cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: Manager Link linkType: directReport managedType: manager
nsslapd-dynamic-plugins
を使用して動的プラグインを有効にするためにサーバーが設定されていない場合は、サーバーを再起動して新しいプラグインインスタンスを適用します。# systemctl restart dirsrv.target
7.3.4. 属性リンクのクリーンアップ
7.3.4.1. fixup-linkedattrs.pl を使用したリンク先属性の再生成
# fixup-linkedattrs.pl -D "cn=Directory Manager" -w password
-l
オプションを使用してターゲットプラグインインスタンス DN を指定し、修正タスクを単一のリンク管理属性ペアに制限することもできます。
# fixup-linkedattrs.pl -D "cn=Directory Manager" -w password -l "cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config"
fixup-linkedattrs.pl
スクリプトの説明を参照してください』。
7.3.4.2. ldapmodify を使用したリンク先属性の再生成
dse.ldif
ファイルの cn=tasks 設定エントリーで発生するため、ldapmodify を使用してエントリーを追加してタスクを開始することもできます。タスクが完了すると、エントリーはディレクトリーから削除されます。
cn
のみですが、ttl
属性にはタイムアウト期間を設定できます。ldapmodify の使用:
dn: cn=example,cn=fixup linked attributes,cn=tasks,cn=config changetype: add cn:example ttl: 5
dse.ldif
設定から削除されるため、同じタスクエントリーを継続的に再利用できます。
7.4. 一意の数値属性値の割り当ておよび管理
uidNumber
や gidNumber
などの一意の番号が必要です。Directory Server は、DNA (Distributed Numeric Assignment) プラグインを使用して、指定された属性に一意の番号を自動的に生成して提供できます。
7.4.1. 動的番号の割り当ての概要
7.4.1.1. フィルター、検索、およびターゲットエントリー
7.4.1.2. 範囲および割り当て番号
- 最も単純なケースでは、属性がない場合に、unique-number 属性を必要とするオブジェクトクラスを持つディレクトリーにユーザーエントリーが追加されます。管理属性に値を持たないエントリーを追加すると、DNA プラグインによる値の割り当てが発生します。このオプションは、一意の値を 1 つの属性に割り当てるように DNA プラグインが設定されている場合に限り機能します。
- 同様の管理可能なオプションは、マジック番号 を使用することです。このマジックナンバーは、管理対象属性のテンプレート値であり、サーバーの範囲外のもの、数字、または単語でさえあり、プラグインは新しい割り当て値に置き換える必要があると認識します。マジック値でエントリーが追加され、エントリーが設定された DNA プラグインの範囲およびフィルター内にある場合は、プラグインでマジック番号を使用した新しい値の生成が自動的に発生します。下の例では、ldapmodify の使用に基づいて、0 をマジックナンバーとして追加します。
dn: uid=jsmith,ou=people,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: posixAccount uid: jsmith cn: John Smith
uidNumber: 0
gidNumber: 0
....
7.4.1.3. 同じ範囲の複数の属性
- 一意の番号の 1 つの範囲から、1 つの属性タイプに割り当てられた 1 つの番号。
- 1 つのエントリーの 2 つの属性に割り当てられた同じ一意の番号。
- 2 つの異なる属性は、同じ範囲の一意の数字から 2 つの異なる数字を割り当てていました。
employeeID
を割り当てる際には、各従業員エントリーに一意の employeeID
が割り当てられます。
uidNumber
と gidNumber
を posixAccount エントリーに割り当てると、DNA プラグインは同じ数を両方の属性に割り当てます。これを行うには、マジック値を指定して、両方の管理属性を変更操作に渡します。ldapmodify の使用:
# ldapmodify -D "cn=Directory Manager" -W -x dn: uid=jsmith,ou=people,dc=example,dc=com changetype: modify add: uidNumber uidNumber: 0 - add:gidNumber gidNumber: 0
uidNumber
属性を許可しませんが、gidNumber
を許可します。DNA プラグインが uidNumber
と gidNumber
の両方を管理する場合は、posixGroup エントリーが作成されると、gidNumber
の一意の番号が uidNumber
属性および gidNumber
属性と同じ範囲から割り当てられます。プラグインが管理するすべての属性に同じプールを使用すると、一意の数字の割り当てを維持し、異なるエントリーの uidNumber
と gidNumber
が異なる範囲から割り当てられ、同じ 一意 の番号になる状況を防ぐことができます。
# ldapmodify -D "cn=Directory Manager" -W -x dn: uid=jsmith,ou=people,dc=example,dc=com changetype: modify add: uidNumber uidNumber: 0 ^D # ldapmodify -D "cn=Directory Manager" -W -x dn: uid=jsmith,ou=people,dc=example,dc=com changetype: modify add: employeeId employeeId: magic
例7.7 DNA および一意の銀行口座番号
primaryAccount
属性および customerID
属性に同じ一意の番号を使用します。銀行の例の管理者は、DNA プラグインが同じ範囲から両方の属性に一意の値を割り当てるよう設定していました。
secondaryAccount
属性を管理するように設定しますが、エントリーの作成、secondaryAccount
属性および primaryAccount
属性の割り当ての後 にのみ customerID
属性を追加します。これにより、primaryAccount
および customerID
は、同じ一意の番号を共有し、secondaryAccount
番号は完全に一意ですが、それでも同じ範囲の番号からのものです。
7.4.2. DNA プラグイン構文の確認
- 値が管理される属性で、
dnaType
属性に設定されます。 dnaScope
属性に設定される、エントリーを検索するためのベースとして使用するエントリー DNdnaFilter
属性に設定される、管理するエントリーの特定に使用する検索フィルターdnaNextValue
属性に設定される、次に割り当てることができる値 (エントリーの作成後、プラグインにより処理される)
dn: cn=Account UIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: dnaPluginConfig cn: Account UIDs dnatype: uidNumber dnafilter: (objectclass=posixAccount) dnascope: ou=people,dc=example,dc=com dnaNextValue: 1
- サーバーが割り当てることができる最大数。これにより、範囲の上限が設定されます。これは、複数のサーバーが番号を割り当てるときに論理的に必要です。これは
dnaMaxValue
属性で設定されます。 dnaThreshold
属性に設定された範囲転送を発生させるのに範囲が十分低いしきい値です。これが設定されていない場合、デフォルト値は 1 になります。dnaRangeRequestTimeout
属性に設定される、サーバーが転送を待ってハングしないようにするためのタイムアウト期間。これを設定しないと、デフォルト値は 10 (10 秒) になります。dnaSharedCfgDN
属性に設定した各サプライヤーの範囲情報を保存するすべてのサプライヤーサーバー間で共有される設定エントリー DN。
dnaNextRange
属性で定義されます。これは、次に利用可能な範囲を表示し、サーバーが範囲が割り当てられているか、または使用しているため、プラグインにより自動的に管理されます。この範囲は「デッキ上」にあります。 別のサーバーには割り当てられておらず、ローカルの Directory Server が使用する場合は引き続き利用できます。
dn: cn=Account UIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: dnaPluginConfig cn: Account UIDs dnatype: uidNumber dnafilter: (objectclass=posixAccount) dnascope: ou=People,dc=example,dc=com dnanextvalue: 1 dnaMaxValue: 1300 dnasharedcfgdn: cn=Account UIDs,ou=Ranges,dc=example,dc=com dnathreshold: 100 dnaRangeRequestTimeout: 60 dnaNextRange: 1301-2301
dnaNextRange
属性は、個別の特定範囲を他のサーバーに割り当てる必要がある場合にのみ明示的に設定する必要があります。dnaNextRange
属性に設定した範囲は、重複を避けるために、他のサーバーで利用可能な範囲から一意でなければなりません。他のサーバーからの要求がなく、dnaNextRange
が設定されているサーバーが設定 dnaMaxValue
に到達した場合は、次に値 (dnaNextRange
の一部) がこのデッキから割り当てられます。
dnaNextRange
割り当ては、DNA 設定に設定されている dnaThreshold
属性によっても制限されます。dnaNextRange
用に別のサーバーに割り当てられる範囲は、範囲が dnaNextRange
のデッキで利用可能であっても、サーバーのしきい値に違反できません。
dnaNextRange
属性が明示的に設定されていない場合は、内部的に処理されます。自動的に処理される場合、dnaMaxValue
属性は次の範囲の上限として機能します。
dnasharedcfgdn
の場所の子です。設定エントリーは他のすべてのサプライヤーに複製されるため、各サプライヤーが設定を確認して、新しい範囲で問い合わせるサーバーを見つけることができます。以下に例を示します。
dn: dnaHostname=ldap1.example.com+dnaPortNum=389,cn=Account UIDs,ou=Ranges,dc=example,dc=com objectClass: dnaSharedConfig objectClass: top dnahostname: ldap1.example.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemainingValues: 1000
7.4.3. 一意の番号割り当ての設定
7.4.3.1. 一意の番号割り当ての設定
dnaNextvalue
がすでに取得されているかどうかを確認するために、サーバーは、内部的にソートされた検索を実行する必要があります。これには、適切な順序のマッチングルールとともに整数属性で等価インデックスが必要であるかを確認します。
- 複製されたサブツリーに共有コンテナーエントリーを作成します。以下の例では、ldapmodify を使用してこれを行います。
dn: ou=Ranges,dc=example,dc=coma changetype: add objectclass: top objectclass: extensibleObject objectclass: organizationalUnit ou: Ranges dn: cn=Account UIDs,ou=Ranges,dc=example,dc=coma changetype: add objectclass: top objectclass: extensibleObject cn: Account UIDs
- DNA プラグインを有効にし、これを動的として設定します。デフォルトでは、(コンテナーエントリーである)プラグインエントリーは無効になっています。動的プラグインの設定に関する詳細は、「プラグインを動的に有効化」 を参照してください。
- コンテナーエントリーの下に、新しい DNA プラグインインスタンスを作成します。以下に例を示します。注記一意の番号割り当て(
dnaType
)を持つエントリー属性を設定するプラグイン属性は多値です。同じプラグインインスタンスに複数の属性が設定されている場合、その番号の割り当ては同じ範囲から取得されます。異なる範囲を使用するには、異なるプラグインインスタンスを設定します。ldapmodify の使用:dn: cn=Account UIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectClass: top objectClass: dnaPluginConfig cn: Account UIDs dnatype: uidNumber dnafilter: (objectclass=posixAccount) dnascope: ou=People,dc=example,dc=com dnanextvalue: 1 dnaMaxValue: 1300 dnasharedcfgdn: cn=Account UIDs,ou=Ranges,dc=example,dc=com dnathreshold: 100 dnaRangeRequestTimeout: 60 dnaMagicRegen: magic
cn=DNA_config_entry,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config エントリーでサポートされる属性の一覧は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス を参照してください。』 - マルチマスターレプリケーションのサーバーでは、接続情報および範囲を指定するホストの設定エントリーを作成します。エントリーの DN は、ホスト名とポート番号の組み合わせです(dnaHostname+dnaPortNum)。ldapmodify の使用:
dn: dnaHostname=ldap1.example.com+dnaPortNum=389,cn=Account UIDs,ou=Ranges,dc=example,dc=com changetype: add objectClass: dnaSharedConfig objectClass: top dnahostname: ldap1.example.com dnaPortNum: 389 dnaSecurePortNum: 636 dnaRemainingValues: 1000
- サーバーが動的プラグインを有効にするために設定されていない場合は、サーバーを再起動して新しいプラグインインスタンスを読み込みます。
# systemctl restart dirsrv@instance
7.4.3.2. コンソールでの DNA プラグインの編集
dnaNextvalue
がすでに取得されているかどうかを確認するために、サーバーは、内部的にソートされた検索を実行する必要があります。これには、適切な順序のマッチングルールとともに整数属性で等価インデックスが必要であるかを確認します。
- Directory タブをクリックします。
- config ディレクトリーを開き、plugins フォルダーを展開します。
- Distributed Numeric Assignment プラグインフォルダーをクリックします。すべての DNA プラグインインスタンスがメインウィンドウに一覧表示されます。
- DNA インスタンスエントリーを強調表示し、Advanced リンクを右クリックして、プロパティーエディターを開きます。
- DNA 関連の属性を編集します。
7.4.4. Distributed Number Assignment プラグインのパフォーマンスに関する注意事項
第8章 エントリーの編成とグループ化
8.1. グループの使用
nsRoleDN
属性に保存されます。グループを使用する場合は、このグループのメンバーであるユーザーの DN は、グループオブジェクトの member
属性に保存されます。memberOf プラグインを有効にした場合、次にユーザーがメンバーであるグループは、ユーザーオブジェクトの memberOf
属性に追加で保存されます。このプラグインを有効にすると、グループにもロールの利点があり、ロールの使用時と同様にユーザーのグループメンバーシップを一覧表示できます。また、グループはロールよりも高速です。
8.1.1. コンソールで静的グループの作成
- Directory Server コンソールで、Directory タブを選択します。
- 左側のペインで、新しいグループを追加するエントリーを右クリックし、New > Group を選択します。または、Object メニューに移動し、New > Group を選択します。
- 左側のペインで General をクリックします。Group Name フィールドに新規グループの名前を入力します(名前は必須です)、Description フィールドに新しいグループの説明を入力します。
- 左側のペインで Members をクリックします。右側のペインで、静的グループ タブを選択します。 をクリックして、新しいメンバーをグループに追加します。
- Search ドロップダウンリストで、検索するエントリーのソート(ユーザー、グループ、またはその両方)を選択してから Search をクリックします。
- 返されたエントリーからメンバーを選択し、をクリックします。
- 左側のペインで Languages をクリックし、そのグループに言語固有の情報を追加します。
8.1.2. コンソールでの動的グループの作成
- Directory Server コンソールで、Directory タブを選択します。
- 左側のペインで、新しいグループを追加するエントリーを右クリックし、New > Group を選択します。または、Object メニューに移動し、New > Group を選択します。
- 左側のペインで General をクリックします。Group Name フィールドに新規グループの名前を入力します(名前は必須です)、Description フィールドに新しいグループの説明を入力します。
- 左側のペインで Members をクリックします。右側のペインで、Dynamic Group タブを選択します。 をクリックして、データベースのクエリーを行うための LDAP URL を作成します。
- テキストフィールドに LDAP URL を入力するか、LDAP URL の構成 で説明するto を選択します。この結果には、フィルターに対応する現在のエントリー(グループメンバー)が表示されます。
- 左側のペインで Languages をクリックし、そのグループに言語固有の情報を追加します。
8.1.3. コマンドラインでのグループの作成
- groupOfNames (推奨) は、任意のエントリーの追加を可能にする単純なグループです。これのメンバーを判断するために使用される属性は
member
です。 - groupOfNames などの groupOfUniqueNames は、ユーザー DN をメンバーとして一覧表示しますが、メンバーは一意でなければなりません。これにより、ユーザーをグループメンバーとして複数回追加しないようにできます。これは、セルフ参照グループメンバーシップを防ぐ 1 つの方法です。これのメンバーを判断するために使用される属性は
uniqueMember
です。 - groupOfURLs は、LDAP URL の一覧を使用して、メンバーシップの一覧をフィルタリングして生成します。このオブジェクトクラスはすべての動的グループに必要で、groupOfNames および groupOfUniqueNames と共に使用できます。
- groupOfCertificates は、グループメンバーを識別するための証明書 (実際には証明書名) を検索して識別するために LDAP フィルターを使用するという点で、groupOfURLs と似ています。これは、グループに特別なアクセスパーミッションを付与できるため、グループベースのアクセス制御に役立ちます。これのメンバーを判断するために使用される属性は
memberCertificate
です。
グループのタイプ | グループオブジェクトクラス | member 属性 |
---|---|---|
静的 | groupOfUniqueNames | uniqueMember |
動的 |
groupOfUniqueNames
groupOfURLs
| memberURL |
dn: cn=static group,ou=Groups,dc=example,dc=com changetype: add objectClass: top objectClass: groupOfUniqueNames cn: static group description: Example static group. uniqueMember: uid=mwhite,ou=People,dc=example,dc=com uniqueMember: uid=awhite,ou=People,dc=example,dc=com
dn: cn=dynamic group,ou=Groups,dc=example,dc=com changetype: add objectClass: top objectClass: groupOfUniqueNames objectClass: groupOfURLs cn: dynamic group description: Example dynamic group. memberURL: ldap:///dc=example,dc=com??sub?(&(objectclass=person)(cn=*sen*))
memberURL
属性を設定すると、memberOf プラグインはフィルターに一致するユーザーオブジェクトに memberOf
属性を追加しません。
8.1.4. ユーザーエントリーにおけるグループメンバーシップの一覧表示
memberOf
属性を自動的に書き込みます。(デフォルトでは、これにより member
属性を確認しますが、複数の属性インスタンスを使用して複数の異なるグループタイプをサポートすることができます。)
memberOf
属性を更新します。MemberOf プラグインは、ネスト化されたグループメンバーシップを含むエントリーを確認して、ユーザーが属するグループを表示する方法を提供します。ネスト化されたグループを介してメンバーシップを追跡することは非常に困難ですが、MemberOf プラグインには、すべてのグループの (直接および間接的な) メンバーシップが表示されます。
8.1.4.1. memberOf
プラグインを使用する場合の考慮事項
memberOf
プラグインを使用する際に重要な考慮事項を説明します。
- レプリケーショントポロジーでの
memberOf
プラグインの使用 - レプリケーショントポロジーで
memberOf
属性を管理する方法は 2 つあります。- トポロジー内のすべてのマスターで
memberOf
プラグインおよび読み取り専用レプリカサーバーを有効にします。この場合、すべてのレプリカ合意で、レプリケーションからmemberOf
属性を除外する必要があります。属性の除外に関する詳細は、「一部レプリケーションを使用した属性のサブセットの複製」を参照してください。 memberOf
プラグインは、トポロジー内のすべてのマスターサーバーでのみ有効にします。そのためには、以下を実行します。- レプリカ合意ですべての書き込みが有効なマスターに対する
memberOf
属性のレプリケーションを無効にする必要があります。属性の除外に関する詳細は、「一部レプリケーションを使用した属性のサブセットの複製」を参照してください。 memberOf
属性のレプリケーションを、すべての読み取り専用レプリカに対して、レプリカ合意で有効にする必要があります。- 読み取り専用レプリカでは、
memberOf
プラグインを有効にしないでください。
- 分散データベースでの
memberOf
プラグインの使用 - 「データベースの作成」で説明されているように、ディレクトリーのサブツリーを個別のデータベースに保存できます。デフォルトでは、
memberOf
プラグインはグループと同じデータベース内に保存されるユーザーエントリーのみを更新します。プラグインがグループとして異なるデータベースのユーザーも更新できるようにするには、memberOfAllBackends
パラメーターを on に設定する必要があります。「コンソールからの MemberOf プラグインの編集」 を参照してください。
8.1.4.2. memberOf
プラグインで必要なオブジェクトクラス
memberOf
プラグインは nsMemberOf オブジェクトクラスをオブジェクトに追加し、memberOf
属性を提供します。このオブジェクトクラスは、この目的のために任意のオブジェクトに安全に追加でき、このプラグインを正しく動作させるためにこれ以上のアクションは必要ありません。代わりに、inetUser オブジェクトクラスまたは inetAdmin オブジェクトクラスが含まれるユーザーオブジェクトを作成できます。どちらのオブジェクトクラスも memberOf
属性をサポートします。
LDAP: error code 65 - Object Class Violation
8.1.4.3. MemberOf プラグイン構文
memberOfGroupAttr
) と、メンバーのユーザーエントリー (memberOfAttr
) で作成および管理する属性の 2 つの属性を定義します。
memberOfGroupAttr
属性は多値です。異なるタイプのグループは異なるメンバー属性を使用するため、複数の memberOfGroupAttr
属性を使用すると、プラグインで複数のグループタイプを管理できます。
例8.1 デフォルトの MemberOf プラグインエンティティー
dn: cn=MemberOf Plugin,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObjectcn: MemberOf Plugin
nsslapd-pluginPath: libmemberof-plugin
nsslapd-pluginInitfunc: memberof_postop_init
nsslapd-pluginType: postoperationnsslapd-pluginEnabled: on
nsslapd-plugin-depends-on-type: databasememberOfGroupAttr: member
memberOfGroupAttr: uniqueMember
memberOfAttr: memberOf
memberOfAllBackends: on
nsslapd-pluginId: memberOf nsslapd-pluginVersion:X.Y.Z
nsslapd-pluginVendor: Red Hat, Inc. nsslapd-pluginDescription: memberOf plugin
member
) のみを許可した古いバージョンの Directory Server との後方互換性を維持するために、プラグイン設定で使用される新しいメンバー属性に加えて、member
グループ属性または以前のメンバー属性を含める必要がある場合があります。
memberOfGroupAttr: member
memberOfGroupAttr: uniqueMember
8.1.4.4. MemberOf プラグインのインスタンスの設定
8.1.4.4.1. コンソールからの MemberOf プラグインの編集
- Configuration タブを選択し、Plugins フォルダーに展開します。
- Memberof Plugin エントリーまでスクロールします。
- プラグインが有効化されていることを確認します。これはデフォルトで無効にされます。
- Properties Editor を開きます。
memberOfGroupAttr
属性は、サーバーがメンバーエントリーを識別するために使用するグループエントリーの属性を設定します。この属性は、異なるグループ/メンバータイプに対して複数回使用できます。memberOfAttr
属性は、プラグインがユーザーエントリーで作成および管理する属性を設定します。- 変更を保存します。
- Directory Server が動的プラグインを有効にするために設定されていない場合は、サーバーを再起動してプラグインを更新します。
8.1.4.4.2. コマンドラインでの MemberOf プラグインの編集
- MemberOf プラグインを有効にします。ldapmodify の使用:
dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
- グループメンバーエントリー属性に使用する属性を設定します。デフォルトの属性は
member
で、replace コマンドを使用して変更できます。memberOfGroupAttr
属性は多値であるため、追加のメンバータイプを定義に追加できます。たとえば、ldapmodify を使用するには、以下を実行します。dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify add: memberOfGroupAttr memberOfGroupAttr: uniqueMember add: memberOfGroupAttr memberOfGroupAttr: customMember-
- グループメンバーシップを表示するようにユーザーエントリーに設定する属性を設定します。たとえば、ldapmodify を使用するには、以下を実行します。
dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify replace: memberOfAttr memberOfAttr: memberOf
- オプション。デプロイメントで分散データベースを使用する場合は、
memberOfAllBackends
属性を有効にして、ユーザーエントリーについてローカルのデータベースだけではなく、すべてのデータベースを検索します。ldapmodify の使用:dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify replace: memberOfAllBackends memberOfAllBackends: on
- Directory Server が動的プラグインを有効にするために設定されていない場合は、サーバーを再起動して変更した新しいプラグインインスタンスを読み込みます。
8.1.4.6. MemberOf プラグインのスコープの設定
memberOfEntryScope
パラメーターおよび memberOfEntryScopeExcludeSubtree
パラメーターを使用して、MemberOf
プラグインが動作するサフィックスを設定できます。
MemberOf
プラグインは、ユーザーおよびグループの両方がプラグインのスコープにある場合に限り memberOf
属性をグループに追加します。たとえば、dc=example,dc=com
内のすべてのエントリーで機能するように MemberOf
プラグインを設定し、ou=private,dc=example,dc=com
のエントリーを除外するには、以下を設定します。
memberOfEntryScope: dc=example,dc=com memberOfEntryScopeExcludeSubtree: ou=private,dc=example,dc=com
memberOfEntryScope
パラメーターで設定したスコープからユーザーエントリーを移動した場合には、以下を実行します。
member
などのメンバーシップ属性は、グループエントリーで更新され、ユーザー DN 値が削除されます。memberOf
属性は、グループ DN 値を削除するためにユーザーエントリーで更新されます。
memberOfEntryScopeExcludeSubtree
パラメーターに設定した値は、memberOfEntryScope
に設定した値よりも高くなります。両方のパラメーターで設定したスコープが重複する場合、MemberOf
プラグインは、非オーバーラッピングディレクトリーエントリーでのみ機能します。
8.1.4.7. memberOf 値の同期
memberOf
属性を自動的に管理します。ただし、memberOf
属性がすでに設定されているサーバーに、ユーザーエントリーで memberOf
属性を直接編集することも、新しいエントリーをインポートまたは複製できます。このような状況では、サーバープラグインによって管理される memberOf
設定と、エントリーに定義された実際のメンバーシップとの間に不整合が生じます。
memberOf
修復タスクがあり、適切な memberOf
属性がエントリーに設定されていることを確認します。このタスクをトリガーする方法は 3 つあります。
- Directory Server コンソール
- fixup-memberof.pl スクリプトの使用
- cn=memberof task,cn=tasks,cn=config タスクエントリーの実行
memberOf
属性は更新されません。
8.1.4.7.1. fixup-memberof.pl を使用した memberOf 属性の初期化および再生成
memberOf
の説明に従って 「ldapmodify を使用した memberOf 属性の初期化および再生成」 属性を再生成するために使用される Perl スクリプトラッパーです。
8.1.4.7.2. ldapmodify を使用した memberOf 属性の初期化および再生成
memberOf
属性を再生成することは、特別なタスク設定エントリーで管理できるタスクの 1 つです。タスクエントリーは、dse.ldif
ファイルの cn=tasks 設定エントリーで発生するため、ldapmodify を使用してエントリーを追加してタスクを開始することもできます。タスクが完了するとすぐに、エントリーはディレクトリーから削除されます。
memberOf
属性を再生成する Directory Server インスタンスに特別なタスクエントリーを作成します。
cn
のみです。ldapmodify の使用:
dn: cn=example memberOf,cn=memberof task,cn=tasks,cn=config changetype: add cn:example memberOf
dse.ldif 設定から削除
されるため、同じタスクエントリーを継続的に再利用できます。
8.1.5. 指定したグループへのエントリーの自動追加
autoMemberProcessModifyOps
パラメーターは on に設定されます。この設定では、Automembership プラグインは、ユーザーエントリーを編集して管理者が別のグループにユーザーを移動する際にグループメンバーシップも更新します。
autoMemberProcessModifyOps
を off に設定すると、Directory Server は、ユーザーにグループエントリーを追加する場合にのみプラグインを起動し、グループメンバーシップを更新するために手動で修正タスクを実行する必要があります。
8.1.5.1. Automembership ルールの構造の確認
8.1.5.1.1. Automembership 設定エントリー
- 検索スコープと検索フィルターの両方を含むエントリーを識別する LDAP 検索 (
autoMemberScope
およびautoMemberFilter
) - メンバーエントリーを追加するデフォルトグループ (
autoMemberDefaultGroup
) - メンバーエントリーの形式:
member
などのグループエントリーの属性、およびdn
などの属性値 (autoMemberGroupingAttr
)
dn: cn=Windows Users,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition autoMemberScope: ou=People,dc=example,dc=com autoMemberFilter: objectclass=ntUser autoMemberDefaultGroup: cn=windows-group,cn=groups,dc=example,dc=com autoMemberGroupingAttr: member:dn
8.1.5.1.2. 追加の正規表現エントリー
例8.2 ホストグループの automember 定義
dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition cn: Hostgroups autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ipHost autoMemberDefaultGroup: cn=systems,cn=hostgroups,dc=example,dc=com autoMemberGroupingAttr: member:dn
例8.3 Web サーバーグループの正規表現条件
dn: cn=webservers,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: Group for webservers cn: webservers autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com autoMemberInclusiveRegex: fqdn=^www\.web[0-9]+\.example\.com
図8.1 正規表現の条件
属性 | 説明 |
---|---|
autoMemberRegexRule (必須オブジェクトクラス) | 正規表現ルールとしてエントリーを識別します。このエントリーは、automember 定義 (objectclass: autoMemberDefinition) の子である必要があります。 |
autoMemberInclusiveRegex | 含めるエントリーを識別するために使用する正規表現を設定します。一致するエントリーのみがグループに追加されます。複数の正規表現を使用できます。エントリーがこれらの式のいずれかと一致する場合は、グループに含まれます。
式の形式は、Perl と互換性のある正規表現 (PCRE) です。PCRE パターンの詳細は、pcresyntax(3) の man ページを参照してください。
これは多値属性です。
|
autoMemberExclusiveRegex | 除外するエントリーを識別するために使用する正規表現を設定します。エントリーが除外条件と一致する場合は、グループに 含まれません。複数の正規表現を使用できます。エントリーがこれらの式のいずれかと一致する場合は、グループで除外されます。
式の形式は、Perl と互換性のある正規表現 (PCRE) です。PCRE パターンの詳細は、pcresyntax(3) の man ページを参照してください。
これは多値属性です。
注記
除外条件は最初に評価され、包含条件よりも優先されます。
|
autoMemberTargetGroup | 正規表現の条件を満たす場合に、エントリーをメンバーとして追加するグループを設定します。 |
8.1.5.2. Automembership ルールの例
- IP アドレスに基づく異なるホストグループ
- Windows ユーザーグループ
- 従業員の ID に基づく異なるユーザーグループ
例8.4 IP アドレス別のホストグループ
configuration entry dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition cn: Hostgroups autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=bootableDevice autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com autoMemberGroupingAttr: member:dn regex entry #1 dn: cn=webservers,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: Group placement for webservers cn: webservers autoMemberTargetGroup: cn=webservers,cn=hostgroups,dc=example,dc=com autoMemberInclusiveRegex: fqdn=^www[0-9]+\.example\.com autoMemberInclusiveRegex: fqdn=^web[0-9]+\.example\.com autoMemberExclusiveRegex: fqdn=^www13\.example\.com autoMemberExclusiveRegex: fqdn=^web13\.example\.com regex entry #2 dn: cn=mailservers,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: Group placement for mailservers cn: mailservers autoMemberTargetGroup: cn=mailservers,cn=hostgroups,dc=example,dc=com autoMemberInclusiveRegex: fqdn=^mail[0-9]+\.example\.com autoMemberInclusiveRegex: fqdn=^smtp[0-9]+\.example\.com autoMemberExclusiveRegex: fqdn=^mail13\.example\.com autoMemberExclusiveRegex: fqdn=^smtp13\.example\.com
例8.5 Windows ユーザーグループ
posixAccount
属性を使用して新規ユーザーをすべて識別します。Directory Server 内に作成された新規ユーザーはすべて、posixAccount
属性を使用して作成されます。したがって、新しい Directory Server ユーザーにとって安全なキャッチオールです。ただし、ユーザーアカウントを Windows ドメインから Directory Server に同期すると、Windows ユーザーアカウントは posixAccount
属性 なし で作成されます。
ntUser
属性で識別されます。基本的な all-users グループルールは、特に目的の Windows ユーザーに変更できます。これは、デフォルトの all-users グループまたは Windows 固有のグループに追加できます。
dn: cn=Windows Users,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ntUser autoMemberDefaultGroup: cn=Windows Users,cn=groups,dc=example,dc=com autoMemberGroupingAttr: member:dn
例8.6 従業員タイプによるユーザーグループ
employeeType
属性で従業員タイプをもとにユーザーを作成してから参照できます。
configuration entry dn: cn=Employee groups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition cn: Hostgroups autoMemberScope: ou=employees,ou=people,dc=example,dc=com autoMemberFilter: objectclass=inetorgperson autoMemberDefaultGroup: cn=general,cn=employee groups,ou=groups,dc=example,dc=com autoMemberGroupingAttr: member:dn regex entry #1 dn: cn=full time,cn=Employee groups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: Group for full time employees cn: full time autoMemberTargetGroup: cn=full time,cn=employee groups,ou=groups,dc=example,dc=com autoMemberInclusiveRegex: employeeType=full regex entry #2 dn: cn=temporary,cn=Employee groups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule description: Group placement for interns, contractors, and seasonal employees cn: temporary autoMemberTargetGroup: cn=temporary,cn=employee groups,ou=groups,dc=example,dc=com autoMemberInclusiveRegex: employeeType=intern autoMemberInclusiveRegex: employeeType=contractor autoMemberInclusiveRegex: employeeType=seasonal
8.1.5.3. Automembership 定義の作成
- 必要に応じて、Auto Membership プラグインを有効にします。ldapmodify の使用:
dn: cn=Auto Membership Plugin,cn=plugins,cn=config changetype: replace replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
- cn=Auto Membership Plugin,cn=plugins,cn=config コンテナーエントリーの下に、新しいプラグインインスタンスを作成します。このエントリーは、autoMember Definition オブジェクトクラスに属している必要があります。ldapmodify の使用:
dn: cn=Example Automember Definition,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition ...
定義に必要な属性は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 に記載されています。 - 定義のスコープおよびフィルターを設定します。これは、一致するエントリーの初期検索に使用されます。たとえば、ou=People サブツリーに追加され、
ntUser
属性が含まれる新しいエントリーの場合:autoMemberScope: ou=People,dc=example,dc=com autoMemberFilter: objectclass=ntUser
- (デフォルトまたはフォールバックグループとして)一致するエントリーを追加するグループと、そのグループタイプのメンバーエントリーの形式を設定します。
autoMemberDefaultGroup: cn=windows-group,cn=groups,dc=example,dc=com autoMemberGroupingAttr: member:dn
- オプション。包含または排他的な正規表現フィルターを作成し、これらのフィルターに一致するエントリーに使用するグループを設定します。正規表現条件の属性は、表8.3「正規表現の条件属性」 に記載されています。正規表現の条件は、automember 定義の子として追加されます。これらの条件は autoMemberRegexRule オブジェクトクラスに属している必要があります。ldapmodify の使用:
dn: cn=Example Regex,cn=Example Automember Definition,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberRegexRule ...
次に、ターゲットグループ名と包含的または排他的な正規表現を追加します。include および exclude 条件の両方を使用でき、両方のタイプの式を複数使用できます。autoMemberTargetGroup: cn=windows-admin-group,cn=groups,dc=example,dc=com autoMemberInclusiveRegex: cn=\.* Administrator \*
新規エントリーが正規表現条件と一致する場合は、automember 定義に設定されたデフォルトグループ の代わりに、そのグループに追加されます。 - Directory Server が動的プラグインを有効にするために設定されていない場合は、サーバーを再起動して変更した新しいプラグインインスタンスを読み込みます。
8.1.5.4. 自動メンバー定義の既存のエントリーの更新
- 検索フィルター
- 検索範囲
- 検索を開始するベース DN
dn: cn=my rebuild task, cn=automember rebuild membership,cn=tasks,cn=config objectClass: top objectClass: extensibleObject cn: my rebuild task basedn: dc=example,dc=com filter: (uid=*) scope: sub
8.1.5.5. 自動メンバー定義のテスト
既存のエントリーを使用したテスト
cn=automember export updates が、ディレクトリー内の 既存のエントリー に対して実行し、ルールに基づいてユーザーの追加結果をエクスポートします。これは、既存のルールをテストして、実際のデプロイメントの実行方法を確認するのに役立ちます。
dn: cn=test export, cn=automember export updates,cn=tasks,cn=config objectClass: top objectClass: extensibleObject cn: test export basedn: dc=example,dc=com filter: (uid=*) scope: sub ldif: /tmp/automember-updates.ldif
Import LDIF でのテスト
cn=automember map updates タスクは、新規ユーザーの インポート LDIF を取得してから、現在の自動メンバールールに対して新規ユーザーを実行します。これは、(実際の) 新規または既存のユーザーエントリーに適用する前に、新しいルールをテストする場合に非常に役立ちます。
dn: cn=test mapping, cn=automember map updates,cn=tasks,cn=config objectClass: top objectClass: extensibleObject cn: test mapping ldif_in: /tmp/entries.ldif ldif_out: /tmp/automember-updates.ldif
8.2. ロールの使用
8.2.1. ロールの概要
- 管理対象ロール には、メンバーの明示的な列挙リストがあります。
- フィルターされたロール には、LDAP フィルターで指定される各エントリーに含まれる属性に応じて、エントリーがロールに割り当てられます。フィルターに一致するエントリーはロールを持ちます。
- ネストされたロール は、他のロールが含まれるロールです。
nsRole
属性を検索してロールのメンバーシップを確認することができます。nsRole
属性は、エントリーが属するロールを識別する計算属性です。nsRole
属性はエントリー自体に保存されません。クライアントアプリケーションの観点からは、メンバーシップを確認する方法は統一されており、サーバー側で実行されます。
8.2.2. 管理ロールの作成
nsRoleDN
属性を追加して、管理ロールがエントリーに追加されます。
8.2.2.1. コンソールでの管理ロールの作成
- Directory Server コンソールで、Directory タブを選択します。
- 左側のナビゲーションペインでツリーを参照し、新規ロールの親エントリーを選択します。
- オブジェクト メニューに移動し 、 New > Role を選択します。または、エントリーを右クリックし、New > Role を選択します。
- 左側のペインで General をクリックします。Role Name フィールドに新規ロールの名前を入力します。ロール名が必要です。
- Description フィールドに、新規ロールの説明を入力します。
- 左側のペインで Members をクリックします。
- 右側のペインで、Managed Role を選択します。をクリックして、新しいエントリーをメンバーの一覧に追加します。
- Search ドロップダウンリストで、Search ドロップダウンリストから Users を選択します 。返されたエントリーのいずれかを選択し、 をクリックします。
- エントリーを追加したら、をクリックします。
8.2.2.2. コマンドラインでの管理ロールの作成
- nsSimpleRoleDefinition
- nsManagedRoleDefinition
description
属性も許可されます。
nsRoleDN
属性を持ちます。
-a
オプションで ldapmodify を使用して、管理ロールエントリーを追加します。新しいエントリーには、nsManagedRoleDefinition オブジェクトクラスが含まれ、その後に LdapSubEntry、nsRoleDefinition、および nsSimpleRoleDefinition のオブジェクトクラスを継承します。dn: cn=Marketing,ou=people,dc=example,dc=com objectclass: top objectclass: LdapSubEntry objectclass: nsRoleDefinition objectclass: nsSimpleRoleDefinition objectclass: nsManagedRoleDefinition cn: Marketing description: managed role for marketing staff
- ldapmodify を使用して、ロールをマーケティングスタッフメンバーに 1 つずつ割り当てます。
dn: cn=Bob,ou=people,dc=example,dc=com changetype: modify add: nsRoleDN nsRoleDN: cn=Marketing,ou=people,dc=example,dc=com
エントリーのnsRoleDN
属性は、エントリーが管理ロール cn=Marketing,ou=people,dc=example,dc=com のメンバーであることを示します。
8.2.3. フィルター設定されたロールの作成
8.2.3.1. コンソールでのフィルターロールの作成
- Directory Server コンソールで、Directory タブを選択します。
- 左側のナビゲーションペインでツリーを参照し、新規ロールの親エントリーを選択します。
- オブジェクト メニューに移動し 、 New > Role を選択します。または、エントリーを右クリックし、New > Role を選択します。
- 左側のペインで General をクリックします。Role Name フィールドに新規ロールの名前を入力します。ロール名が必要です。
- Description フィールドに、新規ロールの説明を入力します。
- 左側のペインで Members をクリックします。検索ダイアログボックスが簡単に表示されます。
- 右側のペインで、Filtered Role を選択します。
- テキストフィールドに LDAP フィルターを入力するか、または LDAP フィルターを介して、Construct to be struct をクリックします。LDAP Server Host、Port、Base DN、および Search のフィールドを無視します(検索スコープはフィルターされたロール定義を設定できません)。は標準の LDAP URL 構成ダイアログを開きます。
- For ドロップダウンリストから、フィルターするエントリーの種類 を選択します。エントリーは、ユーザー、グループ、またはその両方になります。
- Where ドロップダウンリストから属性を選択します。2 つのフィールドに続く 2 つのフィールドは、ドロップダウンリストから修飾子(include)、not、 または not のいずれかを選択して検索を改良して検索を改良します 。テキストボックスに属性値を入力します。その他のフィルターを追加するには、 をクリックします。不要なフィルターを削除するには、F をクリックします。
8.2.3.2. コマンドラインでフィルターされたロールの作成
- nsComplexRoleDefinition
- nsFilteredRoleDefinition
nsRoleFilter
属性も必要です。任意で、ロールは description
属性を取ることができます。
nsRoleFilter
属性で指定されたフィルタに一致するエントリーです。
-a
オプションを指定して ldapmodify を実行して、新規エントリーを追加します。- フィルターされたロールエントリーを作成します。ロールエントリーには nsFilteredRoleDefinition オブジェクトクラスがあり、これは、オブジェクトクラス LdapSubEntry、nsRoleDefinition、および nsComplexRoleDefinition から継承されます。nsRoleFilter 属性は、sales managers の値が含まれる
o
(組織) 属性にフィルターを設定します。dn: cn=SalesManagerFilter,ou=people,dc=example,dc=com changetype: add objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: SalesManagerFilter nsRoleFilter: o=sales managers Description: filtered role for sales managers
o
属性) と一致するため、このフィルターが自動的に設定されたロールのメンバーになります)。
dn: cn=Pat Smith,ou=people,dc=example,dc=com objectclass: person cn: Pat sn: Smith userPassword: secret o: sales managers
8.2.4. ネスト化されたロールの作成
nsRoleDN
属性を使用して指定します。
8.2.4.1. コンソールでのネスト化されたロールの作成
- Directory Server コンソールで、Directory タブを選択します。
- 左側のナビゲーションペインでツリーを参照し、新規ロールの親エントリーを選択します。
- オブジェクト メニューに移動し 、 New > Role を選択します。または、エントリーを右クリックし、New > Role を選択します。
- 左側のペインで General をクリックします。Role Name フィールドに新規ロールの名前を入力します。ロール名が必要です。
- 左側のペインで Members をクリックします。
- 右側のペインで、Nested Role を選択します。
- Available roles リストからロールを選択し、 をクリックします。
8.2.4.2. コマンドラインでのネスト化されたロールの作成
- nsComplexRoleDefinition
- nsNestedRoleDefinition
nsRoleDN
属性も必要です。任意で、ロールは description
属性を取ることができます。
nsRoleDN
属性で指定されたロールのメンバーです。
-a
オプションを指定して ldapmodify を実行して、新規エントリーを追加します。- ネストされたロールエントリーを作成します。ネストされたロールには 4 つのオブジェクトクラスがあります。
- nsNestedRoleDefinition
- LDAPsubentry (継承)
- nsRoleDefinition (継承)
- nsComplexRoleDefinition (継承)
nsRoleDN
属性には、マーケティング管理ロールと営業マネージャーのフィルターが設定されたロールの両方の DN が含まれます。dn: cn=MarketingSales,ou=people,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsNestedRoleDefinition cn: MarketingSales nsRoleDN: cn=SalesManagerFilter,ou=people,dc=example,dc=com nsRoleDN: cn=Marketing,ou=people,dc=example,dc=com
8.2.5. エントリーへのロールの編集と割り当て
- Directory タブを選択します。
- 左側のナビゲーションペインでツリーを参照し、ロールを表示または編集するエントリーを選択します。
- Object メニューから Set Roles を選択します。
- Managed Roles タブを選択して、このエントリーが属する管理ロールを表示します。
- 新しい管理ロールを追加するには、Role Selector ウィンドウから利用可能なロールを選択します。をクリックし、注記エントリーに関連付けられている管理ロールの設定は、Edit Entry ダイアログボックスが開き、ロールの一般的な情報またはメンバーを変更できます。ボタンをクリックして編集できます。
- Other Roles タブを選択して、このエントリーが属するフィルターされたロールまたはネストされたロールを表示します。
8.2.6. コマンドラインでエントリーのロールの表示
+
を使用して結果オブジェクトの運用上の属性をすべて出力することができます。たとえば、この ldapsearch コマンドは、エントリーの通常の属性に加えて uid=scarter がメンバーであるロールのリストを返します。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(uid=scarter)"\* nsRole
dn: uid=scarter,ou=people,dc=example,dc=com objectClass: inetorgperson objectClass: top objectClass: person objectClass: organizationalPerson uid: scarter cn: Sam Carter sn: Carter givenName: Sam mail: scarter@example.com userPassword: {SSHA}6BE31mhTfcYyIQF60kWlnEL8sIvPZ59hvFTRKw== manager: uid=lbrown,ou=people,dc=example,dc=comnsRole: cn=Role for Managers,dc=example,dc=com
nsRole: cn=Role for Accounting,dc=example,dc=com
nsRole
属性ではなく、nsRoleDN
属性を使用するようにしてください。
8.2.7. ロールのアクティブまたはアクティブ作成
nsAccountLock
属性が true に設定されます。
- Directory タブを選択します。
- 左側のペインでナビゲーションツリーを参照し、ロールのベース DN を見つけます。ロールは、他のエントリーを含む右側のペインに表示されます。
- ロールをダブルクリックして、Account タブを開き、Inactivate ボタンをクリックします。または、ロールを選択します。ロールを右クリックし、メニューから Inactivate を選択します。
8.2.8. エントリーのアクティベーションステータスの表示
nsAccountLock
が true に設定されます。何層にもなったネスティングロールが可能です。ネスティング内のどのネスティングされたロールを非アクティブにしても、その下にあるすべてのロールとユーザーが非アクティブになります。
nsAccountLock
属性は操作属性で、検索属性のリストの検索コマンドで明示的に要求するか、すべての操作属性を要求するために +
を指定する必要があります。以下に例を示します。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(uid=scarter)" nsAccountLock
8.2.9. ロールの削除の概要
nsRoleDN
属性は削除されません。各ロールメンバーの nsRoleDN
属性を削除するには、Referential Integrity プラグインを有効にし、nsRoleDN
属性を管理するように設定します。Referential Integrity プラグインの詳細は、「5章参照整合性の維持」を参照してください。
8.2.10. セキュアなロールの使用
nsAccountLock
属性はそのユーザーの true として計算されるため、ユーザー A はサーバーにバインドできないことを意味します。ただし、ユーザー A がすでに Directory Server にバインドされ、MR ロールでロックされたことに気付くと、ユーザーは自分のエントリーから nsRoleDN
属性を削除して、自身を妨げる ACI がない場合は自身のロックを解除します。
nsRoleDN
属性を削除しないようにするには、使用されているロールのタイプに応じて以下の ACI を使用します。
- 管理対象ロール。管理ロールのメンバーであるエントリーの場合は、以下の ACI を使用して適切な
nsRoleDN
を削除して、ユーザーが自身をロック解除しないようにします。aci: (targetattr="nsRoleDN") (targattrfilters= add=nsRoleDN:(!(nsRoleDN=cn=AdministratorRole,dc=example,dc=com)), del=nsRoleDN:(!(nsRoleDN=cn=nsManagedDisabledRole,dc=example,dc=com))) (version3.0;acl "allow mod of nsRoleDN by self but not to critical values"; allow(write) userdn=ldap:///self;)
- フィルターが設定されたロール。フィルターに含まれる属性は保護されるべきです。これにより、ユーザーは属性を変更してフィルターされたロールを再取得できません。ユーザーは、フィルター処理されたロールによって使用される属性を追加、削除、または変更することを許可されるべきではありません。フィルター属性の値が計算された場合、フィルター属性の値を変更できるすべての属性を同じ方法で保護する必要があります。
- ネストされたロール。ネストされたロールはフィルターされたロールと管理対象のロールで構成されているため、両方の ACI はネストされたロールを構成するロールの属性 (
nsRoleDN
またはその他) の変更について考慮する必要があります。
8.3. デュアルエントリーの自動作成
8.3.1. 管理対象エントリー
- プラグインインスタンスおよび使用するテンプレートの範囲を特定する定義エントリー
- 最終的な管理エントリーをモデル化するテンプレートエントリー
8.3.1.1. インスタンス定義エントリーの概要
- (検索範囲と検索フィルターを使用する) 作成元のエントリーを識別する検索基準
- 管理エントリーを作成するサブツリー (新しいエントリーの場所)
- 管理エントリーに使用するテンプレートエントリー
図8.2 管理エントリーの定義
dn: cn=Posix User-Group,cn=Managed Entries,cn=plugins,cn=config objectclass: extensibleObject cn: Posix User-Group originScope: ou=people,dc=example,dc=com originFilter: objectclass=posixAccount managedBase: ou=groups,dc=example,dc=com managedTemplate: cn=Posix User-Group Template,ou=Templates,dc=example,dc=com
8.3.1.2. テンプレートエントリーの概要
図8.3 テンプレート、管理対象エントリー、およびアーティファクトエントリー
dn: cn=Posix User-Group Template,ou=Templates,dc=example,dc=com objectclass: mepTemplateEntry cn: Posix User-Group Template mepRDNAttr: cn mepStaticAttr: objectclass: posixGroup mepMappedAttr: cn: $cn Group Entry mepMappedAttr: gidNumber: $gidNumber mepMappedAttr: memberUid: $uid
8.3.1.3. 管理エントリープラグインにより書き込まれるエントリー属性
dn: uid=jsmith,ou=people,dc=example,dc=com objectclass: mepOriginEntry objectclass: posixAccount ... sn: Smith mail: jsmith@example.com mepManagedEntry: cn=jsmith Posix Group,ou=groups,dc=example,dc=com
dn: cn=jsmith Posix Group,ou=groups,dc=example,dc=com objectclass: mepManagedEntry objectclass: posixGroup ... mepManagedBy: uid=jsmith,ou=people,dc=example,dc=com
8.3.1.4. 管理エントリープラグインおよび Directory Server 操作
演算子 | 管理対象エントリープラグインによる効果 |
---|---|
Add | すべての追加操作では、サーバーは新しいエントリーが管理エントリープラグインインスタンスの範囲内にあるかどうかを確認します。作成元エントリーの基準を満たすと、管理エントリーが作成され、管理エントリー関連の属性が元のエントリーと管理エントリーの両方に追加されます。 |
Modify |
作成元のエントリーが変更すると、管理エントリーを更新するプラグインが誘発されます。ただし、テンプレート エントリーを変更しても、自動的に管理エントリーを更新しません。テンプレートエントリーへの変更は、次に作成元エントリーが変更するまで、管理エントリーに反映されません。
管理エントリー 内 でマップされた管理属性は、管理エントリープラグインでのみ手動で変更することができません。管理対象エントリーの他の属性 (管理エントリープラグインで追加された静的属性を含む) は手動で変更できます。
|
Delete | 作成元のエントリーが削除されると、管理エントリープラグインもそのエントリーに関連付けられた管理エントリーを削除します。削除できるエントリーにはいくつかの制限があります。
|
Rename | 元のエントリーの名前を変更した場合は、プラグインは対応する管理エントリーを更新します。エントリーがプラグインスコープの 外 に移動すると、管理エントリーが削除されますが、エントリーがプラグインスコープの 中 に移動した場合は、追加操作のように処理され、新しい管理エントリーが作成されます。削除操作と同様に、名前変更または移動できるエントリーに制限があります。
|
レプリケーション | 管理エントリープラグイン操作は レプリケーションの更新によって開始しません。プラグインスコープのエントリーの追加または修正操作が別のレプリカに複製される場合、その操作はレプリカで管理エントリープラグインインスタンスを発生させず、エントリーを作成または更新しません。管理エントリーの更新を複製する唯一の方法は、最終管理エントリーをレプリカに複製することです。 |
8.3.2. 管理対象エントリーテンプレートエントリーの作成
mepStaticAttr: attribute: specific_value mepMappedAttr: attribute: $token_value
mepMappedAttr: cn: Managed Group for $cn
- マップされた値は、トークン (動的な値) と静的な値の組み合わせを使用しますが、マップされた属性ごとに 1 つのトークン しか使用できません。
- テンプレートのマップされた属性は、先頭にドル記号 ($) を追加して作成元のエントリーから値をプルして管理エントリーで使用するトークンを使用します。ドル記号が管理属性値で実際に定義されている場合は、ドル記号を 2 つ使用してドル記号をエスケープできます。
- マッピングされた属性の定義は、Attr: ${cn}test など、中括弧で囲んで引用することができます。トークン名の直後にスペースやコンマなど属性名として有効な文字が使用される場合は、トークンの値を引用符で囲む必要はありません。たとえば、$cn test は属性名の直後に続くため、属性定義では使用できますが、管理エントリープラグインは作成元のエントリーで cntest という名前の属性を検索しようとするため、$cntest は有効ではありません。中括弧を使用すると、属性トークン名を識別します。
- 静的属性およびマップされた属性に値が必要な属性の構文に準拠するようにしてください。
gidNumber
の場合、マップされた値は整数にする必要があります。
属性 | 説明 |
---|---|
mepTemplateEntry (オブジェクトクラス) | テンプレートとしてエントリーを識別します。 |
cn | エントリーの共通名を指定します。 |
mepMappedAttr | プラグインは、元のエントリーから取得した値で管理エントリーの属性を作成するために使用する属性とトークンのペアが含まれます。 |
mepRDNAttr | 管理エントリーで naming 属性として使用する属性を指定します。RDN として使用される属性は、設定のためにマップされた属性である 必要があります。 |
mepStaticAttr | 管理エントリーに指定された値とともに使用される属性と値のペアが含まれます。 |
- ldapmodify を実行してエントリーを追加します。このエントリーは、ディレクトリーツリーの任意の場所に置くことができます。
dn: cn=Posix User Template,ou=templates,dc=example,dc=com cn: Posix User Template ...
「ディレクトリーエントリーの作成」 で説明されているように、Directory Server コンソールを使用して、エントリーを作成することもできます。 - mepTemplateEntry オブジェクトクラスに、これがテンプレートエントリーであることを示します。
objectClass: top objectclass: mepTemplateEntry ...
- エントリーの属性を設定します。これらは、表8.5「管理エントリーテンプレートの属性」 で説明されています。RDN 属性(
mepRDNAttr
)が必要です。属性パラメーターは任意で、値はプラグインが作成するエントリーのタイプによって異なります。naming 属性に使用する属性がマップされた属性としてテンプレートエントリーに含まれていることを確認してください。注記エントリーのオブジェクトクラスと同様に、各管理エントリーに対して同じ属性。値を手動で設定する必要があります。mepStaticAttr
mepRDNAttr: cn mepStaticAttr: objectclass: posixGroup mepMappedAttr: cn: $cn Group Entry mepMappedAttr: gidNumber: $gidNumber mepMappedAttr: memberUid: $uid
8.3.3. 管理対象エントリーインスタンス定義の作成
属性名 | 説明 |
---|---|
originFilter | 検索に使用する検索フィルターで、管理エントリーを必要とするサブツリーのエントリーを特定します。構文は、通常の検索フィルターと同じです。 |
originScope | 監視するプラグインの潜在的な元のエントリーを含むベースサブツリー。 |
managedTemplate | 管理エントリーの作成に使用するテンプレートエントリーを特定します。このエントリーは、ディレクトリーツリーの任意の場所に置くことができます。 |
managedBase | 管理エントリーを作成するサブツリー。 |
- ldapmodify を使用して、cn=Managed Entries,cn=plugins,cn=config コンテナーエントリーの下に新しいプラグインインスタンスを作成します。
dn: cn=instance,cn=Managed Entries,cn=plugins,cn=config ...
- 作成元のエントリー検索、新しい管理エントリーの場所、使用するテンプレートエントリーの場所を設定します。これらの必須属性は、表8.6「管理エントリー定義エントリーの属性」 に一覧表示されます。
objectClass: top objectClass: extensibleObject cn: Posix User-Group originScope: ou=people,dc=example,dc=com originFilter: objectclass=posixAccount managedBase: ou=groups,dc=example,dc=com managedTemplate: cn=Posix User-Group Template,ou=Templates,dc=example,dc=com
- Directory Server が動的プラグインを有効にするために設定されていない場合は、サーバーを再起動して変更した新しいプラグインインスタンスを読み込みます。
8.3.4. 複製されたデータベースへの管理エントリープラグイン設定の追加
nsslapd-pluginConfigArea
属性が許可されます。この属性は、プラグインインスタンスエントリーが含まれるメインのデータベースエリアにおける、別のコンテナーエントリーへの属性です。このコンテナーエントリーは、複製されたデータベースで使用することができます。これにより、プラグイン設定を複製できます。
- ldapmodify を使用して、レプリケートされるサブツリーにコンテナーエントリーを作成します。
dn: cn=managed entries container,ou=containers,dc=example,dc=com objectclass: top objectClass: extensibleObject objectClass: nsContainer cn: managed entries container
- ldapmodify を使用して、コンテナーエントリーを参照する管理エントリープラグインエントリーに
nsslapd-pluginConfigArea
属性を追加します。dn: cn=Managed Entries,cn=plugins,cn=config changetype: modify add: nsslapd-pluginConfigArea nsslapd-pluginConfigArea: cn=managed entries container,ou=containers,dc=example,dc=com
- 新規コンテナーエントリーの下にある定義 (「管理対象エントリーインスタンス定義の作成」) エントリーおよびテンプレート (「管理対象エントリーテンプレートエントリーの作成」) エントリーを移動または作成します。
8.4. ビューの使用
8.4.1. ビューの概要
nsview
) およびフィルター属性 (nsviewfilter
) が含まれており、このビューに属するエントリーのフィルターを設定します。ビューコンテナーエントリーを追加すると、ビューフィルターと一致するすべてのエントリーが即座にビューに入力されます。対象となるエントリーは、ビューの中に存在している ように見える だけで、実際の場所は変わりません。たとえば、ビューは ou=Location Views として作成され、フィルターが l=Mountain View 設定されます。cn=Jane Smith,l=Mountain View,ou=People,dc=example,dc=com どのすべてのエントリーは ou=Location Views エントリーで直ちに一覧表示されますが、実際の cn=Jane Smith ントリーは ou=People,dc=example,dc=com サブツリーに残ります。
図8.4 仮想 DIT ビュー階層を含むディレクトリーツリー
Example-views.ldif
を含む LDIF ファイルのサンプルがあります。このファイルは、Red Hat Enterprise Linux 7 の /usr/share/dirsrv/data/
ディレクトリーにあります。本章のセクションは、Example-views.ldif
がサーバーにインポートされることを前提としています。
8.4.2. コンソールでビューの作成
- Directory タブを選択します。
- 左側のナビゲーションツリーで、ビューを保持する組織単位の接尾辞を作成します。たとえば、ローカリティー(l)属性に基づいたビューの場合は、この組織単位 の場所ビューに名前を付けます。サブ接尾辞の作成については、「コンソールを使用した新しい従属接尾辞の作成」 を参照してください。
- ou=Location Views を右クリックし、New > Other の順に選択します。
- New Object メニューから nsview を選択し、 をクリックします。
- Property Editor ウィンドウで ボタンをクリックし、組織のユニットオブジェクトクラスを追加します。
- ビューを整理する方法は、組織ユニットに名前を付けます。たとえば、ou=Sunnyvale です。
ou
属性を naming 属性にします。 - nsviewfilter 属性を追加します。ボタンをクリックし、
- (l=Sunnyvale など) ビューを反映するフィルターを作成します。
- 右下のボタンをクリックして naming 属性を変更します。エントリーの
description
を、ou
ではなく naming 属性として使用します。
8.4.3. コマンドラインでのビューの作成
- ldapmodify ユーティリティーを使用してサーバーにバインドし、新しいビューエントリーを設定ファイルに追加する準備を行います。
Example-views.ldif
ファイルから、ビューコンテナーの ou=Location Views,dc=example,dc=com ファイルを、Directory Server にアサインします。この例では、root 接尾辞 dc=example,dc=com の下に新しい views コンテナーエントリーを追加します。このエントリーには、nsview ブジェクトクラスおよびnsViewFilter
属性が必要です。nsViewFilter
属性は、ビューに属するエントリーを識別する属性値を設定します。dn: ou=Mountain View,ou=Location Views,dc=example,dc=com changetype: add objectClass: top objectClass: organizationalUnit objectClass: nsview ou: Mountain View nsViewFilter: l=Mountain View description: views categorized by location
8.4.4. ビューのパフォーマンスの向上
nsViewFilter
属性で定義される属性です。フィルターの残りの部分はエントリー階層に基づいており、ビューに含まれる実際のエントリーの entryid
と parentid
を探します。
(|(parentid=search_base_id)(entryid=search_base_id)
entryid
、parentid
、または nsViewFilter
に設定された属性) のいずれかがインデックス化されない場合、views 操作は一致するエントリーのツリー全体を検索するため、ビューの検索はインデックスなしの検索になります。
entryid
、parentid
、および nsViewFilter
で設定した属性の等価インデックスを作成します。
第9章 セキュアな接続の設定
9.1. セキュアな接続の要求
- LDAPS
- LDAPS プロトコルを使用すると、接続は暗号化を使用して開始し、成功または失敗します。ただし、暗号化されていないデータがネットワーク経由で送信されることはありません。このため、暗号化されていない LDAP で StartTLS を使用する代わりに、LDAPS の使用が推奨されます。
- LDAP 上の STARTTLS
- クライアントは LDAP プロトコルで暗号化されていない接続を確立し、StartTLS コマンドを送信します。コマンドに成功すると、それ以降の通信はすべて暗号化されます。警告StartTLS コマンドが失敗し、クライアントが接続をキャンセルしないと、認証情報を含むすべてのデータが暗号化されずにネットワーク上に送信されます。
- SASL
- Simple Authentication and Security Layer (SASL) を使用すると、Kerberos などの外部認証方法を使用してユーザーを認証できます。詳細は「SASL Identity マッピングの設定」を参照してください。
9.2. 最小強度係数の設定
nsslapd-minssf
設定属性を設定します。最小 SSF を適用する場合、Directory Server は操作で使用可能な各暗号化タイプ (TLS または SASL) を調べ、どちらの SSF 値が高いかを判断し、高い値を最小 SSF と比較します。SASL 認証と TLS は、レプリケーションなどのサーバー間の接続に対して、SASL 認証と TLS の両方を設定できます。
nsslapd-minssf-exclude-rootdse
設定属性を使用します。これにより、ルート DSE に対するクエリーを 除き、Directory Server へのすべての接続の最小 SSF 設定が設定されます。クライアントは、操作を開始する前に、デフォルトの命名コンテキストなどのサーバー設定に関する情報を取得しないといけない場合があります。nsslapd-minssf-exclude-rootdse
属性を使用すると、クライアントは最初にセキュアな接続を確立しなくてもその情報を取得できます。
nsslapd-minssf
属性値は 0 です。これは、サーバー接続の最小 SSF がないことを意味します。値は、適切な正の整数に設定できます。値は、セキュアな接続に必要な鍵強度を表します。
nsslapd-minssf
属性を cn=config エントリーに追加します。
#
ldapmodify -D "cn=Directory Manager" -W -x
dn: cn=config changetype: modify replace: nsslapd-minssf nsslapd-minssf: 128
nsslapd-require-secure-binds
属性をオンにすることで、バインド操作にセキュアな接続が必要になる場合があります。
9.3. Directory Server が使用する NSS データベースの管理
9.3.1. Directory Server インスタンスの NSS データベースの作成
/etc/dirsrv/slapd-instance_name/
ディレクトリーに保存します。証明書を管理する前に、データベースを作成する必要があります。
9.3.1.1. コマンドラインを使用した NSS データベースの作成
- NSS データベースを作成し、パスワードを設定します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -N Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password:
- パーミッションを設定します。
# chown dirsrv:dirsrv /etc/dirsrv/slapd-instance_name/*.db # chown dirsrv:dirsrv /etc/dirsrv/slapd-instance_name/pkcs11.txt # chmod 600 /etc/dirsrv/slapd-instance_name/*.db # chmod 600 /etc/dirsrv/slapd-instance_name/pkcs11.txt
9.3.1.2. コンソールを使用した NSS データベースの作成
- Directory Server コンソールを開きます。
- Tasks タブで Manage Certificates をクリックし、データベースを保護するパスワードを設定します。
9.3.2. 証明書署名要求の作成
9.3.2.1. コマンドラインを使用した証明書署名要求の作成
certutil
ユーティリティーを使用します。
# certutil -d instance_directory -R -g key_size -a \ -o output_file -8 FQDN -s "certificate_subject"
例9.1 単一ホスト名の秘密鍵および CSR の作成
server.example.com
ホストの 4096 ビット秘密鍵を生成し、CSR を /root/instance_name.csr
ファイルに保存します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -R -g 4096 -a \ -o /root/instance_name.csr -8 server.example.com \ -s "CN=server.example.com,O=example_organization,OU=IT,ST=North Carolina,C=US"
-8 server.example.com
オプションは、DNS:server.example.com エントリーを持つサブジェクト代替名(SAN)の拡張を CSR に追加します。-s
パラメーターで指定した文字列は、RFC 1485 に従って有効なサブジェクト名である必要があります。CN
フィールドが必要で、サーバーの完全修飾ドメイン名(FQDN)に設定する必要があります。その他のフィールドは任意です。
例9.2 マルチホームホストの秘密鍵および CSR の作成
.example.com および server.
example.net
ホスト名の CSR を生成します。このコマンドは、CSR を /root/instance_name.csr
ファイルに保存します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -R -g 4096 -a \ -o /root/instance_name.csr -8 server.example.com,server.example.net \ -s "CN=server.example.com,O=example_organization,OU=IT,ST=North Carolina,C=US"
-8 server.example.com,server.example.net
オプションは、DNS:server.example.com、DNS:server.example.net エントリーで SAN 拡張を CSR に追加します。-s
パラメーターで指定した文字列は、RFC 1485 に従って有効なサブジェクト名である必要があります。CN
フィールドが必要で、サーバーの FQDN のいずれかに設定する必要があります。その他のフィールドは任意です。
certutil
および拡張使用方法の詳細は、certutil(1) の man ページを参照してください。
9.3.2.2. コンソールを使用した証明書署名要求の作成
- Directory Server コンソールを開きます。
- Tasks タブで、Manage Certificates をクリックします。
- Server Certs タブで、 ボタンをクリックします。
- 証明書を手動で要求するか、または表示される CA のいずれかから証明書を要求するかどうかを選択し、をクリックします。
- 要求された情報を入力し、をクリックします。重要Server name フィールドにサーバーの完全修飾ドメイン名(FQDN)を入力します。
- キーサイズおよび署名アルゴリズムを選択します。をクリックします。セキュリティー上の理由から、以下のようになります。
- RSA キーサイズが 2048 ビット以上のもの
- SHA-256 以降などの強力な署名アルゴリズム
- Network Security Services(NSS)データベースのパスワードを入力し、Done をクリックします。Hardware Security Module(HSM)を使用して証明書を保存する場合、デバイスは接続され、「ハードウェアセキュリティーモジュールの使用」 の説明どおりにモジュールがインストールされていると、モジュールは Active Encryption Token メニューで利用できます。
- CSR をクリップボードにコピーするか、またはファイルに保存します。
9.3.3. CA 証明書のインストール
コンソールオプション | certutil オプション | 詳細 |
---|---|---|
クライアントからの接続を許可(クライアント認証) | T,, | サーバーは、TLS EXTERNAL バインドに適したクライアント証明書を発行するためにこの CA 証明書を信頼します。 |
他のサーバーへの接続の許可(サーバー認証) | C,, | サーバーは、レプリケーションパートナーへの暗号化された接続を確立するために使用する証明書を検証し、信頼できる CA により発行されていることを確認します。 |
certutil
を使用する場合は、-T "CT,,"
パラメーターをユーティリティーに渡します。
9.3.3.1. コマンドラインを使用した CA 証明書のインストール
certutil
ユーティリティーを使用します。たとえば、/etc/pki/CA/nss/ca.crt
ファイルに保存されている CA 証明書をインポートするには、以下を実行します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -A -n "certificate_nickname" \ -t "C,," -i /etc/pki/CA/nss/ca.crt
-t trust_options
パラメーターは、CA が発行する証明書を信頼する証明書を設定します。表9.1「CA 信頼オプション」を参照してください。
9.3.3.2. コンソールを使用した CA 証明書のインストール
- Directory Server コンソールを開きます。
- Tasks タブで、Manage Certificates をクリックします。
- CA Certs タブを選択し、 ボタンをクリックします。
- サーバー証明書が含まれるファイルを選択するか、またはフィールドに証明書を貼り付けます。をクリックします。
- 証明書の詳細を確認し、をクリックします。
- 証明書のニックネームを確認し、をクリックします。
- CA が発行する証明書を信頼する証明書を設定します。オプションのいずれかまたは両方を選択できます。表9.1「CA 信頼オプション」を参照してください。
9.3.4. 証明書のインストール
9.3.4.1. コマンドラインを使用したサーバー証明書のインストール
certutil
ユーティリティーを使用します。以下に例を示します。
- CA 証明書をインストールします。「CA 証明書のインストール」を参照してください。
- 証明書をインポートします。たとえば、
/root/instance_name.crt
ファイルに保存されている証明書をインポートするには、次のコマンドを実行します。# certutil -d /etc/dirsrv/slapd-instance_name/ -A \ -n "server-cert" -t ",," -a -i /root/instance_name.crt
- 必要に応じて、証明書を確認します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -V -n "server-cert" -u V
9.3.4.2. コンソールを使用した証明書のインストール
- CA 証明書をインストールします。「CA 証明書のインストール」を参照してください。
- Directory Server コンソールを開きます。
- Tasks タブで、Manage Certificates をクリックします。
- サーバー証明書が含まれるファイルを選択するか、またはフィールドに証明書を貼り付けます。をクリックします。
- 証明書の詳細を確認し、をクリックします。
- 証明書のニックネームを設定し、をクリックします。注記Directory Server コンソールは、既存のニックネームと同じニックネームを使用する証明書のインストールには対応していません。この問題を回避するには、コマンドラインを使用して証明書をインストールします。「コマンドラインを使用したサーバー証明書のインストール」を参照してください。
- NSS データベースのパスワードを入力し、をクリックします。
9.3.5. 自己署名証明書の生成およびインストール
- Network Security Services(NSS)データベースがすでに初期化されているかどうかを確認します。
# certutil -d /etc/dirsrv/slapd-instance_name -L
コマンドが失敗した場合は、データベースを初期化します。詳細は、「Directory Server インスタンスの NSS データベースの作成」 を参照してください。 - ランダムなデータで関心のあるファイルを生成します。たとえば、サイズが 4096 ビットのあるファイルを生成するには、次のコマンドを実行します。
# openssl rand -out /tmp/noise.bin 4096
- 自己署名証明書を作成し、NSS データベースに追加します。
# certutil -S -x -d /etc/dirsrv/slapd-instance_name/ -z /tmp/noise.bin \ -n "server-cert" -s "CN=$HOSTNAME" -t "CT,C,C" -m $RANDOM \ --keyUsage digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
Red Hat Enterprise Linux は、$HOSTNAME
変数を自動的に完全修飾ドメイン名 (FQDN) に置換え、$RANDOM
を無作為に生成した番号に置き換えます。先のコマンドで使用したパラメーターの詳細は、certutil(1) の man ページを参照してください。 - 必要に応じて、生成された証明書が自己署名されていることを確認します。
# certutil -L -d /etc/dirsrv/slapd-instance_name/ -n "server-cert" | egrep "Issuer|Subject" Issuer: "CN=server.example.com" Subject: "CN=server.example.com"
このコマンドの出力には、証明書の発行者とサブジェクトの両方について Directory Server ホストの FQDN が表示されるはずです。
9.3.6. 証明書の更新
9.3.6.1. コマンドラインでの証明書の更新
- キーサイズ、ホスト名、サブジェクトなど、同じオプションで新しい証明書署名要求 (CSR) を作成します。CSR の作成に関する詳細は、「コマンドラインを使用した証明書署名要求の作成」を参照してください。
- CA から発行した証明書を取得したら、同じニックネームを使用してデータベースにインストールします。「コマンドラインを使用した CA 証明書のインストール」を参照してください。
9.3.6.2. コンソールを使用した証明書の更新
9.3.7. 証明書の削除
9.3.7.1. コマンドラインで証明書の削除
- 秘密鍵を削除します。「秘密鍵の削除」 を参照してください。
- 必要に応じて、データベースの証明書を表示します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Example CA CT,, server-cert u,u,u
- 証明書を削除します。たとえば、server-cert ニックネームで証明書を削除するには、次のコマンドを実行します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -D -n "server-cert"
9.3.7.2. コンソールを使用した証明書の削除
- Directory Server コンソールを開きます。
- Tasks タブで、Manage Certificates をクリックします。
- Server Certs タブで証明書を選択し、 ボタンをクリックします。
9.3.8. 秘密鍵の削除
9.3.8.1. コマンドラインでの秘密鍵の削除
- 削除する鍵に基づいてすべての証明書を削除します。「証明書の削除」を参照してください。
- 必要に応じて、データベースのキーを表示します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -K certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" Enter Password or Pin for "NSS Certificate DB": < 0> rsa 7a2fb6c269d83c4036eac7e4edb6aaf2ed08bc4a server-cert < 1> rsa 662b826aa3dd4ca7fd7e6883558cf3866c42f4e2 example-cert
- 秘密鍵を削除します。たとえば、example-cert ニックネームで秘密鍵を削除するには、次を実行します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -F -n "example-cert"
9.3.8.2. コンソールを使用した秘密鍵の削除
9.3.9. CA 信頼オプションの変更
9.3.9.1. コマンドラインを使用した CA 信頼オプションの変更
-t
パラメーターの新しいオプションを certutil
ユーティリティーに渡します。
example-CA
という名前の CA が発行するクライアント証明書のみを信頼するように設定するには、以下を実行します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -M -t "T,," -n "example-CA"
-t trust_options
パラメーターは、CA が発行する証明書を信頼する証明書を設定します。表9.1「CA 信頼オプション」を参照してください。
9.3.9.2. コンソールを使用した CA 信頼オプションの変更
- Directory Server コンソールを開きます。
- Tasks タブで、Manage Certificates をクリックします。
- CA Certs タブを選択します。
- 編集する CA を選択し、表9.1「CA 信頼オプション」を参照してください。ボタンをクリックし、CA が発行する証明書を信頼する証明書を設定します。オプションのいずれかまたは両方を選択できます。
9.3.10. NSS データベースのパスワードの変更
9.3.10.1. コマンドラインを使用した NSS データベースのパスワードの変更
# certutil -d /etc/dirsrv/slapd-instance_name -W Enter Password or Pin for "NSS Certificate DB": Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password: Password changed successfully.
9.3.10.2. コンソールを使用した NSS データベースのパスワードの変更
- Directory Server コンソールを開きます。
- Tasks タブで、Manage Certificates をクリックします。
- パスワードの変更 ボタンをクリックします。
- 現在のパスワードを入力し、をクリックします。
9.3.11. 証明書失効リストの追加
9.3.11.1. コマンドラインを使用した証明書失効リストの追加
certutil
を使用して CRL を追加するには、CA 証明書のインストール時に -4 URL_to_CRL_file
パラメーターをユーティリティーに渡します。
9.3.11.2. コンソールを使用した証明書失効リストの追加
- Directory Server コンソールを開きます。
- Tasks タブで、Manage Certificates をクリックします。
- Revoked Certs タブを選択し、 ボタンをクリックします。
- ファイルへのパスを入力し、リストの形式を選択してをクリックします。
9.4. TLS の有効化
- LDAPS プロトコル: TLS 暗号化は接続が確立された後に直接使用されます。
- LDAP プロトコルの STARTTLS コマンド: 接続は、クライアントが STARTTLS コマンドを送信するまで暗号化されません。
9.4.1. Directory Server での TLS の有効化
9.4.1.1. コマンドラインを使用した Directory Server での TLS の有効化
- Directory Server の NSS データベースがすでに存在しているかどうかを確認します。
# ls -1 /etc/dirsrv/slapd-instance_name/*.db
データベースが存在しない場合は作成します。「コマンドラインを使用した NSS データベースの作成」 を参照してください。 - 証明書を要求してインストールします。
- 認証局 (CA) が発行する証明書の場合:
- Certificate Signing Request (CSR) を生成します。「コマンドラインを使用した証明書署名要求の作成」を参照してください。
- CA 証明書をインポートします。「コマンドラインを使用した CA 証明書のインストール」を参照してください。
- CA が発行するサーバー証明書をインポートします。「コマンドラインを使用したサーバー証明書のインストール」を参照してください。
- 自己署名証明書は、「自己署名証明書の生成およびインストール」を参照してください。
- TLS を有効にし、LDAPS ポートを設定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config changetype: modify replace: nsslapd-securePort nsslapd-securePort: 636 - replace: nsslapd-security nsslapd-security: on
- NSS データベースのサーバー証明書のニックネームを表示します。
# certutil -L -d /etc/dirsrv/slapd-instance_name/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Example CA CT,, server-cert u,u,u
次の手順でニックネームが必要です。 - RSA 暗号ファミリーを有効にするには、NSS データベースセキュリティーデバイスおよびサーバー証明書のニックネームを設定し、次のエントリーをディレクトリーに追加します。
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=RSA,cn=encryption,cn=config cn: RSA objectClass: top objectClass: nsEncryptionModule nsSSLToken: internal (software) nsSSLPersonalitySSL: server-cert nsSSLActivation: on
注記デフォルトでは、NSS データベース内のセキュリティーデバイスの名前は internal (software) です。cn=RSA,cn=encryption,cn=config エントリーがすでに存在しているため、上記のコマンドが失敗する場合は、対応する属性を更新します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=RSA,cn=encryption,cn=config changetype: modify replace: nsSSLToken nsSSLToken: internal (software) - replace: nsSSLPersonalitySSL nsSSLPersonalitySSL: server-cert - replace: nsSSLActivation nsSSLActivation: on
- 必要に応じて、Directory Server がサポートする暗号化の一覧を更新します。詳細は「コマンドラインを使用した Directory Server が使用する暗号の表示および設定」を参照してください。
- 必要に応じて、証明書ベースの認証を有効にします。詳細は「証明書ベースのクライアント認証の使用」を参照してください。
- 必要に応じて、パスワードファイルを作成して、NSS データベースのパスワードを要求せずに Directory Server が起動するようにします。詳細は「Directory Server のパスワードファイルの作成」を参照してください。
- Directory Server インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
NSS データベースにパスワードを設定し、パスワードファイルを作成しないと、Directory Server は NSS データベースのパスワードを要求します。詳細は「パスワードファイルなしで Directory Server の起動」を参照してください。 - 必要に応じて、サーバーへの接続時に Directory Server Console が TLS を使用するようにします。「コマンドラインを使用したコンソールから Directory Server への接続に対する TLS の有効化」 を参照してください。
- 必要に応じて、Red Hat Identity Management Console が TLS を使用するように TLS を有効にします。「管理サーバーでの TLS の有効化」 を参照してください。
9.4.1.2. コンソールを使用した Directory Server での TLS の有効化
- CSR を作成します。「コンソールを使用した証明書署名要求の作成」 を参照してください。
- 認証局 (CA) 証明書をインポートします。「コンソールを使用した CA 証明書のインストール」 を参照してください。
- CA が発行するサーバー証明書をインポートします。「コンソールを使用した証明書のインストール」 を参照してください。
- Directory Server コンソールを開き、Configuration タブでホスト名を選択します。
- 右側のペインの Settings タブで LDAPS ポートを Encrypted port フィールドに入力し、 ボタンをクリックします。LDAPS のデフォルトポートは 636 です。注記LDAPS ポートは、ポート フィールドの 暗号化されていない接続に設定されたセットとは異なる必要があります。
- 右側のペインの Encryption タブで、以下を実行します。
- このサーバーの Enable SSL を選択します。
- Use this cipher family: RSA。 一覧からセキュリティーデバイスおよび証明書を選択します。
- 必要に応じて、「コンソールを使用した Directory Server が使用する暗号の表示および設定」 を参照してください。ボタンをクリックして、Directory Server がサポートする暗号化の一覧を更新します。詳細は、
- 必要に応じて、ユーザーが証明書を使用して認証できるようにします。詳細は「証明書ベースのクライアント認証の使用」を参照してください。重要TLS が Directory Server でのみ有効で、Directory Server コンソールではない場合は、Require client authentication を選択しないでください。
- アウトバウンド SSL 接続オプションに対して証明書の名前に対して Check host name を選択し、認証用にクライアントが提示する証明書のサブジェクト名の
cn
属性と一致することを確認します。重要Red Hat は、中間者攻撃(MITM)に対して発信 TLS 接続を保護するために、レプリケーション環境でこのオプションを有効にすることを推奨します。 - Use SSL in Console オプションが選択されていないことを確認します。警告この手順を終了する前に、Use SSL in Console オプションを有効にしないでください。設定を保存すると直ちに反映されるためです。これにより、コンソールがサーバーへの接続に失敗します。このオプションを誤って有効にし、コンソールがサーバーへの接続に失敗した場合には、コマンドラインを使用してオプションを無効にします。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=slapd-instance_name,cn=Red Hat Directory Server, cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot changetype: modify replace: nsServerSecurity nsServerSecurity: off
- 必要に応じて、パスワードファイルを作成して、NSS データベースのパスワードを要求せずに Directory Server が起動するようにします。詳細は「Directory Server のパスワードファイルの作成」を参照してください。
- Directory Server インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
NSS データベースにパスワードを設定し、パスワードファイルを作成しないと、Directory Server は NSS データベースのパスワードを要求します。詳細は「パスワードファイルなしで Directory Server の起動」を参照してください。 - 必要に応じて、サーバーへの接続時に Directory Server Console が TLS を使用するようにします。「コンソールを使用したコンソールから Directory Server への接続に対する TLS の有効化」 を参照してください。
- 必要に応じて、Red Hat Identity Management Console が TLS を使用するようにします。「管理サーバーでの TLS の有効化」 を参照してください。
9.4.1.3. 暗号化暗号の設定
9.4.1.3.1. コマンドラインを使用した Directory Server が使用する暗号の表示および設定
利用可能なすべての暗号の表示
# ldapsearch -xLLL -H ldap://server.example.com:389 -D "cn=Directory Manager" -W \ -b 'cn=encryption,cn=config' -s base nsSSLSupportedCiphers -o ldif-wrap=no dn: cn=encryption,cn=config nsSSLSupportedCiphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256::AES-GCM::AEAD::128 ... nsSSLSupportedCiphers: SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5::RC2::MD5::128
使用する暗号ディレクトリーサーバーの表示
nsSSLEnabledCiphers
の読み取り専用属性に保存されます。それらを表示するには、次のコマンドを実行します。
# ldapsearch -xLLL -H ldap://server.example.com:389 -D "cn=Directory Manager" -W \ -b 'cn=encryption,cn=config' -s base nsSSLEnabledCiphers -o ldif-wrap=no dn: cn=encryption,cn=config nsSSLEnabledCiphers: TLS_RSA_WITH_AES_256_CBC_SHA::AES::SHA1::256 nsSSLEnabledCiphers: TLS_RSA_WITH_AES_128_CBC_SHA::AES::SHA1::128 ...
# ldapsearch -xLLL -H ldap://server.example.com:389 -D "cn=Directory Manager" -W \ -b 'cn=encryption,cn=config' -s base nsSSL3Ciphers -o ldif-wrap=no dn: cn=encryption,cn=config nsSSL3Ciphers: -all,+tls_rsa_aes_128_sha,+tls_rsa_aes_256_sha,...
nsSSL3Ciphers
属性からの設定を使用して、実際に使用されている暗号の一覧を生成します。ただし、nsSSL3Ciphers
で弱い暗号化を有効にし、allowWeakCiphers
パラメーターをデフォルトの off に設定した場合、Directory Server は強力な暗号化のみを使用し、nsSSLSupportedCiphers
読み取り専用属性に表示します。
有効な暗号リストの更新
- 現在有効な暗号の一覧を表示します。「使用する暗号ディレクトリーサーバーの表示」を参照してください。
- 特定の暗号のみを有効にするには、
nsSSL3Ciphers
属性を更新します。たとえば、TLS_RSA_WITH_AES_128_GCM_SHA256
暗号のみを有効にするには、次のコマンドを実行します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=encryption,cn=config changetype: modify add: nsSSL3Ciphers nsSSL3Ciphers: -all,+TLS_RSA_WITH_AES_128_GCM_SHA256
- Directory Server インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
- 必要に応じて、有効な暗号の一覧を表示して、結果を確認します。「使用する暗号ディレクトリーサーバーの表示」を参照してください。
9.4.1.3.2. コンソールを使用した Directory Server が使用する暗号の表示および設定
- Directory Server コンソールを開きます。
- Configuration タブでサーバー名を選択します。
- 右側のペインで Encryption タブを選択し、 ボタンをクリックします。
- 必要に応じて、暗号の一覧を更新します。以下に例を示します。
- 暗号の一覧を更新した場合は、Directory Server インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
9.4.1.4. パスワードファイルなしで Directory Server の起動
- systemctl コマンドで ns-slapd Directory Server プロセスが起動すると、
systemd
はパスワードを求めるプロンプトを表示し、その入力内容を systemd-tty-ask-password-agent ユーティリティーに自動的に渡します。以下に例を示します。# systemctl start dirsrv Enter PIN for Internal (Software) Token:
- まれに、ns-slapd Directory Server プロセスが systemctl ユーティリティーにより開始されず、ターミナルから切り離されていると、wall コマンドを使用してすべての端末にメッセージを送信します。以下に例を示します。
Broadcast message from root@server (Fri 2017-01-01 06:00:00 CET): Password entry required for 'Enter PIN for Internal (Software) Token:' (PID 1234). Please enter password with the systemd-tty-ask-password-agent tool!
パスワードを入力するには、次を実行します。# systemd-tty-ask-password-agent Enter PIN for Internal (Software) Token:
9.4.1.5. Directory Server のパスワードファイルの作成
/etc/dirsrv/slapd-instance_name/pin.txt
ファイルに保存できます。これにより、このパスワードを要求せずに Directory Server が自動的に起動できます。
- 以下の内容で
/etc/dirsrv/slapd-instance_name/pin.txt
ファイルを作成します。- NSS ソフトウェア暗号モジュールを使用する場合は、以下になります。
Internal (Software) Token:password
- Hardware Security Module (HSM) を使用する場合:
name_of_the_token:password
- パーミッションを設定します。
# chown dirsrv:dirsrv /etc/dirsrv/slapd-instance_name/pin.txt # chmod 400 /etc/dirsrv/slapd-instance_name/pin.txt
9.4.1.6. 証明書の有効期限が切れた場合の Directory Server の動作の管理方法
nsslapd-validate-cert
属性を設定します。以下の値を設定できます。
- warn: Directory Server インスタンスが起動し、期限切れの証明書に関する警告を
/var/log/dirsrv/slapd-instance_name/error
ログファイルに記録します。これはデフォルト設定です。 - on: Directory Server は証明書を検証し、証明書の有効期限が切れると、インスタンスの起動に失敗します。
- off: Directory Server は証明書の有効期限を検証しません。インスタンスが起動し、警告は記録されません。
例9.3 証明書の有効期限が切れると Directory Server が起動しないようにする
nsslapd-validate-cert
属性を on に設定します。# ldapmodify -D "cn=Directory Manager" -W -p 636 -h server.example.com -x dn: cn=config changetype: modify replace: nsslapd-validate-cert nsslapd-validate-cert: on
- Directory Server インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
9.4.2. コンソールから Directory Server への接続に TLS を有効化
9.4.2.1. コマンドラインを使用したコンソールから Directory Server への接続に対する TLS の有効化
# ldapmodify -D "cn=Directory Manager" -W -p 636 -h server.example.com -x dn: cn=slapd-instance_name,cn=Red Hat Directory Server, cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot changetype: modify replace: nsServerSecurity nsServerSecurity: on
9.4.2.2. コンソールを使用したコンソールから Directory Server への接続に対する TLS の有効化
- Directory Server コンソールを開き、Configuration タブでホスト名を選択します。
- 右側のペインの Encryption タブで、以下を実行します。
- コンソールで SSL の使用 を選択します。
- Directory Server コンソールを再起動します。
9.4.3. 管理サーバーでの TLS の有効化
- Red Hat Identity Management コンソール アプリケーションへの接続時の HTTPS プロトコルの有効化
- Administration Server が、Directory Server への暗号化された接続 を使用してデータを o=NetscapeRoot エントリーに保存するように設定します。
- Red Hat Identity Management Console アプリケーションを有効にして、LDAPS プロトコルを使用して、ディレクトリーに保存されているユーザーおよびグループを管理します。
- 必要な証明書をインポートします。以下のいずれかの方法で選択します。
- Directory Server と同じ秘密鍵と証明書を使用するには、「管理サーバーの Directory Server プライベートキーおよび証明書の使用」 を参照してください。
- 管理サーバーに別の鍵と証明書を使用するには、以下を参照してください。重要Directory Server コンソールではなく、管理コンソールの Manage Certificates メニューの手順を実行します。
管理サーバーと Directory Server は、他の共有証明書を信頼するために、少なくとも 1 つの CA 証明書を共有する必要があります。 - 管理コンソールを開きます。
- Configuration タブで、左側のペインで Administration Server エントリーを選択します。
- 右側のペインで Encryption タブを選択して、Red Hat Identity Management Console の暗号化を有効にします。
- このサーバーの Enable SSL を選択します。
- Use this cipher family: RSA。 一覧からセキュリティーデバイスおよび証明書を選択します。
- 必要に応じて、ボタンをクリックして、Administration Server がサポートする暗号の一覧を更新します。
- 必要に応じて、証明書を使用してクライアント認証を有効にします。詳細は「証明書ベースのクライアント認証の使用」を参照してください。
- 右側のペインで Configuration DS タブを選択して、LDAP プロトコルを使用して Administration Server が o=NetscapeRoot エントリーにデータを格納するように設定します。
- o=NetscapeRoot エントリーを保存する Directory Server インスタンスの LDAPS ポートを設定します。デフォルトでは、LDAPS は 636 ポートを使用します。
- Secure Connection を選択します。
- 右側のペインで ユーザー DS タブを選択して、Red Hat Identity Management Console が暗号化された接続を使用してユーザーおよびグループを管理するように設定します。
- Set User Directory を選択し、フィールドに入力します。暗号化された接続では、Secure Connections オプションが選択され、LDAP Host および Port フィールドで指定されたポートポートは LDAPS をサポートする必要があります。
- 必要に応じて、コンソールから
~/.redhat-idm-console/Console. version.Login.preferences ファイルの接続の最小および最大の TLSバージョン
を設定します。以下に例を示します。sslVersionMin: TLS1.1 sslVersionMax: TLS1.2
- 必要に応じて、パスワードファイルを作成し、Network Security Services(NSS)データベースのパスワードを要求せずに管理サーバーが起動するようにします。詳細は、「管理サーバーのパスワードファイルの作成」 を参照してください。
- 管理サーバーを再起動します。
# systemctl restart dirsrv-admin
パスワードファイルを作成していない場合、システムは NSS データベースのパスワードを要求します。 - コンソールが証明書を信頼するように設定するには、「Directory Server コンソールが使用する証明書の管理」 を参照してください。
# redhat-idm-console -a https://server.example.com:9830
9.4.3.1. Directory Server コンソールが使用する証明書の管理
/etc/dirsrv/slapd-instance_name/
ディレクトリーの NSS セキュリティーデータベースに保存されます。Directory Server コンソール自体は、TLS 接続に証明書と鍵も使用します。これらの証明書は、ユーザーのホームディレクトリーにある別のデータベースに保存されます。Directory Server Console を使用して TLS 経由で Directory Server の複数のインスタンスに接続する場合は、すべての Directory Server インスタンスで証明書を発行したすべての CA を信頼する必要があります。
Linux でコンソールを使用する場合の CA 証明書のインポート
/root/ca.crt
ファイルに保存されている CA 証明書をデータベースに追加するには、以下を実行します。
# certutil -d ~/.redhat-idm-console/ -A -n "Example CA" -t CT,, -a -i /root/ca.crt
Windows でコンソールを使用する場合の CA 証明書のインポート
:\ca.crt
ファイルに保存されている CA 証明書をデータベースに追加するには、以下を実行します。
> cd C:\Program Files\Red Hat Identity Management Console\ > certutil.exe -d "C:\Documents and Settings\user_name\.389-console\" -A -n "Example CA" -t CT,, -a -i C:\ca.crt
9.4.4. Directory Server が使用する CA 証明書の Red Hat Enterprise Linux のトラストストアへの追加
例9.4 クライアントユーティリティーが CA 証明書を使用しない場合の接続エラー
# ldapsearch -H ldaps://server.example.com:636 -D "cn=Directory Manager" -W -b "dc=example,dc=com" -x Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
- Directory Server が使用する CA 証明書のローカルコピーがない場合は、以下を実行します。
- サーバーの NSS データベースの証明書を一覧表示します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Example CA C,, server-cert u,u,u
- NSS データベースの CA 証明書のニックネームを使用して、CA 証明書をエクスポートします。
# certutil -d /etc/dirsrv/slapd-instance_name/ -L -n "Example CA" -a > /tmp/ds-ca.crt
- CA 証明書を
/etc/pki/ca-trust/source/anchors/
ディレクトリーにコピーします。以下に例を示します。# cp /tmp/ds-ca.crt /etc/pki/ca-trust/source/anchors/
- CA 信頼データベースを再構築します。
# update-ca-trust
9.5. Directory Server で有効な暗号化プロトコルの表示
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x \ -s base -b 'cn=encryption,cn=config' sslVersionMin sslVersionMax dn: cn=encryption,cn=config sslVersionMin: TLS1.0 sslVersionMax: TLS1.2
sslVersionMin
パラメーターおよび sslVersionMax
パラメーターは、Directory Server が使用する暗号化プロトコルを制御します。デフォルトでは、プロトコルの TLS 1.0 以降のバージョンのみが有効になっています。
9.6. 暗号化プロトコルバージョンの設定
sslVersionMin
パラメーターおよび sslVersionMax
パラメーターを更新して、Directory Server が使用する暗号化プロトコルを設定します。
sslVersionMax
パラメーターでサポートされる最強の暗号化プロトコルバージョンを常に使用するには、このパラメーターを設定しないでください。「sslVersionMax
パラメーターにおける強固なプロトコルを自動的に使用」 を参照してください。
sslVersionMin
パラメーターおよびsslVersionMax
パラメーターを更新します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=encryption,cn=config changetype: modify replace: sslVersionMin sslVersionMin: TLS1.1 - replace: sslVersionMax sslVersionMax: TLS1.2
- Directory Server インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
9.6.1. sslVersionMax
パラメーターにおける強固なプロトコルを自動的に使用
sslVersionMax
パラメーターが設定されていない場合(デフォルト)、Directory Server は、このパラメーターに最も強力な暗号化プロトコルバージョンを使用します。これにより、更新後に常に最も強力なプロトコルバージョンを有効にできます。
sslVersionMax
が設定されていない場合の特定
sslVersionMax
が設定されていない場合でも、パラメーターが検索で返されます。パラメーターが設定されていないかどうかを特定するには、次のコマンドを実行します。
# grep sslVersionMax /etc/dirsrv/slapd-instance_name/dse.ldif
sslVersionMax
パラメーターの削除
sslVersionMax
パラメーターを削除して、デフォルトの設定を使用します。
sslVersionMax
パラメーターを削除します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=encryption,cn=config changetype: modify delete: sslVersionMax
- Directory Server インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
9.7. ハードウェアセキュリティーモジュールの使用
key3.db
および cert8.db
を使用して、サーバーが使用する鍵と証明書を保存します。
9.8. 証明書ベースのクライアント認証の使用
userCertificate
属性に保存されている Distinguished Encoding Rules(DER)形式の証明書と一致するように設定できます。
- 効率が改善されました。証明書データベースのパスワードに一度要求されたアプリケーションを使用し、その証明書を後続のバインドまたは認証操作に使用すると、バインド DN およびパスワードを継続的に提供するよりも効率的です。
- セキュリティーが改善されました。証明書ベースの認証は、証明書ベースの認証では公開鍵の暗号化が使用されるため、証明書以外のバインド操作よりも安全です。バインド認証情報はネットワーク全体で傍受することはできません。証明書やデバイスが失われた場合は、PIN なしで使用しないため、フィッシング攻撃などのサードパーティーの干渉の影響を受けません。
9.8.1. 証明書ベースの認証の設定
- 暗号化された接続を有効にします。詳細は「TLS の有効化」を参照してください。
- CA 証明書をインストールし、クライアントとサーバーの接続の信頼オプションを設定します。「CA 証明書のインストール」を参照してください。
- 必要に応じて、クライアントおよびサーバーの CT,, 信頼オプションが CA 証明書に設定されていることを確認します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Example CA CT,,
/etc/dirsrv/slapd-instance_name/certmap.conf
ファイルを作成し、証明書から Directory Server ユーザーへ情報をマッピングします。以下に例を示します。certmap default default default:DNComps dc default:FilterComps mail,cn default:VerifyCert on certmap example o=Example Inc.,c=US example:DNComps
これは、この発行者にはDNComps
パラメーターが空に設定されているため、o=Example Inc.,c=US 発行者識別名 (DN) セットを持つ証明書を使用するユーザーを認証するため、Directory Server が証明書のサブジェクトからベース DN を生成しないように設定されています。また、FilterComps
およびVerifyCert
の設定も、デフォルトのエントリーから継承されます。指定の証明書とは異なる発行者 DN を持つ証明書は default エントリーの設定を使用し、証明書のサブジェクトのcn
属性に基づいてベース DN を生成します。これにより、ディレクトリー全体を検索せずに、Directory Server が特定の DN で検索を開始できます。すべての証明書について、Directory Server は、証明書のサブジェクトのmail
属性およびcn
属性を使用して検索フィルターを生成します。ただし、mail
がサブジェクトに存在しない場合は、Directory Server はサブジェクトで証明書のe
属性の値を自動的に使用します。利用可能なパラメーターの詳細と説明は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンス のcertmap.conf
ファイルの説明を参照してください』。- クライアント認証を有効にします。たとえば、クライアント認証を任意に設定するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -Z dn: cn=encryption,cn=config changetype: modify replace: nsSSLClientAuth nsSSLClientAuth: allowed
または、nsSSLClientAuth
パラメーターを required に設定して、クライアントが認証に使用する必要のある証明書を設定します。重要Directory Server コンソールは、クライアント認証に対応していません。nsSSLClientAuth
を required に設定すると、コンソールを使用してインスタンスを管理することはできません。 /etc/dirsrv/slapd-instance_name/certmap.conf
ファイルで alias_name:VerifyCert on を設定して、認証証明書がユーザーのuserCertificate
属性に保存されている証明書と一致する必要がある場合は、その証明書をユーザーエントリーに追加します。「ユーザーへの証明書の追加」を参照してください。
9.8.2. ユーザーへの証明書の追加
userCertificate
バイナリー属性に保存されている証明書と一致する必要があるように設定できます。/etc/dirsrv/slapd-instance_name/certmap.conf
ファイルに alias_name:VerifyCert on を設定してこの機能を有効にした場合は、影響を受けるユーザーの証明書をディレクトリーエントリーに追加する必要があります。
userCertificate
属性の識別名エンコーディングルール (DER) 形式で保存する必要があります。
userCertificate
属性に証明書を保存するには、以下を行います。
- 証明書が DER 形式ではない場合は、これを変換します。以下に例を示します。
# openssl x509 -in /root/certificate.pem -out /root/certificate.der -outform DER
- 証明書をユーザーの
userCertificate
属性に追加します。以下に例を示します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=user_name,ou=People,dc=example,dc=com changetype: modify add: userCertificate userCertificate: < /root/example.der
9.8.3. バインドリクエストの EXTERNAL SASL メカニズムの強制
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config changetype: modify replace: nsslapd-force-sasl-external nsslapd-force-sasl-external: on
9.8.4. 証明書を使用した認証
- CA 証明書、ユーザーキー、およびユーザー証明書の対応するパスに、以下の環境変数を設定します。以下に例を示します。
LDAPTLS_CACERT=/home/user_name/CA.crt LDAPTLS_KEY=/home/user_name/user.key LDAPTLS_CERT=/home/user_name/user.crt
あるいは、~/.ldaprc
ファイルにTLS_CACERT
パラメーター、TLS_KEY
パラメーター、およびTLS_CERT
パラメーターを設定します。詳細は、ldap.conf(5) の man ページの 『TLS OPTIONS』 セクションを参照してください。 - サーバーに接続します。以下に例を示します。
# ldapwhoami -H ldaps://server.example.com:636
9.9. SASL Identity マッピングの設定
9.9.1. SASL Identity マッピングの概要
dn: cn=sasl,cn=config objectClass: top objectClass: nsContainer cn: sasl
dn: cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsContainer cn: mapping
nsSaslMapRegexString
: 指定したauthid
の要素をマップするために使用される正規表現。nsSaslMapFilterTemplate
: DN を作成するnsSaslMapRegexString
の要素を適用するテンプレート。nsSaslMapBaseDNTemplate
: 構築した DN と照合する検索ベースまたは特定のエントリー DN を指定します。- オプション:
nsSaslMapPriority
: この SASL マッピングの優先度を設定します。nsslapd-sasl-mapping-fallback
がcn=config
で有効になっている場合は、優先度値が使用されます。詳細は「SASL マッピングの優先度の設定」を参照してください。
dn: cn=mymap,cn=mapping,cn=sasl,cn=config objectclass:top objectclass:nsSaslMapping cn: mymap nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) nsSaslMapFilterTemplate: (objectclass=inetOrgPerson) nsSaslMapBaseDNTemplate: uid=\1,ou=people,dc=\2,dc=\3
nsSaslMapRegexString
属性は、検索中にテンプレート属性に埋め込まれたバインド ID に対し、\1、\2、\3 形式の変数を設定します。この例では、inetOrgPerson オブジェクトクラスに属する ou=People,dc=example,dc=com サブツリーに含まれるユーザーに対して SASL アイデンティティーマッピングを設定します。
authid
) として使用する SASL バインド要求を受け取ると、正規表現は uid=mconnors,ou=people,dc=EXAMPLE,dc=COM をユーザー ID として使用するベース DN テンプレートに入力し、認証がそこから続行します。
dn: cn=example map,cn=mapping,cn=sasl,cn=config objectclass: top objectclass: nsSaslMapping cn: example map nsSaslMapRegexString: \(.*\) nsSaslMapBaseDNTemplate: ou=People,dc=example,dc=com nsSaslMapFilterTemplate: (cn=\1)
nsSaslMapRegexString
属性にレルムを指定すると、マッピングを 1 つのレルムに制限することができます。以下に例を示します。
dn: cn=example map,cn=mapping,cn=sasl,cn=config
objectclass: top
objectclass: nsSaslMapping
cn: example map
nsSaslMapRegexString: \(.*\)@US.EXAMPLE.COM
nsSaslMapBaseDNTemplate: ou=People,dc=example,dc=com
nsSaslMapFilterTemplate: (cn=\1)
dn: cn=z,cn=mapping,cn=sasl,cn=config objectclass: top objectclass: nsSaslMapping cn: z nsSaslMapRegexString: ldap/ldap1.example.com@EXAMPLE.COM nsSaslMapBaseDNTemplate: cn=replication manager,cn=config nsSaslMapFilterTemplate: (objectclass=*)
dn: cn=y,cn=mapping,cn=sasl,cn=config objectclass: top objectclass: nsSaslMapping cn: y nsSaslMapRegexString: ldap/ldap1.example.com nsSaslMapBaseDNTemplate: cn=replication manager,cn=config nsSaslMapFilterTemplate: (objectclass=*)
nsSaslMapPriority
パラメーターを使用して SASL マッピングに優先度が設定されていない場合は、マッピングが処理される順序を指定する方法はありません。ただし、SASL マッピングの処理方法 (名前) を制御する方法もあります。Directory Server は、ASCII の逆順で SASL マッピングを処理します。過去 2 つの例では、cn=z マッピング (最初の例) が最初に処理されます。一致する場合、サーバーは cn=y マッピングを処理します (2 番目の例)。
9.9.2. Directory Server のデフォルトの SASL マッピング
Kerberos UID マッピング
これは、user@example.com などの 2 部分レルムを使用して Kerberos プリンシパルと一致します。レルムは、検索ベースの定義に使用され、ユーザー ID (authid
) はフィルターを定義します。検索ベースは dc=example,dc=com と (uid=user) のフィルターです。
dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: Kerberos uid mapping nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\) nsSaslMapBaseDNTemplate: dc=\2,dc=\3 nsSaslMapFilterTemplate: (uid=\1)
RFC 2829 DN 構文
このマッピングは、dn: で始まる有効な DN (RFC 2829 で定義) である authid
と一致します。authid
は、指定された DN に直接マッピングします。
dn: cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: rfc 2829 dn syntax nsSaslMapRegexString: ^dn:\(.*\) nsSaslMapBaseDNTemplate: \1 nsSaslMapFilterTemplate: (objectclass=*)
RFC 2829 U 構文
このマッピングは、u: の接頭辞が付いた UID の authid
と一致します。プレフィックスの後に指定された値は (uid=value) のフィルターを定義します。検索ベースは、デフォルトの userRoot データベースの接尾辞になるようにハードコーディングされます。
dn: cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: rfc 2829 u syntax nsSaslMapRegexString: ^u:\(.*\) nsSaslMapBaseDNTemplate: dc=example,dc=com nsSaslMapFilterTemplate: (uid=\1)
UID マッピング
このマッピングは、他のデフォルトのマッピングルールに一致しない平文文字列である authid
と一致します。この値を使用して (uid=value) のフィルターを定義します。検索ベースは、デフォルトの userRoot データベースの接尾辞になるようにハードコーディングされます。
dn: cn=uid mapping,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping cn: uid mapping nsSaslMapRegexString: ^[^:@]+$ nsSaslMapBaseDNTemplate: dc=example,dc=com nsSaslMapFilterTemplate: (uid=&)
9.9.3. SASL Identity マッピングの設定
9.9.3.1. コンソールからの SASL アイデンティティーマッピングの設定
- Directory Server コンソールで、Configuration タブを開きます。
- SASL Mapping タブを選択します。
- 新しい SASL ID マッピングを追加するには、ボタンを選択し、必要な値を入力します。
- Nameこのフィールドは SASL マッピングの一意の名前を設定します。
- 正規表現。このフィールドは、\(.*\) などの DN コンポーネントに一致するために使用される正規表現を設定します。このフィールドは、SASL マッピング LDIF エントリーの nsSaslMapRegexString 値に対応します。
- 検索ベース DN。このフィールドは、ou=People,dc=example,dc=com などのエントリーをマップするために検索するベース DN を指定します。このフィールドは、SASL マッピング LDIF エントリーの nsSaslMapBaseDNTemplate 値に対応します。
- 検索フィルターこのフィールドには 、(objectclass=*) などの置き換えるコンポーネントの検索フィルターを指定します。このフィールドは、SASL マッピング LDIF エントリーの nsSaslMapFilterTemplate 値に対応します。
9.9.3.2. コマンドラインでの SASL Identity マッピングの設定
# ldapmodify -a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=example map,cn=mapping,cn=sasl,cn=config
changetype: add
objectclass: top
objectclass: nsSaslMapping
cn: example map
nsSaslMapRegexString: \(.*\)
nsSaslMapBaseDNTemplate: ou=People,dc=example,dc=com
nsSaslMapFilterTemplate: (cn=\1)
9.9.4. SASL マッピングフォールバックの有効化
nsslapd-sasl-mapping-fallback
パラメーターを有効にすると、Directory Server が一致するすべてのマッピングを検証するように設定できます。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config changetype: modify replace: nsslapd-sasl-mapping-fallback nsslapd-sasl-mapping-fallback: on
9.9.4.1. SASL マッピングの優先度の設定
nsslapd-sasl-mapping-fallback
属性を使用して SASL マッピングフォールバックを有効にすると、任意でマッピング設定の nsSaslMapPriority
属性を設定して優先順位を設定できます。nsSaslMapPriority
属性は、1 (最も高い優先度) から 100 (最も低い優先度) の値をサポートします。デフォルトは 100 です。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config changetype: modify replace: nsSaslMapPriority nsSaslMapPriority: 1
9.10. SASL での Kerberos GSS-API の使用
9.10.1. Directory Server の SASL の認証メカニズム
- Generic Security Services (GSS-API). 汎用セキュリティーサービス (GSS) は、UNIX ベースのオペレーティングシステムが Kerberos サービスにアクセスして認証するためのネイティブな方法であるセキュリティー API です。GSS-API は TLS と同様にセッション暗号化もサポートします。これにより、Kerberos バージョン 5 の認証情報 (チケット) を使用して LDAP クライアントがサーバーで認証でき、ネットワークセッションの暗号化を使用できます。Directory Server が GSS-API を使用するには、Kerberos をホストマシンに設定する必要があります。「SASL での Kerberos GSS-API の使用」を参照してください。注記GSS-API および Kerberos は GSS-API サポートのあるプラットフォームでのみサポートされます。GSS-API を使用するには、Kerberos クライアントライブラリーをインストールする必要があります。必要な Kerberos ライブラリーはすべてオペレーティングシステムベンダーから利用できます。
9.10.2. Directory Server の Kerberos の概要
9.10.2.1. プリンシパルおよびレルムについて
uid=user_name/[server_instance],cn=realm,cn=mechanism,cn=auth
uid=mconnors/cn=Europe.example.com,cn=engineering,cn=gssapi,cn=auth
uid=bjensen,cn=accounting,cn=gssapi,cn=auth
9.10.2.2. KDC サーバーおよびキータブの概要
ldap/server.example.com/EXAMPLE.COM
9.10.3. Directory Server 起動時の SASL 認証の設定
/etc/sysconfig/dirsrv
ファイルに保存されます。
dirsrv-
instance という名前の /etc/sysconfig/
ディレクトリーにインスタンス固有の設定ファイルを作成できます (例: dirsrv-example
)。ホストにインスタンスが 1 つある場合は、デフォルトの dirsrv
ファイルを使用することができます。
/etc/sysconfig/dirsrv
(またはインスタンス固有の) ファイルの KRB5_KTNAME 行のコメントを解除し、KRB5_KTNAME 変数のキータブの場所を設定します。以下に例を示します。
# In order to use SASL/GSSAPI the directory
# server needs to know where to find its keytab
# file - uncomment the following line and set
# the path and filename appropriately
KRB5_KTNAME=/etc/dirsrv/krb5.keytab
9.11. SASL メカニズムの設定
supportedSASLMechanisms
パラメーターに一覧表示されます。特定の SASL メカニズムを有効にするには、cn=config エントリーに nsslapd-allowed-sasl-mechanisms
属性を設定します。たとえば、GSSAPI および DIGEST-MD5 メカニズムのみを有効にするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-allowed-sasl-mechanisms nsslapd-allowed-sasl-mechanisms: GSSAPI, DIGEST-MD5
nsslapd-allowed-sasl-mechanisms
属性に記載されていない場合でも、このメカニズムは常に有効になります。
9.12. LDAP クライアントでの SASL の使用
ldapsearch
などの LDAP クライアントで SASL を使用するには、-Y SASL_mechanism
をコマンドに渡します。以下に例を示します。
- LDAP プロトコルで SASL メカニズム GSSAPI を使用するには、以下を行います。
# ldapsearch -Y GSSAPI -U "dn:uid=user_name,ou=people,dc=example,dc=com" -R EXAMPLE.COM -H ldap://server.example.com -b "dc=example,dc=com"
- LDAPS プロトコルで SASL メカニズム PLAIN を使用するには、以下を行います。
# ldapsearch -Y PLAIN -D "uid=user_name,ou=people,dc=example,dc=com" -W -H ldaps://server.example.com -b "dc=example,dc=com"
第10章 属性暗号化の設定
uid
属性が暗号化されている場合、値はエントリーで暗号化されますが、DN に表示されます。
# entry-id: 16 dn:uid=jsmith1234
,ou=People,dc=example,dc=com nsUniqueId: ee91ea82-1dd111b2-9f36e9bc-39fb8550 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson givenName: John sn: Smithuid:: Sf04P9nJWGU1qiW9JJCGRg==
10.1. キーの暗号化
10.2. 暗号化暗号
- AES (Advanced Encryption Standard)
- 3DES (Triple Data Encryption Standard)
10.3. コンソールからの属性暗号化の設定
- Configuration タブで、Data node を選択します。
- 接尾辞を展開し、編集するデータベースを選択します。
- Attribute Encryption タブを選択します。
- Add Attribute ボタンをクリックして、属性の一覧を開きます。暗号化する属性を選択します。注記既存の属性値を暗号化するには、データベースから情報をエクスポートしてから再インポートする必要があります。「暗号化したデータベースのエクスポートおよびインポート」 を参照してください。
- 使用する暗号化暗号を選択します。
10.4. コマンドラインを使用した属性暗号化の設定
- ldapmodify コマンドを実行します。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x - 暗号化する属性の暗号化エントリーを追加します。たとえば、このエントリーは、AES 暗号で
telephoneNumber
属性を暗号化します。dn: cn=telephoneNumber,cn=encrypted attributes,cn=Database1,cn=ldbm database,cn=plugins,cn=config changetype: add objectclass: top objectclass: nsAttributeEncryption cn: telephoneNumber nsEncryptionAlgorithm: AES
- エントリーの既存の属性を暗号化するには、情報をエクスポートしてから再インポートする必要があります。「暗号化したデータベースのエクスポートおよびインポート」 を参照してください。
10.5. 既存の属性値の属性暗号化の有効化
10.6. 属性暗号化の有効化後の一般的な考慮事項
- 暗号化されていないデータは、サーバーのデータベースページプールのバッキングファイルで保持できます。このデータを削除するには、以下を実行します。
- インスタンスを停止します。
# systemctl stop dirsrv@instance_name
/var/lib/dirsrv/slapd-instance_name/db/guardian
ファイルを削除します。# rm /var/lib/dirsrv/slapd-instance_name/db/guardian
- インスタンスを起動します。
# systemctl start dirsrv@instance_name
- 暗号化を有効にし、データが正常にインポートされた後に、暗号化されていないデータで LDIF ファイルを削除します。
- 暗号化を有効にすると、データの再インポート時に Directory Server は新規データベースを削除し、作成します。
- レプリケーションログファイルは暗号化されません。このデータを保護するには、暗号化されたディスクに保存します。
- サーバーのメモリー (RAM) のデータは暗号化されず、swap パーティションに一時的に保存できます。このデータを保護するには、暗号化された swap 領域を設定します。
10.7. 暗号化したデータベースのエクスポートおよびインポート
10.7.1. 暗号化したデータベースのエクスポート
-E
パラメーターを db2ldif スクリプトに渡します。このスクリプトは、Directory Sever 設定に保存されているパスワードを使用して、データベースを復号します。
# db2ldif -Z instance_name -n database_name -E -a /tmp/data.ldif
/tmp/export.ldif
ファイルにすべてのデータをエクスポートするには、次のコマンドを実行します。
# db2ldif -Z instance_name -n database_name -E -s "ou=people,dc=example,dc=com" \ -a /tmp/data.ldif
a
オプションで設定したファイルに書き込みできる必要があります。
10.7.2. 暗号化されたデータベースへの LDIF ファイルのインポート
- Directory Server インスタンスを停止します。
# systemctl stop dirsrv@instance_name
- 前回のエクスポートと今回のインポートとの間で証明書データベースを置き換えた場合は、
/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルを編集して、その属性を含む以下のエントリーを削除します。- cn=AES,cn=encrypted attribute keys,cn=database_name,cn=ldbm database,cn=plugins,cn=config
- cn=3DES,cn=encrypted attribute keys,cn=database_name,cn=ldbm database,cn=plugins,cn=config
重要全データベースのエントリーを削除します。nsSymmetricKey
属性を含むエントリーが/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルに残されると、Directory Server は起動に失敗します。 - LDIF ファイルをインポートします。以下に例を示します。
# ldif2db -Z instance_name -n database_name -E -i /tmp/data.ldif
-E
パラメーターにより、スクリプトはインポート中に暗号化を設定する属性を暗号化できます。 - インスタンスを起動します。
# systemctl start dirsrv@instance_name
10.8. 属性暗号化に使用される TLS 証明書の更新
- 復号化された属性でデータベースをエクスポートします。「暗号化したデータベースのエクスポート」を参照してください。
- Network Security Services (NSS) データベースから既存の秘密鍵と証明書を削除します。「秘密鍵の削除」を参照してください。
- Certificate Signing Request (CSR) を新規作成します。「証明書署名要求の作成」を参照してください。
- 新しい証明書をインストールします。「証明書のインストール」 を参照してください。
- Directory Server インスタンスを停止します。
# systemctl stop dirsrv@instance_name
/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルを編集し、属性を含む以下のエントリーを削除します。- cn=AES,cn=encrypted attribute keys,cn=database_name,cn=ldbm database,cn=plugins,cn=config
- cn=3DES,cn=encrypted attribute keys,cn=database_name,cn=ldbm database,cn=plugins,cn=config
重要全データベースのエントリーを削除します。nsSymmetricKey
属性を含むエントリーが/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルに残されると、Directory Server は起動に失敗します。- データベースをインポートします。「暗号化されたデータベースへの LDIF ファイルのインポート」を参照してください。
- インスタンスを起動します。
# systemctl start dirsrv@instance_name
第11章 FIPS モードサポートの管理
FIPS モードサポートの有効化
- 必要に応じて、Red Hat Enterprise Linux で FIPS モードを有効にします。詳細は、『Red Hat Enterprise Linux セキュリティーガイド』 の該当するセクションを参照してください。
- ネットワークセキュリティーサービス (NSS) データベースの FIPS モードを有効にします。
# modutil -dbdir /etc/dirsrv/slapd-instance_name/ -fips true
- Directory Server インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
FIPS モードサポートの無効化
- ネットワークセキュリティーサービス (NSS) データベースの FIPS モードを無効にします。
# modutil -dbdir /etc/dirsrv/slapd-instance_name/ -fips false
- Directory Server インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
- 必要に応じて、Red Hat Enterprise Linux で FIPS モードを無効にします。詳細は、『Red Hat Enterprise Linux セキュリティーガイド』 の該当するセクションを参照してください。
第12章 ディレクトリースキーマの管理
12.1. スキーマの概要
12.1.1. デフォルトのスキーマファイル
/usr/share/dirsrv/schema/
ディレクトリーにあります。このディレクトリーのファイルは、新しい Directory Server インスタンスのテンプレートとして使用されます。このディレクトリーに新しいスキーマを追加すると、新しいインスタンスが利用可能になります。
12.1.2. オブジェクトクラス
objectclasses
行によって識別され、その後 OID、名前、説明、その直接の上位オブジェクトクラス (オブジェクトクラスと使用する必要のあるオブジェクトクラス、およびそのオブジェクトクラスと属性を共有するのに必要なオブジェクトクラス)、および必須属性の一覧 (MUST) および許可される属性の一覧 (MAY) が続きます。
例12.1 個人のオブジェクトクラススキーマエントリー
objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 4519' )
cn
属性、sn
属性、および objectClass
属性が必要で、description
属性、seeAlso
属性、telephoneNumber
属性、および userPassword
属性を許可します。
objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson
12.1.3. 属性
cn
属性は、cn: John Smith などのユーザーの氏名を保存するために使用されます。
givenname: John surname: Smith mail: jsmith@example.com
- OID
- name
- 構文マッチングルール (任意)
- 部分文字列マッチングルール (任意)
- 順序ルール (任意)
- 説明 (任意)
- 構文
- 単値または多値の属性
- 属性が定義されている場所の詳細
uid
属性スキーマエントリー」 に示されています。
例12.2 uid
属性スキーマエントリー
( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 4519' )
12.1.4. スキーマの拡張
user.ldif
)。新しい個別のスキーマファイルを作成し、デフォルトのスキーマファイルで追加することもできます。
- 新規スキーマの OID の計画および定義。スキーマ要素はその OID によってサーバーが認識されるため、OID を一意で、整理することが重要です。Directory Server 自体は OID を管理しませんが、「オブジェクト識別子の管理」で説明するベストプラクティスがいくつかあります。
- 新しい属性を作成します。属性定義には名前、構文 (許可される値の形式)、OID、および属性をエントリーごとに一度または複数回使用できるかどうかの説明が必要です。
- 新規属性を含むオブジェクトクラスを作成します。オブジェクトクラスは、そのエントリータイプに必要な属性と許可される (許容) 属性を一覧表示します。デフォルトのスキーマは変更できないため、新規属性を作成している場合は、カスタムオブジェクトクラスに追加する必要があります。
/usr/share/dirsrv/schema/
のスキーマファイルで読み取ることができます。まずは、利用可能なスキーマを確認してください。次に、不足している情報属性と、不足している情報属性を補うためにカスタム属性を使用した最善の方法を計画します。スキーマのプランニングについては、『デプロイメントガイド』 で説明しています。
- スキーマはできるだけシンプルに保ちます。
- 可能であれば、既存のスキーマ要素を再利用します。
- 各オブジェクトクラスに定義される必須属性の数を最小限に抑えます。
- 複数のオブジェクトクラスまたは属性を同じ目的で定義しないでください。
- 属性またはオブジェクトクラスの既存の定義は変更しないでください。
12.1.5. スキーマレプリケーション
/etc/dirsrv/slapd-instance_name/schema/99user.ldif
ファイルに変更を保存します。更新されたスキーマは他のレプリカに自動的に複製されません。スキーマレプリケーションは、ディレクトリーのコンテンツが複製されたツリーで更新されると開始します。たとえば、スキーマの変更後にユーザーエントリーまたはグループエントリーを更新すると、nsSchemaCSN
属性に保存されている CSN と、コンシューマーにある CSN が比較されます。リモート CSN がサプライヤー上のものよりも小さい場合、スキーマはコンシューマーに複製されます。レプリケーションに成功すると、サプライヤーにあるすべてのオブジェクトクラスと属性タイプはコンシューマーの定義のスーパーセットである必要があります。
例12.3 スキーマのサブセットとスーパーセット
server1
では、demo オブジェクトクラスはa1
属性、a2
属性、およびa3
属性を許可します。server2
では、demo オブジェクトクラスはa1
属性およびa3
属性を許可します。
server1
にある demo オブジェクトクラスのスキーマ定義は、server2
のオブジェクトクラスのスーパーセットです。検証フェーズで、スキーマが複製または許可されると、Directory Server はスーパーセット定義を取得します。たとえば、ローカルスキーマのオブジェクトクラスがサプライヤースキーマのオブジェクトクラスよりも少ない属性を許可していることをコンシューマーが検出すると、ローカルスキーマが更新されます。
nsSchemaCSN
属性は両サーバーで同一であり、レプリケーションセッションの開始時に比較されなくなります。
- あるホストのスキーマは、別のホストのスキーマのサブセットです。たとえば、例12.3「スキーマのサブセットとスーパーセット」では、
server2
にある demo オブジェクトクラスのスキーマ定義はserver1
のオブジェクトクラスのサブセットです。サブセットは、属性 (単一値属性は複数値属性のサブセット) および属性の構文 (IA5
はOctet_string
のサブセット) に対しても発生する可能性があります。 - サプライヤースキーマとコンシューマースキーマの定義をマージする必要があります。Directory Server はマージスキーマをサポートしません。たとえば、1 台のサーバーのオブジェクトクラスが
a1
属性、a2
属性、およびa3
属性を許可し、別のサーバーのオブジェクトクラスがa1
属性、a3
属性、およびa4
属性を許可する場合、スキーマはサブセットではなく、マージできません。 /etc/dirsrv/slapd-instance_name/schema/99user.ldif
以外のスキーマファイルが使用されます。Directory Server を使用すると、/etc/dirsrv/slapd-instance_name/schema/
ディレクトリーにスキーマファイルを追加できます。ただし、99user.ldif
ファイルの CSN のみが更新されます。このため、他のスキーマファイルはローカルでのみ使用され、レプリケーションパートナーに自動的に転送されません。更新されたスキーマファイルをコンシューマーに手動でコピーし、スキーマを再読み込みします。詳細は「スキーマの動的再読み込み」を参照してください。スキーマ定義の重複を回避し、自動レプリケーションを有効にするには、すべてのカスタムスキーマを/etc/dirsrv/slapd-instance_name/schema/99user.ldif
ファイルに保存します。カスタムスキーマファイルの作成方法は、「カスタムスキーマファイルの作成」を参照してください。
12.2. オブジェクト識別子の管理
12.3. Directory Server 属性の構文
12.4. コンソールでのカスタムスキーマの管理
12.4.1. 属性およびオブジェクトクラスの表示
- Directory Server コンソールで、Configuration タブを選択します。
- 左側のナビゲーションツリーで Schema フォルダーを選択します。
- Directory Server に読み込まれているスキーマ要素を表示するタブには、オブジェクトクラス、属性、 および Matching Rules という 3 つのタブがあります。
12.4.2. 属性の作成
- Configuration タブを選択します。
- 左側のナビゲーションツリーで Schema フォルダーを選択し、右側のペインの Attributes タブを選択します。
- 作成 をクリックします。
- 新しい属性の情報を入力します。
- 属性名。これは一意である必要があります。
- OID。これは必須ではありませんが、互換性およびサーバーパフォーマンスのために、一意の数値 OID を割り当てることが強く推奨されます。
- 構文。これは属性値で使用できる形式です。
- 属性が多値かどうか。デフォルトでは、すべての属性をエントリーで複数回使用できますが、チェックボックスの選択を解除すると、属性が一度だけ使用できることを意味します。
12.4.3. オブジェクトクラスの作成
- Directory Server コンソールで、Configuration タブを選択します。
- ナビゲーションツリーで Schema フォルダーを選択し、右側のペインで Object Classes タブを選択します。
- Object Classes タブの ボタンをクリックします。
- 新規オブジェクトクラスの情報を入力します。
- 名前。これは一意である必要があります。
- OID。これは必須ではありませんが、互換性およびサーバーパフォーマンスのために、一意の数値 OID を割り当てることが強く推奨されます。
- エントリーの上位オブジェクトクラスデフォルトは top です。別のオブジェクトクラスを選択すると、新規オブジェクトクラスは、独自の定義された属性に加えて、親から必須属性および許可される属性をすべて継承します。
- 必須および許可される属性。左側の属性を選択し、Available Attributes および Required Attributes ボックス によって ボタンを使用して、属性を適宜追加します。
注記親オブジェクトクラスから継承される属性は、許可または拒否されるかどうかに関わらず、削除できません。
12.4.4. カスタムスキーマ要素の編集
- Directory Server コンソールで、Configuration タブを選択します。
- 左側のナビゲーションツリーで Schema フォルダーを選択します。
- Object Classes または Attributes タブを開きます。
- リストから編集するスキーマ要素を選択します。カスタム(ユーザー定義の)スキーマのみが Directory Server コンソールで編集できます。
- ウィンドウの下部にあるボタンをクリックします。
- スキーマ情報を編集します。
12.4.5. スキーマの削除
- Directory Server コンソールで、Configuration タブを選択します。
- 左側のナビゲーションツリーで Schema フォルダーを選択します。
- Object Classes または Attributes タブを開きます。
- リストから削除するスキーマ要素を選択します。Directory Server コンソールでは、カスタム(ユーザー定義の)スキーマのみを削除できます。
- ウィンドウの下部にあるボタンをクリックします。
- 削除を確認します。
12.5. ldapmodify を使用したスキーマの管理
user.ldif
)のデフォルトのカスタムスキーマファイルも変更します。
12.5.1. 属性の作成
attributetypes
エントリーです。attributetypes
属性の形式は以下のとおりです。
attributetypes: ( definition )定義には 5 つのコンポーネントが含まれます。
- OID (通常はドット区切り番号)
- NAME 名前 形式の一意の名前
- DESC 説明 形式の説明
- 任意で、属性が定義されているソース
99user.ldif
に属性定義が追加されます。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -x -v dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.2.3.4.5.6.1 NAME 'dateofbirth' DESC 'For employee birthdays' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUED X-ORIGIN 'Example defined')
12.5.2. オブジェクトクラスの作成
objectclasses
属性です。objectclasses
属性の形式は以下のとおりです。
objectclasses: ( definition )オブジェクトクラス定義には複数のコンポーネントが含まれます。
- OID (通常はドット区切り番号)
- NAME 名前 形式の一意の名前
- DESC 説明 形式の説明
- SUP object_class の形式で、このオブジェクトクラスの上位または親のオブジェクトクラス。関連する親がない場合は、SUP top を使用してください。
- AUXILIARY という単語で、オブジェクトクラスを適用するエントリーのタイプを指定します。AUXILIARY は、任意のエントリーに適用できることを意味します。
- MUST の後に続く必要な属性のリスト。複数の属性を含めるには、グループを括弧で囲み、ドル記号 ($) で属性を区切ります。
- MAY の後に続く許可される属性のリスト。複数の属性を含めるには、グループを括弧で囲み、ドル記号 ($) で属性を区切ります。
99user.ldif
に追加されます。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -v dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 2.16.840.1133730.2.123 NAME 'examplePerson' DESC 'Example Person Object Class' SUP inetOrgPerson AUXILIARY MUST cn MAY (exampleDateOfBirth $ examplePreferredOS) )
12.5.3. スキーマの削除
- 不要な属性を使用するエントリーから、その属性を受け入れるスキーマファイルのオブジェクトクラスから削除します。同様に、オブジェクトクラスを削除するには、任意のエントリーから削除します。
- ldapmodify を実行して属性を削除します。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=schema changetype: modify delete: objectclasses objectclasses: ( 2.16.840.1133730.2.123 NAME 'examplePerson' DESC 'Example Person Object Class' SUP inetOrgPerson AUXILIARY MUST cn MAY (exampleDateOfBirth $ examplePreferredOS) )
警告削除するオブジェクトクラスまたは属性を指定してください。値なしでattributetypes
属性またはobjectclasses
属性のみを使用すると、ファイル内のすべてのユーザー定義属性またはオブジェクトクラスが削除されます。
99user.ldif
以外のカスタムスキーマファイルにある場合は、ファイルを直接編集します。Directory Server コンソールおよび LDAP ツールは 、99user.ldif
以外のスキーマファイルを編集できません。
12.6. カスタムスキーマファイルの作成
- 最初の行は dn: cn=schema である必要があります。
- スキーマファイルには、属性とオブジェクトクラスの両方を含めることができますが、どちらか一方のみを含めることもできます。
- スタイルに属性とオブジェクトクラスの両方が定義されている場合は、最初にすべての属性がファイルに記載し、次にオブジェクトクラスを記載する必要があります。
- オブジェクトクラスは、他のスキーマファイルで定義された属性を使用できます。
- このファイルは、[1-9][0-9]text.ldif の形式で指定する必要があります。このファイルは、常に 2 つの数字で開始する必要があります。数値的には、コア設定スキーマ (00 および 01) の前にスキーマファイルを読み込ませることができません。また、Directory Server は、常に、そのカスタムスキーマをスキーマディレクトリー内の数値およびアルファベット順で最も高い名前のスキーマファイルに書き込みます。このファイルは、
99user.ldif
であることを想定しています。このファイルが99user.ldif
ではない場合には、サーバーで問題が発生する可能性があります。そのため、常に、カスタムスキーマファイルが、少なくともアルファベット順で99user.ldif
よりも低くなることを確認します。名前99alpha.ldif
は問題ではありません。99zzz.ldif
名前は問題です。
attributetypes
属性として、5 つのコンポーネントがあるスキーマファイルで定義されます。
- OID (通常はドット区切り番号)
- NAME 名前 形式の一意の名前
- DESC 説明 形式の説明
- 任意で、属性が定義されているソース
attributetypes: ( 1.2.3.4.5.6.1 NAME 'dateofbirth' DESC 'For employee birthdays' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUED X-ORIGIN 'Example defined')
objectclasses
属性の値として定義されますが、オブジェクトクラスの定義方法には若干柔軟性があります。必要な設定は、オブジェクトクラスの名前と OID のみになります。他のすべての設定は、オブジェクトクラスのニーズに依存します。
- OID (通常はドット区切り番号)
- NAME 名前 形式の一意の名前
- DESC 説明 形式の説明
- SUP object_class の形式で、このオブジェクトクラスの上位または親のオブジェクトクラス。関連する親がない場合は、SUP top を使用してください。
- AUXILIARY という単語で、オブジェクトクラスを適用するエントリーのタイプを指定します。AUXILIARY は、任意のエントリーに適用できることを意味します。
- MUST の後に続く必要な属性のリスト。複数の属性を含めるには、グループを括弧で囲み、ドル記号 ($) で属性を区切ります。
- MAY の後に続く許可される属性のリスト。複数の属性を含めるには、グループを括弧で囲み、ドル記号 ($) で属性を区切ります。
objectclasses: ( 2.16.840.1133730.2.123 NAME 'examplePerson' DESC 'Example Person Object Class' SUP inetOrgPerson AUXILIARY MUST cn MAY (exampleDateOfBirth $ examplePreferredOS) )
例12.4 スキーマファイルの例
dn: cn=schema attributetypes: ( 2.16.840.1133730.1.123 NAME 'dateofbirth' DESC 'For employee birthdays' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Example defined') objectclasses: ( 2.16.840.1133730.2.123 NAME 'examplePerson' DESC 'Example Person Object Class' SUP inetOrgPerson AUXILIARY MAY (dateofbirth) )
/etc/dirsrv/slapd-instance/schema
に追加する必要があります。サーバーが再起動するか、動的に再読み込みされたタスクが実行されない限り、これらのファイルのスキーマは読み込まれず、サーバーで使用できなくなります。
/usr/share/data/
ディレクトリーから標準スキーマを使用する場合は、スキーマファイルを /usr/share/dirsrv/schema/
ディレクトリーにコピーします。標準スキーマが特定のインスタンスでのみ利用できるようにする必要がある場合は、スキーマファイルを /etc/dirsrv/slapd-instance_name/schema/
ディレクトリーにコピーしますが、宛先ディレクトリーで別のファイル名を使用します。それ以外の場合は、Directory Server はアップグレード中にファイルの名前を変更し、.bak
接尾辞を追加します。
12.7. スキーマの動的再読み込み
- schema-reload.pl スクリプトの使用
- ldapmodifyを使用した cn=schema 再読み込みタスク エントリーの追加
12.7.1. schema-reload.pl を使用したスキーマの再読み込み
99user.ldif
に追加しなくても、カスタムスキーマファイルを動的に読み込むことができます。
- Directory Manager としてスクリプトを実行し、バインドします。
# schema-reload.pl -Z instance_name -D "cn=Directory Manager" -w secret
Directory Server は、新しい再読み込みタスクエントリーが追加されたことを伝えます。adding new entry cn=schema_reload_2009_1_6_17_52_4,cn=schema reload task,cn=tasks,cn=config
これにより、デフォルトのスキーマディレクトリー/etc/dirsrv/slapd-instance/schema
からスキーマが再読み込みされます。-d
オプションを使用して別のディレクトリーを指定することもできます。# schema-reload.pl -Z instance_name-D "cn=Directory Manager" -w password
-d /export/custom-schema
重要Directory Server スキーマ再読み込みタスクは、schemadir
パラメーターで指定したディレクトリーからスキーマファイルを再読み込みします。さらに、サーバーは//usr/share/dirsrv/schema
ディレクトリーからすべてのスキーマファイルを読み込みます。
12.7.2. ldapmodify を使用したスキーマの再読み込み
dse.ldif
ファイルの cn=tasks 設定エントリーで発生するため、ldapmodify を使用してエントリーを追加してタスクを開始することもできます。タスクが完了するとすぐに、エントリーはディレクトリーから削除されます。
cn
のみです。
# ldapmodify -a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=example schema reload,cn=schema reload task,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn:example schema reload
/usr/share/dirsrv/schema
にあります。これは、schemadir
属性を使用して別のスキーマディレクトリーを指定できます。これは、schema -reload.pl の -d
オプションに似ています。
# ldapmodify -a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=example schema reload,cn=schema reload task,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn:example schema reload
schemadir: /etc/dirsrv/slapd-instance_name/schema/
schemadir
パラメーターで指定したディレクトリーからスキーマファイルを再読み込みします。さらに、サーバーは //usr/share/dirsrv/schema
ディレクトリーからすべてのスキーマファイルを読み込みます。
dse.ldif 設定から削除
されるため、同じタスクエントリーを継続的に再利用できます。
12.7.3. レプリケーションによるスキーマの再読み込み
- レプリケーションを停止します。
- 新しいスキーマファイルをコピーし、各サプライヤーおよびレプリカサーバーに対してスキーマ再読み込みタスクを実行します。
- レプリケーションを再起動します。
12.7.4. スキーマの再読み込みエラー
adding new entry cn=schema reload task 1,cn=schema reload task,cn=tasks,cn=config
[06/Jan/2009:17:52:04.001214874 -0500] schemareload - Schema reload task starts (schema dir: default) ... [06/Jan/2009:17:52:04.754335904 -0500] schemareload - Schema validation passed. [06/Jan/2009:17:52:04.894255328 -0500] schemareload - Schema reload task finished.
[..] schemareload - Schema reload task starts (schema dir: /bogus) ... [..] schema - No schema files were found in the directory /bogus [..] schema_reload - schema file validation failed [..] schemareload - Schema validation failed.
12.8. スキーマチェックのオンとオフを切り替える
- 使用するオブジェクトクラスおよび属性はディレクトリースキーマで定義されます。
- オブジェクトクラスに必要な属性はエントリーに含まれます。
- オブジェクトクラスで使用できる属性のみがエントリーに含まれます。
12.8.1. コマンドラインでスキーマチェックのオンおよびオフを切り替え
nsslapd-schemacheck
属性の値を編集します。スキーマの確認を無効にするには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config changetype: modify replace: nsslapd-schemacheck nsslapd-schemacheck: off
nsslapd-schemacheck
パラメーターの詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンス で、パラメーターの説明を参照してください』。
12.8.2. コンソールを使用したスキーマチェックのオンおよびオフの切り替え
- Directory Server コンソールで、Configuration タブを選択します。
- ナビゲーションツリーの上部にあるサーバーアイコンを強調表示し、右側のペインの Settings タブを選択します。
- スキーマチェックを有効にするには、Enable Schema Checking チェックボックスにチェックを入れます。スキーマチェックをオフにします。
12.9. 構文の検証の使用
telephoneNumber
属性に、実際にその値に有効な電話番号が指定されていることを確認します。
12.9.1. 構文の検証の概要
12.9.2. 構文の検証およびその他の Directory Server 操作
データベース暗号化
通常の LDAP 操作では、値がデータベースに書き込まれる直前に属性は暗号化されます。これは、属性構文の検証 後に 暗号化が実行されることを意味します。
-E
フラグを使用して行うことが強く推奨されます。これにより、インポート操作で構文の検証が問題になる可能性もあります。ただし、-E
フラグを使用せずに暗号化されたデータベースをエクスポートする場合は (サポートされていない)、暗号化された値で LDIF が作成されます。この LDIF をインポートすると、暗号化された属性を検証できず、警告がログに記録され、インポートされたエントリーで属性検証はスキップされます。
同期
Windows Active Directory エントリーと Red Hat Directory Server エントリーでは、属性の許容構文または強制構文に違いがある場合があります。この場合、構文の検証により Directory Server エントリーの RFC 標準が強制されるため、Active Directory の値を適切に同期できませんでした。
レプリケーション
Directory Server 10.6 インスタンスがその変更をコンシューマーに複製するサプライヤーである場合は、構文検証を使用した問題はありません。ただし、レプリケーションのサプライヤーが古いバージョンの Directory Server であったり、構文の検証が無効になっていたりする場合は、Directory Server 10.6 コンシューマーはマスターが許可する属性値を拒否する可能性があるため、構文の検証をコンシューマーで使用しないでください。
12.9.3. 構文の検証の有効化または無効化
nsslapd-syntaxcheck
属性で設定されます。この属性の値は on または off (デフォルトではオン)です。構文の検証を変更するには、ldapmodify を使用するか、dse.ldif
ファイルを直接編集してこの属性を変更します。
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-syntaxcheck nsslapd-syntaxcheck: off
12.9.4. DN の厳格な構文検証の有効化
dse.ldif
ファイルを直接編集してこの属性を変更します。
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-dn-validate-strict nsslapd-dn-validate-strict: on
12.9.5. 構文検証警告の有効化(Logging)
nsslapd-syntaxlogging
属性は、構文違反のエラーロギングを有効にします。
nsslapd-syntaxlogging
と nsslapd-syntaxcheck
の両方を有効にすると、無効な属性の変更が拒否され、メッセージがログに書き込まれます。nsslapd-syntaxlogging
が有効ですが nsslapd-syntaxcheck
が無効の場合、操作は成功できますが、警告メッセージがエラーログに書き込まれます。
dse.ldif
ファイルを直接編集します。
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-syntaxlogging nsslapd-syntaxlogging: on
12.9.6. 既存の属性値の構文の検証
nsslapd-syntaxcheck
パラメーターで構文の検証が無効になっている場合。詳細は、「構文の検証の有効化または無効化」 を参照してください。重要Red Hat は、構文の検証を無効にしないことを推奨します。- 構文検証なしまたは無効化されたサーバーからデータを移行する場合。
# syntax-validate.pl -D "cn=Directory Manager" -w secret \ -b "ou=people,dc=example,dc=com" -f "(objectclass=inetorgperson)" ldap_initialize( ldap://server.example.com:389 ) Successfully added task entry "cn=syntax_validate_2017_7_3_10_52_47, cn=syntax validate, cn=tasks, cn=config"
/var/log/dirsrv/slapd-instance_name/errors
ファイルに記録します。以下に例を示します。
- 検証済みの値がすべて有効であれば、以下を実行します。
[28/Jun/2017:12:52:43.669867966 +0200] - ERR - syntax-plugin - syntax_validate_task_thread - Starting (base: "dc=example,dc=com", filter: "(objectclass=*)") ... [28/Jun/2017:12:52:43.696850129 +0200] - ERR - syntax-plugin - syntax_validate_task_thread - Complete. Found 0 invalid entries.
- 無効なエントリーが見つかった場合は、以下を行います。
[28/Jun/2017:12:54:05.736087520 +0200] - ERR - syntax-plugin - syntax_validate_task_thread - Starting (base: "dc=example,dc=com", filter: "(objectclass=*)") ... [28/Jun/2017:12:54:05.754195607 +0200] - ERR - syntax-plugin - syntax_validate_task_callback - Entry "cn=user,ou=People,dc=example,dc=com" violates syntax. description: value #0 invalid per syntax [28/Jun/2017:12:54:05.759905671 +0200] - ERR - syntax-plugin - syntax_validate_task_thread - Complete. Found 1 invalid entries.
注記syntax-validate.pl
スクリプトは、構文違反のみを識別します。誤った値を手動で修正する必要があります。
第13章 インデックスの管理
13.1. インデックスの概要
13.1.1. インデックスタイプの概要
cn.db
ファイルに含まれます。
- Substring index (sub) は、維持するコストのかかるインデックスですが、エントリー内の部分文字列に対して効率的な検索が可能になります。部分文字列のインデックスは、各エントリーの最小 3 文字に制限されます。たとえば、cn=*derson の形式で検索すると、Bill Anderson、Jill Henderson、または Steve Sanderson といった文字列が含まれる共通名と一致します。同様に、telephoneNumber= *555* の検索は、555 が含まれる電話番号を持つディレクトリー内の全エントリーを返します。
- 国際インデックス は、国際ディレクトリー内の情報の検索を迅速化します。国際インデックスの作成プロセスは、通常のインデックスを作成するプロセスと似ています。ただし、オブジェクト識別子 (OID) をインデックス化する属性に関連付けることで 一致するルール を適用する点が異なります。サポートされるロケールおよび関連付けられた OID が「付録D 国際化」に一覧表示されています。追加のマッチングルールを受け入れるように Directory Server を設定する必要がある場合は、Red Hat コンサルティングにお問い合わせください。
- 参照インデックスまたは 仮想リストビュー(VLV)インデックスは、Directory Server コンソールのエントリーの表示を迅速化します。このインデックスは、ディレクトリーのブランチに数百のエントリーが含まれている場合に便利です(例: ou=people ブランチ)。ディレクトリーツリーの任意のブランチポイントに参照インデックスを作成して、Directory Server Console または vlvindex コマンドラインツールを使用して表示パフォーマンスを向上させることができます。これは、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス で説明されています。』
13.1.2. デフォルトインデックスおよびデータベースインデックスの概要
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com \ -b "cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config" \ '(objectClass=nsindex)'
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com \ -b "cn=index,cn=database_name,cn=ldbm database,cn=plugins,cn=config" \ '(objectClass=nsindex)'
13.1.3. 検索アルゴリズムの概要
cn
、共通名、属性)、および各値に対応するエントリーへのポインターが含まれます。Directory Server は、以下のように検索要求を処理します。
- LDAP クライアントアプリケーションは、検索要求をディレクトリーに送信します。
- ディレクトリーは、受信要求を調べて、指定したベース DN が、1 つ以上のデータベースまたはデータベースリンクに含まれるサフィックスと一致することを確認します。
- 一致する場合には、ディレクトリーはリクエストを処理します。
- 一致しない場合、ディレクトリーはサフィックスと一致しないことを示すエラーをクライアントに返します。cn=config 下の nsslapd-referral 属性で参照を指定している場合、ディレクトリーは、クライアントがリクエストを購入できる LDAP URL も返します。
- Directory Server は、どのインデックスが適用されるかを確認するための検索フィルターを調べ、フィルターを満たす各インデックスからエントリー ID の一覧を読み込もうとします。ID リストは、フィルターで使用されている AND または OR に参加するかによって組み合わせられます。
- エントリー ID の一覧が設定された ID リストのスキャン制限よりも大きい場合や、インデックスがない場合、Directory Server はデータベースのすべてのエントリーを検索します。これは インデックスのない 検索です。
- Directory Server は、ID リストのすべてのエントリー ID について、
id2entry.db
データベースまたはエントリーキャッシュから (またはインデックスなしの検索の場合はデータベース全体から) すべてのエントリーを読み取ります。その後、サーバーはエントリーをチェックして、検索フィルターと一致するかどうかを確認します。それぞれの一致が見つかったら、それが返されます。サーバーは、すべての候補エントリーを検索するか、設定されたリソース制限に達するまで、ID のリストを検索し続けます。(リソース制限は「コマンドラインを使用したユーザーおよびグローバルリソース制限の設定」に一覧表示されます。)注記簡単なページ化された結果制御を使用して、検索に対して別のリソース制限を設定できます。たとえば、管理者は、高いサイズまたは無制限サイズを設定し、ページ化された検索で制限を検索しますが、ページのない検索には低いデフォルト制限を使用します。
13.1.4. おおよその検索
- すべてのクエリー文字列コードは、エントリー文字列に生成されたコードと一致します。
- クエリー文字列コードはすべて、エントリー文字列コードと同じ順序で実行されます。
ディレクトリーの名前 (フォネティックコード) | クエリー文字列 (フォネティックコード) | 一致のコメント |
---|---|---|
Alice B Sarette (ALS B SRT) | Alice Sarette (ALS SRT) | 一致。コードが正しい順序で指定されます。 |
Alice Sarrette (ALS SRT) | 一致。コードは、Sarette が間違っているにもかかわらず、正しい順序で指定されます。 | |
Surette (SRT) | 一致。生成されたコードは、Sarette のスペルが間違っているにもかかわらず、元の名前で存在しています。 | |
Bertha Sarette (BR0 SRT) | 一致するものはありません。コード BR0 は元の名前に存在しません。 | |
Sarette, Alice (SRT ALS) | 一致するものはありません。コードが正しい順序で指定されていません。 |
13.1.5. インデックスのメリットとのバランス
- 概算インデックスは、通常、数字を含む属性 (電話番号など) には効率的ではありません。
- 部分文字列のインデックスはバイナリー属性では機能しません。
- 等価インデックスは、値が大きい場合に使用しないようにしてください (例: 暗号化データを含む写真やパスワードを含む属性など)。
- 検索であまり使用されない属性のインデックスを維持することは、グローバル検索のパフォーマンスを向上させることなく、オーバーヘッドを増加させます。
- インデックス化されていない属性は、検索要求で依然として指定できますが、検索のタイプによっては検索パフォーマンスが大幅に低下する可能性があります。
- 保守するインデックスが多いほど、必要なディスク領域が多くなります。
- Directory Server は add 操作または modify 操作を受け取ります。
- Directory Server は indexing 属性を調べ、属性値に対してインデックスが維持されているかどうかを判断します。
- 作成した属性値がインデックス化されると、Directory Server は新しいインデックスエントリーを生成します。
- サーバーがインデックス作成を完了すると、クライアント要求に応じて実際の属性値が作成されます。
dn: cn=John Doe,ou=People,dc=example,dc=com objectclass: top objectClass: person objectClass: orgperson objectClass: inetorgperson cn: John Doe cn: John sn: Doe ou: Manufacturing ou: people telephoneNumber: 408 555 8834 description: Manufacturing lead for the Z238 line of widgets.
cn
(一般名 (common name)) 属性およびsn
(姓 (surname)) 属性の等価、概算、および部分文字列インデックス。- 電話番号属性の等価および部分文字列のインデックス。
- 説明属性の部分文字列インデックス。
- John および John Doe の
cn
等価インデックスエントリーを作成します。 - John および John Doe の適切な
cn
の概算インデックスエントリーを作成します。 - John および John Doe の適切な
cn
部分文字列インデックスエントリーを作成します。 - Doe の
sn
等価インデックスエントリーを作成します。 - Doe に対する
sn
概算インデックスエントリーを作成します。 - Doe に適切な
sn
部分文字列インデックスエントリーを作成します。 - 408 555 8834 に電話番号の等価インデックスエントリーを作成します。
- 408 555 8834 に適切な電話番号の部分文字列インデックスエントリーを作成します。
- Manufacturing lead for the Z238 line of widgets の適切な説明部分文字列インデックスエントリーを作成します。この文字列に対して多数の部分文字列エントリーが生成されます。
13.1.6. インデックスの制限
nsrole
や cos_attribute
などの仮想属性をインデックス化できません。仮想属性には計算値が含まれます。これらの属性をインデックス化すると、Directory Server は無効なエントリーセットを返して直接的かつ内部検索を行うことができます。
13.2. 標準インデックスの作成
13.2.1. サーバーコンソールからのインデックスの作成
- Configuration タブを選択します。
- Data ノードを展開し、インデックスを作成するデータベースの接尾辞を展開して、データベースを選択します。
- 右側のペインで Indexes タブを選択します。注記Database Settings ノードをクリックしないでください。これにより Default Index Settings ウィンドウが開き、データベースごとにインデックスを設定するウィンドウは開かれません。
- インデックス化する属性が Additional Indexes テーブルに一覧表示される場合は、ステップ 6 に進みます。それ以外の場合は、Add Attribute をクリックして、サーバースキーマで利用可能な属性の一覧を含むダイアログボックスを開きます。
- インデックスの属性を選択し、をクリックします。サーバーは属性を Additional Indexes テーブルに追加します。
- 各属性について保持するインデックスの各タイプのチェックボックスを選択します。
- 英語以外の言語のインデックスを作成するには、Matching Rules フィールドで使用する照合順序 の OID を入力します。複数の言語を使用して属性をインデックス化するには、複数の OID をコンマで区切って指定しますが、空白文字は一覧表示しません。言語のリスト、関連する OID、および照合順序の詳細は、付録D 国際化 を参照してください。
13.2.2. コマンドラインからのインデックスの作成
- デフォルトインデックスのいずれかになる新しいインデックスを作成するには、新しいインデックス属性を cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config エントリーに追加します。
- 特定のデータベースに新しいインデックスを作成するには、作成するインデックスを cn=index,cn=database_name,cn=ldbm database,cn=plugins,cn=config エントリーに追加します。ここで、cn=database_name はデータベースの名前に対応します。
dse.ldif
ファイルの cn=config の下にエントリーを作成しないでください。シンプルな flat dse.ldif
設定ファイルの cn=config エントリーは、通常のエントリーと同じ拡張性の高いデータベースには保存されません。その結果、多くのエントリー (特に頻繁に更新される可能性のあるエントリー) を cn=config に保存すると、パフォーマンスが低下する可能性があります。パフォーマンスの理由から、cn=config に単純なユーザーエントリーを保存することは推奨していませんが、設定情報が一元化されるため、cn=config に Directory Manager エントリーやレプリケーションマネージャー (サプライヤーのバインド DN) エントリーなどの特別なユーザーエントリーを保存すると便利です。
sn
(姓 (surname)) 属性の有無、等価、および部分文字列インデックスを作成するには、以下を実行します。
- ldapmodify を実行して、新しいインデックスの LDIF エントリーを追加します。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=sn,cn=index,cn=Example1,cn=ldbm database,cn=plugins,cn=config changetype: add objectClass:top objectClass:nsIndex cn:sn nsSystemIndex:false nsIndexType:pres nsIndexType:eq nsIndexType:sub nsMatchingRule:2.16.840.1.113730.3.3.2.3.1cn
属性には、インデックスの属性の名前 (この例ではsn
属性) が含まれます。エントリーは nsIndex オブジェクトクラスのメンバーです。nsSystemIndex 属性は false で、インデックスが Directory Server 操作に不可欠ではないことを示します。複数値の nsIndexType 属性は、存在 (pres)、等価 (eq)、および部分文字列 (sub) のインデックスを指定します。各キーワードは別々の行で入力する必要があります。この例の nsMatchingRule 属性は、ブルガリア語の照合順序の OID を指定しています。マッチングルールは、言語や、日付や整数などの他のフォーマットなど、値の一致の可能性を示すことができます。nsIndexType 属性の none キーワードを使用して、インデックスが属性に対して維持されないように指定できます。この例では、nsIndexType を none に変更して、Example1 データベースのsn
インデックスを一時的に無効にします。dn: cn=sn,cn=index,cn=Example1,cn=ldbm database,cn=plugins,cn=config objectClass:top objectClass:nsIndex cn:sn nsSystemIndex:false nsIndexType:none
13.3. 既存のデータベースへの新規インデックスの生成
13.3.1. db2index.pl スクリプトの実行
# db2index.pl -Z instance_name -D "cn=Directory Manager" -w secret -n ExampleServer -t sn
db2index
ユーティリティーの説明を参照してください』。
13.3.2. cn=tasks エントリーを使用したインデックスの作成
cn
)と、属性およびインデックスの定義が必要です。形式は attribute:index_type で nsIndexAttribute
に設定します。
# ldapmodify -a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=example presence index,cn=index,cn=tasks,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: example presence index
nsInstance: userRoot
nsIndexAttribute: "cn:pres"
- 存在 インデックスの事前
- 等価インデックスの eq
- 部分文字列インデックスのサブ
13.4. ロージング(VLV)インデックスの作成
13.4.1. サーバーコンソールから参照インデックスの作成
- Directory タブを選択します。
- 左側のナビゲーションツリーで、インデックスを作成する People などのエントリーを選択します。
- Object メニューから Create Browsing Index を選択します。Create Browsing Index ダイアログボックスが表示され、インデックス作成のステータスを表示します。Status Logs ボックスをクリックし、作成されたインデックスのステータスを表示します。
13.4.2. コマンドラインから参照インデックスの作成
- ldapmodify を使用して新しい参照インデックスエントリーを追加するか、既存の参照インデックスエントリーを編集します。「参照インデックスエントリーの追加」を参照してください。
- vlvindex スクリプトを実行して、サーバーが維持する参照インデックスの新しいセットを生成します。「vlvindex スクリプトの実行」 を参照してください。または、cn=tasks,cn=config (「cn=tasks エントリーを使用した参照インデックスの作成」)で適切なタスクを起動します。
- VLV インデックス情報へのアクセス制御が適切に設定されていることを確認します。「VLV 情報のアクセス制御の設定」を参照してください。
13.4.2.1. 参照インデックスエントリーの追加
- 検索の範囲 (base、one、sub)
- 検索のベース (検索の開始点として使用するエントリー)
- ソートする属性
- 検索のフィルター検索用のフィルターを指定する方法は、「14章ディレクトリーエントリーの検索」を参照してください。
- 検索のベースとなるエントリーが属する LDBM データベース。LDBM データベースで参照先インデックスのみを作成できます。
- 検索ベースは ou=People,dc=example,dc=com です。
- 検索フィルターは (|(objectclass=*)(objectclass=ldapsubentry))です。
- スコープは 1 です。
- 返される属性のソート順序は、
cn
、givenname
、o
、ou
、sn
です。
- ldapmodify を実行し、参照しているインデックスのベース、スコープ、およびフィルターを指定するエントリーを追加します。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=MCC ou=People dc=example dc=com,cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: add objectClass: top objectClass: vlvSearch cn: MCC ou=People dc=example dc=com vlvBase: ou=People,dc=example,dc=com vlvScope: 1 vlvFilter: (|(objectclass=*)(objectclass=ldapsubentry))cn
には、参照インデックスを作成するエントリーを指定する参照インデックス識別子 (この例では ou=People,dc=example,dc=com エントリー) が含まれます。Red Hat は、Directory Server コンソールによって採用されるアプローチである参照インデックス識別子にエントリーの dn を使用して、同一の参照インデックスが作成されないようにすることを推奨します。エントリーは vlvSearch オブジェクトクラスのメンバーです。- vlvbase 属性の値は、参照インデックスを作成するエントリーを指定します。この例では、ou=People,dc=example,dc=com エントリー (参照インデックス識別子) を指定します。
- vlvScope 属性は 1 で、加速する検索の範囲が 1 であることを示します。1 の検索範囲は、
cn
属性に指定されたエントリーの即時の子のみで、エントリー自体ではなく検索が実行されます。 - vlvFilter は、検索に使用するフィルターを指定します (例: (|(objectclass=*)(objectclass=ldapsubentry)))。
- 2 番目のエントリーを追加して、返された属性のソート順序を指定します。
dn: cn=by MCC ou=People dc=example dc=com,cn=MCC ou=People dc=example dc=com,cn=userRoot,cn=ldbm database,cn=plugins, cn= config objectClass: top objectClass: vlvIndex cn: by MCC ou=People dc=example dc=com vlvSort: cn givenName o ou sn
cn
には、参照先のインデックスソート識別子が含まれます。上記のcn
は、デフォルトでコンソールによって作成されたタイプです。これには、参照インデックス ベースで設定されるソート順序が含まれます。エントリーは vlvIndex オブジェクトクラスのメンバーです。vlvSort
属性の値は、属性のソート順序を指定します。この例では、cn
、givenName
、o
、ou
、さらにsn
になります。
13.4.2.2. vlvindex スクリプトの実行
- サーバーを停止します。
# systemctl stop dirsrv@instance_name
- vlvindex スクリプトを実行します。
# vlvindex -Z instance_name -n Example1 -T "by MCC ou=people dc=example dc=com"
この例で使用されるパラメーターの詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンス のvlvindex
スクリプトの説明を参照してください』。 - サービスを起動します。
# systemctl start dirsrv instance
13.4.2.3. cn=tasks エントリーを使用した参照インデックスの作成
cn
)と他の属性 nsIndexVLVAttribute
が必要です。これにより、VLV インデックスの生成に使用する参照インデックス定義エントリーの名前を指定します。
# ldapmodify -a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=example VLV index,cn=index,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn: example VLV index
nsIndexVLVAttribute: "by MCC ou=people,dc=example,dc=com"
13.4.3. VLV 情報のアクセス制御の設定
aci
属性を更新して userdn
パラメーターを ldap://anyone
に設定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: oid=2.16.840.1.113730.3.4.9,cn=features,cn=config changetype: modify replace: aci aci: (targetattr != "aci")(version 3.0; acl "VLV Request Control"; allow( read, search, compare, proxy ) userdn = "ldap://anyone" ;)
13.5. インデックスのソート順序の変更
13.5.1. コンソールでのソート順序の変更
- Configuration タブを選択します。
- Data ノードを展開し、インデックスを作成するデータベースの接尾辞を展開して、データベースを選択します。
- 右側のペインで Indexes タブを選択します。
- インデックスを選択し、Matching Rules フィールドで、使用する新しいソート順序を入力します。たとえば、アルファベットでなく、数字でソートするには、integerOrderingMatch を入力します。
13.5.2. コマンドラインでのソート順序の変更
nsMatchingRule
を変更します。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=sn,cn=index,cn=Example1,cn=ldbm database,cn=plugins,cn=config changetype:modify replace:nsMatchingRule nsMatchingRule:integerOrderingMatch
13.6. Indexed Substring Search の Width の変更
nsSubStrBegin
属性は、ワイルドカードの前に検索文字列の最初にインデックス化された検索に必要な文字数を設定します。abc*
nsSubStrMiddle
属性は、検索文字列の途中でワイルドカードが使用される、インデックス化された検索に必要な文字数を設定します。以下に例を示します。ab*z
nsSubStrEnd
属性は、ワイルドカードの後に検索文字列の最後にインデックス化された検索に必要な文字数を設定します。以下に例を示します。*xyz
- 特定の属性インデックスの新しいキーの長さを設定します。これには、extensibleObject オブジェクトクラスを追加してから、
nsSubStrBegin
属性、nsSubStrEnd
属性、またはnsSubStrMiddle
属性を適宜追加する必要があります。以下に例を示します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: attribute_name,cn=index,cn=database_name,cn=ldbm database,cn=plugins,cn=config changetype: modify add: objectclass objectclass: extensibleObject - add: nsSubStrBegin nsSubStrBegin: 2 - add: nsSubStrMiddle nsSubStrMiddle: 2 - add: nsSubStrEnd nsSubStrEnd: 2
- サーバーを停止します。
# systemctl stop dirsrv.target
- 属性インデックスを再作成します。部分文字列検索の幅オプションのいずれかを変更した場合は、インデックス全体を再作成する必要があります。
# db2index -t attribute_name
- サーバーを再び起動します。
# systemctl start dirsrv.target
13.7. インデックスの削除
13.7.1. デフォルトインデックスエントリーからの属性の削除
sn
などのデフォルトのインデックスエントリーに一覧表示される複数の属性がインデックス化されます。以下の属性はデフォルトインデックスの一部です。
aci
|
cn
|
entryusn
|
givenName
|
mail
|
mailAlternateAddress
|
mailHost
|
member
|
memberOf
|
nsUniqueId
|
ntUniqueId
|
ntUserDomainId
|
numsubordinates
|
objectclass
|
owner
|
parentid
|
seeAlso
|
sn
|
telephoneNumber
|
uid
|
uniquemember
|
sn
属性を削除するには、次のコマンドを実行します。
cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config
エントリーから属性を削除します。# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x cn=sn,cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config
このエントリーから属性を削除しない場合は、サーバーの再起動後にsn
属性のインデックスが自動的に再作成され、破損します。cn=attribute_name,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
エントリーを削除します。詳細は、次を参照してください。- db2index.pl Perl スクリプトを実行してインデックスを再作成します。
# db2index.pl -Z instance_name -D "cn=Directory Manager" -w secret -n database_name
db2index.pl Perl スクリプトの使用に関する詳細は、db2index.pl(8) の man ページを参照してください。
13.7.2. サーバーコンソールを使用したインデックスからの属性の削除
- 削除する属性が
cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config
デフォルトインデックスエントリーに一覧表示されている場合は、最初にこのエントリーから削除します。詳細は「デフォルトインデックスエントリーからの属性の削除」を参照してください。 - Configuration タブを選択します。
- Data ノードを展開し、インデックスが含まれるデータベースに関連する接尾辞を展開します。
- インデックスを削除するデータベースを選択します。
- 削除するインデックスが含まれる属性を見つけます。インデックスの下のチェックボックスの選択を解除します。特定の属性に対して保持されるすべてのインデックスを削除するには、Attribute Name で属性のセルを選択し、 をクリックします。
- Delete Index 警告ダイアログボックスが開き、インデックスの削除の確認が必要になります。
13.7.3. コマンドラインを使用したインデックスから属性の削除
sn
属性を削除するには、以下のコマンドを実行します。
- 削除する属性が
cn=default indexes,cn=config,cn=ldbm database,cn=plugins,cn=config
デフォルトインデックスエントリーに一覧表示されている場合は、最初にこのエントリーからこれを削除する必要があります。詳細は「デフォルトインデックスエントリーからの属性の削除」を参照してください。 - インデックスから属性を削除します。
# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x cn=sn,cn=index,cn=database_name,cn=ldbm database,cn=plugins,cn=config
エントリーを削除すると、sn
属性のインデックスは維持されなくなります。 - db2index.pl Perl スクリプトを実行してインデックスを再作成します。
# db2index.pl -Z instance_name -D "cn=Directory Manager" -w secret -n database_name
db2index.pl Perl スクリプトの使用に関する詳細は、db2index.pl(8) の man ページを参照してください。
13.7.4. コマンドラインでのインデックスタイプの削除
sn
属性の sub インデックスタイプを削除するには、以下を実行します。
- インデックスタイプを削除します。
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=sn,cn=index,cn=database_name,cn=ldbm database,cn=plugins,cn=config changetype: modify delete: nsIndexType nsIndexType:sub
インデックスエントリーを削除すると、sn
属性の部分文字列インデックスは維持されなくなります。 - db2index.pl Perl スクリプトを実行してインデックスを再作成します。以下に例を示します。
# db2index.pl -Z instance_name -D "cn=Directory Manager" -w secret -n database_name
db2index.pl Perl スクリプトの使用に関する詳細は、db2index.pl(8) の man ページを参照してください。
13.7.5. サーバーコンソールからの参照インデックスの削除
- Directory タブを選択します。
- ナビゲーションツリーでインデックスを削除するエントリーを選択し、Object メニューから Delete Browsing Index を選択します。または、インデックスのエントリーを選択して、ナビゲーションツリーで削除する項目を選択し、ポップアップメニューから Delete Browsing Index を選択します。
- Delete Browsing Index ダイアログボックスが表示され、インデックスの削除を確定するように求められます。 をクリックします。
- Delete Browsing Index ダイアログボックスが表示され、インデックスの削除のステータスを表示します。
13.7.6. コマンドラインから参照インデックスの削除
- ldapdelete を使用して、参照インデックスエントリーを削除するか、既存の参照インデックスエントリー(「参照インデックスエントリーの削除」)を編集します。
- vlvindex スクリプトを実行して、サーバーが維持する参照インデックスの新しいセットを生成します(「vlvindex スクリプトの実行」)。または、cn=tasks,cn=config (「cn=tasks エントリーを使用した参照インデックスの作成」)で適切なタスクを起動します。
13.7.6.1. 参照インデックスエントリーの削除
cn
、givenname
、o
、ou
、sn
です。
dn: cn=MCC ou=People dc=example dc=com,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: vlvSearch cn: MCC ou=People dc=example dc=com vlvBase: ou=People,dc=example,dc=com vlvScope: 1 vlvFilter: (|(objectclass=*)(objectclass=ldapsubentry)) dn: cn=by MCC ou=People dc=example dc=com,cn=MCC ou=People dc=example dc=com,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: vlvIndex cn: by MCC ou=People dc=example dc=com vlvSort: cn givenname o ou sn
# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "cn=MCC ou=People dc=example dc=com,cn=userRoot,cn=ldbm database,cn=plugins,cn=config" "cn=by MCC ou=People dc=example dc=com,cn=MCC ou=People dc=example dc=com,cn=userRoot,cn=ldbm database,cn=plugins,cn=config"
13.7.6.2. vlvindex スクリプトの実行
- サーバーを停止します。
# systemctl stop dirsrv.target instance
- vlvindex スクリプトを実行します。
# vlvindex -Z instance_name -n Example1 -T "by MCC ou=people dc=example dc=com"
この例で使用されるパラメーターの詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンス のvlvindex
スクリプトの説明を参照してください』。 - サービスを再起動します。
# systemctl start dirsrv.target instance
cn
)と他の属性 nsIndexVLVAttribute
が必要です。これにより、VLV インデックスの生成に使用する参照インデックス定義エントリーの名前を指定します。このタスクは vlvindex の実行と同じです。
# ldapmodify -a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=example VLV index,cn=index,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn: example VLV index
nsIndexVLVAttribute: "by MCC ou=people,dc=example,dc=com"
第14章 ディレクトリーエントリーの検索
14.1. リソース制限による検索パフォーマンスの改善
- ルックスルー制限。検索操作で確認できるエントリーの数を指定します。
- サイズ制限。検索操作にしたがって、サーバーがクライアントアプリケーションに返すエントリーの最大数を指定します。
- 時間制限。サーバーが検索操作の処理に費やす最大時間を指定します。
- アイドルタイムアウト。接続が切断される前に、サーバーへの接続がアイドル状態でいられる時間を指定します。
- 範囲のタイムアウト。範囲を使用した検索のために、別のルックスルー制限を指定します。
14.1.1. パフォーマンスおよびリソース制限の検索
14.1.2. 粒度の細かい ID リストサイズ
14.1.3. 単一ユーザーでのリソース制限の設定
- Directory タブを選択します。
- 左側のナビゲーションペインでナビゲーションツリーを参照し、リソース制限を設定するユーザーまたはロールをダブルクリックします。Edit Entry ダイアログボックスが表示されます。
- 左側のペインで アカウント をクリックします。
- リソース制限を設定します。設定可能な 4 つの制限があります。
- ルックスルー制限。検索操作に対して、エントリーの最大数を調べます。
- サイズ制限。検索操作に対応するために、サーバーがクライアントアプリケーションに返すエントリーの最大数。
- 時間制限。サーバーが検索操作の処理に費やす最大時間。
- アイドルタイムアウト。サーバーへの接続がアイドル状態でいられる期間。
-1 を値として指定すると、制限がないことを意味します。 - OK をクリックします。
14.1.4. コマンドラインを使用したユーザーおよびグローバルリソース制限の設定
- シークスルー制限
- 検索操作に対して検査するエントリーの数を指定します。この属性を -1 の値に指定すると、制限がないことを意味します。
- ユーザーレベルの属性:
nsLookThroughLimit
- グローバル設定:
- 属性:
nsslapd-lookthroughlimit
- エントリー: cn=config,cn=ldbm database,cn=plugins,cn=config
- ページルックアップの制限
- ルックスルー制限と同様に、検査するエントリーの数を指定しますが、単純なページング検索操作に特化しています。この属性を -1 の値に指定すると、制限がないことを意味します。
- ユーザーレベルの属性:
nsPagedLookThroughLimit
- グローバル設定:
- 属性:
nsSizeLimit
- エントリー: cn=config
- サイズ制限
- 検索操作にしたがって、サーバーがクライアントアプリケーションに返すエントリーの最大数を指定します。この属性を -1 の値に指定すると、制限がないことを意味します。
- ユーザーレベルの属性:
nsSizeLimit
- グローバル設定:
- 属性:
nsslapd-sizelimit
- エントリー: cn=config
- ページサイズ制限
- サイズの制限と同様、サーバーがクライアントアプリケーションに戻る最大エントリー数を指定しますが、単純なページング検索操作の場合に限ります。この属性を -1 の値に指定すると、制限がないことを意味します。
- ユーザーレベルの属性:
nsPagedSizeLimit
- グローバル設定:
- 属性:
nsslapd-pagedsizelimit
- エントリー: cn=config
- 時間制限
- サーバーが検索操作の処理に費やす最大時間を指定します。この属性を -1 の値に指定すると、制限がないことを意味します。
- ユーザーレベルの属性:
nsTimeLimit
- グローバル設定:
- 属性:
nsslapd-timelimit
- エントリー: cn=config
- アイドルタイムアウト
- 接続が切断される前に、サーバーへの接続がアイドル状態でいられる時間を指定します。値は秒単位で指定されます。この属性を -1 の値に指定すると、制限がないことを意味します。
- ユーザーレベルの属性:
nsidletimeout
- グローバル設定:
- 属性:
nsslapd-idletimeout
- エントリー: cn=config
- ID リストのスキャン制限
- 検索結果のインデックスファイルから読み込まれるエントリー ID の最大数を指定します。ID リストのサイズがこの値よりも大きい場合、検索はインデックスリストを使用せず、インデックスなしの検索として扱われ、データベース全体を検索します。
- ユーザーレベルの属性:
nsIDListScanLimit
- グローバル設定:
- 属性:
nsslapd-idlistscanlimit
- エントリー: cn=config,cn=ldbm database,cn=plugins,cn=config
- ページ ID リストスキャンの制限
- ID リストスキャンの制限と同様、検索結果のインデックスファイルから読み込まれるエントリー ID の最大数を指定しますが、ページングされた検索操作に対して指定します。
- ユーザーレベルの属性:
nsPagedIDListScanLimit
- グローバル設定:
- 属性:
nsslapd-pagedidlistscanlimit
- エントリー: cn=config,cn=ldbm database,cn=plugins,cn=config
- 範囲のルックアップの制限
- 範囲検索操作に関するエントリー数を指定します(greater-than、equal-to-or-greater-than、less-than、または equal-to-less-than 演算子を使用した検索)。この属性を -1 の値に指定すると、制限がないことを意味します。
- ユーザーレベルの属性: 利用できません。
- グローバル設定:
- 属性:
nsslapd-rangelookthroughlimit
- エントリー: cn=config,cn=ldbm database,cn=plugins,cn=config
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=user_name,ou=People,dc=example,dc=com changetype: modify add: nsSizeLimit nsSizeLimit: 500
nsSizeLimit
属性を Babs Jensen のエントリーに追加し、検索結果のサイズ制限を 500 エントリーにします。
14.1.5. 匿名バインドでのリソース制限の設定
- テンプレートエントリーを作成し、匿名バインドに適用するリソース制限を設定します。注記パフォーマンス上の理由から、テンプレートは、エントリーキャッシュは使用しない cn=config 接尾辞ではなく、通常のバックエンドになければなりません。以下に例を示します。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=anon template,ou=people,dc=example,dc=com changetype: add objectclass: nsContainer objectclass: top cn: anon template nsSizeLimit: 250 nsLookThroughLimit: 1000 nsTimeLimit: 60 - レプリケーショントポロジー内のすべてのマスターで、テンプレートエントリーの DN を参照するサーバー設定に
nsslapd-anonlimitsdn
を追加します。「コマンドラインを使用したユーザーおよびグローバルリソース制限の設定」に任意のリソース制限を設定できます。以下に例を示します。# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify add: nsslapd-anonlimitsdn nsslapd-anonlimitsdn: cn=anon template,ou=people,dc=example,dc=com
14.1.6. 範囲検索のパフォーマンス向上
(modifyTimestamp>=20200101010101Z)
nsslapd-rangelookthroughlimit
属性で設定されます。デフォルト値は 5000 で、デフォルトの nsslapd-lookthroughlimit
属性値と同じです。
# ldapmodify -a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: add
add: nsslapd-rangelookthroughlimit
nsslapd-rangelookthroughlimit: 7500
14.2. Directory Server コンソールを使用したエントリーの検索
図14.1 ディレクトリータブでエントリーの閲覧
図14.2 エントリーの検索
14.3. ldapsearch の使用
-s base
)、エントリーの即時サブエントリー (-s one
)、またはツリー全体またはサブツリー (-s sub
) を含めることができます。
14.3.1. ldapsearch コマンドライン形式
# ldapsearch [-x | -Y mechanism] [options] [search_filter] [list_of_attributes]
-x
(簡単なバインドを使用するため) または-Y
(SASL メカニズムを設定するため) は、接続の種類を設定するために使用されます。- オプション は、一連のコマンドラインオプションです。これが存在する場合は、検索フィルターの前に指定する必要があります。
- search_filter は、「LDAP 検索フィルター」で説明されている LDAP 検索フィルターです。-f オプションを使用して、検索フィルターがファイルで指定されている場合には、別の検索フィルターを指定しないでください。
- list_of_attributes は、スペースで区切られた属性の一覧です。属性の一覧を指定すると、検索結果で返される属性の数を減らすことができます。この属性のリストは、検索フィルターの後に表示されなければなりません。例は、「属性のサブセットの表示」を参照してください。属性の一覧が指定されていない場合、検索はディレクトリーで設定されているアクセスコントロールで許可されているすべての属性の値を返しますが、運用上の属性は例外となります。操作属性を検索結果として返すためには、検索コマンドの中で明示的に指定する必要があります。オブジェクトのすべての操作属性を返すには、
+
を指定します。明示的に指定した操作属性に加えて通常の属性を取得するには、ldapsearch コマンドの属性一覧でアスタリスク (*) を使用します。一致する DN の一覧のみを取得するには、特別な属性 1.1 を使用します。以下に例を示します。# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com \ -b "dc=example,dc=com" -x "(objectclass=inetorgperson)" 1.1
14.3.2. 一般的に使用される ldapsearch オプション
-x
引数を使用して SASL を無効にし、他の接続方法を許可します。
オプション | 説明 | |||
---|---|---|---|---|
-b | 検索の開始点を指定します。ここで指定する値は、現在データベースに存在する識別名である必要があります。これは、LDAP_BASEDN 環境変数がベース DN に設定されている場合は任意です。このオプションで指定する値は、単一引用符または二重引用符で指定する必要があります。以下に例を示します。
-b "cn=Barbara Jensen,ou=Product Development,dc=example,dc=com"ルート DSE エントリーを検索するには、-b "" などの空の文字列を指定します。 | |||
-D | サーバーへの認証に使用する識別名を指定します。これは、サーバーによって匿名アクセスに対応している場合はオプションです。指定している場合、この値は Directory Server が認識する DN である必要があります。また、エントリーを検索する権限も必要です 例: -D "uid=bjensen,dc=example,dc=com" | |||
-H |
サーバーへの接続に使用する LDAP URL を指定します。従来の LDAP URL の場合は、以下の形式になります。
ldap[s]://hostname[:port]ポート は任意です。ポートを使用しないと、LDAP ポートの場合は 389、LDAPS ポートの場合は 636 がデフォルトで使用されます。
これは LDAPI URL を使用することもできます。各要素は、スラッシュ (/) ではなく、HTML の 16 進コード %2F で区切られています。
ldapi://%2Ffull%2Fpath%2Fto%2Fslapd-example.socketLDAPI の場合は、サーバーがリッスンする LDAPI ソケットの完全パスおよびファイル名を指定します。この値は LDAP URL として解釈されるため、パスおよびファイル名のスラッシュ (/) をエスケープ処理して、URL エスケープ値 %2F としてエスケープする必要があります。 -h および -p の代わりに -H オプションが使用されます。
| |||
-h | Directory Server がインストールされているマシンのホスト名または IP アドレスを指定します (例: -h server.example.com)。ホストが指定されない場合、ldapsearch は localhost を使用します。
注記
Directory Server は、IPv4 アドレスと IPv6 アドレスの両方に対応します。
| |||
-l | 検索要求が完了するまで待つ最大秒数を指定します (例: -l 300)。nsslapd-timelimit 属性のデフォルト値は 3600 秒です。指定された値に関係なく、ldapsearch はサーバーの nsslapd-timelimit 属性によって許可されるよりも長く待機します。 | |||
-p | Directory Server が使用する TCP ポート番号を指定します (例: -p 1049)。デフォルトは 389 です。
-h が指定されている場合は、デフォルト値が指定されていても -p も指定する必要があります。
| |||
-s scope | 検索の範囲を指定します。範囲は以下のいずれかになります。
| |||
-W |
パスワードの入力を要求します。このオプションが設定されていない場合は、匿名アクセスが使用されます。
あるいは、
-w オプションを使用して、パスワードをそのユーティリティーに渡します。他のユーザーのプロセス一覧にパスワードが表示され、シェルの履歴に保存されていることに注意してください。
| |||
-x | 単純なバインドを許可するためにデフォルトの SASL 接続を無効にします。 | |||
-Y SASL_mechanism |
認証に使用する SASL メカニズムを設定します。メカニズムが設定されていない場合、
ldapsearch はサーバーがサポートする最適なメカニズムを選択します。
-x を使用しない場合は、-Y オプションを使用する必要があります。
| |||
-z number | 検索リクエストへの応答で返すエントリーの最大数を設定します。この値は、ルート DN を使用してバインディングする際にサーバー側の nsslapd-sizelimit パラメーターを上書きします。wibrown> |
14.3.3. 特殊文字の使用
-D "cn=Barbara Jensen,ou=Product Development,dc=example,dc=com"
14.4. LDAP 検索フィルター
attribute operator value
buildingname>=alpha
buildingname
が属性、>= が演算子、および alpha が値となります。フィルターは、異なる属性をブール値演算子とともに使用するように定義することもできます。
businessCategory
属性の値が Example*Net product line の社員をすべて検索するには、検索フィルターに以下の値を入力します。
Example\5c2a*Net product line
14.4.1. 検索フィルターの属性の使用
manager
属性を持つすべてのエントリーを返します。
"(manager=*)"
"(cn=babs jensen)"
cn: babs jensen cn;lang-fr: babs jensen
"(description=*X.500*)" "(sn=*nderson)" "(givenname=car*)"
14.4.2. 検索フィルターでの演算子の使用
"(employeeNumber>=500)" "(sn~=suret)" "(salary<=150000)"
検索タイプ | 演算子 | 説明 |
---|---|---|
等号 | = | 指定された値と完全に一致する属性値が含まれるエントリーを返します (例: cn=Bob Johnson) |
部分文字列 | =string* string | 指定の部分文字列が含まれる属性が含まれるエントリーを返します たとえば、cn=Bob* cn=*Johnson cn=*John* cn=B*John になります。アスタリスク (*) はゼロ (0) 以上の文字を示します。 |
以上 | >= | 指定された値以上の属性を含むエントリーを返します たとえば、build name >= alpha です。 |
より小か等しい | <= | 指定された値以下の属性が含まれるエントリーを返します たとえば、builds name <= alpha のようになります。 |
存在 | =* | 指定属性の 1 つ以上の値が含まれるエントリーを返します (例: cn=* telephoneNumber=* manager=*)。 |
概算値 | ~= | 指定した属性を含むエントリーを、検索フィルターで指定された値とほぼ等しい値で返します。たとえば、cn~=suret l~=san fransico は cn=sarette l=san francisco を返す可能性があります。 |
14.4.3. 複合検索フィルターの使用
(Boolean-operator(filter)(filter)(filter)...)
(!(cn=Ray Kultgen)) (!(objectClass=person))
(Boolean-operator(filter)((Boolean-operator(filter)(filter)))
(&(ou=Marketing)(!(description=*X.500*)))
(&(ou=Marketing)(!(description=*X.500*))(|(manager=cn=Julie Fulmer,ou=Marketing,dc=example,dc=com)(manager=cn=Cindy Zwaska,ou=Marketing,dc=example,dc=com)))
(&(!(objectClass=person))(cn~=printer3b))
演算子 | 記号 | 説明 |
---|---|---|
AND | & | 文が true になるには、指定したフィルターはすべて true である必要があります。例: (&(filter)(filter)(filter)...) |
OR | | | 文が true になるには、少なくとも 1 つのフィルターを true にする必要があります。例: (|(filter)(filter)(filter)...) |
NOT | ! | 文が true になるには、指定の文が true にならないようにする必要があります。NOT 演算子の影響を受けるフィルターは 1 つだけです。例: (!(filter)) |
- 一番内側から外側に向かって、親表現が優先されます。
- 左から右へのすべての式。
14.4.4. 一致するルールの使用
- EQUALITY は、同じ一致の 2 つの値を比較する方法を指定します。たとえば、「Fred」および「FRED」などの文字列の処理方法です。等価をテストする検索フィルター (attribute=value など) は EQUALITY ルールを使用します。等価 (eq) インデックスは EQUALITY ルールを使用してインデックスキーを生成します。更新操作は EQUALITY ルールを使用して、値を比較して、エントリーにすでにある値と比較します。
- ORDERING は、2 つの値を比較して、ある値が別の値以上であるかを確認できます。範囲 (例: attribute<=value または attribute>=value) を設定する検索フィルターは、ORDERING ルールを使用します。ORDERING ルールを持つ属性のインデックスは等価値の順序です。
- SUBSTR は、部分文字列照合を行う方法を指定します。部分文字列検索フィルター (例: attribute=*partial_string* または attribute=*end_string) は SUBSTR ルールを使用します。部分文字列 (サブ) インデックスは SUBSTR ルールを使用してインデックスを生成します。
例14.1 マッチングルールおよびカスタム属性
MyFirstName
という名前のカスタム属性タイプと、caseExactIA5Match の EQUALITY マッチングルールを作成します。MyFirstName
の値が Fred のエントリーは、(MyFirstName=Fred) のフィルターを使用した検索で返されますが、(MyFirstName=FRED) および (MyFirstName=fred) のフィルターでは返されません。Fred、FRED、および fred はすべて有効な IA5 文字列値ですが、caseExactIA5Match ルールを使用した場合一致しません。
MyFirstName
を定義する必要があります。
(MyFirstName:caseIgnoreIA5Match:
=fred)
nsMatchingRule
属性を使用して設定できます。
attr:matchingRule:=value
- attr は、
cn
やmail
など、検索されるエントリーに属する属性です。 - matchingRule は、必要な構文に従って属性値と一致するために使用するルールの名前または OID を含む文字列です。
- value は、検索する属性値か、比較演算子および検索する属性値のいずれかです。フィルターの値の構文は、使用されるマッチングルール形式によって異なります。
- ビット単位の AND 一致
- ビット単位の AND 一致を実行します。OID: 1.2.840.113556.1.4.803互換性のある構文: 通常、
Integer
および数値の文字列で使用されます。Directory Server は自動的に数値の文字列を整数に変換します。 - ビット単位の OR 一致
- ビット単位の OR 一致を実行します。OID: 1.2.840.113556.1.4.804互換性のある構文: 通常、
Integer
および数値の文字列で使用されます。Directory Server は自動的に数値の文字列を整数に変換します。 - booleanMatch
- 照合する値が TRUE または FALSE かを評価します。OID: 2.5.13.13互換性のある構文: ブール値
- caseExactIA5Match
- 値の大文字と小文字を区別する比較を行います。OID: 1.3.6.1.4.1.1466.109.114.1互換性のある構文:
IA5
構文、URI - caseExactMatch
- 値の大文字と小文字を区別する比較を行います。OID: 2.5.13.5互換性のある構文: Directory String、Printable String、OID
- caseExactOrderingMatch
- 大文字と小文字を区別する範囲検索が可能になります (「より小さい」および「より大きい」)。OID: 2.5.13.6互換性のある構文: Directory String、Printable String、OID
- caseExactSubstringsMatch
- 大文字と小文字を区別した部分文字列とインデックスの検索を実行します。OID: 2.5.13.7互換性のある構文: Directory String、Printable String、OID
- caseIgnoreIA5Match
- 値に対して大文字と小文字を区別しない比較を実行します。OID: 1.3.6.1.4.1.1466.109.114.2互換性のある構文:
IA5
構文、URI - caseIgnoreIA5SubstringsMatch
- 部分文字列およびインデックスで大文字と小文字を区別しない検索を実行します。OID: 1.3.6.1.4.1.1466.109.114.3互換性のある構文:
IA5
構文、URI - caseIgnoreListMatch
- 値に対して大文字と小文字を区別しない比較を実行します。OID: 2.5.13.11互換性のある構文: 住所
- caseIgnoreListSubstringsMatch
- 部分文字列およびインデックスで大文字と小文字を区別しない検索を実行します。OID: 2.5.13.12互換性のある構文: 住所
- caseIgnoreMatch
- 値に対して大文字と小文字を区別しない比較を実行します。OID: 2.5.13.2互換性のある構文: Directory String、Printable String、OID
- caseIgnoreOrderingMatch
- 大文字と小文字を区別しない範囲検索が可能になります (「より小さい」および「より大きい」)。OID: 2.5.13.3互換性のある構文: Directory String、Printable String、OID
- caseIgnoreSubstringsMatch
- 部分文字列およびインデックスで大文字と小文字を区別しない検索を実行します。OID: 2.5.13.4互換性のある構文: Directory String、Printable String、OID
- distinguishedNameMatch
- 識別名の値を比較します。OID: 2.5.13.1互換性のある構文: 識別名(DN)
- generalizedTimeMatch
- 一般化された時間形式の値を比較します。OID: 2.5.13.27互換性のある構文: 一般化時刻
- generalizedTimeOrderingMatch
- 一般化された時間形式の値の範囲検索 (「より小さい」および「より大きい」) が可能になります。OID: 2.5.13.28互換性のある構文: 一般化時刻
- integerMatch
- 整数値を評価します。OID: 2.5.13.14互換性のある構文: 整数
- integerOrderingMatch
- 整数値に範囲化された検索が可能になります (「より小さい」および「より大きい」)。OID: 2.5.13.15互換性のある構文: 整数
- keywordMatch
- 指定した検索値を、属性値の文字列と比較します。OID: 2.5.13.33互換性のある構文: ディレクトリー文字列
- numericStringMatch
- より一般的な数値を比較します。OID: 2.5.13.8互換性のある構文: 数値文字列
- numericStringOrderingMatch
- 複数の一般的な値に対する範囲検索 (「より小さい」および「より大きい」) が可能になります。OID: 2.5.13.9互換性のある構文: 数値文字列
- numericStringSubstringMatch
- より一般的な数値を比較します。OID: 2.5.13.10互換性のある構文: 数値文字列
- objectIdentifierMatch
- オブジェクト識別子 (OID) 値を比較します。OID: 2.5.13.0互換性のある構文: OID
- octetStringMatch
- octet 文字列の値を評価します。OID: 2.5.13.17互換性のある構文: オクテット文字列
- octetStringOrderingMatch
- 一連のオクテット文字列値で範囲検索 (「より小さい」および「より大きい」) をサポートします。OID: 2.5.13.18互換性のある構文: オクテット文字列
- telephoneNumberMatch
- 電話番号の値を評価します。OID: 2.5.13.20互換性のある構文: 電話番号
- telephoneNumberSubstringsMatch
- 電話番号の値に対して部分文字列とインデックス検索を行います。OID: 2.5.13.21互換性のある構文: 電話番号
- uniqueMemberMatch
- 名前と UID の値を比較します。OID: 2.5.13.23互換性のある構文: 名前および任意の UID
- wordMatch
- 指定した検索値を、属性値の文字列と比較します。このマッチングルールは大文字と小文字を区別しません。OID: 2.5.13.32互換性のある構文: ディレクトリー文字列
マッチングルール | オブジェクト識別子 (OID) |
---|---|
英語 (大文字と小文字を区別する順序の一致) | 2.16.840.1.113730.3.3.2.11.3 |
アルバニア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.44.1 |
アラビア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.1.1 |
ベラルーシ語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.2.1 |
ブルガリア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.3.1 |
カタロニア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.4.1 |
中国語: 簡体字 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.49.1 |
中国語: 繁体字 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.50.1 |
クロアチア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.22.1 |
チェコ語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.5.1 |
デンマーク語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.6.1 |
オランダ語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.33.1 |
オランダ語: ベルギー (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.34.1 |
英語 - アメリカ (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.11.1 |
英語 - カナダ語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.12.1 |
英語: アイルランド (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.14.1 |
エストニア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.16.1 |
フィンランド語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.17.1 |
フランス語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.18.1 |
フランス語: ベルギー (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.19.1 |
フランス語 - カナダ語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.20.1 |
フランス語 - スイス (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.21.1 |
ドイツ語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.7.1 |
ドイツ語 - オーストリア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.8.1 |
ドイツ語: スイス (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.9.1 |
ギリシャ語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.10.1 |
ヘブライ語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.27.1 |
ハンガリー語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.23.1 |
アイスランド語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.24.1 |
イタリア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.25.1 |
イタリア語: スイス (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.26.1 |
日本語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.28.1 |
韓国語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.29.1 |
ラトビア語、レット語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.31.1 |
リトアニア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.30.1 |
マケドニア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.32.1 |
ノルウェー語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.35.1 |
ノルウェー語 - ブークモール (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.36.1 |
ノルウェー語 - ニーノルスク (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.37.1 |
ポーランド語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.38.1 |
ルーマニア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.39.1 |
ロシア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.40.1 |
セルビア語 - キリル文字 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.45.1 |
セルビア語 - ラテン語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.41.1 |
スロバキア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.42.1 |
スロベニア語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.43.1 |
スペイン語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.15.1 |
スウェーデン語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.46.1 |
トルコ語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.47.1 |
ウクライナ語 (大文字と小文字を区別しない順序一致) | 2.16.840.1.113730.3.3.2.48.1 |
マッチングルール | オブジェクト識別子 (OID) |
---|---|
英語 (大文字と小文字を区別する部分文字列の一致) | 2.16.840.1.113730.3.3.2.11.3.6 |
アルバニア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.44.1.6 |
アラビア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.1.1.6 |
ベラルーシ語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.2.1.6 |
ブルガリア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.3.1.6 |
カタロニア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.4.1.6 |
中国語 - 簡体字 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.49.1.6 |
中国語 - 繁体字 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.50.1.6 |
クロアチア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.22.1.6 |
チェコ語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.5.1.6 |
デンマーク語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.6.1.6 |
オランダ語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.33.1.6 |
オランダ語: ベルギー (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.34.1.6 |
英語 - アメリカ (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.11.1.6 |
英語: カナダ (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.12.1.6 |
英語: アイルランド (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.14.1.6 |
エストニア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.16.1.6 |
フィンランド語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.17.1.6 |
フランス語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.18.1.6 |
フランス語: ベルギー (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.19.1.6 |
フランス語: カナダ (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.20.1.6 |
フランス語: スイス (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.21.1.6 |
ドイツ語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.7.1.6 |
ドイツ語 - オーストリア (大文字小文字を区別しない文字列一致) | 2.16.840.1.113730.3.3.2.8.1.6 |
ドイツ語: スイス (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.9.1.6 |
ギリシャ語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.10.1.6 |
ヘブライ語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.27.1.6 |
ハンガリー語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.23.1.6 |
アイスランド語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.24.1.6 |
イタリア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.25.1.6 |
イタリア語: スイス (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.26.1.6 |
日本語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.28.1.6 |
韓国語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.29.1.6 |
ラトビア語、レット語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.31.1.6 |
リトアニア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.30.1.6 |
マケドニア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.32.1.6 |
ノルウェー語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.35.1.6 |
ノルウェー語 - ブークモール (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.36.1.6 |
ノルウェー語 - ニーノルスク (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.37.1.6 |
ポーランド語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.38.1.6 |
ルーマニア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.39.1.6 |
ロシア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.40.1.6 |
セルビア語 - キリル文字 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.45.1.6 |
セルビア語 - ラテン語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.41.1.6 |
スロバキア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.42.1.6 |
ストべニア語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.43.1.6 |
スペイン語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.15.1.6 |
スウェーデン語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.46.1.6 |
トルコ語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.47.1.6 |
ウクライナ語 (大文字と小文字を区別しない部分文字列一致) | 2.16.840.1.113730.3.3.2.48.1.6 |
14.5. 一般的な ldapsearch の例
- 検索は、ディレクトリー内のすべてのエントリーに対するものです。
- このディレクトリーは、検索および読み取りの匿名アクセスをサポートするように設定されます。つまり、検索を実行するためにバインド情報を提供する必要はありません。匿名アクセスの詳細は、「匿名アクセスの付与」を参照してください。
- サーバーは、server.example.com という名前のホストにあります。
- サーバーはポート番号 389 を使用します。これはデフォルトのポートであるため、ポート番号は検索リクエストで送信する必要がありません。
- TLS は、ポート 636 のサーバー (デフォルトの LDAPS ポート番号) に対して有効になります。
- すべてのデータが格納される接尾辞は dc=example,dc=com です。
14.5.1. すべてのエントリーの返信
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)"
objectclass
属性は常にインデックス化されるため、すべてのエントリーを返すための便利な検索フィルターになります。
14.5.2. コマンドラインでの検索フィルターの指定
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "cn=babs jensen"
14.5.3. ルート DSE エントリーの検索
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -b "" -s base "objectclass=*"
14.5.4. スキーマエントリーの検索
# ldapsearch -o ldif-wrap=no -D "cn=Directory Manager" -W -b "cn=schema" \ '(objectClass=subSchema)' -s sub objectClasses attributeTypes matchingRules \ matchingRuleUse dITStructureRules nameForms ITContentRules ldapSyntaxes
14.5.5. LDAP_BASEDN の使用
# export LDAP_BASEDN="dc=example,dc=com" # ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "cn=babs jensen"
14.5.6. 属性のサブセットの表示
+
を使用してすべての操作属性を返します。
cn
属性および sn
属性を表示するには、コマンドライン呼び出しを使用します。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" sn cn
14.5.7. 操作属性の検索
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" '+'
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" creatorsName createTimestamp modifiersName modifyTimestamp
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)" "*" aci
14.5.8. ファイルを使用した検索フィルターの指定
sn=Francis givenname=Richard
searchdb
という名前のファイルにフィルターを指定します。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -f searchdb
givenname
属性、および sn
属性のみが返されます。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -f searchdb sn givenname
14.5.9. 検索フィルターでコンマを含む DN の指定
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -s base -b "l=Bolivia\,S.A.,dc=example,dc=com" "objectclass=*"
14.5.10. クライアント証明書の Directory Server へのバインド
14.5.11. 言語マッチングルールでの検索
attr:matchingRule:=value
departmentNumber:2.16.840.1.113730.3.3.2.46.1:=>= N4709
14.5.12. Bit Field の値での属性の検索
"(UserAccountControl:1.2.840.113556.1.4.803:=2)"
"(UserAccountControl:1.2.840.113556.1.4.803:=6)”
"(UserAccountControl:1.2.840.113556.1.4.804:=6)"
14.6. 永続検索の使用
- 一貫性のあるローカルキャッシュと現在のローカルキャッシュを保持します。クライアントは、ディレクトリーに接続してクエリーを試行する前にローカルキャッシュをクエリーします。永続検索は、これらのクライアントのパフォーマンスを改善するのに必要なローカルキャッシュを提供します。
- ディレクトリーアクションを自動的に開始します。永続キャッシュはエントリーの変更時に自動的に更新され、永続検索結果ではエントリーに対して実行された変更の種類を表示できます。別のアプリケーションでは、その出力を利用してエントリーを自動的に更新することができます。たとえば、新しいユーザーのためにメールサーバーにメールアカウントを自動的に作成したり、固有のユーザー ID 番号を生成したりすることができます。
- クライアントの接続解除時に ldapsearch は通知を送信せず、検索が切断されている間に変更についての通知が送信されません。これは、クライアントのキャッシュが切断されても更新されないことを意味し、切断中に変更した新しいエントリー、変更されたエントリー、または削除されたエントリーでキャッシュを更新する適切な方法はありません。
- 攻撃者は、サービス拒否攻撃を開始するために多数の永続検索を開くことができます。
- 永続的な検索では、Directory Server とクライアント間で TCP 接続を開放する必要があります。これは、サーバーが多くのクライアント接続を許可し、アイドル状態の接続を閉じる方法を持つ場合にのみ行う必要があります。
[12/Jan/2009:12:51:54.899423510 -0500] conn=19636710736396323 op=0 SRCH base="dc=example,dc=com" scope=2 filter="(objectClass=person)" attrs=ALL options=persistent
14.7. 指定したコントロールでの検索
supportedControls
属性に制御を定義しています。これらの中には、レプリケーションのようなサーバーの操作を定義するものもあれば、Get Effective Rights や、クライアントが LDAP 操作でサーバーに渡すことができる制御の逆参照などの拡張操作を許可するものもあります。
-E
オプションを使用して指定できます。制御 OID、ldapsearch の重大度、およびその制御操作に必要な情報を指定します。
-E '[!]control_OID:control_information'
14.7.1. 効果のあるユーザー権限の取得
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=jsmith,ou=people,dc=example,dc=com' "(objectclass=*)"
14.7.2. サーバー側のソートの使用
-E
フラグと sss
制御エイリアスを使用して、他の制御操作として実行されます。操作の構造は、結果をソートし、任意でソート順序および順序ルールである属性を設定します。
-E sss=[-]attribute_name:[ordering_rule_OID]
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x -E sss=-uidNumber:2.5.13.15 "(objectclass=*)"
14.7.3. 逆参照検索の実行
-E 'deref=deref_attribute:list_of_attributes'
図14.3 簡単な参照検索コマンド
member
属性を deref_attribute として使用するように指示します。その後、各メンバーの locality 属性を返します。
# ldapsearch -x -D "cn=Directory Manager" -W -b "cn=Example,ou=Groups,dc=example,dc=com" -E 'deref=member:mail,cn' "(objectclass=*)" # Engineers, Groups, example.com dn: cn=Engineers,ou=Groups,dc=example,dc=com control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAADNMIQAAAA1BAZtZW1iZXIEK2NuPURld mVsb3BlcnMsIG91PUdyb3VwcywgZGM9ZXhhbXBsZSxkYz1jb20whAAAADIEBm1lbWJlcgQoY249VG VzdGVycywgb3U9R3JvdXBzLCBkYz1leGFtcGxlLGRjPWNvbTCEAAAAVAQGbWVtYmVyBCp1aWQ9ZW5 nLCBvdT1lbmdpbmVlcmluZywgZGM9ZXhhbXBsZSxkYz1jb22ghAAAABowhAAAABQEAWwxhAAAAAsE CUNhbWJyaWRnZQ== # member: <mail=jsmith@example.com><cn=John Smith>;uid=jsmith,ou=people,dc=example,dc=com objectClass: top objectClass: inetuser objectClass: groupofnames cn: Engineers member: uid=jsmith,ou=people,dc=example,dc=com
14.7.4. 単純なページ結果の使用
簡単なページ結果の仕組み
ページ結果の簡単な検索を開始すると、以下のようになります。
- クライアントは検索をサーバーに送り、ページ付けの結果が制御し、最初のページで返すレコードの数を制御します。
- Directory Server がデータの返信を開始する前に、サーバーは合計で何件のレコードを返信できるかの見積もりを生成します。レコードの推定値は、正確な数ではありません。返されるレコードの合計数は推定値よりも小さくなります。このようなシナリオの理由は以下の通りです。
- 検索フィルターで使用される属性はインデックスに存在しません。最適な結果を得るには、クエリーされた属性をすべてインデックス化する必要があります。
- エントリーがクライアントに送信される前に、アクセス制御リスト (ACL) が検証されます。パーミッションが十分にないため、エントリーが返されなくなります。
推定値を生成した後、サーバーは最初の結果セット、Cookie、および推定レコード数を送信します。 - 返されたレコードがクライアントに表示されます。ユーザーは、次のリクエストで返されるレコードの数を入力できるようになりました。要求された番号は、Cookie と一緒にサーバーに送信されます。
- サーバーは要求された数のレコードをデータベースから取得し、それらを Cookie と共にクライアントに送信します。
- 前述の 2 つのステップは、すべてのレコードが送信されるか、検索がキャンセルされるまで繰り返されます。
シンプルなページ結および OpenLDAP ツール
ldapsearch の簡単なページの結果検索オプションの形式は以下のとおりです。
-E pg=size
ldapsearch -x -D "cn=Directory Manager" -W -b "ou=Engineers,ou=People,dc=example,dc=com" -E pg=3 "(objectclass=*)" cn dn: uid=jsmith,ou=Engineers,ou=People,dc=example,dc=com cn: John Smith dn: uid=bjensen,ou=Engineers,ou=People,dc=example,dc=com cn: Barbara Jensen dn: uid=hmartin,ou=Engineers,ou=People,dc=example,dc=com cn: Henry Martin Results are sorted. next page size (3): 5
ページングされた簡素な結果およびサーバー一致
ページングされた簡素な結果は、サーバー側のソートと併用できます。サーバー側のソートは、クライアントではなくサーバーでソートプロセスを実行する制御です。これは通常、特定のマッチングルールを使用する検索を行います。(この動作は RFC 2891 で定義されています。) OpenLDAP クライアントツールは、簡素なページングされた結果制御でサーバー側のソートをサポートしませんが、Perl Net::LDAP などのその他の LDAP ユーティリティーは両方をサポートします。
1 つの接続に複数の簡素なページングされた結果要求
一部のクライアントは Directory Server への接続を 1 つ開きますが、簡素なページングされた結果拡張を使用する複数の検索要求など、複数の操作要求を送信します。
VLV インデックスと対照的な、簡素なページングされた結果
VLV インデックスは簡素なページングされた結果に類似しているため、それらのインデックスは、結果の閲覧可能な一覧も返すことになります。主な違いは、リストの生成方法です。簡素なページングされた結果は検索ごとに計算されますが、VLV インデックスは永続的なリストになります。全体的に、VLV インデックスは検索速度が速いですが、サーバー側の設定が必要で、サーバーが維持するためのオーバーヘッドがあります。
14.7.5. 読み取り前および後のエントリーレスポンス制御
description
属性を更新し、変更前および変更後に値を表示するには、次のコマンドを実行します。
#ldapmodify -D "cn=Directory Manager" -W -x \
-e \!preread=description -e \!postread=description
dn: uid=user,ou=People,dc=example,dc=com changetype: modify replace: description description: new description modifying entry "uid=user,ou=People,dc=example,dc=com" control: 1.3.6.1.1.13.1 false ZCkEJXVpZD1qdXNlcixvdT1QZW9wbGUsZGM9ZXhhbXBsZSxk Yz1jb20wAA== # ==> preread dn: uid=user,ou=People,dc=example,dc=com description: old description # <== preread control: 1.3.6.1.1.13.2 false ZEsEJXVpZD1qdXNlcixvdT1QZW9wbGUsZGM9ZXhhbXBsZSxk Yz1jb20wIjAgBAtkZXNjcmlwdGlvbjERBA9uZXcgZGVzY3JpcHRpb24= # ==> postread dn: uid=user,ou=People,dc=example,dc=com description: new description # <== postread
第15章 レプリケーションの管理
15.1. レプリケーションの概要
15.1.1. 複製されるディレクトリーユニット
15.1.2. 読み取り/書き込みレプリカおよび読み取り専用レプリカ
15.1.3. サプライヤーとコンシューマー
- レプリケーションをカスケードするとき、ハブサーバーは、コンシューマーに提供する読み取り専用レプリカを保持します。「カスケードレプリケーション」 に詳細情報があります。
- マルチマスターレプリケーションの場合、マスター は同じ情報についてサプライヤーとコンシューマーの両方を設定します。詳細は、「マルチマスターレプリケーション」 を参照してください。
15.1.4. Changelog
2bak.pl
ユーティリティーまたは Directory Server Console を使用します。いずれの方法でも、バックアップを開始する前に RUV がデータベースに書き込まれます。
15.1.5. レプリケーション ID
- これは、サプライヤーサーバー ではなく、コンシューマーサーバーに作成されます。
- 別のサーバーから更新を受け取る すべて のサーバー (つまり、すべてのハブまたは専用のコンシューマー) でこのエントリーを作成します。
- レプリカがコンシューマーまたはハブとして設定されている場合は、このエントリーを、レプリケーションの更新を実行する権限のあるものとして指定する必要があります。
- レプリカ合意はサプライヤーサーバーで作成され、このエントリーの DN をレプリカ合意に指定する必要があります。
- このエントリーは、特別なユーザープロファイルで、そのレプリカ合意に関係するデータベースのコンシューマーサーバーで定義されるアクセス制御ルールをすべて回避します。
15.1.6. レプリカ合意
- 複製されるデータベース。
- データがプッシュされるコンシューマーサーバー
- レプリケーションが実行する曜日および時間帯
- サプライヤーサーバーがバインドに使用する必要のある DN および認証情報 (レプリケーションマネージャーエントリーまたはサプライヤーバインド DN)
- 接続をセキュアにする方法 (TLS、クライアント認証)。
- 複製されない属性 (一部レプリケーション)
15.1.7. 一部レプリケーションを使用した属性のサブセットの複製
nsDS5ReplicatedAttributeList
) は、一部レプリケーションを有効にするために常に設定される必要があります。唯一の属性が設定されている場合は、増分更新と合計更新の両方に適用されます。任意の nsDS5ReplicatedAttributeListTotal
属性は、更新の合計に追加の一部レプリケーション一覧を設定します。これは、「合計更新および増分更新での異なる一部レプリケーション属性の設定」で説明されています。
nsds5ReplicaStripAttrs
属性は、空のレプリケーションイベントでは送信できず、更新シーケンスから削除される属性の一覧を追加します。これには、modifiersName
のような運用上の利便性が含まれます。
15.1.7.1. レプリケーションのキープアライブエントリー
keepalivetimestamp
属性が更新され、コンシューマーに複製されます。keepalivetimestamp
属性はレプリケーションから除外されないため、キープアライブエントリーの更新は複製され、コンシューマー上の CSN が更新され、サプライヤー上のものと等しくなります。次回サプライヤーをコンシューマーに接続する際には、コンシューマーの CSN より新しい更新のみが検索されます。これにより、サプライヤーが送信する新規更新の検索に費やされた時間が短縮されます。
dn: cn=repl keep alive 14,dc=example,dc=com objectclass: top objectclass: ldapsubentry objectclass: extensibleObject cn: repl keep alive 14 keepalivetimestamp: 20170227190346Z
- 一部レプリカ合意が 100 を超える更新を省略し、レプリケーションセッションの終了前に更新を送信しません。
- マスターがコンシューマーを初期化すると、最初に独自のキープアライブエントリーを作成します。マスターでもあるコンシューマーは、別のコンシューマーも初期化しない限り、独自のキープアライブエントリーを作成しません。
15.2. コマンドラインでのレプリケーションの設定
- すべてのコンシューマー、ハブ、および複数マスターサプライヤー(「サプライヤーバインド DN エントリーの作成」)にサプライヤーバインド DN を作成します。
- 対応するデータベースおよび接尾辞がレプリカのいずれかに存在しない場合は、これを作成します(「接尾辞の作成」)。
- サプライヤーレプリカ(「コマンドラインでのサプライヤーの設定」)を設定します。
- コンシューマーを設定します(「コマンドラインを使用したコンシューマーの設定」)。
- レプリケーションをカスケードするためのハブ(「コマンドラインでのハブの設定」)を設定します。
- レプリカ合意(「コマンドラインからのレプリカ合意の設定」)を作成します。カスケードレプリケーションの場合は、サプライヤーとハブ間の合意を作成し、ハブとコンシューマー間の合意を作成します。マルチマスターの場合は、すべてのサプライヤーとコンシューマー間の合意を作成します。
- 最後に、レプリカ合意の作成時にコンシューマーが初期化されていない場合は、すべてのコンシューマー(「コマンドラインからのコンシューマーオンラインの初期化」)を初期化します。
15.2.1. コマンドラインでのサプライヤーの設定
- サプライヤーサーバーで ldapmodify を使用して changelog エントリーを作成します。
例15.1 Changelog エントリーの例
# ldapmodify -D "cn=Directory Manager" -W -x -h supplier1.example.com -v -a dn: cn=changelog5,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: changelog5 nsslapd-changelogdir: /var/lib/dirsrv/slapd-instance/changelogdb nsslapd-changelogmaxage: 10d
changelog には 2 つの重要な属性があります。nsslapd-changelogdir
changelog が保持されるディレクトリーを設定します。nsslapd-changelogmaxage
changelog が保持する期間を設定します。changelog は非常に大きくなる可能性があるため、これは、サーバーのパフォーマンスに影響を与え、ディスク領域を占有しないように changelog をトリミングするのに役立ちます。このパラメーターが設定されていない場合、デフォルトは持続するように changelog になります。
changelog エントリー属性は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 に記載されています。 - サプライヤーレプリカを作成します。
例15.2 サプライヤーレプリカエントリーの例
# ldapmodify -D "cn=Directory Manager" -W -x -h supplier1.example.com -v -a dn: cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config changetype: add objectclass: top objectclass: nsds5replica objectclass: extensibleObject cn: replica nsds5replicaroot: dc=example,dc=com nsds5replicaid: 7 nsds5replicatype: 3 nsds5flags: 1 nsds5ReplicaPurgeDelay: 604800 nsds5ReplicaBindDN: cn=replication manager,cn=config
重要以下の例に示すように、レプリカエントリーのcn
パラメーターを replica に設定する必要があります。Directory Server は、パラメーターを異なる値に設定するとエントリーを無視します。changelog エントリー属性は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 に記載されています。
15.2.2. コマンドラインを使用したコンシューマーの設定
- レプリカエントリーを作成します。
# ldapadd -D "cn=Directory Manager" -W -p 389 -h consumer.example.com -x dn: cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config objectclass: top objectclass: nsds5replica objectclass: extensibleObject cn: replica nsds5replicaroot: dc=example,dc=com nsds5replicaid: 65535 nsds5replicatype: 2 nsds5ReplicaBindDN: cn=replication manager,cn=config nsds5flags: 0
重要以下の例に示すように、レプリカエントリーのcn
パラメーターを replica に設定する必要があります。Directory Server は、パラメーターを異なる値に設定するとエントリーを無視します。このエントリーは、レプリケーションに参加しているようにデータベースと接尾辞を特定し、データベースがレプリカの種類を設定します。 nsslapd-referral
パラメーターをサプライヤーサーバーの LDAP URL に、nsslapd-state
を更新時に参照 するように設定します。以下に例を示します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h consumer.example.com -x dn: cn=dc\=example\,dc\=com,cn=mapping tree,cn=config changetype: modify replace: nsslapd-referral nsslapd-referral: ldap://supplier.example.com:389/dc\=example\,dc\=com - replace: nsslapd-state nsslapd-state: referral on update
15.2.3. コマンドラインでのハブの設定
- hub1.example.com などのハブサーバー で、ldapmodify を使用して changelog エントリーを作成します。
# ldapmodify -D "cn=Directory Manager" -W -x -h hub1.example.com -v -a dn: cn=changelog5,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: changelog5 nsslapd-changelogdir: /var/lib/dirsrv/slapd-instance/changelogdb
changelog には重要な属性が 1 つあります。nsslapd-changelogdir
は、changelog が保持されるディレクトリーを設定します。changelog エントリー属性は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 に記載されています。 - ハブホストで、レプリカエントリーを作成します。この ldapmodify コマンドは、dc=example ,dc= com サブツリーの hub1.example.com ホストに新しいハブレプリカを作成します。
# ldapmodify -D "cn=Directory Manager" -W -x -h hub1.example.com -v -a dn: cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config changetype: add objectclass: top objectclass: nsds5replica objectclass: extensibleObject cn: replica nsds5replicaid: 65535 nsds5replicaroot: dc=example,dc=com nsds5replicatype: 2 nsds5ReplicaPurgeDelay: 604800 nsds5ReplicaBindDN: cn=replication manager,cn=config nsds5flags: 1
重要以下の例に示すように、レプリカエントリーのcn
パラメーターを replica に設定する必要があります。Directory Server は、パラメーターを異なる値に設定するとエントリーを無視します。このエントリーは、レプリケーションに参加しているようにデータベースと接尾辞を特定し、データベースがレプリカの種類を設定します。
15.2.4. コマンドラインからのレプリカ合意の設定
- コンシューマーホスト(
nsds5replicahost
)およびポート(nsds5replicaport
) - コンシューマーにバインドするために使用するサプライヤーの DN(
nsds5ReplicaBindDN
)。 - サプライヤーがバインドする方法(
nsds5replicabindmethod
)。 - バインドメソッドおよび指定された DN に必要な認証情報(
nsDS5ReplicaCredentials
)。 - 複製されるサブツリー(
nsds5replicaroot
)。 - レプリケーションスケジュール(
nsds5replicaupdateschedule
) - 複製されない属性 (
nsds5replicatedattributelist
およびnsDS5ReplicatedAttributeListTotal
)。
例15.3 レプリカ合意エントリーの例
dn: cn=ExampleAgreement,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config objectclass: top objectclass: nsds5ReplicationAgreement cn: ExampleAgreement nsds5replicahost: consumer1 nsds5replicaport: 389 nsds5ReplicaBindDN: cn=replication manager,cn=config nsds5replicabindmethod: SIMPLE nsds5replicaroot: dc=example,dc=com description: agreement between supplier1 and consumer1 nsds5replicaupdateschedule: 0000-0500 1 nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE authorityRevocationList accountUnlockTime memberof nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE accountUnlockTime nsds5replicacredentials: secret
15.2.4.1. 証明書ベースの認証を使用するようにレプリケーションパートナーの設定
server2.example.com
という名前の新規サーバーを追加する方法を説明します。また、証明書ベースの認証を使用して、新規ホストと既存の server1.example.com
との間でレプリカ合意を設定する方法を説明します。
- 両方のホストで、証明書ベースの認証を設定します。詳細は「証明書ベースの認証の設定」を参照してください。
server1.example.com
ホスト上で:- 両方のサーバー (
cn=server1,example,dc=com
やcn=server2,dc=example,dc=com
など) にアカウントを作成し、クライアント証明書を対応するアカウントに追加します。詳細は、次を参照してください。両方のサーバーは、後でこれらのアカウントと証明書を使用して、相互にレプリケーション接続を確立するときに認証を行います。 cn=repl_server,ou=Groups,dc=example,dc=com
などのグループを作成し、両方のサーバーアカウントを追加します。「コマンドラインでのグループの作成」 を参照してください。- レプリカエントリーを作成し、
nsds5ReplicaBindDNGroup
属性を直前の手順で作成されたグループの DN に設定します。# ldapmodify -D "cn=Directory Manager" -W -p 636 -h server1.example.com -x dn: cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config changetype: add objectclass: top objectclass: nsds5replica objectclass: extensibleObject cn: replica nsds5replicaroot: dc=example,dc=com nsds5replicaid: 7 nsds5replicatype: 3 nsds5flags: 1 nsds5ReplicaPurgeDelay: 604800 nsds5replicabinddngroup: cn=repl_server,ou=Groups,dc=example,dc=com nsDS5ReplicaBindDNGroupCheckInterval: 0
重要以下の例に示すように、レプリカエントリーのcn
パラメーターを replica に設定する必要があります。Directory Server は、パラメーターを異なる値に設定するとエントリーを無視します。
- 新しいサーバーを初期化します。
server2.example.com
で、cn=Replication Manager,cn=config
などの一時的なレプリケーションマネージャーアカウントを作成します。「サプライヤーバインド DN エントリーの作成」 を参照してください。server1.example.com
で、認証用に直前の手順でアカウントを使用する一時的なレプリカ合意を作成します。# ldapmodify -D "cn=Directory Manager" -W -p 636 -h server1.example.com -x dn: cn=temporary_agreement,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config objectclass: top objectclass: nsds5ReplicationAgreement cn: temporary_agreement nsds5replicahost: server2.example.com nsds5replicaport: 636 nsds5replicabindmethod: SIMPLE nsds5ReplicaBindDN: cn=Replication Manager,cn=config nsds5replicacredentials: password_of_replication_manager_account nsds5replicaroot: dc=example,dc=com description: Temporary agreement between server1 and server2 nsds5replicaupdateschedule: 0000-0500 1 nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE authorityRevocationList accountUnlockTime memberof nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE accountUnlockTime nsds5BeginReplicaRefresh: start
この合意は、以前に作成したレプリケーションマネージャーアカウントを使用してデータベースを初期化します。この初期化前に、server2.example.com
のデータベースが空で、関連する証明書を持つアカウントは存在しません。したがって、データベースの初期化前に、証明書を使用してレプリケーションすることはできません。
- 新しいサーバーが初期化された後
server1.example.com
から一時的なレプリカ合意を削除します。# ldapdelete -D "cn=Directory Manager" -W -p 636 -h server1.example.com -x "cn=temporary_agreement,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config"
server2.example.com
から一時的なレプリケーションマネージャーアカウントを削除します。# ldapdelete -D "cn=Directory Manager" -W -p 636 -h server2.example.com -x "cn=Replication Manager,cn=config"
- 証明書ベースの認証を使用する両サーバーでレプリカ合意を作成します。
server1.example.com
上で:# ldapmodify -D "cn=Directory Manager" -W -p 636 -h server1.example.com -x dn: cn=example_agreement,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config objectclass: top objectclass: nsds5ReplicationAgreement cn: example_agreement nsds5replicahost: server2.example.com nsds5replicaport: 636 nsds5replicabindmethod: SSLCLIENTAUTH nsds5replicaroot: dc=example,dc=com description: Agreement between server1 and server2 nsds5replicaupdateschedule: 0000-0500 1 nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE authorityRevocationList accountUnlockTime memberof nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE accountUnlockTime nsDS5ReplicaTransportInfo: SSL
server2.example.com
上で:# ldapmodify -D "cn=Directory Manager" -W -p 636 -h server2.example.com -x dn: cn=example_agreement,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config objectclass: top objectclass: nsds5ReplicationAgreement cn: example_agreement nsds5replicahost: server1.example.com nsds5replicaport: 636 nsds5replicabindmethod: SSLCLIENTAUTH nsds5replicaroot: dc=example,dc=com description: Agreement between server2 and server1 nsds5replicaupdateschedule: 0000-0500 1 nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE authorityRevocationList accountUnlockTime memberof nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE accountUnlockTime nsDS5ReplicaTransportInfo: SSL
- レプリケーションが正しく機能していることを確認するには、レプリカ合意に
nsds5replicaLastUpdateStatus
属性を表示します。# ldapsearch -D "cn=Directory Manager" -W -p 636 -h server1.example.com -b "cn=example_agreement,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config" nsds5replicaLastUpdateStatus
可能なステータスの詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンス の付録 『レプリカ合意の状況』 を参照してください』。
15.2.5. コマンドラインからのコンシューマーオンラインの初期化
nsds5replicarefresh
属性をレプリカ合意エントリーに追加することで、コマンドラインからオンライン初期化を開始できます。レプリカ合意の作成時に属性が含まれる場合、初期化が開始されます。後で追加して、コンシューマーをいつでも初期化できます。この属性はデフォルトでは存在しないため、コンシューマーの初期化が完了すると自動的に削除されます。
- コンシューマーを初期化するサプライヤーサーバーでレプリカ合意の DN を検索します。以下に例を示します。
# ldapsearch -x -h supplier1.example.com -p 389 -D "cn=Directory Manager" -W -s sub -b cn=config "(objectclass=nsds5ReplicationAgreement)"
このコマンドは、サプライヤーに設定されたすべてのレプリカ合意を LDIF 形式で返します。初期化されるコンシューマーとのレプリカ合意の DN を取得します。これは、編集されるレプリカ合意です。 - レプリカ合意を編集し、
nsds5BeginReplicaRefresh
属性を追加します。# ldapmodify -D "cn=Directory Manager" -W -x -h supplier1.example.com dn: cn=ExampleAgreement,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config changetype: modify replace: nsds5BeginReplicaRefresh nsds5BeginReplicaRefresh: start
ldapmodify は入力を要求しません。LDIF ステートメントに入力するだけで、LDIF ステートメントが完了すると 2 回到達されます。Ctrl+C を押して ldapmodify ユーティリティーを閉じます。
nsds5BeginReplicaRefresh
属性はレプリカ合意エントリーから自動的に削除されます。
nsslapd-idletimeout
設定を十分な期間(または無制限の時間)に設定する必要があります。これにより、操作がタイムアウトする前にデータベース全体を初期化できるようにする必要があります。または、サプライヤーバインド DN エントリーの nsIdleTimeout
設定は、グローバル設定を変更しなくても、オンライン初期化操作を完了できるように設定することも可能です。
- コンシューマーを初期化するソースとして、1 つのサプライヤー( データマスター )を使用します。
- レプリカ合意の作成時にデータマスター を再初期化 しないでください。たとえば、server2 が server1 からすでに初期化されている場合は、server2 から server1 を初期化しないでください。
- マルチマスターシナリオでは、1 つのマスターからの設定内の他のすべてのマスターサーバーを初期化します。
- カスケードレプリケーションの場合は、サプライヤーからすべてのハブを初期化し、ハブからコンシューマーを初期化します。
15.3. レプリケーションシナリオ
15.3.1. 単一マスターレプリケーション
図15.1 単一マスターレプリケーション
15.3.2. マルチマスターレプリケーション
図15.2 マルチマスターレプリケーション(Two Masters)
図15.3 マルチマスターレプリケーション(4 つのマスター)
- 1 つのサプライヤーにアクセスできない場合に自動書き込みフェイルオーバー。
- 更新は、地理的に分散した環境のローカルサプライヤーで実行されます。
- ネットワークの速度。
- 送信および受信のレプリカ合意の数。最適なパフォーマンスを得るために、最大 8 アウトバウンドと 4 つの受信レプリカ合意を設定します。
15.3.3. カスケードレプリケーション
図15.4 カスケードレプリケーション
15.4. サプライヤーバインド DN エントリーの作成
- 一意である必要があります。
- サプライヤーサーバー ではなく、コンシューマーサーバー(またはハブ)に作成する必要があります。
- コンシューマーサーバーの実際のエントリーに対応する必要があります。
- 別のサーバーから 更新を受け取る すべてのサーバーで作成する必要があります。
- セキュリティー上の理由から、複製されたデータベースの一部にすることはできません。
- これは、サプライヤーサーバーのレプリカ合意で定義する必要があります。
- 大規模なデータベースの初期化プロセスを完了させるには、アイドルタイムアウトの期間を十分な制限に設定する必要があります。
nsIdleTimeOut
操作属性を使用すると、レプリケーションマネージャーエントリーがグローバルnsslapd-idletimeout
設定をオーバーライドできます。
dse.ldif
ファイルの cn=config エントリーの下に単純なエントリーを作成しないでください。シンプルな flat dse.ldif
設定ファイルの cn=cn=config エントリーは、通常のエントリーと同じ拡張性の高いデータベースに保存されません。その結果、多くのエントリーと、頻繁に更新される可能性のあるエントリーが cn=config に保存されると、パフォーマンスが低下します。ただし、Red Hat はパフォーマンス上の理由から、cn=config に単純なユーザーエントリーを保存しないことを推奨しますが、設定情報を一元化するため、cn=config に Directory Manager エントリーやレプリケーションマネージャー(サプライヤーのバインド DN)エントリーなどの特別なユーザーエントリーを保存すると便利です。
- Directory Server を停止します。サーバーが停止していない場合は、
dse.ldif
ファイルへの変更は保存されません。サーバーの停止に関する詳細は、「Directory Server インスタンスの起動および停止」 を参照してください。 dse.ldif
ファイルに、cn=replication manager,cn=config などの新規エントリーを作成します。userPassword
属性と値のペアを指定します。- 大規模なデータベースのレプリケーション初期化を完了できるように、レプリケーションユーザーに十分な時間制限を提供する
nsIdleTimeout
期間を設定します。 - パスワードの有効であるか、または有効になる場合は、レプリケーションマネージャーのエントリーでこれを無効にし、パスワードが期限切れになってレプリケーションが失敗するのを防ぎます。
userPassword
属性でパスワードの有効期限ポリシーを無効にするには、2038 0119031407Z の値でpasswordExpirationTime
属性を追加します。つまり、パスワードは期限切れになりません。 - Directory Server を再起動します。サーバーの起動の詳細は、「Directory Server インスタンスの起動および停止」 を参照してください。
例15.4 サプライヤーバインド DN エントリーの例
dn: cn=replication manager,cn=config objectClass: top objectClass: device objectClass: simpleSecurityObject cn: replication manager userPassword: strong_password nsIdleTimeout: 0
15.5. 単一マスターレプリケーションの設定
15.5.1. Supplier サーバーでの読み書きレプリカの設定
- サーバーのサプライヤー設定を指定します。
- Directory Server コンソールで、Configuration タブを選択します。
- ナビゲーションツリーで、Replication フォルダーを選択します。
- ウィンドウの右側で、Supplier Settings タブを選択します。
- Enable Changelog チェックボックスを選択します。これにより、以前にグレーアウトされていたペインのフィールドがすべて有効になります。
- ログファイルの数と期間の changelog パラメーターを設定します。異なる値を指定するには、無制限のチェックボックスをクリアします。注記Red Hat は、最大変更ログ 期間を 7 日に 設定することを推奨します。
- 読み取り/書き込みレプリカに必要なレプリケーション設定を指定します。
- Configuration タブのナビゲーションツリーで、Replication ノードを展開し、複製するデータベースを強調表示します。Replica Settings タブがウィンドウの右側で開きます。
- Enable Replica チェックボックスを選択します。
- Replica Role セクションで、Single Master ラジオボタンを選択します。
- Common Settings セクションで、Replica ID を指定します。レプリカ ID は 1 から 65534 までの整数です。指定の接尾辞のレプリカには、レプリカ ID を一意にする必要があります。このサーバーおよび他のサーバーで読み取り/書き込みレプリカに使用される他の ID とは異なります。
- Common Settings セクションで、Purge delay フィールドでパージ遅延を指定します。パージの遅延は、複製されたエントリーに対する状態情報を削除する頻度です。
15.5.2. コンシューマーでの読み取り専用レプリカの設定
- 読み取り専用レプリカのデータベースがない場合は、これを作成します。接尾辞の作成方法については、「接尾辞の作成」 を参照してください。
- コンシューマーサーバーにサプライヤーバインド DN のエントリーを作成します(存在しない場合)。サプライヤーバインド DN は、サプライヤーがコンシューマーにバインドするために使用する特別なエントリーです。これは 「サプライヤーバインド DN エントリーの作成」 で説明されています。
- 読み取り専用レプリカに必要なレプリケーション設定を指定します。
- Directory Server コンソールで、Configuration タブを選択します。
- ナビゲーションツリーで Replication フォルダーを展開し、レプリカデータベースを選択します。o=NetscapeRoot データベースを複製 する場合は、「管理サーバーのフェイルオーバー用の o=NetscapeRoot の複製」 を参照してください。
- 選択したデータベースの Replica Settings タブで、Enable Replica チェックボックスを選択します。
- Replica Role セクションで、Dedicated Consumer ラジオボタンを選択します。
- Common Settings セクションで、Purge delay フィールドでパージ遅延を指定します。このオプションは、複製されたエントリーのステータス情報がパージされる頻度を示します。
- Update Settings セクションで、サプライヤーがレプリカにバインドするために使用するバインド DN を指定します。Enter a new Supplier DN フィールドにサプライヤーバインド DN を入力し、 をクリックします。サプライヤーバインド DN が現在の サプライヤー DN 一覧に表示されます。サプライヤーバインド DN は、手順 2 で作成されたエントリーである必要があります。サプライヤーバインド DN はアクセス制御の対象ではないため、特権ユーザーです。注記コンシューマーごとに複数のサプライヤーバインド DN を指定できますが、レプリカ合意ごとに 1 つのサプライヤー DN のみがあります。
- 更新を参照するサプライヤーサーバーの URL を指定します。デフォルトでは、すべての更新は、ここで指定されたサプライヤーサーバーが最初に参照されます。ここでサプライヤーが設定されていない場合、更新は現在のレプリカを含むレプリカ合意を持つサプライヤーサーバーと呼ばれます。自動参照は、クライアントが通常の接続上でバインドすることを前提としています。これには ldap://hostname:port 形式の URL があります。クライアントが TLS を使用してサプライヤーにバインドするには、このフィールドを使用して ldaps://hostname:port 形式の参照を指定します。ldaps の s はセキュアな接続を示します。注記ホスト名の代わりに IPv4 アドレスまたは IPv6 アドレスを使用することもできます。
15.5.3. レプリカ合意の作成
- Configuration タブのナビゲーションツリーで、データベースを右クリックし、New Replication Agreement を選択します。または、データベースを強調表示し、Object メニューから New Replication Agreement を選択して Replication Agreement Wizard を起動します。
- 最初の画面で、レプリカ合意の名前および説明を入力し、を押します。
- Source and Destination 画面で、コンシューマーの URL(hostname:port または IP_address:port )と、コンシューマー上のサプライヤーバインド DN とパスワードを入力します。ターゲットサーバーが利用できない場合は、他のサーバーにアクセスして情報を手動で入力します。
- 複数の Directory Server インスタンスが設定されていない場合、デフォルトでは、ドロップダウンメニューにはコンシューマーがありません。
- Directory Server インスタンスが TLS で実行されるように設定されている場合でも、一覧表示されるポートは TLS 以外のポートになります。このポート番号は、コンソールで Directory Server インスタンスを識別するためにのみ使用されます。これは、レプリケーションに使用される実際のポート番号またはプロトコルを指定しません。
- サーバーで TLS が有効になっている場合は、TLS クライアント認証に Using encrypted SSL connection ラジオボタンを選択できます。それ以外の場合は、サプライヤーバインド DN およびパスワードを入力します。注記属性の暗号化が有効な場合は、暗号化された属性を複製するセキュアな接続 を使用する必要があります。
- 接続タイプを選択します。以下の 3 つのオプションがあります。
- LDAP を使用します。これにより、標準の暗号化されていない接続が設定されます。
- TLS/SSL を使用します。これは、636 などのサーバーのセキュアな LDAPS ポートを介したセキュアな接続を使用します。この設定は TLS を使用するために必要です。
- Start TLS を使用します。Start TLS を使用して、サーバーの標準ポートでセキュアな接続を確立します。
注記シンプルなパスワード認証(「セキュアなバインドの要求」)にセキュアなバインドが必要な場合は、セキュアな接続で行われる場合を除き、レプリケーション操作は失敗します。セキュアな接続(TLS および Start TLS 接続または SASL 認証)の使用が推奨されます。 - 適切な認証方法を選択し、必要な情報を提供します。これにより、サプライヤーがコンシューマーサーバーにバインドして更新を送信するために使用する情報を提供します。
- simple は、サーバーが、暗号化なしで標準ポートで接続することを意味します。必要な情報は、Replication Manager のバインド DN およびパスワード(コンシューマーサーバーに存在する必要がある)です。
- サーバー TLS/SSL 証明書は、サプライヤーの TLS 証明書を使用して、コンシューマーサーバーに対して認証します。証明書は、証明書ベースの認証のサプライヤーにインストールされ、コンシューマーサーバーには、サプライヤーの証明書内のサブジェクト DN をその Replication Manager エントリーにマッピングできるように、証明書マッピングを設定する必要があります。TLS および証明書マッピングの設定については、「TLS の有効化」 を参照してください。
- 簡易認証などの SASL/DIGEST-MD5。このセキュアでない方法で認証するには、バインド DN およびパスワードのみが必要になります。これは、標準または TLS 接続上で実行できます。
- SASL/GSSAPI では、サプライヤーサーバーに Kerberos キータブ( 「KDC サーバーおよびキータブの概要」にあるように)があり、コンシューマーサーバーでサプライヤーのプリンシパルを実際のレプリケーションマネージャーエントリーにマップするために SASL マッピングが必要です( 「コンソールからの SASL アイデンティティーマッピングの設定」のように)。
- 一部レプリケーションは、サーバー間でエントリーがレプリケートされるエントリー属性を制御します。デフォルトでは、すべての属性がレプリケートされます。コンシューマーに複製され ない属性 を選択するには、Enable Fractional Replication チェックボックスを選択します。次に、右側の Included コラムの属性(または属性)を強調表示し、Remove をクリックします。レプリケートされない属性はすべて左側の Excluded 列に一覧表示されます。また、レプリカ合意が完了する概要にも表示されます。
- レプリケーションの実行時にスケジュールを設定します。デフォルトでは、レプリケーションは継続的に実行されます。注記レプリケーションスケジュールは、真夜中(0000)を越えません。そのため、0001 を開始し、同じ日に 2359 で終わるスケジュールを設定できますが、1 日の 2359 から開始したスケジュールを設定し、次の 部分で終了することはできません。
- Initialize consumer now を選択して、レプリカ合意の完了後に初期化を開始し、 をクリックします。注記レプリケーションは、コンシューマーが初期化されるまで 開始されません。コンシューマーの初期化の詳細は、「コンシューマーの初期化」 を参照してください。
- 最後の画面には
dse.ldif
ファイルに含まれるため、レプリカ合意の設定が表示されます。 を押して合意を保存します。
15.6. マルチマスターレプリケーションの設定
15.6.1. サプライヤーサーバーでの読み書きレプリカの設定
- サーバーのサプライヤー設定を指定します。
- Directory Server コンソールで、Configuration タブを選択します。
- ナビゲーションツリーで、Replication フォルダーを選択します。
- ウィンドウの右側で、Supplier Settings タブを選択します。
- Enable Changelog チェックボックスを選択します。これにより、以前にグレーアウトされていたペインのフィールドがすべて有効になります。
- ログファイルの数と期間の changelog パラメーターを設定します。異なる値を指定するには、無制限のチェックボックスをクリアします。
- コンシューマーサーバーにサプライヤーバインド DN のエントリーを作成します(存在しない場合)。これは、他のサプライヤーとコンシューマーの関係と同様に、他のサプライヤーがこのサプライヤーにバインドするために使用する特別なエントリーです。これは 「サプライヤーバインド DN エントリーの作成」 で説明されています。注記マルチマスターレプリケーションでは、サプライヤーがコンシューマーとサプライヤーの両方を他のサプライヤーサーバーに対して機能するため、サプライヤーサーバーとコンシューマーにこのサプライヤーバインド DN を作成する必要があります。
- マルチマスターの読み取り/書き込みレプリカのレプリケーション設定を指定します。
- Directory Server コンソールで、Configuration タブを選択します。
- ナビゲーションツリーで、Replication フォルダーを展開し、レプリカデータベースを強調表示します。ウィンドウの右側で、そのデータベースの Replica Settings タブが開きます。
- Enable Replica チェックボックスを選択します。
- Replica Role セクションで、Multiple Master ラジオボタンを選択します。
- Common Settings セクションで、Replica ID を指定します。レプリカ ID は 1 から 65534 までの整数です。指定の接尾辞のレプリカには、レプリカ ID を一意にする必要があります。このサーバーおよび他のサーバーで読み取り/書き込みレプリカに使用される他の ID とは異なります。
- Common Settings セクションで、Purge delay フィールドでパージ遅延を指定します。パージの遅延は、複製されたエントリーに対する状態情報を削除する頻度です。
- Update Settings セクションで、サプライヤーがレプリカにバインドするために使用するバインド DN を指定します。Enter a new Supplier DN フィールドにサプライヤーバインド DN を入力し、 をクリックします。サプライヤーバインド DN が現在の サプライヤー DN 一覧に表示されます。サプライヤーバインド DN は、手順 2 で作成されたエントリーである必要があります。サプライヤーバインド DN は、複製されたデータベースのアクセス制御の対象ではないため、特権ユーザーです。注記コンシューマーごとに複数のサプライヤーバインド DN を指定できますが、レプリカ合意ごとに 1 つのサプライヤー DN のみがあります。
- マルチマスターレプリケーションセットの他のサプライヤーなど、更新を参照するサプライヤーサーバーの LDAP URL(ldap://hostname:port または ldap://IP_address:port) を指定します。サプライヤーサーバーの URL のみを指定します。クライアントが TLS を使用してバインドするには、ldaps:// で始まる URL を指定します。
15.6.2. コンシューマーサーバーでの読み取り専用レプリカの設定
- 読み取り専用レプリカのデータベースがない場合は、これを作成します。接尾辞の作成方法については、「接尾辞の作成」 を参照してください。
- コンシューマーサーバーにサプライヤーバインド DN のエントリーを作成します(存在しない場合)。サプライヤーバインド DN は、サプライヤーがコンシューマーにバインドするために使用する特別なエントリーです。これは 「サプライヤーバインド DN エントリーの作成」 で説明されています。
- 読み取り専用レプリカに必要なレプリケーション設定を指定します。
- Directory Server コンソールで、Configuration タブを選択します。
- ナビゲーションツリーで、Replication フォルダーを展開し、レプリカデータベースを強調表示します。ウィンドウの右側で、そのデータベースの Replica Settings タブが開きます。
- Enable Replica チェックボックスを選択します。
- Replica Role セクションで、Dedicated Consumer ラジオボタンを選択します。
- Common Settings セクションで、Purge delay フィールドでパージ遅延を指定します。このオプションは、複製されたエントリーのステータス情報がパージされる頻度を示します。
- Update Settings セクションで、サプライヤーがレプリカにバインドするために使用するバインド DN を指定します。Enter a new Supplier DN フィールドにサプライヤーバインド DN を入力し、 をクリックします。サプライヤーバインド DN が現在の サプライヤー DN 一覧に表示されます。サプライヤーバインド DN は、手順 2 で作成されたエントリーである必要があります。サプライヤーバインド DN は、複製されたデータベースのアクセス制御の対象ではないため、特権ユーザーです。注記コンシューマーごとに複数のサプライヤーバインド DN を指定できますが、レプリカ合意ごとに 1 つのサプライヤー DN のみがあります。
- 更新を参照するサプライヤーサーバーの URL を指定します。デフォルトでは、すべての更新は、ここで指定されたサプライヤーサーバーが最初に参照されます。ここでサプライヤーが設定されていない場合、更新は現在のレプリカを含むレプリカ合意を持つサプライヤーサーバーと呼ばれます。自動参照は、クライアントが通常の接続上でバインドすることを前提としています。これには ldap://hostname:port 形式の URL があります。クライアントが TLS を使用してサプライヤーにバインドするには、このフィールドを使用して ldaps://hostname:port 形式の参照を指定します。ldaps の s はセキュアな接続を示します。注記ホスト名の代わりに IPv4 アドレスまたは IPv6 アドレスを使用することもできます。
15.6.3. レプリカ合意の設定
- まず、1 つのサプライヤー、他のマルチマスターレプリケーション間のデータマスターでレプリカ合意を設定し、他のすべてのサプライヤーを初期化します。
- 次に、マルチマスターレプリケーションセットで他のすべてのサプライヤーに対してレプリカ合意を作成しますが、サプライヤーは再初期化 しません。
- 次に、1 つのデータマスターからすべてのコンシューマーに対してレプリカ合意を作成し、コンシューマーを初期化します。
- 次に、他のすべてのサプライヤーに対してすべてのコンシューマーに対してレプリカ合意を作成しますが、コンシューマーも再初期化 しません。
- Configuration タブのナビゲーションツリーで、データベースを右クリックし、New Replication Agreement を選択します。または、データベースを強調表示し、Object メニューから New Replication Agreement を選択して Replication Agreement Wizard を起動します。
- 最初の画面で、レプリカ合意の名前および説明を入力し、を押します。
- Source and Destination 画面で、コンシューマーの URL(hostname:port または IP_address:port )と、コンシューマー上のサプライヤーバインド DN とパスワードを入力します。ターゲットサーバーが利用できない場合は、他のサーバーにアクセスして情報を手動で入力します。
- 複数の Directory Server インスタンスが設定されていない場合、デフォルトでは、ドロップダウンメニューにはコンシューマーがありません。サーバー URL は、IPv4 アドレスまたは IPv6 アドレスで、hostname:port または IP_address:port の形式で手動で入力できます。
- Directory Server インスタンスが TLS で実行されるように設定されている場合でも、一覧表示されるポートは TLS 以外のポートになります。このポート番号は、コンソールで Directory Server インスタンスを識別するためにのみ使用されます。これは、レプリケーションに使用される実際のポート番号またはプロトコルを指定しません。
- サーバーで TLS が有効になっている場合は、TLS クライアント認証に Using encrypted SSL connection ラジオボタンを選択できます。それ以外の場合は、サプライヤーバインド DN およびパスワードを入力します。注記属性の暗号化が有効な場合は、暗号化された属性を複製するのにセキュアな接続が必要になります。
- 接続タイプを選択します。以下の 3 つのオプションがあります。
- LDAP を使用します。これにより、標準の暗号化されていない接続が設定されます。
- TLS/SSL を使用します。これは、636 などのサーバーのセキュアな LDAPS ポートを介したセキュアな接続を使用します。この設定は TLS を使用するために必要です。
- Start TLS を使用します。Start TLS を使用して、サーバーの標準ポートでセキュアな接続を確立します。
注記シンプルなパスワード認証(「セキュアなバインドの要求」)にセキュアなバインドが必要な場合は、セキュアな接続で行われる場合を除き、レプリケーション操作は失敗します。セキュアな接続(TLS および Start TLS 接続または SASL 認証)の使用が推奨されます。 - 適切な認証方法を選択し、必要な情報を提供します。これにより、サプライヤーがコンシューマーサーバーにバインドして更新を送信するために使用する情報を提供します。
- simple は、サーバーが、暗号化なしで標準ポートで接続することを意味します。必要な情報は、Replication Manager のバインド DN およびパスワード(コンシューマーサーバーに存在する必要がある)です。
- サーバー TLS/SSL 証明書は、サプライヤーの TLS 証明書を使用して、コンシューマーサーバーに対して認証します。証明書は、証明書ベースの認証のサプライヤーにインストールされ、コンシューマーサーバーには、サプライヤーの証明書内のサブジェクト DN をその Replication Manager エントリーにマッピングできるように、証明書マッピングを設定する必要があります。TLS および証明書マッピングの設定については、「TLS の有効化」 を参照してください。
- 簡易認証などの SASL/DIGEST-MD5 では、認証に使用するバインド DN とパスワードのみが必要になります。これは、標準または TLS 接続上で実行できます。
- SASL/GSSAPI では、サプライヤーサーバーに Kerberos キータブ( 「KDC サーバーおよびキータブの概要」にあるように)があり、コンシューマーサーバーでサプライヤーのプリンシパルを実際のレプリケーションマネージャーエントリーにマップするために SASL マッピングが必要です( 「コンソールからの SASL アイデンティティーマッピングの設定」のように)。
- 一部レプリケーションは、サーバー間でエントリーがレプリケートされるエントリー属性を制御します。デフォルトでは、すべての属性がレプリケートされます。コンシューマーに複製され ない属性 を選択するには、Enable Fractional Replication チェックボックスを選択します。次に、右側の Included コラムの属性(または属性)を強調表示し、Remove をクリックします。レプリケートされない属性はすべて左側の Excluded 列に一覧表示されます。また、レプリカ合意が完了する概要にも表示されます。
- レプリケーションの実行時にスケジュールを設定します。デフォルトでは、レプリケーションは継続的に実行されます。注記レプリケーションスケジュールは、真夜中(0000)を越えません。そのため、0001 を開始し、同じ日に 2359 で終わるスケジュールを設定できますが、1 日の 2359 から開始したスケジュールを設定し、次の 部分で終了することはできません。
- コンシューマーが初期化されると設定されます。コンシューマー を初期化すると、サプライヤーからコンシューマーにすべてのデータを手動でコピーします。デフォルトでは、コンシューマーを後で初期化できるように初期化ファイル(すべてのサプライヤーデータの LDIF)を作成します。レプリカ合意が完了した後、または全くない時に、コンシューマーを初期化することもできます。コンシューマーの初期化の詳細は、「コンシューマーの初期化」 を参照してください。マルチマスターレプリケーションについては、以下を考慮してください。
- 1 つのサプライヤーに、他のサプライヤーに複製するための完全なデータセットがあることを確認します。この 1 つのサプライヤーを使用して、マルチマスターレプリケーションセットの他のすべてのサプライヤーでレプリカを初期化します。
- いずれかのマルチマスターサプライヤーからコンシューマーサーバーのレプリカを初期化します。
- レプリカ合意が設定されると、サーバー の再初期化 を試行しないでください。たとえば、server2 が server1 からすでに初期化されている場合は、server2 から server1 を初期化しないでください。この場合は、Do not initialize consumer を選択します。
注記レプリケーションは、コンシューマーが初期化されるまで 開始されません。重要マルチマスターレプリケーションの場合は、コンシューマーが 1 つのサプライヤーによって 1 度だけ 初期化されていることを確認します。レプリケーションのステータスを確認する際には、コンシューマーの初期化に使用された適切なサプライヤーでレプリカ合意のエントリーを確認してください。 - 最後の画面には
dse.ldif
ファイルに含まれるため、レプリカ合意の設定が表示されます。 を押して合意を保存します。
15.6.4. マルチマスターレプリケーションにおけるコンシューマーの独占を防ぐ
nsds5ReplicaBusyWaitTime
- 別のアクセスの取得を試みる前に、コンシューマーがビジー応答を返した後のサプライヤーが待機する時間を秒単位で設定します。たとえば、別の取得を試みる前に、サプライヤーが 5 秒待機するように設定するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Replication_Agreement_Name,cn=replica,cn=suffix_Name,cn=mapping tree,cn=config changetype: modify replace: nsds5ReplicaBusyWaitTime nsds5ReplicaBusyWaitTime: 5
nsds5ReplicaSessionPauseTime
- 2 つの更新セッションの間にサプライヤーが待機する時間を秒単位で設定します。
nsds5ReplicaBusyWaitTime
で指定した値またはそれよりも小さい値を設定すると、Directory Server はnsds5ReplicaSessionPauseTime
パラメーターの値を自動的に使用します。これは、nsds5ReplicaBusyWaitTime
に設定した値よりも大きな値になります。たとえば、サプライヤーは 2 つの更新セッション間で 10 秒待機するように設定するには、以下を実行します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Replication_Agreement_Name,cn=replica,cn=suffix_Name,cn=mapping tree,cn=config changetype: modify replace: nsds5ReplicaSessionPauseTime nsds5ReplicaSessionPauseTime: 10
nsds5ReplicaReleaseTimeout
- 更新の送信を終了したかどうかにかかわらず、マスターがレプリカを解放するタイムアウトを設定します。これにより、単一マスターがレプリカを独占しなくなります。たとえば、マスターが 90 秒後にレプリカを解放する大規模なレプリケーション環境に設定するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replica,cn=suffix_Name,cn=mapping tree,cn=config changetype: modify replace: nsds5ReplicaReleaseTimeout nsds5ReplicaReleaseTimeout: 90
15.7. カスケードレプリケーションの設定
15.7.1. Supplier サーバーでの読み書きレプリカの設定
- サーバーのサプライヤー設定を指定します。
- Directory Server コンソールで、Configuration タブを選択します。
- ナビゲーションツリーで、Replication フォルダーを選択します。
- ウィンドウの右側で、Supplier Settings タブを選択します。
- Enable Changelog チェックボックスを選択します。これにより、以前にグレーアウトされていたペインのフィールドがすべて有効になります。
- ログファイルの数と期間の changelog パラメーターを設定します。異なる値を指定するには、無制限のチェックボックスをクリアします。
- 読み取り/書き込みレプリカに必要なレプリケーション設定を指定します。
- Configuration タブのナビゲーションツリーで、Replication ノードを展開し、複製するデータベースを強調表示します。Replica Settings タブがウィンドウの右側で開きます。
- Enable Replica チェックボックスを選択します。
- Replica Role セクションで、Single Master ラジオボタンを選択します。
- Common Settings セクションで、Replica ID を指定します。レプリカ ID は 1 から 65534 までの整数です。指定の接尾辞のレプリカには、レプリカ ID を一意にする必要があります。このサーバーおよび他のサーバーで読み取り/書き込みレプリカに使用される他の ID とは異なります。
- Common Settings セクションで、Purge delay フィールドでパージ遅延を指定します。パージの遅延は、複製されたエントリーに対する状態情報を削除する頻度です。
15.7.2. コンシューマーサーバーでの読み取り専用レプリカの設定
- 読み取り専用レプリカのデータベースがない場合は、これを作成します。接尾辞の作成方法については、「接尾辞の作成」 を参照してください。
- コンシューマーサーバーにサプライヤーバインド DN のエントリーを作成します(存在しない場合)。サプライヤーバインド DN は、サプライヤーがコンシューマーにバインドするために使用する特別なエントリーです。これは 「サプライヤーバインド DN エントリーの作成」 で説明されています。
- 読み取り専用レプリカに必要なレプリケーション設定を指定します。
- Directory Server コンソールで、Configuration タブを選択します。
- ナビゲーションツリーで、Replication フォルダーを展開し、レプリカデータベースを強調表示します。ウィンドウの右側で、そのデータベースの Replica Settings タブが開きます。
- Enable Replica チェックボックスを選択します。
- Replica Role セクションで、Dedicated Consumer ラジオボタンを選択します。
- Common Settings セクションで、Purge delay フィールドでパージ遅延を指定します。このオプションは、複製されたエントリーのステータス情報がパージされる頻度を示します。
- Update Settings セクションで、サプライヤーがレプリカにバインドするために使用するバインド DN を指定します。Enter a new Supplier DN フィールドにサプライヤーバインド DN を入力し、 をクリックします。サプライヤーバインド DN が現在の サプライヤー DN 一覧に表示されます。サプライヤーバインド DN は、手順 2 で作成されたエントリーである必要があります。サプライヤーバインド DN は、複製されたデータベースのアクセス制御の対象ではないため、特権ユーザーです。注記コンシューマーごとに複数のサプライヤーバインド DN を指定できますが、レプリカ合意ごとに 1 つのサプライヤー DN のみがあります。
- 更新を参照するサプライヤーサーバーの URL(hostname :port または IP_address:port、IPv4 アドレスまたは IPv6 アドレスを使用)を指定します。デフォルトでは、すべての更新は、ここで指定されたサプライヤーサーバーが最初に参照されます。ここでサプライヤーが設定されていない場合、更新は現在のレプリカを含むレプリカ合意を持つサプライヤーサーバーと呼ばれます。カスケードレプリケーションでは、参照は自動的にハブサーバーに送信され、元のサプライヤーへの要求を参照します。そのため、自動的に生成された参照を交換するように、元のサプライヤーに参照を設定します。
15.7.3. ハブでの読み取り専用レプリカの設定
- 読み取り専用レプリカのデータベースがない場合は、これを作成します。接尾辞の作成方法については、「接尾辞の作成」 を参照してください。
- コンシューマーサーバーにサプライヤーバインド DN のエントリーを作成します(存在しない場合)。サプライヤーバインド DN は、サプライヤーがコンシューマーにバインドするために使用する特別なエントリーです。これは 「サプライヤーバインド DN エントリーの作成」 で説明されています。
- ハブサーバーの changelog を作成します。ハブは、サプライヤーサーバーから送信された変更を記録するので、更新操作を受け入れなくても changelog を維持する必要があります。
- Directory Server コンソールで、Configuration タブを選択します。
- ナビゲーションツリーで、Replication フォルダーを選択します。
- ウィンドウの右側で、Supplier Settings タブを選択します。
- Enable Changelog チェックボックスを選択します。これにより、以前にグレーアウトされていたペインのフィールドがすべて有効になります。
- ログファイルの数と期間の changelog パラメーターを設定します。異なる値を指定するには、無制限のチェックボックスをクリアします。
- 必要なハブレプリカ設定を指定します。
- Directory Server コンソールで、Configuration タブを選択します。
- ナビゲーションツリーで、Replication フォルダーを展開し、レプリカデータベースを強調表示します。ウィンドウの右側で、そのデータベースの Replica Settings タブが開きます。
- Enable Replica チェックボックスを選択します。
- Replica Role セクションで、Hub ラジオボタンを選択します。
- Common Settings セクションで、Purge delay フィールドでパージ遅延を指定します。このオプションは、複製されたエントリーのステータス情報がパージされる頻度を設定します。
- Update Settings セクションで、サプライヤーがレプリカにバインドするために使用するバインド DN を指定します。Enter a new Supplier DN フィールドにサプライヤーバインド DN を入力し、 をクリックします。サプライヤーバインド DN が現在の サプライヤー DN 一覧に表示されます。サプライヤーバインド DN は、手順 2 で作成されたエントリーである必要があります。サプライヤーバインド DN は、複製されたデータベースのアクセス制御の対象ではないため、特権ユーザーです。注記コンシューマーごとに複数のサプライヤーバインド DN を指定できますが、レプリカ合意ごとに 1 つのサプライヤー DN のみがあります。
- 更新を参照するサプライヤーサーバーの URL を指定します。デフォルトでは、すべての更新は、ここで指定されたサプライヤーサーバーが最初に参照されます。ここでサプライヤーが設定されていない場合、更新は現在のレプリカを含むレプリカ合意を持つサプライヤーサーバーと呼ばれます。自動参照は、クライアントが通常の接続上でバインドすることを前提としています。これには ldap://hostname:port 形式の URL があります。クライアントが TLS を使用してサプライヤーにバインドするには、このフィールドを使用して ldaps://hostname:port 形式の参照を指定します。ldaps の s はセキュアな接続を示します。注記ホスト名の代わりに IPv4 アドレスまたは IPv6 アドレスを使用することもできます。
15.7.4. レプリカ合意の設定
- ハブのサプライヤーにレプリカ合意を作成してから、サプライヤーサーバーを使用してハブサーバーでレプリカを初期化します。
- 次に、各コンシューマーのハブでレプリカ合意を作成し、ハブからコンシューマーレプリカを初期化します。
- Configuration タブのナビゲーションツリーで、データベースを右クリックし、New Replication Agreement を選択します。または、データベースを強調表示し、Object メニューから New Replication Agreement を選択して Replication Agreement Wizard を起動します。
- 最初の画面で、レプリカ合意の名前および説明を入力し、を押します。
- Source and Destination 画面で、コンシューマーの URL(hostname:port または IP_address:port )と、コンシューマー上のサプライヤーバインド DN とパスワードを入力します。ターゲットサーバーが利用できない場合は、他のサーバーにアクセスして情報を手動で入力します。
- 複数の Directory Server インスタンスが設定されていない場合、デフォルトでは、ドロップダウンメニューにはコンシューマーがありません。サーバーの URL は、IPv4 アドレスまたは IPv6 アドレスで .hostname :port または IP_address:port として手動で入力できます。
- Directory Server インスタンスが TLS で実行されるように設定されている場合でも、一覧表示されるポートは TLS 以外のポートになります。このポート番号は、コンソールで Directory Server インスタンスを識別するためにのみ使用されます。これは、レプリケーションに使用される実際のポート番号またはプロトコルを指定しません。
- サーバーで TLS が有効になっている場合は、TLS クライアント認証に Using encrypted SSL connection ラジオボタンを選択できます。それ以外の場合は、サプライヤーバインド DN およびパスワードを入力します。注記属性の暗号化が有効な場合は、暗号化された属性を複製するセキュアな接続 を使用する必要があります。
- 接続タイプを選択します。以下の 3 つのオプションがあります。
- LDAP を使用します。これにより、標準の暗号化されていない接続が設定されます。
- TLS/SSL を使用します。これは、636 などのサーバーのセキュアな LDAPS ポートを介したセキュアな接続を使用します。この設定は TLS を使用するために必要です。
- Start TLS を使用します。Start TLS を使用して、サーバーの標準ポートでセキュアな接続を確立します。
注記シンプルなパスワード認証(「セキュアなバインドの要求」)にセキュアなバインドが必要な場合は、セキュアな接続で行われる場合を除き、レプリケーション操作は失敗します。セキュアな接続(TLS および Start TLS 接続または SASL 認証)の使用が推奨されます。 - 適切な認証方法を選択し、必要な情報を提供します。これにより、サプライヤーがコンシューマーサーバーにバインドして更新を送信するために使用する情報を提供します。
- simple は、サーバーが、暗号化なしで標準ポートで接続することを意味します。必要な情報は、Replication Manager のバインド DN およびパスワード(コンシューマーサーバーに存在する必要がある)です。
- サーバー TLS/SSL 証明書は、サプライヤーの TLS 証明書を使用して、コンシューマーサーバーに対して認証します。証明書は、証明書ベースの認証のサプライヤーにインストールされ、コンシューマーサーバーには、サプライヤーの証明書内のサブジェクト DN をその Replication Manager エントリーにマッピングできるように、証明書マッピングを設定する必要があります。TSL および証明書マッピングの設定については、「TLS の有効化」 を参照してください。
- 簡易認証などの SASL/DIGEST-MD5 では、認証に使用するバインド DN とパスワードのみが必要になります。これは、標準または TLS 接続上で実行できます。
- SASL/GSSAPI では、サプライヤーサーバーに Kerberos キータブ( 「KDC サーバーおよびキータブの概要」にあるように)があり、コンシューマーサーバーでサプライヤーのプリンシパルを実際のレプリケーションマネージャーエントリーにマップするために SASL マッピングが必要です( 「コンソールからの SASL アイデンティティーマッピングの設定」のように)。
- 一部レプリケーションは、サーバー間でエントリーがレプリケートされるエントリー属性を制御します。デフォルトでは、すべての属性がレプリケートされます。コンシューマーに複製され ない属性 を選択するには、Enable Fractional Replication チェックボックスを選択します。次に、右側の Included コラムの属性(または属性)を強調表示し、Remove をクリックします。レプリケートされない属性はすべて左側の Excluded 列に一覧表示されます。また、レプリカ合意が完了する概要にも表示されます。
- レプリケーションの実行時にスケジュールを設定します。デフォルトでは、レプリケーションは継続的に実行されます。注記レプリケーションスケジュールは、真夜中(0000)を越えません。そのため、0001 を開始し、同じ日に 2359 で終わるスケジュールを設定できますが、1 日の 2359 から開始したスケジュールを設定し、次の 部分で終了することはできません。
- コンシューマーが初期化されると設定されます。コンシューマー を初期化すると、サプライヤーからコンシューマーにすべてのデータを手動でコピーします。デフォルトでは、コンシューマーを後で初期化できるように初期化ファイル(すべてのサプライヤーデータの LDIF)を作成します。レプリカ合意が完了した後、または全くない時に、コンシューマーを初期化することもできます。コンシューマーの初期化の詳細は、「コンシューマーの初期化」 を参照してください。カスケードレプリケーションについては、以下を考慮してください。
- 最初にサプライヤーで supplier-hub レプリカ合意を作成し、サプライヤーからハブを初期化します。
- ハブで hub-consumer レプリカ合意を作成し、ハブからコンシューマーを初期化します。
注記レプリケーションは、コンシューマーが初期化されるまで 開始されません。重要マルチマスターレプリケーションの場合は、コンシューマーが 1 つのサプライヤーによって 1 度だけ 初期化されていることを確認します。レプリケーションのステータスを確認する際には、コンシューマーの初期化に使用された適切なサプライヤーでレプリカ合意のエントリーを確認してください。 - 最後の画面には
dse.ldif
ファイルに含まれるため、レプリカ合意の設定が表示されます。 を押して合意を保存します。
15.8. 一時的にレプリケーションを一時停止
15.9. レプリカ合意の無効化および再有効化
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replication_agreement_name,cn=replica,cn=suffix_DN,cn=mapping tree,cn=config changetype: modify replace: nsds5ReplicaEnabled nsds5ReplicaEnabled: off
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replication_agreement_name,cn=replica,cn=suffix_DN,cn=mapping tree,cn=config changetype: modify replace: nsds5ReplicaEnabled nsds5ReplicaEnabled: on
15.10. 一部レプリケーションによる属性の管理
memberOf
計算など) が実行される回数を減らすために実行できます。
nsDS5ReplicatedAttributeList
属性で定義されます。この属性はレプリカ合意の一部で、レプリカ合意の作成時に(またはコマンドラインから)Directory Server Console のレプリカ合意ウィザードで設定できます。
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof authorityRevocationList accountUnlockTime
nsDS5ReplicatedAttributeList
属性の値に (objectclass=*) $ EXCLUDE の部分が必要です。ldapmodify
ユーティリティーなどを使用して属性を直接編集する場合は、上記の例で示されている属性の一覧とともにこの部分を指定する必要があります。
15.10.1. 合計更新および増分更新での異なる一部レプリケーション属性の設定
nsDS5ReplicatedAttributeListTotal
) から除外する属性の別のリストを定義する 2 番目の属性を追加できます。
nsDS5ReplicatedAttributeList
プライマリーの一部レプリケーション属性です。nsDS5ReplicatedAttributeList
のみが設定されている場合、増分更新と合計更新の両方に適用されます。nsDS5ReplicatedAttributeList
と nsDS5ReplicatedAttributeListTotal
の両方が設定されている場合、nsDS5ReplicatedAttributeList
は増分更新にのみ適用されます。
memberOf
属性がエントリーに追加されるたびに、memberOf 修正タスクが実行してグループメンバーシップを解決します。これにより、レプリケーションが発生するたびにそのタスクが実行する場合に、サーバーでオーバーヘッドが発生する可能性があります。合計の更新は、レプリケーションに新たに追加されたり、長期間オフラインになったデータベースでのみ実行されるため、合計更新後の memberOf 修正タスクを実行すると、合計値が許容オプションになります。この場合、nsDS5ReplicatedAttributeList
属性には memberOf
というリストが記載されるため、増分更新から除外されるようにしますが、nsDS5ReplicatedAttributeListTotal
は memberOf
を一覧表示しないため、すべての更新に含まれるようにします。
nsDS5ReplicatedAttributeList
属性に設定されます。
nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE authorityRevocationList accountUnlockTime memberof
nsDS5ReplicatedAttributeList
が唯一の属性セットである場合、そのリストは増分更新と合計更新の両方に適用されます。更新の合計に別のリストを設定するには、nsDS5ReplicatedAttributeListTotal
属性をレプリカ合意に追加します。
# ldapmodify -D "cn=Directory Manager" -W -x -D "cn=directory manager" -W -p 389 -h server.example.com -x dn: cn=ExampleAgreement,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config changetype: modify add: nsDS5ReplicatedAttributeListTotal nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE accountUnlockTime
nsDS5ReplicatedAttributeList
属性は、すべての更新に対して nsDS5ReplicatedAttributeListTotal
を設定する前に増分更新のために設定される必要があります。
15.10.2. 一部レプリケーションによる「空」のアップデートの防止
nsDS5ReplicatedAttributeList
) から削除される属性の一覧が許可されます。しかし、除外された属性への変更があっても、修正イベントが発生し、空のレプリケーション更新が生成されます。
nsds5ReplicaStripAttrs
属性は、空のレプリケーションイベントでは送信できず、更新シーケンスから削除される属性の一覧を追加します。これには、modifiersName
のような運用上の利便性が含まれます。
accountUnlockTime
属性が除外されたとします。John Smith のユーザーアカウントがロックされ、期間が期限切れになり、自動的にロック解除されます。accountUnlockTime
属性のみが変更し、その属性はレプリケーションから除外されます。ただし、運用する属性 internalmodifytimestamp
も 変更しています。John Smith のユーザーアカウントが変更しているため、レプリケーションイベントがトリガーされます。ただし、送信する唯一のデータは新しい変更タイムスタンプであり、更新は空になります。(たとえば) ログイン時間やパスワードの有効期限などに関連する多くの属性がある場合は、空のレプリケーション更新が作成され、サーバーのパフォーマンスに悪影響を与えるか、関連するアプリケーションを妨げる可能性があります。
nsds5ReplicaStripAttrs
属性をレプリカ合意に追加します。
# ldapmodify -D "cn=Directory Manager" -W -x -D "cn=directory manager" -W -p 389 -h server.example.com -x dn: cn=ExampleAgreement,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config changetype: modify add: nsds5ReplicaStripAttrs nsds5ReplicaStripAttrs: modifiersname modifytimestamp internalmodifiersname internalmodifytimestamp
15.11. 読み取り専用レプリカの設定
- 実行中の更新がないことを確認します。
- サプライヤーサーバーを停止します。
- 変更ログを有効にします。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=changelog5,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: changelog5 nsslapd-changelogdir: /var/lib/dirsrv/slapd-instance_name/changelogdb/
- レプリカロールを変更します。
- 単一マスターの場合:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify replace: nsDS5ReplicaType nsDS5ReplicaType: 3 - replace: nsDS5Flags nsDS5Flags: 1 - replace: nsDS5ReplicaId nsDS5ReplicaId: unique_replica_id - delete: nsDS5ReplicaBindDN
- マルチマスターの場合:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify replace: nsDS5ReplicaType nsDS5ReplicaType: 3 - replace: nsDS5Flags nsDS5Flags: 1 - replace: nsDS5ReplicaId nsDS5ReplicaId: unique_replica_id - replace: nsDS5ReplicaBindDN nsDS5ReplicaBindDN: cn=Replication Manager,cn=config
- Directory Server インスタンスを停止します。
# systemctl stop dirsrv
/etc/dirsrv/slapd-instance/dse.ldif
ファイルをバックアップします。# cp /etc/dirsrv/slapd-instance_name/dse.ldif \ /etc/dirsrv/slapd-instance_name/dse.ldif-1
バックアップファイルdse.ldif.bak
には名前を付けないでください。Directory Server は、このファイル名を使用してdse.ldif
ファイルの既知の作業コピーを保持します。/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルを編集します。- レプリカ合意を検索します。以下に例を示します。
dn: cn=replica,cn=dc\5c3Dexample\5c2Cdc\5c3Dcom,cn=mapping tree,cn=config
- すべてのレプリカ合意から
nsState
属性を含む行を削除します。
- Directory Server インスタンスを停止します。
# systemctl start dirsrv.target
- エラーメッセージがないか、エラーログファイルを監視します。詳細は、「ログの表示」 を参照してください。レプリケーションが失敗した場合は、以下を行います。
- すべてのレプリカ合意を削除します( 「レプリケーショントポロジーからのサプライヤーの削除」 )。
- レプリケーションを無効にします: 「レプリカ合意の無効化および再有効化」
- changelog 設定を削除します( 「Changelog の削除」 )。
- Directory Server および管理コンソールを再起動します。
# systemctl restart dirsrv.target # systemctl restart dirsrv-admin.service
- レプリケーションを有効にします( 「レプリカ合意の無効化および再有効化」 )。
- レプリカ合意の作成: 「レプリケーションシナリオ」
15.12. レプリケーショントポロジーからのサプライヤーの削除
- 削除するレプリカで、 更新を防ぐためにデータベースを読み取り専用モードにします。
# ldapmodify -D "cn=Directory Manager" -W -x -p 389 -h dead-replica.example.com dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-readonly nsslapd-readonly: on
レプリカが保留中の変更をすべてフラッシュするまで数分待機します。 - トポロジー内の他のすべてのサプライヤーで、削除するレプリカとのレプリカ合意を削除します。
# ldapmodify -D "cn=Directory Manager" -W -x -p 389 -h replica1.example.com dn: cn=Agmt_with_dead-replica,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: delete
- 削除するレプリカで、削除する レプリカのレプリカ ID を取得します。これは設定エントリーの
nsds5replicaid
属性にあります。# ldapsearch -xLLL -D "cn=Directory Manager" -W -s sub -b cn=config objectclass=nsds5replica nsds5replicaid dn: cn=dead-replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsds5replicaid: 55 ...
- 削除するレプリカで、 すべてのレプリカ合意エントリーとその独自の設定エントリーを削除します。
# ldapmodify -D "cn=Directory Manager" -W -x -p 389 -h dead-replica.example.com dn: cn=to_replica1,cn=dead-replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: delete ... dn: cn=to_replica2,cn=dead-replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: delete dn: cn=dead-replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: delete
- トポロジー内の他のマスターサーバーの 1 つで、 レプリカ ID で クリーン コマンドを実行します。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=clean 55, cn=cleanallruv, cn=tasks, cn=config objectclass: extensibleObject replica-base-dn: dc=example,dc=com replica-id: 55 cn: clean 55各レプリカの tombstone エントリーを検索して、他のレプリカでタスクの進捗を監視できます。# ldapsearch -xLLL -D "cn=Directory Manager" -W -h remaining-replica.example.com -b "dc=example,dc=com" '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' nsds50ruv
15.13. レプリケーションを使用した削除されたエントリーの管理
nsDS5ReplicaTombstonePurgeInterval
属性の設定)。パージは古い tombstone エントリーを削除します。tombstone エントリーは、指定の期間 (nsDS5ReplicaPurgeDelay
属性で設定) に保存されます。tombstone エントリーが遅延期間よりも古い場合が、次のパージジョブで復元します。
- パージ操作は、特にサーバーが多くの削除操作を処理する場合に時間がかかりません。パージの間隔が低すぎるか、サーバーのリソースを過剰に消費してパフォーマンスに影響を及ぼす可能性があります。
- サプライヤーは、tombstone エントリーなどの変更情報を使用して、初期化後に Prime レプリケーションを実行します。コンシューマーを効果的に再初期化し、レプリケーションの競合を解決するには、変更のバックログが十分にある必要があります。パージ遅延 (tombstone エントリーの経過時間) を低く設定しすぎないでください。または、レプリケーションの競合の解決に必要な情報が失われる可能性があります。レプリケーショントポロジーの長いレプリケーションスケジュールよりもわずかに長くパージ遅延を設定します。たとえば、最長のレプリケーションの間隔が 24 時間の場合は、tombstone エントリーを 25 時間保持します。これにより、コンシューマーを初期化するのに十分な変更履歴が確保され、異なるサプライヤーに保存されているデータが乖離するのを防ぐことができます。
# ldapmodify -D "cn=Directory Manager" -W -x -h supplier1.example.com dn: cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config changetype: modify replace: nsDS5ReplicaTombstonePurgeInterval nsDS5ReplicaTombstonePurgeInterval: 43200 # in seconds, 12 hours - changetype: modify replace: nsDS5ReplicaPurgeDelay nsDS5ReplicaPurgeDelay: 90000 # in seconds, 25 hours
nsDS5ReplicaTombstonePurgeInterval
属性および nsDS5ReplicaPurgeDelay
属性に設定します。どちらの属性も値が秒単位で設定されているため、パージ操作をほぼ即座に開始することができます。
15.14. Changelog 暗号化の設定
前提条件
Procedure
- changelog 暗号化を有効にするサーバーを除き、以下のコマンドを入力してレプリケーショントポロジー内のすべてのインスタンスを停止します。
# systemctl stop dirsrv@instance_name
- changelog 暗号化を有効にするサーバーで、以下を実行します。
- changelog をエクスポートするタスクを作成します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replica,cn=suffix,cn=mapping tree,cn=config changetype: modify add: nsds5Task nsds5Task: CL2LDIF
Directory Server は、エクスポートを/var/lib/dirsrv/slapd-instance_name/changelogdb/
ディレクトリーに保存します。 - インスタンスを停止します。
# systemctl stop dirsrv@instance_name
/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルの dn: cn=changelog5,cn=config エントリーに、以下の設定を追加します。nsslapd-encryptionalgorithm: AES
- インスタンスを起動します。
# systemctl start dirsrv@instance_name
- changelog をインポートするタスクを作成します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replica,cn=suffix,cn=mapping tree,cn=config changetype: modify add: nsds5Task nsds5Task: LDIF2CL
- 以下のコマンドを実行して、レプリケーショントポロジー内の他のサーバー上のインスタンスをすべて起動します。
# systemctl start dirsrv@instance_name
検証
- エントリーの更新など、LDAP ディレクトリーに変更を加えます。
- インスタンスを停止します。
# systemctl stop dirsrv@instance_name
- 以下のコマンドを実行して、changelog の一部を表示します。
# dbscan -f /var/lib/dirsrv/slapd-instance_name/changelogdb/replica_name_replGen.db | tail -50
changelog が暗号化されている場合は、暗号化されたデータのみが表示されます。 - インスタンスを起動します。
# systemctl start dirsrv@instance_name
15.15. Changelog の削除
15.15.1. コマンドラインを使用した Changelog の削除
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=changelog5,cn=config changetype: delete
15.15.2. コンソールを使用した changelog の削除
- Directory Server コンソールで、Configuration タブを選択します。
- 左側のナビゲーションツリーで Replication フォルダーを選択し、右側のペインで Supplier Server Settings タブを選択します。
- Enable Changelog チェックボックスの選択を解除します。
- Directory Server を再起動します。「コンソールを使用した Directory Server インスタンスの起動および停止」 を参照してください。
- コンシューマーを再初期化します。「コンシューマーの初期化」 を参照してください。
15.16. レプリケーション changelog ディレクトリーの移動
/var/lib/dirsrv/slapd-instance_name/new_changelogdb/
に変更するには、以下のコマンドを実行します。
- 現在のディレクトリーを表示します。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x \ -b "cn=changelog5,cn=config" nsslapd-changelogdir ... nsslapd-changelogdir: /var/lib/dirsrv/slapd-instance_name/changelogdb/
ディレクトリーを移動するには、後のステップで表示されたパスが必要です。 - 新しいパスを設定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=changelog5,cn=config changetype: modify replace: nsslapd-changelogdir nsslapd-changelogdir: /var/lib/dirsrv/slapd-instance_name/new_changelogdb/
- Directory Server インスタンスを停止します。
# systemctl stop dirsrv@instance_name
- 前のディレクトリーのコンテンツを
/var/lib/dirsrv/slapd-instance_name/new_changelogdb/
に移動します。# mv /var/lib/dirsrv/slapd-instance_name/changelogdb/ \ /var/lib/dirsrv/slapd-instance_name/new_changelogdb/
- 以前のディレクトリーを削除します。
# rm /var/lib/dirsrv/slapd-instance_name/changelogdb/
- Directory Server インスタンスを起動します。
# systemctl start dirsrv@instance_name
15.17. レプリケーション changelog のトリム
nsslapd-changelogmaxage
(推奨): このパラメーターで設定された時間を超えた場合はエントリーを削除します。nsslapd-changelogmaxentries
: レコードの合計数がこのパラメーターに設定された値を超えると、最も古いエントリーを削除します。
15.17.1. レプリケーション changelog のトリムの有効化
7d
) より古いエントリーを自動的に削除します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=changelog5,cn=config changetype: modify replace: nsslapd-changelogmaxage nsslapd-changelogmaxage: 7d
nsslapd-changelogmaxentries
の最大エントリー数ではなく、nsslapd-changelogmaxage
で最大期間を設定することを推奨します。nsslapd-changelogmaxage
に設定された時間は、nsDS5ReplicaPurgeDelay
で設定したレプリケーションパージ遅延と一致する必要があります。nsDS5ReplicaPurgeDelay
の詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス のパラメーターの説明を参照してください』。
15.17.2. 大きな changelog のサイズを手動で縮小
- changelog サイズを縮小した後にパラメーターをリセットできるようにするには、対応するパラメーターの現在の値を表示します。以下に例を示します。
# ldapsearch -x -D 'cn=Directory Manager' -W -b "cn=changelog5,cn=config" \ nsslapd-changelogmaxage nsslapd-changelogcompactdb-interval \ nsslapd-changelogtrim-interval nsslapd-changelogmaxage dn: cn=changelog5,cn=config nsslapd-changelogmaxage: 7d nsslapd-changelogcompactdb-interval: 2592000 nsslapd-changelogtrim-interval: 300
出力に表示されないパラメーターには設定されず、Directory Server はデフォルト値を使用します。デフォルト値は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンス のパラメーターの説明を参照してください』。 - 以下のパラメーターの値を一時的に減らします。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=changelog5,cn=config changetype: modify replace: nsslapd-changelogmaxage nsslapd-changelogmaxage: 3d - replace: nsslapd-changelogtrim-interval nsslapd-changelogtrim-interval: 30 - replace: nsslapd-changelogcompactdb-interval nsslapd-changelogcompactdb-interval: 300
この設定により、Directory Server は、次の 30 秒で (nsslapd-changelogtrim-interval
)、3 日 (nsslapd-changelogmaxage
) よりも古い changelog エントリーを削除します。 - Directory Server インスタンスを再起動して、
nsslapd-changelogcompactdb-interval
パラメーターの新しい値が有効になります。# systemctl restart dirsrv@instance
次のデータベースの更新後、nsslapd-changelogcompactdb-interval
パラメーターで設定した時間間隔内でデータベースが自動的に圧縮されます。 - 更新されたパラメーターを以前の値にリセットします。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=changelog5,cn=config changetype: modify replace: nsslapd-changelogmaxage nsslapd-changelogmaxage: 7d - replace: nsslapd-changelogtrim-interval nsslapd-changelogtrim-interval: 300 - replace: nsslapd-changelogcompactdb-interval nsslapd-changelogcompactdb-interval: 2592000
重要パフォーマンス上の理由から、短い間隔設定を永続的に使用しないでください。 - Directory Server インスタンスを再起動します。
# systemctl restart dirsrv@instance
15.18. コンシューマーの初期化
nsslapd-idletimeout
設定を十分な期間(または無制限の時間)に設定する必要があります。これにより、操作がタイムアウトする前にデータベース全体を初期化できるようにする必要があります。または、サプライヤーバインド DN エントリーの nsIdleTimeout
設定は、グローバル設定を変更しなくても、オンライン初期化操作を完了できるように設定することも可能です。
15.18.1. コンシューマーの初期化のタイミング
15.18.2. コンソールを使用したオンラインコンシューマーの初期化
- レプリカ合意を作成します。
- サプライヤーサーバーの Directory Server コンソールで、Configuration タブを選択します。
- Replication フォルダーを展開し、複製されたデータベースを展開します。レプリカ合意を右クリックし、ポップアップメニューから Initialize Consumer を選択します。コンシューマーのレプリカにすでに保存された情報を削除するというメッセージが表示されます。
- 確認ボックスの Yes をクリックします。
15.18.3. コマンドラインを使用したコンシューマーオンラインの初期化
nsds5BeginReplicaRefresh
属性をレプリカ合意エントリーに追加することで実行できます。この属性はデフォルトでは存在しないため、コンシューマーの初期化が完了すると自動的に削除されます。
- コンシューマーを初期化するサプライヤーサーバーでレプリカ合意の DN を検索します。以下に例を示します。
# ldapsearch -h supplier1.example.com -p 389 -D "cn=Directory Manager" -W -s sub -b cn=config "(objectclass=nsds5ReplicationAgreement)"
このコマンドは、サプライヤーに設定されたすべてのレプリカ合意を LDIF 形式で返します。初期化されるコンシューマーとのレプリカ合意の DN を取得します。これは、編集されるレプリカ合意です。 - レプリカ合意を編集し、
nsds5BeginReplicaRefresh
属性を追加します。# ldapmodify -D "cn=Directory Manager" -W -x -h supplier1.example.com dn: cn=ExampleAgreement,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config changetype: modify replace: nsds5BeginReplicaRefresh nsds5BeginReplicaRefresh: start
ldapmodify は入力を要求しません。LDIF ステートメントに入力するだけで、LDIF ステートメントが完了すると 2 回到達されます。Ctrl+C を押して ldapmodify ユーティリティーを閉じます。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -s base -b 'cn=ExampleAgreement,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config' '(objectclass=*)'
nsds5BeginReplicaRefresh
属性が存在する場合は、初期化が進行中です。初期化が完了すると、属性 nsds5ReplicaLastInitStatus
にステータスが表示されます。初期化に成功すると、nsds5ReplicaLastInitStatus
の値は Total update succeeded になります。初期化に成功しなかった場合、この属性はエラーに関する情報を表示します。追加の情報については、サプライヤーとコンシューマーの両方にエラーログを確認します。
15.18.4. コマンドラインを使用した手動コンシューマーの初期化
- レプリカ合意を作成します。
- サプライヤーサーバーのレプリカを LDIF ファイルにエクスポートします。「レプリカから LDIF へのエクスポート」 を参照してください。
- サプライヤーレプリカの内容を持つ LDIF ファイルをコンシューマーサーバーにインポートします。「LDIF ファイルのコンシューマーサーバーへのインポート」 を参照してください。
15.18.4.1. レプリカから LDIF へのエクスポート
- レプリカ合意の作成時に、Replication Agreement Wizard の Initialize Consumer ダイアログボックスで Create consumer initialization file を選択します。
- Directory Server Console から、Replication フォルダーでレプリカ合意を右クリックし、ポップアップメニューから Create LDIF File を選択します。
- 「コマンドラインを使用した LDIF へのデータベースのエクスポート」 で説明されているように、export コマンドを使用してコマンドラインから実行します。コマンドラインツールで LDIF へのエクスポートは、データベースをレプリカとしてエクスポートするオプションを使用する必要があります。つまり、エクスポートされた LDIF には、LDIF のインポート時にコンシューマーを初期化する適切なエントリーが含まれていることを意味します。db2ldif スクリプトおよび db2ldif.pl スクリプトの場合、これは
-r
オプションになります。以下に例を示します。# db2ldif
-r
-n database1 -a /export/output.ldifcn=export,cn=tasks,cn=config エントリーの場合、これはnsExportReplica
属性です。#ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=example export,cn=export,cn=tasks,cn=config changetype: add objectclass: extensibleObject cn: example export nsInstance: userRoot nsFilename: /home/files/example.ldifnsExportReplica: true
15.18.4.2. LDIF ファイルのコンシューマーサーバーへのインポート
15.19. レプリケーション更新の強制
15.19.1. コンソールからのレプリケーション更新の強制
- Directory Server コンソールで、Configuration タブをクリックし、Replication フォルダーおよびデータベースノードを展開し、更新するレプリカに対応するレプリカ合意を選択します。
- レプリカ合意を右クリックし、ドロップダウンリストから Send Updates Now を選択します。
15.19.2. コマンドラインでのレプリケーション更新の強制
15.20. TLS 上のレプリケーション
- サプライヤーサーバーとコンシューマーサーバーの両方が TLS を使用するように設定します。
- コンシューマーサーバーが、サプライヤーサーバーの証明書を サプライヤー DN として認識するように設定します。これは、簡易認証ではなく TLS クライアント認証のみを使用します。
certutil
を使用して証明書署名要求 (CSR) を生成する場合は、--nsCertType=sslClient,sslServer
オプションをコマンドに渡し、必要な証明書を設定します。
- SSL クライアント認証 を選択します。TLS クライアント認証では、サプライヤーサーバーおよびコンシューマーサーバーは証明書を使用して相互に対して認証します。
- Simple Authentication を選択します。簡易認証では、サプライヤーサーバーおよびコンシューマーサーバーはバインド DN およびパスワードを使用して相互に対して認証を行います。これは、提供される Replication Agreement Wizard テキストフィールドに指定されます。簡易認証はセキュアなチャンネルで実行されますが、証明書はありません。注記シンプルなパスワード認証(「セキュアなバインドの要求」)にセキュアなバインドが必要な場合は、セキュアな接続で行われる場合を除き、レプリケーション操作は失敗します。セキュアな接続(TLS および Start TLS 接続または SASL 認証)の使用が推奨されます。
15.21. レプリケーションのタイムアウト期間の設定
nsDS5ReplicaTimeout
は、レプリケーション操作がコンシューマーからの応答を待ってから、タイムアウトして失敗するまでの秒数を設定します。最適な数値を設定するには、アクセスログでレプリケーション処理にかかる平均時間を確認し、それに合わせてタイムアウト期間を設定します。nsDS5DebugReplicaTimeout
は、デバッグロギングが有効な場合にレプリケーション操作のタイムアウト期間を設定します。デバッグロギングではディレクトリー操作が遅くなる可能性があるため、この設定はnsDS5ReplicaTimeout
設定よりも大幅に高くなる可能性があります。この属性は任意で、このパラメーターが適用されるエラーログレベルを設定できます。デフォルトはレプリケーションのデバッグ (8192) です。
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=replica,cn="ou=People,dc=example,dc=com",cn=mapping tree,cn=config changetype: modify add: nsDS5ReplicaTimeout nsDS5ReplicaTimeout: 600 add: nsDS5DebugReplicaTimeout nsDS5DebugReplicaTimeout: 6000
15.22. 管理サーバーのフェイルオーバー用の o=NetscapeRoot の複製
- 最初の Directory Server インスタンスをインストールして設定します。setup-ds-admin.pl スクリプトには、inf を参照する -f オプションがあります
。
inf
を使用して、ConfigFile パラメーターを使用して LDIF ファイルをインポートでき、LDIF ファイルはデータベース、接尾辞、およびレプリケーションエントリーを作成できます。(そのファイル
の詳細は『 『Red Hat Directory Server インストールガイド』を参照してください』。)# setup-ds-admin.pl -f /tmp/server1.inf
server1 の o=NetscapeRoot データベースをマルチマスターサプライヤーレプリカとして設定するには、infファイルで以下のステートメント
を使用します。[slapd] ... ConfigFile = repluser.ldif 例15.4「サプライヤーバインド DN エントリーの例」 ConfigFile = changelog.ldif 例15.1「Changelog エントリーの例」 ConfigFile = replica.ldif 例15.2「サプライヤーレプリカエントリーの例」 ConfigFile = replagreement.ldif 例15.3「レプリカ合意エントリーの例」 ...
- 2 番目の Directory Server インスタンスをインストールして設定します。2 番目のサーバー server2.example.com の場合は、setup-ds.pl コマンドを使用して、ローカルの管理サーバーをインストールせずに Directory Server インスタンスをインストールします。
# setup-ds.pl -f /tmp/server2.inf
server2 では、inf
ファイルを使用して、server2 で o=NetscapeRoot データベースをマルチマスターサプライヤーレプリカとして作成および設定します。[slapd] ... ConfigFile = netscaperootdb.ldif 「コマンドラインでのルート接尾辞およびサブ接尾辞の作成」 ConfigFile = repluser.ldif 例15.4「サプライヤーバインド DN エントリーの例」 ConfigFile = changelog.ldif 例15.1「Changelog エントリーの例」 ConfigFile = replica.ldif 例15.2「サプライヤーレプリカエントリーの例」 ConfigFile = replagreement.ldif 例15.3「レプリカ合意エントリーの例」 ...
- server 1 から server 2 で o=NetscapeRoot データベースを初期化します。
nsds5replicarefresh
属性を server1 のレプリカ合意に追加します。# ldapmodify -D "cn=Directory Manager" -W -x -h supplier1.example.com dn: cn=ExampleAgreement1,cn=replica,cn=o=NetscapeRoot,cn=mapping tree,cn=config changetype: modify replace: nsds5beginreplicarefresh nsds5beginreplicarefresh: start
- register-ds-admin.pl を実行して server2 にローカル管理サーバーを作成し、server2 の設定ディレクトリーを server1 から独自の o=NetscapeRoot データベースに切り替えます。
# register-ds-admin.pl
- 以下のアクセス制御命令(ACI)を server2 に追加し、
Configuration Administrators Group
、サーバーインスタンスエントリーSIE グループ
、およびadmin
ユーザーのメンバーが server2 に属するサフィックスで実行できます。たとえば、dc =example,dc=com 接尾辞で実行する場合は、以下を入力します。# ldapmodify -D "cn=Directory Manager" -W -x -h server2.example.com dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr="*")(version 3.0; acl "Configuration Administrators Group"; allow (all) groupdn="ldap:///cn=Configuration Administrators,ou=Groups, ou=TopologyManagement,o=NetscapeRoot";) - add: aci aci: (targetattr="*")(version 3.0; acl "Configuration Administrator"; allow (all) userdn="ldap:///uid=admin, ou=Administrators,ou=TopologyManagement,o=NetscapeRoot";) - add: aci aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) groupdn = "ldap:///cn=slapd-instance,cn=Red Hat Directory Server,cn=Server Group, cn=machine_name,ou=example.com,o=NetscapeRoot";)
- server2 で PTA プラグインを無効にし、o=NetscapeRoot の管理者ユーザーのバインド操作を server1 に渡さないようにします。「Directory Server コンソールでプラグインの有効化」 を参照してください。
15.23. Retro Changelog プラグインの使用
changeLogEntry
があります。changelog エントリーで可能な属性の一覧は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 の 『changelog 属性』 セクションを参照してください。
15.23.1. Retro Changelog プラグインの有効化
dse.ldif
の cn=Retro Changelog Plugin,cn=plugins,cn=config エントリーに保存されます。コマンドラインから Retro Changelog プラグインを有効にするには、以下を実行します。
- 以下の LDIF 更新ステートメントが含まれる LDIF ファイルを作成します。
dn: cn=Retro Changelog Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
- ldapmodify コマンドを使用して、LDIF ファイルをディレクトリーにインポートします。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -f retro.ldif
- サービスを再起動します。サーバーの再起動に関する情報は、「Directory Server インスタンスの起動および停止」 を参照してください。
15.23.2. Retro Changelog のトリム
nsslapd-changelogmaxage
パラメーターで設定したレコードの最大年齢を下げ、nsslapd-changelog-trim-interval
で設定した次のトリミング間隔を実行すると、Retro Changelog のサイズが自動的に縮小されます。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Retro Changelog Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-changelogmaxage nsslapd-changelogmaxage: 2d
15.23.3. Retro Changelog の検索および変更
15.23.4. Retro Changelog およびアクセス制御ポリシーの見直し
- すべての認証されたユーザー (userdn=anyone。ただし。userdn=all である匿名アクセスと混同しないようにしてください) には、Retro Changelog のトップエントリー cn=changelog に対して、読み取り、検索、および比較の権限が与えられます。
- Directory Manager に暗黙的ではなく、書き込みアクセスと削除のアクセスは付与されません。
aci
属性を変更します。
15.24. レプリケーションステータスの監視
15.24.1. コンソールからのレプリケーションのステータスの監視
- Status タブを選択し、左側のナビゲーションツリーで Replication Status を選択します。右側のペインに、このサーバーに設定した各レプリカ合意に関する情報が含まれるテーブルが表示されます。
- 表示されるステータス情報は、表15.1「Directory Server コンソールのレプリケーションステータス」 で説明されています。
テーブルヘッダー | 詳細 |
---|---|
合意 | レプリカ合意の名前。 |
レプリカ接尾辞 | 複製される接尾辞。 |
supplier | 合意内のサプライヤーサーバー。 |
コンシューマー | この合意のコンシューマーサーバー |
変更数 | サーバーの開始以降、このレプリカに送信された変更を示す比率。この値の形式は replica_id:changes_sent/changes_skipped になります。そのため、レプリカ ID が 7 で、100 個の変更が送信され、変更が省略されない場合、変更の数の値は 7:100/0 になります。 |
Last replica update began | 最新のレプリケーション更新が開始された時間。 |
Last replica update ended | 最新のレプリケーション更新が完了した時間。 |
Last update message | 最新のレプリケーション更新のステータス。 |
コンシューマーの初期化 | コンシューマーの初期化の現在のステータス(進捗中または否定)。 |
最後のコンシューマーの初期化更新メッセージ | コンシューマーの最後の初期化のステータス。 |
最後のコンシューマーの初期化が開始 | コンシューマーレプリカの初期化が開始された時間。 |
最後のコンシューマーの初期化が終了しました | コンシューマーレプリカの初期化が終了したとき。 |
15.24.2. Admin Express からのレプリケーションの監視
- Replication Status ページはサプライヤーサーバーでのみ利用できます。(他のタイプのレプリカ用に開くこともできます。利用可能な情報がなく、このメッセージ にはマスターではないか、レプリカ合意がないという メッセージがあります。)
- 設定ファイルは、管理サーバーがアクセスできるディレクトリーにあり、このファイルは Administration Server ユーザーが読み取り可能でなければなりません。デフォルトでは、ユーザーは dirsrv です。ユーザーは
console.conf ファイルに設定されます
。ユーザーを確認するには、grep を使用して値を返します。# grep \^User /etc/dirsrv/admin-serv/console.conf
設定ファイルは、管理サーバーユーザーが読み取り可能で、他のユーザーも行わないようにする必要があります。したがって、ファイルのパーミッションをリセットすることを検討してください。# chmod 0400 filename
- 設定ファイルを作成します。設定ファイルでは、レプリケーションを監視するすべてのサーバーを一覧表示し、ホスト名または IPv4 アドレスまたは IPv6 アドレス、ポート、使用するバインド認証情報、次にエイリアスおよび時間遅延の色の任意設定を提供します。
#Configuration File for Monitoring Replication Using Admin Express [connection] Required. Gives the server host (or IPv4 or IPv6 address), port, supplier bind DN, and password. host1.example.com:389:cn=replication manager:mypassword host2.example.com:3891:cn=replication manager:altpassword [alias] Optional. Gives a friendly-name alias to the servers and consumers. M1 = host1.example.com:389 M2 = host2.example.com:3891 C1 = host3.example.com:3892 C2 = host4.example.com:3890 [color] Optional. Sets the color for the time lag boxes. 0 = #ccffcc 5 = #FFFFCC 60 = #FFCCCC
設定ファイルは、管理サーバーがアクセスできるディレクトリーにあり、このファイルは Administration Server ユーザーが読み取り可能でなければなりません。デフォルトでは、ユーザーは dirsrv です。ユーザーはconsole.conf ファイルに設定されます
。ユーザーを確認するには、grep を使用して値を返します。# grep \^User /etc/dirsrv/admin-serv/console.conf
設定ファイルは、管理サーバーユーザーが読み取り可能で、他のユーザーも行わないようにする必要があります。したがって、ファイルのパーミッションをリセットすることを検討してください。# chmod 0400 filename
- Administration Server Web ページで Admin Express リンクをクリックし、ログインします。
- サプライヤーサーバー 名の横にある Replication Status リンクをクリックします。
- Configuration file フィールドに設定ファイルへのパスを入力します。また、更新レートを設定します。これは、レプリケーションステータスページの更新頻度です。デフォルトは 300 秒です。
図15.5 レプリケーションステータスの表示
図15.6 レプリケーションステータスの表示
表 | 詳細 |
---|---|
テーブルヘッダー | テーブルヘッダーには、サプライヤーレプリカのレプリカ ID、複製された接尾辞 root(dc =example,dc=comなど)、およびサプライヤー上の最大変更状態番号(CSN)が表示されます。(CSN はサプライヤーの最新変更の ID で、サプライヤーの最大 CSN には、最後に受信した更新が表示されます。) |
最大 CSN | コンシューマーがサプライヤーから送信された最新の CSN の ID 番号。 |
時間ラグ | コンシューマーがサプライヤーから更新を受け取るのにかかる時間。これは、サプライヤーとコンシューマーの最大 CSN 間の時間差です。コンシューマーがサプライヤーと同期している場合、時間ラグは 0 になります。 |
Last Modify Time | コンシューマーの最後の更新時間を指定します(最後の CSN エントリーが送信された時間)。 |
supplier | そのコンシューマーに更新を送信するサプライヤーの名前を指定します。これは、コンシューマーが複数のサプライヤーから更新を受信する場合や、Replication Status ページに複数のサプライヤーを監視する場合に便利です。 |
送信/スキップ | レプリケーション更新でサプライヤーから送信された変更の数およびスキップされた数。数字はサプライヤーのメモリーにのみ保持され、サプライヤーが再起動された場合は消去されます。 |
更新のステータス | 最後の更新のステータスコード(および意味)。すべての サプライヤーがビジーなレプリカを取得できないことを伝えると、この列はデッドロックを示している可能性があります。サプライヤーの 1 つが更新を行う場合、ビジーなメッセージが発生するのは普通です。 |
Update Start and End | 最新の更新プロセスの開始および終了時のタイムスタンプ。 |
スケジュール | 設定されたレプリケーションスケジュール。0:- は、コンシューマーがサプライヤーによって継続的に更新されることを意味します。 |
SSL? | サプライヤーが TLS 経由でコンシューマーに接続するかどうかを示します。 |
15.24.3. コマンドラインからのレプリケーションの監視
s
オプションを追加して /usr/bin/repl-monitor.pl
スクリプトを実行します。スクリプトはレポートをプレーンテキスト形式で出力し、たとえばユーザーがレプリケーションステータスを迅速に判別したい場合に有用ですが、ブラウザーは利用できません。「Admin Express からのレプリケーションの監視」 で説明されている Admin Express と同様に、repl-monitor.pl
は、リアルタイムでレプリケーションの状態を表示します。
repl-monitor.pl
スクリプトは、多くのコマンドラインオプションを受け入れます。これの使用方法は、repl-monitor(1) の man ページまたは Directory Server Configuration, Command, and File Referenceを参照してください。
-s
オプションを指定せずに実行すると、repl -monitor.pl
により、レポートが HTML ファイルとして生成されます。
15.25. 2 つの Directory Server インスタンスの比較
ds-replcheck
ユーティリティーを使用すると、2 つのオンラインサーバーを比較できます。また、ds-replcheck
は、オフラインモードで 2 つの LDIF 形式のファイルを比較できます。
-l time_in_seconds
パラメーターを ds-replcheck
に渡すことで、スクリプトでラグ時間値を使用します。デフォルトでは、この値は 300 秒 (5 分) に設定されます。ユーティリティーがラグ時間内にある不整合を検出すると、報告されません。これにより、誤検出が軽減されます。
ds-replcheck
はこれらの属性を異なると報告します。これらの属性を無視するには、-i attribute_list
パラメーターをユーティリティーに渡します。
dc=example,dc=com
接尾辞を比較するには、以下のコマンドを実行します。
# ds-replcheck -D "cn=Directory Manager" -W \ -m ldap://server1.example.com:389 \ -r ldap://server2.example.com:389 \ -b "dc=example,dc=com"
- データベース RUV
- データベースの Replication Update Vectors (RUV) と、最小および最大の Change Sequence Numbers (CSN) を一覧表示します。以下に例を示します。
Master RUV: {replica 1 ldap://server1.example.com:389} 58e53b92000200010000 58e6ab46000000010000 {replica 2 ldap://server2.example.com:389} 58e53baa000000020000 58e69d7e000000020000 {replicageneration} 58e53b7a000000010000 Replica RUV: {replica 1 ldap://server1.example.com:389} 58e53ba1000000010000 58e6ab46000000010000 {replica 2 ldap://server2.example.com:389} 58e53baa000000020000 58e7e8a3000000020000 {replicageneration} 58e53b7a000000010000
- エントリー数
- tombstone エントリーを含む、両方のサーバー上のエントリーの合計数を表示します。以下に例を示します。
Master: 12 Replica: 10
- Tombstones
- 各レプリカの tombstone エントリーの数を表示します。これらのエントリーは、合計エントリー数に追加されます。以下に例を示します。
Master: 4 Replica: 2
- 競合エントリー
- 各競合エントリーの識別名 (DN)、競合タイプ、および作成された日付を一覧表示します。以下に例を示します。
Master Conflict Entries: 1 - nsuniqueid=48177227-2ab611e7-afcb801a-ecef6d49+uid=user1,dc=example,dc=com - Conflict: namingConflict (add) uid=user1,dc=example,dc=com - Glue entry: no - Created: Wed Apr 26 20:27:40 2017 Replica Conflict Entries: 1 - nsuniqueid=48177227-2ab611e7-afcb801a-ecef6d49+uid=user1,dc=example,dc=com - Conflict: namingConflict (add) uid=user1,dc=example,dc=com - Glue entry: no - Created: Wed Apr 26 20:27:40 2017
- エントリーがありません
- 足りない各エントリーの DN と、エントリーが存在する他のサーバーからの作成日を一覧表示します。以下に例を示します。
Entries missing on Master: - uid=user2,dc=example,dc=com (Created on Replica at: Wed Apr 12 14:43:24 2017) - uid=user3,dc=example,dc=com (Created on Replica at: Wed Apr 12 14:43:24 2017) Entries missing on Replica: - uid=user4,dc=example,dc=com (Created on Master at: Wed Apr 12 14:43:24 2017)
- エントリーの不整合
- 相手のサーバーとは異なる属性を持つエントリーの DN を一覧表示します。状態情報が利用可能な場合は、これも表示されます。属性の状態情報が利用できない場合には、元の値として一覧表示されます。レプリケーションが初めて初期化されてから、値が更新されていないことを意味します。以下に例を示します。
cn=group1,dc=example,dc=com --------------------------- Replica missing attribute "objectclass": - Master's State Info: objectClass;vucsn-58e53baa000000020000: top - Date: Wed Apr 5 14:47:06 2017 - Master's State Info: objectClass;vucsn-58e53baa000000020000: groupofuniquenames - Date: Wed Apr 5 14:47:06 2017
ds-replcheck
ユーティリティーの詳細は、Red Hat 設定、コマンド、およびファイルリファレンス の説明を参照してください。
15.26. 一般的なレプリケーションの競合の解決
nsds5ReplConflict
競合マーカー属性および ldapSubEntry
オブジェクトクラスが含まれます。nsds5ReplConflict
属性は、存在および等価性のためにインデックス化される操作属性です。
# ldapsearch -D "cn=Directory Manager" -W -b "dc=example,dc=com" \ "(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))" \* nsds5ReplConflict
15.26.1. ネーミングの競合の解決
nsuniqueid
の操作属性に格納されている一意の識別子が含まれます。命名の競合が発生すると、この一意の ID が一意でない DN に追加されます。
- uid=user_name,dc=example,dc=com
- nsuniqueid=66446001-1dd211b2+uid=user_name,dc=example,dc=com
- 競合エントリーを削除して、有効なエントリー(uid=user_name,dc=example,dc=com)のみを保持するには、次のコマンドを実行します。
# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x \ uid=nsuniqueid=66446001-1dd211b2+user_name,dc=example,dc=com
- 競合エントリー(nsuniqueid=66446001-1dd211b2+uid=user_name,dc=example,dc=com)のみを保持します。
- 有効なエントリーを削除します。
# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x \ uid=user_name,dc=example,dc=com
- 競合エントリーの名前を変更します。「多値命名属性を使用したエントリーの名前変更」 を参照してください。
- 両方のエントリーを保持するには、競合エントリーの名前を変更します。「多値命名属性を使用したエントリーの名前変更」 を参照してください。
15.26.1.1. 多値命名属性を使用したエントリーの名前変更
- naming 属性の新しい値を使用してエントリーの名前を変更し、古い RDN を保持します。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: nsuniqueid=66446001-1dd211b2+uid=adamss,dc=example,dc=com changetype: modrdn newrdn: uid=NewValue deleteoldrdn: 0
エントリーの名前変更時に RDN を維持する方法は、「deleteOldRDN
パラメーター」 を参照してください。 - naming 属性と conflict マーカー属性の古い RDN 値を削除します。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=NewValue,dc=example,dc=com changetype: modify delete: uid uid: adamss - delete: nsds5ReplConflict -
nsuniqueid
は削除できません。
nsuniqueid uid
値に変更されます。コンソールからこのエントリーを変更しようとすると、多値 RDN を持つエントリーについてエラーの変更を保存できません。
nsuniqueid uid
に設定されていることが分かります。ただし、ユーザー ID と RDN の値を異なる値に変更したり、修正したりすることはできません。たとえば、ユーザー ID がユーザー ID であり、jdoe1 に 変更する必要がある場合はコンソールから実行できません。代わりに ldapmodify コマンドを使用します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=John Doe changetype: modify replace: uid uid: jdoe dn: cn=John Doe changetype: modrdn newrdn: uid=jdoe1 deleteoldrdn: 1
15.26.1.2. 単一の値命名属性でエントリーの名前変更
- 別の naming 属性を使用してエントリーの名前を変更し、古い RDN を保持します。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: nsuniqueid=66446001-1dd211b2+dc=pubs,dc=example,dc=com changetype: modrdn newrdn: cn=TempValue deleteoldrdn: 0
エントリーの名前変更時に RDN を維持する方法は、「deleteOldRDN
パラメーター」 を参照してください。 - naming 属性と conflict マーカー属性の古い RDN 値を削除します。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=TempValue,dc=example,dc=com changetype: modify delete: dc dc: pubs - delete: nsds5ReplConflict -
注記一意の識別子属性nsuniqueid
は削除できません。 - 目的の属性と値のペアでエントリーの名前を変更します。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=TempValue,dc=example,dc=com changetype: modrdn newrdn: dc=NewValue deleteoldrdn: 1
deleteoldrdn
属性の値を 1 に設定して、一時属性と値のペア cn=TempValue を削除します。この属性を保持するには、deleteoldrdn
属性の値を 0 に設定します。
15.26.2. 孤立エントリーの競合の解決
- 競合解決手続で、一致する一意の識別子を持つ削除されたエントリーが見つかった場合、glue エントリーは、そのエントリーの再生であり、glue のオブジェクトクラスと
nsds5ReplConflict
の属性が追加されます。このような場合は、glue エントリーを変更して glue オブジェクトクラスとnsds5ReplConflict
属性を削除して、エントリーを通常のエントリーとして維持するか、その子エントリーを削除します。 - サーバーは glue および extensibleObject オブジェクトクラスを使用して最小のエントリーを作成します。
15.26.3. 廃止または不明なエラーの解決
[22/Jan/2020:17:16:01 -0500] NSMMReplicationPlugin - ruv_compare_ruv: RUV [changelog max RUV] does not contain element [{replica 8 ldap://m2.example.com:389} 4aac3e59000000080000 4c6f2a02000000080000] which is present in RUV [database RUV] <...several more samples...> [22/Jan/2020:17:16:01 -0500] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: for replica dc=example,dc=com there were some differences between the changelog max RUV and the database RUV. If there are obsolete elements in the database RUV, you should remove them using the CLEANALLRUV task. If they are not obsolete, you should check their status to see why there are no changes from those servers in the changelog.
8
を書き留めます。
cleanallruv
ディレクトリータスクを使用して、トポロジー内のすべてのサプライヤーから RUV エントリーを削除します。
cleanallruv
タスクが複製されます。そのため、1 つのマスターでのみ実行する必要があります。
手順15.1 cleanallruv タスク操作を使用した、廃止または欠落したサプライヤーの削除
- 削除されたマスターが他のマスターにメタデータを残す可能性があるため、有効無効を問わず、すべての RUV レコードとレプリカ ID を一覧表示します。
# ldapsearch -o ldif-wrap=no -xLLL -H m1.example.com -D "cn=Directory Manager" -W -b dc=example,dc=com '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' nsDS5ReplicaId nsDS5ReplicaType nsds50ruv dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsDS5ReplicaId: 1 nsDS5ReplicaType: 3 nsds50ruv: {replicageneration} 55d5093a000000010000 nsds50ruv: {replica 1 ldap://m1.example.com:389} 55d57026000000010000 55d57275000000010000 nsds50ruv: {replica 20 ldap://m2.example.com:389} 55e74b8c000000140000 55e74bf7000000140000 nsds50ruv: {replica 9 ldap://m2.example.com:389} nsds50ruv: {replica 8 ldap://m2.example.com:389} 506f921f000000080000 50774211000500080000
返されたレプリカ ID1
、20
、9
、および8
を書き留めます。 - cn=
config
接尾辞のレプリカ設定エントリー DNcn=replica
を検索して、データベースを複製するすべてのマスターで現在定義され、有効なレプリカ ID を一覧表示します。注記コンシューマーおよび読み取り専用ノードには、レプリカ ID が65535
に常に設定され、nsDS5ReplicaType: 3
はマスターを署名します。# ldapsearch -o ldif-wrap=no -xLLL -H m1.example.com m2.example.com -D "cn=Directory Manager" -W -b cn=config cn=replica nsDS5ReplicaId nsDS5ReplicaType dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsDS5ReplicaId: 1 nsDS5ReplicaType: 3 dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsDS5ReplicaId: 20 nsDS5ReplicaType: 3
最初のステップで返されるすべての URI を検索すると(この手順ではm1.example.com
およびm2.example.com
)、返されたマスターのリスト(nsDS5ReplicaType: 3)
を直前の手順の RUV の一覧と比較します。上記の例では、この検索で ID1
と20
のみが返されますが、以前の検索では URIm2.example.com
で9
および8
も返されます。これは、後者の 2 つが削除済みで、その RUV を消去する必要があることを意味します。 - クリーニングが必要な RUV を判別した後に、新しい
cn=cleanallruv,cn=tasks,cn=config
エントリーを作成し、レプリケーション設定に関する以下の情報を提供します。- 複製されたデータベースのベース DN (
replica-base-dn
) - レプリカ ID (
replica-id
) - 欠落しているサプライヤーからの最大変更状態番号 (CSN) に追いつくか、あるいはすべての RUV エントリーを削除して更新を見逃すか (
replica-force-cleaning
)。この属性をno
に設定すると、タスクは設定されているすべてのレプリカが、まず削除されたレプリカからのすべての変更に追いつくのを待ってから、RUV を削除することになります。
# ldapmodify -a -D "cn=Directory Manager" -W -H m2.example.com -x dn: cn=clean 8,cn=cleanallruv,cn=tasks,cn=config objectclass: extensibleObject replica-base-dn: dc=example,dc=com replica-id: 8 replica-force-cleaning: no cn: clean 8
注記cleanallruv
タスクが複製されます。そのため、1 つのマスターでのみ実行する必要があります。整理したい各 RUV に同じことを繰り返す (この手順では ID9
)。 - 先に確認したすべてのレプリカの RUV をクリーンアップした後、最初の手順からの検索を再度使用して、追加の RUV がすべて削除されていることを確認します。
# ldapsearch -o ldif-wrap=no -xLLL -H m1.example.com -D "cn=Directory Manager" -W -b dc=example,dc=com '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' nsDS5ReplicaId nsDS5ReplicaType nsds50ruv dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsDS5ReplicaId: 1 nsDS5ReplicaType: 3 nsds50ruv: {replicageneration} 55d5093a000000010000 nsds50ruv: {replica 1 ldap://m1.example.com:389} 55d57026000000010000 55d57275000000010000 nsds50ruv: {replica 20 ldap://m2.example.com:389} 55e74b8c000000140000 55e74bf7000000140000
上記の出力で分かるように、レプリカ ID8
および9
は存在しなくなり、RUV が正常に消去されていることを示しています。
15.27. レプリケーション関連の問題のトラブルシューティング
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config changetype: modify replace: nsslapd-errorlog-level nsslapd-errorlog-level: 8192
replication-change-log
ファイルとインメモリー変数の内容をダンプします。また、メモリー変数は RUV および maxRUV をパージ します。- Changelog で grep 状態番号(CSN)を解釈します。
- Directory Server から base-64 でエンコードされた changelog を取得し、changelog をデコードします。
agmt=%s (%s:%d) Replica has a different generation ID than the local data
- 理由: このメッセージの最初に指定されたコンシューマーがまだ (正常に)初期化されていないか、または異なるルートサプライヤーから初期化されました。
- 影響: ローカルのサプライヤーは、コンシューマーにデータを複製することはありません。
- 対策: コンシューマーを初期化する前に発生する場合は、このメッセージを無視してください。または、メッセージが永続的であれば、コンシューマーを再初期化します。マルチマスター環境では、すべてのサーバーは、ルートサプライヤーから直接または間接的に 1 回のみ初期化する必要があります。たとえば、M1 は M2 および M4 を初期化し、M2 は M3 の初期化を行います。重要なことは、M2 自身の初期化が完了するまで M3 の初期化を開始しないでください(M1 のコンソール、M1 または M2 のエラーログから合計更新ステータスを確認してください)。また、M2 は M1 を再び初期化しないでください。
Warning: data for replica's was reloaded, and it no longer matches the data in the changelog.Recreating the changelog file.This could affect replication with replica's consumers, in which case the consumers should be reinitialized.
- 理由: このメッセージは、サプライヤーが再開した場合にのみ表示されます。これは、サプライヤーが changelog を書き込みできないか、または最後のシャットダウン時に RUV を消去できなかったことを示しています。前者はディスク領域の問題、後者はサーバーのクラッシュや不適切なシャットダウンなどが原因です。
- 影響: コンシューマの
maxcsn
がサーバーの changelog に存在しない場合、サーバーはコンシューマーに変更を送信できません。 - 対策: ディスク領域と考えられるコアファイル (サーバーの logs ディレクトリー配下) を確認します。これが単一マスターレプリケーションの場合は、コンシューマーを再初期化します。そうでなければ、後にサーバーがコンシューマーの CSN を見つけられないと訴えた場合に、コンシューマーが他のサプライヤーから CSN を入手できるかどうかを確認します。そうでない場合には、コンシューマーを再初期化します。
agmt=%s(%s:%d): Can't locate CSN %s in the changelog (DB rc=%d).The consumer may need to be reinitialized.
- 理由: ディスクが満杯になったり、またはサーバーが適切にシャットダウンしたりしたたあります。あります。
- 影響: ローカルサーバーは、コンシューマーが再初期化されたり、他のサプライヤーから CSN を取得するまで、そのコンシューマーへの追加の変更を送信できません。
- 対策: これが単一マスターのレプリケーションである場合は、コンシューマーを再初期化します。そうでない場合は、コンシューマーが他のサプライヤーから CSN を取得できるかどうかを確認します。そうでない場合には、コンシューマーを再初期化します。
Too much time skew
- 理由: ホストマシンのシステムクロックは同期が非常に低下します。
- 影響: システムクロックは、CSN の一部を生成するのに使用されます。複数のサプライヤー間で変更シーケンスを反映させるために、サプライヤーは、他のサプライヤーのリモートクロックに基づいて、ローカルクロックを転送します。調整は一定量に制限されているため、許可される制限を超過すると、レプリケーションセッションが中止します。
- 対策: Directory Server ホストマシンでシステムクロックを同期します。該当する場合は、それらのホストでネットワークタイムプロトコル (
ntp
) デーモンを実行します。
agmt=%s(%s:%d): Warning: Unable to send endReplication extended operation (%s)
- 理由: コンシューマーが応答しない。
- 影響: コンシューマーが再起動せずに回復すると、サプライヤーからリリースロックメッセージを受け取らないと、コンシューマーのレプリカが永久にロックされる可能性が高くなります。
- 対策: コンシューマーがあらゆるサプライヤーから新しい変更を受け取ったり、レプリケーションモニターを開始できる場合に、このコンシューマーの全サプライヤーが、レプリカがビジーであることを警告しているかどうかを確認します。レプリカが永久にロックされ、サプライヤーを取得できない場合は、コンシューマーを再起動します。
Changelog is getting too big.
- 理由: changelog のパージがオフになっていて、それがデフォルトの設定になっているか、changelog のパージがオンになっていても一部のコンシューマーがサプライヤーよりもずっと遅れているかのどちらかです。
- 対策: デフォルトでは、changelog のパージはオフになっています。コマンドラインからこれを有効にするには、以下のように ldapmodify を実行します。
ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=changelog5,cn=config changetype: modify add: nsslapd-changelogmaxage nsslapd-changelogmaxage: 1d
1d は 1 日を意味します。その他の有効な時間単位は、秒 (s)、分 (m)、時 (h)、および週 (w) になります。0 の場合は、パージをオフにします。changelog パージがオンになっている場合、5 分ごとに起動するパージスレッドは、そのエイジが nsslapd-changelogmaxage の値よりも大きく、そのサプライヤー (サプライヤーまたはハブ) のすべての直接コンシューマーに再生されている場合にその変更を削除します。パージのしきい値に達したときに changelog がパージされていないと思われる場合は、すべてのコンシューマー間でレプリケーションモニターからの最大遅延時間を確認します。パージのしきい値に関わらず、すべての消費者によって再生される前に変更がパージされることはありません。
The Replication Monitor is not responding.
- 理由: LDAPS ポートは一部のレプリカ合意で指定されますが、証明書データベースは Replication Monitor によって指定されず、アクセスできません。LDAPS ポートに問題がある場合は、レプリケーショントポロジー内のいずれかのサーバーがハングする可能性があります。
- 対策: Replication Monitor の設定ファイルで TLS ポートを TLS 以外のポートにマッピングします。たとえば、636 が TLS ポートであり、389 が TLS 以外のポートである場合は、
[connection]
セクションに以下の行を追加します。*:636=389:*:password
In the Replication Monitor, some consumers show just the header of the table.
- 理由: 対応するサプライヤーから作成された変更はありません。この場合、ヘッダー部分の
MaxCSN
: は "None" である必要があります。 - 対策: サプライヤーからの変更がない場合は、何も間違ってありません。
第16章 Red Hat Directory Server と Microsoft Active Directory の同期
16.1. Windows 同期の概要
- Directory Server Windows 同期ユーザーエントリーおよびグループエントリーの同期は同期合意で設定されます。同様に、レプリケーションがレプリカ合意で設定されます。同期合意は、同期するエントリーの種類 (ユーザー、グループ、またはその両方) と、同期する方向の変更 (Directory Server から Active Directory へ、Active Directory から Directory Server へ、またはその両方) を定義します。Directory Server は、マルチマスターレプリケーションプラグインを使用して、ユーザーエントリーおよびグループエントリーを同期します。マルチマスターレプリケーションに使用されるものと同じ changelog は、LDAP 操作として Directory Server から Active Directory に更新を送信するために使用されます。サーバーは、Windows サーバーに対して LDAP 検索操作を実行し、Windows エントリーに加えた変更を対応する Directory Server エントリーと同期します。
- パスワード同期サービス。Directory Server で行われたパスワードの変更は Active Directory に自動的に同期されますが、Active Directory でパスワード変更を認識して Directory Server に送るための特別なフックが必要です。これは、パスワード同期サービスにより実行されます。このアプリケーションは、Windows マシンのパスワード変更をキャプチャーして、LDAPS 経由で Directory Server に送信します。パスワード同期サービスは、すべての Active Directory ドメインコントローラーにインストールする必要があります。
図16.1 Active Directory - Directory Server の同期プロセス
winSyncInterval
パラメーターを設定して、このデフォルトを変更することができます。Dirsync を使用すると、以前の検索以降に変更されたエントリーのみが取得されます。
- 同期合意の作成時に、作成時に新しい Windows エントリー (
nsDS7NewWinUserSyncEnabled
およびnsDS7NewWinGroupSyncEnabled
) を同期するオプションがあります。これらの属性が on に設定されている場合は、既存の Windows ユーザー/グループが Directory Server に同期され、作成されるユーザー/グループが Directory Server と同期されます。Windows サブツリー内では、ユーザーまたはグループのオブジェクトクラスを持つエントリーのみを Directory Server に同期できます。 - Directory Server で、ntUser または ntGroup オブジェクトクラス、および属性を持つエントリーのみを同期できます。
図16.2 マルチマスターディレクトリーサーバー - Windows ドメインの同期
16.2. サポート対象の Active Directory のバージョン
16.3. パスワードの同期
- Password Sync ユーティリティーは、Directory Server と同期する Windows マシンにローカルにインストールする必要があります。
- Password Sync は、Windows マシンを 1 つの Directory Server にのみリンクできます。複数の Directory Server インスタンスと変更を同期するには、マルチマスターレプリケーション用に Directory Server を設定します。
- パスワードの有効期限の警告および時間、バインド試行の失敗、その他のパスワード関連の情報はサーバーごとにローカルで適用され、同期ピアサーバー間で同期されません。
- バインド動作は、すべてのサーバーで発生します。Directory Server サーバーおよび Active Directory サーバーの両方で、同じパスワードポリシーまたは同様のパスワードポリシーを作成してください。
- 同期用に作成されるエントリー (例: サーバーアイデンティティー) には有効期限のないパスワードが必要です。これらの特別なユーザーが期限切れにならないパスワードを持っていることを確認するために、Directory Server のエントリーに
passwordExpirationTime
属性を追加し、それに 20380119031407Z の値 (有効範囲の一番上) を指定します。
16.4. Windows 同期の設定手順
16.4.1. ステップ 1: Directory Server での TLS の設定
- Directory Server と AD 間で共有される CA 証明書
- 同期サービスがアクセスできる Directory Server および AD 同期ピアのサーバー証明書
16.4.2. ステップ 2: Active Directory ドメインの設定
- Group Policy Management コンソールを開き、新しい Group Policy Object(GPO)を作成します。詳細は、Windows のドキュメントを参照してください。
- GPO を右クリックし、Edit を選択して Group Policy Management Editor を開きます。
- Password must meet complexity requirements という名前のポリシーをダブルクリックします。→ → → → に移動し、
- ポリシーを有効にし、をクリックします。
- Group Policy Management Editor および Group Policy Management コンソールを閉じます。
- 認証局をインストールします。
- Administrative Tools エリアで Server Manager を開き、ロールを追加します。
- Active Directory Certificate Services チェックボックスを選択します。
- Select Role Services ページをクリックし、Certification Authority チェックボックスを選択します。
- CA の設定時に、適切な画面で以下のオプションを選択します。
- Enterprise (設定タイプの場合)
- オプション設定の認証局の Web 登録
- AD サーバーを再起動します。
- TLS サーバー証明書を使用するように AD サーバーを設定します。
- AD の完全修飾ドメイン名を証明書サブジェクトとして使用し、証明書要求
.inf
を作成します。以下に例を示します。;----------------- request.inf ----------------- [Version] Signature="$Windows NT$ [NewRequest] Subject = "CN=ad.server.example.com, O=Engineering, L=Raleigh, S=North Carolina, C=US" KeySpec = 1 KeyLength = 2048 Exportable = TRUE MachineKeySet = TRUE SMIME = False PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12 RequestType = PKCS10 KeyUsage = 0xa0 [EnhancedKeyUsageExtension] OID=1.3.6.1.5.5.7.3.1 ;-----------------------------------------------
- 証明書要求を生成します。
# certreq -new request.inf request.req
- AD CA に要求を送信します。以下に例を示します。
# certreq -submit request.req certnew.cer
注記コマンドラインツールがエラーメッセージを返す場合は、Web ブラウザーを使用して CA にアクセスし、証明書要求を送信します。IIS が実行されている場合、CA URL は http://servername/certsrv になります。 - 証明書要求を受け入れます。以下に例を示します。
# certreq -accept certnew.cer
- サーバー証明書が AD サーバーに存在する。
- Run メニューで MMC コンソールを開きます。
- 左側の 証明書(ローカル) メニューを展開します。 項目を展開し、Certificates をクリックします。
- 新しい証明書は他の証明書と共に一覧表示される必要があります。
- Directory Server で、CA 証明書をエクスポートします。
# cd /etc/dirsrv/slapd-instance_name/ # certutil -d . -L -n "CA certificate" -a > dsca.crt
- エクスポートされた証明書を Directory Server から Windows マシンにコピーします。
- Directory Server から AD に CA 証明書をインポートします。
- Administrative Tools を開き、認証局 項目を選択します。
- Trusted Root Certification Authorities を展開します。
- Certificates 項目を右クリックし、Import を選択します。
- ダウンロードした Directory Server CA 証明書を参照し、をクリックします。
- CA 証明書を Trusted Root 認証局 ストアに保存します。
- ドメインコントローラーを再起動します。
16.4.3. ステップ 3: 同期 ID を選択または作成
- 同期合意で指定された AD ユーザー。同期合意で指定されたユーザーは、Directory Server が AD にバインドして更新の送受信を行うエンティティーです。AD ユーザーは Domain Admins グループのメンバーであるか、同等の権限を持っている必要があります。また、ディレクトリーの変更を複製する権限が必要になります。AD でユーザーを追加し、権限を設定する方法は、Microsoft のドキュメントを参照してください。
- Password Sync サービスで指定される Directory Server ユーザー。Password Sync サービスで参照されるユーザーは、同期サブツリー内のすべてのエントリーに対する読み取りおよび書き込みパーミッションを持っている必要があります。また、Password Sync がパスワード変更を更新できるように、Directory Server のパスワード属性への書き込みアクセス権が必要です。
- パスワードで cn=sync user,cn=config などの新規エントリーを作成します。以下に例を示します。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=sync user,cn=config changetype: add objectClass: inetorgperson objectClass: person objectClass: top cn: sync user sn: SU userPassword: secret passwordExpirationTime: 20380119031407Z - ユーザーパスワードの比較および書き込みのために同期ユーザーにアクセスを付与する ACI を設定します。ACI は、同期するサブツリーの上部に設定する必要があります。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=people,dc=example,dc=com changetype: modify add: aci aci: (targetattr="userPassword")(version 3.0;acl "password sync";allow (write,compare) userdn="ldap:///cn=sync user,cn=config";)
セキュリティー上の理由から、Password Sync ユーザーは Directory Manager ではなく、同期されたサブツリーに含めることはできません。
16.4.4. ステップ 4: パスワード同期サービスの インストール
16.4.5. ステップ 5: パスワード同期サービス の設定
- Directory Server で TLS を有効にします。詳細は、「Directory Server での TLS の有効化」を参照してください。注記Password Sync が Directory Server にパスワードを送信するには、TLS が必要です。サービスは、TLS 以外にパスワードを送信せず、Active Directory マシンから Directory Server マシンに送られるクリアテキストパスワードを保護します。つまり、Password Sync は TLS が設定されるまで機能しません。
- Directory Server で、サーバー証明書をエクスポートします。
# certutil -d /usr/lib64/dirsrv/slapd-instance -L -n "CA certificate" -a > dsca.crt
- エクスポートされた証明書を Directory Server から Windows マシンにコピーします。
- Windows マシンでコマンドプロンプトを開き、Password Sync インストールディレクトリーを開きます。
> cd "C:\Program Files\Red Hat Directory Password Synchronization""
- Windows マシンに
cert8.db
データベースおよびkey.db
データベースを作成します。> certutil.exe -d . -N
- Directory Server から新規証明書データベースにサーバー証明書をインポートします。
> certutil.exe -d . -A -n "DS CA cert" -t CT,, -a -i \path\to\dsca.crt
- CA 証明書が正しくインポートされていることを確認します。
> certutil.exe -d . -L -n "DS CA cert"
- Windows マシンを再起動します。システムを再起動するまで、Password Sync サービスは利用できません。
16.4.6. ステップ 6: 同期用の Directory Server データベースの設定
16.4.6.1. コンソールからの同期用の Directory Server の設定
- Directory Server コンソールで、Configuration タブを選択します。
- 左側のナビゲーションツリーで、Replication フォルダーをクリックします。
- メインウィンドウで、Supplier Settings タブをクリックします。
- Enable Changelog データベースを確認します。
図16.3 Configuration タブ
- changelog データベースディレクトリーを設定します。Use default ボタンをクリックして、デフォルトまたは Browse... を使用してカスタムディレクトリーを選択します。
- changelog 設定を保存します。
- Directory Server コンソールで、Configuration タブを選択します。
- 左側のナビゲーションツリーで Replication フォルダーをクリックし、同期するデータベースの名前をクリックします。デフォルトでは、ディレクトリー設定用の NetscapeRoot とディレクトリーエントリー用の userRoot の 2 つのデータベースがあります。Directory Server に追加されているその他のデータベースは、一覧表示できます。
- Enable Replica チェックボックスを選択し、データベースが存在するレプリカのタイプでラジオボタンを選択します。
図16.4 Enable Replica チェックボックス
- Update Settings セクションで、サプライヤー DN を選択または追加します。これは、同期プロセスが実行されるユーザーアカウントです。「ステップ 3: 同期 ID を選択または作成」 で説明されているように、このユーザーは Directory Server 上に配置し、同期される全ユーザーの
userPassword
属性に対するアクセス権が必要です。図16.5 Update Settings セクション
- データベースのレプリケーション設定を保存します。
16.4.6.2. コマンドラインからの同期用の Directory Server の設定
# ldapmodify -a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-instance_name/changelogdb
nsslapd-changelogmaxage: 7d
# ldapmodify -a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=sync replica,cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsds5replica
objectclass: extensibleObject
cn: sync replica
nsds5replicaroot: dc=example,dc=com
nsds5replicaid: 7
nsds5replicatype: 3
nsds5flags: 1
nsds5ReplicaPurgeDelay: 604800
nsds5ReplicaBindDN: cn=sync user,cn=config
16.4.7. ステップ 7: 同期合意の作成
16.4.7.1. コンソールからの同期合意の作成
- Directory Server コンソールで、Configuration タブを選択します。
- 左側のナビゲーションツリーで Replication をクリックし、同期するデータベースを右クリックします。デフォルトのユーザーデータベースは userRoot ですが、Directory Server に新しい接尾辞が追加されるため、追加のデータベースが追加されます。または、データベースを強調表示し、トップツールバーで Object をクリックします。
- メニューから New Windows Synchronization Agreement を選択します。
- 2 つのフィールドに、同期合意の名前と説明を指定します。。
- Windows Sync Server Info ウィンドウで、Windows Domain Information エリアに AD 情報を入力します。
- Windows ドメインの名前。
- 同期するエントリーの種類。ユーザーおよびグループは個別に同期されます。エントリーのタイプを選択すると、Windows サブツリーにあるそのタイプのエントリーがすべて Directory Server に作成されます。
- Windows および Directory Server のサブツリー情報。これは自動的に入力されます。
- ドメインコントローラーのホスト名、IPv4 アドレス、または IPv6 アドレス
- Windows サーバーのポート番号
- 接続タイプを設定します。以下の 3 つのオプションがあります。
- LDAP を使用します。これにより、標準の暗号化されていない接続が設定されます。
- TLS/SSL を使用します。これは、636 などのサーバーのセキュアな LDAPS ポートを介したセキュアな接続を使用します。Directory Server と Windows サーバーの両方が、この接続に対して TLS で実行されるよう適切に設定し、サーバー証明書を信頼するために相互の CA 証明書をインストールする必要があります。
- Start TLS を使用します。Start TLS を使用して、サーバーの標準ポートでセキュアな接続を確立します。通常の TLS と同様に、これらのピアサーバーは相互の証明書を信頼できる必要があります。
セキュリティー上の理由から、TLS または Start TLS のいずれかを使用することが推奨されます。AD は、接続が TLS で保護されない限り、パスワードの同期に TLS または Start TLS が必要です。 - Bind as... および Password フィールドに同期 ID 情報を入力します。このユーザーは AD に存在している必要があります。
- 同期合意を保存します。
winSyncInterval
属性を手動で編集することで変更できます。「コマンドラインでの同期合意の追加および編集」 を参照してください。
16.4.7.2. コマンドラインからの同期契約の作成
# ldapmodify -a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=replication_agreement_name,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: nsDSWindowsReplicationAgreement
cn: replication_agreement_name
nsds7WindowsReplicaSubtree: cn=Users,dc=ad1
nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com
nsds7NewWinUserSyncEnabled: on
nsds7NewWinGroupSyncEnabled: on
nsds7WindowsDomain: ad1
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaHost: ad1.windows-server.com
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=sync user,cn=config
nsDS5ReplicaCredentials: {DES}ffGad646dT0nnsT8nJOaMA==
nsDS5ReplicaTransportInfo: TLS
winSyncInterval: 1200
16.4.8. ステップ 8: 同期用の Directory Server ユーザーとグループエントリーの設定
16.4.9. ステップ 9: 同期の開始
コマンドラインでの同期の開始
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replication_agreement_name,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config changetype: modify replace: nsds5beginreplicarefresh nsds5beginreplicarefresh: start
nsds5BeginReplicaRefresh
属性を自動的に削除します。
コンソールを使用した同期の開始
- コンソールの Configuration タブに移動します。
- Replication フォルダーを開き、適切なデータベースを展開します。
- 同期合意を選択します。
- 合意を右クリックしたり、Object メニューを開きます。
16.5. ユーザーの同期
- Active Directory ドメインのユーザーは、Sync New Windows Users オプションを選択し、同期合意に設定すると同期されます。同期が開始すると、すべての Windows ユーザーが Directory Server にコピーされ、その後、新しいユーザーが作成されると、そのユーザーが同期されます。
- Directory Server のユーザーアカウントは、Directory Server エントリーにある特定の属性を使用して Active Directory と同期されます。Directory Server エントリーには、ntUser オブジェクトクラスと
ntUserCreateNewAccount
属性が必要です。ntUserCreateNewAccount
属性 (既存のエントリーでも) は、Active Directory サーバーにエントリーを書き込むように Directory Server Windows Synchronization プラグインに通知します。ntUser オブジェクトクラスが追加された新規または変更されたユーザーエントリーが作成され、エントリーの標準的なポーリングである次の定期更新時に Windows マシンに同期されます。
- ntUserDomainId.これは、Active Directory エントリーの
sAMAccountName
属性に対応します。 - ntUniqueId.これには、対応する Windows エントリーの
objectGUID
属性の値が含まれます。この属性は同期プロセスで設定され、手動で設定または変更しないでください。 - ntUserDeleteAccount.この属性は、Windows エントリーが同期され、Directory Server エントリーに対して手動で設定する必要がある場合に自動的に設定されます。
ntUserDeleteAccount
の値が true であれば、Directory Server エントリーが削除された場合に対応する Windows エントリーが削除されます。それ以外の場合、エントリーは Active Directory のままになりますが、Directory Server で削除されている場合は Directory Server データベースから削除されます。
ntUserCreateNewAccount
および ntUserDeleteAccount
を設定すると、Directory Manager では、同期されたサブツリー内のどのユーザーが Active Directory で同期されるかを正確に制御できます。
16.5.1. Directory Server と Active Directory との間で同期されるユーザー属性
Directory Server | Active Directory |
---|---|
cn[a] | name |
ntUserDomainId | sAMAccountName |
ntUserHomeDir | homeDirectory |
ntUserScriptPath | scriptPath |
ntUserLastLogon | lastLogon |
ntUserLastLogoff | lastLogoff |
ntUserAcctExpires | accountExpires |
ntUserCodePage | codePage |
ntUserLogonHours | logonHours |
ntUserMaxStorage | maxStorage |
ntUserProfile | profilePath |
ntUserParms | userParameters |
ntUserWorkstations | userWorkstations |
[a]
cn は、他の同期属性とは異なる方法で処理されます。Directory Server から Active Directory に同期する際に、直接 (cn から cn へ) マッピングされます。ただし、Active Directory から Directory Server に同期する場合、cn は Windows の name 属性から Directory Server の cn 属性にマッピングされます。
|
cn[a] | physicalDeliveryOfficeName |
description | postOfficeBox |
destinationIndicator | postalAddress |
facsimileTelephoneNumber | postalCode |
givenname | registeredAddress |
homePhone | sn |
homePostalAddress | st |
initials | street |
l | telephoneNumber |
teletexTerminalIdentifier | |
mobile | telexNumber |
o | title |
ou | usercertificate |
pager | x121Address |
[a]
cn は、他の同期属性とは異なる方法で処理されます。Directory Server から Active Directory に同期する際に、直接 (cn から cn へ) マッピングされます。ただし、Active Directory から Directory Server に同期する場合、cn は Windows の name 属性から Directory Server の cn 属性にマッピングされます。
|
16.5.2. Red Hat Directory Server と Active Directory との間のユーザースキーマの相違点
16.5.2.1. cn 属性の値
cn
属性に複数の値を指定できますが、Active Directory ではこの属性に単一の値しか持たせません。Directory Server の cn
属性が同期されると、単一の値のみが Active Directory ピアに送信されます。
cn
の値が Active Directory エントリーに追加され、その値が Directory Server の cn
の値のいずれでもない場合、Directory Server の cn
値がすべて単一の Active Directory 値で上書きされます。
cn
属性を命名属性として使用するのに対し、Directory Server では uid
を使用する点があります。つまり、cn
属性が Directory Server で編集されると、エントリーの名前が完全に (誤って) 変更される可能性があります。この cn
の変更が Active Directory エントリーに書き込まれると、エントリーの名前が変更になり、新しい名前付きエントリーが Directory Server に書き込まれます。
16.5.2.2. パスワードポリシー
16.5.2.3. street および streetAddress の値
streetAddress
属性を使用します。これは、Directory Server が street
属性を使用する方法です。Active Directory および Directory Server が streetAddress
属性および street
属性を使用する方法には 2 つの重要な相違点があります。
- Directory Server では、
streetAddress
はstreet
のエイリアスです。Active Directory にもstreet
属性がありますが、streetAddress
のエイリアスではなく、独立した値を保持することができる個別の属性です。 - Active Directory は
streetAddress
とstreet
を単一値の属性として定義しますが、Directory Server は RFC 4519 で指定されるようにstreet
を多値属性として定義します。
streetAddress
および street
属性を処理する方法が異なるため、Active Directory および Directory Server で address 属性を設定する際に従う 2 つのルールがあります。
- Windows 同期は、Windows エントリーの
streetAddress
を Directory Server のstreet
にマッピングします。競合を回避するために、street
属性は Active Directory では使用しないようにしてください。 - 1 つの Directory Server
street
属性値のみが Active Directory に同期されます。streetAddress
属性が Active Directory で変更され、新しい値が Directory Server に存在しない場合は、Directory Server のすべてのstreet
属性値が新しい Active Directory 値に置き換えられます。
16.5.2.4. initials 属性の制約
initials
属性では、Active Directory は最大長 6 文字の制限を課しますが、Directory Server には長さ制限がありません。6 文字を超える initials
属性が Directory Server に追加されると、その値は Active Directory エントリーと同期したときにトリミングされます。
16.5.3. Directory Server ユーザーのユーザー同期の設定
16.5.3.1. コンソールでのユーザー同期の設定
- Directory Server コンソールで、Directory タブを選択します。
- 既存のエントリーでエントリーを右クリックし、Properties をクリックしてエントリーのプロパティーエディターを開きます。新しいエントリーについては、左側のウィンドウのメインエントリーを右クリックして、新しいエントリーを追加し、User を選択して必要なエントリー属性を入力します。
- Property Editor の左側で、NT User リンクをクリックします。
- NT User タブで、NT 属性の有効化 チェックボックスを選択します。
- 同期を有効にするには、2 つのフィールドが必要です。
- NT ユーザー IDの設定
- 「Create New NT Account 」チェックボックスの選択
- Delete NT Account チェックボックスを選択すると、Directory Server エントリーが削除された場合に対応する Windows ユーザーが削除されることを意味します。
- 他の Windows 属性を設定します。これらの属性は、関連する Windows 属性にマッピングされます。追加の ntUser 属性は ボタンを使用して作成できます。「ディレクトリーエントリーの更新」 を参照してください。
16.5.3.2. コマンドラインでのユーザー同期の設定
- ntUser オブジェクトクラス。
- Windows ID を指定する
ntUserDomainId
属性 - 同期プラグインに Active Directory 経由で Directory Server エントリーを同期するように通知する
ntUserCreateNewAccount
属性
ldapmodify
ユーティリティーを使用します。
dn: uid=scarter,ou=People,dc=example,dc=com changetype: modify add: objectClass objectClass:ntUser - add: ntUserDomainId ntUserDomainId: Sam Carter - add: ntUserCreateNewAccount ntUserCreateNewAccount: true - add: ntUserDeleteAccount ntUserDeleteAccount: true
16.5.4. Active Directory ユーザーのユーザー同期の設定
16.5.4.1. コンソールでのユーザー同期の設定
- Configuration タブを開き、Replication フォルダーを展開します。
- 適切なデータベースを開き、同期合意を選択します。
- Connection タブを開きます。
- New Windows User Sync チェックボックスにチェックを入れて、ユーザーの同期を有効にします。同期を無効にするには、チェックボックスの選択を解除します。
16.5.4.2. コマンドラインでのユーザー同期の設定
nsds7NewWinUserSyncEnabled
で、同期合意に設定されます。ユーザーの同期を有効にするには、この属性を同期合意に追加するか、ldapmodify を使用して、この属性を on
に設定して同期合意を作成します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replication_agreement_name,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config changetype: modify replace: nsds7NewWinUserSyncEnabled nsds7NewWinUserSyncEnabled: on
nsds7NewWinUserSyncEnabled: off
を設定します。
16.6. グループの同期
- 同期合意で設定されている場合、Active Directory ドメインのグループは、新規 Windows グループの同期 オプションを選択すると同期されます。同期を開始すると、すべての Windows グループが Directory Server にコピーされ、新規グループは作成時に同期されます。
- Directory Server のグループアカウントは、Directory Server エントリーにある特定の属性を使用して Active Directory と同期します。Directory Server エントリーには、ntGroup オブジェクトクラスと
ntGroupCreateNewGroup
属性が必要です。ntGroupCreateNewGroup
属性 (既存のエントリーでも) は、Active Directory サーバーにエントリーを書き込むように Directory Server Windows Synchronization に通知します。ntGroup オブジェクトクラスを持つ新規または変更されたグループが作成され、次の通常の更新時に Windows マシンと同期されます。
- Active Directory では、Directory Server グループが作成/削除されるかどうかを制御する 2 つの属性 (
ntGroupCreateNewGroup
およびntGroupDeleteGroup
) を制御します。ntGroupCreateNewGroup
は、Active Directory に Directory Server グループを同期するために必要です。 - ntUserDomainId には、Active Directory ドメインのエントリーの一意の ID が含まれます。これは、ntGroup オブジェクトクラスの唯一の必須属性です。
- ntGroupType は Windows グループのタイプです。Windows のグループタイプには、global/security、domain local/security、builtin、universal/security、global/distribution、domain local/distribution、universal/distribution があります。この属性は、同期をとる Windows グループには自動的に設定されますが、Directory Server エントリーには、同期をとる前にこの属性を手動で設定する必要があります。
16.6.1. Windows グループタイプの概要
- グローバル/セキュリティーの場合 (デフォルト) は
-2147483646
- ドメインローカル/セキュリティーの場合は
-2147483644
- 組み込みの場合は
-2147483643
- 汎用/セキュリティーの場合は
-2147483640
- グローバル/ディストリビューションの場合は
2
- ドメインローカル/ディストリビューションの場合は
4
- ユニバーサル/ディストリビューションの場合は
8
16.6.2. Directory Server と Active Directory との間で同期されるグループ属性
Directory Server | Active Directory | ||
---|---|---|---|
cn | name | ||
ntUserDomainID | name | ||
ntGroupType | groupType | ||
| メンバー[a] | ||
cn | o |
description | ou |
l | seeAlso |
16.6.3. Red Hat Directory Server と Active Directory のグループスキーマの相違点
16.6.4. Directory Server グループのグループ同期の設定
16.6.4.1. コンソールでのグループ同期の設定
- Directory Server コンソールで、Directory タブを選択します。
- グループエントリーを右クリックし、Advanced をクリックして、エントリーの高度なプロパティーエディターを開きます。同期関連の属性はすべて手動で追加する必要があるため、高度なプロパティーエディターのみが属性を設定できます。
- objectclasses フィールド をクリックしてから、 ボタンをクリックします。
- ntGroup オブジェクトクラス を選択します。
- ntGroup オブジェクトクラス を設定すると、
ntUserDomainId
属性が自動的に追加されます。この属性は必須となるため、値を追加します。 - 同期を有効にするには、ボタンをクリックし、一覧から
ntGroupCreateNewGroup
属性を選択します。次に、その値を true に設定します。これは、エントリーを Active Directory ディレクトリーに追加する必要がある同期プラグインに信号を送ります。Directory Server データベースからグループエントリーが削除された場合に Active Directory ドメインからグループエントリーを削除するには、ntGroupDeleteGroup
属性を設定して true に設定します。 - Directory Server エントリーの他の Windows 属性を追加します。利用可能な属性は、「Directory Server と Active Directory との間で同期されるグループ属性」 に記載されています。
ntGroupType
が追加されない場合は、グループはグローバルセキュリティーグループ(ntGroupType:-2147483646)として自動的に追加されます。
16.6.4.2. コマンドラインでのグループ同期の設定
- ntGroup オブジェクトクラス。
- エントリーの Windows ID を与える
ntUserDomainId
属性。 ntGroupCreateNewGroup
属性は、同期プラグインに Active Directory 経由で Directory Server エントリーを同期するように通知します。ntGroupDeleteGroup
属性は任意ですが、Directory Server で削除される場合に、自動的に Active Directory ドメインからエントリーを削除するかどうかを設定します。
ntGroupType
属性を追加することも推奨されます。この属性が指定されていない場合、グループはグローバルセキュリティーグループ (ntGroupType:-2147483646) として自動的に追加されます。
ldapmodify
を使用するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Example Group,ou=Groups,dc=example,dc=com changetype: modify add: objectClass objectClass:ntGroup - add: ntUserDomainId ntUserDomainId: example-group - add: ntGroupCreateNewGroup ntGroupCreateNewGroup: true - add: ntGroupDeleteGroup ntGroupDeleteGroup: true - add: ntGroupType ntGroupType: 2
16.6.5. Active Directory グループのグループ同期の設定
16.6.5.1. コンソールでのグループ同期の設定
- Configuration タブを開き、Replication フォルダーを展開します。
- 適切なデータベースを開き、同期合意を選択します。
- Connection タブを開きます。
- 新規 Windows Group Sync チェックボックスを選択して、グループ同期を有効にします。同期を無効にするには、チェックボックスの選択を解除します。
16.6.5.2. コマンドラインでのグループ同期の設定
nsds7NewWinGroupSyncEnabled
で、同期合意に設定されます。グループ同期を有効にするには、この属性を同期合意に追加するか、この属性が on に設定された同期合意を作成します。ldapmodify
の使用:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replication_agreement_name,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config changetype: modify replace: nsds7NewWinGroupSyncEnabled nsds7NewWinGroupSyncEnabled: on
16.7. 一方向の同期の設定
oneWaySync
は、一方向の同期を有効にし、変更を送信する方向を指定します。使用できる値は fromWindows
(Active Directory から Directory Server への同期の場合) および toWindows
(Directory Server から Active Directory の同期の場合) です。この属性がない場合、同期は双方向になります。
図16.6 一方向の同期
- 「ステップ 7: 同期合意の作成」 にあるように、同期合意を作成します。
- Directory Server コンソールには、合意の初回作成時に一方向同期を設定するオプションはありません。同期合意を編集して、
oneWaySync
属性を追加します。ldapmodify
の使用:# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replication_agreement_name,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config changetype: modify add: oneWaySync oneWaySync: fromWindows
oneWaySync
が toWindows
に設定されている場合でも、Active Directory サーバーでパスワードを更新した後に、パスワードは Directory Server に送信されます。
16.8. Windows 同期での複数のサブツリーおよびフィルターの設定
Windows 同期における複数のサブツリー
winSyncSubtreePair
パラメーターに Directory Server サブツリーと Active Directory サブツリーを設定します。ldapmodify
を使用して、以下のように複数のサブツリーを設定します。
changetype: modify add: winSyncSubtreePair winSyncSubtreePair: ou=OU1,dc=DSexample,dc=com:ou=OU1,DC=ADexample,DC=com
winSyncSubtreePair
が設定されていない場合は、代わりに nsds7WindowsReplicaSubtree
AD サブツリーパラメーターと nsds7DirectoryReplicaSubtree
DS サブツリーパラメーターが同期ターゲットチェックに使用されます。それ以外の場合は、この 2 つのパラメーターは無視されます。
Windows 同期のフィルター
winSyncWindowsFilter
は、Active Directory サーバーに追加のフィルターを設定します。winSyncDirectoryFilter
パラメーターは、Directory Server に追加のフィルターを設定します。
ユーザーまたはグループ
が含まれるエントリーを同期するために使用されます。
changetype: modify add: winSyncWindowsFilter winSyncWindowsFilter: (|(cn=*user*)(cn=*group*)) - add: winSyncDirectoryFilter winSyncDirectoryFilter: (|(uid=*user*)(cn=*group*))
16.9. ユーザーとグループの POSIX 属性の同期
ntUser
属性および ntGroup
属性が自動的に追加されますが、POSIX 属性は同期されず (Active Directory エントリーに存在していても)、Directory Server 側でも POSIX 属性は追加されません。
uidNumber
、gidNumber
、および homeDirectory
) は、Active Directory エントリーと Directory Server エントリー間で同期されます。ただし、新しい POSIX エントリーまたは POSIX 属性が Directory Server の既存のエントリーに追加されると、POSIX 属性のみが Active Directory に対応するエントリーと同期します。POSIX オブジェクトクラス (ユーザーの場合は posixAccount、グループの場合は posixGroup) は Active Directory エントリーに追加されません。
16.9.1. POSIX 属性同期の有効化
nsslapd-pluginEnabled
属性を on に設定します。ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Posix Winsync API,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
注記Posix 同期プラグインが最初に読み込まれるように、優先順位は 50 未満である必要があります。デフォルトの設定では、優先順位は 25 であり、この値はほとんどのデプロイメントで同じままになる可能性があります。- Directory Server を再起動して、新しい構成を読み込みます。
16.9.2. Posix グループ属性の同期設定の変更
- ldapmodify を使用して、属性を適切な設定に変更します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Posix Winsync API,cn=plugins,cn=config changetype: modify replace: posixWinsyncMapNestedGrouping posixWinsyncMapNestedGrouping: true
- Directory Server を再起動して、新しい構成を読み込みます。
16.10. エントリーの削除および復元
16.10.1. エントリーの削除
ntUserDeleteAccount
属性または ntGroupDeleteGroup
属性が true に設定されている場合のみ、Active Directory の対応するエントリーが削除されます。
ntUniqueId
属性として保存されます。一意の ID が Directory Server に同期する 前 に Active Directory で Directory Server エントリーを削除すると、このエントリーは Directory Server で削除 されません。Directory Server は ntUniqueId
属性を使用して、Active Directory に追加された変更を対応する Directory Server エントリーに識別し、同期します。その属性がないと、Directory Server は削除を認識しません。
ntUniqueId
属性が削除される前に、エントリーの作成後に winSyncInterval
の長さ (デフォルトでは 5 分) 待ちます。
16.10.2. エントリーのレスキュー
ntUniqueId
属性が含まれます。これは、この新規エントリーが tombstone エントリーである Active Directory サーバーに通知されます。
16.11. 同期更新の送信
winSyncInterval
(Active Directory ドメインから変更内容を取得する場合) またはnsds5replicaupdateschedule
設定 (Directory Server から変更内容をプッシュする場合) で設定された頻度で行われます。デフォルトでは、変更は 5 分ごとに Active Directory から取得され、Directory Server からの変更がすぐに送信されます。
16.11.1. 手動増分同期の実行
- コンソールの Configuration タブに移動します。
- Replication フォルダーを開き、適切なデータベースを展開します。
- 同期合意を選択します。
- 合意を右クリックしたり、Object メニューを開きます。
- ドロップダウンメニューから Send and Receive Updates を選択します。
16.11.2. 完全同期の実行
16.11.2.1. コンソールを使用した完全同期の実行
- コンソールの Configuration タブに移動します。
- Replication フォルダーを開き、適切なデータベースを展開します。
- 同期合意を選択します。
- 合意を右クリックしたり、Object メニューを開きます。
- ドロップダウンメニューから Initialize Full Re-synchronization を選択します。Resynchronizing は、同期ピアのデータを削除しません。すべての更新を送受信して、新規または変更した Directory Server エントリーを追加します。たとえば、ntUser オブジェクトクラスが追加された既存の Directory Server ユーザーを追加します。
16.11.2.2. コマンドラインを使用した完全同期の実行
nsDS5BeginReplicaRefresh
属性を同期合意に追加します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replication_agreement_name,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config changetype: modify add: nsDS5BeginReplicaRefresh nsDS5BeginReplicaRefresh: start
nsDS5BeginReplicaRefresh
属性を自動的に削除します。
16.11.3. 同期ステータスの確認
- コンソールの Configuration タブに移動します。
- Replication フォルダーを開き、適切なデータベースを展開します。
- 同期合意を選択します。
- Summary タブで、最新の同期プロセスのステータスが下部に表示されます。
16.12. 同期合意の変更
16.12.1. コンソールでの同期合意の編集
- Configuration タブで、Replication フォルダーを展開します。
- 同期されるデータベースを展開します。同期合意はすべて、データベースの下に一覧表示されます。同期合意をダブルクリックして、メインウィンドウで開きます。
図16.7 同期合意の選択
- Connection タブをクリックします。
図16.8 Connection タブ
編集できる情報の 3 つの項目があります。- 接続タイプ(標準、TLS、および Start TLS)
- バインドユーザー(DN およびパスワードの両方)。
- 新しい Directory Server ユーザーおよび新しい Directory Server グループを自動的に同期するかどうか。
接続タイプには、standard、TLS、および Start TLS の 3 つのオプションがありますが、実際には LDAP および LDAPS の接続プロトコルが 2 つしかありません。標準接続と Start TLS 接続はいずれも LDAP を使用します(Start TLS は、非セキュアなポートでセキュアな接続を作成します)。接続プロトコルは 、 Windows 同期ピアへの接続に使用するポート番号を変更することができないため、接続プロトコルを変更できません。標準接続と Start TLS の間で接続タイプを変更できますが、TLS から標準または Start TLS 接続のいずれかに変更することはできません。同様に、標準または Start TLS から TLS に移動することはできません。接続プロトコルまたはポート番号を変更する必要がある場合は、同期合意を削除し、新しいアカウントを作成します。
16.12.2. コマンドラインでの同期合意の追加および編集
16.12.2.1. Basic 同期合意の作成
- Directory Server データベースの場合:
- ディレクトリーの同期されたサブツリー(
nsds7DirectoryReplicaSubtree
) - Directory Server のルート DN(
nsDS5ReplicaRoot
)
- Active Directory ドメインの場合:
- Active Directory ドメインで同期されたサブツリー(
nsds7WindowsReplicaSubtree
) - Active Directory ドメイン名(
nsds7WindowsDomain
)
- Active Directory ホスト名、IPv4 アドレス、または IPv6 アドレス(
nsDS5ReplicaHost
) - Active Directory ポート(
nsDS5ReplicaPort
) - 標準(LDAP)、TLS(SSL)、またはStartTLS(TLS)の接続の種類(標準ポートを介したセキュアな接続)です。
nsDS5ReplicaTransportInfo
- Active Directory サーバーにバインドする Directory Server のユーザー名(
nsDS5ReplicaBindDN
)およびパスワード(nsDS5ReplicaCredentials
)。
ldapmodify
を使用するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replication_agreement_name,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config changetype: add objectclass: top objectclass: nsDSWindowsReplicationAgreement cn: replication_agreement_name nsds7WindowsReplicaSubtree: cn=Users,dc=ad1 nsds7DirectoryReplicaSubtree: ou=People,dc=example,dc=com nsds7WindowsDomain: ad1 nsDS5ReplicaRoot: dc=example,dc=com nsDS5ReplicaHost: ad1.windows-server.com nsDS5ReplicaPort: 389 nsDS5ReplicaBindDN: cn=sync user,cn=Users,dc=ad1 nsDS5ReplicaCredentials: {DES}ffGad646dT0nnsT8nJOaMA== nsDS5ReplicaTransportInfo: TLS nsds7NewWinUserSyncEnabled: on nsds7NewWinGroupSyncEnabled: on
16.12.2.2. 同期スケジュールの設定
nsds5replicaupdateschedule
属性を使用して、レプリケーションと同様に設定可能なスケジュールの Active Directory に更新を適用します。Directory Server は Active Directory をポーリングして変更の有無 (Active Directory サーバーが winSyncInterval
属性に設定されている頻度) を確認します。
nsds5replicaupdateschedule
属性を編集します。スケジュールは、24 時間クロックを使用して HHMM 形式の開始 (SSSS) および終了 (EEEE) 時間で設定されます。同期の更新スケジュールを設定する日は、0 (日曜日) から 6 (土曜日) までです。
nsds5replicaupdateschedule: SSSS EEEE DDDDDDD
nsds5replicaupdateschedule: 1200 1400 0246
winSyncInterval
属性をリセットします。この属性は秒単位で設定されるため、デフォルトの 300 は、Directory Server が Active Directory サーバーを 300 秒または 5 分間隔でポーリングすることを意味します。これを高い値に設定すると、ディレクトリーの検索に時間がかかり、パフォーマンスに影響する場合に便利です。
winSyncInterval: 1000
16.12.2.3. 同期接続の変更
- バインドユーザー名およびパスワード (
nsDS5ReplicaBindDN
およびnsDS5ReplicaCredentials
) - 接続メソッド (
nsDS5ReplicaTransportInfo
)nsDS5ReplicaTransportInfo
を LDAP から TLS に変更すること しかできません。SSL への変更、または SSL からの変更はポート番号を変更することができないため、LDAP と LDAPS の切り替えにはポート番号の変更が必要となります。
nsDS5ReplicaBindDN: cn=sync user,cn=Users,dc=ad1 nsDS5ReplicaCredentials: {DES}ffGad646dT0nnsT8nJOaMA== nsDS5ReplicaTransportInfo: TLS
16.12.2.4. 同期しているサブツリーから移動するエントリーの処理
samAccount
と Directory Server の uid
属性に基づいて相関します。同期プラグインは、(samAccount/uid
関係に基づいて) エントリーが削除または移動されたために、同期されたサブツリーから削除された場合、その旨を通知します。これは、同期プラグインに対して、そのエントリーがもう同期されないことを示す信号です。
samAccount
ID が jsmith のユーザーは、Active Directory の ou=Employees サブツリーに作成されています。同期されたサブツリーは ou=Users であるため、jsmith ユーザーは Directory Server に同期されませんでした。
図16.9 Active Directory ツリー
samAccount/uid
関係) に対応し、同期サブツリーの外にあるエントリーを、意図的に 同期サブツリーの外に移動させることを前提としています (基本的には名前の変更操作)。「対応する」Directory Server エントリーを削除する必要があることを前提とします。
図16.10 Active Directory と Directory Server ツリーの比較
winSyncMoveAction
属性は、これらの移動したエントリーの処理方法を設定します。
- none は何もしないため、同期した Directory Server エントリーが存在する場合は、同期するか、スコープ 内 に Active Directory エントリーを作成したりできます。同期された Directory Server エントリーが存在しない場合は、何も起こりません (Directory Serverバージョン 9.1 以降では、これがデフォルトの動作です)。
- unsync は、Directory Server エントリーから同期関連の属性 (
ntUser
またはntGroup
) を削除しますが、Directory Server エントリーはそのまま残されます。重要エントリーの同期を解除すると、Active Directory のエントリーが後から削除され、Directory Server のエントリーがそのまま残ってしまう危険性があります。これにより、特に Active Directory 側でエントリーを再作成するのに Directory Server エントリーを使用する場合などに、データが不整合になる可能性があります。 - delete は、Active Directory と同期していたかどうかに関わらず、Directory Server で該当するエントリーを削除します (これは 9.0 のデフォルト動作です)。重要対応する Active Directory エントリーを削除せずに Directory Server エントリーを削除することはありません。このオプションは、Directory Server 9.0 システムとの互換性でのみ利用できます。
winSyncMoveAction
属性を追加します。ldapmodify
の使用:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=replication_agreement_name,cn=replica,cn="dc=example,dc=com",cn=mapping tree,cn=config changetype: modify add: winSyncMoveAction winSyncMoveAction: unsync
16.13. パスワード同期サービスの管理
16.13.1. パスワード同期の変更
- コントロールパネル を開き、プログラムと機能 を選択します。
- Red Hat Directory Password Sync エントリーを選択し、 ボタンをクリックしてインストーラーを再起動して設定を変更します。
- 設定画面に戻り、設定を変更します。
16.13.2. パスワード同期サービスの起動と停止
- Services アプリケーションを開きます。
- Password Synchronization サービスをダブルクリックします。
- Services アプリケーションを開きます。
- Password Synchronization サービスを右クリックします。
16.13.3. パスワード同期サービスの アンインストール
- コントロールパネル を開き、プログラムと機能 を選択します。
- Red Hat Directory Password Sync エントリーを選択し、 ボタンをクリックします。
- Password Sync に対して TLS が設定されている場合、パスワード同期
のアンインストール時に作成された cert8.db
データベースおよび key3.db
データベースは削除されません でした。これらのファイルは手動で削除します。
16.13.4. パスワード同期のアップグレード
16.14. トラブルシューティング
レプリケーションロギングを有効にして同期エラーを記録する
レプリケーションロギングを有効にすると、同期に関するより詳細な情報がエラーログに記録されます。レプリケーションログレベルは、同期コードからより詳細なログを生成します。同期トラフィックに関連するメッセージ (レプリケーショントラフィックと同じ) は、問題を診断するのに役立ちます。
- コンソールで、Configuration タブをクリックします。
- 右側のナビゲーションメニューから Logs を選択し、エラーログを開きます。
- エラーログレベルまでスクロールダウンし、メニューから Replication を選択します。
- 保存します。
Error #1: 同期合意の作成時にメッセージのボックスは、Active Directory に接続できないことを示しています。
ディレクトリーのサフィックス、Windows ドメインおよびドメインホスト、および管理者 DN およびパスワードが正しいことを確認します。LDAPS に使用されるポート番号が正しいことを確認します。すべての接続情報が正しい場合は、Active Directory マシンが実行中であることを確認してください。
エラー #2: 同期後、ステータスは error 81 を返します。
同期ピアサーバーの 1 つは TLS 通信に対して適切に設定されていません。Directory Server のアクセスログファイルを調べ、Directory Server が接続試行を受け取っているかどうかを確認します。Directory Server のエラーログファイルには有用なメッセージがあります。
エラー #3: エントリーは Active Directory のサブツリーから別のサブツリーに移動していますが、ユーザーは Directory Server の対応するサブツリーに移動していません。
これは、Active Directory の modrdn 操作と Directory Server のエントリーとの同期に関する既知の問題です。これを回避するには、Active Directory のエントリーを削除して、新しいサブツリーに追加します。削除と追加は、Directory Server ピアに対して適切に同期されます。
第17章 コンテンツの同期の設定
Content Synchronization
プラグインを使用すると、Directory Server は RFC 4533 に従って SyncRepl
プロトコルをサポートします。このプロトコルにより、LDAP サーバーとクライアントは Red Hat Directory Server をソースとして使用し、ローカルデータベースを Directory Server の変更するコンテンツと同期させることができます。
SyncRepl
プロトコルを使用するには、以下を実行します。
- Directory Server で
Content Synchronization
プラグインを有効にし、必要に応じてクライアントが Directory Server にバインドするために使用する新規ユーザーを作成します。アカウントには、ディレクトリー内のコンテンツを読み取るパーミッションが必要です。 - クライアントを設定します。たとえば、同期するサブツリーの検索ベースを設定します。詳細は、クライアントのドキュメントを参照してください。
Content Synchronization
プラグインを設定します。
Content Synchronization
プラグインでは、nsuniqueid
属性をログに記録するのにRetro Changelog
プラグインが必要です。- Retro Changelog が有効になっているかどうかを確認するには、次のコマンドを実行します。
# ldapsearch -D "cn=Directory Manager" -W -x -b \ 'cn=Retro Changelog Plugin,cn=plugins,cn=config' nsslapd-pluginEnabled ... dn: cn=Retro Changelog Plugin,cn=plugins,cn=config nsslapd-pluginEnabled: off
nsslapd-pluginEnabled
属性が off に設定されている場合、Retro Changelog は無効になります。有効にする場合は、「Retro Changelog プラグインの有効化」 を参照してください。 nsuniqueid
属性を、Retro Changelog プラグインの設定に追加します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Retro Changelog Plugin,cn=plugins,cn=config changetype: add add: nsslapd-attribute nsslapd-attribute: nsuniqueid:targetUniqueId
- 必要に応じて、パフォーマンスを向上させるために、以下の推奨事項を適用します。
- Retro Changelog のエントリーの最大有効期間を設定します。たとえば、2 日 (2d) を設定するには、以下のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=changelog5,cn=config changetype: modify replace: nsslapd-changelogmaxage nsslapd-changelogmaxage: 2d
- データを同期するバックエンドまたはサブツリーのクライアントアクセスを把握している場合は、
Retro Changelog
プラグインのスコープを制限します。たとえば、cn=demo,dc=example,dc=com
サブツリーを除外するには、以下を入力します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Retro Changelog Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-exclude-suffix nsslapd-exclude-suffix: cn=demo,dc=example,dc=com
Content Synchronization
プラグインを有効にします。- コマンドラインの使用するには、以下を行います。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Retro Changelog Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
- Directory Server コンソールの使用: 「Directory Server コンソールでプラグインの有効化」 を参照してください。
- デフォルトの Directory Server は、
oid=1.3.6.1.4.1.4203.1.9.1.1,cn=features,cn=config
エントリーにアクセス制御命令 (ACI) を作成し、すべてのユーザーがSyncRepl
プロトコルを使用できるようにします。aci: (targetattr != "aci")(version 3.0; acl "Sync Request Control"; allow( read, search ) userdn = "ldap:///all";)
必要に応じて、SyncRepl
コントロールを使用して ACI を制限するように更新します。ACI の詳細は、「バインドルールの定義」を参照してください。 - Directory Server を再起動します。
# systemctl restart dirsrv@instance_name
SyncRepl
プロトコルを使用して、Directory Server とデータを同期できるようになりました。
第18章 アクセス制御の管理
18.1. アクセス制御要件
- ディレクトリー全体、サブツリー、または特定のエントリーの場合
- 特定のユーザー、特定のユーザーまたはグループに属するすべてのユーザー、またはディレクトリー内のすべてのユーザーの場合
- IP アドレス、IP 範囲、または DNS 名などの特定の場所。ロードバランサーは場所固有のルールに影響を及ぼす可能性があることに注意してください。
18.2. ACI 配置
aci
操作属性に ACI を保存します。ACI を設定するには、aci
を対応するディレクトリーエントリーに追加します。Directory Server は ACI を適用します。
- ACI を含むエントリー (子エントリーがない場合) にのみ適用されます。たとえば、クライアントが uid=user_name,ou=People,dc=example,dc=com オブジェクトへのアクセスを必要とし、ACI が dc=example,dc=com にのみ設定されており、子エントリーには設定されていない場合は、この ACI のみが適用されます。
- ACI を含むエントリーと、(子エントリーがある場合は) その下のすべてのエントリーへ。これにより、サーバーが指定のエントリーに対するアクセスパーミッションを評価すると、リクエストされたディレクトリー接尾辞と、エントリー自体の ACI との間のすべてのエントリーについて ACI を検証します。たとえば、ACI は dc=example,dc=com および ou=People,dc=example,dc=com エントリーに設定されます。ACI が設定されていない uid=user_name,ou=People,dc=example,dc=com オブジェクトにクライアントがアクセスする場合、Directory Server はまず dc=example,dc=com エントリー上の ACI を検証します。この ACI がアクセスを許可する場合、Directory Server は ou=People,dc=example,dc=com 上の ACI を検証します。この ACI がクライアントを正常に承認すると、オブジェクトにアクセスできます。
organizationalUnit
エントリーまたは locality
エントリーのレベルで作成できます。
18.3. ACI 構造
aci
属性は以下の構文を使用します。
(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)
target_rule
は、アクセスを制御するためのエントリー、属性、またはエントリーと属性のセットを指定します。詳細は、「ターゲットの定義」を参照してください。version 3.0
は、ACI バージョンを識別する必須の文字列です。bind_rules
は、アクセスを許可または拒否するために、バインド時に一致するルールを指定します。詳細は、「バインドルールの定義」を参照してください。
(target_rule)(version 3.0; acl "ACL_name"; permission_rule bind_rules; permission_rule bind_rules; ... ;)
18.4. ACI 評価
18.5. ACI の制限
- ディレクトリーデータベースが複数のサーバーに分散されている場合は、ACI で使用できるキーワードに以下の制限が適用されます。
- groupdn キーワードを使用したグループエントリーに依存する ACI は、グループエントリーと同じサーバーに置く必要があります。グループが動的の場合、グループのすべてのメンバーに、サーバーのエントリーが必要です。静的グループのメンバーエントリーは、リモートサーバーに配置できます。
- roledn キーワードを使用したロール定義に依存する ACI は、ロール定義エントリーと同じサーバーにある必要があります。ロールを持つすべてのエントリーは、同じサーバーに配置する必要があります。
ただし、ターゲットエントリーに保存されている値を、たとえば userattr キーワードを使用して、bind ユーザーのエントリーに保存されている値と一致させることができます。この場合、通常、バインドユーザーに ACI を格納するサーバーにエントリーがない場合でも、アクセスが評価されます。詳細は、「データベースリンクおよびアクセス制御評価」を参照してください。 - 以下の ACI キーワードでは、Class of Service (CoS) 属性などの仮想属性を使用することはできません。
- targetfilter
- targattrfilters
- userattr
詳細は、「8章エントリーの編成とグループ化」を参照してください。 - アクセス制御ルールは、ローカルサーバーでのみ評価されます。たとえば、ACI キーワードの LDAP URL にサーバーのホスト名を指定すると、URL は無視されます。
18.6. Directory Server がレプリケーショントポロジーで ACI を処理する方法
aci
属性に保存します。したがって、ACI を含むエントリーが複製されたデータベースの一部である場合、ACI は複製されます。
18.7. ACI の表示
18.7.1. コマンドラインを使用した ACI の表示
ldapsearch
ユーティリティーを使用して、コマンドラインを使用して ACI を表示します。たとえば、dc=example,dc=com およびサブエントリーに設定された ACI を表示するには、以下のコマンドを実行します。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x \ -b "dc=example,dc=com" -s sub '(aci=*)' aci
18.7.2. コンソールを使用した ACI の表示
- Directory Server コンソールを開きます。
- Directory タブで、エントリーを右クリックし、Set Access Permissionsを選択します。
- オプションで、Show Inherited ACI を選択して、ディレクトリーの上位レベルのエントリーをさらに表示します。
18.8. ACI の追加
18.8.1. コマンドラインを使用した ACI の追加
ldapmodify
ユーティリティーを使用して ACI を追加します。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr="userPassword") (version 3.0; acl "Allow users updating their password"; allow (write) userdn= "ldap:///self";)
18.8.2. コンソールを使用した ACI の追加
- Directory Server コンソールを開きます。
- Directory タブで、エントリーを右クリックし、Set Access Permissionsを選択します。
- ACI Name フィールドに ACI の名前を入力します。
- Users タブで、 ボタンをクリックしてユーザー、グループ、ロール、管理者、または特別な権限を一覧に追加します。
- Search for フィールドに文字列を入力し、検索エリアを選択して をクリックします。
- 検索結果からエントリーを選択し、をクリックします。
- Rights タブで、この ACI に設定するパーミッションを選択します。
- Targets タブで、ターゲットディレクトリーエントリーを選択します。注記ターゲット DN の値を変更できますが、新しい DN は選択したエントリーの直接または間接子である必要があります。ACI がこのノード下のサブツリーのすべてのエントリーをターゲットにするには、Filter for Sub-entries フィールドにフィルターを入力します。フィルターは、ターゲットエントリー下のすべてのエントリーに適用されます。たとえば、フィルターを ou=Sales に設定すると、DN に ou=Sales を持つエントリーのみが返されます。さらに、リスト内の属性を選択して、ACI の範囲を特定の属性に制限することもできます。
- ホスト タブで、オプションで DNS 名または IP アドレスを追加します。DNS 名または IP アドレスを設定する場合、ACI はこれらのホストからの LDAP 操作にのみ適用されます。
- Times タブで、ACI を適用する時間をオプションから選択します。デフォルトでは、アクセスはいつでも許可されます。カーソルをテーブル上でクリックしてドラッグして、アクセス時間を変更します。継続的な時間範囲のみを選択できることに注意してください。
18.9. ACI の削除
18.9.1. コマンドラインを使用した ACI の削除
- エントリーに設定された ACI を表示します。「コマンドラインを使用した ACI の表示」 を参照してください。
- ACI を削除します。
- 1 つの
aci
属性がエントリーに設定されているか、またはエントリーからすべての ACI を削除する場合は、以下を実行します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: delete delete: aci
- 複数の ACI がエントリーに存在し、特定の ACI を削除する場合は、実際の ACI を指定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify delete: aci aci: (targetattr="userPassword") (version 3.0; acl "Allow users updating their password"; allow (write) userdn= "ldap:///self";)
18.9.2. コンソールを使用した ACI の削除
- Directory Server コンソールを開きます。
- Directory タブで、エントリーを右クリックし、Set Access Permissionsを選択します。
- 一覧から ACI を選択し、をクリックします。
18.10. ACI の更新
18.10.1. コマンドラインを使用した ACI の更新
- 既存の ACI を削除します。「コマンドラインを使用した ACI の削除」 を参照してください。
- 更新された設定で新しい ACI を追加します。「コマンドラインを使用した ACI の追加」 を参照してください。
18.10.2. コンソールを使用した ACI の更新
- Directory Server コンソールを開きます。
- Directory タブで、エントリーを右クリックし、Set Access Permissionsを選択します。
- 一覧から ACI を選択し、をクリックします。
- ACI を更新します。個別の画面については、「コンソールを使用した ACI の追加」 セクションで説明されています。
18.11. ターゲットの定義
aci
属性が含まれるエントリーと以下のエントリーに適用されます。
(target_rule)(version 3.0; acl "ACL_name"; permission_rule bind_rules;)
(target_rule_1)(target_rule_2)(...)(version 3.0; acl "ACL_name"; permission_rule bind_rules;)
- target
- targetattr
- targetattrfilters
- targetfilter
- target_from
- target_to
構文
(keyword comparison_operator "expression")
- keyword: ターゲットの種類を設定します。「よく使用されるターゲットキーワード」を参照してください。
- comparisonoperator: 有効な値は = および != で、ターゲットが式で指定されたオブジェクトであるかを示します。警告セキュリティー上の理由から、Red Hat は、他のすべてのエントリーまたは属性で指定の操作を許可するため、!= 演算子を使用しないことを推奨します。以下に例を示します。
(targetattr != "userPassword");(version 3.0; acl "example"); allow (write) ... );
前の例では、ACI を設定する識別名 (DN) の下にあるuserPassword
属性以外の属性の設定、更新、または削除を行うことができます。ただし、これにより、ユーザーはこの属性への書き込みアクセスを許可するaci
属性を追加することもできます。 - expression: ターゲットを設定し、引用符で囲む必要があります。式自体は使用するキーワードによって異なります。
18.11.1. よく使用されるターゲットキーワード
- target: 「ディレクトリーエントリーのターゲット」を参照してください。
- targetattr: 「ターゲット属性」を参照してください。
- targetfilter: 「LDAP フィルターを使用したエントリーと属性の対象」を参照してください。
- targattrfilters: 「LDAP フィルターを使用した属性値のターゲット」を参照してください。
18.11.1.1. ディレクトリーエントリーのターゲット
(target comparison_operator "ldap:///distinguished_name")
例18.1 target キーワードの使用
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=People,dc=example,dc=com changetype: modify add: aci aci: (target = "ldap:///ou=People,dc=example,dc=com") (version 3.0; acl "Allow users to read and search attributes of own entry"; allow (search, read) (userdn = "ldap:///self");)
target キーワードでのワイルドカードの使用
uid
属性が文字 a で始まる値に設定される ou=People,dc=example,dc=com のすべてのエントリーと一致します。
(target = "ldap:///uid=a*,ou=People,dc=example,dc=com")
例18.2 ワイルドカードを使用したディレクトリーエントリーのターゲット
uid
属性が一致するもので、dc=example,dc=com エントリー自体に格納されているエントリーだけではありません。
(target = "ldap:///uid=user_name*,dc=example,dc=com")
- uid=user_name,dc=example,dc=com
- uid=user_name,ou=People,dc=example,dc=com
- uid=user_name2,dc=example,dc=com
18.11.1.2. ターゲット属性
- 読み取り操作では、どの属性がクライアントに返されるか
- 検索操作では、どのような属性が検索されるのか
- 書き込み操作では、どの属性がオブジェクトに書き込むことができるか
- add 操作では、新規オブジェクトの作成時に追加できる属性
(targetattr comparison_operator "attribute_1 || attribute_2 || ...")
例18.3 targetattr キーワードの使用
userPassword
属性を更新するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr = "userPassword") (version 3.0; acl "Allow users updating own userPassword"; allow (write) (userdn = "ldap:///self");)
targetattr キーワードでのワイルドカードの使用
(targetattr = "*")
18.11.1.3. LDAP フィルターを使用したエントリーと属性の対象
(targetfilter comparison_operator "LDAP_filter")
例18.4 targetfilter キーワードの使用
department
属性が Engineering または Sales に設定されているすべてのエントリーを変更するために、cn=Human Resources,dc=example,dc.com グループのメンバーにパーミッションを付与するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (targetfilter = "(|(department=Engineering)(department=Sales)") (version 3.0; acl "Allow HR updating engineering and sales entries"; allow (write) (groupdn = "ldap:///cn=Human Resources,dc=example,dc.com");)
targetfilter キーワードでのワイルドカードの使用
uid
属性をターゲットにするには、次のコマンドを実行します。
(targetattr = "(uid=adm*) ...)
18.11.1.4. LDAP フィルターを使用した属性値のターゲット
- 1 つの属性とフィルターの組み合わせが含まれる操作の場合:
(targattrfilters="operation=attribute:filter")
- 複数の属性とフィルターの組み合わせのある操作の場合:
(targattrfilters="operation=attribute_1:filter_1 && attribute_2:filter_2 ... && attribute_m:filter_m")
- 複数の属性とフィルターを組み合わせた 2 つの操作の場合。
(targattrfilters="operation_1=attribute_1_1:filter_1_1 && attribute_1_2:filter_1_2 ... && attribute_1_m:filter_1_m , operation_2=attribute_2_1:filter_2_1 && attribute_2_2:filter_2_2 ... & attribute_2_n:filter_2_n ")
- エントリーを作成する際に、新しいエントリーの属性にフィルターが適用されると、その属性の各インスタンスがフィルターに一致する必要があります。
- エントリーとフィルターを削除するとエントリーの属性に適用される場合、その属性の各インスタンスはフィルターと一致する必要があります。
- エントリーを変更し、操作が属性を追加する場合は、その属性に適用される add フィルターが一致している必要があります。
- 操作が属性を削除すると、その属性に適用される del フィルターが一致している必要があります。エントリーに属性の個別の値が置き換えられる場合は、add および del フィルターの両方が一致する必要があります。
例18.5 targattrfilters キーワードの使用
telephone
属性を追加するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (targattrfilters="add=nsroledn:(!(nsroledn=cn=Admin)) && telephoneNumber:(telephoneNumber=123*)") (version 3.0; acl "Allow adding roles and telephone"; allow (add) (userdn = "ldap:///self");)
18.11.2. 詳細なターゲットキーキーワード
18.11.2.1. ソースおよび宛先 DN のターゲット
- ACI に設定される別のソースからエントリーを移動します。
- エントリーを ACI のセットとして別の宛先に移動するには、以下のコマンドを実行します。
- ソース DN から既存のエントリーを削除するには、以下を実行します。
- 宛先 DN に新規エントリーを追加するには、以下を行います。
例18.6 target_from および target_to キーワードの使用
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (target_from="ldap:///uid=*,cn=staging,dc=example,dc=com") (target_to="ldap:///cn=People,dc=example,dc=com") (version 3.0; acl "MODDN from"; allow (moddn)) userdn="ldap:///uid=user,dc=example,dc=com";)
18.11.3. ターゲットルールの高度な使用方法
18.11.3.1. グループの作成およびメンテナンスへのパーミッションの委譲
例18.7 グループの作成およびメンテナンスへのパーミッションの委譲
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (target = "ldap:///cn=*,ou=Groups,dc=example,dc=com") targetfilter="(&(objectClass=top)(objectClass=groupOfUniqueNames))") (targetattr="cn || uniqueMember || objectClass") (version 3.0; acl "example"; allow (read, search, write, add) (userdn = "ldap:///uid=test,ou=People,dc=example,dc=com");)
- top オブジェクトクラスおよび groupOfUniqueNames オブジェクトクラスが含まれる必要があるオブジェクトを作成できます。
- account などの追加のオブジェクトクラスを追加できません。たとえば、ローカル認証に Directory Server アカウントを使用して、無効なユーザー ID (例:
root
ユーザーの 0) を持つ新規ユーザーを作成できなくなります。
18.11.3.2. エントリーと属性の両方をターゲットに設定
例18.8 エントリーと属性の両方をターゲットに設定
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (target="ldap:///cn=*,dc=example,dc=com")(targetattr="member" || "cn") (version 3.0; acl "Allow uid=user to search and read members of groups"; allow (read, search) (userdn = "ldap:///uid=user,ou=People,dc=example,dc.com");)
18.11.3.3. フィルターに一致するエントリーの個別属性のターゲット設定
例18.9 フィルターに一致するエントリーの個別属性のターゲット設定
department
属性が Engineering に設定されている全エントリーの jpegPhoto
属性および manager
属性を cn=Engineering Admins,dc=example,dc=com グループのメンバーが変更できるようにするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr = "jpegPhoto|| manager") (targetfilter = "(department=Engineering)") (version 3.0; acl "Allow engineering admins updating jpegPhoto and manager of department members"; allow (write) (groupdn = "ldap:///cn=Engineering Admins,dc=example,dc.com");)
18.11.3.4. 単一ディレクトリーエントリーのターゲット設定
例18.10 単一ディレクトリーエントリーのターゲット設定
ou
および cn
属性を読み取り、検索できるようにするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=Engineering,dc=example,dc=com changetype: modify add: aci aci: (targetattr = "ou || cn") (targetfilter = "(ou=Engineering)") (version 3.0; acl "Allow uid=user to search and read engineering attributes"; allow (read, search) (userdn = "ldap:///uid=user,ou=People,dc=example,dc.com");)
ou
属性を Engineering に設定しないでください。
18.12. パーミッションの定義
(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)
構文
permission (rights)
- permission: ACI がパーミッションを許可するか、拒否するかを設定します。
- rights: ACI が許可または拒否する権限を設定します。「ユーザーの権利」を参照してください。
例18.11 パーミッションの定義
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: dc=People,dc=example,dc=com
changetype: modify
add: aci
aci: (target = "ldap:///ou=People,dc=example,dc=com") (version 3.0;
acl "Allow users to read and search attributes of own entry"; allow (search, read)
(userdn = "ldap:///self");)
18.12.1. ユーザーの権利
権利 | 説明 |
---|---|
read | ユーザーがディレクトリーデータを読み込めるかどうかを設定します。このパーミッションは、LDAP の検索操作にのみ適用されます。 |
write | 属性を追加、変更、または削除してユーザーがエントリーを変更できるかどうかを設定します。このパーミッションは、LDAP の modify および modrdn 操作に適用されます。 |
add | ユーザーがエントリーを作成できるかどうかを設定します。このパーミッションは、LDAP の add 操作にのみ適用されます。 |
削除 | ユーザーがエントリーを削除できるかどうかを設定します。このパーミッションは、LDAP の delete 操作にのみ適用されます。 |
search | ユーザーがディレクトリーデータを検索できるかどうかを設定します。検索結果の一部として返されたデータを表示するには、search および read 権限を付与します。このパーミッションは、LDAP の検索操作にのみ適用されます。 |
compare | ユーザーが提供したデータとディレクトリーに保存されているデータを比較できるかどうかを設定します。compare 権限では、ディレクトリーは問い合わせに対して成功または失敗のメッセージを返しますが、ユーザーはエントリーや属性の値を見ることはできません。このパーミッションは、LDAP の比較操作にのみ適用されます。 |
selfwrite | ユーザーがグループから独自の DN を追加または削除できるかどうかを設定します。この権限は、グループ管理にのみ使用されます。 |
proxy |
指定した DN が他のエントリーの権限でターゲットにアクセスできるかどうかを設定します。proxy 権限は ACL の範囲内で付与され、その権限が付与されたユーザーやグループは、Directory Server のユーザーとしてコマンドを実行することができます。プロキシー権限を特定のユーザーに制限することはできません。
セキュリティー上の理由から、proxy 権限を使用する ACI は、ディレクトリーの最も対象となるレベルに設定してください。
|
all | proxy 以外のすべての権限を設定します。 |
18.12.2. LDAP 操作に必要な権限
- エントリーの追加:
- 追加するエントリーの add パーミッションを付与します。
- エントリーの各属性の値に write パーミッションを付与します。この権限はデフォルトで付与されますが、targattrfilters キーワードを使用して制限できます。
- エントリーの削除:
- 削除するエントリーの delete パーミッションを付与します。
- エントリーの各属性の値に write パーミッションを付与します。この権限はデフォルトで付与されますが、targattrfilters キーワードを使用して制限できます。
- エントリーの属性の変更:
- 属性タイプで write パーミッションを付与します。
- 各属性種別の値の write 権限を付与します。この権限はデフォルトで付与されますが、targattrfilters キーワードを使用して制限できます。
- エントリーの RDN の変更:
- エントリーで write パーミッションを付与します。
- 新しい RDN で使用される属性タイプの write パーミッションを付与します。
- 古い RDN の削除に適した権限を付与する場合は、古い RDN で使用される属性タイプの write パーミッションを付与します。
- 新しい RDN で使用される属性型の値に対して write 権限を付与します。この権限はデフォルトで付与されますが、targattrfilters キーワードを使用して制限できます。
- 属性の値を比較します。
- 属性タイプで compare パーミッションを付与します。
- エントリーの検索:
- 検索フィルターで使用される各属性タイプの search パーミッションを付与します。
- エントリーで使用される属性タイプの read パーミッションを付与します。
18.12.3. アクセス制御と modrdn 操作
cn
属性が含まれる ou=people,dc=example,dc=com のエントリーの名前を変更できません。
ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (target="ldap:///cn=*,ou=people,dc=example,dc=com") (version 3.0; acl "Deny modrdn rights to the example group"; deny(write) groupdn="ldap:///cn=example,ou=groups,dc=example,dc=com";)
18.13. バインドルールの定義
- DNS
- グループメンバーシップまたは割り当てられたロール
- エントリーがバインドする場所
- バインド時に使用する必要のある認証の種類
- バインドが実行される回数または日数
(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)
構文
keyword comparison_operator "expression"
- keyword: bind 操作のタイプを設定します。「頻繁に使用されるバインドルール」を参照してください。
- comparison_operator: 有効な値は = および != で、ターゲットが式で指定されたオブジェクトであるかを示します。キーワードが追加の比較演算子に対応している場合は、該当するセクションで説明されます。
- expression: 式を設定し、引用符で囲む必要があります。式自体は使用するキーワードによって異なります。
18.13.1. 頻繁に使用されるバインドルール
- userDN: 「ユーザーベースのアクセスの定義」を参照してください。
- groupdn: 「グループベースのアクセスの定義」を参照してください。
18.13.1.1. ユーザーベースのアクセスの定義
userdn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."
- DN: 「userdn キーワードでの DN の使用」を参照してください。
- LDAP フィルター: 「LDAP フィルターで userdn キーワードの使用」を参照してください。
- anyone エイリアス: 「匿名アクセスの付与」を参照してください。
- all エイリアス: 「認証済みユーザーへのアクセスの付与」を参照してください。
- self エイリアス: 「ユーザーが空のエントリーにアクセスできるようにする」を参照してください。
- parent エイリアス: 「ユーザーの子エントリーへのアクセス設定」を参照してください。
18.13.1.1.1. userdn キーワードでの DN の使用
userdn comparison_operator ldap:///distinguished_name
例18.12 userdn キーワードでの DN の使用
manager
属性を読み取るようにするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr="manager") (version 3.0; acl "Allow uid=admin reading manager attribute"; allow (search, read) userdn = "ldap:///uid=admin,ou=People,dc=example,dc=com";)
18.13.1.1.2. LDAP フィルターで userdn キーワードの使用
userdn comparison_operator "ldap:///distinguished_name??scope?(filter)"
例18.13 LDAP フィルターで userdn キーワードの使用
department
属性が Human Resources に設定されたユーザーを有効にするには、ou=People,dc=example,dc=com エントリーでユーザーの homePostalAddress
属性を更新します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr="homePostalAddress") (version 3.0; acl "Allow HR setting homePostalAddress"; allow (write) userdn = "ldap:///ou=People,dc=example,dc=com??sub?(department=Human Resources)";)
18.13.1.1.3. 匿名アクセスの付与
- バインド DN およびパスワードなし
- 有効なバインド DN およびパスワード
userdn comparison_operator "ldap:///anyone"
例18.14 匿名アクセスの付与
sn
属性、givenName
属性、および telephoneNumber
属性を読み取りおよび検索できるようにするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr="sn" || targetattr="givenName" || targetattr = "telephoneNumber") (version 3.0; acl "Anonymous read, search for names and phone numbers"; allow (read, search) userdn = "ldap:///anyone")
18.13.1.1.4. 認証済みユーザーへのアクセスの付与
userdn comparison_operator "ldap:///all"
例18.15 認証済みユーザーへのアクセスの付与
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=example,ou=Groups,dc=example,dc=com changetype: modify add: aci aci: (targetattr="member") (version 3.0; acl "Allow users to add/remove themselves from example group"; allow (selfwrite) userdn = "ldap:///all")
18.13.1.1.5. ユーザーが空のエントリーにアクセスできるようにする
userdn comparison_operator "ldap:///self"
例18.16 ユーザーが空のエントリーにアクセスできるようにする
userPassword
属性を更新できるようにするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr="userPassword") (version 3.0; acl "Allow users updating their password"; allow (write) userdn = "ldap:///self")
18.13.1.1.6. ユーザーの子エントリーへのアクセス設定
userdn comparison_operator "ldap:///parent"
例18.17 ユーザーの子エントリーへのアクセス設定
manager
属性を更新できるようにするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=user,ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr="manager") (version 3.0; acl "Allow cn=user to update manager attributes"; allow (write) userdn = "ldap:///parent")
18.13.1.2. グループベースのアクセスの定義
member
uniqueMember
memberURL
memberCertificateDescription
groupdn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."
- DN。「groupdn キーワードでの DN の使用」を参照してください。
- LDAP フィルター。「LDAP フィルターで groupdn キーワードの使用」を参照してください。
18.13.1.2.1. groupdn キーワードでの DN の使用
groupdn comparison_operator ldap:///distinguished_name
例18.18 groupdn キーワードでの DN の使用
manager
属性を検索および読み取るようにするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr="manager") (version 3.0; acl "Allow example group to read manager attribute"; allow (search, read) groupdn = "ldap:///cn=example,ou=Groups,dc=example,dc=com";)
18.13.1.2.2. LDAP フィルターで groupdn キーワードの使用
groupdn comparison_operator "ldap:///distinguished_name??scope?(filter)"
例18.19 LDAP フィルターで groupdn キーワードの使用
manager
属性が example に設定されているサブツリーを有効にするには、ou=People,dc=example,dc=com のエントリーのhomePostalAddress
を更新します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr="homePostalAddress") (version 3.0; acl "Allow manager=example setting homePostalAddress"; allow (write) userdn = "ldap:///dc=example,dc=com??sub?(manager=example)";)
18.13.2. さらなるバインドルール
18.13.2.1. 値の一致に基づくアクセスの定義
userattr comparison_operator "attribute_name#bind_type_or_attribute_value
18.13.2.1.1. USERDN バインドタイプの使用
userattr comparison_operator "attribute_name#USERDN"
例18.20 USERDN バインドタイプの使用
telephoneNumber
属性に付与するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr = "telephoneNumber") (version 3.0; acl "Manager: telephoneNumber"; allow (all) userattr = "manager#USERDN";)
manager
属性に格納されている DN と一致すれば、真と評価されます。
18.13.2.1.2. GROUPDN バインドタイプの使用
userattr comparison_operator "attribute_name#GROUPDN"
例18.21 GROUPDN バインドタイプの使用
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=Social Committee,ou=Groups,dc=example,dc=com changetype: modify add: aci aci: (target="ou=Social Committee,ou=Groups,dc=example,dc=com) (targattrfilters="del=objectClass:(objectClass=groupOfNames)") (version 3.0; acl "Delete Group"; allow (delete) userattr = "owner#GROUPDN";)
owner
属性で指定されたグループのメンバーである場合に、以前の ACI が true になります。
userattr comparison_operator "ldap:///distinguished_name?attribute_name#GROUPDN"
18.13.2.1.3. ROLEDN バインドタイプの使用
userattr comparison_operator "attribute_name#ROLEDN"
例18.22 ROLEDN バインドタイプの使用
cn=Administrators,dc=example,dc=com
ロールを持つユーザーが ou=People,dc=example,dc=com のエントリーの manager
属性を検索および読み取るようにするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (version 3.0; acl "Allow example role owners to read manager attribute"; allow (search, read) roledn="ldap:///cn=Administrators,dc=example,dc=com";)
userattr comparison_operator "ldap:///distinguished_name?attribute_name#ROLEDN"
18.13.2.1.4. SELFDN バインドタイプの使用
userattr comparison_operator "attribute_name#SELFDN"
例18.23 SELFDN バインドタイプの使用
ipatokenOwner
属性にバインドユーザーの DN が設定された ipatokenuniqueid=*,cn=otp,dc=example,dc=com エントリーを追加できるようにするには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=otp,dc=example,dc=com changetype: modify add: aci aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,dc=example,dc=com") (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl "token-add-delete"; allow (add) userattr = "ipatokenOwner#SELFDN";)
18.13.2.1.5. LDAPURL バインドタイプの使用
userattr comparison_operator "attribute_name#LDAPURL"
例18.24 LDAPURL バインドタイプの使用
aciurl
属性が含まれるユーザーオブジェクトに読み取りパーミッションおよび検索パーミッションを付与するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr = "*") (version 3.0; acl "Allow read,search "; allow (read,search) (userattr = "aciurl#LDAPURL);)
18.13.2.1.6. バインド DN とターゲット DN の属性値の一致
userattr comparison_operator "attribute_name#value"
例18.25 バインド DN とターゲット DN の属性値の一致
l
属性が office_1 に設定されたツリー内の操作およびユーザーの両方に読み取りパーミッションおよび検索パーミッションを付与するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr != "userPassword") (version 3.0; acl "Users in the same location"; allow (read,search) userattr = "l#office_1";)
18.13.2.1.7. 継承による userattr キーワードの使用
userattr comparison_operator "parent[inheritance_level].attribute_name#bind_type_or_attribute_value
- inheritance_level: ターゲットが ACI を継承するレベルの数を指定します。ターゲットエントリーの下に、5 つのレベル (0、1、2、3、4) を追加できます。ゼロ (0) はターゲットエントリーを示します。
- attribute_name: userattr または groupattr のキーワードでターゲットとする属性。
- bind_type_or_attribute_value: USERDN などの属性値またはバインドタイプを設定します。
userattr = "parent[0,1].manager#USERDN"
例18.26 継承による userattr キーワードの使用
owner
属性に設定されている cn=Profiles,dc=example,dc=com エントリー、および cn=mail,cn=Profiles,dc=example,dc=com および cn=news,cn=Profiles,dc=example,dc=com を含む第 1 レベルの子エントリーの読み取りと検索を可能にするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Profiles,dc=example,dc=com changetype: modify add: aci aci: (targetattr="*") (version 3.0; acl "Profile access", allow (read,search) userattr="parent[0,1].owner#USERDN" ;)
18.13.2.2. 特定の IP アドレスまたは範囲からのアクセスの定義
ip comparison_operator "IP_address_or_range"
例18.27 バインドルールでの IPv4 アドレス範囲の使用
192.0.2.2/24
ネットワークから dc=example,dc=com エントリーへのアクセスを拒否するには、以下のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr = "*") (version 3.0;acl "Deny 192.0.2.2/24"; deny (all) (userdn = "ldap:///anyone") and (ip != "192.0.2.");)
例18.28 バインドルールでの IPv6 アドレス範囲の使用
2001:db8::/64
ネットワークから dc=example,dc=com エントリーへのアクセスを拒否するには、以下のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr = "*") (version 3.0;acl "Deny 2001:db8::/64"; deny (all) (userdn = "ldap:///anyone") and (ip != "2001:db8::");)
18.13.2.3. 特定のホストまたはドメインからアクセスの定義
dns comparison_operator "host_name_or_domain_name"
例18.29 特定のホストからのアクセスの定義
client.example.com
ホストから dc=example,dc=com エントリーへのアクセスを拒否するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr = "*") (version 3.0;acl "Deny client.example.com"; deny (all) (userdn = "ldap:///anyone") and (dns != "client.example.com");)
例18.30 特定のドメインからアクセスの定義
example.com
ドメイン内のすべてのホストから dc=example,dc=com エントリーへのアクセスを拒否するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr = "*") (version 3.0;acl "Deny example.com"; deny (all) (userdn = "ldap:///anyone") and (dns != "*.example.com");)
18.13.2.4. 接続に一定レベルのセキュリティーの要求
ssf comparison_operator key_strength
- = (等しい)
- ! (等しくない)
- < (より小さい)
- > (より大きい)
- <= (より小さいか等しい)
- >= (より大きいか等しい)
例18.31 接続に一定レベルのセキュリティーの要求
userPassword
属性を更新できるように設定する場合は、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr = "userPassword") (version 3.0; acl "Allow users updating own userPassword"; allow (write) (userdn = "ldap:///self") (ssf >= "128");)
18.13.2.5. 曜日の特定の日におけるアクセスの定義
dayofweek comparison_operator "comma-separated_list_of_days"
例18.32 特定の曜日にアクセスの付与
uid=user,ou=People,dc=example,dc=com
ユーザーエントリーのアクセスを拒否するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (version 3.0; acl "Deny access on Saturdays and Sundays"; deny (all) (userdn = "ldap:///uid=user,ou=People,dc=example,dc=com") and (dayofweek = "Sun,Sat");)
18.13.2.6. 特定の時刻におけるアクセスの定義
timeofday comparison_operator "time"
- = (等しい)
- ! (等しくない)
- < (より小さい)
- > (より大きい)
- <= (より小さいか等しい)
- >= (より大きいか等しい)
例18.33 特定の時刻におけるアクセスの定義
uid=user,ou=People,dc=example,dc=com
ユーザーエントリーへのアクセスを拒否するには、6pm から 0am までのサーバーにバインドします。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (version 3.0; acl "Deny access between 6pm and 0am"; deny (all) (userdn = "ldap:///uid=user,ou=People,dc=example,dc=com") and (timeofday >= "1800" and timeofday < "2400");)
18.13.2.7. 認証方法に基づいたアクセスの定義
authmethod comparison_operator "authentication_method"
- none: 認証は不要で、匿名のアクセスを表します。これがデフォルトになります。
- simple: クライアントは、ディレクトリーにバインドするユーザー名とパスワードを提供する必要があります。
- SSL: クライアントは、データベース、スマートカード、または他のデバイスのいずれかで TLS 証明書を使用してディレクトリーにバインドする必要があります。証明書ベースの認証の詳細は、「証明書ベースのクライアント認証の使用」を参照してください。
- SASL: クライアントは、Simple Authentication and Security Layer (SASL) 接続を介してディレクトリーにバインドする必要があります。bind ルールでこの認証方法を使用する場合は、EXTERNAL などの SASL メカニズムも指定します。
例18.34 EXTERNAL SASL 認証方法を使用した接続でのみアクセスのみの有効化
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (version 3.0; acl "Deny all access without certificate"; deny (all) (authmethod = "none" or authmethod = "simple");)
18.13.2.8. ロールに基づくアクセスの定義
userdn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."
例18.35 ロールに基づくアクセスの定義
nsRole
属性で cn=Human Resources,ou=People,dc=example,dc=com ロールを設定したユーザーが ou=People,dc=example,dc=com のエントリーの manager
属性を検索および読み取るようにするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr="manager") (version 3.0; acl "Allow manager role to update manager attribute"; allow (search, read) roledn = "ldap:///cn=Human Resources,ou=People,dc=example,dc=com";)
18.13.3. ブール演算子を使用したバインドルールの組み合わせ
bind_rule_1 boolean_operator bind_rule_2...
例18.36 ブール演算子を使用したバインドルールの組み合わせ
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (target="ldap:///ou=People,dc=example,dc=com") (version 3.0; acl "Allow members of administrators and operators group to manage users"; allow (read, search, add, write, delete) groupdn = "ldap:///cn=Administrators,ou=Groups,dc=example,com" AND groupdn = "ldap:///cn=Operators,ou=Groups,dc=example,com";)
Directory Server によるブール値演算子の評価方法
- 左から右へのすべての式。以下の例では、bind_rule_1 が最初に評価されます。
(bind_rule_1) OR (bind_rule_2)
- 一番内側から外側に向かって、親表現が優先されます。以下の例では、bind_rule_2 を最初に評価し、次に bind_rule_3 を評価します。
(bind_rule_1) OR ((bind_rule_2) AND (bind_rule_3))
- AND または OR 演算子の前に NOT。以下の例では、bind_rule_2 が最初に評価されます。
(bind_rule_1) AND NOT (bind_rule_2)
18.14. エントリーのアクセス権利の確認 (Get Effective Rights)
- 管理者は、ディレクトリーに対するアクセス制御手順をより適切に整理するために、get effective rights コマンドを使用できます。あるグループのユーザーが閲覧または編集できる内容を、別のグループと比較して制限する必要があることがよくあります。たとえば、QA Managers グループのメンバーには、
manager
やsalary
などの属性を検索および読み取る権利がありますが、HR Group メンバーのみが変更または削除する権限を持ちます。ユーザーまたはグループの実効権限を確認する方法は、適切なアクセス制御が有効であることを確認する方法です。 - ユーザーは、get effective rights コマンドを実行して、個人エントリーで表示または変更できる属性を確認することができます。たとえば、ユーザーは
homePostalAddress
やcn
などの属性にアクセスできますが、manager
属性およびsalary
属性への読み取りアクセスしかできません。
18.14.1. Get Effective Rights 検索表示される権限
entryLevelRights: vadn attributeLevelRights: givenName:rscWO, sn:rscW, objectClass:rsc, uid:rsc, cn:rscW
パーミッション | 説明 |
---|---|
a | エントリーを追加します。 |
d | このエントリーを削除します。 |
n | DN の名前を変更します。 |
v | エントリーを表示します。 |
パーミッション | 説明 |
---|---|
r | 読み取り。 |
s | 検索。 |
w | 書き込み (mod-add)。 |
o | 抹消 (mod-del)。削除に類似しています。 |
c | 比較。 |
W | 自己書き込み。 |
O | 自己削除。 |
18.14.2. Get Effective Rights 検索の形式
-E
オプションを定義して、ldapsearch コマンドで LDAP コントロールを渡します。(-E
オプションなしで ldapsearch を実行すると、get effective rights 情報なしに、エントリーが通常通りに返されます。)
# ldapsearch -x -D bind_dn -W -p server_port -h server_hostname -E [!]1.3.6.1.4.1.42.2.27.9.5.2=:GER_subject (searchFilter) attributeList
-b
は、GER サブジェクトの検索に使用されるサブツリーまたはエントリーのベース DN です。検索ベースが特定のエントリー DN である場合や、1 つのエントリーのみが返される場合、結果には要求元がその特定のエントリーに対して所有している権利が表示されます。検索ベースの下にある複数のエントリーがフィルターと一致する場合、検索は一致するすべてのエントリーを返し、各エントリーに対する要求側の権限で返します。- 1.3.6.1.4.1.42.2.27.9.5.2 は、get effective rights control の OID です。
- 感嘆符 (!) は、サーバーがこの制御 (!) をサポートしていない場合に、検索操作でエラーを返すか、無視して通常通りの検索を行うか (nothing) を指定します。
- GER_subject は、権限を確認するユーザーです。GER_subject が空白 (dn:) のままの場合、匿名ユーザーの権限が返されます。
- 任意の attributeList は、Get Effective Rights 結果を指定された属性またはオブジェクトクラスに制限します。通常の ldapsearch の場合のように、
mail
などの特定の属性を指定できます。属性が表示されない場合は、エントリーの present 属性がすべて返されます。アスタリスク (*) を使用すると、エントリーに対して可能なすべての属性の権限が返されます (既存の属性と存在しない属性の両方)。プラス記号 (+) を使用すると、エントリーの操作属性が返されます。「Non-Existent 属性の Get Effective Rights 検索の例」および「特定の属性またはオブジェクトクラスの Get Effective Rights 検索の例」で特定属性の権限を確認する例。
-E
) が検索対象者 (-b
) に対してどのような権利を持っているかを確認できることです。get effective rights 検索は通常の ldapsearch で、検索パラメーターに一致するエントリーを検索し、その情報を返します。get effective rights オプションは、これらの検索結果に追加の情報を加え、特定のユーザーがそれらの検索結果に対してどのような権利を持っているかを示します。その GER サブジェクトユーザーは、リクエスター (-D
が -E
と同じ) でも、別のユーザーでも構いません。
- ユーザー A は、他のディレクトリーエントリーに対する権利を確認します。
- ユーザー A は、自身のエントリーに必要な権限をチェックします。
- ユーザー A は、ユーザー B がユーザー A のエントリーに対して持っている権利をチェックします。
18.14.3. GER 検索の例
18.14.3.1. アクセス権限の確認に関する一般的な例
-D
と -E
オプションの両方により、そのエントリーは要求元として付与されます。-b
オプションには、個人エントリーを確認するため、その DN も含まれます。
例18.37 個人の権利の確認 (ユーザー A からユーザー A)
# ldapsearch -x -p 389 -h server.example.com -D "uid=tmorris,ou=people,dc=example,dc=com" -W -b "uid=tmorris,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=tmorris,ou=people,dc=example,dc=com' "(objectClass=*)" dn: uid=tmorris,ou=People,dc=example,dc=com givenName: Ted sn: Morris ou: IT ou: People l: Santa Clara manager: uid=jsmith,ou=People,dc=example,dc=com roomNumber: 4117 mail: tmorris@example.com facsimileTelephoneNumber: +1 408 555 5409 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: tmorris cn: Ted Morris userPassword: {SSHA}bz0uCmHZM5b357zwrCUCJs1IOHtMD6yqPyhxBA==entryLevelRights:
vattributeLevelRights:
givenName:rsc, sn:rsc, ou:rsc, l:rsc, manager:rsc, roomNumber:rscwo, mail:rscwo, facsimileTelephoneNumber:rscwo, objectClass:rsc, uid:rsc, cn:rsc, userPassword:wo
-D
) が Dave Miller のエントリー (-b
) に対する自分の権利 (-E
) を確認しているように、他のユーザーのエントリーに対して自分がどのような権利を持っているかを確認したい場合があります。
例18.38 別のユーザーの権限を個人的に確認 (ユーザー A からユーザー B へ)
# ldapsearch -p 389 -h server.example.com -D "uid=tmorris,ou=people,dc=example,dc=com" -W -b "uid=dmiller,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=tmorris,ou=people,dc=example,dc=com' "(objectClass=*)" dn: uid=dmiller,ou=People,dc=example,dc=com ... snip ... entryLevelRights: vad attributeLevelRights: givenName:rscwo, sn:rscwo, ou:rscwo, l:rscwo, manager:rsc, roomNumber:rscwo, mail:rscwo, facsimileTelephoneNumber:rscwo, objectClass:rscwo, uid:rscwo, cn:rscwo, userPassword:rswo
-E
) が部下である Ted Morris (-b
) に対して持っている権限をチェックしています。
例18.39 Directory Manager での別のユーザーに対する (User A からユーザー B に対する) 権利の確認
# ldapsearch -p 389 -h server.example.com -D "cn=Directory Manager" -W -b "uid=tmorris,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=jsmith,ou=people,dc=example,dc=com' "(objectClass=*)" dn: uid=tmorris,ou=People,dc=example,dc=com ... snip ... entryLevelRights: vadn attributeLevelRights: givenName:rscwo, sn:rscwo, ou:rscwo, l:rscwo, manager:rscwo, roomNumber:rscwo, mail:rscwo, facsimileTelephoneNumber:rscwo, objectClass:rscwo, uid:rscwo, cn:rscwo, userPassword:rscwo
# ldapsearch -p 389 -h server.example.com -D "uid=dmiller,ou=people,dc=example,dc=com" -W -b "uid=tmorris,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=tmorris,ou=people,dc=example,dc=com' "(objectClass=*)" ldap_search: Insufficient access ldap_search: additional info: get-effective-rights: requester has no g permission on the entry
例18.40 個人のエントリーに対する他ユーザーの権利の確認
# ldapsearch -p 389 -h server.example.com -D "uid=tmorris,ou=people,dc=example,dc=com" -W -b "uid=tmorris,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=dmiller,ou=people,dc=example,dc=com' "(objectClass=*)" dn: uid=tmorris,ou=people,dc=example,dc=com ... snip ... entryLevelRights: v attributeLevelRights: givenName:rsc, sn:rsc, ou:rsc, l:rsc,manager:rsc, roomNumber:rsc, mail:rsc, facsimileTelephoneNumber:rsc, objectClass:rsc, uid:rsc, cn:rsc, userPassword:none
ou
、givenName
、l
、およびその他の属性を読み取り、検索し、比較する権利を有しており、userPassword
属性については権利を有していません。
18.14.3.2. Non-Existent 属性の Get Effective Rights 検索の例
userPassword
の値が削除された場合、上記のエントリーで将来的に有効な権利を検索しても、自己書き込みおよび自己削除の権利が許可されていても、userPassword
に対する有効な権利は返されません。
例18.41 Non-Existent 属性の有効な権限を返す
# ldapsearch -D "cn=Directory Manager" -W -b "uid=scarter,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" "*"
dn: uid=scarter,ou=People,dc=example,dc=com
givenName: Sam
telephoneNumber: +1 408 555 4798
sn: Carter
ou: Accounting
ou: People
l: Sunnyvale
manager: uid=dmiller,ou=People,dc=example,dc=com
roomNumber: 4612
mail: scarter@example.com
facsimileTelephoneNumber: +1 408 555 9700
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: scarter
cn: Sam Carter
userPassword: {SSHA}Xd9Jt8g1UsHC8enNDrEmxj3iJPKQLItlDYdD9A==
entryLevelRights: vadn
attributeLevelRights: objectClass:rscwo, aci:rscwo, sn:rscwo, cn:rscwo, description:rscwo, seeAlso:rscwo, telephoneNumber:rscwo, userPassword:rscwo, destinationIndicator:rscwo, facsimileTelephoneNumber:rscwo, internationaliSDNNumber:rscwo, l:rscwo, ou:rscwo, physicalDeliveryOfficeName:rscwo, postOfficeBox:rscwo, postalAddress:rscwo, postalCode:rscwo, preferredDeliveryMethod:rscwo, registeredAddress:rscwo, st:rscwo, street:rscwo, teletexTerminalIdentifier:rscwo, telexNumber:rscwo, title:rscwo, x121Address:rscwo, audio:rscwo, businessCategory:rscwo, carLicense:rscwo, departmentNumber:rscwo, displayName:rscwo, employeeType:rscwo, employeeNumber:rscwo, givenName:rscwo, homePhone:rscwo, homePostalAddress:rscwo, initials:rscwo, jpegPhoto:rscwo, labeledUri:rscwo, manager:rscwo, mobile:rscwo, pager:rscwo, photo:rscwo, preferredLanguage:rscwo, mail:rscwo, o:rscwo, roomNumber:rscwo, secretary:rscwo, uid:rscwo,x500UniqueIdentifier:rscwo, userCertificate:rscwo, userSMIMECertificate:rscwo, userPKCS12:rscwo
secretary
など、エントリーに使用できる属性はすべて、その属性が存在しない場合でも表示されます。
18.14.3.3. 特定の属性またはオブジェクトクラスの Get Effective Rights 検索の例
例18.42 特定の属性に対する get effective rights の結果
# ldapsearch -D "cn=Directory Manager" -W -b "uid=scarter,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)"cn mail initials
dn: uid=scarter,ou=People,dc=example,dc=com cn: Sam Carter mail: scarter@example.com entryLevelRights: vadn attributeLevelRights:cn:rscwo, mail:rscwo, initials:rscwo
initials
属性のように、attributeList に存在しない属性を指定することで、アスタリスクを使用してすべての属性をリストアップするのと同様に、利用可能な権利を確認することができます。
例18.43 オブジェクトクラス内の属性に対する get effective rights 結果
# ldapsearch -D "cn=Directory Manager" -W -b "uid=scarter,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" uidNumber@posixAccount
... snip ...
dn: cn=template_posixaccount_objectclass,uid=scarter,ou=people,dc=example,dc=com
uidnumber: (template_attribute)
entryLevelRights: v
attributeLevelRights: uidNumber:rsc
-D
) が Directory Manager の場合のみ利用できます。
例18.44 オブジェクトクラスのすべての属性に対する get effective rights 結果
# ldapsearch -D "cn=Directory Manager" -W -b "uid=scarter,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" *@posixaccount
... snip ...
dn: cn=template_posixaccount_objectclass,uid=scarter,ou=people,dc=example,dc=com
objectClass: posixaccount
objectClass: top
homeDirectory: (template_attribute)
gidNumber: (template_attribute)
uidNumber: (template_attribute)
uid: (template_attribute)
cn: (template_attribute)
entryLevelRights: v
attributeLevelRights: cn:rsc, uid:rsc, uidNumber:rsc, gidNumber:rsc, homeDirectory:rsc, objectClass:rsc, userPassword:none, loginShell:rsc, gecos:rsc, description:rsc, aci:rsc
18.14.3.4. 存在しないエントリーの get effective rights 検索の例
jsmith
) が存在しないユーザーにどのような権限を確認したい場合があります。存在しないエントリーをチェックする場合、サーバーはそのサブツリー内にダミーエントリーを生成します。たとえば、ダミーエントリー cn=joe new user,cn=accounts,ou=people,dc=example,dc=com
を確認するには、サーバーは cn=template,cn=accounts,ou=people,dc=example,dc=com
を作成します。
@person
) を持つ cn=joe new user,cn=accounts,ou=people,dc=example,dc=com
の場合、サーバーは cn=template_person_objectclass,cn=accounts,ou=people,dc=example,dc=com
を生成します。
uidNumber
の存在しない Posix エントリーについて scarter
の権限を確認するには、次のコマンドを実行します。
# ldapsearch -D "cn=Directory Manager" -W -b "ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" @posixaccount:uidnumber
dn: uidNumber=template_posixaccount_objectclass,ou=people,dc=example,dc=com
entryLevelRights: v
attributeLevelRights: description:rsc, gecos:rsc, loginShell:rsc, userPassword
:rsc, objectClass:rsc, homeDirectory:rsc, gidNumber:rsc, uidNumber:rsc, uid:
rsc, cn:rsc
18.14.3.5. 操作属性の get effective rights 検索の例
例18.45 操作属性に対する get effective rights の結果
# ldapsearch -D "cn=Directory Manager" -W -x -b "uid=scarter,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" "+"
dn: uid=scarter,ou=People,dc=example,dc=com
entryLevelRights: vadn
attributeLevelRights: nsICQStatusText:rscwo, passwordGraceUserTime:rscwo, pwdGraceUserTime:rscwo, nsYIMStatusText:rscwo, modifyTimestamp:rscwo, passwordExpWarned:rscwo, pwdExpirationWarned:rscwo, entrydn:rscwo, aci:rscwo, nsSizeLimit:rscwo, nsAccountLock:rscwo, passwordExpirationTime:rscwo, entryid:rscwo, nsSchemaCSN:rscwo, nsRole:rscwo, retryCountResetTime:rscwo, ldapSchemas:rscwo, nsAIMStatusText:rscwo, copiedFrom:rscwo, nsICQStatusGraphic:rscwo, nsUniqueId:rscwo, creatorsName:rscwo, passwordRetryCount:rscwo, dncomp:rscwo, nsTimeLimit:rscwo, passwordHistory:rscwo, pwdHistory:rscwo, nscpEntryDN:rscwo, subschemaSubentry:rscwo, nsYIMStatusGraphic:rscwo, hasSubordinates:rscwo, pwdpolicysubentry:rscwo, nsAIMStatusGraphic:rscwo, nsRoleDN:rscwo, createTimestamp:rscwo, accountUnlockTime:rscwo, copyingFrom:rscwo, nsLookThroughLimit:rscwo, nsds5ReplConflict:rscwo, modifiersName:rscwo, parentid:rscwo, passwordAllowChangeTime:rscwo, nsBackendSuffix:rscwo, nsIdleTimeout:rscwo, ldapSyntaxes:rscwo, numSubordinates:rscwo
18.14.3.6. get effective rights 結果とアクセスコントロールルールの例
dn: dc=example,dc=com objectClass: top objectClass: domain dc: example aci: (target=ldap:///ou=Accounting,dc=example,dc=com)(targetattr="*")(version 3.0; acl "test acl"; allow (read,search,compare) (userdn = "ldap:///anyone") ;) dn: ou=Accounting,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: Accounting
例18.46 ACL を設定しない (Directory Manager) Get Effective Rights の結果
# ldapsearch -D "cn=Directory Manager" -W -b "dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" "*@person" dn: cn=template_person_objectclass,uid=scarter,ou=people,dc=example,dc=com objectClass: person objectClass: top cn: (template_attribute) sn: (template_attribute) description: (template_attribute) seeAlso: (template_attribute) telephoneNumber: (template_attribute) userPassword: (template_attribute) entryLevelRights: none attributeLevelRights: sn:none, cn:none, objectClass:none, description:none, seeAlso:none, telephoneNumber:none, userPassword:none, aci:none
例18.47 ACL を設定しない (通常ユーザー) Get Effective Rights の結果
# ldapsearch -D "uid=scarter,ou=people,dc=example,dc=com" -W -b "dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" "*@person"
18.14.4. コンソールからの Get Effective Rights の使用
- Directory タブを開き、権限を確認するエントリーを右クリックします。
- ドロップダウンメニューから Advanced Properties を選択します。
- Show effective rights チェックボックスにチェックを入れます。
- 属性ごとに、属性レベルの get effective rights が表示されます。エントリーレベルの権限は、エントリーの DN の下に表示されます。属性レベルの有効な権限(r、s、c、w、o)が属性の横に表示されます。エントリーレベルの権限(v、 a、d、n)は、Property Editor の左下にあるエントリーの完全な DN に表示されます。
18.14.5. Get Effective Rights 戻りコード
コード | 説明 |
---|---|
0 | 正常に完了しました。 |
1 | 操作エラー。 |
12 | 重要な拡張機能は利用できません。重大度式が true に設定され、クエリー対象のエントリーに有効な権限がない場合は、このエラーが返されます。 |
16 | そのような属性はありません。アクセス権のために特定の属性をクエリーしましたが、その属性がスキーマに存在しない場合は、このエラーが返されます。 |
17 | 未定義の属性タイプ。 |
21 | 無効な属性構文。 |
50 | 権限が不十分。 |
52 | 利用できません。 |
53 | 不本意なパフォーマンス。 |
80 | その他。 |
18.15. アクセス制御情報のロギング
- Console で Directory タブをクリックし、設定ノードを右クリックし、ポップアップメニューから Properties を選択します。これにより、cn=config エントリーの Property Editor が表示されます。
- 属性値のペアのリストを下方向にスクロールして、nsslapd-errorlog-level 属性を見つけます。
- nsslapd-errorlog-level value フィールドに、現在表示されている値に 128 を追加します。たとえば、すでに表示される値が 8192 (レプリケーションのデバッグ)の場合は、値を 8320 に変更します。エラーログレベルの詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス を参照してください』。
- Property Editor を外します。をクリックして、
18.16. 高度なアクセス制御: マクロ ACI の使用
18.16.1. マクロ ACI の例
aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)
図18.1 マクロ ACI のディレクトリーツリーの例
aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com";)
aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1,dc=example,dc=com";)
aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany2,dc=example,dc=com";)
aci: (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany2,dc=example,dc=com";)
aci: (target="ldap:///ou=Groups,($dn),dc=example,dc=com") (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)
18.16.2. マクロ ACI 構文
- ($dn)
- [$dn]
- ($attr.attrName) ここで、attrName はターゲットエントリーに含まれる属性を表します。
マクロ | ACI キーキーワード |
---|---|
($dn) | target, targetfilter, userdn, roledn, groupdn, userattr |
[$dn] | targetfilter, userdn, roledn, groupdn, userattr |
($attr.attrName) | userdn, roledn, groupdn, userattr |
- targetfilter、userdn、roledn、groupdn、userattr で ($dn) を使用する場合は、($dn) を含むターゲットを定義する 必要があります。
- targetfilter、userdn、roledn、groupdn、userattr で [$dn] を使用する場合は、($dn) を含むターゲットを定義する 必要があります。
18.16.2.1. ($dn) のマクロ一致
(target="ldap:///ou=Groups,($dn),dc=example,dc=com")
aci: (target="ldap:///ou=*,($dn),dc=example,dc=com") (targetattr = "*") (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,($dn),dc=example,dc=com";)
aci: (target="ldap:///ou=Groups,dc=subdomain1,dc=hostedCompany1, dc=example,dc=com") (targetattr = "*") (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups, dc=subdomain1,dc=hostedCompany1,dc=example,dc=com";)
18.16.2.2. [$dn] のマクロ一致
aci: (target="ldap:///ou=Groups,($dn),dc=example,dc=com") (targetattr = "*") (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)
- ターゲットの ($dn) は dc=subdomain1,dc=hostedCompany1 と一致します。
- サブジェクトの [$dn] は、dc=subdomain1,dc=hostedCompany1 に置き換えられます。その結果は、groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=subdomain1,dc=hostedCompany1,dc=example,dc=com" になります。バインド DN が対象のグループのメンバーである場合は、一致するプロセスが停止し、ACI が評価されます。一致しない場合は、プロセスが続行します。
- サブジェクトの [$dn] は、dc=hostedCompany1 に置き換えられます。その結果は、groupdn="ldap:///cn=DomainAdmins,ou=Groups,dc=hostedCompany1,dc=example,dc=com" になります。この場合、バインド DN がそのグループのメンバーではない場合、ACI は評価されません。これがメンバーの場合には、ACI が評価されます。
aci: (target="ldap:///ou=*, ($dn),dc=example,dc=com") (targetattr="*")(targetfilter=(objectClass=nsManagedDomain)) (version 3.0; acl "Domain access"; allow (read,search) groupdn="ldap:///cn=DomainAdmins,ou=Groups,[$dn],dc=example,dc=com";)
18.16.2.3. Macro Matching for ($attr.attrName)
roledn = "ldap:///cn=DomainAdmins,($attr.ou)"
dn: cn=Jane Doe,ou=People,dc=HostedCompany1,dc=example,dc=com cn: Jane Doe sn: Doe ou: Engineering,dc=HostedCompany1,dc=example,dc=com ...
ou
属性を確認し、この属性の値をマクロを展開します。そのため、この例では roledn は以下のように展開されます。
roledn = "ldap:///cn=DomainAdmins,ou=Engineering,dc=HostedCompany1,dc=example,dc=com"
dn: cn=Jane Doe,ou=People,dc=HostedCompany1,dc=example,dc=com cn: Jane Doe sn: Doe ou: Engineering,dc=HostedCompany1,dc=example,dc=com ou: People,dc=HostedCompany1,dc=example,dc=com...
roledn = "ldap:///cn=DomainAdmins,ou=Engineering,dc=HostedCompany1,dc=example,dc=com" roledn = "ldap:///cn=DomainAdmins,ou=People,dc=HostedCompany1,dc=example,dc=com"
18.17. Directory Manager でのアクセス制御の設定
18.17.1. Directory Manager アカウントのアクセス制御
dse.ldif
ファイルで定義されます。したがって、サブツリー内のエントリーに基づく ACI ターゲット(「ターゲットの定義」)には Directory Manager は含まれません。
- 時間ベースのアクセス制御 (例: 8a.m. から 5p.m)(0800 から 1700)、および曜日のアクセス制御により、アクセスは明示的に定義された日数でのみ許可されます。これは「曜日の特定の日におけるアクセスの定義」および「特定の時刻におけるアクセスの定義」に類似しています。
- 指定した IP アドレス、ドメイン、またはサブネットのみが明示的に許可または拒否される IP アドレスルール。これは、「特定の IP アドレスまたは範囲からのアクセスの定義」に類似しています。
- ホストアクセスルール。指定されたホスト名、ドメイン名、またはサブドメインのみが明示的に許可または拒否されます。これは、「特定のホストまたはドメインからアクセスの定義」に類似しています。
18.17.2. RootDN アクセス制御プラグインの設定
nsslapd-pluginEnabled
属性を on に設定して、RootDN アクセス制御プラグインを有効にします。以下に例を示します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=RootDN Access Control Plug-in,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
- アクセス制御命令にバインドルールを設定します。
rootdn-open-time
時間ベースのアクセス制御の場合はrootdn-close-time
です。rootdn-days-allowed
日ベースのアクセス制御の場合rootdn-allow-host
ホストベースのアクセス制御用のrootdn-deny-host
、rootdn-allow-ip
、およびrootdn-deny-ip
。これらはすべて多値の属性です。拒否ルールは、許可ルールよりも優先されます。たとえば、rootdn-allow-host
属性が *.example.com に設定され、rootdn-deny-host
属性が *.front-office.example.com に設定されている場合、front-office.example.com サブドメインにあるものはすべて、大規模な example.com ドメインが許可されていても Directory Manager としてログインできなくなります。ワイルドカードは、IP 範囲またはフルドメインを許可するために使用できます。
以下に例を示します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=RootDN Access Control Plug-in,cn=plugins,cn=config changetype: modify add: rootdn-open-time rootdn-open-time: 0600 - add: rootdn-close-time rootdn-close-time: 2100 - add: rootdn-allow-host rootdn-allow-host: *.example.com - add: rootdn-deny-host rootdn-allow-host: *.remote.example.com
- Directory Server を再起動して、新しいプラグイン設定を読み込みます。
# systemctl restart dirsrv@instance
18.18. 以前のリリースとの互換性
- userdnattr
- groupdnattr
第19章 ユーザー認証の管理
19.1. ユーザーパスワードの設定
userPassword
属性があり、アクティブではない場合にのみディレクトリーにバインドするために使用できます。ユーザーパスワードはディレクトリーに格納されるため、ldapmodify などの LDAP 操作でユーザーパスワードを設定またはリセットできます。
Directory Manager
(root DN) を使用してパスワードを設定すると、パスワードポリシーは回避され、検証されません。通常のユーザーパスワードの管理には、これらのアカウントを使用しないでください。パスワードポリシーの回避が必要なパスワード管理タスクの実行にのみ使用します。
19.2. パスワード管理者の設定
- ユーザーがパスワードの変更を強制する
- パスワードポリシーで定義されている異なるストレージスキームへのユーザーのパスワードの変更
- パスワード構文チェックを回避
- ハッシュ化されたパスワードを追加します。
userPassword
属性のみを更新するパーミッションを持つデータベース内の既存のロールで実行することが推奨されます。このような通常のタスクにパスワード管理者アカウントを使用することは推奨されません。
ldapmodify
を使用してメインの設定エントリーに passwordAdminDN
属性を設定します。
# ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -W dn: cn=cn\3DnsPwPolicyEntry\2Cou\3DPeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=example,dc=com changetype: modify replace: passwordAdminDN passwordAdminDN: cn=Passwd Admins,ou=groups,dc=example,dc=com
# ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -W dn: cn=config changetype: modify replace: passwordAdminDN passwordAdminDN: cn=Passwd Admins,ou=groups,dc=example,dc=com
19.3. 外部に保存されたパスワードの変更
# ldappasswd -x -D bind_dn -W -p server_port -h server_hostname [-a oldPassword] [-s newPassword] [user]
パラメーター | 詳細 |
---|---|
-h | Directory Server のホスト名を指定します。 |
-p | Directory Server のポート番号を指定します。パスワード変更操作に TLS が必要なため、通常は Directory Server の TLS ポートが指定されます。Start TLS の -Z Z または -ZZZ を使用する場合、これは標準ポートになります。 |
-D | バインド DN を指定します。 |
-w | バインド DN のパスワードを指定します。 |
-x | TLS 接続での単純なバインドを許可するように SASL を無効にします。 |
-a | オプション。変更中の古いパスワードを指定します。 |
-s | オプション。新しいパスワードを設定します。 |
user | オプション。パスワードを変更するユーザーエントリーの DN を指定します。 |
# ldappasswd -x -D bind_dn -W -p server_port -h server_hostname -Z
[-a oldPassword] [-s newPassword] [user]
# ldappasswd -x -h ldap.example.com -p 389 -ZZ -D "uid=jsmith,ou=People,dc=example,dc=com" -W -s newpassword
# ldappasswd -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -ZZ -s newpassword "uid=jsmith,ou=People,dc=example,dc=com"
19.4. パスワードポリシーの管理
- ユーザーはスケジュールに応じてパスワードを変更する必要があります。
- ユーザーは、簡単ではないパスワードを提供する必要があります。
- パスワード構文は、特定の複雑な要件を満たす必要があります。
Directory Manager
(root DN) を使用してパスワードを設定すると、パスワードポリシーは回避され、検証されません。通常のユーザーパスワードの管理には、これらのアカウントを使用しないでください。パスワードポリシーの回避が必要なパスワード管理タスクの実行にのみ使用します。
- パスワードポリシーチェックのタイプまたはレベル。この情報は、サーバーがグローバルパスワードポリシーまたはローカル (サブツリー/ユーザーレベル) パスワードポリシーを確認および有効にするかどうかを示します。パスワードポリシーは、一般的なものから特定のものまで、逆ピラミッド型になっています。グローバルパスワードポリシーは、サブツリーレベルのパスワードポリシーに置き換えられました。これは、ユーザーレベルのパスワードポリシーに置き換えられます。エントリーに対して強制されるパスワードポリシーは 1 つだけで、パスワードポリシーは追加されません。つまり、特定の属性がグローバルレベルまたはサブツリーレベルのポリシーで設定されていて、ユーザーレベルのパスワードポリシーで設定されていない場合、アクティブで適用されるポリシーはユーザーレベルのポリシーであるため、ログインが試みられてもその属性はユーザーに使用されません。
- パスワードの追加および変更の情報。パスワード情報には、パスワードの構文およびパスワード履歴の詳細が含まれます。
- バインド情報バインド情報には、許可された猶予期間の数、パスワードエージング属性、およびバインド失敗の追跡が含まれます。
19.4.1. グローバルパスワードポリシーの設定
19.4.1.1. コンソールを使用したグローバルパスワードポリシーの設定
- Configuration タブを選択し、Data ノードを選択します。
- 右側のペインで、Passwords タブを選択します。このタブには、Directory Server 全体のパスワードポリシーが含まれます。
- ユーザーが独自のパスワードを変更するためにパスワードポリシーを設定します。
- ユーザーが初めてパスワードを変更する必要がある場合は、リセット後にパスワードを変更する必要があります。
- ユーザーが独自のパスワードを変更できるようにするには、User may change password チェックボックスを選択します。
- ユーザーが特定の期間のパスワードを変更できないようにするには、Allow changes in X day(s) テキストボックスに日数を入力します。これにより、パスワード履歴でパスワードを再利用できるように、パスワード交換を迅速化する必要がなくなります。
- サーバーが各ユーザーが使用するパスワードの履歴リストを維持するには、Keep password history チェックボックスを選択します。Remember X password テキストボックスに、ユーザーごとに保持するサーバーのパスワード 数を入力します。
- パスワードの有効期限が切れる場合のポリシーを設定します。
- ユーザーパスワードが失効しない場合は、パスワードを失効 しない ラジオボタンを選択します。
- ユーザーがパスワードを定期的に変更する必要がある場合は、X days ラジオボタンの後に Password expires を選択し、ユーザーパスワードが有効な日数を入力します。パスワード期間の最大値は、今日の日付から 1 月 18 日の 2038 を引いて派生します。入力した値は最大値に設定できず、最大値に近い値も設定しないでください。値を最大値に設定すると、エポック日が経過した秒数を超えると、Directory Server が起動できなくなる可能性があります。このような場合、エラーログはパスワードの最大期間が無効であることを示します。この問題を解決するには、dse.ldif ファイルの
passwordMaxAge
属性値を修正します。一般的なポリシーでは、パスワードは 30 - 90 日ごとに失効します。デフォルトでは、パスワードの最大期間は 8640000 秒(100 日)に設定されます。 - X days ラジオボタンが終わった後にパスワードを失効 させた場合は、パスワードが失効してからユーザーに警告を送信する期間を指定します。Send Warning X Days Before Password Expires テキストでは、パスワードの有効期限が失効してから警告を送信するまでの日数を入力します。注記Directory Server がユーザーに警告を送信するように設定する必要はありません。Directory Server は、次回ユーザーが Directory Server Console にログインしようとすると、パスワードが期限切れになったり、期限切れになったりするときに警告が表示されます。これは、ユーザーのログイン時に "Warning: password will expire in 7 days" を読み取るオペレーティングシステムの警告に似ています。
- サーバーによるユーザーパスワードの構文をチェックして、パスワードポリシーで設定された最小要件を満たすようにするには、Check Password Syntax チェックボックスを選択します。次に、最小の長さや必要な数や特殊文字など、必要なパスワードの複雑性を指定します。
- パスワード暗号化 プルダウンメニューから、パスワードを保存する時に使用するサーバーの暗号化方法を選択します。サポート対象のパスワードストレージスキームの一覧は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス の該当するセクションを参照してください』。
- Save をクリックします。
19.4.1.2. コマンドラインを使用したグローバルパスワードポリシーの設定
- LDIF ファイルを作成します。各ステートメントは、stdin による変更の入力と同じです。これは、ダッシュ(-)で区切られた個別の更新ステートメントです。
dn: cn=config changetype: modify add: passwordChange passwordChange: on - add: passwordExp passwordExp: on - add: passwordMaxAge passwordMaxAge: 8640000 - add: passwordCheckSyntax passwordCheckSyntax: on - add: passwordMinCategories passwordMinCategories: 3 - add: passwordStorageScheme passwordStorageScheme: SSHA512 ^D
以下の表は、パスワードポリシーの設定に使用できる属性を示しています。表19.2 パスワードポリシー関連の属性 passwordChange passwordCheckSyntax passwordExp passwordGraceLimit passwordHistory passwordInHistory passwordMaxAge passwordMaxRepeats passwordMin8bit passwordMinAge passwordMinAlphas passwordMinCategories passwordMinDigits passwordMinLength passwordMinLowers passwordMinSpecials passwordMinTokenLength passwordMinUppers passwordMustChange passwordSendExpiringTime passwordStorageScheme passwordTrackUpdateTime passwordWarning - ldapmodify コマンドで
-f
オプションを使用して、LDIF ファイルをサーバーに渡します。# ldapmodify -D "cn=Directory Manager" -W -x
-f user-pwdpolicy.ldif
19.4.2. ローカルパスワードポリシーの設定
19.4.2.1. コンソールを使用したサブツリー/ユーザーパスワードポリシーの設定
- 「コンソールを使用したグローバルパスワードポリシーの設定」 で説明されているように、きめ細かなパスワードポリシーをグローバルに有効にします。ユーザーレベルのパスワードポリシーを許可する場合は、Enable fine-grained password policy チェックボックスにチェックマークを入れてください。注記グローバルパスワードポリシーは、異なる場合はローカルポリシーを上書きしません。
- サブツリーまたはユーザーのローカルパスワードポリシーを作成します。
- Directory タブを選択します。
- ナビゲーションペインで、パスワードポリシーを設定するサブツリーまたはユーザーエントリーを選択します。
- Object メニューから Manage Password Policy オプションを選択し、For user または For subtree を選択します。
- Passwords タブで Create subtree/user level password policy のチェックボックスを選択し、必要な属性を追加します。パスワードポリシー設定: リセット、有効期限、構文、および暗号化は、「コンソールを使用したグローバルパスワードポリシーの設定」 のグローバルポリシーと同じです。
- Account Lockout タブで、適切な情報を指定して Save をクリックします。
19.4.2.2. コマンドラインを使用したサブツリー/ユーザーパスワードポリシーの設定
- ns-newpwpolicy.pl スクリプトを実行して、必要な属性をサブツリーまたはユーザーエントリーに追加します。スクリプトのコマンド構文は以下のとおりです。
# ns-newpwpolicy.pl [-D rootDN] -w password | -w - | -j filename [-p port] [-h host] -U userDN -S suffixDN
サブツリーエントリーを更新するには、- S オプションを使用します。ユーザーエントリーを更新するには、- U オプションを使用します。ns-newpwpolicy.pl スクリプトは、一度に 1 つのユーザーまたはサブツリーエントリーのみを受け入れます。ただし、ユーザーと接尾辞エントリーの両方を同時に使用することも可能です。このスクリプトの詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス を参照してください』。 - このスクリプトは、ターゲットエントリーがサブツリーまたはユーザーエントリーであるかに応じて、必要な属性を追加します。サブツリー (例: ou=people,dc=example,dc=com) では、以下のエントリーが追加されます。
- サブツリーとそのすべての子について、さまざまなパスワードポリシー関連のエントリーを保持するためのサブツリーレベルのコンテナーエントリー (
nsPwPolicyContainer
)。以下に例を示します。dn: cn=nsPwPolicyContainer,ou=people,dc=example,dc=com objectClass: top objectClass: nsContainer cn: nsPwPolicyContainer
- サブツリーに固有のすべてのパスワードポリシー属性を保持するための実際のパスワードポリシー仕様エントリー (
nsPwPolicyEntry
) です。以下に例を示します。dn: cn="cn=nsPwPolicyEntry,ou=people,dc=example,dc=com", cn=nsPwPolicyContainer,ou=people,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: ldapsubentry objectclass: passwordpolicy
- 上記の (
nsPwPolicyEntry
) エントリーを指定するpwdpolicysubentry
値を持つ CoS テンプレートエントリー (nsPwTemplateEntry
)。以下に例を示します。dn: cn="cn=nsPwTemplateEntry,ou=people,dc=example,dc=com", cn=nsPwPolicyContainer,ou=people,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: costemplate objectclass: ldapsubentry cosPriority: 1 pwdpolicysubentry: cn="cn=nsPwPolicyEntry,ou=people,dc=example,dc=com", cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
- サブツリーレベルでの CoS 仕様エントリー。以下に例を示します。
dn: cn=newpwdpolicy_cos,ou=people,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=cn=nsPwTemplateEntry\,ou=people\,dc=example,dc=com, cn=nsPwPolicyContainer,ou=people,dc=example,dc=com cosAttribute: pwdpolicysubentry default operational
ユーザーの場合( uid=jdoe,ou=people,dc=example,dc=comなど)、以下のエントリーが追加されます。- ユーザーとそのすべての子について、さまざまなパスワードポリシー関連のエントリーを保持するための親レベルのコンテナーエントリー (
nsPwPolicyContainer
)。以下に例を示します。dn: cn=nsPwPolicyContainer,ou=people,dc=example,dc=com objectClass: top objectClass: nsContainer cn: nsPwPolicyContainer
- ユーザーに固有のパスワードポリシー属性を保持するための実際のパスワードポリシー仕様エントリー (
nsPwPolicyEntry
) です。以下に例を示します。dn: cn="cn=nsPwPolicyEntry,uid=jdoe,ou=people,dc=example,dc=com", cn=nsPwPolicyContainer,ou=people,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: ldapsubentry objectclass: passwordpolicy
- 上記のエントリー DN の値をターゲットエントリーの
pwdpolicysubentry
属性に割り当てます。たとえば、以下はパスワードポリシーをユーザーエントリーに割り当てます。dn: uid=jdoe,ou=people,dc=example,dc=com changetype: modify replace: pwdpolicysubentry pwdpolicysubentry: cn="cn=nsPwPolicyEntry,uid=jdoe,ou=people,dc=example,dc=com", cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
- 適切な値でサブツリーまたはユーザーエントリーのパスワードポリシー属性を設定します。表19.2「パスワードポリシー関連の属性」 には、パスワードポリシーの設定に使用できる属性が記載されています。ldapmodify ユーティリティーを使用すると、nsPwPolicyEntry オブジェクトクラスが含まれるサブツリーまたはユーザーエントリーのこれらの属性を変更できます。注記cn=config エントリーの
nsslapd-pwpolicy-local
属性は、サーバーが強制するパスワードポリシーのタイプを制御します。デフォルトでは、この属性は無効(off)です。属性が無効になると、サーバーはグローバルパスワードポリシーのみを確認し、強制します。サブツリーおよびユーザーレベルのパスワードポリシーは無視されます。ns-newpwpolicy.pl スクリプトが実行されると、最初に指定されたサブツリーおよびユーザーエントリーをチェックし、それらが存在する場合は変更します。エントリーを正常に更新した後、スクリプトはnsslapd-pwpolicy-local
設定パラメーターを on に設定します。サブツリーおよびユーザーレベルのパスワードポリシーを有効にできない場合は、スクリプトの実行後にnsslapd-pwpolicy-local
を off に設定するようにしてください。
nsslapd-pwpolicy-local
属性を off に設定します。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config changetype: modify replace: nsslapd-pwpolicy-local nsslapd-pwpolicy-local: off
dse.ldif
)で直接変更して無効にすることもできます。
- サーバーを停止します。
# systemctl stop dirsrv.target instance
- テキストエディターで
dse.ldif
ファイルを開きます。 nsslapd-pwpolicy-local
の値を off に設定し、保存します。nsslapd-pwpolicy-local: off
- サービスを起動します。
# systemctl start dirsrv.target instance
19.5. パスワードの有効期限コントロールの概要
- 期限切れのコントロール (2.16.840.1.113730.3.4.4): パスワードの有効期限が切れていることを示しています。Directory Server は以下の状況でこの制御を送信します。
- パスワードの失効していますが、猶予のあるログインがなくなりました。サーバーは、Error 49 メッセージでバインドを拒否します。
- パスワードは失効していますが、自動ログインは引き続き利用できます。バインドが許可されます。
- cn=config エントリーで
passwordMustChange
を有効にし、管理者が変更した後にパスワードをリセットする必要があります。バインドが許可されますが、パスワードの変更以外の後続の操作では、Error 53 メッセージが表示されます。
- 期限切れコントロール (2.16.840.1.113730.3.4.5): パスワードが間もなく期限切れになることを示します。Directory Server は以下の状況でこの制御を送信します。
- このパスワードは、cn=config エントリーの
passwordWarning
属性に設定されたパスワード警告期間内に期限切れとなります。 - cn=config エントリーの
passwordSendExpiringTime
属性でパスワードポリシー設定オプションが有効になっている場合は、パスワードが警告期間内にいるかどうかにかかわらず、期限切れ制御が常に返されます。
- バインド応答制御 (1.3.6.1.4.1.42.2.27.8.5.1): この制御には、期限切れ間近のパスワードや、もうすぐ期限切れになるパスワードの状態に関する詳細な情報が含まれています。注記Directory Server は、クライアントが要求した場合に限りバインド応答制御を送信します。たとえば、ldapsearch を使用する場合は、
-e ppolicy
パラメーターをコマンドに渡してバインド応答制御を要求する必要があります。例19.1 Query でのバインド処理コントロールの要求
-e ppolicy
パラメーターを ldapsearch コマンドに渡すなどしてバインド応答制御を要求する場合、サーバーはアカウントの有効期限に関する詳細情報を返します。以下に例を示します。# ldapsearch -D "uid=user_name,dc=example,dc=com" -xLLL -W \ -b "dc=example,dc=com" -e ppolicy ldap_bind: Success (0); Password expired (Password expired, 1 grace logins remain)
19.6. Directory Manager パスワードの管理
root
ユーザーと類似しています。Directory Manager エントリーと対応するパスワードは、インスタンスのインストール時に設定されます。
cn=Directory Manager
です。
19.6.1. Directory Manager パスワードのリセット
- Directory Server インスタンスを停止します。
# systemctl stop dirsrv@instance_name
- 新しいパスワードハッシュを生成します。以下に例を示します。
# pwdhash -D /etc/dirsrv/slapd-instance_name password {SSHA512}2eyW2uSFhh8LeB/nwZipfvFhSwL2DKZ58kXrCXsxr98Vz0nZI8fhd0W5BbL321Sr9Ulhzo3LhiQLiv4iVGF7hEGezIka65kN
Directory Server 設定へのパスを指定すると、nsslapd-rootpwstoragescheme
属性に設定されたパスワードストレージスキームが自動的に使用され、新しいパスワードを暗号化します。 /etc/dirsrv/slapd-instance_name/dse.ldif
ファイルを編集し、nsslapd-rootpw
属性を直前の手順で表示された値に設定します。nsslapd-rootpw: {SSHA512}2eyW2uSFhh8LeB/nwZipfvFhSwL2DKZ58kXrCXsxr98Vz0nZI8fhd0W5BbL321Sr9Ulhzo3LhiQLiv4iVGF7hEGezIka65kN
- Directory Server インスタンスを起動します。
# systemctl start dirsrv@instance_name
19.6.2. Directory Manager パスワードの変更
19.6.2.1. コマンドラインを使用した Directory Manager パスワードの変更
- 新しいパスワードハッシュを生成します。以下に例を示します。
# pwdhash -D /etc/dirsrv/slapd-instance_name password {SSHA512}2eyW2uSFhh8LeB/nwZipfvFhSwL2DKZ58kXrCXsxr98Vz0nZI8fhd0W5BbL321Sr9Ulhzo3LhiQLiv4iVGF7hEGezIka65kN
Directory Server 設定へのパスを指定すると、nsslapd-rootpwstoragescheme
属性に設定されたパスワードストレージスキームが自動的に使用され、新しいパスワードを暗号化します。 - セキュアな接続 (STARTTLS) を使用して、前のステップで表示される値に
nsslapd-rootpw
属性を設定します。# ldapmodify -W -x -D "cn=Directory Manager" -p 389 -h server.example.com -x -ZZ dn: cn=config changetype: modify replace: nsslapd-rootpw nsslapd-rootpw: {SSHA512}2eyW2uSFhh8LeB/nwZipfvFhSwL2DKZ58kXrCXsxr98Vz0nZI8fhd0W5BbL321Sr9Ulhzo3LhiQLiv4iVGF7hEGezIka65kN
19.6.2.2. Directory Server コンソールを使用した Directory Manager パスワードの変更
- Directory Server コンソールを開きます。詳細は、「Directory Server コンソールを開く」 を参照してください。
- Configuration タブで、左側のペインのホスト名を選択し、Manager タブをクリックします。
- 新しいパスワードを入力して確定します。
19.6.3. Directory Manager パスワードストレージスキームの変更
nsslapd-rootpwstoragescheme
)のストレージスキームは、ユーザーパスワードの暗号化に使用されるスキームと異なる場合があります(nsslapd-pwstoragescheme
)。
19.6.3.1. コマンドラインを使用した Directory Manager パスワードストレージスキームの変更
- 新しいストレージスキームを使用する新しいパスワードハッシュを生成します。以下に例を示します。
# pwdhash -s SSHA512 password {SSHA512}2eyW2uSFhh8LeB/nwZipfvFhSwL2DKZ58kXrCXsxr98Vz0nZI8fhd0W5BbL321Sr9Ulhzo3LhiQLiv4iVGF7hEGezIka65kN
nsslapd-rootpwstoragescheme
属性をストレージスキームに設定し、nsslapd-rootpw
属性をセキュアな接続 (STARTTLS) を使用して、前の手順で表示した値に設定します。# ldapmodify -W -x -D "cn=Directory Manager" -p 389 -h server.example.com -x -F dn: cn=config changetype: modify replace: nsslapd-rootpwstoragescheme nsslapd-rootpwstoragescheme: SSHA512 - replace: nsslapd-rootpw nsslapd-rootpw: {SSHA512}2eyW2uSFhh8LeB/nwZipfvFhSwL2DKZ58kXrCXsxr98Vz0nZI8fhd0W5BbL321Sr9Ulhzo3LhiQLiv4iVGF7hEGezIka65kN
19.6.3.2. コンソールを使用した Directory Manager パスワードストレージスキームの変更
- Directory Server コンソールを開きます。詳細は、「Directory Server コンソールを開く」 を参照してください。
- Configuration タブで左側のペインのホスト名を選択し、Manager タブをクリックします。
- Manager password encryption フィールドで新しいパスワードストレージスキームを選択します。
- 新しいパスワードを入力して確定します。
19.6.4. Directory Manager DN の変更
19.6.4.1. コマンドラインを使用した Directory Manager DN の変更
cn=New Directory Manager
に変更するには、以下の手順を実施します。
# ldapmodify -W -x -D "cn=Directory Manager" -p 389 -h server.example.com -x dn: cn=config changetype: modify replace: nsslapd-rootdn nsslapd-rootdn: cn=New Directory Manager
19.6.4.2. コンソールを使用した Directory Manager DN の変更
- Directory Server コンソールを開きます。詳細は、「Directory Server コンソールを開く」 を参照してください。
- Configuration タブで左側のペインのホスト名を選択し、Manager タブをクリックします。
- Directory Manager DN フィールドに、Directory Manager の新しい DN を入力します。
19.7. パスワードなしのアクセスについてのアカウント可用性の確認
19.7.1. アカウントのユーザビリティー拡張制御を使用したエントリーの検索
-J
、または accountusability:true
フラグを使用して指定することができます。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub-J "accountusability:true"
"(objectclass=*)" # Account Usability Response Control# The account is usable
dn: dc=example,dc=com objectClass: domain objectClass: top dc: example ...
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "uid=bjensen,ou=people,dc=example,dc=com" -s base-J "accountusability:true"
"(objectclass=*)" # Account Usability Response Control# The account is usable
dn: uid=bjensen,ou=people,dc=example,dc=com ...
アカウントのステータス | コントロール結果メッセージ |
---|---|
有効なパスワードがあるアクティブなアカウント | The account is usable |
パスワードが設定されていないアクティブなアカウント | The account is usable |
期限切れのパスワード | Password expired |
アカウントのパスワードポリシーが変更される | Password expired |
アカウントがロックされ、ロックアウト期間がありません | Password reset |
アカウントがロックされ、ロックアウト期間があります | Time (in seconds) for automatic unlock of the account |
最初のログイン時にアカウントのパスワードをリセットする必要があります | Password reset |
パスワードの期限が切れており、猶予期間ログインが許可されます | Password expired and X grace login is allowed |
パスワードの有効期限が切れ、猶予ログイン回数がなくなっています。 | Password expired |
パスワードの有効期限が切れます (期限切れの警告)。 | Password will expire in X number of seconds |
19.7.2. アカウントのユーザビリティー検索の対象を変更
# ldapmodify -D "cn=Directory Manager" -W -x dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config changetype: modify add: aci aci: (targetattr = "*")(version 3.0; acl "Account Usable"; allow (read)(groupdn = "ldap:///cn=Administrators,ou=groups,dc=example,dc=com");)
19.8. パスワードベースのアカウントロックアウトポリシーの設定
19.8.1. コンソールを使用したアカウントロックアウトポリシーの設定
- Configuration タブを選択し、Data ノードを選択します。
- 右側のペインで、Account Lockout タブを選択します。
- アカウントのロックアウトを有効にするには、Accounts may be locked out のチェックボックスを選択します。
- X ログインの失敗テキストボックスの後に、Lockout アカウントに 許可されるバインド失敗の最大数を入力します。サーバーは、ここで指定した制限を超えるユーザーをロックします。
- X minutes テキストボックスの後に Reset failure カウンターに、サーバーが待機した後に、バインド失敗カウンターがゼロにリセットされるまでの数分を入力します。
- ユーザーがディレクトリーからロックされる間隔を設定します。
- パスワードを管理者がリセットするまで ロックアウト ラジオボタンを選択し てユーザーをロックアウトします。
- Lockout Duration ラジオボタンを選択し、テキストボックスに時間(分単位)を入力して、特定のロックアウト期間を設定します。
- Save をクリックします。
19.8.2. コマンドラインを使用したアカウントロックアウトポリシーの設定
# ldapmodify -D "cn=Directory Manager" -W -x -p 389 -h server.example.com -x dn: cn=config changetype: modify replace: passwordLockout passwordLockout: on - add: passwordMaxFailure passwordMaxFailure: 4 - add: passwordLockoutDuration passwordLockoutDuration: 600 -
19.8.3. レガシーパスワードロックアウト動作の無効化
passwordMaxFailure
) に達すると、解釈する方法は複数あります。これは、サーバーが最後の失敗を全体の失敗数にどのようにカウントするかによります。
passwordLegacyPolicy
パラメーターで設定されます。
[root@server ~]# ldapmodify -D "cn=Directory Manager" -x -D "cn=directory manager" -W -p 389 -h server.example.com -x dn: cn=config replace: passwordLegacyPolicy passwordLegacyPolicy: off
19.9. 時間ベースのアカウントロックアウトポリシーの構成
- プラグイン自体の設定エントリー。これにより、そのサーバーに設定されたすべてのアカウントポリシーに使用されるグローバル値が設定されます。
- アカウントポリシー設定エントリー。このエントリーはユーザーディレクトリー内にあり、基本的にはユーザーアカウントエントリーに参照および適用されるテンプレートとなります。
- アカウントポリシーエントリーを適用するエントリー。ユーザーアカウントは、直接アカウントポリシーを参照したり、CoS またはロールを使用してアカウントポリシーを自動的にユーザーアカウントのセットに適用することができます。注記アカウントポリシーは、
acctPolicySubentry
属性を介して適用されます。この属性はユーザーアカウントに直接追加できますが、この属性は単値になります。つまり、そのアカウントにはアカウントポリシーを 1 つだけ適用できます。これはほとんどの場合で問題ありません。しかし、現実的には、2 つのアカウントポリシーを作成することができます。1 つはアカウントの非アクティブ化のため、もう1つは年齢に基づくアカウントの失効のためです。CoS を使用してアカウントポリシーを適用すると、複数のアカウントポリシーをアカウントに使用できます。
19.9.1. アカウントポリシープラグインの構文
- nsslapd-pluginEnabled: プラグインが有効かどうかを設定します。この属性はデフォルトで off です。
- nsslapd-pluginarg0: プラグイン設定ディレクトリーの DN を参照します。設定エントリーは、通常プラグイン自体の子エントリーです (例: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config)。
- nsslapd-pluginarg0 属性で特定されたプラグイン設定エントリー。これにより、アカウントポリシー設定エントリーの特定やユーザーアカウントエントリーの管理に使用するプラグインのグローバル設定が設定されます。これらの設定はサーバー全体に適用されます。設定エントリー属性は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 の 『アカウントポリシープラグイン属性』 セクションで説明されています。
- アカウントポリシーの設定エントリー。これは、アカウントポリシーに特定の値を設定するテンプレートエントリーとよく似ています。ユーザーアカウントは、直接または CoS エントリーを介して、このアカウントポリシーエントリを参照します。アカウントポリシーとユーザーエントリーの属性については、以下の表で説明されています。
表19.4 アカウントポリシーエントリーおよびユーザーエントリーの属性 属性 定義 設定またはユーザーエントリー accountpolicy (オブジェクトクラス) アカウントの無効化または期限切れポリシーのテンプレートエントリーを定義します。 設定 accountInactivityLimit (属性) アカウントの最終ログイン時刻から、非アクティブ時にアカウントがロックされるまでの時間を秒単位で設定します。 設定 acctPolicySubentry (属性) アカウントのポリシー (具体的には、アカウントロックアウトポリシー) に属するエントリーを指定します。この属性の値は、エントリーに適用されるアカウントポリシーの DN を参照します。 ユーザー createTimestamp (操作属性) エントリーが最初に作成された日時が含まれます。 ユーザー lastLoginTime (操作属性) 指定のアカウントがディレクトリーに対して認証された最終時刻のタイムスタンプが含まれます。 ユーザー 詳細は、Red 『Hat Directory Server の設定、コマンド、およびファイルリファレンス』の属性の説明を参照してください。
19.9.2. アカウントアクティビティーとアカウントの有効期限
Account Policy
プラグインを使用すると、以下を設定できます。
- アカウントの有効期限: アカウントの作成後に一定時間無効になります。
- アカウントの非アクティブ化: 最後にログインに成功してから一定時間が経過すると、アカウントが無効になります。これにより、未使用のアカウントを自動的に無効にできます。
Account Policy
プラグインを設定するには、以下を実行します。
- アカウントポリシープラグインを有効にします。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Account Policy Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
- nsslapd-pluginarg0 属性を、プラグイン設定エントリーを参照するように設定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Account Policy Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginarg0 nsslapd-pluginarg0: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
- プラグイン設定エントリーを作成します。
- アカウントポリシーで CoS またはロールを使用するには、
alwaysRecordLogin
の値をyes
に設定します。これは、acctPolicySubentry
属性がない場合でも、すべてのエントリーにログイン時間が記録されることを意味します。 - アカウントポリシー評価に使用するプライマリー属性を
stateAttrName
の値として設定します。アカウントの停止状態の場合は、lastLoginTime
属性を使用します。単純なアカウントの有効期限の場合は、createTimestamp
属性を使用します。 altStateAttrName
にセカンダリー属性を設定できます。これは、stateAttrName
で定義されたプライマリー属性が存在しない場合にチェックできます。属性を指定していない場合は、デフォルト値のcreateTimestamp
が使用されます。警告プライマリー属性の値がlastLoginTime
とaltStateAttrName
でcreateTimestamp
に設定されていると、既存の環境のユーザーは、アカウントにlastLoginTime
属性がなく、設定した非アクティブ期間よりもcreateTimestamp
が古い場合に、既存の環境のユーザーは自動的にロックされます。この状況に対処するには、代替属性を1.1
に設定します。これは、代替として属性を使用しないことを明示します。lastLoginTime
属性は、ユーザーが次回ログインした後に自動的に作成されます。- アカウントポリシーを適用するエントリーを表示するのに使用する属性を設定します (
acctPolicySubentry
)。 - 実際のタイムアウト期間の設定に使用されるアカウントポリシーの属性を秒単位で設定します (
accountInactivityLimit
)。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: config alwaysRecordLogin: yes stateAttrName: lastLoginTime altStateAttrName: 1.1 specattrname: acctPolicySubentry limitattrname: accountInactivityLimit - サーバーを再起動して、新しいプラグイン設定を読み込みます。
# systemctl start dirsrv.target
- アカウントポリシーを定義します。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Account Inactivation Policy,dc=example,dc=com objectClass: top objectClass: ldapsubentry objectClass: extensibleObjectobjectClass: accountpolicy
accountInactivityLimit: 2592000
cn: Account Inactivation Policy - サービステンプレートエントリーのクラスを作成します。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=TempltCoS,dc=example,dc=com objectClass: top objectClass: ldapsubentry objectClass: extensibleObject objectClass: cosTemplate acctPolicySubentry: cn=Account Inactivation Policy,dc=example,dc=comアカウントポリシーは、CoS を使用する代わりに、ユーザーエントリーで直接定義できます。しかし、CoS を使用することで、複数のエントリーに対して確実にアカウントポリシーを適用および更新することができ、1 つのエントリーに複数のポリシーを適用することができます。 - サービス定義エントリーのクラスを作成します。CoS の管理エントリーは、アカウントポリシーの属性
acctPolicySubentry
です。この例では、CoS をディレクトリーツリー全体に適用します。# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=DefnCoS,dc=example,dc=com objectClass: top objectClass: ldapsubentry objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=TempltCoS,dc=example,dc=com cosAttribute: acctPolicySubentry default operational-default
19.9.3. パスワード失効後の特定期間のアカウントの無効化
dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: config alwaysrecordlogin: yes stateAttrName: non_existent_attribute altStateAttrName: passwordExpirationTime specattrname: acctPolicySubentry limitattrname: accountInactivityLimit
stateAttrName
パラメーターにダミー値を使用します。したがって、altStateAttrName
パラメーターで設定した passwordExpirationTime 属性のみが、アカウントの期限が切れるタイミングを算出するために使用されます。
lastLoginTime
属性に最後に成功したログインの時間を記録するため、以下を設定します。
dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config alwaysRecordLoginAttr: lastLoginTime
passwordExpirationTime
属性とaccountInactivityLimit
パラメーターの値に設定されている時間の合計が過去になった場合は、アカウントが自動的に無効になります。この設定では、ユーザーの passwordExpirationTime
属性と accountInactivityLimit
パラメーターの値の合計が、alwaysRecordLoginAttr
属性が最後に更新されてからの時間を超えた場合は、アカウントが自動的に無効になります。
19.9.4. ロックアウトポリシーを設定しないログイン時間の追跡
lastLoginTime
属性をユーザーエントリーに追加するために使用されますが、他のポリシールールを設定する必要はありません。
- アカウントポリシープラグインを有効にします。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Account Policy Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
- nsslapd-pluginarg0 属性を、プラグイン設定エントリーを参照するように設定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Account Policy Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginarg0 nsslapd-pluginarg0: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
- ログイン時間を記録するプラグイン設定エントリーを作成します。
- すべてのエントリーにログイン時間が記録されるように、
alwaysRecordLogin
の値を yes に設定します。 lastLoginTime
属性をアカウントポリシー (stateattrname
) に使用する属性として設定します。- アカウントポリシーを適用するエントリーを表示するのに使用する属性を設定します (
acctPolicySubentry
)。 - 実際のタイムアウト期間 (秒単位) を設定するのに使用されるアカウントポリシーの属性を設定します (
accountInactivityLimit
)。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: config alwaysRecordLogin: yes stateattrname: lastLoginTime altstateattrname: createTimestamp specattrname: acctPolicySubentry limitattrname: accountInactivityLimit - サーバーを再起動して、新しいプラグイン設定を読み込みます。
# systemctl start dirsrv.target
19.9.5. Inactive アカウントのロックの解除
lastLoginTime
属性をリセットして再度アクティブにできます。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=jsmith,ou=people,dc=example,dc=com changetype: modify replace: lastLoginTime lastLoginTime: 20160610080000Z
lastLoginTime
は、GMT/UTC 時間(Zulu タイムゾーン)で設定され、タイムスタンプに Z
が付加されます。
19.10. アカウントロックアウト属性の複製
passwordRetryCount
retryCountResetTime
accountUnlockTime
19.10.1. アカウントロックアウトおよびレプリケーションの管理
- パスワードポリシーはデータマスターで実施されます。
- アカウントロックアウトは、レプリケーションに参加するすべてのサーバーに適用されます。
passwordMinAge
およびpasswordMaxAge
passwordExp
passwordWarning
- パスワードの有効期限が迫っていることを示すサーバーからの警告は、すべてのレプリカで発行されます。この情報は、各サーバーにローカルに保存されるため、ユーザーが複数のレプリカにバインドされた場合は、同じ警告が複数回発行されます。また、ユーザーがパスワードを変更した場合は、その情報がレプリカに反映されるまでに時間がかかることがあります。ユーザーがパスワードを変更してすぐに再バインドすると、レプリカが変更を登録するまでバインドに失敗することがあります。
- サプライヤーやレプリカなど、すべてのサーバーで同じバインド動作が発生する必要があります。各サーバーで同じパスワードポリシー設定情報を作成してください。
- アカウントロックアウトカウンターは、マルチマスター環境で期待どおりに機能しない可能性があります。アカウントのロックアウトカウンターは、デフォルトでは複製されません (ただし、設定は可能です)。アカウントのロックアウト属性がまったく複製されない場合、あるユーザーがあるサーバーからロックアウトされていても、別のサーバーには正常にバインドできる可能性があります (または、あるサーバーではロックが解除されていても、別のサーバーではブロックされている場合もあります)。アカウントロックアウト属性が複製されると、アカウントのロックアウトの変更と、その変更が他のサーバーに伝播されるときにラグが発生することがあります。これはレプリケーションのスケジュールにより異なります。
- レプリケーション用に作成されるエントリー (例: サーバーアイデンティティー) には有効期限のないパスワードが必要です。これらの特別なユーザーに有効期限のないパスワードがあることを確認するには、エントリーに
passwordExpirationTime
属性を追加し、その値を 20380119031407Z 有効な範囲内に) 指定します。
alwaysRecordLogin
パラメーターが yes に設定されている場合、lastLoginTime
属性の値はマスターと読み取り専用レプリカで異なる場合があります。たとえば、ユーザーが読み取り専用のレプリカにログインすると、lastLoginTime
属性はローカルに更新されますが、値はマスターサーバーに複製されません。
19.10.2. パスワードポリシー属性を複製する Directory Server の設定
passwordIsGlobalPolicy
属性で、コンシューマーがパスワードポリシーの操作属性を受け入れるようにします。
passwordIsGlobalPolicy
設定属性を変更します。
# ldapmodify -D "cn=Directory Manager" -W -x -h consumer1.example.com dn: cn=config changetype: modify replace: passwordIsGlobalPolicy passwordIsGlobalPolicy: on
passwordRetryCount
、retryCountResetTime
、および accountUnlockTime
が複製されます。複製された属性で属性を含めるには、他の設定は必要ありません。
19.10.3. パスワードポリシー属性に対する一部レプリケーションの設定
passwordIsGlobalPolicy
属性を設定すると、コンシューマーがそれらの属性への更新を受け取ることができるように、レプリケーションのコンシューマーに影響します。パスワードポリシー属性がサプライヤーによって実際に複製されるかどうかを制御するには、特定のエントリー属性が複製されるものを制御する一部レプリケーションを使用します。
passwordIsGlobalPolicy
属性が off に設定されているため、パスワードポリシー属性を複製する必要がない場合は、一部レプリケーション (「一部レプリケーションを使用した属性のサブセットの複製」で説明) を使用してサプライヤーでレプリケーションを強制し、それらの属性をレプリカ合意から明確に除外します。
- 「レプリカ合意の作成」 で説明したようにサプライヤーにレプリカ合意を設定する場合は、Enable Fractional Replication チェックボックスを選択します。
- デフォルトでは、すべての属性が Replicated 属性 ボックスに一覧表示されます。
passwordRetryCount
、retryCountResetTime
、およびaccountUnlockTime
パラメーターを選択し、矢印ボタンをクリックして Do Not Replicate ボックスに移動します。 - レプリカ合意の設定を終了します。
19.11. 異なるタイプのバインドの有効化
19.11.1. セキュアなバインドの要求
nsslapd-require-secure-binds
属性が有効にになっている場合は、レプリカ合意、同期合意、およびチェーン設定がセキュアな接続を指定するようにしてください。それ以外の場合、これらの操作は失敗します。
nsslapd-require-secure-binds
属性を cn=config エントリーに追加します。# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-require-secure-binds nsslapd-require-secure-binds: on
- サービスを再起動します。
# systemctl restart dirsrv.target
19.11.2. 匿名バインドの無効化
rootdse
により、匿名検索および root DSE 自体への読み取りアクセスが許可されますが、他のすべてのディレクトリーエントリーへのアクセスを制限します。
nsslapd-allow-anonymous-access
属性を cn=config エントリーに追加します。# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-allow-anonymous-access nsslapd-allow-anonymous-access: off
- サービスを再起動します。
# systemctl restart dirsrv.target
19.11.3. 認証されていないバインドの許可
# ldapsearch -w "" -p 389 -h server.example.com -b "dc=example,dc=com" \ -s sub -x "(objectclass=*)" ldap_bind: Server is unwilling to perform (53) additional info: Unauthenticated binds are not allowed
nsslapd-allow-unauthenticated-binds
を on に設定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config changetype: modify replace: nsslapd-allow-unauthenticated-binds nsslapd-allow-unauthenticated-binds: on
19.11.4. 自動バインドの設定
19.11.4.1. Autobind および LDAPI の概要
- Unix ユーザーが 1 つのユーザーエントリーに一致した場合はユーザーエントリー
- Unix ユーザーが rootの場合は Directory Manager(または
nsslapd-ldapimaprootdn
で定義されたスーパーユーザー)
図19.1 自動バインド接続パス
gidNumber=gid+uidNumberuid, autobindsuffix
19.11.4.2. 自動バインドの設定
root
を Directory Manager にマップすることもできます。
- ldapmodify を実行して Directory Server 設定を更新します。
#ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config changetype: modify
- autobind を有効にします。
replace: nsslapd-ldapiautobind nsslapd-ldapiautobind: on
- ユーザーエントリーをマッピングするには、以下の 4 つの属性を追加します。
nsslapd-ldapimaptoentries
エントリーマッピングを有効にするには、以下を実行します。nsslapd-ldapiuidnumbertype
Directory Server 属性を Unix UID 番号にマッピングするように設定するには、nsslapd-ldapigidnumbertype
Unix グループ ID 番号にマップする Directory Server 属性を設定します。nsslapd-ldapientrysearchbase
Directory Server ユーザーエントリーの検索に使用する検索ベースを設定します。
add: nsslapd-ldapimaptoentries nsslapd-ldapimaptoentries: on - add: nsslapd-ldapiuidnumbertype nsslapd-ldapiuidnumbertype: uidNumber - add: nsslapd-ldapigidnumbertype nsslapd-ldapigidnumbertype: gidNumber - add: nsslapd-ldapientrysearchbase nsslapd-ldapientrysearchbase: ou=people,dc=example,dc=com
root
エントリーを Directory Manager にマッピングするには、nsslapd-ldapimaprootdn
属性を追加します。add: nsslapd-ldapimaprootdn nsslapd-ldapimaprootdn: cn=Directory Manager
- サーバーを再起動して、新しい設定を適用します。
# systemctl restart dirsrv@instance
19.12. パススルー認証の使用
図19.2 簡易的な PAM パススルー認証プロセス
- 設定 Directory Server(認証ディレクトリー)がマシン A にインストールされています。設定ディレクトリーには、設定データベースと接尾辞 o=NetscapeRoot が常に含まれます。この例では、サーバー名は configdir.example.com です。
- ユーザー Directory Server (PTA ディレクトリー) がマシン B にインストールされます。ユーザーディレクトリーは、dc=example,dc=com などのルート接尾辞を保存します。この例では、サーバー名は userdir.example.com です。
- ユーザーディレクトリーがマシン B に設定されている場合、setup スクリプトはマシン A の設定ディレクトリーの LDAP URL を要求します。
- setup プログラムは PTA プラグインを有効にし、設定ディレクトリー LDAP URL を使用するように設定します。このエントリーには、設定ディレクトリーの LDAP URL が含まれます。以下に例を示します。
dn: cn=Pass Through Authentication,cn=plugins, ... nsslapd-pluginEnabled: on nsslapd-pluginarg0: ldap://configdir.example.com/o=NetscapeRoot ...
ユーザーディレクトリーは、o=NetscapeRoot が含まれる DN を持つエントリーのすべてのバインド要求を設定ディレクトリー configdir.example.com に送信するように設定されるようになりました。 - インストールが完了すると、admin ユーザーはユーザーディレクトリーへの接続を試み、ユーザーの追加を開始します。
- 設定プログラムは、admin ユーザーのエントリーを uid=admin,ou=TopologyManagement,o=NetscapeRoot としてディレクトリーに追加します。そのため、ユーザーディレクトリーは PTA プラグイン設定で定義されている設定ディレクトリーにバインド要求を渡します。
- 設定ディレクトリーは、ユーザーの認証情報を認証し、情報をユーザーディレクトリーに送信します。
- ユーザーディレクトリーを使用すると、admin ユーザーがバインドできるようになります。
19.12.1. PTA プラグインの構文
- nsslapd-pluginEnabled: プラグインが有効かどうかを設定します。この属性の値は オンまたはオフに することができます。
- nsslapd-pluginarg 0: 設定ディレクトリーを参照します。この属性の値は、バインド要求を渡すサーバーおよび接尾辞の LDAP URL で、オプションのパラメーターである maxconns、maxops、timeout、ldver、connlifetime、startTLS です。
nsslapd-pluginarg
属性接尾辞を 1 つずつ増やすことで、いくつかの認証ディレクトリーまたはサブツリーを指定できます。以下に例を示します。
nsslapd-pluginarg0: LDAP URL for the first server nsslapd-pluginarg1: LDAP URL for the second server nsslapd-pluginarg2: LDAP URL for the third server ...
変数 | 定義 | ||
---|---|---|---|
state | プラグインを有効または無効にするかどうかを定義します。使用できる値は on または off です。 | ||
ldap|ldaps | 2 つの Directory Server 間の通信に TLS を使用するかどうかを定義します。詳細は、「セキュアな接続を使用するようにサーバーを設定」を参照してください。 | ||
authDS | 認証ディレクトリーのホスト名。Directory Server のポート番号は、コロンとポート番号を追加して指定できます。たとえば、ldap://dirserver.example.com:389/ です。ポート番号が指定されていない場合、PTA サーバーは標準ポートのいずれかを使用して接続を試みます。
| ||
subtree | パススルーサブツリー。PTA Directory Server は、このサブツリーに DN を持つすべてのクライアントから、認証する Directory Server にバインド要求を渡します。詳細は、「パススルーサブツリーの指定」を参照してください。このサブツリーは、このサーバーに存在させることはできません。o=NetscapeRoot のバインド要求を設定ディレクトリーに渡すには、サブツリー o=NetscapeRoot がサーバーに存在しません。 | ||
maxconns | 任意。PTA ディレクトリーの最大接続数は、認証ディレクトリーに対して同時に開くことができます。デフォルトは 3 です。詳細は、「オプションパラメーターの設定」を参照してください。 | ||
maxops | 任意。PTA ディレクトリーは単一接続内の認証ディレクトリーに送信できる同時操作の最大数 (通常はバインド要求)。デフォルトは 5 です。詳細は、「オプションパラメーターの設定」を参照してください。 | ||
timeout | 任意。PTA ディレクトリーが、認証用ディレクトリーサーバーからの応答を待つ時間を秒単位で指定します。このタイムアウトを超えると、サーバーはエラーをクライアントに返します。デフォルトは 300 秒 (5 分) です。ゼロ (0) を指定すると、時間制限をかけないことを示します。詳細は、「オプションパラメーターの設定」を参照してください。 | ||
ldver | 任意。認証用ディレクトリーへの接続に使用される LDAP プロトコルのバージョン。Directory Server は LDAP バージョン 2 および 3 をサポートします。デフォルトはバージョン 3 です。Red Hat は、古くなり、非推奨になる LDAPv2 を使用 しない ことを強く推奨します。詳細は、「オプションパラメーターの設定」を参照してください。 | ||
connlifetime | 任意。接続を使用できる制限時間を秒単位で指定します。この時間が経過した後にクライアントからバインド要求が開始すると、サーバーは接続を閉じ、認証するディレクトリーへの新しい接続を開きます。バインド要求が開始し、ディレクトリーが接続寿命を超えたと判断しない限り、サーバーは接続を閉じません。このオプションを指定しない場合、または 1 つのホストのみが記載されている場合は、接続の有効期間は実行されません。2 つ以上のホストがリストされている場合、デフォルトは 300 秒 (5 分)です。詳細は、「オプションパラメーターの設定」を参照してください。 | ||
startTLS |
オプション。認証用ディレクトリーへの接続に Start TLS を使用するかどうかを示すフラグ。Start TLS は標準ポート上でセキュアな接続を確立するため、LDAPS の代わりに LDAP を使用して接続するのに便利です。TLS サーバーと CA 証明書の両方がサーバーで使用できる必要があります。
デフォルトは 0 (off) です。Start TLS を有効にするには 、1 に設定します。TLS を使用するには、LDAP URL は ldaps : ではなく ldap: を使用する必要があります。
詳細は、「オプションパラメーターの設定」を参照してください。
|
19.12.2. PTA プラグインの設定
- ldapmodify コマンドを使用して cn=Pass Through Authentication,cn=plugins,cn=config を変更します。
- Directory Server を再起動します。
19.12.2.1. セキュアな接続を使用するようにサーバーを設定
nsslapd-pluginarg0: ldaps://ldap.example.com:636/o=NetscapeRoot
19.12.2.2. 認証する Directory Server の指定
- ldapmodify は PTA プラグインエントリーを編集します。
ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Pass Through Authentication,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginarg0 nsslapd-pluginarg0: ldap://dirserver.example.com/o=NetscapeRoot
必要に応じて、ポート番号を含めます。ポート番号が指定されていない場合、PTA Directory Server は ldap:// の標準ポート (389) または ldaps:// のセキュアなポート (636) を使用して接続を試みます。PTA Directory Server と認証する Directory Server との間の接続が破損するか、接続を開始できない場合は、PTA Directory Server が、指定された次のサーバー (存在する場合) に要求を送信します。最初の Directory Server が利用できない場合にフェイルオーバーを提供するために、必要に応じて認証する複数の Directory Server を指定できます。認証するすべての Directory Server がnsslapd-pluginarg0
属性に設定されます。認証する複数の Directory Server は、以下の形式で、スペース区切りの host:port ペアの一覧で記述されます。ldap|ldaps://host1:port1 host2:port2/subtree
- サービスを再起動します。
systemctl restart dirsrv@instance
19.12.2.3. パススルーサブツリーの指定
- ldapmodify コマンドを使用して、LDIF ファイルをディレクトリーにインポートします。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Pass Through Authentication,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginarg0 nsslapd-pluginarg0: ldap://dirserver.example.com/o=NetscapeRoot
この構文の変数コンポーネントの詳細は、表19.5「PTA プラグインのパラメーター」を参照してください。 - サービスを再起動します。
# systemctl restart dirsrv@instance
19.12.2.4. オプションパラメーターの設定
ldap|ldaps://authDS/subtree maxconns, maxops, timeout, ldver, connlifetime, startTLS
- PTA Directory Server が認証ディレクトリーに対して同時に開くことができる最大の接続数で、PTA の構文では maxconns で表されます。デフォルト値は 3 です。
- PTA Directory Server が単一の接続内の認証する Directory Server に同時に送信できるバインド要求の最大数。PTA 構文では、このパラメーターは maxops です。デフォルト値は 5 です。
- PTA Directory Server が認証する Directory Server からの応答を待つ時間制限。PTA 構文では、このパラメーターは timeout です。デフォルト値は 300 秒 (5 分) です。
- 認証する Directory Server への接続に使用する PTA Directory Server の LDAP プロトコルのバージョン。PTA 構文では、このパラメーターは ldver です。デフォルトは LDAPv3 です。
- 接続を使用できる制限時間を秒単位で指定します。この時間を過ぎてからクライアントがバインドリクエストを開始すると、そのサーバーは接続を閉じ、認証する Directory Server への新しい接続を開きます。バインド要求が開始し、サーバーがタイムアウトを超えたかどうかを判別しない限り、サーバーは接続を閉じません。このオプションが指定されていない場合や、認証する Directory Server が authDS パラメーターに記載されている場合に限り、時間制限が適用されません。2 つ以上のホストがリストされている場合、デフォルトは 300 秒 (5 分)です。PTA 構文では、このパラメーターは connlifetime になります。
- 接続に Start TLS を使用するかどうか。TLS は、標準の LDAP ポートでセキュアな接続を作成します。Start TLS では、サーバーおよび CA 証明書がインストールされている必要がありますが、TLS で実行する必要はありません。デフォルトは 0 で、Start TLS がオフになっていることを意味します。Start TLS を有効にするには 、1 に設定します。TLS を使用するには、LDAP URL は ldaps : ではなく ldap: を使用する必要があります。
- ldapmodify を使用してプラグインエントリーを編集します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Pass Through Authentication,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginarg0 nsslapd-pluginarg0: ldap://dirserver.example.com/o=NetscapeRoot 3,5,300,3,300,0
(この例では、各オプションのパラメーターはデフォルト値に設定されます。) subtree パラメーターと任意のパラメーターの間にスペースがあることを確認してください。注記これらのパラメーターは任意ですが、いずれかのパラメーターが定義されている場合は、デフォルト値を使用していてもすべてのパラメーターを定義する必要があります。 - サービスを再起動します。
# systemctl restart dirsrv@instance
19.12.3. PTA プラグイン構文の例
dse.ldif
ファイルの PTA プラグイン構文の以下の例を説明します。
19.12.3.1. Directory Server と 1 つのサブツリーの指定
dn: cn=Pass Through Authentication,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0: ldap://configdir.example.com/o=NetscapeRoot ...
19.12.3.2. 複数の認証用 Directory Server の指定
nsslapd-pluginarg0
属性に設定されます。認証する複数の Directory Server は、host:port ペアの空白区切りリストに一覧表示されます。以下に例を示します。
dn: cn=Pass Through Authentication,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0: ldap://configdir.example.com:389 config2dir.example.com:1389/o=NetscapeRoot ...
nsslapd-pluginarg0
属性は、認証する Directory Server を設定します。追加の nsslapd-pluginargN
属性は、使用する PTA プラグインの追加 接尾辞 を設定できますが、追加の ホスト ではありません。
19.12.3.3. 1 つの Directory Server と複数のサブツリーを指定
dn: cn=Pass Through Authentication,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0: ldap://configdir.example.com/o=NetscapeRoot nsslapd-pluginarg1: ldap://configdir.example.com/dc=example,dc=com ...
19.12.3.4. デフォルト以外のパラメーター値の使用
dn: cn=Pass Through Authentication,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0: ldap://configdir.example.com/o=NetscapeRoot 10,5,300,3,300,1 ...
19.12.3.5. 認証する異なる Directory Server の異なる任意のパラメーターおよびサブツリーの指定
dn: cn=Pass Through Authentication,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0:ldap://configdir.example.com/o=NetscapeRoot 10,15,30,3,600,0 nsslapd-pluginarg1:ldap://config2dir.example.com/dc=example,dc=com 7,7,300,3,300,1 ...
19.13. 認証に Active Directory 形式のユーザー名の使用
uid=user_name,ou=People,dc=example,dc=com
などのユーザーの識別名 (DN) を指定して認証する必要があります。ただし、DN は記憶しにくくなります。AD DN プラグインを有効にして設定する場合には、DN ではなく user_name
や user_name@domain
などの Active Directory 形式のユーザー名を使用できます。
example.com
をデフォルトドメインとして使用するようにプラグインを有効にして設定するには、以下を行います。
- cn=addn,cn=plugins,cn=config プラグインエントリーを追加し、デフォルトドメインを設定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=addn,cn=plugins,cn=config changetype: add objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: addn nsslapd-pluginPath: libaddn-plugin nsslapd-pluginInitfunc: addn_init nsslapd-pluginType: preoperation nsslapd-pluginEnabled: on nsslapd-pluginId: addn nsslapd-pluginVendor: 389 Project nsslapd-pluginVersion: 1.3.6.0 nsslapd-pluginDescription: Allow AD DN style bind names to LDAP addn_default_domain: example.com
プラグインエントリーで必要なaddn_default_domain
パラメーターにより、デフォルトのドメインが設定されます。認証時に指定されたユーザー名にドメイン名が含まれていない場合、プラグインはこのドメインを追加します。 - デフォルトドメインの設定エントリーを追加します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=example.com,cn=addn,cn=plugins,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: example.com addn_base: ou=People,dc=example,dc=com addn_filter: (&(objectClass=account)(uid=%s))
この例で使用されるパラメーターの詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 の説明を参照してください。警告デフォルトドメインに、少なくとも設定エントリーを追加する必要があります。エントリーが見つからないと、Directory Server は起動できません。 - 必要に応じて、前のステップで説明したように、追加のドメイン設定を作成して、複数のドメイン名をサポートすることができます。各ドメイン設定は、異なる検索ベースおよびフィルターを使用できます。
- Directory Server インスタンスを再起動します。
# systemctl restart dirsrv@instance_name
19.14. パススルー認証での PAM の使用
図19.3 PAM パススルー認証プロセス
19.14.1. PAM パススルー認証設定オプション
- PAM パススルー認証プラグインで制御される接尾辞です。ここでは、除外する接尾辞および含める接尾辞と、欠落した接尾辞の処理方法を説明します。
- 認証設定のターゲットである、設定された接尾辞内の個々のエントリー。デフォルトでは、接尾辞内のすべてのエントリーが認証スコープに含まれますが、複数の異なる PAM パススルー認証プラグインインスタンスを設定し、異なるユーザーに異なるプラグイン設定を適用することが可能です。
- PAM 属性マッピング。Directory Server に提示された認証情報は、何らかの方法で LDAP エントリーにマッピングされ、さらに PAM サービスの認証情報に戻される必要があります。これは、マッピングメソッドを定義し、任意で認証情報と一致させるために使用する LDAP 属性を定義します。
- TLS 接続の使用や、使用する PAM サービス、および PAM 認証に失敗した場合の LDAP 認証へのフォールバックなど、一般的な設定。
pamFilter
属性を使用して、プラグインで使用する特定のエントリーを検索するよう LDAP フィルターを設定することで、ユーザーエントリーのサブセットに適用できます。
19.14.1.1. PAMPTA のターゲットとなるサフィックスの指定
pamExcludeSuffix
属性は接尾辞を除外します。デフォルトでは、設定サブツリー (cn=config) のみが除外されます。別の方法では、PAM PTA プラグインは pamIncludeSuffix
属性の接尾辞に適用することもできます。これらの属性はいずれも多値で構成されます。
pamExcludeSuffix: cn=config pamExcludeSuffix: o=NetscapeRoot
pamIncludeSuffix
を使用すると、指定した接尾辞のみが含まれ、その他は自動的に除外されます。この属性は多値であるため、接尾辞を明示的に一覧表示することで、PAM 評価に複数の接尾辞を追加できます。
pamIncludeSuffix: ou=Engineering,dc=example,dc=com pamIncludeSuffix: ou=QE,dc=example,dc=com
pamMissingSuffix
属性は、指定された接尾辞 (include または exclude) が存在しない場合に失敗を処理する方法をサーバーに指示します。IGNORE に設定すると、接尾辞が存在しない場合は、プラグインはその接尾辞を省略し、次の試行を試みます。
pamMissingSuffix: IGNORE pamIncludeSuffix: ou=Engineering,dc=example,dc=com pamIncludeSuffix: ou=Not Real,dc=example,dc=com
19.14.1.2. 異なるエントリーへの異なる PAM パススルー認証設定の適用
pamFilter
属性で LDAP フィルターを指定することができます。これは、PAM パススルー認証ポリシーを適用する接尾辞内の特定のエントリーを識別します。
19.14.1.3. PAM PTA マッピングの設定
pamIDMapMethod: RDN ENTRY DN
マッピング | 説明 |
---|---|
RDN | このメソッドは、バインド DN の左端にある RDN から値を使用します。このメソッドのマッピングは、Directory Server で定義されます。指定がない場合は、これがデフォルトのマッピングメソッドになります。 |
ENTRY | このメソッドは、バインド DN エントリーのユーザー定義の属性から PAM アイデンティティーの値をプルします。identity 属性は pamIDAttr 属性で定義されます。例: pamIDAttr: customPamUid |
DN | このメソッドは、バインド DN からの完全な識別名を使用します。このメソッドのマッピングは、Directory Server で定義されます。 |
19.14.1.4. 汎用 PAM PTA 設定の設定
- PAM (pamService) に送信するサービス名。これは、
/etc/pam.d
で使用する設定ファイルの名前です。 - セキュアな接続 (pamSecure) を必要とするかどうか。
- PAM 認証に失敗した場合の LDAP 認証にフォールバックするかどうか (pamFallback)
pamFallback: false pamSecure: false pamService: ldapserver
19.14.2. PAM パススルー認証の設定
pamFilter
属性を使用して、プラグインで使用する特定のエントリーを検索するよう LDAP フィルターを設定することで、ユーザーエントリーのサブセットに適用できます。
- PAM サービスが完全に設定されていることを確認してください。
- pam_fprintd.so モジュールを PAM 設定ファイルから削除します。重要pam_fprintd.so モジュールは、PAM パススルー認証プラグイン設定の
pamService
属性によって参照される設定ファイルにすることはできません。PAM の fprintd モジュールを使用すると、Directory Server は最大ファイル記述子制限に到達し、Directory Server プロセスが中止する可能性があります。 - プラグインを有効にします。デフォルトでは無効になっています。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=PAM Pass-Through Auth Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
- PAM パススルー認証プラグイン設定エントリーを作成します。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=Admin PAM PTA Config,cn=PAM Pass-Through Auth Plugin,cn=plugins,cn=config cn: AD PAM PTA Config - PAM プラグインに使用できる属性を追加します。利用可能な属性は 「PAM パススルー認証設定オプション」 に表示され、例19.2「PAM パススルー認証設定エントリーの例」 にはサンプルエントリーがあります。
- サーバーを再起動して、新しいプラグイン設定を読み込みます。
# systemctl restart dirsrv.target
例19.2 PAM パススルー認証設定エントリーの例
dn: cn=Admin PAM PTA Config,cn=PAM Pass Through Auth,cn=plugins,cn=config objectclass: top objectclass: pamConfig objectClass: nsSlapdPlugin objectClass: extensibleObject cn: Admin PAM PTA Config pamMissingSuffix: ALLOWpamExcludeSuffix: cn=config
pamExcludeSuffix: o=NetscapeRoot
pamIDMapMethod: RDN ENTRY
pamIDAttr: customPamUid
pamFilter: (manager=uid=bjensen,ou=people,dc=example,dc=com)
pamFallback: FALSEpamSecure: TRUE
pamService: ldapserver
19.14.3. Active Directory をバックエンドとして PAM パススルー認証の使用
図19.4 SSSD による PAM パススルー認証
- Active Directory サーバーを ID プロバイダーの 1 つとして使用するように SSSD を設定します。この設定は、『Windows 統合ガイド』 の 『SSSD で Active Directory を ID プロバイダーとして使用』 セクションで説明しています。
- PAM パススルー認証プラグインを有効にします。これはデフォルトで無効にされています。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=PAM Pass-Through Auth Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on
- PAM パススルー認証プラグイン設定エントリーを作成します。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=AD PAM PTA Config,cn=PAM Pass-Through Auth Plugin,cn=plugins,cn=config cn: AD PAM PTA Config pamService
属性を設定して、SSSD が管理する PAM 設定ファイルを参照します。デフォルトでは、これは/etc/pam.d/system-auth
です。pamService: system-auth
重要pam_fprintd.so モジュールは、PAM パススルー認証プラグイン設定のpamService
属性によって参照される設定ファイルにすることはできません。PAM の fprintd モジュールを使用すると、Directory Server は最大ファイル記述子制限に到達し、Directory Server プロセスが中止する可能性があります。- ID マップメソッドおよび属性を設定します。Directory Server 環境に応じて、これを行う方法は複数あります。最も簡単な方法は、RDN マップメソッドを使用して、
uid
属性(または正しい命名属性)を使用して Directory Server ユーザーを Active Directory ユーザー(Active Directory はアイデンティティープロバイダー)に戻します。pamIDMapMethod: RDN
同様に、samAccountName
属性を使用して ENTRY マップメソッドで実行できます。Directory Server のユーザーアカウントが、Active Directory のユーザーアカウントのuid
値と一致するsamAccountName
で作成されると、マッピングは成功します。pamIDMapMethod: ENTRY pamIDAttr: samAccountName
Windows 同期が設定されている場合、ENTRY メソッドはntUserDomainId
属性で使用できます。Directory Server および Active Directory ユーザーアカウントは、その属性値に基づいてすでに同期されているため、PAM マッピングは成功します。pamIDMapMethod: ENTRY pamIDAttr: ntUserDomainId
- サーバーを再起動して、新しいプラグイン設定を読み込みます。
# systemctl restart dirsrv.target
19.15. ユーザーおよびロールの手動による非アクティブ化
nsAccountLock
を使用して非アクティベートされます。エントリーに値が true の nsAccountLock
属性が含まれる場合、サーバーはバインドを拒否します。
19.15.1. コンソールを使用したアクティブユーザーとロールの表示
- 非アクティブ化。
19.15.2. コンソールを使用したユーザーおよびロールのアクティベートおよび非アクティブ化
- Directory タブを選択します。
- 左側のナビゲーションペインでナビゲーションツリーを参照し、エントリーをダブルクリックします。Edit Entry ダイアログボックスが表示されます。
- 左側のペインで アカウント をクリックします。右側のペインには、ロールまたはユーザーがアクティブになっていると記載されています。非アクティブ ボタンをクリックしてユーザーまたはロール(または アクティベート )を非アクティブにして、エントリーを再度有効にします。
- OK をクリックします。
19.15.3. コマンドラインを使用したアクティブユーザーおよびロールの表示
# ns-accountstatus.pl -D "cn=Directory Manager" -w password -I "uid=jsmith,ou=people,dc=example,dc=com"
uid=bjensen,ou=people,dc=example,dc=com activated.
-V
オプションを追加して、より詳細な出力を取得します。
# ns-accountstatus.pl -D "cn=Directory Manager" -w password -I "uid=jsmith,ou=people,dc=example,dc=com"
Entry: uid=jsmith,ou=People,dc=example,dc=com
Entry Creation Date: 20160204153140Z (02/04/2016 10:31:40)
Entry Modification Date: 20160205163904Z (02/05/2016 11:39:04)
Last Login Date: 20160205163905Z (02/05/2016 11:39:05)
Inactivity Limit: 2592000 seconds (30 days)
Time Until Inactive: 2591688 seconds (29 days, 23 hours, 54 minutes, 48 seconds)
Time Since Inactive: -
Entry State: activated
# ns-accountstatus.pl -D "cn=Directory Manager" -w password -I "uid=jsmith,ou=people,dc=example,dc=com"
Entry: uid=jsmith,ou=people,dc=example,dc=com
Entry Creation Date: 20160204153140Z (02/04/2016 10:31:40)
Entry Modification Date: 20160204160545Z (02/04/2016 11:05:45)
Last Login Date: 20160204160546Z (01/04/2016 11:05:46)
Inactivity Limit: 2592000 seconds (30 days)
Time Until Inactive: -
Time Since Inactivated: 85877 seconds (23 hours, 51 minutes, 17 seconds)
Entry State: inactivated (inactivity limit exceeded)
-I
オプションを使用してアカウントを指定する代わりに、- b
(search a database suffix)、- f
(フィルターを使用)、- s
(検索範囲)オプションを使用して検索を作成できます。さらに、- i
オプション(非アクティブアカウントのみを返す)または -g X オプション(次の X
秒で有効期限が切れるアカウントのみ)を使用して検索を改良できます。以下に例を示します。
# ns-accountstatus.pl -D "cn=Directory Manager" -w password -b "ou=people,dc=example,dc=com" -f "(uid=*)" -V -g 86400
Entry: uid=jsmith,ou=people,dc=example,dc=com
Entry Creation Date: 20160204153140Z (02/04/2016 10:31:40)
Entry Modification Date: 20160205163904Z (02/05/2016 11:39:04)
Last Login Date: 20160205163905Z (01/05/2016 11:39:05)
Inactivity Limit: 2592000 seconds (30 days)
Time Until Inactive: 979 seconds (16 minutes, 19 seconds)
Time Since Inactive: -
Entry State: activated
19.15.4. コマンドラインを使用したユーザーおよびロールの非アクティブ化およびアクティブ化
[root@server ~]# ns-inactivate.pl -Z instance_name -D Directory Manager -w secret -p 389 -h example.com -I "uid=jfrasier,ou=people,dc=example,dc=com"
# ns-activate.pl -Z instance_name -D Directory Manager -w secret -p 389 -h example.com -I "uid=jfrasier,ou=people,dc=example,dc=com"
第20章 サーバーおよびデータベースアクティビティーの監視
20.1. Directory Server ログファイルの種類
- 警告Directory Server がエラーログに書き込みに失敗した場合、サーバーはエラーメッセージを Syslog サービスに送信し、終了します。このログタイプは、デフォルトで有効になります。
20.2. ログファイルの表示
20.2.1. コマンドラインでログファイルの表示
# less /var/log/dirsrv/slapd-instance_name/access
# ldapsearch -D "cn=Directory Manager" -W -p 389 \ -h server.example.com -x -b "cn=config" -s base \ nsslapd-accesslog nsslapd-errorlog nsslapd-auditlog nsslapd-auditfaillog ... nsslapd-accesslog: /var/log/dirsrv/slapd-instance_name/access nsslapd-errorlog: /var/log/dirsrv/slapd-instance_name/errors nsslapd-auditlog: /var/log/dirsrv/slapd-instance_name/audit nsslapd-auditfaillog: /var/log/dirsrv/slapd-instance_name/audit-failure
20.2.2. コンソールを使用したログファイルの表示
- Directory Server コンソールを開きます。詳細は、「Directory Server コンソールを開く」 を参照してください。
- Status タブを選択します。
- Logs エントリーを展開し、表示するログを選択します。注記コンソールには、
Audit Fail
ログのログファイルビューアーが含まれていません。または、以下を行うことができます。- コマンドラインでこのログを表示します。「コマンドラインでログファイルの表示」 を参照してください。
Audit Fail エントリーを
ファイルに記録するように Directory Server を設定します。Audit
イベントと同じ
- 必要に応じて、以下の設定をログファイルビューアーに適用することができます。
- 表示するフィールドに行数 を設定します。
- Show only lines with the field(フィールドを含む )にフィルターを設定します。
- Select log フィールドでログを選択して、同じタイプの古いログファイルを表示します。
- Continuous refresh を選択して、新しいログエントリーを自動的に表示できるようにします。
20.3. ログファイルの設定
20.3.1. ログの有効化または無効化
Directory Server コンソールでのロギングの有効化または無効化
- Directory Server コンソールにログインします。
- Configuration タブを選択します。
- ナビゲーションツリーで Logs フォルダーを展開し、ログのフォルダーを選択して有効または無効にします。
- ロギングを有効または無効にするには、Enable Logging チェックボックスを選択します。
- ログが有効な場合は、提供されるフィールドに Directory Server がログインするために使用する完全パスおよびファイル名を入力します。デフォルトのパスは
/var/log/dirsrv/slapd-instance/
log_type です(例:/var/log/dirsrv/slapd-instance/access
)。
コマンドラインを使用したロギングの有効化または無効化
- アクセスログ:
nsslapd-accesslog-logging-enabled
- エラーログ:
nsslapd-errorlog-logging-enabled
- 監査ログ:
nsslapd-auditlog-logging-enabled
- 監査ログの失敗ログ:
nsslapd-auditfaillog-logging-enabled
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-auditlog-logging-enabled nsslapd-auditlog-logging-enabled: on
20.3.2. プラグイン固有のロギングの設定
20.3.3. 高解像度のログタイムスタンプの無効化
[27/May/2016:17:52:04.754335904 -0500] schemareload - Schema validation passed. [27/May/2016:17:52:04.894255328 -0500] schemareload - Schema reload task finished.
# ldapmodify -D "cn=Directory Manager" -W -x
dn: cn=config
changetype: modify
replace: nsslapd-logging-hr-timestamps-enabled
nsslapd-logging-hr-timestamps-enabled: off
[27/May/2016:17:52:04 -0500] schemareload - Schema validation passed. [27/May/2016:17:52:04 -0500] schemareload - Schema reload task finished.
20.3.4. ログファイルのローテーションポリシーの定義
- アクセスモード
- アクセスモードでは、新規に作成されたログファイルにファイル権限を設定します。
- アクセスログ:
nsslapd-accesslog-mode
- エラーログ:
nsslapd-errorlog-mode
- 監査ログ:
nsslapd-auditlog-mode
- 監査ログの失敗ログ:
nsslapd-auditfaillog-mode
- ログの最大数
- 保持するログファイルの最大数を設定します。ファイル数に達すると、Directory Server は新しいログファイルを作成する前に、最も古いログファイルを削除します。
- アクセスログ:
nsslapd-accesslog-maxlogsperdir
- エラーログ:
nsslapd-errorlog-maxlogsperdir
- 監査ログ:
nsslapd-auditlog-maxlogsperdir
- 監査ログの失敗ログ:
nsslapd-auditfaillog-maxlogsperdir
- 各ログのファイルサイズ
- ログファイルがローテーションされるまでの最大サイズをメガバイト単位で設定します。
- アクセスログ:
nsslapd-accesslog-maxlogsize
- エラーログ:
nsslapd-errorlog-maxlogsize
- 監査ログ:
nsslapd-auditlog-maxlogsize
- 監査ログの失敗ログ:
nsslapd-auditfaillog-maxlogsize
- 毎回ログの作成
- ログファイルの最大期間を設定します。
nsslapd-accesslog-logrotationtime
およびnsslapd-accesslog-logrotationtimeunit
nsslapd-errorlog-logrotationtime
およびnsslapd-errorlog-logrotationtimeunit
nsslapd-auditlog-logrotationtime
およびnsslapd-auditlog-logrotationtimeunit
nsslapd-auditfaillog-logrotationtime
およびnsslapd-auditfaillog-logrotationtimeunit
さらに、以下のパラメーターを使用してログファイルがローテーションされるまでの時間を設定することもできます。nsslapd-accesslog-logrotationsynchour
およびnsslapd-accesslog-logrotationsyncmin
nsslapd-errorlog-logrotationsynchour
およびnsslapd-errorlog-logrotationsyncmin
nsslapd-auditlog-logrotationsynchour
およびnsslapd-auditlog-logrotationsyncmin
nsslapd-auditfaillog-logrotationsynchour
およびnsslapd-auditfaillog-logrotationsyncmin
389-Directory/1.3.5.10 B2016.257.1817 server.example.com:389 (/etc/dirsrv/slapd-instance)
Directory Server コンソールでログファイルローテーションの設定
- Directory Server コンソールにログインします。
- Configuration タブを選択します。
- ナビゲーションツリーで、Logs フォルダーを展開し、設定を更新するログのフォルダーを選択します。
- 作成ポリシー エリアでロギング設定を設定します。以下に例を示します。
コマンドラインを使用したログファイルローテーションの設定
600
を設定して最大 2
を維持し、ログファイルのサイズを 100
MB または 5 日
ごとにローテーションするには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-errorlog-mode nsslapd-errorlog-mode: 600 - replace: nsslapd-errorlog-maxlogsperdir nsslapd-errorlog-maxlogsperdir: 2 - replace: nsslapd-errorlog-maxlogsize nsslapd-errorlog-maxlogsize: 100 - replace: nsslapd-errorlog-logrotationtime nsslapd-errorlog-logrotationtime: 5 - replace: nsslapd-errorlog-logrotationtimeunit nsslapd-errorlog-logrotationtimeunit: day
20.3.5. ログファイルの削除ポリシーの定義
Deletion Policy
を設定すると、アーカイブされた古いログファイルを自動的に削除します。
- ログサイズの合計
- すべてのアクセス、エラー、監査、または監査失敗ログファイルのサイズが設定された値を越えると、最も古いログファイルが自動的に削除されます。
- アクセスログ:
nsslapd-accesslog-logmaxdiskspace
- エラーログ:
nsslapd-errorlog-logmaxdiskspace
- 監査ログ:
nsslapd-auditlog-logmaxdiskspace
- 監査ログ:
nsslapd-auditfaillog-logmaxdiskspace
- 空きディスク領域が「より少ない」
- 空きディスク容量がこの値に達すると、最も古いアーカイブファイルが自動的に削除されます。
- アクセスログ:
nsslapd-accesslog-logminfreediskspace
- エラーログ:
nsslapd-errorlog-logminfreediskspace
- 監査ログ:
nsslapd-auditlog-logminfreediskspace
- 監査ログ:
nsslapd-auditfaillog-logminfreediskspace
- 指定した時間よりもファイルが古い場合
- ログファイルが設定された時間よりも古い場合は、これが自動的に削除されます。
- アクセスログ:
nsslapd-accesslog-logexpirationtime
およびnsslapd-accesslog-logexpirationtimeunit
- エラーログ:
nsslapd-errorlog-logminfreediskspace
およびnsslapd-errorlog-logexpirationtimeunit
- 監査ログ:
nsslapd-auditlog-logminfreediskspace
およびnsslapd-auditlog-logexpirationtimeunit
- 監査ログ:
nsslapd-auditfaillog-logminfreediskspace
およびnsslapd-auditfaillog-logexpirationtimeunit
Directory Server コンソールでのログ削除ポリシーの設定
- Directory Server コンソールにログインします。
- Configuration タブを選択します。
- ナビゲーションツリーで、Logs フォルダーを展開し、設定を更新するログのフォルダーを選択します。
- Deletion Policy エリアでロギング設定を設定します。以下に例を示します。
コマンドラインを使用したログ削除ポリシーの設定
500
MB 増加した場合に、最も古いアクセスログファイルを自動的に削除するには、次のように実行します。
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-accesslog-logmaxdiskspace nsslapd-accesslog-logmaxdiskspace: 500
20.3.6. 手動ログファイルローテーション
/var/log/dirsrv/slapd-instance
- サーバーをシャットダウンします。
# systemctl stop dirsrv.target instance
- 古いログファイルが今後の参照で利用できるように、ローテーションされるログファイルを移動するか名前を変更します。
- サービスを再起動します。
# systemctl restart dirsrv.target instance
20.3.7. ログレベルの設定
- アクセスログ:
nsslapd-accesslog-level
- エラーログ:
nsslapd-errorlog-level
Directory Server コンソールでのログレベルの設定
- Directory Server コンソールにログインします。
- Configuration タブを選択します。
- ナビゲーションツリーで、Logs フォルダーを展開し、設定を更新するログのフォルダーを選択します。
- Log Level エリアにログレベルを設定します。たとえば、エラーログファイルの場合、
コマンドラインを使用したログレベルの設定
nsslapd-errorlog-level
パラメーターを 96 (32 + 64) に設定します。
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-errorlog-level nsslapd-errorlog-level: 96
20.4. アクセスログ統計の取得
logconv.pl
スクリプトはアクセスログを解析し、サーバーで実行するさまざまなユーザーおよび操作に関するサマリー情報を返します。
# logconv.pl /relative/path/to/accessLog
# logconv.pl /var/log/dirsrv/slapd-instance/access*
logconv.pl
のさまざまなオプションは、man ページと 『設定、コマンド、およびファイルリファレンス』 で説明されています。
logconv.pl
は、アクセスログから一般的な使用状況を引き出すために、いくつかの異なる方法があります。
logconv.pl
が、総操作数、総接続数、各操作タイプごとのカウント、永続的な検索などの拡張操作のカウント、およびバインド情報のリストを表示します。
# logconv.pl /var/log/dirsrv/slapd-instance/access Access Log Analyzer 8.2 Command: logconv.pl /var/log/dirsrv/slapd-instance/access Processing 1 Access Log(s)... [001] /var/log/dirsrv/slapd-instance/access size (bytes): 77532 Total Log Lines Analysed: 527 Start of Logs: 14/Oct/2017:16:15:22.452909568 End of Logs: 14/Oct/2017:16:39:50.157790196 Processed Log Time: 0 Hours, 24 Minutes, 27.704877056 Seconds Restarts: 10 Secure Protocol Versions: - TLS1.2 client bound as uid=user_name,ou=people,o=example.com (11 connections) - TLS1.2 128-bit AES; client CN=CA Subsystem,O=example.com; issuer CN=Certificate Authority,O=example.com (11 connections) - TLS1.2 128-bit AES-GCM (2 connections) - TLS1.2 128-bit AES (3 connections) Peak Concurrent Connections: 38 Total Operations: 4771 Total Results: 4653 Overall Performance: 97.5% Total Connections: 249 (0.17/sec) (10.18/min) - LDAP Connections: 107 (0.07/sec) (4.37/min) - LDAPI Connections: 128 (0.09/sec) (5.23/min) - LDAPS Connections: 14 (0.01/sec) (0.57/min) - StartTLS Extended Ops: 2 (0.00/sec) (0.08/min) Searches: 2963 (2.02/sec) (121.13/min) Modifications: 649 (0.44/sec) (26.53/min) Adds: 785 (0.53/sec) (32.09/min) Deletes: 10 (0.01/sec) (0.41/min) Mod RDNs: 6 (0.00/sec) (0.25/min) Compares: 0 (0.00/sec) (0.00/min) Binds: 324 (0.22/sec) (13.25/min) Proxied Auth Operations: 0 Persistent Searches: 17 Internal Operations: 0 Entry Operations: 0 Extended Operations: 4 Abandoned Requests: 0 Smart Referrals Received: 0 VLV Operations: 30 VLV Unindexed Searches: 0 VLV Unindexed Components: 20 SORT Operations: 22 Entire Search Base Queries: 12 Paged Searches: 2 Unindexed Searches: 0 Unindexed Components: 149 FDs Taken: 249 FDs Returned: 212 Highest FD Taken: 107 Broken Pipes: 0 Connections Reset By Peer: 0 Resource Unavailable: 0 Max BER Size Exceeded: 0 Binds: 324 Unbinds: 155 --------------------------------- - LDAP v2 Binds: 41 - LDAP v3 Binds: 180 - AUTOBINDs(LDAPI): 103 - SSL Client Binds: 0 - Failed SSL Client Binds: 0 - SASL Binds: 134 - EXTERNAL: 114 - GSSAPI: 20 - Directory Manager Binds: 10 - Anonymous Binds: 1 Cleaning up temp files... Done.
b
) への接続に使用する DN 数と、サーバーによって返された合計接続コード (c
) を -bc
として渡します。
# logconv.pl -bc /var/log/dirsrv/slapd-instance/access ... ----- Total Connection Codes ----- U1 3 Cleanly Closed Connections B1 1 Bad Ber Tag Encountered ----- Top 20 Bind DN's ----- Number of Unique Bind DN's: 212 1801 cn=Directory Manager 1297 Anonymous Binds 311 uid=jsmith,ou=people... 87 uid=bjensen,ou=peopl... 85 uid=mreynolds,ou=peo... 69 uid=jrockford,ou=peo... 55 uid=sspencer,ou=peop... ...
-S
) 以降、特定の終了時間 (-E
) 以降、または範囲内からエントリーに制限することができます。開始時間と終了時間が設定されると、logconv.pl
が最初に指定の時間範囲を出力し、次にその期間の概要を出力します。
# logconv.pl -S "[01/Jul/2016:16:11:47.000000000 -0400]" -E "[01/Jul/2016:17:23:08.999999999 -0400]" /var/log/dirsrv/slapd-instance/access ... ----------- Access Log Output ------------ Start of Logs: 01/Jul/2016:16:11:47 End of Logs: 01/Jul/2016:17:23:08 ...
-M
) や 1 秒ごと (-m
) のカウントデータを出力することができます。この場合、データは時間単位で、指定した CSV 出力ファイルに出力されます。
# logconv.pl -m|-M outputFile accessLogFile
# logconv.pl -M /home/output/statsPerMin.txt /var/log/dirsrv/slapd-instance/access*
-M|-m
オプションは、-S
引数および -E
引数と共に使用することで、特定の期間内の分単位または秒単位のカウントを取得することもできます。
Time,time_t,Results,Search,Add,Mod,Modrdn,Delete,Abandon,Connections,SSL Conns,Bind,Anon Bind,Unbind,Unindexed
- CSV ファイルを開きます。
- Chart Type エリアで、チャートタイプを XY (Scatter) に設定します。
- サブタイプを行のみに設定します。
- X 値でソートするオプションを選択します。
- 他の画面のデフォルト (特に、データ系列を列で使用すること、最初の行と最初の列をラベルとして設定すること) を受け入れて、チャートを作成します。
20.5. シャットダウンのローカルディスクの監視
nsslapd-disk-monitoring
設定属性を使用して有効になります。これにより、特定の領域で利用可能なディスク領域をチェックするために 10 秒ごとにウェイクする監視スレッドが作成されます。
- 詳細なロギングは無効になっています。
- アクセスロギングおよびエラーロギングは無効になっています。
- ローテーション(アーカイブ)ログが削除されます。
nsslapd-disk-monitoring-logging-critical
)を設定してログディレクトリーを追加できます。
- ldapmodify を使用して、ディスク監視属性を追加します。少なくとも、
nsslapd-disk-monitoring
属性をオンにしてディスクの監視を有効にします。デフォルトのしきい値は 2MB です。これは、nsslapd-disk-monitoring-threshold
属性で設定できます(任意)。以下に例を示します。# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify add: nsslapd-disk-monitoring nsslapd-disk-monitoring: on - add: nsslapd-disk-monitoring-threshold nsslapd-disk-monitoring-threshold: 3000000 - add: nsslapd-disk-monitoring-grace-period nsslapd-disk-monitoring-grace-period: 20
- Directory Server を再起動して、新しい構成を読み込みます。
[root@server ~]# systemctl restart dirsrv.target
設定属性 | 詳細 |
---|---|
nsslapd-disk-monitoring | 有効にするディスクモニタリング。他の設定オプションで使用できるデフォルト値があるため、これは唯一の必須属性です。 |
nsslapd-disk-monitoring-grace-period | ディスク領域の制限の半分に達するとサーバーをシャットダウンする前に待機する猶予期間を設定します。これにより、状況に対応するための管理者の時間が提供されます。デフォルト値は 60(分)です。 |
nsslapd-disk-monitoring-logging-critical | ログディレクトリーがディスク領域の制限に設定された半方向ポイントをパスした場合に、サーバーをシャットダウンするかどうかを設定します。これにより、監視スレッドが監査ロギングを無効にしたり、ローテーションされたログファイルを削除したりできなくなります。 |
nsslapd-disk-monitoring-threshold | サーバーに十分なディスク領域があるかどうかを評価するために使用するディスク容量(バイト単位)を設定します。スペースがこのしきい値の半分になると、サーバーはシャットダウンプロセスを開始します。デフォルト値は 2000000(2MB)です。 |
20.6. サーバーアクティビティーの監視
20.6.1. Directory Server コンソールからのサーバーの監視
- Status タブを選択します。
- ナビゲーションツリーで Performance Counters を選択します。右側のペインの Status タブには、サーバーアクティビティーに関する現在の情報が表示されます。サーバーが現在実行していない場合は、このタブではパフォーマンスの監視情報は提供されません。
- Continuous チェックボックスを選択します。をクリックし、現在の表示を更新します。サーバーが表示する情報を継続的に更新するには、
フィールド | 詳細 |
---|---|
サーバーバージョン | 現在のサーバーバージョンを識別します。 |
サーバー上の起動時間 | サーバーが開始した日時。 |
サーバーの現在の時間 | サーバーの現在の日時。 |
リソース | 起動時の使用方法 | 1 分あたりの平均数 |
---|---|---|
接続 | サーバーの起動以降、このサーバーへの接続の合計数。 | サーバーの起動から 1 分あたりの平均接続数 |
操作開始 | サーバーの起動以降に開始された操作の合計数。操作には、検索、追加、変更などのサーバーアクションのクライアント要求が含まれます。多くの場合、接続ごとに複数の操作が開始されます。 | サーバーの起動から 1 分あたりの操作の平均。 |
完了した操作 | サーバーの起動以降、サーバーによって完了した操作の合計数。 | サーバーの起動から 1 分あたりの操作の平均。 |
クライアントに送信されるエントリー | サーバーの起動以降にクライアントに送信されるエントリーの合計数。エントリーは、検索要求の結果でクライアントに送信されます。 | サーバーの起動時に 1 分あたりにクライアントに送信されるエントリーの平均数。 |
クライアントに送信されるバイト | サーバーの起動以降にクライアントに送信される合計バイト数。 | サーバーの起動時に 1 分あたりにクライアントに送信される平均のバイト数。 |
リソース | 現在の合計 |
---|---|
アクティブなスレッド | リクエストの処理に使用される現在のアクティブなスレッドの数。追加のスレッドは、レプリケーションやチェーンなどの内部サーバータスクで作成できます。 |
開いている接続 | オープン接続の合計数。各接続は複数の操作のために考慮できるため、複数のスレッドがあります。 |
残りの利用可能な接続 | サーバーが同時に開くことのできる残りの接続の合計数。この数は、現在開いている接続の数と、サーバーが開くことのできる同時接続の合計数に基づいています。多くの場合、後者の値はオペレーティングシステムによって決定され、タスクで利用可能なファイル記述子の数で表示されます。 |
クライアントへの書き込みを待機するスレッド | クライアントへの書き込みを待機するスレッドの合計数。スレッドは、クライアントにデータ送信中にサーバーを一時停止する必要がある場合にすぐに書き込みできない場合があります。一時停止の理由には、低速なネットワーク、低速なクライアント、またはクライアントに送信される非常に多くの情報などがあります。 |
クライアントからの読み取りを待機するスレッド | クライアントから読み取りを待機するスレッドの合計数。サーバーがクライアントから要求を受信していった場合、スレッドはすぐに読み取らない場合があり、一部の理由でその要求の送信は停止します。通常、読み取りを待機するスレッドは、低速なネットワークまたはクライアントを示します。 |
使用中のデータベース | サーバーによってサービスされるデータベースの合計数。 |
テーブルヘッダー | 詳細 | ||
---|---|---|---|
開かれた時間 | 接続が最初に開かれたサーバー上の時間。 | ||
Started | このコネクションによって開始される操作の数。 | ||
完了 | この接続のためにサーバーが完了した操作の数。 | ||
バインド: | サーバーにバインドするためにクライアントによって使用される識別名。クライアントがサーバーに対して認証されていない場合、サーバーはこのフィールドで バインドされません。 | ||
読み取り/書き込み | サーバーが現在クライアントへの読み取りまたは書き込みアクセスに対してブロックされているかどうかを示します。以下の 2 つの値を使用できます。
|
テーブルヘッダー | 詳細 |
---|---|
Hits | ディスクに移動するのではなく、キャッシュからデータを取得することで、サーバーがリクエストを処理できる回数。 |
tries | サーバー起動後のデータベースアクセスの総数。 |
Ratio のヒット | キャッシュの比率は、キャッシュヒットの成功を試みます。この数を 100% にすると、より良い数値になります。 |
ページの読み取り | ディスクからキャッシュに読み取られるページ数。 |
ページが書き込まれる | キャッシュからディスクに書き込まれたページ数。 |
読み取り専用ページのエビクション | 新規ページのスペースを作成するために、キャッシュから破棄された読み取り専用ページの数。キャッシュから破棄されたページはディスクに書き込まれ、サーバーのパフォーマンスに影響する可能性があります。ページの数が小さいほどエビクトされます。 |
読み取り/書き込みページのエビクション | 新規ページのスペースを作成するために、キャッシュから破棄された読み取り/書き込みページの数。この値は、変更されていない読み取り書き込みページを破棄する点で、Pages Written Out とは異なります。キャッシュから破棄されたページはディスクに書き込まれ、サーバーのパフォーマンスに影響する可能性があります。ページのエビクト数が少ないほど、パフォーマンスが向上します。 |
20.6.2. コマンドラインでの Directory Server の監視
- 属性 filterobjectclass =* で検索します。
- 検索ベースの cn=monitor を使用します。サーバーの監視属性は cn=monitor エントリーにあります。
- 検索範囲 ベース を使用します。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -s base -b "cn=monitor" "(objectclass=*)"
属性 | 説明 | ||||||
---|---|---|---|---|---|---|---|
バージョン | ディレクトリーの現在のバージョン番号を指定します。 | ||||||
スレッド | リクエストの処理に使用される現在のアクティブなスレッドの数。追加のスレッドは、レプリケーションやチェーンなどの内部サーバータスクで作成できます。 | ||||||
connection:fd:opentime:opsinitiated:opscompleted:binddn:[rw] | オープン接続ごとに以下の概要情報を提供します(Directory Manager としてディレクトリーにバインドする場合にのみ利用可能)。
| ||||||
currentconnections | ディレクトリーで現在サービスにある接続の数を特定します。 | ||||||
totalconnections | 起動してからディレクトリーによって処理される接続の数を特定します。 | ||||||
dtablesize | は、ディレクトリーで利用可能なファイル記述子の数を表示します。各接続には、オープンインデックスごとに 1 つのファイル記述子、ログファイル管理用のファイル、および ns-slapd 自体に 1 つ必要です。基本的に、この値は、ディレクトリーが提供できる追加の同時接続の数を示します。ファイル記述子の詳細は、オペレーティングシステムのドキュメントを参照してください。 | ||||||
readwaiters | クライアントからデータの読み取りを待機するスレッドの数を特定します。 | ||||||
opsinitiated | 起動後にサーバーが開始した操作の数を特定します。 | ||||||
opscompleted | 起動してからサーバーが完了した操作の数を特定します。 | ||||||
entriessent | サーバー起動以降にクライアントに送信されるエントリーの数を特定します。 | ||||||
bytesSent | サーバーが起動してからクライアントに送信されたバイト数を特定します。 | ||||||
currenttime | サーバーのこのスナップショットが作成された時間を指定します。この時間は Greenwich Mean Time(GMT)で UTC 形式で表示されます。 | ||||||
rhncfg | サーバーが起動した時間を指定します。この時間は Greenwich Mean Time(GMT)で UTC 形式で表示されます。 | ||||||
nbackends | サーバーサービスのバックエンド(データベース)の数を指定します。 | ||||||
backendmonitordn | 各ディレクトリーデータベースの DN を識別します。 |
20.7. データベースアクティビティーの監視
20.7.1. Directory Server コンソールからのデータベースアクティビティーの監視
- Directory Server コンソールで、Status タブを選択します。
- ナビゲーションツリーで、Performance Counters フォルダーを展開し、監視するデータベースを選択します。タブには、データベースアクティビティーの現在の情報が表示されます。サーバーが現在実行していない場合は、このタブではパフォーマンスの監視情報は提供されません。
- Continuous チェックボックスを選択し、 をクリックします。をクリックし、現在表示されている情報を更新します。ディレクトリーが継続的に表示される情報を更新する場合は、
フィールド | 詳細 |
---|---|
データベース | 監視されるデータベースのタイプを特定します。 |
設定 DN | ldapsearch コマンドラインユーティリティーを使用して、検索ベースとして使用する必要のある識別名を特定します。 |
パフォーマンスメトリック | 現在の合計 |
---|---|
読み取り専用のステータス | 現在、データベースが読み取り専用モードであるかどうかを示します。nsslapd-readonly 属性が on に設定されている場合、データベースは読み取り専用モードになります。 |
エントリーキャッシュヒット | 成功したエントリーキャッシュルックアップの合計数。つまり、ディスクに移動するのではなくキャッシュからデータを取得することで、サーバーが検索要求を処理できる合計回数です。 |
エントリーキャッシュのトリアトリア | ディレクトリーが最後に開始されてからのエントリーキャッシュルックアップの合計数。つまり、サーバー起動以降に要求されるエントリーの合計数です。 |
エントリー Cache Hit Ratio |
エントリーキャッシュの検索の成功を試みる比率。この数は、ディレクトリーが最後に開始された後のルックアップおよびヒットの合計に基づいています。この値を 100% にすると、より良い値になります。操作がエントリーキャッシュに存在しないエントリーの検索を試みるたびに、ディレクトリーがエントリーを取得するためにディスクアクセスを実行する必要があります。そのため、この比率はゼロに対してドロップするため、ディスクアクセスの数は増加し、ディレクトリー検索のパフォーマンス低下します。
比率を改善するには、エントリーキャッシュの自動調整を有効にします。詳細は、『Red 『Hat Directory Server パフォーマンスチューニングガイド』の該当するセクションを参照してください』。
|
現在のエントリーキャッシュサイズ(バイト) | エントリーキャッシュに現在存在するディレクトリーエントリーの合計サイズ。 |
最大エントリーキャッシュサイズ(バイト単位) |
ディレクトリーが維持するエントリーキャッシュのサイズ。
エントリーキャッシュのサイズは、cn= database _name,cn=ldbm database,cn=plugins,cn=config エントリーの
nsslapd-cachememsize 属性に設定されます。パフォーマンスを最適化するには、エントリーキャッシュの自動調整を有効にします。詳細は、『Red 『Hat Directory Server パフォーマンスチューニングガイド』の該当するセクションを参照してください』。
|
現在のエントリーキャッシュサイズ(エントリー内) | エントリーキャッシュに現在存在するディレクトリーエントリーの数。 |
エントリーキャッシュサイズ(エントリー内) |
非推奨。
エントリーキャッシュで保持できるディレクトリーエントリーの最大数。
許可される最大エントリー数を設定し、キャッシュサイズの管理を試行しないでください。これにより、ホストが RAM を効果的に割り当てることが困難になる可能性があります。
|
パフォーマンスメトリック | 現在の合計 |
---|---|
Hits | データベースキャッシュが要求されたページを正常に提供した回数。 |
tries | データベースキャッシュがページを要求する回数。 |
Ratio のヒット |
データベースキャッシュへのデータベースキャッシュヒットの比率。この値を 100% にすると、より良い値になります。ディレクトリー操作がデータベースキャッシュに存在しないデータベースの一部を見つけようとした場合、ディレクトリーは適切なデータベースページを取得するためにディスクアクセスを実行する必要があります。そのため、この比率はゼロに対してドロップするため、ディスクアクセスの数は増加し、ディレクトリーのパフォーマンス低下します。
比率を改善するには、データベースキャッシュの自動調整を有効にします。詳細は、『Red 『Hat Directory Server パフォーマンスチューニングガイド』の該当するセクションを参照してください』。
|
ページの読み取り | ディスクからデータベースキャッシュに読み取られるページ数。 |
ページが書き込まれる | キャッシュからディスクに書き込まれたページ数。データベースページは、読み取り/書き込みページが変更され、その後キャッシュから削除されるたびにディスクに書き込まれます。キャッシュが満杯になり、ディレクトリー操作に現在キャッシュに保存されていないデータベースページが必要な場合に、ページはデータベースキャッシュから削除されます。 |
読み取り専用ページのエビクション | 新規ページのスペースを作成するために、キャッシュから破棄された読み取り専用ページの数。 |
読み取り/書き込みページのエビクション | 新規ページのスペースを作成するために、キャッシュから破棄された読み取り/書き込みページの数。この値は、変更されていない読み取り書き込みページを破棄する点で、Pages Written Out とは異なります。 |
パフォーマンスメトリック | 現在の合計 |
---|---|
Cache Hits | 検索によって、この特定のファイルでキャッシュがヒットした回数。つまり、クライアントはこのファイルからデータを必要とする検索を実行し、ディレクトリーはキャッシュから必要なデータを取得します。 |
キャッシュがない | 検索結果が、この特定のファイルのキャッシュに到達できなかった回数。つまり、このファイルから必要なデータが実行されており、必要なデータがキャッシュにあることができませんでした。 |
ページの読み取り | このファイルからキャッシュに移動するページ数。 |
ページが書き込まれる | キャッシュからディスクに書き込まれるこのファイルのページ数。 |
20.7.2. コマンドラインでのデータベースの監視
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -s base -b "cn=monitor,cn=database_name,cn=ldbm database,cn=plugins,cn=config" "(objectclass=*)"
属性 | 詳細 |
---|---|
データベース | 現在モニターされているデータベースのタイプを特定します。 |
readonly | データベースが読み取り専用モードであるかどうかを指定します。0 は 、 サーバーが読み取り専用モードではないことを意味します。1 は、読み取り専用モードであることを意味します。 |
entrycachehits | 成功したエントリーキャッシュルックアップの合計数。つまり、ディスクに移動するのではなくキャッシュからデータを取得することで、サーバーが検索要求を処理できる合計回数です。 |
entrycachetries | ディレクトリーが最後に開始されてからのエントリーキャッシュルックアップの合計数。つまり、サーバー起動以降にサーバーに対して実行される検索操作の合計数。 |
entrycachehitratio |
エントリーキャッシュの検索の成功を試みる比率。この数は、ディレクトリーが最後に開始された後のルックアップおよびヒットの合計に基づいています。この値を 100% にすると、より良い値になります。検索操作がエントリーキャッシュに存在しないエントリーの検索を試みるたびに、ディレクトリーがエントリーを取得するためにディスクアクセスを実行する必要があります。そのため、この比率はゼロに対してドロップするため、ディスクアクセスの数は増加し、ディレクトリー検索のパフォーマンス低下します。
比率を改善するには、エントリーキャッシュの自動調整を有効にします。詳細は、『Red 『Hat Directory Server パフォーマンスチューニングガイド』の該当するセクションを参照してください』。
|
currententrycachesize |
エントリーキャッシュに現在存在するディレクトリーエントリーの合計サイズ(バイト単位)。
|
maxentrycachesize |
エントリーキャッシュで保持できるディレクトリーエントリーの最大サイズ(バイト単位)。
エントリーキャッシュのサイズは、cn= database _name,cn=ldbm database,cn=plugins,cn=config エントリーの
nsslapd-cachememsize 属性に設定されます。パフォーマンスを最適化するには、エントリーキャッシュの自動調整を有効にします。詳細は、『Red 『Hat Directory Server パフォーマンスチューニングガイド』の該当するセクションを参照してください』。
|
dbcachehits | ディスクに移動するのではなく、キャッシュからデータを取得することで、サーバーがリクエストを処理できる回数。 |
dbcachetries | サーバー起動後のデータベースアクセスの総数。 |
dbcachehitratio | キャッシュの比率は、キャッシュヒットの成功を試みます。この数を 100% にすると、より良い数値になります。 |
dbcachepagein | ディスクからキャッシュに読み取られるページ数。 |
dbcachepageout | キャッシュからディスクに書き込まれたページ数。 |
dbcacheroevict | 新規ページのスペースを作成するために、キャッシュから破棄された読み取り専用ページの数。キャッシュから破棄されたページはディスクに書き込まれ、サーバーのパフォーマンスに影響する可能性があります。ページの数が小さいほどエビクトされます。 |
dbcacherwevict | 新規ページのスペースを作成するために、キャッシュから破棄された読み取り/書き込みページの数。この値は、変更されていない読み取り書き込みページを破棄する点で、Pages Written Out とは異なります。キャッシュから破棄されたページはディスクに書き込まれ、サーバーのパフォーマンスに影響する可能性があります。ページの数が小さいほどエビクトされます。 |
dbfilename-number | ファイルの名前です。数値は、ファイルの連続した整数識別子(0 から開始)を提供します。ファイルに関連付けられたすべての統計には、同じ数値 ID が指定されます。 |
dbfilecachehit-number | 検索によって、この特定のファイルでキャッシュがヒットした回数。つまり、クライアントはこのファイルからデータを必要とする検索を実行し、ディレクトリーはキャッシュから必要なデータを取得します。 |
dbfilecachemiss-number | 検索結果が、この特定のファイルのキャッシュに到達できなかった回数。つまり、このファイルから必要なデータが実行されており、必要なデータがキャッシュにあることができませんでした。 |
dbfilepagein-number | このファイルからキャッシュに移動するページ数。 |
dbfilepageout-number | キャッシュからディスクに書き込まれるこのファイルのページ数。 |
currentdncachesize |
DN キャッシュに現在存在する DN の合計サイズ(バイト単位)。
DN キャッシュに存在するエントリーのサイズを増やすには、データベースの cn= database_name , cn=ldbm database,cn=plugins,cn=config エントリーの
nsslapd-dncachememsize 属性の値を増やします。
|
maxdncachesize |
DN キャッシュで保持できる DN の最大サイズ(バイト単位)。
キャッシュに存在するエントリーのサイズを増やすには、データベースの cn= database_name、cn= ldbm database,cn=plugins,cn=config エントリーの
nsslapd-dncachememsize 属性の値を増やします。
|
currentdncachecount | DN キャッシュに現在存在する DN の数。 |
20.8. データベースリンクアクティビティーの監視
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -s sub -b "cn=monitor,cn=DBLink1,cn=chaining database,cn=plugins,cn=config" "(objectclass=*)" nsAddCount
属性名 | 詳細 |
---|---|
nsAddCount | 受信した追加操作の数。 |
nsDeleteCount | 受信した削除操作の数。 |
nsModifyCount | 受信した変更操作の数。 |
nsRenameCount | 受信した名前変更操作の数。 |
nsSearchBaseCount | 受け取ったベースレベルの検索の数。 |
nsSearchOneLevelCount | 受信した 1 レベル検索の数。 |
nsSearchSubtreeCount | 受信したサブツリー検索の数。 |
nsAbandonCount | 受信した Abandon 操作の数。 |
nsBindCount | 受信したバインド要求の数。 |
nsUnbindCount | 受信したバインド解除の数。 |
nsCompareCount | 受信した比較操作の数。 |
nsOperationConnectionCount | 通常操作のオープン接続の数。 |
nsBindConnectionCount | バインド操作のオープン接続の数。 |
20.9. カウンターの有効化および無効化
nsslapd-counters
属性により、実行するカウンターが有効になります。ただし、カウンターの実行はパフォーマンスに影響する可能性があるため、カウンターをオフにすることもできます。カウンターがオフの場合、カウンターの値はすべてゼロ (0) になります。
ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config changetype: modify replace: nsslapd-counters nsslapd-counters: off
第21章 SNMP を使用した Directory Server の監視
21.1. SNMP の概要
21.2. SNMP 用の Directory Server の設定
- Configuration タブを選択し、左側のペインのナビゲーションツリーで最上位のエントリーを選択します。
- メインウィンドウで SNMP タブを選択します。
- Net-SNMP で Directory Server インスタンスを簡単に識別できるように、SNMP 記述子に関する情報を入力します。
- インスタンスの一意の名前および説明。
- ディレクトリーインスタンスが属する企業または組織。
- インスタンスを管理するディレクトリーインスタンスまたは組織の物理的な場所。
- Directory Server インスタンスを維持するユーザーのメールアドレスまたは連絡先番号。
21.3. Directory Server の SNMP Agent の設定
- 389-ds-base-snmp パッケージおよび net-snmp パッケージをインストールします。
# yum install 389-ds-base-snmp net-snmp
- SNMP マスターエージェントを設定するには、
/etc/snmp/snmpd.conf
ファイルを編集し、以下のエントリーを追加してエージェントの拡張性 (AgentX) プロトコルを有効にします。master agentx
AgentX プロトコルの詳細は RFC 2741 を参照してください。 - SNMP サブエージェントを設定するには、
/etc/dirsrv/config/ldap-agent.conf
ファイルを編集し、監視する各 Directory Server インスタンスに server パラメーターを追加します。以下に例を示します。server slapd-instance_name
- 必要に応じて、SNMP ユーザーアカウントを作成します。
snmpd
サービスを停止します。# systemctl stop snmpd
- SNMP ユーザーアカウントを作成します。以下に例を示します。
# net-snmp-create-v3-user -A authentication_password -a SHA \ -X private_password -x AES user_name
コマンドで使用されるパラメーターの詳細は、net-snmp-create-v3-user(1) の man ページを参照してください。 snmpd
サービスを起動します。# systemctl start snmpd
- 必要に応じて、Directory Server 記述プロパティーを設定します。詳細は、「SNMP 用の Directory Server の設定」 を参照してください。
dirsrv-snmp
サービスを起動します。# systemctl start dirsrv-snmp
- 必要に応じて、設定を確認するには、以下を実行します。
- net-snmp-utils パッケージをインストールします。
# yum install net-snmp-utils
- Directory Server オブジェクト識別子 (OID) をクエリーします。以下に例を示します。
# snmpwalk -v3 -u user_name -M /usr/share/snmp/mibs:/usr/share/dirsrv/mibs/ \ -l AuthPriv -m +RHDS-MIB -A authentication_password -a SHA -X private_password -x AES server.example.com .1.3.6.1.4.1.2312.6.1.1
21.4. SNMP トラップの設定
dsEntityContact
変数に定義された電子メールアドレスに電子メールを送信する一方で、別のインスタンスでは dsEntityContact
変数に定義されたページャー番号に通知を送信するなど、柔軟に対応することができます。
- DirectoryServerDown.このトラップは、サブエージェントが Directory Server が実行されていないことを検出するたびに生成されます。このトラップは、Directory Server インスタンスの説明、バージョン、物理的な場所、および連絡先情報と共に送信されます。詳細は、
dsEntityDescr
変数、dsEntityVers
変数、dsEntityLocation
変数、およびdsEntityContact
変数を参照してください。 - DirectoryServerStart.このトラップは、サブエージェントが Directory Server が起動または再起動していることを検出すると常に生成されます。このトラップは、Directory Server インスタンスの説明、バージョン、物理的な場所、および連絡先情報と共に送信されます。詳細は、
dsEntityDescr
変数、dsEntityVers
変数、dsEntityLocation
変数、およびdsEntityContact
変数を参照してください。
21.5. 管理情報ベースの使用
-directory.mib
と呼ばれるファイルです。この MIB には、そのディレクトリーのネットワーク管理に関する変数の定義が含まれます。これらの変数は、管理オブジェクトと呼ばれます。ディレクトリー MIB および Net-SNMP を使用すると、ネットワーク上の他の全デバイスと同様にディレクトリーを監視できます。MIB を使用する方法は、「Directory Server の SNMP Agent の設定」を参照してください。
21.5.1. 操作表
redhat-directory.mib
ファイルの Operations Table に保存されている管理オブジェクトを説明します。
管理オブジェクト | 説明 |
---|---|
dsAnonymousBinds | サーバーの起動以降、ディレクトリーへの匿名バインド数。 |
dsUnauthBinds | サーバーの起動以降、ディレクトリーへの認証されていないバインド数。 |
dsSimpleAuthBinds | サーバーが起動してから、単純な認証方法 (パスワード保護など) で確立された、ディレクトリーのバインド数。 |
dsStrongAuthBinds | サーバーの起動してから、強力な認証方法 (TLS や、Kerberosのような SASL メカニズムなど) を使用して確立されたディレクトリーへのバインドの数。 |
dsBindSecurityErrors | サーバーの起動以降に、認証失敗または無効な認証情報により、ディレクトリーで拒否されたバインド要求の数。 |
dsInOps | サーバーの起動以降、別のディレクトリーからこのディレクトリーに転送される操作の数。 |
dsReadOps | アプリケーションが起動してからこのディレクトリーによる読み取り操作の数。LDAP は検索操作を使用して間接的に読み取り操作を実装するため、このオブジェクトの値は常に 0 になります。 |
dsCompareOps | サーバーの起動時にこのディレクトリーによる比較操作の数。 |
dsAddEntryOps | サーバーの起動時にこのディレクトリーによる追加操作の数。 |
dsRemoveEntryOps | サーバーの起動以降、このディレクトリーがサービス化された削除操作の数。 |
dsModifyEntryOps | サーバーの起動以降、このディレクトリーがサービス化された変更操作の数。 |
dsModifyRDNOps | サーバー起動以降、このディレクトリーが処理する RDN 操作の数。 |
dsListOps | サーバーの起動時にこのディレクトリーによるリスト操作の数。LDAP は検索操作を使用して間接的にリスト操作を実装するため、このオブジェクトの値は常に 0 になります。 |
dsSearchOps | サーバーの起動以降、このディレクトリーで処理された検索操作の合計数。 |
dsOneLevelSearchOps | サーバー起動以降、このディレクトリーが処理する 1 レベルの検索操作の数。 |
dsWholeSubtreeSearchOps | サーバー起動以降、このディレクトリーが指定したサブツリー検索操作全体の数。 |
dsReferrals | サーバー起動からクライアント要求に対応して、このディレクトリーが返す参照数。 |
dsSecurityErrors | セキュリティー要件を満たしていないこのディレクトリーに転送される操作の数。 |
dsErrors | エラー (セキュリティーエラーや参照エラー以外) のためにサービスを提供できなかった要求の数です。エラーには、名前エラー、更新エラー、属性エラー、およびサービスエラーなどがあります。部分的に設定されたリクエストはエラーとしてカウントされません。 |
21.5.2. エントリー表
redhat-directory.mib
ファイルの Entries Table に保存されている管理オブジェクトを説明します。
管理オブジェクト | 説明 |
---|---|
dsMasterEntries | このディレクトリーにマスターエントリーが含まれるディレクトリーエントリーの数。(現在更新が行われないため)このオブジェクトの値は、常に 0 になります。 |
dsCopyEntries | このディレクトリーのコピーが含まれるディレクトリーエントリーの数。このオブジェクトの値は、常に 0 になります (現在実行された更新は実行されていません)。 |
dsCacheEntries | ディレクトリーにキャッシュされたエントリーの数。 |
dsCacheHits | アプリケーションが起動してからローカルに保持されたキャッシュから指定された操作数。 |
dsSlaveHits | ローカルを保持するレプリケーション (shadow エントリー) で処理されたオペレーションの数。このオブジェクトの値は常に 0 になります。 |
21.5.3. エンティティーテーブル
管理オブジェクト | 説明 |
---|---|
dsEntityDescr | Directory Server インスタンスの説明セット。 |
dsEntityVers | Directory Server インスタンスの Directory Server のバージョン番号。 |
dsEntityOrg | Directory Server インスタンスに対応する組織。 |
dsEntityLocation | Directory Server インスタンスの物理的な場所。 |
dsEntityContact | Directory Server インスタンス担当する担当者の名前と連絡先情報。 |
dsEntityName | Directory Server インスタンスの名前。 |
21.5.4. 対話表
管理オブジェクト | 説明 |
---|---|
dsIntTable | 表の各行で、監視される Directory Server とそれぞれのピア Directory Server との対話の履歴に関連する詳細が表示されます。 |
dsIntEntry | Directory Server と相手の Directory Server との相互作用の詳細を示すエントリー。 |
dsIntIndex | applIndex と共に一意の鍵の一部であり、(applIndex で参照される) Directory Server と相手の Directory Server との間の (試行された) 相互作用に関する有用な情報を含む概念的な行を特定するためのものです。 |
dsName | このエントリーが属するピア Directory Server の識別名 (DN)。 |
dsTimeOfCreation | この行が作成された場合の sysUpTime の値。ネットワーク管理サブシステムが初期化される前にエントリーが作成されると、このオブジェクトにはゼロの値が含まれます。 |
dsTimeOfLastAttempt | この Directory Server に対する接続最終試行時の sysUpTime の値。ネットワーク管理サブシステムが初期化される前に最後の試行が行われた場合、このオブジェクトにはゼロの値が含まれます。 |
dsTimeOfLastSuccess | この Directory Server に問い合わせた最後の試行時の sysUpTime の値。このエントリーは、成功した試行がない場合や、最後に成功した試行がネットワーク管理サブシステムの初期化前に行われた場合には、0 の値になります。 |
dsFailuresSinceLastSuccess | この Directory Server への初回連絡の試行に成功した後の失敗回数。試行に成功しなかった場合、このカウンターには、このエントリーが作成されてからの失敗回数が格納されます。 |
dsFailures | このエントリーの作成からの累積的な障害。 |
dsSuccesses | このエントリーの作成以降、累積成功。 |
dsURL | Directory Server アプリケーションの URL。 |
第22章 高可用性および障害復旧計画の作成
22.1. 潜在的なシナリオの特定
シナリオ | インフラストラクチャーへの影響 | 理想的な応答 |
---|---|---|
データの破損 | ソフトウェアやハードウェア障害 (または悪意のある攻撃経由) を介して、1 つのサイトまたは 1 つサーバーのデータが破損する可能性があります。その破損したサーバーがマルチマスターレプリケーションのサプライヤーである場合、破損はすぐにデプロイメント全体に伝播してしまいます。 | 破損していないデータの最新のバックアップにアクセスできる、分離されたサーバーを用意する必要があります。問題が検出された場合は、通常のインフラストラクチャーでのレプリケーションを中断し、このサーバーをオンラインにして、適切なデータでサプライヤーを再初期化することができます。 |
自然な障害およびその他の大量イベント | 自然災害は、長期間の停電だけでなく、オフィスやデータセンター全体を停止させる可能性があります。 | ディレクトリー操作は、同じデータを使用して、別の物理の場所にあるミラーリングされたサイトに転送できます。 |
サーバーまたはマシンの損失 | 1 つのマシンが失敗する可能性があります。 | 同じデータを持つ別のマシンは、失われたマシンがあることを想定できます。 |
22.2. ロールオーバーの種類の定義
- ホットロール オーバーは、インフラストラクチャーが別のサイトで完全にミラーリングされ、バックアップサイトは常にプライマリーサイトで最新の状態であることを意味します。これには、プライマリーからバックアップに操作を切り替えるための調整のみが必要になります。
- ウォーム ロールオーバーとは、バックアップサイトのすべての要素 (適切なネットワーク接続、必要なすべてのアプリケーションとハードウェア) は整っているが、システムがアクティブに稼働していない、または必ずしも設定されていない状態を指します。これには、マシンを設定し、システムの実行に追加の時間が必要になる場合があります。
- コールド ロールオーバーとは、サイトは利用可能だが、それをセットアップするためのリソースがすぐには得られないことを意味します。
22.3. 障害復旧における便利な Directory Server 機能の特定
- データベースのバックアップおよびバックアップの定期的な検証
- マルチマスターのレプリケーション、チェーン、データベースのバックアップ、および名前付きパイプスクリプトでサーバーの監視
- チェーン
22.3.1. 災害リカバリー用のディレクトリーデータのバックアップ
0 7 * * 1 /usr/sbin/db2bak.pl -Z instance_name
dse.ldif
ファイル)の両方のバックアップが対象です。
22.3.2. 高可用性のためのマルチマスターレプリケーション
例22.1 マルチマスターレプリケーションのシナリオ
- 単一のサーバー障害の場合、そのインスタンスに保存されているすべてのデータには、他のサーバーからアクセスと取得が可能です。
- オフィス全体やコロケーション施設が失われた場合は、まったく別の物理的な場所にサーバーをミラーリングすることができます (Directory Serverの広域レプリケーションの性能が役立ちます)。最低限の努力で、新しいサーバーをオンラインにすることなく、トラフィックは複製されたサイトにリダイレクトされます。
22.3.3. 高可用性のデータベースチェーン
例22.2 連鎖のシナリオ
22.4. リカバリープロセスの定義
- 障害を示すシグナル。明白なもの (大規模な停電、ネットワーク損失、または火災) もありますが、定義する必要があるものもあります。たとえば、バックアップサーバーをオンラインにする必要があるというメッセージは何ですか。
- 障害に応答する人および方法。災害が発生したら、誰が責任を持って行動しますか。これらのイベントについて通知する方法。何を期待されていますか。
- 災害復旧計画を出力したものをサイト外に保管します。
- 障害復旧計画を定期的にテストし、設定とインフラストラクチャーの変更後にテストします。
22.5. 基本的な例: リカバリーの実行
- プラン A では、Directory Server における 1 つのインスタンスの損失について扱います。
- プラン B は、何らかのデータの破損または攻撃を扱います。
- プラン C では、オフィス全体が失われた場合を扱います。
付録A LDAP クライアントツールの使用
A.1. 延長操作の実行
-e
オプションまたは -E
オプションのいずれかを使用して拡張操作を送信します。-e
引数は、任意の OpenLDAP クライアントツールと使用でき、パスワードポリシーの処理方法など、操作に関する一般的な指示を送信できます。-E
は、ldapsearch でのみ使用され、GER 検索、ソート、ページ情報などのより有用な制御を渡し、その他情報 (not-explicitly-support 拡張操作など) に関する情報を渡します。
-E extended_operation_type=operation_parameters
# ldapsearch -x -D "cn=Directory Manager" -W -b "ou=Engineers,ou=People,dc=example,dc=com" -E pg=3 "(objectclass=*)" cn dn: uid=jsmith,ou=Engineers,ou=People,dc=example,dc=com cn: John Smith dn: uid=bjensen,ou=Engineers,ou=People,dc=example,dc=com cn: Barbara Jensen dn: uid=hmartin,ou=Engineers,ou=People,dc=example,dc=com cn: Henry Martin Results are sorted. next page size (3): 5
ldapexop 1.2.840.113556.1.4.319=3
A.2. エントリーの比較
sn
値が Smith であるかを確認します。
# ldapcompare -D "cn=Directory Manager" -W -p 389 -h server.example.com -x sn:smith uid=bjensen,ou=people,dc=example,dc=com comparing type: "sn" value: "smith" in entry "uid=bjensen,ou=people,dc=example,dc=com" compare FALSE ldapcompare -D "cn=Directory Manager" -W -p 389 -h server.example.com -x sn:smith uid=jsmith,ou=people,dc=example,dc=com comparing type: "sn" value: "smith" in entry "uid=jsmith,ou=people,dc=example,dc=com" compare TRUE
- コマンドラインで直接渡される単一の attribute:value 文
sn:Smith
jpegPhoto
などの属性、または証明書または CRL を検証するために、コマンドラインで渡される単一の attribute::base64value ステートメントjpegPhoto:dkdkPDKCDdko0eiofk==
- 属性の比較値の一覧を含むファイルを参照する attribute:file 文およびスクリプトは、リストを繰り返し処理します。
postalCode:/tmp/codes.txt
-f
オプションを使用して指定することのできる DN の一覧を指定します。
例A.1 1 つの属性値と 1 つのエントリーの比較
ldapcompare -D "cn=Directory Manager" -W -p 389 -h server.example.com -x sn:smith uid=jsmith,ou=people,dc=example,dc=com comparing type: "sn" value: "smith" in entry "uid=jsmith,ou=people,dc=example,dc=com" compare TRUE
例A.2 ファイルからのリスト属性値の比較
sn
値のファイルを作成します。
jensen johnson johannson jackson jorgenson
uid=jen200,ou=people,dc=example,dc=com uid=dsj,ou=people,dc=example,dc=com uid=matthewjms,ou=people,dc=example,dc=com uid=john1234,ou=people,dc=example,dc=com uid=jack.son.1990,ou=people,dc=example,dc=com
# ldapcompare -D "cn=Directory Manager" -W -p 389 -h server.example.com -x sn:/tmp/surnames.txt -f /tmp/names.txt comparing type: "sn" value: "jensen" in entry "uid=jen200,ou=people,dc=example,dc=com" compare TRUE
A.3. パスワードの変更
# ldappasswd -x -D bind_dn -W -p server_port -h server_hostname [-A | -a oldPassword] [-S | -s newPassword] [user]
passwd
のパスワード操作関連のパラメーターの一覧は、表19.1「ldappasswd オプション」 を参照してください。
例A.3 Directory Manager が TLS を介してユーザーのパスワードを変更
# ldappasswd -D "cn=Directory Manager" -W -ZZ -p 389 -h server.example.com -x -s new_password "uid=tuser1,ou=People,dc=example,dc=com"
例A.4 ユーザーのパスワードを生成する Directory Manager
# ldappasswd -D "cn=Directory Manager" -W -ZZ -p 389 -h server.example.com -x "uid=tuser2,ou=People,dc=example,dc=com"
例A.5 ユーザーが自分のパスワードを変更
# ldappasswd -p 389 -h server.example.com -ZZ -x -D "uid=tuser3,ou=People,dc=example,dc=com" -W -a old_password -s new_password
例A.6 DIGEST_MD5 によるユーザー認証および自身のパスワードの変更
# ldappasswd -p 389 -h server.example.com -O noplain,minssf=1,maxbufsize=512 -Y GSSAPI -U "dn:uid=jsmith,ou=people,dc=example,dc=com" -R EXAMPLE.COM -W -s new_password
A.4. LDAP URL の生成
-H
オプションで、他の接続情報 (ホスト名、ポート、サブツリー、検索ベースなど) の代わりに LDAP URL を渡すことができます。
- 指定された LDAP URL をその構成要素に分解
- 指定要素から新しくて有効な LDAP URL を作成
オプション | 説明 |
---|---|
URL の分解の場合 | |
-H "URL" | LDAP URL を渡して要素に分割します。 |
URL の構築の場合 | |
-a attributes | 検索結果で特に返されるコンマ区切りの属性を指定します。 |
-b base | URL の検索ベースまたはサブツリーを設定します。 |
-f filter | 使用する検索フィルターを設定します。 |
-h hostname | Directory Server のホスト名を指定します。 |
-p port | Directory Server のポートを指定します。 |
-S ldap|ldaps|ldapi | ldap、ldaps、ldapi など、接続に使用するプロトコルを指定します。 |
-s scope | 検索条件を指定します。 |
例A.8 LDAP URL の無効化
-H
オプションを使用して既存の LDAP URL にフィードし、このツールは neat リストの URL の要素を返します。
# ldapurl -H "ldap://:389/dc=example,dc=com?cn,sn?sub?(objectclass=inetorgperson)" scheme: ldap port: 389 dn: dc=example,dc=com selector: cn selector: sn scope: sub filter: (objectclass=inetorgperson)
例A.9 LDAP URL の構築
ldapurl -a cn,sn -b dc=example,dc=com -s sub -f "(objectclass=inetorgperson)" ldap://:389/dc=example,dc=com?cn,sn?sub?(objectclass=inetorgperson)
付録B LDAP データ交換形式
B.1. LDIF ファイルの形式の概要
dn: distinguished_name objectClass: object_class objectClass: object_class ... attribute_type[;subtype]:attribute_value ...
- すべての LDIF エントリーには、DN と 1 つ以上のオブジェクトクラス定義が必要です。
- エントリーに定義されるオブジェクトクラスで必要な属性を含めます。
- その他の属性およびオブジェクトクラスはすべて任意です。
- オブジェクトクラスおよび属性は任意の順序で指定できます。
- コロン後のスペースは任意です。
フィールド | 定義 |
---|---|
[id] | 任意。エントリー ID を表す正の 10 進数。データベース作成ツールは、この ID を自動的に生成します。この値は独自に追加したり、編集したりしないでください。 |
dn: distinguished_name | エントリーの識別名を指定します。 |
objectClass: object_class | このエントリーで使用するオブジェクトクラスを指定します。オブジェクトクラスは、エントリーに使用可能な属性のタイプ (スキーマ) を識別します。標準オブジェクトクラスの一覧は 『、Red Hat Directory Server 10 の設定、コマンド、およびファイルリファレンス』 を参照してください。スキーマのカスタマイズに関する情報は、「 12章ディレクトリースキーマの管理 」を参照してください。 |
attribute_type | エントリーで使用する説明的な属性を指定します。属性はスキーマで定義する必要があります。標準 『属性の一覧は、Red Hat Directory Server 10 の設定、コマンド、およびファイルリファレンス』 を参照してください。スキーマのカスタマイズに関する情報は、「 12章ディレクトリースキーマの管理 」を参照してください。 |
[subtype] | 任意。サブタイプ、言語、バイナリー、または発音を指定します。このタグを使用して、対応する属性値が表現されている言語や、属性値がバイナリーであるか、属性値の発音であるかを識別します。属性サブタイプに関する詳細は、「属性サブタイプの追加」 を参照してください。サポートされるサブタイプタグの一覧は、表D.1「サポートされる言語サブタイプ」を参照してください。 |
attribute_value | 属性タイプと使用する属性値を指定します。 |
B.2. LDIF での行継続
dn: cn=Jake Lupinski,dc=example,dc=com dn: cn=Jake Lup inski,dc=exa mple,dc=com
B.3. バイナリーデータの表現
B.3.1. 標準の LDIF 表記
jpegphoto: < file:/path/to/photo
version: 1
# ldapmodify -x -D userDN -W version: 1 dn: cn=Barney Fife,ou=People,dc=example,dc=com changetype: modify add: usercertificate usercertificate;binary: < file: BarneysCert
B.3.2. Base-64 でエンコード
jpegPhoto::encoded_data
- コロン (:) またはスペースで始まる値。
- ASCII 以外のデータを含む値 (新しい行を含む)。
# ldif -b attribute_name
# ldif -b jpegPhoto < mark.jpg > out.ldif
jpegPhoto
の LDIF 形式に変換します。出力は out.ldif
に保存されます。
B.4. LDIF を使用したディレクトリーエントリーの指定
B.4.1. ドメインエントリーの指定
dn: distinguished_name objectClass: top objectClass: domain dc: domain_component_name list_of_optional_attributes ...
dn: dc=example,dc=com objectclass: top objectclass: domain dc: example description: Fictional example company
LDIF 要素 | 説明 |
---|---|
dn: distinguished_name | 必須。エントリーの識別名を指定します。 |
objectClass: top | 必須。top オブジェクトクラスを指定します。 |
objectClass: domain | domain オブジェクトクラスを指定します。この行は、エントリーをドメインまたはドメインコンポーネントとして定義します。このオブジェクトクラスで利用可能な属性の一覧は、『Red Hat Directory Server 10 Configuration, Command, and File Referenceを参照してください』。 |
dc: domain_component | ドメイン名を指定する属性。サーバーは通常、dc=hostname,dc=domain,dc=toplevel の形式で接尾辞または命名コンテキストを持つように初期設定時に設定されます。たとえば、dc=ldap,dc=example,dc=com になります。ドメインエントリーは、dc: ldap のように左端の dc の値を使用する必要があります。サフィックスが dc=example,dc=com の場合、dc の値は dc: example になります。サーバーが接尾辞を使用するよう設定されていない場合は、dn: dc=com のエントリーを作成しないでください。 |
list_of_attributes | エントリーに保持する任意の属性の一覧を指定します。このオブジェクトクラスで利用可能な属性の一覧は、『Red Hat Directory Server 10 Configuration, Command, and File Referenceを参照してください』。 |
B.4.2. 組織単位エントリーの指定
dn: distinguished_name objectClass: top objectClass: organizationalUnit ou: organizational_unit_name list_of_optional_attributes ...
dn: ou=people,dc=example,dc=com objectclass: top objectclass: organizationalUnit ou: people description: Fictional example organizational unit
LDIF 要素 | 説明 |
---|---|
dn: distinguished_name | エントリーの識別名を指定します。DN が必要です。DN にコンマがある場合、コンマはバックスラッシュ (\) でエスケープする必要があります (例: dn: ou=people,dc=example,dc=com)。 |
objectClass: top | 必須。top オブジェクトクラスを指定します。 |
objectClass: organizationalUnit | organizationalUnit オブジェクトクラスを指定します。この行は、エントリーを organizational unit として定義します。このオブジェクトクラスで利用可能な属性の一覧は、『Red Hat Directory Server 10 Configuration, Command, and File Referenceを参照してください』。 |
ou: organizational_unit_name | 組織単位の名前を指定する属性。 |
list_of_attributes | エントリーに保持する任意の属性の一覧を指定します。このオブジェクトクラスで利用可能な属性の一覧は、『Red Hat Directory Server 10 Configuration, Command, and File Referenceを参照してください』。 |
B.4.3. 組織の個人エントリーの指定
dn: distinguished_name objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: common_name sn: surname list_of_optional_attributes
dn: uid=bjensen,ou=people,dc=example,dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: Babs Jensen sn: Jensen givenname: Babs uid: bjensen ou: people description: Fictional example person telephoneNumber: 555-5557 userPassword: {SSHA}dkfljlk34r2kljdsfk9
LDIF 要素 | 説明 |
---|---|
dn: distinguished_name | 必須。エントリーの識別名を指定します。たとえば、dn: uid=bjensen,ou=people,dc=example,dc=com になります。DN にコンマがある場合は、コンマをバックスラッシュ (\) でエスケープする必要があります。 |
objectClass: top | 必須。top オブジェクトクラスを指定します。 |
objectClass: person | person オブジェクトクラスを指定します。多くの LDAP クライアントは、ユーザーや組織のユーザーの検索操作時にこれを必要とするため、このオブジェクトクラス仕様を含める必要があります。 |
objectClass: organizationalPerson | organizationalPerson オブジェクトクラスを指定します。一部の LDAP クライアントは、組織ユーザーの検索操作時に必要であるため、このオブジェクトクラス仕様を含める必要があります。 |
objectClass: inetOrgPerson | inetOrgPerson オブジェクトクラスを指定します。このオブジェクトクラスには属性の範囲が広がるため、このオブジェクトクラスには組織の人エントリーの作成には、inetOrgPerson オブジェクトクラスが推奨されます。uid 属性はこのオブジェクトクラスで必要で、このオブジェクトクラスが含まれるエントリーは uid 属性の値に基づいて名前が付けられます。このオブジェクトクラスで利用可能な属性の一覧は、『Red Hat Directory Server 10 Configuration, Command, and File Referenceを参照してください』。 |
cn: common_name | 担当者の一般的な名前を指定します。これは、担当者が一般的に使用するフルネームです。たとえば、cn: Bill Anderson のようになります。少なくとも 1 つの共通名が必要です。 |
sn: 姓 | ユーザーの姓を指定します。たとえば、sn: Anderson のようになります。姓が必要です。 |
list_of_attributes | エントリーに保持する任意の属性の一覧を指定します。このオブジェクトクラスで利用可能な属性の一覧は、『Red Hat Directory Server 10 Configuration, Command, and File Referenceを参照してください』。 |
B.5. LDIF を使用したディレクトリーの定義
- LDIF 形式に追加するエントリーを含む ASCII ファイルを作成します。各エントリーは、空の行で次のエントリーと区切られていることを確認してください。エントリーの間に 1 行のみを使用し、ファイルの最初の行が空白ではないことを確認します。そうでない場合は、ldapmodify ユーティリティーが終了します。詳細は「LDIF を使用したディレクトリーエントリーの指定」を参照してください。
- 各ファイルは、データベースの一番上のエントリー (ルート) から始めます。root エントリーは、データベースに含まれる接尾辞または部分接尾辞を表す必要があります。たとえば、データベースに dc=example,dc=com の接尾辞がある場合、ディレクトリーの最初のエントリーは dn: dc=example,dc=com でなければなりません。接尾辞の詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 に記載されている「Suffix」パラメーターを参照してください。
- LDIF ファイルのブランチポイントを表すエントリーが、そのブランチで作成するエントリーの前に配置されていることを確認します。たとえば、エントリーをユーザーやグループのサブツリーに置くには、それらのサブツリー内にエントリーを作成する前に、そのサブツリーの分岐点を作成します。注記LDIF ファイルは順番に読み込まれるため、親エントリーが子エントリーの前にある必要があります。
- 以下の方法のいずれかを使用して、LDIF ファイルからディレクトリーを作成します。
- Directory Server コンソールでデータベースの初期化インポートするデータベースの規模が小さい (10,000 エントリーより少ない) 場合は、この方法を使用します。「コンソールからのデータベースのインポート」 を参照してください。警告このメソッドは破壊的で、接尾辞の既存のデータを削除します。
- ldif2db または ldif2db.pl コマンドラインユーティリティー。インポートするデータベースの規模が大きい (10,000 エントリーより多い) 場合は、この方法を使用します。「ldif2db コマンドラインユーティリティーを使用したインポート」 を参照してください。
- ldif2db サーバーが実行している場合のみ使用できます。
- ldif2db.pl サーバーが実行されている場合のみ使用できます。
警告このメソッドは破壊的で、接尾辞の既存のデータを削除します。 - ldapmodify コマンドラインユーティリティーに -a パラメータをつけたものです。この方法は、既存のデータベースに新しいサブツリーを追加する場合や、削除してはいけない既存のデータが接尾辞にある場合に使用します。LDIF ファイルからディレクトリーを作成する他の方法とは異なり、ldapmodify を使用してサブツリーを追加する前に Directory Server を実行する必要があります。「エントリーの追加」を参照してください。
例B.1 LDIF ファイルの例
dn: dc=example,dc=com objectclass: top objectclass: domain dc: example description: Fictional example domain dn: ou=People,dc=example,dc=com objectclass: top objectclass: organizationalUnit ou: People description: Fictional example organizational unit tel: 555-5559 dn: cn=June Rossi,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: June Rossi sn: Rossi givenName: June mail: rossi@example.com userPassword: {sha}KDIE3AL9DK ou: Accounting ou: people telephoneNumber: 2616 roomNumber: 220 dn: cn=Marc Chambers,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Marc Chambers sn: Chambers givenname: Marc mail: chambers@example.com userPassword: {sha}jdl2alem87dlacz1 telephoneNumber: 2652 ou: Manufacturing ou: People roomNumber: 167 dn: cn=Robert Wong,ou=People,example.com Corp,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Robert Wong cn: Bob Wong sn: Wong givenname: Robert givenname: Bob mail: bwong@example.com userPassword: {sha}nn2msx761 telephoneNumber: 2881 roomNumber: 211 ou: Manufacturing ou: people dn: ou=Groups,dc=example,dc=com objectclass: top objectclass: organizationalUnit ou: groups description: Fictional example organizational unit
B.6. 複数の言語での情報の保存
- 管理者が、フランスの所在地住所値で
street.txt
ファイルを作成します。1 rue de l'Université
- ファイルのコンテンツは UTF-8 に変換されます。
# iconv -t UTF-8 -o output.txt street.txt
- 以下の LDIF エントリーは、
streetAddress;lang-fr
の street アドレス値の UTF-8 値を使用して作成されます。dn: uid=bjensen,ou=people,dc=example,dc=com objectclass: top objectclass: person objectclass: organizationalPerson name: Babs Jensen cn: Babs Jensen sn: Jensen uid: bjensen streetAddress: 1 University Street streetAddress;lang-en: 1 University Street streetAddress;lang-fr
:: AasljdoaAJASI023909jaASJaonasd0ADS
preferredLanguage: fr属性名とサブタイプの後にコロンは、値がバイナリーの base-64 でエンコードされたことを示しています。
付録C LDAP URL
- LDAP URL は、Web ベースのクライアントを使用して Directory Server にアクセスする際に特定の Directory Server インスタンスを特定するために使用されます。
- LDAP URL は Directory Server の参照を設定するのに使用されます。
- LDAP URL はアクセス制御の指示を設定するのに使用されます。
C.1. LDAP URL のコンポーネント
ldap[s]://hostname:port/base_dn?attributes?scope?filter
コンポーネント | 説明 | |||
---|---|---|---|---|
ホスト名 | LDAP サーバーの名前(または IPv4 アドレスまたは IPv6 アドレス)たとえば、ldap .example.com または 192.0.2.90 です。 | |||
ポート | LDAP サーバーのポート番号 (例: 696)。ポートが指定されていない場合は、標準の LDAP ポート (389) または LDAPS ポート (636) が使用されます。 | |||
base_dn | ディレクトリー内のエントリーの識別名 (DN)。この DN は、検索の開始点であるエントリーを特定します。ベース DN が指定されていない場合、検索はディレクトリーツリーのルートで始まります。 | |||
attributes | 返される属性。複数の属性を指定するには、コンマを使用して属性を区切ります (例: cn,mail,telephoneNumber)。URL に属性が指定されていない場合は、すべての属性が返されます。 | |||
scope | 検索の範囲で、以下のいずれかの値になります。
| |||
filter | 指定された検索範囲内のエントリーに適用する検索フィルター。フィルターを指定しないと、サーバーはフィルター (objectClass=*) を使用します。 |
ldap://ldap.example.com/dc=example,dc=com??sub?(sn=Jensen)
C.2. 不安全文字のエスケープ
不安全な文字 | エスケープ文字 |
---|---|
space | %20 |
< | %3c |
> | %3e |
" | %22 |
# | %23 |
% | %25 |
{ | %7b |
} | %7d |
| | %7c |
\ | %5c |
^ | %5e |
~ | %7e |
[ | %5b |
] | %5d |
` | %60 |
C.3. LDAP URL の例
例 1
以下の LDAP URL は、識別名 dc=example,dc=com のエントリーのベース検索を指定します。
ldap://ldap.example.com/dc=example,dc=com
- ポート番号が指定されていないため、標準の LDAP ポート番号 (389) が使用されます。
- 属性が指定されていないため、検索はすべての属性を返します。
- 検索条件が指定されていないため、検索はベースエントリー dc=example,dc=com に制限されます。
- フィルターが指定されていないため、ディレクトリーはデフォルトのフィルター (objectclass=*) を使用します。
例 2
以下の LDAP URL は、DN dc=example,dc=com を使用してエントリーの postalAddress
属性を取得します。
ldap://ldap.example.com/dc=example,dc=com?postalAddress
- 検索条件が指定されていないため、検索はベースエントリー dc=example,dc=com に制限されます。
- フィルターが指定されていないため、ディレクトリーはデフォルトのフィルター (objectclass=*) を使用します。
例 3
以下の LDAP URL は、Barbara Jensen のエントリーの cn
属性、mail
属性、および telephoneNumber
属性を取得します。
ldap://ldap.example.com/cn=Barbara%20Jensen,dc=example,dc=com?cn,mail,telephoneNumber
- 検索範囲が指定されていないため、検索はベースエントリー cn=Barbara Jensen,dc=example,dc=com に制限されます。
- フィルターが指定されていないため、ディレクトリーはデフォルトのフィルター (objectclass=*) を使用します。
例 4
以下の LDAP URL は、姓 Jensen を持ち、dc=example,dc=com 下のレベルにあるエントリーの検索を指定します。
ldap://ldap.example.com/dc=example,dc=com??sub?(sn=Jensen)
- 属性が指定されていないため、検索はすべての属性を返します。
- 検索範囲は sub であるため、検索にはベースエントリー dc=example,dc=com と、ベースエントリー下の全レベルでエントリーが含まれます。
例 5
以下の LDAP URL は、dc=example,dc=com 下 1 レベル下にあるすべてのエントリーレベルに対するオブジェクトクラスの検索を指定します。
ldap://ldap.example.com/dc=example,dc=com?objectClass?one
- 検索範囲は one であるため、検索にはベースエントリー dc=example,dc=com の 1 レベル下に全エントリーが含まれます。検索範囲にはベースエントリーが含まれません。
- フィルターが指定されていないため、ディレクトリーはデフォルトのフィルター (objectclass=*) を使用します。
付録D 国際化
D.1. ローカルの概要
- 照合順序。照合順序は、特定の言語の文字をどのようにソートするかについて、言語および文化に固有の情報を提供します。アルファベットの文字の順序、アクセントのある文字とアクセントのない文字を比較する方法、文字列を比較するときに無視できる文字があるかどうかなどを識別します。照合順序では、言語が読み取られる方向 (左から右、右から左、または上と下) など、言語に関する文化固有の情報も考慮されます。
- 文字タイプ。文字タイプは、アルファベット文字を数字またはその他の文字と区別します。たとえば、ある言語では、パイプ (|) 文字は句読点と見なされますが、他の言語ではアルファベットと見なされます。さらに、大文字への大文字のマッピングを定義します。
- 通貨形式。通貨形式は、特定の地域で使用される通貨記号、その記号がその値の前後にあるかどうか、および通貨単位がどのように表されるかを指定します。
- 時刻/日付の形式。時刻と日付の形式は、その地域の時刻と日付の慣習的な形式を示しています。日時形式は、日付が mm/dd/yy (月、日、年) または dd/mm/yy (日、月、年) の形式で、特定の言語の曜日と日付を指定します。たとえば、1996 年 1 月 10 日の日付は、チェコ語では 10. leden 1996、およびフランス語では 10 janvier 1996 と表示されます。
D.2. サポート対象のロケール
/etc/dirsrv/config/slapd-collations.conf
ファイルを参照してください。
D.3. サポートされる言語サブタイプ
言語タグ | 言語 |
---|---|
af | アフリカーンス語 |
be | ベラルーシ語 |
bg | ブルガリア語 |
ca | カタロニア語 |
cs | チェコ語 |
da | デンマーク語 |
de | ドイツ語 |
el | ギリシャ語 |
en | 英語 |
es | スペイン語 |
eu | バスク語 |
fi | フィンランド語 |
fo | フェロー語 |
fr | フランス語 |
ga | アイルランド語 |
gl | ガリシア語 |
hr | クロアチア語 |
hu | ハンガリー語 |
id | インドネシア語 |
is | アイスランド語 |
it | イタリア語 |
ja | 日本語 |
ko | 韓国語 |
nl | オランダ語 |
no | ノルウェー語 |
pl | ポーランド語 |
pt | ポルトガル語 |
ro | ルーマニア語 |
ru | ロシア語 |
sk | スクロバキア語 |
sl | スロベニア語 |
sq | アルバニア語 |
sr | セルビア語 |
sv | スウェーデン語 |
tr | スウェーデン語 |
uk | ウクライナ語 |
zh | 中国語 |
D.4. 国際化されたディレクトリーの検索
D.4.1. マッチングルールの形式
- 検索のベースとなるロケールの照合順序の OID として。
- 検索のベースとなる照合順序に関連付けられた言語タグとして。
- 照合順序の OID および関係演算子を表す接尾辞として。
- 照合順序に関連付けられた言語タグと、関係演算子を表す接尾辞として。
D.4.1.1. マッチングルールでの OID の使用
/etc/dirsrv/config/slapd-collations.conf
ファイルを参照してください。
attr:OID:=(relational_operator value)
departmentNumber
属性を検索するには、次のフィルターを使用します。
departmentNumber:2.16.840.1.113730.3.3.2.46.1:=>= N4709
D.4.1.2. マッチングルールに言語タグの使用
/etc/dirsrv/config/slapd-collations.conf
ファイルを参照してください。
attr:language-tag:=(relational_operator value)
cn:es:== estudiante
D.4.1.3. マッチングルールでの OID および Suffix の使用
attr: OID+suffix:=value
mozldap
ユーティリティーでのみサポートされ、ldapsearch などの OpenLDAP ユーティリティーではサポートされません。
businessCategory
属性を選択するには、次のフィルターを使用します。
businessCategory:2.16.840.1.113730.3.3.2.7.1.3:=softwareprodukte
/etc/dirsrv/config/slapd-collations.conf
ファイルを参照してください。リレーショナル演算子とそれらの同等の接尾辞の一覧は、表D.2「検索タイプ、演算子、および接尾辞」を参照してください。
D.4.1.4. 一致するルールに対する言語タグと接尾辞の使用
attr: language-tag+suffix:=value
mozldap
ユーティリティーでのみサポートされ、ldapsearch などの OpenLDAP ユーティリティーではサポートされません。
sn:fr.4:=La Salle
/etc/dirsrv/config/slapd-collations.conf
ファイルを参照してください。リレーショナル演算子とそれらの同等の接尾辞の一覧は、表D.2「検索タイプ、演算子、および接尾辞」を参照してください。
D.4.2. サポートされる検索タイプ
- 等号 (=)
- 部分文字列 (*)
- より大きい (>)
- 以上 (>=)
- より小さい (<)
- 以下 (<=)
検索タイプ | 演算子 | 接尾辞 |
---|---|---|
より小さい | < | .1 |
より小さいか等しい | <= | .2 |
等号 | = | .3 |
より大きいか等しい | >= | .4 |
より大きい | > | .5 |
部分文字列 | * | .6 |
D.4.3. 国際検索の例
D.4.3.1. less-than の例
sn:2.16.840.1.113730.3.3.2.15.1:=< Marquez ... sn:es:=< Marquez ... sn:2.16.840.1.113730.3.3.2.15.1.1:=Marquez ... sn:es.1:=Marquez
D.4.3.2. less-Than または Equal-to の例
roomNumber:2.16.840.1.113730.3.3.2.23.1:=<= CZ422 ... roomNumber:hu:=<= CZ422 ... roomNumber:2.16.840.1.113730.3.3.2.23.1.2:=CZ422 ... roomNumber:hu.2:=CZ422
D.4.3.3. 等価性の例
businessCategory
属性を検索するには、次のマッチングルールフィルターのいずれかが機能します。
businessCategory:2.16.840.1.113730.3.3.2.7.1:==softwareprodukte ... businessCategory:de:== softwareprodukte ... businessCategory:2.16.840.1.113730.3.3.2.7.1.3:=softwareprodukte ... businessCategory:de.3:=softwareprodukte
D.4.3.4. より大きいか等しいの例
locality:2.16.840.1.113730.3.3.2.18.1:=>= Québec ... locality:fr:=>= Québec ... locality:2.16.840.1.113730.3.3.2.18.1.4:=Québec ... locality:fr.4:=Québec
D.4.3.5. より大きいの例
mailHost:2.16.840.1.113730.3.3.2.5.1:=> schranka4 ... mailHost:cs:=> schranka4 ... mailHost:2.16.840.1.113730.3.3.2.5.1.5:=schranka4 ... mailHost:cs.5:=schranka4
D.4.3.6. 部分文字列の例
uid:2.16.840.1.113730.3.3.2.49.1:=* *ming ... uid:zh:=* *ming ... uid:2.16.840.1.113730.3.3.2.49.1.6:=* *ming .. uid:zh.6:=* *ming
modifiersName
や memberOf
などの DN 値属性を使用する部分文字列検索フィルターは、フィルターに空白文字が 1 つ以上含まれる場合は、エントリーには常に正しく一致しません。
(memberOf=*Domain Administrators*)
(memberOf=cn=Domain Administrators*) ... (memberOf=cn=Domain Administrators,ou=Groups,dc=example,dc=com)
D.5. マッチングルールのトラブルシューティング
# ldapsearch -x -p 389 -D "uid=userID,ou=people,dc=example,dc=com" -W -b "dc=example,dc=com" "sn:2.16.840.1.113730.3.3.2.7.1:=passin" ldapsearch -x -p 389 -D "uid=userID,ou=people,dc=example,dc=com" -W -b "dc=example,dc=com" "sn:de:=passin"
# ldapsearch -x -p 389 -D "uid=userID,ou=people,dc=example,dc=com" -W -b "dc=example,dc=com" "sn:2.16.840.1.113730.3.3.2.7.1.3
:=passin" ldapsearch -x -p 389 -D "uid=userID,ou=people,dc=example,dc=com" -W -b "dc=example,dc=com" "sn:de.3
:=passin"
付録E 管理サーバーの管理
E.1. Red Hat 管理サーバーの概要
- Java ベースの管理コンソール
- Web サーバーとしても機能する管理サーバー
- LDAP ディレクトリーサーバー
図E.1 コンソール、管理サーバー、および Directory Server 間の対話
E.2. 管理サーバー設定
E.2.1. ファイルの場所
E.2.2. 管理コンソールを開く
# /usr/bin/redhat-idm-console
図E.2 ログインボックス
# /usr/bin/redhat-idm-console -a http://localhost:9830
図E.3 管理コンソール
java -version
E.2.3. ログの表示
- アクセスログアクセスログには、管理サーバーからのリクエストおよび応答が表示されます。デフォルトでは、ファイルは
/var/log/dirsrv/admin-serv/access
にあります。 - エラーログ。エラーログは、ログファイルの作成後にサーバーが発生したエラーのメッセージを表示します。また、サーバーの開始時やサーバーにログオンしようとしたユーザーなど、サーバーに関する情報メッセージも含まれます。デフォルトでは、ファイルは
/var/log/dirsrv/admin-serv/error
にあります。
E.2.3.1. コンソールからのログの表示
- Administration Server 管理ウィンドウを開きます。
- Configuration タブをクリックします。
- Logs ディレクトリーを展開し、Access es または Error のいずれかのログファイル名をクリックします。
E.2.3.2. コマンドラインでのログの表示
/var/log/dirsrv/admin-serv/error
です。アクセスログを表示するには、vi などのエディターで開きます 。
ip_address - bind_DN [timestamp -0500] "GET|POST cgi" HTTP_response bytes
例E.1 アクセスログの例
127.0.0.1 - cn=Directory Manager [23/Dec/2008:19:32:52.157345975 -0500] "GET /admin-serv/authenticate HTTP/1.0" 200 338 192.168.123.121 - cn=Directory Manager [23/Dec/2008:19:33:14.453724501 -0500] "POST /admin-serv/tasks/Configuration/ServerSetup HTTP/1.0" 200 244 192.168.123.121 - cn=Directory Manager [23/Dec/2008:19:33:16.573485244 -0500] "GET /admin-serv/tasks/Configuration/ReadLog?op=count&name=access HTTP/1.0" 200 10
/var/log/dirsrv/admin-serv/errors
です。エラーログを表示するには、vi などのエディターで開きます 。
[timestamp] [severity] [client ip_address error_message
例E.2 エラーログの例
[24/Mar/2017:11:14:27.110314677 +0100] - NOTICE - ldbm_back_start - total cache size: 417775616 B; [24/Mar/2017:11:14:27.165466639 +0100] - INFO - dblayer_start - Resizing db cache size: 1519206400 -> 132562944 [24/Mar/2017:11:14:27.650899322 +0100] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests [24/Mar/2017:11:14:29.620268885 +0100] - WARN - modify_config_dse - Modification of attribute "aci" is not allowed, ignoring!
E.2.3.3. コンソールでのログ名の変更
- Administration Server 管理ウィンドウを開きます。
- Configuration タブをクリックします。
- 左側のパネルで Logs をクリックします。
- 右側の Logs ウィンドウで、新規ログファイル名を入力します。警告ログファイルへのパスは絶対的なものであり、変更することはできません。
- OK をクリックして変更を保存します。
- Tasks タブを開き、 ボタンをクリックしてサーバーを再起動して変更を適用します。
E.2.3.4. コマンドラインでのログ場所の変更
/var/log/dirsrv/admin-serv
のデフォルトの場所がアプリケーションのニーズを満たさない場合は、場所を変更できます。
console.conf
ファイルです。ログ設定の変更には、両方の設定を変更する必要があります。
- Configuration Directory Server で Administration Server 設定エントリーを編集します。
- Administration Server エントリーの名前を取得します。Administration Server エントリーには特別なオブジェクトクラス nsAdminConfig があるため、そのオブジェクトクラスを使用して DN を取得することができます。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
-b "o=NetscapeRoot" "(objectclass=nsAdminConfig)" dn
version:1 dn: cn=configuration,cn=admin-serv-example,cn=Red Hat Administration Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot - Administration Server エントリーは、ldapmodify を使用して編集できます。アクセスおよびエラーログ設定は、それぞれ
nsAccessLogs
属性およびnsErrorLogs
属性に保存されます。以下に例を示します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=configuration,cn=admin-serv-example,cn=Red Hat Administration Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot changetype:modify replace:nsAccessLog nsAccessLog:/var/log/dirsrv/admin-serv/access_new
Enter を 2 回押して 操作を送信し、Control +C を押して ldapmodify を閉じます。
- Administration Server 設定ディレクトリーを開きます。
# cd /etc/dirsrv/admin-serv
console.conf
ファイルを編集します。アクセスログの場合は、CustomLog パラメーター のパスおよびファイル名を編集します。エラーログの場合は、ErrorLog パラメーターのパスおよびファイル名を編集します。CustomLog /var/log/dirsrv/admin-serv/access_new common ErrorLog /var/log/dirsrv/admin-serv/error_new
アクセスログパスの後に 一般的な 用語を残します。これは、アクセスログが Common Log Format にあることを意味します。- 管理サーバーを再起動します。
# systemctl restart dirsrv-admin.service
E.2.3.5. IP アドレスの代わりにホスト名を表示するログの設定
管理コンソールの console.conf
ファイルを編集します。# cd /etc/dirsrv/admin-serv # vim console.conf
- HostnameLookups パラメーターを on に設定します。デフォルトでは、これはオフになっており、IP アドレスはホスト名ではなくログに記録されます。
HostnameLookups on
E.2.4. ポート番号の変更
E.2.4.1. コンソールのポート番号の変更
- Administration Server 管理ウィンドウを開きます。
- Configuration タブをクリックします。
- Network タブをクリックします。
- Port フィールドに Administration Server インスタンスのポート番号を入力します。管理サーバーのポート番号には、デフォルトの 9830 があります。
- OK をクリックします。
- Tasks タブを開き、 ボタンをクリックしてサーバーを再起動して変更を適用します。
- コンソールを閉じ、接続 URL に新しい管理サーバーポート番号を指定して、コンソールを再起動します。
E.2.4.2. コマンドラインでのポート番号の変更
console.conf
ファイルです。ポート番号を変更するには、両方の設定を変更する必要があります。
- Configuration Directory Server で Administration Server 設定エントリーを編集します。
- Administration Server エントリーの名前を取得します。Administration Server エントリーには特別なオブジェクトクラス nsAdminConfig があるため、そのオブジェクトクラスを使用して DN を取得することができます。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
-b "o=NetscapeRoot" "(objectclass=nsAdminConfig)" dn
version:1 dn: cn=configuration,cn=admin-serv-example,cn=Red Hat Administration Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot - Administration Server エントリーは、ldapmodify を使用して編集できます。ポート番号は
nsServerPort
属性に設定されます。以下に例を示します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=configuration,cn=admin-serv-example,cn=Red Hat Administration Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot changetype:modify replace:nsServerPort nsServerPort:10030
Enter を 2 回押して 操作を送信し、Control +C を押して ldapmodify を閉じます。
- Administration Server 設定ディレクトリーを開きます。
# cd /etc/dirsrv/admin-serv
console.conf
ファイルの Listen パラメーターを編集します。Listen 0.0.0.0:10030
- 管理サーバーを再起動します。
# systemctl restart dirsrv-admin.service
E.2.5. ホスト制限の設定
E.2.5.1. コンソールでのホスト制限の設定
- Administration Server 管理ウィンドウを開きます。
- Configuration タブをクリックします。
- Network タブをクリックします。
- 接続制限 エリアには、管理サーバーへの接続が許可されているホストの一覧が表示されます。ドロップダウンリストは、リストエントリーが DNS 名または IP アドレスで追加されるかどうかを指定します。この一覧は最初にホスト名で評価され、次に IP アドレスで評価されます。
- 追加 ボタンをクリックして、許可されたコンピューターの一覧に別のホストを追加します。ホスト名を追加するには、上部のドロップダウンリストで、許可するホスト名 を読み取るようにしてください。IP アドレスを追加するには、許可する IP アドレス を選択します。
- ホスト名または IPv4 アドレスまたは IPv6 アドレスのいずれかでホスト情報を入力します。* ワイルドカードを使用すると、ホストのグループを指定できます。たとえば 、*.example.com は、example .com ドメイン内のすべてのマシンがインスタンスにアクセスできるようにします。205.12.* を入力すると、IP アドレスが 205.12 で始まるすべてのホストがインスタンスにアクセスできるようになります。IP アドレスの制限を指定する場合には、3 つすべて分離ドットを含めます。これがない場合、Administration Server はエラーメッセージを返します。
- OK をクリックして Add... を閉じてから、保存 ボタンをクリックして新規ホストを保存します。
- Tasks タブを開き、 ボタンをクリックしてサーバーを再起動して変更を適用します。
E.2.5.2. コマンドラインでのホスト制限の設定
nsAdminAccessAddresses
と nsAdminAccessHosts
の 2 つの属性があります。
- Administration Server エントリーの名前を取得します。Administration Server エントリーには特別なオブジェクトクラス nsAdminConfig があるため、そのオブジェクトクラスを使用して DN を取得することができます。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
-b "o=NetscapeRoot" "(objectclass=nsAdminConfig)" dn
version:1 dn: cn=configuration,cn=admin-serv-example,cn=Red Hat Administration Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot - IP アドレスベースの制限を設定するには、
nsAdminAccessAddresses
属性を編集します。IPv4 アドレスまたは IPv6 アドレスのいずれかを使用できます。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=configuration,cn=admin-serv-example,cn=Red Hat Administration Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot changetype:modify replace:nsAdminAccessAddresses nsAdminAccessAddresses:72.5.*.*
Enter を 2 回押して 操作を送信し、Control +C を押して ldapmodify を閉じます。nsAdminAccessAddresses
値では、ワイルドカードを使用して範囲を許可することができます。IPv4 アドレスまたは IPv6 アドレスのいずれかを使用できます。たとえば、すべての IP アドレスを許可するには、以下を実行します。nsAdminAccessAddresses:*
ローカルネットワーク上のアドレスのサブセットのみを許可するには、以下を実行します。nsAdminAccessAddresses:192.168.123.*
- ホスト名またはドメインベースの制限を設定するには、
nsAdminAccessHosts
属性を編集します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=configuration,cn=admin-serv-example,cn=Red Hat Administration Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot changetype:modify replace:nsAdminAccessHosts nsAdminAccessHosts:*.example.com
Enter を 2 回押して 操作を送信し、Control +C を押して ldapmodify を閉じます。 - Administration Server を再起動して変更を適用します。
# systemctl restart dirsrv-admin.service
E.2.6. 管理ユーザーのパスワードの変更
uid=userID,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot
/etc/dirsrv/admin-serv/admpw のエンティティーとしてのみ存在します
。
/etc/dirsrv/admin-serv/admpw
ファイルに保存されます。以下に例を示します。
admin:{SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
admpw
ファイルで直接変更することはできません。ユーザー名はこのファイルで変更できますが、最初にコンソールでパスワードが更新されない限り、コンソールへのログインには使用できません。このため、管理コンソールからのみ管理サーバー管理者のユーザー名およびパスワードを編集することをお勧めします。
- Administration Server 管理ウィンドウを開きます。
- Configuration タブをクリックします。
- Access タブをクリックします。
- admin ユーザーまたはパスワードを変更します。ユーザー名は、管理サーバーにログインするために提供された ID です。
- Save をクリックします。
E.2.7. TLS の使用
- 証明書要求の生成および送信。
- 証明書の受信およびインストール。
- 証明書を発行した認証局(CA)を信頼すること。
- 管理サーバー設定を変更して TLS 接続を許可します。
E.2.7.1. 管理サーバーの証明書の管理
- 管理サーバーと同じ Directory Server の証明書を使用するには、「管理サーバーの Directory Server プライベートキーおよび証明書の使用」 を参照してください。
- 管理サーバーと同じ Directory Server の証明書を使用するには、「管理サーバーの Directory Server プライベートキーおよび証明書の使用」 を参照してください。
- グラフィカルユーザーインターフェース。Directory Server コンソールではなく、管理コンソールの 証明書の管理 メニューで手順を実行します。
- Network Security Services(NSS)データベースを管理する場合は、
/etc/
/ コマンドを使用します。dirsrv/slapd-instance_name/ ディレクトリーの代わりに /etc
/dirsrv/admin-serv
E.2.7.1.1. 管理サーバーの Directory Server プライベートキーおよび証明書の使用
Certificate Request Wizard
が渡されると、自動生成された秘密鍵は Directory Server の PKI データベースに保存されます。ただし、同じ秘密鍵が両方のデータベースに存在しないため、発行した証明書は他のデータベースにインストールできません。
- 管理サーバーをシャットダウンします。
# systemctl stop dirsrv-admin
- Directory Server をシャットダウンします。
# systemctl stop dirsrv@instance
- Directory Server NSS データベースの内容を一覧表示します。
# certutil -L -d /etc/dirsrv/admin-serv/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Demo CA CT,, server-cert u,u,u
- Directory Server の PKI データベースから、server-cert という名前の秘密鍵と証明書をエクスポートします。
# pk12util -o /tmp/keys.pk12 -n server-cert -d /etc/dirsrv/slapd-instance/ Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: Re-enter password: pk12util: PKCS12 EXPORT SUCCESSFUL
Directory Server のキーストアパスワードを入力します。オプションで、プロンプトが表示されたら、一時的にエクスポートされたファイルの新しいパスワードを入力します。 - 秘密鍵および証明書を管理サーバーの PKI データベースにインポートします。
# pk12util -i /tmp/keys.pk12 -d /etc/dirsrv/admin-serv/ Enter a password which will be used to encrypt your keys. The password should be at least 8 characters long, and should contain at least one non-alphabetic character. Enter new password: Re-enter password: Enter password for PKCS12 file: pk12util: PKCS12 IMPORT SUCCESSFUL
pk12util は、管理サーバーのキーストアのパスワードを設定するよう要求します。事前にこのデータベースに 1 つ設定されていた場合は、代わりにこのパスワードを入力するよう求められます。前の手順でエクスポートしたファイルにパスワードを設定すると、このパスワードを入力するよう求められます。 - 一時的にエクスポートされたファイルを削除します。
# rm /tmp/keys.pk12
- Demo CA を信頼します。
# certutil -M -d /etc/dirsrv/admin-serv/ -n "Demo CA" -t CT,,
- Directory Server を起動します。
# systemctl start dirsrv@instance
- 管理サーバーを起動します。
# systemctl start dirsrv-admin
E.2.7.2. TLS の有効化
E.2.7.3. 管理サーバーのパスワードファイルの作成
Starting dirsrv-admin: Please enter password for "internal" token:
- 以下の内容で
/etc/dirsrv/admin-serv/password.conf
ファイルを作成します。- FIPS(Federal Information Processing Standard)モードが無効になっているシステムの場合:
internal:password
- FIPS モードが有効になっているシステムの場合は、次のコマンドを実行します。
internal:password NSS FIPS 140-2 Certificate DB:password
このファイルの行は、token_name:password の形式を使用します。NSS ソフトウェア暗号モジュール(デフォルトのソフトウェアデータベース)では、トークンは常にinternal
と呼ばれます。FIPS モードを有効にすると、証明書データベースの追加トークンはNSS FIPS 140-2 Certificate DB
と呼ばれます。 - 他のユーザー(mode
0400
)にはアクセスなく、管理サーバーユーザーがパスワードファイルを所有し、admin Server ユーザーで読み取り専用に設定する必要があります。注記Administration Server ユーザー ID を確認するには、Administration Server 設定ディレクトリーでgrep
を実行します。# grep "^User" /etc/dirsrv/admin-serv/console.conf User dirsrv
パーミッションを設定するには、以下を入力します。# chown dirsrv:root /etc/dirsrv/admin-serv/password.conf # chmod 0400 /etc/dirsrv/admin-serv/password.conf
/etc/dirsrv/admin-serv/nss.conf
ファイルを編集し、新しいパスワードファイルの場所を参照します。# Pass Phrase Dialog: # Configure the pass phrase gathering process. # The filtering dialog program (`builtin' is a internal # terminal dialog) has to provide the pass phrase on stdout. NSSPassPhraseDialog file://etc/dirsrv/admin-serv/password.conf
- 管理サーバーを再起動します。
# systemctl restart dirsrv-admin.service
E.2.8. Directory Server 設定の変更
E.2.8.1. 設定ディレクトリーホストまたはポートの変更
- Administration Server 管理ウィンドウを開きます。
- Configuration タブをクリックします。
- Configuration DS タブをクリックします。
- Configuration Directory Server 接続情報を設定します。
- LDAP ホストは、設定 Directory Server マシンのホスト名、IPv4、または IPv6 アドレスです。
- LDAP Port は Directory Server インスタンスに使用するポート番号です。通常の LDAP ポートは 389 で、デフォルトの LDAPS(セキュア)ポート番号は 636 です。
- Secure Connection チェックボックスにチェックを入れて、セキュアなポートを使用します。このボックスをチェックする前に、設定 Directory Server が TLS を有効にしていることを確認します。
- Save をクリックします。
E.2.8.2. ユーザーディレクトリーホストまたはポートの変更
- Administration Server 管理ウィンドウを開きます。
- Configuration タブをクリックします。
- User DS タブをクリックします。
- User Directory Server の接続情報を設定します。
- ユーザーディレクトリー情報を編集します。Use Default User Directory ラジオボタンは、ドメインに関連付けられたデフォルトのユーザーディレクトリーを使用します。複数の Directory Server インスタンスを使用するか、別のインスタンスを使用するには、Set User Directory ラジオボタンを選択して、必要な情報を設定します。
- LDAP ホストおよびポート フィールドは、IPv4 アドレスまたは IPv6 アドレスで hostname:port または ip_address:port 形式を使用して、ユーザーディレクトリーインスタンスの場所を指定します。認証およびその他のディレクトリー機能用に、ユーザーディレクトリーに複数の場所を設定できます。各場所はスペースで区切ります。以下に例を示します。
server.example.com:389 alt.example.com:389
注記LDAP ホストおよびポート フィールドに複数の場所 を指定すると、残りのフィールドの設定はそれらのインスタンスすべてに適用されます。 - TLS を使用してユーザーディレクトリーに接続するには、Secure Connection ボックスにチェックを入れます。Directory Server がすでに TLS を使用するように設定されている場合のみこれ を選択します。
- User Directory サブツリー を指定します。以下に例を示します。
dc=example,dc=com
LDAP Host および Port フィールドに一覧表示されるすべての場所には、そのサブツリーが含まれる必要があり、サブツリーにはユーザー情報が含まれている必要があります。 - 必要に応じて、バインド DN と、ユーザーディレクトリーを接続するユーザーの Password を入力します。
- Save をクリックします。
付録F Admin Express の使用
F.1. Admin Express でのサーバーの管理
- サーバーの停止および起動
- サーバーのアクセス、エラー、監査ログの確認
- Directory Server との間のレプリケーションの進捗および情報の監視
F.1.1. Admin Express を開く
http://ldap.example.com:9830/
https://ldap.example.com:9830/
F.1.2. サーバーの起動と停止
図F.1 サーバーの停止および停止
F.1.3. サーバーログの表示
- Admin Express ページで、サーバー名の Logs リンクをクリックします。
- 表示するログタイプ、返す行数、検索する文字列数を選択し、OK をクリックします。
図F.2 ログの確認
F.1.4. サーバー情報の表示
図F.3 サーバー情報の確認
/etc/dirsrv/slapd-instance/dse.ldif
ファイルにあります。管理サーバー情報は、/etc/dirsrv/admin-serv
ディレクトリーの .conf
ファイルにあります。
F.2. Admin Express の設定
F.2.1. Admin Express ファイルの場所
ディレクトリー | 詳細 |
---|---|
/etc/dirsrv/admin-serv/ | 管理サーバーを定義し、Web サーバーを設定する local .conf、およびその他の設定ファイルが含まれます。 |
/usr/share/dirsrv/html/ | Admin Express の外観に使用される HTML ファイルとグラフィックが含まれます。 |
F.2.2. Admin Express 設定ファイル
F.2.2.1. 管理サーバーの Welcome ページのファイル
/etc/dirsrv/admin-serv
ディレクトリーにあります。1 つのファイルはフォーマット、著作権テキスト、および一部の Web アプリケーションテキスト( admserv.html
)を設定します。
図F.4 ページ要素の導入
<tr valign="TOP"> <td> </td> <td bgcolor="#9999cc" colspan="4"> <font color="white" size="+1"><font face="Verdana, sans-serif">Services for Administrators</font></font></td> <td> </td> </tr> <tr valign="TOP"> <td> </td> <td colspan="4"> <table border="0" cellspacing="0" cellpadding="0"> <tr valign="TOP"> <td><img src="/icons/spacer.gif" width="6" height="6"></td> <td></td> </tr> <!-- INCLUDEIFEXISTS admserv_dsgw.html -->
F.2.2.2. Replication Status Appearance のファイル
- ページの本文
/usr/share/dirsrv/html/monreplication.html
- ページの
/usr/share/dirsrv/html/htmladmin.html
図F.5 レプリケーション設定のページ要素の監視
- ページの本文。レプリケーション監視スクリプト
/usr/bin/repl-monitor.pl
で設定されます。 - オプションで、レプリケーション監視の設定ファイル。この設定ファイルは、時間ラグ色を [colors] セクションで設定できます。
- ページの
/usr/share/dirsrv/html/htmladmin.html
図F.6 レプリケーションビューのページ要素の監視
#Print the header of consumer print "\n<tr class=bgColor16>\n"; print "<th nowrap>Receiver</th>\n"; print "<th nowrap>Time Lag</th>\n"; print "<th nowrap>Max CSN</th>\n"; .... print "</tr>\n";
style.css
と同じです。これらは Perl スクリプトで編集することも、スタイルシートの参照のコメントを解除して CSS ファイルを指定して編集できます。以下に例を示します。
# print the HTML header
print "Content-type: text/html\n\n";
print "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2//EN\"><html>\n";
print "<head><title>Replication Status</title>\n";
# print "<link type=text/css rel=stylesheet href=\"master-style.css\">\n";
print "<style text/css>\n";
print "Body, p, table, td, ul, li {color: #000000; font-family: Arial, Helvetica, sans-serif; font-size: 12px;}\n";
print "A {color:blue; text-decoration: none;}\n";
print "BODY {font-family: Arial, Helvetica, sans-serif}\n";
print "P {font-family: Arial, Helvetica, sans-serif}\n";
print "TH {font-weight: bold; font-family: Arial, Helvetica, sans-serif}\n";
print "TD {font-family: Arial, Helvetica, sans-serif}\n";
print ".bgColor1 {background-color: #003366;}\n";
print ".bgColor4 {background-color: #cccccc;}\n";
print ".bgColor5 {background-color: #999999;}\n";
print ".bgColor9 {background-color: #336699;}\n";
print ".bgColor13 {background-color: #ffffff;}\n";
print ".bgColor16 {background-color: #6699cc;}\n";
print ".text8 {color: #0099cc; font-size: 11px; font-weight: bold;}\n";
print ".text28 {color: #ffcc33; font-size: 12px; font-weight: bold;}\n";
print ".areatitle {font-weight: bold; color: #ffffff; font-family: Arial, Helvetica, sans-serif}\n";
print ".page-title {font-weight: bold; font-size: larger; font-family: Arial, Helvetica, sans-serif}\n";
print ".page-subtitle {font-weight: bold; font-family: Arial, Helvetica, sans-serif}\n";
print "</style></head>\n<body class=bgColor4>\n";
F.2.2.3. サーバー情報ページのファイル
- ページ
/usr/share/dirsrv/html/viewdata.html
- ページの
/usr/share/dirsrv/html/htmladmin.html
図F.7 サーバー情報のページ要素
viewdata.html
ファイルは、2 つのディレクティブのみを使用してサーバーデータを挿入したり、その他のディレクティブを使用して他の情報を挿入したりすることが非常に簡単です。Administration Server では、SHOW_DATA ディレクティブは /etc/dirsrv/admin-serv/local.conf
ファイルから情報を取得します。Directory Server では、/etc/dirsrv/slapd-instance/dse.ldif
ファイルからデータを取得します。ID_TITLE はサーバーインスタンスの名前です。
<body text="#000000" bgcolor="#FFFFFF" link="#666699" vlink="#666699" alink="#333366"> <br> <table BORDER=0 CELLSPACING=2 CELLPADDING=2 WIDTH="100%"> <!-- ID_TITLE --> <p> <!-- SHOW_DATA --> <p> <font face="PrimaSans BT, Verdana, sans-serif"><font size=-1>Additional Information:</font></font> <p> <!-- CHECK_UPGRADE --> <p> <!-- SHOW_URL --> </table> <!-- HELPBUTTON --> </body>
F.2.2.4. サーバーログページのファイル
- ページ
/usr/share/dirsrv/html/viewlog.html
- ページの
/usr/share/dirsrv/html/htmladmin.html
図F.8 ログ表示ページ要素
<form method=GET action=ViewLog> <font face="PrimaSans BT, Verdana, sans-serif"><font size=-1> <!-- BEGINELEM --> <!-- ELEM txt="Log to view: " --> <!-- LOG_TO_VIEW --> .... <!-- SUBMIT --> </font></font> </form>
F.2.3. Admin Express ディレクティブ
ディレクティブ | 詳細 | 例 |
---|---|---|
ACCESS_LOG | サーバーログファイルを挿入します。 | <!-- ACCESS_LOG --> |
ADMURL | <!-- ADMURL --> | |
BEGINELEM | フォームの入力要素のオープンとマークします。これは、常に ENDELEM のペアです。 | <!-- BEGINELEM --> |
CHECK_UPGRADE | <!-- CHECK_UPGRADE --> | |
ELEM | テキスト要素を挿入します。これには、使用するテキストを定義する引数である txt= が 1 つあります。 | <!-- ELEM txt="Field name here: " --> |
ELEMADD | テキスト要素を挿入します。これには、使用するテキストを定義する引数である txt= が 1 つあります。 | <!-- ELEMADD txt="Field name here: " --> |
ENDELEM | フォームの入力要素の最後をマークします。これは、BEGINELEM と常にペアになります。 | <!-- ENDELEM --> |
HELP_BUTTON | コンテキスト固有のヘルプを開くボタンを挿入します。 | <!-- HELP_BUTTON --> |
HELPLINK | 一般的な Admin Express ヘルプファイルへのリンクを挿入します。 | <!-- HELPLINK --> |
HIDDEN_ID | <!-- HIDDEN_ID --> | |
ID_TITLE | admin-serv や example などのサーバーインスタンスの名前を挿入します(Directory Server インスタンス名が slapd-example の場合)。 | <!-- ID_TITLE --> |
INCLUDEIFEXISTS | HTML ファイルの内容を挿入します。挿入されたファイルには、テキストと HTML マークアップの両方を含める必要があります。 | <!-- INCLUDEIFEXISTS "file.html" --> |
LOG_TO_VIEW | 表示可能なログの種類でドロップダウンメニューを挿入します。 | <!-- LOG_TO_VIEW --> |
NUM_TO_VIEW | フォームフィールドを挿入し、返す行数を設定します。 | <!-- NUM_TO_VIEW --> |
REFRESHINTERVAL | フォームフィールドを挿入し、レプリケーション監視の更新間隔(秒単位)を設定します。 | <!-- REFRESHINTERVAL --> |
SERVHOST | <!-- SERVHOST --> | |
SERVPORT | <!-- SERVPORT --> | |
SHOW_DATA | ポート番号、インストール日、ビルド番号など、設定ファイルからサーバーデータを挿入します。 | <!-- SHOW_DATA --> |
SHOW_URL | <!-- SHOW_URL --> | |
SITEROOT | <!-- SITEROOT --> | |
STRING_TO_VIEW | ログの検索文字列を設定するのに使用するフォームフィールドを挿入します。 | <!-- STRING_TO_VIEW --> |
送信 | 3 つのボタンセットを挿入する: フォームを保存または送信してください。フォームをリセットして、ヘルプトピックを開きます。 | <!-- SUBMIT --> |
付録G コンソールの使用
G.1. Directory Server コンソールの概要
G.1.1. コンソール、Directory Server、および管理サーバーの機能
図G.1 Red Hat 管理コンソールインターフェース
図G.2 Red Hat 管理コンソールを使用したシンプルなシステム
図G.3 より詳細な複雑なシステム
G.1.2. Red Hat 管理コンソールメニュー
メニュー | 詳細 |
---|---|
コンソール | ウィンドウを閉じるか、セッションを完全に終了したりなど、コンソールセッションを管理します。
|
Edit | 3 つのコンソールすべてに表示設定を設定します。Directory Server コンソールでは、ディレクトリーエントリーまたはテキストをコピー、貼り付け、削除する方法も提供します。 |
表示 | トップバナー、メニュー、サイドナビゲーションペインなど、コンソールウィンドウの特定部分を表示するかどうかを設定します。これにより、現在の表示も更新されます。Directory Server コンソールでは、このメニューはディレクトリーまたは表示するデータベースの一部を設定します。 |
オブジェクト | アクティブオブジェクトで利用可能な操作を提供します。これは、アクティブエリアまたはエントリーの右クリックメニューと同じです。
|
ヘルプ | 現在のコンソールエリアのコンテキスト固有のヘルプを開きます。 |
G.1.3. Red Hat Management Console タブ
- Directory Server インスタンス および管理 サーバーインスタンスを管理するサーバーおよびアプリケーション
- ユーザーおよびグループ。 Directory Server でユーザーエントリーおよびグループエントリーを検索および作成する
G.1.3.1. 「Servers and Applications」タブ
図G.5 「Servers and Applications」タブ
G.1.3.2. ユーザーおよびグループタブ
図G.6 ユーザーおよびグループタブ
G.1.4. サーバー固有のコンソール
G.1.4.1. Directory Server コンソール
図G.7 Directory Server コンソール
- Directory Server インスタンスの起動/停止、データベースのインポートおよびエクスポート、TLS 証明書の管理など、一般的なサーバー操作へのショートカットがある タスク
- SASL および TLS 認証 、 ポート番号、レプリケーション、同期、データベースおよびサフィックス、ロギング、プラグインなど、すべてのサーバー設定を定義する設定
- ユーザーエントリーおよび 全グループエントリー(ロール、サービスクラス、ビュー、およびグループを含む)などのディレクトリー情報にアクセスし、管理します。
- status: サーバーパフォーマンスを監視し、Directory Server およびデータベースに異なる監視およびパフォーマンスカウンターを表示します。
G.1.4.2. 管理コンソール
図G.8 管理コンソール
- タスク (管理サーバーインスタンスの起動および停止、ロギングの設定、TLS 証明書の管理など、一般的なサーバー操作へのショートカットを含む)
- TLS 認証 、 ポート番号、ロギングなどの管理サーバー構成設定や、管理サーバー がディレクトリーサービスに接続するために使用される Configuration Directory Server および User Directory Server 設定など、すべての管理 Server 設定を定義する設定
G.2. コンソールアプリケーションの変更
G.2.1. プロファイルの場所の変更
- トップメニューで Edit をクリックし、Preferences を選択します。
- Settings タブをクリックします。
- 設定を保存する場所のラジオボタンを選択します。
- 設定ディレクトリーでは、設定が Directory Server 設定に保存され、コンソールにどこからでも利用できるようにすることができます。
- お使いのコンピューターのハードディスクでは、設定プロファイルをローカルに保存します。これは主に、ワークステーションやラップトップなど、異なるコンソールで使用される特定の設定が必要な場合に有用です。
- OK をクリックします。
G.2.2. デフォルトのフォント設定の復元
- トップメニューで Edit をクリックし、Preferences を選択します。
- Settings タブをクリックします。
- Restore Defaults ボタンをクリックして、デフォルトの表示設定に戻ります。
- OK をクリックします。
G.2.3. コンソールフォントの変更
- メインの Red Hat Management Console ウィンドウで、Edit メニューから Preferences を選択します。
- Fonts タブをクリックします。
- 新規設定を新規プロファイルとして保存するには、ボタンをクリックして、プロファイル名を入力します。デフォルト(または現在の)プロファイルを編集するには、フォントの編集を開始します。
- スクリーン要素 のコラムで編集する画面要素をクリックし、 ボタンをクリックします。
- その特定の要素のフォントを編集します。フォントファミリー、サイズ、およびフォーマット(太字またはイタリック)の 3 つの設定が可能です。
- OK をクリックしてプロファイルを保存します。
- コンソールを再起動して変更を適用します。
G.2.4. テーブル列の並べ替え
- テーブル見出しをクリックします。
- 左のマウスを押し続けると、その列を新しい場所にドラッグします。他のテーブル列は、自動的に新しい位置に移動します。
- マウスボタンをリリースすると、列 snap を新しい位置に送ります。
G.2.5. メインウィンドウのカスタマイズ
G.2.6. カスタムビューの使用
G.2.6.2. カスタムビューへの切り替え
G.2.6.3. パブリックビューのアクセスパーミッションの設定
- View メニューから Custom View Configuration を選択します。
- 一覧からパブリック Custom View を選択し、Access をクリックします。
- アクセス制御手順を設定します。
G.3. サーバーインスタンスの管理
G.3.1. ドメイン、ホスト、サーバーグループ、およびインスタンス情報の編集
- Servers and Applications タブで、変更するエントリーを選択します。
- 編集 をクリックします。
- インスタンスの情報を編集します。すべてのエントリーには、名前と説明を変更するオプションがあります。インスタンスがインストールされている物理マシンであるホストには、場所を変更するオプションもあります。
- OK をクリックします。
G.3.2. 管理ドメインの作成と削除
G.3.2.1. 管理対象ドメインの作成および編集
- トップメニューで、Console メニューアイテムをクリックし。
- 新しい Directory Server インスタンスの情報など、管理ドメインの情報を入力します。
- OK をクリックします。
G.3.2.2. 管理対象ドメインの削除
- ナビゲーションツリーで削除する管理ドメインを強調表示します。
- トップメニューで、Console メニューアイテムをクリックし。
- 管理ドメイン。
- Yes をクリックします。
G.4. Directory Server のユーザーおよびグループの管理
G.4.1. ユーザーおよびグループの検索
- Users and Groups タブをクリックします。
- 検索条件を入力し、をクリックします。
- 簡単な検索には、テキストボックスにエントリー名 all または part を入力します。すべてのエントリーを返すには、検索フィールドを空白のままにするか、アスタリスク(*)を入力します。
- より複雑な検索またはフォーカス検索には、Advanced ボタンをクリックして検索する属性(
cn
、givenname
、またはou
)、検索の種類、検索用語など)を入力します。検索条件を追加または削除するには、 and 。
- Search をクリックします。結果はリストボックスに表示されます。
- Users and Groups タブをクリックします。
- トップメニューでメニューアイテムを選択し、 を選択します。
- ユーザーディレクトリーの情報を入力します。
- ユーザーディレクトリーホスト。Directory Server インスタンスの完全修飾ホスト名。
- ユーザーディレクトリー ポートおよび セキュアな接続接続のポート番号と、これが TLS(LDAPS)であるかどうか。
- ユーザーディレクトリーサブツリー。ディレクトリーを検索するサブツリーの DN です。たとえば、サブツリーの場合は dc=example,dc=com (ベース DN または ou=Marketing, dc=example,dc=com )になります。
- バインド DN および バインドパスワード。ディレクトリーへの認証に使用する認証情報。
- OK をクリックします。
G.4.2. ディレクトリーエントリーの作成
G.4.2.1. ディレクトリーおよび管理ユーザー
- Directory Server ユーザーは、ボタンをクリックしてから オプションをクリックすると追加されます。一方、管理者は オプションを選択すると作成されます。
- 管理者は ou=Groups,ou=Topology,o=NetscapeRoot に自動的に追加されます。
- Users and Groups タブをクリックします。
- User を選択します。ボタンをクリックし、または、トップメニューでオプションを開き、 を選択します。
- エントリーが作成されるディレクトリーツリーにあるものを選択します。注記管理者の作成時に、通常の Directory Server ユーザーとともにユーザーを追加する
ou
を選択するオプションはありません。これは、管理者が admin ユーザーで ou=Groups,ou=Topology,o=NetscapeRoot に追加されるためです。ビューがディレクトリーに追加されている場合は、エントリーをou
またはビューに追加できます。 - Create User ウィンドウで、ユーザー情報を入力します。Common Name フィールドおよび User ID フィールドには、First Name フィールドと Last Name フィールドに結合された値が自動的に入力されます。これらの最初、姓、および共通名フィールドは必須です。Directory Server とコンソールにログインできるパスワードも必要ですが、必須の属性ではありません。
- 必要に応じて、左側の Languages リンクをクリックし、代替言語を選択して、共通の属性に対して国際化された値を入力します。このオプションを使用すると、国際ユーザーは英語以外の言語を選択でき、優先言語でその名前を表すことができます。pronunciation 属性を使用すると、国際名属性に対する電話番号検索が可能になります。
- OK をクリックします。
G.4.2.2. グループ
- Users and Groups タブをクリックします。
- Group を選択します。ボタンをクリックし、または、トップメニューでオプションを開き、 を選択します。
- エントリーが作成されるディレクトリーツリーにあるものを選択します。サブツリーエントリーは、ディレクトリーに追加された場合に
ou
またはビューになります。 - グループの名前と説明を入力します。この時点で、メンバーを追加せずに、新しいグループエントリーを保存できます。をクリックします。
- Members リンクをクリックしてグループにメンバーを追加し、グループメンバーシップ、静的、動的、または証明書のタイプのタブをクリックします 。
- メンバーを設定します。静的グループの場合は、ユーザーを手動で検索して追加します。動的グループの場合は、エントリーの検索に使用する LDAP URL を作成し、証明書グループの場合は、ユーザー証明書サブジェクト名で検索する値を入力します。
G.4.2.3. 組織単位
organizationalUnitName
(ou
)はディレクトリーツリーの新しいサブツリーブランチです。これは、サブエントリーの識別名の一部である ou=People,dc=example,dc=com など、ou
の相対識別名に反映されます。
- Users and Groups タブをクリックします。
- Unit を選択します。ボタンをクリックし、Organizationalまたは、トップメニューでオプションを開き、 を選択します。
- 新しい組織単位を検索するディレクトリーサブツリーを選択します。
- 組織単位情報を記入します。Alias は、フルネームの代わりに使用できる組織単位の代替名を指定します。
- OK をクリックします。
G.4.3. ディレクトリーエントリーの変更
G.4.3.1. エントリーの編集
- 編集するエントリーを検索します。エントリーの検索に関する詳細は、「ユーザーおよびグループの検索」 を参照してください。
- エントリーを選択し、をクリックします。
- エントリー情報を編集し、をクリックして変更を保存します。
G.4.3.2. エントリーの同期属性の許可
- ユーザーを選択または作成し、NT User リンクをクリックします。
- NT アカウントを有効にし、エントリーの同期方法を確認します(つまり、新しいエントリーが作成されるかどうか、および Directory Server を削除する場合に、Active Directory でそのエントリーを削除するかどうか)を確認します。
- OK をクリックします。
G.4.3.3. 管理者エントリーの変更
/usr/share/dirsrv/properties/admpw
に存在します。
G.4.3.3.1. 設定管理者およびパスワードの変更
- Users and Groups で、Advanced をクリックします。
- Configuration Administrator を検索します。Configuration Administrator を入力します。オブジェクトを選択し、デフォルトで管理者のユーザー名である
- 検索結果の一覧から Configuration Administrator を選択し、Edit をクリックします。
- 管理者の
uid
およびパスワードを変更します。uid
は、コンソールにログインしてコマンドを実行するために使用する naming 属性です。
- Users and Groups タブで、トップメニューの メニューをクリックし、 を選択します。
- Bind DN および Bind Password フィールドを Configuration Administrator の新しい情報で更新し、OK をクリックします。
G.4.3.3.2. 管理者パスワードの変更
- Servers and Applications タブで Administration Server を選択し、 をクリックします。
- Configuration タブをクリックし、Access タブを開き ます。
- 新しいパスワードを設定します。警告admin ユーザー名を変更しないでください。
- 管理サーバーを再起動します。
systemctl restart dirsrv-admin.service
G.4.3.3.3. 管理者管理者グループへのユーザーの追加
- Users and Groups タブで、トップメニューの メニューをクリックし、 を選択します。
- 設定情報および Configuration Administrators グループが含まれる o=NetscapeRoot サブツリーに切り替えます。
- Configuration Administrators グループを検索し、Edit をクリックします。
- 編集ウィンドウの左側にある Members リンクをクリックします。
- Add をクリックして、グループに追加するユーザーを検索します。注記o=NetscapeRoot データベースのユーザーだけが Configuration Administrators グループに追加できます。つまり、コンソールを介して追加される場合に、エントリーは管理者として作成する必要があります。「ディレクトリーおよび管理ユーザー」 を参照してください。
G.4.3.4. ディレクトリーからのエントリーの削除
- 削除するエントリーを検索します。エントリーの検索に関する詳細は、「ユーザーおよびグループの検索」 を参照してください。注記すべてのエントリーは、組織ユニットから削除してから削除する必要があります。
- 結果一覧でエントリーを選択し、をクリックします。 をクリックして削除を確定します。
G.5. アクセス制御の設定
G.5.1. Directory Server および管理サーバーのユーザーへの管理者権限の付与
- コンソールのナビゲーションツリーでサーバーを強調表示します。
- Object メニューを選択し、Set Access Permissions を選択します。または、エントリーを右クリックし、Set Access Permissions を選択します。
- Directory Server の Directory Manager と admin の Directory Manager は、Set Permissions Dialog ボックスに記載されていません。をクリックして、サーバーの管理者一覧に新規ユーザーを追加します。管理サーバーの
- ユーザーを検索して管理者として追加します。その結果、選択したユーザーを強調表示し、をクリックして管理者一覧に追加します。ユーザーおよびグループの検索に関する詳細は、「ユーザーおよびグループの検索」 を参照してください。
- OK をクリックして名前を Set Permissions Dialog 一覧に追加し、再度 OK をクリックして変更を保存し、ダイアログを閉じます。
G.5.2. コンソール要素でのアクセスパーミッションの設定
- ユーザーおよびグループタブ(表示)
- ユーザーおよびグループのタブ(編集)
- Topology タブ(編集)
- カスタムビュータブ(編集)
- サーバーセキュリティー(編集)
- 匿名アクセスの有効化
- デフォルトの匿名アクセス
- 設定管理者の変更
- グループ拡張の有効化
- SIE(ホスト)グループパーミッション
- トップメニューでを選択し、 を選択します。
- 一覧から Console 要素を選択し、ボタンをクリックします。
- ACI Manager ウィンドウで、 ボタンをクリックします。継承された ACI はデフォルトでは表示されません。一覧表示を表示するには、Show inherited ACI チェックボックスをクリックします。
- ACI は、少なくとも、適用するユーザーと、許可される権限を設定して設定します。ウィザードで ACI を設定するには(通常)、以下を実行します。
- ACI Name フィールドに ACI の名前を入力します。
- Users/Groups タブで ボタンをクリックして検索ウィンドウを開きます。ACI を適用するユーザーを検索し、追加します。結果の一覧からユーザーを選択し、追加 ボタンをクリックして。 をクリックして一覧を保存します。
- Rights タブで、この ACI の一部として許可される操作を指定します。選択したユーザー、グループ、およびホストから Console 要素を完全に非表示にするには、をクリックしてすべてのアクセスをブロックします。
- 必要に応じて、ACI が有効になるサブツリー、ホスト名、または時間にターゲットエントリーを設定します。
より複雑な ACI は視覚的に編集することができません。この場合は、ボタンをクリックして ACI エントリーを直接設定します。 - OK をクリックして ACI を保存します。
- Red Hat 管理コンソールを再起動して、新しい ACI を適用します。
索引
シンボル
- アカウントのアクティブ化
- コマンドラインでの使用, コマンドラインを使用したユーザーおよびロールの非アクティブ化およびアクティブ化
- コンソールから, コンソールを使用したユーザーおよびロールのアクティベートおよび非アクティブ化
- アカウントのロックアウト, コンソールを使用したアカウントロックアウトポリシーの設定
- Lockout duration, コンソールを使用したアカウントロックアウトポリシーの設定
- パスワードベースの設定, パスワードベースのアカウントロックアウトポリシーの設定
- パスワード障害カウンター, コンソールを使用したアカウントロックアウトポリシーの設定
- レプリケーション, アカウントロックアウトおよびレプリケーションの管理
- 属性の複製, アカウントロックアウト属性の複製
- 時間ベースの設定, 時間ベースのアカウントロックアウトポリシーの構成
- 有効化, コンソールを使用したアカウントロックアウトポリシーの設定
- 無効化, コンソールを使用したアカウントロックアウトポリシーの設定
- 設定
- attributes, コマンドラインを使用したアカウントロックアウトポリシーの設定
- コマンドラインの使用, コマンドラインを使用したアカウントロックアウトポリシーの設定
- コンソールの使用, コンソールを使用したアカウントロックアウトポリシーの設定
- アカウントの非アクティブ化, ユーザーおよびロールの手動による非アクティブ化
- PAM パススルー認証, PAM PTA マッピングの設定
- コマンドラインでの使用, コマンドラインを使用したユーザーおよびロールの非アクティブ化およびアクティブ化
- コンソールから, コンソールを使用したユーザーおよびロールのアクティベートおよび非アクティブ化
- アカウントポリシー
- アクセスログ
- コマンドラインでの表示, コマンドラインでのログの表示
- コンソールでの表示, コンソールからのログの表示
- ロケーションおよび名前の変更
- コマンドラインで、, コマンドラインでのログ場所の変更
- コンソールでは、以下を行います。, コンソールでのログ名の変更
- 定義, ログの表示
- 手動ローテーション, 手動ログファイルローテーション
- 表示する, ログファイルの表示
- 設定
- タイムスタンプの無効化, 高解像度のログタイムスタンプの無効化
- ローテーションポリシー, ログファイルのローテーションポリシーの定義
- 削除ポリシー, ログファイルの削除ポリシーの定義
- アクセス制御
- roles, セキュアなロールの使用
- およびディレクトリーマネージャー, Directory Manager でのアクセス制御の設定
- ナビゲーションツリー, Directory Server および管理サーバーのユーザーへの管理者権限の付与
- ロギング情報, アクセス制御情報のロギング
- 以前のバージョンとの互換性, 以前のリリースとの互換性
- 表示する
- get effective rights, エントリーのアクセス権利の確認 (Get Effective Rights)
- アクセス設定
- 管理サーバーの場合, 管理ユーザーのパスワードの変更
- アルゴリズム
- metaphone phonetic アルゴリズム, おおよその検索
- search, 検索アルゴリズムの概要
- アルゴリズムの検索
- 概要, 検索アルゴリズムの概要
- インデックスの参照
- 作成
- cn=tasks, cn=tasks エントリーを使用した参照インデックスの作成
- インデックスタイプ, インデックスタイプの概要
- 仮想リストビューのインデックス, インデックスタイプの概要
- 参照インデックス, インデックスタイプの概要
- 国際インデックス, インデックスタイプの概要
- 存在インデックス, インデックスタイプの概要
- 概算インデックス, インデックスタイプの概要
- 等価インデックス, インデックスタイプの概要
- 部分文字列インデックス, インデックスタイプの概要
- インデックス化, インデックスタイプの概要
- コンソールからのインデックスの作成, サーバーコンソールからのインデックスの作成
- エラーログ
- アクセス制御情報, アクセス制御情報のロギング
- コマンドラインでの表示, コマンドラインでのログの表示
- コンソールでの表示, コンソールからのログの表示
- ロケーションおよび名前の変更
- コマンドラインで、, コマンドラインでのログ場所の変更
- コンソールでは、以下を行います。, コンソールでのログ名の変更
- 定義, ログの表示
- 手動ローテーション, 手動ログファイルローテーション
- 表示する, ログファイルの表示
- 設定
- タイムスタンプの無効化, 高解像度のログタイムスタンプの無効化
- ローテーションポリシー, ログファイルのローテーションポリシーの定義
- 削除ポリシー, ログファイルの削除ポリシーの定義
- エンティティーテーブル, エンティティーテーブル
- エントリー
- distribution, データベースの作成
- root, LDIF を使用したディレクトリーの定義
- オブジェクトクラスの削除, オブジェクトクラスのエントリーへの追加または削除
- オブジェクトクラスの追加, オブジェクトクラスのエントリーへの追加または削除
- コンソールからの管理, ディレクトリーコンソールを使用したエントリーの管理
- 作成, ディレクトリーエントリーの作成
- LDIF の使用, LDIF を使用したディレクトリーエントリーの指定
- 修正, ディレクトリーエントリーの変更
- 削除, ディレクトリーエントリーの削除
- 削除およびレプリケーション, レプリケーションを使用した削除されたエントリーの管理
- 属性の追加, エントリーへの属性の追加
- 検索, ldapsearch の使用
- 管理, ディレクトリーエントリーの管理
- 非常に大きな属性の追加, 大きな属性の追加
- エントリー分布, データベースの作成
- オブジェクトクラス
- referral, コマンドラインからのスマートリファーラルの作成
- standard, スキーマの概要
- user-defined, 属性およびオブジェクトクラスの表示
- エントリーからの削除, オブジェクトクラスのエントリーへの追加または削除
- エントリーへの追加, オブジェクトクラスのエントリーへの追加または削除
- スキーマでの定義, オブジェクトクラスの作成, カスタムスキーマファイルの作成
- 作成, オブジェクトクラスの作成
- 削除, スキーマの削除
- 定義, オブジェクトクラス
- 必須属性, オブジェクトクラス
- 継承, オブジェクトクラス
- 編集, カスタムスキーマ要素の編集
- 表示する, 属性およびオブジェクトクラスの表示
- 親オブジェクトクラス, オブジェクトクラス
- 許可される属性, オブジェクトクラス
- オブジェクト識別子, オブジェクト識別子の管理
- オブジェクト識別子(OID), サポート対象のロケール
- in matchingRule, マッチングルールの形式
- マッチングルール, 一致するルールの使用
- カウンター、パスワードの失敗, コンソールを使用したアカウントロックアウトポリシーの設定
- カスケードレプリケーション
- レプリカの初期化, レプリカ合意の設定
- 概要, カスケードレプリケーション
- 設定, カスケードレプリケーションの設定
- カスケード連鎖
- proxy admin user ACI, コマンドラインからのカスケード連鎖の設定
- クライアント ACI, コマンドラインからのカスケード連鎖の設定
- コマンドラインからの設定, コマンドラインからのカスケード連鎖の設定
- コンソールからの設定, コンソールを使用したカスケード連鎖の設定
- プロキシーの承認, コマンドラインからのカスケード連鎖の設定
- ループ検出, ループの検出
- ローカル ACI 評価, コマンドラインからのカスケード連鎖の設定
- 例, カスケード連鎖設定の例
- 概要, カスケード連鎖の概要
- 設定属性, カスケード連鎖設定属性の概要
- カスタムスキーマファイル, カスタムスキーマファイルの作成
- カスタムディストリビューションロジック
- データベースの追加, 単一の接尾辞に複数のデータベースの追加
- 接尾辞への追加, 単一の接尾辞に複数のデータベースの追加
- カスタムディストリビューション機能
- 接尾辞への追加, 単一の接尾辞に複数のデータベースの追加
- カスタムビュー, コンソールアプリケーションの変更
- ACI の設定, パブリックビューのアクセスパーミッションの設定
- 作成, カスタムビューの作成
- 使用, カスタムビューの使用
- 削除中, カスタムビューの作成
- 変更先, カスタムビューへの切り替え
- 編集, カスタムビューの作成
- グループ
- Directory Server と Active Directory の相違点, Red Hat Directory Server と Active Directory のグループスキーマの相違点
- fixup-memberof.pl, fixup-memberof.pl を使用した memberOf 属性の初期化および再生成
- locating, ユーザーおよびグループの検索
- memberOf
- cn=memberof task, ldapmodify を使用した memberOf 属性の初期化および再生成
- memberOf プラグインの設定, MemberOf プラグインのインスタンスの設定, コンソールからの MemberOf プラグインの編集, コマンドラインでの MemberOf プラグインの編集
- タイプ, グループ
- 作成, グループ
- 削除中, ディレクトリーからのエントリーの削除
- 動的, コンソールでの動的グループの作成
- 作成, コンソールでの動的グループの作成
- 修正, コンソールでの動的グループの作成
- 概要, グループの使用
- 編集, エントリーの編集
- 静的, コンソールで静的グループの作成
- 作成, コンソールで静的グループの作成
- 修正, コンソールで静的グループの作成
- グローバルパスワードポリシー, グローバルパスワードポリシーの設定
- コマンドを参照, リファーラルモードでのサーバーの起動
- コマンドラインスクリプト
- db2bak, コマンドラインでのすべてのデータベースのバックアップ
- db2bak.pl, コマンドラインでのすべてのデータベースのバックアップ
- fixup-linkedattrs.pl, fixup-linkedattrs.pl を使用したリンク先属性の再生成
- fixup-memberof.pl, fixup-memberof.pl を使用した memberOf 属性の初期化および再生成
- schema-reload.pl, schema-reload.pl を使用したスキーマの再読み込み
- コマンドラインユーティリティー
- ldapsearch, LDAP 検索フィルター
- ldif, Base-64 でエンコード
- ldif2db, db2index.pl スクリプトの実行
- 証明書ベースの認証, 証明書ベースのクライアント認証の使用
- コンシューマーサーバー, サプライヤーとコンシューマー
- コンソールからのモニタリング, サーバーアクティビティーの監視
- コードページ, ローカルの概要
- サブサフィックス, 接尾辞の作成
- コマンドラインからの作成, コマンドラインでのルート接尾辞およびサブ接尾辞の作成
- コンソールからの作成, コンソールを使用した新しい従属接尾辞の作成
- サブツリーレベルのパスワードポリシー, ローカルパスワードポリシーの設定
- サプライヤー
- RUV からの古いエントリーのパージ, 廃止または不明なエラーの解決
- サプライヤーサーバー, サプライヤーとコンシューマー
- サプライヤーバインド DN, レプリケーション ID
- サーバーの起動と停止, サーバーの起動と停止
- サーバーインスタンス
- サーバーグループ
- サーバーパラメーター
- データベース
- read-only, Directory Server コンソールからのデータベースアクティビティーの監視
- サーバーログの表示, サーバーログの表示
- サーバー情報の表示, サーバー情報の表示
- サービスクラス (CoS), サービスのクラスの割り当て
- classic
- cosPriority attribute, CoS を使用した多値属性の処理
- アクセス制御, アクセス制御と CoS
- テンプレートエントリー
- ポインター
- 作成, 新規 CoS の作成
- 修飾子
- merge-scheme, CoS を使用した多値属性の処理
- オーバーライド, 物理属性値の処理
- 定義エントリー, コマンドラインでの CoS 定義エントリーの作成
- 編集, CoS テンプレートエントリーの作成
- 間接的
- 例, 間接的な CoS の仕組み
- 概要, 間接的な CoS の仕組み
- システムリソース
- モニタリング, Directory Server コンソールからのサーバーの監視
- システム接続
- モニタリング, Directory Server コンソールからのサーバーの監視
- シングルマスターレプリケーション
- 概要, 単一マスターレプリケーション
- 設定, 単一マスターレプリケーションの設定
- シンプルバインド
- セキュアな接続の要求, セキュアなバインドの要求
- シンボル
- ''(ldapsearch の場合), 特殊文字の使用
- <(LDIF ステートメントの), 標準の LDIF 表記
- LDIF ステートメントの ::, Base-64 でエンコード
- スキーマ
- Directory Server と Active Directory の相違点, Red Hat Directory Server と Active Directory との間のユーザースキーマの相違点, Red Hat Directory Server と Active Directory のグループスキーマの相違点
- cn, cn 属性の値
- initials, initials 属性の制約
- street および streetAddress, street および streetAddress の値
- OID の割り当て, オブジェクト識別子の管理
- カスタムファイル, カスタムスキーマファイルの作成
- スキーマのリロード, スキーマの動的再読み込み
- cn=schema リロードタスク, ldapmodify を使用したスキーマの再読み込み
- schema-reload.pl, schema-reload.pl を使用したスキーマの再読み込み
- スキーマチェック
- オンまたはオフ, スキーマチェックのオンとオフを切り替える
- コマンドラインでのオンまたはオフ, コマンドラインでスキーマチェックのオンおよびオフを切り替え
- 概要, スキーマチェックのオンとオフを切り替える
- スキーマ要素の削除, スキーマの削除
- スマート参照
- コマンドラインからの作成, コマンドラインからのスマートリファーラルの作成
- コンソールからの作成, Directory Server コンソールを使用したスマートリファーラルの作成
- 作成, スマートリファーラルの作成
- スレッド
- モニタリング, Directory Server コンソールからのサーバーの監視
- セキュリティー
- LDAP URL, LDAP URL の例
- 暗号化暗号の設定, 暗号化暗号の設定
- セキュリティー強度係数, セキュアな接続の要求
- タイムアウト時間
- レプリケーションの場合, レプリケーションのタイムアウト期間の設定
- チェーン
- TLS の使用, コンソールを使用した新規データベースリンクの作成, LDAP URL の提供
- カスケード, カスケード連鎖の概要
- コマンドラインからのコンポーネント操作, コマンドラインでのコンポーネントの操作の連鎖
- コンソールからのコンポーネント操作, コンソールを使用したコンポーネントの操作の連鎖
- 概要, データベースリンクの作成および維持
- テンプレートエントリー。「CoS テンプレートエントリー」を参照してください。, CoS テンプレートエントリーの概要
- テーブル
- 列の位置の変更, テーブル列の並べ替え
- ディスク領域
- アクセスログおよび, ログの有効化または無効化
- ログファイル, 手動ログファイルローテーション
- ディストリビューション機能, 単一の接尾辞に複数のデータベースの追加
- ディレクティブ, Admin Express ディレクティブ
- ディレクトリーの作成, LDIF を使用したディレクトリーの定義
- ディレクトリーエントリー
- コンソールからの管理, ディレクトリーコンソールを使用したエントリーの管理
- 作成, ディレクトリーエントリーの作成, ディレクトリーエントリーの作成
- 修正, ディレクトリーエントリーの変更
- 削除, ディレクトリーエントリーの削除
- 削除中, ディレクトリーからのエントリーの削除
- 検索, ユーザーおよびグループの検索
- ディレクトリースキーマの拡張, ディレクトリースキーマの管理
- ディレクトリーツリー
- エントリーの検索, ldapsearch の使用
- デフォルトの CoS 修飾子, 物理属性値の処理
- デフォルトの参照
- コマンドラインでの設定, コマンドラインからのデフォルトリファーラルの設定
- コンソールからの設定, コンソールを使用したデフォルトのリファーラルの設定
- 設定, デフォルト参照の設定
- データのインポート, データのインポート
- cn=tasks, cn=tasks エントリーを使用したインポート
- ldif2ldap, ldif2ldap コマンドラインスクリプトを使用したインポート
- using ldif2db, ldif2db コマンドラインユーティリティーを使用したインポート
- using ldif2db.pl, ldif2db.pl Perl スクリプトを使用したインポート
- コンソールから, コンソールからのデータベースのインポート
- 暗号化されたデータベース, 暗号化したデータベースのエクスポートおよびインポート
- データのエクスポート, データのエクスポート
- cn=tasks, エクスポートタスクの手動作成
- db2ldif, db2ldif.pl スクリプトを使用した データベースのエクスポート
- db2ldif.pl, db2ldif.pl スクリプトを使用した データベースのエクスポート
- コンソールの使用, コンソールを使用したディレクトリーデータの LDIF へのエクスポート
- 暗号化されたデータベース, 暗号化したデータベースのエクスポートおよびインポート
- データのバックアップ, データのバックアップおよび復元
- all, すべてのデータベースのバックアップ
- cn=tasks, cn=tasks エントリーを使用したデータベースのバックアップ
- db2bak, コマンドラインでのすべてのデータベースのバックアップ
- db2bak.pl, コマンドラインでのすべてのデータベースのバックアップ
- dse.ldif, dse.ldif 設定ファイルのバックアップ
- データの復元, データのバックアップおよび復元
- bak2db, bak2db コマンドラインユーティリティーの使用
- bak2db.pl, bak2db.pl Perl スクリプトの使用
- cn=tasks, cn=tasks エントリーを使用したデータベースの復元
- dse.ldif, dse.ldif 設定ファイルの復元
- コンソールから, コンソールからのすべてのデータベースの復元
- 複製されたエントリー, 複製されたエントリーが含まれるデータベースの復元
- データの整合性
- 参照整合性の使用, 参照整合性の維持
- データベース
- backup, データのバックアップおよび復元
- Directory Server, ディレクトリーデータベースの設定
- export, データのエクスポート
- cn=tasks, エクスポートタスクの手動作成
- db2ldif, db2ldif.pl スクリプトを使用した データベースのエクスポート
- db2ldif.pl, db2ldif.pl スクリプトを使用した データベースのエクスポート
- 暗号化されたデータベース, 暗号化したデータベースのエクスポートおよびインポート
- import, データのインポート
- cn=tasks, cn=tasks エントリーを使用したインポート
- ldif2db, ldif2db コマンドラインユーティリティーを使用したインポート
- ldif2db.pl, ldif2db.pl Perl スクリプトを使用したインポート
- ldif2ldap, ldif2ldap コマンドラインスクリプトを使用したインポート
- 暗号化されたデータベース, 暗号化したデータベースのエクスポートおよびインポート
- LDIF を使用した作成, LDIF を使用したディレクトリーの定義
- コマンドラインからの作成, コマンドラインから単一の接尾辞用の新規データベースの作成
- コマンドラインからの監視, コマンドラインでのデータベースの監視
- コンソールからのエクスポート, コンソールを使用したディレクトリーデータの LDIF へのエクスポート
- コンソールからのバックアップ, すべてのデータベースのバックアップ
- コンソールからの作成, コンソールを使用した既存の接尾辞の新規データベースの作成
- コンソールからの復元, コンソールからのすべてのデータベースの復元
- サーバーコンソールからの監視, Directory Server コンソールからのデータベースアクティビティーの監視
- バックアップ
- cn=tasks, cn=tasks エントリーを使用したデータベースのバックアップ
- db2bak, コマンドラインでのすべてのデータベースのバックアップ
- db2bak.pl, コマンドラインでのすべてのデータベースのバックアップ
- バックアップファイル, コンソールからのすべてのデータベースのバックアップ
- バックエンド情報の表示, データベースアクティビティーの監視
- モニタリングの選択, データベースアクティビティーの監視
- レプリケーション, 複製されるディレクトリーユニット
- 初期化, コンソールからのデータベースの初期化
- 削除, データベースの削除
- 復元, データのバックアップおよび復元
- bak2db, bak2db コマンドラインユーティリティーの使用
- bak2db.pl, bak2db.pl Perl スクリプトの使用
- cn=tasks, cn=tasks エントリーを使用したデータベースの復元
- 概要, データベースの作成および維持
- 複数の作成, 単一の接尾辞に複数のデータベースの追加
- 読み取り専用の作成, 読み取り専用モードでのデータベースの配置
- 読み取り専用モード, 読み取り専用モードでのデータベースの配置
- 関連接尾辞, 接尾辞の作成および維持
- データベースの作成
- コマンドラインでの操作, コマンドラインから単一の接尾辞用の新規データベースの作成
- コンソールから, コンソールを使用した既存の接尾辞の新規データベースの作成
- データベースの初期化, コンソールからのデータベースの初期化
- データベースサーバーのパラメーター
- read-only, Directory Server コンソールからのデータベースアクティビティーの監視
- データベースリンク
- LDAP URL の設定, LDAP URL の提供
- TLS を使用したチェーン, コンソールを使用した新規データベースリンクの作成, LDAP URL の提供
- カスケード
- コマンドラインからの設定, コマンドラインからのカスケード連鎖の設定
- コンソールからの設定, コンソールを使用したカスケード連鎖の設定
- 概要, カスケード連鎖の概要
- コマンドラインからの作成, コマンドラインからのデータベースリンクの作成
- コンソールからの作成, コンソールを使用した新規データベースリンクの作成
- デフォルトの設定, データベースリンクのデフォルトの設定
- バインドおよび認証の設定, 異なるバインドメカニズムの使用
- バインド認証情報の設定, バインド認証情報の提供
- フェイルオーバーサーバーの設定, フェイルオーバーサーバーの一覧の提供
- リモートサーバー情報のメンテナンス, データベースリンクの維持
- 削除, データベースリンクの削除
- 接尾辞の設定, コマンドラインからのデータベースリンクの作成
- 概要, データベースリンクの作成および維持
- 設定, 新規データベースリンクの作成
- 設定例, データベースリンクの設定属性の概要
- 設定属性, データベースリンクの設定属性の概要
- トポロジー
- トランザクションログ
- ナビゲーションツリー
- アクセスパーミッションの設定, Directory Server および管理サーバーのユーザーへの管理者権限の付与
- 概要, 「Servers and Applications」タブ
- ネストされたロール
- バイナリーサブタイプ, 属性サブタイプの追加
- バイナリーデータ、LDIF、および, バイナリーデータの表現
- バインド
- unauthenticated, 認証されていないバインドの許可
- セキュアな要求, セキュアなバインドの要求
- 匿名, 匿名バインドの無効化
- 特別なタイプ, 異なるタイプのバインドの有効化
- バインド認証情報
- データベースリンクの場合, バインド認証情報の提供
- パススルー認証
- PAM, パススルー認証での PAM の使用
- パススルー認証(PTA), パススルー認証の使用
- パスワード, 管理ユーザーのパスワードの変更
- Active Directory との同期, パスワード同期サービスの管理
- Directory Manager, Directory Manager パスワードのリセット
- Lockout duration, コンソールを使用したアカウントロックアウトポリシーの設定
- synchronizing, パスワードの同期
- アカウントのロックアウト, コンソールを使用したアカウントロックアウトポリシーの設定
- ポリシー
- Directory Server と Active Directory の相違点, パスワードポリシー
- ユーザーまたは管理者の変更, エントリーの編集
- 変更, 外部に保存されたパスワードの変更
- 失敗カウンター, コンソールを使用したアカウントロックアウトポリシーの設定
- 設定, ユーザーパスワードの設定
- パスワードの変更拡張操作, 外部に保存されたパスワードの変更
- パスワードの設定, ユーザーパスワードの設定
- パスワードファイル
- 管理サーバー, 管理サーバーのパスワードファイルの作成
- パスワードポリシー
- attributes, コマンドラインを使用したグローバルパスワードポリシーの設定
- Lockout duration, コンソールを使用したアカウントロックアウトポリシーの設定
- subtree-level, ローカルパスワードポリシーの設定
- user-level, ローカルパスワードポリシーの設定
- アカウントのロックアウト, コンソールを使用したアカウントロックアウトポリシーの設定
- アカウントロックアウト属性の複製, アカウントロックアウト属性の複製
- グローバル, グローバルパスワードポリシーの設定
- グローバルの設定, グローバルパスワードポリシーの設定
- パスワード障害カウンター, コンソールを使用したアカウントロックアウトポリシーの設定
- レプリケーション, アカウントロックアウトおよびレプリケーションの管理
- ローカルの設定, ローカルパスワードポリシーの設定
- 管理, パスワードポリシーの管理
- 設定
- コマンドラインの使用, コマンドラインを使用したグローバルパスワードポリシーの設定
- コンソールの使用, コンソールを使用したグローバルパスワードポリシーの設定
- パスワード同期, パスワード同期サービスの管理
- TLS の設定, ステップ 5: パスワード同期サービス の設定
- アンインストール, パスワード同期サービスの アンインストール
- 修正, パスワード同期の変更
- 起動と停止, パスワード同期サービスの起動と停止
- パフォーマンスカウンター, Directory Server コンソールからのデータベースアクティビティーの監視
- 64 ビットの整数の設定, カウンターの有効化および無効化
- 64 ビットの設定, サーバーアクティビティーの監視, データベースアクティビティーの監視, 管理情報ベースの使用
- サーバーの属性, カウンターの有効化および無効化
- 以下を実行してサーバーの監視, サーバーアクティビティーの監視
- ファイル
- データベースのバックアップ, コンソールからのすべてのデータベースのバックアップ
- ファイルの場所, ファイルの場所
- ファイルシステム階層標準, ファイルの場所
- フィルターされたロール
- フェイルオーバーサーバー
- データベースリンクの場合, フェイルオーバーサーバーの一覧の提供
- プラグイン
- Directory Manager ACI, Directory Manager でのアクセス制御の設定
- コンソールでの詳細の表示, Directory Server コンソールでプラグインの有効化
- リンクされた属性, 属性値の管理属性のリンク
- scope, リンク属性の概要
- インスタンスの作成, 属性リンクの設定
- 情報, リンク属性の概要
- 構文, リンク元属性プラグイン構文の確認
- 優先順位の設定, プラグインの優先順位の設定
- 分散番号の割り当て, 一意の数値属性値の割り当ておよび管理
- 動的プラグイン, プラグインを動的に有効化
- 有効化, コマンドラインでプラグインの有効化, Directory Server コンソールでプラグインの有効化
- 無効化, コマンドラインでプラグインの有効化, Directory Server コンソールでプラグインの有効化
- プレゼンス検索
- 例, 検索フィルターの属性の使用
- 構文, 検索フィルターでの演算子の使用
- プロキシーの承認
- カスケード連鎖の使用, コマンドラインからのカスケード連鎖の設定
- プロトコルデータユニット。「PDU」を参照してください。, SNMP の概要
- プロパティーエディター
- 表示, ディレクトリーエントリーの変更
- ベース DN、ldapsearch, LDAP_BASEDN の使用
- ホストの制限, ホスト制限の設定
- コマンドラインでの設定, コマンドラインでのホスト制限の設定
- コンソールでの設定, コンソールでのホスト制限の設定
- ホスト情報、変更, ドメイン、ホスト、サーバーグループ、およびインスタンス情報の編集
- ポインター CoS
- ポート番号, 標準ポート番号の変更, ポート番号の変更
- Directory Server の設定, Directory Server ポート番号の変更
- TLS 通信の場合, LDAPS ポート番号の変更
- コマンドラインでの変更, コマンドラインでのポート番号の変更
- コンソールでの変更, コンソールのポート番号の変更
- マクロ ACI
- 例, マクロ ACI の例
- 概要, 高度なアクセス制御: マクロ ACI の使用
- 構文, マクロ ACI 構文
- マッチングルール, 一致するルールの使用
- 国際形式, マッチングルールの形式
- 対応しているリスト, 一致するルールの使用
- マネージドデバイス
- 概要, SNMP の概要
- マルチマスターレプリケーション
- コンシューマーの独占防止, マルチマスターレプリケーションにおけるコンシューマーの独占を防ぐ
- 概要, マルチマスターレプリケーション
- 設定, マルチマスターレプリケーションの設定
- マルチマスターレプリケーションにおけるコンシューマーの独占を防ぐ, マルチマスターレプリケーションにおけるコンシューマーの独占を防ぐ
- モニタリング
- Directory Server, Directory Server ログファイルの種類
- SNMP の使用, SNMP を使用した Directory Server の監視
- コマンドラインからのデータベース, コマンドラインでのデータベースの監視
- コンソールから, サーバーアクティビティーの監視
- サーバーコンソールからのデータベース, Directory Server コンソールからのデータベースアクティビティーの監視
- スレッド, Directory Server コンソールからのサーバーの監視
- レプリケーションのステータス, レプリケーションステータスの監視
- ログファイル, Directory Server ログファイルの種類
- ユーザーおよびグループの管理
- 参照の整合性, 参照整合性の維持
- ユーザーやグループタブ、検索ディレクトリーの変更, ユーザーおよびグループの検索
- ユーザーエントリー
- locating, ユーザーおよびグループの検索
- パスワードの変更, エントリーの編集
- 作成, ディレクトリーおよび管理ユーザー
- 削除中, ディレクトリーからのエントリーの削除
- 編集, エントリーの編集
- ユーザーディレクトリー
- settings, ユーザーディレクトリーホストまたはポートの変更
- ユーザーパスワード, ユーザーパスワードの設定
- ユーザーレベルのパスワードポリシー, ローカルパスワードポリシーの設定
- ユーザー定義のオブジェクトクラス, 属性およびオブジェクトクラスの表示
- リソースの使用
- connections, Directory Server コンソールからのサーバーの監視
- モニタリング, Directory Server コンソールからのサーバーの監視
- リソースの概要
- リソース制限
- 設定
- コマンドラインの使用, コマンドラインを使用したユーザーおよびグローバルリソース制限の設定
- コンソールの使用, 単一ユーザーでのリソース制限の設定
- 匿名バインドの場合, 匿名バインドでのリソース制限の設定
- リンクされた属性, 属性値の管理属性のリンク
- ループ検出
- カスケード連鎖, ループの検出
- レプリカの初期化
- カスケードレプリケーション, レプリカ合意の設定
- レプリカ合意, レプリカ合意
- レプリケーション
- and ou=NetscapeRoot, 管理サーバーのフェイルオーバー用の o=NetscapeRoot の複製
- changelog, Changelog
- cl-dump.pl スクリプトの使用, レプリケーション関連の問題のトラブルシューティング
- hub, サプライヤーとコンシューマー
- RUV のパージ, 廃止または不明なエラーの解決
- single-master, 単一マスターレプリケーションの設定
- supplier-initiated, サプライヤーとコンシューマー
- TLS の設定, TLS 上のレプリケーション
- tombstone エントリー
- および TLS, TLS 上のレプリケーション
- およびパスワードポリシー, アカウントロックアウトおよびレプリケーションの管理
- アカウントのロックアウト属性, アカウントロックアウト属性の複製
- カスケード, カスケードレプリケーションの設定
- コマンドラインからの設定, コマンドラインでのレプリケーションの設定
- コンシューマーサーバー, サプライヤーとコンシューマー
- サプライヤーと RUV の削除, レプリケーショントポロジーからのサプライヤーの削除
- サプライヤーサーバー, サプライヤーとコンシューマー
- サプライヤーバインド DN, レプリケーション ID
- サプライヤーバインド DN の作成, サプライヤーバインド DN エントリーの作成
- ステータスの監視, レプリケーションステータスの監視
- タイムアウト期間, レプリケーションのタイムアウト期間の設定
- トラブルシューティング, レプリケーション関連の問題のトラブルシューティング
- マルチマスター, マルチマスターレプリケーションの設定
- レプリケーションマネージャーエントリー, レプリケーション ID
- 一部, 一部レプリケーションを使用した属性のサブセットの複製
- 単位, 複製されるディレクトリーユニット
- 参照の整合性と参照の整合性, レプリケーションによる参照整合性の使用
- 同期の強制, レプリケーション更新の強制
- 概要, レプリケーションの概要
- 競合の解決, 一般的なレプリケーションの競合の解決
- 管理, レプリケーションの管理
- 管理サーバー, 管理サーバーのフェイルオーバー用の o=NetscapeRoot の複製
- レプリケーションの監視, Admin Express からのレプリケーションの監視
- レプリケーションマネージャー, レプリケーション ID
- ログ
- Windows 同期の場合, トラブルシューティング
- ログファイル, Directory Server ログファイルの種類
- アクセスログ, Directory Server ログファイルの種類
- エラーログ, Directory Server ログファイルの種類
- タイムスタンプの無効化, 高解像度のログタイムスタンプの無効化
- ローテーションポリシー, ログファイルのローテーションポリシーの定義
- 削除ポリシー, ログファイルの削除ポリシーの定義
- 場所, 手動ログファイルローテーション
- 手動ローテーション, 手動ログファイルローテーション
- 監査ログ, Directory Server ログファイルの種類
- 監査ログの失敗, Directory Server ログファイルの種類
- 表示する, ログファイルの表示
- ログファイルの手動ローテーション, 手動ログファイルローテーション
- ロケール
- サポート対象, サポート対象のロケール
- ファイルの場所, ローカルの概要
- 定義, ローカルの概要
- ロックされたアカウント, コンソールを使用したアカウントロックアウトポリシーの設定
- ローカルパスワードポリシー, ローカルパスワードポリシーの設定
- ロール
- 非アクティブ化, ロールのアクティブまたはアクティブ作成
- ロールの非アクティブ化, ロールのアクティブまたはアクティブ作成
- ワイルドカード
- マッチングルールフィルターの場合, LDAP 検索フィルター
- 一部レプリケーション, 一部レプリケーションを使用した属性のサブセットの複製
- 仮想 DIT の作成, ビューの概要
- 仮想リストビューのインデックス, インデックスタイプの概要
- 例
- カスケード連鎖, カスケード連鎖設定の例
- 分散番号の割り当て, 一意の数値属性値の割り当ておよび管理
- Directory Server の動作, 一意の数値属性値の割り当ておよび管理
- scope, フィルター、検索、およびターゲットエントリー
- 基本的な例, DNA プラグイン構文の確認
- 完全な例, DNA プラグイン構文の確認
- 属性の場合, 範囲および割り当て番号
- 概要, 一意の数値属性値の割り当ておよび管理
- 構文, DNA プラグイン構文の確認
- 範囲について, 動的番号の割り当ての概要
- 設定, 一意の番号割り当ての設定, コンソールでの DNA プラグインの編集
- 初期化
- および entryUSN 値, インポート中の EntryUSN 初期値の設定
- MMR でのサプライヤー, インポート中の EntryUSN 初期値の設定
- オンラインのコンシューマー作成, コンソールを使用したオンラインコンシューマーの初期化
- 手動コンシューマーの作成, コマンドラインを使用した手動コンシューマーの初期化
- 削除
- attributes, スキーマの削除
- オブジェクトクラス, スキーマの削除
- データベースリンク, データベースリンクの削除
- 削除中
- Directory Server インスタンス, コンソールを使用した Directory Server インスタンスの削除
- 動的グループ, コンソールでの動的グループの作成, グループ
- 作成, コンソールでの動的グループの作成
- 修正, コンソールでの動的グループの作成
- 匿名バインド
- リソース制限, 匿名バインドでのリソース制限の設定
- 無効化, 匿名バインドの無効化
- 参照
- スマート参照の作成, スマートリファーラルの作成
- デフォルトの設定, デフォルト参照の設定
- 接尾辞, コンソールを使用した接尾辞リファーラルの作成
- 接尾辞の作成, バグ修正参照の作成
- 更新時, コンソールを使用した接尾辞リファーラルの作成
- 参照の整合性
- attributes, 参照整合性の仕組み
- レプリケーションの使用, レプリケーションによる参照整合性の使用
- ログファイル, 参照整合性の仕組み
- 属性の変更, コンソールを使用した属性一覧の変更
- 必要なインデックス, 参照整合性の仕組み
- 有効化, コンソールでの参照整合性の有効化および無効化
- 概要, 参照整合性の維持
- 無効化, コンソールでの参照整合性の有効化および無効化
- 参照インデックス, インデックスタイプの概要
- 参照モード, リファーラルモードでのサーバーの起動
- 同期
- POSIX 属性
- オブジェクトクラスを同期しない, ユーザーとグループの POSIX 属性の同期
- 同期の設定, ユーザーとグループの POSIX 属性の同期
- サブツリースコープおよびエントリーの削除, 同期しているサブツリーから移動するエントリーの処理
- 同期オプション
- 有効化, エントリーの同期属性の許可
- 概要, エントリーの同期属性の許可
- 同期合意
- 命名の競合
- レプリケーション, ネーミングの競合の解決
- 国コード, サポート対象のロケール
- 国際インデックス, インデックスタイプの概要
- 照合順序, サーバーコンソールからのインデックスの作成
- 国際化
- LDIF ファイルの, 複数の言語での情報の保存
- オブジェクト識別子および, サポート対象のロケール
- サポートされるロケール, サポート対象のロケール
- ファイルの場所, ローカルの概要
- フィルターおよび, 国際化されたディレクトリーの検索
- ロケールおよび, ローカルの概要
- 国コード, サポート対象のロケール
- 文字タイプ, ローカルの概要
- 日付形式, ローカルの概要
- 時間形式, ローカルの概要
- 照合順序, ローカルの概要
- 言語タグ, サポート対象のロケール
- 通貨形式, ローカルの概要
- 国際文字セット, 国際化
- 国際検索, 国際化されたディレクトリーの検索
- OID の使用, マッチングルールの形式
- substring, 部分文字列の例
- は次の値よりも大きい:, より大きいの例
- は次の値よりも小さい:, less-than の例
- は次の値以上:, より大きいか等しいの例
- は次の値以下:, less-Than または Equal-to の例
- 例, 国際検索の例
- 等価, 等価性の例
- 存在インデックス, インデックスタイプの概要
- 参照整合性に必須, 参照整合性の仕組み
- 定義
- attributes, 属性の作成
- オブジェクトクラス, オブジェクトクラスの作成
- 対話表, 対話表
- 属性
- nsslapd-schemacheck, コマンドラインでスキーマチェックのオンおよびオフを切り替え
- ref, コマンドラインからのスマートリファーラルの作成
- standard, スキーマの概要
- エントリーへの追加, エントリーへの属性の追加
- スキーマでの定義, 属性の作成, カスタムスキーマファイルの作成
- 一意の番号の割り当て
- 使用方法, 範囲および割り当て番号
- 概要, 一意の数値属性値の割り当ておよび管理
- 構文, DNA プラグイン構文の確認
- 作成, 属性の作成
- 値の削除, 属性値の追加
- 削除, スキーマの削除
- 検索, 検索フィルターの属性の使用
- 編集, カスタムスキーマ要素の編集
- 表示する, 属性およびオブジェクトクラスの表示
- 複数の値の追加, 属性値の追加
- 非常に大きな, 大きな属性の追加
- 属性の一意性プラグイン, 属性の一意性の有効化
- uniqueness-subtree-entries-oc, オブジェクトクラスに対する属性の一意性の設定
- uniqueness-top-entry-oc, オブジェクトクラスに対する属性の一意性の設定
- 属性の暗号化, 属性暗号化の設定
- 暗号化されたデータベースのインポートおよびエクスポート, 暗号化したデータベースのエクスポートおよびインポート
- 属性サブタイプ, 属性サブタイプの追加
- Pronunciation, 属性サブタイプの追加
- バイナリー, 属性サブタイプの追加
- 言語, 属性サブタイプの追加
- 追加, 属性サブタイプの追加
- 属性タイプフィールド(LDIF), LDIF ファイルの形式の概要
- 属性値フィールド(LDIF), LDIF ファイルの形式の概要
- 接尾辞
- Directory Server, ディレクトリーデータベースの設定
- root 接尾辞の作成, コンソールを使用した新規ルート接尾辞の作成
- カスタムディストリビューションロジック, 単一の接尾辞に複数のデータベースの追加
- カスタムディストリビューション機能, 単一の接尾辞に複数のデータベースの追加
- コマンドラインからの作成, コマンドラインでのルート接尾辞およびサブ接尾辞の作成
- サブ接尾辞の作成, コンソールを使用した新しい従属接尾辞の作成
- 作成, ルートエントリーの作成
- 参照の使用, コンソールを使用した接尾辞リファーラルの作成
- 更新時にのみ, コンソールを使用した接尾辞リファーラルの作成
- 無効化, 接尾辞の無効化
- 複数のデータベースを使用する場合, 単一の接尾辞に複数のデータベースの追加
- 関連データベース, 接尾辞の作成および維持
- 接尾辞の参照
- コマンドラインからの作成, コマンドラインからの接尾辞リファーラルの作成
- コンソールからの作成, コンソールを使用した接尾辞リファーラルの作成
- 作成, バグ修正参照の作成
- 接尾辞の無効化, 接尾辞の無効化
- 接続の制限, ホスト制限の設定
- コマンドラインでの設定, コマンドラインでのホスト制限の設定
- コンソールでの設定, コンソールでのホスト制限の設定
- 操作, Directory Server コンソールからのサーバーの監視
- 操作表, 操作表
- 文字タイプ, ローカルの概要
- 日付形式, ローカルの概要
- 時間形式, ローカルの概要
- 暗号化, 暗号化暗号の設定
- 検索
- attributes, 検索フィルターの属性の使用
- substring, 検索フィルターでの演算子の使用
- は次の値よりも小さい:, less-than の例
- は次の値以上:, 検索フィルターでの演算子の使用
- は次の値以下:, 検索フィルターでの演算子の使用
- エントリー, ldapsearch の使用
- スコープの指定, 一般的に使用される ldapsearch オプション
- ディレクトリーエントリーの場合, ユーザーおよびグループの検索
- ディレクトリーツリー, ldapsearch の使用
- 例, 一般的な ldapsearch の例
- 国際, 国際化されたディレクトリーの検索
- 国際的な例, 国際検索の例
- 存在, 検索フィルターでの演算子の使用
- 検索ディレクトリーの変更, ユーザーおよびグループの検索
- 概算, 検索フィルターでの演算子の使用
- 等価, 検索フィルターでの演算子の使用
- 検索よりも小さい
- 国際の例, less-than の例
- 構文, 検索フィルターでの演算子の使用
- 検索タイプ
- 一覧, 検索フィルターでの演算子の使用
- 検索フィルター, LDAP 検索フィルター
- Operator in, 検索フィルターでの演算子の使用
- ファイル内, 属性のサブセットの表示
- ブール値の演算子, 複合検索フィルターの使用
- マッチングルール, 一致するルールの使用
- 例, LDAP 検索フィルター
- 属性の指定, 検索フィルターの属性の使用
- 構文, LDAP 検索フィルター
- 複合の使用, 複合検索フィルターの使用
- 複数の使用, 複合検索フィルターの使用
- 検索フィルターにおけるブール値演算子, 複合検索フィルターの使用
- 検索以上
- 国際の例, より大きいか等しいの例
- 概要, 検索フィルターでの演算子の使用
- 検索条件以下
- 国際の例, less-Than または Equal-to の例
- 構文, 検索フィルターでの演算子の使用
- 概算インデックス, インデックスタイプの概要
- クエリー文字列コード, おおよその検索
- 概算検索, 検索フィルターでの演算子の使用
- 構文
- LDAP URL, LDAP URL のコンポーネント
- ldapsearch, ldapsearch コマンドライン形式
- マッチングルールフィルター, 一致するルールの使用
- 検索フィルター, LDAP 検索フィルター
- 構文の検証, 構文の検証の使用
- DN の強制, DN の厳格な構文検証の有効化
- および warnings, 構文検証警告の有効化(Logging)
- およびエラーロギング, 構文検証警告の有効化(Logging)
- コマンドライン perl スクリプト, 既存の属性値の構文の検証
- 有効化および無効化, 構文の検証の有効化または無効化
- 関連 RFC, 構文の検証の概要
- 演算子
- フィルターおよび, 検索フィルターでの演算子の使用
- ブール値, 複合検索フィルターの使用
- 国際検索および, サポートされる検索タイプ
- 接尾辞, サポートされる検索タイプ
- 照合順序
- フィルターおよび, 国際化されたディレクトリーの検索
- 国際インデックス, サーバーコンソールからのインデックスの作成
- 概要, ローカルの概要
- 環境変数
- LDAP_BASEDN, LDAP_BASEDN の使用
- 監査ログ
- 有効化, ログの有効化または無効化
- 無効化, ログの有効化または無効化
- 表示する, ログファイルの表示
- 設定
- タイムスタンプの無効化, 高解像度のログタイムスタンプの無効化
- ローテーションポリシー, ログファイルのローテーションポリシーの定義
- 削除ポリシー, ログファイルの削除ポリシーの定義
- 監査ログの失敗
- 表示する, ログファイルの表示
- 設定
- タイムスタンプの無効化, 高解像度のログタイムスタンプの無効化
- ローテーションポリシー, ログファイルのローテーションポリシーの定義
- 削除ポリシー, ログファイルの削除ポリシーの定義
- 等価インデックス, インデックスタイプの概要
- 参照整合性に必須, 参照整合性の仕組み
- 等価検索, 検索フィルターでの演算子の使用
- 例, 検索フィルターの属性の使用
- 国際の例, 等価性の例
- 管理オブジェクト, SNMP の概要
- 管理コンソール
- 起動, 管理コンソールを開く
- 管理サーバー
- login, 管理コンソールを開く
- TLS の有効化, TLS の有効化
- およびレプリケーション, 管理サーバーのフェイルオーバー用の o=NetscapeRoot の複製
- アクセス設定, 管理ユーザーのパスワードの変更
- コンソールの起動, 管理コンソールを開く
- サーバーの起動と停止, サーバーの起動と停止
- サーバー情報の表示, サーバー情報の表示
- ディレクトリー設定, Directory Server 設定の変更
- パスワードファイル, 管理サーバーのパスワードファイルの作成
- ポート番号, ポート番号の変更
- コマンドラインで、, コマンドラインでのポート番号の変更
- コンソールでは、以下を行います。, コンソールのポート番号の変更
- ロギングのオプション, ログの表示
- ログの表示, サーバーログの表示
- 削除中, Directory Server インスタンスおよび管理サーバーの削除
- 定義, Red Hat 管理サーバーの概要, Directory Server コンソールの概要
- 暗号化の設定, TLS の使用
- 証明書の要求, 管理サーバーの証明書の管理
- 起動と停止, Directory Server 管理サーバーサービスの起動と停止
- 管理サーバー管理者
- ユーザー名およびパスワードの変更, 管理者パスワードの変更
- 定義, 管理ユーザーのパスワードの変更, 管理者エントリーの変更
- 管理ドメイン
- 管理対象ロール
- 作成, 管理ロールの作成
- 例, コマンドラインでの管理ロールの作成
- 管理者
- パスワードのリセット, 管理ユーザーのパスワードの変更
- ユーザー名の変更, 管理ユーザーのパスワードの変更
- 管理者(概要), 管理者エントリーの変更
- 組織のユーザー(エントリーの指定), 組織の個人エントリーの指定
- 組織単位
- 作成, 組織単位
- 削除中, ディレクトリーからのエントリーの削除
- 組織単位(エントリーの指定), 組織単位エントリーの指定
- 継続した行
- LDIF の場合, LDIF での行継続
- 編集
- attributes, カスタムスキーマ要素の編集
- オブジェクトクラス, カスタムスキーマ要素の編集
- 表示する
- attributes, 属性およびオブジェクトクラスの表示
- アクセス制御
- get effective rights, エントリーのアクセス権利の確認 (Get Effective Rights)
- オブジェクトクラス, 属性およびオブジェクトクラスの表示
- 複合検索フィルター, 複合検索フィルターの使用
- 複数の検索フィルター, 複合検索フィルターの使用
- 親オブジェクトクラス, オブジェクトクラス
- 言語コード
- LDIF エントリーでの使用, 複数の言語での情報の保存
- 対応しているリスト, サポート対象のロケール
- 言語サブタイプ, 属性サブタイプの追加
- 言語サポート
- ロケールを使用した指定, サポート対象のロケール
- 検索および, 国際化されたディレクトリーの検索
- 言語タグ, サポート対象のロケール
- 言語タグ
- 国際検索の場合, マッチングルールに言語タグの使用
- 説明, サポート対象のロケール
- 設定, コンソールアプリケーションの変更
- UI パーミッション, コンソールアプリケーションの変更
- フォント, コンソールフォントの変更
- 設定ディレクトリー
- 設定属性
- アカウントのロックアウト, コマンドラインを使用したアカウントロックアウトポリシーの設定
- カスケード連鎖, カスケード連鎖設定属性の概要
- パスワードポリシー, コマンドラインを使用したグローバルパスワードポリシーの設定
- 設定管理者
- ユーザー名およびパスワードの変更, 管理者エントリーの変更
- 定義, 管理ユーザーのパスワードの変更, 管理者エントリーの変更
- 証明書, 管理サーバーの証明書の管理
- 証明書グループ, グループ
- 証明書ベースの認証, 証明書ベースのクライアント認証の使用
- 認証, 管理コンソールを開く
- autobind
- 概要, Autobind および LDAPI の概要
- 設定, 自動バインドの設定
- certificate-based, 証明書ベースのクライアント認証の使用
- LDAP URL, LDAP URL の例
- PAM の使用, パススルー認証での PAM の使用
- SASL, SASL Identity マッピングの設定
- SASL メカニズム, Directory Server の SASL の認証メカニズム
- データベースリンクの場合, 異なるバインドメカニズムの使用
- 認証されていないバインド, 認証されていないバインドの許可
- 読み取り/書き込みレプリカ, 読み取り/書き込みレプリカおよび読み取り専用レプリカ
- 読み取り専用モード, Directory Server コンソールからのデータベースアクティビティーの監視
- データベース, 読み取り専用モードでのデータベースの配置
- 読み取り専用レプリカ, 読み取り/書き込みレプリカおよび読み取り専用レプリカ
- 起動と停止
- Directory Server および管理サーバー, Directory Server インスタンスの起動および停止
- 管理コンソール, 管理コンソールを開く
- 通貨形式, ローカルの概要
- 部分文字列インデックス, インデックスタイプの概要
- 参照整合性に必須, 参照整合性の仕組み
- 部分文字列インデックスの制限, インデックスタイプの概要
- 部分文字列検索, 検索フィルターでの演算子の使用
- 国際の例, 部分文字列の例
- 間接的な CoS
- 例, 間接的な CoS の仕組み
- 概要, 間接的な CoS の仕組み
- 静的グループ, コンソールで静的グループの作成, グループ
- 作成, コンソールで静的グループの作成
- 修正, コンソールで静的グループの作成
A
- ACI
- およびディレクトリーマネージャー, Directory Manager でのアクセス制御の設定
- カスケード連鎖, コマンドラインからのカスケード連鎖の設定
- マクロ ACI の使用, 高度なアクセス制御: マクロ ACI の使用
- ローカル評価
- カスケード連鎖, コマンドラインからのカスケード連鎖の設定
- ACL, アクセス制御要件
- Active Directory
- Directory Server とのスキーマの相違点, Red Hat Directory Server と Active Directory との間のユーザースキーマの相違点, Red Hat Directory Server と Active Directory のグループスキーマの相違点
- AD DN プラグイン, 認証に Active Directory 形式のユーザー名の使用
- Admin Express
- サーバーの起動と停止, サーバーの起動と停止
- サーバーログの表示, サーバーログの表示
- サーバー情報の表示, サーバー情報の表示
- ファイル, Admin Express 設定ファイル
- Welcome ページの場合, 管理サーバーの Welcome ページのファイル
- サーバーログページの場合, サーバーログページのファイル
- サーバー情報ページの場合, サーバー情報ページのファイル
- レプリケーションステータスの場合, Replication Status Appearance のファイル
- ファイルの場所, Admin Express ファイルの場所
- レプリケーションの監視, Admin Express からのレプリケーションの監視
- 設定, Admin Express の設定
- ディレクティブ, Admin Express ディレクティブ
- 開く, Admin Express を開く
- attributes
- リンク
- fixup-linkedattrs.pl, fixup-linkedattrs.pl を使用したリンク先属性の再生成
- リンクされた属性, 属性値の管理属性のリンク
- インスタンスの作成, 属性リンクの設定
- 情報, リンク属性の概要
- 構文, リンク元属性プラグイン構文の確認
- 一意の番号の割り当て, 一意の数値属性値の割り当ておよび管理
- マジック番号, 範囲および割り当て番号
- 概要, 一意の数値属性値の割り当ておよび管理
- 構文, DNA プラグイン構文の確認
- 設定, 一意の番号割り当ての設定, コンソールでの DNA プラグインの編集
- 定義, 属性
- 必須, オブジェクトクラス
- 構文, Directory Server 属性の構文
- 管理, 属性および値の管理
- 許可, オブジェクトクラス
- autobind
- 概要, Autobind および LDAPI の概要
- 設定, 自動バインドの設定
B
- bak2db スクリプト, bak2db コマンドラインユーティリティーの使用
- bak2db.pl perl スクリプト, bak2db.pl Perl スクリプトの使用
- Base 64 エンコーディング, バイナリーデータの表現
C
- changelog, Changelog
- トリム, レプリケーション changelog のトリム
- 削除, Changelog の削除
- cl-dump.pl script, レプリケーション関連の問題のトラブルシューティング
- classic CoS
- client
- エントリーの検索に使用, ディレクトリーエントリーの検索
- cn=fixup linked attributes task, ldapmodify を使用したリンク先属性の再生成
- cn=memberof task, ldapmodify を使用した memberOf 属性の初期化および再生成
- cn=schema リロードタスク, ldapmodify を使用したスキーマの再読み込み
- cn=task
- cn=schema リロードタスク, ldapmodify を使用したスキーマの再読み込み
- cn=tasks
- cn=backup, cn=tasks エントリーを使用したデータベースのバックアップ
- cn=export, エクスポートタスクの手動作成
- cn=fixup リンク属性, ldapmodify を使用したリンク先属性の再生成
- cn=import, cn=tasks エントリーを使用したインポート
- cn=memberof task, ldapmodify を使用した memberOf 属性の初期化および再生成
- cn=restore, cn=tasks エントリーを使用したデータベースの復元
- インデックスの作成, cn=tasks エントリーを使用したインデックスの作成
- 参照インデックスの作成, cn=tasks エントリーを使用した参照インデックスの作成
- compatibility
- ACIs, 以前のリリースとの互換性
- Configuration Administrators グループ
- ユーザーの追加, 管理者管理者グループへのユーザーの追加
- connections
- LDAPI(Unix ソケット), Autobind および LDAPI の概要
- 設定, LDAPI の有効化
- セキュアな要求, セキュアな接続の要求
- モニタリング, Directory Server コンソールからのサーバーの監視
- 数の表示, Directory Server コンソールからのサーバーの監視
- CoS (サービスクラス), サービスのクラスの割り当て
- CoS テンプレートエントリー, CoS テンプレートエントリーの概要
- CoS 修飾子
- default, 物理属性値の処理
- merge-scheme, CoS を使用した多値属性の処理
- オーバーライド, 物理属性値の処理
- CoS 修飾子のオーバーライド, 物理属性値の処理
- CoS 定義エントリー
- attributes, コマンドラインでの CoS 定義エントリーの作成
- オブジェクトクラス, コマンドラインでの CoS 定義エントリーの作成
- cosPriority attribute, CoS を使用した多値属性の処理
D
- db2bak スクリプト, コマンドラインでのすべてのデータベースのバックアップ
- db2bak ユーティリティー, コマンドラインでのすべてのデータベースのバックアップ
- db2bak.pl script, コマンドラインでのすべてのデータベースのバックアップ
- db2ldif utility, db2ldif.pl スクリプトを使用した データベースのエクスポート
- db2ldif.pl, db2ldif.pl スクリプトを使用した データベースのエクスポート
- debug
- およびレプリケーションのタイムアウト, レプリケーションのタイムアウト期間の設定
- directory
- 検索ディレクトリーの変更, ユーザーおよびグループの検索
- Directory Manager
- Directory Server の削除
- Directory Server コンソール
- Directory Server
- data, Directory Database への入力
- Directory Server および管理サーバーの削除, Directory Server インスタンスおよび管理サーバーの削除
- LDAPI(Unix ソケット)での接続, Autobind および LDAPI の概要
- MIB, 管理情報ベースの使用
- root エントリーの作成, ルートエントリーの作成
- SNMP による監視, SNMP を使用した Directory Server の監視
- インスタンスの削除, コンソールを使用した Directory Server インスタンスの削除
- エントリーの作成, ディレクトリーエントリーの作成
- エントリーの削除, ディレクトリーエントリーの削除
- エントリーの変更, ディレクトリーエントリーの変更
- エントリーの管理, ディレクトリーエントリーの管理
- コマンドラインからの監視, コマンドラインでの Directory Server の監視
- コンテンツの作成, Directory Database への入力
- サポート言語, サポート対象のロケール
- サーバーの起動と停止, サーバーの起動と停止
- スキーマのリロード, スキーマの動的再読み込み
- cn=schema リロードタスク, ldapmodify を使用したスキーマの再読み込み
- schema-reload.pl, schema-reload.pl を使用したスキーマの再読み込み
- データのインポート, データのインポート
- データベース, ディレクトリーデータベースの設定
- パフォーマンスカウンター, サーバーアクティビティーの監視, カウンターの有効化および無効化
- 64 ビット, サーバーアクティビティーの監視, データベースアクティビティーの監視, 管理情報ベースの使用
- ファイルの場所, ファイルの場所
- モニタリング, Directory Server ログファイルの種類
- ユーザーサブツリー, Directory Server コンソールの概要
- リソースおよびユーザーの管理におけるロール, Directory Server コンソールの概要
- レプリケーションの監視, Admin Express からのレプリケーションの監視
- ログの表示, サーバーログの表示
- 単一のインスタンスの削除, コマンドラインを使用した Directory Server インスタンスの削除
- 国際文字セット, 国際化
- 基本的な管理, Red Hat Directory Server の基本設定, コンテンツの同期の設定
- 属性の管理, 属性および値の管理
- 情報の表示, サーバー情報の表示
- 接尾辞, ディレクトリーデータベースの設定
- 概要, Red Hat Directory Server の基本設定
- 設定, Directory Server ポート番号の変更
- 設定サブツリー, Directory Server コンソールの概要
- 起動と停止, コマンドラインを使用した Directory Server インスタンスの起動および停止
- 起動時の SASL 認証の設定, Directory Server 起動時の SASL 認証の設定
- DN のコンマ
- を用いた ldapsearch の使用, 検索フィルターでコンマを含む DN の指定
- DN フィールド(LDIF), LDIF ファイルの形式の概要
- DNS
- 構文の検証, DN の厳格な構文検証の有効化
- dse.ldif ファイル
- バックアップ, dse.ldif 設定ファイルのバックアップ
- 復元, dse.ldif 設定ファイルの復元
E
- entryUSN
- インポート操作, インポート中の EntryUSN 初期値の設定
- レプリカおよびデータベースの初期化, インポート中の EntryUSN 初期値の設定
- entryusn:
- インポート操作, インポート中の EntryUSN 初期値の設定
F
- fixup-linkedattrs.pl, fixup-linkedattrs.pl を使用したリンク先属性の再生成
- fixup-memberof.pl, fixup-memberof.pl を使用した memberOf 属性の初期化および再生成
- fonts
- 変更, コンソールフォントの変更
- format, LDIF, LDAP データ交換形式
G
- get effective rights, エントリーのアクセス権利の確認 (Get Effective Rights)
- 戻りコード, Get Effective Rights 戻りコード
- glue エントリー, 孤立エントリーの競合の解決
- GSS-API, Directory Server の SASL の認証メカニズム
H
- hub, サプライヤーとコンシューマー
I
- ID フィールド(LDIF), LDIF ファイルの形式の概要
- ID マッピング
- default, Directory Server のデフォルトの SASL マッピング
- Indexes
- マッチングルール, 一致するルールの使用
- 作成
- cn=tasks, cn=tasks エントリーを使用したインデックスの作成
- 動的な作成, コマンドラインからのインデックスの作成
- 動的な変更, コマンドラインからのインデックスの作成
- 参照整合性に必須, 参照整合性の仕組み
- Init スクリプト
- SASL 認証の設定, Directory Server 起動時の SASL 認証の設定
J
- JPEG イメージ, バイナリーデータの表現
L
- LDAP URL
- components of, LDAP URL のコンポーネント
- セキュリティー, LDAP URL の例
- データベースリンクの場合, LDAP URL の提供
- 例, LDAP URL の例
- 構文, LDAP URL のコンポーネント
- LDAP クライアント
- エントリーの検索に使用, ディレクトリーエントリーの検索
- 使用しているデータベースの監視, コマンドラインでのデータベースの監視
- 監視サーバー, コマンドラインでの Directory Server の監視
- 証明書ベースの認証, 証明書ベースのクライアント認証の使用
- LDAP 検索フィルター
- DNS はコンマで区切り、, 検索フィルターでコンマを含む DN の指定
- ldapcompare コマンドラインユーティリティー
- 例, エントリーの比較
- LDAPI
- 有効化, LDAPI の有効化
- 概要, Autobind および LDAPI の概要
- ldappasswd コマンドラインユーティリティー
- ldapsearch コマンドラインユーティリティー
- 拡張操作, 延長操作の実行
- ldapsearch ユーティリティー
- DNS はコンマで区切り、, 特殊文字の使用
- format, ldapsearch コマンドライン形式
- ファイルの指定, 属性のサブセットの表示
- ベース DN および, LDAP_BASEDN の使用
- 一般的に使用されるオプション, 一般的に使用される ldapsearch オプション
- 使用, ldapsearch の使用
- 使用例, 一般的な ldapsearch の例
- 国際検索, 国際化されたディレクトリーの検索
- 検索フィルター, LDAP 検索フィルター
- 返された属性の制限, 属性のサブセットの表示
- LDAP_BASEDN 環境変数, LDAP_BASEDN の使用
- LDIF
- エントリーの形式, LDAP データ交換形式
- 組織, ドメインエントリーの指定
- 組織単位, 組織単位エントリーの指定
- 組織担当者, 組織の個人エントリーの指定
- エントリーの指定
- 組織, ドメインエントリーの指定
- 組織単位, 組織単位エントリーの指定
- 組織担当者, 組織の個人エントリーの指定
- ディレクトリーの作成に使用, LDIF を使用したディレクトリーの定義
- バイナリーデータ, バイナリーデータの表現
- 例, LDIF を使用したディレクトリーの定義
- 国際化, 複数の言語での情報の保存
- 行継続, LDIF での行継続
- LDIF エントリー
- バイナリーデータ, バイナリーデータの表現
- 作成, LDIF を使用したディレクトリーエントリーの指定
- 組織, ドメインエントリーの指定
- 組織単位, 組織単位エントリーの指定
- 組織担当者, 組織の個人エントリーの指定
- 国際化, 複数の言語での情報の保存
- LDIF ファイル
- 使用しているディレクトリーの作成, LDIF を使用したディレクトリーの定義
- 例, LDIF を使用したディレクトリーの定義
- 国際化, 複数の言語での情報の保存
- 継続した行, LDIF での行継続
- LDIF ユーティリティー
- バイナリーデータの LDIF への変換, Base-64 でエンコード
- LDIF 形式, LDAP データ交換形式
- ldif2db utility, ldif2db コマンドラインユーティリティーを使用したインポート
- オプション, db2index.pl スクリプトの実行
- ldif2db.pl perl script, ldif2db.pl Perl スクリプトを使用したインポート
- ldif2ldap utility, ldif2ldap コマンドラインスクリプトを使用したインポート
- Lockout duration, コンソールを使用したアカウントロックアウトポリシーの設定
- logs
- transaction
- アクセスの表示, コンソールからのログの表示, コマンドラインでのログの表示
- エラーの表示, コンソールからのログの表示, コマンドラインでのログの表示
- ロケーションおよび名前の変更
- コマンドラインで、, コマンドラインでのログ場所の変更
- コンソールでは、以下を行います。, コンソールでのログ名の変更
M
- matchingRule 形式
- OID および接尾辞の使用, マッチングルールでの OID および Suffix の使用
- OID の使用, マッチングルールの形式
- 言語タグおよび接尾辞の使用, 一致するルールに対する言語タグと接尾辞の使用
- 言語タグの使用, マッチングルールに言語タグの使用
- memberOf plug-in
- 設定, MemberOf プラグインのインスタンスの設定
- コマンドラインでの操作, コマンドラインでの MemberOf プラグインの編集
- コンソールから, コンソールからの MemberOf プラグインの編集
- metaphone phonetic アルゴリズム, おおよその検索
- MIB
- Directory Server, 管理情報ベースの使用
- redhat-directory.mib, 管理情報ベースの使用
- エンティティーテーブル, エンティティーテーブル
- エントリーテーブル, エントリー表
- 対話表, 対話表
- 操作表, 操作表
N
- NetscapeRoot
- およびレプリケーション, 管理サーバーのフェイルオーバー用の o=NetscapeRoot の複製
- nsds5ReplicaBusyWaitTime, マルチマスターレプリケーションにおけるコンシューマーの独占を防ぐ
- nsds5ReplicaReleaseTimeout, マルチマスターレプリケーションにおけるコンシューマーの独占を防ぐ
- nsds5ReplicaSessionPauseTime, マルチマスターレプリケーションにおけるコンシューマーの独占を防ぐ
- nsslapd-maxbersize, 大きな属性の追加
- nsslapd-schemacheck 属性, コマンドラインでスキーマチェックのオンおよびオフを切り替え
- nsview, ビューの概要
- nsviewfilter, ビューの概要
O
- objectclass フィールド(LDIF), LDIF ファイルの形式の概要
- OID
- 取得と割り当て, オブジェクト識別子の管理
- OID、オブジェクト識別子を参照してください。, サポート対象のロケール
- Organization(エントリーの指定), ドメインエントリーの指定
P
- PAM パススルー認証, パススルー認証での PAM の使用
- およびアカウントの非アクティブ化, PAM PTA マッピングの設定
- およびパスワードポリシー, パススルー認証での PAM の使用
- エントリーマッピングメソッド, PAM PTA マッピングの設定
- ターゲットサフィックス, PAMPTA のターゲットとなるサフィックスの指定
- 一般的な設定, 汎用 PAM PTA 設定の設定
- 例, PAM パススルー認証の設定
- 設定, PAM パススルー認証の設定
- 設定オプション, PAM パススルー認証設定オプション
- PDU, SNMP の概要
- PKCS#11 モジュール, ハードウェアセキュリティーモジュールの使用
- Pronunciation サブタイプ, 属性サブタイプの追加
- PTA プラグイン
- Directory Server での使用, パススルー認証の使用
- 例, PTA プラグイン構文の例
- 構文, PTA プラグインの構文
- 設定, PTA プラグインの設定
R
- Red Hat Console
- Red Hat 管理コンソール
- Red Hat 管理コンソールのタブ, Red Hat Management Console タブ
- Red Hat 管理コンソールのメニュー, Red Hat 管理コンソールメニュー
- redhat-directory.mib, 管理情報ベースの使用
- エンティティーテーブル, エンティティーテーブル
- エントリーテーブル, エントリー表
- 対話表, 対話表
- 操作表, 操作表
- ref 属性, コマンドラインからのスマートリファーラルの作成
- referral オブジェクトクラス, コマンドラインからのスマートリファーラルの作成
- replica
- LDIF へのエクスポート, レプリカから LDIF へのエクスポート
- read-only, 読み取り/書き込みレプリカおよび読み取り専用レプリカ
- read-write, 読み取り/書き込みレプリカおよび読み取り専用レプリカ
- Retro Changelog
- attributes, Retro Changelog プラグインの使用
- およびアクセス制御, Retro Changelog およびアクセス制御ポリシーの見直し
- オブジェクトクラス, Retro Changelog プラグインの使用
- トリム, Retro Changelog のトリム
- 検索, Retro Changelog およびアクセス制御ポリシーの見直し
- Retro Changelog プラグイン
- roles, ロールの使用
- アクセス制御, セキュアなロールの使用
- アクティベート中, コンソールを使用したユーザーおよびロールのアクティベートおよび非アクティブ化
- ネスティング
- フィルター
- 割り当て, エントリーへのロールの編集と割り当て
- 概要, ロールの概要
- 管理
- 作成, 管理ロールの作成
- 例, コマンドラインでの管理ロールの作成
- Root DSE, ルート DSE エントリーの検索
- root エントリー作成, LDIF を使用したディレクトリーの定義
- root 接尾辞, 接尾辞の作成
- コマンドラインからの作成, コマンドラインでのルート接尾辞およびサブ接尾辞の作成
- コンソールからの作成, コンソールを使用した新規ルート接尾辞の作成
- RUV
- 古いサプライヤーエントリーのパージ, 廃止または不明なエラーの解決
S
- SASL, SASL Identity マッピングの設定
- ID マッピング, SASL Identity マッピングの概要
- default, Directory Server のデフォルトの SASL マッピング
- コマンドラインからの設定, コマンドラインでの SASL Identity マッピングの設定
- コンソールフォームの設定, コンソールからの SASL アイデンティティーマッピングの設定
- Kerberos, SASL での Kerberos GSS-API の使用
- Kerberos レルム, プリンシパルおよびレルムについて
- ldapsearch での使用, LDAP クライアントでの SASL の使用
- コネクションの要求, セキュアな接続の要求
- サーバーのサーバーマッピングの設定, SASL Identity マッピングの概要
- セキュアなバインドの要求, セキュアなバインドの要求
- パスワードの変更拡張操作, 外部に保存されたパスワードの変更
- メカニズム, Directory Server の SASL の認証メカニズム
- CRAM-MD5, Directory Server の SASL の認証メカニズム
- DIGEST-MD5, Directory Server の SASL の認証メカニズム
- EXTERNAL, Directory Server の SASL の認証メカニズム
- GSS-API, Directory Server の SASL の認証メカニズム
- PLAIN, Directory Server の SASL の認証メカニズム
- 概要, SASL Identity マッピングの設定
- 設定
- KDC サーバー, KDC サーバーおよびキータブの概要
- 起動時の認証の設定, Directory Server 起動時の SASL 認証の設定
- schema
- nsslapd-schemacheck 属性, コマンドラインでスキーマチェックのオンおよびオフを切り替え
- standard, ディレクトリースキーマの管理
- オブジェクトクラスの削除, スキーマの削除
- オブジェクトクラスの編集, カスタムスキーマ要素の編集
- オブジェクトクラスの表示, 属性およびオブジェクトクラスの表示
- チェック, スキーマチェックのオンとオフを切り替える
- リロード, スキーマの動的再読み込み
- cn=schema リロードタスク, ldapmodify を使用したスキーマの再読み込み
- schema-reload.pl, schema-reload.pl を使用したスキーマの再読み込み
- 属性の削除, スキーマの削除
- 属性の編集, カスタムスキーマ要素の編集
- 属性の表示, 属性およびオブジェクトクラスの表示
- 拡張, ディレクトリースキーマの管理
- 新しい属性の作成, 属性の作成
- 新規オブジェクトクラスの作成, オブジェクトクラスの作成
- 新規属性の追加, 属性の作成, カスタムスキーマファイルの作成
- 要素の削除, スキーマの削除
- schema-reload.pl, schema-reload.pl を使用したスキーマの再読み込み
- scripts
- cl-dump.pl, レプリケーション関連の問題のトラブルシューティング
- Search Performance, パフォーマンスおよびリソース制限の検索
- server
- Simple Authentication and Security Layer, SASL Identity マッピングの設定
- Simple Network Management Protocol。SNMP を参照してください。, SNMP の概要
- SNMP
- Directory Server の監視, SNMP を使用した Directory Server の監視
- MIB
- エンティティーテーブル, エンティティーテーブル
- エントリーテーブル, エントリー表
- 対話表, 対話表
- 操作表, 操作表
- サブエージェント, SNMP の概要
- マスターエージェント, SNMP の概要
- マネージドデバイス, SNMP の概要
- 概要, SNMP の概要
- 管理オブジェクト, SNMP の概要
- 設定
- Directory Server, SNMP 用の Directory Server の設定
- SSF, セキュアな接続の要求
- standard
- attributes, スキーマの概要
- schema, ディレクトリースキーマの管理
- オブジェクトクラス, スキーマの概要
- subtypes
- 属性, 属性サブタイプの追加
- synchronizing
- パスワード, パスワードの同期
- syntax-validate.pl, 既存の属性値の構文の検証
T
- tasks
- RUV からの古いエントリーのパージ, 廃止または不明なエラーの解決
- TLS, TLS の使用
- CA 証明書エラーメッセージ, Directory Server コンソールが使用する証明書の管理
- Directory Server コンソールの証明書の管理, Directory Server コンソールが使用する証明書の管理
- PKCS#11 モジュールの読み込み, ハードウェアセキュリティーモジュールの使用
- およびレプリケーション, TLS 上のレプリケーション
- コネクションの要求, セキュアな接続の要求
- セキュアなバインドの要求, セキュアなバインドの要求
- チェーンの使用, コンソールを使用した新規データベースリンクの作成, LDAP URL の提供
- ハードウェアセキュリティーモジュールの使用, ハードウェアセキュリティーモジュールの使用
- ポート番号, LDAPS ポート番号の変更
- 暗号化暗号の設定, 暗号化暗号の設定
- 管理サーバーの使用, TLS の有効化
- 管理サーバーパスワードファイル, 管理サーバーのパスワードファイルの作成
- 証明書, 管理サーバーの証明書の管理
- 証明書ベースの認証, 証明書ベースのクライアント認証の使用
- tombstone エントリー
U
- uniqueness-top-entry-oc keyword, オブジェクトクラスに対する属性の一意性の設定
- users
- アクティベート中, コンソールを使用したユーザーおよびロールのアクティベートおよび非アクティブ化
- 非アクティブ化, ユーザーおよびロールの手動による非アクティブ化
- UTF-8, 国際化
V
- vlvIndex コマンドラインツール, インデックスタイプの概要
W
- Windows 同期, Red Hat Directory Server と Microsoft Active Directory の同期
- users, ユーザーの同期
- エントリーの削除, エントリーの削除および復元
- グループ, グループの同期
- コマンドライン
- 複数のサブツリーおよびフィルターの設定, Windows 同期での複数のサブツリーおよびフィルターの設定
- スキーマの相違点, Red Hat Directory Server と Active Directory との間のユーザースキーマの相違点, Red Hat Directory Server と Active Directory のグループスキーマの相違点
- トラブルシューティング, トラブルシューティング
- パスワード同期サービス, パスワード同期サービスの管理
- TLS の設定, ステップ 5: パスワード同期サービス の設定
- アンインストール, パスワード同期サービスの アンインストール
- 修正, パスワード同期の変更
- 起動と停止, パスワード同期サービスの起動と停止
- ロギングレベル, トラブルシューティング
- 削除されたエントリーの再取得, エントリーのレスキュー
- 同期ステータスの確認, 同期ステータスの確認
- 同期合意の変更, 同期合意の変更, コマンドラインでの同期合意の追加および編集
- 情報, Windows 同期の概要
- 手動による更新, 同期更新の送信
- 設定, Windows 同期の設定手順
付録H 改訂履歴
改訂履歴 | |||
---|---|---|---|
改訂 10.6-2 | Mon Dec 07 2020 | ||
| |||
改訂 10.6-1 | Tue Aug 11 2020 | ||
| |||
改訂 10.5-1 | Tue Mar 31 2020 | ||
| |||
改訂 10.4-2 | Mon Aug 26 2019 | ||
| |||
改訂 10.4-1 | Tue Aug 06 2019 | ||
| |||
改訂 10.3-2 | Wed Jun 05 2019 | ||
| |||
改訂 10.3-1 | Wed Oct 24 2018 | ||
| |||
改訂 10.2-1 | Tue Apr 10 2018 | ||
| |||
改訂 10.1-17 | Mon Mar 12 2018 | ||
| |||
改訂 10.1-16 | Wed Feb 14 2018 | ||
| |||
改訂 10.1-15 | Wed Jan 17 2018 | ||
| |||
改訂 10.1-14 | Tue Dec 05 2017 | ||
| |||
改訂 10.1-13 | Mon Nov 06 2017 | ||
| |||
改訂 10.1-11 | Tue Aug 08 2017 | ||
| |||
改訂 10.1-10 | Tue Aug 01 2017 | ||
| |||
改訂 10.1-9 | Mon Jul 31 2017 | ||
| |||
改訂 10.1-8 | Wed Jul 12 2017 | ||
| |||
改訂 10.1-7 | Mon Jun 26 2017 | ||
| |||
改訂 10.1-6 | Mon May 29 2017 | ||
| |||
改訂 10.1-5 | Tue Mar 14 2017 | ||
| |||
改訂 10.1-4 | Fri Feb 24 2017 | ||
| |||
改訂 10.1-3 | Wed Jan 11 2017 | ||
| |||
改訂 10.1-1 | Fri Nov 11 2016 | ||
| |||
改訂 10.1-0 | Mon Oct 31 2016 | ||
| |||
改訂 10.0-3 | Wed Jun 22 2016 | ||
| |||
改訂 10.0-2 | Thu Mar 24 2016 | ||
| |||
改訂 10.0-1 | Wed Jun 17 2015 | ||
| |||
改訂 10.0-0 | Tue Jun 09 2015 | ||
|