6.3. ナレッジ参照について


複数のデータベースにデータを分散させた後、ナレッジ参照、さまざまなデータベースに保持されているディレクトリー情報へのポインターを使用して、分散データ間の関係を定義します。Directory Server には、分散データを 1 つのディレクトリーツリーにリンクできるように、以下のタイプのナレッジ参照を提供します。
  • 参照: サーバーは、クライアントアプリケーションが要求を満たすために別のサーバーに問い合わせる必要があることを示す情報をクライアントアプリケーションに返します。
  • チェーン: サーバーは、クライアントアプリケーションの代わりに他のサーバーに問い合わせ、操作の完了時にクライアントアプリケーションに結果をまとめて返します。
以下のセクションでは、これら 2 種類のナレッジ参照を詳細に説明し、比較します。

6.3.1. 参照の使用

参照 とは、サーバーから返される情報のことで、クライアントアプリケーションに対して、操作リクエストを続行するにはどのサーバーに問い合わせればよいかを知らせるものです。このリダイレクトメカニズムは、クライアントアプリケーションがローカルサーバーに存在しないディレクトリーエントリーを要求すると発生します。
Directory Server は、2 種類の参照をサポートします。
  • デフォルトの参照: サーバーが一致する接尾辞を持たない DN をクライアントのアプリケーションが提示した場合、ディレクトリーはデフォルトの参照を返します。デフォルトの参照は、サーバーの設定ファイルに保存されます。Directory Server にはデフォルトの参照 1 つを設定し、各データベースには個別のデフォルト参照を設定できます。
    各データベースのデフォルトの参照は、接尾辞の設定情報により行われます。データベースの接尾辞が無効になっている場合は、その接尾辞に対して行われたクライアントの要求に対してデフォルトの参照を返すようにディレクトリーサービスを設定します。
    接尾辞の詳細は、「接尾辞について」 を参照してください。接尾辞の設定に関する詳細は、『Red Hat Directory Server Administration Guide』を参照してください。
  • スマート参照: スマート参照は、ディレクトリーサービス自体のエントリーに保存されます。スマート参照は、スマート参照を含むエントリーの DN に一致する DN を持つサブツリーの知識を有する Directory Server を指します。
すべての参照は、LDAP URL (LDAP Uniform Resource Locator) の形式で返されます。以下のセクションでは、LDAP 参照の構造の説明後、Directory Server でサポートされる 2 つの参照タイプを説明します。

6.3.1.1. LDAP 参照の構造

LDAP 参照には LDAP URL 形式の情報が含まれます。LDAP URL には以下の情報が含まれています。
  • 問い合わせるサーバーのホスト名。
  • LDAP 要求をリッスンするように設定されたサーバーのポート番号。
  • ベース DN (検索操作用) またはターゲット DN (操作の追加、削除、および変更用)。
たとえば、クライアントアプリケーションは、surname 値が Jensen のエントリーを dc=example,dc=com で検索します。参照は、以下の LDAP URL をクライアントアプリケーションに返します。
ldap://europe.example.com:389/ou=people, l=europe,dc=example,dc=com
Copy to Clipboard Toggle word wrap
この参照は、クライアントアプリケーションにポート 389 でホスト europe.example.com に問い合わせ、root 接尾辞 ou=people, l=europe,dc=example,dc=com を使用して検索を送信するように指示します。
LDAP クライアントアプリケーションは、参照を処理する方法を決定します。クライアントアプリケーションの中には、参照されたサーバーで、操作を自動的に再試行するものがあります。他のクライアントアプリケーションは、参照情報をユーザーに返します。Red Hat Directory Server が提供するほとんどの LDAP クライアントアプリケーション (コマンドラインユーティリティーなど) は、自動的に参照に従います。最初のディレクトリー要求で提供されたのと同じバインド認証情報が、サーバーへのアクセスに使用されます。
ほとんどのクライアントアプリケーションは、限られた数の参照 (hops) に従います。従う参照数を制限することで、クライアントアプリケーションがディレクトリールックアップ要求を完了しようとして費やす時間を短縮し、循環参照パターンによるハングプロセスを排除することができます。

6.3.1.2. デフォルトの参照について

