4 移行の実行
内容は次のとおりです。
4.1 OUDへの移行の理解
Directory ServerおよびDirectory Proxy ServerをOracle Unified Directoryにアップグレードできます。OUDに移行するには特定のステップを実行する必要があります。
ノート:
直接ストラテジを使用している場合は、「レプリケーション・ゲートウェイまたはDIPのデプロイ」にスキップしてください。
使用している移行ストラテジに関係なく、移行の実行のすべてのステップを実行する必要があります。
4.2 完全なバックアップの作成
Oracle Unified Directoryへの移行を開始する前に、Oracle Directory Server Enterprise Editionのシステムに重要なファイル(バイナリ、データベース・ファイルおよびLDIFを含む)の完全なバックアップを作成します。
ノート:
Oracle Unified Directoryへの移行を開始する前に、使用環境の完全なバックアップを作成することをお薦めします。移行は元に戻せません。ほとんどの場合、エラーが発生したときには、移行を中止してバックアップから環境全体をリストアし、移行プロセスを最初からやり直す必要があります。必ず、状況に合ったバックアップおよびリストア戦略を設計してください。様々なバックアップ・オプション、必要な考慮事項、バックアップおよびリストア戦略を計画するためのガイドラインの詳細は、Oracle Directory Server Enterprise Editionのデプロイメント計画ガイドのバックアップおよびリストア・ポリシーの設計に関する項を参照してください。
関連項目:
- Oracle Directory Server Enterprise Editionの管理者ガイドのバイナリ・バックアップに関する項。
- Oracle Directory Server Enterprise Editionの管理者ガイドのLDIFへのバックアップに関する項。
4.3 参照OUDインスタンスの作成
OUD参照インスタンスは、ODSEEと同等のLDAPサービスが提供されるように構成されます。
まず、OUD 12cをインストールして新しいインスタンスを作成する必要があります。移行ステップの実行中に新しいOUDインスタンスが構成および初期化された後、レプリケートされるトポロジに追加インスタンスを構成およびデプロイするためのベースとして使用されます。
OUDインスタンスのインストール手順は、『Oracle Unified Directoryのインストール』のOracle Unified Directoryのインストールに関する項を参照してください。
次のいずれかの方法で新しいOUDを設定できます。
-
グラフィカル・ユーザー・インタフェース(GUI)
-
コマンド行インタフェース
-
バッチ・モード
ノート:
ディレクトリ・サーバー・インスタンスでSecure Socket Layers (SSL)を使用する場合、ディレクトリ・サーバー・インスタンスの作成時に実際の証明書でSSLを有効にする必要があります。ds2oudコマンドが正常に機能するには、サフィックスを付けずに新しいインスタンスを構成する必要があります。
GUIまたはCLIを使用してディレクトリ・サーバーを構成するには、サフィックス/ベースdnを空白のままにしておく必要があります。『Oracle Unified Directoryのインストール』のグラフィカル・ユーザー・インタフェースを使用したディレクトリ・サーバーの設定およびコマンド行インタフェースを使用したディレクトリ・サーバーの設定を参照してください。
ディレクトリ・サーバーをバッチ・モードで設定する場合は、-bオプションを指定しないでください。
ノート:
ds2oudコマンドは<OUD_INSTANCE>/OUD/binにあります。OUD_INSTANCEはベースOUDインスタンスのパスです。
4.4 ds2oudを使用した(O)DSEEディレクトリ・サーバー、構成、スキーマおよびデータの理解
既存の(O)DSEE設定には、OUD側に対応するものがなく自動的には移行できない特定の機能があります。これらの機能は、移行中に特に注意する必要があります。
(O)DSEEディレクトリ・サーバーにアクセスするためのLDAP管理パスワードがあることを確認します。診断サイクル中にこのサーバーで変更は行われません。詳細は、『Oracle Unified Directoryの管理』のrootユーザーと特権サブシステムの理解を参照してください。
(O)DSEEディレクトリ・サーバーからエクスポートされたユーザー・データを含むLDIFファイルがあることを確認します。LDIFファイルのエクスポートの詳細は、次を参照してください。
-
5.2のLDIFファイルのエクスポートの詳細は、『Sun ONE Directory Server 5.2リファレンス・マニュアル』のデータベースのエクスポートを参照してください。リファレンス・マニュアルは、
http://docs.oracle.com/cd/E19199-01/のSun Java Enterprise System 2003Q4 Webサイトにあります。 -
6.xのLDIFファイルのエクスポートの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3管理ガイド』のLDIFへのエクスポートを参照してください。管理ガイドは、
http://docs.oracle.com/cd/E19261-01/のSun Java System Directory Server Enterprise Edition 6.3 Webサイトにあります。 -
7.0のLDIFファイルのエクスポートの詳細は、『Sun Directory Server Enterprise Edition 7.0管理ガイド』のLDIFへのエクスポートを参照してください。管理ガイドは、
http://docs.oracle.com/cd/E19424-01/のSun Directory Server Enterprise Edition 7.0 Webサイトにあります。 -
11gのLDIFファイルのエクスポートの詳細は、『Oracle Directory Server Enterprise Edition管理ガイド』のLDIFへのエクスポートを参照してください。管理ガイドは、
https://docs.oracle.com/cd/E29127_01/index.htmのOracle Directory Server Enterprise Edition 11gリリース1 (11.1.1.7)ライブラリにあります。
(O)DSEEサーバー・スキーマ拡張を保持するユーザー・スキーマ拡張のコピー(99user.ldif)へのアクセス権があることを確認します。
この診断プロセスは、OUDに付属するds2oudツールを実行することで実行されます。診断モードのds2oudで検出される差異の数を使用すると、複雑性および移行作業を見積もることができます。
4.4.1 (O)DSEEディレクトリ・サーバー、構成およびスキーマの診断
ds2oudコマンドを実行して、Oracle Unified Directoryへの移行の前に(O)DSEE Directory Serverサーバーの構成およびスキーマを診断できます。
次のds2oudコマンドを実行します。
$ ds2oud --diagnose -h host1.example.com -p 1389 \ -D "cn=directory manager" -j pwdfile
前述のコマンドで、host1はOUDサーバーではなく(O)DSEEサーバーです。
--diagnoseサブコマンドは、ディレクトリ・サーバー構成の次の要素を調べます。
-
サポートされていないプラグイン
-
デフォルトのスキーマに対する拡張
-
レプリケーション・ゲートウェイを使用する場合に影響する可能性がある、使用されるパスワード・ポリシーのタイプ
-
暗号化された属性
-
索引設定
-
グローバル構成パラメータ
前述の要素ごとに、ds2oudは移行する必要があるものと潜在的な非互換性(ある場合)を調べます。次に出力の例を示します。
*** diagnose the deployment ... ******************************************************************************* Diagnose ODSEE Server : host1:1389 ******************************************************************************* ** Plugins : No user plugins are defined, nothing particular to migrate ** Plugins : No subtree counter plugins are enabled, nothing particular to migrate ** Schema The schema was extended regarding the original delivery. The following schema should be added to the new OUD server attributeTypes : ( 2.16.840.1.113730.9999 NAME 'customAttributeType' DESC 'Oracle defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN ( 'Custom' 'user defined' ) ) ** Password Policy A compatible password policy is defined, nothing particular to migrate ** Naming context(s) available on the ODSEE server : o=migration No incompatibility has been detected for naming context o=migration ** Indexes Only default indexes are defined, nothing particular to migrate ** Encrypted attributes No encrypted attributes are defined, no action is required
4.4.2 ディレクトリ・サーバー・データの診断
ds2oudコマンドを実行して、ディレクトリ・サーバー・データをOracle Unified Directoryスキーマに対して検証できます。
データをインポートする前に、ディレクトリ・サーバー・データがOUDスキーマに準拠していることを確認するには、次の手順を実行します。
4.4.3 診断中のエラー解決
診断中にスキーマ・エラーを解決する方法を学習します。
次の理由でスキーマ・エラーが報告される可能性があります。
-
デフォルト・スキーマが異なる。
-
OUDに標準スキーマの最新バージョンが使用されている。
-
属性値構文の検証と包含ルールの検証
-
サポートされていないディレクトリ・メタデータ。これには、ロールベースのACI、LDAPサブエントリとしてOUDパスワード・ポリシーで現在サポートされていないロールまたはサービス・クラス定義があります。これらのサブエントリには、(O)DSEEとOUDで異なる(O)DSEE固有の拡張アカウントベースのリソース制限があります。
前述のケースでは、OUDは次のコマンドを提供して、スキーマの制約を柔軟にし、そのスキーマ・エラーを解決します。
構造的なobjectclassエラー:
インポート中にディレクトリ・サーバー・データが拒否されると、構造的なobjectclassエラーが発生します。このエラーの一般的な理由は、ユーザー・エントリの構造化オブジェクト・クラスです。ユーザー・エントリには1つの構造オブジェクト・クラスが必要です。エントリが0個または複数ある場合、エントリは拒否されます。また、(O)DSEEディレクトリ・サーバーは2つのオブジェクト・クラス・タイプを区別しないため、この種のスキーマの矛盾は頻繁に発生します。このエラーを回避するには、次のコマンドを使用します。
dsconfig set-global-configuration-prop --set \ single-structural-objectclass-behavior:accept -n
無効な属性値エラー:
属性値は、スキーマに定義されている属性構文に準拠する必要があります。デフォルトでは、OUDで属性構文チェックが有効になっています。たとえば、ブール構文を持つ属性は、TRUEまたはFALSE値のみを保持できます。また、長さが0の属性値は、インポート中にOUDで拒否されます。ただし、次のコマンドを使用することで、DirectoryString構文でこの制約を柔軟にすることができます。
dsconfig set-attribute-syntax-prop --syntax-name Directory\ String \ --set allow-zero-length-values:true -n
4.5 ディレクトリ・スキーマの移行
移行モードのds2oudツールは、ディレクトリ・ユーザー・スキーマの移行中に(O)DSEEスキーマ拡張をOUD参照インスタンス・スキーマに自動的に追加します。
スキーマはds2oudツールを使用して自動的に移行されます。構成を移行する前にスキーマを移行しないと、後続の移行ステップで構成エラーが発生します。次のコマンドは、(O)DSEEディレクトリ・サーバーからOUDにユーザー・スキーマを伝播し、(O)DSEEスキーマを他のOUDインスタンスに移行する場合にも使用できます。
$ ds2oud --migrateUserSchema -h host1.example.com -p 1389 \ -D "cn=directory manager" -j pwdfile
(O)DSEEスキーマを他のOUDインスタンスに移行する場合、<OUD_INSTANCE>/OUD/config/schemaディレクトリの内容を新しいOUDインスタンスの対応するディレクトリにコピーし、OUDインスタンスを再起動することもできます。
ノート:
ds2oud --migrateUserSchemaコマンドは、(O)DSEEユーザー・スキーまで行われた拡張を処理しますが、ユーザー・データをOUDにインポートするときにスキーマ違反エラーが発生する可能性があります。これは、ユーザー定義スキーマと異なり、標準スキーマは(O)DSEEとOUDで若干異なるためです。インポート・プロセス中にスキーマ違反が発生した場合、(O)DSEE診断プロセスの結果として提示される可能性がある追加のスキーマ拡張を作成する必要があります。
4.6 ディレクトリ構成の移行
OUD参照インスタンスは、(O)DSEEと同等のLDAPサービスが提供されるように構成されます。
(O)DSEEディレクトリ構成の大部分は、移行モードのds2oudツールを使用して自動的に移行されます。
自動的に生成される構成コマンドは、他のインスタンスを迅速に初期化する際に再利用できるように、バッチ・ファイルに保持されます。手動で作成した追加コマンドもそのバッチ・ファイルに追加することをお薦めします。
自動的に移行できないその他の構成要素は、ds2oudを使用した(O)DSEEディレクトリ・サーバー、構成、スキーマおよびデータの理解で特定されています。
この章の内容は次のとおりです。
4.6.1 ds2oudコマンドを使用した構成設定の移行
ds2oudコマンドを実行して、構成設定を(O)DSEEディレクトリ・サーバーからOracle Unified Directoryに移行できます。
-
命名コンテキスト
-
OUDに関連するグローバル構成設定
-
Size-limit
-
Look-through-limit
-
Idle-time-limit
-
Max-psearches
-
Bind-with-dn-require-password
-
Allidthresholds
-
データベース索引
-
グローバル・デフォルト・アクセス制御
-
サポートされている組込みプラグイン
-
7ビット検索
-
UID一意性プラグイン
-
参照整合性プラグイン
-
厳密なパスワード・ポリシー検査
前述の各構成設定を各OUDインスタンスに適用するには、ds2oudコマンドをバッチ・モードで実行する必要があります。次に、dsconfigで適用されるコマンドのリストを生成します。変更を補完し、すべてのターゲット・システムで簡単に再現できるようにするために、これを実行することをお薦めします。
構成を移行するための管理コマンド・バッチ・ファイルを生成するには、次のコマンドを実行します。
ds2oud --migrateConfiguration
--odseeBindDN "cn=directory manager"
--odseePort <ODSEE_PORT>
--odseeBindPasswordFile <ODSEE_ADMIN_PASSWORD_FILE>
--oudBindDN "cn=directory manager"
--oudBindPasswordFile <OUD_ADMIN_PASSWORD_FILE1>
--oudPort <OUD_LDAP_PORT1>
--oudAdminPort <OUD_ADMIN_PORT1>
--no-prompt --batchFile <COMMAND_BATCH_FILE>
この項には次のトピックが含まれます:
4.6.1.1 SSL証明書の移行
デフォルトでは、OUDインスタンスの作成時に自己署名付き証明書が自動的に生成されます。移行がSSLクライアントに対して透過的になるように、新しいOUDインスタンスの(O)DSEEサーバー証明書を再利用することもできます。ただし、使用するSSL証明書オプションに応じて、(O)DSEEサーバーと同じボックスにOUDインスタンスをインストールする必要がある場合があります。
SSLサーバー証明書を再利用するには、次の手順を実行します。
4.6.1.2 PKCS#12キーストアの構成
OUD PKCS12キーストアを構成するには、次のコマンドを実行します。
dsconfig set-key-manager-provider-prop \
-provider-name PKCS12 \
-set key-store-file:config/dsee.p12 \
-set key-store-pin-file:config/dsee.p12.pin \
-set enabled:true \
このコード・サンプルでは、dsconfigコマンドの接続関連の引数(ports、credentialsなど)は、簡略化のため省略されています。
4.6.1.3 PKCS#12キーストアを使用するためのLDAPS接続ハンドラの構成
LDAPS接続を構成するには、次のコマンドを実行します。
dsconfig set-connection-handler-prop \
--handler-name LDAPS\ Connection\ Handler \
--set key-manager-provider:PKCS12 \
4.6.1.5 暗号化された属性の移行
属性を復号化するには、dsconf exportで--decrypt-attrオプションを使用します。LDIFファイルにエクスポートしたときに属性が復号化されることを確認する必要があります。インポート中に値が再暗号化されるように、対応する属性の暗号化をOUDで構成する必要があります。
詳細は、『Oracle Unified Directoryの管理』の属性の暗号化の構成を参照してください。
4.6.2 共存のためのパスワード記憶スキームの理解
共存ストラテジ、つまりレプリケーション・ゲートウェイまたはDIPを使用している場合、OUDパスワード記憶スキームの構成を変更する必要があります。これにより、OUD側で構成されるパスワード記憶スキームが、(O)DSEEでサポートされるアルゴリズムに対応するようになります。それ以外の場合、OUD側でパスワードを変更すると、ユーザーは(O)DSEE側でログインできなくなります。
(O)DSEEでは、パスワードはパスワード暗号化スキーム(SHA-1など)を使用して格納されます。OUDでは、これに似ていますが、デフォルトではパスワードはSSHA512に格納されます。OUDでは、パスワード記憶スキームはパスワード・ポリシーで構成されます。
4.6.3 構成変更の適用
このトピックに提供されたコマンドを使用して、構成の変更をOUDディレクトリ・サーバー・インスタンスに適用できます。
ds2oudコマンドを使用した構成設定の移行で生成された構成の変更を、次のコマンドを使用してOUDディレクトリ・サーバー・インスタンスに適用できます。
dsconfig -h <oud hostname> -p <oud admin port> -D cn="directory manager" -w <admin password> \ -F command_batch_file -X -n
dsconfigコマンドの-Fオプションまたは--batchFilePathオプションを使用して、1つのファイルにまとめることにより1回のコマンドで完了する複数の操作を指定できます。これにより、複数のdsconfigコマンドが必要な場合、パフォーマンスが大幅に向上し、他のインスタンスの構成が簡素化されます。
SSL証明書の移行に示した追加の構成変更も適用する必要があります。
ノート:
スキーマの変更は、常に構成変更の前に適用する必要があります。これらの構成変更は、後でデプロイされる各OUDインスタンスに適用する必要があります。レプリケーション・ゲートウェイ・デプロイの理解を参照してください。
4.7 ユーザー・データおよびディレクトリ・メタデータの移行
OUD参照インスタンスを構成すると、実際の(O)DSEEユーザー・データおよびディレクトリ・メタデータとともにロードされます。
詳細については、次のセクションを参照してください。
4.7.1 (O)DSEEからOUDへのユーザー・データのエクスポート
まず、ディレクトリ・サーバーに存在するユーザー・データをOUDに再インポートできるように、LDIF形式にエクスポートする必要があります。エクスポートされるデータは、選択した移行ストラテジによって異なります。
LDIFファイルへのエクスポートについては、ds2oudを使用した(O)DSEEディレクトリ・サーバー、構成、スキーマおよびデータの理解に移動してください。
たとえば、直接移行ストラテジまたはDIPを使用した移行ストラテジを使用している場合、ディスク上の大量のデータを占めるレプリケーション・メタデータはエクスポート時に除外する必要があります。ただし、レプリケーション・ゲートウェイを使用した移行ストラテジの場合、レプリケーション・メタデータが必要です。
直接移行ストラテジまたはDIPを使用した移行ストラテジを使用している場合は、次の例に示すように、dsconfエクスポート・コマンドを実行してユーザー・データをLDIFにエクスポートします。
$ dsconf export --no-repl --decrypt-attr \ -h host1.example.com -p 1389 \ dc=example,dc=com odsee-data.ldif
レプリケーション・ゲートウェイ・ストラテジを使用した移行を使用している場合は、レプリケーション・メタデータを保持し、OUD形式に調整する必要があります。このストラテジを使用してユーザー・データをLDIFにエクスポートするには、次の例に示すように、dsconf exportコマンドを実行します。
$ dsconf export -f opends-export --decrypt-attr -h host1.example.com -p 1389 \ dc=example,dc=com odsee-data.ldif
ノート:
前述のコマンドの-f opends-exportオプションは、ODSEE 11g リリース1 (11.1.1.5以上)にのみ適用可能です。これは、レプリケーション・ゲートウェイを使用している場合に必要なODSEE 11gマスターからデータをエクスポートする必要があるためです。ディスク上の暗号化されたデータは、エクスポート中に復号化する必要があることにも注意してください。
DSEE 6.3用のLDIFファイルを生成するには(DSEE 6.3では-fオプションは提供されません):
-
dsconfコマンド(-fは含めない)を使用してDSEE 6.3からLDIFにエクスポートします -
ds2oud --adaptDseeData<path to LDIF file>を実行します(これにより、新規のLDIFファイル<path to LDIF file>_result.ldifが生成されます) -
次のコマンドを使用して生成されたファイルをOUDにインポートします:
import-ldif -b <your user data suffix> -n <db name e.g userRoot> --excludeAttribute "nsds5replconflict" -l <path to LDIF file_result.ldif>
4.7.2 OUDへのデータのインポート
import-ldifコマンドを使用して、LDIFファイルから読み込まれたデータをOracle Unified Directoryサーバー・バックエンドに移入できます。
次に、import-ldifの例を示します。
import-ldif -b <your user data suffix> -n userRoot --excludeAttribute "nsds5replconflict" -l <path to LDIF file>
移行時にopends-exportオプションを使用すると、(O)DSEE固有の属性が一部のエントリに存在する場合があり、これらのエントリがインポートされないようにできます。たとえば、nds5replconflictが(O)DSEEのデータに存在する場合があるため、OUDへのインポート時に、次のインポート・オプションを使用してこの属性をフィルタする必要があります。
--excludeAttribute "nsds5replconflict"
4.7.3 ディレクトリ・メタデータの移行ストラテジ
ディレクトリ・メタデータの移行は、使用する移行ストラテジによって異なります。これには、アクセス制御情報(ACI)、集合属性、LDAPサブエントリなどがあります。
ディレクトリ・メタデータ移行の様々なストラテジ:
-
直接移行ストラテジの場合、ディレクトリ・メタデータのみを1回調整する必要があります。
-
レプリケーション・ゲートウェイ・ストラテジの場合: ディレクトリ・サーバーとOUDの間でディレクトリ・メタデータがレプリケートされます。ディレクトリ・メタデータは両方で互換性を維持する必要があります。ただし、一部のメタデータは2つの環境間で異なるため、エラーまたはデータの損失を回避するために追加のスキーマ拡張が必要になります。
-
DIPストラテジの場合: ユーザー・データを同期するようにDIPを構成する必要があります。通常、ディレクトリ・メタデータは手動でOUDに追加されます。メタデータを同期するようにDIPを構成することもできます。
データへのアクセスは、エントリのアクセス権を指定するアクセス制御命令(ACI)で管理されます。ACIは、ユーザー・データの一部として、またはOUD構成に格納できます。
-
グローバルACIとデータ内のACI
グローバルACIは、ディレクトリ内のすべてのエントリに適用されます。これらは構成に格納されます。(O)DSEEとOUDのグローバルACIは、レプリケートされないためにエラーが発生しない場合、異なる可能性があります。
ds2oudツールは、グローバルACIをOUDグローバルACIに自動的に移行します。データの一部として格納されるACIはレプリケートされます。
-
構文の違い
現在、
rolednキーワードはOUD 12cではサポートされていません。ACI構文チェックが失敗するため、rolednキーワードを含むACIをOUDにインポートすることはできません。ロールをグループに置換し、rolednキーワードをgroupdnに置換できます(「ロールとACI」を参照)。targetscopeキーワードの新しい値subordinateは、OUDで導入されます。この値は(O)DSEEではサポートされないため、(O)DSEEとOUDの間の双方向レプリケーション・トポロジでは使用しないでください。 -
動作の違い
同じACIの評価が(O)DSEEとOUDで異なる場合があります。デフォルトではOUDは(O)DSEEより少ないアクセス権を付与するため、OUDが(O)DSEEのように動作するように、移行中に追加の書込みアクセス権を付与する必要があります。このような場合、OUD ACIの評価は(O)DSEE側よりも柔軟性が低くなります。
デフォルトでは、OUD ACIはユーザーが別のユーザーのパスワードをリセットするのを許可しません。OUDでは、(O)DSEEと同等の動作を実行するための権限を追加する必要があります。権限サブシステムを無効にすることもできます。たとえば、次のコマンドでは、管理者は(O)DSEEのユーザー・パスワードをリセットできます(このタイプのパスワード・リセットは、OUDではデフォルトで拒否されます)。
ldapmodify -p <dsee port> -D "cn=directory manager"-w <admin password dn: dc=example,dc=com changetype: modify replace: aci aci: (targetattr = "*") (version 3.0;acl "Custom LDAP Administrator";allow (all)(userdn = "ldap:///uid=admin,dc=example,dc=com");)
OUDでは、同等の動作を実行する次の権限を追加する必要があります。
dn: uid=admin,dc=example,dc=com changetype: modify add: ds-privilege-name ds-privilege-name: password-reset
次のコマンドを使用して、権限サブシステムを無効にすることもできます。
dsconfig set-global-configuration-prop -add disabled-privilege:password-reset
4.7.4 レプリケーション・トポロジ内のACI
(O)DSEEとOUDをレプリケーション・トポロジで共存させる必要がない場合、前に説明したように、ACIをOUDにインポートする前に必要に応じてACIを手動で調整できます。
一方向のレプリケーションを使用する場合、(O)DSEE上のデータに存在するACIを移行の前に手動で調整する必要があります。ACI構文チェックにより、レプリケーション初期化中に無効なACIはインポートされません。(O)DSEE側のACIの更新は、引き続きOUDにレプリケートされる可能性がありますが、OUD側には適用されません。
互換性のないACIを使用している場合、レプリケーション中にACIを除外するようにレプリケーション・ゲートウェイを構成することもできます。各(O)DSEE ACIが除外され、管理者はデータの一部として、または構成内に、OUDの対応するACIを作成する必要があります。
(O)DSEEとOUDの間の双方向のレプリケーションの場合、一方向のレプリケーションと同じ推奨事項が適用されます。また、OUD固有のACI拡張を混合環境で使用しないでください。
ノート:
(O)DSEEとOUD ACIは互換性がありますが、roleDNとして(O)DSEE固有のキーワードが使用される場合を除きます。
4.7.5 サービス・クラス(CoS)の理解
サービス・クラス定義は、ユーザー・データとともにLDAPサブエントリとして格納されます。現在、サービス・クラス機能はOUDではサポートされていません。(O)DSEEとOUDの間にレプリケーションが構成されている場合、CoS定義はレプリケーション・ゲートウェイによって自動的に除外されます。
CoSは、標準の集合属性メカニズムまたは仮想属性に置換できます。レプリケートされるトポロジでは、計算された属性は(O)DSEE側のCoSによって生成されますが、同等の計算はOUD側の集合属性または仮想属性を使用して実行されます。
4.7.5.1 集合属性と仮想属性
集合属性定義はユーザー・データとともにLDAPサブエントリとして格納されます。つまり、レプリケートされます。集合属性は、汎用的なサブエントリ・サブツリー仕様を通じてファイングレイン・スコーピング制御を提供します。仮想属性はOUD構成に格納され、レプリケーションには依存しません。(O)DSEEとOUDの間で双方向レプリケーションが有効になっている場合、集合属性ではなく仮想属性を使用する必要があります。これは、集合属性は(O)DSEEに再びレプリケートされるためです。
明確に集合属性を使用する必要がある場合(クラシックCoSおよび間接CoSを参照)、集合属性に関連するスキーマ・オブジェクトを使用して(O)DSEEスキーマを拡張する必要があります。この場合、LDAPサブエントリは(O)DSEEに存在しますが、非アクティブになります。つまり、属性計算は行われません。(OUDスキーマ・ファイル00-core.ldifに存在する)collectiveAttributeSubentryおよびsubentryオブジェクト・クラスに関連付けられたスキーマ定義、および関連付けられた属性を(O)DSEEスキーマに追加できます。
ノート:
(O)DSEEでは、CoSは通常、ロールおよびパスワード・ポリシーとともに使用されます。たとえば、カスタム・パスワード・ポリシーをユーザーのセットに割り当てるためにCoSを使用できます。OUDは、パスワード・ポリシーをユーザー・アカウントに割り当てるための新しい方法を提供します。したがって、通常、CoSには単純な代替方法があります。
(O)DSEEサービス・クラス・タイプは、次の項で詳しく説明しています。
4.7.5.2 ポインタCoS
(O)DSEEポインタCoSを使用して、エントリのセットで共通の属性を共有できます。
次の(O)DSEEポインタCoSは、固定値(+61245607890)を持つfacsimiletelephonenumberを、ou=People,dc=example,dc=comの下にあるすべてのエントリに自動的に割り当てます。
dn: cn=ZipTemplate,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: extensibleobject objectclass: cosTemplate facsimiletelephonenumber: +61245607890 cosPriority: 0 dn: cn=pointerCoS,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosPointerDefinition cosTemplateDn: cn=ZipTemplate,ou=People,dc=example,dc=com cosAttribute: facsimiletelephonenumber
次のOUD仮想属性を使用して、同等の属性値を計算できます。この例では、objectclass=personフィルタに一致するユーザー・エントリに、仮想のFAX番号+61245607890を追加する仮想属性ルールを作成して有効にします(ユーザー・エントリにすでにFAX番号がある場合を除く)。
dsconfig -h localhost -p 4444 -D "cn=directory manager" -j <password_file> -n \ create-virtual-attribute \ --type user-defined -name "Sydney Fax Number" \ --set attribute-type:facsimiletelephonenumber -set enabled:true \ --set value:+61245607890 -set filter:"(objectClass=person)"
仮想属性と異なり、集合属性はユーザー・データとともに格納されるため、OUDインスタンス間でレプリケートされます。
次の集合属性は、サブツリーou=people,dc=example,dc=comにエントリのfacsimiletelephonenumberを生成します。
dn: cn=People Preferred Language,dc=example,dc=com
changetype: add
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People fac simile number
facsimiletelephonenumber;collective: +61245607890
subtreeSpecification: {base "ou=people", minimum 1}
collectiveConflictBehavior: virtual-overrides-real
4.7.5.3 間接CoS
(O)DSEE間接CoSでは、各ターゲットに固有のテンプレートを見つけるために、cosIndirectSpecifier属性内の属性に名前が付けられます。間接CoSのテンプレート・エントリは、他のユーザー・エントリを含むディレクトリ内の任意のエントリにできます。次の間接CoSの例では、ターゲット・エントリのmanager属性を使用して、CoSテンプレート・エントリを識別します。テンプレート・エントリはマネージャのユーザー・エントリです。マネージャのユーザー・エントリには、生成する属性の値が含まれます。この場合、値はdepartmentNumber属性の値になります。
dn: cn=generateDeptNum,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosIndirectDefinition cosIndirectSpecifier: manager cosAttribute: departmentNumber dn: cn=Carla Fuentes,ou=People,dc=example,dc=com objectclass: cosTemplate objectclass: person departmentNumber: 318842 cn: Carla Fuentes
継承集合属性を使用して、間接CoSを置換できます。通常の集合属性と同様に、継承集合属性は、ディレクトリ・ツリー内のLDAPサブエントリを使用して定義されます(適用可能な場合)。継承集合属性は、OUDインスタンス間でレプリケートされます。(O)DSEEとOUDの間で双方向のレプリケーションが使用される場合、集合属性と仮想属性で説明したように、集合属性スキーマ要素を使用して(O)DSEEスキーマを拡張する必要があります。次の継承集合属性は、前述の間接CoSの定義と同等です。
dn: cn=indirectCOS,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: inheritedCollectiveAttributeSubentry
objectClass: inheritedFromDNCollectiveAttributeSubentry
cn: indirectCOS
subtreeSpecification: {base "ou=people"}
inheritFromDNAttribute: manager
inheritAttribute: departmentNumber
4.7.5.4 クラシックCoS
この例では、クラシックCoS定義による住所値の生成方法を示します。生成される値は、CoS定義のcosTemplateDNおよびターゲット・エントリのcosSpecifier属性の値の組合せで検索されるテンプレート・エントリに指定されます。次の例では、cosClassicDefinitionオブジェクト・クラスを使用して定義エントリを作成します。
dn: cn=classicCoS,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDn: ou=templates,ou=People,dc=example,dc=com cosSpecifier: building cosAttribute: postalAddress dn: cn=B07,ou=templates, ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: extensibleobject objectclass: cosTemplate postalAddres: 7 Old Oak Street, Anytown, CA 95054
このCoS定義では、building属性を含むターゲット・エントリ(ou=People,dc=example,dc=comの下のエントリ)には、自動的に対応する住所が含まれます。CoSメカニズムは、RDNに指示子属性値を持つテンプレート・エントリを検索します。この例では、Babs JensenがビルB07に割り当てられると、Jensenの住所が生成されます。
OUDでは、次のように、継承集合属性を使用して同等の動作を実行できます。
dn: cn=classicCOS,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: inheritedCollectiveAttributeSubentry
objectClass: inheritedFromRDNCollectiveAttributeSubentry
cn: classicCOS
subtreeSpecification: {base "ou=people"}
inheritFromBaseRDN: ou=templates
inheritFromRDNAttribute: building
inheritFromRDNType: cn
inheritAttribute: postalAddress
この継承集合属性サブエントリは、ou=people,dc=example,dc=comの下のユーザー・エントリに適用されます。サブエントリは、DNがou=templatesから構築されたユーザー・エントリから継承されたpostalAddress属性、継承集合属性サブエントリ・ルートDN dc=example,dc=com、および適用可能なエントリ構築属性(ある場合)から取得されたRDN cn値を追加します。
通常の集合属性と同様に、継承集合属性は、ディレクトリ・ツリー内のLDAPサブエントリを使用して定義されます(適用可能な場合)。これらはOUDインスタンス間でレプリケートされます。(O)DSEEとOUDの間で双方向のレプリケーションが使用される場合、集合属性と仮想属性で説明したように、集合属性スキーマ要素を使用して(O)DSEEスキーマを拡張する必要があります。
4.7.6 OUDへのロールの移行の概要
現在、Oracle Unified Directory 12cは非標準の(O)DSEEロールをサポートしていません。通常は、標準のOUDグループに置換されます。レプリケーション・ゲートウェイは、ロール定義を除外します。(O)DSEEロールをOUDに移行するために必要なステップは、ロールを外部クライアント・アプリケーションに公開する方法によって異なります。
多くのデプロイメントでは、ロールはクライアント・アプリケーションに公開されません。つまり、アプリケーションはnsRoleおよびnsRoleDN属性を使用しません。このようなロールは、ACIおよびパスワード・ポリシーの静的または動的グループに置換できます。
この項には次のトピックが含まれます:
4.7.6.1 ロールとACI
roledn ACIキーワードを使用して、ユーザー・ロールに基づいてデータにアクセス権を付与/拒否できます。たとえば、次の(O)DSEE ACIはパスワード・マネージャ・ロールを持つユーザーにユーザー・パスワード属性へのアクセス権を付与します。
dn: ou=data,o=example.com aci: (targetattr="userPassword")(version 3.0; acl "PasswordManager";allow (read,search,compare,write) roledn = "ldap:///cn=Password_Manager_Role,ou=roles,dc=example,dc=com";
rolednキーワードはOUD 12cではサポートされていません。これは次のような意味合いを持ちます:
-
rolednキーワードを含むACIをOUD 12cにインポートすることはできません。 -
(O)DSEEデータに存在するACIはOUDに適用されません。これらのACIはOUDにレプリケートされますが、ACI構文はOUDに対して無効なため、変更は適用されません。
ACIで使用されるロールは、移行の前にgroupdnキーワードを使用してグループに置換する必要があります。OUDの場合、前述のACIを次のように書き換えられます。
dn: ou=data,o=example.com aci: (targetattr="userPassword")(version 3.0; acl "PasswordManager";allow (read,search,compare,write) groupdn = "ldap:///cn=Password_Manager_Group,ou=group,dc=example,dc=com";
ACIが指すグループは、静的グループまたは動的グループのいずれかになります。
OUDに移行する前にロールベースのACIをグループベースのACIに移行するには、次の処理を実行する必要があります。
-
(同じDNを使用して)ロールに対応するグループを定義します。
-
OUDに移行する前に(O)DSEE側のACIを書き換えます。
ノート:
(O)DSEE構成に存在するロールベースのACIはレプリケートされないため、書き換える必要はありません。
4.7.6.2 ロールとパスワード・ポリシー
多くのデプロイメントでは、ロールを使用して、ロール・メンバーシップに基づいてカスタム・パスワード・ポリシーを割り当てます。たとえば、管理者ロールを持つユーザーは管理者パスワード・ポリシーの影響を受けます。このユース・ケースでは、ロールとCoSを使用して、必要なパスワード・ポリシーを指すすべてのユーザー・エントリに仮想属性pwdPolicySubEntryを作成します。
OUDでは、仮想属性を使用することで、パスワード・ポリシーをグループのメンバーと直接関連付けることができます。次の例では、adminPasswordPolicyパスワード・ポリシーをadministratorグループのメンバーに関連付けます。
dsconfig create-virtual-attribute -name "PWPolicy for Admins" --type user-defined --set attribute-type:ds-pwp-password-policy-dn --set group-dn:cn=administrators,ou=groups,dc=example,dc=com --set conflict-behavior:real-overrides-virtual --set value:"cn=adminPasswordPolicy,ou=policies,ddc=example,dc=com"
ノート:
CoSと異なり、パスワード・ポリシーをロールに関連付ける前述の仮想属性は、OUDインスタンスにはレプリケートされません。
4.7.6.3 クライアント・アプリケーションへのロールの公開
直接移行ストラテジまたはDIPストラテジを使用した移行を使用している場合(次の例はレプリケーション・ゲートウェイ・ストラテジを使用した移行とは互換性がありません)、ターゲット・ユーザーのエントリでnsRole属性を使用して、ユーザーがアプリケーション内の特定のロールのメンバーであるかどうかを判断する必要がある場合に適切なロールのDNが存在するかどうかを判断します。この場合、次のステップに従って、ロール機能をシミュレートできます。
ユーザーのエントリのnsRoleDN仮想属性に、対応するロールの名前を配置することによってアプリケーションがメンバーシップを変更する場合、各ロールの動的グループを作成(ロールDNを再利用する必要があります)し、グループ・メンバーシップのnsRoleDNが考慮されるようにグループのmemberURLフィルタを拡張します。次の例では、値が"cn=Test Role,ou=Roles,dc=example,dc=com"のnsRoleDNを含むユーザー・エントリのnsRole操作属性にもそのDNがあります。
dn: cn=Test Role,ou=Roles,dc=example,dc=com objectClass: top objectClass: groupOfURLs cn: Test Role memberURL: ldap:///dc=example,dc=com??sub?(nsRoleDN=\ cn=Test Role,ou=Roles,dc=example,dc=com)
使用しているアプリケーションでロール・エントリを作成、変更または削除することが必要な場合(たとえば、nsRoleDefinitionオブジェクト・クラスのいずれかの下位クラスが含まれるエントリ)、この機能は現在OUDでは使用できません。
4.7.7 OUDへのパスワード・ポリシー移行の理解
パスワード・ポリシーの扱いはDSEEとOUDで異なるため、OUDへのポリシー移行の管理には様々な方法があります。
この項の内容は次のとおりです。
4.7.7.1 パスワード・ポリシー移行のガイドライン
OUDに付属するds2oudツールは、デフォルトのパスワード・ポリシーの標準属性のみを移行します。(O)DSEEからOUDへのパスワード・ポリシー・マッピングは、表4-1を参照してください。
カスタム・パスワード・ポリシーはデータまたはOUD構成に格納できます。また、ユーザー・エントリ内の属性により、またはDIT内のサブエントリの位置に基づいて、ターゲット・ユーザーに割り当てることができます。パスワード・ポリシーの移行が成功するためには、最適なオプションを選択することが重要です。使いやすさとOUD管理に対する影響を考慮する必要があります(たとえば、サブエントリとしてのパスワード・ポリシーはOUDインスタンス全体にレプリケートされますが、構成内のパスワード・ポリシーはレプリケートされません)。また、すべての組合せがOUD 12cで使用可能なわけではありません。
デプロイメントの制約に基づいて次のオプションを選択する必要があります。
-
カスタム・パスワード・ポリシーをサブエントリとして、またはOUD構成内に格納します
-
パスワード・ポリシーを割り当てるには、ユーザー・エントリ内の属性を使用するか、またはサブ・エントリのサブツリー仕様を使用します
-
ユーザー・エントリ内の属性を使用してパスワード・ポリシーを割り当てる場合は、明示的な設定、仮想属性または集合属性を使用して属性を移入します
-
レプリケーション中に(O)DSEEパスワード・ポリシーを再利用または除外します
考慮する必要がある主な決定基準は次のとおりです。
-
(O)DSEEカスタム・パスワード・ポリシーが特定の拡張機能に依存しているかどうか
-
レプリケーションが(O)DSEE一方向とのみ使用されるかどうか
-
(O)DSEEカスタム・パスワード・ポリシーのサブエントリ位置がOUDと互換性があるかどうか
-
パスワード・ポリシー割当てがグループ・メンバーシップに基づいているかどうか
OUDと(O)DSEEのパスワード・ポリシーの違いをまとめたものを次に示します。
-
(O)DSEEパスワード・ポリシー定義は(
pwdPolicyオブジェクト・クラスで定義される)標準属性と(sunPwdPolicyオブジェクト・クラスで定義される)特定の拡張機能で構成されます。 -
OUDパスワード・ポリシーも(
pwdPolicyオブジェクト・クラスで定義される)標準属性に依存します。ただし、(O)DSEE固有の拡張機能は現在OUD 12cでサポートされていません。このような拡張機能はレプリケーション時に自動的にフィルタで除外され、ds-cfg-password-policyオブジェクト・クラスで定義されているOUD固有の拡張機能で置換する必要があります。
これらの拡張機能を移行するために必要な手動の調整を次の表に示します。
表4-1 (O)DSEEおよびOUDのパスワード拡張機能
| (O)DSEEの拡張機能 | OUDの拡張機能 |
|---|---|
|
PasswordStorageScheme |
default-password-storage-scheme |
|
PwdKeepLastAuthTime |
last-login-time-attribute、last-login-time-format |
|
PasswordRootDnMayByPassModsChecks |
skip-validation-for-administrators |
|
pwdIsLockoutPrioritized |
N/A |
|
PwdCheckQuality |
password-validator |
グローバル・パスワード・ポリシー以外に、カスタム・パスワード・ポリシーを作成できます。(O)DSEEでは、カスタム・パスワード・ポリシーはデータの一部またはLDAPサブエントリの一部として格納されます。
OUDでは、カスタム・パスワード・ポリシーはデータの一部またはLDAPサブエントリの一部として格納されるか、OUD構成に直接格納されます。
OUDでは、LDAPサブエントリとして定義されたパスワード・ポリシーは標準属性にのみ依存する必要があり(前項を参照)、拡張機能を含めることはできません。この制限は、OUD構成に格納されたパスワード・ポリシーには適用されません。
4.7.7.2 パスワード・ポリシーの割当て
(O)DSEEでは、パスワード・ポリシーはpwdPolicySubEntry属性の値に基づいてユーザー・アカウントに割り当てられます。属性値は、ユーザー・エントリに物理的に格納することも、エントリで照合された基準に基づいてCoSで動的に作成することもできます。パスワード・ポリシーのLDAPサブエントリの場所は、ポリシーをターゲット・ユーザーに割り当てる目的では使用されません。pwdPolicySubEntry属性がユーザー・エントリに存在しない場合は、デフォルトのパスワード・ポリシーが適用されます。
OUDでは、2つの方法でパスワード・ポリシーをユーザー・アカウントに割り当てることができます。
-
(O)DSEEと同じように、明示的に、または仮想属性または集合属性を介して属性
ds-pwp-password-policy-dnを設定。 -
パスワード・ポリシー・エントリとターゲット・ユーザー・エントリの下のすべてのユーザー・エントリが、サブエントリに存在するLDAPフィルタ/サブツリー仕様と一致するように、DITにパスワード・ポリシー・サブエントリを作成。サブエントリ・サブツリー仕様はRFC 3672で定義されます。
次の例は、最初のケースに対応しています。パスワード・ポリシーServiceAccountは、グループ・メンバーシップに基づいて属性ds-pwp-password-policy-dnを移入する仮想属性を作成することで、グループgroup_FirstLoginPolicyのメンバーに割り当てられます。
dn: cn=group_FirstLoginPolicy,dc=example,dc=com objectClass: groupOfURLs MemberURL: ldap://ou=people,dc=example,dc=com??sub? (pwdReset=TRUE) cn:group_FirstLoginPolicy dsconfig create-virtual-attribute --name "PWPolicy to Admins" \ --type user-defined --set attribute-type:ds-pwp-password-policy-dn \ --set group-dn:cn=group_FirstLoginPolicy,dc=example,dc=com \ --set conflict-behavior:real-overrides-virtual \ --set value:"cn=ServiceAccount,ou=passwordPolicies,ou=config,dc=example,dc=com"
次の例は、2番目のケースに対応しています。ポリシーFirstLoginPolicyは、サブツリーou=people,dc=example,dc=com内のグループnewbeesのメンバーであるユーザーに適用されます。
dn: cn=FirstLoginPolicy,dc=example,dc=com
objectClass: subentry
Objectclass: pwdpolicy
SubtreeSpecification: { specificationFilter "ismemberOf=cn=group_FirstLoginPolicy,dc=example,dc=com"}
PwdMaxFailure: 2
PwdAttribute: userPassword
cn:FirstLoginPolicyノート:
OUDで実装されるサブツリー仕様は、標準のスーパーセットです。OUDでは、整形式のLDAPフィルタをspecificationFilter属性の有効な値とみなします。これは、前述の例に示すように、グループ・メンバーシップに基づいてパスワード・ポリシーを割り当てる際に非常に便利です。
4.7.7.3 パスワード・ポリシーの継承
カスタム・パスワード・ポリシーの評価は、(O)DSEEとOUDで異なります。(O)DSEEでは、カスタム・パスワード・ポリシーがデフォルトのパスワード・ポリシー設定を上書きします。OUDでは、カスタム・パスワード・ポリシーはデフォルトのパスワード・ポリシーから継承されます。カスタム・ポリシー・レベルで定義されていないプロパティは、(属性名が対応していない場合でも)機能レベルのデフォルト・パスワード・ポリシーから取得されます。移行中は、これらの違いを考慮する必要があります。
4.7.7.4 パスワード・ポリシーとレプリケーション・ゲートウェイ
OUDと(O)DSEEがレプリケートされるトポロジに共存している場合、レプリケーション・プロトコルを介してレプリケートされない場合でも、2つの環境の間でパスワード・ポリシーの一貫性をできるかぎり維持する必要があります。たとえば、パスワード・バリデータが異なる場合、パスワードは一方で有効になり、他方で無効とみなされる可能性があるため、矛盾が生じる可能性があります。
特定のエントリのセットのアカウント・ロックアウトが(O)DSEEで有効になっており、OUDで無効になっている(またはその逆)場合、パスワード・リセットは他方のアカウントをロック解除しません。
4.7.7.5 レプリケーション・ゲートウェイと(O)DSEEパスワード・ポリシーのアップグレード
トポロジ全体でグローバル・パスワード・ポリシーとアカウント・ロックアウトが設定された、レプリケートされるトポロジでは、レプリケーション・ゲートウェイと直接通信する(O)DSEEサーバーは、DS6modeのパスワード・ポリシーを使用して実行する必要があり、ユーザー・エントリに前のパスワード・ポリシー・モードに関連するデータを含めることはできません。これは、グローバル・パスワード・ポリシーが不要で、OUDと(O)DSEEが独自のパスワード・ポリシー管理を行っている場合は必須ではありません。他の(O)DSEEサーバーは非互換性モードで実行できますが、そのようなデプロイメントは優先されません。
パスワード・ポリシー・モードの変更の詳細は、『Oracle Unified Directoryの管理』のパスワード・ポリシーの管理を参照してください。
dsconf get-server-prop pwd-compat-modeコマンドを使用して、現在のパスワード・ポリシー・モードを取得できます。デフォルトでは、ODSEE 11g リリース2はDS5-compatibleモードを使用します。(O)DSEEからデータをエクスポートする前にDS6-modeに切り替える必要があります。DS6-modeに切り替えるには、まず中間のDS6-migrationモードに切り替える必要があります。
DS6-modeに切り替えてユーザー・エントリを再生成するプロセスの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のパスワード・ポリシーの互換性に関する項を参照してください。
4.7.7.6 アカウント・ロックアウト・ポリシーの構成
(O)DSEEとOUDの両方で、指定した回数のバインド試行が失敗した後に、アカウントを強制的にロックアウトするパスワード・ポリシーを設定できます。アカウントを手動でロックすることもできます。ロックされたアカウントは、アカウントがアクティブ化されるまで、ロックされたままとなります。
(O)DSEEとOUDの間でアカウント状態(ロック済/ロック解除済)を移行するには、特定の設定が必要です。(O)DSEEでは、手動のアカウント・ロックはロールに依存します。ロックされたエントリにはnsRoleDN=cn=nsManagedDisabledRole,dc=com roleが割り当てられます。OUDでは、手動のアカウント・ロックはブール属性ds-pwp-account-disabledに依存します。手動でロックされたアカウントを(O)DSEEからOUDに自動的にインポートするには、次のステップを使用します。
4.7.7.7 カスタム・リソース制限
(O)DSEEでは、次の制限をパスワード・ポリシーと関連付けることができます。
-
検索制限は、検索操作で調べるエントリの最大数を指定する。
-
サイズ制限は、検索操作に応答して返されるエントリの最大数を指定する。
-
時間制限は、検索操作に費やせる最大時間を指定する。
-
アイドル・タイムアウトは、接続が切断されるまでに、クライアント接続がアイドル状態でいられる最大時間を指定する。
アカウント制限の設定の詳細は、Oracle Fusion Middleware Oracle Directory Server Enterprise Edition管理ガイドの各クライアント・アカウントのリソース制限の設定を参照してください。ドキュメントは、http://docs.oracle.com/cd/E19656-01/のOracle Directory Server Enterprise Edition 11g リリース1の索引ページにあります。.
それ以外に、特定のアカウント/ユーザー・エントリに対してこれらの制限を設定することもできます。一部の(O)DSEEエントリには、nsSizeLimit, nsTimeLimit, nsLookThroughLimit, nsIdleTimeoutというリソース制限属性が含まれている可能性があります。
OUDに対応する属性は、ds-rlim-size-limit, ds-rlim-time-limit, ds-rlim-lookthrough-limit,ds-rlim-idle-time-limitです。
アカウントベースのリソース制限はds2oudでは考慮されないため、手動で移行する必要があります。
レプリケーション・ゲートウェイを使用する場合、リソース制限に関連する各(O)DSEE属性名が、対応する各OUD属性の別名として制限されるように、OUDスキーマ(02-config.ldif)を変更する必要があります。
(O)DSEEでは、-1を使用してリソース制限を無効にします。OUDでは0を使用します。この違いに対処するには、OUDで仮想属性を作成して、(O)DSEE属性の値が-1に等しくなったときにOUD属性の内容を上書きするという方法があります。4つの属性に対して仮想属性を作成する必要があります。次に説明を示します。
attributeTypes: ( 1.3.6.1.4.1.26027.1.1.166 NAME ( 'ds-pwp-account-disabled' 'nsAccountLock' ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation X-ORIGIN 'OpenDS Directory Server' )
dsconfig create-virtual-attribute --name "mapping nsTimeLimit " \ --type user-defined --set attribute-type:ds-rlim-time-limit \ --set filter:"(nsTimeLimit=-1)" \ --set conflict-behavior:virtual-overrides-real \ --set value:"0" \ --set enabled:true
dsconfig create-virtual-attribute --name "mapping nsLookthroughLimit " \ --type user-defined --set attribute-type:ds-rlim-lookthrough-limit \ --set filter:"(nsLookthroughLimit=-1)" \ --set conflict-behavior:virtual-overrides-real \ --set value:"0" \ --set enabled:true
dsconfig create-virtual-attribute --name "mapping nsIdleTimeout " \ --type user-defined --set attribute-type:ds-rlim-idle-time-limit \ --set filter:"(nsIdleTimeout=-1)" \ --set conflict-behavior:virtual-overrides-real \ --set value:"0" \ --set enabled:true
パフォーマンスのために、「プレゼンス」の前述の4つの属性に索引を作成することをお薦めします。
ノート:
前述の設定では、OUD側でも(O)DSEEリソース制限属性名を常に使用する必要があります。(O)DSEEとOUDが同じレプリケーション・トポロジに共存する場合、OUD属性名の使用は使用できません。
4.8 レプリケーション・ゲートウェイまたはDIPのデプロイ
選択したアプリケーションが、OUDサーバーに対して検証されます。
ユーザー・データおよびディレクトリ・メタデータの移行を実行した後、選択したアプリケーションをOUDサーバーに対して検証できます。参照先は次のとおりです。
表4-2 選択したアプリケーションの検証
| デプロイメント・ストラテジ | 参照先 |
|---|---|
|
レプリケーション・ゲートウェイを使用した共存 |
|
|
Oracle Directory Integration Platform (DIP)を使用した共存 |
|
|
直接移行ストラテジ |
4.8.1 レプリケーション・ゲートウェイ・デプロイの理解
レプリケーション・ゲートウェイをデプロイする方法を理解します。レプリケーション・ゲートウェイを使用して(O)DSEEとOUDの間でレプリケーションを構成するための追加コンポーネントを次に示します。
『Oracle Unified Directoryのインストール』のレプリケーション・ゲートウェイの設定の説明に従って、レプリケーション・ゲートウェイをインストールして構成します。
この時点で、レプリケーションのグローバル管理者を構成する必要があります。このサーバーを後で既存のレプリケート対象OUDトポロジに接続する予定の場合は、他のOUDサーバーで定義されている同じグローバル管理者の資格証明を使用します。
たとえば、既存のOUDトポロジがあると仮定した場合、移行前のサーバー・レイアウトは次のようになります。
移行後のサーバー・レイアウトは次のようになります。
4.8.2 DIPのデプロイ
DIPを使用して(O)DSEEとOUDの間をリンクするための追加コンポーネントを次に示します。古いディレクトリ・サーバーをプロビジョニング解除し、DIPが削除された後、DIP関連のメタデータがOUDに格納されなくなるように、次の手順では(O)DSEEサーバーをDIPバックエンド・ディレクトリとして構成します。
DIPをデプロイするには:
-
同期される(O)DSEEマスター・インスタンスおよびOUDディレクトリ・サーバー・インスタンスを選択します。レプリケーション・サーバーが外部の変更ログ・サービスを提供するため、OUDディレクトリ・サーバーには埋込みのレプリケーション・サーバーが必要です。
-
パスワード記憶スキームを同期します。
パスワード記憶スキームは、(O)DSEEとOUDの間で同一であり、互換性がある必要があります。同期を有効にするようにパスワード記憶スキームを構成するには、『Oracle Unified Directoryの管理』のパスワード・ポリシーの管理に関する項を参照してください。
-
(O)DSEEにDIPメタデータを保持するディレクトリ・サフィックスを作成します。
DSEE 6.x (以上)で次のコマンドを使用して、DIPメタデータを保持するサフィックス
cn=products,cn=oraclecontextを作成します。dsconf create-suffix -i -c -p $PORT -D "$ADMIN" -w "$PW_FILE" cn=products,cn=oraclecontext
DSEE 5.2のディレクトリ・サフィックスを作成する手順は、Sun ONE Directory Server管理ガイドのサフィックスの作成に関する項を参照してください。
-
変更ログを有効化します。
変更を含むディレクトリで変更ログを有効にする必要があります。次のコマンドを使用して、(O)DSEEで変更ログを有効にします。
dsconf set-server-prop -p $PORT -w "$PW_FILE" retro-cl-enabled:on
双方向同期の場合、OUDで外部変更ログを有効にする必要があります。デフォルトでは、OUDインスタンスがレプリケーション・トポロジの一部である場合、外部変更ログは自動的に有効化されます。テスト用に、スタンドアロンOUDディレクトリ・サーバー・インスタンスを設定し、次のコマンドを使用して外部変更ログを有効にします。
dsreplication enable-changelog --no-prompt --baseDN "dc=example,dc=com" --hostname "$HOST" --port $APORT --bindDN "$ADMIN" --adminPasswordFile "$PW_FILE" --trustAll
-
DIPをインストールして構成します。
-
WeblogicコンテナにDIPをインストールします。
WebLogicコンテナへのDIPのインストールの詳細は、『Oracle Directory Integration Platformの管理』のOracle Unified Directoryを使用したOracle Directory Integration Platformに対するOracle WebLogic Serverドメインの構成に関する項を参照してください。
-
次のコマンドを使用してDIPを構成します。
$ORACLE_HOME/bin/dipConfigurator setup -wlshost <hostname> -wlsport <admin_server_domain_Port> -wlsuser weblogic -ldaphost <dsee_host> -ldapport <dsee_port> -ldapuser "dsee_administrator" -metadatasuffix cn=products,cn=oraclecontext -isldapssl false
たとえば、
<dsee_administrator>、cn=directoryマネージャには、DIPメタデータ・サフィックス(cn=products,cn=oraclecontext)への読取りおよび書込みアクセス権を付与する必要があります。デフォルトのパスワード・ポリシーでは、
allow-pre-encodedオプションは'true'である必要があります。これにより、<dsee_administrator>は事前にエンコードされたパスワードへの書込みアクセス権を持つことができます。LDAPユーザーの場合は、次のコマンドによりデフォルトのパスワード・ポリシーが変更されます。
dsconfig set-password-policy-prop --policy-name Default\ Password\ Policy --set allow-pre-encoded-passwords: true
SSLユーザーは、DIP管理者ガイドを参照して証明書を管理します。
-
-
同期プロファイルを作成します。
oud_ldap_administrator(cn=directory managerなど)が、同期されるサフィックスへの読取りおよび書込みアクセス権を持っていることを確認します。また、双方向同期を使用する場合、OUD外部変更ログでの読取りアクセス権が必要です。プロファイルを同期するには、コマンド行とDIPグラフィカル・ユーザー・インタフェース(EM)の2つの方法があります。コマンド行を使用してプロファイルを同期する例を次に示します。
$ORACLE_HOME/bin/expressSyncSetup -h <dip_hostname> -p <dip_domain_port> -D weblogic -conDirType IPLANET -conDirUrl <OUD_host>:<oud_port> -conDirBindDN <oud_ldap_administrator> -conDirContainer <target_suffix> -backendDirContainer cn=products,cn=oraclecontext -pf <profile_name>
前述のコマンドは、次の命名規則を使用して1つのインポート・ファイルおよび1つのエクスポート・ファイルを作成します。
-
プロファイル名(
-pf argument)がprofile1の場合、expresSyncSetupは2つのプロファイル(profile1Exportおよびprofile1Import)を作成します。
EMを使用して同期プロファイルを作成するには、『Oracle Directory Integration Platformの管理』の同期プロファイルの作成に関する項を参照してください。同期する属性のリストを更新するには、DIPグラフィカル・ユーザー・インタフェースを使用します。
1-1の正確な属性マッピング(
cn<->cnなど)と、属性の別名ごとに1つの余分なマッピング(commonName->commonNameなど)を作成することをお薦めします。 -
-
ACIを構成します。
DIPが正しく動作するためには、バックエンド・ディレクトリ・サーバーに追加のディレクトリACIを作成する必要があります。
次のコマンドは、同期されるサフィックスのバックエンド・ディレクトリに作成されるACIの例です(
dc=example,dc=com)。ldapmodify -h <dsee_host> -p <dsee_port> -D "cn=Directory Manager" -w <password> <<EOF dn: dc=example,dc=com changetype: modify add: aci aci: (target="ldap:///dc=example,dc=com")(version 3.0; acl "Entry-level DIP permissions"; allow (all,proxy) groupdn="ldap:///cn=dipadmingrp,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext"; allow (all,proxy) groupdn="ldap:///cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext"; ) - add: aci aci: (targetattr="*")(version 3.0; acl "Attribute-level DIP permissions"; allow (all,proxy) groupdn="ldap:///cn=dipadmingrp,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext"; allow (all,proxy) groupdn="ldap:///cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext";) EOF
エクスポート・プロファイルのエントリをエクスポート・グループに追加する必要があります。
ldapmodify -h <dsee_host> -p <dsee_port> -D "cn=Directory Manager" -w <password> <<EOF dn: cn=odipegroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext changetype: modify add: uniqueMember uniqueMember: orclodipagentname=profile1Export,cn=subscriber profile,cn=changelog subscriber,cn=directory integration platform,cn=products,cn=oraclecontext EOF
プロファイル名(例では
profile1Export)は、新しいメンバーのDNの一部であることに注意してください。双方向同期を使用する場合、インポート・プロファイルのエントリをインポート・グループに追加する必要があります。
ldapmodify -h <dsee_host> -p <dsee_port> -D "cn=Directory Manager" -w <password> <<EOF dn: cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=products,cn=oraclecontext changetype: modify add: uniqueMember uniqueMember: orclodipagentname=profile1Import,cn=subscriber profile,cn=changelog subscriber,cn=directory integration platform,cn=products,cn=oraclecontext EOF
前述の例では、プロファイル名(例では
profile1Export)は、新しいメンバーのDNの一部であることに注意してください。 -
ディレクトリ・ブートストラップを管理します。
ブートストラップは、(O)DSEEバックエンド・ディレクトリとOUDの間のデータの初期移行を指します。同期プロセスでは(O)DSEEとOUD間のデータの移行も処理されるため、ディレクトリのブートストラップを実行する必要はありません。ただし、初期のデータ移行を同期プロセスに依存すると、時間がかかる可能性があります。このため、初めてDIPをデプロイする場合には、ディレクトリのブートストラップを実行します。
2つのディレクトリ・トポロジを初期化するには2つの可能性が考えられます。
-
DIPがOUDへのすべての(O)DSEEエントリを作成するように同期を有効にします。
-
(O)DSEEディレクトリの内容をLDIFファイルにエクスポートした後、その内容をOUDにインポートし、(O)DSEE変更ログを使用するようにDIPを構成します。
最初の解決策は単純ですが、この手順を使用する直接移行ストラテジよりも遅くなります。
最初の解決策を使用するには、次のことを実行する必要があります。
-
同期プロファイルを有効化します
-
次のコマンドを実行します。
$ORACLE_HOME/bin/syncProfileBootstrap -h <dip_host> -p <dip_domain_port> -D weblogic -pf profile1Import $ORACLE_HOME/bin/syncProfileBootstrap -h <dip_host> -p <dip_domain_port> -D weblogic -pf profile1Export
ディレクトリ・ブートストラップについては、『Oracle Directory Integration Platformの管理』のOracle Directory Integration Platformにおけるディレクトリのブートストラップに関する項で説明されています。
LDIFブートストラップを使用するには:
-
次のコマンドを使用して、レプリケーション・メタデータなしで、バックエンド・サーバーをオフライン・モードに設定して、DSEEから
data.ldifファイルにエントリをエクスポートします。$ dsconf export --no-repl -h host -p port suffix-DN LDIF-file
-
エクスポートの開始前に適用された最終更新の変更番号を取得します。そのためには、エクスポート手順を開始した後、その時間を書き留めてYYYYMMDDHHMMSSZ形式の一般化された時間に変換します。一般化された時刻形式のタイムスタンプの例として、20130508200557Zは、(UTCタイムゾーンで)2013年5月28日午後8時5分57秒の時刻を指定します。
-
エクスポートが完了した後、(必要に応じて) (O)DSEEサーバーを再起動します。
-
次の検索コマンドを実行します。
ldapsearch -p <dsee_port> -D <dsee_admin> -w <password> -b "cn=changelog" "changetime>= <timeStamp>" changeNumber
-
次のコマンドを実行して返される最も小さい
changeNumberの値を書き留めます。ldapsearch -p PORT -h DSEE HOSTNAME -D "cn=directory manager" -w PASSWORD -b "cn=changelog" "changetime>=20130508200557Z" changeNumber dn: changenumber=16747773,cn=changelog changeNumber: 16747773 dn: changenumber=167477734,cn=changelog changeNumber: 167477734 dn: changenumber=1674777345,cn=changelog changeNumber: 1674777345
-
『Oracle Directory Integration Platformの管理』のFusion Middleware Controlを使用した同期プロファイルの管理に関する項に説明されているように、DIP管理コンソール(EM)を使用します。
同期を開始する
manageSyncProfilesupdatechgnumコマンドを使用して、DIP同期エクスポート・プロファイルの最終変更番号パラメータを前述の値で更新することもできます。manageSyncProfilesupdatechgnumコマンドは、『Oracle Directory Integration Platformの管理』のmanageSyncProfilesユーティリティに関する項で説明されています。 -
『Oracle Directory Integration Platformの管理』の同期プロファイルの有効化と無効化に関する項で説明されているGUIまたはCLIを使用して、DIP同期プロファイルを有効にします。
変更ログに基づいて同期が開始されます。
-
4.9 レプリケート対象トポロジのデプロイ
OUD参照インスタンスを初期化して移行作業の大部分が完了したら、レプリケートされた環境に追加のインスタンスを設定できます。
「ディレクトリ構成の移行」で示されたバッチ手順で、追加インスタンスが作成され初期化されます。その後、レプリケーションがOUDのインスタンス間で有効化されます。
「参照OUDインスタンスの作成」、「ds2oudを使用した(O)DSEEディレクトリ・サーバー、構成、スキーマおよびデータの理解」、「ディレクトリ・スキーマの移行」、「ディレクトリ構成の移行」で示されているように、(O)DSEEからのデータを使用して参照OUDサーバーを構成およびロードした後、レプリケートされる環境で追加インスタンスを設定できます。このステップは次のとおりです。
-
OUDレプリカの構成
-
トポロジのデプロイ
-
データの初期化
これらのステップはすべてのストラテジに必要です。
4.9.1 レプリカのタイプ
3つのタイプのレプリカ(マスター・レプリカ、コンシューマ・レプリカおよびハブ・レプリカ)について理解します。
(O)DSEEは、3つのタイプのレプリカを区別することに注意してください。
-
マスター・レプリカは、ディレクトリ・データのマスター・コピーが含まれている読取り-書込みデータベースです。
-
コンシューマ・レプリカは、マスター・レプリカに格納されている情報のコピーを含む読取り専用データベースです。
-
ハブ・レプリカは、コンシューマ・レプリカと同様に読取り専用のデータベースですが、1つ以上のコンシューマ・レプリカを提供するディレクトリ・サーバー上に格納されます。
(O)DSEEレプリカの詳細は、『Oracle Directory Server Enterprise Editionリファレンス』のレプリケーションの概要に関する項を参照してください。
OUDレプリケーション・モデルはマルチマスター・モデルです。言い換えると、レプリケートされるトポロジのすべてのディレクトリ・サーバー・レプリカが、読取り操作と書込み操作の両方を処理できます。
DSEE 6.xのリリース以降、オラクル社ではコンシューマ・レプリカおよびハブ・レプリカが不要になる一般的なデプロイメントのマルチマスター・レプリケーションを推奨してきました。
ほとんどのデプロイメントでは、パフォーマンス上の理由で読取り専用レプリカを使用する必要はありません。アプリケーションで必要な場合のみ使用します。この場合、バック・エンドの書込み可能性モードを構成することで実行します。ただし、OUDディレクトリ・サーバーを読取り専用になるように構成できます。その場合、LDAPクライアントからの追加、変更および削除操作はこのサーバーでは拒否され、レプリケートされるトポロジ内の他の(読取り-書込み)サーバーへのポインタを含むリフェラルが返されます。
4.9.2 OUD読取り-書込みレプリカについて
Oracle Unified Directoryにおけるレプリケーションの概念とデプロイメントは、(O)DSEEの場合と異なります。OUD読取り-書込みレプリカおよびカスケード型レプリケーションと集中化レプリケーションの違いについてさらに学習します。
(O)DSEEでは、レプリケーション・プロトコルの動作を改善するために、カスケード型レプリケーションとともにハブ・レプリカが導入されます。カスケード型レプリケーションは、次の場合に役立ちます。
-
コンシューマの数が多い場合
-
レプリケーション・トポロジ内のマスターは更新トラフィックをすべて処理するため、コンシューマへのレプリケーション・トラフィックをサポートすると、マスターに大きな負荷がかかる場合があります。レプリケーション・トラフィックの負荷を複数のハブに分散すると、それぞれのハブから、コンシューマのサブセットに対して、レプリケーションの更新を送信できます。
-
地理的に分散した環境で、ローカル・ハブを使用して接続コストを削減する場合
OUDでは、ハブ・レプリカは存在しません。レプリケーションは、パブリッシュ・サブスクライブ・アーキテクチャを中心に構築されています。各ディレクトリ・サーバーは、中央サービスと通信し、自身の変更のパブリッシュおよび他のディレクトリ・サーバーの変更通知の受信を行うために中央サービスを使用します。この中央サービスは、レプリケーション・サービスと呼ばれます。OUD読取り-書込みマスターはデフォルトであるため、ほとんどの場合デプロイされます。
レプリケーション・サービスは、複数のホストで動作する複数のサーバー・インスタンスを使用することで、高可用性を持たせることができます。レプリケーション・アーキテクチャ内でレプリケーション・サービスを提供するサーバー・インスタンスは、レプリケーション・サーバーと呼ばれます。ディレクトリ・サービスを提供するサーバー・インスタンスは、ディレクトリ・サーバーと呼ばれます。
小規模トポロジ(ディレクトリ・サーバーの数が最大4つ)では、各サーバーをディレクトリ・サーバー兼レプリケーション・サーバーとして構成することが合理的です。大規模トポロジ(ディレクトリ・サーバーの数が20を超えている)では、ディレクトリ・サーバー・インスタンスとレプリケーション・サーバー・インスタンスを別々のJVMに分けて、レプリケーション・サーバーの数を制限することをお薦めします。
この2つの極端なトポロジの中間の規模の場合は、要件にあわせて最適な構成を決定できます。すべてのサーバーをディレクトリ・サーバー兼レプリケーション・サーバーとして動作させるほうが、一般にはトポロジが単純になり、管理しやすくなります。ディレクトリ・サーバーとレプリケーション・サーバーを分ける場合、ディレクトリ・サーバー・インスタンスはレプリケーション変更ログを保存する必要がないので必要なディスク容量が少なくなります。
複数のディレクトリ・サーバーと複数のレプリケーション・サーバーからなる大規模なトポロジでは、あらかじめ定義された方法でディレクトリ・サーバーをレプリケーション・サーバーに分散させた方が効率的です。これは、レプリケーション・サーバーを異なるタイプの異なる能力を持つマシンで実行している場合に、特に重要です。予想されるマシンのパフォーマンスがレプリケーション・サーバー間で大幅に異なる場合は、その能力に従ってレプリケーション・サーバーに負荷を分散させることが有効です。
OUDのレプリケーションの概念を理解する必要があります。これは、(O)DSEEの場合とは異なるためです。レプリケーション・サーバーおよびロード・バランシングの構成の詳細は、『Oracle Unified Directoryの管理』のレプリケーション・サーバーのロード・バランシングに関する項を参照してください。
4.9.3 OUD読取り専用レプリカについて
Oracle Unified Directoryの読取り専用レプリカでは、LDAPクライアント・アプリケーションがサーバーに直接にレプリケーション操作を実行することはできません。Oracle Unified Directoryを読取り専用レプリカとして構成するには、dsconfigコマンドを使用します。
この例では、host1とhost2の2つのホストにレプリケーション・サーバーが存在するレプリケーション構成を想定しています。この例では、host2上のディレクトリ・サーバーを読取り専用レプリカにして、管理コネクタを使用してサーバー構成にアクセスするdsconfigコマンドを使用します。
OUDの読取り専用レプリカの構成の詳細は、『Oracle Unified Directoryの管理』のレプリケーション・サーバーのロード・バランシングの理解に関する項を参照してください。
dsconfigコマンドを使用してhost2の書込み可能性モードを設定し、OUDを読取り専用レプリカとして構成できます。
$ dsconfig -h host2 -p 4444 -D "cn=Directory Manager" -j <password_file> -X -n \
set-global-configuration-prop --set writability-mode:internal-onlyinternal-onlyという書込み可能性モードは、サーバーでレプリケーション操作は処理されるが、LDAPクライアント・アプリケーションによるサーバーへの直接の書込みはできないことを意味します。
4.9.4 レプリケート対象トポロジでのサーバーのデプロイ
レプリケート対象トポロジでのOracle Unified Directoryサーバーのデプロイメントは、OUDインスタンスの作成とインスタンス間のレプリケーションの構成から始まります。
新しいOUDインスタンスを作成するには:
- OUDインスタンスを作成します。ディレクトリ・サーバーの設定の手順は、『Oracle Unified Directoryのインストール』の「ディレクトリ・サーバーとしてのOracle Unified Directoryの設定」を参照してください。
- 「ディレクトリ構成の移行」で示された構成変更を適用して、各OUDインスタンスを構成します。データのインポート中に識別された追加の構成変更については、「ユーザー・データおよびディレクトリ・メタデータの移行」を参照してください。
dsreplicationコマンドを実行して、OUDインスタンス間のレプリケーションを有効にします。dsreplicationコマンドの詳細は、『Oracle Unified Directoryの管理』のdsreplicationによる2つのサーバー間のレプリケーションの有効化に関する項を参照してください。
レプリケート対象トポロジへのサーバーのデプロイの詳細は、『Oracle Unified Directoryの管理』のdsreplicationを使用したデータ・レプリケーションの構成を参照してください。
(O)DSEEデータとともにOUDサーバーがロードされた後、『Oracle Unified Directoryの管理』で説明されているように、他のすべてのOUDインスタンスに同じファイルをインポートするか、バイナリ・コピーを使用するか、別のレプリケート対象サーバーからのデータでレプリケート対象サーバーを初期化できます。
4.9.5 (O)DSEEデータによるOUDの初期化
レプリケーション・トポロジを設定した後、新しいデータで初期化する必要があります。すでに参照インスタンスに含まれている(O)DSEEデータでOUDインスタンスを初期化するには、ストラテジごとに4つのオプションがあります。
レプリケーション・ゲートウェイ・ストラテジを使用している場合は、(O)DSEEで(O)DSEEレプリケーション・パージ遅延が構成される前にエクスポートされた(O)DSEEデータとともにOUD参照インスタンスがロードされることを確認する必要があります。
4つのオプションは次のとおりです。
-
dsreplicationコマンドを実行して、空の各OUDインスタンスを初期化します。『Oracle Unified Directoryの管理』のdsreplicationによるレプリケート対象サーバーの初期化を参照してください。 -
各OUDインスタンスを同時に初期化します。『Oracle Unified Directoryの管理』のdsreplicationによるトポロジ全体の初期化を参照してください。
-
参照OUDから各OUDインスタンスに、データベース・ファイルのバイナリ・コピーを実行します。『Oracle Unified Directoryの管理』の既存のレプリケート対象トポロジへのディレクトリ・サーバーの追加を参照してください。
-
参照OUDからエントリをエクスポートし、空の各OUDインスタンスに再インポートします。
4.10 OUDトポロジへのトラフィックのリダイレクト
クライアント・アプリケーションが徐々にOUDに変換される間、(O)DSEEとOUDデプロイメントが共存し、本番環境で同期されます。2つの環境間の共存は、アプリケーション・テストが完了するまで維持されます。
この手順はアーキテクチャに依存します。リダイレクトには、ソフトウェアまたはハードウェアのロード・バランサ、LDAPプロキシ・サーバーの再構成、ドメイン・ネーム・システム(DNS)の変更、またはIP偽装の使用が含まれる可能性があります。
4.11 共存の中止
すべてのアプリケーションがOracle Unified Directoryにリダイレクトされて検証されると、レプリケーション・ゲートウェイおよびコンパニオン(O)DSEEサーバーのプロビジョニング解除が始まります。
レプリケーション・ゲートウェイを使用しなくなった場合、停止してアンインストールできます。同じことが(O)DSEE側にも当てはまります。
ノート:
共存の中止を実行すると、OUDへの移行は完了です。移行中に問題が発生した場合は、Oracleサポート担当者に問い合せてください。詳細は、https://support.oracle.comのMy Oracle Support Webサイトにアクセスしてください。