| Oracle® Fusion Middleware Oracle Virtual Directory管理者ガイド 11gリリース1 (11.1.1) for Windows B55922-09 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Virtual Directory管理者ガイド 11gリリース1 (11.1.1) for Windows B55922-09 |
|
前 |
次 |
この章では、Oracle Virtual Directoryのルーティングについて説明します。この章の内容は次のとおりです。
従来型のディレクトリ・サーバーには、複数のデータベースが定義されており、それぞれがディレクトリ・ツリーのネームスペースの一部に対応し、選択はネームスペースの比較のみに基づいて決定されます。仮想ディレクトリでは、複数のアダプタで同じネームスペースを共有できるため、選択はより複雑ですが、より詳細に制御できます。
ルーティングは、LDAP操作に対して選択するアダプタをOracle Virtual Directoryが決定するために行われる処理です。ルーティングはタイプに関係なくすべてのアダプタに適用され、次に示すような、複数の役割を果します。
選択されるアダプタ数を制限し、リクエストされたクライアント・データを含み、現在のLDAP操作と関連するアダプタのみに絞り込む。
複雑な環境の設計を可能にする。
特定トランザクションのアダプタ数を削減し、よりセキュアでパフォーマンスの高い構成を実装できるようにOracle Virtual Directoryのチューニングを可能にする。
ルーティングでは、基本的なDNネームスペースのみでなく、DNパターン一致、LDAPフィルタ、属性フィルタ、問合せフィルタなど、トランザクション情報のその他の局面も調査してアダプタの選択を制御します。最も基本的なレベルでは、Oracle Virtual Directoryはアダプタ接尾辞比較プロセスを使用してアダプタを選択できます。アダプタ接尾辞の比較では、特定の検索ベースまたはエントリDN(追加、変更、削除、名前変更の場合)を調べて、各アダプタの接尾辞(ルート)と比較します。有効範囲によっては、Oracle Virtual Directoryは、1つ以上のアダプタが特定の問合せの影響を受けたかどうかを判別できます。
アダプタ接尾辞の比較は、アダプタ数が少ない場合に非常によく機能しますが、通常はさらに柔軟性の高い決定が必要で、このような場合にルーティングが重要になります。管理者はルーティングを使用すると、プロキシ・データ・ソースの情報をOracle Virtual Directoryにルーティング・インテリジェント機能という形で知らせることができます。ルーティングにより、Oracle Virtual Directoryはディレクトリ操作に細かい条件を付けて、操作が必要な特定の場所に送ることができます。これにより、既存のディレクトリに無関係な操作による過剰な負荷をかけずにすみ、自身のディレクトリに関係ない問合せがパートナに送られなくなります。Oracle Virtual Directoryルーティング・プロセスは、従来のアダプタ接尾辞比較に加えてLDAPクライアントの検索フィルタを分析し、処理に適格なアダプタをさらに絞り込みます。
ルーティングの例
図3-1に示すように、次の4つのアダプタが構成されているサンプルの仮想ディレクトリ構造があるとします。
アダプタ0は、ディレクトリ・ツリーのルートを形成し、o=AppViewにマッピングされます。このアダプタは、ツリーの仮想ルート、およびアクセス制御グループなどのローカル・エントリを保持します。
アダプタ1から3は、各ディレクトリ・ソースを新しいアプリケーション・ツリーのou=Peopleブランチの下の位置にマッピングします。
たとえば、図3-1のディレクトリを使用するアプリケーションがあり、ディレクトリ・サービスに関するインテリジェント機能がほとんどないと仮定します。これは本来1つのビジネスのために設計されたため、複数のビジネス・ユーザー・グループが同じアプリケーションを使用することに対応していません。このアプリケーションは、多種多様なディレクトリ・ツリー構造を想定することなく、1つの共通ディレクトリ階層ポイント(または1つの共通ベース)のみでディレクトリを検索します。この例では、アプリケーションがou=People,o=AppViewのディレクトリのみを検索するとします。ユーザーがjim.smith@divisionB.comなどのログイン証明書を入力すると、アプリケーションは次の検索を実行します。
ベース: ou=People,o=AppView
有効範囲: subtree
フィルタ: (uid=jim.smith@divisionb.com)
Oracle Virtual Directoryは、この問合せを受け取ると、この問合せで使用できるすべてのアダプタを自動的に選択します。問合せはツリーのベースを対象としているため、すべてのアダプタが選択され、調査が必要なパフォーマンスの問題の原因になります。他のすべての企業がディレクトリ構造の下部に存在する場合(たとえばou=DivisionB, ou=People,o=AppView)、親であるou=People,o=AppViewよりもそれらのブランチが下にあるため、デフォルトですべてのディレクトリ・ソースが検索されます。
この問題を解決するために、Oracle Virtual Directoryはルーティングの組込みと除外のフィルタを提供しています。これらのフィルタを使用して、特定のパートナ・ディレクトリへのトラフィックをフィルタ処理できます。この例では、管理者は次のルーティング組込みフィルタを設定できます。
Division Aのアダプタ: (uid=*@divisiona.com)
Division Bのアダプタ: (uid=*@divisionb.com)
Division Cのアダプタ: (uid=*@divisionc.com)
LDAPクライアント検索のベースでは通常すべてのディレクトリが選択されますが、このフィルタによって、(uid=jim.smith@divisionb.com)の検索はDivision Bのディレクトリのみを対象とすることが指定されます。図3-2では、通常選択される3つのアダプタを灰色で示し、フィルタ処理の後ではDivision Bのデータのみが検索されることを点線で示しています。
問合せのフィルタ処理の他に、Oracle Virtual Directoryでは各アダプタに優先度を割り当てることもできます。常に優先度の数値が小さいアダプタから順に問合せの対象になります。優先度の数値が同じアダプタは、構成ファイルでの定義順に検索されます。競合が発生した場合(2つのエントリが同じDNを持つ場合など)、Oracle Virtual Directoryは常に優先度または構成の数値が小さい方のアダプタの応答のみを受け入れます。ルーティングのフィルタで1つのアダプタを選択できなかった場合、競合が発生する可能性がありますが、優先度の選択によって解消されます。
アダプタを作成したら、Oracle Directory Services Managerでアダプタの「ルーティング」タブを使用して、そのアダプタのルーティングを構成できます。この項では、「ルーティング」タブで実行可能なアダプタ・ルーティング設定について説明します。この項の内容は次のとおりです。
|
注意: アダプタの「ルーティング」タブの「適用」ボタンをクリックして、アダプタのルーティング設定に行った変更を適用します。変更を行う前に構成されていたルーティング設定に戻すには、「回復」ボタンをクリックします。「適用」をクリックすると、設定を元に戻せなくなります。 |
複数のアダプタでネームスペースが重複している場合など、他のアダプタより先に特定のアダプタが処理されるように、Oracle Virtual Directoryを設定することが必要になる場合があります。このような状況は、既存のディレクトリをオンライン状態にしたまま新しいディレクトリを使用可能にする場合に発生します。
優先度の設定により、アダプタが他のアダプタに対して相対的に処理される優先度が決定されます。最も高い優先度は1で、100が最も低くなります。デフォルトの設定は50です。
既存のディレクトリをオンライン状態にしたまま新しいディレクトリを使用可能にする前述の例のような状況では、より新しくより重要なアダプタの優先度の設定は、より高い優先度(つまり、デフォルトの50より小さく、なおかつネームスペースが重複する既存のアダプタより小さい数値)に設定する必要があります。
優先度は、他のルーティング・パラメータがすべて処理されてから、最後のセレクタとして使用されます。その他の点で同等の2つの候補がある場合、優先度が高い(数値が小さい)方のアダプタが先に処理されます。優先度の数値が同じアダプタは、構成ファイルでの定義順に検索されます。同じDNをサポートするアダプタが2つあるなど、検索操作で競合が発生した場合、Oracle Virtual Directoryでは、構成の優先度の数値が低い方のアダプタが先に使用されます。変更操作では、エントリからツリーを上位にさかのぼって先に一致したアダプタ内のエントリのみが処理されます。
|
注意: 正確を期すために、複数のアダプタが選択される構成での判断基準として、「含めるフィルタ」、「除外するフィルタ」および「DN一致」の設定を使用することをお薦めします。 |
「含めるフィルタ」および「除外するフィルタ」の設定は、基本的にフィルタのフィルタで、クライアントによって指定されたLDAP検索フィルタに適用されます。クライアント検索フィルタが「含めるフィルタ」設定に定義された論理的要件を満たしている場合、そのアダプタが選択され、検索に使用するアダプタ・セットに含められます。同様に、「除外するフィルタ」設定の場合は、論理的要件が満たされると、クライアント検索に使用するアダプタ・セットからそのアダプタが除外されます。
「含めるフィルタ」および「除外するフィルタ」フィールドの書式では、標準のLDAP検索フィルタの後にスコープ条件(#base、#oneまたは#sub)が続きます。このスコープは、フィルタを適用するスコープ・レベルを示します。たとえば、#oneスコープを使用するフィルタは、1レベルまたはサブツリーの検索に適用され、ベース検索はフィルタ処理されません。
包含フィルタのデフォルト・スコープは#subで、サブツリー全体に関する問合せのみが除外されます。すべてのスコープにフィルタを適用するには、スコープを#baseに設定します。これにより、フィルタはベース、1レベル、およびサブツリーの検索に適用されます。
除外フィルタのデフォルト・スコープは#oneで、特定の検索がブロックされます。すべてのスコープにフィルタを適用するには、スコープを#baseに設定します。サブツリー検索のみにフィルタを適用するには、スコープを#subに設定します。
「含めるフィルタ」と「除外するフィルタ」の両方の設定を同時に使用することで、より複雑な条件セットを作成して、クライアント検索操作で使用されるアダプタを管理できます。たとえば、ファイアウォールとしてデプロイされたLDAPアダプタを介する、特定の種類の検索を許可するとします。特定の検索のみを許可するには、次のような「含めるフィルタ」設定を使用します。
(|(mail=*@myorg.com)(uid=*@myorg.com)(sn=*)(givenname=*)(cn=*))
このフィルタでは、mail、uid、sn、givennameまたはcn以外の条件の検索がブロックされます。許可されるのは、これらの条件の1つ以上を伴う検索のみです。たとえば、(cn=Jim Smith)は受け入れられますが、(uid=smith@oracle.com)はmyorg.comで終わらないため受け入れられません。
ほとんどのアダプタ構成では、単純な検索条件が使用されますが、より複雑な例を参考にすると、ロジックの適用方法をより理解できます。そこで、次に示すフィルタの例をみてください。
クライアント検索コマンド
$ ldapsearch -b dc=oracle,dc=com -s sub "(|(sn=user2)(cn=user2b))"
ルーティング・フィルタ:
(&(|(uid=*)(cn=*))(sn=*))
このルーティング・フィルタは、クライアント検索フィルタに1つのsn属性、およびuidまたはcnのどちから一方の条件が含まれる場合に一致となることを示します。この例では、他の条件に関係なく、指定されたルーティング・フィルタが「含めるフィルタ」設定に割り当てられている場合はアダプタが選択され、「除外するフィルタ」設定に割り当てられている場合は選択解除されます。これは、クライアント・フィルタにsnおよびcnの条件が含まれており、フィルタのロジックが満たされるためです。
DN一致は、アダプタ間で同じアダプタ・ルートを共有する場合や、どのエントリがどのアダプタに属すかを判断する方法が必要な場合に、最も使用されます。DN一致を使用すると、プロキシ設定された2つのソース間で発生するネーミングの相違を利用できます。たとえば、大規模な開発では、アルファベットに基づいてエントリを分けることもできます。DN一致では、アルファベットの範囲を選択し、範囲の一致に基づいてOracle Virtual Directoryでアダプタを選択できます。たとえば、名前を3つの範囲に分割する場合は、ユーザーのIDの先頭文字を基準に、AからJを1つのディレクトリ、KからRを別のディレクトリ、SからZを最後のディレクトリ部分のように指定できます。
DN一致のもう1つの役立つシナリオとしてあげられるのは、Microsoft Active DirectoryユーザーとOpen LDAPやその他のディレクトリなどの外部ディレクトリに含まれるユーザーとのフェデレーションです。Open LDAPのユーザーにuid属性に基づく相対識別名(RDN)が設定されており、Active Directoryにcn属性に基づくユーザー・エントリがある場合は、RDNタイプに基づいてアダプタを選択する正規表現を設定できます。
Active DirectoryアダプタのDN一致は次のようになります。
(.*)cn=[a-z0-9]*$
Open LDAPのDN一致は次のようになります。
(.*)uid=[a-z0-9]*$
DN一致を使用することで、Oracle Virtual Directoryでは、既存のソースの相違を利用して、重複するアダプタを効果的に管理できます。
「DN一致」フィールドには、アダプタ内のDNの書式を示す正規表現を入力できます。この正規表現は、アダプタ・ルートの下のDN部分に適用されます。たとえば、アダプタのルートがou=People,o=MyBigOrg.comで、次のレベルにあるRDNの先頭文字がAからJまでのエントリのみを許可する場合は、次のような式を指定します。
m/^(.*)uid=[a-j][a-z0-9]*$/
この式は、DNにuid=の条件が含まれ、その後にAからJの文字があり、その後に任意の数の英数字が続く必要があることを示しています。$記号は文字列の終わりを示します。この場合、文字列の終わりのカンマは除外されるため、uid=がこのアダプタ内のDNの最後の構成要素であることが必要です。UID値はAからJで始まる必要があるため、この条件と一致するUIDのみが受け入れられます。最後に、正規表現の^(.*)部分は、なんらかの文字(種類と数は特定しない)が文字列の最初(^の部分)と特定の値uid=の間に含まれることを示しています。
|
注意:
|
使用する複数のアダプタの一部がその他のアダプタの子である場合は、親アダプタを構成して子アダプタのネームスペース内で発生する問合せが親アダプタに送信されないようにする必要が出てきます。これは、LDAP操作のDNが、通常のネームスペース選択を介して子アダプタと親アダプタの両方に関係する場合に発生します。親アダプタの深さ(レベル)を設定すると、Oracle Virtual Directoryで子トランザクションから親アダプタを排除できます。
ルーティングの「レベル」設定をLDAP検索とともに使用すると、検索ベースとなる、アダプタ・ルートの下のレベル数を指定できます。たとえば、値0では、検索ベースがアダプタのルートと同じになり、値1では、検索ベースがアダプタのルートまたは1つ下のレベルになります。デフォルトの設定である空(空白)の「レベル」設定では、すべてのレベルで検索が行われます。
「レベル」設定は、複数のアダプタが複雑にネストされた状況を混在させる場合に便利です。ルート・アダプタは、仮想化ツリーのすべての問合せに対して選択される可能性がありますが、その他のアダプタが関連データを含むツリーの一部を指すように設定されている可能性があるため、望ましくありません。ルート・アダプタを、実際にルート・エントリを調査する問合せ以外のすべての問合せから除外するには(つまりサーバーのパフォーマンスを向上させるには)、「レベル」設定を0に設定する必要があります。
たとえば、ローカル・ストア・アダプタがo=Oracle.comと定義されている場合は、ou=Partner1, o=Oracle.comおよびou=Partner2, o=Oracle.comなどの一連のLDAPアダプタの共通の親として使用できます。この場合、o=Oracle.comは子アダプタのプレースホルダになります。アダプタのエントリは1つのみであるため、検索ベースがo=Oracle.comである操作に対してのみの問合せを行う必要があります。検索ベースがou=Partner1, o=Oracle.comの場合には、このアダプタを検索する必要はありません。この場合、ルーティングの「レベル」の値は0が適切です。
「属性フロー」ルーティング設定は、アダプタへの属性のフロー、およびそのアダプタからの属性のフローを制御します。「属性フロー」ルーティング設定は、認証されていないクライアントからの情報のリクエストや、そのようなクライアントに情報が戻されるのを防ぐことによりセキュリティを実現します。また、結合ビュー・アダプタの場合は、複数のアダプタが同じ仮想結合エントリをもたらす可能性があるため、どの属性がどのアダプタに送られるかを制御するのに「属性フロー」ルーティング設定が役立ちます。
|
注意: アクセス制御とは異なり、属性フロー規則は内部で適用されます。つまり、単純にリクエストがフィルタ処理されるのみで、クライアントにはエラーは戻されません。セキュリティ性の高い設定では、この内部での適用により、クライアント側では、特定の属性の表示が許可されているかどうかさえ知ることができません。 |
次に、「属性フロー」ルーティング設定のリストを示します。各設定については、この項の残りの部分で詳細に説明します。
「取得可能な属性」設定は、ターゲット・ディレクトリ上のアダプタで取得される属性を制御します。「取得可能な属性」設定では、プロキシ設定されたサーバーから追加、変更、削除などの操作をリクエストできるのは指定された属性に対してのみであるため、サーバーのパフォーマンスや、場合によってはセキュリティの向上に貢献します。
また、結合ビュー・アダプタの使用時に、「取得可能な属性」設定を使用して属性フローを制御できます。結合ビュー・アダプタでは、2つ以上のアダプタからのエントリが結合されるため、どの属性を関連アダプタから取得するのかを制御する必要があります。結合ビューの関連アダプタから取得できる属性を制御するには、結合ビューの各アダプタに「取得可能な属性」設定を構成します。
「取得可能な属性」フィールドに、アダプタから取得できる属性の明示的なリストを指定します。リストが空の場合は、すべての属性が取得可能です。「取得可能な属性」フィールドに指定されているリストは、リストに含まれている属性のみがプロキシ設定されたディレクトリからリクエストされることを示します。
|
注意: DNおよびオブジェクト・クラスは、アダプタの「取得可能な属性」ルーティング設定に関係なく、常にldapsearchから戻されます。必要に応じて、ObjectClass Mapperなどのプラグインを使用してDNまたはオブジェクト・クラスを変更できます。 |
「格納可能な属性」設定は、ターゲット・ディレクトリ上のアダプタに格納される属性を制御します。「格納可能な属性」設定では、プロキシ設定されたサーバーに追加、変更、削除などの操作が送信されるのは指定された属性とその値のみであるため、サーバーのパフォーマンスや、場合によってはセキュリティの向上に貢献します。
また、結合ビュー・アダプタの使用時に、「格納可能な属性」設定を使用して属性フローを制御できます。結合ビュー・アダプタでは、2つ以上のアダプタからのエントリが結合されるため、どの属性を関連アダプタに送信する必要があるかを制御する必要があります。結合ビューの関連アダプタに送信する属性を制御するには、結合ビューの各アダプタに「格納可能な属性」設定を構成します。
「格納可能な属性」フィールドに、アダプタに書き込まれる属性のリストを入力します。リストが空の場合は、「格納できない属性」が定義されていないかぎり、すべての属性が格納可能です。「格納できない属性」が指定されている場合は、「格納可能な属性」フィールドにリストされている特定の値のみが格納可能です。
アダプタを読取り専用にするには、「格納可能な属性」のリストに_neverを入力します。_文字は属性名では無効なため、この条件が満たされることはなく、アダプタは読取り専用になります。
アダプタの「可視性」ルーティング設定は、外部クライアントによるアダプタへの問合せが可能かどうか、また、ルート・エントリの下にあるサーバーのnamingcontexts属性で公開されるかどうかを制御します。次に、各「可視性」設定のリストと説明を示します。
|
注意: 「可視性」のオプションは、Oracle Directory Services Managerのインタフェースに英語でのみリストされますが、「可視性」の各オプションの説明はローカライズされた言語翻訳でサポートされています。 |
デフォルトの設定。可視アダプタは、namingcontexts属性の一部としてサーバーのルート・エントリにルートが公開されるアダプタです。
可視性を「いいえ」に設定すると、アダプタはnamingcontexts属性に含まれませんが、外部のLDAPクライアントでは使用できます。複数のアダプタが同時に機能して単一のディレクトリ・ツリー・ブランチを形成している場合に便利です。論理ツリー全体は暗黙的に利用できる上、子アダプタの公開はアプリケーションにとって冗長で複雑なため、namingcontextsに含まれる親およびすべての子アダプタを公開せずに、ルート・アダプタのみを公開することもできます。
「内部」に設定されているアダプタは、Oracle Virtual Directory内部で実行されるプラグインおよび結合ビュー・アダプタでのみ使用できるアダプタです。「内部」のアダプタは、外部のLDAPクライアントでは使用できません。結合ビュー・アダプタで使用するために構成されたアダプタは、これに当てはまります。外部の仮想ディレクトリで情報を2度公開するかわりに、プライマリ・アダプタおよびジョイナ・アダプタを「内部」としてマーク付けすると、これらのアダプタで定義された情報に結合ビュー・アダプタのみがアクセスできるようになります。
「バインド・サポート」オプションは、アダプタがLDAPバインド操作を処理できるかどうかを示します。アダプタがバインド機能をサポートしない場合、Oracle Virtual Directoryは、指定されているDNに対応するエントリからのuserPassword属性の取得を試行し、ローカル・パスワードの比較操作を実行します。これは、LDAPアダプタで「パススルー・モード」設定を「なし」に設定することと同じです。バインド操作をサポートするかどうかが不明なカスタム・アダプタを定義する際に、「バインド・サポート」設定を有効化します。
ホストのエラーによってアダプタでの検索操作が失敗した場合、Oracle Virtual Directoryでは「重要性」設定に基づいて処理が行われます。次に、各「重要性」設定のリストと概要を示します。
|
注意: 「重要性」のオプションは、Oracle Directory Services Managerのインタフェースに英語でのみリストされますが、「重要性」フィールドの説明はローカライズされた言語翻訳でサポートされています。 |
デフォルトの設定。これは、操作エラーやすべてのリモート・ホストが失敗した場合など、アダプタが結果を戻すのに失敗した場合、Oracle Virtual Directoryでは検索操作全体が失敗し、その他のアダプタでデータが検出されたかどうかに関係なく、クライアントにDSA使用不可というエラーが戻されることを示します。
この設定では、アダプタで操作の実行に失敗しても、Oracle Virtual Directoryでは、全体的な結果には重大ではないと認識されます。重大でないアダプタで操作上のエラーが発生した場合は、単純に、LDAP検索結果全体からその結果が省略されます。Oracle Virtual Directoryによってその他のアダプタからの結果の一部が戻されますが、エラーは示されません。
アダプタの重要性を「partial」に設定すると、アプリケーションを介して、結果の一部が取得されたことをユーザーに通知できます。エラーが発生すると、Oracle Virtual Directoryによって「管理制限を超えました」というエラーが戻されます。これは、実際の内容とは異なるエラーですが、この設定の目的は、クライアント・アプリケーションのロジックによって、表示されている結果が全体の一部にすぎないことが示されることです。
「ビュー」では、Oracle Virtual Directoryの様々な情報をアプリケーションから参照できるようにします。ビューは、「ビュー」フィールドに構成された識別名(DN)またはIPアドレスによって定義されます。アダプタがビューに対して有効な場合は、「ビュー」で構成されたDNまたはIPアドレスのみが、そのアダプタからのデータを表示できます。アダプタは、1つまたは複数のビューに対して有効にできます。ビューのメンバーであるユーザーは、同じビューに対して有効なアダプタからの情報のみを参照できます。
アダプタをビューに対して有効にするには、アダプタの「ルーティング」タブで、適切なビューの「有効化」オプションを選択します。ビューに対して有効にされていないアダプタは、デフォルト・ビューに属します。ビューに割り当てられていないすべてのクライアントは、デフォルト・ビューに含まれるすべてのアダプタを表示できます。
ビュー作成および構成するには、次の手順を実行します。
Oracle Directory Services Managerにログインします。
タスク選択バーから「拡張」を選択します。拡張ナビゲーション・ツリーが表示されます。
ツリーで「サーバー・ビュー」を開きます。既存のビューのリストが表示されます。
ビューを作成するには、次のようにします。
「新規ビューの追加」ボタンをクリックします。「新規ビューの追加」ダイアログ・ボックスが表示されます。
「ビュー名」フィールドにこのビューの名前を入力し、「OK」ボタンをクリックして、新規ビューを作成します。既存のビューのリストに新規作成したビューが表示されます。
ビューを構成するには、次の手順を実行します。
ビューを構成するには、次のようにします。
既存のビューのリストで、構成するビューの名前をクリックします。このビューのDNおよびIPアドレスを構成できる画面が表示されます。
このビューにDNまたはIPアドレスを追加するには、適切なフィールドで「作成」ボタンをクリックし、値を入力し、「適用」ボタンをクリックします。
ビューからDNまたはIPアドレスを削除するには、削除する値を選択し、「削除」ボタンをクリックします。
「バインドを含める」および「バインドを除外」の設定は、現在のアダプタのネームスペースの下にないDNを解決するのに使用されるメカニズムです。これらの設定は、どのアダプタが互いの資格証明を共有できるかを管理者に示します。また、これらの設定は、ユーザー資格証明またはアダプタのプロキシ・アカウントが操作で渡される必要があるかどうか、アダプタが判断するのに役立ちます。
たとえば、Microsoft Active Directoryフォレスト内の2つの異なるドメイン・コントローラをプロキシ設定する、異なるLDAPアダプタについて考えてみます。Oracle Virtual Directoryでは、1つのドメインからのユーザー資格証明は、別のドメインの一部として認識されません。また、両方のドメインが同じフォレストに属すため、2番目のドメインでは実際に別のドメインからの資格証明が受け入れられることは明白です。管理者は、「バインドを含む」および「バインドの除外」設定を使用して、このような状況の処理方法をOracle Virtual Directoryに対して指定できます。
ユーザー資格証明を渡せるかどうかを決定する際に、Oracle Virtual Directoryでは次の2つの条件が考慮されます。
提供された資格証明が現在のアダプタのルートの下にあるか。
ユーザー資格証明が「バインドを含む」フィールドにリストされているアダプタの下にマップされているか。また、ユーザー資格証明が「バインドの除外」フィールドにリストされている除外アダプタの下にマップされているか。
例は、次の項を参照してください。
アダプタのルートがou=admin,o=depts,dc=oracle,dc=comである場合の例を次に示します。ユーザー資格証明は、次のいずれかに当てはまります。
ケースA: ou=admin,o=depts,dc=oracle,dc=comのネームスペース内にマップされます。
ケースB: ou=admin,o=depts,dc=oracle, dc=comのネームスペース内にマップされません(たとえば、資格証明のDNがou=sales,o=depts, dc=oracle,dc=comで終わるなど)。
ケースA
ユーザー資格証明がou=admin,o=depts,dc=oracle,dc=comで終わる場合:
「バインドの除外」フィールドが空でない場合は、ユーザーの資格証明をチェックして、除外アダプタの子であるかどうかを確認する必要があります。
ユーザーの資格証明が除外アダプタの子である場合は、クライアントの資格証明を渡すのではなく、プロキシ資格証明を使用する必要があります。
ユーザー資格証明が除外アダプタに属さない場合は、ユーザー資格証明が現在のアダプタを通過します。
この状況が最も発生するのは、2つのLDAPアダプタが定義されていて、2番目のアダプタが最初のアダプタ(親アダプタ)の子である場合です。子アダプタの一部である資格証明は、誤って親アダプタの一部でもあるとみなされる可能性があります。「バインドの除外」設定を使用すると、子アダプタの資格証明が不正に親アダプタに渡されるという問題を修正するのに役立ちます。「バインドの除外」設定を使用することで、特定の子DNが親アダプタの資格証明セットにマップされないことをOracle Virtual Directoryに認識させることができます。
ケースB
ユーザー資格証明がou=admin,o=depts, dc=oracle,dc=comとは異なるルートで終わる場合:
「バインドを含む」フィールドが空ではないが、共有として定義されているアダプタがある場合は、ユーザー資格証明をチェックして、共有アダプタにマップされているかどうか確認する必要があります。
ユーザーの資格証明が共有アダプタにマップする場合は、共有アダプタが資格証明をマップし、元のアダプタに戻します。その後、元のアダプは、共有アダプタによってマップされた資格証明を渡すことが可能になります。
資格証明が現在のアダプタまたはいずれかの共有アダプタにマップされない場合は、提供された資格証明を渡すかわりに、プロキシ資格証明を使用する必要があります。
Oracle Virtual Directoryが複数のMicrosoft Active Directoryドメインにプロキシを設定するのは、このシナリオの一例です。ユーザー資格証明のルートが異なる場合でも、すべてのプロキシの行き先は同じフォレストであるため、1つのドメイン・コントローラによって別のドメイン・コントローラからのDNが認証されます。この場合は、どちらのアダプタからの資格証明でも、両方のアダプタで同様に共有できます。
たとえば、Domain AアダプタによってDomain Aがプロキシ設定され、Domain BアダプタによってDomain Bがプロキシ設定されます。Domain AおよびDomain Bは同じフォレストに存在します。そのため、Domain AおよびDomain Bアダプタの両方で、「バインドを含む」設定をDomain AとDomain Bに設定でき、両方のアダプタがそれぞれの資格証明を相互に渡すことができます。
この例は「バインドを含める」および「バインドを除外」機能を説明します。
バインドを含める。2つのアダプタが存在すると仮定します。
A1はルートがroot dc=oracle,dc=comで、同じremotebaseを持ちます。
A2はルートがdc=example,dc=comで同じremotebaseを持ちます。
この場合、A1とA2が互いに信頼し、すなわち、互いの資格証明をパススルーできます。「バインドを含める」機能の意図は、管理者がA1のために信頼されるすべてのアダプタを構成するようにすることです。そうすることによって、管理者は認証されたユーザーが信頼されるアダプタのいずれかに属しているかを確認でき、ユーザーが信頼されるアダプタのいずれにも属していない場合には、プロキシ資格証明を使用します。この設定は主に、同じAD FORESTS内で複数のドメイン制御の間で信頼を構成するのに使用されます。
ユーザーがバインドDN: cn=jsmith,dc=oracle,dc=com Search baseDN: dc=example,dc=comでバインドと検索を実行する場合:
この検索ではA2がヒットするだろうが、資格証明はA1によって認証されていたでしょう。しかし、A2はA1からの資格証明を信頼するため、このユーザーがそのネームスペースの下でなくてもA2はバインドDN(cn=jsmith,dc=oracle,dc=com)をパススルーする必要があります。
このシナリオを実現するには、A2の「バインドを含める」リストでA1を構成します。
バインドを除外。2つのアダプタが存在すると仮定します。
A1ルートがdc=oracle,dc=comです。
A2はルートがdc=us,dc=oracle,dc=comです。
ユーザーがバインドDN: cn=jsmith,dc=us,dc=oracle,dc=com Search baseDN: dc=users,dc=oracle,dc=comでバインドと検索を実行する場合:
この検索ではA1がヒットするだろうが、資格証明はA2によって認証されていたでしょう。A1がまたバインドDNのネームスペースを満たしているという理由のみで、ユーザーがそのネームスペースの下に存在すると仮定して、A1はA1自身に対してバインドDN(cn=jsmith,dc=us,dc=oracle,dc=com)にサイレント・バインドを実行する必要はありません。このシナリオを実現するために、A1の「バインドを除外」リストでA2を構成します。この場合、A1はそのバインドDNを使用しようとしませんが、プロキシ資格証明を使用して検索を実行します。
