3 移行ストラテジの検証

Directory Server Enterprise EditionをOracle Unified Directoryに移行するストラテジを選択した後、次のステップではストラテジを検証します。この章では、潜在的な障害を検出し、選択したストラテジを検証するためのガイダンスを示します。

この章の内容は次のとおりです。

第3.1項「選択したストラテジの検証」
第3.2項「DSEEバージョンの検討」
第3.3項「(O)DSEEのレガシー機能の調整」
第3.4項「(O)DSEE技術特性の影響」

3.1 選択したストラテジの検証

選択した最適な移行ストラテジを検証するには、選択したストラテジについて、(O)DSEEリリース、使用されるパスワード・ポリシーのバージョン、および第2章「移行ストラテジの選択」で識別されるもの以外に(O)DSEE固有の機能(ロール、サービス・クラスなど)が使用されるかどうか、という側面をすべて検討する必要があります。

3.2 DSEEバージョンの検討

次のようにレプリケーション・ゲートウェイが使用される場合、DSEEバージョンは移行に影響します。

パスワード・ポリシー状態のレプリケーション

DSEE 5.2ではパスワード・ポリシー属性セットが使用されます。DSEE 6.0以上では、新しく標準のパスワード・ポリシー属性(DS6-mode)セットが導入されました。DSEE 5.2パスワード・ポリシーとDS6パスワード・ポリシーのどちらを選択するかは、構成によって決まります。

OUDとレプリケーション・ゲートウェイは標準属性を管理します。(O)DSEEとOUDの間で完全に機能するパスワード・ポリシーでは、すべての(O)DSEEインスタンスをDS6モードで実行する必要があります。

デフォルトのパスワード・ポリシー・モードからDS6モードに切り替えるには、管理操作が必要です。

パスワード・ポリシーの詳細は、Oracle Directory Server Enterprise Edition管理者ガイドのパスワード・ポリシーの互換性に関する項を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Directory Server Enterprise Edition 11g リリース1 (11.1.1.7)ライブラリにあります。

DSEE 5.2インスタンスまたは既存の(O)DSEEトポロジ内にある古いパスワード・ポリシー・モードの(O)DSEEインスタンスでは、(O)DSEEとOUDの両方にスキーマ拡張が必要です。

レプリケーション・ゲートウェイの統合

レプリケーション・ゲートウェイは、互換性のあるODSEEマスター・インスタンスと通信する必要があります。つまり、レプリケーション・ゲートウェイに接続されるODSEEサーバーのうち、少なくとも1つはODSEE 11gR1 (11.1.1.5)インスタンスである必要があります。1つもない場合は、レプリケーション・ゲートウェイで使用するためにODSEE 11gをトポロジに追加する必要があります。このODSEE 11gR1およびそのレプリケーション・ゲートウェイを同じボックス内に配置しておくことも、既存のインスタンスをODSEE 11gR1 (11.1.1.5.)以上にアップグレードすることもできます。

注意:

OUD 11gR2 (11.1.2.3)では、レプリケーション・ゲートウェイはDSEE 6.3インスタンスと通信できますが、DSEE 5.2などの古いバージョンは、やはりODSEE 11gインスタンスが追加で必要になります。

図3-1 レプリケーション・ゲートウェイを使用したOUDへの移行プロセス

「図3-1 レプリケーション・ゲートウェイを使用したOUDへの移行プロセス」の説明

3.3 (O)DSEEのレガシー機能の調整

選択したストラテジに関係なく、次のものはOUDを使用するために調整する必要があります。

ロールベースのACI
ロールとサービス・クラス(CoS)
カスタム・パスワード・ポリシー

3.3.1 ロールベースのACI

ロールベースのACIを使用すると、ユーザー・ロールに基づいてデータへのアクセスを管理できます。ロールベースのACIはOUD 11g R2 リリース2 (11.1.2.3)ではサポートされていないため、そのようなACIは、使用するストラテジに関係なく、移行プロセス中にグループベースのACIに調整および置換する必要があります。

レプリケーション・ゲートウェイ・ストラテジを使用する場合、ACIを含むすべてのディレクトリ・メタデータがレプリケートされます。つまり、ロールベースのACIは、共存が確立される前に(O)DSEE上のグループベースのACIに置換する必要があります。

DIPストラテジを使用する場合、同期をデプロイする前に(O)DSEE上のそのようなACIを調整するか、またはそのようなACIの同期の除外を検討する必要があります。

ロールベースのACIの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Directory Server Enterprise Edition 11g リリース1 (11.1.1.7)ライブラリにあります。

3.3.2 ロールとサービス・クラス(CoS)

第4.6.6項「OUDへのロールの移行」および第4.6.5項「サービス・クラス(CoS)の管理」で説明しているように、(O)DSEEのロールとサービス・クラスは、同等のOUDメカニズムに置換する必要があります。場合によっては、対応するOUDメカニズムでディレクトリ・メタデータを使用する必要があります。たとえば、サービス・クラス定義は、ユーザー・データとともに格納されるOUD集合属性定義に置換できます。

レプリケーション・ゲートウェイ・ストラテジを使用する場合、これらのOUD固有のメタデータを(O)DSEEにレプリケートできます。そのような場合、これらの追加属性とオブジェクト・クラスをサポートするように(O)DSEEスキーマを拡張する必要があります。互換性のために(O)DSEEサーバーで使用できるOUDスキーマの抽出内容は、OUD: INSTALL_DIR/config/ds2oud/99OudSchemaExtract.ldifで使用できます。

ロールとCoSの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Directory Server Enterprise Edition 11g リリース1 (11.1.1.7)ライブラリにあります。

3.3.3 カスタム・パスワード・ポリシー

