検索

5.4. Directory Server でのリファラルの使用

download PDF

リファラル とは、Directory Server によって返される情報で、要求を続行するためにどのサーバーに接続するかをクライアントアプリケーションに通知します。このリダイレクトメカニズムは、クライアントアプリケーションがローカルサーバーに含まれていないディレクトリーエントリーを要求したときに発生します。

Directory Server は以下のタイプのリファラルをサポートしています。

デフォルトのリファラル
クライアントアプリケーションがローカルツリーに属していないエントリーを要求すると、ディレクトリーはデフォルトのリファラルを返します。デフォルトのリファラルは、サーバーレベルと接尾辞レベルで設定できます。
スマートリファラル
Directory Server は、ディレクトリー内のエントリーにスマートリファラルを保存します。スマートリファラルは、スマートリファラルを含むエントリーの DN と一致する DN を持つサブツリーに関する情報を含むサーバーを指します。

Directory Server は、すべてのリファラルを LDAP ユニフォームリソースロケーター (LDAP URL) の形式で返します。

5.4.1. LDAP リファラルの構造

Directory Server は、すべてのリファラルを LDAP URL の形式で返します。LDAP URL には以下の情報が含まれています。

  • 問い合わせるサーバーのホスト名。
  • LDAP 要求をリッスンするように設定されたサーバーのポート番号。
  • ベース DN (検索操作用) またはターゲット DN (操作の追加、削除、および変更用)。

たとえば、クライアントアプリケーションは、dc=example,dc=com ブランチで姓が Jensen のエントリーを検索します。ただし、ディレクトリーツリーの一部はヨーロッパのサーバーに保存されます。リファラルは、以下の LDAP URL をクライアントアプリケーションに返します。

ldap://europe.example.com:389/ou=people,l=europe,dc=example,dc=com

このリファラルは、クライアントアプリケーションに、ポート 389 でホスト europe.example.com に接続し、ヨーロッパブランチ ou=people,l=europe,dc=example,dc=com を通じて新しい検索を送信するように指示します。

使用する LDAP クライアントアプリケーションによって、リファラルの処理方法が決まります。クライアントアプリケーションの中には、参照されたサーバーで、操作を自動的に再試行するものがあります。他のクライアントアプリケーションは、リファラル情報をユーザーに返します。Red Hat Directory Server が提供するほとんどの LDAP クライアントアプリケーション (コマンドラインユーティリティーなど) は、自動的にリファラルに従います。Directory Server は、サーバーにアクセスするために、最初のディレクトリー要求で提供されたのと同じバインド認証情報を使用します。

ほとんどのクライアントアプリケーションは、限られた数のリファラル (hops) に従います。リファラル数を制限することで、クライアントアプリケーションがディレクトリールックアップ要求を完了しようとして費やす時間を短縮し、循環リファラルパターンが原因で発生するハングプロセスを排除する際に役立ちます。

5.4.2. Directory Server のデフォルトのリファラル

Directory Server は、接続されたサーバーまたはデータベースに要求されたデータが含まれていない場合、クライアントに デフォルトのリファラル を返します。

たとえば、クライアントが次のディレクトリーエントリーを要求します: uid=bjensen,ou=people,dc=example,dc=com

ただし、サーバーは dc=europe,dc=example,dc=com 接尾辞に保存されているエントリーのみを管理します。ディレクトリーは、dc=example,dc=com 接尾辞の下に保存されているエントリーに関して、どのサーバーに接続するかという情報を含むリファラルをクライアントに返します。その後、クライアントは該当するサーバーに問い合わせ、元の要求を再提出します。

デフォルトのリファラルは、サーバーレベルと接尾辞レベルで設定できます。

  • サーバーレベルのリファラルを設定するには、サーバーレベルの設定属性 nsslapd-referral を使用します。Directory Server は、その属性値を dse.ldif 設定ファイルに保存します。サーバーが利用できない場合、またはクライアントにローカルサーバー上のデータにアクセスするパーミッションがない場合は、Directory Server はデフォルトのリファラルを返します。
  • 接尾辞レベルのリファラルを設定するには、接尾辞設定属性 nsslapd-referralnsslapd-state を使用します。接尾辞全体がオフラインになると、Directory Server はその接尾辞に対して行われたクライアント要求へのリファラルを返します。

