2.3. データベースリンクの作成および維持
チェーン とは、サーバーがクライアントアプリケーションの代わりに他のサーバーに接続し、組み合わせた結果を返すことを意味します。チェーンは データベースリンク を介して実装され、リモートで保存されたデータを参照します。クライアントアプリケーションがデータベースリンクからデータを要求すると、データベースリンクはリモートデータベースからデータを取得し、クライアントに返します。
チェーンに関する一般的な情報は、『Red Hat Directory Server デプロイメントガイド』のディレクトリートポロジーの設計の章を参照してください。「データベースリンクアクティビティーの監視」では、データベースリンクアクティビティーを監視する方法を説明します。
2.3.1. 新規データベースリンクの作成
基本的なデータベースリンクの設定には、以下の情報が必要です。
- 接尾辞の情報。接尾辞は、通常のデータベースではなく、データベースリンクが管理するディレクトリーツリーに作成されます。この接尾辞は、データが含まれるリモートサーバーの接尾辞に対応します。
- バインド認証情報。データベースリンクがリモートサーバーにバインドされると、ユーザーのなりすましが行われ、リモートサーバーとバインドするために使用する各データベースリンクの DN および認証情報を指定します。
- LDAP URL。これは、データベースリンクが接続するリモートサーバーの LDAP URL を提供します。URL はプロトコル (ldap または ldaps)、サーバーのホスト名または IP アドレス (IPv4 または IPv6)、およびポートで設定されます。
- フェイルオーバーサーバーのリスト。これは、障害発生時にデータベースリンクが接続するための代替サーバーのリストを提供します。この設定項目は任意です。
注記
シンプルなパスワード認証 (「セキュアなバインドの要求」) にセキュアなバインドが必要な場合は、セキュアな接続で行われる場合を除き、チェーン操作は失敗します。いずれの場合も、セキュアな接続 (TLS および STARTTLS 接続または SASL 認証) の使用が推奨されます。
2.3.1.1. コマンドラインを使用した新規データベースリンクの作成
新しいデータベースリンクを作成するには、dsconf chaining link-create コマンドを使用します。以下に例を示します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining link-create --suffix="ou=Customers,dc=example,dc=com" --server-url="ldap://remote_server.example.com:389" --bind-mech="" --bind-dn="cn=proxy_user,cn=config" --bind-pw="password" "example_chain_name"
これにより、
ou=Customers,dc=example,dc=com
の example_chain_name
という名前のデータベースリンクが作成されます。リンクはサーバー ldap://remote_server.example.com:389
を参照し、指定のバインド DN とパスワードを使用して認証を行います。--bind-mech が空に設定されているため、リンクは簡易認証を使用します。
注記
proxy_user にデータへのアクセス権を付与するには、リモートサーバーの
dc=example,dc=com
接尾辞にプロキシー ACI エントリーを作成する必要があります。その方法については、「データベースリンクの作成時に必要な設定に関する追加情報」 セクションを参照してください。
データベースリンクの作成時に設定できる追加設定を表示するには、以下を参照してください。
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining link-create --help
詳細は、「データベースリンクの作成時に必要な設定に関する追加情報」を参照してください。
2.3.1.2. Web コンソールを使用した新規データベースリンクの作成
新規データベースリンクを作成するには、以下を行います。
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Database メニューを開きます。
- 「接尾辞の作成」 で説明されているように、新しい接尾辞を作成します。
- 接尾辞を選択し、Suffix Tasks をクリックして Create Database Link を選択します。
- フィールドに、リモートサーバーへのコネクションの詳細を入力します。以下に例を示します。詳細は、「データベースリンクの作成時に必要な設定に関する追加情報」を参照してください。
- Create Database Link をクリックします。
2.3.1.3. 新規データベースリンクのデフォルト設定の管理
dsconf chaining コマンドを使用すると、データベースリンクのデフォルト設定を管理できます。
現在のデフォルト値を表示するには、以下を参照してください。
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-get-def
新しいデータベースリンク設定を変更するには、dsconf chaining config-set-def コマンドを使用します。たとえば、
response-delay
パラメーターを 30
に設定するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-set-def --response-delay 30
このサンプルコマンドは、すべてのチェーン接続にデフォルトの応答タイムアウトを設定します。dsconf instance chaining link-set コマンドを使用すると、特定のチェーンリンクの応答タイムアウトを上書きできます。
設定可能なすべてのパラメーターの一覧を表示するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-set-def --help
2.3.1.4. データベースリンクの作成時に必要な設定に関する追加情報
接尾辞情報
接尾辞は、データベースリンクで管理される接尾辞を定義します。
バインド認証情報
クライアントアプリケーションからの要求がリモートサーバーにチェーンされるようにするには、クライアントアプリケーションに特別なバインド認証情報を指定できます。これにより、リモートサーバーでチェーン操作に必要なプロキシー認証権限が付与されます。バインド認証情報がないと、データベースリンクは anonymous としてリモートサーバーにバインドされます。
たとえば、クライアントアプリケーションは要求をサーバー A に送信します。サーバー A には、サーバー B のデータベースに要求をチェーンするデータベースリンクが含まれています。

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