カスタム・パスワード・ポリシーは、データの一部として(O)DSEEに格納できます。このようなパスワード・ポリシー定義は、(OUDでサポートされる)標準属性と(OUDの他の属性に置換される) (O)DSEE固有の属性で構成されます。さらに、特定のユーザー・エントリへのパスワード・ポリシーの割当ては、(O)DSEEとOUDで異なります。

レプリケーション・ゲートウェイ・ストラテジを使用する場合、一部のOUD固有のメタデータをレプリケートできますが、(O)DSEEスキーマ拡張が必要です。互換性のためにODSEEサーバーで使用できるOUDスキーマの抽出内容は、OUD: INSTALL_DIR/config/ds2oud/99OudSchemaExtract.ldifで使用できます。

カスタム・パスワード・ポリシーの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』を参照してください。このドキュメントは、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlのOracle Directory Server Enterprise Edition 11g リリース1 (11.1.1.7)ライブラリにあります。

3.3.4 データの矛盾の管理

OUDは、属性値構文の検証を含む完全なスキーマ検査を実装するため、(O)DSEEに格納されているユーザー・データの特性が移行に影響する可能性があります。(O)DSEEは完全なスキーマ検査を実装しないため、(O)DSEEで受け入れられる一部の値はOUDでは拒否される可能性があります。これらのデータの矛盾は、OUDに付属する診断ツールを使用して識別できます。これらの問題に対処するには、移行前のデータの修正、スキーマの修正、OUDでのチェックの実行など、複数の方法があります。

3.4 レビュー: (O)DSEE技術特性の影響

次の表に、(O)DSEE技術特性の影響を示します。アスタリスク(*)は、移行が双方向のレプリケーションを必要としない場合に優先されるオプションであることに注意してください。このオプションを使用すると、一方向のレプリケーションは変更を(O)からOUDにのみレプリケートするため、(O)DSEE側の影響が軽減します。

表3-1 既存のディレクトリ・サーバー・リリース

ディレクトリ・サーバー・リリース	レプリケーション・ゲートウェイ	DIP	直接
DSEE 5.2	1つのODSEE 11gインスタンスをゲートウェイ・コンパニオンとしてデプロイします。 OUDパスワード・ポリシーを使用してDSEEスキーマを拡張します(*)。制限: (O)DSEEとOUDのパスワード・ポリシーは分離されます	制限: (O)DSEEとOUDのパスワード・ポリシーは分離されます	制限: パスワード・ポリシー状態は移行中にリセットされます。
DSEE 6.x/7.x	OUDパスワード・ポリシーを使用してDSEEスキーマを拡張します(*)。必要に応じて、DSEEパスワード・ポリシー・モードをアップグレードします。	制限: (O)DSEEとOUDのパスワード・ポリシーは分離されます。	制限: パスワード・ポリシー状態は移行中にリセットされます。
ODSEE 11gR1+	グローバル・パスワード・ポリシーが不要な場合は、OUDパスワード・ポリシーを使用してDSEEスキーマを拡張し、古いパスワード・ポリシー・モードをそのまま使用します(*)。必要に応じて、DSEEパスワード・ポリシー・モードをアップグレードします。	制限: (O)DSEEとOUDのパスワード・ポリシーは分離されます。	制限: パスワード・ポリシー状態は移行中にリセットされます。

表3-2 既存のディレクトリ・サーバー・データ

既存のディレクトリ・サーバー・データ	レプリケーション・ゲートウェイ	DIP	直接
メタデータ: ロールベースのACI	移行前にDSEE ACIを更新します。	移行前にDSEE ACIを更新しますまたは OUDのACIを調整し、ACIを同期しません。	ACIを調整します。
メタデータ: CoS/ロール	CoS/ロールを調整します。オプションで、DSEEスキーマを拡張します(*)。	CoS/ロールを調整します(同期しません)。	CoS/ロールを調整します。
メタデータ: サブ・エントリとしてのパスワード・ポリシー(データ内)	パスワード・ポリシーを調整します。オプションで、移行前にパスワード・ポリシーを更新します。	可能であれば、カスタム・パスワード・ポリシーを同期または調整しません。	パスワード・ポリシーを調整します。
DSEE内のデータが無効です(LDAPスキーマと完全に一致しません)。	DSEE内のデータを修正しますまたは OUDのスキーマ検査を緩和しますまたは OUDのスキーマを更新します。	DSEE内のデータを修正しますまたは OUDのスキーマ検査を緩和しますまたは OUDのスキーマを更新します。	DSEE内のデータを修正しますまたは OUDのスキーマ検査を緩和しますまたは OUDのスキーマを更新します。

3.4.1 ds2oudを使用した関連する(O)DSEE機能の識別

OUDには、移行に影響する(O)DSEE機能を自動的に識別するds2oudという診断ツールが用意されています。診断モードでは、ds2oudは、OUDに完全に対応するものがない、現在使用中の(O)DSEE固有の機能を識別することもできます。これには、ロールとサービス・クラスが含まれます。ds2oudツールは構成およびスキーマを移行し、調整が必要な(O)DSEE機能を識別するため、すべてのストラテジで役に立ちます。ds2oudツールが特に役立つのは、レプリケーション・ゲートウェイ・ストラテジを使用する場合です。これは、ゲートウェイはユーザー・データ以外にディレクトリ・メタデータをレプリケートするためです。このツールは(O)DSEEスキーマとデータも分析して、OUDによって実装されるLDAPスキーマに準拠していることを確認します。

診断モードでのds2oudコマンド実行の詳細は、『Oracle Fusion Middleware Oracle Unified Directoryの管理』の第A.2.3項「ds2oud」を参照してください。

『Oracle Fusion Middleware Oracle Unified Directoryの管理』は、http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.htmlにあります。