問い合わせたサーバーまたはデータベースにリクエストされたデータが含まれていない場合、デフォルトの参照はクライアントに返されます。
Directory Server は、リクエストされたディレクトリーオブジェクトの DN を、ローカルサーバーがサポートするディレクトリー接尾辞と比較することで、デフォルトの参照を返すかどうかを決定します。DN がサポートされる接尾辞と一致しない場合には、Directory Server はデフォルトの参照を返します。
たとえば、ディレクトリークライアントは以下のディレクトリーエントリーを要求します。 uid=bjensen,ou=people,dc=example,dc=com
ただし、サーバーは dc=europe,dc=example,dc=com 接尾辞に保存されているエントリーのみを管理します。ディレクトリーは、dc=example,dc=com 接尾辞に保存されているエントリーについてどのサーバーに問い合わせるかを示すクライアントに参照を返します。その後、クライアントは該当するサーバーに問い合わせ、元のリクエストを再提出します。
デフォルトの参照が、ディレクトリーサービスのディストリビューションに関する詳細情報を持つ Directory Server を参照するように設定します。サーバーのデフォルトの参照は、nsslapd-referral 属性で設定します。ディレクトリーインストールの各データベースのデフォルトの参照は、設定のデータベースエントリーの nsslapd-referral 属性で設定されます。これらの属性値は、dse.ldif ファイルに保存されます。
デフォルトの参照の設定に関する詳細は、『Red Hat Directory Server Administration Guide』を参照してください。

6.3.1.3. スマート参照

Directory Server では、スマート参照 を使用することもできます。スマート参照は、ディレクトリーエントリーまたはディレクトリーツリーを特定の LDAP URL に関連付けます。つまり、リクエストは以下のいずれかに転送されます。
  • 別のサーバーに含まれる同じ namespace。
  • ローカルサーバー上の異なる namespace。
  • 同じサーバー上の異なる namespace。
デフォルトの参照とは異なり、スマート参照はディレクトリーサービス自体に保存されます。スマート参照の設定および管理の詳細は『Red Hat Directory Server Administration Guide』を参照してください。
たとえば、Example Corp. の米国オフィスのディレクトリーサービスには、ou=people,dc=example,dc=com ディレクトリーブランチポイントが含まれます。
ou=people エントリー自体にスマートリファーラルを指定して、このブランチのすべての要求を Example Corp. のヨーロッパの ou=people ブランチにリダイレクトします。スマート参照は ldap://europe.example.com:389/ou=people,dc=example,dc=com です。
アメリカのディレクトリーサービスの people ブランチへのリクエストは、すべてヨーロッパのディレクトリーにリダイレクトされます。以下で説明します。

図6.7 スマート参照を使用したリクエストのリダイレクト

同じメカニズムを使用して、別の namespace を使用する異なるサーバーにクエリーをリダイレクトすることができます。たとえば、Example Corp. のイタリアのオフィスで働く従業員が、Example Corp. のアメリカの従業員の電話番号をヨーロッパのディレクトリーサービスにリクエストするとします。ディレクトリーサービスは参照元 ldap://europe.example.com:389/ou=US employees,dc=example,dc=com を返します。

図6.8 異なるサーバーと namespace へのクエリーのリダイレクト

最後に、複数の接尾辞が同じサーバーで提供される場合、クエリーをある namespace から同じマシンで提供される別の namespace にリダイレクトすることができます。たとえば、o=example,c=us のローカルマシンのすべてのクエリーを dc=example,dc=com にリダイレクトするには、スマート参照 ldap:///dc=example,dc=como=example,c=us エントリーに配置します。

図6.9 同一サーバー上のある namespace から別の namespace へのクエリーのリダイレクト

注記
この LDAP URL の 3 番目のスラッシュは、URL が同じ Directory Server を参照していることを示しています。
ある namespace から他の namespace への参照の作成は、検索がその識別名に基づくクライアントに対してのみ機能します。ou=people,o=example,c=US 以下の検索など、その他の種類の操作は正しく実行されません。
LDAP URLS と Directory Server エントリーにスマート URL を追加する方法は、『Red Hat Directory Server Administration Guide』を参照してください。

6.3.1.4. スマート参照の設計に関するヒント

