移行ストラテジの検証

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

Directory Server Enterprise EditionをOracle Unified Directoryに移行するストラテジを選択した後、次のステップでは選択したストラテジを検証します。

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

3.2 DSEEバージョンの検討

レプリケーション・ゲートウェイが移行に使用される場合、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管理者ガイド』のパスワード・ポリシーの互換性を参照してください。

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

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

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

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

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

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

3.3 (O)DSEEのレガシー機能の概要

Oracle Unified Directoryは、選択したストラテジに関係なく、(O)DSEEから特定の機能を導入して使用します。

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

3.3.1 ロールベースのACI

ロールベースのACIを使用して、ユーザー・ロールに基づいてデータへのアクセスを管理できます。Oracle Unified Directory 12c (12.2.1.4.0)はロールベースのACIをサポートしていないため、そのようなACIは、使用するストラテジに関係なく、移行プロセス中にグループベースのACIに調整および置換する必要があります。

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

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

ロールベースのACIの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のディレクトリ・サーバーのアクセス制御に関する項を参照してください。

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

(O)DSEEのロールとサービス・クラスを同等のOUDメカニズムに置き換える必要があります。対応するOUDメカニズムでディレクトリ・メタデータの使用が必要な場合もあります。たとえば、サービス・クラス定義は、ユーザー・データとともに格納されるOUD集合属性定義に置換できます。

詳細は、OUDへのロールの移行の概要およびクラス・サービス(CoS)の理解を参照してください。

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

ODSEEのロールおよびCoSの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のディレクトリ・サーバーのグループ、ロールおよびCoSに関する項を参照してください。

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管理者ガイド』のディレクトリ・サーバーのパスワード・ポリシーに関する項を参照してください。

3.3.4 データの矛盾の影響

OUDは、属性値構文の検証を含む完全なスキーマ検査を実装するため、(O)DSEEに格納されているユーザー・データの特性が移行に影響する可能性があります。(O)DSEEは完全なスキーマ検査を実装しないため、(O)DSEEで受け入れられる一部の値はOUDでは拒否される可能性があります。

これらのデータの矛盾は、OUDに付属する診断ツールを使用して識別できます。これらの問題に対処するには、移行前のデータの修正、スキーマの修正、OUDでのチェックの実行など、複数の方法があります。

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

(O)DSEEの技術特性は、Directory Server Enterprise EditionからOracle Unified Directoryへの移行に影響を及ぼします。

次の表に、(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.5 ds2oudを使用した関連する(O)DSEE機能の識別

Oracle Unified Directoryには、移行に影響する(O)DSEE機能を自動的に識別するds2oudという診断ツールが用意されています。

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