5.4.3. Directory Server のスマートリファーラル

デフォルトのリファラルに加えて、Directory Server は、ディレクトリーエントリーまたはディレクトリーツリーを特定の LDAP URL に関連付ける スマートリファラル もサポートします。したがって、Directory Server はクライアント要求を次のいずれかに転送できます。

  • 別のサーバーに含まれる同じ namespace。
  • 異なるサーバー上の異なる namespace。
  • 同じサーバー上の異なる namespace。

デフォルトのリファラルとは異なり、Directory Server はスマートリファラルを設定ファイルではなくディレクトリー内に保存します。

たとえば、ExampleCom のアメリカオフィスのディレクトリーには、ou=people,dc=example,dc=com ディレクトリーブランチポイントが含まれます。

このブランチの要求を ExampleCom のヨーロッパオフィスの ou=people ブランチにリダイレクトするには、ou=people エントリー自体にスマートリファラルを指定できます。スマートリファーラルには次の値があります。

ldap://europe.example.com:389/ou=people,dc=example,dc=com

アメリカディレクトリーの ou=people ブランチへの要求は、以下の方法でヨーロッパディレクトリーにリダイレクトされます。

図5.7 スマートリファラルを使用した要求のリダイレクト

dg ディレクトリートポロジーの設計 7

同じメカニズムを使用して、異なる namespace を使用する別のサーバーにクエリーをリダイレクトすることもできます。たとえば、ExampleCom のイタリアのオフィスで働く従業員が、ExampleCom のアメリカの従業員の電話番号をヨーロッパのディレクトリーサービスに要求するとします。Directory Server は次のリファーラルを返します。

ldap://america.example.com:389/ou=people,dc=example,dc=com

次の図は、別の namespace へのリファラルがどのように機能するかを示しています。

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

dg ディレクトリートポロジーの設計 8

最後に、同じサーバー上で複数の接尾辞を提供する場合、ある namespace から同じサーバー上で提供される別の namespace にクエリーをリダイレクトできます。たとえば、ローカルサーバー上の o=example,c=us のすべてのクエリーを dc=example,dc=com にリダイレクトするには、o=example,c=us エントリーにスマートリファラル ldap:///dc=example,dc=com を設定します。LDAP URL の 3 番目のスラッシュは、URL が同じサーバーを指していることを示します。

注記

ある namespace から他の namespace へのリファラルは、その識別名に基づいて検索が行われるクライアントに対してのみ機能します。ou=people,o=example,c=US 以下の検索などのその他のタイプの操作は、正しく実行されません。

5.4.4. スマートリファラルを使用する際の考慮事項

スマートリファラルを使用する前に、次の点を考慮してください。

  • 設計はシンプルにします。

    複雑なリファラル Web では管理が困難になります。スマートリファラルを過度に使用すると、循環リファラルパターンにつながる可能性もあります。たとえば、あるリファラルが LDAP URL を指し、その URL がまた別の LDAP URL を指し、といった具合に、チェーンのどこかでリファラルが元のサーバーを指すまで続きます。次の図は循環リファラルパターンを示しています。

図5.9 循環リファラルパターン

dg ディレクトリートポロジーの設計 9
  • 主要なブランチポイントでリダイレクトします。

    セキュリティーを強化し、メンテナンスコストを削減するには、接尾辞と主要なブランチポイントレベルでリダイレクトを処理するようにリファラルの使用を制限します。スマートリファラルをエイリス作成メカニズムとして使用しないでください。

  • セキュリティーへの影響を考慮します。

    アクセス制御はリファラルの境界を越えません。要求が最初に送信されたサーバーがエントリーへのアクセスを許可している場合でも、スマートリファラルがクライアント要求を別のサーバーに送信すると、クライアントアプリケーションはアクセスを拒否される可能性があります。

    さらに、クライアントアプリケーションには、クライアントが参照されるサーバーに対して認証するための認証情報が必要です。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.