| Oracle Access Managerインストレーション・ガイド 10g（10.1.4.3） B55482-01 |
|
 戻る |
 次へ |
ここでは、新しいディレクトリ・サーバー・ホストを認識するようにOracle Access Managerを再構成する方法を説明します。次の項目について説明します。
Oracle Access Managerをインストールして設定した後で、Oracle Access Managerが通信するディレクトリ・サーバーのホスト・コンピュータを変更する場合があります。変更した場合は、新しいディレクトリ・サーバー・ホストを認識するようにOracle Access Managerを再構成する必要があります。
新しいディレクトリ・サーバー・インスタンス（別のホストに移されたインスタンス）と通信するためにOracle Access Managerを再構成するとき、停止時間が発生します。停止時間を最小限に抑えるには、Oracle Access Manager Webコンポーネントとアクセス・サーバーおよびアイデンティティ・サーバーのフェイルオーバーを構成します。
Oracle Access Managerはフェイルオーバーを利用して、本来のリクエスト先に障害がある場合に別のサーバーにリクエストをリダイレクトし、中断のないサービスを提供します。フェイルオーバーを実行するには、プライマリ・サーバーとセカンダリ・サーバーを構成し、フェイルオーバー・プロセスに関して特定のパラメータを指定します。Oracle Access Manager Webコンポーネントは、最初はプライマリ・サーバーにアクセスしようとします。プライマリ・サーバーが使用できない場合に、セカンダリ・サーバーへの接続が試行されます。
WebPassのリクエストは、セカンダリ・アイデンティティ・サーバーにリダイレクトされます。
WebGateのリクエストは、セカンダリ・アクセス・サーバーにリダイレクトされます。
タスクの概要: 停止時間の最短化
これらのタスクを実行すると、新しいディレクトリ・サーバー・インスタンスに対してプライマリ・アイデンティティ・サーバーおよびアクセス・サーバーを再構成したときに、ユーザーが中断のないサービスを利用できるようになります。
フェイルオーバーの詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
セカンダリ・アイデンティティ・サーバーを設定すると、新しいディレクトリ・サーバー・インスタンスとの通信のためにプライマリ・アイデンティティ・サーバーを停止して再構成するとき、WebPassがセカンダリ・アイデンティティ・サーバーにフェイルオーバーされます。
アイデンティティ・サーバーとWebPassのフェイルオーバーを構成する手順
次の要件を満たす2番目のアイデンティティ・サーバーがインストールされていることを確認します。
2番目のアイデンティティ・サーバーは、既存のディレクトリ・サーバーと通信する必要があります。
2番目のアイデンティティ・サーバーは、既存のWebPassにセカンダリ・サーバーとして関連付ける必要があります。
|
注意: Oracle Access Managerのインストールに、これらの条件を満たす2番目のアイデンティティ・サーバーが含まれない場合は、条件を満たすアイデンティティ・サーバーをインストールする必要があります。詳細は、「複数のアイデンティティ・サーバーのインストールの概要」を参照してください。 |
セカンダリ・アイデンティティ・サーバーとWebPassの間でフェイルオーバーを構成します。
アイデンティティ・システム・コンソールで、「システム構成」→「Webパス」→「名前」を選択し、「変更」をクリックします。
WebPassの構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
次の情報を入力して、変更内容を保存します。
フェイルオーバーしきい値: Webコンポーネントからプライマリ・アクセス・サーバーまたはアイデンティティ・サーバーに対して開く必要がある接続数を入力します。
アイデンティティ・サーバー・タイムアウトしきい値: Webコンポーネントが応答しないサーバーを待機する時間（秒）を指定する、タイムアウトしきい値を入力します。この時間を過ぎると、接続不可と判断して別のサーバーへのアクセスを試行します。
スリープ時間（秒）: 間隔を秒数で入力します。有効接続数が、構成された最大接続数と等しいかどうかをWebGateが確認する間隔です。
すべてのアイデンティティ・サーバーを使用するように、関連するディレクトリ・プロファイルを構成します。
「システム・コンソール」で、LDAPディレクトリ・サーバー・プロファイルのリストを探します。
アイデンティティ・システム・コンソールで「システム構成」を選択して「ディレクトリ・オプション」をクリックします。
「プロファイルの構成」ページが表示されます。ディレクトリ・サーバー情報の他に「LDAPディレクトリ・サーバー・プロファイルの構成」セクションと「RDBMSプロファイルの構成」セクションが含まれます。
「LDAPディレクトリ・サーバー・プロファイルの構成」見出しの下で、アイデンティティ・サーバー・プロファイルの名前を選択します。
LDAPディレクトリ・サーバー・プロファイルの構成
<名前>
「ディレクトリ・サーバー・プロファイルの変更」ページ
「ディレクトリ・サーバー・プロファイルの変更」ページの「使用」フィールドで「すべてのアイデンティティ・サーバー」を選択します。
変更を保存します。
次の「アクセス・サーバーとWebGateのフェイルオーバーの構成」に進みます。
アイデンティティ・サーバーの場合と同じく、セカンダリ・アクセス・サーバーを設定すると、新しいディレクトリ・サーバー・インスタンスとの通信のためにプライマリ・アクセス・サーバーを停止して再構成するときに、WebGateがセカンダリ・アクセス・サーバーにフェイルオーバーされます。
アクセス・サーバーとWebGateのフェイルオーバーを構成する手順
次の要件を満たす2番目のアクセス・サーバーがインストールされていることを確認します。
2番目のアクセス・サーバーは、Oracle Access Managerの構成データとポリシー・データを含む既存のディレクトリ・サーバーと通信する必要があります。
2番目のアクセス・サーバーは、既存のWebGateにセカンダリ・サーバーとして関連付ける必要があります。
|
注意: Oracle Access Managerのインストールに、これらの条件を満たす2番目のアクセス・サーバーが含まれない場合は、条件を満たすアクセス・サーバーをインストールする必要があります。詳細は、「複数のアクセス・サーバーのインストールの概要」を参照してください。 |
『Oracle Access Managerデプロイメント・ガイド』の説明に従って、次のようにセカンダリ・アクセス・サーバーとWebGateのフェイルオーバーを構成します。
アクセス・システム・コンソールで、「アクセス・システム構成」→「AccessGate構成」→「すべて」→「実行」を選択し、該当する名前をクリックします。
「AccessGateの詳細」ページが表示されます。WebGateの構成の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
「変更」ボタンをクリックし、次の情報を入力して変更内容を保存します。
フェイルオーバーしきい値: WebコンポーネントからプライマリOracle Access Managerサーバーに対して開く必要がある接続数を入力します。
アクセス・サーバー・タイムアウトしきい値: Webコンポーネントが応答しないOracle Access Managerサーバーを待機する時間（秒）を入力します。この時間を過ぎると、接続不可と判断して別のサーバーへのアクセスを試行します。
スリープ時間（秒）: 間隔を秒数で入力します。有効接続数が、構成された最大接続数と等しいかどうかをWebGateが確認する間隔です。
すべてのアクセス・サーバーを使用するように、関連するディレクトリ・サーバー・プロファイルを構成します。
アクセス・システム・コンソールで、LDAPディレクトリ・サーバー・プロファイルのリストを探します。
「アクセス・システム・コンソール」→「システム構成」→「サーバー設定」
「サーバー設定の表示」ページが表示されます。ディレクトリ・サーバー情報の他に「LDAPディレクトリ・サーバー・プロファイルの構成」セクションと「RDBMSプロファイルの構成」セクションが含まれます。
「LDAPディレクトリ・サーバー・プロファイルの構成」見出しの下で、アクセス・サーバー・プロファイルの名前を選択します。
LDAPディレクトリ・サーバー・プロファイルの構成
<名前>
「ディレクトリ・サーバー・プロファイルの変更」ページの「使用」フィールドで「アクセス・サーバー」の横のボタンを選択し、リストから「すべてのサーバー」を選択します。次に例を示します。
Used By o All components
o Identity Servers
o Access servers
All Servers
変更を保存します。
次の「新しいディレクトリ・サーバー・インスタンスの準備」に進みます。
新しいディレクトリ・サーバー・インスタンスが、Oracle Access Managerが通信するディレクトリ・サーバー・インスタンスの正確なレプリカであることを確認してください。つまり、スキーマ、ユーザー・データ、Oracle Access Manager構成データおよびポリシー・データが一致する必要があります。さらに、次の要件があります。
既存のディレクトリ・サーバー・インスタンスにいずれかのデータが個別に格納されている場合、新しいディレクトリ・サーバー・インスタンスはその構成と一致する必要があります。
既存のディレクトリ・サーバーがSSLを使用している場合、新しいディレクトリ・サーバーには、既存のディレクトリ・サーバーに証明書を発行したのと同じルートCAが発行した証明書が必要です。
新しいディレクトリ・サーバー・インスタンスを準備するときは、次の点によく注意してください。
ポリシー・データが構成データとは別のディレクトリ・サーバーに格納されている場合（o=oblix）、ポリシー・データのLDIFをエクスポートしてからインポートすることも必要です。
NetPoint 6.5以上を使用している場合、obcontainerId=DBAgents,<Configuration DN>…の下のエントリ（ポリシー・マネージャとアクセス・サーバーに関連付けられている）を削除する必要があります。
|
注意: DBエージェントのエントリを削除するとき、コンテナ（obcontainerId=DBAgents）は削除しないでください。 |
新しいディレクトリ・サーバー・インスタンスを準備する手順
次に示すldapsearchコマンドを使用して、Oracle Access Managerの元の構成ツリー（o=oblix）を既存のディレクトリ・サーバー・インスタンスからLDIFファイルにエクスポートします。ポリシー・データが別に格納されている場合は、ポリシー・データについても同じ操作を繰り返します。次に例を示します。
|
注意: Oracle Internet DirectoryのLDAPツールは、環境変数LDAP_PASSWORD_PROMPTONLYをTRUE（または1）に設定すると、セキュリティの低いオプション-w passwordおよび-P passwordが無効になるように変更されました。-q（または-Q）を使用する場合、ユーザー・パスワード（またはウォレット・パスワード）が求められます。可能であれば必ずこの環境変数を設定することをお薦めします。 |
ldapsearch -h DS_hostname -p DS_port_number -b Configuration_DN (o=oblix...)
-D bind_dn -q -s sub (objectClass=*) > Oblix_Data_original.ldif
Please enter bind password:
bind successful
DS_hostnameは新しいディレクトリ・サーバー・インスタンスのホスト・コンピュータ名（データのエクスポート元）、DS_port_numberはディレクトリ・サーバーがリスニングしているポート、bind_dnはOracle Access ManagerのDN、passwordはバインドDNのパスワード、Oblix_Data_original.ldifは構成データのldifファイルの名前です。
コンテナ（obcontainerId=DBAgents）は削除せずにDBエージェントのエントリを削除します。次に例を示します。
obcontainerId=DBAgents,<Configuration DN>…
次に示すldapmodifyコマンドを使用し、変更したLDIFを新しいディレクトリ・サーバー・インスタンスにインポートします。次に例を示します。
ldapmodify -h DS_hostname -p DS_port_number -D bind_dn -q -a -f
Oblix_Data_modified.ldif
Please enter bind password:
bind successful
DS_hostnameは新しいディレクトリ・サーバー・インスタンスのホスト・コンピュータ名（データのインポート先）、DS_port_numberはディレクトリ・サーバーがリスニングしているポート、bind_dnはOracle Access Manager構成データのDN、passwordはバインドDNのパスワード、Oblix_Data_modified.ldifは構成データのldifファイルの名前です。
「プライマリ・アイデンティティ・サーバーの再構成」に進み、新しいディレクトリ・サーバー・インスタンスのディレクトリ・サーバー・プロファイルをアイデンティティ・システム・コンソールに追加します。
次の手順では、プライマリ・アイデンティティ・サーバー（既存のディレクトリ・サーバー・インスタンスと通信している）が新しいディレクトリ・サーバー・インスタンスと通信するように、再構成する方法を説明します。
新しいディレクトリ・サーバー・インスタンスと通信するようにアイデンティティ・サーバーを構成する手順
アイデンティティ・システム・コンソールで「システム構成」→「ディレクトリ・プロファイル」を選択し、「ディレクトリ・サーバー」をクリックします。
「ディレクトリ・サーバー構成」ページで、新しいディレクトリ・サーバー・インスタンスを反映するように次の情報を変更し、変更内容を保存します。
マシン* : new_hostname.domain.com
ポート番号* : new_host_port
アスタリスク（*）が付いたフィールドを変更した場合は、アイデンティティ・システムの設定を手動で再実行する必要があります。
セカンダリ・サーバーを除くすべてのアイデンティティ・サーバーを停止します（複数のサーバーが実行している場合）。
実行している1つのアイデンティティ・サーバー・ホストで、setup.xmlファイルを開きます。
IdentityServer_install_dir\identity\oblix\config\setup.xml
statusパラメータを削除し（または、statusパラメータの値を"done"から"incomplete"に変更し）、ファイルを保存します。次に例を示します。
<NameValPair ParamName="status" Value="incomplete"></NameValPair>
このアイデンティティ・サーバーを再起動します。
Webブラウザでアイデンティティ・システム・コンソールを起動します。
アイデンティティ・システムの初期設定のページと似ている「セットアップ」ページが表示されます。
「セットアップ」ボタンをクリックして、設定プロセスを進めます。
次のように新しいディレクトリ・サーバー・インスタンスの情報を指定します。
ホスト: 新しいユーザー・データ・ディレクトリ・サーバーのDNSホスト名
ポート番号: 新しいユーザー・データ・ディレクトリ・サーバーのポート番号
|
注意: ユーザー・データが構成データとは別に格納されている場合、同様のページが表示されます。そこで構成データ・ディレクトリの情報を入力します。ただし、その手順についてはここでは省略します。 |
第6章「アイデンティティ・システムの設定」の説明に従って設定を完了します。
新しい情報を反映するようにアイデンティティ・サーバーを再起動します。
「システム・コンソール」で、新しいデータベース・プロファイルが作成されたことを確認します。
「ディレクトリ・プロファイル」ページにナビゲートします。
アイデンティティ・システム・コンソールで「システム構成」を選択して「ディレクトリ・プロファイル」をクリックします。
「プロファイルの構成」ページの「LDAPディレクトリ・サーバー・プロファイルの構成」見出しの下で、関連するプロファイル名を選択します。
「ディレクトリ・サーバー・プロファイルの変更」ページで、新しいデータベース・インスタンスの名前を探し、新しいコンピュータとポート番号を確認します。
|
注意: さらにDBプロファイルが必要であれば作成できます。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
次の「ポリシー・マネージャの再構成」に進みます。
新しいディレクトリ・サーバー・インスタンスを使用するようにポリシー・マネージャを再構成する必要があります。
新しいディレクトリ・サーバー・インスタンスに対してポリシー・マネージャを再構成する手順
次のようにアクセス・システム・コンソールでサーバー設定を表示します。
アクセス・システム・コンソールで「アクセス・システム構成」→「サーバー設定」を選択して「ディレクトリ・サーバー」をクリックします。
「ディレクトリ・サーバー構成」ページで、新しいディレクトリ・サーバー・インスタンスを反映するように次の情報を変更し、変更内容を保存します。
マシン* : new_hostname.domain.com
ポート番号* : new_host_port
アスタリスク（*）が付いたフィールドを変更した場合は、ポリシー・マネージャの設定を手動で再実行する必要があります。
1つを除きすべてのポリシー・マネージャWebサーバーを停止します（複数のサーバーが実行している場合）。
実行している1つのポリシー・マネージャ・ホストで、setup.xmlファイルを開きます。
PolicyManager_install\dir\oblix\config\setup.xml
statusパラメータを削除し（または、statusパラメータの値を"done"から"incomplete"に変更し）、ファイルを保存します。次に例を示します。
<NameValPair ParamName="status" Value="incomplete"></NameValPair>
ポリシー・マネージャWebサーバーを再起動します。
Webブラウザでアクセス・システム・コンソールを起動します。
アクセス・システムの初期設定時に表示されるのと似ている「セットアップ」ページが表示されます。ユーザー・データ、構成データおよびポリシー・データが格納されているディレクトリ・サーバーの詳細を指定する必要があります。また、各データ・タイプのディレクトリ・サーバーの情報を指定することを求められます。
「セットアップ」を再び起動し、求められたら次の情報を指定します。
ユーザー・データと構成データが一緒に格納されている場合は、ポリシー・データを格納する場所を指定するように求められます。
データが個別に格納されている場合は、構成データの詳細を指定するように求められます。
この詳細は、「データ記憶域の要件」を参照してください。
求められたら、次のように新しいディレクトリ・サーバー・インスタンスの情報を指定します。
次のように新しいディレクトリ・サーバー・インスタンスの情報を指定します。
ホスト: 新しいディレクトリ・サーバーのDNSホスト名
ポート番号: 新しいディレクトリ・サーバーのポート番号
|
注意: データの格納方法によっては、ポリシー・データのために別の画面が表示されることがあります。ただし、その手順についてはここでは省略します。 |
「ポリシー・マネージャの設定」の説明に従って設定を完了します。
設定が完了したら、他のポリシー・マネージャWebサーバーを再起動します。
他のポリシー・マネージャに新しい情報が反映されます。
次のようにアクセス・システム・コンソールで新しいデータベース・インスタンスを確認します。
次のようにアクセス・システム・コンソールでサーバー設定を表示します。
アクセス・システム・コンソールで「アクセス・システム構成」→「サーバー設定」を選択します。
「サーバー設定の表示」ページの「LDAPディレクトリ・サーバー・プロファイルの構成」見出しの下で、関連するプロファイル名を選択します。
「ディレクトリ・サーバー・プロファイルの変更」ページで、新しいデータベース・インスタンスの名前を探し、新しいコンピュータとポート番号を確認します。
|
注意: さらにDBプロファイルが必要であれば作成できます。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
「アクセス・サーバーの再構成」の説明に従ってアクセス・サーバーの設定を再実行します。
ポリシー・マネージャの設定を手動で再実行したら、次に示すようにアクセス・サーバーを再構成する必要があります。configureAAAServerツールの使用方法の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
新しいディレクトリ・サーバー・インスタンスに対してアクセス・サーバーを再構成する手順
configureAAAServerツールを探します。次に例を示します。
AccessServer_install_dir\access\oblix\tools\configureAAAServer
configureAAAServerツールで次のコマンドを使用してアクセス・サーバーを設定します。次に例を示します。
configureAAAServer install -i AccessServer_install_dir/util/access
新しいディレクトリ・サーバー・インスタンスが存在するホストの新しい情報を指定します。
アクセス・サーバーを再起動します。
次のようにアクセス・システム・コンソールで新しいデータベース・インスタンスを確認します。
次のようにアクセス・システム・コンソールでサーバー設定を表示します。
「アクセス・システム・コンソール」→「システム構成」→「サーバー設定」
「サーバー設定の表示」ページの「LDAPディレクトリ・サーバー・プロファイルの構成」見出しの下で、関連するプロファイル名を選択します。
「ディレクトリ・サーバー・プロファイルの変更」ページで、新しいデータベース・インスタンスの名前を探し、新しいコンピュータとポート番号を確認します。
デフォルトの他にもう1つのデータベース・プロファイルが作成されていることがあります。ポリシー・ツリーと構成ツリーが同じディレクトリ・サーバーにあるが、それぞれの接尾辞が異なる場合です。
|
注意: さらにDBプロファイルが必要であれば作成できます。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
