| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
この章では、プロキシ・サーバー・インスタンス固有の機能について説明します。内容は次のとおりです:
プロキシを使用して、複数のデータ・ソースまたはレプリケートされたLDAPサーバー間でリクエストをロード・バランシングすることができます。
ロード・バランシング・デプロイメントでは、リクエストは、設定されているロード・バランシング・アルゴリズムに基づいて、データ・ソースの1つにルーティングされます。
次のいずれかのロード・バランシング・アルゴリズムを選択できます:
フェイルオーバー。複数のリモートLDAPサーバーが、特定の操作タイプに対して、サーバー上で構成されている優先度に基づいてリクエストを処理します。エラーが発生すると、その操作タイプに対して次に優先度が高いサーバーに、リクエストが送信されます。
詳細は、第12.1.1項「フェイルオーバー・ロード・バランシング」を参照してください。
最適。複数のリモートLDAPサーバー間に優先度が設けられません。飽和レベルが最も低いLDAPサーバーが、リクエストを処理するサーバーになります。最適なルートが選択されるように、リモートLDAPサーバーの飽和レベルは定期的に再評価されます。
詳細は、第12.1.2項「最適ロード・バランシング」を参照してください。
比例。すべてのリモートLDAPサーバーが、設定された比率(重み)に基づいてリクエストを処理します。
詳細は、第12.1.3項「比例ロード・バランシング」を参照してください。
飽和。飽和制限に達するまで、1つのメインLDAPサーバーがすべてのリクエストを処理します。
詳細は、第12.1.4項「飽和ロード・バランシング」を参照してください。
検索フィルタ。複数のLDAPサーバーがデプロイされ、リクエスト検索フィルタの特定の属性に基づいてリクエストを処理します。詳細は、第12.1.5項「検索フィルタ・ロード・バランシング」を参照してください。
フェイルオーバー・アルゴリズムを使用したロード・バランシングでは、プロキシが、特定の操作タイプ(追加操作など)に対して優先度が一番高いリモートLDAPサーバーまたはデータ・センターにリクエストをルーティングします。リモートLDAPサーバーが停止するまで、プロキシは優先度ルートにリクエストを送信し続けます。これは、ネットワークの切断、ハードウェアの障害、ソフトウェアの障害などの問題が原因になります。フェイルオーバーにより、プロキシは、特定の操作タイプに対する2番目の優先度のサーバーに着信リクエストをルーティングします。
図12-1は、フェイルオーバー・ロード・バランシングの構成を示しています。この例では、3つのルートがあり、それぞれ、操作タイプごとに一意の優先度が設定されています。追加操作はすべて、最高優先度(priority=1)が設定されているサーバー1によって処理され、バインド操作はサーバー2によって処理されます。サーバー1が停止すると、追加リクエストは、2番目の優先度が設定されているサーバー2に送信されます。
デフォルトでは、停止したサーバーが再度実行しても、プロキシはそのサーバーへのリクエストの再ルーティングをすぐには行いません。たとえば、サーバー1が停止すると、追加リクエストはサーバー2に送信されます。サーバー1が再起動しても、着信した追加リクエストは、サーバー2が処理し続けます。ただし、サーバー2が停止して、サーバー1が再起動している場合、サーバー1が着信リクエストを再び受信するようになります。このデフォルト動作は、switch-backフラグで変更できます。switch-backフラグの構成については、第18.1.3.5.2項「switch-backフラグの設定」を参照してください。
フェイルオーバーを効果的に実行するには、ビジネス・ニーズに合った間隔内でフェイルオーバーが発生するように監視チェック間隔を低く設定する必要があります。監視チェック間隔の詳細は、第32章「Oracle Unified Directoryの監視」を参照してください。
最適ロード・バランシング・アルゴリズムでは、プロキシは、最低飽和レベルのルートにリクエストを送信します。ルート上のリモートLDAPサーバーの飽和レベルが、そのデプロイメントでの他のリモートLDAPサーバーの飽和レベルを超えるまで、プロキシはリクエストをこのルートに送信し続けます。飽和レベルは割合で表されます。
ルートの飽和レベルが変わると、ロード・バランシング・アルゴリズムが最適なルートを再評価し、必要に応じて別のルートを選択します。最低飽和レベルのルートが、常に最適ルートとして選択されます。図12-5の構成では、最低飽和レベルのサーバーはサーバー1であり、この飽和レベルが他のサーバーの飽和レベルを超えるまで、サーバー1がすべてのリクエストを処理します。サーバーの1つが停止すると、その飽和レベルは100%になります。
飽和精度を構成して、ルートが最低飽和レベルのサーバーに切り替わる前の2つのサーバー間の飽和レベルの差を設定できます。デフォルトでは、飽和精度は5に設定されています。ただし、アルゴリズムがサーバー間で頻繁に切り替わっている場合は、飽和精度を10に設定できます。飽和精度はLDAPサーバーの拡張で設定します。詳細は、第18.1.3.5.3項「最適アルゴリズムまたは飽和アルゴリズムでの飽和精度の設定」を参照してください。
飽和レベルは、接続プール内の使用中の接続数と、その構成済の最大サイズとの割合を示します。接続プールの最大サイズは、LDAPサーバー拡張オブジェクトの拡張パラメータの1つです。
使用中の接続数が、最大プール・サイズの2で割った数より小さい場合、飽和は0になります。これは、プールが飽和していないことを意味します。
接続の半分以上が使用中である場合、次のように飽和レベルが計算されます:
100 * (1 - 使用可能な接続数/(最大プール・サイズ/2))
この計算により、すべての接続が使用中であるとき、飽和レベルが100になります。
比例ロード・バランシング・アルゴリズムでは、プロキシは、複数のルート間において、設定されている比率に基づいて、リモートLDAPサーバーまたはデータ・ソースにリクエストを転送します。ルートによって処理されるリクエストの比率は、構成内の各ルートに対して設定した重みによって識別されます。重みは整数値で表されます。
ロード・バランシングを構成する際に、各LDAPサーバーが処理するリクエスト比率を示す必要があります。図12-3の例では、2:1という重みが設定されているため、サーバー1は、サーバー2の2倍の数の接続を処理します。サーバー2とサーバー3は、同じリクエスト量を処理します(1:1)。
図12-4に示されているように、クライアント操作の各タイプに対して重みを構成できます。たとえば、サーバー1で全バインド操作を処理するように設定できます。そのためには、バインドの重みをサーバー1は1 (以上)に設定し、サーバー2とサーバー3は0に設定します。
図12-4の例では、サーバー1は、サーバー2とサーバー3の3倍の追加リクエストを処理します。ただし、サーバー1が処理する検索リクエストは、サーバー2とサーバー3が処理する半分になります。サーバー2とサーバー3は、追加リクエストと検索リクエストについて同じ量を処理しますが、バインド・リクエストは処理しません。
図12-4のように、バインド、追加および検索以外の操作の重みを変更しなければ、サーバーは他のすべての操作(削除など)については、同じロードを共有します。
比例ロード・バランシングにおけるルートの重みの構成の詳細は、第18.1.3.5項「ロード・バランシングのプロパティの変更」を参照してください。
飽和ロード・バランシング・アルゴリズムでは、プロキシは、選択された優先度のルートにリクエストを送信します。そのルートのリモートLDAPサーバーが、設定されている飽和しきい値を超えるまで、プロキシは、その優先度のルートにリクエストを送信し続けます。飽和しきい値は割合で表されます。
たとえば、1つのリモートLDAPサーバーですべての着信リクエストを管理する必要がある場合、このサーバーに優先度1を設定します。飽和索引が70%に達するとリクエストの処理を停止するように同じリモートLDAPサーバーを設定するには、図12-5のように、飽和しきい値を70%に設定します。このようにすると、サーバーは飽和レベルが70%に達するまで、全着信リクエストを処理します。そして、プロキシは、次に優先度の高いサーバー2に、リモートLDAPサーバーへの新しいリクエストをすべて送信します。サーバー2は、サーバー2の飽和しきい値に達するまで、またはサーバー1の飽和レベルが再び低くなるまで、リクエストを処理し続けます。
つまり、サーバー1の飽和レベルが70%に達すると、プロキシはサーバー2にリクエストを送信し始めます。サーバー1が70%のままで、サーバー2が60%に達すると、プロキシは、新しいリクエストをサーバー3に送信します。
ただし、サーバー2がリクエストを処理しているときに、サーバー1の飽和レベルが55%まで落ちると、サーバー2が飽和しきい値に達していない場合でも、プロキシはサーバー1に新しい全リクエストを送信し始めます。
すべてのルートが飽和しきい値に達する場合、プロキシは、飽和レベルが最低のルートを選択します。
サーバーが飽和レベルに達したときに警告を発するように、飽和しきい値アラートを設定することができます。たとえば、飽和しきい値アラートを60%に設定した場合、サーバーがこの値に達すると通知が届き、サーバーのパフォーマンスが低下しすぎないうちに対応策をとることができます。
飽和レベルの決定方法の詳細は、第12.1.2.1項「飽和レベルの決定」を参照してください。
検索フィルタ・ロード・バランシング・アルゴリズムでは、プロキシは、リクエスト検索フィルタで定義されている特定属性に基づいてLDAPサーバーに検索リクエストをルーティングします。
トポロジは、プロキシ経由でアクセス可能な複数のLDAPサーバーで構成されます。すべてのLDAPサーバーには似たデータが含まれますが、各サーバーが、より高いパフォーマンスを提供するように検索フィルタで定義された属性に基づいて最適化されます。各ルートを、許可属性リストと禁止属性リストで構成できます。リクエストの検索フィルタに少なくとも1つの許可属性が含まれ、禁止属性が含まれていない場合に、検索リクエストはルートと一致します。
図12-6は、検索フィルタ・ロード・バランシング・アルゴリズムを示しています。この例では、3つのLDAPサーバーがあり、3つの個別ルートが設定されています。LDAPサーバー1は索引としてuid属性を持ち、LDAPサーバー2は索引としてcn属性を持ち、3つ目のLDAPサーバーはパススルー・ルートです。
プロキシが、検索フィルタにuid属性を含む検索リクエストを受信すると、検索リクエストは、より高いパフォーマンスのためLDAPサーバー1にルーティングされます。同様に、検索フィルタにcn属性が含まれている場合、検索リクエストはLDAPサーバー2にルーティングされます。他のすべての検索リクエストは、パススルーLDAPサーバー3にルーティングされます。
追加、削除、変更などのその他すべてのリクエストは、優先度ベースでLDAPサーバーにルーティングできます。各検索フィルタ・ルートに優先度が設定されます。この優先度によってルートの評価順序が決まります。検索フィルタに一致し、優先度が一番高いルート・フィルタが、リクエスト処理用に選択されます。すべての検索フィルタ・ルートの優先度が同じ場合、どのルートでもリクエストを処理できます。
Oracle Unified Directoryの分散機能は、水平スケーラビリティなど、全エントリを単一のデータ・ソースまたはLDAPサーバーに格納できない大規模デプロイメントに対応できる機能です。また、分散を使用して、1秒当たりの更新回数を調整することができます。
分散デプロイメントでは、まずデータを小さなチャンクに分割する必要があります。データを分割するには、split-ldifコマンドを使用します。このようなデータ・チャンクをパーティションと呼びます。通常、各パーティションは別々のサーバー上に格納されます。
データの分割は、次の分散アルゴリズムのいずれかに基づきます:
数値。エントリを、命名属性(たとえばuid)の数値に基づいて、パーティションに分割し、分散します。詳細は、第12.2.1項「数値分散」を参照してください。
辞書編集。エントリを、命名属性(たとえばcn)のアルファベット値に基づいて、パーティションに分割し、分散します。詳細は、第12.2.2項「辞書編集分散」を参照してください。
容量。エントリは、各パーティションの容量に基づいてパーティションに追加されます。このアルゴリズムは、追加リクエストにのみ使用されます。他のすべてのリクエストは、グローバル索引カタログまたはブロードキャストによって分散されます。詳細は、第12.2.3項「容量分散」を参照してください。
DNパターン。エントリを、エントリDNのパターン(値)に基づいて、パーティションに分割し、分散します。詳細は、第12.2.4項「DNパターン分散」を参照してください。
選択するデータ分散タイプは、ディレクトリ・サービス内のデータの編成方法によります。数値分散と辞書編集分散は、特別な分散形式を持ちます。DNパターンは、既存のデータ分散モデルと一致させるのに使用できます。
クライアント・リクエスト(追加以外)が、分散パーティションの1つとリンクできない場合、グローバル索引カタログが構成されていないかぎり、プロキシは、着信リクエストをすべてのパーティションにブロードキャストします。
ただし、リクエストが分散範囲外であることが明確な場合は、このリクエストは、エントリが存在しないことを示すエラーとともに返されます。たとえば、分散パーティションにuidが1-100 (partition1)と100-200 (partition2)が含まれている状態で、ベースDNがuid=222,ou=people,dc=example,dc=comの検索を実行すると、プロキシは、このエントリが存在しないことを示します。
さらに、数値アルゴリズムと辞書編集アルゴリズムの場合、分散ベースDNの直下の最初のRDNが、リクエストの処理用に使用されます。たとえば、次の検索はエラーを返します。uidが分散ベースDN (たとえばou=people,dc=example,dc=com)の直下の最初のRDNでないためです。
$ ldapsearch -b "uid=1010,o=admin,ou=people,dc=example,dc=com" "objectclass=*"
パーティション数は慎重に決めてください。デプロイメント内のパーティション数を定義する際、後でデータを分割し、新しいパーティションに再分散する場合、ダウンタイムが必要になることを念頭に置いておく必要があります。ただし、初期パーティション外のエントリを持つデータで、新しいパーティションを追加することはできます。
たとえば、初期パーティションが、uidが1-100のデータ(partition1)と100-200のデータ(partition2)で構成されている場合に、後で、200-300のuidを含むpartition3を追加することはできます。ただし、partition1とpartition2を分割して、たとえばpartition1に1-150のuidを含め、partition2に150-300のuidを含めることは簡単ではありません。パーティションの分割は、新しい分散デプロイメントを再構成するのと実質同じです。
数値アルゴリズムを使用する分散では、プロキシは、リクエスト内の分散ベースDNの直下の最初のRDNの数値に基づいて、リクエストをパーティションの1つに転送します。数値アルゴリズムの分散を設定する場合、選択した属性の数値に基づいてデータベース上のデータをパーティションに分割します。このとき、選択する属性が数値文字列を表すものである必要があります。プロキシは、同じ数値アルゴリズムを使用して、適切なパーティションにすべてのクライアント・リクエストを転送します。
たとえば、図12-7に示されているように、エントリのuidに基づいて、2つのパーティションにデータを分割できます。
この例では、uidが1111のエントリの検索はパーティション1に送信され、uidが2345のエントリの検索はパーティション2に送信されます。定義されているパーティション範囲外のuidのエントリに対するリクエストについては、そのエントリが存在していないことが示されます。
|
注意: 分散アルゴリズムの上限は含まれません。つまり、この例においては、uidが |
例12-1 数値分散アルゴリズムを使用した検索例
次の検索は成功します:
$ ldapsearch -b "uid=1010,ou=people,cn=example,cn=com" "cn=Ben"
ただし、次の検索では、エントリが存在しないことが示されます(結果コード32):
$ ldapsearch -b "uid=1010,o=admin,ou=people,cn=example,cn=com" "objectclass=*" $ ldapsearch -b "uid=99,ou=people,cn=example,cn=com" "objectclass=*"
プロキシが、上記定義されている分散アルゴリズムでエントリの所属するパーティションを判断できないため、次の検索はブロードキャストされます:
$ ldapsearch -b "ou=people,cn=example,cn=com" "uid=*"
辞書編集アルゴリズムを使用する分散では、プロキシは、リクエスト内の分散ベースDN直下の最初のRDNのアルファベット値に基づいて、リクエストをパーティションの1つに転送します。辞書編集アルゴリズムの分散を設定する場合、選択した属性のアルファベット値に基づいてデータベース上のデータをパーティションに分割します。プロキシは、同じアルゴリズムを使用して、適切なパーティションにすべてのクライアント・リクエストを転送します。
たとえば、図12-8に示されているように、エントリのcnに基づいて、2つのパーティションにデータを分割できます。
この例では、cnがBenなど、Bで始まるエントリに対するリクエストはパーティション1に送信され、cnがM-Yのエントリに対するリクエストはパーティション2に送信されます。
|
注意: 分散アルゴリズムの上限は含まれません。つまり、この例において、cn= |
例12-2 辞書編集分散アルゴリズムを使用した検索例
次の検索は成功します:
$ ldapsearch -b "cn=Ben,ou=people,cn=example,cn=com" "objectclass=*"
次の検索も、cn=Benが最初のRDNになるので、成功します。
$ ldapsearch -b "uid=1010,cn=Ben,ou=people,cn=example,cn=com" "objectclass=*"
ただし、次の検索では、エントリが存在しないことが示されます(結果コード32):
$ ldapsearch -b "cn=Ben,o=admin,ou=people,cn=example,cn=com" "objectclass=*" $ ldapsearch -b "cn=Zach,ou=people,cn=example,cn=com" "objectclass=*"
次の検索は、所属するパーティションを判断できないので、ブロードキャストされます:
$ ldapsearch -b "ou=people,cn=example,cn=com" "cn=*"
容量ベースの分散では、プロキシは、各パーティションの容量に基づいて追加リクエストを送信します。これは、パーティションに含めることができるエントリの最大数により判断されます。他のすべてのリクエストは、グローバル索引カタログまたはブロードキャストによって分散されます。
データは完全無作為にパーティションに分散されるため、特定のデータ・エントリが所属するパーティションを識別する最も簡単な方法はグローバル索引を使用する方法です。容量分散を使用する場合は、グローバル索引は必須です。グローバル索引がセットアップされていない場合、追加以外のすべてのリクエストはブロードキャストされます。グローバル索引の詳細は、第12.3項「グローバル索引カタログ」および第18.1.7項「コマンド行を使用したグローバル索引の構成」を参照してください。
図12-9の例では、パーティション1は、パーティション2の2倍の容量があるので、パーティション1は、パーティション2より2倍の追加リクエストを受信します。この場合、両方のパーティションが同時に一杯になります。すべてのパーティションが一杯になったら、各サイクルで各パーティションに1つのリクエストが送信されます。
DNパターン・アルゴリズムを使用する分散では、プロキシは、リクエスト・ベースDNと文字列パターンとの照合に基づいて、リクエストをパーティションの1つに転送します。照合は、リクエスト・ベースDNの相対部分、つまり、分散ベースDN以下の部分についてのみ行われます。たとえば、図12-10に示されているように、エントリのuid内のDNパターンに基づいて、2つのパーティションにデータを分割できます。
DNパターンを使用する分散は、数値アルゴリズムまたは辞書編集アルゴリズムを使用する分散より面倒です。できるかぎり、別の分散アルゴリズムを使用するようにしてください。
この例では、0、1、2、3または4で終わるuidのすべてのデータ・エントリがパーティション1に送信されます。5、6、7、8または9で終わるuidのデータ・エントリはパーティション2に送信されます。
この分散は、数値を使用していますが、数値分散とはまったく異なります。数値分散では、データは数値の範囲に基づいて分割されますが、DNパターン分散は、データ文字列のパターンに基づきます。
DNパターン・アルゴリズムを使用する分散は、通常、分散パーティションが分散ベースDNに正確に対応していない場合に使用します。たとえば、データが図12-11で示されているように分散されている場合、パーティション1とパーティション2のデータは、ベースDN ou=people,ou=region1とou=people,ou=region2の両方に該当します。データを簡単に分散するには、DNパターンを使用する以外方法がありません。
例12-3 地域別分割DNパターン・アルゴリズムの例
情報のデプロイメントが2つの地域で行われている場合、データの分散にはDNパターン分散を使用するのが簡単です。たとえば、従業員番号が4桁コードで、最初の桁が地域を示している場合、次のようになります:
| 地域1 | 地域2 |
|---|---|
|
1000 |
2000 |
|
1001 |
2001 |
|
1002 |
2002 |
|
1003 |
2003 |
|
1004 |
2004 |
|
1005 |
2005 |
|
1006 |
2006 |
|
1007 |
2007 |
|
1008 |
2008 |
|
1009 |
2009 |
|
1010 |
2010 |
|
... |
... |
データのロードを分散するのに各地域内のエントリを2つのサーバーに分割します。このとき、サーバー1には、0、1、2、3および4で終わるすべてのエントリが含まれ、サーバー2には、5、6、7、8および9で終わるすべてのエントリが含まれます(図12-10参照)。
したがって、DNパターン1222の検索はパーティション1に送信され、2222も同様です。
分散デプロイメントでグローバル索引カタログを使用できます。容量ベース分散を構成する場合、DNを索引とするグローバル索引カタログをセットアップする必要があります。グローバル索引カタログは、エントリと、そのデータを格納する分散パーティションとをマップします。プロキシはクライアントからリクエストを受信すると、分散が、グローバル索引カタログで属性エントリを検索して、クライアント・リクエストを正しいパーティションに転送します。これにより、ブロードキャストの手間を省くことができます。さらに、DN変更リクエストが行われる場合、グローバル索引カタログにより、そのエントリが確実に存在することを確認することができます。
グローバル索引カタログは、従業員番号や電話番号など、特定の属性に基づいてエントリをマップします。索引とする属性値は、全エントリにおいて一意である必要があります。たとえば、一意でない国などに基づいて、グローバル索引を使用してエントリをマップすることはできません。
値が一意でない属性を索引とした場合、プロキシ・サーバーが、リクエストされるすべてのエントリを返せないことがあります。たとえば、必ずしも一意とはかぎらないmail属性を索引にしたとします。そして、次の2つのエントリを連続で追加します:
uid=user.1およびmail=joe.smith@example.comの属性を持つエントリ1はパーティション1に送信されます。
uid=user.2およびmail=joe.smith@example.comの属性を持つエントリ2はパーティション2に送信されます。
この状況では、グローバル索引mailは、2つ目のエントリへの参照のみを保持します。この場合、フィルタ(mail=joe.smith@example.com)の検索を実行すると、2つ目のエントリuid=user.2のみが返されることになります。
グローバル索引カタログには、複数のグローバル索引を含めることができます。各グローバル索引でそれぞれ異なる属性のマッピングを行います。たとえば、電話番号をベースにしたエントリのマッピングを行うグローバル索引と、従業員番号をベースにしたエントリのマッピングを行うグローバル索引を含むGI-catalogというグローバル索引カタログをセットアップできます。この場合、電話番号または従業員番号のいずれかを使用して、正しいパーティションにクライアント・リクエストを転送できます。
グローバル索引カタログとグローバル索引は、gicadmコマンドを使用して作成および構成されます。詳細は、第18.1.7項「コマンド行を使用したグローバル索引の構成」および付録A「gicadm」を参照してください。
グローバル索引には、LDIFファイルからデータを移入できます。1つのLDIFファイルのデータは、split-ldifコマンドを使用してパーティションに分割できます。詳細は、付録A「split-ldif」を参照してください。
シングル・ポイント障害を回避するために、グローバル索引カタログはレプリケートする必要があります。グローバル索引カタログのレプリケートについては、第18.1.7.2項「グローバル索引カタログのレプリケーション」を参照してください。
例12-4 電話番号のグローバル索引カタログの使用
グローバル索引の作成に使用できる一意の属性の一般的な例は、電話番号です。この属性値は一意になるので、その電話番号を持っている人物(従業員など)は1人のみです。
次の例では、データベース内のエントリは電話番号に基づいて分割されています。グローバル索引には、次の情報が含まれています:
| 値 | パーティションID |
|---|---|
|
4011233 |
1 |
|
4011234 |
1 |
|
7054477 |
2 |
グローバル索引には、従業員名、場所または電話番号に関連付けることのできるその他の属性値は格納されません。属性の索引とパーティションとのマッピングのみが行われます。索引値(ここでは電話番号)に関連付けられているデータは、リモートLDAPサーバー上に置かれています。
1人の従業員が複数の電話番号を持っている場合、複数値エントリとしての扱いになります。この場合、グローバル索引が電話番号に基づいて作成される際、たとえばBen Brownという1人の従業員を検出するグローバル索引エントリが2つできるということになります。
前述の例では、従業員Ben Brownには、4011233と7054477の両方の電話番号が割り当てられています。この場合、Ben Brownの1つの電話番号を検索すれば、Ben Brownに2つの電話番号が割り当てられていることとは関係なく、正しいパーティションと、その電話番号に関連付けられている、Ben Brownという名前を含むすべての情報が返されます。
ディレクトリの各エントリは、DNおよび属性と属性値のセットにより識別されます。クライアント側で定義されたDNおよび属性は、サーバー側で定義されたDNおよび属性にマップされない場合があります。たとえば、サンプルAという組織ではdc=parentcompany, dc=comというエントリを使用しているとします。ここに、サンプルBという別の組織が加わりました。このサンプルBは、dc=newcompany, dc=comというエントリを使用しています。つまり、既存のクライアント・アプリケーションを正しく動かすには、dc=newcompany, dc=comをdc=parentcompany, dc=comにリネームする必要があります。
DNリネーム・ワークフロー要素を定義して、DNをサーバー側と一致する値にリネームできます。クライアントがリクエストを行うと、DNと属性の名前がサーバー側と一致するように変更されます。結果がクライアントに返されるときには、DNと属性はクライアント側と一致するよう元に戻されます。
Oracle Unified Directoryでは、ディレクトリ情報ツリー(DIT)のコンテンツを、異なるベースDNの別のDITに変換できるDNリネーム・ワークフロー要素が用意されています。ある操作(追加、バインド、削除、変更など)がDNリネーム・ワークフロー要素を通ることにより、DNリネーム構成に従ってパラメータが変換され、仮想エントリから実際のエントリへの変換が行われます。
図12-12は、プロキシを使用したDNリネームの動作を示しています。
クライアントはou=myorg, dc=server, dc=comエントリを待機します。しかし、LDAPサーバー上のエントリはou=people, dc=server, dc=comです。プロキシは、DNリネーム・ワークフロー要素を使用してしてDNのリネームを行います。
この例では、実際のエントリou=people, dc=server, dc=comを、クライアントからはou=myorg, dc=server, dc=comエントリに見えるようにします。
DNリネーム変換は、次のオブジェクトに対して適用可能です:
エントリのDN。たとえば、LDAPサーバー上の実際のエントリであるdn:uid=user, ou=people, dc=server, dc=comが、クライアントの仮想エントリdn:uid=user, ou=myorg, dc=server, dc=comに変換されます。
DNを含むエントリの属性。たとえば、オブジェクトクラスinetorgpersonmanagerのエントリのmanager属性のサーバー側の値がmanager:uid=mgr, ou=people, dc=server, dc=comである場合に、クライアント側の値であるmanager:uid=mgr, ou=myorg, dc=server, dc=comに変換します。
|
注意: 変換は、エントリのすべてのユーザー属性に適用できます。このとき、該当する属性リストを定義したり、該当しない属性リストを定義することもできます。 |
Oracle Unified Directoryでは、RDNChanging構成を使用して、ソース・ディレクトリからOracle Unified Directoryに対して、RDN値をリネームまたは置換することが可能です。
図12-13は、プロキシを使用したDNリネームの動作を示しています。
|
注意: 相対識別名(RDN)は、エントリDNの左端の要素です。たとえば、 |
RDNChanging構成には、次のパラメータがあります:
RDNの名前変更を実行するオブジェクト・クラスのタイプを指定します。デフォルト設定はpersonです。
TrueまたはFalse: クライアント・ビュー内の元のRDN値(source-rdnパラメータで指定)を新しいRDN値(client-rdnパラメータで指定)に置き換えるかどうかを指定します。デフォルトの設定はtrueです。
|
注意: この値がtrueに設定されており、エントリの新しいRDN属性に複数の値がある場合、Oracle Unified DirectoryではRDNの最初の値が使用されます。 |
Oracle Unified Directoryで置換または変更される、ソース・ディレクトリの元のRDN属性名を指定します。
Oracle Unified Directoryで使用される新しいRDN属性名を指定し、source-rdn構成パラメータで指定されている属性名と置き換えます。
RDNの名前変更を実行するDNを持つ属性のリスト。属性のデフォルト・リストはmember、managerおよびownerです。
Oracle Unified Directoryは、ワークフロー要素の定義を介したデータ変換をサポートしています。ワークフロー要素のインスタンスを作成することにより、物理データを異なる方法で表示できます。この章では、Oracle Unified Directoryで変換がどのように発生するのかについて説明します。この章の内容は次のとおりです:
LDAPクライアント・アプリケーションのデータ構造が、LDAPリポジトリのデータ構造と異なる場合があります。スキーマが異なる場合もあれば(エントリ内の属性タイプが異なる)、値が異なる場合もあります(属性名は同じでも値のセマンティクスが異なる)。これが、変換が必要な対象となります。
1つの変換は、特定の方向における特定のアクションを実行します。必要な変換を指定し、既存のワークフロー要素に対する変換を定義します。
この項には次のトピックが含まれます:
変換の方向は、変換がリクエスト中に適用されるのか、応答中に適用されるのか、または両方に適用されるのかを示し、これにより変換モデルが決まります。
変換は次のタイプに分類できます:
読取り変換(アウトバウンド変換): 詳細は、第12.6.1.1.1項「読取り変換」を参照してください。
書込み変換(インバウンド変換): 詳細は、第12.6.1.1.2項「書込み変換」を参照してください。
マッピング変換(双方向変換): 詳細は、第12.6.1.1.3項「マッピング変換」を参照してください。
読取り変換は、一般的に使用される変換です。読取り変換は、リクエストへの応答中にのみ発生します。リクエスト中には変換は行われず、物理データの変更はありません。
図12-14は、読取り変換の概念を示しています。
組織に、personエントリを表示するレガシー・アプリケーションがあるとします。このアプリケーションは、email属性を含まないエントリをサポートしません。物理データ・ソースはアップグレードされており、email属性はpersonエントリから削除されています。
そこで、検索応答中にemail属性を追加するという変換が必要になります。この変換は、データ・ソースから読み取られるエントリを変更し、email属性を追加します。このとき、この属性値はfirstname.surname@mycompany.comになります。元に戻す変換は必要ないので、物理データは変更されません。
書込み変換は、応答中ではなく、リクエスト中に適用される変換です。書込み変換は、バックエンドに格納する前に、クライアントによって提供されたデータを変更します。
図12-15は、書込み変換の概念を示しています。
組織に、personエントリをデータ・ソースに追加するレガシー・アプリケーションがあるとします。このアプリケーションは、email属性なしでエントリを追加します。物理データ・ソースはアップグレードされており、email属性はpersonエントリの必須属性となっています。そこで、追加リクエスト中にemail属性を追加するという変換が必要になります。この変換は、データベースに書き込むエントリを変更します。逆の変換は必要ありません。
マッピング変換は、一般的に使用される変換です。これは、まず変換がリクエスト中に適用され、逆の変換が応答中に適用されるという双方向の変換です。このような変換は、物理データ・ビュー内の属性またはエントリが、仮想データ・ビュー内の属性またはエントリにマップされるため、マッピング変換と呼ばれます。マッピング変換では、既存値を、DNコンポーネント、属性タイプまたは値、またはオブジェクト・クラスに割り当てる前に、処理することができます。
図12-16は、マッピング変換の概念を示しています。
組織に、surnameおよびfirstnameの属性を持つエントリが格納される物理データ・ソースがあるとします。この組織には、firstname surnameという形式のcn (共通名)属性を持つエントリを要求するクライアント・アプリケーションがあります。
このクライアント・アプリケーションは、cn=Joe Smithという形式のエントリの検索リクエストを送信します。変換は、このリクエスト中に名(firstname)と姓(surname)を抽出し、このリクエストをsurname=Smith, firstname=Joeという形式に変換するように定義されています。対応するエントリは、データ・ソース内にあります。このエントリをクライアント・アプリケーションに戻す前に、逆の変換が実行されます。クライアント・アプリケーションは、認識できるcn=Joe Smithというエントリを受信します。
このリクエストは、surname=Smith, firstname=Joeという形式に変換されます。
Oracle Unified Directoryは、プロキシ・サーバーでの変換をサポートするLDAPサーバーです。
変換を実装するには、次のことが必要です:
変換タイプのワークフロー要素のインスタンスを作成します。
目的のワークフロー要素リストに変換ワークフロー要素を挿入します。
Oracle Unified Directoryのアーキテクチャの詳細は、第5.2項「Oracle Unified Directoryのアーキテクチャ」を参照してください。
変換ワークフロー要素インスタンスは、特定の変換アクションが定義されているデータ・ビューのことです。
この項では、変換のワークフロー要素を構成するためのコンポーネントについて説明します。次のトピックが含まれます:
変換タイプのワークフロー要素は、次の変換セットで構成できます:
|
注意: 説明:
|
この項には次のトピックが含まれます:
addOutboundAttribute変換タイプこの変換は、検索操作中、リクエスト内の属性リストが未定義(つまり、すべて該当)な場合、またはその属性が含まれている場合に、クライアントに返されるエントリに、仮想属性または値を追加します。
エントリに仮想属性がすでに含まれているかどうか判断できない場合、conflict-behaviorパラメータが、次のポリシーのどれを適用するかを決定します:
仮想値を追加しない
仮想値を追加して、既存値とマージする
既存値を仮想値に置き換える
仮想属性をソース・リポジトリで検索できる場合(ソース・リポジトリ内のエントリの一部に仮想属性が含まれており、この属性について検索が最適化されている)、およびフラグvirtual-in-sourceが設定されている場合、変換プロセスは、SEARCH REQUESTフィルタで仮想属性をソース・リポジトリに転送します。通常、仮想属性はソース・リポジトリに転送されません。このパラメータがFALSEに設定されている場合、検索リクエストは一般用に最適化されているということです。つまり、仮想属性はソース・リポジトリには存在していないことを意味します。
|
注意: 追加リクエストまたは変更リクエストに仮想属性を含めることが必要とされる場合は、ソース・スキーマ・チェックが適用されます。したがって、仮想属性を受け入れるようにソースのスキーマを構成することをお薦めします。それ以外の場合は、スキーマ・チェックを無効にしてください。 |
表12-1は、addOutboundAttribute変換タイプのパラメータを説明しています。
表12-1 addOutboundAttribute変換タイプのパラメータ
| パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
|---|---|---|---|---|
|
クライアント仮想属性の名前とクライアント仮想属性の値定義 |
|
S |
M |
文字列 詳細は、第12.6.2.3項「変換のための属性値の定義」を参照してください。 たとえば、 |
|
競合動作ポリシー |
|
S |
O [デフォルト= |
|
|
ソース内の仮想ポリシー |
|
S |
O [デフォルト = |
|
|
エントリが一致する必要があるフィルタベースの条件 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
|
祖先である必要があるDNベースの条件 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
|
処理する操作から操作を除外する条件 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY...) |
filterOutboundAttribute変換タイプこの変換では、ソースから受信したエントリをクライアントに送信する前に、ここから属性または値を削除します。
表12-2は、filterOutboundAttribute変換タイプのパラメータを説明しています。
表12-2 filterOutboundAttribute変換タイプのパラメータ
| パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
|---|---|---|---|---|
|
ソース仮想属性の名前とクライアント仮想属性の値定義 |
|
S |
M |
文字列 詳細は、第12.6.2.3項「変換のための属性値の定義」を参照してください。 たとえば、 |
|
エントリが一致する必要があるフィルタベースの条件 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
|
祖先である必要があるDNベースの条件 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
|
処理する操作から操作を除外する条件 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY...) |
addInboundAttribute変換タイプこの変換は、追加操作の実行中、データをソースに転送する前に、クライアントから受信したエントリに仮想属性または値を追加します。
エントリに仮想属性がすでに含まれているかどうか判断できない場合、conflict-behaviorパラメータが、次のポリシーのどれを適用するかを決定します:
仮想値を追加しない
仮想値を追加して、既存値とマージする
既存値を仮想値に置き換える
表12-3は、addInboundAttribute変換タイプのパラメータを説明しています。
表12-3 addInboundAttribute変換タイプのパラメータ
| パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
|---|---|---|---|---|
|
ソース仮想属性の名前とソース仮想属性の値定義 |
|
S |
M |
文字列 詳細は、第12.6.2.3項「変換のための属性値の定義」を参照してください。 たとえば、 |
|
競合動作ポリシー |
|
S |
O [デフォルト= |
|
|
エントリが一致する必要があるフィルタベースの条件 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
|
祖先である必要があるDNベースの条件 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
|
処理する操作から操作を除外する条件 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY) |
filterInboundAttribute変換タイプこの変換では、追加(および変更)時に、クライアントから受信したエントリ(および変更)をソースに送信する前に、ここから属性または値を削除します。
表12-4は、filterInboundAttribute変換タイプのパラメータを説明しています。
表12-4 filterInboundAttribute変換タイプのパラメータ
| パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
|---|---|---|---|---|
|
クライアント仮想属性の名前とクライアント仮想属性の値定義 |
|
S |
M |
文字列 詳細は、第12.6.2.3項「変換のための属性値の定義」を参照してください。 たとえば、 同様に、 |
|
エントリが一致する必要があるフィルタベースの条件 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
|
祖先である必要があるDNベースの条件 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
|
処理する操作から操作を除外する条件 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY...) |
mapAttribute変換タイプこの変換では、両方向において、クライアント属性を1つのソース属性にリネームしたり、値の変換を行うことができます。
表12-5は、mapAttribute変換タイプのパラメータを説明しています。
表12-5 mapAttribute変換タイプのパラメータ
| パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
|---|---|---|---|---|
|
クライアント属性の名前とクライアント仮想属性からソース仮想属性へのマッピングの値定義 |
|
S |
M |
文字列 詳細は、第12.6.2.3項「変換のための属性値の定義」を参照してください。 たとえば、 |
|
ソース内の仮想ポリシー |
|
S |
O [デフォルト = |
|
|
競合動作ポリシー |
|
S |
O [デフォルト= |
|
|
エントリが一致する必要があるフィルタベースの条件 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
|
祖先である必要があるDNベースの条件 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
|
処理する操作から操作を除外する条件 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY...) |
条件付きで変換ワークフロー要素を構成できます。条件は、transformations-workflow-elementまたは個々のtransformationに対して設定できるプロパティ(属性)です。変換は、LDAPリクエストがすべての条件およびワークフロー要素レベルで設定されているすべての条件を満たしている場合のみ、実行されます。
変換の実装には、次の条件を使用できます:
変換を実施するかどうかを決定するルールに対して条件を構成できます。
transformations-workflow-elementに対して条件を設定できます。この場合、そのworkflow-elementに設定されているすべての変換に対して条件が照合され、各変換が実際に処理される前に評価されます。
個々の各変換に対しても条件を設定でき、この変換の実際の処理前に評価されます。
条件は、広い意味で次のカテゴリに分類されます:
この条件は、指定されている1つの親接頭辞の下にある名前のエントリをターゲットとするLDAP操作のみに適用される変換に対して使用されます。
このタイプの条件が構成されていない場合、処理されるすべてのエントリに対して変換が適用されます。
この条件は、指定フィルタと一致するエントリに対するLDAP操作にのみ適用される変換に対して使用されます。
このタイプの条件が構成されていない場合、処理されるすべてのエントリに対して変換が適用されます。
この条件は、複数値属性のリストを指定し、各属性が、変換によって影響を受けてはならないLDAP操作を示します。各LDAPプロトコル・メッセージに対する変換(ある場合)のアクションを無効にできます。
このタイプの条件が構成されていない場合、このタイプの変換が通常影響するすべてのLDAP操作に対して変換が実行されます。
属性値により、変換中における仮想属性の値を定義できます。この値は、デフォルト値のままにすることもできますし、他の属性値から値を作成するルールにすることもできます。
addInboundAttribute、addOutboundAttributeおよびmapAttributeでは、追加する仮想属性の値を構成する必要があります。filterInboundAttributeおよびfilterOutboundAttributeでは、フィルタリングする値を構成することもできます。
属性は、次から値を導出できます:
静的なデフォルト値の属性を生成したり、属性の静的な値でフィルタリングする場合に使用します。
たとえば、プロパティsource-attribute:mycompany=Acmeは、デフォルトの会社名を指定する際に使用します。
dsconfig --create-transformation \ --type add-inbound-attribute \ --set source-attribute:mycompany=Acme \ --transformation-name virtDeptName \
%inputAttrName%構文を使用して、処理対象のエントリ内の既存の属性から新しい属性を作成したり、別の属性から取得する値をフィルタリングできます。
たとえば、プロパティsource-attribute:displayName=%cn%は、cn属性の値から新しい属性値を取得する必要があることを示します。
dsconfig --create-transformation \ --type add-inbound-attribute \ --set source-attribute:displayName=%cn% \ --transformation-name virtDeptName \
|
注意: 同じ |
{expression}構文を使用して、既存の属性値を操作することにより、属性値を作成したり、属性値をフィルタリングできます。
たとえば、プロパティclient-attribute:mail={%cn%.%sn%@mycompany.com}は、既存の属性の値を組み合せて属性を導出するための正規表現です。
dsconfig create-transformation \
--type add-outbound-attribute \
--set client-attribute:mail={%cn%.%sn%@mycompany.com} \
--transformation-name virtDeptName \
virtAttrName=%refAttrName%(virtValue1,refValue1)(virtValue2,refValue2)構文を使用して、別の属性の値のマッピングとして仮想値を定義します。
virtAttrNameパラメータに対して、変換が、refAttrNameから抽出された値を追加またはフィルタリングします。refAttrNameがrefValue1と一致すれば、変換は、virtValue1に対する追加またはフィルタリングを行います。指定する値内の文字(、)、,および\は\文字でエスケープ処理する必要があります。
たとえば、複数の部署を持つ組織があり、取得される部署IDにより、部署名が、Department:1–Marketing、2–Sales、3–Financeなどのように返されます。ただし、deptIdが1の場合、deptNameに対して返される値はMarketingです。deptIdが2の場合は、deptName値はSalesです。同様に、deptIdが3の場合は、deptNameに対して返される値はFinanceです。
dsconfig --create-transformation \ --type add-outbound-attribute \ --set client-attribute:deptName=%deptId%(Marketing,1)(Sales,2)(Finance,3) \ --transformation-name virtDeptName
virtAttrName=virtAttrValue1=virtAttrValue2=構文を使用して、複数値仮想属性を指定します。
dsconfig --create-transformation \ --type add-outbound-attribute \ --set client-attribute:countriesResp=France=Germany=Italy \ --transformation-name virtCountriesRep
この項では、変換ワークフロー要素の構成方法について説明します。この項の内容は次のとおりです:
transformations-workflow-elementおよびtransformationは、変換構成の中心的なエントリです。
変換ワークフロー要素は、変換への参照リストを含むコンテナです。1つの変換は複数のtransformation-workflow-elementによって再利用できます。条件は、transformations-workflow-elementまたはtransformationのいずれかに対して設定できるプロパティ(属性)です。
表12-6では、transformations-workflow-elementに対して構成できるパラメータについて説明します。
表12-6 transformations-workflow-elementの構成パラメータ
| パラメータ | dsconfig CLI | 複数(M)/単一(S)値 | オプション(O)/必須(M) | 値 |
|---|---|---|---|---|
|
変換タイプのリスト 詳細は、第12.6.2.1項「変換のタイプ」を参照してください。 |
変換オブジェクト(関連付け) |
M |
M |
変換の参照 |
|
エントリが一致する必要があるフィルタベースの条件 詳細は、第12.6.2.2.2項「エントリ一致フィルタ」を参照してください。 |
|
S |
O [デフォルト = ワークフロー要素によって処理されるすべてのエントリに適用] |
LDAPフィルタ |
|
祖先である必要があるDNベースの条件 詳細は、第12.6.2.2.1項「親接頭辞」を参照してください。 |
|
M |
O [デフォルト = ワークフロー要素によって処理されるすべてのリクエストに適用] |
DN |
|
処理する操作から操作を除外する条件 詳細は、第12.6.2.2.3項「除外LDAP操作」を参照してください。 |
|
M |
O [デフォルト = すべてのLDAP操作に適用] |
列挙(ADD、MODIFY...) |
変換の実行順序は構成できません。たとえば、変換Aと変換Bを使用するtransformation-workflow-elementを使用するとします。このとき、エントリに対して変換Aを先に実行してから変換Bを実行するように指定することはできません。Bの後にAである可能性もあります。
変換の実行順序を定義する必要がある場合、たとえば、変換Aを変換Bの前に実行する必要がある場合は、変換Aを使用するtransformation-workflow-elementを最初に作成することをお薦めします。次に、変換Bを使用する別のtransformation-workflow-elementを作成します。そして、2つ目のtransformation-workflow-elementを最初のtransformation-workflow-elementの後に配置します。
図12-17は、高レベルな構成モデルを示しています。
この項の例は、CLIで変換を作成し、変換ワークフロー要素を作成し、変換を追加し、条件を関連付ける方法について説明します。
次の手順で変換を構成します:
まず、filter-outbound-attributeタイプの変換を作成します。
$ dsconfig --create-transformation -X -n -Q -p -D cn="directory manager" -j pwd-file \ --set source-attribute:description \ --type filter-outbound-attribute\ --transformation-name fodescription
add-outbound-attributeタイプの別の変換を作成します。
$ dsconfig --create-transformation -X -n -Q -p -D cn="directory manager" -j pwd-file \ --set client-attribute:legacyemail=%cn%.%sn%@mycompany.com \ --type add-outbound-attribute \ --transformation-name legacyemail
最初の変換でtransformations-workflow-elementを作成し、これを処理フローに追加します。
$ dsconfig --create-workflow-element -X -n -Q -p -D cn="directory manager" -j pwd-file \ --set transformation:legacyemail \ --set set next-workflow-element:pxywfe \ --type transformations \ --element-name trsfwfe
$ dsconfig --set-workflow-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --workflow-name pxywf \ --set workflow-element:trsfwfe
2つ目の変換をワークフロー要素に追加します。
$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --element-name trsfwfe \ --add transformation:fodescription
cn=usersの下の変換のみ実行するという変換条件を定義します。
$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --element-name trsfwfe \ --set entry-parent-suffix:cn=users,dc=oracle
パリにいるユーザーにのみ変換を適用するように設定します。
$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --element-name trsfwfe \ --set entry-match-filter:l=Paris
新しいマッピング変換を作成し、これをワークフロー要素に追加します。
$ dsconfig --create-transformation -X -n -Q -p -D cn="directory manager" -j pwd-file \ --set client-attribute:faxnum=%facsimileTelephoneNumber% \ --type map-attribute \ --transformation-name mapfax
$ dsconfig --set-workflow-element-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --element-name trsfwfe \ --add transformation:mapfax
この変換が人物に対してのみ適用されるように設定します。
$ dsconfig --set-transformation-prop -X -n -Q -p -D cn="directory manager" -j pwd-file \ --transformation-name mapfax \ --set entry-match-filter:\(objectclass=person\)
パススルー認証(PTA)は、あるディレクトリ・サーバーが別のディレクトリ・サーバーにバインド・リクエストの認証を求めるメカニズムです。パススルー認証の一般的なシナリオは、Oracle Unified Directoryからのユーザーについての認証をActive Directoryに渡すなどです。
パススルー認証の使用と操作は、次の項目で説明します。
クライアントがディレクトリ・サーバーへのバインドを試行するとき、認証用のユーザー資格証明がローカルで格納されておらず、認証(Auth)サーバーと呼ばれるリモートの別のディレクトリ・サーバーに格納されている場合、パススルー認証メカニズムが使用されます。ディレクトリ・サーバーは、次に資格証明を検証するために認証サーバーへバインドの操作をリダイレクトします。ここでの資格証明は、userpassword属性を指します。ユーザー資格証明が格納されたAuthサーバーには、Oracle Unified Directory、Microsoft Active DirectoryまたはLDAP V3互換ディレクトリ・サーバーを使用できます。
Oracle Unified Directoryがバインドをリダイレクトする方法は、ユーザー・サーバーのユーザー・エントリが認証サーバーの対応するユーザー・エントリにマップされている方法に完全に依存します。Oracle Unified Directoryでは、ユーザー・エントリと認証エントリ間の1対1のマッピングがサポートされます。
パススルー認証メカニズムについて詳しく理解するために、図12-18に示す例について考えます。
2つのサーバーについて検討します。サーバーAとサーバーBがあり、ユーザー・エントリcn=myuserがサーバーBに保存されているとします。ユーザーがサーバーAにアクセスして操作を実行するように試みる場合、先に認証用の資格証明を使用してサーバーAにバインドする必要があります。ただし、資格証明がサーバーAに存在しないため、通常はサーバーAへのバインドは失敗します。ただし、パススルー認証メカニズムを使用すれば、サーバーAでバインド・リクエストをサーバーBに誘導することで、資格証明を検証できます。サーバーBを使用して資格証明が検証され、バインドに成功すると、サーバーAはバインド操作の成功を返します。
この例のサーバーAは、ユーザー・ディレクトリ・サーバーまたはパススルー認証ディレクトリ・サーバーとして動作します。これは、このサーバーがバインド・リクエストを他のディレクトリ・サーバーに渡すためです。認証ディレクトリ・サーバーBは、認証ディレクトリとして動作し、エントリを格納しており、リクエストしているクライアントのバインド資格証明を検証します。
次に、パススルー認証ワークフロー要素のいくつかの機能を示します。
リクエスト・タイプに応じて、リクエストを特定のワークフロー要素へルーティングできます。たとえば、バインド・リクエストが認証ワークフロー要素へルーティングされます。userpasswordを除く任意の属性にMODIFYを適用する場合は、ユーザー・ワークフロー要素にルーティングされます。userpassword属性へのMODIFYの適用は、認証ワークフロー要素にルーティングされます(さらにパスワードコピーが有効な場合にはユーザー・ワークフロー要素にもルーティングされます)。ADD、DELETE、RENAME、COMPAREおよびSEARCHなどのその他の要素はすべて、ユーザー・ワークフロー要素にルーティングされます。
Kerberosワークフロー要素を認証ワークフロー要素としてサポートします。認証ワークフロー要素がKerberosワークフロー要素の場合、Oracle Unified Directoryが認証リクエストをKerberosサーバーに転送し、認証がLDAPバインドのかわりにKerberosプロトコルを使用して実行されます。
ユーザー資格証明を含んだ外部LDAPサーバーからOracle Unified Directoryへの移行を単純化します。移行フェーズの間に、正常なバインドが行われると、パススルー認証ワークフロー要素がユーザー・パスワードを外部LDAPサーバーからOracle Unified Directoryにコピーします。この機能は、パスワードコピーと呼ばれます。たとえば、ユーザーが正常に認証されると、外部LDAPサーバーの認証ワークフロー要素にバインドがルーティングされます。次に、パススルー認証ワークフロー要素は、ユーザー・ワークフロー要素でこのバインド操作に使用するパスワードを保存します。この移行フェーズでは、移行フェーズの間にアクセスを開始したすべてのユーザーのユーザー・パスワード属性が移入されます。
認証ワークフロー要素のエントリを結合ルールと認証サフィックスによってユーザー・ワークフロー要素のエントリにリンクする方法がサポートされます。この結合ルールは、DN=DNマッピングか、次の形式による単純な結合ルールで指定できます。
auth.<Attribute1>=user.<Attribute2>
結合ルールの詳細は、第14.4項「結合ルール」を参照してください。
ユーザー・エントリと認証エントリ間のマッピングは、1対1のマッピングになる必要があります。これは、ユーザー・プロバイダの各エントリが認証プロバイダの1つのエントリに対応することを意味します。
DNマッピングのサポートにより、たとえばユーザー・ワークフロー要素の接尾辞がdc=user,dc=comである一方で、dc=pta,dc=comの配下にエントリを発行できます。
パスワード変更をサポートします。
ユーザー・ワークフロー要素に対して、ローカルやリモートなど、すべての種類のワークフロー要素をサポートします。
パススルー認証ワークフロー要素を使用する際には、次の点に留意する必要があります。
認証ワークフロー要素はバインド・リクエストのみを処理します。
ユーザー・ワークフロー要素は、ADD、DELETE、RENAME、COMPAREおよびSEARCHなどのその他のすべての操作に使用されます。
MODIFY操作は、save-password-on-successful-bindパラメータに依存します。このパラメータは、パススルー認証ワークフロー要素が認証ワークフロー要素へと正常にバインドしたとき、ユーザー・ワークフロー要素で要求されるとパスワードを保存します。
save-password-on-successful-bindを有効にした場合、両方の参加要素でuserpasswordパラメータが変更されます。
save-password-on-successful-bindを無効にした場合、userpasswordは、認証参加要素のみで変更されます。
user-suffixまたはauth-suffixパラメータを定義する場合、pta-suffixを定義する必要があります。両方のパラメータが、ユーザー認証参加要素とパススルー認証参加要素間のDNリネームに適用されます。
結合ルールを定義するときに、認証およびユーザー・エントリが同じDNを持つ必要がない場合、auth-suffixを定義する必要があります。
user-suffixが定義されていない場合、ワークフロー要素はuser-suffix=pta-suffixを仮定します。auth-suffixが定義されていない場合も同様です。この場合も、ワークフロー要素はauth-suffix=pta-suffixを仮定します。
Oracle Unified Directoryは、パススルー認証ワークフロー要素を使用してパススルー認証を実装します。これにより、異なるディレクトリ・サーバーのインスタンスにあるユーザーおよび認証ディレクトリの管理が可能になります。
ユーザー・プロバイダは、ユーザー・エントリを含んだワークフロー要素であり、これはつまりユーザーのパスワードを除くすべての属性を含みます。一方、認証プロバイダは、ユーザー・パスワードを含んだワークフロー要素です。
|
注意: Oracle Unified Directoryは、ユーザー・プロバイダ・ワークフロー要素および認証プロバイダ・ワークフロー要素の両方のローカル・バックエンドまたはプロキシをサポートします。ただし、Kerberosは認証プロバイダ・ワークフロー要素のみでサポートされます。 |
図12-19は、パススルー認証構成モデルを示しています。
表12-7は、第12.7.4項「パススルー認証の構成モデル」で説明されているパススルー認証構成モデルで使用される構成パラメータについて説明しています。
dsconfigコマンドを使用した、パススルー認証の詳細は、第18.1.9項「dsconfigを使用したパススルー認証の構成」を参照してください。
ODSMを使用したパススルー認証の構成の詳細は、第17.2.4.1項「ワークフロー要素の作成」を参照してください。
表12-7 パススルー認証プロセスで使用されるパラメータの構成
| パラメータ | 説明 |
|---|---|
|
|
ユーザー・プロバイダ・ワークフロー要素 このパラメータは、ユーザー・エントリを含むワークフロー要素を定義します。このワークフロー要素は、BIND以外のすべての操作に使用します。 これは必須パラメータです。 |
|
|
認証プロバイダ・ワークフロー要素 このパラメータは、認証エントリを格納し、リクエストしているクライアントのバインド資格証明を検証するワークフロー要素を定義します。このワークフロー要素は、 これは必須パラメータです。 |
|
|
このパラメータによって、パスワードコピー機能を有効化または無効化できます。このパラメータが これはオプションのパラメータです。デフォルト値は |
|
|
このパラメータは、パスワードコピー機能が有効なときに、ユーザー・エントリでコピーされるパスワード値の属性を定義します。パスワードの保存後、 これはオプションのパラメータです。デフォルト値は |
|
|
このパラメータは、パススルー認証ワークフロー要素によって公開される仮想DNを定義します。 これはオプションのパラメータです。デフォルトでは、このパラメータは設定されず、DNマッピングがないことを意味します。 |
|
|
このパラメータは、ユーザー・プロバイダ・ワークフロー要素のユーザー・エントリを含む実際の接尾辞を定義します。 これはオプションのパラメータです。デフォルトでは、このパラメータは設定されず、DNは |
|
|
このパラメータは、認証プロバイダ・ワークフロー要素の認証エントリを含む実際の接尾辞を定義します。 これはオプションのパラメータです。デフォルトでは、このパラメータは設定されず、DNは |
|
|
このパラメータは、認証エントリとユーザー・エントリ間のマッピングを定義します。 これはオプションのパラメータです。デフォルトでは、このパラメータは設定されず、ルールが |
Oracle Unified Directoryでは、パススルー認証ワークフロー要素を使用した次のLDAPの操作をサポートしています。
パススルー認証ワークフロー要素によって処理されるADD操作はすべて、ユーザー・プロバイダ・ワークフロー要素に送信されます。
save-password-on-successful-bindをtrueに設定した場合、userpassword属性がユーザー・プロバイダ・ワークフロー要素にも保存されます。この機能を無効にした場合、userpassword属性はユーザー・プロバイダ・ワークフロー要素に保存されません。
BIND操作は、認証プロバイダ・ワークフロー要素にルーティングされます。
BINDに成功し、save-password-on-successful-bindパラメータが有効な場合、パススルー認証ワークフロー要素も、パスワードのローカル・コピーがないかどうかを確認するために、ユーザー・プロバイダ・ワークフロー要素にバインドを試行します。バインドに失敗した場合は、userpassword属性がユーザー・プロバイダ・ワークフロー要素にコピーされます。
COMPARE操作は、ユーザー・プロバイダ・ワークフロー要素にルーティングされます。
userpassword属性に適用されるCOMPARE操作は、ユーザー・プロバイダ・ワークフロー要素にルーティングされます。save-password-on-successful-bindが有効化されていない場合、この要素には、この属性が含まれていない可能性があります。
DELETE操作は、ユーザー・プロバイダ・ワークフロー要素のみにルーティングされます。認証サーバーのエントリは削除されません。
userpasswordを除くすべての属性に対して、ユーザー・プロバイダ・ワークフロー要素で変更が実行されます。
userpassword属性の場合:
save-password-on-successful-bindパラメータが有効な場合、パスワードはユーザー・プロバイダ・ワークフロー要素と認証プロバイダ・ワークフロー要素の両方で変更されます。
save-password-on-successful-bindが無効な場合、パスワードは認証プロバイダ・ワークフロー要素のみで変更されます。
認証プロバイダがKerberosワークフロー要素の場合、パスワードの変更操作に失敗します。
パススルー認証ワークフロー要素は、MODIFY_DNをユーザー・プロバイダ・ワークフロー要素のみで処理し、認証プロバイダ・ワークフロー要素のエントリは変更しません。
SEARCH操作は、ユーザー・プロバイダ・ワークフロー要素のみにルーティングされます。これは、userpassword属性に対するリクエストを送信する検索操作は、ユーザー・プロバイダ・ワークフロー要素にコピーがないかぎり値を返さない可能性があることを意味します。
パススルー認証の構成には次のベスト・プラクティスを実施することをお薦めします。
ユーザー・プロバイダ・ワークフロー要素と認証プロバイダ・ワークフロー要素に異なる接尾辞を使用している場合は、データを保護するために仮想ACIを定義することをお薦めします。仮想ACIはpta-suffixを使用して定義します。
認証プロバイダがKerberosワークフロー要素の場合、結合ルールや認証サフィックスは指定しないでください。
認証プロバイダがプロキシ・ワークフロー要素の場合、remote-root-dnを構成する必要があります。
ユーザー・プロバイダがプロキシ・ワークフロー要素の場合、remote-root-dnを構成する必要があります。プロキシ・サーバーは、サイレント・バインドを実行するため、慎重に構成する必要があります。