スマート参照の実装は簡単ではありますが、使用する前に以下の点を考慮してください。
  • 設計はシンプルにします。
    複雑な参照の Web を使用してディレクトリーサービスをデプロイすると、管理が困難になります。スマート参照を使いすぎると、循環参照パターンが発生する可能性もあります。たとえば、参照が LDAP URL を指し、その URL がまた別の LDAP URL を指し、といった具合に、チェーンのどこかの参照が元のサーバーを指すまで続きます。以下で説明します。

    図6.10 循環参照パターン

  • メジャーなブランチポイントでリダイレクトします。
    ディレクトリーツリーの接尾辞レベルでリダイレクトを処理する参照の使用を制限します。スマート参照は、リーフ (ブランチ以外) エントリーに対するルックアップ要求を、異なるサーバーおよび DN にリダイレクトします。その結果、スマート参照をエイリアスメカニズムとして使用したくなるため、ディレクトリー構造のセキュア化は複雑で困難な方法になります。ディレクトリーツリーの接尾辞またはメジャーブランチポイントに対する参照を制限すると、管理する必要のある参照数が制限され、その後ディレクトリーの管理オーバーヘッドが削減されます。
  • セキュリティーへの影響を考慮します。
    アクセス制御は参照の境界を越えません。リクエストを発信したサーバーがエントリーへのアクセスを許可していても、スマート参照が別のサーバーにクライアントリクエストを送信すると、クライアントアプリケーションのアクセスが許可されない場合があります。
    さらに、クライアントの認証が行われるためにクライアントが参照されるサーバー上でクライアントの認証情報が利用可能である必要があります。

6.3.2. チェーンの使用

チェーンは、別のサーバーにリクエストをリレーする方法です。この方法は、データベースリンクを使用して実装されます。「ディレクトリーデータの配布」 で説明したように、データベースリンクにはデータは含まれません。代わりに、クライアントアプリケーションのリクエストを、データを含むリモートサーバーにリダイレクトします。
サーバーはチェーン処理中に、クライアントアプリケーションから、サーバーに含まれないデータのリクエストを受信します。データベースリンクを使用して、サーバーはクライアントアプリケーションの代わりに他のサーバーに問い合わせ、クライアントアプリケーションに結果を返します。
各データベースリンクは、データを保持するリモートサーバーに関連付けられます。障害発生時にデータベースリンクが使用するデータのレプリカを含む代替リモートサーバーを設定します。データベースリンクの設定に関する詳細は、『Red Hat Directory Server Administration Guide』を参照してください。
データベースリンクは以下の機能を提供します。
  • リモートデータへの非表示のアクセス。
    データベースリンクはクライアントのリクエストを解決するため、データ配布はクライアントから完全に非表示になります。
  • 動的管理。
    システム全体をクライアントアプリケーションで利用できる状態で、ディレクトリーサービスの一部をシステムに追加したり、システムから削除したりできます。データベースリンクは、ディレクトリーサービス全体にエントリーが再分散されるまで、アプリケーションに参照を一時的に返すことができます。
    これは、クライアントアプリケーションをデータベースに転送するのではなく、参照を返すことができる接尾辞自体で実施することも可能です。
  • アクセス制御。
    データベースリンクは、クライアントアプリケーションになりすまし、適切な認証 ID をリモートサーバーに提供します。アクセス制御の評価が必要ない場合は、リモートサーバーでユーザーのなりすましを無効にすることができます。データベースリンクの設定に関する詳細は、『Red Hat Directory Server Administration Guide』を参照してください。

6.3.3. 参照とチェーンのどちらかを選択する

ディレクトリーパーティションをリンクする方法は、いずれも長所と短所があります。使用するメソッドまたはメソッドの組み合わせは、ディレクトリーサービスの特定のニーズによって異なります。
2 つのナレッジ参照の主な違いは、分散された情報の検索方法を知るインテリジェンスの場所にあります。チェーンシステムでは、インテリジェンスはサーバーに実装されています。参照を使用するシステムでは、インテリジェンスはクライアントアプリケーションに実装されています。
チェーンはクライアントの複雑性を軽減しますが、その代償としてサーバーの複雑さが増します。チェーンサーバーはリモートサーバーと連携し、結果をディレクトリークライアントに送信する必要があります。
参照では、クライアントは参照の位置を探したり、検索結果を照合したりする必要があります。ただし、参照はクライアントアプリケーションの作成者にさらなる柔軟性を提供し、開発者が分散ディレクトリー操作の進捗状況についてユーザーに適切にフィードバックできるようにします。
以下のセクションでは、参照とチェーンのより具体的な相違点について詳しく説明します。

6.3.3.1. 使用に関する相違点

クライアントアプリケーションによっては、参照をサポートしないものがあります。チェーンにより、クライアントアプリケーションが単一のサーバーと通信し、多くのサーバーに保存されているデータに引き続きアクセスすることができます。会社のネットワークがプロキシーを使用する場合、参照が機能しないことがあります。たとえば、クライアントアプリケーションは、ファイアウォール内の 1 つのサーバーのみと通信する権限を持っている場合があります。そのアプリケーションが別のサーバーを参照する場合、正常にコンタクトすることはできません。
また、参照を使用する際には、クライアントが正しく認証できなければなりません。つまり、クライアントが参照されるサーバーには、クライアントの認証情報が含まれている必要があります。チェーンでは、クライアントの認証は一度しか行われません。クライアントは、リクエストがチェーンされるサーバーで再度認証する必要はありません。

