| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
この章は、ディレクトリのスキーマおよびデータの管理と更新を担当するディレクトリ・サーバーの管理者を対象としています。ここでは、Oracle Access Manager（以前のOblix NetPointまたはOracle COREid）のスキーマおよびデータのアップグレードに備えた環境の準備の詳細を示します。次の項では、環境を準備する際に役立つ情報について説明します。
|
注意: 特に明記されていない場合、この章に記載されている情報はどちらのアップグレード・メソッドにも同様に適用されます。アップグレード元のOracle Access Managerが6.1.1より前のリリースである場合は、アップグレードの前にOracleサポート・サービスにお問い合せください（http://www.oracle.com/support/contact.html）。 |
Oracle Access Managerによって使用されるデータには、ユーザー・データ、構成データおよびポリシー・データという複数のタイプがあります。ユーザー・データとは、Oracle Access Managerの処理対象として構成されているエンタープライズ・アイデンティティ・ストア（LDAP）を指します。構成データは、ディレクトリに格納されるOracle Access Manager構成に関するメタデータです。ポリシー・データは、ディレクトリに格納されるアクセス・ポリシーに関するメタデータです。
停止時間ゼロのメソッド: スキーマは個別にアップグレードされます。データは、最初にインストールしたCOREidサーバーと最初にインストールしたAccess Managerのクローンをアップグレードするときにアップグレードされます。インプレース・メソッドに関するスキーマとデータのアップグレードの説明では、マスターのアイデンティティ・サーバーとポリシー・マネージャの概念を、停止時間ゼロ・メソッドでの、最初にインストールしたアイデンティティ・サーバーとAccess Managerのクローンの概念に置き換えることができます。「停止時間ゼロのアップグレード・メソッドを使用したスキーマおよびデータのアップグレード」も参照してください。
インプレース・メソッド: スキーマは、マスター・アイデンティティ・サーバーをアップグレードするときにアップグレードされます。マスター・アイデンティティ・サーバー（以前のCOREidサーバー）のアップグレード時には、構成データもアップグレードされます。その他のアイデンティティ・サーバー・インスタンスをアップグレードすると、最初のスキーマおよびデータのアップグレードが自動的に検出されます。これ以外のアイデンティティ・システムのスキーマおよびデータのアップグレードは要求されません。
ポリシー・データは、マスター・ポリシー・マネージャ（以前のAccess Managerコンポーネント）のアップグレードとともにアップグレードされます。構成ツリーとポリシー・ノードが同じディレクトリ・サーバー内にある場合、マスター・アイデンティティ・サーバーのアップグレードは構成データに対してのみ影響します。ポリシー・データがアップグレードされるのは、マスター・ポリシー・マネージャがアップグレードされる場合のみです。構成ツリー内に大量のエントリがある場合、データの移行が完了するまでに時間がかかる場合があります。
通常、次に示すような複数のディレクトリ・インスタンスを構成していないかぎり、ポリシー・データとともにその他のスキーマを更新する必要はありません。
Directory_1: アイデンティティ・システムと通信
Directory_2: アイデンティティ・システムおよびアクセス・システムと通信
Directory_3: アクセス・システムと通信
このような場合、マスター・アイデンティティ・サーバーのアップグレード時に、Directory_1およびDirectory_2上でOracle Access Managerのスキーマ・データおよび構成データがアップグレードされます。マスター・ポリシー・マネージャのアップグレード時に、Directory_2およびDirectory_3上でスキーマ・データおよびポリシー・データがアップグレードされます。
両方のメソッド: アクセス・サーバー、WebPassまたはWebGateのアップグレード時に、スキーマはアップグレードされません。各アクセス・サーバーのアップグレード時にはデータが自動的にアップグレードされ、アクセス・サーバーごとにディレクトリ・サーバー・プロファイルが作成されます。
詳細は、次を参照してください。
すべてのワークフローを1つのディレクトリ・サーバー上にまとめることをお薦めします。ワークフローが複数のディレクトリ・サーバーに格納されている場合、スキーマおよびデータを自動的にアップグレードすることはできません。
インストールに含まれるワークフローが異なるディレクトリ・サーバー上にある場合、スキーマおよびデータを手動でアップグレードする必要があります。この場合、詳細は付録Dを参照してください。
付録Fに概要を示すように、既存のデプロイに関する詳細を記録しておくことをお薦めします。使用環境におけるアップグレード・タスクの完了を追跡する際に役立つ概要も付録Fにまとめられています。
図5-1は、インプレース・アップグレード・メソッドを使用する場合の、スキーマとデータのアップグレードの準備および実行に関するタスクを示しています。図の後に詳細があります。停止時間ゼロのアップグレード・メソッドを選択する場合のスキーマとデータのアップグレードの実行については、「停止時間ゼロのアップグレード・メソッドを使用したスキーマおよびデータのアップグレード」を参照してください。
タスクの概要: スキーマおよびデータのインプレース・アップグレードの準備および実行
次の項を参照し、実行が必要な手順とタスクに影響する条件を確認します。
ディレクトリ・インスタンスおよびデータの準備: 次のリストのタスクを実行し、ディレクトリ・インスタンスおよびデータのアップグレードを準備します。
次の一連のタスクを実行し、元の読取り/書込み用マスター・ディレクトリ・サーバー・インスタンス用のセカンダリ・サーバーのマスター環境を作成します。
「スキーマおよびデータのインプレース・アップグレードの準備の完了」の説明に従って、スキーマおよびデータのアップグレードの準備を完了します。
次の説明に従って、スキーマおよびデータを順にアップグレードします。
スキーマおよびデータが正常にアップグレードされている場合、第III部の説明に従って、残りのコンポーネントを準備およびアップグレードします。
データの移行時には、ディレクトリ・サーバー・タイプとは関係なく、次の2つのファイルが作成されます。これらのファイルには両方とも、特定の中間リリースのアップグレードを適用した後に生成された新しいOracle Access Managerデータが含まれます。古いOracle Access Managerツリーは削除され、適切なファイルがアップロードされ、アップグレードされたツリーが生成されます。
アイデンティティ・サーバー・データの移行時に、output_fromversion_to_toversion_osd.ldifファイルがIdentityServer_install_dir\identity\oblix\tools\migration_tools\obmigratedataディレクトリに作成されます。
ポリシー・マネージャ・データの移行時に、output_fromversion_to_toversion_psc.ldifファイルがPolicyManager_install_dir\access\oblix\tools\migration_tools\obmigratedataディレクトリに作成されます。
また、次のようなLDAP固有のエラーをログに記録するために、次にリストされているファイルも作成されます。
アイデンティティ・サーバー・データの移行時に、error_output_fromversion_to_toversion_osd.ldifファイルがIdentityServer_install_dir\identity\oblix\tools\migration_tools\obmigratedataディレクトリに作成されます。
ポリシー・マネージャ・データの移行時に、error_output_fromversion_to_toversion_psc.ldifファイルがPolicyManager_install_dir\access\oblix\tools\migration_tools\obmigratedataディレクトリに作成されます。
詳細は、「ログ・ファイルへのアクセス」を参照してください。
ここでは、レプリケートされた環境でのアップグレード時に実行が推奨されるその他のタスクについて説明します。
デプロイには、システムの可用性やパフォーマンスを向上させるためにレプリカが採用されている場合があります。フェイルオーバー構成でレプリカを使用すると、エンタープライズ・クラスのアプリケーションで重要となるシステムの可用性を向上できます。レプリカをロード・バランシング構成で使用することにより、アプリケーションのパフォーマンスやスループットを向上できます。
停止時間を最小限に抑えるには、アップグレードが完了してすべての機能が正常に動作することを確認するまでレプリケーションを無効にしておくことをお薦めします。アイデンティティ・サーバー、ポリシー・マネージャ、アクセス・サーバー、およびディレクトリと接続するすべてのプラグインが正しく構成されている場合、（たとえばActive Directoryで）レプリケーションを無効にすると、アップグレード時にOracle Access Managerは稼働したままになります。一連のサーバーは、10g（10.1.4.0.1）へのアップグレード中に、元のディレクトリ情報（リリース7.0.4など）を操作できます。10g（10.1.4.0.1）のスキーマは、Oracle Access Managerオブジェクト・クラスからOracle Access Manager属性を削除しないかぎり、リリース7.0.4のスキーマと下位互換性があります。
次のタスクを実行する場合、特に指定がないかぎり、ディレクトリ・ベンダーのドキュメントを参照してください。タスクの概要の後に詳細があります。
|
注意: 停止時間ゼロのアップグレード・メソッドを使用している場合、スキーマのアップグレード前にレプリケーション承諾を無効にして、データのアップグレード後にそのレプリケーション承諾を有効にすることができます。詳細は、第VI部を参照してください。 |
レプリケーション承諾を無効にします（可能な場合）。
前のタスクの概要で説明されているように、スキーマおよびデータのアップグレードを準備および実行します。停止時間ゼロのメソッドを使用している場合は、第VI部を参照してください。
元のデプロイからアイデンティティ・サーバー、ポリシー・マネージャおよびアクセス・サーバーを停止します。
レプリケーション承諾を再度確立します。
レプリカに変更を送信します。
レプリカに変更が送信された後、これらのレプリカに対して構成されているコンポーネントをアップグレードします（第III部を参照してください）。停止時間ゼロのメソッドを使用している場合は、第VI部を参照してください。
|
注意: アップグレード・ツールによってスキーマおよびデータがアップグレードされていることは自動的に検出されるため、残りのコンポーネントのアップグレード時にこれらの手順は実行されません。 |
詳細は、次を参照してください。
デプロイは、ユーザー・データのレプリカを様々な方法で利用するよう構成できます。たとえば、次で説明するように、フェイルオーバーやロード・バランシングなどを実現できます。
1つのマスター・ディレクトリ・サーバー（名前はM）と1つのレプリカ（名前はR）を使用しているとします。フェイルオーバー構成を設定するには、プライマリ・サーバーMとセカンダリ・サーバーRを使用して構成された1つのDBプロファイルが必要です。この場合、Oracle Access Managerは、Mに到達できないときにRにフェイルオーバーします。
アップグレードの考慮事項: レプリカを使用したこのディレクトリ・サーバー構成は、マルチマスター・デプロイになります。したがって、ユーザー・スキーマは、マスター・インスタンスMに対してアップロードする必要があります。
このシナリオは、前述のフェイルオーバー構成と非常に類似しています。ただし、この状況では、ロード・バランシングをサポートするために複数のプライマリLDAPサーバーが使用される点が異なります。たとえば、1つのマスター・ディレクトリ・サーバー（名前はM）と1つのレプリカ（名前はR）を使用しているとします。ロード・バランシング構成を設定するには、2つのプライマリ・サーバーが構成されたDBプロファイルを1つ作成します。この場合、サーバーMとサーバーRの両方がプライマリとして構成されます。
アップグレードの考慮事項: 考慮事項は、前述のフェイルオーバー構成と同じです。レプリカを使用したディレクトリ・サーバー構成は、マルチマスター・デプロイになります。したがって、ユーザー・スキーマは、マスター・インスタンス（M）に対してアップロードする必要があります。
この構成では、複数のプライマリ・サーバーとともにセカンダリ・サーバーが構成されます。たとえば、1つのマスター・ディレクトリ・サーバー（名前はM）と2つのレプリカ（名前はR1およびR2）を使用しているとします。この場合、プライマリ・サーバーとしてMおよびR1が構成されたDBプロファイルと、1つのセカンダリ・サーバーR2が存在することになります。
このDBプロファイルに対して「フェイルオーバーしきい値」を1と指定すると、1つのプライマリ・サーバーが停止した後、残りのプライマリとともにセカンダリを使用できるようになります。
アップグレードの考慮事項: この場合も、考慮事項は前述のフェイルオーバー構成と同じです。レプリカを使用したディレクトリ・サーバー構成は、マルチマスター・デプロイになります。したがって、ユーザー・スキーマは、マスター・インスタンス（M）に対してアップロードする必要があります。
通常、このデプロイ構成を採用するのは、1つの読取り/書込み用マスターと1つの読取り専用レプリカを使用している場合です。たとえば、読取り/書込み用マスターがMで、読取り専用レプリカがRだとします。この場合、同じネームスペースに対して2つのDBプロファイルを構成する必要があります。1つのDBプロファイルでは、Mに対する書込み操作のみを許可します。もう1つのDBプロファイルでは、Rに対する読取りおよびバインド操作のみを許可します。Oracle Access Managerは、リクエストされた操作に基づいて適切なプロファイルを使用します。
アップグレードの考慮事項: これは、ディレクトリ・サーバーのマルチマスター・デプロイではありません。レプリカ（R）は読取り専用であるため、アップグレード時には、スキーマはマスター（M）に対してのみアップグレードする必要があります。
Oracle Access Managerは、レプリケートされた構成データをフェイルオーバー構成で利用できます。このシナリオでは、構成データが含まれる1つのマスター・ディレクトリ・サーバー（名前はM）と1つの読取り/書込み用レプリカ（名前はR）を使用します。また、プライマリ・インスタンス（M）とセカンダリ・インスタンス（R）が構成されたDBプロファイルを1つ使用します。
|
注意: Oracle Access Managerは、構成データのロード・バランシングには対応していません。これは、ポリシー・データのレプリケーションの場合も同様です。 |
アップグレードの考慮事項: これは、マルチマスター・デプロイです。スキーマおよびデータのアップグレードは、1つのインスタンス（M）に対してのみ実行する必要があります。これは、アイデンティティ・システムのデータとアクセス・システム（ポリシー）のデータの両方に当てはまります。
チャレンジ属性およびレスポンス属性が（オブジェクト・クラス・レベルではなく）「従業員」タブ・レベルで構成されている場合、構成データのアップグレードが正しく実行されない可能性があります。アップグレードを開始する前に、チャレンジ属性およびレスポンス属性がオブジェクト・クラス・レベルで構成されていることを確認することをお薦めします。
オブジェクト・クラス・レベルでチャレンジ/レスポンス・フレーズを構成する手順
通常どおり、COREidシステム・コンソールにログインします。
「共通構成」タブに移動し、左側のペインの「オブジェクト・クラス」をクリックします。
属性PおよびQがチャレンジ属性およびレスポンス属性として構成されている場合、PおよびQが属するオブジェクト・クラスを確認します。
「オブジェクト・クラスの構成」ページで、PおよびQ属性が属するオブジェクト・クラスをクリックします。
「オブジェクト・クラスの表示」ページで、「属性の変更」ボタンをクリックします。
属性構成アプレットで、「属性」リストで属性Pが選択されている場合、「セマンティク型」リストで「チャレンジ」セマンティク型がハイライト表示されていることを確認します。
「チャレンジ」セマンティク型がハイライト表示されていない場合、「チャレンジ」セマンティク型を選択し、これを保存します。
属性Rについても、「レスポンス」セマンティク型を選択して作業を繰り返します。
詳細は、以前のバージョンのOblix NetPointまたはOracle COREidの管理ガイド（2巻で構成されている場合は第1巻）を参照してください。
|
注意: ユーザー・データはアップグレード時には移行されませんが、アップグレード後の最初のログイン時に移行されます。インプレース・アップグレードでの関連情報については、「最初のログイン時のユーザー・データのオンザフライ移行の一時停止」を参照してください。停止時間ゼロのメソッドを使用している場合は、「ユーザー・データの移行およびLPMのチャレンジ属性とレスポンス属性の複数の値」を参照してください。 |
各ディレクトリ・サーバー・プロファイルには、ディレクトリに対する接続情報が含まれます。これには、プロファイル名、適用対象のドメインまたはネームスペース、ディレクトリ・タイプ、および一連の操作要件（読取り、書込み、検索など）が含まれます。デフォルトのディレクトリ・サーバー・プロファイルは、アイデンティティ・サーバーをインストールして新規ディレクトリ・サーバーの接続情報を指定するたびに自動的に作成されます。
リリース6.5より前は、データが2つの異なるディレクトリに格納される場合、ポリシー・データとユーザー・データのディレクトリのネームスペースは一意である必要がありました。10g（10.1.4.0.1）へのアップグレードの際、マルチ言語機能を使用できるようにするためには、この一意性を確認する必要があります。
使用している環境が次のいずれかの状況に該当する場合、アップグレード前に次の手順を実行し、ネームスペースが一意であり、その他のディレクトリ・サーバー・プロファイルのネームスペースと重複しないようにする必要があります。
以前のOracle Access Managerインストールで、構成データまたはポリシー・データがユーザー・データとは異なるディレクトリ・サーバーに格納されていました。
|
注意: ネームスペースの重複の例外として、Microsoft Active Directoryサブドメインのディレクトリ・サーバー・プロファイルと、構成DNを含むディレクトリ・サーバー・プロファイルがあげられます。 |
アイデンティティ・システムの設定時に割り当てられた構成DNまたはポリシー・ベースのネームスペースが検索ベースと一致する場合、構成データおよびポリシー・データのネームスペースが一意であることを確認せずにアップグレードすると、マスター・アイデンティティ・サーバーのアップグレード時にマルチ言語機能を有効化する自動プロセスが失敗する可能性があります。停止時間ゼロのアップグレードの場合、この機能は最初のアイデンティティ・サーバーのクローンをアップグレードするときに有効化されます。
このマニュアルでは、サード・パーティのツールの使用は扱っていません。ネームスペースがディレクトリ・サーバーで一意であることを確認する方法の詳細は、使用するディレクトリ・サーバーのドキュメントを参照してください。LDAPディレクトリ・サーバー・プロファイルの構成の詳細は、以前のOblix NetPointまたはOracle COREidの管理ガイドを参照してください。アイデンティティ・システム、ポリシー・マネージャまたはアクセス・サーバーの設定の再実行については、以前のOblix NetPointまたはOracle COREidの管理ガイドを参照してください。
ネームスペースの一意性を確認して再構成する手順（必要な場合）
ディレクトリ・サーバーで、構成データのネームスペースが一意であり、その他のネームスペースと重複していないことを確認します。
ディレクトリ・サーバーで、ポリシー・データのネームスペースが一意であり、その他のネームスペースと重複していないことを確認します。
COREidシステム・コンソールを使用して、構成データおよびポリシー・データの一意のネームスペースが含まれるようにLDAPディレクトリ・サーバー・プロファイルを構成します。次に例を示します。
COREidシステム・コンソール→「システム管理」→「システム構成」→「ディレクトリ・オプションの構成」→Profile_Linkを選択して次のフィールドで入力を行います。
ネームスペース: 一意のネームスペースを入力します。
アイデンティティ・サーバーを再起動します。
以前のOblix NetPointまたはOracle COREidの管理ガイドの説明に従って、アイデンティティ・システムの設定を再実行します。
以前のOblix NetPointまたはOracle COREidの管理ガイドの説明に従って、ポリシー・マネージャの設定を再実行します。
以前のOblix NetPointまたはOracle COREidの管理ガイドの説明に従って、アクセス・サーバーの設定を再実行します。
アップグレードを開始する前に、次の概要に示すタスクをすべて実行して、スキーマおよびデータのアップグレード用のディレクトリ・インスタンスを準備することをお薦めします。
タスクの概要: スキーマおよびデータのアップグレード用のディレクトリ・インスタンスの準備
次のように、サポートされるディレクトリ・サーバーを確認します。
https://metalink.oracle.comのMetaLinkにアクセスします。
指示に従ってMetaLinkにログインします。
「Certify」タブをクリックします。
「View Certifications by Product」をクリックします。
「Application Server」オプションを選択し、「Submit」をクリックします。
「Oracle Identity Manager」を選択し、「Submit」をクリックします。
「Oracle Identity Management Certification Information 10g (10.1.4.0.1)」（html）をクリックして「Oracle Identity Management」ページを表示します。
「Section 6, "Oracle Access Manager Certification"」のリンクをクリックして、証明書マトリクスを表示します。
廃止されているディレクトリ・リリース: 「リリースが終了となったディレクトリ・サーバーの準備」のアクティビティを実行します。
「ディレクトリ・サーバーの検索サイズ制限パラメータの変更」のアクティビティを実行します。
ディレクトリ・サーバーの考慮事項を確認し、使用している環境が次のすべての要件を満たしていることを確認します。
ディレクトリのベンダーの指示に従って、Oracle Access Managerデータが含まれるすべてのディレクトリ・インスタンスをバックアップします。
使用しているディレクトリ・サーバーのリリースがサポートされていない場合、次で説明するように、Oracle Access Managerの以前のディレクトリ・サーバー・プロファイルおよびディレクトリ・サーバーをアップグレードしてから、10g（10.1.4.0.1）にアップグレードできます。
|
注意: 次の概要は参考用とし、ディレクトリ・サーバーの管理に関する詳細情報が記載されたベンダーのドキュメントを参照してください。また、「サポートが変更または終了した場合のアップグレード計画」も参照してください。 |
タスクの概要: リリースが終了となった場合の新しいディレクトリ・サーバーのインストール
次のように、Oracle Access Manager 10g（10.1.4.0.1）に関する最新のサポート情報を確認します。
https://metalink.oracle.comのMetaLinkにアクセスします。
指示に従ってMetaLinkにログインします。
「Certify」タブをクリックします。
「View Certifications by Product」をクリックします。
「Application Server」オプションを選択し、「Submit」をクリックします。
「Oracle Identity Manager」を選択し、「Submit」をクリックします。
「Oracle Identity Management Certification Information 10g (10.1.4.0.1)」（html）をクリックして「Oracle Identity Management」ページを表示します。
「Section 6, "Oracle Access Manager Certification"」のリンクをクリックして、証明書マトリクスを表示します。
アップグレードを開始する前に、使用ベンダーのドキュメントを参考として使用して、10g（10.1.4.0.1）でサポートされるディレクトリ・サーバーをインストールします。
以前のOracle Access Managerインストールで、10g（10.1.4.0.1）へのアップグレードを開始する前に、ディレクトリ・サーバー・プロファイル（およびこれに含まれるデータベース・インスタンス・プロファイル）を再構成します。詳細は、以前のOblix NetPointまたはOracle COREidの管理ガイド（2巻で構成されている場合は第1巻）を参照してください。
以前のOracle Access Managerインストールで、次のようにディレクトリ・サーバーを変更します。
COREidシステム・コンソールで、「システム構成」→「ディレクトリ・サーバー・オプションの構成」を選択して「ディレクトリ・サーバー」をクリックし、必要に応じて設定を変更します。
以前のOblix NetPointまたはOracle COREidの管理ガイド（2巻で構成されている場合は第1巻）の説明に従って、アイデンティティ・システムの設定を再実行し、構成ファイルが正しく更新されていることを確認します。
アップグレードを開始する前に、この章に関連するタスクをすべて実行します。インプレース・アップグレード・メソッドを使用している場合、新しいディレクトリに対して構成されているマスター・アイデンティティ・サーバー（以前のCOREidサーバー）、WebPass、およびポリシー・マネージャ（以前のAccess Managerコンポーネント）を追加します。停止時間ゼロのメソッドを使用している場合は、第VI部を参照してください。
このマニュアルの説明に従い、選択したメソッドを使用してアップグレードします。
アップグレードを開始する前に、ディレクトリ・サーバーの検索サイズ制限パラメータの値が構成ツリー内のエントリ数より大きいことを確認する必要があります。このパラメータのデフォルト値は、ディレクトリによって異なります。詳細は、ベンダーのドキュメントを参照してください。
|
注意: 構成ツリー内のエントリ数の方がディレクトリ・サーバーのサイズ制限パラメータの値より大きい場合、Oracle Access Managerデータのアップグレード・プロセスは失敗する可能性があります。 |
このパラメータに適した値を決定する特定のルールは存在しません。このため、次の手順で説明するように、正しい値を定義および検出するプロセスは、繰返しの作業になります。
ディレクトリ・サーバーのサイズ制限パラメータに適した値を設定する手順
ldapsearchコマンドを使用して構成ツリー内のすべてのノードを取得してすべてのエントリを取得し、ディレクトリ・サーバーのサイズ制限パラメータの既存の値の適性を確認します。次に例を示します。
ldapsearch.exe -h host -p port-D bindDN -w password -b config_root
-s sub (objectclass=*) Dn
このコマンドで、bindDNは、以前のアイデンティティ・システム（以前のCOREid）の設定時に指定したものです。
ldapsearchコマンドの結果が成功している場合、データの移行時に問題は発生しないため、この手順の残りの部分はスキップしてください。
ldapsearchの結果、サイズ制限を超えていることを示すメッセージが表示された場合、ステップ2を実行します。
ベンダーのドキュメントに記載されている情報を使用してディレクトリ・サーバーのサイズ制限パラメータ値を大きくしてから、ステップ1を繰り返します。
たとえば、値を10000（または使用環境に適していると思われる値）に設定してから、ldapsearchを再実行し、この値で成功するかどうかを確認します。これでもサイズ制限を超える場合は、ldapsearchコマンドの実行が成功するまでステップ2を繰り返す必要があります。
ldapsearchが成功した後、成功した検索サイズ制限値をアップグレードが終了するまで保持します。
アップグレードが成功した後、このサイズ制限パラメータを元の値に戻すことができます。
Active Directoryをバックエンド・ディレクトリ・サーバーとして使用している場合、次の情報を確認し、使用している環境のアップグレード前に必要なタスクを実行する必要があります。
アップグレードを開始する前に、検索サイズ制限パラメータ（MaxPageSize）の値が構成ツリー内のエントリ数より大きいことを確認する必要があります。MaxPageSizeパラメータにより、検索操作で返されるエントリの最大数を指定します。MaxPageSizeパラメータのデフォルト値は1000です。構成ツリー内のエントリ数の方がMaxPageSizeパラメータの設定値より大きい場合、Oracle Access Managerデータの移行プロセスは失敗する可能性があります。
|
注意: ここで示す例は、Microsoft Windows 2000 Advanced Server上で動作しているActive Directoryに基づいています。これらの詳細はその他のバージョンでは異なる場合があります。使用しているバージョンに固有の詳細は、Active Directoryのドキュメントを参照してください。 |
MaxPageSizeパラメータの既存の値を表示して新しい値を設定する手順
コマンド・プロンプトでntdsutilツールを使用して、次のトランスクリプトで示すように、MaxPageSizeパラメータの現在値を表示します。次に例を示します。
C:\Documents and Settings\Administrator ntdsutil
ntdsutil: ldap policies
ldap policy: connections
server connections: connect to server <machine_name>
Binding to <machine_name> ...
Connected to <machine_name> using credentials of locally logged on userserver connections: q
ldap policy: show values
コマンド・プロンプトでntdsutilツールを使用して、次のトランスクリプトで示すように、新しいMaxPageSizeの値を設定し、変更内容を表示します。次に例を示します。
C:\Documents and Settings\Administrator ntdsutil ntdsutil: ldap policies ldap policy: connections server connections: connect to server <machine_name> Binding to <machine_name> ... Connected to <machine_name> using credentials of locally logged on userserver connections: q ldap policy: set MaxPageSize to <new_value> ldap policy: commit changes ldap policy: show values
このパラメータに適した値の選択方法は、「ディレクトリ・サーバーの検索サイズ制限パラメータの変更」を参照してください。
Active Directoryスキーマの変更は、スキーマ・マスターに対してのみ実行できます。以前の環境がActive Directoryスキーマ・マスターを使用するよう構成されている場合、この説明はスキップしてください。
スキーマ・マスターを使用していない場合、Windows 2000プラットフォーム上で次の手順を実行できます。これ以外の方法は、Microsoftのサポート用WebサイトにあるMicrosoftナレッジベースの文書番号285172「To Enable Schema Updates by Means of the Registry」（以前のQ285172P）を参照してください。
Active Directoryスキーマ・プラグインを開きます。多くの場合、このプラグインは「管理ツール」にあります。
スキーマの最上位ノードを右クリックし、「操作マスタ」を選択し、「スキーマ マスタの変更」を表示します。
「このドメイン コントローラでスキーマの修正が可能」の横にあるボックスを選択し、「OK」をクリックします。
アップグレードを開始する前に、サイズ制限パラメータの値が構成ツリー内のエントリ数より大きいことを確認する必要があります。詳細は、「ディレクトリ・サーバーの検索サイズ制限パラメータの変更」を参照してください。
ADAMがディレクトリ・サーバーである場合、アップグレード時には、不要になったスキーマのクリーンアップはサポートされません。ADAMを使用する場合、アップグレード・プロセス中にスキーマを手動で更新する必要があります。ただし、スキーマを手動でアップグレードした後、データの自動アップグレードを受け入れ、コンポーネントのアップグレード・プロセスを完了できます。
ADAMがサポートされるのは、リリース6.5からです。ADAMをアップグレードする場合、Oracle Access Managerでは、構成ディレクトリとユーザー・ディレクトリの手動アップグレード用として次のスキーマ・ファイルが提供されます。
各ファイルには、指定されたリリース間に固有のスキーマ変更のみが含まれます。詳細は、次のとおりです。
リリース6.5からアップグレードする場合、リリース6.5から7.0への段階的アップグレード時に650_to_700ファイルをアップロードする必要があります。この場合、リリース7.0から10g（10.1.4.0.1）への段階的アップグレード時に700_to_1014ファイルもアップロードする必要があります。
リリース7.0から10g（10.1.4.0.1）に直接アップグレードする場合、7.0からの段階的アップグレード時にアップロードする必要があるのは、700_to_1014ファイルのみです。
|
注意: 静的リンク補助クラスを使用している場合、アップグレード時に必要な特定のファイルはありません。 |
ADAMスキーマを手動で更新するためのldifdeコマンドの例を次に示し、また表5-1でも説明します。詳細は、Microsoft社のドキュメントを参照してください。
ldifde -k -b
"<user_distinguished_name>""<domain_name>""<user_password>"
-c"<GUID>"<ADAM_instance_ID> -i -f ADAM_oblix_schema_add -s
<ADAM_server_name> -t <port>
| オプション | 説明 |
|---|---|
|
-k |
このオプションはエラーを無視する。 |
|
-b "<user_distinguished_name>" "<domain_name>" "<user_password> |
スキーマを拡張するための各値: |
|
-c "<GUID>" <ADAM_instance_ID> |
このオプションでは、"<GUID>"は他の値で置き換えずにそのまま使用する。引用符も含める。<ADAM_instance_ID>は、ldp.exeなどのツールを使用してADAMルートDSEで置き換える。最初に接続したときにルートDSEが表示される。たとえば、ADAMルートDSE値はEC31B31B-19FC-4FD4-8590-3BD57D6A3E77。 |
|
-i -f <filename> |
-iオプションはインポート・オプションを指定する。-fオプションはファイルを指定する。値には、インポートするファイル名を指定する。例: ADAM_oblix_schema_add.ldifADAMAuxSchema.ldif |
|
-s <ADAM_server_name> |
この値は、ADAMがインストールされているコンピュータの名前。 |
|
-t <port > |
この値は、このインスタンスがスキーマの更新をリスニングするポート番号（オープン・ポートが必要）。 |
アップグレードを開始する前に、サイズ制限パラメータの値が構成ツリー内のエントリ数より大きいことを確認する必要があります。詳細は、「ディレクトリ・サーバーの検索サイズ制限パラメータの変更」を参照してください。
最初のアイデンティティ・サーバーおよびポリシー・マネージャのアップグレード時に、IBM SecureWayディレクトリ・サーバーを実行するユーザーは、Oracle Access Managerスキーマ・ファイルおよびスキーマ・ファイルが含まれるディレクトリへの読取りおよび書込み権限を持っている必要があります。アップグレード時には、スキーマ・ファイルをコピーするよう求められる場合があります。スキーマ・ファイルのコピー先は、アップグレード・プログラムによって示されます。
次のタスクの概要は、以前のインストールのIBM Directory Serverが10g（10.1.4.0.1）でサポートされていない場合のガイドです。特定の製品リリースに対する参照は、単に説明目的で使用されています。
タスクの概要: IBM Directory Serverがサポートされていない場合のアップグレード
次のように、Oracle Access Manager 10g（10.1.4.0.1）に関する最新のサポート情報を確認します。
https://metalink.oracle.comのMetaLinkにアクセスします。
指示に従ってMetaLinkにログインします。
「Certify」タブをクリックします。
「View Certifications by Product」をクリックします。
「Application Server」オプションを選択し、「Submit」をクリックします。
「Oracle Identity Manager」を選択し、「Submit」をクリックします。
「Oracle Identity Management Certification Information 10g (10.1.4.0.1)」（html）をクリックして「Oracle Identity Management」ページを表示します。
「Section 6, "Oracle Access Manager Certification"」のリンクをクリックして、証明書マトリクスを表示します。
Oracle Access Managerをアップグレードする前に、IBMのドキュメントに記載されている情報を使用して以前のIBM Directory Server（v4.xなど）のデータおよびスキーマをIBM Directory Serverバージョン5.1にアップグレードする必要があります。
10g（10.1.4.0.1）へのアップグレードを開始する前に、「ディレクトリ・サーバーの検索サイズ制限パラメータの変更」のアクティビティを実行します。
10g（10.1.4.0.1）インストール・パッケージを使用して、このマニュアルの説明に従ってOracle Access Managerコンポーネントをアップグレードします。
アップグレードを開始する前に、orclsizelimitパラメータの値が構成ツリー内のエントリ数より大きいことを確認する必要があります。このパラメータにより、検索操作で返されるエントリの最大数を指定します。Oracle Internet Directoryの場合、サイズ制限パラメータはorclsizelimitです。このパラメータのデフォルト値は1000です。このパラメータに適した値の選択方法は、「ディレクトリ・サーバーの検索サイズ制限パラメータの変更」を参照してください。
|
注意: 次の手順の例は、Microsoft Windows 2000 Advanced Server上で動作しているOracle Internet Directoryバージョン10.1.2に基づいています。これらの詳細はその他のバージョンでは異なる場合があります。使用しているバージョンに固有の詳細は、Oracle Internet Directoryのドキュメントを参照してください。 |
orclsizelimitパラメータの既存の値を表示するか新しい値を設定する手順
Oracle Directory Manager（ODM）を開きます。
左側のナビゲータ・ペインで、Oracle Internet Directoryサーバーを開きます。
Oracle Access Managerの以前のリリースを構成したディレクトリ・サーバー・インスタンスを選択します。
このインスタンス・ページ（右側のペイン）で、「システム操作属性」タブを選択します。
このページの「問合せエントリの返送制限」パラメータは、orclsizelimitを指します。
この「問合せエントリの返送制限」パラメータのテキスト・ボックスの値は、orclsizelimitパラメータの既存の値を示します。
「問合せエントリの返送制限」パラメータのテキスト・ボックスの値を変更してから、変更を適用します。
Oracle Access Manager 10g（10.1.4.0.1）は、Siemens DirXディレクトリをサポートしていません。このディレクトリの移行パスはありません。
アップグレードを開始する前に、ディレクトリ・サーバーのリリースが現在サポートされていることを確認する必要があります。サポートされていない場合は、「リリースが終了となったディレクトリ・サーバーの準備」を参照してください。また、サイズ制限パラメータの値が構成ツリー内のエントリ数より大きいことも確認する必要があります。Sun（以前のiPlanet）Directory Serverの場合は、nsslapd-sizelimit（サイズ制限）です。このパラメータにより、検索操作で返されるエントリの最大数を指定します。このパラメータのデフォルト値は2000です。このパラメータに適した値の選択方法は、「ディレクトリ・サーバーの検索サイズ制限パラメータの変更」を参照してください。
|
注意: この例は、Microsoft Windows 2000 Professional上で動作しているiPlanet 5.1に基づいています。これらの詳細はその他のバージョンでは異なる場合があります。使用しているバージョンに固有の詳細は、Sun Directoryのドキュメントを参照してください。 |
nsslapd-sizelimitパラメータの既存の値を表示して新しい値を設定する手順
iPlanetコンソールを開きます。
「Servers and Applications」タブで、左側のペインにあるツリーを開き、既存のすべてのディレクトリ・サーバー・インスタンスのリストを表示します。
COREidを構成したディレクトリ・サーバー・インスタンスを選択します。
選択したインスタンスの管理ウィンドウを開きます。
開かれたウィンドウで、「Configuration」タブを選択します。
「Performance」タブを選択し、このサイズ制限パラメータの既存の値を表示します。
サイズ制限パラメータのテキスト・ボックスの値を変更してから、変更を保存します。
第2章で説明するように、特定のアップグレード・タスクの実行前に既存のデータをバックアップすることをお薦めします。図5-2に、使用するメソッドを問わず、アップグレードを開始する前にバックアップするデータのタイプを示します。
バックアップが必要なデータの詳細は、この章の次の項を参照してください。
第8章の次の詳細も参照してください。
アップグレードしたスキーマには、以前のスキーマ（リリース6.1.1まで）との下位互換性がありますが、Oracleで提供されるツールを使用してスキーマのアップグレードをロールバックすることはできません。ディレクトリ・サーバーの一部のベンダーでは、スキーマのバックアップに使用できるツールが提供されています。アップグレード前に外部ツールを使用して以前のスキーマをバックアップしておけば、元のリリースにロールバックする場合に、バックアップ・コピーを回復できます。
アップグレードを開始する前に、ディレクトリ・ベンダーによって提供されるツールを使用して、既存のディレクトリ・サーバー・インスタンスのスキーマをバックアップすることをお薦めします。たとえば、Sun ONE Directory Serverでは、slapd-instance-nameconfig/schema/99user.ldifファイルにスキーマが格納されています。
詳細は、ディレクトリ・ベンダーのドキュメントを参照してください。すべてのディレクトリ・サーバーのベンダーが、スキーマをバックアップするツールを提供しているわけでありません。
アップグレードを開始する前に、Oracle Access Managerの構成データおよびポリシー・データをldifファイルに手動でエクスポートすることをお薦めします。アップグレードが失敗した場合、このファイルを使用して設定をリストアできるようになります。
ほとんどのベンダーは、ディレクトリ・データをldifファイルにエクスポートするために使用できるディレクトリ・サーバー・コンソール・アプリケーションを用意しています。また、サブツリー・レベルで構成ベースおよびポリシー・ベースに対してldapsearchを実行することもできます。この場合、フィルタ（objectclass=*など）を使用し、この検索の出力をldifファイルにリダイレクトできます。
Ldapsearchコマンドを実行します。
このコマンドで、構成データおよびポリシー・データをバックアップするための構成ベース/ポリシー・ベースを指定します。
Ldapsearch –h hostname -p port> D bind_dn -w password -s sub –b config/policy base dn (objectclass=*) > backup_cp_data.ldif
ユーザー・データおよびグループ・データのバックアップの手順は、「Oracle Access Managerの構成データおよびポリシー・データのバックアップ」の手順と同じです。ただし、この場合、検索ベースを指定します。
Windowsプラットフォームにインストールされたコンポーネントの場合、ワークフロー・データのみでなく、コンポーネントのWindowsレジストリ・エントリもバックアップすることをお薦めします。
Ldapsearchコマンドを実行します。
このコマンドで、ユーザー・データおよびグループ・データをバックアップするための検索ベースを指定します。
Ldapsearch –h hostname -p port> D bind_dn -w password -s sub –b searchbase dn (objectclass=*) > backup_ug_data.ldif
Windows: 「Windowsレジストリ・データのバックアップ」のアクティビティを実行します。
適切なDBプロファイルを構成してワークフローを個別に格納することを選択していないかぎり、ワークフロー・データは、構成データの一部として自動的にバックアップされます。ワークフローが個別に格納されている場合、「Oracle Access Managerの構成データおよびポリシー・データのバックアップ」の場合と同じ手順を実行し、ワークフロー・データをバックアップする必要があります。
ワークフロー・データを個別にバックアップする場合の唯一の差異は、次の手順で示すように、Ldapsearchコマンドでワークフロー・データベース・インスタンス・プロファイルのネームスペースを指定する点です。たとえば、データベース・インスタンス・プロファイルの名前がworkflow_namespaceである場合、これをコマンドに含めます。
Windowsプラットフォームにインストールされたコンポーネントの場合、ワークフロー・データのみでなく、コンポーネントのWindowsレジストリ・エントリもバックアップすることをお薦めします。
Ldapsearchコマンドを実行します。
このコマンドで、ユーザー・データおよびグループ・データをバックアップするためのワークフローを指定します。
Ldapsearch –h hostname -p port> D bind_dn -w password -s sub –b workflow_namespace (objectclass=*) > backup_wf_data.ldif
Windows: 「Windowsレジストリ・データのバックアップ」のアクティビティを実行します。
チケットの検索速度を上げるには、次で説明するように、処理済ワークフロー・インスタンスもアーカイブする必要があります。
ワークフロー・インスタンス（ワークフローの参加者によって実行および処理されるものを含む）は、ディレクトリ・サーバーに格納されます。アップグレード時に、ワークフロー・データは妨害または削除されません。
アップグレードを開始する前に、すべての処理済ワークフロー・インスタンスをアーカイブすることをお薦めします。アーカイブされたインスタンスは、IdentityServer_install_dir/identity/oblix/data/common/wfinstance.ldifのldifファイルに格納されます。これにより、処理済ワークフローのレコードが作成され、ワークフロー・チケットの検索速度が上がる場合があります。
処理済ワークフロー・インスタンスをアーカイブしてチケットの検索速度を上げる手順
通常どおり、COREidシステム・コンソールに移動します。
ユーザー・マネージャ、グループ・マネージャまたは組織マネージャ・アプリケーションで、「リクエスト」を選択します。
「リクエストのモニター」ページで、検索基準を入力し、チケットを検索します。
結果が返された場合、これらを選択し、「アーカイブ」ボタンをクリックします。
wfinstance.ldifという名前のファイルが作成され、IdentityServer_install_dir/identity/oblix/data/commonディレクトリに格納されます。
リカバリ計画に役立つため、アップグレードを開始する前に、Oracle Access Managerデータが含まれるディレクトリ・インスタンスをバックアップすることをお薦めします。
このタスクを実行するには、ディレクトリ・ベンダーの指示に従います。このマニュアルでは、サード・パーティのツールを扱っていません。
ユーザー・データはアップグレード時には移行されませんが、アップグレード後の最初のログイン時に移行されます。インプレース・アップグレードを実行する場合のみ、データをバックアップした後、ホスト・コンピュータを準備する前にここで説明するアクティビティを実行します。
|
注意: 停止時間ゼロのメソッドを使用している場合、この移行はユーザーが開始するまで自動的に停止しています。詳細は、「ユーザー・データの移行およびLPMのチャレンジ属性とレスポンス属性の複数の値」を参照してください。 |
第4章で説明するように、以前のリリースからOracle Access Manager 10g（10.1.4.0.1）にアップグレードする場合、ディレクトリ・サーバーのoblixツリーに格納されている構成データは自動的に移行され、obVer属性の値は10.1.4.0に変わります。ただし、ユーザー・データ（ロスト・パスワード管理の場合のみ、チャレンジ属性とレスポンス属性に複数の値が存在する）は、アップグレード後の最初のログインまで移行されません。つまり、ユーザー・データ（OblixOrgPersonクラス）のobVer属性の値は10.1.4.0より小さいまま変わりません。
タスクの概要の説明に従ってユーザー・データの即時（オンザフライとも呼ばれる）移行を一時的に停止しないかぎり、10g（10.1.4.0.1）へのアップグレード後、最初にユーザーがログインしたときにユーザー・エントリが即時移行されます。そのユーザーの既存のチャレンジおよびレスポンスの値はエンコードされ（@1#が末尾に付加され）、そのユーザーのOblixOrgPersonクラスのobVer属性の値は10.1.4.0に変わります。ただし、これらの変更はロールバック・プロセスでは元に戻りません。以前のリリースにロールバックしても、OblixOrgPersonクラスのユーザー・エントリのobVer値は10.1.4.0のまま変わらず、チャレンジおよびレスポンスの値はエンコード形式のまま変わりません。
タスクの概要: 最初のログイン時のユーザー・データ移行の一時停止および再実行
まず、アップグレードを開始する前に、「ユーザー・データのオンザフライ移行の停止: フェーズ1」の手順のアクティビティを実行してから、この章の残りのアクティビティをすべて実行します。
アイデンティティ・システムのスキーマとデータをアップグレードする第6章のアクティビティを順に実行してから、「ユーザー・データのオンザフライ移行の停止: フェーズ2」のステップを実行します。
|
注意: フェーズ2は、アイデンティティ・システムとアクセス・システムの混合デプロイの場合でも、アイデンティティ・システムのスキーマとデータをアップグレードした後、管理者またはユーザーがログインする前に一度実行する必要があるアクティビティです。 |
第7章〜第13章の説明に従って、インプレース・アップグレードの残りのタスクを実行します。
第14章の説明に従ってデプロイを検証し、デプロイが予定どおりに機能しているか、および以前のリリースにロールバックする必要がないかどうかを確認します。
アップグレードしたデプロイを以前のリリースにロールバックする必要がないことを確認したら、「インプレース・アップグレードのユーザー・データのオンザフライ移行の再実行」のステップを実行します。
フェーズ1では、マスター管理者エントリのobVer属性を設定し、スキーマとデータを10g（10.1.4.0.1）にアップグレードします。フェーズ2はスキーマおよびデータのアップグレード後に実行します。フェーズ2では、「チャレンジ」セマンティク型と「レスポンス」セマンティク型を、タブ・レベルとオブジェクト・クラス・レベルの両方で削除します。
次に示すフェーズ1の手順を実行する前に、考慮する条件がいくつかあります。
OblixOrgPersonがユーザー・エントリのオブジェクト・クラス・リストに存在しない場合、最初にステップ1の説明に従ってOblixOrgPersonを追加する必要があります。存在する場合はステップ2から開始します。
最後のステップを実行すると、ロスト・パスワード管理機能は動作しなくなります。
最初のログイン時のユーザー・データのオンザフライ移行を一時的に停止した後、次のアクションの処理または実行を中止して、ユーザー・データが下位互換性を確保しているかどうかを確認することをお薦めします。
ユーザーの作成、属性の変更などのワークフロー・チケットの処理の中止
「プロファイルの変更」ページでのチャレンジ属性とレスポンス属性の変更の中止
マスター管理者のユーザー・エントリにOblixOrgPersonを追加します（必要な場合）。
ldapmodify.exe -h <Host> \
-p <Port>
-D <Bind DN>
-w <Bind Password> \
-f <ldif file containing attribute to be added>
オブジェクト・クラス・リストにOblixOrgPersonを追加する際に作成されるLDIFファイルの形式は次のとおりです。これはNetscape Directory Serverの場合の例です。
dn: <Administrator DN>
changetype: modify
add: objectclass
objectclass: OblixOrgPerson
次のコマンドを使用して、LDAPディレクトリ・サーバーのマスター管理者エントリのobVer属性を7.0.4に設定します。
ldapmodify.exe -h <Host> \
-p <Port>
-D <Bind DN>
-w <Bind Password> \
-f <ldif file containing attribute to be modified>
作成されるLDIFファイルの形式は次のとおりです。これはNetscape Directory Serverの場合の例です。
dn: <Administrator DN>
changetype: modify
replace: obver
obver: 7.0.4
この章の説明に従って、残りの準備タスクを完了します。
第6章の説明に従って、デプロイのスキーマとデータのアップグレードを実行します。この章の「ユーザー・データのオンザフライ移行の停止: フェーズ2」には、フェーズ2を実行する手順が記載されています。
デプロイ全体のアップグレードの成功を確認した後にユーザー・データの移行を再実行するには、「インプレース・アップグレードのユーザー・データのオンザフライ移行の再実行」を参照してください。
次のアクティビティは、スキーマおよびデータのアップグレード時に追加および使用するマスター・コンポーネントのホスト・コンピュータを準備することです。マスター・コンポーネントには、以前のアイデンティティ・サーバー、WebPass（およびアクセス・システムがインストールされている場合はポリシー・マネージャ（以前のAccess Managerコンポーネント））が含まれます。
マスター・コンポーネントをインストールする前のホスト・コンピュータの準備については、第8章の次の項を参照してください。
マスター・コンポーネントのホスト・コンピュータを準備した後、「インプレース・メソッドのマスターとして使用するための以前のアイデンティティ・システムの追加」に進みます。
アイデンティティ・システムとアクセス・システムの混合: アクセス・システムもインストールされている場合は、マスター・アイデンティティ・システムを追加した後、「インプレース・メソッドのマスターとして使用するための以前のAccess Managerの追加」のタスクを実行します。アクセス・システムがインストールされていない場合は、アクセス・システム関連のアクティビティはスキップします。
インストールにアクセス・システムが含まれるかどうかに関係なく、この章のアクティビティが完了した後、アイデンティティ・システムのスキーマおよびデータをアップグレードします。
ここで説明するアクティビティを実行し、1つの（以前の）アイデンティティ・サーバー・インスタンス（以前のCOREidサーバー）およびWebPassを既存のインストールに追加します。この追加のアイデンティティ・システムは、元の読取り/書込み用のマスター・ディレクトリ・サーバー・インスタンスのセカンダリ・サーバーとして使用されます。これらのマスター・コンポーネントに対してスキーマおよびデータをアップグレードすると、以前のインストールの残りの部分をアップグレードする前にスキーマおよびデータを正しくアップグレードする上で役立ちます。
|
注意: アップグレードの際にプラットフォームをSolarisからLinuxに切り替える場合は、このステップを省略してください。アイデンティティ・システム・インスタンスをLinuxホストにインストールする場合、そのインスタンスはマスター・コンポーネントとして機能します。アップグレードの際にプラットフォームをSolarisからLinuxに切り替える方法の詳細は、付録Bを参照してください。 |
ここで追加するマスター・インスタンスは、10g（10.1.4.0.1）の要件を満たす任意のコンピュータを選択してインストールできます。ただし、追加するマスター・インスタンスは、（使用環境内の他のアイデンティティ・サーバーに対して構成されていても）監査およびアクセス・レポートなどについては構成する必要はありません。ここで追加するマスター・インスタンスの目的は1つであり、これは、スキーマおよびデータのアップグレード時に使用するためのものです。アイデンティティ・システム環境全体をアップグレードした後、この追加インスタンスを保持することも、アップグレード環境に影響を与えずに削除することもできます。
|
注意: 以前のインストールに英語以外の言語が含まれる場合、この追加インスタンスは同じ言語パックを使用してインストールする必要があります。 |
スキーマおよびデータのアップグレード用のマスター・アイデンティティ・システムの設定の説明は、次を参照してください。
タスクの概要: スキーマおよびデータのアップグレード用のマスター・アイデンティティ・システムの追加
作業を開始する前に、表5-2のタスクを完了していることを確認してください。前提条件が満たされていないと、アップグレードに悪影響が生じる場合があります。
表5-2 マスター・アイデンティティ・サーバー・インストールの前提条件
| マスター・アイデンティティ・サーバー・インストールの前提条件 |
|---|
|
この章のすべての準備アクティビティを実行している。
|
|
第I部の概要の章の情報を確認している。 |
追加するアイデンティティ・サーバー・インスタンスには、WebPassが必要です。ただし、どちらをインストールする場合もその前に、既存のCOREidシステム・コンソールで追加インスタンスの詳細を定義する必要があります。詳細は、以前のOblix NetPointまたはOracle COREidの管理ガイド（2巻で構成されている場合は第1巻）を参照してください。
|
注意: ここでは、説明を明確にするために、画面に表示される以前の用語を使用します。 |
システム・コンソールで追加コンポーネントに関する情報を追加する手順
COREidシステム・コンソールで新しいWebPassインスタンスに関する情報を追加します。次に例を示します。
通常どおり、既存のCOREidシステム・コンソールに移動します。次に例を示します。
http://hostname:port/identity/oblix/
ここで、hostnameは既存のWebPassのWebサーバーをホストするコンピュータ、portは既存のWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、\identity\oblixはCOREidシステム・コンソールに接続します。
COREidシステム・コンソールで、「システム構成」→「WebPassの構成」を選択し、「追加」ボタンをクリックします。
「新規WebPassの追加」ページで、次の情報を入力します。
名前: このWebPassインスタンスの一意の識別子（リリース番号やポート番号が含まれる場合があります）。たとえば、WebPass_611_6047などです。
ホスト名: このWebPassインスタンスをホストしているコンピュータのDNSのフルネーム。このインスタンスはどこにでもインストールできます。注意事項はありません。
最大接続数: このWebPassでCOREidサーバーに対してオープンする接続の最大数。追加するCOREidサーバーに対してこの値を1に設定します。
トランスポート・セキュリティ: アイデンティティ・サーバーとWebクライアント間の通信に使用するセキュリティ方式を選択します。
|
注意: すべてのアイデンティティ・システムのコンポーネント（アイデンティティ・サーバー・インスタンスおよびWebPassインスタンス）間のトランスポート・セキュリティは一致している必要があります（すべてオープン、簡易または証明書モード）。 |
最大セッション時間(時間): WebPassとアイデンティティ・サーバー間の接続をオープン状態のまま維持する最大時間。この時間が経過すると、既存の接続はクローズされて新規接続がオープンされます。
COREidサーバー・タイムアウトしきい値: WebPassで接続を試みて応答しないCOREidサーバーを接続不可能とみなして別のサーバーへの接続を試みるまでの時間（秒単位）。値を指定しない場合、タイムアウトは適用されません。
情報を保存します。
COREidシステム・コンソールで追加のCOREidサーバー・インスタンスに関する詳細を追加します。具体的には次のとおりです。
COREidシステム・コンソールで、「システム構成」→「COREidサーバーの構成」を選択し、「追加」ボタンをクリックします。
新規COREidサーバーの追加ページで、次の情報を入力します。
名前: このCOREidサーバー・インスタンスの一意の識別子（リリース番号やポート番号が含まれる場合があります）。たとえば、COREidServer_611_6047のようにします。
ホスト名: このCOREidサーバー・インスタンスをホストしているコンピュータのDNSのフルネーム。このインスタンスはどこにでもインストールできます。注意事項はありません。
トランスポート・セキュリティ: COREidサーバーとWebPass間の通信に使用するセキュリティ方式を選択します。
|
注意: すべてのアイデンティティ・システムのコンポーネント（アイデンティティ・サーバー・インスタンスおよびWebPassインスタンス）間のトランスポート・セキュリティは一致している必要があります（すべてオープン、簡易または証明書モード）。 |
最大セッション時間(時間): WebPassとアイデンティティ・サーバー間の接続をオープン状態のまま維持する最大時間を入力します。この時間が経過すると、既存の接続はクローズされて新規接続がオープンされます。
情報を保存します。
システム・コンソールで、このCOREidサーバーをWebPassに関連付け、優先順位を「セカンダリ」に指定します。具体的には次のとおりです。
COREidシステム・コンソールで、「システム構成」を選択し、「WebPassの構成」をクリックします。
「すべてのWebPassをリスト」ページで、定義したWebPassのリンクをクリックします。
WebPassの詳細ページで、「COREidサーバーのリスト」をクリックします。
WebPassに関連付けられているプライマリ・サーバーとセカンダリ・サーバーがリストされたページで、「追加」をクリックします。
「サーバーの選択」リスト（WebPassへの新規COREidサーバーの追加ページ上）で、今追加したサーバーをクリックして選択します。
このサーバーをセカンダリ・サーバーに指定します。
「接続数」ボックスで、WebPassインスタンスによりこのCOREidサーバーに対してオープンする接続の最大数を指定します（最小は1）。
「追加」をクリックしてこのCOREidサーバーをWebPassに関連付けます。
次の「マスターCOREidサーバー・インスタンスのインストール」に進みます。
システム・コンソールで新しいインスタンスを定義した後、以前のCOREidサーバーのインストーラを使用してこの手順を実行する必要があります。
このインストール時に、システム・コンソールで指定したホストでこのインスタンスをインストールする必要があります。また、これがこのディレクトリ・サーバーに対する最初のCOREidサーバーではないことを示す必要があります。
|
注意: このコンポーネントのインストール時には、スキーマまたはデータを更新しないでください。ここでは、説明を明確にするために、画面に表示される以前の用語を使用します。 |
この手順では、このタスクの実行ステップを簡略化しています。詳細は、以前のOblix NetPointまたはOracle COREidのインストレーション・ガイドを参照してください。
スキーマおよびデータのアップグレード用に以前のアイデンティティ・サーバーをインストールする手順
以前にインストールしたアイデンティティ・システム言語パックを、以前のCOREidサーバーのインストーラと同じディレクトリに移動します。
製品構成ファイルを変更するための管理者権限があるユーザーとしてログインし、通常どおりに以前のCOREidサーバーのインストーラを起動します。次に例を示します。
このコンポーネントの新しいインストール・ディレクトリを指定します。
このCOREidサーバーに対してシステム・コンソールで指定したものと同じトランスポート・セキュリティ・モードを選択します。
COREidシステム・コンソールに追加した情報に基づいてこのインスタンスの構成パラメータを指定します。次に例を示します。
名前: このアイデンティティ・サーバーの一意の名前を入力します。たとえば、COREidServer_611_6047のようにします。
ホスト名: システム・コンソールで指定された、このインスタンスがインストールされるコンピュータのDNSホスト名を入力します。
ポート: システム・コンソールで指定された、このCOREidサーバーがクライアントと通信するポート番号を入力します。
このインスタンスのディレクトリ・サーバー詳細を指定します（これにより、元の読取り/書込み用のマスター・ディレクトリ・サーバー・インスタンスのセカンダリ・サーバーとしてインストールされるようにします）。次に例を示します。
これがディレクトリ・サーバーにインストールされる最初のCOREidサーバーかどうかについて指定を求められた場合、「いいえ」を選択します。
このCOREidサーバーとディレクトリ・サーバー間に適した通信オプション（SSL対応の有無）の横にあるボックスを選択します。
以前に選択したモードに従って、「トランスポート・セキュリティ」ダイアログを完了します。
ユーザーの環境を説明するオプションを選択します。たとえば、構成データはユーザー・データ・ディレクトリ内に存在など、使用している環境に適したオプションを選択します。
スキーマを更新するかどうかの指定を求められた場合、「いいえ」を選択します。
|
注意: このインストール時には、スキーマまたはデータを更新しないでください。 |
通常どおりにインストールを終了します。
COREidサーバー・サービスを起動して、インスタンスが正常にインストールされて稼働していることを確認します。
次の「マスターWebPassのインストール」に進みます。
マスターCOREidサーバー・インスタンスをインストールした後、システム・コンソールで定義したマスターWebPassをインストールする必要があります。
必要に応じて、以前にインストールしたアイデンティティ・システム言語パックを、以前のWebPassインストーラと同じディレクトリに移動します。
製品およびWebサーバー構成ファイルを変更するための管理者権限があるユーザーとしてログインし、以前のWebPassインストーラを起動します。
「ようこそ」画面を閉じます。次に、プラットフォーム固有の管理者確認画面に応答します。
インストール・ディレクトリを選択します。次に例を示します。
\OracleAccessManager\Webcomponent
言語: 選択するよう求められた場合、インストールする管理者の言語および他のロケールに使用するデフォルト・ロケールを選択してから、次に進みます。
アイデンティティ・サーバーに選択したものと同じトランスポート・セキュリティ・モードをWebPassに対して選択します。
このWebPassの一意の情報を入力します。
名前: このWebPassの一意の名前（WebPass_611_ABC）
ホスト名: このWebPassが通信するCOREidサーバーのDNSのホスト名（Identity_DNS_hostname）
ポート: このWebPassが通信するCOREidサーバーのポート番号（Identity_port）
以前の仕様に基づいてトランスポート・セキュリティの詳細を入力します。
指示どおりにWebサーバーの構成ファイルを自動的に更新します。
必要に応じて、Webサーバーの権限を確認します。
次のように、アイデンティティ・サーバーとの通信を確立します。
WebPassのWebサーバー・インスタンスを停止します。
アイデンティティ・サーバー・サービスを停止して再起動します。
WebPassのWebサーバー・インスタンスを開始します。
追加のCOREidサーバーおよびWebPassをインストールした後、元の読取り/書込み用のマスター・ディレクトリ・サーバー・インスタンスに対してこれらを設定する必要があります。
スキーマおよびデータのアップグレード用にマスター・アイデンティティ・システムを設定する手順
まだ停止していない場合は、すべてのCOREidサーバー・サービスを停止します。
新しいCOREidサーバー・サービスのみを起動します。
通常どおり、COREidシステム・コンソールに移動します。次に例を示します。
「セットアップ」ボタンをクリックします。
|
注意: スキーマをLDAPサーバーにアップロードするよう求められる場合があります。しかし、このステップはすでに実行されているため、この作業は必要ありません。 |
次のようにディレクトリ情報を指定します。
既存のユーザー・データのディレクトリ・サーバーのタイプを指定します。たとえば、Sunなどです。
インストールに従って既存のユーザー・データのディレクトリ・サーバー詳細を指定します。次に例を示します。
ユーザー・データおよび構成データの場所を指定するよう求める新しいページ上で、使用する構成バインドDNおよびユーザー・データ検索ベースを入力します。次に例を示します。
|
注意: インスタンスをセカンダリCOREidサーバーとして設定する場合、Personオブジェクト・クラスまたはGroupオブジェクト・クラスの詳細は求められません。かわりに、ユーザー・データおよび構成データの場所を指定した後、「完了」ボタンがあるCOREidの設定の完了ページが表示されます。 |
COREidの設定の完了ページで、「完了」をクリックします。
付録Fの説明に従って、マスター・アイデンティティ・サーバーおよびWebPassの詳細の概要を作成します。
環境に応じて次に進みます。使用環境に既存のアクセス・システムがある場合は、最初の作業を実行します。
既存のアクセス・システム: 次の「インプレース・メソッドのマスターとして使用するための以前のAccess Managerの追加」のアクティビティを実行します。
アイデンティティ・システムのみ: インプレース・アップグレード・メソッドのアイデンティティ・システムのスキーマとデータのアップグレードの詳細を示す第6章に進みます。
このタスクを実行する必要があるのは、既存のインストールにアクセス・システムが含まれる場合のみです。元の読取り/書込み用のマスター・ディレクトリ・サーバー・インスタンスのセカンダリ・サーバーとしてマスターAccess Manager（現在のポリシー・マネージャ）を作成します。この新しいインスタンスは、後でアクセス・システムのスキーマおよびデータをアップグレードするときに使用します。
|
注意: アップグレードの際にプラットフォームをSolarisからLinuxに切り替える場合は、このステップを省略してください。Linuxホストにインストールする10g（10.1.4.0.1）Access Managerインスタンスは、同じ目的で機能します。アップグレードの際にプラットフォームをSolarisからLinuxに切り替える方法の詳細は、付録Bを参照してください。 |
このマスターを使用して、既存のアクセス・システムのスキーマとデータをアップグレードします。別のアクセス・サーバーやWebGateを関連付けたり、インストールしたりする必要はありません。
元のAccess Managerコンポーネントが、ディレクトリ・サーバーに対してSSL対応の通信を使用するように構成されている場合、追加するマスターもそのディレクトリ・サーバーに対してSSL対応の通信を使用するよう構成する必要があります。
この章の手順以外に、以前のバージョンのOblix NetPointまたはOracle COREidのアクセス管理ガイド（2巻で構成されている場合は第2巻）も参照してください。
タスクの概要: マスターとして使用するために以前のAccess Managerを追加する手順
|
注意: 以前のインストールにアクセス・システムが含まれていない場合は、この説明をスキップしてください。 |
作業を開始する前に、表5-3のタスクを完了していることを確認してください。前提条件が満たされていないと、アップグレードに悪影響が生じる場合があります。
表5-3 マスターAccess Managerインストールの前提条件
| マスターAccess Managerインストールの前提条件 |
|---|
|
「インプレース・メソッドのマスターとして使用するための以前のアイデンティティ・システムの追加」を含む、この章のすべての準備アクティビティが実行されており、次が実行されている。
|
|
第I部の各章の概要を確認している。 |
マスター・アイデンティティ・システム（以前のCOREidシステム）をインストールおよび設定した後、ポリシー・データのアップグレード用のマスターとして使用する以前のAccess Manager（現在のポリシー・マネージャ）インスタンスをインストールできます。
また、ここで示すステップは簡略化しています。詳細は、以前のOblix NetPointまたはOracle COREidのインストレーション・ガイドを参照してください。
|
注意: このインストール時には、スキーマまたはデータを更新しないでください。 |
スキーマおよびデータのアップグレード用に以前のAccess Managerをインストールする手順
必要に応じて、以前にインストールしたアクセス・システム言語パックを、以前のAccess Managerインストーラと同じディレクトリに移動します。
製品およびWebサーバー構成ファイルを変更するための管理者権限があるユーザーとしてログインし、以前のAccess Managerインストーラを起動します。
「ようこそ」画面を閉じます。次に、プラットフォームに固有の管理者確認画面に応答します。
WebPassと同じインストール・ディレクトリを選択します。次に例を示します。
\OracleAccessManager\Webcomponent
言語: 言語を選択するよう求められた場合、管理者の言語に使用するデフォルト・ロケール、およびインストールする他のロケール（言語）を選択してから、「次へ」をクリックします。
尋ねられたポリシー・データの格納場所を指定し、このインスタンスのディレクトリ・サーバー詳細を指定します。次に例を示します。
ディレクトリ・サーバーのタイプを選択します。
ポリシー・データの格納場所についての質問に応答します。
スキーマを更新するかどうかの指定を求められた場合、「いいえ」を選択します。
|
注意: このインストール時には、スキーマまたはデータを更新しないでください。 |
Solarisシステムでは、ポリシー・データが他のOracle Access Manager（以前のNetPointまたはCOREid）データと一緒に格納される場合、既存のディレクトリ・サーバーの通信方法について指定を求められます。
Windowsシステムでは、ポリシー・データが他のOracle Access Managerデータと一緒に格納される場合、ディレクトリ・サーバーとの通信について指定を求められます。
残りのアクセス・システムと通信するためにこのポリシー・マネージャが使用するトランスポート・セキュリティ・モードを指定します。
|
注意: トランスポート・セキュリティはすべてのアクセス・システム・コンポーネント間で一致している必要があります。つまり、すべてオープン・モード、すべて簡易モード、またはすべて証明書モードのいずれかになります。元のAccess Managerコンポーネントがディレクトリ・サーバーに対してSSL対応の通信を使用するように構成されている場合、このマスター・コンポーネントにSSLを選択してください。 |
このインスタンスのWebサーバー構成ファイルを自動的に更新し、Webサーバー構成ファイルへのパスを指定します（Sun Webサーバーを使用している場合、次に変更を適用します）。
ポリシー・マネージャのWebサーバー・インスタンスを停止し、アイデンティティ・サーバー・サービスを停止および再起動して、ポリシー・マネージャのWebサーバー・インスタンスを開始します。
通常どおりにインストールを終了し、Webサーバーの権限を確認し、次の「インプレース・メソッドのマスターAccess Managerの設定」に進みます。
追加した以前のAccess Managerは、元の読取り/書込み用のマスター・ディレクトリ・サーバー・インスタンスと通信できるよう設定する必要があります。次の手順は、この通信に必要な接続を確立する場合のガイドです。
設定中は、「次へ」ボタンをクリックするたびに仕様が保存されます。設定を中止して後で設定を再開すると、同じ場所に戻ります。
インプレース・メソッドのマスターAccess Managerの設定を開始する手順
Webサーバーが実行されていることを確認します。
ポリシー・マネージャに接続するWebPassインスタンスのURLを指定して、ブラウザからアクセス・システム・コンソールに移動します。次に例を示します。
http://hostname:port/access/oblix
ここで、hostnameはWebPassのWebサーバーをホストするコンピュータ、portはWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、\access\oblixはアクセス・システム・コンソールに接続します。
アクセス・システムのメイン・ページが表示されます。
「アクセス・システム・コンソール」リンクをクリックします。
アプリケーションがまだ設定されていないことが通知されます。
「セットアップ」ボタンをクリックします。
次のページでディレクトリ・サーバー・タイプについて指定します。
ユーザー・データ、構成データ、およびポリシー・データが現在格納されているディレクトリ・サーバーの詳細を指定する必要があります。各タイプのデータに対してディレクトリ・サーバーの情報を指定するよう求められます。
ユーザー・データのディレクトリ・サーバー・タイプを選択してから、「次へ」をクリックします。
インストールに従ってユーザー・データのディレクトリ・サーバー詳細を指定してから、「次へ」をクリックします。次に例を示します。
マシン: ユーザー・データのディレクトリ・サーバーのDNSホスト名
ポート番号: ユーザー・データのディレクトリ・サーバーのポート番号
ルートDN: ユーザー・データのディレクトリ・サーバーのバインドDN
ルート・パスワード: バインドDNのパスワード
|
注意: Active Directoryの場合、「ドメイン名」フィールドは、入力に含まれます。ADSIの場合、「ユーザー・プリンシパル名」フィールドは、ルートDNのUserPrincipleNameを入力する場所（admin@mycompany.comなど）に含まれます。 |
構成データのディレクトリ・サーバー・タイプを選択してから、「次へ」をクリックします。
次に、ユーザー・データおよび構成データを同じディレクトリまたは個別のディレクトリに格納できることが通知され、デプロイの構成を選択するよう求められます。
ユーザー・データおよび構成データが（一緒または個別に）格納される場所を記述する項目を選択してから、「次へ」をクリックします。
データが一緒に格納される場合、ポリシー・データの格納場所の指定を求められます。この場合は、ステップ5に進みます。
データが個別に格納される場合、作業を続行する前に、構成データのディレクトリ・サーバー詳細を指定するよう求められます。
ポリシー・データおよび構成データが（一緒または個別に）格納される場所を記述する項目を選択して、「次へ」をクリックします。
データが一緒に格納される場合、ステップ6に進みます。
データが個別に格納される場合、作業を続行する前に、ポリシー・データのディレクトリ・サーバー詳細を指定するよう求められます。
次のページで「セットアップ・ヘルプ」ボタンが表示されます。このボタンを選択して、設定プロセス中の追加情報を取得できます。ここで、構成DN、検索ベース、およびポリシー・ベースの場所を指定するよう求められます。
インストールに該当する情報を指定して、「次へ」をクリックします。具体的には次のとおりです。
これは、アイデンティティ・システム構成中に指定した検索ベースと同じである必要があります。
これは、アイデンティティ・システム構成中に指定した構成DNと同じである必要があります。
このノードは、ポリシー・ディレクトリ・サーバー内に存在します。このノードが存在していない場合、手動で作成します。
ここで、Personオブジェクト・クラスを指定するよう求められます。これは、アイデンティティ・システムの設定中に指定したものと一致する必要があります。詳細は、各自の準備の概要と『Oracle Access Managerインストレーション・ガイド』を参照してください。
Personオブジェクト・クラス名を入力して、「次へ」をクリックします。
次に例を示します。
この時点で、Webサーバーの再起動を求めるプロンプトが表示されます。
|
注意: IISを使用している場合、画面上の追加の指示に従います。net stop iisadminおよびnet start w3svcを使用してIISを停止および開始することを検討してください。netコマンドは、メタベースが破損しないようにするために役立ちます。 |
WebPass/Access ManagerのWebサーバー・インスタンスおよび関連するCOREidサーバー・インスタンスを停止および再起動し、「次へ」をクリックして続行します。
ここで、Oracle Access Managerポリシー・ドメインのルート・ディレクトリを指定するよう求められます。
ポリシー・ドメインを定義および保護するマスター管理者の機能を制限しない場合は、デフォルト値「/」を受け入れることをお薦めします。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
ポリシー・ドメインのデフォルトのルート・ディレクトリを受け入れ（または新規ルート・ディレクトリを指定して）、「次へ」をクリックします。次に例を示します。
次のページで認証スキームの構成の情報を指定します。
このAccess Managerの設定中に、2つの認証スキームが自動的に構成されます。また、ユーザー・ディレクトリの構成情報に基づき、基本およびクライアント証明書認証スキームを自動的に構成できます。
このAccess Managerに対して他の場合と同じ認証スキームを定義します。
同じポリシーを構成し、Oracle Access Manager（以前のNetPointまたはCOREid）関連のURLを保護します。
|
注意: このAccess Manager設定を使用して既存のアクセス・システムのスキーマおよびデータのアップグレードを計画するこのケースでは、別のアクセス・サーバーまたはWebGateの関連付けやインストールは必要ありません。 |
マスターAccess Managerコンポーネントの設定は、次のように終了します。
画面上の説明に従って設定プロセスを実行します。
付録Fの説明に従って、マスターAccess Managerの詳細の概要を作成します。
スキーマおよびデータのアップグレード時に使用するために追加したマスター・インスタンスに対して次のタスクを実行する必要があります。アップグレード用のコンポーネントの準備方法については、第8章の各項を参照してください。
タスクの概要: スキーマおよびデータのインプレース・アップグレードの準備の完了（次の項を参照）
リリース6.x環境での準備（必要な場合）
マルチ言語インストールの準備（必要な場合）
既存のコンポーネントのインストール・ディレクトリのバックアップ（マスター・コンポーネントに関する説明）
既存のWebサーバー構成ファイルのバックアップ（マスターWebコンポーネントに関する説明）
Windows: Windowsレジストリ・データのバックアップ（マスター・コンポーネントに関する説明、必要な場合）
すべての準備タスクが終了すると、第6章の説明に従って、アイデンティティ・システムのスキーマおよびデータをインプレース・アップグレードできるようになります。