サーバー B にはユーザーエントリーが含まれ、このユーザーのプロキシー認証権限を設定する必要があります。プロキシー承認を正しく設定するには、プロキシー ACI をその他の ACI として設定します。
警告
ディレクトリーの制限された領域へのアクセス権限を付与しないようにチェーンを有効にする場合は、アクセス制御を慎重に検討します。たとえば、ブランチにデフォルトのプロキシー ACI が作成されると、データベースリンクを使用して接続するユーザーは、そのブランチの下にあるすべてのエントリーを表示できるようになります。ユーザーがすべてのサブツリーを表示する必要がない場合もあります。セキュリティーホールを回避するには、追加の ACI を作成して、サブツリーへのアクセスを制限します。
ACI の詳細は、18章アクセス制御の管理を参照してください。
注記
エントリーの作成または変更にクライアントアプリケーションでデータベースリンクを使用する場合、
creatorsName
属性および modifiersName
属性にはエントリーの実際の作成者または修正者が反映されません。これらの属性には、リモートデータサーバーでプロキシー認証権限が付与されている管理ユーザーの名前が含まれています。
バインド認証情報を指定するには、リモートサーバーで以下の手順が必要です。
- データベースリンク用に、
cn=proxy_user,cn=config
などの管理ユーザーを作成します。エントリーの追加に関する詳細は、3章ディレクトリーエントリーの管理を参照してください。 - データベースリンクによってチェーンされたサブツリーの直前の手順で作成した管理ユーザーのプロキシーアクセス権限を提供します。ACI の設定に関する詳細は、18章アクセス制御の管理を参照してください。たとえば、以下の ACI は、ACI が設定されたサブツリー内のみにリモートサーバーに含まれるデータにアクセスするために、
cn=proxy_admin,cn=config
ユーザーへの読み取り専用アクセスを付与します。aci: (targetattr = "*")(version 3.0; acl "Proxied authorization for database links"; allow (proxy) userdn = "ldap:///cn=proxy_admin ,cn=config";)
注記
ユーザーがデータベースリンクにバインドすると、ユーザーのアイデンティティーがリモートサーバーに送信されます。アクセス制御は、常にリモートサーバーで評価されます。ユーザーがリモートサーバーにデータを変更または書き込みできるようにするには、リモートサーバーに正しいアクセス制御を設定します。チェーン操作のコンテキストでアクセス制御がどのように評価されるかについての詳細は、「データベースリンクおよびアクセス制御評価」を参照してください。
LDAP URL
データベースリンクが含まれるサーバーで、データベースリンクが LDAP URL を使用して接続するリモートサーバーを特定します。標準の LDAP URL 形式とは異なり、リモートサーバーの URL は接尾辞を指定しません。ldap://host_name:port の形式を取ります。
データベースリンクが TLS 経由で LDAP を使用してリモートサーバーに接続する場合、リモートサーバーの LDAP URL は URL の LDAP ではなくプロトコル LDAP を使用し、サーバーのセキュアなポートを参照します。たとえば、以下のようになります。
ldaps://africa.example.com:636/
注記
TLS を介してチェーンするには、ローカル Directory Server とリモート Directory Server で TLS を有効にする必要があります。TLS の有効化に関する詳細は、「TLS の有効化」を参照してください。
データベースリンクとリモートサーバーが TLS を使用して通信するよう設定されている場合は、操作要求を行うクライアントアプリケーションも TLS を使用して通信する必要があるわけではありません。クライアントは、通常のポートを使用してバインドできます。
バインドメカニズム
ローカルサーバーは、複数の異なる接続タイプと認証メカニズムを使用してリモートサーバーに接続できます。
ローカルサーバーがリモートサーバーに接続する方法は 3 つあります。
- 標準の LDAP ポートを使用する場合
- 専用の LDAPS ポートを使用する場合
- STARTTLS (標準ポートでのセキュアな接続) の使用
注記
シンプルなパスワード認証 (「セキュアなバインドの要求」) にセキュアなバインドが必要な場合は、セキュアな接続で行われる場合を除き、チェーン操作は失敗します。いずれの場合も、セキュアな接続 (TLS および STARTTLS 接続または SASL 認証) の使用が推奨されます。
最終的に 2 つの接続設定があります。TLS オプションでは、サーバーの両方が TLS 経由の接続を実行および許可するように設定されますが、TLS を強制する別の設定属性はありません。
ローカルサーバーがファームサーバーへの認証に使用できる 4 つの方法があります。
- empty: バインドメカニズムが設定されていない場合、サーバーは単純な認証を実行し、バインド DN とパスワードが必要になります。
- EXTERNAL: これは TLS 証明書を使用して、ファームサーバーをリモートサーバーに認証します。ファームサーバーをセキュアな URL (ldaps) に設定するか、
nsUseStartTLS
属性を on に設定する必要があります。さらに、『Red Hat Directory Server 設定、コマンド、およびファイルリファレンス』 の 『certmap.conf』 セクションで説明されているように、ファームサーバーの証明書をバインド ID にマッピングするようにリモートサーバーを設定する必要があります。 - DIGEST-MD5: DIGEST-MD5 暗号化での SASL 認証を使用します。簡易認証と同様、バインド情報を付与するには、
nsMultiplexorBindDN
およびnsMultiplexorCredentials
属性が必要です。 - GSSAPI: SASL 上で Kerberos ベースの認証を使用します。ファームサーバーは Kerberos キータブで設定する必要があるため、リモートサーバーには、そのファームサーバーのバインド ID に対して定義された SASL マッピングが必要です。Kerberos キータブおよび SASL マッピングの設定は、「SASL Identity マッピングの設定」に記載されています。
注記
SASL 接続は、標準の接続または TLS 接続で確立できます。
注記
SASL を使用する場合は、SASL およびパスワードポリシーコンポーネントをチェーンするようにローカルサーバーを設定する必要もあります。「シャーシポリシーの設定」 で説明されているように、データベースリンク設定のコンポーネントを追加します。
2.3.2. シャーシポリシーの設定
この手順では、クライアントアプリケーションによって行われた要求を、データベースリンクを含む Directory Server に、Directory Server が連鎖させる方法の設定を説明します。このチェーンポリシーは、Directory Server で作成されたすべてのデータベースリンクに適用されます。
2.3.2.1. コンポーネントの動作の連鎖
コンポーネントは、内部操作を使用するサーバーの機能ユニットです。たとえば、プラグインはフロントエンドの機能のようにコンポーネントとみなされます。ただし、プラグインは実際には複数のコンポーネントで設定される場合があります (例: ACI プラグイン)。
一部のコンポーネントは、ローカルデータのみにアクセスできることを想定し、内部 LDAP 要求をサーバーに送信します。このようなコンポーネントの場合、チェーンポリシーを制御し、コンポーネントが操作を正常に完了できるようにします。一例として、証明書の検証機能が挙げられます。証明書をチェックするために関数によって行われる LDAP 要求を連鎖させると、リモートサーバーが信頼されていることを意味します。リモートサーバーが信頼されていない場合は、セキュリティーの問題があります。
デフォルトでは、すべての内部操作はチェーンされず、チェーンにはコンポーネントは許可されませんが、これは上書きできます。
また、指定したプラグインがリモートサーバーで操作を実行できるようにするには、リモートサーバーに ACI を作成する必要があります。ACI は、データベースリンクに割り当てられた 接尾辞 に存在している必要があります。
以下は、コンポーネント名、内部操作をチェーンできるようにする可能性のある副次的な影響、およびリモートサーバーの ACI で必要なパーミッションをリスト表示します。
- ACI プラグイン
- このプラグインはアクセス制御を実装します。ACI 属性の取得および更新に使用される操作は、ローカルおよびリモートの ACI 属性を混在することは安全ではないため、連鎖されません。ただし、ユーザーエントリーの取得に使用されるリクエストは、チェーンコンポーネント属性を設定することでチェーンすることができます。
nsActiveChainingComponents: cn=ACI Plugin,cn=plugins,cn=config
権限: 読み取り、検索、および比較 - リソース制限コンポーネント
- このコンポーネントは、ユーザーバインド DN に応じてサーバー制限を設定します。リソース制限コンポーネントを連鎖させることが可能であれば、リソース制限をリモートユーザーに適用できます。リソース制限コンポーネント操作を連鎖させるには、連鎖コンポーネント属性を追加します。
nsActiveChainingComponents: cn=resource limits,cn=components,cn=config
権限: 読み取り、検索、および比較 - 証明書ベースの認証チェックコンポーネント
- このコンポーネントは、外部バインドメソッドが使用される場合に使用します。リモートサーバーのデータベースからユーザー証明書を取得します。このコンポーネントの連鎖を許可すると、証明書ベースの認証がデータベースリンクと連携できることを意味します。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。
nsActiveChainingComponents: cn=certificate-based authentication,cn=components,cn=config
権限: 読み取り、検索、および比較 - パスワードポリシーコンポーネント
- このコンポーネントは、リモートサーバーへの SASL バインドを許可するために使用されます。SASL 認証の形式によっては、ユーザー名とパスワードを使用した認証が必要になります。パスワードポリシーを有効にすると、サーバーは要求された特定の認証方法を検証および実装し、適切なパスワードポリシーを適用できます。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。
nsActiveChainingComponents: cn=password policy,cn=components,cn=config
権限: 読み取り、検索、および比較 - SASL コンポーネント
- このコンポーネントは、リモートサーバーへの SASL バインドを許可するために使用されます。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。
nsActiveChainingComponents: cn=password policy,cn=components,cn=config
権限: 読み取り、検索、および比較 - 参照整合性プラグイン
- このプラグインは、DN を含む属性の更新が、属性へのポインターを含むすべてのエントリーに伝播されるようにします。たとえば、グループのメンバーであるエントリーが削除されると、そのエントリーはグループから自動的に削除されます。このプラグインをチェーンで使用すると、グループメンバーが静的グループ定義にリモートになる場合に静的グループの管理を簡素化できます。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。
nsActiveChainingComponents: cn=referential integrity postoperation,cn=plugins,cn=config
権限: 読み取り、検索、および比較 - Attribute Uniqueness プラグイン
- このプラグインは、指定された属性のすべての値が一意 (重複なし) のものであることを確認します 。このプラグインが連鎖されている場合は、データベースリンクで変更された属性でも属性値が一意であることを確認します。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。
nsActiveChainingComponents: cn=attribute uniqueness,cn=plugins,cn=config
権限: 読み取り、検索、および比較 - ロールのコンポーネント
- このコンポーネントは、データベースのエントリーのロールおよびロール割り当てを連鎖させます。このコンポーネントの連鎖は、連鎖されたデータベースであってもロールを維持します。このコンポーネントの動作を連鎖させるには、チェーンコンポーネント属性を追加します。
nsActiveChainingComponents: cn=roles,cn=components,cn=config
権限: 読み取り、検索、および比較
注記
以下のコンポーネントはチェーンできません。
- Roles プラグイン
- パスワードポリシーコンポーネント
- レプリケーションプラグイン
- 参照整合性プラグイン
連鎖要求を発行しているサーバーで Referential Integrity プラグインを有効にする場合は、パフォーマンス、リソース、時間のニーズ、整合性のニーズを分析してください。整合性チェックは時間がかかり、メモリーと CPU を浪費する可能性があります。ACI および連鎖関連の制限の詳細は、「ACI の制限」を参照してください。
2.3.2.1.1. コマンドラインを使用したコンポーネント操作の連鎖
チェーンに許可されているコンポーネントを追加するには、以下を実行します。
- チェーンに追加するコンポーネントを指定します。たとえば、整合性コンポーネントが連鎖操作を実行できるように設定するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining config-set \ --add-comp="cn=referential integrity postoperation,cn=components,cn=config"
連鎖が可能なコンポーネントのリストは、「コンポーネントの動作の連鎖」を参照してください。 - インスタンスを再起動します。
# dsctl instance_name restart
- 操作を連鎖させるリモートサーバーの接尾辞に ACI を作成します。たとえば、Rerefer Integrity プラグインに ACI を作成するには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h remoteserver.example.com -x dn: ou=People,dc=example,dc=com changetype: modify add: aci aci: (targetattr = "*")(target="ldap:///ou=customers,l=us,dc=example,dc=com") (version 3.0; acl "RefInt Access for chaining"; allow (read,write,search,compare) userdn = "ldap:///cn=referential integrity postoperation,cn=plugins,cn=config";)
2.3.2.1.2. Web コンソールを使用したコンポーネントの操作の連鎖
チェーンに許可されているコンポーネントを追加するには、以下を実行します。
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Database タブを開きます。
- 左側のナビゲーションで、Chaining Configuration エントリーを選択します。
- Components to Chain フィールドの下にある Add ボタンをクリックします。
- コンポーネントを選択し、Add & Save New Components をクリックします。
- 操作を連鎖させるリモートサーバーの接尾辞に 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 制御チェーン
LDAP 制御による操作リクエストを連鎖させることは できません。デフォルトでは、以下の制御で行われる要求は、データベースリンクによってリモートサーバーに転送されます。
- 仮想リストビュー (VLV)。この制御は、すべてのエントリー情報を返すのではなく、エントリーの一部のリストを提供します。
- サーバー側のソート。この制御では、通常は特定のマッチングルールを使用して、エントリーを属性値に従ってソートます。
- 逆参照。この制御は、検索内のエントリー属性の参照を上書きし、参照されるエントリーから指定された属性情報をプルし、残りの検索結果とともに返します。
- 管理 DSA。この制御は、参照に従うのではなく、スマート参照をエントリーとして返します。そのため、スマートの参照自体は変更または削除できます。
- ループ検出。この制御では、別のサーバーとのサーバー連鎖の回数を追跡します。数が設定された数に達すると、ループが検出され、クライアントアプリケーションに通知が送信されます。この制御の使用方法は、「ループの検出」を参照してください。
注記
サーバー側のソートおよび VLV 制御は、1 つのデータベースにクライアントアプリケーション要求が行われている場合にのみサポートされます。データベースリンクは、クライアントアプリケーションが複数のデータベースに要求を行う場合に、これらの制御をサポートしません。
チェーン可能な LDAP 制御とその OID を以下の表に示します。
表2.1 LDAP コントロールとその OID
コントロール名 | OID |
---|---|
仮想リストビュー (VLV) | 2.16.840.1.113730.3.4.9 |
サーバー側のソート | 1.2.840.113556.1.4.473 |
管理 DSA | 2.16.840.1.113730.3.4.2 |
ループ検出 | 1.3.6.1.4.1.1466.29539.12 |
検索の逆参照 | 1.3.6.1.4.1.4203.666.5.16 |
2.3.2.2.1. コマンドラインを使用した LDAP コントロールの連鎖
LDAP 制御をチェーンするには、dsconf chaining config-set --add-control コマンドを使用します。たとえば、仮想リストビューコントロールを転送するには、以下を実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com chaining \ config-set --add-control="2.16.840.1.113730.3.4.9"
Directory Server のクライアントが独自の制御を作成し、その操作をリモートサーバーにチェーンする必要がある場合は、カスタムコントロールのオブジェクト識別子 (OID) を追加します。
連鎖可能な LDAP コントロールとその OID のリストは、表2.1「LDAP コントロールとその OID」を参照してください。
2.3.2.2.2. Web コンソールを使用した LDAP 制御の連鎖
Web コンソールを使用して LDAP コントロールを連鎖するには、以下を実行します。
- Web コンソールで Directory Server ユーザーインターフェイスを開きます。「Web コンソールを使用した Directory Server へのログイン」を参照してください。
- インスタンスを選択します。
- Database メニューを開きます。
- Chaining Configuration エントリーを選択します。
- Forwarded LDAP Controls フィールドの下にある Add ボタンをクリックします。
- LDAP コントロールを選択し、Add & Save New Controls をクリックします。Directory Server のクライアントが独自の制御を作成し、その操作をリモートサーバーにチェーンする必要がある場合は、カスタムコントロールのオブジェクト識別子 (OID) を追加します。連鎖可能な LDAP コントロールとその OID のリストは、表2.1「LDAP コントロールとその OID」を参照してください。
- Save をクリックします。
2.3.3. データベースリンクおよびアクセス制御評価
ユーザーがデータベースリンクを含むサーバーにバインドすると、データベースリンクがユーザーの ID をリモートサーバーに送信します。アクセス制御は、常にリモートサーバーで評価されます。リモートサーバーで評価されるすべての LDAP 操作は、プロキシーが設定された承認コントロールを使用して渡されたクライアントアプリケーションの元の ID を使用します。ユーザーがリモートサーバーに含まれるサブツリーに正しいアクセス制御がある場合に限り、リモートサーバーで操作に成功します。これには、いくつかの制限があるリモートサーバーに通常のアクセス制御を追加する必要があります。
- すべての種類のアクセス制御を使用できるわけではありません。たとえば、ロールベースまたはフィルターベースの ACI はユーザーエントリーへのアクセスを必要とします。データベースリンクを介してデータにアクセスするため、プロキシーコントロールのデータのみが検証できます。ユーザーエントリーがユーザーのデータと同じデータベースに配置されるように、ディレクトリーを設計することを検討してください。
- クライアントの IP アドレスまたは DNS ドメインに基づくすべてのアクセス制御は、チェーン中にクライアントの元のドメインが失われるためです。リモートサーバーは、クライアントアプリケーションをデータベースリンクと同じ IP アドレスと、同じ DNS ドメインにある表示します。注記Directory Server は、IPv4 と IPv6 の IP アドレスの両方に対応します。
データベースリンクで使用される ACI には、以下の制限が適用されます。
- ACI は、使用する任意のグループと共に配置する必要があります。グループが動的である場合は、グループ内のすべてのユーザーが ACI およびグループで配置される必要があります。グループが静的である場合は、リモートユーザーにリンクされます。
- ACI は、使用するロール定義とそれらのロールを持つユーザーに対して配置する必要があります。
- ユーザーのエントリーの値 (例: userattr サブジェクトルール) にリンクする ACI は、ユーザーがリモートの場合に機能します。
アクセス制御は常にリモートサーバーで評価されますが、データベースリンクとリモートサーバーの両方が含まれるサーバーでも評価できます。これにはいくつかの制限があります。
- アクセス制御の評価時に、ユーザーエントリーの内容は必ずしも利用できるとは限りません (たとえば、データベースリンクを含むサーバーでアクセス制御が評価され、エントリーがリモートサーバーにある場合)。パフォーマンス上の理由から、クライアントはリモート問い合わせを実行してアクセス制御を評価することはできません。
- データベースリンクは、クライアントアプリケーションによって変更されるエントリーに必ずしもアクセスできるとは限りません。変更操作を実行する場合、データベースリンクはリモートサーバーに保存されている全エントリーにアクセスできません。削除操作を実行すると、データベースリンクはエントリーの DN のみを認識します。アクセス制御が特定の属性を指定する場合、データベースリンクを介して実行すると削除操作は失敗します。
注記
デフォルトでは、データベースリンクが含まれるサーバーに設定されたアクセス制御は評価されません。このデフォルトをオーバーライドするには、cn=database_link, cn=chaining database,cn=plugins,cn=config エントリーの
nsCheckLocalACI
属性を使用します。ただし、データベースリンクを含むサーバーでアクセス制御を評価することは、カスケード連鎖を使用する場合を除いて推奨されません。