5.4. Directory Server でのリファラルの使用
リファラル とは、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-referral
とnsslapd-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 スマートリファラルを使用した要求のリダイレクト
同じメカニズムを使用して、異なる namespace を使用する別のサーバーにクエリーをリダイレクトすることもできます。たとえば、ExampleCom のイタリアのオフィスで働く従業員が、ExampleCom のアメリカの従業員の電話番号をヨーロッパのディレクトリーサービスに要求するとします。Directory Server は次のリファーラルを返します。
ldap://america.example.com:389/ou=people,dc=example,dc=com
次の図は、別の namespace へのリファラルがどのように機能するかを示しています。
図5.8 異なるサーバーと namespace へのクエリーのリダイレクト
最後に、同じサーバー上で複数の接尾辞を提供する場合、ある 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 循環リファラルパターン
主要なブランチポイントでリダイレクトします。
セキュリティーを強化し、メンテナンスコストを削減するには、接尾辞と主要なブランチポイントレベルでリダイレクトを処理するようにリファラルの使用を制限します。スマートリファラルをエイリス作成メカニズムとして使用しないでください。
セキュリティーへの影響を考慮します。
アクセス制御はリファラルの境界を越えません。要求が最初に送信されたサーバーがエントリーへのアクセスを許可している場合でも、スマートリファラルがクライアント要求を別のサーバーに送信すると、クライアントアプリケーションはアクセスを拒否される可能性があります。
さらに、クライアントアプリケーションには、クライアントが参照されるサーバーに対して認証するための認証情報が必要です。