管理ガイド
Directory Server の基本および高度な管理
概要
多様性を受け入れるオープンソースの強化
第1章 一般的な Directory Server 管理タスク
1.1. システム要件
1.2. ファイルの場所
1.3. Directory Server を設定するサポート対象のメソッド
- Directory Server が提供するコマンドラインユーティリティー
- Web コンソール
1.4. Web コンソールを使用した Directory Server へのログイン
- ブラウザーを使用して、Directory Server ホストのポート 9090 で実行している Web コンソールに接続します。以下に例を示します。
https://server.example.com:9090
root
ユーザーまたはsudo
権限を持つユーザーとしてログインします。Red Hat Directory Server
エントリーを選択します。
1.5. Directory Server インスタンスの起動および停止
1.5.1. コマンドラインを使用した Directory Server インスタンスの起動および停止
- インスタンスを起動するには、以下を実行します。
# dsctl instance_name start
- インスタンスを停止するには、以下を実行します。
# dsctl instance_name stop
- インスタンスを再起動するには、以下を実行します。
# dsctl instance_name restart
- 単一のインスタンスの場合:
# systemctl enable dirsrv@instance_name
- サーバー上のすべてのインスタンスの場合:
# systemctl enable dirsrv.target
1.5.2. Web コンソールを使用した Directory Server インスタンスの起動および停止
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Start Instance
- Stop Instance
- Restart Instance
1.6. 新規 Directory Server インスタンスの作成
1.7. Directory Server インスタンスの削除
/var/lib/dirsrv/slapd-instance_name/
および /etc/dirsrv/slapd-instance_name/
ディレクトリーの内容が削除されます。
/var/lib/dirsrv/slapd-instance_name/
ディレクトリーには、データベース、バックアップおよびエクスポートディレクトリーが含まれています。/etc/dirsrv/slapd-instance_name/
ディレクトリーには、インスタンス設定とネットワークセキュリティーサービス (NSS) データベースが含まれています。インスタンスを削除する前に、このデータのバックアップを作成します。
1.7.1. コマンドラインを使用したインスタンスの削除
# dsctl instance_name remove --do-it Removing instance ... Completed instance removal
1.7.2. Web コンソールを使用したインスタンスの削除
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Remove instance を選択します。ボタンをクリックし、
1.8. Directory Server の設定パラメーターの設定
1.8.1. 設定パラメーターの管理
dsconf
ユーティリティーの使用:注記Red Hat は、dsconf
ユーティリティーを使用して、Directory Server 設定を管理することを推奨しています。例1.1
dsconf
を使用した設定パラメーターの設定たとえば、エラーログレベルを 16384 に設定するには、dsconf
ユーティリティーを使用して、nsslapd-errorlog-level
パラメーターを更新します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-errorlog-level=16384
dsconf
の使用の詳細については、dsconf(8) man ページを参照してください。- LDAP インターフェイスの使用:
例1.2 LDAP インターフェイスを使用した設定パラメーターの設定
たとえば、エラーログレベルを 16384 に設定するには、LDAP インターフェイスを使用して、nsslapd-errorlog-level
パラメーターを更新します。# ldapmodify -D "cn=Directory Manager" -W -x -H ldap://server.example.com:389 dn: cn=config replace: nsslapd-errorlog-level nsslapd-errorlog-level: 16384
/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルを編集します。警告インスタンスが正常に起動している限り、このファイルは手動で編集しないでください。これは、Directory Server が想定どおりに機能しないか、インスタンスの起動に失敗する可能性があるためです。
1.8.2. Directory Server が設定を保存する場所
/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルに保存します。サーバーは、このファイルで変更したパラメーターのみを保存します。リストにない属性には、デフォルト値を使用します。これにより、/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルを表示して、このインスタンスに設定したすべての設定パラメーターを識別できます。
/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルを手動で編集しないでください。
1.8.3. デフォルト値を使用する利点
passwordStorageScheme
属性を指定すると、Directory Server は、サポートされている利用可能な最も強力なパスワード保存スキームを自動的に使用します。今後の更新で、セキュリティーを向上させるデフォルト値を変更すると、パスワードを設定する際に、新しいストレージスキームを使用してパスワードが自動的に暗号化されます。
1.8.3.1. デフォルト値を使用するパラメーターの削除
# dsconf -D "cn=Directory Manager" ldap://server.example.com config delete parameter_name
nsslapd-secureport
など、特定のパラメーターは、削除して、デフォルトにリセットすることはできません。それらを削除しようとすると、サーバーは Server is unwilling to perform (53) エラーでリクエストを拒否します。
1.8.4. dsconf config backend
コマンドの制限事項
dsconf config backend
コマンドは、バックエンド設定を取得および設定します。このコマンドには次の引数があります。
- get
- set
dsconf config backend get
コマンドは、設定された値を持つすべてのサーバーバックエンド設定属性を取得します。次に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com:389 backend config get nsslapd-lookthroughlimit: 5000 nsslapd-mode: 600 nsslapd-idlistscanlimit: 2147483646 …
dsconf config backend get
コマンドを使用すると、指定された属性の値ではなく、属性値の完全なセットのみを取得できます。
dsconf config backend set
コマンドは、バックエンド設定属性を個別に設定します。値を設定するには、LDAP 属性名に一致するオプションを指定します。たとえば、次のようになります。
# dsconf -D "cn=Directory Manager" ldap://server.example.com:389 backend config set --lookthroughlimit 4000 --cache-autosize-split 24
dsconf backend config set
コマンドのオプションと LDAP 属性名のマッピングを示します。
dsconf backend config set コマンドのオプション | LDAP 属性名 |
---|---|
--lookthroughlimit | nsslapd-lookthroughlimit |
--mode | nsslapd-mode |
--idlistscanlimit | nsslapd-idlistscanlimit |
--directory | nsslapd-directory |
--dbcachesize | nsslapd-dbcachesize |
--logdirectory | nsslapd-db-logdirectory |
--txn-wait | nsslapd-db-transaction-wait |
--checkpoint-interval | nsslapd-db-checkpoint-interval |
--compactdb-interval | nsslapd-db-compactdb-interval |
--compactdb-time | nsslapd-db-compactdb-time |
--txn-batch-val | nsslapd-db-transaction-batch-val |
--txn-batch-min | nsslapd-db-transaction-batch-min-wait |
--txn-batch-max | nsslapd-db-transaction-batch-max-wait |
--logbufsize | nsslapd-db-logbuf-size |
--locks | nsslapd-db-locks |
--locks-monitoring-enabled | nsslapd-db-locks-monitoring-enabled |
--locks-monitoring-threshold | nsslapd-db-locks-monitoring-threshold |
--locks-monitoring-pause | nsslapd-db-locks-monitoring-pause |
--import-cache-autosize | nsslapd-import-cache-autosize |
--import-cachesize | nsslapd-import-cachesize |
--cache-autosize | nsslapd-cache-autosize |
--cache-autosize-split | nsslapd-cache-autosize-split |
--exclude-from-export | nsslapd-exclude-from-export |
--pagedlookthroughlimit | nsslapd-pagedlookthroughlimit |
--pagedidlistscanlimit | nsslapd-pagedidlistscanlimit |
--rangelookthroughlimit | nsslapd-rangelookthroughlimit |
--backend-opt-level | nsslapd-backend-opt-level |
--deadlock-policy | nsslapd-db-deadlock-policy |
--db-home-directory | nsslapd-db-home-directory |
--db-lib | nsslapd-backend-implement |
1.9. LDAP および LDAPS ポート番号の変更
1.9.1. コマンドラインを使用したポート番号の変更
nsslapd-port
: インスタンスが LDAP プロトコルに使用するポート番号を保存します。nsslapd-secureport
: インスタンスが LDAPS プロトコルに使用するポート番号を保存します。
- 必要に応じて、インスタンスに現在設定されているポート番号を表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config get nsslapd-port nsslapd-secureport nsslapd-port: 389 nsslapd-secureport: 636
- LDAP ポートを変更するには、以下を行います。
- LDAP プロトコルのポートを設定します。たとえば、
1389
に設定するには、以下を実行します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-port=1389 Successfully replaced "nsslapd-port"
- 前の手順で割り当てた LDAP ポートの
ldap_port_t
タイプを設定します。# semanage port -a -t ldap_port_t -p tcp 1389
- LDAPS ポートを変更するには、以下を実行します。
- LDAPS プロトコルのポートを設定します。たとえば、
1636
に設定するには、以下を実行します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-secureport=1636 Successfully replaced "nsslapd-secureport"
- 前の手順で割り当てた LDAPS ポートの
ldap_port_t
タイプを設定します。# semanage port -a -t ldap_port_t -p tcp 1636
- インスタンスを再起動します。
# dsctl instance_name restart
1.9.2. Web コンソールを使用したポート番号の変更
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- LDAP ポートを変更するには、以下を行います。
- Server Settings タブで、新しいポート番号を LDAP Port フィールドに入力します。
- LDAPS ポートを変更するには、以下を実行します。
- General Settings タブで、新しいポート番号を LDAPS Port フィールドに入力します。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
1.10. Directory Server プラグインの使用
1.10.1. 利用可能なプラグインのリスト表示
1.10.1.1. コマンドラインを使用した利用可能なプラグインのリスト表示
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin list 7-bit check Account Policy Plugin ...
1.10.1.2. Web コンソールを使用した利用可能なプラグインのリスト表示
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
1.10.2. プラグインの有効化および無効化
1.10.2.1. コマンドラインでプラグインの有効化および無効化
- プラグインを有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin automember enable
- インスタンスを再起動します。
# dsctl instance_name restart
1.10.2.2. Web コンソールを使用したプラグインの有効化および無効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- All Plugins タブを選択します。
- 有効または無効にするプラグインの右側にあるボタンをクリックします。
- ステータスを ON に変更してプラグインを有効にするか、OFF に変更して無効にします。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
1.10.3. プラグインの設定
1.10.3.1. コマンドラインでプラグインの設定
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin \ plug-in-specific_subcommand ...
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin --help
1.10.3.2. Web コンソールを使用したプラグインの設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- All Plugins タブを選択します。
- プラグインを選択し、Show Advanced Settings をクリックします。
- プラグイン固有のタブを開きます。
- 適切な設定を行います。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
1.10.4. プラグインの優先順位の設定
1.10.4.1. コマンドラインを使用したプラグインの優先順位の設定
- プラグインの優先順位を設定します。たとえば、
example
プラグインの優先順位を 1 に設定するには、次のようにします。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin edit example --precedence 1
- インスタンスを再起動します。
# dsctl instance_name restart
1.10.4.2. Web コンソールを使用したプラグインの優先順位の設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- All Plugins を選択します。
- 優先順位の値を設定するプラグインの横にあるボタンを押します。
- Plugin Precedence フィールドの値を更新します。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
1.11. .dsrc ファイルを作成して使用し、Directory Server コマンドラインユーティリティーのデフォルトオプションを設定する
~/.dsrc
ファイルは、Directory Server コマンドラインユーティリティーを使用するコマンドを簡素化します。デフォルトでは、これらのユーティリティーでは、LDAP URL やバインド識別名 (DN) などをコマンドに渡す必要があります。これらの設定を ~/dsrc
ファイルに保存すると、毎回これらの設定を指定しなくても、コマンドラインユーティリティーを使用できます。
1.11.1. .dsrc ファイルがコマンドを簡素化する方法
~/.dsrc
ファイルの例です。
[server1] uri = ldap://server1.example.com binddn = cn=Directory Manager basedn = dc=example,dc=com
# dsidm server1 user create
~/.dsrc
ファイルがない場合は、コマンドでバインド DN、LDAP URL、およびベース DN を指定する必要があります。
# dsidm -D cn=Directory Manager ldap://server1.example.com -b "dc=example,dc=com" user create
1.11.2. dsctl ユーティリティーを使用して .dsrc ファイルを作成する
~/.dsrc
ファイルを手動で作成する代わりに、dsctl
ユーティリティーを使用して作成できます。
# dsctl instance_name dsrc create ...
--uri
: protocol://host_name_or_IP_address_or_socket の形式で URL をインスタンスに設定します。例 :--uri ldap://server.example.com
--uri = ldaps://server.example.com
--uri = ldapi://%%2fvar%%2frun%%2fslapd-instance_name.socket
Directory Server ソケットへのパスを設定する場合は、パスにスラッシュ (/) ではなく %%02 を使用します。重要ldapi URL を使用すると、サーバーは、Directory Server コマンドラインユーティリティーを実行するユーザーのユーザー ID (UID) とグループ ID (GID) を識別します。root
ユーザーとしてコマンドを実行すると、UID と GID の両方が 0 になり、Directory Server は、対応するパスワードを入力しなくても、cn=Directory Manager
としてユーザーを自動的に認証します。
--starttls
: LDAP ポートに接続し、STARTTLS コマンドを送信して、暗号化された接続に切り替えるように、ユーティリティーを設定します。--basedn
: 基本識別名 (DN) を設定します。例:--basedn dc=example,dc=com
--binddn
: バインド DN を設定します。例:--binddn cn=Directory Manager
--pwdfile
: バインド DN のパスワードを含むファイルへのパスを設定します。例:--pwdfile /root/rhds.pwd
--tls-cacertdir
: LDAPS 接続を使用する場合、このパラメーターに設定されたパスは、サーバーの証明書を検証するために必要な認証局 (CA) 証明書を含むディレクトリーを定義します。例:--tls-cacertdir /etc/pki/CA/certs/
指定したディレクトリーに CA 証明書をコピーした後、c_rehash /etc/pki/CA/certs/ コマンドを使用する必要があることに注意してください。--tls-cert
: サーバーの証明書への絶対パスを設定します。例:--tls-cert /etc/dirsrv/slapd-instance_name/Server-Cert.crt
--tls-key
: サーバーの秘密鍵への絶対パスを設定します。例:--tls-key /etc/dirsrv/slapd-instance_name/Server-Cert.key
--tls-reqcert
: クライアントユーティリティーが TLS セッションでサーバー証明書に対して実行するチェックを設定します。例:--tls-reqcert hard
以下のパラメーターを利用することができます。- never: ユーティリティーはサーバー証明書を要求または確認しません。
- allow: ユーティリティーは証明書エラーを無視し、接続はとにかく確立されます。
- hard: ユーティリティーは証明書エラーで接続を終了します。
--saslmech
: 使用する SASL メカニズムを PLAIN または EXTERNAL に設定します。例:--saslmech PLAIN
1.11.3. Directory Server ユーティリティー使用時のリモートおよびローカル接続の解決
/etc/openldap/ldap.conf
設定ファイルをチェックします。
~/.dsrc
ファイルが存在するかどうかを確認し、次のロジックを適用して続行します。
~/.dsrc
ファイルが存在し、インスタンス名と LDAP URL の両方が含まれている場合、Directory Server は、それをリモート接続と見なし、/etc/openldap/ldap.conf
設定ファイルとシステム全体の設定をチェックします。~/.dsrc
ファイルが存在し、指定されたインスタンス名のみが含まれている場合、または~/.dsrc
ファイルが存在しない場合、Directory Server は、それをローカル接続と見なし、ローカルのdse.ldif
ファイルのnsslapd-certdir
設定を使用して、接続を保護します。nsslapd-certdir
が存在しない場合、サーバーは、デフォルトパス/etc/dirsrv/slapd-instance_name/
を使用して、インスタンスの Network Security Services (NSS) データベースを保存します。
nsslapd-certdir
パラメーターの詳細については、nsslapd-certdir (証明書と鍵のデータベースディレクトリー) セクションを参照してください。
第2章 ディレクトリーデータベースの設定
2.1. 接尾辞の作成および維持
図2.1 1 つのルート接尾辞があるディレクトリーツリー
ou=people
接尾辞とその下のすべてのエントリーとノードが 1 つのデータベースに保存され、ou=groups
接尾辞が別のデータベースに保存され、ou=contractors 接尾辞がさらに別のデータベースに保存される場合があります。
2.1.1. 接尾辞の作成
2.1.1.1. ルート接尾辞の作成
example.com
用と redhat.com
用の複数の Web サイトをホスティングするインターネットサービスプロバイダーなどです。このシナリオでは、2 つのルート接尾辞が必要です。次の図に示すように、1 つは dc=example,dc=com
命名コンテキストに対応し、もう 1 つは dc=redhat,dc=com
命名コンテキストに対応します。
図2.2 2 つのルート接尾辞があるディレクトリー
dc=example,dc=com
に対応し、もう 1 つのルート接尾辞はディレクトリーツリーのヨーロッパブランチ ou=europe,dc=example,dc=com
に対応します。クライアントアプリケーションの観点では、ディレクトリーツリーは以下の図のように示されます。
図2.3 検索操作への制限がオフのルート接尾辞があるディレクトリー
dc=example,dc=com
ブランチでクライアントアプリケーションによって実行される検索では、ディレクトリーの ou=europe,dc=example,dc=com
ブランチからのエントリーは返されません。これは、別のルート接尾辞であるためです。
2.1.1.1.1. コマンドラインでルート接尾辞の作成
- 必要に応じて、使用中の接尾辞およびバックエンドデータベースを指定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list dc=example,dc=com (userroot)
括弧内の名前は、対応する接尾辞のデータを保存するバックエンドデータベースです。次の手順でルートの接尾辞を作成する場合は、既存のデータベース名を使用することはできません。 example
バックエンドデータベースに dc=example,dc=net ルート接尾辞を作成します。# dsconf -D "cn=Directory Manager" ldap://server.example.com backend create \ --suffix="dc=example,dc=net" --be-name="example"
2.1.1.1.2. Web コンソールを使用したルート接尾辞の作成
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 接尾辞 DN およびバックエンド名を入力します。以下に例を示します。
- Create The Top Suffix Entry を選択します。
2.1.1.2. 従属接尾辞の作成
図2.4 従属接尾辞が含まれるディレクトリーツリー
2.1.1.2.1. コマンドラインを使用した従属接尾辞の作成
- 必要に応じて、使用中の接尾辞およびバックエンドデータベースを指定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list dc=example,dc=com (userroot)
括弧内の名前は、対応する接尾辞のデータを保存するバックエンドデータベースです。次の手順で従属接尾辞を作成する場合は、既存のデータベース名を使用することはできません。 - 従属接尾辞を作成します。たとえば、
example
バックエンドデータベースとともに ou=People,dc=example,dc=com サブ接尾辞を作成するには、次のように入力します。# dsconf -D "cn=Directory Manager" ldap://server.example.com backend create \ --suffix="ou=People,dc=example,dc=com" --be-name="example" \ --parent-suffix="dc=example,dc=com"
2.1.1.2.2. Web コンソールを使用した副接尾辞の作成
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- サブ接尾辞を作成する接尾辞を選択し、をクリックして、 を選択します。
- 従属接尾辞 DN およびバックエンド名を入力します。以下に例を示します。
- Create The Top Sub-Suffix Entry を選択します。
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. コマンドラインでの接尾辞の無効化
- 接尾辞とそれに対応するバックエンドを表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list dc=example,dc=com (userroot) o=test (test_database)
このコマンドにより、各接尾辞の横にバックエンドデータベースが表示されます。次の手順で、接尾辞のデータベース名が必要です。 - 接尾辞を無効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend \ suffix set --disable "test_database"
2.1.2.3. 接尾辞の削除
2.1.2.3.1. コマンドラインを使用した接尾辞の削除
- 接尾辞とそれに対応するバックエンドを表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list dc=example,dc=com (userroot) o=test (test_database)
このコマンドにより、各接尾辞の横にバックエンドデータベースが表示されます。次の手順で、接尾辞のデータベース名が必要です。 - バックエンドデータベースと対応する接尾辞を削除します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend delete test_database Deleting Backend cn=test_database,cn=ldbm database,cn=plugins,cn=config : Type 'Yes I am sure' to continue: Yes I am sure The database, and any sub-suffixes, were successfully deleted
2.1.2.3.2. Web コンソールを使用した接尾辞の削除
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 接尾辞を選択し、Delete Suffix. を選択します。をクリックして
2.2. データベースの作成および維持
dsconf
ユーティリティーまたは Web コンソールを使用して接尾辞を作成すると、Directory Server はデータベースを自動的に作成していました。
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. コマンドラインを使用した単一の接尾辞用の新規データベースの作成
ldapmodify
コマンドラインユーティリティーを使用して、ディレクトリー設定ファイルに新しいデータベースを追加します。データベース設定情報は cn=ldbm database,cn=plugins,cn=config エントリーに保存されます。新しいデータベースを追加するには、以下を実行します。
- ldapmodify を実行して、新規データベースのエントリーを作成します。
# ldapmodify
-a
-D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=UserData,cn=ldbm database,cn=plugins,cn=config changetype: add objectclass: extensibleObject objectclass: nsBackendInstance nsslapd-suffix: ou=people,dc=example,dc=com追加されたエントリーは UserData という名前のデータベースに対応します。このデータベースには root 接尾辞または副接尾辞 ou=people,dc=example,dc=com のデータが含まれます。 - 「コマンドラインでルート接尾辞の作成」 および 「コマンドラインを使用した従属接尾辞の作成」 で説明されているように、ルートまたは従属接尾辞を作成します。DN 属性に指定されたデータベース名は、接尾辞エントリーの
nsslapd-backend
属性の値に対応している必要があります。
2.2.1.2. 単一の接尾辞に複数のデータベースの追加
- ディストリビューション機能は、エントリーディストリビューションのデプロイ後は変更できません。
- エントリーを異なるデータベースに分散させる可能性がある場合は、LDAP modrdn 操作を使用してエントリーの名前を変更することができません。
- 分散ローカルデータベースは複製できません。
- エントリーを異なるデータベースに分散させる可能性がある場合は、ldapmodify 操作を使用してエントリーを変更することができません。
- 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. コマンドラインを使用した読み取り専用モードでのデータベースの設定
o=test
接尾辞のデータベースを読み取り専用モードで設定するには、以下を実行します。
- 接尾辞とそれに対応するバックエンドを表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list dc=example,dc=com (userroot) o=test (test_database)
このコマンドにより、各接尾辞の横にバックエンドデータベースが表示されます。次の手順で、接尾辞のデータベース名が必要です。 - データベースを読み取り専用モードで設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix set --enable-readonly "test_database"
2.2.2.1.2. Web コンソールを使用した読み取り専用モードでのデータベースの設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 接尾辞エントリーを選択します。
- Database Read-Only Mode を選択します。
2.2.2.2. 読み取り専用モードでの Directory Server の配置
2.2.2.2.1. コマンドラインを使用した読み取り専用モードでの Directory Server の配置
nsslapd-readonly
パラメーターを on に設定します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-readonly=on
- インスタンスを再起動します。
# dsctl instance_name restart
2.2.2.2.2. Web コンソールを使用した読み取り専用モードでの Entire Directory Server の配置
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Server Settings エントリーを選択します。メニューを開き、
- Advanced Settings タブで Server Read-Only を選択します。
- Save をクリックします。
2.2.2.3. データベースの削除
2.2.2.3.1. コマンドラインを使用したデータベースの削除
o=test
接尾辞のデータベースを削除するには、以下を実行します。
- 接尾辞とそれに対応するバックエンドを表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list dc=example,dc=com (userroot) o=test (test_database)
次の手順で、接尾辞の横に表示されるバックエンドデータベースの名前が必要です。 - データベースを削除します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend delete "test_database"
2.2.2.3.2. Web コンソールを使用したデータベースの削除
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 削除する接尾辞を選択し、Delete Suffix を選択します。をクリックして
2.2.2.4. トランザクションログディレクトリーの変更
- Directory Server インスタンスを停止します。
# dsctl instance_name stop
- トランザクションログ用に新しい場所を作成します。以下に例を示します。
# mkdir -p /srv/dirsrv/instance_name/db/
- Directory Server のみがディレクトリーにアクセスできるように、パーミッションを設定します。
# chown dirsrv:dirsrv /srv/dirsrv/instance_name/db/ # chmod 770 /srv/dirsrv/instance_name/db/
- 以前のトランザクションログディレクトリーからすべての
__db.*
ファイルを削除します。以下に例を示します。# rm /var/lib/dirsrv/slapd-instance_name/db/__db.*
- 以前のトランザクションログディレクトリーから新しいトランザクションログディレクトリーに、すべての
log.*
ファイルを移動します。以下に例を示します。# mv /var/lib/dirsrv/slapd-instance_name/db/log.* \ /srv/dirsrv/instance_name/db/
- SELinux が enforcing モードで実行している場合は、ディレクトリーに
dirsrv_var_lib_t
コンテキストを設定します。# semanage fcontext -a -t dirsrv_var_lib_t /srv/dirsrv/instance_name/db/ # restorecon -Rv /srv/dirsrv/instance_name/db/
/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルを編集し、cn=config,cn=ldbm database,cn=plugins,cn=config エントリーのnsslapd-db-logdirectory
パラメーターを更新します。以下に例を示します。dn: cn=config,cn=ldbm database,cn=plugins,cn=config ... nsslapd-db-logdirectory: /srv/dirsrv/instance_name/db/
- インスタンスを起動します。
# dsctl instance_name start
2.3. データベースリンクの作成および維持
2.3.1. 新規データベースリンクの作成
- 接尾辞の情報。接尾辞は、通常のデータベースではなく、データベースリンクが管理するディレクトリーツリーに作成されます。この接尾辞は、データが含まれるリモートサーバーの接尾辞に対応します。
- バインド認証情報。データベースリンクがリモートサーバーにバインドされると、ユーザーのなりすましが行われ、リモートサーバーとバインドするために使用する各データベースリンクの DN および認証情報を指定します。
- LDAP URL。これは、データベースリンクが接続するリモートサーバーの LDAP URL を提供します。URL はプロトコル (ldap または ldaps)、サーバーのホスト名または IP アドレス (IPv4 または IPv6)、およびポートで設定されます。
- フェイルオーバーサーバーのリスト。これは、障害発生時にデータベースリンクが接続するための代替サーバーのリストを提供します。この設定項目は任意です。
2.3.1.1. コマンドラインを使用した新規データベースリンクの作成
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining link-create --suffix="ou=Customers,dc=example,dc=com" --server-url="ldap://remote_server.example.com:389" --bind-mech="" --bind-dn="cn=proxy_user,cn=config" --bind-pw="password" "example_chain_name"
ou=Customers,dc=example,dc=com
の example_chain_name
という名前のデータベースリンクが作成されます。リンクはサーバー ldap://remote_server.example.com:389
を参照し、指定のバインド DN とパスワードを使用して認証を行います。--bind-mech が空に設定されているため、リンクは簡易認証を使用します。
dc=example,dc=com
接尾辞にプロキシー ACI エントリーを作成する必要があります。その方法については、「データベースリンクの作成時に必要な設定に関する追加情報」 セクションを参照してください。
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining link-create --help
2.3.1.2. Web コンソールを使用した新規データベースリンクの作成
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 「接尾辞の作成」 で説明されているように、新しい接尾辞を作成します。
- 接尾辞を選択し、Create Database Link を選択します。をクリックして
- フィールドに、リモートサーバーへのコネクションの詳細を入力します。以下に例を示します。詳細は、「データベースリンクの作成時に必要な設定に関する追加情報」を参照してください。
2.3.1.3. 新規データベースリンクのデフォルト設定の管理
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-get-def
response-delay
パラメーターを 30
に設定するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-set-def --response-delay 30
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-set-def --help
2.3.1.4. データベースリンクの作成時に必要な設定に関する追加情報
接尾辞情報
バインド認証情報
creatorsName
属性および modifiersName
属性にはエントリーの実際の作成者または修正者が反映されません。これらの属性には、リモートデータサーバーでプロキシー認証権限が付与されている管理ユーザーの名前が含まれています。
- データベースリンク用に、
cn=proxy_user,cn=config
などの管理ユーザーを作成します。エントリーの追加に関する詳細は、3章ディレクトリーエントリーの管理を参照してください。 - データベースリンクによってチェーンされたサブツリーの直前の手順で作成した管理ユーザーのプロキシーアクセス権限を提供します。ACI の設定に関する詳細は、18章アクセス制御の管理を参照してください。たとえば、以下の ACI は、ACI が設定されたサブツリー内のみにリモートサーバーに含まれるデータにアクセスするために、
cn=proxy_admin,cn=config
ユーザーへの読み取り専用アクセスを付与します。aci: (targetattr = "*")(version 3.0; acl "Proxied authorization for database links"; allow (proxy) userdn = "ldap:///cn=proxy_admin ,cn=config";)
LDAP URL
ldaps://africa.example.com:636/
バインドメカニズム
- 標準の LDAP ポートを使用する場合
- 専用の LDAPS ポートを使用する場合
- STARTTLS (標準ポートでのセキュアな接続) の使用
- empty: バインドメカニズムが設定されていない場合、サーバーは単純な認証を実行し、バインド DN とパスワードが必要になります。
- EXTERNAL: これは TLS 証明書を使用して、ファームサーバーをリモートサーバーに認証します。ファームサーバーをセキュアな URL (ldaps) に設定するか、
nsUseStartTLS
属性を on に設定する必要があります。さらに、『Red Hat Directory Server 設定、コマンド、およびファイルリファレンス』 の 『certmap.conf』 セクションで説明されているように、ファームサーバーの証明書をバインド ID にマッピングするようにリモートサーバーを設定する必要があります。 - DIGEST-MD5: DIGEST-MD5 暗号化での SASL 認証を使用します。簡易認証と同様、バインド情報を付与するには、
nsMultiplexorBindDN
およびnsMultiplexorCredentials
属性が必要です。 - GSSAPI: SASL 上で Kerberos ベースの認証を使用します。ファームサーバーは Kerberos キータブで設定する必要があるため、リモートサーバーには、そのファームサーバーのバインド ID に対して定義された SASL マッピングが必要です。Kerberos キータブおよび SASL マッピングの設定は、「SASL Identity マッピングの設定」に記載されています。
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. コマンドラインを使用したコンポーネント操作の連鎖
- チェーンに追加するコンポーネントを指定します。たとえば、整合性コンポーネントが連鎖操作を実行できるように設定するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-set \ --add-comp="cn=referential integrity postoperation,cn=components,cn=config"
連鎖が可能なコンポーネントのリストは、「コンポーネントの動作の連鎖」を参照してください。 - インスタンスを再起動します。
# dsctl instance_name restart
- 操作を連鎖させるリモートサーバーの接尾辞に ACI を作成します。たとえば、Rerefer Integrity プラグインに ACI を作成するには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h remoteserver.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr = "*")(target="ldap:///ou=customers,l=us,dc=example,dc=com") (version 3.0; acl "RefInt Access for chaining"; allow (read,write,search,compare) userdn = "ldap:///cn=referential integrity postoperation,cn=plugins,cn=config";)
2.3.2.1.2. Web コンソールを使用したコンポーネントの操作の連鎖
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 左側のナビゲーションで、エントリーを選択します。
- Components to Chain フィールドの下にある ボタンをクリックします。
- コンポーネントを選択し、をクリックします。
- 操作を連鎖させるリモートサーバーの接尾辞に ACI を作成します。たとえば、Rerefer Integrity プラグインに ACI を作成するには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h remoteserver.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr = "*")(target="ldap:///ou=customers,l=us,dc=example,dc=com") (version 3.0; acl "RefInt Access for chaining"; allow (read,write,search,compare) userdn = "ldap:///cn=referential integrity postoperation,cn=plugins,cn=config";)
2.3.2.2. LDAP 制御チェーン
- 仮想リストビュー (VLV)。この制御は、すべてのエントリー情報を返すのではなく、エントリーの一部のリストを提供します。
- サーバー側のソート。この制御では、通常は特定のマッチングルールを使用して、エントリーを属性値に従ってソートます。
- 逆参照。この制御では、参照されたエントリーから指定された属性情報を取得し、この情報を残りの検索結果とともに返します。
- 管理 DSA。この制御は、参照に従うのではなく、スマート参照をエントリーとして返します。そのため、スマートの参照自体は変更または削除できます。
- ループ検出。この制御では、別のサーバーとのサーバー連鎖の回数を追跡します。数が設定された数に達すると、ループが検出され、クライアントアプリケーションに通知が送信されます。この制御の使用方法は、「ループの検出」を参照してください。
コントロール名 | OID |
---|---|
仮想リストビュー (VLV) | 2.16.840.1.113730.3.4.9 |
サーバー側のソート | 1.2.840.113556.1.4.473 |
管理 DSA | 2.16.840.1.113730.3.4.2 |
ループ検出 | 1.3.6.1.4.1.1466.29539.12 |
検索の逆参照 | 1.3.6.1.4.1.4203.666.5.16 |
2.3.2.2.1. コマンドラインを使用した LDAP コントロールの連鎖
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining \ config-set --add-control="2.16.840.1.113730.3.4.9"
2.3.2.2.2. Web コンソールを使用した LDAP 制御の連鎖
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Forwarded LDAP Controls フィールドの下にある ボタンをクリックします。
- LDAP コントロールを選択し、をクリックします。Directory Server のクライアントが独自の制御を作成し、その操作をリモートサーバーにチェーンする必要がある場合は、カスタムコントロールのオブジェクト識別子 (OID) を追加します。連鎖可能な LDAP コントロールとその OID のリストは、表2.1「LDAP コントロールとその OID」を参照してください。
2.3.3. データベースリンクおよびアクセス制御評価
- すべての種類のアクセス制御を使用できるわけではありません。たとえば、ロールベースまたはフィルターベースの 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. コマンドラインを使用したカスケード連鎖の設定
Server 1 の設定手順
- 接尾辞 c=africa,ou=people,dc=example,dc=com を作成します。
# dsconf -D "cn=Directory Manager" ldap://server1.example.com backend create --parent-suffix="ou=people,dc=example,dc=com" --suffix="c=africa,ou=people,dc=example,dc=com"
- DBLink1 データベースリンクを作成します。
# dsconf -D "cn=Directory Manager" ldap://server1.example.com chaining link-create --suffix="c=africa,ou=people,dc=example,dc=com" --server-url="ldap://africa.example.com:389/" --bind-mech="" --bind-dn="cn=server1 proxy admin,cn=config" --bind-pw="password" --check-aci="off" "DBLink1"
- ループ検出を有効にします。
# dsconf -D "cn=Directory Manager" ldap://server1.example.com chaining config-set --add-control="1.3.6.1.4.1.1466.29539.12"
Server 2 上の設定手順
- Server 1 をプロキシー承認に使用するプロキシー管理ユーザーを Server 2 に作成します。
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server2.example.com -x dn: cn=server1 proxy admin,cn=config objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: server1 proxy admin sn: server1 proxy admin userPassword: password description: Entry for use by database links
重要セキュリティー上の理由から、cn=Directory Manager
アカウントは使用しないでください。 - 接尾辞 ou=Zanzibar,c=africa,ou=people,dc=example,dc=com を作成します。
# dsconf -D "cn=Directory Manager" ldap://server2.example.com backend create --parent-suffix="c=africaou=people,dc=example,dc=com" --suffix="ou=Zanzibar,c=africa,ou=people,dc=example,dc=com"
- DBLink2 データベースリンクを作成します。
# dsconf -D "cn=Directory Manager" ldap://server2.example.com chaining link-create --suffix="ou=Zanzibar,c=africa,ou=people,dc=example,dc=com" --server-url="ldap://zanz.africa.example.com:389/" --bind-mech="" --bind-dn="server2 proxy admin,cn=config" --bind-pw="password" --check-aci="on "DBLink2"
DBLink2
リンクはカスケード連鎖設定の中間データベースリンクであるため、ACL チェックを有効にして、クライアントとプロキシーの管理ユーザーによるデータベースリンクへのアクセスを許可するかどうかをサーバーが確認できるようにします。 - ループ検出を有効にします。
# dsconf -D "cn=Directory Manager" ldap://server2.example.com chaining config-set --add-control="1.3.6.1.4.1.1466.29539.12"
- プロキシー認証制御を有効にします。
# dsconf -D "cn=Directory Manager" ldap://server2.example.com chaining config-set --add-control="2.16.840.1.113730.3.4.12"
- ローカルプロキシー認証 ACI を追加します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server2.example.com -x dn: c=africa,ou=people,dc=example,dc=com changetype: modify add: aci aci:(targetattr="*")(target="lou=Zanzibar,c=africa,ou=people,dc=example,dc=com") (version 3.0; acl "Proxied authorization for database links"; allow (proxy) userdn = "ldap:///cn=server1 proxy admin,cn=config";)
- Server 1 の c=us,ou=people,dc=example,dc=com にいる
uid
属性セットを持つユーザーが、Server 3 の ou=Zanzibar,c=africa,ou=people,dc=example,dc=com の接尾辞ツリーに対して、任意のタイプの操作を実行できるようにする ACI を追加します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server2.example.com -x dn: c=africa,ou=people,dc=example,dc=com changetype: modify add: aci aci:(targetattr="*")(target="ou=Zanzibar,c=africa,ou=people,dc=example,dc=com") (version 3.0; acl "Client authorization for database links"; allow (all) userdn = "ldap:///uid=*,c=us,ou=people,dc=example,dc=com";)
Server 3 に、Server 3 で追加の権限を必要とする別の接尾辞のユーザーが存在する場合は、Server 2 にさらにクライアント ACI を追加する必要があります。
Server 3 の設定手順
- Server 3 でプロキシー管理ユーザーを作成し、Server 2 をプロキシー承認に使用するプロキシー管理ユーザーを作成します。
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server3.example.com -x dn: cn=server2 proxy admin,cn=config objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: server2 proxy admin sn: server2 proxy admin userPassword: password description: Entry for use by database links
重要セキュリティー上の理由から、cn=Directory Manager
アカウントは使用しないでください。 - ローカルプロキシー認証 ACI を追加します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server3.example.com -x dn: ou=Zanzibar,ou=people,dc=example,dc=com changetype: modify add: aci aci: (targetattr = "*")(version 3.0; acl "Proxied authorization for database links"; allow (proxy) userdn = "ldap:///cn=server2 proxy admin,cn=config";)
- Server 1 の c=us,ou=people,dc=example,dc=com にいる
uid
属性セットを持つユーザーが、Server 3 の ou=Zanzibar,c=africa,ou=people,dc=example,dc=com の接尾辞ツリーに対して、任意のタイプの操作を実行できるようにする ACI を追加します。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server3.example.com -x dn: ou=Zanzibar,ou=people,dc=example,dc=com changetype: modify add: aci aci: (targetattr ="*")(target="ou=Zanzibar,c=africa,ou=people,dc=example,dc=com") (version 3.0; acl "Client authentication for database link users"; allow (all) userdn = "ldap:///uid=*,c=us,ou=people,dc=example,dc=com";)
Server 3 に、Server 3 で追加の権限を必要とする別の接尾辞のユーザーが存在する場合は、Server 2 にさらにクライアント ACI を追加する必要があります。
2.4.3. ループの検出
nsHopLimit
パラメーターを使用して定義されます。デフォルトでは、パラメーターは 10 に設定されます。たとえば、example
チェーンのホップ制限を 5 に設定するには、以下のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining link-set --hop-limit 5 example
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 でのデフォルトの場所です。- port は、リファーラルモードで開始する Directory Server のオプションのポート番号です。
- referral_url は、クライアントに返される参照先です。LDAP URL の形式は、付録C LDAP URLを参照してください。
2.5.2. デフォルト参照の設定
2.5.2.1. コマンドラインを使用したデフォルトのリファーラルの設定
nsslapd-referral
パラメーターのデフォルトのリファーラルを設定します。たとえば、ldap://directory.example.com/
をデフォルトのリファーラルとして設定するには、以下のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-referral="ldap://directory.example.com/"
2.5.3. スマートリファーラルの作成
2.5.3.1. コマンドラインを使用したスマートリファーラルの作成
ref
属性をリファーラル LDAP URL に設定します。
ldap://directory.europe.example.com/cn=user,ou=people,ou=europe,dc=example,dc=com
を参照する uid=user,ou=people,dc=example,dc=com という名前のスマートカードを作成するには、次のコマンドを実行します。
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server2.example.com -x dn: uid=user,ou=people,dc=example,dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: referral sn: user uid: user cn: user ref: ldap://directory.europe.example.com/cn=user,ou=people,ou=europe,dc=example,dc=com
-M
オプションを使用します。スマートリファーラルの詳細は、『Directory Server デプロイメントガイド』 を参照してください。
2.5.4. バグ修正参照の作成
2.5.4.1. コマンドラインを使用した接尾辞リファーラルの作成
- 必要に応じて、ルートまたは従属接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」 を参照してください。
- 接尾辞にリファーラルを追加します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix set --add-referral="ldap://directory.example.com/" database_name
2.5.4.2. Web コンソールを使用した接尾辞リファーラルの作成
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 必要に応じて、ルートまたは従属接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」 を参照してください。
- 一覧で接尾辞を選択し、Referrals タブを開きます。
- リファーラル URL を作成するために、フィールドに入力します。
2.6. バックエンドデータベースの整合性の確認
userroot
データベースを確認するには、以下のコマンドを実行します。
- 必要に応じて、インスタンスのバックエンドデータベースをリスト表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend suffix list dc=example,dc=com (userroot)
後のステップでデータベースの名前が必要になります。 - Directory Server インスタンスを停止します。
# dsctl instance_name stop
- データベースを確認します。
# dsctl instance_name dbverify userroot [04/Feb/2020:13:11:02.453624171 +0100] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [04/Feb/2020:13:11:02.465339507 +0100] - WARN - ldbm_instance_add_instance_entry_callback - ldbm instance userroot already exists [04/Feb/2020:13:11:02.468060144 +0100] - ERR - ldbm_config_read_instance_entries - Failed to add instance entry cn=userroot,cn=ldbm database,cn=plugins,cn=config [04/Feb/2020:13:11:02.471079045 +0100] - ERR - bdb_config_load_dse_info - failed to read instance entries [04/Feb/2020:13:11:02.476173304 +0100] - ERR - libdb - BDB0522 Page 0: metadata page corrupted [04/Feb/2020:13:11:02.481684604 +0100] - ERR - libdb - BDB0523 Page 0: could not check metadata page [04/Feb/2020:13:11:02.484113053 +0100] - ERR - libdb - /var/lib/dirsrv/slapd-instance_name/db/userroot/entryrdn.db: BDB0090 DB_VERIFY_BAD: Database verification failed [04/Feb/2020:13:11:02.486449603 +0100] - ERR - dbverify_ext - verify failed(-30970): /var/lib/dirsrv/slapd-instance_name/db/userroot/entryrdn.db dbverify failed
- 検証プロセスで問題が報告された場合は、手動で修正するか、バックアップを復元します。
- Directory Server インスタンスを起動します。
# dsctl instance_name start
第3章 ディレクトリーエントリーの管理
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
属性:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=user,ou=People,dc=example,dc=com changetype: modify add: telephoneNumber telephoneNumber: 555-1234567
telephoneNumber
属性を同時に追加するには、以下のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=user,ou=People,dc=example,dc=com changetype: modify add: telephoneNumber telephoneNumber: 555-1234567 telephoneNumber: 555-7654321
3.1.4.2. 属性の値の更新
単値属性の更新
manager
属性:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=user,ou=People,dc=example,dc=com changetype: modify replace: manager manager: uid=manager_name,ou=People,dc=example,dc=com
多値属性の特定値の更新
telephoneNumber
属性:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=user,ou=People,dc=example,dc=com changetype: modify delete: telephoneNumber telephoneNumber: 555-1234567 - add: telephoneNumber telephoneNumber: 555-9876543
3.1.4.3. エントリーからの属性の削除
属性の削除
manager
属性:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=user,ou=People,dc=example,dc=com changetype: modify delete: manager
多値属性から特定の値の削除
telephoneNumber
属性:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=user,ou=People,dc=example,dc=com changetype: modify delete: telephoneNumber telephoneNumber: 555-1234567
3.1.5. エントリーの削除
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,ou=People,dc=example,dc=com changetype: delete
3.1.6. エントリーの名前変更および変更
- エントリーの名前変更
- エントリーの名前を変更すると、modrdn 操作によってエントリーの相対識別名 (RDN) が変更されます。
- サブエントリーの名前変更
- サブツリーエントリーの場合、modrdn 操作はサブツリーと子エントリーの DN コンポーネントの名前を変更します。大規模なサブツリーでは、このプロセスに多くの時間とリソースが必要になる可能性があることに注意してください。
- エントリーを新しい親へ移動
- サブツリーの名前を変更する同様のアクションは、エントリーをあるサブツリーから別のサブツリーに移動することです。これは、modrdn 操作の拡張タイプで、エントリーの名前を同時に変更し、
newSuperior
属性を設定して、エントリーを別の親に移動します。
3.1.6.1. エントリーの名前変更に関する考慮事項
- root 接尾辞の名前を変更することはできません。
- サブツリー名前変更操作によるレプリケーションへの影響は最小限に抑えられます。レプリカ合意は、データベースのサブツリーではなく、データベース全体に適用されます。そのため、サブツリーの名前変更操作ではレプリカ合意の再設定は必要ありません。サブツリーの名前変更操作後のすべての名前の変更は、通常どおり複製されます。
- サブツリーの名前を変更し、同期合意を再設定する必要がある場合があります。同期合意は、接尾辞またはサブツリーレベルで設定されます。そのため、サブツリーの名前を変更すると、同期が中断する可能性があります。
- サブツリーの名前を変更するには、サブツリーに設定されたサブツリーレベルのアクセス制御命令 (ACI) を手動で再設定し、サブツリーの子エントリーに設定されたエントリーレベルの ACI (エントリーレベルの ACI) を手動で再設定する必要があります。
ou
からdc
への移行など、サブツリーのコンポーネントを変更しようとすると、スキーマ違反で失敗する可能性があります。たとえば、organizationalUnit オブジェクトクラスにはou
属性が必要です。この属性がサブツリーの名前の一部として削除されると、操作は失敗します。- グループを移動すると、MemberOf プラグインは
memberOf
属性を自動的に更新します。ただし、グループが含まれるサブツリーを移動する場合は、cn=memberof task エントリーでタスクを手動で作成するか、fixup-memberof.pl を使用して関連するmemberOf
属性を更新する必要があります。memberOf
属性参照のクリーンアップに関する詳細は、「memberOf
値の再生成」 を参照してください。
3.1.6.2. ユーザー、グループ、POSIX グループ、および OU の名前変更
dsidm
ユーティリティーは、複数のタイプのオブジェクトの名前を変更できます。
- ユーザー:
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" user rename current_user_name new_user_name
dsidm user rename コマンドは、指定したベース DN の前に ou=People を自動的に配置することに注意してください。 - グループ:
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" group rename current_group_name new_group_name
dsidm group rename コマンドは、指定したベース DN の前に ou=Groups を自動的に配置することに注意してください。 - POSIX グループ:
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" posixgroup rename current_posix_group_name new_posix_group_name
dsidm posixgroup rename コマンドは、指定したベース DN の前に ou=Groups を自動的に配置することに注意してください。 - 組織単位 (OU)
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" organizationalunit rename current_ou_name new_ou_name
dsidm organizationalunit rename コマンドは、指定したベース DN で直接名前変更の操作を実行します。
3.1.6.3. LDIF ステートメントを使用してエントリーの名前を変更する際の deleteOldRDN
パラメーター
deleteOldRDN
パラメーターは古い RDN が削除されるかどうかを制御します。
deleteOldRDN
: 0- 既存の RDN は、新しいエントリーの値として保持されます。生成されるエントリーには、古い属性と新しい共通名 (CN) を持つ 2 つの
cn
属性が含まれます。たとえば、以下の属性は、deleteOldRDN: 0 パラメーターを設定して、cn=old_group,dc=example,dc=com からcn=new_group,dc=example,dc=com に名前を変更したグループに属しています。dn: cn=new_group,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfUniqueNames cn: old_group cn: new_group
deleteOldRDN
: 1- Directory Server は古いエントリーを削除し、新しい RDN を使用して新しいエントリーを作成します。新しいエントリーには、新しいエントリーの
cn
属性のみが含まれます。たとえば、以下のグループは、deleteOldRDN: 1 パラメーターを設定して、cn=new_group,dc=example,dc=com に名前を変更しました。dn: cn=new_group,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupofuniquenames cn: new_group
3.1.6.4. LDIF ステートメントを使用したエントリーまたはサブツリーの名前変更
newrdn
属性に新しい RDN を設定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=example_user,cn=ldap_connect,dc=example,dc=com changetype: modrdn newrdn: cn=example_user deleteOldRDN: 1 newSuperior: dc=example,dc=com
deleteOldRDN
の詳細は、「LDIF ステートメントを使用してエントリーの名前を変更する際の deleteOldRDN
パラメーター」を参照してください。
3.1.6.5. LDIF ステートメントを使用した新しい親へのエントリーの移動
newrdn
- 移動したエントリーの RDN を設定します。RDN が同じままであっても、このエントリーを設定する必要があります。
newSuperior
- 新しい親エントリーの DN を設定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=demo,ou=Germany,dc=example,dc=com changetype: modrdn newrdn: cn=demo deleteOldRDN: 1 newSuperior: ou=France,dc=example,dc=com
deleteOldRDN
の詳細は、「LDIF ステートメントを使用してエントリーの名前を変更する際の deleteOldRDN
パラメーター」を参照してください。
3.1.7. 特殊文字の使用
cn=Directory Manager
ユーザーとして認証するには、ユーザーの DN を引用符で囲みます。
# ldapmodify -a -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
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. Web コンソールを使用したディレクトリーエントリーの管理
3.2.1. Web コンソールを使用した LDAP エントリーの追加
- ユーザー
- グループ
- roles
- 組織単位 (OU)
- カスタムエントリー
cn=John Smith,ou=people,dc=example,dc=com
のパスワードを使用して POSIX ユーザーを作成するとします。
前提条件
- ディレクトリーサーバー Web コンソールにログインしている。
- 親エントリーが存在する。例:
ou=people,dc=example,dc=com
手順
- Web コンソールでメニューを開き、既存の接尾辞のリストを表示します。
ou=people,dc=example,dc=com
を展開します。- ユーザーエントリーでタイプを選択し、 をクリックします。
- オプション:
userPassword
のような追加属性を選択し、 をクリックします。ステップ名の近くにあるドロップダウンリストを展開すると、選択されたすべての属性を表示できます。 - 各属性の値を設定します。
- 属性の鉛筆ボタンをクリックし、値を追加します。
userPassword
値を設定すると、別のメニューが開くことに注意してください。プレーンテキストを非表示にするために、値にはアスタリスク (*) が入力されます。 - チェックボタンをクリックして変更を保存します。
- オプション:→ をクリックして、追加の属性値を設定します。
- すべての値を設定したら、をクリックします。
- エントリーの詳細がすべて正しいことを確認し、をクリックします。ディレクトリーサーバーは、POSIX ユーザーの必須属性を持つエントリーを作成し、それにパスワードを設定します。 をクリックしてエントリーの設定を変更するか、 をクリックしてエントリーの作成をキャンセルできます。
検証
- エントリーを含むデータベース接尾辞 (例:
dc=example,cd=com
) を選択します。 - 検索基準 (例:
John
) をフィールドに入力し、 を押します。 - エントリーのリストで最近作成したエントリーを見つけます。
3.2.2. Web コンソールを使用した LDAP エントリーの編集
cn=John Smith,ou=people,dc=example,dc=com
を次のとおり変更します。
- 電話番号
556778987
および556897445
を追加します。 - 電子メール
jsmith@example.com
を追加します。 - パスワードを変更します。
前提条件
手順
- Web コンソールでメニューを開き、既存の接尾辞のリストを表示します。
cn=John Smith,ou=people,dc=example,dc=com
) を展開します。- オプション:の手順で、エントリーのオブジェクトクラスを追加または削除します。 をクリックします。
telephoneNumber
とmail
の属性を追加し、 をクリックします。エントリーに追加する属性が表示されない場合は、前の手順で対応するオブジェクトクラスを追加していないことを意味します。注記この手順では、選択したオブジェクトクラスの必須属性は 削除できません。telephoneNumber
を556778987
および556897445
、mail
をjsmith@example.com
に設定し、userPassword
値を変更します。- 属性の鉛筆ボタンをクリックして、新しい値を追加または変更します。
- チェックボタンをクリックして変更を保存します。
- オプション:→ をクリックして、属性に追加の値を設定します。この例では、
telephoneNumber
属性には値が 2 つあります。すべての値を設定したら、 をクリックします。
- 変更内容を確認し、をクリックします。
- エントリーを編集するには、をクリックします。 をクリックしてエントリーの設定を変更するか、 をクリックしてエントリーの編集をキャンセルできます。
検証
- エントリーの詳細を展開し、エントリー属性に表示される新しく変更された内容を確認します。
3.2.3. Web コンソールを使用した LDAP エントリーまたはサブツリーの名前変更と再配置
cn=John Smith,ou=people,dc=example,dc=com
の名前と配置を cn=Tom Smith,ou=clients,dc=example,dc=com
に変更します。
前提条件
手順
- Web コンソールでメニューを開き、既存の接尾辞のリストを表示します。
cn=John Smith,ou=people,dc=example,dc=com
) を展開します。- 命名属性
cn
に新しい値Tom Smith
を設定し、 をクリックします。 - オプション: ドロップダウンメニューから別の命名属性を選択します。
- オプション: 古いエントリーを削除し、新しい RDN を使用して新規エントリーを作成する場合は、をオンにします。
- エントリーに加えた変更を確認し、をクリックします。
- エントリーの詳細が正しい場合は、をクリックします。 をクリックしてエントリーに別の変更を加えるか、 をクリックしてエントリーの変更をキャンセルできます。
検証
- エントリーの詳細を展開し、更新されたエントリーを確認します。
3.2.4. Web コンソールを使用した LDAP エントリーの削除
cn=Tom Smith,ou=clients,dc=example,dc=com
を削除します。
前提条件
手順
- Web コンソールでメニューを開き、既存の接尾辞のリストを表示します。
cn=Tom Smith,ou=clients,dc=example,dc=com
) を展開します。- 削除するエントリーに関するデータを確認し、をクリックします。
検証
- 前にエントリーが存在していた接尾辞 (例:
dc=example,cd=com
) を選択します。 - 検索基準 (例:
Tom
) をフィールドに入力し、 を押します。 - 削除されたエントリーが存在しないことを確認します。
第4章 ディレクトリーエントリーの変更の追跡
- 変更シーケンス番号を使用してデータベースへの変更を追跡します。これは、レプリケーションおよび同期で使用されるシーケンス番号の変更に類似しています。通常のディレクトリー操作はすべて、シーケンス番号がトリガーされます。
- 作成および変更の情報を割り当てます。これらの属性は、エントリーを作成して直近に変更したユーザーの名前と、エントリーの作成および修正時のタイムスタンプを記録します。
4.1. 更新シーケンス番号でデータベースへの変更の追跡
4.1.1. エントリーシーケンス番号の概要
4.1.1.1. ローカルおよびグローバルの USN
entryUSN
操作属性のエントリーへの最後の変更の変更番号が表示されます。操作属性の詳細は、「操作属性の検索」を参照してください。
例4.1 エントリー USN の例
uid=example,ou=People,dc=example,dc=com
ユーザーエントリーの entryusn
属性を表示するには、以下のコマンドを実行します。
# ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com:389 -x -b "uid=example,ou=People,dc=example,dc=com" -s base -x entryusn
dn: uid=example,ou=People,dc=example,dc=com
entryusn: 17653
- ローカルモードでは、各バックエンドデータベースには、そのバックエンドデータベースに固有の USN カウンターを持つ 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 プラグインの有効化
4.1.2.1. コマンドラインで USN プラグインの有効化
dsconf
ユーティリティーを使用してプラグインを有効にします。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin usn enable
- インスタンスを再起動します。
# dsctl instance_name restart
4.1.2.2. Web コンソールを使用した USN プラグインの有効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- USN プラグインを選択します。
- ステータスを ON に変更し、プラグインを有効にします。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
4.1.3. グローバルの USN
4.1.3.1. グローバル USN が有効になっているかどうかの特定
4.1.3.1.1. コマンドラインでグローバル USN が有効になっているかどうかの特定
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin usn global USN global mode is disabled
4.1.3.1.2. Web コンソールを使用してグローバル USN が有効になっているかどうかの特定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- USN プラグインを選択します。
- On に設定されていることを確認します。スイッチが
4.1.3.2. グローバル USN の有効化
4.1.3.2.1. コマンドラインでグローバル USN の有効化
- グローバル USN を有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin usn global on
- インスタンスを再起動します。
# dsctl instance_name restart
4.1.3.2.2. Web コンソールを使用したグローバル USN の有効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- USN プラグインを選択します。
- プラグインのステータスを On に変更します。
- USN Global ステータスを On に変更します。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
4.1.4. USN Tombstone エントリーのクリーンアップ
- サーバーをレプリカに変換する前に
- サーバーのメモリーを解放する
4.1.4.1. コマンドラインを使用した USN tombstone エントリーのクリーンアップ
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin usn cleanup -s "dc=example,dc=com"
-o max_USN
オプションをコマンドに渡して、指定した値まで USN tombstone エントリーを削除します。
4.1.4.2. Web コンソールを使用した USN tombstone エントリーのクリーンアップ
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- USN プラグインを選択します。
- フィールドを入力し、を押します。
4.2. 操作属性によるエントリー変更の追跡
creatorsName
: エントリーを最初に作成したユーザーの識別名 (DN) です。createTimestamp
: エントリーの作成時にグリニッジ標準時 (GMT) 形式のタイムスタンプ。modifiersName
: エントリーを最後に変更したユーザーの識別名。modifyTimestamp
: エントリーが最後に修正された時点の GMT 形式のタイムスタンプ。
nsUniqueID
属性に割り当てられた一意の ID を取得しなくなり、レプリケーションは機能しません。
4.2.1. データベースリンクにより変更されたエントリーまたは作成済みエントリー
creatorsName
および modifiersName
属性には、リモートサーバーのプロキシー認可権限を付与されたユーザー名が含まれます。この場合、属性はエントリーの元の作成者または最新の変更者を表示しません。ただし、アクセスログには、プロキシーユーザー (dn) と元のユーザー (authzid) の両方が表示されます。以下に例を示します。
[23/May/2018:18:13:56.145747965 +051800] conn=1175 op=0 BIND dn="cn=proxy admin,ou=People,dc=example,dc=com" method=128 version=3 [23/May/2018:18:13:56.575439751 +051800] conn=1175 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=proxy admin,ou=people,dc=example,dc=com" [23/May/2018:18:13:56.744359706 +051800] conn=1175 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(objectClass=*)" attrs=ALL authzid="uid=user_name,ou=People,dc=example,dc=com"
4.2.2. 変更のトラッキングの有効化
4.2.2.1. コマンドラインを使用した変更の追跡の有効化
nsslapd-lastmod
パラメーターを on に設定します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-lastmod=on
- 必要に応じて、不足している
nsUniqueID
属性を再生成するには、以下を実行します。- データベースを LDAP データ交換形式 (LDIF) ファイルにエクスポートします。「コマンドラインを使用した LDIF ファイルへのデータのエクスポート」を参照してください。
- LDIF ファイルからデータベースをインポートします。「コマンドラインでのインポート」を参照してください。
4.3. プラグイン開始更新のバインド DN の追跡
dn: cn=example_group,ou=groups,dc=example,dc=com modifiersname: uid=example,ou=people,dc=example,dc=com dn: uid=example,ou=people,dc=example,dc=com modifiersname: cn=memberOf plugin,cn=plugins,cn=config
nsslapd-plugin-binddn-tracking
パラメーターにより、サーバーは、更新操作を開始したユーザーと、実際に実行した内部プラグインを追跡できます。バインドされたユーザーは modifiersname
操作属性および creatorsname
操作属性に表示されますが、実行されたプラグインは internalModifiersname
操作属性および internalCreatorsname
操作属性に表示されます。以下に例を示します。
dn: uid=example,ou=people,dc=example,dc=com modifiersname: uid=admin,ou=people,dc=example,dc=com internalModifiersname: cn=memberOf plugin,cn=plugins,cn=config
nsslapd-plugin-binddn-tracking
パラメーターは、バインドされたユーザーと、その接続に対して実行される更新の関係を追跡し、維持します。
internalModifiersname
属性および internalCreatorsname
属性は、常にプラグインをアイデンティティーとして表示します。このプラグインは、MemberOf プラグインなどの追加のプラグインである可能性があります。コア Directory Server により変更が加えられると、プラグインはデータベースプラグイン (cn=ldbm database,cn=plugins,cn=config) になります。
4.3.1. コマンドラインで開始した更新のバインド DN の追跡の有効化
nsslapd-plugin-binddn-tracking
パラメーターを on に設定します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-plugin-binddn-tracking=on
- インスタンスを再起動します。
# dsctl instance_name restart
4.3.2. Web コンソールを使用したプラグイン開始の更新のバインド DN の追跡の有効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Server Settings エントリーを選択します。メニューを開き、
- Advanced Settings タブで Enable Plugin Bind DN Tracking を選択します。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
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. レプリケーションによる参照整合性の使用
- 専用のコンシューマーサーバー (読み取り専用レプリカのみが含まれるサーバー) では有効に しないでください。
- 読み書きレプリカと読み取り専用レプリカの組み合わせが含まれるサーバーで有効に しないでください。
- 読み取り/書き込みレプリカ のみ を含むサプライヤーサーバーで有効にします。
- マルチサプライヤーレプリケーショントポロジーの各サプライヤーサーバーに対してプラグインを有効にします。プラグイン設定は、すべてのサプライヤーサーバーで同じである必要があります。
5.3. 参照整合性の有効化
5.3.1. コマンドラインを使用した参照整合性の有効化
dsconf
ユーティリティーを使用してプラグインを有効にします。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity enable
- インスタンスを再起動します。
# dsctl instance_name restart
5.3.2. Web コンソールを使用した参照整合性の有効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Plugins メニューを選択します。
- Referential Integrity プラグインを選択し、Show Advanced Settings をクリックします。
- ステータスを ON に変更し、プラグインを有効にします。
5.4. 参照整合性の更新間隔
- 0: 参照整合性の確認は即座に実行されます。
- -1: 参照整合性の確認は実行されません。
5.4.1. コマンドラインを使用した更新間隔の表示
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity show
referint-update-delay: 0
...
5.4.2. Web コンソールを使用した更新間隔の表示
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Referential Integrity プラグインを選択します。
- 更新間隔については、Update Delay フィールドを参照してください。
5.4.3. コマンドラインを使用した更新間隔の変更
- 更新間隔を 0 に設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --update-delay=0
- インスタンスを再起動します。
# dsctl instance_name restart
5.4.4. Web コンソールを使用した更新間隔の変更
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Referential Integrity プラグインを選択します。
- Update Delay フィールドに間隔を設定します。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
5.5. 属性リストの表示および修正
member
属性、uniquemember
属性、owner
属性、および seeAlso
属性を確認し、更新します。コマンドラインまたは Web コンソールを使用して、更新する属性を追加または削除できます。
5.5.1. コマンドラインを使用した属性リストの表示
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity show
5.5.2. Web コンソールを使用した属性リストの表示
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Referential Integrity プラグインを選択します。
- 属性のリストは、Membership Attribute フィールドを参照してください。
5.5.3. コマンドラインで属性リストの設定
- 必要に応じて、属性の現在のリストを表示します。「コマンドラインを使用した属性リストの表示」を参照してください。
- 属性リストを更新します。
- プラグインが確認および更新される必要がある属性リストを設定するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --membership-attr attribute_name_1 attribute_name_2
- プラグインで確認および更新されなくなった属性をすべて削除するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --membership-attr delete
- インスタンスを再起動します。
# dsctl instance_name restart
5.5.4. Web コンソールを使用した属性リストの設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Referential Integrity プラグインを選択します。
- Membership Attribute フィールドを更新して、属性を設定します。
- 属性を追加するには、Membership Attribute フィールドに名前を入力します。
- 属性を削除するには、Membership Attribute フィールドの属性名の横にある ボタンをクリックします。
5.6. 参照整合性のためのスコープの設定
dc=example,dc=com
に ou=active users,dc=example,dc=com
と ou=deleted users,dc=example,dc=com
の 2 つのサブツリーが含まれる場合があります。deleted users
のエントリーは、参照整合性の確保のために処理しないでください。
5.6.1. 参照整合性の範囲を制御するパラメーター
nsslapd-pluginEntryScope
- この多値パラメーターは、削除または名前変更のエントリーの範囲を制御します。これは、Referential Integrity Postoperation プラグインがユーザーエントリーの削除操作または名前変更操作を検索するサブツリーを定義します。定義されたサブツリーに存在しないユーザーを削除または名前変更した場合、プラグインは操作を無視します。このパラメーターを使用すると、プラグインが操作を適用するデータベースのブランチを指定できます。
nsslapd-pluginExcludeEntryScope
- このパラメーターは、削除または名前変更のエントリーの範囲も制御します。これは、Referential Integrity Postoperation プラグインがユーザーの削除や名前変更の操作を無視するサブツリーを定義します。
nsslapd-pluginContainerScope
- このパラメーターは、参照を更新するグループのスコープを制御します。ユーザーの削除後、Referential Integrity Postoperation プラグインはユーザーが属するグループを検索し、それに応じて更新します。このパラメーターは、プラグインがユーザーが属するグループを検索するブランチを指定します。Referential Integrity Postoperation プラグインは、指定のコンテナーブランチにあるグループのみを更新し、その他のグループは更新されないままにします。
5.6.2. コマンドラインを使用した参照整合性範囲の表示
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity show ... nsslapd-pluginEntryScope: DN nsslapd-pluginExcludeEntryScope: DN nsslapd-pluginContainerScope: DN
5.6.3. Web コンソールを使用した参照整合性範囲の表示
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Referential Integrity プラグインを選択します。
- 現在設定されているスコープについては、Entry Scope フィールド、Exclude Entry Scope フィールド、および Container Scope フィールドを参照してください。
5.6.4. コマンドラインを使用した参照整合性範囲の設定
- 必要に応じて、スコープ設定を表示します。「コマンドラインを使用した参照整合性範囲の表示」を参照してください。
- 以下のコマンドは、コマンドラインを使用して個別の参照整合性スコープを設定する方法を示しています。
- 識別名 (DN) を設定するには、以下を実行します。
nsslapd-pluginEntryScope
パラメーターに対して以下を実行します。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --entry-scope="DN"
nsslapd-pluginExcludeEntryScope
パラメーターに対して以下を実行します。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --exclude-entry-scope="DN"
nsslapd-pluginContainerScope
パラメーターに対して以下を実行します。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --container-scope="DN"
- DN を削除するには、以下を実行します。
nsslapd-pluginEntryScope
パラメーターから、以下を行います。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --entry-scope=delete
nsslapd-pluginExcludeEntryScope
パラメーターから、以下を行います。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --exclude-entry-scope=delete
nsslapd-pluginContainerScope
パラメーターから、以下を行います。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --container-scope=delete
- インスタンスを再起動します。
# dsctl instance_name restart
5.6.5. Web コンソールを使用した参照整合性範囲の設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Referential Integrity プラグインを選択します。
- Entry Scope フィールド、Exclude Entry Scope フィールドおよび Container Scope フィールドにスコープを設定します。
第6章 Directory Database への入力
6.1. データのインポート
- データのインポート重要データをインポートするには、インポートする LDIF ファイルを
/var/lib/dirsrv/slapd-instance_name/ldif/
ディレクトリーに保存する必要があります。Directory Server はデフォルトでPrivateTmp
systemd ディレクティブを使用します。そのため、LDIF ファイルを/tmp/
または/var/tmp/
システムディレクトリーにエクスポートすると、Directory Server はインポート中にこれらの LDIF ファイルを認識しません。PrivateTmp
の詳細は、systemd.exec(5)
の man ページを参照してください。 - レプリケーションのデータベースの初期化
動作 | インポート | データベースの初期化 |
---|---|---|
データベースの上書き | いいえ | はい |
LDAP 操作 | 追加、変更、削除 | 追加のみ |
パフォーマンス | より時間がかかる | 速い |
パーティション特長 | すべてのパーティションで機能 | ローカルパーティションのみ |
サーバー障害への応答 | ベストエフォート (障害が発生した時点までに行われたすべての変更が残る) | アトミック (障害発生後にすべての変更が失われる) |
LDIF ファイルの場所 | Web コンソールへのローカル | Web コンソールまたはローカルサーバーへのローカル |
設定情報 (cn=config) をインポートする | はい | いいえ |
6.1.1. インポート中の EntryUSN 初期値の設定
nsslapd-entryusn-import-initval
パラメーターを設定します。これにより、インポートされたすべてのエントリーの USN が開始されます。
nsslapd-entryusn-import-initval
には 2 つの値を指定することができます。
- 整数。インポートされたすべてのエントリーに使用される明示的な開始番号です。
- next。つまり、インポートされたエントリーはすべて、インポート操作の前にサーバー上にあった最大のエントリー USN 値を、1 つずつインクリメントして使用します。
nsslapd-entryusn-import-initval
が設定されていない場合、すべてのエントリー USN はゼロで始まります。
例6.1 nsslapd-entryusn-import-initval
パラメーターの仕組み
nsslapd-entryusn-import-initval
の値が next の場合、インポートされたすべてのエントリーには 1001 の USN が割り当てられます。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "(cn=*)" entryusn dn: dc=example,dc=com entryusn: 1001 dn: ou=Accounting,dc=example,dc=com entryusn: 1001 dn: ou=Product Development,dc=example,dc=com entryusn: 1001 ... dn: uid=user_name,ou=people,dc=example,dc=com entryusn: 1001 ...
nsslapd-entryusn-import-initval
パラメーターを、データをインポートするサーバーまたは初期化を実行するサプライヤーサーバーに追加します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-entryusn-import-initval=next
nsslapd-entryusn-import-initval
パラメーターはサーバー間で複製 されません。つまり、値は、レプリカの初期化に使用しているすべてのサプライヤーサーバーに対して設定する必要があります。
Supplier1
ホストの nsslapd-entryusn-import-initval
が next に設定され、レプリカの初期化に使用される場合は、インポートされたエントリーのエントリー USN は最も高い値に 1 が追加されます。Supplier2
ホストに nsslapd-entryusn-import-initval
が設定されておらず、レプリカの初期化に使用される場合は、Supplier1
および Supplier2
にマルチサプライヤーレプリカ合意がある場合でも、インポートされたエントリーのすべてのエントリー USN はゼロで始まります。
6.1.2. コマンドラインでのインポート
- インスタンスが実行している場合には、以下のいずれかの方法を使用します。
- dsconf backend import コマンドを使用します。「dsconf backend import コマンドを使用したインポート」を参照してください。
- cn=tasks エントリーを作成します。「cn=tasks エントリーを使用したデータのインポート」を参照してください。
- インスタンスがオフラインの場合は、dsctl ldif2db コマンドを使用します。「サーバーがオフライン時のデータのインポート」を参照してください。
UTF-8
文字セットエンコーディングを使用する必要があります。インポート操作は、データをローカル文字セットエンコーディングから UTF-8
に変換しません。また、インポートされたすべての LDIF ファイルにルート接尾辞エントリーが含まれている必要があります。
dirsrv
ユーザーとしてインポート操作を実行します。したがって、LDIF ファイルのパーミッションにより、このユーザーがファイルの読み取りを許可する必要があります。
6.1.2.1. サーバーの実行中にデータのインポート
6.1.2.1.1. dsconf backend import コマンドを使用したインポート
/var/lib/dirsrv/slapd-instance_name/ldif/instance_name-database_name-time_stamp.ldif
ファイルを userRoot
データベースにインポートするには、以下のコマンドを実行します。
- 接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」 を参照してください。
- インポートする LDIF に接尾辞エントリーを追加するステートメントが含まれていない場合は、「ルートエントリーの作成」 で説明されているように、このエントリーを手動で作成します。
- LDIF ファイルをインポートします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend import userRoot /var/lib/dirsrv/slapd-instance_name/ldif/instance_name-database_name-time_stamp.ldif The import task has finished successfully
dsconf backend import コマンドは、特定の接尾辞を除外するなど、追加オプションに対応します。利用可能なオプションをすべて表示するには、以下を入力します。# dsconf ldap://server.example.com backend import --help
6.1.2.1.2. cn=tasks エントリーを使用したデータのインポート
cn
: タスクの一意の名前を設定します。nsFilename
: インポートする LDIF ファイルの名前を設定します。nsInstance
: ファイルをインポートするデータベースの名前を設定します。
/var/lib/dirsrv/slapd-instance_name/ldif/example.ldif
ファイルの内容を userRoot
データベースにインポートするタスクを追加するには:
- 接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」 を参照してください。
- インポートする LDIF に接尾辞エントリーを追加するステートメントが含まれていない場合は、「ルートエントリーの作成」 で説明されているように、このエントリーを手動で作成します。
- インポートタスクを追加します。
# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x dn: cn=example_import,cn=import,cn=tasks,cn=config changetype: add objectclass: extensibleObject cn: example_import nsFilename: /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif nsInstance: userRoot
6.1.2.2. サーバーがオフライン時のデータのインポート
- 接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」 を参照してください。
- インポートする LDIF に接尾辞エントリーを追加するステートメントが含まれていない場合は、「ルートエントリーの作成」 で説明されているように、このエントリーを手動で作成します。
- インスタンスを停止します。
# dsctl instance_name stop
- LDIF ファイルからデータをインポートします。たとえば、
/var/lib/dirsrv/slapd-instance_name/ldif/example.ldif
ファイルをuserRoot
データベースにインポートするには、以下を実行します。# dsctl instance_name ldif2db userroot /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif OK group dirsrv exists OK user dirsrv exists [17/Jul/2018:13:42:42.015554231 +0200] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 ... [17/Jul/2018:13:42:44.302630629 +0200] - INFO - import_main_offline - import userroot: Import complete. Processed 160 entries in 2 seconds. (80.00 entries/sec) ldif2db successful
警告コマンドで指定したデータベースが、LDIF ファイルに含まれる接尾辞と一致しない場合は、データベースに含まれるすべてのデータが削除され、インポートに失敗します。 - インスタンスを起動します。
# dsctl instance_name start
6.1.3. Web コンソールを使用したデータのインポート
- 接尾辞が存在しない場合は作成します。詳細については、「接尾辞の作成」 を参照してください。
- インポートする LDIF に接尾辞エントリーを追加するステートメントが含まれていない場合は、「ルートエントリーの作成」 で説明されているように、このエントリーを手動で作成します。
- インポートする LDIF ファイルを
/var/lib/dirsrv/slapd-instance_name/ldif/
ディレクトリーに保存します。 - Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 接尾辞エントリーを選択します。
- Initialize Suffix を選択します。をクリックし、
- インポートする LDIF ファイルを選択するか、ファイルへの完全パスを入力します。
- Yes, I am sure を選択し、 をクリックして確定します。
6.2. データのエクスポート
- データベースのデータのバックアップを作成します。
- 別の Directory Server にデータをコピーします。
- 別のアプリケーションへのデータのエクスポート。
- ディレクトリートポロジーの変更後にデータベースを再作成します。たとえば、ディレクトリーに 1 つのデータベースが含まれ、その内容を 2 つのデータベースに分割する必要がある場合は、図6.1「データベースコンテンツの 2 つのデータベースへの分割」で説明されるように、2 つの新しいデータベースのコンテンツをエクスポートし、それを 2 つの新しいデータベースにインポートます。
図6.1 データベースコンテンツの 2 つのデータベースへの分割
dirsrv
ユーザーとして実行します。したがって、移行先ディレクトリーのパーミッションでは、このユーザーがこのファイルを作成できるようにする必要があります。
6.2.1. コマンドラインを使用した LDIF ファイルへのデータのエクスポート
- インスタンスが実行している場合には、以下のいずれかの方法を使用します。
- dsconf backend export コマンドを使用します。「dsconf backend export コマンドを使用したデータベースのエクスポート」を参照してください。
- cn=tasks エントリーを作成します。「cn=tasks エントリーを使用したデータベースのエクスポート」を参照してください。
- インスタンスがオフラインの場合は、dsctl db2ldif コマンドを使用します。「サーバーがオフライン時のデータベースのエクスポート」を参照してください。
/tmp
または /var/tmp/
ディレクトリーにエクスポートしないでください。理由は以下のとおりです。
- Directory Server は、デフォルトで
systemd
のPrivateTmp
機能を使用します。LDIF ファイルを/tmp
または/var/tmp/
システムディレクトリーに配置すると、Directory Server はインポート中にこれらの LDIF ファイルを認識しません。PrivateTmp
の詳細は、systemd.exec(5)
の man ページを参照してください。 - LDIF ファイルには、しばしばユーザーパスワードなどの機密データが含まれます。したがって、これらのファイルを保存するために一時システムディレクトリーを使用しないでください。
6.2.1.1. サーバーの実行中にデータベースのエクスポート
6.2.1.1.1. dsconf backend export コマンドを使用したデータベースのエクスポート
userRoot
データベースをエクスポートするには、以下のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend export userRoot The export task has finished successfully
dsconf
は、エクスポートを /var/lib/dirsrv/slapd-instance_name/export/
ディレクトリーの instance_name_database_name-time_stamp.ldif
という名前のファイルに保存します。または、コマンドに -l file_name
オプションを追加して、別の場所を指定します。
# dsconf ldap://server.example.com backend export --help
6.2.1.1.2. cn=tasks エントリーを使用したデータベースのエクスポート
cn
: タスクの一意の名前を設定します。nsInstance
: エクスポートするデータベースの名前を設定します。nsFilename
: エクスポートを保存するファイルの名前を設定します。
userRoot
データベースのコンテンツを /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif
ファイルにエクスポートするタスクを追加するには、次のようにします。
# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x dn: cn=example_export,cn=export,cn=tasks,cn=config changetype: add objectclass: extensibleObject cn: example_export nsInstance: userRoot nsFilename: /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif
6.2.1.2. サーバーがオフライン時のデータベースのエクスポート
- インスタンスを停止します。
# dsctl instance_name stop
- データベースを LDIF ファイルにエクスポートします。たとえば、
userRoot
データベースを/var/lib/dirsrv/slapd-instance_name/ldif/example.ldif
ファイルにエクスポートするには:# dsctl instance_name db2ldif userroot /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif OK group dirsrv exists OK user dirsrv exists ldiffile: /var/lib/dirsrv/slapd-instance_name/ldif/example.ldif [18/Jul/2018:10:46:03.353656777 +0200] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [18/Jul/2018:10:46:03.383101305 +0200] - INFO - ldbm_back_ldbm2ldif - export userroot: Processed 160 entries (100%). [18/Jul/2018:10:46:03.391553963 +0200] - INFO - dblayer_pre_close - All database threads now stopped db2ldif successful
- インスタンスを起動します。
# dsctl instance_name start
6.2.2. Web コンソールを使用した LDIF ファイルへの接尾辞のエクスポート
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 接尾辞エントリーを選択します。
- Export Suffix を選択します。をクリックし、
- エクスポートを保存する LDIF ファイルの名前を入力します。Directory Server は、指定したファイル名を使用して、ファイルを
/var/lib/dirsrv/slapd-instance_name/ldif/
ディレクトリーに保存します。
6.2.3. グループのメンバーがデータをエクスポートすることの許可、およびグループメンバーの 1 つとしてのエクスポートの実行
cn=Directory Manager
の認証情報を設定する必要がなくなるため、セキュリティーが向上します。また、グループを変更して、エクスポートのパーミッションを簡単に許可し、取り消しすことができます。
6.2.3.1. グループがデータをエクスポートすることの許可
cn=export_users,ou=groups,dc=example,dc=com
グループを追加し、このグループのメンバーがエクスポートタスクを作成することを許可します。
手順
cn=export_users,ou=groups,dc=example,dc=com
グループを作成します。# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" group create --cn export_users
cn=export_users,ou=groups,dc=example,dc=com
グループのメンバーがエクスポートタスクを作成するのを許可するアクセス制御手順 (ACI) を追加します。# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com dn: cn=config changetype: modify add: aci aci: (target = "ldap:///cn=export,cn=tasks,cn=config")(targetattr="*") (version 3.0 ; acl "permission: Allow export_users group to export data" ; allow (add, read, search) groupdn = "ldap:///cn=export_users,ou=groups,dc=example,dc=com";) - add: aci aci: (target = "ldap:///cn=config")(targetattr = "objectclass || cn || nsslapd-suffix || nsslapd-ldifdir") (version 3.0 ; acl "permission: Allow export_users group to access ldifdir attribute" ; allow (read,search) groupdn = "ldap:///cn=export_users,ou=groups,dc=example,dc=com";)
- ユーザーを作成します。
- ユーザーアカウントを作成します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" user create --uid="example" --cn="example" --uidNumber="1000" --gidNumber="1000" --homeDirectory="/home/example/" --displayName="Example User"
- ユーザーアカウントのパスワードを設定します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account reset_password "uid=example,ou=People,dc=example,dc=com" "password"
uid=example,ou=People,dc=example,dc=com
ユーザーをcn=export_users,ou=groups,dc=example,dc=com
グループに追加します。# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" group add_member export_users uid=example,ou=People,dc=example,dc=com
検証
- cn=config に設定した ACI を表示します。
# ldapsearch -o ldif-wrap=no -LLLx -D "cn=Directory Manager" -W -H ldap://server.example.com -b cn=config aci=* aci -s base dn: cn=config aci: (target = "ldap:///cn=export,cn=tasks,cn=config")(targetattr="*")(version 3.0 ; acl "permission: Allow export_users group to export data" ; allow (add, read, search) groupdn = "ldap:///cn=export_users,ou=groups,dc=example,dc=com";) aci: (target = "ldap:///cn=config")(targetattr = "objectclass || cn || nsslapd-suffix || nsslapd-ldifdir")(version 3.0 ; acl "permission: Allow export_users group to access ldifdir attribute" ; allow (read,search) groupdn = "ldap:///cn=export_users,ou=groups,dc=example,dc=com";) ...
6.2.3.2. 通常のユーザーとしてのエクスポートの実行
cn=Directory Manager
ではなく、通常のユーザーとしてエクスポートを実行できます。
前提条件
cn=export_users,ou=groups,dc=example,dc=com
グループのメンバーがデータをエクスポートすることを許可している。「グループがデータをエクスポートすることの許可」を参照してください。- エクスポートの実行に使用するユーザーが
cn=export_users,ou=groups,dc=example,dc=com
グループのメンバーである。
手順
- 以下の方法のいずれかを使用してエクスポートタスクを作成します。
- dsconf backend export コマンドの使用:
# dsconf -D "uid=example,ou=People,dc=example,dc=com" ldap://server.example.com backend export userRoot
- タスクの手動での作成:
# ldapadd -D "uid=example,ou=People,dc=example,dc=com" -W -H ldap://server.example.com dn: cn=userRoot-2021_07_23_12:55_00,cn=export,cn=tasks,cn=config changetype: add objectClass: extensibleObject nsFilename: /var/lib/dirsrv/slapd-instance_name/ldif/None-userroot-2021_07_23_12:55_00.ldif nsInstance: userRoot cn: export-2021_07_23_12:55_00
検証
- バックアップが作成されたことを確認します。
# ls -l /var/lib/dirsrv/slapd-instance_name/ldif/*.ldif total 0 -rw-------. 1 dirsrv dirsrv 10306 Jul 23 12:55 None-userroot-2021_07_23_12_55_00.ldif ...
6.3. Directory Server のバックアップ
- これらのデータベース内に格納されているデータを含むすべてのデータベースファイル注記Directory Server は、個別のデータベースのバックアップをサポートしません。
- トランザクションログ
- インデックス
dirsrv
ユーザーとして実行します。したがって、移行先ディレクトリーのパーミッションでは、このユーザーがファイルを作成できるようにする必要があります。
6.3.1. コマンドラインを使用した全データベースのバックアップ
- インスタンスが実行している場合には、以下のいずれかの方法を使用します。
- dsconf backup create コマンドを使用します。「dsconf backup create コマンドを使用した全データベースのバックアップ」を参照してください。
- cn=tasks エントリーを作成します。「cn=tasks エントリーを使用した全データベースのバックアップ」を参照してください。
- インスタンスがオフラインの場合は、dsctl db2bak コマンドを使用します。「サーバーがオフライン時のすべてのデータベースのバックアップ」を参照してください。
6.3.1.1. サーバーの実行中にすべてのデータベースのバックアップ
6.3.1.1.1. dsconf backup create コマンドを使用した全データベースのバックアップ
# dsconf -D "cn=Directory Manager" ldap://server.example.com backup create The backup create task has finished successfully
dsconf
は、バックアップを /var/lib/dirsrv/slapd-instance_name/bak/
ディレクトリーの instance_name-time_stamp
というサブディレクトリーに保存します。別の場所を指定するには、コマンドにディレクトリー名を追加します。
6.3.1.1.2. cn=tasks エントリーを使用した全データベースのバックアップ
cn
: タスクの一意の名前を設定します。nsDatabaseType
: バックアップするデータベースのタイプを設定します。Directory Server は、この属性の ldbm database 値のみをサポートします。
/var/lib/dirsrv/slapd-instance_name/bak/
)。完全なリストは、『Red Hat Directory Server Configuration, Command, and File Reference』の『cn=backup』セクションを参照してください。
# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x dn: cn=example_backup,cn=export,cn=tasks,cn=config changetype: add objectclass: extensibleObject cn: example_backup nsDatabaseType: ldbm database
nsArchiveDir
属性を指定しないと、サーバーは /var/lib/dirsrv/slapd-instance_name/bak/
ディレクトリーの instance_name-time_stamp
という名前のサブディレクトリーにバックアップを保存します。
6.3.1.2. サーバーがオフライン時のすべてのデータベースのバックアップ
- インスタンスを停止します。
# dsctl instance_name stop
- データベースのバックアップを作成します。
# dsctl instance_name db2bak db2bak successful
注記dsctl db2bak コマンドは、dirsrv
ユーザーとしてバックアップとして実行されます。したがって、インストール先ディレクトリーのパーミッションでは、このユーザーがファイルとディレクトリーを作成できるようにする必要があります。宛先ディレクトリーをコマンドに追加しないと、サーバーは、/var/lib/dirsrv/slapd-instance_name/bak/
ディレクトリーのサブディレクトリーinstance_name-time_stamp
にバックアップを保存します。 - インスタンスを起動します。
# dsctl instance_name start
6.3.2. Web コンソールを使用した全データベースのバックアップ
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Manage Backup を選択します。ボタンをクリックして、
- バックアップの作成日時を示すタイムスタンプなど、バックアップの名前を入力します。
/var/lib/dirsrv/slapd-instance_name/bak/
ディレクトリー内の指定した名前のサブディレクトリーに保存します。
6.3.3. 設定ファイル、証明書データベース、およびカスタムスキーマファイルのバックアップ
/etc/dirsrv/slapd-instance_name/
ディレクトリーには追加のファイルが保存されています。これらのファイルは、たとえば、ハードウェア障害後に別のサーバー上でインスタンスを復元するのに必要になります。
例6.2 /etc/dirsrv/slapd-instance_name/
ディレクトリーのバックアップ方法
/etc/dirsrv/slapd-instance_name/
のコンテンツをバックアップするには、ディレクトリーをコピーするか、アーカイブファイルに保存します。たとえば、/etc/dirsrv/slapd-instance_name/
ディレクトリーのコンテンツを /root/config_slapd-instance_name_time_stamp.tar.gz
ファイルに保存するには、次のコマンドを実行します。
# cd /etc/dirsrv/ # tar -zcvf /root/config_slapd-instance_name_$(date +%Y-%m-%d_%H-%M-%S).tar.gz slapd-instance_name/
6.3.4. グループのメンバーが Directory Server をバックアップすることの許可、およびグループメンバーの 1 つとしてのバックアップの実行
cn=Directory Manager
の認証情報を設定する必要がなくなるため、セキュリティーが向上します。また、グループを変更して、バックアップのパーミッションを簡単に許可し、取り消しすことができます。
6.3.4.1. グループが Directory Server をバックアップすることの許可
cn=backup_users,ou=groups,dc=example,dc=com
グループを追加し、このグループのメンバーがバックアップタスクを作成するのを許可します。
手順
cn=backup_users,ou=groups,dc=example,dc=com
グループを作成します。# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" group create --cn backup_users
cn=backup_users,ou=groups,dc=example,dc=com
グループのメンバーがバックアップタスクを作成するのを許可するアクセス制御手順 (ACI) を追加します。# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com dn: cn=config changetype: modify add: aci aci: (target = "ldap:///cn=backup,cn=tasks,cn=config")(targetattr="*") (version 3.0 ; acl "permission: Allow backup_users group to create backup tasks" ; allow (add, read, search) groupdn = "ldap:///cn=backup_users,ou=groups,dc=example,dc=com";) - add: aci aci: (target = "ldap:///cn=config")(targetattr = "nsslapd-bakdir || objectClass") (version 3.0 ; acl "permission: Allow backup_users group to access bakdir attribute" ; allow (read,search) groupdn = "ldap:///cn=backup_users,ou=groups,dc=example,dc=com";)
- ユーザーを作成します。
- ユーザーアカウントを作成します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" user create --uid="example" --cn="example" --uidNumber="1000" --gidNumber="1000" --homeDirectory="/home/example/" --displayName="Example User"
- ユーザーアカウントのパスワードを設定します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account reset_password "uid=example,ou=People,dc=example,dc=com" "password"
uid=example,ou=People,dc=example,dc=com
ユーザーをcn=backup_users,ou=groups,dc=example,dc=com
グループに追加します。# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" group add_member backup_users uid=example,ou=People,dc=example,dc=com
検証
- cn=config エントリーに設定された ACI を表示します。
# ldapsearch -o ldif-wrap=no -LLLx -D "cn=directory manager" -W -H ldap://server.example.com -b cn=config aci=* aci -s base dn: cn=config aci: (target = "ldap:///cn=backup,cn=tasks,cn=config")(targetattr="*")(version 3.0 ; acl "permission: Allow backup_users group to create backup tasks" ; allow (add, read, search) groupdn = "ldap:///cn=backup_users,ou=groups,dc=example,dc=com";) aci: (target = "ldap:///cn=config")(targetattr = "nsslapd-bakdir || objectClass")(version 3.0 ; acl "permission: Allow backup_users group to access bakdir attribute" ; allow (read,search) groupdn = "ldap:///cn=backup_users,ou=groups,dc=example,dc=com";) ...
6.3.4.2. 通常のユーザーとしてのバックアップの実行
cn=Directory Manager
ではなく、通常のユーザーとしてバックアップを実行できます。
前提条件
cn=backup_users,ou=groups,dc=example,dc=com
グループのメンバーがデータをバックアップするのを許可している。「グループが Directory Server をバックアップすることの許可」を参照してください。- バックアップの実行に使用するユーザーが
cn=backup_users,ou=groups,dc=example,dc=com
グループのメンバーである。
手順
- 以下の方法のいずれかを使用してバックアップタスクを作成します。
- dsconf backup create コマンドの使用:
# dsconf -D uid=example,ou=People,dc=example,dc=com ldap://server.example.com backup create
- タスクの手動での作成:
# ldapadd -D uid=example,ou=People,dc=example,dc=com -W -H ldap://server.example.com dn: cn=backup-2021_07_23_12:55_00,cn=backup,cn=tasks,cn=config changetype: add objectClass: extensibleObject nsarchivedir: /var/lib/dirsrv/slapd-instance_name/bak/backup-2021_07_23_12:55_00 nsdatabasetype: ldbm database cn: backup-2021_07_23_12:55_00
検証
- バックアップが作成されたことを確認します。
# ls -l /var/lib/dirsrv/slapd-instance_name/bak/ total 0 drwx------. 3 dirsrv dirsrv 108 Jul 23 12:55 backup-2021_07_23_12_55_00 ...
6.4. Directory Server の復元
dirsrv
ユーザーとして実行します。そのため、バックアップを含むディレクトリーのパーミッションにより、このユーザーがファイルを読み取ることができます。
6.4.1. コマンドラインでのすべてのデータベースの復元
- インスタンスが実行している場合には、以下のいずれかの方法を使用します。
- dsconf backup restore コマンドを使用します。「dsconf backup restore コマンドを使用した全データベースの復元」を参照してください。
- cn=tasks エントリーを作成します。「cn=tasks エントリーを使用した全データベースの復元」を参照してください。
- インスタンスがオフラインの場合は、dsctl bak2db コマンドを使用します。「サーバーがオフライン時の全データベースの復元」を参照してください。
6.4.1.1. サーバーの実行中にすべてのデータベースの復元
6.4.1.1.1. dsconf backup restore コマンドを使用した全データベースの復元
/var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/
ディレクトリーに保存されているバックアップを復元するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backup restore /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/ The backup restore task has finished successfully
6.4.1.1.2. cn=tasks エントリーを使用した全データベースの復元
cn
: タスクの一意の名前を設定します。nsArchiveDir
: バックアップが含まれるディレクトリーへのパスを設定します。nsDatabaseType
: 復元するデータベースのタイプを設定します。Directory Server は、この属性の ldbm database 値のみをサポートします。
/var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/
ディレクトリーに保存されているバックアップからすべてのデータベースを復元するタスクを追加するには、次のコマンドを実行します。
# ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x dn: cn=example_restore,cn=import,cn=tasks,cn=config changetype: add objectclass: extensibleObject cn: example_restore nsArchiveDir: /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/ nsDatabaseType: ldbm database
6.4.1.2. サーバーがオフライン時の全データベースの復元
- インスタンスを停止します。
# dsctl instance_name stop
- データベースを復元します。たとえば、
/var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/
ディレクトリーに保存されているバックアップからすべてのデータベースを復元するタスクを追加するには、次のコマンドを実行します。# dsctl instance_name bak2db /var/lib/dirsrv/slapd-instance_name/bak/instance_name-time_stamp/ bak2db successful
注記dsctl bak2db コマンドは、dirsrv
ユーザーとして復元として実行されます。したがって、ソースディレクトリーのパーミッションでは、このユーザーがファイルとディレクトリーを読み取りできるようにする必要があります。 - インスタンスを起動します。
# dsctl instance_name start
6.4.2. Web コンソールを使用した全データベースの復元
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Manage Backups を選択します。ボタンをクリックして、表示されるウィンドウには、
/var/lib/dirsrv/slapd-instance_name/bak/
ディレクトリーで利用可能なバックアップが表示されます。 - 復元するバックアップの横にある Actions メニューを開き、 を選択します。
6.4.3. 複製されたエントリーが含まれるデータベースの復元
- コンシューマーサーバーも復元される。(データが同期されるように) 全く同じ時間に作成されたバックアップからすべてのデータベースを復元するような非常にまれな状況においては、コンシューマーはサプライヤーと同期が取れた状態のままであるため、特に何もする必要はありません。レプリケーションは中断せずに再開します。
- サプライヤーだけが復元します。サプライヤーのみが復元された場合や、コンシューマーが別のバックアップから復元された場合は、サプライヤーがコンシューマーを再初期化して、データベースのデータを更新します。サプライヤーのみが復元された場合や、コンシューマーが別のバックアップから復元された場合は、サプライヤーがコンシューマーを再初期化して、データベースのデータを更新します。
- サプライヤーサーバーでチェンジログエントリーの有効期限が切れていません。データベースのバックアップの取得後にサプライヤーの変更ログが期限切れになっていない場合は、ローカルコンシューマーを復元し、通常の操作を継続します。この状態は、cn=changelog5,cn=config エントリーで、最大 changelog age 属性
nsslapd-changelogmaxage
に設定された値よりも短い期間内にバックアップを取得した場合に限り発生します。このオプションの詳細は、『Red Hat Directory Server 設定、コマンド、およびファイルリファレンス』 を参照してください。Directory Server は、レプリカとその変更ログの間の互換性を自動的に検出します。不一致が検出されると、サーバーは古い変更ログファイルを削除し、空のファイルを新たに作成します。 - 変更ログエントリーが、ローカルバックアップを作成した後にサプライヤーサーバー上で期限切れになる。変更ログエントリーの有効期限が切れている場合は、コンシューマーが再初期化される。コンシューマーの再初期化に関する詳細は、「コンシューマーの初期化」を参照してください。
例6.3 Directory Server のレプリケーショントポロジーの復元
- 最初のサプライヤーを復元します。dsconf backend import コマンドを使用して、データをインポートします。「コマンドラインでのインポート」を参照してください。
- レプリケーションを使用して残りのサーバーをオンラインに初期化します。
- 最初のサプライヤーから 2 番目のサプライヤーを初期化します。
- サプライヤーからコンシューマーを初期化します。
詳細については、「コンシューマーの初期化」 を参照してください。 - 各サーバーでレプリケーションのステータスを表示し、レプリケーションが正しく機能していることを確認します。詳細については、「特定のレプリカ合意の状態の表示」 を参照してください。
第7章 属性および値の管理
7.1. 属性の一意性の有効化
7.1.1. Attribute Uniqueness プラグインの新規設定レコードの作成
dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq add "Example" --attr-name uid
7.1.2. 接尾辞またはサブツリーにおける属性一意の設定
7.1.2.1. コマンドラインで接尾辞またはサブツリーに対する属性一意の設定
- たとえば mail Attribute Uniqueness という名前の Attribute Uniqueness プラグインの新たな設定レコードを作成します。詳細については、「Attribute Uniqueness プラグインの新規設定レコードの作成」 を参照してください。
- プラグイン設定レコードを有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq enable "mail Attribute Uniqueness"
mail
属性に保存されている値は、内部で一意である必要があります。たとえば、ou=Engineering,dc=example,dc=com および ou=Sales,dc=example,dc=com サブツリーなどです。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq set "mail Attribute Uniqueness" --attr-name mail --subtree ou=Engineering,dc=example,dc=com ou=Sales,dc=example,dc=com
- 必要に応じて、このプラグイン設定レコードに設定されたすべてのサブツリーで一意性を設定するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq set "mail Attribute Uniqueness" --across--all-subtrees=on
- インスタンスを再起動します。
# dsctl instance_name restart
7.1.2.2. Web コンソールを使用した接尾辞またはサブツリーに対する属性の一意の設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Attribute Uniqueness プラグインを選択します。
- フィールドを入力し、設定を有効にします。以下に例を示します。
図7.1 属性一意設定の追加
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
7.1.3. オブジェクトクラスに対する属性の一意性の設定
uniqueness-attribute-name
に設定された属性の値がこのサブツリー内で一意であることを確認します。
- たとえば mail Attribute Uniqueness という名前の Attribute Uniqueness プラグインの新たな設定レコードを作成します。詳細については、「Attribute Uniqueness プラグインの新規設定レコードの作成」 を参照してください。
- プラグイン設定レコードを有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq enable "mail Attribute Uniqueness"
mail
属性に保存される値は、nsContainer オブジェクトクラスが含まれるエントリーで一意である必要があります。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq set "mail Attribute Uniqueness" --top-entry-oc=nsContainer
- 必要に応じて、チェックされるオブジェクトの範囲を制限できます。サーバーが nsContainer オブジェクトクラスを含むエントリーの下にあるエントリーのサブセットのみをチェックするようにするには、
uniqueness-subtree-entries-oc
パラメーターに追加のオブジェクトクラスを設定します。この追加クラスも存在している必要があります。たとえば、nsContainer オブジェクトクラスセットが含まれるエントリーにあるすべてのエントリーでmail
属性を一意にする必要があります。ただし、プラグインは、inetOrgPerson など、この属性を提供するオブジェクトクラスが含まれるエントリーでmail
のみを検索します。この場合は、以下を入力します。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin attr-uniq set "mail Attribute Uniqueness" --subtree-entries-oc=inetOrgPerson
- インスタンスを再起動します。
# dsctl instance_name restart
7.1.4. 属性の一意性プラグイン設定パラメーター
例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. サービスのクラスの割り当て
- 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.2 Pointer CoS のサンプル
postalCode
属性がエントリー cn=wholiday,ou=people,dc=example,dc=com に対してクエリーされるたびに、Directory Server は、テンプレートエントリー cn=exampleUS,cn=data で使用可能な値を返します。
7.2.4. 間接的な CoS の仕組み
manager
属性を使用してテンプレートエントリーを識別する間接的な CoS を作成します。図7.3「間接的な CoS の例」に示されるように、3 つの CoS エントリーが表示されます。
図7.3 間接的な CoS の例
manager
属性) が含まれます。William のマネージャーは Carla Fuentes であるため、manager
属性にはテンプレートエントリーの DN へのポインター cn=Carla Fuentes,ou=people,dc=example,dc=com が含まれます。テンプレートエントリーは次に、318842 の departmentNumber
属性値を提供します。
7.2.5. Classic CoS の仕組み
図7.4 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 定義エントリーの作成
cosTemplateDn
属性で指定されたエントリー DN 値を使用してテンプレートエントリーを識別します。
例7.2 Pointer CoS エントリーの例
dn: cn=pointerCoS,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass:cosPointerDefinition
cosTemplateDn
:DN_string cosAttribute:list_of_attributes qualifier cn: pointerCoS
cosIndirectSpecifier
属性で指定されているターゲットエントリーの属性のいずれかの値に基づいてテンプレートエントリーを識別します。これは、例7.3「間接的な CoS エントリーの例」 で説明されています。
例7.3 間接的な CoS エントリーの例
dn: cn=indirectCoS,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass:cosIndirectDefinition
cosIndirectSpecifier
:attribute_name cosAttribute:list_of_attributes qualifier cn: indirectCoS
cosTemplateDn
属性に設定) と、ターゲットエントリーの属性のいずれかの値 (cosSpecifier
属性に設定) の両方を使用してテンプレートエントリーを特定します。これは、例7.4「Classic CoS エントリーの例」 で説明されています。
例7.4 Classic CoS エントリーの例
dn: cn=classicCoS,dc=example,dc=com objectclass: top objectclass: cosSuperDefinition objectclass:cosClassicDefinition
cosTemplateDn
:DN_stringcosSpecifier
:attribute_name cosAttribute:list_of_attributes qualifier cn: classicCoS
cosAttribute
)。CoS の目的は、複数のエントリーに属性値を提供することです。cosAttribute
属性は、CoS が生成する属性を定義します。
7.2.10.2. コマンドラインでの CoS テンプレートエントリーの作成
cosAttribute
属性で指定) によって生成された属性とその属性の値も含まれます。
postalCode
属性の値を提供する CoS テンプレートエントリーは、以下のようになります。
dn:cn=exampleUS,ou=data,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 44438
7.2.10.3. Pointer CoS の例
- ldapmodify を使用して、新しい pointer CoS 定義エントリーを dc=example,dc=com 接尾辞に追加します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=pointerCoS,dc=example,dc=com changetype: add objectclass: top objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=exampleUS,ou=data,dc=example,dc=com cosAttribute: postalCode
- テンプレートエントリーを作成します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=exampleUS,ou=data,dc=example,dc=com changetype: add objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 44438
postalCode
属性に保存された値を dc=example,dc=com 接尾辞に置かれているエントリーに提供します。これらのエントリーはターゲットエントリーです。
7.2.10.4. 間接的な CoS の例
manager
属性を使用して CoS テンプレートエントリーを識別します。これは、属性の値によって異なります。
- ldapmodify を使用して、dc=example,dc=com 接尾辞に新しい間接 CoS 定義エントリーを追加します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=indirectCoS,dc=example,dc=com changetype: add objectclass: top objectclass: cosSuperDefinition objectclass: cosIndirectDefinition cosIndirectSpecifier: manager cosAttribute: departmentNumber
departmentNumber
属性がすでに含まれる場合は、他の属性をマネージャーエントリーに追加する必要はありません。この属性は定義エントリーの cosIndirectSpecifier
属性に指定されるため、定義エントリーは manager
属性が含まれるエントリーのターゲット接尾辞 (dc=example,dc=com 下のエントリー) を検索します。次に、一覧表示された manager エントリーの departmentNumber
値を確認します。departmentNumber
属性の値は、manager
属性を持つマネージャーの下位すべてに自動的にリレーされます。departmentNumber
の値は、異なるマネージャーのエントリーに記載されている部門番号によって異なります。
7.2.10.5. Classic CoS の例
cosSpecifier
属性で指定された属性の組み合わせを使用して、郵便番号コードを自動的に生成する Classic CoS を作成します。
- ldapmodify を使用して、新しいクラス CoS 定義エントリーを dc=example,dc=com 接尾辞に追加します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=classicCoS,dc=example,dc=com changetype: add objectclass: top objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: cn=classicCoS,dc=example,dc=com cosSpecifier: businessCategory cosAttribute: postalCode override
- 営業部門およびマーケティング部門のテンプレートエントリーを作成します。CoS 属性をテンプレートエントリーに追加します。テンプレートの
cn
は、ターゲットエントリーのbusinessCategory
属性の値を設定し、テンプレートの値に応じて属性を追加または上書きされます。# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=sales,cn=classicCoS,dc=example,dc=com changetype: add objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 44438 - dn: cn=marketing,cn=classicCoS,dc=example,dc=com changetype: add objectclass: top objectclass: extensibleObject objectclass: cosTemplate postalCode: 99111
businessCategory
属性と cosTemplateDn
の組み合わせによって、2 つのテンプレートのいずれかに到達できます。1 つ目は営業テンプレートで、営業部門に従業員固有の郵便番号コードを提供します。マーケティングテンプレートは、マーケティング部門の従業員固有の郵便番号コードを提供します。
7.2.10.6. CoS エントリーの検索
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=pointerCoS,ou=People,dc=example,dc=com changetype: add objectclass: ldapSubEntry
ldapsearch
ユーティリティーで (objectclass=ldapSubEntry) フィルターを使用して、ldapSubEntry オブジェクトクラスを含むエントリーを検索します。以下に例を示します。
# ldapsearch -x -s sub -b ou=People,dc=example,dc=com "(|(objectclass=*)(objectclass=ldapSubEntry))"
7.2.10.7. costargettree 属性
costargettree
属性は、CoS スキーマが適用されるサブツリーを定義します。スキーマと複数の CoS スキーマの costargettree
の値は、任意にターゲットツリーと重複する可能性があります。
OID | 2.16.840.1.113730.3.1.552 |
構文 | DirectoryString |
多値または単一値 | 単一値 |
定義される場所 | Directory Server |
7.2.11. ロールベースの属性の作成
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.5 リンク先属性の基本設定
図7.6 リンク先属性プラグインを特定のサブツリーに制限
- 管理属性とリンク先属性の両方で、属性定義で識別名の構文が必要です。リンク先属性は基本的にクロス参照で管理されます。プラグインがこれらの相互参照を処理する方法は、属性値からエントリーの DN をプルすることで行われます。カスタムスキーマ要素のプランニングに関する情報は、12章ディレクトリースキーマの管理を参照してください。
- 各リンク先属性プラグインインスタンスはローカルで、管理 属性は一部レプリケーションを使用してレプリケーションからブロックする必要があります。あるサプライヤーに加えられた変更は、プラグインが自動的に発生し、対応するディレクトリーエントリーの値を管理するため、データはサーバー全体で一貫性を維持します。ただし、リンクされたエントリー間でデータの一貫性を保つには、プラグインインスタンスで管理属性を維持する必要があります。つまり、管理属性値は、マルチサプライヤーレプリケーション環境であっても、レプリケーションプロセスではなく、プラグインプロセスによってのみ維持される必要があります。一部レプリケーションの使用方法は、「一部レプリケーションを使用した属性のサブセットの複製」を参照してください。
7.3.2. リンク元属性プラグイン構文の確認
linkType
属性において、管理者が手動で管理する属性managedType
属性に含まれる、プラグインによって動的に作成される属性- 必要に応じて、プラグインを
linkScope
属性のディレクトリーツリーの特定の部分に制限するスコープ
例7.5 リンク先属性のプラグインインスタンスエントリーの例
dn: cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: Manager Link linkType: directReport managedType: manager linkScope: ou=people,dc=example,dc=com
7.3.3. 属性リンクの設定
- これが有効になっていない場合は、Linked Attributes プラグインを有効にします。詳細については、「プラグインの有効化および無効化」 を参照してください。
- プラグインインスタンスを作成します。
--managed-type
パラメーターおよび--link-type
パラメーターの両方が必要です。以下の例は、dsconf を使用して作成したプラグインインスタンスを示しています。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin linked-attr config "Manager Link" add --link-type=directReport --managed-type=manager
- インスタンスを再起動します。
# dsctl instance_name restart
7.3.4. 属性リンクのクリーンアップ
7.3.4.1. リンク先属性の再生成
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin linked-attr fixup
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin linked-attr fixup "cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config"
7.3.4.2. ldapmodify を使用したリンク先属性の再生成
dse.ldif
ファイルの cn=tasks 設定エントリーで発生するため、ldapmodify を使用してエントリーを追加してタスクを開始することもできます。タスクが完了すると、エントリーはディレクトリーから削除されます。
cn
のみですが、ttl
属性にはタイムアウト期間を設定できます。ldapmodify の使用:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=example,cn=fixup linked attributes,cn=tasks,cn=config changetype: add cn:example ttl: 5
dse.ldif
設定から削除されるため、同じタスクエントリーを継続的に再利用できます。
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
....DNA プラグインは、新規の一意の値のみを生成します。DNA プラグインが制御する属性に特定の値を使用するためにエントリーを追加または変更した場合には、指定した番号が使用されます。DNA プラグインは、その番号を上書きしません。
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.6 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. DNA プラグインの新規インスタンスの作成
- たとえば、プラグインの新規インスタンスを作成するには、以下のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin dna config "Account UIDs" add --type uidNumber --filter "(objectclass=posixAccount)" --scope ou=People,dc=example,dc=com --next-value 1 --max-value 1300 --shared-config-entry "cn=Account UIDs,ou=Ranges,dc=example,dc=com" --threshold 100 --range-request-timeout 60 --magic-regen magic
で設定できる値の詳細については、--magic-regen
パラメーターについては、『Configuration, Command and File Reference』 のdnaMagicRegen
属性の説明。 - DNA プラグインを有効にするには、以下を実行します。詳細については、「プラグインの有効化および無効化」 を参照してください。
7.4.3.2. コマンドラインでの一意の番号割り当ての設定
dnaNextvalue
がすでに取得されているかどうかを確認するために、サーバーは、内部的にソートされた検索を実行する必要があります。これには、適切な順序のマッチングルールとともに整数属性で等価インデックスが必要であるかを確認します。
- プラグインの新規インスタンスを作成します。「DNA プラグインの新規インスタンスの作成」を参照してください。
- 複製されたサブツリーに共有コンテナーエントリーを作成します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: ou=Ranges,dc=example,dc=com changetype: add objectclass: top objectclass: extensibleObject objectclass: organizationalUnit ou: Ranges - dn: cn=Account UIDs,ou=Ranges,dc=example,dc=com changetype: add objectclass: top objectclass: extensibleObject cn: Account UIDs
- インスタンスを再起動します。
# dsctl instance_name restart
7.4.3.3. Web コンソールを使用した一意の番号割り当ての設定
- プラグインの新規インスタンスを作成します。「DNA プラグインの新規インスタンスの作成」を参照してください。
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- DNA プラグインを選択します。
- ステータスを ON に変更し、プラグインを有効にします。
- フィールドを入力し、設定を有効にします。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
7.4.4. Distributed Number Assignment プラグインのパフォーマンスに関する注意事項
第8章 エントリーの編成とグループ化
8.1. グループの使用
nsRoleDN
属性に保存されます。グループを使用する場合は、このグループのメンバーであるユーザーの DN は、グループオブジェクトの member
属性に保存されます。memberOf プラグインを有効にした場合、次にユーザーがメンバーであるグループは、ユーザーオブジェクトの memberOf
属性に追加で保存されます。このプラグインを有効にすると、グループにもロールの利点があり、ロールの使用時と同様にユーザーのグループメンバーシップをリスト表示できます。また、グループはロールよりも高速です。
8.1.1. 各種グループ
- groupOfNames (推奨) は、任意のエントリーの追加を可能にする単純なグループです。これのメンバーを判断するために使用される属性は
member
です。 - groupOfNames などの groupOfUniqueNames は、ユーザー DN をメンバーとして一覧表示しますが、メンバーは一意でなければなりません。これにより、ユーザーをグループメンバーとして複数回追加しないようにできます。これは、セルフ参照グループメンバーシップを防ぐ 1 つの方法です。これのメンバーを判断するために使用される属性は
uniqueMember
です。 - groupOfURLs は、LDAP URL の一覧を使用して、メンバーシップの一覧をフィルタリングして生成します。このオブジェクトクラスはすべての動的グループに必要で、groupOfNames および groupOfUniqueNames とともに使用できます。
- groupOfCertificates は、グループメンバーを識別するための証明書 (実際には証明書名) を検索して識別するために LDAP フィルターを使用するという点で、groupOfURLs と似ています。これは、グループに特別なアクセスパーミッションを付与できるため、グループベースのアクセス制御に役立ちます。これのメンバーを判断するために使用される属性は
memberCertificate
です。
グループのタイプ | グループオブジェクトクラス | member 属性 |
---|---|---|
静的 | groupOfNames [a] | member |
groupOfUniqueNames [a] | uniqueMember | |
動的 | groupOfURLs | memberURL |
groupOfCertificates | memberCertificate | |
[a]
このオブジェクトクラスが動的オブジェクトクラスの 1 つとともに使用されると、グループは動的になります。
|
例8.1 静的グループエントリー
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
例8.2 動的グループエントリー
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.2. 静的グループの作成
8.1.2.1. コマンドラインで静的グループの作成
groupOfNames オブジェクトクラスを使用した静的グループの作成
dsidm
ユーティリティーは、指定したベース DN の cn=Groups エントリーに静的グループを作成します。
example_group
グループを作成するには、次のコマンドを実行します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" group create --cn "example_group"
groupOfUniqueNames オブジェクトクラスを使用した静的グループの作成
ldapmodify
ユーティリティーを使用してエントリーを追加します。
example_group
グループを作成するには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=example_group,cn=Groups,dc=example,dc=com changetype: add objectClass: top objectClass: groupOfUniqueNames cn: example_group description: Example static group with unique members
8.1.3. 動的グループの作成
8.1.3.1. コマンドラインで動的グループの作成
groupOfURLs オブジェクトクラスを使用した動的グループの作成
example_group
グループを作成するには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=example_group,cn=Groups,dc=example,dc=com changetype: add objectClass: top objectClass: groupOfURLs cn: example_group description: Example dynamic group for user entries memberURL: ldap:///dc=example,dc=com??sub?(&(objectclass=person)(cn=*sen*))
groupOfCertificates オブジェクトクラスを使用した動的グループの作成
example_group
グループを作成するには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=example_group,cn=Groups,dc=example,dc=com changetype: add objectClass: top objectClass: groupOfURLs cn: example_group description: Example dynamic group for certificate entries memberCertificate: ...
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 に設定する必要があります。「Web コンソールを使用した各サーバーでの MemberOf プラグインの設定」を参照してください。
8.1.4.2. memberOf
プラグインで必要なオブジェクトクラス
memberOf
プラグイン。デフォルトで、memberOf
プラグインは、MemberOf オブジェクトクラスをオブジェクトに追加し、memberOf
属性を提供します。このオブジェクトクラスは、この目的のために任意のオブジェクトに安全に追加でき、このプラグインを正しく動作させるためにこれ以上のアクションは必要ありません。代わりに、inetUser または inetAdmin オブジェクトクラスが含まれるユーザーオブジェクトを作成できます。どちらのオブジェクトクラスも memberOf
属性をサポートします。
LDAP: error code 65 - Object Class Violation
8.1.4.3. MemberOf プラグイン構文
memberOfGroupAttr
) と、メンバーのユーザーエントリー (memberOfAttr
) で作成および管理する属性の 2 つの属性を定義します。
memberOfGroupAttr
属性は複数値です。異なるタイプのグループは異なるメンバー属性を使用するため、複数の memberOfGroupAttr
属性を使用すると、プラグインで複数のグループタイプを管理できます。
例8.3 デフォルトの 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 プラグインの有効化
dsconf
ユーティリティーを使用してプラグインを有効にします。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin memberof enable
- インスタンスを再起動します。
# dsctl instance_name restart
8.1.4.4.2. Web コンソールを使用した MemberOf プラグインの有効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- MemberOf プラグインを選択します。
- ステータスを ON に変更し、プラグインを有効にします。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
8.1.4.5. 各サーバーでの MemberOf プラグインの設定
8.1.4.5.1. コマンドラインを使用した各サーバーでの MemberOf プラグインの設定
- プラグインを有効にします。「コマンドラインを使用した MemberOf プラグインの有効化」を参照してください。
- デフォルトである
member
以外の属性からグループのメンバーを取得するには、memberOfGroupAttr
パラメーターをそれぞれの属性名に設定します。たとえば、uniqueMember
属性からグループメンバーを読み取るには、memberOfGroupAttr
の現在の値を置き換えます。- 必要に応じて、現在設定されている属性を表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin memberof show ... memberofgroupattr: member ...
このコマンドは、現在member
属性のみがグループのメンバーを取得するように設定されていることを示しています。 - 現在設定されている設定からすべての属性を削除します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin memberof set --groupattr delete Successfully changed the cn=MemberOf Plugin,cn=plugins,cn=config
注記特定のグループ属性を削除できません。 - 設定に
uniqueMember
属性を追加します。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin memberof set --groupattr uniqueMember successfully added memberOfGroupAttr value "uniqueMember"
複数の属性を設定するには、すべて--groupattr
パラメーターに渡します。以下に例を示します。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin memberof set --groupattr member uniqueMember ...
- デフォルトでは、MemberOf プラグインは
memberOf
属性をユーザーエントリーに追加します。別の属性を使用するには、memberOfAttr
パラメーターで属性の名前を設定します。たとえば、customMemberOf
属性をユーザーレコードに追加するには、memberOfAttr
の現在の値を置き換えます。- 必要に応じて、現在設定されている属性を表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin memberof show ... memberofattr: memberOf ...
- MemberOf プラグインを設定し、
customMemberOf
属性をユーザーエントリーに追加します。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin memberof set --attr customMemberOf memberOfAttr set to "customMemberOf"
注記このパラメーターは、DN 構文をサポートする属性にのみ設定できます。
- 分散データベースを使用する環境では、ローカルデータベースのみではなく、すべてのデータベースでユーザーエントリーを検索するようにプラグインを設定できます。
dsconf -D "cn=Directory Manager" ldap://server.example.com plugin memberof set --allbackends on memberOfAllBackends enabled successfully
- インスタンスを再起動します。
# dsctl instance_name restart
8.1.4.5.2. Web コンソールを使用した各サーバーでの MemberOf プラグインの設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- memberOf プラグインを選択します。
- ステータスを ON に変更し、プラグインを有効にします。
- フィールドに入力してプラグインを設定します。たとえば、
uniqueMember
属性がグループに追加されると、プラグインがユーザーエントリーにcustomMemberOf
属性を追加するように設定するには、以下を実行します。 - インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
8.1.4.7. MemberOf プラグインのスコープの設定
memberOfEntryScope
パラメーターおよび memberOfEntryScopeExcludeSubtree
パラメーターを使用して、MemberOf
プラグインが動作する接尾辞を設定できます。
MemberOf
プラグインは、ユーザーおよびグループの両方がプラグインのスコープにある場合に限り memberOf
属性をグループに追加します。たとえば、dc=example,dc=com
内のすべてのエントリーで機能するように MemberOf
プラグインを設定し、ou=private,dc=example,dc=com
のエントリーを除外するには、以下のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin memberof set --scope "dc=example,com" # dsconf -D "cn=Directory Manager" ldap://server.example.com plugin memberof set --exclude "dc=group,dc=example,com"
--scope DN
パラメーターを使用してユーザーエントリーを範囲外に移動した場合:
member
などのメンバーシップ属性は、グループエントリーで更新され、ユーザー DN 値が削除されます。memberOf
属性は、グループ DN 値を削除するためにユーザーエントリーで更新されます。
--exclude
パラメーターに設定した値は、--scope
に設定した値よりも高くなります。両方のパラメーターで設定したスコープが重複する場合、MemberOf
プラグインは、非オーバーラッピングディレクトリーエントリーでのみ機能します。
8.1.4.8. memberOf
値の再生成
memberOf
属性を自動的に管理します。ただし、memberOf
属性はユーザーエントリーで手動で編集でき、新しいエントリーは memberOf
属性がすでに設定されているサーバーにインポートまたは複製できます。このような状況では、サーバープラグインによって管理される memberOf
設定と、エントリーで定義された実際のメンバーシップとの間に不整合が生じます。
memberOf
の値を再生成するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin memberof fixup -f "(|(objectclass=inetuser)(objectclass=inetadmin)(objectclass=nsmemberof))" "dc=example,dc=com" Attempting to add task entry... Successfully added task entry
-f filter
オプションは任意です。フィルターを使用して、フィルターに一致するユーザーエントリーの memberOf
属性を再生成します。フィルターを指定しない場合、タスクは inetUser オブジェクトクラス、inetAdmin オブジェクトクラス、または nsMemberOf オブジェクトクラスを含むすべてのエントリーで属性を再生成します。
memberOf
属性は更新されません。
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.4 ホストグループの 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.5 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. Auto Membership 定義の設定
8.1.5.2.1. コマンドラインを使用した Auto Membership 定義の設定
- Auto Membership プラグインを有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin automember enable Enabled Auto Membership Plugin
- Auto Membership 定義を作成します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin automember definition definition_name add --default-group "cn=windows-group,cn=groups,dc=example,dc=com" --scope "ou=People,dc=example,dc=com" --filter "objectclass=ntUser" --grouping-attr "member:dn" Automember definition created successfully!
- 必要に応じて、Auto Membership 定義に追加のパラメーターを設定して、たとえば正規表現を使用して追加するエントリーを特定します。
ldapmodify
ユーティリティーを使用して、cn=definition_name,cn=Auto Membership Plugin,cn=plugins,cn=config エントリーにこれらのパラメーターを追加または更新します。設定可能なパラメーターは、Red Hat Directory Server Configuration, Command, and File Reference の cn=Auto Membership Plugin,cn=plugins,cn=config エントリーの説明を参照してください。 - インスタンスを再起動します。
# dsctl instance_name restart
8.1.5.2.2. Web コンソールを使用した Auto Membership 定義の設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Auto Membership プラグインを選択します。
- ステータスを ON に変更し、プラグインを有効にします。
- フィールドに入力します。以下に例を示します。
- オプションで、正規表現フィルターを追加します。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
8.1.5.3. 既存エントリーの更新による Auto Membership 定義の適用
autoMemberProcessModifyOps
パラメーターは有効です。この設定では、Automembership プラグインは、ユーザーエントリーを編集して管理者が別のグループにユーザーを移動する際にグループメンバーシップも更新します。ただし、autoMemberProcessModifyOps
を off に設定した場合は、ディレクトリーに新しいエントリーを追加したか、既存のエントリーを変更した場合に、手動で修正タスクを実行する必要があります。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin automember fixup -f "filter" -s scope
8.1.5.4. Automembership ルールの例
- IP アドレスに基づく異なるホストグループ
- Windows ユーザーグループ
- 従業員の ID に基づく異なるユーザーグループ
例8.6 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.7 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.8 従業員タイプによるユーザーグループ
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.5. 自動メンバー定義のテスト
既存のエントリーを使用したテスト
cn=automember export updates が、ディレクトリー内の 既存のエントリー に対して実行し、ルールに基づいてユーザーの追加結果をエクスポートします。これは、既存のルールをテストして、実際のデプロイメントの実行方法を確認するのに役立ちます。
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server.example.com -x 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 を取得してから、現在の自動メンバールールに対して新規ユーザーを実行します。これは、(実際の) 新規または既存のユーザーエントリーに適用する前に、新しいルールをテストする場合に非常に役立ちます。
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server.example.com -x 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.1.5.6. Auto Membership プラグインタスクのキャンセル
手順
- Auto Membership プラグインタスクをキャンセルするには、以下を入力します。
# dsconf server.example.com plugin automember abort-fixup
検証
- キャンセルされたタスクを含む、すべての Auto Membership プラグインタスクのリストを表示するには、以下を入力します。
# dsconf server.example.com plugin automember fixup-status
8.2. ロールの使用
8.2.1. ロールの概要
- マネージドロール には、メンバーの明示的な列挙リストがあります。
- フィルターされたロール には、LDAP フィルターで指定される各エントリーに含まれる属性に応じて、エントリーがロールに割り当てられます。フィルターに一致するエントリーはロールを持ちます。
- ネストされたロール は、他のロールが含まれるロールです。
nsRole
属性を検索してロールのメンバーシップを確認することができます。nsRole
属性は、エントリーが属するロールを識別する計算属性です。nsRole
属性はエントリー自体に保存されません。クライアントアプリケーションの観点からは、メンバーシップを確認する方法は統一されており、サーバー側で実行されます。
8.2.2. コマンドラインを使用したロールの管理
8.2.2.1. 管理ロールの作成
nsRoleDN
属性を追加して、管理ロールがエントリーに追加されます。
8.2.2.1.1. コマンドラインでの管理ロールの作成
- 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.2.2. フィルター設定されたロールの作成
8.2.2.2.1. コマンドラインでフィルターされたロールの作成
- 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.2.3. ネスト化されたロールの作成
nsRoleDN
属性を使用して指定します。
8.2.2.3.1. コマンドラインでのネスト化されたロールの作成
- 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.2.4. コマンドラインでエントリーのロールの表示
+
を使用して結果オブジェクトの操作属性をすべて出力することができます。たとえば、この ldapsearch コマンドは、エントリーの通常の属性に加えて、uid=user_name がメンバーであるロールのリストを返します。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(uid=user_name)"” \* nsRole dn: uid=user_name,ou=people,dc=example,dc=com ... nsRole: cn=Role for Managers,dc=example,dc=com nsRole: cn=Role for Accounting,dc=example,dc=com
8.2.2.5. ロールの削除の概要
nsRoleDN
属性は削除されません。各ロールメンバーの nsRoleDN
属性を削除するには、Referential Integrity プラグインを有効にし、nsRoleDN
属性を管理するように設定します。Referential Integrity プラグインの詳細は、5章参照整合性の維持を参照してください。
8.2.3. LDAP ブラウザーを使用したディレクトリーサーバーでのロールの管理
8.2.3.1. LDAP ブラウザーでのロールの作成
前提条件
- Web コンソールへのアクセス。
- Red Hat Directory Server に存在する親エントリー。
手順
- Web コンソールにログインし、をクリックします。
- Web コンソールがインターフェイスをロードしたら、 をクリックします。
- LDAP エントリーを選択し、Options メニューをクリックします。
- ドロップダウンメニューからを選択し、 をクリックします。
- ウィザードの手順に従い、各手順を完了したらボタンをクリックします。
- ロールを作成するには、の手順でロールの設定を確認し、 ボタンをクリックします。 ボタンをクリックしてロールの設定を変更するか、 ボタンをクリックしてロールの作成をキャンセルできます。
- ウィザードウィンドウを閉じるには、ボタンをクリックします。
検証
- LDAP エントリーを展開し、新しいロールがエントリーパラメーターに表示されることを確認します。
8.2.3.2. LDAP ブラウザーでのロールの変更
前提条件
- Web コンソールへのアクセス。
- Red Hat Directory Server に存在する親エントリー。
手順
- Web コンソールにログインし、をクリックします。
- Web コンソールがインターフェイスをロードしたら、 をクリックします。
- LDAP エントリーを展開し、変更するロールを選択します。
- Options メニューをクリックし、を選択してロールのパラメーターを変更するか、 を選択してロールの名前を変更します。
- ウィザードウィンドウで必要なパラメーターを変更し、の手順が表示されるまで各手順を完了して をクリックします。
- 更新されたパラメーターを確認し、または をクリックします。
- ウィザードウィンドウを閉じるには、ボタンをクリックします。
検証
- LDAP エントリーを展開し、更新されたパラメーターがロールにリストされていることを確認します。
8.2.3.3. LDAP ブラウザーでのロールの削除
前提条件
- Web コンソールへのアクセス。
- Red Hat Directory Server に存在する親エントリー。
手順
- Web コンソールにログインし、をクリックします。
- Web コンソールがインターフェイスをロードしたら、 をクリックします。
- LDAP エントリーを展開し、削除するロールを選択します。
- Options メニューを開き、を選択します。
- 削除するロールに関するデータを確認し、の手順に到達するまで ボタンをクリックします。
- スイッチをの位置に切り替え、 ボタンをクリックします。
- ウィザードウィンドウを閉じるには、ボタンをクリックします。
検証
- LDAP エントリーを展開し、ロールがエントリーの詳細に含まれていないことを確認します。
8.2.4. セキュアなロールの使用
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 | 管理エントリーに指定された値とともに使用される属性と値のペアが含まれます。 |
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin managed-entries template "cn=Posix User Template,ou=templates,dc=example,dc=com" add --rdn-attr "cn" --static-attr "objectclass: posixGroup" --mapped-attr "cn: $cn Group Entry" "gidNumber: $gidNumber" "memberUid: $uid"
8.3.3. マネージドエントリーインスタンス定義の作成
属性名 | 説明 |
---|---|
originFilter | 検索に使用する検索フィルターで、管理エントリーを必要とするサブツリーのエントリーを特定します。構文は、通常の検索フィルターと同じです。 |
originScope | 監視するプラグインの潜在的な元のエントリーを含むベースサブツリー。 |
managedTemplate | 管理エントリーの作成に使用するテンプレートエントリーを特定します。このエントリーは、ディレクトリーツリーの任意の場所に置くことができます。 |
managedBase | 管理エントリーを作成するサブツリー。 |
- cn=Managed Entries,cn=plugins,cn=config コンテナーエントリーの下に、新しいプラグインインスタンスを作成します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin managed-entries config "cn=instance,cn=Managed Entries,cn=plugins,cn=config" add --scope="ou=people,dc=example,dc=com" --filter="objectclass=posixAccount" --managed-base="ou=groups,dc=example,dc=com" --managed-template="cn=Posix User-Group Template,ou=Templates,dc=example,dc=com"
このコマンドは、作成元のエントリー検索、新規管理エントリーの場所、使用するテンプレートエントリーの場所を設定します。 - Directory Server が動的プラグインを有効にするために設定されていない場合は、サーバーを再起動して変更した新しいプラグインインスタンスを読み込みます。
# dsctl instance_name restart
8.3.4. 複製されたデータベースへの管理エントリープラグイン設定の追加
nsslapd-pluginConfigArea
属性が許可されます。この属性は、プラグインインスタンスエントリーが含まれるメインのデータベースエリアにおける、別のコンテナーエントリーへの属性です。このコンテナーエントリーは、複製されたデータベースで使用することができます。これにより、プラグイン設定を複製できます。
- コンテナーエントリーを作成します。たとえば、コンテナーエントリーを参照するエントリーを作成するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin managed-entries set --config-area="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 ファイルのサンプルがあります。このファイルは、/usr/share/dirsrv/data/
ディレクトリーにあります。本章のセクションは、Example-views.ldif
がサーバーにインポートされることを前提としています。
8.4.2. コマンドラインでのビューの作成
- 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.3. ビューのパフォーマンスの向上
nsViewFilter
属性で定義される属性です。フィルターの残りの部分はエントリー階層に基づいており、ビューに含まれる実際のエントリーの entryid
と parentid
を探します。
(|(parentid=search_base_id)(entryid=search_base_id)
entryid
、parentid
、または nsViewFilter
に設定された属性) のいずれかがインデックス化されない場合、views 操作は一致するエントリーのツリー全体を検索するため、ビューの検索はインデックスなしの検索になります。
entryid
、parentid
、および nsViewFilter
で設定した属性の等価インデックスを作成します。
8.5. 組織単位の管理
- OU を作成するには、次のコマンドを実行します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" organizationalunit create --ou OU_name
- エントリー内の OU をリスト表示するには、以下を入力します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" organizationalunit list People ...
- OU の名前を変更するには、次のコマンドを実行します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" organizationalunit rename old_name new_name
- OU を削除するには、次のコマンドを実行します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" organizationalunit delete OU_name
第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
パラメーターを 128 に設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-minssf=128 Successfully replaced "nsslapd-minssf"
nsslapd-require-secure-binds
属性をオンにすることで、バインド操作にセキュアな接続が必要になる場合があります。
9.3. Directory Server が使用する NSS データベースの管理
dscreate
ユーティリティーは /etc/dirsrv/slapd-instance_name/
ディレクトリーにこのデータベースを自動的に作成し、強力なパスワードで保護します。このユーティリティーは、パスワードを /etc/dirsrv/slapd-instance_name/pwdfile.txt
ファイルに保存します。Directory Server はこのファイルを使用しないことに注意してください。dscreate
ユーティリティーは、管理者にパスワードを提供するためだけにこのファイルを作成しました。パスワードの変更方法は、「NSS データベースのパスワードの変更」を参照してください。
9.3.1. 証明書署名要求の作成
certutil
ユーティリティーを使用して NSS データベースへの秘密鍵と証明書および CSR を直接作成することのみをサポートします。
9.3.1.1. コマンドラインを使用した証明書署名要求の作成
# dsctl instance_name tls generate-server-cert-csr -s "certificate_subject"
/etc/dirsrv/slapd-instance_name/Server-Cert.csr
ファイルに、秘密鍵を DDirectory Server のネットワークセキュリティーサービス (NSS) データベースに保存します。
例9.1 単一ホスト名の秘密鍵および CSR の作成
server.example.com
ホストのビット秘密鍵を生成します。
# dsctl instance_name tls generate-server-cert-csr -s "CN=server.example.com,O=example_organization,OU=IT,ST=North Carolina,C=US"
-s
パラメーターで指定した文字列は、RFC 1485 に従って有効なサブジェクト名である必要があります。CN
フィールドが必要で、サーバーの完全修飾ドメイン名 (FQDN) に設定する必要があります。その他のフィールドは任意です。
例9.2 マルチホームホストの秘密鍵および CSR の作成
server.example.com
および server.example.net
の CSR を作成します。
# dsctl instance_name tls generate-server-cert-csr -s "CN=server.example.com,O=example_organization,OU=IT,ST=North Carolina,C=US" server.example.com server.example.net
-s
パラメーターで指定した文字列は、RFC 1485 に従って有効なサブジェクト名である必要があります。CN
フィールドが必要で、サーバーの FQDN のいずれかに設定する必要があります。その他のフィールドは任意です。
9.3.2. CA 証明書のインストール
Web コンソールオプション | dsconf および certutil オプション | 説明 |
---|---|---|
(C) 信頼できる CA | C,, | サーバーは、レプリケーションパートナーへの暗号化された接続を確立するために使用する証明書を検証し、信頼できる CA により発行されていることを確認します。 |
(T) 信頼できる CA クライアント認証 | T,, | サーバーは、TLS EXTERNAL バインドに適したクライアント証明書を発行するためにこの CA 証明書を信頼します。 |
certutil
を使用する場合は、-T "CT,,"
パラメーターをユーティリティーに渡します。
9.3.2.1. コマンドラインを使用した CA 証明書のインストール
- CA 証明書をインポートします。たとえば、
/root/ca.crt
ファイルに保存されている CA 証明書をインポートし、Example CA
のニックネームでデータベースに保存するには、次のコマンドを実行します。# dsconf -D "cn=Directory Manager" ldap://server.example.com security ca-certificate add --file /root/ca.crt --name "Example CA"
- 信頼オプションを設定します。たとえば、CT,, t 信頼フラグを設定するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com security ca-certificate set-trust-flags "Example CA" --flags "CT,,"
9.3.2.2. Web コンソールを使用した CA 証明書のインストール
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Security エントリーを選択します。メニューを開き、
- Certificate Management タブを開き、Trusted Certificate Authorities サブタブを選択します。
- CA 証明書ファイルへのパスと証明書のニックネームを入力します。
図9.1 CA 証明書の追加
注記CA 証明書は Directory Server ホストにローカルに保存され、dirsrv
ユーザーが読み取り可能でなければなりません。 - インポートされた CA 証明書の横にある Edit Trust Flags を選択します。をクリックし、
- SSL 列で、(C) - Trusted CA および (T)- Trusted CA Client Auth を選択します。
図9.2 CA 証明書の信頼フラグの追加
9.3.3. 秘密鍵およびサーバー証明書のインポート
/root/server.crt
から証明書をインポートし、/root/server.key
ファイルから秘密鍵をインポートするには、以下を入力します。
# dsctl instance_name tls import-server-key-cert /root/server.crt /root/server.key
- サーバー証明書へのパス。
- 秘密鍵ファイルへのパス。
9.3.4. サーバー証明書のインストール
9.3.4.1. コマンドラインを使用したサーバー証明書のインストール
certutil
ユーティリティーを使用します。以下に例を示します。
- CA 証明書をインストールします。「CA 証明書のインストール」を参照してください。
- サーバー証明書をインポートします。たとえば、
/root/instance_name.crt
ファイルに保存されている証明書をインポートし、インスタンスが使用するプライマリー証明書として設定します。# dsconf -D "cn=Directory Manager" ldap://server.example.com security certificate add --file /root/instance_name.crt --name "Server-Cert" --primary-cert
9.3.4.2. Web コンソールを使用したサーバー証明書のインストール
- CA 証明書をインストールします。「CA 証明書のインストール」を参照してください。
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Security エントリーを選択します。メニューを開き、
- Certificate Management タブを開き、サブタブの TLS Certificates を選択します。
- CA 証明書ファイルのパスおよび証明書のニックネームを入力します。
図9.3 サーバー証明書の追加
注記サーバー証明書は Directory Server ホストにローカルに保存され、dirsrv
ユーザーが読み取り可能でなければなりません。
9.3.5. 自己署名証明書の生成およびインストール
dscreate
ユーティリティーを使用して TLS を有効にしたインスタンスを作成すると、dscreate
が自動的に作成され、自己署名証明書がインストールされます。ただし、インスタンスの作成時に TLS を有効にしなかった場合は、手動で自己署名証明書を作成およびインストールできます。
- ランダムなデータで関心のあるファイルを生成します。たとえば、サイズが 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 証明書のインストール」を参照してください。
- インスタンスを停止します。
# dsctl instance_name stop
/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 は起動に失敗します。- インスタンスを起動します。
# dsctl instance_name start
Directory Server は、新たに発行した証明書を自動的に使用します。 - 属性の暗号化を使用する場合は、「属性暗号化に使用される TLS 証明書の更新」 を参照してください。
9.3.7. 証明書の削除
9.3.7.1. コマンドラインで証明書の削除
- 必要に応じて、データベースの証明書を表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com security certificate list Certificate Name: Server-Cert Subject DN: CN=server.example.com Issuer DN: CN=Example CA Expires: 2022-07-29 11:10:14 Trust Flags: ,,
- 証明書を削除します。たとえば、Server-Cert ニックネームで証明書を削除するには、次を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com security certificate del Server-Cert
9.3.7.2. Web コンソールを使用した証明書の削除
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Security エントリーを選択します。メニューを開き、
- Certificate Management タブを開き、サブタブの TLS Certificates を選択します。
- 証明書の横にある Delete Certificate を選択します。をクリックし、
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.9. CA 信頼オプションの変更
9.3.9.1. コマンドラインを使用した CA 信頼オプションの変更
--flags
パラメーターの新しいオプションを dsconf security ca-certificate set-trust-flags コマンドに渡します。
example-CA
という名前の CA が発行するクライアント証明書のみを信頼するように設定するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com security ca-certificate set-trust-flags "example-CA" --flags "T,,"
--flags trust_options
パラメーターは、CA が発行し、信頼する証明書を設定します。表9.1「CA 信頼オプション」を参照してください。
9.3.9.2. Web コンソールを使用した CA 信頼オプションの変更
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Security エントリーを選択します。メニューを開き、
- Certificate Management タブを開きます。
- Trusted Certificate Authorities サブタブで、インポートした CA 証明書の横にある をクリックし、Edit Trust Flags を選択します。
- 信頼フラグを選択します。以下に例を示します。
図9.4 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.4. TLS の有効化
- LDAPS プロトコル: TLS 暗号化は接続が確立された後に直接使用されます。
- LDAP プロトコルの STARTTLS コマンド: 接続は、クライアントが STARTTLS コマンドを送信するまで暗号化されません。
9.4.1. Directory Server での TLS の有効化
9.4.1.1. コマンドラインを使用した Directory Server での TLS の有効化
- 証明書を要求してインストールします。
- 認証局 (CA) が発行する証明書の場合:
- Certificate Signing Request (CSR) を生成します。「コマンドラインを使用した証明書署名要求の作成」を参照してください。
- CA 証明書をインポートします。「コマンドラインを使用した CA 証明書のインストール」を参照してください。
- CA が発行するサーバー証明書をインポートします。「コマンドラインを使用したサーバー証明書のインストール」を参照してください。
- 自己署名証明書は、「自己署名証明書の生成およびインストール」を参照してください。
- TLS を有効にし、LDAPS ポートを設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-securePort=636 nsslapd-security=on Successfully replaced "nsslapd-securePort" Successfully replaced "nsslapd-security"
- NSS データベースでサーバー証明書名を表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com security certificate list Certificate Name: Server-Cert Subject DN: CN=server.example.com Issuer DN: CN=Example CA Expires: 2022-07-29 11:10:14 Trust Flags: ,,
次の手順でニックネームが必要です。 - RSA 暗号ファミリーを有効にするには、NSS データベースセキュリティーデバイスおよびサーバー証明書名を設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com security rsa set --tls-allow-rsa-certificates on --nss-token "internal (software)" --nss-cert-name Server-Cert
注記デフォルトでは、NSS データベースのセキュリティーデバイスの名前は internal (software) です。 - 必要に応じて、Directory Server がサポートする暗号化のリストを更新します。詳細については、「コマンドラインを使用した Directory Server が使用する暗号の表示および設定」 を参照してください。
- 必要に応じて、証明書ベースの認証を有効にします。詳細については、「証明書ベースのクライアント認証の使用」 を参照してください。
- 必要に応じて、パスワードファイルを作成して、NSS データベースのパスワードを要求せずに Directory Server が起動するようにします。詳細については、「Directory Server のパスワードファイルの作成」 を参照してください。
- Directory Server インスタンスを再起動します。
# dsctl instance_name restart
NSS データベースにパスワードを設定し、パスワードファイルを作成しないと、Directory Server は NSS データベースのパスワードを要求します。詳細については、「パスワードファイルなしで Directory Server の起動」 を参照してください。
9.4.1.2. Web コンソールを使用した Directory Server での TLS の有効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- CSR を作成します。「証明書署名要求の作成」を参照してください。
- 認証局 (CA) 証明書をインポートします。「Web コンソールを使用した CA 証明書のインストール」を参照してください。
- CA が発行するサーバー証明書をインポートします。「Web コンソールを使用したサーバー証明書のインストール」を参照してください。
- Security エントリーを選択します。メニューを開き、
- Security Configuration タブで以下を行います。
- Security Enabled をクリックします。
- Server Certificate Name フィールドで証明書のニックネームを選択します。
- 必要に応じて、サーバーが対応する最小および最大の TLS バージョンの設定を変更します。
- 必要に応じて、クライアントが証明書を使用して認証できるように、クライアント認証を設定します。詳細については、「証明書ベースのクライアント認証の使用」 を参照してください。
- 必要に応じて、パスワードファイルを作成して、NSS データベースのパスワードを要求せずに Directory Server が起動するようにします。詳細については、「Directory Server のパスワードファイルの作成」 を参照してください。
- Directory Server インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。NSS データベースにパスワードを設定し、パスワードファイルを作成しないと、Directory Server は NSS データベースのパスワードを要求します。詳細については、「パスワードファイルなしで Directory Server の起動」 を参照してください。
9.4.1.3. 暗号化暗号の設定
9.4.1.3.1. デフォルトの暗号の表示
nsSSL3Ciphers
パラメーターが設定されていない場合、Directory Server は Network Security Service (NSS) のデフォルトの暗号を使用します。デフォルトの暗号を表示するには、次のコマンドを実行します。
# /usr/lib64/nss/unsupported-tools/listsuites | grep -B1 --no-group-separator "Enabled" TLS_AES_128_GCM_SHA256: 0x1301 TLS 1.3 TLS 1.3 AES-GCM 128 AEAD Enabled FIPS Domestic TLS_CHACHA20_POLY1305_SHA256: 0x1303 TLS 1.3 TLS 1.3 CHACHA20POLY1305 256 AEAD Enabled Domestic ...
9.4.1.3.2. コマンドラインを使用した Directory Server が使用する暗号の表示および設定
利用可能なすべての暗号の表示
# dsconf -D "cn=Directory Manager" ldap://server.example.com security ciphers list --supported TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ...
使用する暗号ディレクトリーサーバーの表示
# dsconf -D "cn=Directory Manager" ldap://server.example.com security ciphers list --enabled TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 ...
# dsconf -D "cn=Directory Manager" ldap://server.example.com security ciphers list default +tls_rsa_aes_128_sha +tls_rsa_aes_256_sha ...
default
キーワードは、NSS が提供する推奨のデフォルト暗号を参照します。「デフォルトの暗号の表示」を参照してください。
nsSSL3Ciphers
属性からの設定を使用して、実際に使用されている暗号の一覧を生成します。ただし、nsSSL3Ciphers
で弱い暗号化を有効にし、allowWeakCiphers
パラメーターをデフォルトの off に設定した場合、Directory Server は強力な暗号化のみを使用し、nsSSLSupportedCiphers
読み取り専用属性に表示します。
有効な暗号リストの更新
- 現在有効な暗号のリストを表示します。「使用する暗号ディレクトリーサーバーの表示」を参照してください。
- 特定の暗号のみを有効にするには、
nsSSL3Ciphers
属性を更新します。たとえば、TLS_RSA_WITH_AES_128_GCM_SHA256
暗号のみを有効にするには、次のコマンドを実行します。# dsconf -D "cn=Directory Manager" ldap://server.example.com security ciphers set "-all,+TLS_RSA_WITH_AES_128_GCM_SHA256"
- Directory Server インスタンスを再起動します。
# dsctl instance_name restart
- 必要に応じて、有効な暗号のリストを表示して、結果を確認します。「使用する暗号ディレクトリーサーバーの表示」を参照してください。
9.4.1.3.3. Web コンソールを使用した Directory Server が使用する暗号の表示および設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Security エントリーを選択します。メニューを開き、
- Cipher Preferences タブで、Directory Server では、現在有効な暗号が表示されます。
- デフォルトとは異なる暗号を使用する場合は、Ciphers Suite フィールドで Default Ciphers を選択し、デフォルトの暗号化を自動的に有効にします。詳細については、「デフォルトの暗号の表示」 を参照してください。または、暗号スイート を以下に設定できます。
- すべての暗号を有効にする All Ciphers。必要に応じて、Deny Specific Ciphers フィールドで特定の暗号を無効にします。
- すべての暗号を無効にする場合は No Ciphers。必要に応じて、Allow Specific Ciphers フィールドで特定の暗号を有効にします。
- 暗号のリストを更新した場合は、Directory Server インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
9.4.1.4. パスワードファイルなしで Directory Server の起動
- systemctl コマンドで ns-slapd Directory Server プロセスが起動すると、
systemd
はパスワードを求めるプロンプトを表示し、その入力内容を systemd-tty-ask-password-agent ユーティリティーに自動的に渡します。以下に例を示します。# systemctl start dirsrv@instance_name 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 に設定します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-validate-cert=on Successfully replaced "nsslapd-validate-cert"
- Directory Server インスタンスを再起動します。
# dsctl instance_name restart
9.4.2. Directory Server が使用する CA 証明書の Red Hat Enterprise Linux のトラストストアへの追加
例9.4 クライアントユーティリティーが CA 証明書を使用しない場合の接続エラーの可能性
- dsconf
# dsconf -D "cn=Directory Manager" ldaps://server.example.com:636 config get Error: {'desc': "Can't contact LDAP server", 'info': 'error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain)'}
- ldapsearch
# 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 で有効な暗号化プロトコルの表示
# dsconf -D "cn=Directory Manager" ldap://server.example.com security get ... sslversionmin: TLS1.2 sslversionmax: TLS1.3
sslVersionMin
パラメーターおよび sslVersionMax
パラメーターは、Directory Server が使用する暗号化プロトコルを制御します。sslVersionMin
のデフォルトは、使用するシステム全体の暗号化ポリシーによって異なります。
9.6. 最小 TLS 暗号化プロトコルバージョンの設定
sslVersionMin
パラメーターを自動的に設定します。以下の表は、システム全体の暗号化ポリシープロファイルを基に Directory Server が使用する TLS バージョン sslVersionMin
の概要を示しています。
プロファイル | 最小の TLS バージョン |
---|---|
DEFAULT | TLS 1.2 |
FUTURE | TLS 1.2 |
FIPS | TLS 1.2 |
LEGACY | TLS 1.0 |
sslVersionMin
は、暗号化ポリシープロファイルで定義された値よりも高い値に手動で設定できます。
# dsconf -D "cn=Directory Manager" ldap://server.example.com security set --tls-protocol-min="TLS1.3"
9.7. 最も大きい TLS 暗号化プロトコルバージョンの設定
# dsconf -D "cn=Directory Manager" ldap://server.example.com security set --tls-protocol-max="protocol_version"
sslVersionMin
未満の値に設定すると、Directory Server は sslVersionMax
を sslVersionMin
と同じ値に設定します。
sslVersionMax
パラメーターでサポートされる最強の暗号化プロトコルバージョンを常に使用するには、このパラメーターを設定しないでください。
9.8. ハードウェアセキュリティーモジュールの使用
key4.db
と cert9.db
を使用して、サーバーが使用する鍵と証明書を保存します。
9.9. 証明書ベースのクライアント認証の使用
userCertificate
属性に保存されている Distinguished Encoding Rules (DER) 形式の証明書と一致するように設定できます。
- 効率が改善されました。証明書データベースのパスワードに一度要求されたアプリケーションを使用し、その証明書を後続のバインドまたは認証操作に使用すると、バインド DN およびパスワードを継続的に提供するよりも効率的です。
- セキュリティーが改善されました。証明書ベースの認証は、証明書ベースの認証では公開鍵の暗号化が使用されるため、証明書以外のバインド操作よりも安全です。バインド認証情報はネットワーク全体で傍受することはできません。証明書やデバイスが失われた場合は、PIN なしで使用しないため、フィッシング攻撃などのサードパーティーの干渉の影響を受けません。
9.9.1. 証明書ベースの認証の設定
- 暗号化された接続を有効にします。詳細については、「TLS の有効化」 を参照してください。
- CA 証明書をインストールし、クライアントとサーバーの接続の信頼オプションを設定します。「CA 証明書のインストール」を参照してください。
- 必要に応じて、クライアントおよびサーバーの CT,, 信頼オプションが CA 証明書に設定されていることを確認します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com security ca-certificate get "Example-CA" Certificate Name: Example-CA Subject DN: CN=server.example.com,ST=Queensland,C=AU Issuer DN: CN=server.example.com,,ST=Queensland,C=AU Expires: 2021-05-09 10:57:54 Trust Flags: 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 Configuration, Command, and File Reference』のcertmap.conf
ファイルの説明を参照してください。- クライアント認証を有効にします。たとえば、クライアント認証を任意に設定するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com security set --tls-client-auth="allowed"
また、--tls-client-auth
パラメーターを required に設定して、クライアントが認証に使用する必要のある証明書を設定します。 /etc/dirsrv/slapd-instance_name/certmap.conf
ファイルで alias_name:VerifyCert on を設定して、認証証明書がユーザーのuserCertificate
属性に保存されている証明書と一致する必要がある場合は、その証明書をユーザーエントリーに追加します。「ユーザーへの証明書の追加」を参照してください。
9.9.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:< file:///root/example.der
9.9.3. バインドリクエストの EXTERNAL SASL メカニズムの強制
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-force-sasl-external=on Successfully replaced "nsslapd-force-sasl-external"
9.9.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.10. SASL Identity マッピングの設定
9.10.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.10.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.10.3. SASL Identity マッピングの設定
9.10.3.1. コマンドラインで SASL ID マッピングの設定
- ID マッピングスキームを追加します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com sasl create --cn "example_map" --nsSaslMapRegexString "\(.*\)" --nsSaslMapBaseDNTemplate "ou=People,dc=example,dc=com" --nsSaslMapFilterTemplate "(cn=\1)" --nsSaslMapPriority 50 Successfully created example_map
これは、ユーザーの共通名に一致し、フィルター cn=userId に基づいて、ベース ou=People,dc=example,dc=com を用いたサブツリー検索の結果にマッピングされます。 - インスタンスを再起動します。
# dsctl instance_name restart
9.10.3.2. Web コンソールを使用した SASL アイデンティティーマッピングの設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- SASL Settings & Mappings を選択します。メニューを開き、
- フォームを入力します。以下に例を示します。
9.10.4. SASL マッピングフォールバックの有効化
nsslapd-sasl-mapping-fallback
パラメーターを有効にすると、Directory Server が一致するすべてのマッピングを検証するように設定できます。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-sasl-mapping-fallback=on Successfully replaced "nsslapd-sasl-mapping-fallback"
9.10.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.11. SASL での Kerberos GSS-API の使用
9.11.1. Directory Server の SASL の認証メカニズム
- PLAIN。PLAIN は、簡単なパスワードベースの認証用にクリアテキストのパスワードを送信します。
- EXTERNAL。TLS を使用する EXTERNAL は、証明書ベースの認証を実行します。この方法では、強力な認証に公開鍵を使用します。
- CRAM-MD5。CRAM-MD5 は弱く、単純な challenge-response 認証メソッドです。セキュリティー層を確立しません。警告Red Hat では、セキュアでない CRAM-MD5 メカニズムを使用することは推奨されません。
- DIGEST-MD5。DIGEST-MD5 は LDAPv3 サーバーの弱い認証方法です。警告Red Hat では、セキュアでない DIGGEST-MD5 メカニズムを使用することは推奨されません。
- 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.11.2. Directory Server の Kerberos の概要
9.11.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.11.2.2. KDC サーバーおよびキータブの概要
ldap/server.example.com@EXAMPLE.COM
9.11.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.12. SASL メカニズムの設定
supportedSASLMechanisms
パラメーターに一覧表示されます。特定の SASL メカニズムを有効にするには、cn=config エントリーに nsslapd-allowed-sasl-mechanisms
属性を設定します。たとえば、GSSAPI および DIGEST-MD5 メカニズムのみを有効にするには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-allowed-sasl-mechanisms="GSSAPI, DIGEST-MD5" Successfully replaced "nsslapd-allowed-sasl-mechanisms"
nsslapd-allowed-sasl-mechanisms
パラメーターに記載されていない場合でも、このメカニズムは常に有効になります。
9.13. 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 に表示されます。
dn: uid=jsmith1234,ou=People,dc=example,dc=com ... uid:: Sf04P9nJWGU1qiW9JJCGRg==
10.1. キーの暗号化
10.2. 暗号化暗号
- AES (Advanced Encryption Standard)
- 3DES (Triple Data Encryption Standard)
10.3. 属性暗号化の設定
10.3.1. コマンドラインを使用した属性の暗号化の有効化
userRoot
データベースの telephoneNumber
属性を) Directory Server が保存するように設定するには、以下を行います。
- オプションで、既存の
telephoneNumber
属性を暗号化するには、データベースをエクスポートします。「暗号化したデータベースのエクスポート」を参照してください。 userRoot
データベースのtelephoneNumber
属性の AES 暗号化を有効にします。# dsconf -D "cn=Directory Manager" ldap://server.example.com backend attr-encrypt --add-attr telephoneNumber userRoot
- 既存の属性を暗号化するためにデータベースをエクスポートした場合は、データベースを再インポートします。「暗号化されたデータベースへの LDIF ファイルのインポート」を参照してください。
10.3.2. Web コンソールを使用した属性の暗号化の有効化
telephoneNumber
属性を) Directory Server が保存するように設定するには、以下を行います。
- オプションで、既存の
telephoneNumber
属性を暗号化するには、データベースをエクスポートします。「暗号化したデータベースのエクスポート」を参照してください。 - Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 接尾辞エントリーを選択します。
- Encrypted Attributes タブを開きます。
- 暗号化する属性の名前を入力します。
- 既存の属性を暗号化するためにデータベースをエクスポートした場合は、データベースを再インポートします。「暗号化されたデータベースへの LDIF ファイルのインポート」を参照してください。
10.3.3. コマンドラインを使用した属性の暗号化の無効化
userRoot
データベースに暗号化された telephoneNumber
属性) を設定するには、以下を実行します。
- 必要に応じて、既存の
telephoneNumber
属性を複号するには、データベースをエクスポートします。「暗号化したデータベースのエクスポート」を参照してください。 userRoot
データベースのtelephoneNumber
属性の暗号化を無効にします。# dsconf -D "cn=Directory Manager" ldap://server.example.com backend attr-encrypt --del-attr telephoneNumber userRoot
- 既存の属性を復号するためにデータベースをエクスポートした場合は、データベースを再インポートします。「暗号化されたデータベースへの LDIF ファイルのインポート」を参照してください。
10.3.4. Web コンソールを使用した属性の暗号化の無効化
telephoneNumber
属性を) Directory Server が保存するように設定するには、以下を行います。
- オプションで、既存の
telephoneNumber
属性を暗号化するには、データベースをエクスポートします。「暗号化したデータベースのエクスポート」を参照してください。 - Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 接尾辞エントリーを選択します。
- Encrypted Attributes タブを開きます。
telephoneNumber
属性の右側にある ボタンをクリックします。- 既存の属性を復号するためにデータベースをエクスポートした場合は、データベースを再インポートします。「暗号化されたデータベースへの LDIF ファイルのインポート」を参照してください。
10.3.5. 属性暗号化の有効化後の一般的な考慮事項
- 暗号化されていないデータは、サーバーのデータベースページプールのバッキングファイルで保持できます。このデータを削除するには、以下を実行します。
- インスタンスを停止します。
# dsctl instance_name stop
/var/lib/dirsrv/slapd-instance_name/db/guardian
ファイルを削除します。# rm /var/lib/dirsrv/slapd-instance_name/db/guardian
- インスタンスを起動します。
# dsctl instance_name start
- 暗号化を有効にし、データが正常にインポートされた後に、暗号化されていないデータで LDIF ファイルを削除します。
- 暗号化を有効にしたら、データの再インポート時に Directory Server は新しいデータベースを削除し、作成します。
- レプリケーションログファイルは暗号化されません。このデータを保護するには、暗号化されたディスクに保存します。
- サーバーのメモリー (RAM) のデータは暗号化されず、swap パーティションに一時的に保存できます。このデータを保護するには、暗号化された swap 領域を設定します。
10.4. 暗号化したデータベースのエクスポートおよびインポート
10.4.1. 暗号化したデータベースのエクスポート
-E
パラメーターを dsconf コマンドに渡します。
userRoot
データベースをエクスポートするには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend export -E userRoot
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend export -E -s "ou=People,dc=example,dc=com" userRoot
dsconf
を使用したデータのエクスポートに関する詳細は、「dsconf backend export コマンドを使用したデータベースのエクスポート」を参照してください。
10.4.2. 暗号化されたデータベースへの LDIF ファイルのインポート
- Directory Server インスタンスを停止します。
# dsctl instance_name stop
- 前回のエクスポートと今回のインポートとの間で証明書データベースを置き換えた場合は、
/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 ファイルをインポートします。たとえば、
/tmp/example.ldif
をuserRoot
データベースにインポートするには、以下を行います。# dsctl instance_name ldif2db --encrypted userRoot /tmp/example.ldif
--encrypted
パラメーターを使用すると、スクリプトで属性を暗号化して、インポート中に暗号化を設定できます。 - インスタンスを起動します。
# dsctl instance_name start
10.5. 属性暗号化に使用される TLS 証明書の更新
- 復号化された属性でデータベースをエクスポートします。「暗号化したデータベースのエクスポート」を参照してください。
- Certificate Signing Request (CSR) を新規作成します。「証明書署名要求の作成」を参照してください。
- 新しい証明書をインストールします。「サーバー証明書のインストール」を参照してください。
- Directory Server インスタンスを停止します。
# dsctl instance_name stop
/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 ファイルのインポート」を参照してください。
- インスタンスを起動します。
# dsctl instance_name start
第11章 FIPS モードサポートの管理
FIPS モードサポートの有効化
- 必要に応じて、Red Hat Enterprise Linux で FIPS モードを有効にします。詳細については、『Red Hat Enterprise Linux 8 セキュリティー強化』 ドキュメントの対応するセクションを参照してください。
- ネットワークセキュリティーサービス (NSS) データベースの FIPS モードを有効にします。
# modutil -dbdir /etc/dirsrv/slapd-instance_name/ -fips true
- Directory Server インスタンスを再起動します。
# dsctl instance_name restart
FIPS モードサポートの無効化
- ネットワークセキュリティーサービス (NSS) データベースの FIPS モードを無効にします。
# modutil -dbdir /etc/dirsrv/slapd-instance_name/ -fips false
- Directory Server インスタンスを再起動します。
# dsctl instance_name restart
第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
objectclasses
属性です。objectclasses
属性の形式は以下のとおりです。
objectclasses: ( definition )
- OID (通常はドット区切り番号)
- NAME 名前 形式の一意の名前
- DESC 説明 形式の説明
- SUP object_class の形式で、このオブジェクトクラスの上位または親のオブジェクトクラス。関連する親がない場合は、SUP top を使用してください。
- AUXILIARY という単語で、オブジェクトクラスを適用するエントリーのタイプを指定します。AUXILIARY は、任意のエントリーに適用できることを意味します。
- MUST の後に続く必要な属性のリスト。複数の属性を含めるには、グループを括弧で囲み、ドル記号 ($) で属性を区切ります。
- MAY の後に続く許可される属性のリスト。複数の属性を含めるには、グループを括弧で囲み、ドル記号 ($) で属性を区切ります。
/etc/dirsrv/slapd-instance_name/schema/99user.ldif
に保存されます。
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.3.1. Directory Server 属性の構文
12.1.4. スキーマの拡張
99user.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. オブジェクトクラスの作成
12.3.1. コマンドラインを使用したオブジェクトクラスの作成
ldapmodify
ユーティリティーを使用して、新しいオブジェクトクラスエントリーを作成します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com schema objectclasses add examplePerson --oid="2.16.840.1133730.2.123" --desc="Example Person Object Class" --sup="inetOrgPerson" --kind="AUXILIARY" --must="cn" --may exampleDateOfBirth examplePreferredOS
12.3.2. Web コンソールを使用したオブジェクトクラスの作成
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 親オブジェクトクラスを選択します。
- オブジェクトクラス名を入力し、オプションでオブジェクト識別子 (OID) を設定します。
- オブジェクトクラスの種類を選択します。
- 対応するフィールドに必須属性および許可属性を入力します。
12.4. オブジェクトクラスの更新
12.4.1. コマンドラインを使用したオブジェクトクラスの更新
dsconf
ユーティリティーを使用して、オブジェクトクラスエントリーを更新します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com schema objectclasses replace examplePerson --oid="2.16.840.1133730.2.123" --desc="Example Person Object Class" --sup="inetOrgPerson" --kind="AUXILIARY" --must="cn" --may exampleDisplayName exampleAlias
12.4.2. Web コンソールを使用したオブジェクトクラスの更新
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 編集するオブジェクトクラスエントリーの右側にあるボタンをクリックします。
- パラメーターを更新します。
12.5. オブジェクトクラスの削除
12.5.1. コマンドラインを使用したオブジェクトクラスの削除
ldapmodify
ユーティリティーを使用してオブジェクトクラスエントリーを削除します。たとえば、examplePerson
オブジェクトクラスを削除するには、以下を実行します。
- 不要な属性を使用するエントリーから、その属性を削除します。詳細については、「属性の削除」 を参照してください。
- オブジェクトクラスエントリーを削除します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com schema objectclasses delete examplePerson
12.5.2. Web コンソールを使用したオブジェクトクラスの削除
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 削除するオブジェクトクラスエントリーの横にあるボタンをクリックします。
12.6. 属性の作成
12.6.1. コマンドラインで属性の作成
ldapmodify
ユーティリティーを使用して新しい属性を作成します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com schema attributetypes add dateofbirth --desc="For employee birthdays" --syntax="1.3.6.1.4.1.1466.115.121.1.15" --single-value --x-origin="Example defined"
12.6.2. Web コンソールを使用した属性の作成
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- パラメーターを入力します。
12.7. 属性の更新
12.7.1. コマンドラインを使用した属性の更新
dsconf
ユーティリティーを使用して、属性エントリーを更新します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com schema attributetypes replace dateofbirth --desc="Employee birthday" --syntax="1.3.6.1.4.1.1466.115.121.1.15" --single-value --x-origin="Example defined"
12.7.2. Web コンソールを使用した属性の更新
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 編集する属性の横にあるボタンをクリックします。
- パラメーターを更新します。
12.8. 属性の削除
12.8.1. コマンドラインを使用した属性の削除
ldapmodify
ユーティリティーを使用して属性を削除します。以下に例を示します。
- 不要な属性を使用するエントリーから、その属性を削除します。
- 属性を削除します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com schema attributetypes remove dateofbirth
12.8.2. Web コンソールを使用した属性の削除
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 削除する属性の横にあるボタンをクリックします。
12.9. カスタムスキーマファイルの作成
- 最初の行は 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.10. スキーマの動的再読み込み
- dsconf schema reload コマンド。「dsconf schema reload コマンドを使用したスキーマの動的再読み込み」を参照してください。
- cn=tasks エントリー。「cn=tasks エントリーを使用したスキーマの動的再読み込み」を参照してください。
/usr/share/dirsrv/schema/
ディレクトリーに保存されたすべてのスキーマファイルを再読み込みします。
12.10.1. dsconf schema reload コマンドを使用したスキーマの動的再読み込み
# dsconf -D "cn=Directory Manager" ldap://server.example.com schema reload Attempting to add task entry... This will fail if Schema Reload plug-in is not enabled. Successfully added task entry cn=schema_reload_2018-08-28T09:45:48.027962,cn=schema reload task,cn=tasks,cn=config To verify that the schema reload operation was successful, please check the error logs
nsslapd-schemadir
パラメーターに設定したディレクトリーに保存されているスキーマファイルを再読み込みします。必要に応じて、-d directory
オプションをコマンドに指定して、別のディレクトリーに保存されているスキーマを再読み込みします。
12.10.2. cn=tasks エントリーを使用したスキーマの動的再読み込み
nsslapd-schemadir
パラメーターに設定したディレクトリーに保存されているスキーマファイルを再読み込みします。たとえば、このパラメーターで設定したディレクトリーに保存されたスキーマファイルを再読み込みするには、次のコマンドを実行します。
# ldapadd -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 objectclass: extensibleObject cn: cn=example_schema_reload
schemadir
パラメーターを指定して、別のディレクトリーに保存されているスキーマを再読み込みします。以下に例を示します。
# ldapadd -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 objectclass: extensibleObject cn: cn=example_schema_reload schemadir: /example/schema/
12.10.3. レプリケーショントポロジーでのスキーマの再読み込み
- レプリケーションを停止します。「レプリケーションの無効化および再有効化」を参照してください。
- 新しいスキーマファイルをコピーし、各サプライヤーおよびレプリカサーバーに対してスキーマ再読み込みタスクを実行します。参照:
- レプリケーションを再起動します。「レプリケーションの無効化および再有効化」を参照してください。
12.10.4. スキーマの再読み込みエラー
[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.11. スキーマチェックのオンとオフを切り替える
- 使用するオブジェクトクラスおよび属性はディレクトリースキーマで定義されます。
- オブジェクトクラスに必要な属性はエントリーに含まれます。
- オブジェクトクラスで使用できる属性のみがエントリーに含まれます。
12.11.1. コマンドラインでスキーマチェックのオンおよびオフを切り替え
nsslapd-schemacheck
パラメーターの値を設定します。スキーマの確認を無効にするには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-schemacheck=off Successfully replaced "nsslapd-schemacheck"
nsslapd-schemacheck
パラメーターの詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 で、パラメーターの説明を参照してください。
12.11.2. Web コンソールを使用したスキーマチェックのオンおよびオフの切り替え
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Advanced Settings タブを開きます。
- スキーマチェックを有効にするには、Enable Schema Checking チェックボックスを選択します。この機能を無効にするには、チェックボックスの選択を解除します。
12.12. 構文の検証の使用
telephoneNumber
属性に、実際にその値に有効な電話番号が指定されていることを確認します。
12.12.1. 構文の検証の概要
12.12.2. 構文の検証およびその他の Directory Server 操作
データベース暗号化
通常の LDAP 操作では、値がデータベースに書き込まれる直前に属性は暗号化されます。これは、属性構文の検証 後に 暗号化が実行されることを意味します。
-E
フラグを使用して行うことが強く推奨されます。これにより、インポート操作で構文の検証が問題になる可能性もあります。ただし、-E
フラグを使用せずに暗号化されたデータベースをエクスポートする場合は (サポートされていない)、暗号化された値で LDIF が作成されます。この LDIF をインポートすると、暗号化された属性を検証できず、警告がログに記録され、インポートされたエントリーで属性検証はスキップされます。
同期
Windows Active Directory エントリーと Red Hat Directory Server エントリーでは、属性の許容構文または強制構文に違いがある場合があります。この場合、構文の検証により Directory Server エントリーの RFC 標準が強制されるため、Active Directory の値を適切に同期できませんでした。
レプリケーション
Directory Server 11 インスタンスがコンシューマーに変更を複製するサプライヤーである場合は、構文検証の使用に問題はありません。ただし、レプリケーションのサプライヤーが古いバージョンの Directory Server であったり、構文の検証が無効になっていたりする場合は、Directory Server 11 コンシューマーは、サプライヤーが許可する属性値を拒否する可能性があるため、構文の検証をコンシューマーで使用しないでください。
12.12.2.1. コマンドラインを使用した構文検証のオンおよびオフを切り替え
nsslapd-syntaxcheck
パラメーターの値を設定します。構文の検証を無効にするには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-syntaxcheck=off Successfully replaced "nsslapd-syntaxcheck"
nsslapd-syntaxcheck
パラメーターの詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 で、パラメーターの説明を参照してください。
12.12.2.2. Web コンソールを使用した構文検証のオンおよびオフの切り替え
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Advanced Settings タブを開きます。
- 属性構文の確認を有効にするには、Enable Attribute Syntax Checking チェックボックスを選択します。この機能を無効にするには、チェックボックスの選択を解除します。
12.12.3. DN の厳格な構文検証の有効化または無効化
12.12.3.1. コマンドラインを使用した DN の厳格な構文の検証の有効化または無効化
nsslapd-dn-validate-strict
パラメーターの値を設定します。たとえば、DN の厳格な構文検証を無効にするには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-dn-validate-strict=off Successfully replaced "nsslapd-dn-validate-strict"
nsslapd-syntaxcheck
パラメーターの詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 で、パラメーターの説明を参照してください。
12.12.3.2. Web コンソールを使用した DN の厳格な構文検証の有効化または無効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Advanced Settings タブを開きます。
- 機能を有効または無効にするかどうかに応じて、Strict DN Syntax Validation オプションを選択または選択解除します。
12.12.4. 構文検証ロギングの有効化
nsslapd-syntaxlogging
属性は、構文違反のエラーロギングを有効にします。
nsslapd-syntaxlogging
パラメーターおよび nsslapd-syntaxcheck
パラメーターの両方が有効な場合には、無効な属性の変更が拒否され、メッセージがログに書き込まれます。nsslapd-syntaxlogging
が有効、nsslapd-syntaxcheck
が無効の場合、操作は成功できますが、警告メッセージがエラーログに書き込まれます。
12.12.4.1. コマンドラインを使用した構文検証ロギングの有効化
nsslapd-syntaxlogging
パラメーターの値を on に設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-syntaxlogging=on Successfully replaced "nsslapd-syntaxlogging"
nsslapd-syntaxlogging
パラメーターの詳細は、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 で、パラメーターの説明を参照してください。
12.12.4.2. Web コンソールを使用した構文検証ロギングの有効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Advanced Settings タブを開きます。
- Enable Attribute Syntax Logging オプションを選択します。
12.12.5. 既存の属性値の構文の検証
nsslapd-syntaxcheck
パラメーターで構文の検証が無効になっている場合。詳細については、「構文の検証およびその他の Directory Server 操作」 を参照してください。重要Red Hat は、構文の検証を無効にしないことを推奨します。- 構文検証なしまたは無効化されたサーバーからデータを移行する場合。
/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.
注記構文検証タスクは、構文違反のみを識別します。誤った値を手動で修正する必要があります。
12.12.5.1. dsconf スキーマの validate-syntax コマンドを使用した構文検証タスクの作成
# dsconf -D "cn=Directory Manager" ldap://server.example.com schema validate-syntax -f '(objectclass=inetorgperson)' ou=People,dc=example,dc=com
12.12.5.2. cn=tasks エントリーを使用した構文検証タスクの作成
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=example_syntax_validate,cn=syntax validate,cn=tasks,cn=config objectclass: extensibleObject cn: cn=example_syntax_validate basedn: ou=People,dc=example,dc=com filter: (objectclass=inetorgperson)
第13章 インデックスの管理
13.1. インデックスの概要
13.1.1. インデックスタイプの概要
cn.db
ファイルに含まれます。
- Presence index (pres) には、特定の属性を含むエントリーのリストが含まれており、検索には非常に便利です。たとえば、アクセス制御情報を含むエントリーを簡単に検証できます。プレゼンスインデックスを含む
aci.db
ファイルを生成すると、ACI=* の検索を効率的に実行して、サーバーのアクセス制御リストを生成します。 - Equality index (eq) により、特定の属性値を含むエントリーの検索が改善されます。たとえば、
cn
属性の等価インデックスを使用すると、ユーザーは cn=Babs Jensen の検索をより効率的に実行できます。 - Approximate index (approx) は、効率的な近似検索や sounds-like 検索に使われます。たとえば、エントリーには属性値 cn=Firstname M Lastname を含めることができます。概算検索では、この値を cn~=Firstname Lastname、cn~=Firstname、または cn~=Lastname に対する検索に対して返します。同様に、l~=San Fransisco (スペルミスに注意) を検索すると、l=San Francisco を含むエントリーが返されます。
- Substring index (sub) は、維持するコストのかかるインデックスですが、エントリー内の部分文字列に対して効率的な検索が可能になります。部分文字列のインデックスは、各エントリーの最小 3 文字に制限されます。たとえば、cn=*derson の形式で検索すると、Bill Anderson、Jill Henderson、または Steve Sanderson といった文字列が含まれる共通名と一致します。同様に、telephoneNumber= *555* の検索は、555 が含まれる電話番号を持つディレクトリー内の全エントリーを返します。
- 国際インデックス は、国際ディレクトリー内の情報の検索を迅速化します。国際インデックスの作成プロセスは、通常のインデックスを作成するプロセスと似ています。ただし、オブジェクト識別子 (OID) をインデックス化する属性に関連付けることで 一致するルール を適用する点が異なります。サポートされるロケールおよび関連付けられた OID が付録D 国際化にリスト表示されています。追加のマッチングルールを受け入れるように Directory Server を設定する必要がある場合は、Red Hat コンサルティングにお問い合わせください。
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)'
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend index list database_name
13.1.3. 検索アルゴリズムの概要
cn
、共通名、属性など) 属性の一覧と、インデックス化された属性値が含まれるエントリーの ID の一覧が含まれます。
- LDAP クライアントアプリケーションは、検索要求をディレクトリーに送信します。
- ディレクトリーは、受信要求を調べて、指定したベース DN が、1 つ以上のデータベースまたはデータベースリンクに含まれる接尾辞と一致することを確認します。
- 一致する場合には、ディレクトリーはリクエストを処理します。
- 一致しない場合、ディレクトリーは接尾辞と一致しないことを示すエラーをクライアントに返します。cn=config 下の nsslapd-referral 属性で参照を指定している場合、ディレクトリーは、クライアントがリクエストを購入できる LDAP URL も返します。
- Directory Server は、どのインデックスが適用されるかを確認するための検索フィルターを調べ、フィルターを満たす各インデックスからエントリー ID のリストを読み込もうとします。ID リストは、フィルターで使用されている AND または OR に参加するかによって組み合わせられます。各フィルターコンポーネントは個別に処理され、ID リストを返します。
- エントリー ID の一覧が設定された ID リストのスキャン制限よりも大きい場合や、属性にインデックスが定義されていない場合、Directory Server は、この filtercomponent の結果を allids に設定します。個々の検索コンポーネントの結果に論理操作を適用すると、その一覧は引き続き ALLIDs のままになる場合は、データベース内のすべてのエントリーを検索します。これは インデックスのない 検索です。
- 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
(通称) およびsn
(姓) 属性の等価、近似、および部分文字列インデックス。- 電話番号属性の等価および部分文字列のインデックス。
- 説明属性の部分文字列インデックス。
- 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. コマンドラインを使用したインデックスの作成
- デフォルトインデックスのいずれかになる新しいインデックスを作成するには、新しいインデックス属性を 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 の下にエントリーを作成しないでください。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.2.2. Web コンソールを使用したインデックスの作成
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 接尾辞エントリーを選択します。
- Indexes タブを開きます。
- インデックスの属性、インデックスのタイプ、および任意でマッチングルールを選択します。
13.3. 既存のデータベースへの新規インデックスの作成
13.3.1. インスタンスの実行中にインデックスの作成
13.3.1.1. dsconf backend index reindex コマンドを使用したインデックスの作成
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend index reindex database_name
13.3.1.2. cn=tasks エントリーを使用したインデックスの作成
ldapadd
ユーティリティーを使用して、新しいインデックスタスクを追加します。たとえば、userRoot
データベースに cn
属性の presence インデックスを作成するタスクを追加するには、以下を実行します。
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=example_presence_index,cn=index,cn=tasks,cn=config objectclass: top objectclass: extensibleObject cn: example presence index nsInstance: userRoot nsIndexAttribute: "cn:pres"
13.3.2. インスタンスのオフライン時におけるインデックスの作成
- インスタンスをシャットダウンします。
# dsctl instance_name stop
- インデックスを再作成します。
# dsctl instance_name db2index userRoot [13/Aug/2019:15:25:37.277426483 +0200] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [13/Aug/2019:15:25:37.289257996 +0200] - INFO - check_and_set_import_cache - pagesize: 4096, available bytes 1704378368, process usage 22212608 [13/Aug/2019:15:25:37.291738104 +0200] - INFO - check_and_set_import_cache - Import allocates 665772KB import cache. ... db2index successful
- インスタンスを起動します。
# dsctl instance_name start
13.4. 仮想リストビューコントロールを使用して、大規模な検索結果の連続したサブセットを要求する
13.4.1. ldapsearch コマンドでの VLV コントロールの動作
ldapsearch
ユーティリティーを使用して部分的な結果のみを要求できます。
sss
(サーバー側の並べ替え) と vlv
検索拡張機能の両方に -E
オプションを指定します。
# ldapsearch ... -E 'sss=attribute_list' -E 'vlv=query_options'
sss
検索拡張機能の構文は次のとおりです。
[!]sss=[-]<attr[:OID]>[/[-]<attr[:OID]>...]
vlv
検索拡張機能の構文は次のとおりです。
[!]vlv=<before>/<after>(/<offset>/<count>|:<value>)
- before は、対象のエントリーの前に返されるエントリーの数を設定します。
- after は、対象のエントリーの後に返されるエントリーの数を設定します。
- index、count、および value は、ターゲットエントリーの決定に役立ちます。value を設定すると、ターゲットエントリーは、その値で始まる最初の並べ替え属性を持つ最初のエントリーになります。それ以外の場合は、count を 0 に設定し、ターゲットエントリーは index 値 (1 から開始) によって決定されます。count 値が 0 より大きい場合、ターゲットエントリーは ratio index * number of entries / count によって決定されます。
例13.1 VLV 検索拡張機能を使用した ldapsearch コマンドの出力
cn
属性でソートし、70 番目のエントリーの uid
属性をオフセットの前の 1 つのエントリーと後の 2 つのエントリーとともに返します。
# ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "ou=People,dc=example,dc=com" -s one -x -E 'sss=cn' -E 'vlv=1/2/70/0' uid # user069, People, example.com dn: uid=user069,ou=People,dc=example,dc=com uid: user069 # user070, People, example.com dn: uid=user070,ou=People,dc=example,dc=com uid: user070 # user071, People, example.com dn: uid=user071,ou=People,dc=example,dc=com uid: user071 # user072, People, example.com dn: uid=user072,ou=People,dc=example,dc=com uid: user072 # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.474 false MIQAAAADCgEA sortResult: (0) Success control: 2.16.840.1.113730.3.4.10 false MIQAAAALAgFGAgMAnaQKAQA= vlvResult: pos=70 count=40356 context= (0) Success # numResponses: 5 # numEntries: 4 Press [before/after(/offset/count|:value)] Enter for the next window.
-E
パラメーターの説明を参照してください。
13.4.2. 認証されていないユーザーが VLV コントロールを使用できるようにする
手順
- oid=2.16.840.1.113730.3.4.9,cn=features,cn=config の ACI を更新します。
# ldapmodify -D "cn=Directory Manager" -W -H ldap://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";)
検証
- バインドユーザーを指定せずに、VLV コントロールでクエリーを実行します。
# ldapsearch -H ldap://server.example.com -b "ou=People,dc=example,dc=com" -s one -x -E 'sss=cn' -E 'vlv=1/2/70/0' uid
このコマンドでは、サーバーが匿名バインドを許可する必要があります。コマンドが成功してもエントリーが返されない場合は、バインドユーザーを使用してクエリーを再度実行し、認証の使用時にクエリーが機能することを確認します。
13.4.3. コマンドラインを使用して VLV インデックスを作成し、VLV クエリーの速度を向上させる
mail
属性を持ち、person に設定された objectClass
属性があります。
前提条件
- クライアントアプリケーションは VLV コントロールを使用している。
- クライアントアプリケーションでは、大規模な検索結果の連続したサブセットに対してクエリーを実行する必要がある。
- ディレクトリーには多数のエントリーが含まれている。
手順
- VLV 検索エントリーを作成します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend vlv-index add-search --name "VLV People" --search-base "ou=People,dc=example,dc=com" --search-filter "(&(objectClass=person)(mail=*))" --search-scope 2 userRoot
コマンドは、以下のオプションを使用します。--name
は検索エントリーの名前を設定します。これは任意の名前にすることができます。--search-base
VLV インデックスのベース DN を設定します。Directory Server は、このエントリーに VLV インデックスを作成します。--search-scope
は VLV インデックス内のエントリーに対して実行する検索の範囲を設定します。このオプションは、0 (ベース検索)、1 (1 レベル検索)、または 2 (サブツリー検索) に設定できます。--search-filter
は VLV インデックスの作成時に Directory Server が適用するフィルターを設定します。このフィルターに一致するエントリーのみがインデックスの一部になります。userRoot
は、エントリーを作成するデータベースの名前です。
- インデックスエントリーを作成します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend vlv-index add-index --index-name "VLV People - cn sn" --parent-name "VLV People" --sort "cn sn" --index-it dc=example,dc=com
コマンドは、以下のオプションを使用します。--index-name
は、インデックスエントリーの名前を設定します。これは任意の名前にすることができます。--parent-name
は、VLV 検索エントリーの名前を設定し、前の手順で設定した名前と一致する必要があります。--sort
は属性名とソート順序を設定します。属性をスペースで区切ります。--index-it
は、エントリーの作成後に、Directory Server がインデックスタスクを自動的に開始します。dc=example,dc=com
は、エントリーを作成するデータベースの接尾辞です。
検証
/var/log/dirsrv/slapd-instance_name/errors
ファイルで VLV インデックスが正常に作成されたことを確認します。[26/Nov/2021:11:32:59.001988040 +0100] - INFO - bdb_db2index - userroot: Indexing VLV: VLV People - cn sn [26/Nov/2021:11:32:59.507092414 +0100] - INFO - bdb_db2index - userroot: Indexed 1000 entries (2%). ... [26/Nov/2021:11:33:21.450916820 +0100] - INFO - bdb_db2index - userroot: Indexed 40000 entries (98%). [26/Nov/2021:11:33:21.671564324 +0100] - INFO - bdb_db2index - userroot: Finished indexing.
- ldapsearch コマンドで VLV コントロールを使用して、ディレクトリーから特定のレコードのみをクエリーします。
# ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "ou=People,dc=example,dc=com" -s one -x -E 'sss=cn' -E 'vlv=1/2/70/0' uid # user069, People, example.com dn: uid=user069,ou=People,dc=example,dc=com cn: user069 # user070, People, example.com dn: uid=user070,ou=People,dc=example,dc=com cn: user070 # user071, People, example.com dn: uid=user071,ou=People,dc=example,dc=com cn: user071 # user072, People, example.com dn: uid=user072,ou=People,dc=example,dc=com cn: user072
この例では、ou=People,dc=example,dc=com にuid=user001
から少なくともuid=user072
まで連続して名前が付けられたエントリーがあることを前提としています。
-E
パラメーターの説明を参照してください。
13.4.4. Web コンソールを使用して VLV インデックスを作成し、VLV クエリーの速度を向上させる
mail
属性を持ち、person に設定された objectClass
属性があります。
前提条件
- クライアントアプリケーションは VLV コントロールを使用している。
- クライアントアプリケーションでは、大規模な検索結果の連続したサブセットに対してクエリーを実行する必要がある。
- ディレクトリーには多数のエントリーが含まれている。
手順
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
図13.1 Web コンソールを使用した VLV インデックスの作成
- 属性名を入力し、をクリックします。
- Index VLV on Save を選択します。
検証
[26/Nov/2021:11:32:59.001988040 +0100] - INFO - bdb_db2index - userroot: Indexing VLV: VLV People - cn sn [26/Nov/2021:11:32:59.507092414 +0100] - INFO - bdb_db2index - userroot: Indexed 1000 entries (2%). ... [26/Nov/2021:11:33:21.450916820 +0100] - INFO - bdb_db2index - userroot: Indexed 40000 entries (98%). [26/Nov/2021:11:33:21.671564324 +0100] - INFO - bdb_db2index - userroot: Finished indexing.
- ldapsearch コマンドで VLV コントロールを使用して、ディレクトリーから特定のレコードのみをクエリーします。
# ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -b "ou=People,dc=example,dc=com" -s one -x -E 'sss=cn' -E 'vlv=1/2/70/0' uid # user069, People, example.com dn: uid=user069,ou=People,dc=example,dc=com cn: user069 # user070, People, example.com dn: uid=user070,ou=People,dc=example,dc=com cn: user070 # user071, People, example.com dn: uid=user071,ou=People,dc=example,dc=com cn: user071 # user072, People, example.com dn: uid=user072,ou=People,dc=example,dc=com cn: user072
この例では、ou=People,dc=example,dc=com にuid=user001
から少なくともuid=user072
まで連続して名前が付けられたエントリーがあることを前提としています。
-E
パラメーターの説明を参照してください。
13.5. インデックスのソート順序の変更
13.5.1. コマンドラインを使用したソート順序の変更
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
属性は、検索文字列の途中でワイルドカードが使用される、インデックス化された検索に必要な文字数を設定します。以下に例を示します。*abc*
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
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
エントリーを削除します。詳細については、「インデックスからの属性の削除」 を参照してください。
13.7.2. インデックスからの属性の削除
13.7.2.1. コマンドラインを使用したインデックスから属性の削除
- 削除する属性が
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
エントリーを削除した後に、Directory Server は属性のインデックスを維持しません。 - 属性インデックスを再作成します。「既存のデータベースへの新規インデックスの作成」を参照してください。
13.7.2.2. Web コンソールを使用したインデックスからの属性の削除
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 接尾辞エントリーを選択します。
- Indexes タブを開きます。
- インデックスを削除する属性の横にある Delete Index を選択します。ボタンをクリックして、
13.7.3. コマンドラインを使用したインデックスタイプの削除
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
インデックスエントリーを削除した後に、Directory Server は属性の部分文字列インデックスを維持しなくなります。 - 属性インデックスを再作成します。「既存のデータベースへの新規インデックスの作成」を参照してください。
13.7.4. 参照インデックスの削除
13.7.4.1. コマンドラインを使用したインデックスの削除
- cn=index,cn=database_name,cn=ldbm database,cn=plugins,cn=config エントリーから、参照しているインデックスエントリーを削除します。以下に例を示します。
# 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"
2 つの参照インデックスエントリーを削除すると、Directory Server ではこれらのインデックス化は維持されなくなります。 - 属性インデックスを再作成します。「既存のデータベースへの新規インデックスの作成」を参照してください。
第14章 ディレクトリーエントリーの検索
14.1. コマンドラインを使用したディレクトリーエントリーの検索
- 1 つのエントリー (
-s base
) - エントリーの直接のサブエントリー (
-s one
) - ツリー全体またはサブツリー全体 (
-s sub
)
14.1.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.1.2. 一般的に使用される ldapsearch オプション
-x
引数を使用して SASL を無効にし、他の接続方法を許可します。
オプション | 説明 | |||
---|---|---|---|---|
-b | 検索の開始点を指定します。ここで指定する値は、現在データベースに存在する識別名である必要があります。これは、LDAP_BASEDN 環境変数がベース DN に設定されている場合は任意です。このオプションで指定する値は、単一引用符または二重引用符で指定する必要があります。以下に例を示します。
-b "cn=user,ou=Product Development,dc=example,dc=com"ルート DSE エントリーを検索するには、ここで -b "" などの空の文字列を指定します。 | |||
-D | サーバーへの認証に使用する識別名を指定します。これは、サーバーによって匿名アクセスに対応している場合はオプションです。指定している場合、この値は Directory Server が認識する DN である必要があります。また、エントリーを検索する権限も必要です、例: -D "uid=user_name,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 パラメーターを上書きします。 |
14.1.3. 特殊文字の使用
-D "cn=user_name,ou=Product Development,dc=example,dc=com"
14.2. Web コンソールを使用したエントリーの検索
uid=user_name,ou=People,dc=example,dc=com
の場合、このエントリーに dc:example
属性が存在する場合にのみエントリーに一致する dc=example
を検索します。
前提条件
- ディレクトリーサーバー Web コンソールにログインしている。
- root 権限がある。
手順
- Web コンソールで、→ に移動します。
- 検索基準を展開して選択し、エントリーをフィルタリングします。
表14.1 デフォルトのインデックス属性 検索パラメーター 説明 検索ベース 検索の開始点を指定します。現在データベースに存在する識別名 (DN) です。注記Search タブが開き、定義済みの検索ベースが表示されます。または でエントリーの詳細を開いたら、 をクリックし、 を選択します。検索範囲 Subtree
を選択すると、検索ベースから開始して子エントリーすべてを含むサブツリー全体のエントリーを検索できます。One Level
を選択すると、検索ベースから開始して第 1 レベルの子エントリーのみを含むエントリーを検索できます。Base
を選択すると、検索ベースとして指定されたエントリーでのみ属性値を検索します。サイズ制限 検索操作で返されるエントリーの最大数を設定します。時間制限 検索エンジンがエントリーを検索する時間を秒単位で設定します。ロックを表示 スイッチをオンに切り替えて、見つかったエントリーのロックステータスを確認します。検索属性 検索にかかわる属性を選択します。事前定義された属性から選択するか、カスタム属性を追加できます。 - 検索テキストフィールドに属性値を入力し、キーを押します。注記ディレクトリーサーバーは、すべての検索要求をアクセスログファイルに記録します。このファイルは、→ → で表示できます。
- オプション: 検索をさらに絞り込むには、タブの検索フィルターを使用して、エントリーを検索します。
14.3. LDAP 検索フィルター
attribute operator value
buildingname>=alpha
buildingname
が属性、>= が演算子、および alpha が値となります。フィルターは、異なる属性をブール値演算子とともに使用するように定義することもできます。
businessCategory
属性の値が Example*Net product line の社員をすべて検索するには、検索フィルターに以下の値を入力します。
Example\5c2a*Net product line
dc
属性が存在し example に設定していなければ、そのエントリーと一致しません。
14.3.1. 検索フィルターの属性の使用
manager
属性を持つすべてのエントリーを返します。
"(manager=*)"
"(cn=example)"
cn: example cn;lang-fr: example
"(description=*X.500*)" "(sn=*nderson)" "(givenname=car*)"
14.3.2. 検索フィルターでの演算子の使用
"(employeeNumber>=500)" "(sn~=suret)" "(salary<=150000)"
検索タイプ | 演算子 | 説明 |
---|---|---|
等号 | = | 指定された値と完全に一致する属性値が含まれるエントリーを返します。たとえば、cn=example です。 |
部分文字列 | =string* string | 指定の部分文字列が含まれる属性が含まれるエントリーを返します。たとえば、cn=exa*l です。アスタリスク (*) はゼロ (0) 以上の文字を示します。 |
以上 | >= | 指定された値以上の属性を含むエントリーを返します。たとえば、uidNumber >= 5000 です。 |
より小か等しい | <= | 指定された値以下の属性が含まれるエントリーを返します。たとえば、uidNumber <= 5000 です。 |
存在 | =* | 指定属性の 1 つ以上の値が含まれるエントリーを返します。たとえば、cn=* です。 |
概算値 | ~= | 指定した属性を含むエントリーを、検索フィルターで指定された値とほぼ等しい値で返します。たとえば、l~=san fransico は l=san francisco を返すことができます。 |
14.3.3. 複合検索フィルターの使用
(Boolean-operator(filter)(filter)(filter)...)
(!(objectClass=person))
(Boolean-operator(filter)((Boolean-operator(filter)(filter)))
description
属性に部分文字列 X.500 が含まれていないすべてのエントリーを返します。
(&(ou=Marketing)(!(description=*X.500*)))
manager
として設定されているエントリーを返すように拡張できます。
(&(ou=Marketing)(!(description=*X.500*))(|(manager=cn=example,ou=Marketing,dc=example,dc=com)(manager=cn=demo,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.3.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.4. 一般的な ldapsearch の例
- 検索は、ディレクトリー内のすべてのエントリーに対するものです。
- このディレクトリーは、検索および読み取りの匿名アクセスをサポートするように設定されます。つまり、検索を実行するためにバインド情報を提供する必要はありません。匿名アクセスの詳細は、「匿名アクセスの付与」を参照してください。
- サーバーは、server.example.com という名前のホストにあります。
- サーバーはポート番号 389 を使用します。これはデフォルトのポートであるため、ポート番号は検索リクエストで送信する必要がありません。
- TLS は、ポート 636 のサーバー (デフォルトの LDAPS ポート番号) に対して有効になります。
- すべてのデータが格納される接尾辞は dc=example,dc=com です。
14.4.1. すべてのエントリーの返信
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x "(objectclass=*)"
objectclass
属性は常にインデックス化されるため、すべてのエントリーを返すための便利な検索フィルターになります。
14.4.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.4.3. ルート DSE エントリーの検索
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x -b "" -s base "objectclass=*"
14.4.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.4.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.4.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.4.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.4.8. ファイルを使用した検索フィルターの指定
sn=example givenname=user
givenname
が user に設定されたすべてのエントリーを検索します。両方の検索条件に一致するエントリーが見つかると、エントリーは 2 回返されます。
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.4.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.4.10. クライアント証明書の Directory Server へのバインド
14.4.11. 言語マッチングルールでの検索
attr:matchingRule:=value
departmentNumber:2.16.840.1.113730.3.3.2.46.1:=>= N4709
14.4.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.5. リソース制限による検索パフォーマンスの改善
- ルックスルー制限。検索操作で確認できるエントリーの数を指定します。
- サイズ制限。検索操作にしたがって、サーバーがクライアントアプリケーションに返すエントリーの最大数を指定します。
- 時間制限。サーバーが検索操作の処理に費やす最大時間を指定します。
- アイドルタイムアウト。接続が切断される前に、サーバーへの接続がアイドル状態でいられる時間を指定します。
- 範囲のタイムアウト。範囲を使用した検索のために、別のルックスルー制限を指定します。
14.5.1. パフォーマンスおよびリソース制限の検索
14.5.2. 粒度の細かい ID リストサイズ
14.5.3. コマンドラインを使用したユーザーおよびグローバルリソース制限の設定
- シークスルー制限
- 検索操作に対して検査するエントリーの数を指定します。この属性を -1 の値に指定すると、制限がないことを意味します。
- ユーザーレベルの属性:
nsLookThroughLimit
- グローバル設定:
- 属性:
nsslapd-lookthroughlimit
- エントリー: cn=config,cn=ldbm database,cn=plugins,cn=config
- ページルックアップの制限
- ルックスルー制限と同様に、検査するエントリーの数を指定しますが、単純なページング検索操作に特化しています。この属性を -1 の値に指定すると、制限がないことを意味します。
- ユーザーレベルの属性:
nsPagedLookThroughLimit
- グローバル設定:
- 属性:
nsslapd-pagedlookthroughlimit
- エントリー: cn=config,cn=ldbm database,cn=plugins,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
属性を追加して、検索結果のサイズ制限を 500 エントリーにします。
14.5.4. 匿名バインドでのリソース制限の設定
- テンプレートエントリーを作成し、匿名バインドに適用するリソース制限を設定します。注記パフォーマンス上の理由から、テンプレートは、エントリーキャッシュは使用しない cn=config 接尾辞ではなく、通常のバックエンドになければなりません。以下に例を示します。
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=anonymous_template,ou=people,dc=example,dc=com objectclass: nsContainer objectclass: top cn: anonymous_template nsSizeLimit: 250 nsLookThroughLimit: 1000 nsTimeLimit: 60
- レプリケーショントポロジー内のすべてのサプライヤーで、テンプレートエントリーの DN を参照するサーバー設定に
nsslapd-anonlimitsdn
パラメーターを追加します。「コマンドラインを使用したユーザーおよびグローバルリソース制限の設定」に任意のリソース制限を設定できます。以下に例を示します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-anonlimitsdn="cn=anonymous_template,ou=people,dc=example,dc=com"
14.5.5. 範囲検索のパフォーマンス向上
(modifyTimestamp>=20210101010101Z)
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.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.1 簡単な参照検索コマンド
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
15.1.5. レプリケーション ID
- これは、cn=config エントリーのコンシューマーサーバーに作成されます。
- 別のサーバーから更新を受け取る すべて のサーバー (つまり、すべてのハブまたは専用のコンシューマー) でこのエントリーを作成します。
- レプリカがコンシューマーまたはハブとして設定されている場合は、このエントリーを、レプリケーションの更新を実行する権限のあるものとして指定する必要があります。
- レプリカ合意はサプライヤーサーバーで作成され、このエントリーの DN をレプリカ合意に指定する必要があります。
- レプリケーションコンテキストでは、このエントリーは、その特別なユーザープロファイルを使用して、そのレプリケーションアグリーメントに含まれるデータベースのコンシューマーサーバーで定義されたアクセス制御規則をバイパスします。レプリケーションコンテキストの外では、レプリケーションマネージャーは通常の操作を実行するときに ACI の影響を受けることに注意してください。
15.1.6. レプリカ合意
- 複製されるデータベース。
- データがプッシュされるコンシューマーサーバー
- レプリケーションが実行する曜日および時間帯
- サプライヤーサーバーがバインドに使用する必要のある DN および認証情報 (レプリケーションマネージャーエントリーまたはサプライヤーバインド DN)
- 接続をセキュアにする方法 (TLS、クライアント認証)。
- 複製されない属性 (一部レプリケーション)
15.1.7. 一部レプリケーションを使用した属性のサブセットの複製
nsDS5ReplicatedAttributeList
) は、一部レプリケーションを有効にするために常に設定される必要があります。唯一の属性が設定されている場合は、増分更新と合計更新の両方に適用されます。オプションの nsDS5ReplicatedAttributeListTotal
属性は、更新の合計に追加の一部レプリケーション一覧を設定します。これは、「合計更新および増分更新での異なる一部レプリケーション属性の設定」で説明されています。
nsds5ReplicaStripAttrs
属性は、空のレプリケーションイベントでは送信できず、更新シーケンスから削除される属性の一覧を追加します。これには、modifiersName
のような運用上の利便性が含まれます。
15.1.8. TLS 上のレプリケーション
前提条件
- サプライヤーサーバーとコンシューマーサーバーの両方が TLS を使用するように設定します。「Directory Server での TLS の有効化」を参照してください。
- コンシューマーサーバーが、サプライヤーサーバーの証明書を サプライヤー DN として認識するように設定します。これは、簡易認証ではなく TLS クライアント認証のみを使用します。「証明書ベースのクライアント認証の使用」を参照してください。重要TLS ハンドシェイク中に、サプライヤーの証明書がサーバー証明書としてのみ動作し、同時にクライアントとしては動作しない場合は、証明書ベースの認証を用いて TLS 上で設定されたレプリケーションが失敗するという問題がありました。証明書ベースの認証でのレプリケーションでは、リモートサーバーへの認証に Directory Server のサーバー証明書を使用します。
certutil
を使用して証明書署名要求 (CSR) を生成する場合は、--nsCertType=sslClient,sslServer
オプションをコマンドに渡し、必要な証明書を設定します。
TLS でのレプリケーションの設定
- ユーザー名とパスワード認証を使用する場合:
- 証明書ベースの認証を使用する場合は、「証明書ベースの認証を使用するようにレプリケーションパートナーの設定」を参照してください。
15.2. 単一サプライヤーレプリケーション
図15.1 単一サプライヤーレプリケーション
15.2.1. コマンドラインを使用した単一サプライヤーレプリケーションの設定
supplier.example.com
という名前のホストで実行されていることを前提としています。このホストは、レプリケーショントポロジーに設定されるサプライヤーとして機能します。以下の手順では、consumer.example.com
という名前の読み取り専用コンシューマーをトポロジーに追加する方法と、dc=example,dc=com
接尾辞に単一サプライヤーレプリケーションを設定する方法を説明します。
コンシューマーで実行する手順
consumer.example.com
ホスト:
- Directory Server をインストールして、インスタンスを作成します。詳細は、『Red Hat Directory Server インストールガイド』 を参照してください。
- データベースなしでインスタンスを作成した場合には、接尾辞のデータベースを作成します。たとえば、dc=example,dc=com 接尾辞に
userRoot
という名前のデータベースを作成するには、以下のコマンドを実行します。# dsconf -D "cn=Directory Manager" ldap://consumer.example.com backend \ create --suffix="dc=example,dc=com" --be-name="userRoot"
接尾辞のデータベース作成に関する詳細は、「接尾辞の作成」を参照してください。 - 接尾辞のレプリケーションを有効にし、レプリケーションマネージャーアカウントを作成します。
# dsconf -D "cn=Directory Manager" ldap://consumer.example.com replication \ enable --suffix="dc=example,dc=com" --role="consumer" \ --bind-dn="cn=replication manager,cn=config" --bind-passwd="password"
このコマンドは、consumer.example.com
ホストを dc=example,dc=com 接尾辞のコンシューマーとして設定します。さらに、サーバーは指定のパスワードでcn=replication manager,cn=config
ユーザーを作成し、このアカウントがこのホストに接尾辞の変更を複製することができます。
サプライヤーで実施する手順
supplier.example.com
ホスト:
- dc=example,dc=com 接尾辞のレプリケーションを有効にします。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication \ enable --suffix="dc=example,dc=com" --role="supplier" --replica-id=1
このコマンドは、supplier.example.com
ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。重要トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。 - レプリカ合意を追加し、コンシューマーを初期化します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt \ create --suffix="dc=example,dc=com" --host="consumer.example.com" --port=636 \ --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" \ --bind-passwd="password" --bind-method=SIMPLE --init \ example-agreement
このコマンドは、example-agreement
という名前のレプリカ合意を作成します。レプリカ合意は、コンシューマーへのデータの接続や複製時にサプライヤーが使用するコンシューマーのホスト名、プロトコル、認証情報などの設定を定義します。この合意の作成後、Directory Server はコンシューマーを初期化します。後ほどコンシューマーを初期化する場合は、--init
オプションを省略します。コンシューマーを初期化する前にレプリケーションが起動しないことに注意してください。コンシューマーの初期化の詳細は、「コンシューマーの初期化」を参照してください。コマンドで使用するオプションの詳細は、以下を入力します。# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt --help
- 初期化が成功したかどうかを確認します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt \ init-status --suffix="dc=example,dc=com" example-agreement Agreement successfully initialized.
複製するデータ量によっては、初期化に時間がかかる場合があります。
15.2.2. Web コンソールを使用した単一サプライヤーレプリケーションの設定
supplier.example.com
という名前のホストで実行されていることを前提としています。このホストは、レプリケーショントポロジーに設定されるサプライヤーとして機能します。以下の手順では、consumer.example.com
という名前の読み取り専用コンシューマーをトポロジーに追加する方法と、dc=example,dc=com
接尾辞に単一サプライヤーレプリケーションを設定する方法を説明します。
コンシューマーで実行する手順
consumer.example.com
ホスト:
- Directory Server をインストールして、インスタンスを作成します。詳細は、『Red Hat Directory Server インストールガイド』 を参照してください。
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- データベースなしでインスタンスを作成した場合には、接尾辞のデータベースを作成します。接尾辞のデータベース作成に関する詳細は、「接尾辞の作成」を参照してください。
- 接尾辞のレプリケーションを有効にします。
- dc=example,dc=com 接尾辞を選択し、 をクリックします。
- Replication Role フィールドで Consumer を選択し、作成するレプリケーションマネージャーアカウントの DN およびパスワードを入力します。以下に例を示します。この設定により、ホストを dc=example,dc=com 接尾辞のコンシューマーとして設定します。さらに、サーバーは指定のパスワードで
cn=replication manager,cn=config
ユーザーを作成し、このアカウントがこのホストに接尾辞の変更を複製することができます。
サプライヤーで実施する手順
supplier.example.com
ホスト:
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- dc=example,dc=com 接尾辞のレプリケーションを有効にします。
- dc=example,dc=com 接尾辞を選択し、 をクリックします。
- Replication Role フィールドで Supplier を選択し、レプリカ ID を入力し、Replication Authentication エリアのフィールドを空のままにします。以下に例を示します。これにより、ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。重要トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。
- レプリカ合意を追加し、コンシューマーを初期化します。
- dc=example,dc=com 接尾辞を選択します。メニューを開き、
- この設定により、
example-agreement
という名前のレプリカ合意が作成されます。レプリカ合意は、コンシューマーへのデータの接続や複製時にサプライヤーが使用するコンシューマーのホスト名、プロトコル、認証情報などの設定を定義します。 - Consumer Initialization フィールドで Do Online Initialization を選択し、合意の保存後にコンシューマーを自動的に初期化します。後でコンシューマーを初期化する場合は、Do Not Initialize を選択します。コンシューマーを初期化する前にレプリケーションが起動しないことに注意してください。コンシューマーの初期化の詳細は、「コンシューマーの初期化」を参照してください。
- 初期化が成功したかどうかを確認します。
- 初期化が正常に完了したら、Web コンソールの Last Update Status 列に Error (0) Replica acquired successfully: Incremental update succeeded メッセージが表示されます。複製するデータ量によっては、初期化に時間がかかる場合があります。
15.3. マルチサプライヤーのレプリケーション
図15.2 2 つのサプライヤーを持つマルチサプライヤーレプリケーション
図15.3 4 つのサプライヤーと 8 つのコンシューマーを持つ複雑なレプリケーションシナリオ
- ネットワークの速度。
- 送信および受信のレプリカ合意の数。
15.3.1. コマンドラインを使用したマルチサプライヤーレプリケーションの設定
supplier1.example.com
という名前のホストで実行されていることを前提としています。以下の手順では、supplier2.example.com
という名前の別の読み取り/書き込みレプリカをトポロジーに追加する方法と、dc=example,dc=com
接尾辞のマルチサプライヤーレプリケーションを設定する方法を説明します。
参加する新しいサーバーの準備
supplier2.example.com
ホスト:
- Directory Server をインストールして、インスタンスを作成します。詳細は、『Red Hat Directory Server インストールガイド』 を参照してください。
- データベースなしでインスタンスを作成した場合には、接尾辞のデータベースを作成します。たとえば、dc=example,dc=com 接尾辞に
userRoot
という名前のデータベースを作成するには、以下のコマンドを実行します。# dsconf -D "cn=Directory Manager" ldap://supplier2.example.com backend \ create --suffix="dc=example,dc=com" --be-name="userRoot"
接尾辞のデータベース作成に関する詳細は、「接尾辞の作成」を参照してください。 - 接尾辞のレプリケーションを有効にし、レプリケーションマネージャーアカウントを作成します。
# dsconf -D "cn=Directory Manager" ldap://supplier2.example.com replication \ enable --suffix="dc=example,dc=com" --role="supplier" --replica-id=1 \ --bind-dn="cn=replication manager,cn=config" --bind-passwd="password"
このコマンドは、supplier2.example.com
ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。さらに、サーバーは指定のパスワードでcn=replication manager,cn=config
ユーザーを作成し、このアカウントがこのホストに接尾辞の変更を複製することができます。重要トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。
既存のサーバーをサプライヤーに設定
supplier1.example.com
ホスト:
- 参加する新しいサーバーで実行したコマンドと同様に、dc=example,dc=com 接尾辞のレプリケーションを有効にし、レプリケーションマネージャーアカウントを作成します。
# dsconf -D "cn=Directory Manager" ldap://supplier1.example.com replication \ enable --suffix="dc=example,dc=com" --role="supplier" --replica-id=2 \ --bind-dn="cn=replication manager,cn=config" --bind-passwd="password"
レプリカ ID は、「参加する新しいサーバーの準備」で作成されるものとは異なるものでなければなりませんが、レプリケーションマネージャーアカウントは同じ DN を使用できます。 - レプリカ合意を追加し、新しいサーバーを初期化します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://supplier1.example.com repl-agmt \ create --suffix="dc=example,dc=com" --host="supplier2.example.com" --port=636 \ --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" \ --bind-passwd="password" --bind-method=SIMPLE --init \ example-agreement-supplier1-to-supplier2
このコマンドは、example-agreement-supplier1-to-supplier2
という名前のレプリカ合意を作成します。レプリカ合意は、コンシューマーへのデータの接続や複製時にサプライヤーが使用するコンシューマーのホスト名、プロトコル、認証情報などの設定を定義します。この合意の作成後、Directory Server はコンシューマーを初期化します。後ほどコンシューマーを初期化する場合は、--init
オプションを省略します。コンシューマーを初期化する前にレプリケーションが起動しないことに注意してください。コンシューマーの初期化の詳細は、「コンシューマーの初期化」を参照してください。コマンドで使用するオプションの詳細は、以下を入力します。# dsconf -D "cn=Directory Manager" ldap://supplier1.example.com repl-agmt --help
- 初期化が成功したかどうかを確認します。
# dsconf -D "cn=Directory Manager" ldap://supplier1.example.com repl-agmt \ init-status --suffix="dc=example,dc=com" example-agreement-supplier1-to-supplier2 Agreement successfully initialized.
複製するデータ量によっては、初期化に時間がかかる場合があります。
新しいサーバーをサプライヤーに設定
supplier2.example.com
ホスト:
supplier 2
からsupplier 1
に情報を複製する複製合意を追加します。以下に例を示します。# dsconf -D "cn=Directory Manager" ldap://supplier2.example.com repl-agmt \ create --suffix="dc=example,dc=com" --host="supplier1.example.com" --port=636 \ --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" \ --bind-passwd="password" --bind-method=SIMPLE \ example-agreement-supplier2-to-supplier1
このコマンドは、example-agreement-supplier2-to-supplier1
という名前のレプリカ合意を作成します。レプリカ合意は、コンシューマーへのデータの接続や複製時にサプライヤーが使用するコンシューマーのホスト名、プロトコル、認証情報などの設定を定義します。
15.3.2. Web コンソールを使用したマルチサプライヤーレプリケーションの設定
supplier1.example.com
という名前のホストで実行されていることを前提としています。以下の手順では、supplier2.example.com
という名前の別の読み取り/書き込みレプリカをトポロジーに追加する方法と、dc=example,dc=com
接尾辞のマルチサプライヤーレプリケーションを設定する方法を説明します。
参加する新しいサーバーの準備
supplier2.example.com
ホスト:
- Directory Server をインストールして、インスタンスを作成します。詳細は、『Red Hat Directory Server インストールガイド』 を参照してください。
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- データベースなしでインスタンスを作成した場合は、接尾辞からデータベースを作成します。接尾辞のデータベース作成に関する詳細は、「接尾辞の作成」を参照してください。
- 接尾辞のレプリケーションを有効にします。
- dc=example,dc=com 接尾辞を選択し、 をクリックします。
- Replication Role フィールドで Supplier を選択し、レプリカ ID を入力し、作成するレプリケーションマネージャーアカウントの DN およびパスワードを入力します。以下に例を示します。この設定により、
supplier2.example.com
ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。さらに、サーバーは指定のパスワードでcn=replication manager,cn=config
ユーザーを作成し、このアカウントがこのホストに接尾辞の変更を複製することができます。重要トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。
既存のサーバーをサプライヤーに設定
supplier1.example.com
ホスト:
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 参加する新規サーバーの設定と同様に、dc=example,dc=com 接尾辞のレプリケーションを有効にし、レプリケーションコントローラーアカウントを作成します。
- dc=example,dc=com 接尾辞を選択し、 をクリックします。
- Replication Role フィールドで Supplier を選択し、レプリカ ID を入力し、作成するレプリケーションマネージャーアカウントの DN およびパスワードを入力します。以下に例を示します。レプリカ ID は、「参加する新しいサーバーの準備」で作成されるものとは異なるものでなければなりませんが、レプリケーションマネージャーアカウントは同じ DN を使用できます。
- レプリカ合意を追加し、コンシューマーを初期化します。
- この設定により、
example-agreement-supplier1-to-supplier2
という名前のレプリカ合意が作成されます。レプリカ合意は、コンシューマーへのデータの接続や複製時にサプライヤーが使用するコンシューマーのホスト名、プロトコル、認証情報などの設定を定義します。 - Consumer Initialization フィールドで Do Online Initialization を選択し、合意の保存後にコンシューマーを自動的に初期化します。後でコンシューマーを初期化する場合は、Do Not Initialize を選択します。コンシューマーを初期化する前にレプリケーションが起動しないことに注意してください。コンシューマーの初期化の詳細は、「コンシューマーの初期化」を参照してください。
- 初期化が成功したかどうかを確認します。
- 初期化が正常に完了したら、Web コンソールの Last Update Status 列に Error (0) Replica acquired successfully: Incremental update succeeded メッセージが表示されます。複製するデータ量によっては、初期化に時間がかかる場合があります。
新しいサーバーをサプライヤーに設定
supplier2.example.com
ホスト:
- レプリカ合意を追加し、コンシューマーを初期化します。
- この設定により、
example-agreement-supplier2-to-supplier1
という名前のレプリカ合意が作成されます。 - Consumer Initialization フィールドで Do Online Initialization を選択し、合意の保存後にコンシューマーを自動的に初期化します。後でコンシューマーを初期化する場合は、Do Not Initialize を選択します。コンシューマーを初期化する前にレプリケーションが起動しないことに注意してください。コンシューマーの初期化の詳細は、「コンシューマーの初期化」を参照してください。
- 初期化が成功したかどうかを確認します。
- 初期化が正常に完了すると、Web コンソールは Last Update Status 列に Error (0) Replica acquired successfully: Incremental update succeeded メッセージを表示します。複製するデータ量によっては、初期化に時間がかかる場合があります。
15.3.3. マルチサプライヤーレプリケーションにおけるコンシューマーの独占を防ぐ
nsds5ReplicaBusyWaitTime
- 別のアクセスの取得を試みる前に、コンシューマーがビジー応答を返した後、サプライヤーが待機する時間を秒単位で設定します。たとえば、別の取得を試みる前に、サプライヤーが 5 秒待機するように設定するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt \ set --suffix="suffix" --busy-wait-time=5 agreement_name
nsds5ReplicaSessionPauseTime
- 2 つの更新セッションの間にサプライヤーが待機する時間を秒単位で設定します。
nsds5ReplicaBusyWaitTime
で指定した値またはそれよりも小さい値を設定すると、Directory Server は、nsds5ReplicaBusyWaitTime
で設定した値よりも大きな値であるnsds5ReplicaSessionPauseTime
パラメーターの値を自動的に使用します。たとえば、サプライヤーは 2 つの更新セッション間で 10 秒待機するように設定するには、以下を実行します。# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt \ set --suffix="suffix" --session-pause-time=10 agreement_name
nsds5ReplicaReleaseTimeout
- 更新の送信を終了したかどうか、サプライヤーがレプリカのリリース後のタイムアウトを設定します。これにより、単一サプライヤーがレプリカを独占しなくなります。たとえば、サプライヤーが大きいレプリケーション環境で 90 秒後にレプリカを解放するように設定するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication \ set --suffix="suffix" --repl-release-timeout=90
15.4. カスケードレプリケーション
図15.4 カスケードレプリケーション
15.4.1. コマンドラインによるカスケードレプリケーションの設定
supplier.example.com
という名前のホストで実行されていることを前提としています。以下の手順では、dc=example,dc=com
接尾辞用にサプライヤーから更新を受信するトポロジーに hub.example.com
という名前のハブを追加する方法を説明します。その後、接尾辞のハブサーバーから更新を受信する consumer.example.com
という名前のコンシューマーを追加する方法を説明します。
参加する新しいハブサーバーの準備
hub.example.com
ホスト:
- Directory Server をインストールしてインスタンスを作成します。詳細は、『Red Hat Directory Server インストールガイド』 を参照してください。
- データベースなしでインスタンスを作成した場合には、接尾辞のデータベースを作成します。たとえば、dc=example,dc=com 接尾辞に
userRoot
という名前のデータベースを作成するには、以下のコマンドを実行します。# dsconf -D "cn=Directory Manager" ldap://hub.example.com backend \ create --suffix="dc=example,dc=com" --be-name="userRoot"
接尾辞のデータベース作成に関する詳細は、「接尾辞の作成」を参照してください。 - 接尾辞のレプリケーションを有効にし、レプリケーションマネージャーアカウントを作成します。
# dsconf -D "cn=Directory Manager" ldap://hub.example.com replication \ enable --suffix="dc=example,dc=com" --role="hub" \ --bind-dn="cn=replication manager,cn=config" --bind-passwd="password"
このコマンドは、dc=example,dc=com 接尾辞のハブとしてhub.example.com
ホストを設定します。さらに、サーバーは指定のパスワードでcn=replication manager,cn=config
ユーザーを作成し、このアカウントがこのホストに接尾辞の変更を複製することができます。
既存のサーバーをサプライヤーに設定
supplier.example.com
ホスト:
- 「参加する新しいハブサーバーの準備」に参加する新しいハブサーバーで実行したコマンドと同様に、dc=example,dc=com 接尾辞のレプリケーションを有効にして、レプリケーションマネージャーアカウントを作成します。
# dsconf -D "cn=Directory Manager" ldap://supplier1.example.com replication \ enable --suffix="dc=example,dc=com" --role="supplier" --replica-id=1 \ --bind-dn="cn=replication manager,cn=config" --bind-passwd="password"
重要トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。レプリケーションマネージャーアカウントは、ハブで作成したものと同じ DN を使用できます。 - レプリカ合意を追加し、ハブを初期化します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt \ create --suffix="dc=example,dc=com" --host="hub.example.com" --port=636 \ --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" \ --bind-passwd="password" --bind-method=SIMPLE --init \ example-agreement-supplier-to-hub
このコマンドは、example-agreement-supplier-to-hub
という名前のレプリカ合意を作成します。レプリカ合意は、ハブへのデータの接続時や複製時にサプライヤーが使用するハブのホスト名、プロトコル、認証情報などの設定を定義します。この合意の作成後、Directory Server はハブを初期化します。後でハブを初期化するには、--init
オプションを省略します。コンシューマーを初期化する前にレプリケーションが起動しないことに注意してください。コンシューマーの初期化の詳細は、「コンシューマーの初期化」を参照してください。コマンドで使用するオプションの詳細は、以下を入力します。# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt --help
- 初期化が成功したかどうかを確認します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt \ init-status --suffix="dc=example,dc=com" example-agreement-supplier-to-hub Agreement successfully initialized.
複製するデータ量によっては、初期化に時間がかかる場合があります。
参加させる新規コンシューマーの準備
consumer.example.com
ホスト:
- Directory Server をインストールしてインスタンスを作成します。詳細は、『Red Hat Directory Server インストールガイド』 を参照してください。
- データベースなしでインスタンスを作成した場合には、接尾辞のデータベースを作成します。たとえば、dc=example,dc=com 接尾辞に
userRoot
という名前のデータベースを作成するには、以下のコマンドを実行します。# dsconf -D "cn=Directory Manager" ldap://hub.example.com backend \ create --suffix="dc=example,dc=com" --be-name="userRoot"
接尾辞のデータベース作成に関する詳細は、「接尾辞の作成」を参照してください。 - 接尾辞のレプリケーションを有効にし、レプリケーションマネージャーアカウントを作成します。
# dsconf -D "cn=Directory Manager" ldap://consumer.example.com replication \ enable --suffix="dc=example,dc=com" --role="consumer" \ --bind-dn="cn=replication manager,cn=config" --bind-passwd="password"
このコマンドは、consumer.example.com
ホストを dc=example,dc=com 接尾辞のコンシューマーとして設定します。さらに、サーバーは指定のパスワードでcn=replication manager,cn=config
ユーザーを作成し、このアカウントがこのホストに接尾辞の変更を複製することができます。
ハブをコンシューマーのサプライヤーとして設定
hub.example.com
ホスト:
- レプリカ合意を追加し、サーバーを初期化します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://hub.example.com repl-agmt \ create --suffix="dc=example,dc=com" --host="consumer.example.com" --port=636 \ --conn-protocol=LDAPS --bind-dn="cn=replication manager,cn=config" \ --bind-passwd="password" --bind-method=SIMPLE --init \ example-agreement-hub-to-consumer
この合意の作成後、Directory Server はコンシューマーを初期化します。後ほどコンシューマーを初期化する場合は、--init
オプションを省略します。 - 初期化が成功したかどうかを確認します。
# dsconf -D "cn=Directory Manager" ldap://hub.example.com repl-agmt \ init-status --suffix="dc=example,dc=com" example-agreement-hub-to-consumer Agreement successfully initialized.
複製するデータ量によっては、初期化に時間がかかる場合があります。
15.4.2. Web コンソールによるカスケードレプリケーションの設定
supplier.example.com
という名前のホストで実行されていることを前提としています。以下の手順では、dc=example,dc=com
接尾辞用にサプライヤーから更新を受信するトポロジーに hub.example.com
という名前のハブを追加する方法を説明します。その後、接尾辞のハブサーバーから更新を受信する consumer.example.com
という名前のコンシューマーを追加する方法を説明します。
参加する新しいハブサーバーの準備
hub.example.com
ホスト:
- Directory Server をインストールしてインスタンスを作成します。詳細は、『Red Hat Directory Server インストールガイド』 を参照してください。
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- データベースなしでインスタンスを作成した場合には、接尾辞のデータベースを作成します。接尾辞のデータベース作成に関する詳細は、「接尾辞の作成」を参照してください。
- 接尾辞のレプリケーションを有効にします。
- dc=example,dc=com 接尾辞を選択し、 をクリックします。
- Replication Role フィールドで Hub を選択し、作成するレプリケーションマネージャーアカウントの DN およびパスワードを入力します。以下に例を示します。この設定により、
hub.example.com
ホストを dc=example,dc=com 接尾辞のハブとして設定します。さらに、サーバーは指定のパスワードでcn=replication manager,cn=config
ユーザーを作成し、このアカウントがこのホストに接尾辞の変更を複製することができます。
既存のサーバーをサプライヤーに設定
supplier.example.com
ホスト:
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 「参加する新しいハブサーバーの準備」に参加する新しいハブサーバーの設定と同様、dc=example,dc=com 接尾辞のレプリケーションを有効にして、レプリケーションマネージャーアカウントを作成します。
- dc=example,dc=com 接尾辞を選択し、 をクリックします。
- Replication Role フィールドで Supplier を選択し、レプリカ ID を入力し、作成するレプリケーションマネージャーアカウントの DN およびパスワードを入力します。以下に例を示します。重要トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。レプリケーションマネージャーアカウントは、ハブで作成したものと同じ DN を使用できます。
- レプリカ合意を追加し、ハブを初期化します。
- この設定により、
example-agreement-supplier-to-hub
という名前のレプリカ合意が作成されます。レプリカ合意は、ハブへのデータの接続時や複製時にサプライヤーが使用するハブのホスト名、プロトコル、認証情報などの設定を定義します。 - Consumer Initialization フィールドで Do Online Initialization を選択し、合意の保存後にコンシューマーを自動的に初期化します。後でハブを初期化するには、Do Not Initialize を選択します。コンシューマーを初期化する前にレプリケーションが起動しないことに注意してください。コンシューマーの初期化の詳細は、「コンシューマーの初期化」を参照してください。
- 初期化が成功したかどうかを確認します。
- 初期化が正常に完了すると、Web コンソールは Last Update Status 列に Error (0) Replica acquired successfully: Incremental update succeeded メッセージを表示します。複製するデータ量によっては、初期化に時間がかかる場合があります。
参加する新規コンシューマーの設定
consumer.example.com
ホスト:
- Directory Server をインストールしてインスタンスを作成します。詳細は、『Red Hat Directory Server インストールガイド』 を参照してください。
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- データベースなしでインスタンスを作成した場合には、接尾辞のデータベースを作成します。接尾辞のデータベース作成に関する詳細は、「接尾辞の作成」を参照してください。
- 接尾辞のレプリケーションを有効にします。
- dc=example,dc=com 接尾辞を選択し、 をクリックします。
- Replication Role フィールドで Consumer を選択し、作成するレプリケーションマネージャーアカウントの DN およびパスワードを入力します。以下に例を示します。この設定により、
consumer.example.com
ホストを dc=example,dc=com 接尾辞のコンシューマーとして設定します。さらに、サーバーは指定のパスワードでcn=replication manager,cn=config
ユーザーを作成し、このアカウントがこのホストに接尾辞の変更を複製することができます。
ハブをコンシューマーのサプライヤーとして設定
consumer.example.com
ホスト:
- レプリカ合意を追加し、コンシューマーを初期化します。
- この設定により、
example-agreement-hub-to-consumer
という名前のレプリカ合意が作成されます。 - Consumer Initialization フィールドで Do Online Initialization を選択し、合意の保存後にコンシューマーを自動的に初期化します。後でコンシューマーを初期化する場合は、Do Not Initialize を選択します。コンシューマーを初期化する前にレプリケーションが起動しないことに注意してください。コンシューマーの初期化の詳細は、「コンシューマーの初期化」を参照してください。
- 初期化が成功したかどうかを確認します。
- 初期化が正常に完了すると、Web コンソールは Last Update Status 列に Error (0) Replica acquired successfully: Incremental update succeeded メッセージを表示します。複製するデータ量によっては、初期化に時間がかかる場合があります。
15.5. ブートストラップ認証情報の設定
- データベースの初期化前にレプリカに対して認証する必要があるオンライン初期化
- GSSAPI を認証方法として使用する場合、Kerberos 認証情報が変更される
- LDAP_INVALID_CREDENTIALS (err=49)
- LDAP_INAPPROPRIATE_AUTH (err=48)
- LDAP_NO_SUCH_OBJECT (err=32)
手順
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt create ... --bootstrap-bind-dn "bind_DN" --bootstrap-bind-passwd "password" --bootstrap-bind-method bind_method --bootstrap-conn-protocol connection protocol ...
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt set --suffix="suffix" --bootstrap-bind-dn "bind_DN" --bootstrap-bind-passwd "password" --bootstrap-bind-method bind_method --bootstrap-conn-protocol connection protocol agreement_name
15.6. 証明書ベースの認証を使用するようにレプリケーションパートナーの設定
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 に設定します。# dsconf -D "cn=Directory Manager" ldap://server1.example.com replication \ enable --suffix="dc=example,dc=com" --role="supplier" --replica-id="7" \ --bind-group-dn="cn=repl_server,ou=Groups,dc=example,dc=com"
- グループが変更したかどうかを Directory Server が確認するレプリカエントリーの間隔を、0 に設定します。
# dsconf -D "cn=Directory Manager" ldap://server1.example.com replication \ set --suffix="dc=example,dc=com" --repl-bind-group-interval=0
- 新しいサーバーを初期化します。
server2.example.com
で、cn=Replication Manager,cn=config
などの一時的なレプリケーションマネージャーアカウントを作成します。server1.example.com
で、認証用に直前の手順でアカウントを使用する一時的なレプリカ合意を作成します。# dsconf -D "cn=Directory Manager" ldap://server2.example.com repl-agmt \ create --suffix="dc=example,dc=com" --host="server1.example.com" --port=636 \ --conn-protocol=LDAPS --bind-dn="cn=Replication Manager,cn=config" \ --bind-passwd="password" --bind-method=SIMPLE --init \ temporary_agreement
この合意は、以前に作成したレプリケーションマネージャーアカウントを使用してデータベースを初期化します。この初期化前に、server2.example.com
のデータベースが空で、関連する証明書を持つアカウントは存在しません。したがって、データベースの初期化前に、証明書を使用してレプリケーションすることはできません。
- 新しいサーバーが初期化された後
server1.example.com
から一時的なレプリカ合意を削除します。# dsconf -D "cn=Directory Manager" ldap://server1.example.com repl-agmt \ delete --suffix="dc=example,dc=com" temporary_agreement
server2.example.com
から一時的なレプリケーションマネージャーアカウントを削除します。# dsconf -D "cn=Directory Manager" ldap://server2.example.com replication \ delete-manager --suffix="dc=example,dc=com" --name="Replication Manager"
- 証明書ベースの認証を使用する両サーバーでレプリカ合意を作成します。
server1.example.com
:# dsconf -D "cn=Directory Manager" ldap://server1.example.com repl-agmt \ create --suffix="dc=example,dc=com" --host="server2.example.com" --port=636 \ --conn-protocol=LDAPS --bind-method="SSLCLIENTAUTH" \ --init example_agreement
server2.example.com
:# dsconf -D "cn=Directory Manager" ldap://server2.example.com repl-agmt \ create --suffix="dc=example,dc=com" --host="server1.example.com" --port=636 \ --conn-protocol=LDAPS --bind-method="SSLCLIENTAUTH" \ --init example_agreement
- レプリケーションが正しく機能していることを確認するには、レプリカ合意に
nsds5replicaLastUpdateStatus
属性を表示します。# dsconf -D "cn=Directory Manager" ldap://server1.example.com repl-agmt status --suffix="dc=example,dc=com" example_agreement
使用できるステータスの詳細は『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 の付録 『レプリカ合意の状況』 を参照してください。
15.7. コンシューマーまたはハブを 1 つのサプライヤーにプロモート
15.7.1. コマンドラインを使用したコンシューマーまたはハブのサプライヤーへのプロモート
server.example.com
ホストを dc=example,dc=com 接尾辞のサプライヤーにプロモートするには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com replication \ promote --suffix="dc=example,dc=com" --newrole="supplier" --replica-id=2
15.7.2. Web コンソールを使用したコンシューマーまたはハブのサプライヤーへのプロモート
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- dc=example,dc=com 接尾辞を選択します。
- Replication Role フィールドで Supplier を選択し、レプリカ ID を入力します。重要トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。
15.8. コンシューマーの初期化の概要
15.8.1. コンシューマーの初期化のタイミング
15.8.2. 初期タイムアウトの設定
- cn=config エントリーの
nsslapd-idletimeout
設定パラメーターは、サーバー上のすべてのレプリカ合意のタイムアウトを設定します。たとえば、グローバルにタイムアウトを無効にするには、次のコマンドを実行します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-idletimeout=0
- レプリケーションマネージャーの DN の
nsIdleTimeout
パラメーターは、このレプリケーションマネージャーエントリーを使用するすべての合意のタイムアウトを設定します。たとえば、cn=replication manager,cn=config
エントリーのタイムアウトを無効にするには、以下のコマンドを実行します。# ldapmodify -D "cn=Directory Manager" -w -h server.example.com -p 389 -x dn: cn=replication manager,cn=config changetype: modify add: nsIdleTimeout nsIdleTimeout: 0
15.8.3. コンシューマーの初期化
15.8.3.1. コマンドラインを使用したコンシューマーの初期化
15.8.3.1.1. コンシューマーオンラインの初期化
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt \ init --suffix="suffix" agreement_name
15.8.3.1.2. コンシューマーオフラインの初期化
- サプライヤーで以下を行います。
- サプライヤーでインスタンスをシャットダウンします。
# dsctl instance_name stop
- 複製する接尾辞が含まれる
userRoot
データベースをエクスポートし、レプリケーションの情報を有する/tmp/example.ldif
ファイルにエクスポートします。# dsctl instance_name db2ldif --replication userRoot /tmp/example.ldif
- サプライヤーでインスタンスを起動します。
# dsctl instance_name start
- エクスポートしたファイルをコンシューマーにコピーします。
- コンシューマーにデータをインポートします。詳細については、「サーバーがオフライン時のデータのインポート」 を参照してください。
15.8.4. Web コンソールを使用したコンシューマーの初期化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Choose Action メニューを開き、Initialize Agreement を選択します。タブで、接尾辞のレプリカ合意の横にある初期化が正常に完了すると、Web コンソールは Last Update Status 列に Error (0) Replica acquired successfully: Incremental update succeeded メッセージを表示します。複製するデータ量によっては、初期化に時間がかかる場合があります。
15.9. レプリケーションの無効化および再有効化
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt disable --suffix="dc=example,dc=com" agreement_name
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt enable --suffix="dc=example,dc=com" agreement_name
15.10. レプリケーショントポロジーからの Directory Server インスタンスの削除
15.10.1. Replication Topology からのコンシューマーまたはハブの削除
- 削除するホストがハブであり、トポロジー内の他のサーバーのサプライヤーでもある場合は、他のサプライヤーまたはハブを設定して、これらのサーバーにデータを複製します。これらのサーバーに他のサプライヤーが設定されておらず、ハブを削除すると、これらのサーバーはレプリケーショントポロジーから分離されます。レプリケーションの設定に関する詳細は、以下を参照してください。
- 削除するホストで、更新を防ぐためにデータベースを読み取り専用モードに設定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h host-to-remove.example.com -x dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-readonly nsslapd-readonly: on
- 削除するホストとのレプリカ合意があるすべてのサプライヤーで、レプリカ合意を削除します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt \ delete --suffix="dc=example,dc=com" agreement_name
- コンシューマーまたはハブで、すべての接尾辞のレプリケーションを無効にします。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://host-to-remove.example.com replication \ disable --suffix="dc=example,dc=com"
レプリケーションを無効にすると、このサーバーのこの接尾辞のレプリカ合意がすべて自動的に削除されます。
15.10.2. レプリケーショントポロジーからのサプライヤーの削除
- 削除するレプリカがトポロジー内の他のサーバーのサプライヤーでもある場合は、他のサプライヤーまたはハブを設定して、そのサーバーにデータを複製します。これらのサーバーに他のサプライヤーが設定されておらず、サプライヤーを削除すると、これらのサーバーはレプリケーショントポロジーから分離されます。レプリケーションの設定に関する詳細は、以下を参照してください。
- 削除するサプライヤーで、以下を行います。
- データベースを読み取り専用モードにして、更新ができないようにします。詳細については、「読み取り専用モードでのデータベースの設定」 を参照してください。
- トポロジー内の他のすべてのサーバーが、このサプライヤーからすべてのデータを受け取るまで待ちます。確認のため、他のサーバーの CSN が、削除するサプライヤーの CSN と同等以上であることを確認します。以下に例を示します。
# ds-replcheck online -D "cn=Directory Manager" -w password -m ldap://replica-to-remove.example.com:389 -r ldap://server.example.com:389 -b dc=example,dc=com ================================================================================ Replication Synchronization Report (Tue Mar 5 09:46:20 2019) ================================================================================ Database RUV's ===================================================== Supplier RUV: {replica 1 ldap://replica-to-remove.example.com:389} 5c7e8927000100010000 5c7e89a0000100010000 {replicageneration} 5c7e8927000000010000 Replica RUV: {replica 1 ldap://replica-to-remove.example.com:389} 5c7e8927000100010000 5c7e8927000400010000 {replica 2 ldap://server.example.com:389} {replicageneration} 5c7e8927000000010000
- レプリカ ID を表示します。
# dsconf -D "cn=Directory Manager" ldap://replica-to-remove.example.com replication get --suffix="dc=example,dc=com" | grep -i "nsds5replicaid" nsDS5ReplicaId: 1
この例では、レプリカ ID は 1 です。この手順の最後のステップのレプリカ ID を書き留めます。
- 削除するレプリカとのレプリカ合意があるすべてのサプライヤーで、レプリカ合意を削除します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt \ delete --suffix="dc=example,dc=com" agreement_name
- 削除するレプリカで、すべての接尾辞のレプリケーションを無効にします。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://replica-to-remove.example.com replication \ disable --suffix="dc=example,dc=com"
レプリケーションを無効にすると、このサーバーのこの接尾辞のレプリカ合意がすべて自動的に削除されます。 - トポロジー内の残りのサプライヤーのいずれかで、レプリカ ID の RUV をクリーンアップします。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-tasks \ cleanallruv --suffix="dc=example,dc=com" --replica-id=1
このコマンドは、この手順の直前の手順で表示されるレプリカ ID を指定する必要があります。
15.11. 一部レプリケーションによる属性の管理
memberOf
計算など) が実行される回数を減らすために実行できます。
nsDS5ReplicatedAttributeList
属性で定義されます。この属性はレプリカ合意の一部で、Web コンソールのレプリカ合意ウィザードで設定するか、レプリカ合意の作成時にコマンドラインから設定できます。
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof authorityRevocationList accountUnlockTime
nsDS5ReplicatedAttributeList
属性の値に (objectclass=*) $ EXCLUDE の部分が必要です。ldapmodify
ユーティリティーなどを使用して属性を直接編集する場合は、上記の例で示されている属性の一覧とともにこの部分を指定する必要があります。ただし、dsconf
および Web コンソールはどちらも (objectclass=*) $ EXCLUDE の部分を自動的に追加し、指定する必要があるのは属性のみです。
15.11.1. 合計更新および増分更新での異なる一部レプリケーション属性の設定
nsDS5ReplicatedAttributeListTotal
) から除外する属性の別のリストを定義する 2 番目の属性を追加できます。
nsDS5ReplicatedAttributeList
プライマリーの一部レプリケーション属性です。nsDS5ReplicatedAttributeList
のみが設定されている場合、増分更新と合計更新の両方に適用されます。nsDS5ReplicatedAttributeList
と nsDS5ReplicatedAttributeListTotal
の両方が設定されている場合、nsDS5ReplicatedAttributeList
は増分更新にのみ適用されます。
memberOf
属性がエントリーに追加されるたびに、memberOf 修正タスクが実行してグループメンバーシップを解決します。これにより、レプリケーションが発生するたびにそのタスクが実行する場合に、サーバーでオーバーヘッドが発生する可能性があります。合計の更新は、レプリケーションに新たに追加されたり、長期間オフラインになったデータベースでのみ実行されるため、合計更新後の memberOf 修正タスクを実行すると、合計値が許容オプションになります。この場合、nsDS5ReplicatedAttributeList
属性には memberOf
というリストが記載されるため、増分更新から除外されるようにしますが、nsDS5ReplicatedAttributeListTotal
は memberOf
を一覧表示しないため、すべての更新に含まれるようにします。
nsDS5ReplicatedAttributeList
属性に設定されます。以下に例を示します。
nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE authorityRevocationList accountUnlockTime memberof
nsDS5ReplicatedAttributeList
属性を設定するには、dsconf repl-agmt set コマンドを使用します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt set \ --suffix="suffix" --frac-list="authorityRevocationList accountUnlockTime memberof" \ agreement_name
nsDS5ReplicatedAttributeList
が唯一の属性セットである場合、そのリストは増分更新と合計更新の両方に適用されます。更新の合計に別のリストを設定するには、レプリカ合意に nsDS5ReplicatedAttributeListTotal
属性を追加します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt set \ --suffix="suffix" --frac-list-total="accountUnlockTime" \ agreement_name
nsDS5ReplicatedAttributeList
属性は、すべての更新に対して nsDS5ReplicatedAttributeListTotal
を設定する前に増分更新のために設定される必要があります。
15.11.2. レプリケーションのキープアライブエントリー
keepalivetimestamp
属性が更新され、コンシューマーに複製されます。keepalivetimestamp
属性はレプリケーションから除外されないため、キープアライブエントリーの更新は複製され、コンシューマー上の CSN が更新され、サプライヤー上のものと等しくなります。次回サプライヤーをコンシューマーに接続する際には、コンシューマーの CSN より新しい更新のみが検索されます。これにより、サプライヤーが送信する新規更新の検索に費やされた時間が短縮されます。
# ldapsearch -D "cn=Directory Manager" -b "dc=example,dc=com" -W -p 389 -h server.example.com -x 'objectClass=ldapsubentry' dn: cn=repl keep alive 1,dc=example,dc=com objectclass: top objectclass: ldapsubentry objectclass: extensibleObject cn: repl keep alive 1 keepalivetimestamp: 20181112150654Z
- 一部レプリカ合意が 100 を超える更新を省略し、レプリケーションセッションの終了前に更新を送信しません。
- サプライヤーがコンシューマーを初期化すると、最初に独自のキープアライブエントリーを作成します。サプライヤーでもあるコンシューマーは、別のコンシューマーも初期化しない限り、独自のキープアライブエントリーを作成しません。
15.11.3. 一部レプリケーションによる空の更新の防止
nsDS5ReplicatedAttributeList
) から削除される属性の一覧が許可されます。しかし、除外された属性への変更があっても、修正イベントが発生し、空のレプリケーション更新が生成されます。
nsds5ReplicaStripAttrs
属性は、空のレプリケーションイベントでは送信できず、更新シーケンスから削除される属性の一覧を追加します。これには、modifiersName
のような運用上の利便性が含まれます。
accountUnlockTime
属性が除外されたとします。John Smith のユーザーアカウントがロックされ、期間が期限切れになり、自動的にロック解除されます。accountUnlockTime
属性のみが変更し、その属性はレプリケーションから除外されます。ただし、操作属性 internalmodifytimestamp
も 変更されています。John Smith のユーザーアカウントが変更しているため、レプリケーションイベントがトリガーされます。ただし、送信する唯一のデータは新しい変更タイムスタンプであり、更新は空になります。(たとえば) ログイン時間やパスワードの有効期限などに関連する多くの属性がある場合は、空のレプリケーション更新が作成され、サーバーのパフォーマンスに悪影響を与えるか、関連するアプリケーションを妨げる可能性があります。
nsds5ReplicaStripAttrs
属性をレプリカ合意に追加します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt set \ --suffix="suffix" \ --strip-list="modifiersname modifytimestamp internalmodifiersname" \ agreement_name
15.12. レプリケーションを使用した削除されたエントリーの管理
nsDS5ReplicaTombstonePurgeInterval
属性の設定)。パージは古い tombstone エントリーを削除します。tombstone エントリーは、指定の期間 (nsDS5ReplicaPurgeDelay
属性で設定) に保存されます。tombstone エントリーが遅延期間よりも古い場合が、次のパージジョブで復元します。
- パージ操作は、特にサーバーが多くの削除操作を処理する場合に時間がかかりません。パージの間隔が低すぎるか、サーバーのリソースを過剰に消費してパフォーマンスに影響を及ぼす可能性があります。
- サプライヤーは、tombstone エントリーなどの変更情報を使用して、初期化後に Prime レプリケーションを実行します。コンシューマーを効果的に再初期化し、レプリケーションの競合を解決するには、変更のバックログが十分にある必要があります。パージ遅延 (tombstone エントリーの経過時間) を低く設定しすぎないでください。または、レプリケーションの競合の解決に必要な情報が失われる可能性があります。レプリケーショントポロジーの長いレプリケーションスケジュールよりもわずかに長くパージ遅延を設定します。たとえば、最長のレプリケーションの間隔が 24 時間の場合は、tombstone エントリーを 25 時間保持します。これにより、コンシューマーを初期化するのに十分な変更履歴が確保され、異なるサプライヤーに保存されているデータが乖離するのを防ぐことができます。
--repl-tombstone-purge-interval=seconds
オプションは nsDS5ReplicaTombstonePurgeInterval
属性を設定し、--repl-purge-delay=seconds
オプションは nsDS5ReplicaPurgeDelay
属性を設定します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication set \ --repl-tombstone-purge-interval=43200 --repl-purge-delay=90000
nsDS5ReplicaTombstonePurgeInterval
属性および nsDS5ReplicaPurgeDelay
属性に設定します。どちらの属性も値が秒単位で設定されているため、パージ操作をほぼ即座に開始することができます。
15.13. Changelog 暗号化の設定
前提条件
手順
- changelog 暗号化を有効にするサーバーを除き、以下のコマンドを入力してレプリケーショントポロジー内のすべてのインスタンスを停止します。
# dsctl instance_name stop
- changelog 暗号化を有効にするサーバーで、以下を実行します。
- changelog(例:
/tmp/changelog.ldif
ファイル) をエクスポートします。# dsconf -D "cn=Directory Manager" ldap://server.example.com replication dump-changelog -o /tmp/changelog.ldif
- インスタンスを停止します。
# dsctl instance_name stop
/etc/dirsrv/slapd-instance_name/dse.ldif
ファイルの dn: cn=changelog5,cn=config エントリーに、以下の設定を追加します。nsslapd-encryptionalgorithm: AES
- インスタンスを起動します。
# dsctl instance_name start
/tmp/changelog.ldif
ファイルから changelog をインポートします。# dsconf -D "cn=Directory Manager" ldap://server.example.com replication restore-changelog from-ldif /tmp/changelog.ldif
- 以下のコマンドを実行して、レプリケーショントポロジー内の他のサーバー上のインスタンスをすべて起動します。
# dsctl instance_name start
検証
- エントリーの更新など、LDAP ディレクトリーに変更を加えます。
- インスタンスを停止します。
# dsctl stop instance_name
- 以下のコマンドを実行して、changelog の一部を表示します。
# dbscan -f /var/lib/dirsrv/slapd-instance_name/changelogdb/replica_name_replGen.db | tail -50
changelog が暗号化されている場合は、暗号化されたデータのみが表示されます。 - インスタンスを起動します。
# dsctl start instance_name
関連情報
15.14. Changelog の削除
15.14.1. コマンドラインを使用した Changelog の削除
- レプリケーションがすべて接尾辞で無効かどうかを確認します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication list There are no replicated suffixes
- changelog を削除します。
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication delete-changelog
15.14.2. Web コンソールを使用した changelog の削除
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
15.15. レプリケーション変更ログのエクスポート
前提条件
- レプリケーションは Directory Server インスタンスで有効になります。
手順
/tmp/changelog.ldif
ファイルにエクスポートするには、以下を入力します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com replication dump-changelog -o /tmp/changelog.ldif
dirsrv
ユーザーには、指定したファイルを作成するには、適切なファイルシステムの権限が必要になることに注意してください。
15.16. レプリケーション changelog の LDIF 形式の changelog ダンプからのインポート
前提条件
- レプリケーションは Directory Server インスタンスで有効になります。
- 「レプリケーション変更ログのエクスポート」 で説明されているように、changelog ダンプが作成されています。
手順
/tmp/changelog.ldif
ファイルから changelog ダンプをインポートするには、以下を入力します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com replication restore-changelog from-ldif /tmp/changelog.ldif
dirsrv
ユーザーには、指定したファイルを読み取るパーミッションが必要です。
15.17. レプリケーション 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/
- Web コンソールの使用
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Show Advanced Settings をクリックします。
- Changelog Location フィールドで現在のパスを特定します。ディレクトリーを移動するには、後のステップで表示されたパスが必要です。
- Changelog Location フィールドに新しいパスを設定します。
- Directory Server インスタンスを停止します。
# dsctl instance_name stop
- 前のディレクトリーのコンテンツを
/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 インスタンスを起動します。
# dsctl instance_name start
15.18. レプリケーション changelog のトリム
- 変更ログにおけるエントリーの最大経過時間 (
nsslapd-changelogmaxage
パラメーター)。 - 変更ログ内のレコード総数 (
nsslapd-changelogmaxentries
パラメーター)。
nsslapd-changelogtrim-interval
)。
15.18.1. レプリケーション変更ログのトリミング設定
nsDS5ReplicaPurgeDelay
parameter in the cn=replica,cn=suffixDN,cn=mapping tree,cn=config エントリーのパラメーター。
- 変更ログのトリミングを設定します。
- 変更ログエントリーの最長期間を設定するには、以下を入力します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com replication set-changelog --max-age "4w"
このコマンドは、最大経過時間を 4 週間に設定します。パラメーターは、以下の単位をサポートします。- s (S) (秒)
- m (M) (分)
- h (H) (時間)
- d (D) (日)
- w (W) (週間)
- エントリーの最大数を設定するには、以下を入力します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com replication set-changelog --max-entries "100000"
このコマンドは、変更ログのエントリーの最大数を 100,000 に設定します。
- デフォルトでは、Directory Server は変更ログを 5 分 (300 秒) ごとにトリミングします。別の間隔を設定するには、以下を入力します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com replication set-changelog --trim-interval 600
このコマンドは、間隔を 10 分 (600 秒) に設定します。
15.18.2. 大きな changelog のサイズを手動で縮小
前提条件
手順
- (オプション) 変更ログのサイズを表示します。
# ls -lh /var/lib/dirsrv/slapd-instance_name/changelogdb/ total 159M rw------. 1 dirsrv dirsrv 159M Nov 21 04:01 a1cf5703-697a11ed-896ed7a0-04f329b5_637b3daf000000010000.db rw------. 1 dirsrv dirsrv 30 Nov 21 03:58 DBVERSION
この例は /var/lib/dirsrv/slapd-instance_name/changelogdb/ ディレクトリーに、サイズが 159M の changelog ファイルが 1 つだけ含まれていることを示しています。 - 変更ログサイズを縮小した後にパラメーターをリセットできるようにするには、対応するパラメーターの現在の値を表示して書き留めます。
# dsconf instance_name replication get-changelog dn: cn=changelog5,cn=config cn: changelog5 nsslapd-changelogdir: /var/lib/dirsrv/slapd-instance_name/changelogdb/ nsslapd-changelogmaxage: 7d nsslapd-changelogtrim-interval: 300 objectClass: top objectClass: nsChangelogConfig
出力に特定の属性が表示されない場合、Directory Server はデフォルト値を使用します。 - 一時的に、トリミングに関連するパラメーターを減らします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com replication set-changelog --max-age "300s" --max-entries 500 --trim-interval 60
重要パフォーマンス上の理由から、短い間隔設定を永続的に使用しないでください。 --trim-interval
パラメーターに設定した時間が経過するのを待ちます。- 変更ログを圧縮して、ディスク領域を再度確保します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com backend compact-db --only-changelog
- 変更ログパラメーターを、一時的に減らす前の値にリセットします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com replication set-changelog --max-age "7d" --max-entries 0 --trim-interval 300
検証
- 変更ログのサイズを表示します。
# ls -lh /var/lib/dirsrv/slapd-instance_name/changelogdb/ total 14M rw------. 1 dirsrv dirsrv 14M Nov 21 05:08 a1cf5703-697a11ed-896ed7a0-04f329b5_637b3daf000000010000.db rw------. 1 dirsrv dirsrv 30 Nov 21 05:01 DBVERSION
15.19. レプリケーション更新の強制
前提条件
- レプリケーションが設定されている。
- コンシューマーが初期化されている。
手順
- レプリカ合意に更新スケジュールが設定されているかどうかを確認します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt get --suffix="dc=example,dc=com" agreement_name
コマンドの出力に nsDS5ReplicaUpdateSchedule: * が含まれている、またはnsDS5ReplicaUpdateSchedule
パラメーターが存在しない場合、更新スケジュールは設定されていません。nsDS5ReplicaUpdateSchedule
に、以下のようなスケジュールが含まれる場合には、値を書き留めておきます。nsDS5ReplicaUpdateSchedule: 0800-2200 0246
- 更新スケジュールが設定されている場合は、以下のコマンドを実行して一時的に無効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt set --schedule \* --suffix="dc=example,dc=com" agreement_name
- レプリカ合意を一時的に無効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt disable --suffix="dc=example,dc=com" agreement_name
- レプリカ合意を再度有効にして、レプリケーションの更新を強制的に実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt enable --suffix="dc=example,dc=com" agreement_name
- この手順の最初にレプリケーションスケジュールが設定されていた場合、スケジュールを以前の値に設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt set --schedule "0800-2200 0246" --suffix="dc=example,dc=com" agreement_name
15.20. レプリケーションのタイムアウト期間の設定
nsDS5ReplicaTimeout
は、レプリケーション操作がコンシューマーからの応答を待ってから、タイムアウトして失敗するまでの秒数を設定します。最適な数値を設定するには、アクセスログでレプリケーション処理にかかる平均時間を確認し、それに合わせてタイムアウト期間を設定します。nsDS5DebugReplicaTimeout
は、デバッグロギングが有効な場合にレプリケーション操作のタイムアウト期間を設定します。デバッグロギングではディレクトリー操作が遅くなる可能性があるため、この設定はnsDS5ReplicaTimeout
設定よりも大幅に高くなる可能性があります。この属性は任意で、このパラメーターが適用されるエラーログレベルを設定できます。デフォルトはレプリケーションのデバッグ (8192) です。
# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=example-agreement,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config changetype: modify add: nsDS5ReplicaTimeout nsDS5ReplicaTimeout: 600 - add: nsDS5DebugReplicaTimeout nsDS5DebugReplicaTimeout: 6000
15.21. Retro Changelog プラグインの使用
changeLogEntry
があります。changelog エントリーで可能な属性のリストは、『Red Hat Directory Server の設定、コマンド、およびファイルリファレンス』 の 『changelog 属性』 セクションを参照してください。
15.21.1. Retro Changelog プラグインの有効化
- 過剰な量のレプリケーショントラフィックが生成され、その半分は重複した更新です。
- retro 変更ログのトリミングに関連する削除操作でエラーが発生します。
- レプリケーションのパフォーマンスが非常に低く、サプライヤーでの更新が収束しません。
15.21.1.1. コマンドラインを使用した Retro Changelog プラグインの有効化
dsconf
ユーティリティーを使用してプラグインを有効にします。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin retro-changelog enable
- インスタンスを再起動します。
# dsctl instance_name restart
15.21.1.2. Web コンソールを使用した Retro Changelog プラグインの有効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 左側の一覧で Retro Changelog プラグインを選択します。
- ステータスを On に変更します。
- インスタンスを再起動します。「Web コンソールを使用した Directory Server インスタンスの起動および停止」を参照してください。
15.21.2. Retro Changelog のトリム
nsslapd-changelogmaxage
パラメーターで設定したレコードの最大年齢を下げ、nsslapd-changelog-trim-interval
で設定した次のトリミング間隔を実行すると、Retro Changelog のサイズが自動的に縮小されます。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin retro-changelog set --max-age="2d"
15.21.3. Retro Changelog の検索および変更
15.21.4. Retro Changelog およびアクセス制御ポリシーの見直し
cn=changelog
エントリーの aci
属性を変更します。たとえば、すべての許可されたユーザーに 読み取り、検索、および 比較 権限を付与する場合は、次の ACI を cn=changelog
に追加します。
dn: cn=changelog
aci: (targetattr="changeNumber || objectClass")(targetfilter="(objectClass=changelogentry)")
(version 3.0; acl "Enable authenticated users to read the retro changelog"; allow (read, search, compare)
(userdn="ldap:///all");)
aci
属性を修正する際は、匿名ユーザー (userdn=anyone
) に読み取り権限を付与しないでください。認証されたアプリケーションとユーザー () に対してのみ、この情報へのアクセスを許可してください。
15.22. 特定のレプリカ合意の状態の表示
15.22.1. コマンドラインを使用した特定のレプリカ合意の状態の表示
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt status --suffix="dc=example,dc=com" agreement_name agreement_name Status for agreement_name agmt consumer.example.com:636 Replica Enabled: on Update In Progress: FALSE Last Update Start: 19700101000000Z Last Update End: 19700101000000Z Number Of Changes Sent: 0 Number Of Changes Skipped: None Last Update Status: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) Init In Progress: Last Init Start: 19700101000000Z Last Init End: 19700101000000Z Last Init Status: unavailable Reap Active: 0 Replication Status: Not in Synchronization: supplier (5bed8467000100010000) consumer (Unavailable) Reason(Unknown) Replication Lag Time: Unavailable
consumer.example.com
ホストが利用できないため、現在レプリケーションが失敗することを示しています。
15.22.2. Web コンソールを使用した特定のレプリカ合意のステータスの表示
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 左側のペインの一覧から Replication エントリーを選択します。
- Directory Server インスタンスまたは Winsync Agreement 間のレプリカ合意の状態を表示するかどうかに応じて、該当するタブを選択します。Update Status 列には、レプリカ合意のステータスが表示されます。
15.23. レプリケーショントポロジーの監視
# dsconf -D "cn=Directory Manager" ldap://supplier.example.com replication monitor Enter password for cn=Directory Manager on ldap://supplier.example.com: password Enter a bind DN for consumer.example.com:389: cn=Directory Manager Enter a password for cn=Directory Manager on consumer.example.com:389: password Supplier: server.example.com:389 -------------------------------- Replica Root: dc=example,dc=com Replica ID: 1 Replica Status: Available Max CSN: 5e3acb77001d00010000 Status For Agreement: "example-agreement" (consumer.example.com:389) Replica Enabled: on Update In Progress: FALSE Last Update Start: 20200205140439Z Last Update End: 20200205140440Z Number Of Changes Sent: 1:166/0 Number Of Changes Skipped: None Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded Last Init Start: 20200205133709Z Last Init End: 20200205133711Z Last Init Status: Error (0) Total update succeeded Reap Active: 0 Replication Status: In Synchronization Replication Lag Time: 00:00:00 Supplier: consumer.example.com:389 ----------------------------------- Replica Root: dc=example,dc=com Replica ID: 65535 Replica Status: Available Max CSN: 00000000000000000000
15.23.1. .dsrc ファイルでのレプリケーション監視の認証情報の設定
~/.dsrc
ファイルのトポロジーで、バインド DN (および必要に応じて) パスワードを設定できます。
例15.1 .dsrc ファイルの例と各フィールドの説明
~/.dsrc
ファイルの例を以下に示します。
[repl-monitor-connections] connection1 = server1.example.com:389:cn=Directory Manager:* connection2 = server2.example.com:389:cn=Directory Manager:[~/pwd.txt] connection3 = hub1.example.com:389:cn=Directory Manager:S3cret
connection1
から connection3
を使用しています。ただし、キーが一意であれば、任意のキーを使用できます。
dsconf
ユーティリティーはインスタンスのレプリカ合意で設定されたすべてのサーバーに接続します。このユーティリティーが ~/.dsrc
でホスト名を見つけると、定義された認証情報を使用してリモートサーバーに対して認証されます。上記の例では、dsconf
はサーバーへの接続時に以下の認証情報を使用します。
ホスト名 | バインド DN | Password |
---|---|---|
server1.example.com | cn=Directory Manager | パスワードの入力を要求します。 |
server2.example.com | cn=Directory Manager | ~/pwd.txt からパスワードを読み取る |
hub1.example.com | cn=Directory Manager | S3cret |
15.23.2. レプリケーショントポロジーモニタリング出力でのエイリアスの使用
~/.dsrc
ファイルでエイリアスを定義します。[repl-monitor-aliases] M1 = server1.example.com:389 M2 = server2.example.com:389
-a alias=host_name:port
パラメーターを dsconf replication monitor コマンドに渡してエイリアスを定義します。# dsconf -D "cn=Directory Manager" ldap://server.example.com replication monitor -a M1=server1.example.com:389 M2=server2.example.com:389
... Supplier: M1 (server1.example.com:389) ... Supplier: M2 (server2.example.com:389) ...
15.24. 2 つの Directory Server インスタンスの比較
ds-replcheck
ユーティリティーを使用すると、2 つのオンラインサーバーを比較できます。また、ds-replcheck
では、オフラインモード 2 つの LDIF 形式のファイルを比較し、オンラインモードで 2 つのサーバーを比較することができます。
-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) をリスト表示します。以下に例を示します。
Supplier 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 エントリーを含む、両方のサーバー上のエントリーの合計数を表示します。以下に例を示します。
Supplier: 12 Replica: 10
- Tombstones
- 各レプリカの tombstone エントリーの数を表示します。これらのエントリーは、合計エントリー数に追加されます。以下に例を示します。
Supplier: 4 Replica: 2
- 競合エントリー
- 各競合エントリーの識別名 (DN)、競合タイプ、および作成された日付をリスト表示します。以下に例を示します。
Supplier 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 Supplier: - 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 Supplier at: Wed Apr 12 14:43:24 2017)
- エントリーの不整合
- 相手のサーバーとは異なる属性を持つエントリーの DN をリスト表示します。状態情報が利用可能な場合は、これも表示されます。属性の状態情報が利用できない場合には、元の値としてリスト表示されます。レプリケーションが初めて初期化されてから、値が更新されていないことを意味します。以下に例を示します。
cn=group1,dc=example,dc=com --------------------------- Replica missing attribute "objectclass": - Supplier's State Info: objectClass;vucsn-58e53baa000000020000: top - Date: Wed Apr 5 14:47:06 2017 - Supplier's State Info: objectClass;vucsn-58e53baa000000020000: groupofuniquenames - Date: Wed Apr 5 14:47:06 2017
15.25. 一般的なレプリケーションの競合の解決
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict list dc=example,dc=com
15.25.1. ネーミングの競合の解決
nsuniqueid
に保存されている一意の識別子が含まれます。命名の競合が発生すると、この一意の ID が一意でない DN に追加されます。
- uid=user_name,ou=People,dc=example,dc=com
- nsuniqueid=66446001-1dd211b2+uid=user_name,ou=People,dc=example,dc=com
- 有効なエントリー (uid=user_name,ou=People,dc=example,dc=com) を維持し、競合エントリーを削除するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict delete nsuniqueid=66446001-1dd211b2+uid=user_name,ou=People,dc=example,dc=com
- 競合エントリー (nsuniqueid=66446001-1dd211b2+uid=user_name,ou=People,dc=example,dc=com) のみを維持するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict swap nsuniqueid=66446001-1dd211b2+uid=user_name,ou=People,dc=example,dc=com
- 両方のエントリーを保持するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict convert --new-rdn=uid=user_name_NEW nsuniqueid=66446001-1dd211b2+uid=user_name,ou=People,dc=example,dc=com
競合エントリーを保持するには、--new-rdn
オプションで新しい Relative Distinguished Name (RDN) を指定して競合エントリーの名前を変更する必要があります。上記のコマンドは、競合エントリーの名前を uid=user_name_NEW,ou=People,dc=example,dc=com に変更します。
15.25.2. 孤立エントリーの競合の解決
- 競合解決手続で、一致する一意の識別子を持つ削除されたエントリーが見つかった場合、glue エントリーは、そのエントリーの再生であり、glue のオブジェクトクラスと
nsds5ReplConflict
の属性が追加されます。このような場合は、glue エントリーを変更して glue オブジェクトクラスとnsds5ReplConflict
属性を削除して、エントリーを通常のエントリーとして維持するか、その子エントリーを削除します。 - サーバーは glue および extensibleObject オブジェクトクラスを使用して最小のエントリーを作成します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict list-glue suffix
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict delete-glue DN_of_glue_entry
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict convert-glue DN_of_glue_entry
15.25.3. 廃止または不明なエラーの解決
[22/Jan/2021: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/2021: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 を削除することになります。
# dsconf -D "cn=Directory Manager" ldap://m2.example.com repl-tasks \ cleanallruv --suffix="dc=example,dc=com" --replica-id=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.26. レプリケーション関連の問題のトラブルシューティング
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-errorlog-level=8192
第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 エントリーと同期します。
- パスワード同期サービス。cn=config エントリーの
nsslapd-unhashed-pw-switch
パラメーターを on に設定すると、Directory Server で行ったパスワードの変更は Active Directory に自動的に同期されます。しかし、Active Directory 上のパスワード変更を認識して Directory Server に伝えるためには、特別なフックが必要です。これは、パスワード同期サービスにより実行されます。このアプリケーションは、Active Directory ドメインコントローラーのパスワード変更をキャプチャーして、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 を設定します。
- パスワードの有効期限の警告および時間、バインド試行の失敗、その他のパスワード関連の情報はサーバーごとにローカルで適用され、同期ピアサーバー間で同期されません。
- Windows サーバーが設定された Directory Server インスタンスで、cn=config エントリーの
nsslapd-unhashed-pw-switch
パラメーターを on に設定します。 - バインド動作は、すべてのサーバーで発生します。Directory Server サーバーおよび Active Directory サーバーの両方で、同じパスワードポリシーまたは同様のパスワードポリシーを作成してください。
- 同期用に作成されるエントリー (例: サーバーアイデンティティー) には有効期限のないパスワードが必要です。これらの特別なユーザーが期限切れにならないパスワードを持っていることを確認するために、Directory Server のエントリーに
passwordExpirationTime
属性を追加し、それに 20380119031407Z の値 (有効範囲の一番上) を指定します。
16.4. Active Directory と Directory Server の同期の設定
16.4.1. ステップ 1: Directory Server ホストで TLS の有効化
16.4.2. ステップ 2: AD ドメインでのパスワード複雑性の有効化
- Group Policy Management コンソールを開き、ドメインに新しい Group Policy Object (GPO) を作成します。Group Policy Management コンソールの使用に関する詳細は、Windows ドキュメントを参照してください。
- GPO を右クリックし、Edit を選択して Group Policy Management Editor を開きます。
- Password must meet complexity requirements という名前のポリシーをダブルクリックします。→ → → → に移動し、
- ポリシーを有効にし、をクリックします。
- Group Policy Management Editor および Group Policy Management コンソールを閉じます。
16.4.3. ステップ 3: AD からの CA 証明書の抽出
- AD CA 証明書が自己署名の場合は、以下を実行します。
- Certification Authority アプリケーションがインストールされている AD DC で Super key+R の組み合わせを押して Run ダイアログを開きます。
- certsrv.msc コマンドを入力して をクリックすると、Certification Authority アプリケーションが開きます。
- ローカルの認証局の名前を右クリックし、Properties を選択します。
- 全般 タブで、CA certificates フィールドでエクスポートする証明書を選択し、 をクリックします。
- 詳細 タブで、 をクリックして 証明書のエクスポートウィザード を起動します。
- base-64 でエンコードされた X.509 (.CER) を選択します。をクリックしてから、
- エクスポートされたファイルに適切なディレクトリーおよびファイル名を指定します。をクリックして証明書をエクスポートしてから、 をクリックします。
- ルート CA 証明書を Directory Server ホストにコピーします。
- AD CA 証明書が外部 CA により署名されている場合は、以下を行います。
- ルート CA を指定します。以下に例を示します。
# openssl s_client -connect adserver.example.com:636 CONNECTED(00000003) depth=1 C = US, O = Demo Company, OU = IT, CN = Demo CA-28 verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/O=Demo Company/OU=IT/CN=adserver.example.com i:/C=US/O=Demo Company/OU=IT/CN=Demo CA-1 1 s:/C=US/O=Demo Company/OU=IT/CN=Demo CA-1 i:/C=US/O=Demo Company/OU=IT/CN=Demo Root CA 2
上記の例では、AD サーバーの CA 証明書は、CN=Demo Root CA 2
で署名されたCN=Demo CA-1
で署名されています。つまり、CN=Demo Root CA 2
が root CA であることがわかります。 - CA 証明書の取得方法についてのルート CA の Operator にお問い合わせください。
- ルート CA 証明書を Directory Server ホストにコピーします。
16.4.4. ステップ 4: Directory Server の NSS データベースから CA 証明書の拡張
- データベースの証明書をリスト表示します。
# certutil -d /etc/dirsrv/slapd-instance_name/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u Example CA C,,
- データベースから CA 証明書を抽出します。たとえば、
Example CA
ニックネームで CA 証明書を抽出し、/root/ds-ca.crt
ファイルに保存します。# certutil -d /etc/dirsrv/slapd-instance_name/ -L -n "Example CA" -a > /root/ds-ca.crt
- CA 証明書を AD DC にコピーします。
16.4.5. ステップ 5: 同期アカウントの作成
Directory Server でのアカウントの作成
Password Sync
サービスの Directory Server アカウントを使用して、パスワードを Directory Server と同期します。たとえば、Directory Server で cn=pw_sync_user,dc=config
ユーザーを作成するには、次のコマンドを実行します。
- ユーザーアカウントを作成します。
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=pw_sync_user,cn=config objectClass: inetorgperson objectClass: person objectClass: top cn: pw_sync_user sn: pw_sync_user userPassword: password passwordExpirationTime: 20380101000000Z
これにより、cn=pw_sync_user,dc=config
アカウントが作成され、その有効期限が 2038 年 1 月 1 日に設定されます。重要セキュリティー上の理由から、同期されたサブツリーにアカウントを作成しないでください。 - 同期されるサブツリーの上部に ACI を設定し、write および compare パーミッションを
cn=pw_sync_user,dc=config
ユーザーに付与します。たとえば、このような ACI を 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: (targetattr="userPassword")(version 3.0;acl "Password synchronization"; allow (write,compare) userdn="ldap:///cn=pw_sync_user,dc=config";)
- Directory Server が、パスワードをクリアテキストで保存できるように設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-unhashed-pw-switch=on
Directory Server は Active Directory 以外のパスワード暗号化を使用するため、Directory Server は、パスワードをクリアテキストで Windows サーバーに送信する必要があります。ただし、クリアテキストパスワードは、パスワードの同期に必要な TLS 暗号化接続で送信されるため、ネットワークに公開されません。
AD でのアカウントの作成
Domain Admins
グループのメンバーであるか、AD に同等のパーミッションがある必要があります。AD アカウントの作成方法は、AD ドキュメントを参照してください。
16.4.6. ステップ 6: Password Sync サービスのインストール
16.4.7. ステップ 7: Password Sync サービスの証明書データベースを使用するように CA Certificate Directory Server を追加
C:\Program Files\Red Hat Directory Password Synchronization\
ディレクトリーに移動します。> cd "C:\Program Files\Red Hat Directory Password Synchronization\"
- 現在のディレクトリーに証明書データベースを作成します。
> certutil.exe -d . -N
certutil.exe
ユーティリティーは、作成する新規データベースにパスワードを設定するようにプロンプトを表示します。 - Directory Server インスタンスが使用する CA 証明書をインポートします。「ステップ 4: Directory Server の NSS データベースから CA 証明書の拡張」にあるこの証明書を Windows DC にコピーしました。たとえば、
C:\ds-ca.crt
ファイルから証明書をインポートし、Example CA
ニックネームを使用してこれをデータベースに保存するには、以下を実行します。> certutil.exe -d . -A -n "Example CA" -t CT,, -a -i "C:\ds-ca.crt"
- 必要に応じて、CA 証明書がデータベースに正しく保存されていることを確認します。
> certutil.exe -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Example CA CT,,
- Windows DC を再起動します。システムを再起動するまで、Password Sync サービスは利用できません。
16.4.8. ステップ 8: AD が使用する CA 証明書を Directory Server の証明書データベースに追加
- AD が使用する CA 証明書をインポートします。「ステップ 3: AD からの CA 証明書の抽出」にある証明書を Directory Server ホストにコピーしている。たとえば、
/root/ad-ca.crt
ファイルから証明書をインポートし、Example CA
ニックネームを使用してこれをデータベースに保存するには、以下を実行します。> certutil -d /etc/dirsrv/slapd-instance_name/ -A -n "Example CA" -t CT,, -a -i /root/ad-ca.crt
- 必要に応じて、CA 証明書がデータベースに正しく保存されていることを確認します。
> certutil -d /etc/dirsrv/slapd-instance_name/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ... Example CA CT,,
16.4.9. ステップ 9: 同期用のデータベースの設定および同期合意の作成
16.4.9.1. コマンドラインを使用した同期用のデータベースの設定および同期合意の作成
ds.example.com
という名前のホストで実行され、AD DC が win-server.ad.example.com
という名前のホストで実行していることを前提としています。以下の手順では、これらのホスト間で同期を設定する方法を説明します。
- 接尾辞のレプリケーションを有効にします。
# dsconf -D "cn=Directory Manager" ldap://ds.example.com replication \ enable --suffix="dc=example,dc=com" --role="supplier" --replica-id=1
このコマンドは、ds.example.com
ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。重要トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。 - 同期合意を追加し、合意を初期化します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://ds.example.com repl-winsync-agmt \ create --suffix="dc=example,dc=com" --host="win-server.ad.example.com" --port=636 \ --conn-protocol="LDAPS" --bind-dn="cn=user_name,cn=Users,dc=ad,dc=example,dc=com" \ --bind-passwd="password" --win-subtree="cn=Users,dc=example,dc=com" \ --ds-subtree="ou=People,dc=example,dc=com" --win-domain="AD" \ --init example-agreement
このコマンドは、example-agreement という名前のレプリカ合意を作成します。レプリカ合意は、AD DC のホスト名、プロトコル、認証情報などの設定を定義します。Directory Server は、データを DC に接続して同期するときに使用します。この合意の作成後、Directory Server は合意を初期化します。後で合意を初期化するには、--init
オプションを省略します。合意を初期化する前に同期は開始されないことに注意してください。同期合意の初期化に関する詳細は、「コマンドラインを使用した完全同期の実行」を参照してください。必要に応じて、--sync-users="on"
および--sync-groups="on"
オプションをコマンドに渡して、新しい Windows ユーザーおよびグループを Directory Server に自動的に同期します。コマンドで使用するオプションの詳細は、以下を入力します。# dsconf -D "cn=Directory Manager" ldap://ds.example.com repl-agmt --help
- 初期化が成功したことを確認します。
# dsconf -D "cn=Directory Manager" ldap://ds.example.com repl-winsync-agmt \ init-status --suffix="dc=example,dc=com" example-agreement Agreement successfully initialized.
16.4.9.2. Web コンソールを使用した同期用のデータベースの設定および同期合意の作成
ds.example.com
という名前のホストで実行され、AD DC が win-server.ad.example.com
という名前のホストで実行していることを前提としています。以下の手順では、これらのホスト間で同期を設定する方法を説明します。
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 接尾辞のレプリケーションを有効にします。
- dc=example,dc=com 接尾辞を選択し、 をクリックします。
- Replication Role フィールドで Supplier を選択し、レプリカ ID を入力します。以下に例を示します。これらの設定は、
ds.example.com
ホストを dc=example,dc=com 接尾辞のサプライヤーとして設定し、このエントリーのレプリカ ID を 1 に設定します。重要トポロジー内のすべてのサプライヤーの接尾辞については、レプリカ ID は 1 から 65534 の間の一意の整数である必要があります。
- 同期合意を追加し、合意を初期化します。
- この設定により、
example-agreement
という名前の同期合意が作成されます。同期契約では、DC のホスト名、プロトコル、認証情報など、Directory Server が接続してデータを同期する際に使用する設定を定義します。必要に応じて、Sync New Windows Users および Sync New Windows Groups を選択すると、新しい Windows ユーザーおよびグループが Directory Server に自動的に同期されます。この合意の作成後、Directory Server は合意を初期化します。後で合意を初期化するには、Do Online Initialization を選択しないでください。合意を初期化する前に同期は開始されないことに注意してください。同期合意の初期化に関する詳細は、「Web コンソールを使用した完全同期の実行」を参照してください。
- 初期化が成功したことを確認します。
- 初期化が正常に完了すると、Web コンソールは Last Update Status 列に Error (0) Replica acquired successfully: Incremental update succeeded メッセージを表示します。同期するデータの量によっては、初期化に最大数時間かかる場合があります。
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 ユーザーのユーザー同期の設定
- ntUser オブジェクトクラス。
- Windows ID を指定する
ntUserDomainId
属性 ntUserCreateNewAccount
属性は、同期プラグインに Active Directory 経由で Directory Server エントリーを同期するように通知します。
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 ユーザーのユーザー同期の設定
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-winsync-agmt set --sync-users="on" --suffix="dc=example,dc=com" example-agreement
--sync-users
オプションを 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 グループのグループ同期の設定
- 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 グループのグループ同期の設定
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-winsync-agmt set --sync-groups="on" --suffix="dc=example,dc=com" example-agreement
--sync-groups
オプションを off に設定します。
16.7. 一方向の同期の設定
oneWaySync
は、一方向の同期を有効にし、変更を送信する方向を指定します。使用できる値は fromWindows
(Active Directory から Directory Server への同期の場合) および toWindows
(Directory Server から Active Directory の同期の場合) です。この属性がない場合、同期は双方向になります。
図16.3 一方向の同期
--one-way-sync="direction"
オプションを使用して、以下のいずれかの状況で一方向同期を有効にします。
- 「ステップ 9: 同期用のデータベースの設定および同期合意の作成」 で新しい同期合意を作成する場合は、オプションを dsconf repl-winsync-agmt create コマンドに渡します。
- 同期合意がすでに存在する場合は、合意を更新します。たとえば、AD から Directory Server への同期を設定するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-winsync-agmt set --one-way-sync="fromWindows" --suffix="dc=example,dc=com" example-agreement
toWindows
に設定されている場合でも、Active Directory サーバー上のパスワードを更新した後に、パスワードは Directory Server に送信されます。
16.8. Windows 同期での複数のサブツリーおよびフィルターの設定
Windows 同期における複数のサブツリー
winSyncSubtreePair
パラメーターに Directory Server サブツリーと Active Directory サブツリーを設定します。たとえば、複数の ou=OU1,dc=DSexample,dc=com および ou=OU1,DC=ADexample,DC=com サブツリーを設定するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-winsync-agmt set --subtree-pair="ou=OU1,dc=DSexample,dc=com:ou=OU1,DC=ADexample,DC=com" --suffix="dc=example,dc=com" example-agreement
winSyncSubtreePair
が設定されていない場合は、代わりに nsds7WindowsReplicaSubtree
AD サブツリーパラメーターと nsds7DirectoryReplicaSubtree
DS サブツリーパラメーターが同期ターゲットチェックに使用されます。それ以外の場合は、この 2 つのパラメーターは無視されます。
Windows 同期のフィルター
--win-filter
は、Active Directory サーバーに追加のフィルターを設定します。--ds-filter
パラメーターは、Directory Server に追加のフィルターを設定します。
user
属性および group
属性が含まれるエントリーを example_agreement
が同期するように設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-winsync-agmt \ set --win-filter="(|(cn=*user*)(cn=*group*))" --ds-filter="(|(uid=*user*)(cn=*group*))" \ example_agreement
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 属性同期の有効化
- プラグインを有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin "cn=Posix Winsync API,cn=plugins,cn=config" enable
- インスタンスを再起動します。
# dsctl instance_name restart
16.9.2. Posix グループ属性の同期設定の変更
- 以下のコマンドを使用して、ネストされたグループマッピングを有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin posix-winsync set --map-nested-grouping="true"
- Directory Server を再起動して、新しい設定を読み込みます。
# dsctl instance_name restart
16.9.3. posixGroup エントリーの member 属性と uniqueMember 属性の値の不一致の修正
posixGroup
エントリーで member
属性値および uniqueMember
属性値が一致しない場合は、dsconf plugin posix-winsync fixup コマンドを使用して問題を修正します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin posix-winsync fixup DN
memberUid
の値を再作成し、AD で定義された値に一致するように member
属性値および uniqueMember
属性値を自動的に変更します。
-f filter
パラメーターをコマンドに渡して、コマンドが memberUid
属性を修正するエントリーを指定します。フィルターなしでは、コマンドは inetuser、inetadmin、および nsmemberof オブジェクトクラスが含まれるすべてのエントリーで動作します。
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. 手動増分同期の実行
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-winsync-agmt poke --suffix="dc=example,dc=com" example-agreement
16.11.2. 完全同期の実行
16.11.2.1. コマンドラインを使用した完全同期の実行
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-winsync-agmt init --suffix="suffix" agreement_name
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-winsync-agmt init-status --suffix="suffix" agreement_name
16.11.2.2. Web コンソールを使用した完全同期の実行
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 同期合意の横にある Full Re-Synchronization を選択します。メニューを開き、再同期は、同期ピアのデータを削除しません。プロセスは、すべての更新を送受信して、新規または変更した Directory Server エントリーを追加します。たとえば、このプロセスは、ntUser オブジェクトクラスが追加される既存の Directory Server ユーザーを追加します。
- 同期が正常に完了すると、Web コンソールは Last Update Status 列に Error (0) Replica acquired successfully: Incremental update succeeded メッセージを表示します。
16.11.3. 同期スケジュールの設定
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.11.4. 同期接続の変更
- バインドユーザー名およびパスワード (
nsDS5ReplicaBindDN
およびnsDS5ReplicaCredentials
) - 接続方法 (
nsDS5ReplicaTransportInfo
)。nsDS5ReplicaTransportInfo
は LDAP から StartTLS に (その逆も) しか変更できません。LDAPS への変更、または LDAPS からの変更はポート番号を変更することができないため、LDAP と LDAPS の切り替えにはポート番号の変更が必要となります。
nsDS5ReplicaBindDN: cn=sync user,cn=Users,dc=ad1 nsDS5ReplicaCredentials: {DES}ffGad646dT0nnsT8nJOaMA== nsDS5ReplicaTransportInfo: StartTLS
16.11.5. 同期しているサブツリーから移動するエントリーの処理
samAccount
と Directory Server の uid
属性に基づいて相関します。同期プラグインは、(samAccount/uid
関係に基づいて) エントリーが削除または移動されたために、同期されたサブツリーから削除された場合、その旨を通知します。これは、同期プラグインに対して、そのエントリーがもう同期されないことを示す信号です。
samAccount
ID が jsmith のユーザーは、Active Directory の ou=Employees サブツリーに作成されています。同期されたサブツリーは ou=Users であるため、jsmith ユーザーは Directory Server に同期されませんでした。
図16.4 Active Directory ツリー
samAccount/uid
関係) に対応し、同期サブツリーの外にあるエントリーを、意図的に 同期サブツリーの外に移動させることを前提としています (基本的には名前の変更操作)。対応する Directory Server エントリーを削除する必要があることを前提とします。
図16.5 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 システムとの互換性でのみ利用できます。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-winsync-agmt --move-action="action" --suffix="suffix" agreement_name
16.12. トラブルシューティング
レプリケーションロギングを有効にして同期エラーを記録する
エラー #1: 同期後、ステータスは error 81 を返します。
エラー #2: エントリーは Active Directory のサブツリーから別のサブツリーに移動していますが、ユーザーは Directory Server の対応するサブツリーに移動していません。
第17章 SyncRepl
プロトコルを使用したコンテンツ同期の設定
Content Synchronization
プラグインを使用すると、Directory Server は RFC 4533 に従って SyncRepl
プロトコルをサポートします。このプロトコルにより、LDAP サーバーとクライアントは Red Hat Directory Server をソースとして使用し、ローカルデータベースを Directory Server の変更するコンテンツと同期させることができます。
SyncRepl
プロトコルを使用するには、以下を実行します。
- Directory Server で
Content Synchronization
プラグインを有効にし、必要に応じてクライアントが Directory Server にバインドするために使用する新規ユーザーを作成します。アカウントには、ディレクトリー内のコンテンツを読み取るパーミッションが必要です。 - クライアントを設定します。たとえば、同期するサブツリーの検索ベースを設定します。詳細は、クライアントのドキュメントを参照してください。
17.1. コマンドラインを使用した Content Synchronization
プラグインの設定
Content Synchronization
プラグインを設定するには、以下を実行します。
Content Synchronization
プラグインでは、nsuniqueid
属性をログに記録するのにRetro Changelog
プラグインが必要です。- Retro Changelog が有効になっているかどうかを確認するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin retro-changelog show ... nsslapd-pluginEnabled: off
nsslapd-pluginEnabled
パラメーターが off に設定されている場合、Retro Changelog は無効になります。有効にする場合は、「Retro Changelog プラグインの有効化」を参照してください。 nsuniqueid
属性を、Retro Changelog プラグインの設定に追加します。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin retro-changelog set --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
サブツリーを除外するには、以下を入力します。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin retro-changelog set --exclude-suffix "cn=demo,dc=example,dc=com"
Content Synchronization
プラグインを有効にします。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin set --enabled on "Content Synchronization"
- デフォルトの 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 を再起動します。
# dsctl instance_name restart
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 のみが適用されます。注記add 権限を持つ 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 オブジェクトにアクセスする場合、ディレクトリーサーバーは、まず dc=example,dc=com と ou=People,dc=example,dc=com からの ACI でセットを作成します。Directory Server は、適用可能な ACI のリストを、ターゲットエントリーから一番上の接尾辞までボトムアップで作成します。ただし、このリストはセットとして考えてください。クライアントアプリケーションは、ACI 評価の順序を予測するべきではありません。サーバーは、この初期セットから適用可能な ACI の最終セットを作成するリソースエントリーに一致する ACI を選択します。次に、最初に権限を拒否する ACI を評価します。DENY ACI が正常に評価された場合、操作は失敗します。DENY ACI が見つからない場合、Directory Server は ALLOW パーミッションを付与する ACI が存在するかどうかを確認します。ACI の少なくとも 1 つがアクセスを許可する場合、Directory Server はアクセスを許可します。ALLOW パーミッションを付与する ACI がない場合、Directory Server はアクセスを拒否し、操作は失敗します。
organizationalUnit
エントリーまたは locality
エントリーのレベルで作成できます。
18.3. ACI 構造
aci
属性は以下の構文を使用します。
(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)
target_rule
は、アクセスを制御するためのエントリー、属性、またはエントリーと属性のセットを指定します。詳細については、「ターゲットの定義」 を参照してください。version 3.0
は、ACI バージョンを識別する必須の文字列です。aci "ACL_name"
は、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 の追加
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.7.3. 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.7.4. ACI の更新
18.8. Web コンソールを使用した ACI 管理
18.8.1. LDAP ブラウザーでのアクセス制御命令の作成
前提条件
- Web コンソールへのアクセス。
- Red Hat Directory Server に存在する親エントリー。
手順
- Web コンソールにログインし、をクリックします。
- Web コンソールがインターフェイスをロードしたら、 をクリックします。
- LDAP エントリーを選択し、Options メニューをクリックします。
- ドロップダウンメニューからを選択します。
- LDAP ブラウザーウィザードを使用して ACI を作成する場合、次の 2 つのオプションがあります。
- ウィザードの手順に従い、各手順を完了したらボタンをクリックします。
- ACI を作成するには、ウィザードが生成したデータを確認し、をクリックします。
- ウィザードウィンドウを閉じるには、ボタンをクリックします。
検証
18.8.2. LDAP ブラウザーでのアクセス制御命令の編集
前提条件
- Web コンソールへのアクセス。
- Red Hat Directory Server に存在する親エントリー。
手順
- Web コンソールにログインし、をクリックします。
- Web コンソールがインターフェイスをロードしたら、 をクリックします。
- LDAP エントリーを選択し、Options メニューをクリックします。
- ドロップダウンメニューからを選択します。
- Options メニューをクリックし、を選択します。
- テキストフィールドの命令を変更し、をクリックします。
検証
18.8.3. LDAP ブラウザーでのアクセス制御命令の削除
前提条件
- Web コンソールへのアクセス。
- Red Hat Directory Server に存在する親エントリー。
手順
- Web コンソールにログインし、をクリックします。
- Web コンソールがインターフェイスをロードしたら、 をクリックします。
- LDAP エントリーを選択し、Options メニューをクリックします。
- ドロップダウンメニューからを選択し、 ウィンドウを開きます。
- 削除する ACI のノードオプションアイコンをクリックし、を選択します。
検証
18.9. ターゲットの定義
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: ターゲットの種類を設定します。「よく使用されるターゲットキーワード」を参照してください。
- comparison_operator: 有効な値は = および != で、ターゲットが式で指定されたオブジェクトであるかを示します。警告セキュリティー上の理由から、Red Hat は、他のすべてのエントリーまたは属性で指定の操作を許可するため、!= 演算子を使用しないことを推奨します。以下に例を示します。
(targetattr != "userPassword");(version 3.0; acl "example"); allow (write) ... );
前の例では、ACI を設定する識別名 (DN) の下にあるuserPassword
属性以外の属性の設定、更新、または削除を行うことができます。ただし、これにより、ユーザーはこの属性への書き込みアクセスを許可するaci
属性を追加することもできます。 - expression: ターゲットを設定し、引用符で囲む必要があります。式自体は使用するキーワードによって異なります。
18.9.1. よく使用されるターゲットキーワード
- target: 「ディレクトリーエントリーのターゲット」 を参照してください。
- targetattr: 「ターゲット属性」 を参照してください。
- targetfilter: 「LDAP フィルターを使用したエントリーと属性の対象」 を参照してください。
- targattrfilters: 「LDAP フィルターを使用した属性値のターゲット」 を参照してください。
18.9.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: ou=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.9.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.9.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
属性をターゲットにするには、次のコマンドを実行します。
(targetfilter = "(uid=adm*) ...)
18.9.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.9.2. 詳細なターゲットキーキーワード
18.9.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.9.3. ターゲットルールの高度な使用方法
18.9.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") (targattrfilters="add=objectclass:(|(objectclas=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.9.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.9.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.9.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.10. パーミッションの定義
(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: ou=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.10.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.10.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.10.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.11. バインドルールの定義
- DNS
- グループメンバーシップまたは割り当てられたロール
- エントリーがバインドする場所
- バインド時に使用する必要のある認証の種類
- バインドが実行される回数または日数
(target_rule) (version 3.0; acl "ACL_name"; permission_rule bind_rules;)
構文
keyword comparison_operator "expression"
- keyword: bind 操作のタイプを設定します。「頻繁に使用されるバインドルール」を参照してください。
- comparison_operator: 有効な値は = および != で、ターゲットが式で指定されたオブジェクトであるかを示します。キーワードが追加の比較演算子に対応している場合は、該当するセクションで説明されます。
- expression: 式を設定し、引用符で囲む必要があります。式自体は使用するキーワードによって異なります。
18.11.1. 頻繁に使用されるバインドルール
- userDN: 「ユーザーベースのアクセスの定義」 を参照してください。
- groupdn: 「グループベースのアクセスの定義」 を参照してください。
18.11.1.1. ユーザーベースのアクセスの定義
userdn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."
- DN: 「userdn キーワードでの DN の使用」を参照してください。
- LDAP フィルター: 「LDAP フィルターで userdn キーワードの使用」を参照してください。
- anyone エイリアス: 「匿名アクセスの付与」 を参照してください。
- all エイリアス: 「認証済みユーザーへのアクセスの付与」 を参照してください。
- self エイリアス: 「ユーザーが空のエントリーにアクセスできるようにする」 を参照してください。
- parent エイリアス: 「ユーザーの子エントリーへのアクセス設定」 を参照してください。
18.11.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.11.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.11.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.11.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.11.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.11.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.11.1.2. グループベースのアクセスの定義
member
uniqueMember
memberURL
memberCertificateDescription
groupdn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."
- DN。「groupdn キーワードでの DN の使用」を参照してください。
- LDAP フィルター。「LDAP フィルターで groupdn キーワードの使用」を参照してください。
18.11.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.11.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.11.2. さらなるバインドルール
18.11.2.1. 値の一致に基づくアクセスの定義
userattr comparison_operator "attribute_name#bind_type_or_attribute_value
18.11.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.11.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.11.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) userattr = manager#ROLEDN;)
18.11.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.11.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.11.2.1.6. 継承による 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.25 継承による 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.11.2.2. 特定の IP アドレスまたは範囲からのアクセスの定義
ip comparison_operator "IP_address_or_range"
例18.26 バインドルールでの IPv4 アドレス範囲の使用
192.0.2.0/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.0/24"; deny (all) (userdn = "ldap:///anyone") and (ip != "192.0.2.");)
例18.27 バインドルールでの 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.11.2.3. 特定のホストまたはドメインからアクセスの定義
dns comparison_operator "host_name_or_domain_name"
例18.28 特定のホストからのアクセスの定義
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.29 特定のドメインからアクセスの定義
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.11.2.4. 接続に一定レベルのセキュリティーの要求
ssf comparison_operator key_strength
- = (等しい)
- ! (等しくない)
- < (未満)
- > (超過)
- <= (以下)
- >= (以上)
例18.30 接続に一定レベルのセキュリティーの要求
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") and (ssf >= "128");)
18.11.2.5. 曜日の特定の日におけるアクセスの定義
dayofweek comparison_operator "comma-separated_list_of_days"
例18.31 特定の曜日にアクセスの付与
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.11.2.6. 特定の時刻におけるアクセスの定義
timeofday comparison_operator "time"
- = (等しい)
- ! (等しくない)
- < (未満)
- > (超過)
- <= (以下)
- >= (以上)
例18.32 特定の時刻におけるアクセスの定義
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.11.2.7. 認証方法に基づいたアクセスの定義
authmethod comparison_operator "authentication_method"
- none: 認証は不要で、匿名のアクセスを表します。これはデフォルトになります。
- simple: クライアントは、ディレクトリーにバインドするユーザー名とパスワードを提供する必要があります。
- SSL: クライアントは、データベース、スマートカード、または他のデバイスのいずれかで TLS 証明書を使用してディレクトリーにバインドする必要があります。証明書ベースの認証の詳細は、「証明書ベースのクライアント認証の使用」を参照してください。
- SASL: クライアントは、Simple Authentication and Security Layer (SASL) 接続を介してディレクトリーにバインドする必要があります。bind ルールでこの認証方法を使用する場合は、EXTERNAL などの SASL メカニズムも指定します。
例18.33 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.11.2.8. ロールに基づくアクセスの定義
roledn comparison_operator "ldap:///distinguished_name || ldap:///distinguished_name || ..."
例18.34 ロールに基づくアクセスの定義
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.11.3. ブール演算子を使用したバインドルールの組み合わせ
bind_rule_1 boolean_operator bind_rule_2...
例18.35 ブール演算子を使用したバインドルールの組み合わせ
# 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)
AND および OR 演算子には優先順位がありません。
18.12. エントリーのアクセス権利の確認 (Get Effective Rights)
- 管理者は、ディレクトリーに対するアクセス制御手順をより適切に整理するために、get effective rights コマンドを使用できます。あるグループのユーザーが閲覧または編集できる内容を、別のグループと比較して制限する必要があることがよくあります。たとえば、QA Managers グループのメンバーには、
manager
やsalary
などの属性を検索および読み取る権利がありますが、HR Group メンバーのみが変更または削除する権限を持ちます。ユーザーまたはグループの実効権限を確認する方法は、適切なアクセス制御が有効であることを確認する方法です。 - ユーザーは、get effective rights コマンドを実行して、個人エントリーで表示または変更できる属性を確認することができます。たとえば、ユーザーは
homePostalAddress
やcn
などの属性にアクセスできますが、manager
属性およびsalary
属性への読み取りアクセスしかできません。
18.12.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.12.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.12.3. GER 検索の例
18.12.3.1. アクセス権限の確認に関する一般的な例
-D
と -E
オプションの両方により、そのエントリーは要求元として付与されます。-b
オプションには、個人エントリーを確認するため、その DN も含まれます。
例18.36 個人の権利の確認 (ユーザー 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.37 別のユーザーの権限を個人的に確認 (ユーザー 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 ... 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.38 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 ... 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.39 個人のエントリーに対する他ユーザーの権利の確認
# 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 ... 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.12.3.2. Non-Existent 属性の Get Effective Rights 検索の例
userPassword
の値が削除された場合、上記のエントリーで将来的に有効な権利を検索しても、自己書き込みおよび自己削除の権利が許可されていても、userPassword
に対する有効な権利は返されません。
例18.40 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.12.3.3. 特定の属性またはオブジェクトクラスの Get Effective Rights 検索の例
例18.41 特定の属性に対する 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.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=*)" uidNumber@posixAccount
...
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.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=*)" *@posixaccount
...
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.12.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.12.3.5. 操作属性の get effective rights 検索の例
例18.44 操作属性に対する 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.12.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.45 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.46 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.12.4. Get Effective Rights 戻りコード
コード | 説明 |
---|---|
0 | 正常に完了しました。 |
1 | 操作エラー。 |
12 | 重要な拡張機能は利用できません。重大度式が true に設定され、クエリー対象のエントリーに有効な権限がない場合は、このエラーが返されます。 |
16 | そのような属性はありません。アクセス権のために特定の属性をクエリーしましたが、その属性がスキーマに存在しない場合は、このエラーが返されます。 |
17 | 未定義の属性タイプ。 |
21 | 無効な属性構文。 |
50 | 権限が不十分。 |
52 | 利用できません。 |
53 | 不本意なパフォーマンス。 |
80 | その他。 |
18.13. アクセス制御情報のロギング
nsslapd-errorlog-level
パラメーターを 128 (アクセス制御リストの処理) が含まれる値に設定します。エラーログレベルの設定に関する詳細は「ログレベルの設定」を参照してください。
18.14. 高度なアクセス制御: マクロ ACI の使用
18.14.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.14.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.14.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.14.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.14.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.15. Directory Manager でのアクセス制御の設定
18.15.1. Directory Manager アカウントのアクセス制御
- 時間ベースのアクセス制御 (例: 8a.m. から 5p.m)(0800 から 1700)、および曜日のアクセス制御により、アクセスは明示的に定義された日数でのみ許可されます。これは「曜日の特定の日におけるアクセスの定義」および「特定の時刻におけるアクセスの定義」に類似しています。
- 指定した IP アドレス、ドメイン、またはサブネットのみが明示的に許可または拒否される IP アドレスルール。これは、「特定の IP アドレスまたは範囲からのアクセスの定義」に類似しています。
- ホストアクセスルール。指定されたホスト名、ドメイン名、またはサブドメインのみが明示的に許可または拒否されます。これは、「特定のホストまたはドメインからアクセスの定義」に類似しています。
18.15.2. RootDN アクセス制御プラグインの設定
RootDN Access Control
プラグインを有効にし、適切なアクセス制御ルールを設定します。
RootDN Access Control
プラグインを有効にします。# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin root-dn enable Plugin 'RootDN Access Control' enabled ...
- アクセス制御命令にバインドルールを設定します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin root-dn set --open-time=0600 --close-time=2100 --allow-host="*.example.com" --deny-host="*.remote.example.com"
以下のパラメーターを設定できます。- 時間ベースのアクセス制御の場合は
--open-time
および--close-time
。 - 日ベースのアクセス制御の場合は
--days-allowed
。 - ホストベースのアクセス制御用の
--allow-host
、--deny-host
、--allow-ip
、および--deny-ip
これらはすべての多値の属性であり、ワイルドカードを使用して IP 範囲またはドメインを許可または拒否することができます。重要拒否ルールの優先度は、許可ルールより高く設定されます。たとえば、--allow-host
パラメーターが *.example.com に設定され、--deny-host
が *.front-office.example.com に設定されている場合は、Directory Manager が阻止されているため、front-office.example.com サブドメインのすべてのホストからのアクセスが阻止されます。
- Directory Server を再起動します。
# dsctl instance_name restart
第19章 ヘルスチェック機能を使用した問題の特定
コンポーネント | 重大度 | 結果コード | 説明 |
---|---|---|---|
バックエンド | 低 | DSBLE0003 | データベースは初期化されませんでした。データベースは作成されましたが、データベースが空です。 |
バックエンド | 中 | DSBLE0001 | バックエンドのマッピングツリーエントリーが設定にありません。 |
コンフィグ | 低 | DSCLE0001 | 高解像度のタイムスタンプが無効になります。 |
コンフィグ | 高 | DSVIRTLE0001 | 仮想属性が誤ってインデックス化されています。ロールまたは CoS (Class of Service) 定義で使用されるインデックス化された属性により、検索結果が破損する可能性があります。 |
オペレーティングシステム | 中 | DSPERMLE0001 | /etc/resolve.conf ファイルに設定されているパーミッションは、0644 とは異なります。 |
オペレーティングシステム | 高 | DSDSLE0001 | ディスク領域不足 |
オペレーティングシステム | 高 | DSPERMLE0002 | /etc/dirsrv/slapd-instance_name/pin.txt および /etc/dirsrv/slapd-instance_name/pwdfile.txt ファイルに設定された権限は、0400 とは異なります。 |
プラグイン | 低 | DSRILE0001 | 更新の遅延は Referential Integrity プラグインに設定されます。これにより、レプリケーションの問題が発生する可能性があります。 |
プラグイン | 高 | DSRILE0002 | Referential Integrity プラグインにはインデックスがありません。プラグインは、インデックス化されていない場合にすべての削除操作に対して特定の属性をクエリーします。これにより、インデックスのない検索結果が検出されにくくなったり、CPU 使用率が高くなったりします。 |
レプリケーション | 低 | DSREPLLE0002 | 競合エントリーがデータベースに存在します。 |
レプリケーション | 低 | DSSKEWLE0001 | レプリケーションタイムのずれが 6 時間より大きく、12 時間より小さくなっています。 |
レプリケーション | 中 | DSCLLE0001 | changelog のトリミングは無効になっています。この場合、changelog は制限なしで増加します。 |
レプリケーション | 中 | DSREPLLE0004 | ヘルスチェックは、レプリケーションのステータスを取得できませんでした。 |
レプリケーション | 中 | DSREPLLE0003 | トポロジーは同期されていませんが、レプリケーションは機能しています。 |
レプリケーション | 中 | DSREPLLE0005 | リモートレプリカには到達できません。 |
レプリケーション | 中 | DSSKEWLE0002 | レプリケーションタイムのずれが 12 時間より大きく、24 時間より小さくなっています。 |
レプリケーション | 高 | DSREPLLE0001 | トポロジーは同期されておらず、レプリケーションは機能しません。 |
レプリケーション | 高 | DSSKEWLE0003 | レプリケーションタイムのずれが 24 時間より大きい。レプリケーションセッションが破損する可能性がありました。 |
セキュリティー | 中 | DSELE0001 | 最小の TLS バージョンは TLS 1.2 未満の値に設定されます。 |
セキュリティー | 高 | DSCLE0002 | 弱いパスワードストレージスキームが設定されている。 |
サーバー | 高 | DSBLE0002 | ヘルスチェックは、バックエンドのクエリーに失敗しました。 |
TLS 証明書 | 中 | DSCERTLE0001 | サーバー証明書は次の 30 日以内に有効期限が切れます。 |
TLS 証明書 | 高 | DSCERTLE0002 | サーバー証明書の有効期限が切れている。 |
19.1. Directory Server ヘルスチェックの実行
# dsctl instance_name healthcheck Beginning lint report, this could take a while ... Checking Backends ... Checking Config ... Checking Encryption ... Checking FSChecks ... Checking ReferentialIntegrityPlugin ... Checking MonitorDiskSpace ... Checking Replica ... Checking Changelog5 ... Checking NssSsl ... Healthcheck complete. 1 Issue found! Generating report ...
例19.1 ヘルスチェックの予想されるレポート
[1] DS Lint Error: DSELE0001 -------------------------------------------------------------------------------- Severity: MEDIUM Affects: -- cn=encryption,cn=config Details: ----------- This Directory Server may not be using strong TLS protocol versions. TLS1.0 is known to have a number of issues with the protocol. Please see: https://tools.ietf.org/html/rfc7457 It is advised you set this value to the maximum possible. Resolution: ----------- There are two options for setting the TLS minimum version allowed. You, can set "sslVersionMin" in "cn=encryption,cn=config" to a version greater than "TLS1.0" You can also use 'dsconf' to set this value. Here is an example: # dsconf slapd-instance_name security set --tls-protocol-min=TLS1.2 You must restart the Directory Server for this change to take effect. Or, you can set the system wide crypto policy to FUTURE which will use a higher TLS minimum version, but doing this affects the entire system: # update-crypto-policies --set FUTURE ===== End Of Report (1 Issue found) =====
--json
パラメーターをコマンドに渡します。
# dsctl --json instance_name healthcheck
例19.2 JSON 形式のヘルスチェックの可能なレポート
[ { "dsle": "DSELE0001", "severity": "MEDIUM", "items": [ "cn=encryption,cn=config" ], "detail": "This Directory Server may not be using strong TLS protocol versions. TLS1.0 is known to\nhave a number of issues with the protocol. Please see:\n\nhttps://tools.ietf.org/html/rfc7457\n\nIt is advised you set this value to the maximum possible.", "fix": "There are two options for setting the TLS minimum version allowed. You,\ncan set \"sslVersionMin\" in \"cn=encryption,cn=config\" to a version greater than \"TLS1.0\"\nYou can also use 'dsconf' to set this value. Here is an example:\n\n # dsconf slapd-instance_name security set --tls-protocol-min=TLS1.2\n\nYou must restart the Directory Server for this change to take effect.\n\nOr, you can set the system wide crypto policy to FUTURE which will use a higher TLS\nminimum version, but doing this affects the entire system:\n\n # update-crypto-policies --set FUTURE" } ]
第20章 ユーザー認証の管理
20.1. ユーザーパスワードの設定
userPassword
属性があり、アクティブではない場合にのみディレクトリーにバインドできます。ユーザーパスワードはディレクトリーに格納されるため、ldapmodify ユーティリティーを使用する場合など、LDAP 操作でユーザーパスワードを設定またはリセットできます。
pwdReset
操作属性を true に設定します。アプリケーションはこの属性を使用して、管理者がユーザーのパスワードをリセットしたかどうかを識別できます。
Directory Manager
(root DN) を使用してパスワードを設定すると、パスワードポリシーは回避され、検証されません。これらのアカウントは、通常のユーザーパスワードの管理には使用しないでください。パスワードポリシーの回避が必要なパスワード管理タスクの実行にのみ使用します。
20.2. パスワード管理者の設定
- ユーザーがパスワードの変更を強制する
- パスワードポリシーで定義されている異なるストレージスキームへのユーザーのパスワードの変更
- パスワード構文チェックを回避
- ハッシュ化されたパスワードを追加します。
userPassword
属性のみを更新するパーミッションを持つデータベース内の既存のロールで実行することが推奨されます。Red Hat は、このような通常のタスクにパスワード管理者アカウントを使用することは推奨されません。
- ローカルポリシーで、次を実行します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp set ou=people,dc=example,dc=com --pwdadmin "cn=password_admins,ou=groups,dc=example,dc=com"
- グローバルポリシーで、次を実行します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdadmin "cn=password_admins,ou=groups,dc=example,dc=com"
passwordAdminSkipInfoUpdate: on/off
設定を追加すると、パスワード管理者が実行するパスワードの更新を詳細に制御できます。この設定を有効にすると、パスワードの更新は passwordHistory
、passwordExpirationTime
、passwordRetryCount
、pwdReset
、passwordExpWarned
などの特定の属性を更新しません。
20.3. 外部に保存されたパスワードの変更
# dsidm ldap://server.example.com -D bind_dn -W -b dc=example,dc=com account change_password user newPassword oldPassword
# dsidm ldap://server.example.com -Z bind_dn -W -b dc=example,dc=com account change_password user newPassword oldPassword
# dsidm ldap://server.example.com -Z bind_dn -W -b dc=example,dc=com account change_password user newPassword oldPassword
20.4. パスワードポリシーの管理
- ユーザーはスケジュールに応じてパスワードを変更する必要があります。
- ユーザーは、簡単ではないパスワードを提供する必要があります。
- パスワード構文は、特定の複雑な要件を満たす必要があります。
Directory Manager
(root DN) を使用してパスワードを設定すると、パスワードポリシーは回避され、検証されません。これらのアカウントは、通常のユーザーパスワードの管理には使用しないでください。パスワードポリシーの回避が必要なパスワード管理タスクの実行にのみ使用します。
- パスワードポリシーチェックのタイプまたはレベル。この情報は、サーバーがグローバルパスワードポリシーまたはローカル (サブツリー/ユーザーレベル) パスワードポリシーを確認および有効にするかどうかを示します。パスワードポリシーは、一般的なものから特定のものまで、逆ピラミッド型になっています。グローバルパスワードポリシーは、サブツリーレベルのパスワードポリシーに置き換えられました。これは、ユーザーレベルのパスワードポリシーに置き換えられます。エントリーに対して強制されるパスワードポリシーは 1 つだけで、パスワードポリシーは追加されません。つまり、特定の属性がグローバルレベルまたはサブツリーレベルのポリシーで設定されていて、ユーザーレベルのパスワードポリシーで設定されていない場合、アクティブで適用されるポリシーはユーザーレベルのポリシーであるため、ログインが試みられてもその属性はユーザーに使用されません。
- パスワードの追加および変更の情報。パスワード情報には、パスワードの構文およびパスワード履歴の詳細が含まれます。
- バインド情報バインド情報には、許可された猶予期間の数、パスワードエージング属性、およびバインド失敗の追跡が含まれます。
20.4.1. グローバルパスワードポリシーの設定
20.4.1.1. コマンドラインを使用したグローバルパスワードポリシーの設定
dsconf
ユーティリティーを使用して、グローバルパスワードポリシー設定を表示および編集します。
- 現在の設定を表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy get Global Password Policy: cn=config ------------------------------------ passwordstoragescheme: PBKDF2_SHA256 passwordChange: on passwordMustChange: off passwordHistory: off passwordInHistory: 6 ...
- パスワードポリシー設定を調整します。たとえば、パスワード構文の確認を有効にしてパスワードの最小の長さを 12 文字に設定するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdchecksyntax=on --pwdmintokenlen=12
使用可能な設定の完全なリストを表示するには、次のように入力します。# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --help
- パスワードポリシーを有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdlockout on
20.4.1.2. Web コンソールを使用したグローバルパスワードポリシーの設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Global Policy を選択します。メニューで、
- グローバルパスワードポリシーを設定します。次のカテゴリーのパラメーターを設定できます。
- パスワードストレージスキームなどの一般的な設定
- パスワード失効回数など、パスワードの有効期限設定。
- アカウントのロックアウト設定 (何回ログインに失敗したらアカウントをロックするかなど)。
- パスワード構文の設定 (パスワードの最小長など)。
ツールヒントとパラメーターの cn=config エントリーで対応する属性名を表示するには、設定の上にマウスのカーソルを合わせます。詳細は、『Red Hat Directory Server 設定、コマンド、およびファイルリファレンス』 のパラメーターの説明を参照してください。
20.4.2. ローカルパスワードポリシーの使用
nsslapd-pwpolicy-inherit-global
パラメーターがオンになっていればグローバルポリシーから構文を継承できます。
--pwpinheritglobal
オプションが定義されている場合、passwordchecksyntax
オプションはローカルポリシーでオフに、グローバルポリシーでオンに設定され、次の属性をグローバルポリシーからローカルポリシーに継承できます。
passwordchecksyntax
passwordminlength
passwordmindigits
passwordminalphas
passwordminuppers
passwordminlowers
passwordminspecials
passwordmin8bit
passwordmaxrepeats
passwordmincategories
passwordmintokenlength
20.4.2.1. 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=user_name,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=user_name,ou=people,dc=example,dc=com", cn=nsPwPolicyContainer,ou=people,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: ldapsubentry objectclass: passwordpolicy
20.4.2.2. ローカルパスワードポリシーの設定
- サブツリーまたはユーザーエントリーにローカルパスワードポリシーがすでに存在しているかどうかを確認します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp get "ou=People,dc=example,dc=com" Error: The policy wasn't set up for the target dn entry or it is invalid
ローカルポリシーが存在しない場合は、これを作成します。- サブツリーパスワードポリシーを作成するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp addsubtree "ou=People,dc=example,dc=com"
- ユーザーパスワードポリシーを作成するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp adduser "uid=user_name,ou=People,dc=example,dc=com"
重要新しいローカルポリシーを作成すると、上記のコマンドは、cn=config エントリーのnsslapd-pwpolicy-local
パラメーターを on に自動的に設定します。ローカルパスワードポリシーを有効にできない場合は、手動でパラメーターを off に設定します。dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdlocal off
- ローカルポリシー属性を設定します。たとえば、パスワードの有効期限を有効にし、パスワードの最大期間を 14 日 (1209600 秒) に設定するには、以下を実行します。
- サブツリーパスワードポリシー:
# dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp set --pwdexpire=on --pwdmaxage=1209600 "ou=People,dc=example,dc=com"
- ユーザーパスワードポリシー:
# dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp set --pwdexpire=on --pwdmaxage=1209600 "uid=user_name,ou=People,dc=example,dc=com"
使用可能な設定の完全なリストを表示するには、次のように入力します。# dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp set --help
20.5. 一時パスワードルールの設定
cn=Directory Manager
アカウントのみが一時パスワードを割り当てることができます。- Directory Server は、攻撃者によるパスワードの調査を防ぐために、認証の試行を一定の回数だけ許可します。
- Directory Server は、設定直後に一時パスワードを使用できないように、指定された遅延時間後に認証の試行を許可します。
- Directory Server は、ユーザーが一時パスワードを使用またはリセットしなかった場合に一時パスワードが期限切れになるように、指定された期間のみ認証の試行を許可します。
- 認証が成功した場合、Directory Server は他の操作を実行する前に、ユーザーによるパスワードのリセットを要求します。
20.5.1. グローバルパスワードポリシーでの一時的なパスワードルールの有効化
- 管理者がパスワードをリセットした場合にユーザーによるパスワードの変更を必須にします。
- グローバルパスワードポリシーで一時パスワード機能を設定します。
userPassword
属性を更新し、passwordMustChange
属性を on に設定すると、Directory Server は一時パスワード規則を適用します。
手順
- 管理者によるパスワードリセット後のユーザーによるパスワード変更を必須に設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdmustchange on
- グローバルパスワードポリシーで一時パスワードルールを設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwptprmaxuse 5 --pwptprdelayexpireat 3600 --pwptprdelayvalidfrom 60
この例では、以下のように設定されています。--pwptprmaxuse
オプションは、ユーザーが一時パスワードを 5 に使用できる最大試行回数を設定します。--pwptprdelayexpireat
オプションは、一時パスワードが 3600 秒 (1 時間) で期限切れになるまでの時間を設定します。--pwptprdelayvalidfrom
オプションは、管理者がユーザーのパスワードをリセットした後に、--pwptprdelayexpireat
に設定した時間が 60 秒を起動するように設定します。
検証
- 一時パスワードルールを保存する属性を表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy get | grep -i TPR passwordTPRMaxUse: 5 passwordTPRDelayExpireAt: 3600 passwordTPRDelayValidFrom: 60
20.5.2. ローカルパスワードポリシーでの一時的なパスワードルールの有効化
userPassword
属性を更新し、passwordMustChange
属性を on に設定すると、ユーザーが以下の場合に、Directory Server は一時パスワード規則を適用します。
- ローカルパスワードポリシーが有効になっている
- ローカルパスワードポリシーが有効になっているサブツリーに保存されている
手順
- 管理者によるパスワードリセット後のユーザーによるパスワード変更を必須に設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdmustchange on
- 一時パスワードルール設定を設定します。
- サブツリーの場合:
# dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp addsubtree --pwptprmaxuse 5 --pwptprdelayexpireat 3600 --pwptprdelayvalidfrom 60 ou=People,dc=example,dc=com
- ユーザーの場合:
# dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp adduser --pwptprmaxuse 5 --pwptprdelayexpireat 3600 --pwptprdelayvalidfrom 60 uid=example,ou=People,dc=example,dc=com
ローカルパスワードポリシーは、存在するエントリーにのみ設定できることに注意してください。この例では、以下のようになります。--pwptprmaxuse
オプションは、ユーザーが一時パスワードを 5 に使用できる最大試行回数を設定します。--pwptprdelayexpireat
オプションは、一時パスワードが 3600 秒 (1 時間) で期限切れになるまでの時間を設定します。-pwptprdelayvalidfrom
オプションは、管理者がユーザーのパスワードをリセットした後に、--pwptprdelayexpireat
に設定した時間が 60 秒を起動するように設定します。
検証
- 識別名 (DN) のローカルパスワードポリシーを表示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com localpwp get distinguished_name | grep -i TPR passwordTPRMaxUse: 5 passwordTPRDelayExpireAt: 3600 passwordTPRDelayValidFrom: 60
20.6. パスワードの有効期限コントロールの概要
- 期限切れのコントロール (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
パラメーターをコマンドに渡してバインド応答制御を要求する必要があります。例20.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)
20.7. Directory Manager パスワードの管理
root
ユーザーと類似しています。Directory Manager のエントリーと、対応するパスワードは、インスタンスのインストール時に設定されます。
cn=Directory Manager
です。
20.7.1. Directory Manager パスワードのリセット
- Directory Server インスタンスを停止します。
# dsctl instance_name stop
- 新しいパスワードハッシュを生成します。以下に例を示します。
# pwdhash -D /etc/dirsrv/slapd-instance_name password {PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...
Directory Server 設定へのパスを指定すると、nsslapd-rootpwstoragescheme
属性に設定されたパスワードストレージスキームが自動的に使用され、新しいパスワードを暗号化します。 /etc/dirsrv/slapd-instance_name/dse.ldif
ファイルを編集し、nsslapd-rootpw
属性を直前の手順で表示された値に設定します。nsslapd-rootpw: {PBKDF2_SHA256}AAAgABU0bKhyjY53NcxY33ueoPjOUWtl4iyYN5uW...
- Directory Server インスタンスを起動します。
# dsctl instance_name start
20.7.2. Directory Manager パスワードの変更
20.7.2.1. コマンドラインを使用した Directory Manager パスワードの変更
nsslapd-rootpw
パラメーターを、Directory Server が自動的に暗号化する平文値に設定するには、以下を実行します。# dsconf -D "cn=Directory Manager" ldaps://server.example.com config replace nsslapd-rootpw=password
警告パスワードに中括弧 ({}) を使用しないでください。Directory Server はパスワードを {password-storage-scheme}hashed_password 形式で保存します。サーバーは、中括弧内の文字をパスワードストレージスキームとして解釈します。文字列が無効なストレージスキームであるか、パスワードが正しくハッシュ化されない場合、Directory Manager はサーバーに接続できません。- パスワードを手動で暗号化し、
nsslapd-rootpw
パラメーターに設定するには、以下を実行します。- 新しいパスワードハッシュを生成します。以下に例を示します。
# pwdhash -D /etc/dirsrv/slapd-instance_name password {PBKDF2_SHA256}AAAgAMwPYIhEkQozTagoX6RGG5E7d6/6oOJ8TVty...
Directory Server 設定へのパスを指定すると、nsslapd-rootpwstoragescheme
属性に設定されたパスワードストレージスキームが自動的に使用され、新しいパスワードを暗号化します。 - セキュアな接続 (STARTTLS) を使用して、前のステップで表示される値に
nsslapd-rootpw
属性を設定します。# dsconf -D "cn=Directory Manager" ldaps://server.example.com config replace nsslapd-rootpw="{PBKDF2_SHA256}AAAgAMwPYIhEkQozTagoX6RGG5E7d6/6oOJ8TVty..."
20.7.2.2. Web コンソールを使用した Directory Manager パスワードの変更
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Server Settings を選択します。メニューを開き、
- Directory Manager タブを開きます。
- Directory Manager Password フィールドおよび Confirm Password フィールドに新規パスワードを入力します。
- 必要に応じて、異なるパスワードストレージスキームを設定します。
20.7.3. Directory Manager パスワードストレージスキームの変更
nsslapd-rootpwstoragescheme
) のストレージスキームは、ユーザーパスワードの暗号化に使用されるスキームと異なる場合があります (nsslapd-pwstoragescheme
)。
20.7.3.1. コマンドラインを使用した Directory Manager パスワードストレージスキームの変更
- 新しいストレージスキームを使用する新しいパスワードハッシュを生成します。以下に例を示します。
# pwdhash -s PBKDF2_SHA256 password {PBKDF2_SHA256}AAAgAMwPYIhEkQozTagoX6RGG5E7d6/6oOJ8TVty...
nsslapd-rootpwstoragescheme
属性をストレージスキームに設定し、nsslapd-rootpw
属性をセキュアな接続 (STARTTLS) を使用して、前の手順で表示した値に設定します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-rootpwstoragescheme=PBKDF2_SHA256 nsslapd-rootpw="{PBKDF2_SHA256}AAAgAMwPYIhEkQozTagoX6RGG5E7d6/6oOJ8TVty..."
20.7.3.2. Web コンソールを使用した Directory Manager パスワードストレージスキームの変更
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Server Settings を選択します。メニューを開き、
- Directory Manager タブを開きます。
- パスワードストレージスキームを設定します。
- Directory Server は、新しいストレージスキームを使用して現在のパスワードを再暗号化することができません。したがって、Directory Manager Password フィールドおよび Confirm Password フィールドに新規パスワードを入力します。
20.7.4. Directory Manager DN の変更
cn=New Directory Manager
に変更するには、以下の手順を実施します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-rootdn="cn=New Directory Manager"
20.8. パスワードなしのアクセスについてのアカウント可用性の確認
20.8.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 |
20.8.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");)
20.9. パスワードベースのアカウントロックアウトポリシーの設定
20.9.1. コマンドラインを使用したアカウントロックアウトポリシーの設定
# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdlockout on --pwdmaxfailures=4
--pwdlockout
: アカウントロックアウト機能を有効または無効にするには、このパラメーターを on または off に設定します。--pwdunlock
: ロックアウトの期間後にアカウントのロックを解除するには、このパラメーターを on に設定します。--pwdlockoutduration
: アカウントがロックされる秒数を設定します。--pwdmaxfailures
: アカウントがロックされるまでの、失敗したパスワードの最大試行回数を設定します。--pwdresetfailcount
: Directory Server がアカウントの失敗したログイン数をリセットするまでの秒数を設定します。
20.9.2. Web コンソールを使用したアカウントロックアウトポリシーの設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Database タブを開き、Global Password Policy を選択します。
- Account Lockout タブでは、Enable Account Lockout 設定を有効にしてパラメーターを設定します。以下に例を示します。ツールヒントとパラメーターの cn=config エントリーで対応する属性名を表示するには、設定の上にマウスのカーソルを合わせます。詳細は、『Red Hat Directory Server 設定、コマンド、およびファイルリファレンス』 のパラメーターの説明を参照してください。
20.9.3. レガシーパスワードロックアウト動作の無効化
passwordMaxFailure
) に達すると、解釈する方法は複数あります。これは、サーバーが最後の失敗を全体の失敗数にどのようにカウントするかによります。
passwordLegacyPolicy
パラメーターで設定されます。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace passwordLegacyPolicy=off
20.10. 時間ベースのアカウントロックアウトポリシーの設定
- プラグイン自体の設定エントリー。これにより、そのサーバーに設定されたすべてのアカウントポリシーに使用されるグローバル値が設定されます。
- アカウントポリシー設定エントリー。このエントリーはユーザーディレクトリー内にあり、基本的にはユーザーアカウントエントリーに参照および適用されるテンプレートとなります。
- アカウントポリシーエントリーを適用するエントリー。ユーザーアカウントは、直接アカウントポリシーを参照したり、CoS またはロールを使用してアカウントポリシーを自動的にユーザーアカウントのセットに適用することができます。注記アカウントポリシーは、
acctPolicySubentry
属性を介して適用されます。この属性はユーザーアカウントに直接追加できますが、この属性は単値になります。つまり、そのアカウントにはアカウントポリシーを 1 つだけ適用できます。これはほとんどの場合で問題ありません。しかし、現実的には、2 つのアカウントポリシーを作成することができます。1 つはアカウントの非アクティブ化のため、もう 1 つは年齢に基づくアカウントの失効のためです。CoS を使用してアカウントポリシーを適用すると、複数のアカウントポリシーをアカウントに使用できます。
20.10.1. アカウントポリシープラグインの構文
- nsslapd-pluginEnabled: プラグインが有効かどうかを設定します。この属性はデフォルトで off です。
- nsslapd-pluginarg0: プラグイン設定ディレクトリーの DN を参照します。設定エントリーは、通常プラグイン自体の子エントリーです (例: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config)。
- nsslapd-pluginarg0 属性で特定されたプラグイン設定エントリー。これにより、アカウントポリシー設定エントリーの特定やユーザーアカウントエントリーの管理に使用するプラグインのグローバル設定が設定されます。これらの設定はサーバー全体に適用されます。設定エントリー属性は、『Red Hat Directory Server 設定、コマンド、およびファイルリファレンス』 の 『アカウントポリシープラグインの属性』 セクションで説明されています。
- アカウントポリシーの設定エントリー。これは、アカウントポリシーに特定の値を設定するテンプレートエントリーとよく似ています。ユーザーアカウントは、直接または CoS エントリーを介して、このアカウントポリシーエントリーを参照します。アカウントポリシーとユーザーエントリーの属性については、以下の表で説明されています。
表20.2 アカウントポリシーエントリーおよびユーザーエントリーの属性 属性 定義 設定またはユーザーエントリー accountpolicy (オブジェクトクラス) アカウントの無効化または期限切れポリシーのテンプレートエントリーを定義します。 設定 accountInactivityLimit (属性) アカウントの最終ログイン時刻から、非アクティブ時にアカウントがロックされるまでの時間を秒単位で設定します。 設定 acctPolicySubentry (属性) アカウントのポリシー (具体的には、アカウントロックアウトポリシー) に属するエントリーを指定します。この属性の値は、エントリーに適用されるアカウントポリシーの DN を参照します。 ユーザー createTimestamp (操作属性) エントリーが最初に作成された日時が含まれます。 ユーザー lastLoginTime (操作属性) 指定のアカウントがディレクトリーに対して認証された最終時刻のタイムスタンプが含まれます。 ユーザー 詳細は、『Red Hat Directory Server 設定、コマンド、およびファイルリファレンス』 の属性の説明を参照してください。
20.10.2. アカウントアクティビティーとアカウントの有効期限
Account Policy
プラグインを使用すると、以下を設定できます。
- アカウントの有効期限: アカウントの作成後に一定時間無効になります。
- アカウントの非アクティブ化: 最後にログインに成功してから一定時間が経過すると、アカウントが無効になります。これにより、未使用のアカウントを自動的に無効にできます。
Account Policy
プラグインを設定するには、以下を実行します。
- アカウントポリシープラグインを有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin account-policy enable
- プラグイン設定エントリーを設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin account-policy set --config-entry="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
)。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin account-policy config-entry set "cn=config,cn=Account Policy Plugin,cn=plugins,cn=config" --always-record-login yes --state-attr lastLoginTime --alt-state-attr 1.1 --spec-attr acctPolicySubentry --limit-attr accountInactivityLimit
- サーバーを再起動して、新しいプラグイン設定を読み込みます。
# dsctl instance_name restart
- アカウントポリシーを定義します。
# ldapadd
-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 - サービステンプレートエントリーのクラスを作成します。
# ldapadd
-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 をディレクトリーツリー全体に適用します。# ldapadd
-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
20.10.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
属性が最後に更新されてからの時間を超えた場合は、アカウントが自動的に無効になります。
20.10.4. ロックアウトポリシーを設定しないログイン時間の追跡
lastLoginTime
属性をユーザーエントリーに追加するために使用されますが、他のポリシールールを設定する必要はありません。
- アカウントポリシープラグインを有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin account-policy enable
- ログイン時間を記録するプラグイン設定エントリーを作成します。
- すべてのエントリーにログイン時間が記録されるように、
alwaysRecordLogin
の値を yes に設定します。 lastLoginTime
属性をアカウントポリシー (stateattrname
) に使用する属性として設定します。- アカウントポリシーを適用するエントリーを表示するのに使用する属性を設定します (
acctPolicySubentry
)。 - 実際のタイムアウト期間 (秒単位) を設定するのに使用されるアカウントポリシーの属性を設定します (
accountInactivityLimit
)。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin account-policy config-entry set "cn=config,cn=Account Policy Plugin,cn=plugins,cn=config" --always-record-login yes --state-attr lastLoginTime --alt-state-attr createTimestamp --spec-attr acctPolicySubentry --limit-attr accountInactivityLimit
- サーバーを再起動して、新しいプラグイン設定を読み込みます。
# dsctl instance_name restart
20.10.5. Inactive アカウントのロックの解除
- dsidm ユーティリティーの使用:
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account unlock "uid=example"
lastLoginTime
属性を現在のタイムスタンプに手動でリセット:# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: uid=example,ou=people,dc=example,dc=com changetype: modify replace: lastLoginTime lastLoginTime: 20210901000000Z
タイムスタンプにZ
が追加されているため、lastLoginTime
属性は値を GMT/UTC 時間 (Zulu タイムゾーン) で保存することがわかります。
20.11. アカウントロックアウト属性の複製
passwordRetryCount
retryCountResetTime
accountUnlockTime
20.11.1. アカウントロックアウトおよびレプリケーションの管理
- パスワードポリシーはデータサプライヤーで実施されます。
- アカウントロックアウトは、レプリケーションに参加するすべてのサーバーに適用されます。
passwordMinAge
およびpasswordMaxAge
passwordExp
passwordWarning
- パスワードの有効期限が迫っていることを示すサーバーからの警告は、すべてのレプリカで発行されます。この情報は、各サーバーにローカルに保存されるため、ユーザーが複数のレプリカにバインドされた場合は、同じ警告が複数回発行されます。また、ユーザーがパスワードを変更した場合は、その情報がレプリカに反映されるまでに時間がかかることがあります。ユーザーがパスワードを変更してすぐに再バインドすると、レプリカが変更を登録するまでバインドに失敗することがあります。
- サプライヤーやレプリカなど、すべてのサーバーで同じバインド動作が発生する必要があります。各サーバーで同じパスワードポリシー設定情報を作成してください。
- アカウントロックアウトカウンターは、マルチサプライヤー環境で期待どおりに機能しない可能性があります。アカウントのロックアウトカウンターは、デフォルトでは複製されません (ただし、設定は可能です)。アカウントのロックアウト属性がまったく複製されない場合、あるユーザーがあるサーバーからロックアウトされていても、別のサーバーには正常にバインドできる可能性があります (または、あるサーバーではロックが解除されていても、別のサーバーではブロックされている場合もあります)。アカウントロックアウト属性が複製されると、アカウントのロックアウトの変更と、その変更が他のサーバーに伝播されるときにラグが発生することがあります。これはレプリケーションのスケジュールにより異なります。
- レプリケーション用に作成されるエントリー (例: サーバーアイデンティティー) には有効期限のないパスワードが必要です。これらの特別なユーザーに有効期限のないパスワードがあることを確認するには、エントリーに
passwordExpirationTime
属性を追加し、その値を 20380119031407Z 有効な範囲内に) 指定します。
alwaysRecordLogin
パラメーターが yes に設定されている場合、lastLoginTime
属性の値は、サプライヤーと読み取り専用レプリカで異なる場合があります。たとえば、ユーザーが読み取り専用のレプリカにログインすると、lastLoginTime
属性はローカルに更新されますが、値はサプライヤーサーバーに複製されません。
20.11.2. パスワードポリシー属性を複製する Directory Server の設定
passwordIsGlobalPolicy
属性で、コンシューマーがパスワードポリシーの操作属性を受け入れるようにします。
passwordIsGlobalPolicy
設定パラメーターを変更します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdisglobal="on"
passwordRetryCount
、retryCountResetTime
、および accountUnlockTime
が複製されます。
20.11.3. パスワードポリシー属性に対する一部レプリケーションの設定
passwordIsGlobalPolicy
属性を設定すると、コンシューマーがそれらの属性への更新を受け取ることができるように、レプリケーションのコンシューマーに影響します。パスワードポリシー属性がサプライヤーによって実際に複製されるかどうかを制御するには、特定のエントリー属性が複製されるものを制御する一部レプリケーションを使用します。
passwordIsGlobalPolicy
属性が off に設定されているため、パスワードポリシー属性を複製する必要がない場合は、一部レプリケーション (「一部レプリケーションを使用した属性のサブセットの複製」で説明) を使用してサプライヤーでレプリケーションを強制し、それらの属性をレプリカ合意から明確に除外します。
- サプライヤーにレプリカ合意を設定する場合は、Show Advanced Settings をクリックします。
- Exclude Attributes フィールドに
passwordRetryCount
属性、retryCountResetTime
属性、およびaccountUnlockTime
属性の名前を入力します。 - レプリカ合意の設定を終了します。
20.12. 異なるタイプのバインドの有効化
20.12.1. セキュアなバインドの要求
nsslapd-require-secure-binds
属性が有効にになっている場合は、レプリカ合意、同期合意、およびチェーン設定がセキュアな接続を指定するようにしてください。それ以外の場合、これらの操作は失敗します。
nsslapd-require-secure-binds
設定パラメーターを on に設定します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-require-secure-binds=on
- インスタンスを再起動します。
# dsctl instance_name restart
20.12.2. 匿名バインドの無効化
rootdse
により、匿名検索および root DSE 自体への読み取りアクセスが許可されますが、他のすべてのディレクトリーエントリーへのアクセスを制限します。
nsslapd-allow-anonymous-access
設定パラメーターを off に設定します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-allow-anonymous-access=off
- インスタンスを再起動します。
# dsctl instance_name restart
20.12.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 に設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-allow-unauthenticated-binds=on
20.12.4. 自動バインドの設定
Autobind
機能の設定」に) autobind マッピングを設定します。
20.12.4.1. Autobind および LDAPI の概要
- Unix ユーザーが 1 つのユーザーエントリーに一致した場合はユーザーエントリー
- Unix ユーザーが root または
nsslapd-ldapimaprootdn
で定義されているスーパーユーザーである場合は Directory Manager
図20.1 自動バインド接続パス
gidNumber=gid+uidNumberuid, autobindsuffix
20.12.4.2. Autobind
機能の設定
Autobind
機能を有効にすると、Directory Server への匿名アクセスのみが許可されます。ただし、Linux ユーザーを Directory Server エントリーにマッピングするように設定すると、root
ユーザーを Directory Manager にマップすることもできます。
nsslapd-ldapiautobind
パラメーターが有効化されていることを確認します。これはデフォルトです。# dsconf -D "cn=Directory Manager" ldap://server.example.com config get nsslapd-ldapiautobind nsslapd-ldapiautobind: on
nsslapd-ldapiautobind
パラメーターが off に設定されている場合は、有効にします。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-ldapiautobind=on
- ユーザーエントリーをマッピングするには、以下のように設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-ldapimaptoentries=on nsslapd-ldapiuidnumbertype=uidNumber nsslapd-ldapigidnumbertype=gidNumber nsslapd-ldapientrysearchbase=ou=People,dc=example,dc=com
- nsslapd-ldapimaptoentries=on は、エントリーマッピングを有効にします。
- nsslapd-ldapiuidnumbertype=uidNumber は、Unix UID 番号が含まれる Directory Server の属性を設定します。
- nsslapd-ldapigidnumbertype=gidNumber は、Unix GID 番号が含まれる Directory Server の属性を設定します。
- nsslapd-ldapientrysearchbase=ou=People,dc=example,dc=com は、ユーザーエントリーを検索する DN を設定します。
- 必要に応じて、Red Hat Enterprise Linux の
root
ユーザーを Directory Server の cn=Directory Manager アカウントにマッピングするには、以下を実行します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-ldapimaprootdn="cn=Directory Manager"
- インスタンスを再起動します。
# dsctl instance_name restart
20.13. パススルー認証の使用
図20.2 簡易的な PAM パススルー認証プロセス
- 設定 Directory Server (認証ディレクトリー) がマシン A にインストールされています。設定ディレクトリーには、認証するユーザーエントリーを含む接尾辞 o=RedHat など) が常に含まれます。この例では、サーバー名は authdir.example.com です。
- ユーザー Directory Server (PTA ディレクトリー) がマシン B にインストールされます。ユーザーディレクトリーは、dc=example,dc=com などのルート接尾辞を保存します。この例では、サーバー名は userdir.example.com です。
- 以下のコマンドを使用して userdir.example.com にプラグインを設定します。
# dsconf -D "cn=Directory Manager" ldap://userdir.example.com plugin pass-through-auth enable # dsconf -D "cn=Directory Manager" ldap://userdir.example.com plugin pass-through-auth url add "ldap://authdir.example.com/o=RedHat"
- userdir.example.com で Directory Server を再起動します。
- ユーザーディレクトリーは、o=RedHat が含まれる DN を持つエントリーのすべてのバインド要求を設定ディレクトリー authdir.example.com に送信するように設定されるようになりました。
- ユーザーディレクトリーでは、任意のユーザーが o=RedHat からバインドできるようになります。
20.13.1. PTA プラグインの構文
- パススルー認証 URL を追加するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin pass-through-auth url add URL
- パススルー認証 URL を変更するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin pass-through-auth url modify old_URL new_URL
- パススルー認証 URL を削除するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin pass-through-auth url delete URL
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 にバインド要求を渡します。詳細は、「パススルーサブツリーの指定」を参照してください。このサブツリーは、このサーバーに存在させることはできません。 | ||
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 |
任意。認証用ディレクトリーへの接続に STARTTLS を使用するかどうかを示すフラグ。STARTTLS は標準ポート上でセキュアな接続を確立するため、LDAPS の代わりに LDAP を使用して接続するのに便利です。TLS サーバーと CA 証明書の両方がサーバーで使用できる必要があります。
デフォルトは 0 (off) です。STARTTLS を有効にするには、1 に設定します。STARTTLS を使用するには、LDAP URL は ldaps: ではなく ldap: を使用する必要があります。
詳細は、「オプションパラメーターの設定」を参照してください。
|
20.13.2. PTA プラグインの設定
- dsconf plugin pass-through-auth を使用して、cn=Pass Through Authentication,cn=plugins,cn=config エントリーを変更します。
- Directory Server を再起動します。
20.13.2.1. セキュアな接続を使用するようにサーバーを設定
nsslapd-pluginarg0: ldaps://ldap.example.com:636/o=example
20.13.2.2. 認証する Directory Server の指定
- dsconf plugin pass-through-auth コマンドを使用して PTA プラグインエントリーを編集します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin pass-through-auth add ldap://server.example.com/o=example
必要に応じて、ポート番号を含めます。ポート番号が指定されていない場合、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
- サービスを再起動します。
# dsctl instance_name restart
20.13.2.3. パススルーサブツリーの指定
- dsconf plugin pass-through-auth コマンドを使用して、LDIF ファイルをディレクトリーにインポートします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin pass-through-auth add ldap://server.example.com/o=example
この構文の変数コンポーネントの詳細は、表20.3「PTA プラグインのパラメーター」 を参照してください。 - サービスを再起動します。
# dsctl instance_name restart
20.13.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 になります。
- 接続に STARTTLS を使用するかどうか。STARTTLS は標準の LDAP ポートでセキュアな接続を作成します。STARTTLS については、サーバーおよび CA 証明書がインストールされている必要がありますが、TLS で実行する必要はありません。デフォルトは 0 で、STARTTLS がオフになっていることを意味します。STARTTLS を有効にするには、1 に設定します。STARTTLS を使用するには、LDAP URL は ldaps: ではなく ldap: を使用する必要があります。
- dsconf plugin pass-through-auth コマンドを使用して、プラグインエントリーを編集します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin pass-through-auth add ldap://server.example.com/o=example 3,5,300,3,300,0
(この例では、各オプションのパラメーターはデフォルト値に設定されます。) subtree パラメーターと任意のパラメーターの間にスペースがあることを確認してください。注記これらのパラメーターは任意ですが、いずれかのパラメーターが定義されている場合は、デフォルト値を使用していてもすべてのパラメーターを定義する必要があります。 - サービスを再起動します。
# dsctl instance_name restart
20.13.3. PTA プラグイン構文の例
dse.ldif
ファイルの PTA プラグイン構文の以下の例を説明します。
20.13.3.1. Directory Server と 1 つのサブツリーの指定
dn: cn=Pass Through Authentication,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0: ldap://configdir.example.com/o=example ...
20.13.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=example ...
nsslapd-pluginarg0
属性は、認証する Directory Server を設定します。追加の nsslapd-pluginargN
属性は、使用する PTA プラグインの追加 接尾辞 を設定できますが、追加の ホスト ではありません。
20.13.3.3. 1 つの Directory Server と複数のサブツリーを指定
dn: cn=Pass Through Authentication,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0: ldap://configdir.example.com/o=example nsslapd-pluginarg1: ldap://configdir.example.com/dc=example,dc=com ...
20.13.3.4. デフォルト以外のパラメーター値の使用
dn: cn=Pass Through Authentication,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0: ldap://configdir.example.com/o=example 10,5,300,3,300,1 ...
20.13.3.5. 認証する異なる Directory Server の異なる任意のパラメーターおよびサブツリーの指定
dn: cn=Pass Through Authentication,cn=plugins,cn=config ... nsslapd-pluginEnabled: on nsslapd-pluginarg0:ldap://configdir.example.com/o=example 10,15,30,3,600,0 nsslapd-pluginarg1:ldap://config2dir.example.com/dc=example,dc=com 7,7,300,3,300,1 ...
20.14. 認証に 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 インスタンスを再起動します。
# dsctl instance_name restart
20.15. パススルー認証での PAM の使用
図20.3 PAM パススルー認証プロセス
20.15.1. PAM パススルー認証設定オプション
- PAM パススルー認証プラグインによって制御される接尾辞。ここでは、除外する接尾辞および含める接尾辞と、欠落した接尾辞の処理方法を説明します。
- 認証設定のターゲットである、設定された接尾辞内の個々のエントリー。デフォルトでは、接尾辞内のすべてのエントリーが認証スコープに含まれますが、複数の異なる PAM パススルー認証プラグインインスタンスを設定し、異なるユーザーに異なるプラグイン設定を適用することが可能です。
- PAM 属性マッピング。Directory Server に提示された認証情報は、何らかの方法で LDAP エントリーにマッピングされ、さらに PAM サービスの認証情報に戻される必要があります。これは、マッピングメソッドを定義し、任意で認証情報と一致させるために使用する LDAP 属性を定義します。
- TLS 接続の使用や、使用する PAM サービス、および PAM 認証に失敗した場合の LDAP 認証へのフォールバックなど、一般的な設定。
pamFilter
属性を使用して、プラグインで使用する特定のエントリーを検索するよう LDAP フィルターを設定することで、ユーザーエントリーのサブセットに適用できます。
20.15.1.1. PAMPTA のターゲットとなる接尾辞の指定
pamExcludeSuffix
属性は接尾辞を除外します。デフォルトでは、設定サブツリー (cn=config) のみが除外されます。別の方法では、PAM PTA プラグインは pamIncludeSuffix
属性の接尾辞に適用することもできます。これらの属性はいずれも多値で設定されます。
pamExcludeSuffix: cn=config
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
20.15.1.2. 異なるエントリーへの異なる PAM パススルー認証設定の適用
pamFilter
属性で LDAP フィルターを指定することができます。これは、PAM パススルー認証ポリシーを適用する接尾辞内の特定のエントリーを識別します。
20.15.1.3. PAM PTA マッピングの設定
pamIDMapMethod: RDN ENTRY DN
マッピング | 説明 |
---|---|
RDN | このメソッドは、バインド DN の左端にある RDN から値を使用します。このメソッドのマッピングは、Directory Server で定義されます。指定がない場合は、これがデフォルトのマッピングメソッドになります。 |
ENTRY | このメソッドは、バインド DN エントリーのユーザー定義の属性から PAM アイデンティティーの値をプルします。identity 属性は pamIDAttr 属性で定義されます。例: pamIDAttr: customPamUid |
DN | このメソッドは、バインド DN からの完全な識別名を使用します。このメソッドのマッピングは、Directory Server で定義されます。 |
20.15.1.4. 汎用 PAM PTA 設定の設定
- PAM (pamService) に送信するサービス名。これは、
/etc/pam.d
で使用する設定ファイルの名前です。 - セキュアな接続 (pamSecure) を必要とするかどうか。
- PAM 認証に失敗した場合の LDAP 認証にフォールバックするかどうか (pamFallback)
pamFallback: false pamSecure: false pamService: ldapserver
20.15.2. PAM パススルー認証の設定
pamFilter
属性を使用して、プラグインで使用する特定のエントリーを検索するよう LDAP フィルターを設定することで、ユーザーエントリーのサブセットに適用できます。
- PAM サービスが完全に設定されていることを確認してください。
- pam_fprintd.so モジュールを PAM 設定ファイルから削除します。重要pam_fprintd.so モジュールは、PAM パススルー認証プラグイン設定の
pamService
属性によって参照される設定ファイルにすることはできません。PAM の fprintd モジュールを使用すると、Directory Server は最大ファイル記述子制限に到達し、Directory Server プロセスが中止する可能性があります。 - PAM パススルーの認証プラグインを有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin set "PAM Pass Through Auth" --enabled on
- PAM パススルー認証設定エントリーを作成します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin pass-through-auth pam-config "Admin PAM PTA Config" add --exclude-suffix="cn=config" --id_map_method="RDN ENTRY" --id-attr="customPamUid" --filter="(manager=uid=example_user,ou=people,dc=example,dc=com pamFallback: FALSE" --secure="TRUE" --service="ldapserver"
- インスタンスを再起動します。
# dsctl instance_name restart
20.15.3. Active Directory をバックエンドとして PAM パススルー認証の使用
図20.4 SSSD による PAM パススルー認証
- Active Directory サーバーを ID プロバイダーの 1 つとして使用するように SSSD を設定します。この設定については、『RHEL システムと Windows Active Directory の直接統合』 の 『SSSD を使用した RHEL システムと AD の直接接続』 セクションを参照してください。
- 次のように PAM パススルー認証プラグインを有効にします。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin set "PAM Pass Through Auth" --enabled on
- 次のように、PAM パススルー認証設定エントリーを作成します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin pass-through-auth pam-config "AD PAM PTA Config" add --id_map_method="ENTRY" --id-attr="uid" --service="login" --include-suffix="ou=people,dc=example,dc=com" --missing-suffix="ERROR"
この例では、uid LDAP
属性を Active Directory に渡すユーザー名として使用し、この設定を people OU に対してのみ有効にしています。 - Directory Server インスタンスを再起動して、設定をロードします。
# dsctl instance_name restart
20.16. ユーザーおよびロールの手動による非アクティブ化
nsAccountLock
を使用して非アクティベートされます。エントリーに値が true の nsAccountLock
属性が含まれる場合、サーバーはバインドを拒否します。
20.16.1. アカウントまたはロールのステータスの表示
- アカウントで、次を入力します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account entry-status "uid=user_name,ou=People,dc=example,dc=com" Entry DN: uid=user_name,ou=People,dc=example,dc=com Entry Creation Date: 20200813085535Z (2020-08-13 08:55:35) Entry Modification Date: 20200813085535Z (2020-08-13 08:55:35) Entry State: activated
オプション:-V
オプションをコマンドに渡して、追加情報を表示します。# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account entry-status "uid=user_name,ou=People,dc=example,dc=com" -V Entry DN: uid=user_name,ou=People,dc=example,dc=com Entry Creation Date: 20200824160645Z (2020-08-24 16:06:45) Entry Modification Date: 20200824160645Z (2020-08-24 16:06:45) Entry Last Login Date: 20200824160645Z (2020-08-24 16:06:45) Entry Time Until Inactive: 2 seconds (2020-08-24 16:07:45) Entry State: activated
上記の出力は、出力の最後の 2 行で表されるアクティブなアカウントの例です。非アクティブなアカウントは、以下のような出力を提供します。# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account entry-status "uid=user_name,ou=People,dc=example,dc=com" -V Entry DN: uid=user_name,ou=People,dc=example,dc=com Entry Creation Date: 20200824160645Z (2020-08-24 16:06:45) Entry Modification Date: 20200824160645Z (2020-08-24 16:06:45) Entry Last Login Date: 20200824160645Z (2020-08-24 16:06:45) Entry Time Since Inactive: 3 seconds (2020-08-24 16:07:45) Entry State: inactivity limit exceeded
- ロールには、以下を入力します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" role entry-status "cn=Marketing,ou=People,dc=example,dc=com" Entry DN: cn=Marketing,ou=people,dc=example,dc=com Entry State: activated
entry-status
オプションの代わりに subtree-status
を使用します。subtree-status
オプションを使用する場合は、フィルター (-f
) と検索範囲 (-s
) を指定して結果を絞り込むことができます。また、-i
オプションを使用して検索を絞り込み、非アクティブアカウントのみを返すか、-o date
オプションを使用して、指定した日付までに非アクティブになるアカウントのみを返したりすることができます。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account account "ou=People,dc=example,dc=com" -f "(uid=*)" -V -o "2020-08-25T14:30:30"
20.16.2. コマンドラインを使用したユーザーおよびロールの非アクティブ化およびアクティブ化
- ユーザーアカウントで、以下を入力します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account lock "uid=user_name,ou=People,dc=example,dc=com
- ロールには、以下を入力します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" role lock "cn=Marketing,ou=People,dc=example,dc=com
- ユーザーアカウントで、以下を入力します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" account unlock "uid=user_name,ou=People,dc=example,dc=com
- ロールには、以下を入力します。
# dsidm -D "cn=Directory Manager" ldap://server.example.com -b "dc=example,dc=com" role unlock "cn=Marketing,ou=People,dc=example,dc=com
第21章 サーバーおよびデータベースアクティビティーの監視
21.1. Directory Server ログファイルの種類
- アクセスログ: クライアント接続および Directory Server インスタンスへの接続試行に関する情報が含まれます。このログタイプは、デフォルトで有効になります。
- エラーログ: エラーや、通常の操作中のディレクトリーエクスペリエンスに関する詳細なエラーメッセージが含まれます。このログタイプは、デフォルトで有効になります。警告Directory Server がエラーログに書き込みに失敗した場合、サーバーはエラーメッセージを Syslog サービスに送信し、終了します。このログタイプは、デフォルトで有効になります。
- 監査ログ: 各データベースとサーバー設定に加えられた変更を録画します。このログはデフォルトでは有効になっていません。
- 監査失敗ログ: レコードで監査ログが失敗しました。このログはデフォルトでは有効になっていません。
21.2. ログファイルの表示
21.2.1. コマンドラインでログファイルの表示
# less /var/log/dirsrv/slapd-instance_name/access
# dsconf -D "cn=Directory Manager" ldap://server.example.com config get 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
21.2.2. Web コンソールを使用したログファイルの表示
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 必要に応じて、以下の設定をログファイルビューアーに適用することができます。
- Log Lines To Show フィールドに表示される行数を設定します。
- 継続的なリフレッシュ を選択して、新しいログエントリーを自動的に表示できるようにします。
21.3. ログファイルの設定
21.3.1. ログの有効化または無効化
21.3.1.1. コマンドラインを使用したロギングの有効化または無効化
- アクセスログ:
nsslapd-accesslog-logging-enabled
- エラーログ:
nsslapd-errorlog-logging-enabled
- 監査ログ:
nsslapd-auditlog-logging-enabled
- 監査失敗ログ:
nsslapd-auditfaillog-logging-enabled
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-auditlog-logging-enabled=on
21.3.1.2. Web コンソールを使用したロギングの有効化または無効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 選択したログタイプのロギング機能を有効または無効にします。
- オプションで、ログローテーションポリシーまたはログ削除ポリシーなどを定義する追加のパラメーターを設定します。
21.3.2. プラグイン固有のロギングの設定
21.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.
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace 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.
21.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.4.0.11 B2018.197.1151 server.example.com:389 (/etc/dirsrv/slapd-instance)
21.3.4.1. コマンドラインを使用したログファイルローテーションポリシーの定義
600
を設定して最大 2
を維持し、ログファイルのサイズを 100
MB あるいは 5 日
ごとにローテーションするには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-errorlog-mode=600 nsslapd-errorlog-maxlogsperdir=2 nsslapd-errorlog-maxlogsize=100 nsslapd-errorlog-logrotationtime=5 nsslapd-errorlog-logrotationtimeunit=day
21.3.4.2. Web コンソールを使用したログファイルローテーションポリシーの定義
21.3.5. ログファイルの削除ポリシーの定義
削除ポリシー
を設定すると、アーカイブされた古いログファイルを自動的に削除します。
- ログサイズの合計
- すべてのアクセス、エラー、監査、または監査失敗ログファイルのサイズが設定された値を越えると、最も古いログファイルが自動的に削除されます。
- アクセスログ:
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
21.3.5.1. コマンドラインを使用したログ削除ポリシーの設定
500
MB 増加した場合に、最も古いアクセスログファイルを自動的に削除するには、次のように実行します。
dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-accesslog-logmaxdiskspace=500
21.3.5.2. Web コンソールを使用したログ削除ポリシーの設定
21.3.6. 手動ログファイルローテーション
/var/log/dirsrv/slapd-instance
- インスタンスを停止します。
# dsctl instance_name stop
- 古いログファイルが今後の参照で利用できるように、ローテーションされるログファイルを移動するか名前を変更します。
- インスタンスを起動します。
# dsctl instance_name restart
21.3.7. ログレベルの設定
- アクセスログ:
nsslapd-accesslog-level
- エラーログ:
nsslapd-errorlog-level
21.3.7.1. コマンドラインを使用したログレベルの設定
nsslapd-errorlog-level
パラメーターを 96 (32 + 64) に設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-errorlog-level=96
nsslapd-accesslog-level
パラメーターを 260 (4 + 256) に設定します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-accesslog-level=260
21.3.7.2. Web コンソールを使用したログレベルの設定
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- 設定するには、以下を実行します。
- アクセスログレベル:
- Access Logging Levels セクションでログレベルを選択します。以下に例を示します。
- エラーログレベル:
- Error Logging Levels セクションでログレベルを選択します。以下に例を示します。
21.3.7.3. 内部操作のロギング
- サーバー開始の内部操作
- サーバーが開始した内部操作ログエントリーの例:
[14/Jan/2021:09:45:25.814158882 -0400] conn=Internal(0) op=0(0)(0) MOD dn="cn=uniqueid generator,cn=config" [14/Jan/2021:09:45:25.822103183 -0400] conn=Internal(0) op=0(0)(0) RESULT err=0 tag=48 nentries=0 etime=0.0007968796
このタイプのログエントリーの場合:conn
フィールドは、Internal に続いて (0) が設定されます。op
フィールドは 0(0)(nesting_level) に設定されます。server-initiated 内部操作の場合、操作 ID と内部操作 ID の両方は常に 0 になります。入れ子ではないログエントリーの場合、ネストレベルは 0 になります。
- クライアントで開始される内部操作
- クライアントが開始した内部操作ログエントリーの例:
[14/Jan/2021:09:45:14.382918693 -0400] conn=5 (Internal) op=15(1)(0) SRCH base="cn=config,cn=userroot,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL [14/Jan/2021:09:45:14.383191380 -0400] conn=5 (Internal) op=15(1)(0) RESULT err=0 tag=48 nentries=0 etime=0.0000295419 [14/Jan/2021:09:45:14.383216269 -0400] conn=5 (Internal) op=15(2)(0) SRCH base="cn=config,cn=example,cn=ldbm database,cn=plugins,cn=config" scope=1 filter="objectclass=vlvsearch" attrs=ALL [14/Jan/2021:09:45:14.383449419 -0400] conn=5 (Internal) op=15(2)(0) RESULT err=0
このタイプのログエントリーの場合:conn
フィールドはクライアント接続 ID に続いて文字列 (Internal) に設定されます。op
フィールドで、操作 ID の後に (internal_operation_ID)(nesting_level) が含まれます。内部の操作 ID は変わることがあり、ネスト化していないログエントリーは 0 になります。
nsslapd-plugin-logging
パラメーターが on に設定され、内部操作のロギングが有効になっている場合、Directory Server はプラグインの内部操作の追加をログに記録します。
例21.1 プラグインロギングが有効になっている内部操作ログエントリー
uid=user,dc=example,dc=com
エントリーを削除し、Referential Integrity プラグインが example
グループからこのエントリーを自動的に削除すると、サーバーログは以下のようになります。
[time_stamp] conn=2 op=37 DEL dn="uid=user,dc=example,dc=com" [time_stamp] conn=2 (Internal) op=37(1) SRCH base="uid=user,dc=example,dc=com" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [time_stamp] conn=2 (Internal) op=37(1) RESULT err=0 tag=48 nentries=1 etime=0.0000129148 [time_stamp] conn=2 (Internal) op=37(2) SRCH base="dc=example,dc=com" scope=2 filter="(member=uid=user,dc=example,dc=com)" attrs="member" [time_stamp] conn=2 (Internal) op=37(2) RESULT err=0 tag=48 nentries=0 etime=0.0000123162 [time_stamp] conn=2 (Internal) op=37(3) SRCH base="dc=example,dc=com" scope=2 filter="(uniquemember=uid=user,dc=example,dc=com)" attrs="uniquemember" [time_stamp] conn=2 (Internal) op=37(3) RESULT err=0 tag=48 nentries=1 etime=0.0000128104 [time_stamp] conn=2 (Internal) op=37(4) MOD dn="cn=example,dc=example,dc=com" [time_stamp] conn=2 (Internal) op=37(5) SRCH base="cn=example,dc=example,dc=com" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL [time_stamp] conn=2 (Internal) op=37(5) RESULT err=0 tag=48 nentries=1 etime=0.0000130685 [time_stamp] conn=2 (Internal) op=37(4) RESULT err=0 tag=48 nentries=0 etime=0.0005217545 [time_stamp] conn=2 (Internal) op=37(6) SRCH base="dc=example,dc=com" scope=2 filter="(owner=uid=user,dc=example,dc=com)" attrs="owner" [time_stamp] conn=2 (Internal) op=37(6) RESULT err=0 tag=48 nentries=0 etime=0.0000137656 [time_stamp] conn=2 (Internal) op=37(7) SRCH base="dc=example,dc=com" scope=2 filter="(seeAlso=uid=user,dc=example,dc=com)" attrs="seeAlso" [time_stamp] conn=2 (Internal) op=37(7) RESULT err=0 tag=48 nentries=0 etime=0.0000066978 [time_stamp] conn=2 (Internal) op=37(8) SRCH base="o=example" scope=2 filter="(member=uid=user,dc=example,dc=com)" attrs="member" [time_stamp] conn=2 (Internal) op=37(8) RESULT err=0 tag=48 nentries=0 etime=0.0000063316 [time_stamp] conn=2 (Internal) op=37(9) SRCH base="o=example" scope=2 filter="(uniquemember=uid=user,dc=example,dc=com)" attrs="uniquemember" [time_stamp] conn=2 (Internal) op=37(9) RESULT err=0 tag=48 nentries=0 etime=0.0000048634 [time_stamp] conn=2 (Internal) op=37(10) SRCH base="o=example" scope=2 filter="(owner=uid=user,dc=example,dc=com)" attrs="owner" [time_stamp] conn=2 (Internal) op=37(10) RESULT err=0 tag=48 nentries=0 etime=0.0000048854 [time_stamp] conn=2 (Internal) op=37(11) SRCH base="o=example" scope=2 filter="(seeAlso=uid=user,dc=example,dc=com)" attrs="seeAlso" [time_stamp] conn=2 (Internal) op=37(11) RESULT err=0 tag=48 nentries=0 etime=0.0000046522 [time_stamp] conn=2 op=37 RESULT err=0 tag=107 nentries=0 etime=0.0010297858
21.3.8. デバッグ用のアクセスログバッファーの無効化
21.3.8.1. コマンドラインを使用したアクセスログバッファーの無効化
nsslapd-accesslog-logbuffering
パラメーターを off に設定します。# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-accesslog-logbuffering=off
21.3.8.2. Web コンソールを使用したアクセスログバッファーの無効化
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Disable Access Log Buffering を選択します。
21.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 値でソートするオプションを選択します。
- 他の画面のデフォルト (特に、データ系列を列で使用すること、最初の行と最初の列をラベルとして設定すること) を受け入れて、チャートを作成します。
21.5. シャットダウンのローカルディスクの監視
21.6. サーバーアクティビティーの監視
21.7. データベースアクティビティーの監視
21.8. データベースリンクアクティビティーの監視
21.9. カウンターの有効化および無効化
nsslapd-counters
パラメーターにより、実行するカウンターが有効になります。ただし、カウンターの実行はパフォーマンスに影響する可能性があるため、カウンターをオフにすることもできます。カウンターがオフの場合、カウンターの値はすべてゼロ (0) になります。
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-counters=off
21.10. SNMP を使用した Directory Server の監視
21.10.1. SNMP の概要
21.10.2. SNMP サポートの有効化および無効化
nsSNMPEnabled
パラメーターを on または off に設定します。たとえば、Directory Server インスタンスで SNMP を無効にするには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=SNMP,cn=config changetype: modify replace: nsSNMPEnabled nsSNMPEnabled: on
21.10.3. SNMP を使用してインスタンスを識別するためのパラメーターの設定
nsSNMPOrganization
nsSNMPLocation
nsSNMPContact
nsSNMPDescription
nsSNMPLocation
パラメーターを Munich, Germany に設定するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=SNMP,cn=config changetype: modify replace: nsSNMPLocation nsSNMPLocation: Munich, Germany
21.10.4. 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 を使用してインスタンスを識別するためのパラメーターの設定」 を参照してください。
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.10.5. SNMP トラップの設定
dsEntityContact
変数に定義された電子メールアドレスに電子メールを送信する一方で、別のインスタンスでは dsEntityContact
変数に定義されたページャー番号に通知を送信するなど、柔軟に対応することができます。
- DirectoryServerDown.このトラップは、サブエージェントが Directory Server が実行されていないことを検出するたびに生成されます。このトラップは、Directory Server インスタンスの説明、バージョン、物理的な場所、および連絡先情報と共に送信されます。詳細は、
dsEntityDescr
変数、dsEntityVers
変数、dsEntityLocation
変数、およびdsEntityContact
変数を参照してください。 - DirectoryServerStart.このトラップは、サブエージェントが Directory Server が起動または再起動していることを検出すると常に生成されます。このトラップは、Directory Server インスタンスの説明、バージョン、物理的な場所、および連絡先情報と共に送信されます。詳細は、
dsEntityDescr
変数、dsEntityVers
変数、dsEntityLocation
変数、およびdsEntityContact
変数を参照してください。
21.10.6. 管理情報ベースの使用
/usr/share/dirsrv/mibs
ディレクトリーに保存されている redhat-directory.mib
と呼ばれるファイルです。この MIB には、そのディレクトリーのネットワーク管理に関する変数の定義が含まれます。これらの変数は、管理オブジェクトと呼ばれます。ディレクトリー MIB および Net-SNMP を使用すると、ネットワーク上の他の全デバイスと同様にディレクトリーを監視できます。MIB を使用する方法は、「Directory Server の SNMP Agent の設定」を参照してください。
21.10.6.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.10.6.2. エントリー表
redhat-directory.mib
ファイルの Entries Table に保存されている管理オブジェクトを説明します。
管理オブジェクト | 説明 |
---|---|
dsCopyEntries | このディレクトリーのコピーが含まれるディレクトリーエントリーの数。このオブジェクトの値は、常に 0 になります (現在実行された更新は実行されていません)。 |
dsCacheEntries | ディレクトリーにキャッシュされたエントリーの数。 |
dsCacheHits | アプリケーションが起動してからローカルに保持されたキャッシュから指定された操作数。 |
21.10.6.3. エンティティーテーブル
管理オブジェクト | 説明 |
---|---|
dsEntityDescr | Directory Server インスタンスの説明セット。 |
dsEntityVers | Directory Server インスタンスの Directory Server のバージョン番号。 |
dsEntityOrg | Directory Server インスタンスに対応する組織。 |
dsEntityLocation | Directory Server インスタンスの物理的な場所。 |
dsEntityContact | Directory Server インスタンス担当する担当者の名前と連絡先情報。 |
dsEntityName | Directory Server インスタンスの名前。 |
21.10.6.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. 災害リカバリー用のディレクトリーデータのバックアップ
ldap://server.example.com
インスタンスを毎日 22:00 (10pm) に作成するには、以下のコマンドを実行します。
0 22 * * 1 /usr/sbin/dsconf -D "cn=Directory Manager" ldap://server.example.com backup create
dse.ldif
ファイル) の両方のバックアップが対象です。
22.3.2. 高可用性のためのマルチサプライヤーレプリケーション
例22.1 マルチサプライヤーレプリケーションのシナリオ
- 単一のサーバー障害の場合、そのインスタンスに保存されているすべてのデータには、他のサーバーからアクセスと取得が可能です。
- オフィス全体やコロケーション施設が失われた場合は、まったく別の物理的な場所にサーバーをミラーリングすることができます (Directory Server の広域レプリケーションの性能が役立ちます)。最低限の努力で、新しいサーバーをオンラインにすることなく、トラフィックは複製されたサイトにリダイレクトされます。
22.3.3. 高可用性のデータベースチェーン
例22.2 連鎖のシナリオ
22.4. リカバリープロセスの定義
- 障害を示すシグナル。明白なもの (大規模な停電、ネットワーク損失、または火災) もありますが、定義する必要があるものもあります。たとえば、バックアップサーバーをオンラインにする必要があるというメッセージは何ですか。
- 障害に応答する人および方法。災害が発生したら、誰が責任を持って行動しますか。これらのイベントについて通知する方法。何を期待されていますか。
- 災害復旧計画を出力したものをサイト外に保管します。
- 障害復旧計画を定期的にテストし、設定とインフラストラクチャーの変更後にテストします。
22.5. 基本的な例: リカバリーの実行
- プラン A では、Directory Server における 1 つのインスタンスの損失について扱います。
- プラン B は、何らかのデータの破損または攻撃を扱います。
- プラン C では、オフィス全体が失われた場合を扱います。
第23章 テストエントリーの作成
users
: ユーザーエントリーが含まれる LDIF ファイルを作成します。groups
: 静的グループおよびメンバーエントリーが含まれる LDIF ファイルを作成します。cos-def
: 従来のポインターまたは間接的な Class of Service (CoS) 定義が含まれる LDIF ファイルを作成します。cos-template
: CoS テンプレートが含まれる LDIF ファイルを作成します。roles
: 管理されたロールエントリー、フィルターが設定されたロールエントリーー、または間接ロールエントリーが含まれる LDIF ファイルを作成します。mod-load
: 変更操作が含まれる LDIF ファイルを作成します。ldapmodify
ユーティリティーを使用してこのファイルをインポートします。nested
: カスケードツリーやフラクタルツリーのように重く入れ子になったエントリーを含む LDIF ファイルを作成します。
mod-load
オプションを使用して LDIF ファイルを作成した後のldapmodify
ユーティリティー- その他のすべてのオプションの
ldapadd
ユーティリティー
ネスト
されたエントリータイプを除き、コマンドラインオプションを指定しないと、dsctl ldifgen コマンドはインタラクティブモードを使用します。
# dsctl instance_name ldifgen entry_type
23.1. サンプルユーザーエントリーを使用した LDIF ファイルの作成
/tmp/users.ldif
という名前の LDIF ファイルを作成するには、次のように入力します。
# dsctl instance_name ldifgen users --suffix "dc=example,dc=com" --number 100000 --generic --ldif-file=/tmp/users.ldif
- ou=accounting
- ou=product development
- ou=product testing
- ou=human resources
- ou=payroll
- ou=people
- ou=groups
# dsctl instance_name ldifgen users --help
23.2. グループエントリーの例を使用した LDIF ファイルの作成
/tmp/groups.ldif
という名前の LDIF ファイルを作成するには、次のコマンドを実行します。
# dsctl instance_name ldifgen groups --number 500 --suffix "dc=example,dc=com" --parent "ou=groups,dc=example,dc=com" --num-members 100 --create-members --member-parent "ou=People,dc=example,dc=com" --ldif-file /tmp/group.ldif example
ldapmodif
ユーティリティーを使用してグループを追加しようとすると、BER (Basic Encoding Rules) サイズ制限を超えており、インポートに失敗します。この場合は、cn=config エントリーの nsslapd-maxbersize
パラメーターの値を増やします。
# dsctl instance_name ldifgen groups --help
23.3. CoS 定義の例を使用した LDIF ファイルの作成
/tmp/cos-definition.ldif
という名前の LDIF ファイルを作成するには、次のコマンドを実行します。
# dsctl instance_name ldifgen cos-def Postal_Def --type classic --parent "ou=cos definitions,dc=example,dc=com" --cos-specifier businessCatagory --cos-template "cn=sales,cn=classicCoS,dc=example,dc=com" --cos-attr postalcode telephonenumber --ldif-file /tmp/cos-definition.ldif
# dsctl instance_name ldifgen cos-def --help
23.4. Example Modification Statements を使用した LDIF ファイルの作成
# dsctl instance_name ldifgen mod-load --parent dc=example,dc=com --num-users 1000 --create-users --mod-users 1000 --add-users 10 --del-users 100 --mod-users 1000 --modrdn-users 100 --mod-attrs cn uid sn --delete-users
/tmp/modifications.ldif
ファイルを作成します。
- ADD 操作 1000 の LDIF ファイルを作成し、ユーザーエントリーを作成します。
cn
属性、uid
属性、およびsn
属性を変更して、すべてのエントリーを変更します。- 10 ユーザーエントリーを追加します。
- 100 個の MODRDN 操作を実行します。
- 100 エントリーの削除
- 末尾の残りのエントリーをすべて削除します。
# dsctl instance_name ldifgen mod-load --help
23.5. ネストされたサンプルエントリーを持つ LDIF ファイルの作成
/tmp/nested.nldif
という名前の LDIF ファイルを作成するには、dc=example,dc=com エントリー配下の異なる組織単位 (OU) に合計 600 ユーザーの追加し、各 OU には最大 100 ユーザーが含まれています。
# dsctl instance_name ldifgen nested --num-users 600 --node-limit 100 --suffix "dc=example,dc=com"
# dsctl instance_name ldifgen nested --help
付録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]
例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.7 新しいパスワードに対して Kerberos プロンプトにより認証されるユーザー権限
# ldappasswd -p 389 -h server.example.com -O noplain,minssf=1,maxbufsize=512 -I
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 11 の設定、コマンド、およびファイルリファレンス』 を参照してください。スキーマのカスタマイズに関する情報は、12章ディレクトリースキーマの管理を参照してください。 |
attribute_type | エントリーで使用する説明的な属性を指定します。属性はスキーマで定義する必要があります。標準属性の一覧は、『Red Hat Directory Server 11 の設定、コマンド、およびファイルリファレンス』 を参照してください。スキーマのカスタマイズに関する情報は、12章ディレクトリースキーマの管理を参照してください。 |
[subtype] | 任意。サブタイプ、言語、バイナリー、または発音を指定します。このタグを使用して、対応する属性値が表現されている言語や、属性値がバイナリーであるか、属性値の発音であるかを識別します。サポートされるサブタイプタグのリストは、???を参照してください。 |
attribute_value | 属性タイプと使用する属性値を指定します。 |
B.2. LDIF での行継続
dn: cn=some_example_user,dc=example,dc=com dn: cn=some_e xample_user, dc=example,d c=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 11 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 11 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 11 Configuration, Command, and File Reference』 を参照してください。 |
ou: organizational_unit_name | 組織単位の名前を指定する属性。 |
list_of_attributes | エントリーに保持する任意の属性のリストを指定します。このオブジェクトクラスで利用可能な属性の一覧は、『Red Hat Directory Server 11 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 11 Configuration, Command, and File Reference』 を参照してください。 |
cn: common_name | 担当者の一般的な名前を指定します。これは、担当者が一般的に使用するフルネームです。たとえば、cn: Bill Anderson です。少なくとも 1 つの共通名が必要です。 |
sn: 姓 | ユーザーの姓を指定します。たとえば、sn: Anderson です。姓が必要です。 |
list_of_attributes | エントリーに保持する任意の属性のリストを指定します。このオブジェクトクラスで利用可能な属性の一覧は、『Red Hat Directory Server 11 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 ファイルからディレクトリーを作成します。
- Web コンソールでデータベースの初期化インポートするデータベースの規模が小さい (10,000 エントリーより少ない) 場合は、この方法を使用します。「Web コンソールを使用したデータのインポート」を参照してください。警告このメソッドは破壊的で、接尾辞の既存のデータを削除します。
- ldif2db または ldif2db.pl コマンドラインユーティリティー。インポートするデータベースの規模が大きい (10,000 エントリーより多い) 場合は、この方法を使用します。「サーバーがオフライン時のデータのインポート」を参照してください。
- 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
コンポーネント | 説明 | |||
---|---|---|---|---|
host name | LDAP サーバーの名前、IPv4、または IPv6 アドレス。たとえば、ldap.example.com、192.0.2.90、または [2001:db8::1] になります。 | |||
port | 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 更新履歴
改訂履歴 | |||
---|---|---|---|
改訂 11.5-1 | Tue May 10 2022 | ||
| |||
改訂 11.4-1 | Tue Nov 09 2021 | ||
| |||
改訂 11.3-1 | Tue May 11 2021 | ||
| |||
改訂 11.2-1 | Tue Nov 03 2020 | ||
| |||
改訂 11.1-1 | Tue Apr 28 2020 | ||
| |||
改訂 11.0-1 | Tue Nov 05 2019 | ||
|