6.3.3.2. アクセス制御の評価

チェーンは、参照とは異なる方法でアクセス制御を評価します。参照では、クライアントのエントリーがすべてのターゲットサーバーに存在している必要があります。チェーンでは、クライアントエントリーはすべてのターゲットサーバー上にある必要はありません。

参照を使用した検索リクエストの実行

以下の図は、参照を使用したクライアントからサーバーへの要求を示しています。

図6.11 参照を使用したクライアント要求のサーバーへの送信

上記の図では、クライアントアプリケーションは以下の手順を実行します。
  1. クライアントアプリケーションは、最初にサーバー A にバインドします。
  2. サーバー A にはユーザー名とパスワードを提供するクライアントのエントリーが含まれるため、バインドの受け入れメッセージを返します。参照を機能させるためには、クライアントエントリーがサーバー A に存在する必要があります。
  3. クライアントアプリケーションは操作リクエストをサーバー A に送信します。
  4. ただし、サーバー A には要求された情報が含まれていません。代わりに、サーバー A は、サーバー B に連絡するよう指示するクライアントアプリケーションへの参照を返します。
  5. その後、クライアントアプリケーションはサーバー B にバインドリクエストを送信します。正常にバインドするには、サーバー B にクライアントアプリケーションのエントリーも含まれている必要があります。
  6. バインドに成功し、クライアントアプリケーションは検索操作をサーバー B に再送信できるようになりました。
この方法では、サーバー B が、サーバー A からのクライアントのエントリーの複製コピーを持つ必要があります。

チェーンを使用した検索リクエストの実行

サーバー間でクライアントエントリーを複製する問題は、チェーンを使用して解決されます。チェーンシステムでは、検索リクエストは応答があるまで複数回転送されます。

図6.12 チェーンを使用したクライアント要求のサーバーへの送信

上記の図で、以下の手順が実行されます。
  1. クライアントアプリケーションがサーバー A にバインドすると、サーバー A はユーザー名とパスワードが正しいかどうかを確認しようとします。
  2. サーバー A にはクライアントアプリケーションに対応するエントリーが含まれません。代わりに、クライアントの実際のエントリーが含まれるサーバー B へのデータベースリンクが含まれます。サーバー A はバインドリクエストをサーバー B に送信します。
  3. サーバー B はサーバー A に受け入れ応答を送信します。
  4. 次に、サーバー A はクライアントアプリケーションのリクエストをデータベースリンクを使用して処理します。データベースリンクは、サーバー B にあるリモートデータストアに問い合わせ、検索操作を処理します。
チェーンシステムでは、クライアントアプリケーションに対応するエントリーは、クライアントが要求するデータと同じサーバーに置く必要はありません。

図6.13 異なるサーバーを使用したクライアントの認証およびデータの取得

この図では、以下の手順が実行されます。
  1. クライアントアプリケーションがサーバー A にバインドすると、サーバー A はユーザー名とパスワードが正しいかどうかを確認しようとします。
  2. サーバー A にはクライアントアプリケーションに対応するエントリーが含まれません。代わりに、クライアントの実際のエントリーが含まれるサーバー B へのデータベースリンクが含まれます。サーバー A はバインドリクエストをサーバー B に送信します。
  3. サーバー B はサーバー A に受け入れ応答を送信します。
  4. サーバー A は次に別のデータベースリンクを使用して、クライアントアプリケーションのリクエストを処理します。データベースリンクは、サーバー C にあるリモートデータストアに問い合わせ、検索操作を処理します。

サポートされないアクセス制御

データベースリンクは、以下のアクセス制御をサポートしません。

  • ユーザーエントリーが別のサーバーにある場合、ユーザーエントリーのコンテンツにアクセスする必要のあるコントロールはサポートされません。これには、グループ、フィルター、およびロールに基づくアクセス制御が含まれます。
  • クライアント IP アドレスまたは DNS ドメインに基づいた制御は拒否される可能性があります。これは、データベースリンクがリモートサーバーに問い合わせする際に、クライアントになりすますためです。リモートデータベースに IP ベースのアクセス制御が含まれている場合は、元のクライアントドメインではなく、データベースリンクのドメインを使用して評価されます。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat