5.6. リファラルとチェイニングの使い分け


ディレクトリーの特定のニーズに基づいて、リファラルとチェイニングのどちらかを選択します。

  • チェイニングにより、クライアントの複雑さが軽減されますが、その代償としてサーバーの複雑さが増します。ただし、チェイニングを使用すると、クライアントアプリケーションは単一のサーバーと対話しながら、複数のサーバーに保存されているデータに引き続きアクセスできます。クライアントは、要求がチェーンされているサーバーに対して認証を行う必要はありません。
  • リファラルの場合、クライアントアプリケーションはリファラルを見つけて検索結果を再送信する必要があります。クライアントは、参照先のサーバーに対して正しく認証できる必要もあります。

    さらに、ある会社のネットワークがプロキシーを使用している場合、リファラルが失敗することがあります。たとえば、クライアントアプリケーションは、ファイアウォール内の 1 つのサーバーのみと通信するパーミッションを持っている場合があります。そのアプリケーションが別のサーバーに参照されている場合、アプリケーションは正常に接続できない可能性があります。

    ただし、リファラルにより、クライアントアプリケーションの作成者にはより柔軟性が提供され、開発者は分散ディレクトリー操作の進行状況についてユーザーに優れたフィードバックを提供できます。

5.6.1. アクセス制御の評価

チェイニングは、リファラルとは異なる方法でアクセス制御を評価します。リファラルを使用する場合、クライアントエントリー (バインド DN) がすべてのターゲットサーバー上に存在している必要があります。チェイニングでは、クライアントエントリーはすべてのターゲットサーバー上にある必要はありません。

5.6.1.1. リファラルを使用した検索要求の実行

次の図は、リファラルを使用するサーバーへのクライアント要求を示しています。

図5.11 リファラルを使用したクライアント要求のサーバーへの送信

検索要求は次のように発生します。

  1. クライアントアプリケーションは、最初に Server A にバインドします。
  2. Server A にはユーザー名とパスワードを提供するクライアントのエントリーが含まれるため、バインドの受け入れメッセージを返します。リファラルを機能させるためには、クライアントエントリーが Server A に存在する必要があります。
  3. クライアントアプリケーションは操作要求を Server A に送信します。
  4. ただし、Server A には要求された情報が含まれていません。代わりに、Server A はクライアントアプリケーションにリファラルを返し、Server B に接続するように指示します。
  5. 次に、クライアントアプリケーションは Server B にバインド要求を送信します。バインドを正常に実行するには、Server B にクライアントアプリケーションのエントリーも含まれている必要があります。
  6. バインドに成功し、クライアントアプリケーションは検索操作を Server B に再送信できるようになりました。

この方法では、Server B が、Server A からのクライアントエントリーのレプリケートされたコピーを持つ必要があります。

5.6.1.2. チェイニングを使用した検索要求の実行

サーバー全体でクライアントエントリーをレプリケートする問題は、チェイニングを使用して解決できます。

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

検索要求は次のように発生します。

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

チェーンシステムでは、クライアントアプリケーションに対応するエントリーは、クライアントが要求するデータと同じサーバーに置く必要はありません。次の図は、2 つのチェーンサーバーを使用してクライアントの検索要求を完了する方法を示しています。

図5.13 2 つの異なるサーバーを使用してクライアントを認証し、データを取得する

検索要求は次のように発生します。

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

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

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

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

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat