1つのサーバー・インスタンスにプロキシの機能とディレクトリ・サーバーの機能をデプロイすると便利な場合があります。この章では、対象となるデプロイメントでサポートされるシナリオと制限について説明します。
この章には次のトピックが含まれます:
混在デプロイメントのシナリオを設計する際には、いくつかの点を考慮する必要があります。この項ではこの考慮事項について説明します。内容は次のとおりです。
Oracle Unified Directoryをoud-setup
コマンドを使用してディレクトリ・サーバーとしてインストールする場合、次の点に注意する必要があります。
ローカル・バックエンド、Kerberos、EUSおよびパススルー認証ワークフロー要素のみを使用できます。
仮想ACIはサポートされません。
ローカル・バックエンドの拡張機能をすべて使用できます。これには、パスワード・ポリシー、グループ、集合属性、仮想属性、特権、参照整合性、パスワード記憶、7ビットなどがあります。
ローカル・バックエンド・ワークフロー要素にはレプリケーションを使用できます。
Oracle Unified Directoryをプロキシ・サーバーとしてインストールする場合、パススルー認証や結合機能を関連するワークフロー要素を使用して実現できます。ただし、次のことに注意してください。
非ローカル・ワークフロー要素をすべて使用できます。これにはLDAPプロキシ、結合、リネーム、変換、RDN変更、ADページング、分散およびロード・バランシングがあります。
パススルー認証またはEUSのいずれかを使用できます。
ローカル・バックエンドを結合参加要素として使用できます。
ローカル・バックエンドの拡張機能はサポートされません。
ローカル・バックエンド・ワークフロー要素にはレプリケーションを使用できます。
ローカル・バックエンド・ワークフロー要素に定義されたACIは結合またはパススルー認証レベルでのDNマッピングに対応していないため、仮想ACIを使用する必要があります。
仮想ACIを使用できますが、バインド・ルールで使用できるのはバインドDNのみです。バインド・ルールの詳細は、第9.7.2項「仮想ACI構文」を参照してください。
仮想ACIバックエンドをレプリケートできます。
クライアントがディレクトリ・サーバーへのバインドを試行するとき、認証用のユーザー資格証明がローカルで格納されておらず、認証(Auth)サーバーと呼ばれるリモートの別のディレクトリ・サーバーに格納されている場合、パススルー認証メカニズムが使用されます。これは、ユーザーが認証を試行すると、バインド・リクエストがリモートのLDAPサーバーに転送されますが、他の操作はディレクトリ・サーバーによってローカルで処理されることを意味します。このようなデプロイメントは、パススルー認証と呼ばれます。図4-1は、パススルー認証メカニズムを示しています。
ユーザー・パスワードは、リモートLDAPサーバーに格納されますが、ユーザー・エントリの他の属性はすべて、ローカルのOracle Unified Directoryに格納されます。
パススルー認証の構成の詳細は、第12.4.4項「パススルー認証の理解」を参照してください。
パススルー認証は結合ワークフロー要素を使用して構成することもできます。詳細は、第24.2項「仮想ディレクトリからの検索結果の最適化」を参照してください。
LDAPアダプタやデータベース・ストアなどのソースで、リモート・データ・ストアに対してスキーマ拡張機能を必要とするが、スキーマ拡張機能がビジネスまたは技術的な理由により使用できない場合には、Shadowジョイナによってそれらのエントリを格納できます。Shadowジョイナでは、ローカル・バックエンド・ワークフロー要素など、シャドウ・ディレクトリと呼ばれるその他のストアの拡張属性を格納できます。Shadowジョイナの詳細は、第12.5.1.5.4項「Shadowジョイナ・タイプ」を参照してください。
図4-2は、シャドウ結合の構成を示しています。リモート・ワークフロー要素にはユーザー・エントリが含まれる一方で、ローカル・バックエンドには地域属性や説明属性、およびリモート・サーバーとの結合が含まれます。