Oracle® Fusion Middleware

Oracle Identity Managementエンタープライズ・デプロイメント・ガイド

11gリリース2 (11.1.2.1)

B71694-06(原本部品番号:E40782-03)

2013年9月

このドキュメントは、システム管理者を対象に、Oracle Fusion Middlewareのエンタープライズ・デプロイメントにおける、Oracle Identity Managementコンポーネントのインストールおよび構成方法について説明しています。

Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド, 11gリリース2 (11.1.2.1)

B71694-06

Copyright © 2004, 2013, Oracle and/or its affiliates.   All rights reserved.

原本主著者: Ellen Desmond(ライター)、Janga Aliminati(設計者)、Michael Rhys(協力エンジニア)

原本協力者: Christelle Balon、Pradeep Bhat、Bruce Jiang、Louise Luo, Xiao Lin

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、他社の商標の可能性があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

図一覧

表一覧

タイトルと著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- 11g リリース2 (11.1.2.1)の新機能と変更機能

1 エンタープライズ・デプロイメント概要

- 1.1 エンタープライズ・デプロイメント・ガイドについて

- 1.2 エンタープライズ・デプロイメント・ガイドの規則

- 1.3 エンタープライズ・デプロイメントの用語

- 1.4 Oracle推奨事項のメリット

- 1.4.1 組込みセキュリティ

- 1.4.2 高可用性

2 導入と計画

- 2.1 デプロイメントの計画

- 2.1.1 デプロイメント・トポロジ

- 2.1.1.1 シングル・ドメイン・トポロジ

- 2.1.1.2 分割ドメイン・トポロジ

- 2.1.1.3 3つのドメイン・トポロジ

- 2.1.2 使用するトポロジ

- 2.1.2.1 シングル・ドメイン・トポロジ

- 2.1.2.2 分割ドメイン・トポロジ

- 2.1.2.3 3つのドメイン・トポロジ

- 2.1.2.4 まとめ

- 2.2 トポロジについて

- 2.2.1 Web層について

- 2.2.1.1 アーキテクチャに関する注意

- 2.2.1.2 高可用性プロビジョニング

- 2.2.1.3 セキュリティ・プロビジョニング

- 2.2.2 アプリケーション層について

- 2.2.2.1 WebLogicドメインについて

- 2.2.2.2 LDAPディレクトリについて

- 2.2.2.2.1 Oracle Unified Directoryについて

- 2.2.2.2.2 Oracle Internet DirectoryおよびOracle Virtual Directoryについて

- 2.2.2.2.3 高可用性プロビジョニング

- 2.2.2.3 アーキテクチャに関する注意

- 2.2.2.4 高可用性プロビジョニング

- 2.2.2.5 セキュリティ・プロビジョニング

- 2.2.3 オプションのディレクトリ層について

- 2.2.4 データベース層について

- 2.3 エンタープライズ・デプロイメントのハードウェア要件

- 2.4 エンタープライズ・デプロイメントのソフトウェア・コンポーネント

- 2.4.1 ソフトウェアのバージョン

- 2.4.2 ソフトウェアの入手について

- 2.4.3 Oracleホームのまとめ

- 2.4.4 ソフトウェアのインストールについて

- 2.4.5 パッチおよび回避策の適用

- 2.5 参照用トポロジのインストールおよび構成のロード・マップ

- 2.5.1 Oracle Identity Managementエンタープライズ・デプロイメント処理のフロー・チャート

- 2.5.2 Oracle Identity Managementエンタープライズ・デプロイメント処理の手順

3 エンタープライズ・デプロイメント用のネットワークの準備

- 3.1 エンタープライズ・デプロイメント用のネットワークの準備の概要

- 3.2 ネットワークの計画

- 3.3 トポロジで使用する仮想サーバー名について

- 3.3.1 仮想ホスト名

- 3.3.2 仮想サーバー名

- 3.3.2.1 IDSTORE.mycompany.com

- 3.3.2.2 ADMIN.mycompany.com

- 3.3.2.3 IDMINTERNAL.mycompany.com

- 3.3.2.4 SSO.mycompany.com

- 3.4 ロード・バランサの構成

- 3.4.1 ロード・バランサの要件

- 3.4.2 ロード・バランサの構成手順

- 3.4.3 ロード・バランサの構成

- 3.5 IPアドレスおよび仮想IPアドレスについて

- 3.6 ファイアウォールとポートについて

- 3.7 Access Manager通信プロトコルの管理

- 3.7.1 Access Managerプロトコル

- 3.7.2 統合リクエストの概要

- 3.7.3 ユーザー・リクエストの概要

- 3.7.4 通信のユニキャスト要件について

4 エンタープライズ・デプロイメント用の記憶域の準備

- 4.1 エンタープライズ・デプロイメント用の記憶域の準備の概要

- 4.2 ディレクトリとディレクトリ変数の用語

- 4.3 ファイル・システムについて

- 4.4 各種ディレクトリの推奨場所について

- 4.4.1 バイナリ(Middlewareホーム)ディレクトリの推奨事項

- 4.4.1.1 バイナリ(Middlewareホーム)ディレクトリについて

- 4.4.1.2 複数のドメイン用の単一のMiddlewareホームの共有について

- 4.4.1.3 冗長バイナリ(Middlewareホーム)ディレクトリの使用について

- 4.4.2 ドメイン構成ファイルの推奨事項

- 4.4.2.1 Oracle WebLogic Server管理サーバーおよび管理対象サーバーのドメイン構成ファイルについて

- 4.4.2.2 管理サーバーのドメイン構成ファイル用の共有記憶域の要件

- 4.4.2.3 管理対象サーバー・ドメイン構成ファイルに対するローカル記憶域の要件

- 4.4.3 JMSファイル・ストアとトランザクション・ログ用の共有記憶域に関する推奨事項

- 4.4.4 ディレクトリの推奨場所

- 4.4.4.1 共有記憶域

- 4.4.4.2 ローカル記憶域

5 エンタープライズ・デプロイメント用のサーバーの準備

- 5.1 サーバーの準備の概要

- 5.2 サーバーおよびオペレーティング・システムの検証

- 5.3 最小ハードウェア要件の達成

- 5.4 オペレーティング・システム要件の達成

- 5.4.1 UNIXおよびLinuxの要件の達成

- 5.4.1.1 カーネル・パラメータの構成

- 5.4.1.2 オープン・ファイル制限の設定

- 5.4.1.3 シェル制限の設定

- 5.4.1.4 ローカルHostsファイルの構成

- 5.5 Unicodeサポートの有効化

- 5.6 仮想IPアドレスの有効化

- 5.6.1 有効化する仮想IPアドレス

- 5.6.2 コマンドラインを使用した仮想アドレスの有効化

- 5.7 共有記憶域のホストへのマウント

- 5.8 ユーザーおよびグループの構成

- 5.9 複数のネットワーク・アドレスを持つサーバーへのOracleソフトウェアのインストール

6 エンタープライズ・デプロイメント用のデータベースの準備

- 6.1 Identity Managementエンタープライズ・デプロイメント用のデータベースの準備の概要

- 6.2 エンタープライズ・デプロイメントのデータベース要件の検証

- 6.2.1 必要なデータベース

- 6.2.2 データベース・ホストの要件

- 6.2.3 サポートされるデータベース・バージョン

- 6.2.4 Oracle Databaseのパッチ適用

- 6.2.4.1 Oracle Database 11g (11.1.0.7)のパッチ要件

- 6.2.4.2 Oracle Database 11g (11.2.0.2.0)のパッチ要件

- 6.2.5 初期化パラメータについて

- 6.3 エンタープライズ・デプロイメント用のデータベースのインストール

- 6.4 データベース・サービスの作成

- 6.4.1 10.xおよび11.1.xデータベース用のデータベース・サービスの作成

- 6.4.2 11.2.xデータベース用のデータベース・サービスの作成

- 6.4.3 データベースのチューニング

- 6.5 リポジトリ作成ユーティリティ(RCU)用のデータベースの準備

- 6.6 RCUを使用したOracle RAC DatabaseへのIdentity Managementスキーマのロード

- 6.7 データベースのバックアップ

7 Oracle Unified Directoryのインストールおよび構成

- 7.1 Oracle Unified Directoryのインストールおよび構成の概要

- 7.2 Oracle Unified Directoryインスタンスを構成するための前提条件

- 7.3 Oracle Unified Directoryのインストール

- 7.4 Oracle Unified Directoryインスタンスの構成

- 7.4.1 IDMHOST1でのOracle Unified Directoryの構成

- 7.4.2 IDMHOST1でのOracle Unified Directoryの検証

- 7.4.3 IDMHOST2での追加のOracle Unified Directoryインスタンスの構成

- 7.4.4 IDMHOST2でのOracle Unified Directoryの検証

- 7.4.5 Oracle Unified Directory保証レプリケーションの有効化

- 7.4.6 Oracle Unified Directoryオブジェクト作成制限の緩和

- 7.4.7 ロード・バランサを使用したOracle Unified Directoryの検証

- 7.5 Oracle Unified Directoryのインストールのバックアップ

8 エンタープライズ・デプロイメント用のドメインの作成

- 8.1 ドメイン作成の概要

- 8.2 Oracle Fusion Middlewareホームのインストール

- 8.2.1 Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成

- 8.2.1.1 JRockitのインストール

- 8.2.1.2 汎用インストーラを使用したWebLogic Serverのインストール

- 8.2.2 Oracle IdentityおよびAccess Managementのインストール

- 8.2.3 Oracle SOA Suiteのインストール

- 8.3 コンソールURLおよびドメインについて

- 8.4 構成ウィザードを実行してドメインを作成する方法

- 8.5 構成後タスクおよび検証タスク

- 8.5.1 OIMアダプタ・テンプレートのコピー

- 8.5.2 WebLogic管理サーバーのboot.propertiesの作成

- 8.5.3 ドメインと既存のOPSSポリシー・ストアの再関連付け

- 8.5.4 ノード・マネージャの起動

- 8.5.5 ノード・マネージャ資格証明の更新

- 8.5.6 WebLogic管理サーバーの検証

- 8.5.7 WebLogicプラグインの有効化

- 8.5.8 Oracle WebLogic管理サーバーのホスト名検証の無効化

- 8.5.9 WebLogic管理サーバーの停止と起動

- 8.6 WebLogic管理サーバーの手動フェイルオーバーのテスト

- 8.7 WebLogicドメインのバックアップ

9 アイデンティティ・ストアの準備

- 9.1 アイデンティティ・ストアの準備の概要

- 9.2 LDAPディレクトリのバックアップ

- 9.3 前提条件

- 9.4 アイデンティティ・ストアの準備

- 9.4.1 アイデンティティ・ストアの準備の概要

- 9.4.2 構成ファイルの作成

- 9.4.3 Access ManagerおよびOracle Identity Manager用のディレクトリの準備

- 9.4.3.1 Access ManagerおよびOracle Identity Managerで使用するためのOracle Unified DirectoryおよびOracle Internet Directoryの構成

- 9.4.3.2 Access ManagerおよびOracle Identity Managerで使用するためのActive Directoryの構成

- 9.4.4 ユーザーとグループの作成

- 9.4.5 不足しているOracle Internet Directoryオブジェクト・クラスの追加

- 9.4.6 不足しているOracle Unified Directoryの権限の追加

- 9.4.7 Oracle Unified Directory変更ログのアクセス権の付与

- 9.4.8 Oracle Unified Directoryの索引の作成

- 9.4.9 Oracle Internet DirectoryおよびOracle Unified Directory以外のディレクトリへのアクセス制御リストの作成

- 9.5 Oracle Virtual Directoryにおけるアダプタの作成

- 9.5.1 変更ログ生成がOracle Internet Directoryで有効になっていることの確認

- 9.5.2 Oracle Internet DirectoryおよびActive Directoryに対するOracle Virtual Directoryアダプタの作成

- 9.5.3 Oracle Virtual Directoryアダプタの検証

- 9.6 アイデンティティ・ストアのバックアップ

10 エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成

- 10.1 Web層のインストールおよび構成の概要

- 10.2 Web層のインストールおよび構成

- 10.2.1 前提条件

- 10.2.2 JRockitのインストール

- 10.2.3 Oracle HTTP Serverのインストール

- 10.2.3.1 前提条件の検証

- 10.2.3.2 インストーラの実行

- 10.2.4 構成ウィザードによるHTTP Serverの構成

- 10.3 構成後のタスク

- 10.3.1 ソフトウェア所有者として実行するためのOracle HTTP Serverの構成

- 10.3.2 Oracle HTTP Serverのランタイム・パラメータの更新

- 10.3.3 Identity Managementをサポートするための仮想ホストの作成

- 10.3.3.1 仮想ホストのサポートの有効化

- 10.3.3.2 仮想ホストの定義の作成

- 10.3.3.2.1 ADMIN.mycompany.comの仮想ホストの作成

- 10.3.3.2.2 SSO.mycompany.comの仮想ホストの作成

- 10.3.3.2.3 IDMINTERNAL.mycompany.comの仮想ホストの作成

- 10.4 Oracle HTTP Serverの再起動

- 10.5 管理コンソール用フロントエンドURLの設定

- 10.6 構成の検証

- 10.7 Web層のURLのまとめ

- 10.8 Web層の構成のバックアップ

11 Oracle Access Managementを追加するためのドメインの拡張

- 11.1 Oracle Access Management Access Managerを追加するためのドメインの拡張の概要

- 11.2 ドメインのURLについて

- 11.3 様々なディレクトリ構成の使用方法

- 11.4 前提条件

- 11.5 Access Managerでのドメインの拡張

- 11.6 Access Managerの構成

- 11.6.1 IDMドメイン・エージェントの削除

- 11.6.2 グローバル・パスフレーズの設定

- 11.6.3 IDM構成ツールを使用したAccess Managerの構成

- 11.6.4 構成の検証

- 11.6.5 新規作成エージェントの更新

- 11.6.6 既存のWebゲート・エージェントの更新

- 11.6.7 バグ13824816の回避策の実行

- 11.7 Web層からのアクセスの構成

- 11.8 ローカル・ストレージへの管理対象サーバーの構成の展開

- 11.9 管理対象サーバーWLS_OAM1およびWLS_OAM2の起動

- 11.10 Access Managerの検証

- 11.11 Access Managerと他のコンポーネントを統合するための単一のキーストアの作成

- 11.12 Access Managerの構成のバックアップ

12 Oracle Identity Managerを追加するためのドメインの拡張

- 12.1 Oracle Identity Managerを追加するためのドメイン拡張の概要

- 12.2 ドメインのURLについて

- 12.3 前提条件

- 12.4 WebLogic Serverライブラリ・ディレクトリへのOIMログイン・モジュールのプロビジョニング

- 12.5 wlfullclient.jarファイルの作成

- 12.6 システム・クロックの同期

- 12.7 Oracle Identity ManagerおよびOracle SOA Suiteを構成するためのドメインの拡張

- 12.8 IDMHOST1およびIDMHOST2の管理対象サーバーのドメイン・ディレクトリへのOracle Identity ManagerおよびOracle SOAの展開

- 12.9 コンポジットをデプロイするためのOracle Coherenceの構成

- 12.9.1 ユニキャスト通信を使用したデプロイメントの通信の有効化

- 12.9.2 Oracle Coherenceで使用するホスト名の指定

- 12.10 Oracle Identity Managerの構成

- 12.11 SOAディレクトリのコピー

- 12.12 IDMHOST1およびIDMHOST2でのSOAおよびOracle Identity Managerの管理対象サーバーの起動

- 12.13 IDMHOST1およびIDMHOST2におけるOracle Identity Managerインスタンスの確認

- 12.14 IDストアから調整するためのOracle Identity Managerの構成

- 12.15 Oracle Web Tierと連携するためのOracle Identity Managerの構成

- 12.15.1 Oracle Identity ManagerおよびSOAの管理対象サーバーのフロント・エンドとして機能するためのOracle HTTP Serverの構成

- 12.15.2 WebLogicにおけるホスト・アサーションの変更

- 12.15.3 SOAエンドポイントの更新

- 12.15.4 Web層統合の検証

- 12.15.4.1 Web層からのOracle Identity Managerインスタンスの検証

- 12.15.4.2 Web層からSOAへのアクセスの検証

- 12.16 トランザクション・リカバリ用のデフォルト永続ストアの構成

- 12.17 UMSの電子メール通知の構成

- 12.18 SOAキーストアへのロード・バランサ証明書の追加

- 12.19 Oracle Identity Managerのリコンシリエーションからのユーザーの除外

- 12.19.1 ODSMを使用してユーザーにorclAppIDUserオブジェクト・クラスを追加

- 12.19.2 失敗したリコンシリエーション・イベントをOIMコンソールを使用して閉じる

- 12.20 LDAPでプロビジョニングした管理ユーザーを使用したOracle Identity ManagerからSOAへの接続の有効化

- 12.21 Active DirectoryをサポートするためのOracle Identity Managerの変更

- 12.21.1 Active Directoryのユーザー名生成ポリシーの更新

- 12.21.2 Active DirectoryをサポートするためのOracle Identity Managerのプロパティの変更

- 12.22 Oracle Identity Managerのバックアップ

- 12.23 Oracle Identity ManagerとOracle Access Management Access Managerの統合

- 12.23.1 前提条件

- 12.23.2 OAMログイン・ページへの「パスワードを忘れた場合」リンクの追加

- 12.23.3 IDMHOST1およびIDMHOST2へのOAMキーストア・ファイルのコピー

- 12.23.4 idmConfigToolを使用したOracle Identity ManagerとOracle Access Managerの統合

- 12.23.5 必須オブジェクト・クラスによる既存のLDAPユーザーの更新

- 12.23.6 TAP認証スキームの更新

- 12.23.7 xelsysadmユーザーのパスワードの管理

- 12.23.8 統合の検証

13 エンタープライズ・デプロイメント用のノード・マネージャの設定

- 13.1 ノード・マネージャの概要

- 13.2 ノード・マネージャのログの場所の変更

- 13.3 ノード・マネージャのホスト名検証証明書の有効化

- 13.3.1 utils.CertGenユーティリティを使用した自己署名証明書の作成

- 13.3.2 utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成

- 13.3.3 keytoolユーティリティを使用したトラスト・キーストアの作成

- 13.3.4 カスタム・キーストアを使用するためのノード・マネージャの構成

- 13.3.5 共通または共有記憶域インストールの使用

- 13.3.6 カスタム・キーストアを使用するための管理対象WebLogic Serverの構成

- 13.3.7 管理対象サーバーのホスト名検証設定の変更

- 13.4 ノード・マネージャの起動

14 エンタープライズ・デプロイメント用のサーバー移行の構成

- 14.1 エンタープライズ・デプロイメント用のサーバー移行の概要

- 14.2 サーバー移行leasing表のユーザーと表領域の設定

- 14.3 Oracle WebLogic管理コンソールを使用したLeasingのGridLinkデータ・ソースの作成

- 14.4 ノード・マネージャのプロパティ・ファイルの編集

- 14.5 wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定

- 14.6 サーバー移行ターゲットの構成

- 14.7 サーバー移行のテスト

- 14.8 サーバー移行構成のバックアップ

15 エンタープライズ・デプロイメントにおける管理コンソールのシングル・サインオンの構成

- 15.1 エンタープライズ・デプロイメントにおける管理コンソールのシングル・サインオンの構成の概要

- 15.2 前提条件

- 15.3 WebLogicセキュリティ・プロバイダの構成

- 15.3.1 Oracle Unified Directoryオーセンティケータの更新

- 15.3.2 セキュリティ・プロバイダの並び替え

- 15.4 WebLogic管理グループへのWLSAdminsグループの割当て

- 15.5 Access Manager管理者によるAPMコンソールへのアクセスの認可

- 15.6 boot.propertiesファイルの更新

- 15.6.1 すべてのドメインの管理サーバーの更新

- 15.6.2 サーバーの再起動

- 15.7 Webゲート11gのインストールと構成

- 15.7.1 前提条件

- 15.7.2 WEBHOST1およびWEBHOST2へのOracle WebGateのインストール

- 15.8 WebゲートおよびAccess Managerのシングル・サインオンのセットアップの検証

- 15.9 シングル・サインオンのバックアップ

16 分割ドメイン・トポロジの作成

- 16.1 分割ドメイン・トポロジの概要

- 16.2 ネットワークに関する追加要件

- 16.2.1 仮想サーバー名

- 16.2.2 ロード・バランサの構成

- 16.2.3 仮想IPアドレス

- 16.2.4 仮想IPアドレスおよび物理IPアドレスをリスニングするためのサーバー構成

- 16.2.5 ファイアウォールとポート

- 16.3 ファイル・システムの準備に関する追加要件

- 16.4 サーバーの準備に関する追加要件

- 16.5 追加ドメインの作成に関する要件

- 16.6 Web層に関する追加要件

- 16.7 Access Managerに関する追加要件

- 16.8 Oracle Identity Managerに関する追加要件

- 16.8.1 ドメインのURL

- 16.8.2 ログイン・モジュールのプロビジョニングとwlfullclient.jarの作成

- 16.8.3 Oracle Identity ManagerおよびOracle SOA Suiteを構成するためのドメインの拡張

- 16.8.4 Oracle Identity Managerの構成

- 16.8.5 Oracle Identity ManagerとOracle SOAの配置

- 16.8.6 Oracle Identity ManagerからSOAへの接続の有効化

- 16.8.7 Access ManagerとOracle Identity Managerの統合の構成

- 16.8.8 Oracle Identity Managerのバックアップ

- 16.9 シングル・サインオンに関する追加要件

- 16.10 ノード・マネージャに関する追加要件

- 16.11 管理に関する追加要件

- 16.11.1 パッチの適用

- 16.11.2 バックアップの実行

17 エンタープライズ・デプロイメント用のトポロジの管理

- 17.1 Oracle Identity Managementコンポーネントの起動と停止

- 17.1.1 起動順序

- 17.1.2 Oracle Unified Directoryの起動と停止

- 17.1.2.1 Oracle Unified Directoryの起動

- 17.1.2.2 Oracle Unified Directoryの停止

- 17.1.3 Access Managerの管理対象サーバーの起動、停止および再起動

- 17.1.3.1 Access Manager管理対象サーバーが1つも実行されていない場合の管理対象サーバーの起動

- 17.1.3.2 別のAccess Manager管理対象サーバーが実行されている場合の管理対象サーバーの起動

- 17.1.3.3 Access Manager管理対象サーバーの停止

- 17.1.3.4 Access Manager管理対象サーバーの再起動

- 17.1.4 WebLogic管理サーバーの起動、停止および再起動

- 17.1.4.1 WebLogic管理サーバーの起動

- 17.1.4.2 WebLogic管理サーバーの停止

- 17.1.4.3 WebLogic管理サーバーの再起動

- 17.1.5 ノード・マネージャの起動と停止

- 17.1.5.1 ノード・マネージャの起動

- 17.1.5.2 ノード・マネージャの停止

- 17.1.5.3 管理サーバーのノード・マネージャの起動

- 17.1.6 Oracle HTTP Serverの起動、停止および再起動

- 17.1.6.1 Oracle HTTP Serverの起動

- 17.1.6.2 Oracle HTTP Serverの停止

- 17.1.6.3 Oracle HTTP Serverの再起動

- 17.1.7 Oracle Identity Managerの起動、停止および再起動

- 17.1.7.1 Oracle Identity Managerの起動

- 17.1.7.2 Oracle Identity Managerの停止

- 17.1.7.3 Oracle Identity Managerの再起動

- 17.2 Identity ManagementコンソールのURLについて

- 17.3 エンタープライズ・デプロイメントの監視

- 17.3.1 WebLogic管理対象サーバーの監視

- 17.3.2 Oracle Unified Directoryの監視

- 17.4 エンタープライズ・デプロイメントのスケーリング

- 17.4.1 トポロジのスケール・アップ

- 17.4.1.1 Oracle Unified Directoryのスケール・アップ

- 17.4.1.2 Oracle Access Manager 11gのスケール・アップ

- 17.4.1.3 Oracle Identity Managerのスケール・アップ

- 17.4.1.4 Oracle HTTP Serverのスケール・アップ

- 17.4.2 トポロジのスケール・アウト

- 17.4.2.1 Oracle Unified Directoryのスケール・アウト

- 17.4.2.2 Oracle Access Manager 11gのスケール・アウト

- 17.4.2.3 Oracle Identity Managerのスケール・アウト

- 17.4.2.4 Oracle HTTP Serverのスケール・アウト

- 17.5 アイデンティティ管理の監査

- 17.6 バックアップとリカバリの実行

- 17.6.1 ベースライン・バックアップの実行

- 17.6.2 ランタイム・バックアップの実行

- 17.6.3 インストール時および構成時のバックアップの実行

- 17.6.3.1 ミドルウェア・ホームのバックアップ

- 17.6.3.2 LDAPディレクトリのバックアップ

- 17.6.3.2.1 Oracle Unified Directoryのバックアップ

- 17.6.3.2.2 Oracle Internet Directoryのバックアップ

- 17.6.3.2.3 Oracle Virtual Directoryのバックアップ

- 17.6.3.2.4 サード・パーティのディレクトリのバックアップ

- 17.6.3.3 データベースのバックアップ

- 17.6.3.4 WebLogicドメインのバックアップ

- 17.6.3.5 Web層のバックアップ

- 17.7 エンタープライズ・デプロイメントのパッチ適用

- 17.7.1 Oracle Fusion Middlewareソース・ファイルへのパッチ適用

- 17.7.2 Identity and Access Managementへのパッチ適用

- 17.7.3 Oracle Unified Directoryのコンポーネントへのパッチ適用

- 17.8 SQLのタイムアウトの防止

- 17.9 WebLogic管理サーバーの手動フェイルオーバー

- 17.9.1 IDMHOST2への管理サーバーのフェイルオーバー

- 17.9.2 IDMHOST2上での管理サーバーの起動

- 17.9.3 Oracle HTTP Serverを使用したIDMHOST2へのアクセスの検証

- 17.9.4 IDMHOST1への管理サーバーのフェイルバック

- 17.10 トラブルシューティング

- 17.10.1 Oracle Internet Directoryのトラブルシューティング

- 17.10.1.1 Oracle Internet Directoryサーバーが応答しない

- 17.10.1.2 SSO/LDAPアプリケーションの接続のタイムアウト

- 17.10.1.3 LDAPアプリケーションがLDAPエラー53を受け取る(DSAが動作しない)

- 17.10.1.4 TNSNAMES.ORA、TAF構成および関連する問題

- 17.10.2 Oracle Virtual Directoryのトラブルシューティング

- 17.10.2.1 SSLServerConfig.sh実行時のコマンドが見つからないエラー

- 17.10.2.2 Oracle Virtual Directoryが応答しない

- 17.10.2.3 SSO/LDAPアプリケーションの接続のタイムアウト

- 17.10.2.4 TNSNAMES.ORA、TAF構成および関連する問題

- 17.10.2.5 SSLServerConfig.shがエラーで失敗する

- 17.10.3 Access Manager 11gのトラブルシューティング

- 17.10.3.1 セッション数が最大許容値に達した

- 17.10.3.2 Oracle Access Managerを初めてインストールしたときにポリシーが作成されない

- 17.10.3.3 保護されたリソースにアクセスしても、資格証明を要求するメッセージが表示されない

- 17.10.3.4 OAMコンソールにログインできない

- 17.10.4 Oracle Identity Managerのトラブルシューティング

- 17.10.4.1 Oracle Identity Managerの構成実行時のjava.io.FileNotFoundException

- 17.10.4.2 Oracle Identity Managerでのユーザー作成時のResourceConnectionValidationxception

- 17.10.5 Oracle SOA Suiteのトラブルシューティング

- 17.10.5.1 トランザクション・タイムアウト・エラー

- 17.10.6 My Oracle Supportを使用したその他のトラブルシューティング情報

A Oracle RACでのマルチ・データ・ソースの使用

- A.1 マルチ・データ・ソースとOracle RACについて

- A.2 EDGトポロジでマルチ・データ・ソースを構成するための標準的な手順

B Identity Managementのトポロジに関するワークシート

- B.1 Identity Managementのホスト、仮想ホストおよび仮想IPアドレス

- B.2 ディレクトリ・マッピング

- B.3 ポート・マッピング

- B.4 LDAPディレクトリの詳細情報

- B.5 データベースの詳細情報

- B.6 Web層の詳細情報

- B.7 アプリケーション層の詳細情報

- B.8 ユーザーとグループのマッピング

索引

図一覧

- 2-1 シングル・ドメイン・トポロジ

- 2-2 分割ドメイン・トポロジ

- 2-3 3つのドメイン・トポロジ

- 2-4 Oracle Identity Managementエンタープライズ・デプロイメント処理のフロー・チャート

- 3-1 IPアドレスおよびVIPアドレス

- 4-1 共有記憶域

- 4-2 ローカル記憶域

- 16-1 IPアドレスとVIPアドレス

- 16-2 分割ドメイン・トポロジにおける共有記憶域

- 16-3 ローカル記憶域

- 17-1 監査イベント・フロー

表一覧

- 2-1 標準ハードウェア要件

- 2-2 使用するソフトウェアのバージョン

- 2-3 ホームの概要

- 2-4 Oracle Identity Managementエンタープライズ・デプロイメント処理の手順

- 3-1 ロード・バランサの構成

- 3-2 VIPアドレスおよび仮想ホスト

- 3-3 Oracle Identity Managementエンタープライズ・デプロイメント・トポロジで使用されるポート

- 4-1 ローカル記憶域のディレクトリ

- 5-1 UNIXのカーネル・パラメータ

- 5-2 ドメインの仮想ホスト

- 6-1 データベースとスキーマ間のマッピング

- 6-2 Oracle Database 11g (11.1.0.7)に必要なパッチ

- 6-3 Oracle Database 11g (11.2.0.2.0)に必要なパッチ

- 6-4 Oracle RACデータベースの最小限の初期化パラメータ

- 8-1 WebLogicドメインの作成手順

- 8-2 Web層統合後に使用可能なURL

- 10-1 Web層のURL

- 11-1 Web層を構成した後のOAMのURL

- 12-1 OIMのURL

- 14-1 PATH環境変数に必要なファイル

- 14-2 管理対象サーバーの移行

- 16-1 分割ドメインにおける追加のロード・バランサの構成

- 16-2 VIPアドレスと仮想ホスト

- 16-3 Oracle Identity Managementエンタープライズ・デプロイメント・トポロジで使用されるポート

- 16-4 共有記憶域上のボリューム

- 16-5 仮想ホスト

- 16-6 OIMのURL

- 17-1 コンソールのURL

- 17-2 Identity Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクト

- 17-3 Identity Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト

- B-1 ホスト、仮想ホストおよび仮想IPアドレス

- B-2 ディレクトリ・マッピング

- B-3 ポート・マッピング

- B-4 LDAPディレクトリの詳細情報

- B-5 データベースの詳細情報

- B-6 Web層の詳細情報

- B-7 アプリケーション層の詳細情報

- B-8 ユーザー・マッピング

- B-9 グループ・マッピング

はじめに

ここでは、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の対象読者、内容および使用される表記規則について説明します。

対象読者

このマニュアルは、Oracle Identity Managementエンタープライズ・デプロイメントのインストールや構成を担当するシステム管理者を対象としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

エンタープライズ・デプロイメント・アーキテクチャをインストールおよび構成する手順に関する追加情報は、Oracle Fusion Middlewareドキュメント・ライブラリにある次のマニュアルを参照してください。

- 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』

- Oracle Fusion Middleware管理者ガイド

- 『Oracle Fusion Middleware高可用性ガイド』

- Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』

- 『Oracle Fusion Middleware Oracle Unified Directory管理者ガイド』

- 『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』

- 『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』

- Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド

- 『Oracle Fusion Middleware Oracle Access Management管理者ガイド』

- Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド

- Oracle Fusion Middleware Oracle Identity Manager管理者ガイド

- Oracle Fusion Middleware Oracle Identity Managerユーザーズ・ガイド

- 『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for Linux』

- 『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for Solaris Operating System』

- 『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for HP-UX』

- 『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for hp Tru64 UNIX』

- 『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for AIX Based Systems』

- 『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド for Microsoft Windows』

- 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』

表記規則

本文では、次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するグラフィカル・ユーザー・インタフェース要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、パラグラフ内のコマンド、URL、例に記載されているコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

次の各トピックでは、Oracle Identity and Access Managementの新機能と変更機能およびこのガイドで説明する主な変更について紹介し、追加情報へのリンクを示します。

11g リリース2 (11.1.2.1)の新機能と変更機能

『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド11gリリース2 (11.1.2.1)』は、11gリリース2 (11.1.2.0)バージョンと似ていますが、11gリリース2 (11.1.2.1)コンポーネントを使用してテストされています。

1 エンタープライズ・デプロイメントの概要

この章では、Oracle Identity Management用エンタープライズ・トポロジの概要について説明します。

この章の構成は、次のとおりです。

- 第1.1項「エンタープライズ・デプロイメント・ガイドについて」

- 第1.2項「エンタープライズ・デプロイメント・ガイドの規則」

- 第1.3項「エンタープライズ・デプロイメントの用語」

- 第1.4項「Oracle推奨事項のメリット」

Oracle Identity Managementは、アイデンティティ管理のあらゆる面に対応する総合的な製品スイートです。本ガイドでは、Oracle Fusion MiddlewareのOracle Identity Managementインフラストラクチャのコンポーネントに関連する、参照用エンタープライズ・トポロジについて説明します。また、エンタープライズ・デプロイメントのガイドラインに沿ってトポロジを作成するための詳しい手順と推奨事項についても説明します。

1.1 エンタープライズ・デプロイメント・ガイドについて

エンタープライズ・デプロイメントは、定評のあるOracle高可用性テクノロジとOracle Fusion Middlewareに関する推奨事項に基づいた、Oracleベスト・プラクティスの青写真です。このマニュアルに示す高可用性ベスト・プラクティスは、Oracle Database、Oracle Fusion Middleware、Oracle Applications、Oracle Collaboration Suite、Oracle Grid Controlなど、技術スタック全体におよぶOracle製品を対象とした様々な高可用性ベスト・プラクティスの1つです。

Oracle Fusion Middlewareエンタープライズ・デプロイメントの機能は次のとおりです。

- 様々なビジネス上のサービス・レベル合意(SLA)を考慮し、高可用性に対するベスト・プラクティスを可能なかぎり広範囲に適用できるようにします。

- データベース・グリッド・サーバーと低コストのストレージを使用したストレージ・グリッドを活用し、回復力に優れた低コストのインフラストラクチャを提供します。

- 様々な構成に対する広範なパフォーマンス影響調査の結果を利用し、最適な高可用性アーキテクチャを構成して、実行およびビジネス・ニーズに合せたスケール変更を可能にします。

- 停止状態からのリカバリ時間と自然災害時に許容可能なデータ損失量を制御できます。

- 各Oracleバージョンと共に内容が向上し、ハードウェアとオペレーティング・システムからは完全に独立しています。

高可用性の実現に関する詳細は、次のOracle Technology Networkで、Oracle Databaseの高可用性のページを参照してください。

http://www.oracle.com/technetwork/database/features/availability/index-087701.html

注意:

『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』では、Linux環境におけるエンタープライズ・デプロイメントを中心に説明しています。しかしながら、UNIX環境を使用したエンタープライズ・デプロイメントの実装も可能です。

1.2 エンタープライズ・デプロイメント・ガイドの規則

このガイドで示されているUNIXおよびLinuxのコマンド例はすべて、bashシェルを使用して実行されます。

1.3 エンタープライズ・デプロイメントの用語

この項では、このガイドで使用されているエンタープライズ・デプロイメント用語について説明します。

- Oracleホーム: Oracleホームには、特定の製品をホストするために必要な、インストール済のファイルが含まれています。たとえば、SOA Oracleホームには、Oracle SOA Suiteのバイナリとライブラリ・ファイルを含むディレクトリが配置されます。Oracleホームは、ミドルウェア・ホームのディレクトリ構造内に配置されます。各Oracleホームは、複数のOracleインスタンスまたはOracle WebLogic Serverドメインと関連付けることができます。

- Oracle共通ホーム: この環境変数と関連ディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files (JRF)に必要なバイナリおよびライブラリ・ファイルが含まれるOracleホームを指しています。

- WebLogic Serverホーム: WebLogic Serverホームには、WebLogic Serverをホストするために必要な、インストール済のファイルが含まれています。WebLogic Serverホーム・ディレクトリは、Oracleホーム・ディレクトリのピアで、ミドルウェア・ホームのディレクトリ構造内に配置されます。

- ミドルウェア・ホーム: ミドルウェア・ホームは、Oracle WebLogic Serverホームと、オプションとして1つまたは複数のOracleホームで構成されます。ミドルウェア・ホームは、ローカル・ファイル・システムに配置できますし、NFSを介してアクセス可能なリモート共有ディスクにも配置できます。

- Oracleインスタンス: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどの、1つ以上のアクティブなミドルウェア・システム・コンポーネントが含まれます。インストール時、または後のインスタンスの作成および構成時に、どのコンポーネントをインスタンスの一部にするかを決定します。Oracleインスタンスには、更新可能なファイルがあります。それらのファイルの例には、構成ファイル、ログ・ファイル、一時ファイルなどがあります。

- フェイルオーバー: 高可用性システムのメンバーに不測の障害が発生した場合(計画外停止)、サービスの提供をコンシューマに対して続行するため、システムではフェイルオーバー操作が行われます。システムがアクティブ/パッシブ型システムの場合、パッシブ・メンバーはフェイルオーバー操作においてアクティブになります。そしてコンシューマは、障害が発生したメンバーではなく、アクティブになったメンバーにダイレクトされます。フェイルオーバー操作は、手動でも実行できます。また、障害を検出した場合にクラスタのリソースを障害ノードからスタンバイ・ノードに移動するように、ハードウェア・クラスタ・サービスを設定することで、フェイルオーバー操作を自動化することもできます。システムがアクティブ/アクティブ型システムの場合、ロード・バランサのエンティティによりフェイルオーバーが実行されます。このエンティティによって、リクエストがアクティブ・メンバーで処理されます。アクティブ・メンバーに障害が発生すると、ロード・バランサにより障害が検出され、障害メンバーへのリクエストが、正常に動作しているアクティブ・メンバーに自動的にリダイレクトされます。アクティブ/アクティブ型システムとアクティブ/パッシブ型システムの詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

- フェイルバック: システムのフェイルオーバー操作が正常に終了した後、最初に障害を起こしたメンバーは修復され、スタンバイ・メンバーとしてシステムに再導入されます。必要に応じて、フェイルバック処理を開始して、このメンバーをアクティブにし、別のメンバーを非アクティブにすることができます。このプロセスにより、システムは障害発生前の構成に戻ります。

- ハードウェア・クラスタ: ハードウェア・クラスタは、これらのサービスのクライアントにネットワーク・サービス(例: IPアドレス)や、アプリケーション・サービス(例: データベース、Webサーバー)の単一ビューを提供するコンピュータの集まりです。ハードウェア・クラスタの各ノードは、それぞれ固有のプロセスを実行するスタンドアロン・サーバーです。これらのプロセスは互いに通信して、単一のシステムであるかのように動作して、アプリケーション、システム・リソースおよびデータを連携してユーザーに提供できます。
特別なハードウェア(クラスタ・インターコネクト、共有記憶域)とソフトウェア(ヘルス・モニター、リソース・モニター)を使用することで、ハードウェア・クラスタにより高可用性とスケーラビリティが実現されます。(クラスタ・インターコネクトは、ハートビート情報がノードの停止を検出する際にハードウェア・クラスタで使用されるプライベート・リンクです)。専用のハードウェアとソフトウェアが必要であるため、通常、ハードウェア・クラスタはSun社、HP社、IBM社、Dell社などのハードウェア・ベンダーによって提供されます。1つのハードウェア・クラスタ内で構成可能なノード数は、ベンダーによって異なりますが、Oracle Fusion Middlewareの高可用性では2つのノードのみを必要とします。このため、ハードウェア・クラスタを使用する高可用性ソリューションでは、2つのノードによるハードウェア・クラスタがこのドキュメントで前提にされています。

- クラスタ・エージェント: ハードウェア・クラスタのノード・メンバー上で実行されるソフトウェアで、他のノードとの可用性やパフォーマンスの操作の調整をします。クラスタウェアによりリソースのグループ化と監視を行い、サービスを移行できます。クラスタ・エージェントではサービスのフェイルオーバーを自動化できます。

- クラスタウェア: クラスタ・メンバーの処理を、1つのシステムとして管理するソフトウェアです。これにより、クラスタ・メンバー間のハートビート・メカニズムを使用して、監視対象のリソースとサービスのセットを定義したり、これらのリソースとサービスをクラスタ内の別のメンバーにできるだけ効率的かつ透過的な方法で移動することができます。

- 共有記憶域: エンタープライズ・デプロイメント・ドメイン内のすべてのマシンがアクセスできる記憶域のサブシステムです。共有ディスクには特に次のものが配置されています。

- ミドルウェア・ホームのソフトウェア

- AdminServerドメイン・ホーム

- JMS

- Tlogs(該当する場合)

必要に応じて、管理対象サーバーのホームを共有ディスクに配置できます。共有記憶域は、Network Attached Storage (NAS)またはStorage Area Network (SAN)にすることができます。また、複数のノードが同時にアクセスして読込みと書込みができる他のストレージ・システムにすることもできます。

- 1次ノード: Oracle Fusion Middlewareインスタンスをいつでもアクティブに実行しているノードであり、バックアップ/2次ノードを持つように構成されているノードです1次ノードに障害が発生すると、Oracle Fusion Middlewareインスタンスでは2次ノードにフェイルオーバーされます。このフェイルオーバーは手動でも実行できますし、管理サーバー用のクラスタウェアを使用して自動的に実行できます。サーバー移行機能に基づいたシナリオでは、WebLogic Whole Server移行機能が自動化フェイルオーバーに使用されています。

- 2次ノード: Oracle Fusion Middlewareインスタンスのバックアップ・ノードであるノード。プライマリ・ノードが使用できなくなると、アクティブなインスタンスでフェイルオーバーが実行されます。この項で、プライマリ・ノードに関する定義を参照してください。

- ネットワーク・ホスト名: ネットワーク・ホスト名は、/etc/hostsファイルまたはDNS名前解決を通じてIPアドレスに割り当てられる名前です。この名前は、参照先マシンに接続する際にネットワークで参照可能です。ネットワーク・ホスト名と物理ホスト名が同一である場合があります。ただし、各マシンには物理ホスト名は1つのみ付与されますが、ネットワーク・ホスト名は複数付与される場合があります。そのため、マシンのネットワーク・ホスト名はその物理ホスト名であるとはかぎりません。

- 物理ホスト名: このガイドでは、物理ホスト名とネットワーク・ホスト名を区別しています。このガイドでは、現在のマシンの内部名を指す場合に物理ホスト名が使用されます。Linuxでは、hostnameコマンドにより返される名前です。
Oracle Fusion Middlewareで使用される物理ホスト名は、ローカル・ホストを示します。インストール中に、インストーラでは物理ホスト名が現在のマシンから自動的に取得され、ディスク上のOracle Fusion Middleware構成メタデータに格納されます。

- 物理IP: 物理IPは、ネットワーク上のマシンのIPを示します。ほとんどの場合、マシンの物理ホスト名と関連付けられます(物理ホスト名に関する定義を参照)。仮想IPと対照的に、マシンがネットワークに接続されると、必ず同じマシンと関連付けられます。

- スイッチオーバー: 通常の操作中に、システムのアクティブなメンバーのメンテナンスやアップグレードが必要になることがあります。スイッチオーバー処理を開始して、メンテナンスやアップグレード(計画停止中に実施)が必要なメンバーが処理していたワークロードを、代替メンバーが引き継ぐことができます。スイッチオーバー処理により、システムのコンシューマに対してサービスが続行できるようになります。

- スイッチバック: スイッチオーバー操作の実行時、メンテナンスまたはアップグレードのためにシステムのメンバーは非アクティブ化されます。メンテナンスやアップグレードが完了すると、システムでスイッチバック処理を実行して、アップグレードしたメンバーをアクティブ化し、スイッチオーバー前の構成にシステムを戻すことがきます。

- 仮想ホスト名: 仮想ホスト名はネットワーク・アドレスを指定可能なホスト名で、ロード・バランサまたはハードウェア・クラスタを通じて、1つ以上の物理マシンにマップされます。ロード・バランサの場合、このマニュアルでは仮想サーバー名の名前は仮想ホスト名と同じ意味で使用されます。複数のサーバーのセットを代表する仮想ホスト名をロード・バランサに付与でき、クライアントは仮想ホスト名を使用して、間接的にマシンと通信します。ハードウェア・クラスタの仮想ホスト名は、クラスタの仮想IPに割り当てられるネットワーク・ホスト名です。クラスタにある特定ノードにクラスタの仮想IPが永続的に付与されないため、仮想ホスト名も特定ノードに永続的に付与されません。

注意:

このドキュメントで「仮想ホスト名」という用語を使用する場合、それが仮想IPアドレスに関連付けられることを前提とします。IPアドレスが必要とされたり使用される場合、明示的に言及します。

- 仮想IP: クラスタ仮想IP、ロード・バランサ仮想IPとも言います。一般的に、仮想IPはハードウェア・クラスタやロード・バランサに割り当てることができます。クラスタにおいて単一のシステム・ビューをネットワーク・クライアントに対して実現するために、クラスタのメンバーであるサーバー・グループに対して仮想IPはエントリ・ポイントのIPアドレスとして機能します。仮想IPは、サーバーのロード・バランサまたはハードウェア・クラスタに割り当てることができます。
ハードウェア・クラスタではクラスタの仮想IPが使用され、外部の世界に対してクラスタ(スタンドアロンのマシンにも設定可能)へのエントリ・ポイントを実現します。ハードウェア・クラスタのソフトウェアにより、クラスタにある2台の物理ノード間においてこのIPアドレスの変更が管理されますが、クライアントはこのIPアドレスに接続します。その際、このIPアドレスが現在アクティブである物理ノードを判別する必要はありません。2台のノードによる標準的ハードウェア・クラスタ構成では、各マシンには固有の物理IPアドレスと物理ホスト名が付与されながら、数個のクラスタIPアドレスを付与することもできます。これらのクラスタIPアドレスは、2台のノードにおいて切り替わります。クラスタIPアドレスを現在所有しているノードは、そのアドレスでアクティブになります。

また、ロード・バランサでも、複数のサーバーのセットのエントリ・ポイントとして仮想IPが使用されます。これらのサーバーは、同時にアクティブになる傾向があります。この仮想IPアドレスは個々のサーバーには割り当てられませんが、サーバーとクライアントとの間においてプロキシとして動作するロード・バランサに割り当てられます。

これらについては、以降の章で詳しく説明されています。

1.4 Oracle推奨事項のメリット

このマニュアルで取り上げるOracle Fusion Middleware構成は、すべてのトランザクションのセキュリティの確保、ハードウェア・リソースの最大化、および各種アプリケーションを使用するエンタープライズ・コンピューティングのための標準に準拠した信頼性の高いシステムの提供を目的としています。Oracle Fusion Middleware構成のセキュリティと高可用性のメリットは、ファイアウォール・ゾーンの分離とソフトウェア・コンポーネントのレプリケーションを通じて実現されます。

この項には次のトピックが含まれます:

- 第1.4.1項「組込みセキュリティ」

- 第1.4.2項「高可用性」

1.4.1 組込みセキュリティ

エンタープライズ・デプロイメント・アーキテクチャのセキュリティは、ソフトウェア・コンポーネントのすべての機能グループが各グループ固有のゾーンに分離され、すべてのトラフィックがプロトコルとポートによって制限されることによって確保されます。次の特長により、必要なレベルのすべてのセキュリティが確保され、高レベルの標準の準拠が実現します。

- ポート80 (HTTP_PORT)で受信するすべての外部通信がポート443 (HTTP_SSL_PORT)にリダイレクトされます。

- 外部との通信には、Secure Socket Layer (SSL)セキュアWebプロトコルを使用します。この通信はサイトのロード・バランサで終了します。

- 外部のクライアントからの通信はロード・バランシング・ルーターを超えたレベルでは発生しません。

- ロード・バランシング・ルーターからデータ層ゾーンへの直接的な通信は許可されません。

- コンポーネントは、Web層、アプリケーション層およびデータベース層の各ゾーン間で分離されます。

- いずれの時点においても、2つのファイアウォール間での直接的な通信は禁止されています。

- 1つのファイアウォール・ゾーンで通信が始まった場合、それは次のファイアウォール・ゾーンで終わる必要があります。

- LDAPディレクトリはディレクトリ層ゾーンに分離できます。(Oracle Unified Directoryはアプリケーション層ゾーン内に配置されます。)

- アイデンティティ管理コンポーネントはアプリケーション層ゾーン内に配置されます。

- ゾーンをまたぐすべてのコンポーネント間通信は、ファイアウォールのルールに従い、ポートとプロトコルによって制限されます。

1.4.2 高可用性

エンタープライズ・デプロイメント・アーキテクチャは、きわめて高い可用性を提供します。それは、ソフトウェア・コンポーネントの各コンポーネントまたは機能グループがそれぞれ別のコンピュータ上でレプリケートされ、コンポーネント・レベルの高可用性を確保するように構成されるためです。

2 導入と計画

この章では、このガイドで使用するエンタープライズ・デプロイメント参照用トポロジについて説明します。

エンタープライズ・デプロイメントを成功させるには、計画および準備が重要です。この章の最後にあるインストールと構成のロード・マップでは、実行する必要のあるタスクが記載されている章へと導きます。この章は、このガイドで使用する例を独自のデプロイメントにマップする際に役立ちます。

付録B「Identity Managementのトポロジに関するワークシート」を使用して、情報を追跡できます。

この章には、次の項目が含まれます。

- 第2.1項「デプロイメントの計画」

- 第2.2項「トポロジについて」

- 第2.3項「エンタープライズ・デプロイメントのハードウェア要件」

- 第2.4項「エンタープライズ・デプロイメントのソフトウェア・コンポーネント」

- 第2.5項「参照用トポロジのインストールおよび構成のロード・マップ」

2.1 デプロイメントの計画

Identity Managementのエンタープライズ・デプロイメントは、次の部分から構成されます。

- ポリシー情報およびデプロイするアイデンティティ管理コンポーネント固有の情報を格納するための高可用性データベース。

- アイデンティティ情報の作成および管理をサポートし、データベースおよびアイデンティティ・ストア内に格納されたポリシーおよびアイデンティティに基づいてリソースへのアクセスを制限するように高可用性の方法でインストールされたIdentity Managementコンポーネント。Identity Managementコンポーネントは、次の3つのカテゴリに分類できます。

- Directory Services: アイデンティティ情報を格納するための1つ以上の高可用性ディレクトリ

- Identity Managementプロビジョニング: Oracle Identity Manager

- アクセス制御: Oracle Access Management

- アイデンティティ管理コンポーネントへのアクセスに使用される高可用性Web層。これらのコンポーネントへのアクセスを制限し、企業のリソースにアクセスしようとする人やプロセスのアイデンティティを確認するために使用されます。

- Webサーバー間に負荷を分散するために使用する高可用性ロード・バランサ。ロード・バランサは、SSL暗号化をオフロードしてユーザー・セッションとOracle Identity Managementの間の通信を暗号化するためにも使用できますが、個別のアイデンティティ管理コンポーネント間のSSLを有効にするためのオーバーヘッドの必要はありません。

これらのコンポーネント・パーツを同時に配置する方法は多数あります。3つのトポロジは、次の項で説明します。このガイドでは、これらのデプロイ方法を詳細に説明します。Oracleがサポートしているのはこれらのトポロジのみではありませんが、これらは最も一般的なものと考えられます。

注意:

このガイドでは、Oracle Internet DirectoryインスタンスまたはOracle Internet Directoryドメインの作成方法は説明しません。

この項には次のトピックが含まれます:

- 第2.1.1項「デプロイメント・トポロジ」

- 第2.1.2項「使用するトポロジ」

2.1.1 デプロイメント・トポロジ

トポロジは、コンポーネントのデプロイメント・マップです。Oracle Identity Managementコンポーネントをインストールして、動作するIdentity and Access Managementのソリューションを提供する方法は複数あります。トポロジは、アーキテクチャの青写真としても記述できます。このガイドでは、Oracle Identity and Access Managementの最も一般的なデプロイメント・トポロジを示します。

Oracle Identity and Access Managementをエンタープライズ・デプロイメントにデプロイする方法は多数あります。2つの最も一般的なデプロイメント・モデルは、すべてを単一のドメインに配置する方法と、運用コンポーネントと管理コンポーネントを別のドメインに分離する方法です。次の3つの図は、これら2つの異なるデプロイメント・モデルを示しています。

この項には次のトピックが含まれます:

- 第2.1.1.1項「シングル・ドメイン・トポロジ」

- 第2.1.1.2項「分割ドメイン・トポロジ」

- 第2.1.1.3項「3つのドメイン・トポロジ」

2.1.1.1 シングル・ドメイン・トポロジ

図2-1 シングル・ドメイン・トポロジ

この図は、エンタープライズ・トポロジのグラフィカル表示です。これには、ハードウェア・ロード・バランサ、ホスト・コンピュータ、ファイアウォールおよびトポロジのその他の要素を表すアイコンおよび記号が含まれています。高レベルでは、次のものを含むトポロジの主コンポーネントを示します。

- Web層: 2つのサーバーがあり、それぞれがOracle HTTP ServerとOracle Webゲートをホストしています。

- アプリケーション層: 2つのサーバー(IDMHOST1とIDMHOST2)があります。それぞれが、次の製品の管理対象サーバーを含んでいます。

- Oracle Access Management。これは、Access Server、Federationおよび対応するJRF/OPSSプロセスをホストしています。

- Oracle Identity Manager。これは、OIM Serverおよび対応するJRF/OPSSプロセスをホストしています。

- SOA。これは、SOA Serverおよび対応するJRF/OPSSプロセスをホストしています。

- Oracle Unified Directory。各ホストには、アイデンティティ情報用のLDAPディレクトリとして使用されるOracle Unified Directoryのインスタンスがあります。それぞれのOracle Unified Directoryインスタンスは、Oracle Unified Directoryのレプリケーションによって最新に保たれます。

IDMHOST1には、WebLogicコンソール、Enterprise Manager Fusion Middleware Control、OAMコンソール、APMコンソールおよびODSM (Oracle Unified Directory用)をホストするWebLogic管理サーバーも含まれています。IDMHOST1に障害が発生した場合、WebLogic管理サーバーはIDMHOST2上で起動できます。

- データ層: これはデータベースがある場所です。データベースには、アプリケーション層の製品が必要とする顧客データおよびスキーマが含まれています。

- ロード・バランサ: ロード・バランサは非武装地帯(DMZ)にあり、SSO.mycompany.com、ADMIN.mycompany.comおよびIDMINTERNAL.mycompany.comで受信したリクエストをOracle HTTPサーバーに転送します。SSO.mycompany.comの場合、リクエストはSSL暗号化されます。これはロード・バランサで終了します。ADMIN.mycompany.comおよびIDMINTERNAL.mycompany.comは、HTTPプロトコルを使用してリクエストを処理します。
また、ロード・バランサは、ロード・バランサの仮想ホストであるIDSTORE.mycompany.comを使用して、LDAPリクエストをIDMHOST1とIDMHOST2のOracle Unified Directoryインスタンス間に分散します。

- ファイアウォール: これらは、Web層、アプリケーション層およびディレクトリ層を異なるゾーンに分離するために使用します。WEBHOST1とWEBHOST2はDMZに配置されています。

詳細は、図に続く各項のトポロジ層の説明を参照してください。このガイドの手順では、このトポロジ用にソフトウェアをインストールして構成する方法を説明します。

2.1.1.2 分割ドメイン・トポロジ

図2-2 分割ドメイン・トポロジ

この図は図2-1と似ています。異なる点は、Oracle Access ManagementのWebLogic管理対象サーバーがIDMDomainというドメインに配置されていて、Oracle Identity Managerの管理対象サーバーおよびSOAコンポーネントがOIMDomainというドメインに配置されていることです。

また、2つ目の管理サーバーがIDMHOST1上に構成されていて、2つ目のドメインであるOIMDomainをサポートしています。

このトポロジ用にソフトウェアをインストールして構成する方法は、第16章「分割ドメイン・トポロジの作成」で説明します。

詳細は、図に続く各項のトポロジ層の説明を参照してください。

2.1.1.3 3つのドメイン・トポロジ

図2-3 3つのドメイン・トポロジ

この図は図2-2と似ています。異なる点は、Oracle Unified DirectoryがOracle Internet Directoryに置き換えられていることです。Oracle Internet Directoryコンポーネントは、ディレクトリ層という名前に変更されたデータベース層に移動します。

ディレクトリ層には、2つの新規ホストOIDHOST1とOIDHOST2があります。これらのホストには、Oracle Internet Directoryインスタンスが含まれています。また、OIDDomainという別のドメインもあり、これにはWebLogic管理サーバーおよび2つのWebLogic管理対象サーバーがあり、それぞれがODSMをホストしています。

ディレクトリ層には追加のデータベースも含まれていて、これにはOracle Internet Directoryスキーマが含まれています。

詳細は、図に続く各項のトポロジ層の説明を参照してください。

2.1.2 使用するトポロジ

シングル・ドメイン・トポロジと分割ドメイン・トポロジには、それぞれ長所と短所があります。

この項には次のトピックが含まれます:

- 第2.1.2.1項「シングル・ドメイン・トポロジ」

- 第2.1.2.2項「分割ドメイン・トポロジ」

- 第2.1.2.3項「3つのドメイン・トポロジ」

- 第2.1.2.4項「まとめ」

2.1.2.1 シングル・ドメイン・トポロジ

シングル・ドメイン・トポロジの長所は次のとおりです。

- 大部分の実装に適しています。

- 各コンポーネントが単一のWebLogicドメイン内に含まれていて、設定、管理およびパッチ適用が簡単です。

- 分割ドメイン・モデルよりも設定が簡単です。

- 同じトポロジは、本番システムと本番ではないシステムに適しています。

- これは、Fusion ApplicationsのIdentity Managementが使用するデプロイメント・モデルと同じです。

- 異なるドメインに異なるIAMコンポーネントを持つことによる複雑さがありません。

- Enterprise Manager Fusion Middleware Controlは、すべてのアイデンティティ管理コンポーネントを統合した単一のビューを表示します。

シングル・デプロイメント・モデルの短所は次のとおりです。

- アイデンティティ・プロビジョニングとアクセス制御が同じデプロイメントによって提供されます。

- パッチを適用する必要があり、そのパッチを適用するにはドメイン全体を停止する必要がある場合、プロビジョニングとアクセス制御の両方のサービスが中断されます。

- ドメイン・レベルの更新を含むパッチ・セットによって互換性の問題が引き起こされる場合があります。これは、Identity and Access Managementのみがインストールされているドメイン(つまり、Oracle Internet Directory、Oracle Virtual DirectoryまたはOracle Identity Federationがないドメイン)ではほとんど発生しません。

2.1.2.2 分割ドメイン・トポロジ

分割ドメイン・トポロジは、デプロイメントの各コンポーネントに対して限定的な制御を必要とする大きい組織に適しています。

分割ドメイン・トポロジの主な長所は、パッチ適用の柔軟性に関係しています。具体的には次のとおりです。

- 各コンポーネント(Oracle Identity ManagerおよびAccess Manager)が異なるドメインに配置されているため、目的のコンポーネントのみを更新するようにパッチを適用できます(ドメイン・レベルのものであっても同様)。

- Oracle Identity Managerなどの管理コンポーネントを制御して停止する必要なくパッチ適用できます。この制御停止は、Access Managerなどの運用コンポーネントの更新では必要です。

分割デプロイメント・トポロジの短所は次のとおりです。

- 設定がより複雑です。

- ドメイン間で動作するようにコンポーネントを構成する必要があります。

- 複数のソフトウェア・デプロイメントが必要なため、Middlewareホームが増えます。

- 汎用パッチを各ドメインにデプロイする必要があります。

- ドメインの管理がより複雑です。具体的には次のとおりです。

- 2つの管理コンソール

- Fusion Middleware Controlの2つのインスタンス

- すべてのアイデンティティ管理コンポーネントの単一ビューなし

2.1.2.3 3つのドメイン・トポロジ

このトポロジは、本質的には分割ドメイン・トポロジと同じですが、Oracle Unified DirectoryのかわりにOracle Internet Directoryを使用します。他のコンポーネントに依存せずにOracle Internet Directoryのパッチ適用を容易にするために、Oracle Internet Directoryは個別のドメインを使用して構成されます。

このガイドでは、高可用性Oracle Internet Directoryがすでにデプロイされていることを想定していますが、その設定については説明しません。高可用性Oracle Internet Directoryの設定の詳細は、『Oracle Fusion Middleware高可用性ガイド』のOracle Internet Directoryの高可用性に関する項を参照してください。

2.1.2.4 まとめ

パッチ適用の完全な制御(つまり、各アイデンティティ管理コンポーネントを個別にパッチ適用する機能)を特別に必要としないのであれば、シングル・ドメイン・トポロジの使用をお薦めします。

2.2 トポロジについて

各トポロジは、セキュリティおよび保護を向上するために複数の層に分割されます。層は、ある層から次の層へのアクセスを制御するファイアウォールによって分離されます。その目的は、未承認のトラフィックを防止することです。たとえば、インターネットに面しているトポロジでは、インターネット領域からデータベースに直接アクセスできないことが必要です。アプリケーション領域にデプロイされているアプリケーションのみがデータベースにアクセスできる必要があります。

前述の図それぞれが次の3つの層を示しています。

- Web層

- アプリケーション層

- データベース層

図には表示されていませんが、ディレクトリ層(データベース層に含まれることが多い)も存在できます。専用のディレクトリ層が導入される場合、LDAPディレクトリをこの層内に配置できます。これは、データベースに密接に関連しているOracle Internet Directoryを使用したデプロイメントで行われることが最も多いです。

この項には次のトピックが含まれます:

- 第2.2.1項「Web層について」

- 第2.2.2項「アプリケーション層について」

- 第2.2.3項「オプションのディレクトリ層について」

- 第2.2.4項「データベース層について」

2.2.1 Web層について

Web層はDMZパブリック・ゾーンにあります。HTTPサーバーはWeb層にデプロイされます。

大半のアイデンティティ管理コンポーネントはWeb層なしで動作できますが、大半のエンタープライズ・デプロイメントではWeb層が望ましいです。Oracle Single Sign-OnやAccess Managerなどの製品を使用して全社レベルのシングル・サインオンをサポートするには、Web層が必要です。

Oracle Enterprise Manager Fusion Middleware ControlやOracle Directory Services ManagerなどのコンポーネントはWeb層なしで動作できますが、必要に応じてWeb層を使用するように構成できます。

Web層:

- WEBHOST1とWEBHOST2には、Oracle HTTP Server、Webゲート(Access Managerコンポーネント)およびmod_wl_ohsプラグイン・モジュールがインストールされています。mod_wl_ohsプラグイン・モジュールにより、アプリケーション層で実行されているWebLogic ServerにOracle HTTP Serverからリクエストをプロキシすることができます。

- Oracle HTTP ServerのWebゲート(Oracle Access Managementコンポーネント)は、Oracle Accessプロトコル(OAP)を使用して、アイデンティティ管理DMZ内のIDMHOST1とIDMHOST2で実行されているAccess Managerと通信します。WebゲートとAccess Managerは、ユーザー認証などの操作の実行に使用されます。

Web層を保護するファイアウォール上では、HTTPポートは、HTTPS用の443(HTTP_SSL_PORT)とHTTP用の80(HTTP_PORT)です。ポート443は開いています。

2.2.1.1 アーキテクチャに関する注意

WEBHOST1とWEBHOST2上のOracle HTTP Serverはmod_wl_ohsを使用して構成されており、IDMHOST1とIDMHOST2上にあるWebLogic ServerにデプロイされたOracle Enterprise Manager、Oracle Directory Integration PlatformおよびOracle Directory Services Manager Java EEアプリケーションのリクエストをプロキシします。

2.2.1.2 高可用性プロビジョニング

Oracle HTTPサーバーがWEBHOST上で障害が発生した場合、Oracle Process Management and Notification (OPMN)サーバーはこれを再起動しようとします。

2.2.1.3 セキュリティ・プロビジョニング

URL SSO.mycompany.comとADMIN.mycompany.comを使用して受信したリクエストをOracle HTTP Serverで処理します。ADMIN.mycompany.comの名前は、ファイアウォール内でのみ解決可能です。これによって、Oracle WebLogic ServerコンソールやOracle Enterprise Manager Fusion Middleware Controlコンソールなどの機密リソースをパブリック・ドメインからアクセスされないようになります。

2.2.2 アプリケーション層について

アプリケーション層は、Java EEアプリケーションが配置される層です。Oracle Identity Manager、Oracle Directory Integration Platform、Oracle Directory Services Manager、Oracle Enterprise Manager Fusion Middleware Controlなどの製品が、この層にデプロイできる主要なJava EEコンポーネントです。この層にあるアプリケーションは、Oracle WebLogic Serverの高可用性サポートにおけるメリットを享受します。

アプリケーション層にあるアイデンティティ管理アプリケーションは、次に示すようにディレクトリ層と対話的に処理を行います。

- エンタープライズ・アイデンティティ情報についてはディレクトリ層が活用されます。

- 場合によっては、アプリケーション・メタデータではディレクトリ層(およびデータ層のデータベースの場合もある)が活用されます。

- Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Directory Services Managerは、アプリケーション層だけでなくディレクトリ層にもあるコンポーネントに対して管理機能を提供する管理ツールです。

- WebLogic Serverには、Webサーバーのサポートが組み込まれています。有効にされていると、HTTPリスナーはアプリケーション層にも配置されます。ただし、図1-1に示したエンタープライズ・デプロイメントでは、お客様はApacheやOracle HTTP ServerなどのWebサーバーに依存する別のWeb層を使用しています。

アプリケーション層では、IDMHOST1とIDMHOST2には次のコンポーネントが含まれています。

- インフラストラクチャの運用コンポーネント。このコンポーネントは、Oracle Access Management Access Manager (OAM)です。これは、Oracle WebLogic Server内で実行されるJ2EEアプリケーションです。

- Oracle Identity ManagerおよびOracle Entitlements Server Policy Manager。これらはユーザー・プロビジョニングおよびポリシー管理に使用されます。

- Oracle Identity Managerなどのアイデンティティ管理の管理コンポーネント。これはユーザー・プロビジョニングに使用されます。注意: これらのサーバーは、Oracle Identity Managerによって排他的に使用されるOracle SOAも実行します。
Oracle Identity Manager (OIM)はディレクトリ層と通信します。

さらに、次の場合もあります。

- IDMHOST1はOracle WebLogic管理サーバーをホストします。管理サーバーの内部には、Oracle WebLogicコンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Access Managementコンソール、Oracle Unified Directory用のOracle Directory Services Manager (ODSM)など、ドメインの管理およびナビゲーション用のコンポーネントがあります。WebLogic管理サーバーは、シングルトン・プロセスです。つまり、一度に1つのサーバーでのみ起動できます。管理サーバーを実行しているホストで障害が発生した場合、管理サーバーを別のホストで手動で起動できます。

2.2.2.1 WebLogicドメインについて

ドメインは、WebLogic Serverインスタンスの基本的な管理単位です。ドメインは、単一の管理サーバーを使用して管理する1つ以上のWebLogic Serverインスタンス(およびその関連リソース)から構成されています。様々なシステム管理者の責任、アプリケーション境界、またはサーバーの地理的な場所に基づいて複数のドメインを定義できます。一方で、1つのドメインを使用して、すべてのWebLogic Server管理アクティビティを集中管理できます。

アイデンティティ管理のコンテキストでは、SOA、Web Center Portalなどの顧客アプリケーションがデプロイされる可能性があるドメインとは別個のWebLogic Serverドメインに、アイデンティティ管理コンポーネントとSOAをデプロイすることをお薦めします。標準のエンタープライズ・デプロイメントでは、アイデンティティ管理コンポーネント(LDAPディレクトリ、シングル・サインオン・ソリューション、プロビジョニング・ソリューションなど)の管理は、ミドルウェア・インフラストラクチャおよびアプリケーションを管理する管理者とは異なる管理者が行います。Oracle Identity Managerは、他の製品に依存せずにパッチ適用できるように個別の専用ドメインにデプロイできます。

開発環境またはテスト環境において単一のドメインにすべてを配置することは技術的には可能です。ただし、本番環境では、別々のドメインを使用するという推奨事項により、アイデンティティ管理スタックと残りのミドルウェアおよびアプリケーションのデプロイメントの間に論理的管理境界が作成されます。

2.2.2.2 LDAPディレクトリについて

アイデンティティ情報は、LDAP対応ディレクトリに格納されます。本来、次のディレクトリがサポートされています。

- Oracle Unified Directory

- Oracle Internet Directory

Microsoft Active Directoryなどの別のディレクトリを使用する場合、Oracle Virtual Directoryを使用してその情報を提供するか、Oracle Directory Integration Platformを使用して、他のディレクトリのユーザーとグループを同期させることができます。

標準的なLDAPポートは、非SSLポートでは389 (LDAP_LBR_PORT)になり、SSLポートでは636 (LDAP_LBR_SSL_PORT)になります。イントラネットの電子メール・クライアントなどのクライアントによりホワイト・ページが検索される際に、LDAPサービスが使用されることがあります。ロード・バランサ上のポート389と636は、通常、個々のディレクトリ・インスタンスによって使用される権限のないポートにリダイレクトされます。LDAPリクエストは、ハードウェア・ロード・バランサを使用して、Oracle Unified Directory、Oracle Internet DirectoryまたはOracle Virtual Directoryの各ホストに分散されます。

アイデンティティ情報が複数のバックエンド・ディレクトリに分割されている複雑なディレクトリ実装では、Oracle Virtual Directoryを使用して、この実装をOracle Identity Managementとともに使用できます。

多くの組織には、既存のディレクトリ・デプロイメントがあります。既存のデプロイメントがない場合、このガイドを使用して、このロールを引き受けるようにOracle Unified Directoryを構成する方法を学習できます。既存のディレクトリがある場合、このガイドを使用して、そのディレクトリを構成してOracle Identity Managementで使用する方法を学習できます。ディレクトリがなく、Oracle Unified Directory以外のディレクトリを使用する場合、これらのディレクトリを高可用性の方法で構成する方法の詳細は、ディレクトリのドキュメントを参照してください。

2.2.2.2.1 Oracle Unified Directoryについて

アイデンティティ情報をOracle Unified Directoryに格納すると、この情報は、Berkeleyデータベースにローカルで格納されます。高可用性を確保するために、Oracle Unified Directoryレプリケーションを使用して、この情報が別のOracle Unified Directoryインスタンスにレプリケーションされます。

Oracle Unified Directoryサーバー・インスタンスは、本来、レプリケーションを使用して、埋込みデータベースの同期状態を保持します。デフォルトでは、レプリケーションは、操作結果がアプリケーションに戻った後に更新をレプリカにレプリケーションするゆるやかな一貫性モデルを使用します。したがってこのモデルでは、データをレプリカに書き込んでから、書込みの少し後に古い情報を別のレプリカから読み取ってしまう可能性があります。レプリケーション・プロセスが高速で1ミリ秒の桁で達成できるように、Oracle Unified Directoryレプリケーションで多くの作業が行われました。

レプリカ内のデータの一貫性を保証するように開発された保証レプリケーション・モデルを使用するようにOracle Unified Directoryを構成できます。保証レプリケーションの安全読取りモードを使用すると、アプリケーションは、レプリケーション・プロセスが書込み操作の結果を返す前に完了することを保証します。

保証レプリケーションを使用すると、書込み操作の応答時間に悪影響があります。これは、保証レプリケーションではリモート・レプリカとの通信の後に操作結果を返す必要があるためです。遅延時間は、使用するネットワークおよびOracle Unified Directoryをホストしているサーバーの容量によって異なります。保証レプリケーションを使用しても、読取り操作への影響はほとんどありません。

ディレクトリへの大量の書込みを定期的に実行することが予想される場合、ロード・バランサを構成して、アクティブ/パッシブ・モードでOracle Unified Directoryインスタンスにリクエストを分散することを検討してください。こうすることによって、レプリカから古いデータ読み取る機会がなくなりますが、使用しているOracle Unified Directoryホストがすべてのリクエストを処理する能力がない場合、全体のパフォーマンスが低下する可能性があります。

このガイドの目的のために、複数のサーバーにリクエストを処理させる機能の方が保証モードでのリクエストの書込みによって生じる追加のオーバーヘッドより重要であると想定されます。この目的のために、このガイドでは、保証レプリケーションを使用したOracle Unified Directoryの構成を示します。ただし、次のOracle Unified Directoryの構成は両方ともサポートされます。

- 保証構成のアクティブ/アクティブ

- 非保証構成のアクティブ/パッシブ

詳細は、Oracle Fusion Middleware Oracle Unified Directory管理者ガイドの保証レプリケーションに関する項を参照してください。

Oracle Unified Directoryは、通常、内部変更番号を使用して変更を追跡します。変更番号は、各Oracle Unified Directoryインスタンス固有で、あるOracle Unified Directoryインスタンスで障害が発生し、レプリケーションされるエントリがない場合に問題となる可能性があります。このような障害は、Oracle Identity Managerのリコンシリエーションに影響する可能性があります。

パッチ16943171によって、Oracle Identity Managerは、新しく信頼性の高いOracle Unified Directoryメカニズムを使用して変更を追跡できます。これはCookieを使用します。このメカニズムを使用すると、Oracle Unified Directoryのフェイルオーバー時に問題が発生しなくなります。パッチ16943171をインストールした後、Oracle Identity Managerは、リコンシリエーション・ジョブを自動的に作成するときにCookieモードを使用します。カスタム・リコンシリエーション・ジョブを作成することを決定する場合、Oracle Unified DirectoryのCookieモードを強制的に使用するする必要があります。

2.2.2.2.2 Oracle Internet DirectoryおよびOracle Virtual Directoryについて

Oracle Internet Directoryをアイデンティティ・ストアとして使用している場合、これを構成してマルチマスター・レプリケーションを使用できます(『Oracle Fusion Middleware高可用性ガイド』の「最大の高可用性を実現するためのアイデンティティ管理の構成」に記載)。これによって、複数のディレクトリ・サーバーで同じネーミング・コンテキストを保持できます。これにより、問合せを処理するサーバーの数が増え、クライアントの近くにデータを持ってくるため、パフォーマンスが向上します。また、シングル・ポイント障害に関連するリスクを排除することで信頼性が向上します。

Oracle Identity Management (Oracle Internet Directoryを含む)は、Oracle Identity and Access Managementとは異なるリリース・サイクルになっています。使用中のアイデンティティ情報がOracle Internet Directoryにある場合、パッチ適用を容易にするために、Oracle Identity Managementコンポーネント(ODSMなど)を分離されたMW_HOMEおよびドメインに配置することをお薦めします。ただし、コンポーネントを同じドメインに配置することもサポートされています。Oracle Directory Services Managerを使用してディレクトリを管理しない場合、ディレクトリ・トポロジで説明されているように分離されたWebLogicドメインは必要ありません。

Oracle Unified DirectoryまたはOracle Internet Directoryを排他的に使用している場合、Oracle Virtual Directoryを使用する必要はありません。

Oracle Internet DirectoryおよびOracle Virtual Directoryは、次の理由からデータベース層に密接に関連付けられています。

- Oracle Internet Directoryは、そのバックエンドとしてOracle Databaseに依存しています。

- Oracle Virtual Directoryでは、他のLDAPサービスまたはデータベース(あるいはその両方)において仮想化がサポートされています。

2.2.2.2.3 高可用性プロビジョニング

通常アクティブ/アクティブであるディレクトリ・デプロイメントの他に、次の機能によってディレクトリの高可用性が提供されます。

- Oracle Internet Directoryで障害が発生した場合、Oracle Process Management and Notification (OPMN)サーバーはこれを再起動しようとします。

- Oracle Virtual Directoryで障害が発生した場合、Oracle Process Management and Notification (OPMN)サーバーはこれを再起動しようとします。

- Oracle Unified Directoryで障害が発生しても、自動的には再起動されません。Oracle Unified Directoryは、ロード・バランサによって正常なインスタンスにリダイレクトするリクエストを待ちます。

2.2.2.3 アーキテクチャに関する注意

- Oracle Entitlement Serverの埋込みバージョンは、Oracle Fusion Middlewareコンポーネントへのアクセス制御に使用されます。

- Oracle Entitlements Serverは、データベース内に格納されている集中管理されたポリシー・ストアを使用します。

- Access Managerは、OPSSポリシー・ストアを使用して、ポリシー情報を格納します。

- 分割ドメイン構成では、OIMおよびSOAは、他のコンポーネントから分離されたドメインにインストールされます。

- Oracle WebLogic Serverコンソール、Oracle Enterprise Manager Fusion Middleware ControlおよびOracle Access Managementコンソールは、常に管理サーバーのリスニング・アドレスにバインドされます。

- WebLogic管理サーバーはシングルトン・サービスです。一度に1つのノード上でのみ実行されます。障害が発生した場合は、正常なノード上で再起動されます。

- 管理対象サーバーWLS_OAM1およびWLS_OAM2はクラスタにデプロイされ、Access Managerアプリケーションはそのクラスタにデプロイされます。

- 管理対象サーバーWLS_OIM1およびWLS_OIM2はクラスタにデプロイされ、Access Managerアプリケーションはそのクラスタにデプロイされます。

- 管理対象サーバーWLS_SOA1およびWLS_SOA2はクラスタにデプロイされ、Access Managerアプリケーションはそのクラスタにデプロイされます。

2.2.2.4 高可用性プロビジョニング

- OAM Server、Oracle Identity ManagerおよびSOAはアクティブ/アクティブ・デプロイメントです。これらのサーバーは実行時にデータ層と通信します。

- WebLogic管理サーバーとOracle Enterprise Managerのデプロイメントは、アクティブ/パッシブです(他のコンポーネントはアクティブ/アクティブ)。ドメインごとに1つの管理サーバーがあります。

- WebLogic管理サーバーは、アクティブ/パッシブ構成でデプロイされるシングルトン・コンポーネントです。プライマリに障害が発生したときや、IDMHOST1上の管理サーバーが起動しなかったときに、セカンダリ・ホスト上の管理サーバーを起動できます。WebLogic管理対象サーバーで障害が発生すると、このホストで動作しているノード・マネージャはこのサーバーの再起動を試行します。

2.2.2.5 セキュリティ・プロビジョニング

Oracle WebLogic Serverコンソール、Oracle Enterprise Manager Fusion Middleware ControlコンソールおよびOracle Access Managementコンソールには、ロード・バランサ上に構成された仮想ホスト経由でのみアクセスできます。このロード・バランサは、ファイアウォール内でのみ使用できます。

2.2.3 オプションのディレクトリ層について

このガイドでは、通常アプリケーション層に配置されているOracle Unified Directoryの使用を扱っているため、第2.1.1項「デプロイメント・トポロジ」ではディレクトリ層は示していません。ただし、Oracle Internet DirectoryまたはOracle Virtual Directoryを使用している場合、ディレクトリ層が必要になる場合があります。また、通常ディレクトリ層はファイアウォールで保護されているため、セキュリティを向上するためにOracle Unified Directoryをディレクトリ層に配置できます。ディレクトリ層より上にあるアプリケーションは、指定LDAPホスト・ポートによりLDAPサービスにアクセスします。

通常ディレクトリ層は、エンタープライズLDAPサービスをサポートするディレクトリ管理者が管理します。

2.2.4 データベース層について

11gリリース2 (11.1.2)以降、ポリシー情報はデータベースに格納されます。このデータベースは、デプロイされるアイデンティティ管理コンポーネント固有の情報の格納にも使用されます。

場合によっては、ディレクトリ層とデータ層は同じ管理者グループで管理することもあります。ただし、多くの企業ではデータベース管理者がデータ層を所有し、ディレクトリ管理者がディレクトリ層を所有しています。

ダイアグラムには示されていませんが、ディレクトリをデータベース層に配置してセキュリティを向上する必要がある場合があります。これは、情報を格納するためにデータベースにアクセスする必要があるOracle Internet Directoryを使用するデプロイメントで必要とされる可能性が最も高いです。

2.3 エンタープライズ・デプロイメントのハードウェア要件

トポロジ・ダイアグラムで示したデプロイメントは、少数の強力なサーバーを使用し、デプロイメントを単純にします。ただし、このような強力なサーバーの使用は必須ではありません。かわりに、管理対象サーバーを多数の小さいサーバーに分散できます。

ダイアグラムで示したサーバーと同数のサーバーにデプロイすることを計画している場合、これらのサーバーは表2-1に示した最小仕様を備えている必要があります。

詳細要件またはその他のプラットフォームの要件は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

表2-1 標準ハードウェア要件

サーバー

プロセッサ

ディスク

メモリー

TMPディレクトリ

スワップ

データベース・ホストIDMDBHOSTn

1.5GHz以上で動作するX Pentiumが4個以上

nXm

n=ディスク数。最小4個(1個のディスクとしてストライプ化)

m=ディスクのサイズ(最小30GB)

6-16GB

デフォルト

デフォルト

WEBHOSTn

1.5GHz以上で動作するX Pentiumが2個以上

10GB

4GB

デフォルト

デフォルト

IDMHOSTn

1.5GHz以上で動作するX Pentiumが4個以上

20GB

16GB

デフォルト

デフォルト

これらは標準的なハードウェア要件です。層ごとに、負荷、スループット、応答時間などの要件を慎重に考慮して、実際に必要な容量を計画してください。必要なノード数、CPU、およびメモリーは、デプロイメント・プロファイルに応じて層ごとに異なる可能性があります。本番での要件は、アプリケーションおよびユーザー数によって異なる場合があります。

このガイドで説明するエンタープライズ・デプロイメント構成は、それぞれの層に2つのサーバーを使用して、フェイルオーバー機能を提供します。ただし、アプリケーションまたはユーザーの入力に対して適切な計算リソースとはみなされません。システムのワークロードが増えてパフォーマンスが低下する場合、第17.4項「エンタープライズ・デプロイメントのスケーリング」の説明に従ってWebLogicサーバーまたはディレクトリ/OHSインスタンスを追加できます。

注意:

オペレーティング・システム・レベル、パッチ・レベル、ユーザー・アカウント、およびユーザー・グループに関して、トポロジ内のノードすべての構成を同一にすることをお薦めします。

2.4 エンタープライズ・デプロイメントのソフトウェア・コンポーネント

この項では、Oracle Identity Managementエンタープライズ・デプロイメントで必要なソフトウェアについて説明します。

この項には次のトピックが含まれます:

- 第2.4.1項「ソフトウェアのバージョン」

- 第2.4.2項「ソフトウェアの入手について」

- 第2.4.3項「Oracleホームのまとめ」

- 第2.4.4項「ソフトウェアのインストールについて」

- 第2.4.5項「パッチおよび回避策の適用」

2.4.1 ソフトウェアのバージョン

表2-2「使用するソフトウェアのバージョン」に、このガイドの手順を開始する前に入手しておく必要があるOracleソフトウェアを示します。

表2-2 使用するソフトウェアのバージョン

短縮名

製品

バージョン

OHS11G

Oracle HTTP Server

11.1.1.6.0

JRockit

Oracle JRockit

jrockit-jdk1.6.0_29-R28.2.0-4.0.1以降

WLS

Oracle WebLogic Server

10.3.6.0

IAM

Oracle Identity and Access Management

11.1.2.1.0

SOA

Oracle SOA Suite

11.1.1.6.0

Webゲート

WebGate 11g

11.1.2.1.0

RCU

リポジトリ作成アシスタント

11.1.2.1.0

OUD

Oracle Unified Directory

11.1.2.1.0

IDM(オプション)

Oracle Identity Management

11.1.2.1.0

2.4.2 ソフトウェアの入手について

Oracle Fusion Middlewareソフトウェアのダウンロードの詳細は、このリリースのOracle Fusion Middleware 11g リリース1ダウンロード、インストール、構成のReadmeファイル(http://docs.oracle.com/cd/E23104_01/download_readme.htm)を参照してください。

2.4.3 Oracleホームのまとめ

OracleバイナリはOracle Fusion Middlewareホームにインストールされます。個別の製品は、Middlewareホーム内のOracleホームにインストールされます。表2-3は、このドキュメントで使用するMiddlewareホームとOracleホームのまとめです。

Oracle Identity Managementのインストールと構成は、このガイドでは説明しません。詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

表2-3 ホームの概要

ホーム名

ホームの説明

インストールする製品

MW_HOME

Oracle WebLogic Serverホーム、およびオプションで1つ以上のOracleホームから構成されています。

WL_HOME

これは、Oracle WebLogic Serverがインストールされるルート・ディレクトリです。WL_HOMEディレクトリは、Oracleホーム・ディレクトリのピアであり、MW_HOME内にあります。

Oracle WebLogic Server

IDM_ORACLE_HOME

Oracle Identity Management用のバイナリ・ファイルおよびライブラリ・ファイルを格納します。IAM_MW_HOME/idm内にあります。

Oracle Internet Directory

Oracle Virtual Directory

Oracle Directory Services Manager

IAM_ORACLE_HOME

Oracle Identity and Access Managementに必要なバイナリ・ファイルおよびライブラリ・ファイルを格納します。IAM_MW_HOME/iam内にあります。

Oracle Access Manager

Oracle Identity Management

OUD_ORACLE_HOME

Oracle Unified Directoryに必要なバイナリ・ファイルおよびライブラリ・ファイルを格納します。IAM_MW_HOME/oud内にあります。

Oracle Unified Directory

WEB_ORACLE_HOME

Oracle HTTP Serverに必要なバイナリ・ファイルおよびライブラリ・ファイルを格納します。

WEB_MW_HOME/web内にあります。

Oracle Webゲート

SOA_ORACLE_HOME

Oracle SOA Suiteに必要なバイナリおよびライブラリ・ファイルを格納します。OIMを含むトポロジを作成する場合のみ必要で、MW_HOME/soa内にあります。

Oracle SOA Suite

ORACLE_COMMON_HOME

汎用Oracleホーム・ファイルを格納します。このOracleホームは、いずれかの製品をインストールすると自動的に作成され、MW_HOME/oracle_common内にあります。

汎用コマンド

2.4.4 ソフトウェアのインストールについて

インストール・メディアにあるOracleインストーラを使用してソフトウェアのインストールを実行します。このガイドでは、第4章「エンタープライズ・デプロイメント用の記憶域の準備」で説明されているように、ソフトウェアを異なるディレクトリにデプロイします。

実行する必要があるインストール・タスクは、次のようにまとめることができます。

- Web層のホストにあるローカル記憶域にOHSをインストールします。

- Web層のホストにあるローカル記憶域にOracle Webゲートをインストールします。

- アプリケーション層のホストで使用できる共有記憶域にOracle WebLogic Serverをインストールします。

- アプリケーション層のホストで使用できる共有記憶域にOracle Identity and Access Managementをインストールします。

- Oracle Unified Directoryを使用している場合、アプリケーション層のホストで使用できる共有記憶域にOracle Unified Directoryをインストールします。

- Oracle Internet DirectoryまたはOracle Virtual Directoryを使用している場合、データ層のホストにOracle Identity Managementをインストールします。これらの製品を使用する計画があるが高可用性ディレクトリがない場合、『Oracle Fusion Middleware高可用性ガイド』の説明に従って、高可用性ディレクトリを作成する必要があります。Oracle Internet DirectoryまたはOracle Virtual Directoryの他に、Oracle Internet DirectoryおよびOracle Virtual Directory用にODSMもインストールする必要があります。

分割ドメイン構成を作成している場合、Oracle Identity Managementをアプリケーション層上の2つの分離された場所にインストールし、独立したパッチ適用を容易にする必要があります。

Oracleソフトウェアのインストールの詳細手順は、このドキュメントのコンポーネントの章を参照してください。

Oracle Internet DirectoryやOracle Virtual Directoryなど、製品によっては、一部のファイルのアクセス権をrootに設定するスクリプトを実行する必要があります。

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

2.4.5 パッチおよび回避策の適用

適用するパッチのリストは、使用中のプラットフォームおよびオペレーティング・システムに関するOracle Fusion Middlewareリリース・ノートを参照してください。ソフトウェアを期待どおりに動作させるには、パッチを適用する必要があります。

注意:

特に、次のトポロジ・ダイアグラムに示すようにOracle Unified Directoryをアクティブ/アクティブ・モードで使用している場合、パッチ16943171は重要です。このパッチを適用しないと、フェイルオーバー・イベントの際にデータの不整合が発生する可能性があります。

パッチはhttp://support.oracle.comからダウンロードできます。各パッチをデプロイする手順は、同封のREADME.htmlファイルにあります。

2.5 参照用トポロジのインストールおよび構成のロード・マップ

Oracle Identity Managementエンタープライズ・デプロイメントを開始する前に、図2-4「Oracle Identity Managementエンタープライズ・デプロイメント処理のフロー・チャート」のフロー・チャートを確認してください。このフロー・チャートは、このガイドで説明するエンタープライズ・デプロイメントを完成させるための大まかなプロセスを示しています。表2-4はこのフロー・チャート内の手順を説明するものであり、ここから各手順の項または章にジャンプできます。

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

- 第2.5.1項「Oracle Identity Managementエンタープライズ・デプロイメント処理のフロー・チャート」

- 第2.5.2項「Oracle Identity Managementエンタープライズ・デプロイメント処理の手順」

2.5.1 Oracle Identity Managementエンタープライズ・デプロイメント処理のフロー・チャート

図2-4「Oracle Identity Managementエンタープライズ・デプロイメント処理のフロー・チャート」は、Oracle Identity Managementエンタープライズ・デプロイメント処理のフロー・チャートです。このチャートを確認し、既存の環境に基づいた実行手順を理解してください。

図2-4 Oracle Identity Managementエンタープライズ・デプロイメント処理のフロー・チャート

2.5.2 Oracle Identity Managementエンタープライズ・デプロイメント処理の手順

表2-4では、図2-4で示したOracle Identity Managementのエンタープライズ・デプロイメント処理のフロー・チャートの各手順を説明します。この表では、処理における各手順の詳細について、その参照先も示します。

表2-4 Oracle Identity Managementエンタープライズ・デプロイメント処理の手順

手順

説明

詳細

エンタープライズ・デプロイメント用のネットワークの準備

エンタープライズ・デプロイメント用のネットワークを準備するには、仮想サーバー名、IP、仮想IPなどの概念を理解し、仮想ホスト名を定義してロード・バランサを構成する必要があります。

第3章「エンタープライズ・デプロイメント用のネットワークの準備」

エンタープライズ・デプロイメント用の記憶域の準備

エンタープライズ・デプロイメント用のファイル・システムを準備するには、ディレクトリおよびディレクトリ環境変数の用語を理解し、共有記憶域を構成する必要があります。

第4章「エンタープライズ・デプロイメント用の記憶域の準備」

エンタープライズ・デプロイメント用のサーバーの準備

エンタープライズ・デプロイメント用のサーバーを準備するには、サーバーがハードウェア要件およびソフトウェア要件を満たしていることを確認し、Unicodeサポートおよび仮想IPアドレスを有効にし、共有記憶域をマウントし、ユーザーおよびグループを構成し、必要に応じてソフトウェアを複数のホームを持つシステムにインストールします。

第5章「エンタープライズ・デプロイメント用のサーバーの準備」

エンタープライズ・デプロイメント用のデータベースの準備

エンタープライズ・デプロイメント用のデータベースを準備するには、データベース要件の確認、データベース・サービスの作成、Oracle RACデータベースへのメタデータ・リポジトリのロード、トランザクション・リカバリ権限用アイデンティティ管理スキーマの構成およびデータベースのバックアップを実行する必要があります。

第6章「エンタープライズ・デプロイメント用のデータベースの準備」

Oracle Unified Directory用のドメインの拡張

構成ウィザードを実行してOracle Unified Directoryを構成することによって既存のWebLogicドメインを拡張します。

第7章「Oracle Unified Directoryのインストールおよび構成」

ドメインの作成

構成ウィザードを実行して、ドメイン(OIMDomain)を作成し、OAMおよびOIMを組み込みます。

第8章「エンタープライズ・デプロイメント用のドメインの作成」

アイデンティティ・ストアとポリシー・ストアの準備

Oracle Identity Managementエンタープライズ・デプロイメントのアイデンティティ・ストアおよびポリシー・ストアを準備します。

第9章「アイデンティティ・ストアの準備」

Web層の構成

Oracle Web層をOracle WebLogicドメインに関連付け、Oracle HTTP Serverをロード・バランサとともに構成し、仮想ホスト名を構成することでOracle Web層を構成します。

第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」

Oracle Access Management用のドメインの拡張

構成ウィザードを再度実行し、Oracle Access Managementを追加するためにドメインを拡張します。

第11章「Oracle Access Managementを追加するためのドメインの拡張」

Oracle Identity Manager用のドメインの拡張

構成ウィザードを再度実行し、Oracle Identity Managerを追加するためにドメインを拡張します。

第12章「Oracle Identity Managerを追加するためのドメインの拡張」

ノード・マネージャの設定

ホスト名検証を有効化し、ノード・マネージャを起動して、カスタム・キーストアを使用するようにWebLogic Serverを構成し、ノード・マネージャを設定します。

第13章「エンタープライズ・デプロイメント用のノード・マネージャの設定」

サーバー移行の構成

WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2の各管理対象サーバーのサーバー移行を構成します。管理対象サーバーWLS_OIM1およびWLS_SOA1は、障害発生時にIDMHOST2上で再起動されるように構成されます。管理対象サーバーWLS_OIM2およびWLS_SOA2は、障害発生時にIDMHOST1上で再起動されるように構成されます。

第14章「エンタープライズ・デプロイメント用のサーバー移行の構成」

エンタープライズ・デプロイメントで管理コンソールのシングル・サインオンを構成します。

アイデンティティ管理エンタープライズ・デプロイメントで管理コンソールのシングル・サインオン(SSO)を構成します。

第15章「エンタープライズ・デプロイメントにおける管理コンソールのシングル・サインオンの構成」

3 エンタープライズ・デプロイメント用のネットワークの準備

この章では、Oracle Identity Managementインフラストラクチャのエンタープライズ・デプロイメント・トポロジの前提条件について説明します。

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

- 第3.1項「エンタープライズ・デプロイメント用のネットワークの準備の概要」

- 第3.2項「ネットワークの計画」

- 第3.3項「トポロジで使用する仮想サーバー名について」

- 第3.4項「ロード・バランサの構成」

- 第3.5項「IPアドレスおよび仮想IPアドレスについて」

- 第3.6項「ファイアウォールとポートについて」

- 第3.7項「Access Manager通信プロトコルの管理」

3.1 エンタープライズ・デプロイメント用のネットワークの準備の概要

様々な種類のネットワーク・トラフィックや監視に対応するように、仮想サーバーや関連するポートをロード・バランサに構成する必要があります。これらの仮想サーバーは、サービスを実行するために適切な実際のホストおよびポートに対して構成する必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これにより、特定の仮想ホストの受信トラフィックが、他の層にある使用できないサービスに送信されないようになります。

3.2 ネットワークの計画

第2.2項「トポロジについて」のデプロイメント・トポロジの図に示すように、各デプロイメントは複数のゾーン間に広がっています。ゾーンは、インフラストラクチャのコンポーネントへのアクセスを実際にアクセスを必要とする人に制限する方法です。このガイドの例では、2つのゾーンを示します。

- パブリック・ゾーン: ここでは外部からシステムにアクセスできます。ロード・バランサやWeb層など外部からアクセスする必要があるコンポーネントのみをこのゾーンに配置します。このゾーンの下の任意のサーバーまたはサービスに外部のユーザーがアクセスしようとすると、ファイアウォールがアクセスを阻止します。
パブリック・ゾーンは、このゾーンのサーバーがプライベート・ゾーンのアプリケーション・サーバーとやり取りできるように構成されます。

- イントラネットゾーン: これは、データベースなどのコア・サービスを含むサーバーを配置する場所です。これらのサービスは、最も機密性の高いデータが含まれているため、組織によって非常に厳密に制御されます。

この方法を使用することによって、情報を必要とするコンポーネントのみに情報へのアクセスを制限します。この方法は、組織の外部のユーザーがいる場合に有効です。エクストラネットのかわりに(すべての通信が信頼できるソースからである)イントラネットを設定している場合、ゾーンの1つまたは複数を合理的に廃棄できる場合があります。

3.3 トポロジで使用する仮想サーバー名について

仮想サーバー名はロード・バランサ上で構成されます。指定のIPアドレスで受信したトラフィックをそのIPアドレスと関連付けられた専用サーバーのプールに分散するようにロード・バランサを構成できます。

このロード・バランサのIPアドレスは、仮想サーバー名と呼ばれる名前と関連付けられています。この名前はDNSで定義されます。ロード・バランサはHTTPヘッダーにこの名前を格納し、Oracle HTTP Serverによって識別できるようにしています。

この項には次のトピックが含まれます:

- 第3.3.1項「仮想ホスト名」

- 第3.3.2項「仮想サーバー名」

3.3.1 仮想ホスト名

ロード・バランサは、これらの仮想ホスト名が使用される領域でアクセスできるような方法でDNSが設定される際に必要なアクセスに応じて、複数の仮想ホスト名を使用して構成されます。例:

パブリック通信は、組織の内部と外部の両方で解決可能な仮想ホストを使用して構成されます。

プロセス間通信は、プライベート・ゾーンでのみ解決可能な仮想ホストを使用して構成されます。

管理アクセスは、組織内でのみ解決可能です。

3.3.2 仮想サーバー名

Identity Managementエンタープライズ・トポロジは、次の仮想サーバー名を使用します。

- IDSTORE.mycompany.com

- ADMIN.mycompany.com

- IDMINTERNAL.mycompany.com

- SSO.mycompany.com

仮想サーバー名がIPアドレスと関連付けられており、DNSの一部になっていることを確認してください。Oracle Fusion Middlewareを実行するコンピュータでは、これらの仮想サーバー名を解決できる必要があります。

第3.4項「ロード・バランサの構成」の手順に従って、ロード・バランサで仮想サーバー名を定義します。

このガイドの残りの部分では、デプロイメントは第2章「導入と計画」で示したデプロイメントの1つであることを前提とします。

3.3.2.1 IDSTORE.mycompany.com

- この仮想サーバーはLBR2上で有効になっています。これは、すべてのアイデンティティ・ストアLDAPトラフィックに対してアクセス・ポイントの役割を果たします。SSLと非SSLの両方へのトラフィックが構成されます。クライアントは、アドレスIDSTORE.mycompany.com:636 (SSLの場合)およびIDSTORE.mycompany.com:389(非SSLの場合)を使用してこのサービスにアクセスします。

- アイデンティティ・ストアにOracle Virtual Directory経由でアクセスする場合は、OVDHOST1およびOVDHOST2上でOracle Virtual Directoryプロセスのハートビートを監視します。Oracle Virtual Directoryプロセスが停止した場合、ロード・バランサは稼動しているOracle Virtual DirectoryインスタンスへのLDAPトラフィックのルーティングを継続する必要があります。

- アイデンティティ・ストアがOracle Internet Directory内にあり、直接アクセスを受ける場合は、Oracle Internet Directoryホスト上でOracle Internet Directoryプロセスのハートビートを監視します。Oracle Internet Directoryプロセスが停止した場合、ロード・バランサは稼動しているOracle Internet DirectoryインスタンスへのLDAPトラフィックのルーティングを継続する必要があります。

- アイデンティティ・ストアがOracle Unified Directoryに配置されていて、直接アクセスされる場合、Oracle Unified Directoryプロセスのハートビートを監視します。Oracle Unified Directoryプロセスが停止した場合、ロード・バランサは稼動しているOracle Unified DirectoryインスタンスへのLDAPトラフィックのルーティングを継続する必要があります。

- アイデンティティ・ストアがOracle Unified Directoryに配置されている場合、この仮想サーバーは、ポート389 (LDAP_LBR_PORT)で受信したトラフィックをポート1389 (LDAP_DIR_PORT)でOracle Unified Directoryの各インスタンスに転送します。

- アイデンティティ・ストアがOracle Unified Directoryに配置されている場合、この仮想サーバーは、ポート636 (LDAP_LBR_SSL_PORT)で受信したトラフィックをポート1636 (LDAP_DIR_SSL_PORT)でOracle Unified Directoryの各インスタンスに転送します。

- アイデンティティ・ストアがOracle Internet Directoryに配置されている場合、この仮想サーバーは、ポート389 (LDAP_LBR_PORT)で受信したトラフィックをポート3060でOracle Internet Directoryの各インスタンスに転送します。

- アイデンティティ・ストアがOracle Internet Directoryに配置されている場合、この仮想サーバーは、ポート636 (LDAP_LBR_SSL_PORT)で受信したトラフィックをポート3131でOracle Internet Directoryの各インスタンスに転送します。

- アイデンティティ・ストアがOracle Virtual Directoryに配置されている場合、この仮想サーバーは、ポート389 (LDAP_LBR_PORT)で受信したトラフィックをポート6501でOracle Virtual Directoryの各インスタンスに転送します。

- アイデンティティ・ストアがOracle Virtual Directoryに配置されている場合、この仮想サーバーは、ポート636 (LDAP_LBR_SSL_PORT)で受信したトラフィックをポート7501でOracle Virtual Directoryの各インスタンスに転送します。

3.3.2.2 ADMIN.mycompany.com

- この仮想サーバーはLBR1上で有効になっています。管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスADMIN.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (OHS_PORT)に転送されます。この仮想ホストでアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle Authorization Policy Manager、Oracle Directory Services Managerなどがあります。

- ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/console URLおよび/em URLにアクセスすることを防止します。DMZ内部のトラフィックのみがADMIN.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。

3.3.2.3 IDMINTERNAL.mycompany.com

- この仮想サーバーはLBR1上で有効になっています。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントは、アドレスIDMINTERNAL.mycompany.com:80を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (OHS_PORT)に転送されます。SOA管理対象サーバーは、この仮想ホストにアクセスして、Oracle Identity Manager Webサービスのコールバックを行います。

- ファイアウォールでルールを作成し、外部トラフィックがこの仮想ホストにアクセスすることを防止します。DMZ内部のトラフィックのみがIDMINTERNAL.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。

3.3.2.4 SSO.mycompany.com

- これは、すべてのアイデンティティ管理コンポーネント(Oracle Access Management、Oracle Identity Managerなど)に対する仮想名です。

- この仮想サーバーはLBR1上で有効になっています。これは、シングル・サインオン・サービスに送信されるすべてのHTTPトラフィックのアクセス・ポイントとして機能します。クライアントからの受信トラフィックはSSLに対応しています。このため、クライアントはアドレスSSO.mycompany.com:443を使用してこのサービスにアクセスし、トラフィックはWEBHOST1およびWEBHOST2のポート7777 (OHS_PORT)に転送されます。シングル・サインオン対応の保護リソースへのアクセスは、すべてこの仮想ホスト上で行われます。

- ロード・バランサでポート80 (HTTP_PORT)とポート443 (HTTP_SSL_PORT)の両方を使用してこの仮想サーバーを構成します。

- この仮想ホストは、リクエストのクライアントIPアドレスを保持するように構成する必要があります。一部のロード・バランサでは、ロード・バランサを有効にしてリクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入することにより、これを構成します。

3.4 ロード・バランサの構成

ロード・バランサ上には、各種のネットワーク・トラフィックおよび監視用に、いくつかの仮想サーバーおよびそれらに関連付けられたポートを構成する必要があります。これらは、サービスを実行するために適切な実際のホストおよびポートに対して構成する必要があります。また、ロード・バランサは、可用性を確保するために実際のホストおよびポートを監視するように構成し、サービスがダウンしたときにこれらのホストおよびポートへのトラフィックをできるだけ早く停止できるようにする必要があります。これにより、特定の仮想ホストの受信トラフィックが、他の層にある使用できないサービスに送信されないようになります。

推奨トポロジ内には、2つのロード・バランサ・デバイスがあります。一方のロード・バランサは外部HTTPトラフィック用に設定し、もう一方のロード・バランサは内部LDAPトラフィック用に設定します。様々な理由から、デプロイメントで使用されるロード・バランサ・デバイスが1つになる場合があります。このような構成もサポートされていますが、これに伴うセキュリティへの影響を考慮する必要があります。その構成が適切であることがわかったら、様々なゾーン間のトラフィックを許可するように、関連するファイアウォール・ポートを開いてください。いずれの場合も、特定のロード・バランサ・デバイスをフォルト・トレラント・モードでデプロイすることを強くお薦めします。

この項には次のトピックが含まれます:

- 第3.4.1項「ロード・バランサの要件」

- 第3.4.2項「ロード・バランサの構成手順」

- 第3.4.3項「ロード・バランサの構成」

3.4.1 ロード・バランサの要件

エンタープライズ・トポロジでは、外部のロード・バランサを使用します。この外部ロード・バランサは次の機能を備えている必要があります。

- 仮想ホスト名を使用してトラフィックを実際のサーバーのプールにロード・バランシングする機能: クライアントは仮想ホスト名を使用してサービスにアクセスします(実際のホスト名は使用しない)。ロード・バランサは、リクエストをプールのサーバーにロード・バランスできるようになります。

- ポート変換の構成。

- ポート(HTTPおよびHTTPS)の監視。

- 仮想サーバーとポート構成: 外部ロード・バランサの仮想サーバー名とポートを構成する機能。仮想サーバー名とポートは次の要件を満たす必要があります。

- ロード・バランサは複数の仮想サーバーの構成が可能である必要がある。各仮想サーバーに対して、ロード・バランサは複数のポート上でトラフィック管理の構成を行える必要があります。たとえば、Oracle WebLogicクラスタの場合は、1つの仮想サーバーとHTTPおよびHTTPSの両トラフィック用のポートを指定してロード・バランサを構成する必要があります。

- 仮想サーバー名は、IPアドレスに関連付けられていて、DNSの一部である必要がある。クライアントは仮想サーバー名を使用して外部ロード・バランサにアクセスできる必要があります。

- ノードの障害を検出し、障害のあるノードへのトラフィックのルーティングを即時に停止する機能。

- リソースの監視/ポートの監視/プロセス障害の検出: ロード・バランサは、サービス障害およびノード障害を(通知またはその他の方法によって)検出し、障害のあるノードへの非Oracleネット・トラフィックの転送を停止する必要があります。ご使用の外部ロード・バランサに障害の自動検出機能がある場合、これを使用する必要があります。

- フォルト・トレラント・モード: ロード・バランサはフォルト・トレラント・モードで構成することを強くお薦めします。

- その他: トラフィックの転送先となるバックエンド・サービスが使用不可の場合に、即座にコール元クライアントに戻るようにロード・バランサの仮想サーバーを構成しておくことを強くお薦めします。これは、クライアントのマシンのTCP/IP設定に基づくタイムアウトの後、自ら接続解除するクライアントに対して好ましい構成です。

- SSLアクセラレーション: SSLトランザクションで実行され、公開鍵暗号化アルゴリズムをハードウェア・アクセラレータにオフロードします。この機能は推奨されますが、必須ではありません。

- SSLリクエストをロード・バランサで終了して、同等の非SSLプロトコルを使用してトラフィックを実際のバックエンド・サーバーに転送する機能。たとえば、ロード・バランサは、HTTPSリクエストをHTTPとして転送できる必要があります。この機能は「SSL終端」と呼ばれることがあります。これは、このエンタープライズ・デプロイメントで必要です。

- クライアントIPアドレスを保持する機能: ロード・バランサには、リクエストの元のクライアントIPアドレスをX-Forwarded-For HTTPヘッダーに挿入し、クライアントIPアドレスを保持する機能がある必要があります。

- WL-Proxy-SSL: trueをHTTP要求ヘッダーに追加する機能。これを自動で行うロード・バランサもあります。

3.4.2 ロード・バランサの構成手順

ロード・バランサの構成手順は、ロード・バランサの特定のタイプによって異なります。実際の手順は、ベンダーが提供するドキュメントを参照してください。次の手順では、一般的な構成フローを示します。

1. サーバーのプールを作成します。このプールには、ロード・バランシング定義に含まれるサーバーおよびポートのリストが存在します。たとえば、Webホスト間のロード・バランシングの場合、リクエストをポート7777 (OHS_PORT)でWEBHOST1およびWEBHOST2のホストに送信するサーバーのプールを作成します。

2. 特定のホストとサービスが使用可能かどうかを決定するルールを作成し、手順1で説明したサーバーのプールに割り当てます。

3. ロード・バランサ上に仮想サーバーを作成します。これは、アプリケーションにより使用されるリクエストを受信するアドレスとポートです。たとえば、Web層のリクエストをロード・バランシングするには、SSO.mycompany.com:80に対する仮想ホストを作成します。

4. ロード・バランサでサポートされている場合は、仮想サーバーが内部から、外部から、またはその両方から利用できるのかどうかを指定します。内部アドレスはネットワーク内からのみ解決可能であることを確認します。

5. 適用可能な場合は、仮想サーバーに対するSSL終端を構成します。

6. 手順1で作成したサーバーのプールを、仮想サーバーに割り当てます。

7. 表3-3「Oracle Identity Managementエンタープライズ・デプロイメント・トポロジで使用されるポート」にリストされているタイムアウト設定を調整します。これには、サービスが停止しているかどうかを検出する時間も含まれます。

3.4.3 ロード・バランサの構成

アイデンティティ管理デプロイメントの場合、表3-1に示すようにロード・バランサを構成します。

表3-1 ロード・バランサの構成

仮想ホスト

サーバー・プール

プロトコル

SSL終端

外部

必要なその他の構成/コメント

SSO.mycompany.com:80

WEBHOST1.mycompany.com:7777

WEBHOST2.mycompany.com:7777

HTTP

いいえ

はい

アイデンティティ管理では、次のコードをHTTPヘッダーに追加する必要があります。

Header Name: IS_SSL脚注 1

Header Value: ssl

SSO.mycompany.com:443

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

はい

はい

アイデンティティ管理では、次のコードをHTTPヘッダーに追加する必要があります。

Header Name: IS_SSL

Header Value: ssl

ADMIN.mycompany.com:80

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

いいえ

いいえ

IDMINTERNAL.mycompany.com:80

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

いいえ

いいえ

IDSTORE.mycompany.com:389

IDMHOST1.mycompany.com:1389

IDMHOST2.mycompany.com:1389

LDAP

いいえ

いいえ

アイデンティティ管理ユーザーがOracle Unified Directoryに格納されている場合のみ必要です。

IDSTORE.mycompany.com:636

IDMHOST1.mycompany.com:1636

IDMHOST2.mycompany.com:1636

LDAP

いいえ

いいえ

アイデンティティ管理ユーザーがOracle Unified Directoryに格納されている場合のみ必要です。

IDSTORE.mycompany.com:389

OIDHOST1.mycompany.com:3060 OIDHOST2.mycompany.com:3060

LDAP

いいえ

いいえ

通常これは、OIDのインストールの一部として設定済です。OIDに対してLDAPコールをロード・バランスするために使用されます。

IDSTORE.mycompany.com:636

OIDHOST1.mycompany.com:3131 OIDHOST2.mycompany.com:3131

LDAP

いいえ

いいえ

通常これは、OIDのインストールの一部として設定済です。OIDに対してLDAPコールをロード・バランスするために使用されます。

IDSTORE.mycompany.com:389

OVDHOST1.mycompany.com:6501 OVDHOST2.mycompany.com:6501

LDAP

いいえ

いいえ

通常これは、OVDのインストールの一部として設定済です。OVDに対してLDAPコールをロード・バランスするために使用されます。

IDSTORE.mycompany.com:636

OVDHOST1.mycompany.com:7501 OVDHOST2.mycompany.com:7501

LDAP

いいえ

いいえ

通常これは、OVDのインストールの一部として設定済です。OVDに対してLDAPコールをロード・バランスするために使用されます。

脚注 1 IS_SSLの構成の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のユーザー定義のWebゲート・パラメータに関する項を参照してください。

3.5 IPアドレスおよび仮想IPアドレスについて

仮想IPアドレスは、ホストの主要IPアドレスと同じサブネットに属する、未使用のIPアドレスです。このアドレスはホストに手動で割り当てられ、Oracle WebLogic管理対象サーバーはこのIPアドレスをリスニングするように構成されます。IPアドレスが割り当てられたノードに障害が発生した場合は、割り当てられた管理対象サーバーの実行を新しいノードが引き継ぐことができるように、このIPアドレスは同じサブネット内の別のノードに割り当てられます。

次に、Oracle Identity Managementが必要とする仮想IPアドレスのリストを示します。

- ADMINVHN.mycompany.com
エンタープライズ・デプロイメントでは、WebLogic管理サーバーが、配置されているホストに障害が発生した後でも、リクエストの処理を継続できることが必要です。仮想IPアドレスは、アプリケーション層内の任意のホスト上でネットワーク・インタフェースにバインドできるように、アプリケーション層内でプロビジョニングされる必要があります。WebLogic管理サーバーは、後でこの仮想IPアドレスをリスニングするように構成されます。これについては、本ドキュメントで後述します。この仮想IPアドレスは、管理サーバーとともに、IDMHOST1からIDMHOST2に(またはIDMHOST2からIDMHOST1に)フェイルオーバーします。

- SOAHOSTXVHN.mycompany.com
SOA管理対象サーバーごとに1つの仮想IPアドレスが必要です。これにより、サーバーをサーバー移行の処理対象にすることができます。

アプリケーション層内で仮想IPアドレスをプロビジョニングすることにより、アプリケーション層にある任意のホストのネットワーク・インタフェースにこのアドレスをバインドできるようにします。

- OIMHOSTXVHN.mycompany.com
Oracle Identity Manager管理対象サーバーごとに1つの仮想IPアドレスが必要です。これにより、サーバーをサーバー移行の処理対象にすることができます。

アプリケーション層内で仮想IPアドレスをプロビジョニングすることにより、アプリケーション層にある任意のホストのネットワーク・インタフェースにこのアドレスをバインドできるようにします。

図3-1に示すように、異なる仮想IPと物理IPでリスニングするように、管理サーバーと管理対象サーバーを構成してください。

図3-1 IPアドレスおよびVIPアドレス

表3-2には、様々な仮想ホストの説明が記載されています。

表3-2 VIPアドレスおよび仮想ホスト

仮想IP

VIPのマップ先

説明

VIP1

ADMINVHN

ADMINVHNは、管理サーバーのリスニング・アドレスである仮想ホスト名であり、管理サーバーの手動フェイルオーバーによりフェイルオーバーします。管理サーバー・プロセスが実行されているノード(デフォルトはIDMHOST1)で有効化されます。

VIP2

SOAHOST1VHN

SOAHOST1VHNは、WLS_SOA1のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA1プロセスが実行されているノード(デフォルトはIDMHOST1)で有効化されます。

VIP3

OIMHOST1VHN

OIMHOST1VHNは、WLS_OIM1サーバーのリスニング・アドレスにマップし、このサーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_OIM1プロセスが実行されているノード(デフォルトはIDMHOST1)で有効化されます。

VIP4

SOAHOST2VHN

SOAHOST2VHNは、WLS_SOA2のリスニング・アドレスにマップし、この管理対象サーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_SOA2プロセスが実行されているノード(デフォルトはIDMHOST2)で有効化されます。

VIP5

OIMHOST2VHN

OIMHOST2VHNは、WLS_OIM2サーバーのリスニング・アドレスにマップし、このサーバーのサーバー移行によりフェイルオーバーする、仮想ホストの名前です。これは、WLS_OIM2プロセスが実行されているノード(デフォルトはIDMHOST2)で有効化されます。

3.6 ファイアウォールとポートについて

多くのOracle Fusion Middlewareコンポーネントとサービスではポートを使用します。管理者はこれらのサービスに使用するポート番号を把握し、ホスト上の2つのサービスが同じポート番号を使用しないようにする必要があります。

ほとんどのポート番号はインストール後に割り当てられます。必要に応じて別のポート番号を使用できます。表3-3に示したポート番号は、一貫性を保つためにこのガイド全体にわたって使用する例です。別のポート番号を使用する場合、その値が使用される場所では必ずその値を表の値のかわりに使用する必要があります。

表3-3は、Oracle Identity Managementトポロジで使用されるポートの一覧です。これには、トポロジ内のファイアウォール上で開く必要があるポートが含まれます。

ファイアウォールの表記法

- FW0は、最も外側のファイアウォールを表します。

- FW1は、Web層とアプリケーション層の間のファイアウォールを表します。

- FW2は、アプリケーション層とデータベース層の間のファイアウォールを表します。

付録Bのポート・マッピング・ワークシートを使用して、ポートの使用を追跡できます。

表3-3 Oracle Identity Managementエンタープライズ・デプロイメント・トポロジで使用されるポート

タイプ

ファイアウォール

ポートとポートの範囲

プロトコル/アプリケーション

インバウンド/アウトバウンド

タイムアウト

ブラウザ・リクエスト

FW0

80

HTTP/ロード・バランサ

両方

Oracle Identity Managementで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツに応じて、タイムアウトは異なります。

ブラウザ・リクエスト

FW0

443

HTTPS/ロード・バランサ

両方

Oracle Identity Managementで使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツに応じて、タイムアウトは異なります。

ブラウザ・リクエスト

FW1

80

HTTPS/ロード・バランサ

アウトバウンド(イントラネット・クライアント)

タイムアウトは、IDMによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

ブラウザ・リクエスト

FW1

443

HTTPS/ロード・バランサ

アウトバウンド(イントラネット・クライアント)

タイムアウトは、IDMによって使用されるプロセス・モデルのタイプとすべてのHTMLコンテンツによって異なります。

ロード・バランサからOracle HTTP Serverへ

n/a

7777

HTTP

n/a

第3.4項「ロード・バランサの構成」を参照してください。

管理サーバーによるOHS登録

FW1

7001

HTTP/t3

インバウンド

タイムアウトを短い時間(5から10秒)に設定します。

Web層からのOracle WebLogic管理サーバー・アクセス

FW1

7001

HTTP/Oracle HTTP Serverと管理サーバー

インバウンド

N/A

Enterprise Managerエージェント - Web層からEnterprise Managerへ

FW1

5160

HTTP/Enterprise ManagerエージェントとEnterprise Manager

両方

N/A

Oracle HTTP ServerからWLS_OAMへ

FW1

14100

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。

Oracle HTTP ServerWLS_OIM

FW1

14000

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。

Oracle HTTP ServerWLS_SOA

FW1

8001

HTTP/Oracle HTTP ServerからWebLogic Serverへ

両方

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります。

管理サーバーによるOracle HTTP Serverの管理

FW1

OPMNのリモート・ポート(6701)およびOHSの管理ポート(7779)

それぞれTCPとHTTP

アウトバウンド

タイムアウトを短い時間(5-10秒など)に設定します。

OAMサーバー

FW1

5575

OAP

両方

N/A

Access Manager Coherenceポート

FW1

9095

TCMP

両方

N/A

Oracle Coherenceポート

FW1

8000 - 8088

TCMP

両方

N/A

ディレクトリ層からのIDMDomain Oracle WebLogic管理サーバー・アクセス

FW2

7001

HTTP/Oracle Internet Directory、Oracle Virtual Directory、および管理サーバー

アウトバウンド

N/A

Enterprise Managerエージェント: ディレクトリ層からEnterprise Managerへ(ディレクトリ層が実装されている場合)。

FW2

5160

HTTP/Enterprise ManagerエージェントとEnterprise Manager

両方

N/A

Oracle HTTP Serverから管理サーバーへ

FW2

OPMNリモート・ポート

HTTP/管理サーバーからOPMNへ

インバウンド

N/A

アプリケーション層からデータベース・リスナーへ

FW2

1521

SQL*Net

両方

Oracle Identity Managementで使用されるプロセス・モデルのタイプとすべてのデータベース・コンテンツに応じて、タイムアウトは異なります。

Oracle Notification Server (ONS)

FW2

6200

ONS

両方

Gridlink用に必要。ONSサーバーは各データベース・サーバー上で稼働します。

LDAPポート

FW2

ディレクトリに依存

LDAP

インバウンド

理想的には、タイムアウトが発生しないようにこれらの接続を構成します。

LDAP SSLポート

FW2

ディレクトリに依存

LDAP SSL

インバウンド

理想的には、タイムアウトが発生しないようにこれらの接続を構成します。

ノード・マネージャ

N/A

5556

TCP/IP

N/A

N/A

注意:

外部ドメイン(SOA、WebCenter Portalドメインなど)のアプリケーションをこのアイデンティティ管理ドメインで認証できるように、ファイアウォール間で追加のポートを開く必要が生じることがあります。

3.7 Access Manager通信プロトコルの管理

ここでは、Oracle Accessプロトコル(OAP)について説明し、ユーザー・リクエストの概要を示します。

この項には次のトピックが含まれます:

- 第3.7.1項「Access Managerプロトコル」

- 第3.7.2項「統合リクエストの概要」

- 第3.7.3項「ユーザー・リクエストの概要」

- 第3.7.4項「通信のユニキャスト要件について」

3.7.1 Access Managerプロトコル

Oracle Accessプロトコル(OAP)は、ユーザー認証および認可の間に、アクセス・システム・コンポーネント(OAMサーバー、Webゲートなど)間の通信を可能にします。このプロトコルは、以前NetPointアクセス・プロトコル(NAP)またはCOREidアクセス・プロトコルと呼ばれていました。

3.7.2 統合リクエストの概要

Oracle Access Management Access Managerは、ユーザーのセッションを作成します。Access Managerが別のアイデンティティ管理コンポーネント(Oracle Identity Managerなど)と統合すると、認証はそのコンポーネントに委任されます。

典型的なリクエスト・フローは次のようになります。

1. ユーザーは、最初にリソースにアクセスしようとします。

2. Webゲートは、リクエストを捕捉し、ユーザーが認証されていないことを検出します。

3. Access Managerの資格証明コレクタが呼び出され、ユーザーはプロンプトに応答してユーザー名およびパスワードを入力します。Access Managerは、パスワード・ポリシーが最初のログイン時にパスワードの変更を要求することを認識しているため、ユーザーのブラウザはOracle Identity Managerにリダイレクトされます。

4. ユーザーは、パスワードの変更およびチャレンジ質問の設定を求められます。

5. この時点で、Oracle Identity Managerは、新しく入力したパスワードを使用してユーザーを認証しています。Oracle Identity Managerは、TAPリクエストを作成し、Access Managerがユーザーにセッションを作成できることを通知します。つまり、ユーザーは再ログインを求められません。これは、Access Managerが読み取ることができるユーザーのブラウザにトークンを追加することによって行われます。
Access ManagerへのTAPリクエストには次のことが含まれています。

- Access Managerサーバーの配置場所。

- 使用するWebゲート・プロファイル。

- Webゲート・プロファイルのパスワード。

- 証明書(Access Managerが簡易モードまたは証明書モードで動作している場合)。

3.7.3 ユーザー・リクエストの概要

ユーザーがアクセスをリクエストするときのリクエスト・フローは、次のとおりです。

1. ユーザーは、HTTPまたはHTTPSを介して保護されたリソースへのアクセスをリクエストします。

2. Webゲートはリクエストを捕捉します。

3. Webゲートは、Oracle Accessプロトコルを介してリクエストをOAMサーバーに転送し、リソースが保護されているかどうか、ユーザーの認証方法およびユーザーが認証されているかどうかを判定します(認証されていない場合は問題になります)。

4. OAMサーバーは、ディレクトリ・サーバーで資格証明(ユーザーIDとパスワードなど)を確認し、Oracle Accessプロトコルを介して情報をWebゲートに戻し、暗号化Cookieを生成してユーザーを認証します。

5. 認証に従い、WebゲートがOracle Accessプロトコルを介してOAMサーバーに要求し、OAMサーバーは適切なセキュリティ・ポリシーを検索し、そのポリシーをユーザーのアイデンティティと比較してユーザーの認証レベルを判別します。

- アクセス・ポリシーが有効な場合、ユーザーは目的のコンテンツまたはアプリケーション(あるいはこれら両方)へのアクセスを許可されます。

- ポリシーが偽の場合、ユーザーはアクセスを拒否され、組織の管理者が決めた別のURLにリダイレクトされます。

3.7.4 通信のユニキャスト要件について

トポロジにあるノードはユニキャスト通信を使用して通信することをお薦めします。マルチキャスト通信と異なり、ユニキャストはクロスネットワーク構成を必要としません。ユニキャストを使用することによって、マルチキャスト・アドレスの競合によるネットワーク・エラーを回避します。

ユニキャスト・メッセージング・モードでは、チャンネルが構成されていないとサーバーのデフォルトのリスニング・ポートが使用されます。クラスタ・メンバーは、ブロードキャスト・メッセージ(通常はハートビート・メッセージ)を送信する必要がある場合、グループ・リーダーと通信します。クラスタ・メンバーがグループ・リーダーの障害を検出すると、その次に古いメンバーがグループ・リーダーになります。ユニキャスト・モードでの通信頻度は、マルチキャスト・ポートでのメッセージの送信頻度と同程度です。

ユニキャストを使用してクラスタ通信を処理する際に次の考慮事項が適用されます。

- WebLogicクラスタのすべてのメンバーでは、同じメッセージ・タイプを使用する必要があります。マルチキャストとユニキャストのメッセージを混在させることはできません。

- 個々のクラスタ・メンバーでは、クラスタのメッセージ・タイプのオーバーライドはできません。

- メッセージ・モードをユニキャストからマルチキャストまたはマルチキャストからユニキャストに変更するには、クラスタ全体を停止してから再起動する必要があります。

- マルチキャスト通信用に構成されたJMSトピックは、ユニキャスト通信用に構成されたWebLogicクラスタにアクセスできます。クラスタ・アドレスとは関係なく固有のマルチキャスト・アドレスでJMSトピックがメッセージを発行するためです。ただし、次の考慮事項が適用されます。

- クラスタでユニキャスト通信が可能なルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能できない場合があります。

- JMSマルチキャスト・サブスクライバでは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成で動作する必要があります。つまり、JMSサブスクライバは、マルチキャストのトピックにアクセスするために、マルチキャスト対応ネットワークで動作する必要があります。

4 エンタープライズ・デプロイメント用の記憶域の準備

この章では、Oracle Identity Managementエンタープライズ・デプロイメント用の記憶域を準備する方法を説明します。

このガイドで説明する記憶域モデルは、可用性の最大化、コンポーネントの最良の独立性、構成の対称性およびバックアップと災害からのリカバリの容易化を実現するために選択されました。このガイドの残りの部分では、この記憶域モデルに基づいたディレクトリ構造およびディレクトリ用語を使用します。その他のディレクトリ・レイアウトも可能で、サポートされています。

この章では、次の項目について説明します。

- 第4.1項「エンタープライズ・デプロイメント用の記憶域の準備の概要」

- 第4.2項「ディレクトリとディレクトリ変数の用語」

- 第4.3項「ファイル・システムについて」

- 第4.4項「各種ディレクトリの推奨場所について」

4.1 エンタープライズ・デプロイメント用の記憶域の準備の概要

記憶域は、エンタープライズ・デプロイメントがわかりやすくなり、構成および管理が容易になるように設定することが重要です。この章の情報に従って記憶域を設定することをお薦めします。この章で定義されている用語は、このガイド内のダイアグラムおよび手順で使用されます。

この章を参照情報として使用すると、インストールおよび構成手順で使用されているディレクトリ変数について理解できます。その他のディレクトリ・レイアウトも可能であり、サポートされていますが、このマニュアルで採用するモデルは、可用性を最大化するために選択されており、コンポーネントの最良の独立性と構成の対称性の両方を実現し、バックアップおよび災害からのリカバリを容易にします。ドキュメントの残りの部分では、このディレクトリ構造およびディレクトリ用語を使用します。

4.2 ディレクトリとディレクトリ変数の用語

この項では、Oracle Identity Managementエンタープライズ・デプロイメントを構成するためにこのガイドで使用されるディレクトリ変数について説明します。これらを環境変数として設定する必要はありません。このガイドでは、インストールして構成するディレクトリを次のディレクトリ変数を使用して説明しています。

- ORACLE_BASE: この環境変数および関係するディレクトリ・パスは、Oracle製品がインストールされるベース・ディレクトリを表します。たとえば、/u01/oracleです

- MW_HOME: この変数および関係するディレクトリ・パスは、Oracle Fusion Middlewareが配置されている場所を表します。MW_HOMEは、WL_HOME、ORACLE_COMMON_HOME、および1つ以上のORACLE_HOMEからなります。典型的なMW_HOMEの例を次に示します。
/u01/oracle/products/access

各ドメインに異なるMW_HOMEがあります。

このガイドでは、この値の前に製品スイートの略語が付く場合があります(IAM_MW_HOME、OIM_MW_HOME、WEB_MW_HOMEなど)。

- WL_HOME: この変数および関係するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています(MW_HOME/wlserver_10.3など)。WL_HOMEディレクトリは、Oracleホーム・ディレクトリのピアであり、MW_HOME内にあります。

- ORACLE_HOME: この変数は、Oracle Fusion Middleware製品(Oracle HTTP Server、Oracle SOA Suite、Oracle Internet Directoryなど)がインストールされている場所を示します。この場所にあるその製品のバイナリが現在のプロシージャで使用されています。このガイドでは、この値の前に製品スイートの略語が付く場合があります(IAM_ORACLE_HOME、OIM_ORACLE_HOME、WEB_ORACLE_HOMEなど)。ホームの詳細は、表2-3「ホームのまとめ」を参照してください。

- ORACLE_COMMON_HOME: この変数および関係するディレクトリ・パスは、Oracle Fusion Middleware Common Java Required Files (JRF)ライブラリおよびOracle Fusion Middleware Enterprise Managerライブラリがインストールされている場所を表します。例: MW_HOME/oracle_common

- ドメイン・ディレクトリ: このパスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されているファイル・システムの場所を示します。同じノードに属している場合であっても、異なるWebLogic Serverは、それぞれ異なるドメイン・ディレクトリを使用できます。これについては、第4.4項「各種ディレクトリの推奨場所」を参照してください。

- ORACLE_INSTANCE: Oracleインスタンスには、1つ以上のシステム・コンポーネント(Oracle Webキャッシュ、Oracle HTTP Server、Oracle Internet Directoryなど)が含まれています。Oracleインスタンスのディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されます。たとえば、/u02/private/oracle/config/instances/web1です
このガイドでは、この値の前に製品スイートの略語が付く場合があります(WEB_ORACLE_INSTANCEなど)。

- JAVA_HOME: JRockitがインストールされている場所です。

- ASERVER_HOME: ドメイン構成のプライマリの場所です。典型的な例は、/u01/oracle/config/domains/domain_nameです。

- MSERVER_HOME: 管理対象サーバーの起動と停止に使用されるドメイン構成のコピーです。典型的な例は、/u02/private/oracle/config/domains/domain_nameです。

4.3 ファイル・システムについて

記憶域にパーティションを作成した後、ファイル・システムをパーティションに配置して、Oracleファイルを格納できるようにする必要があります。ローカル記憶域または直接接続された共有記憶域の場合、ファイル・システム・タイプは、オペレーティング・システムのデフォルト・タイプである可能性が非常に高いです(たとえばLinuxの場合はEXT3)。

共有記憶域が、2つ以上のホストから排他的または同時にアクセスされるネットワーク接続記憶域(NAS)の場合、サポートされているクラスタ・ファイル・システム(NFSバージョン3や4など)を使用する必要があります。このようなファイル・システムは、競合解決およびロック機能を提供します。

4.4 各種ディレクトリの推奨場所について

この項には次のトピックが含まれます:

- 第4.4.1項「バイナリ(Middlewareホーム)ディレクトリの推奨事項」

- 第4.4.2項「ドメイン構成ファイルの推奨事項」

- 第4.4.3項「JMSファイル・ストアとトランザクション・ログ用の共有記憶域に関する推奨事項」

- 第4.4.4項「ディレクトリの推奨場所」

4.4.1 バイナリ(Middlewareホーム)ディレクトリの推奨事項

次の項では、Oracle Fusion Middlewareのミドルウェア・ホーム・ディレクトリに対して共有記憶域を使用する際のガイドラインについて説明します。

- 第4.4.1.1項「バイナリ(Middlewareホーム)ディレクトリについて」

- 第4.4.1.2項「複数のドメイン用の単一のMiddlewareホームの共有について」

- 第4.4.1.3項「冗長バイナリ(Middlewareホーム)ディレクトリの使用について」

4.4.1.1 バイナリ(Middlewareホーム)ディレクトリについて

Oracle Fusion Middleware製品をインストールする際には、製品のバイナリをMiddlewareホームにインストールします。Middlewareホームにインストールされたバイナリ・ファイルは読取り専用であり、Middlewareホームにパッチが適用されるか新しいバージョンにアップグレードされるまで変更されることはありません。

標準的な本番環境では、Middlewareホーム・ファイルは、Oracle Fusion Middleware構成ウィザードを使用して作成するドメイン構成ファイルとは別の場所に保存します。

Oracle Fusion Middlewareインストール用のMiddlewareホームには、Oracle WebLogic Serverのバイナリ、Oracle Fusion Middlewareインフラストラクチャ・ファイルおよび任意のOracle Fusion Middleware製品固有のディレクトリが含まれています。

Oracle Fusion Middlewareホームの構造および内容の詳細は、Oracle Fusion Middleware Oracle Enterprise Content Management Suiteインストレーション・ガイドを参照してください。

4.4.1.2 複数のドメイン用の単一のMiddlewareホームの共有について

Oracle Fusion Middlewareでは、1つのMiddlewareホームから複数のOracle WebLogic Serverドメインを構成できます。これにより、共有ボリューム上の単一の場所にMiddlewareホームをインストールし、複数のホストのインストールにMiddlewareホームを再利用できます。

Middlewareホームが異なるホスト上の複数のサーバーにより共有されている場合、留意するべきいくつかのベスト・プラクティスがあります。特に、整合性およびパッチの適用のため、各ホストにあるOracleインベントリが更新されていることを確認してください。

ホストのoraInventoryを更新して、Middlewareホームを共有記憶域に追加するには、次のコマンドを使用します。

ORACLE_HOME/oui/bin/attachHome.sh

Oracleインベントリの詳細は、Oracle Universal Installerコンセプト・ガイドのOracle Universal Installerインベントリに関する項を参照してください。

4.4.1.3 冗長バイナリ(Middlewareホーム)ディレクトリの使用について

可用性が最大になるように、共有記憶域上でバイナリの冗長インストールを使用することをお薦めします。

このモデルでは、Oracle Fusion Middlewareソフトウェアの2つの同じMiddlewareホームを2つの異なる共有ボリュームにインストールします。まず、Middlewareホームの1つをサーバーの1セットにマウントし、もう一方を残りのサーバーにマウントします。いずれのMiddlewareホームも同じマウント・ポイントを持つため、サーバーがどのMiddlewareホームを使用しているかにかかわらず、Middlewareホームは常に同じパスを持ちます。

一方のMiddlewareホームが破損または使用不可になっても、影響を受けるのは半分のサーバーのみです。さらに保護を強化するために、これらのボリュームのディスク・ミラーを行うことをお薦めします。

共有記憶域で個別ボリュームが使用不可の場合、同じボリューム内の別々のディレクトリを使用して個別ボリュームをシミュレートしたり、ホスト側の同じマウント場所に個別ボリュームをマウントしたりすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。

4.4.2 ドメイン構成ファイルの推奨事項

次の項では、エンタープライズ・デプロイメントでOracle Fusion Middleware製品を構成する際に作成するOracle WebLogic Serverドメイン構成ファイルで共有記憶域を使用するためのガイドラインについて説明します。

- 第4.4.2.1項「Oracle WebLogic Server管理サーバーおよび管理対象サーバーのドメイン構成ファイルについて」

- 第4.4.2.2項「管理サーバーのドメイン構成ファイル用の共有記憶域の要件」

- 第4.4.2.3項「管理対象サーバーのドメイン構成ファイル用のローカル記憶域の要件」

4.4.2.1 Oracle WebLogic Server管理および管理対象サーバー・ドメイン構成ファイルについて

Oracle Fusion Middleware製品を構成すると、Oracle WebLogic Serverドメインが作成または拡張されます。各Oracle WebLogic Serverドメインは、1つの管理サーバーおよび1つ以上の管理対象サーバーで構成されます。

Oracle WebLogic Serverドメインの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解』を参照してください。

エンタープライズ・デプロイメントでは、ドメイン内の管理対象サーバーをアクティブ/アクティブ型の高可用性用に構成できることを理解することが重要です。ただし、管理サーバーではこのようなことはありません。管理サーバーはシングルトン・サービスです。つまり、管理サーバーは1つのホスト上で所定の時間にのみ有効です。

ASERVER_HOMEはドメイン構成のプライマリの場所です。MSERVER_HOMEは管理対象サーバーの起動と停止に使用するドメイン構成のコピーです。WebLogic管理サーバーは、ASERVER_HOMEドメイン構成に適用された構成の変更を、ドメインの一部として登録されているすべてのMSERVER_HOME構成ディレクトリに自動的にコピーします。ただし、MSERVER_HOMEディレクトリには、管理対象サーバーに固有のデプロイメントおよびデータも含まれています。そのため、バックアップを実行する際には、ASERVER_HOMEとMSERVER_HOMEの両方を含める必要があります。

4.4.2.2 管理サーバーのドメイン構成ファイル用の共有記憶域の要件

管理サーバーの構成ファイルは共有記憶域に配置する必要があります。これにより、プライマリ・ホストが使用できなくなった場合でも、別のホストで管理サーバーを起動できます。管理サーバー・ファイルがあるディレクトリは、ASERVER_HOMEディレクトリと呼ばれています。このディレクトリは共有記憶域上にあり、管理サーバー・ホストとOracle Identity Managerを実行する各ホストにマウントされています。

競合に関連するパフォーマンス上の問題を回避するために、管理対象サーバーの構成ファイルはローカル記憶域上に配置する必要があります。管理対象サーバーの構成ファイルがあるディレクトリは、MSERVER_HOMEディレクトリと呼ばれています。管理対象サーバー・ドメイン構成ファイルは、ローカル記憶域に配置することを強くお薦めします。

4.4.2.3 管理対象サーバー・ドメイン構成ファイルに対するローカル記憶域の要件

共有記憶域を使用する必要がある場合は、ノードごとに記憶域パーティションを作成し、その記憶域をそのノードに排他的にマウントすることをお薦めします。

このエンタープライズ・デプロイメント・トポロジに対して用意されている構成手順では、管理対象サーバーごとに各ノードのローカル・ドメイン・ディレクトリが使用されると想定しています。

4.4.3 JMSファイル・ストアとトランザクション・ログ用の共有記憶域に関する推奨事項

サーバーの障害や移行の場合のリカバリで、JMSファイル・ストアやJTAトランザクション・ログを複数のホストから利用できるようにするには、それらを共有記憶域に配置する必要があります。

JMSおよびJTA情報のファイル・ストアへの保存の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使用に関する項を参照してください。

4.4.4 ディレクトリの推奨場所

この項では、共有記憶域およびローカル記憶域のお薦めされる使用方法を説明します。

この項には次のトピックが含まれます:

- 第4.4.4.1項「共有記憶域」

- 第4.4.4.2項「ローカル記憶域」

4.4.4.1 共有記憶域

エンタープライズ・デプロイメントでは、ホストIDMHOST1とIDMHOST2にある共有記憶域にボリュームVOL1/OracleIDMを作成することをお薦めします。マウント・ポイントは/u01/oracleにする必要があります。

排他的または共有で共有記憶域をマウントできます。

図4-1 共有記憶域

この図は、共有記憶域のディレクトリ階層を示しています。マウント・ポイント/u01/oracle (SHARED_ROOT)の下にはディレクトリconfigおよびproductsがあります。

ディレクトリconfigにはdomainsがあり、これにはIDMDomain (ASERVER_HOME)があります。IDMDomainには5つのサブディレクトリ(applications、servers、keystores、jmsおよびlogs)があります。serversディレクトリにはサブディレクトリAdminServerがあります。

ディレクトリproductsにはディレクトリaccess (IAM_MW_HOME)があり、これには6つのサブディレクトリ(iam (IAM_ORACLE_HOME)、oud (OUD_ORACLE_HOME)、soa (SOA_ORACLE_HOME)、oracle_common (ORACLE_COMMON_HOME)、wlserver_10.3 (WL_HOME)およびjrockit_version (JAVA_HOME))があります。

4.4.4.2 ローカル記憶域

エンタープライズ・デプロイメントでは、次のディレクトリをローカル記憶域に作成することをお薦めします。

表4-1 ローカル記憶域のディレクトリ

層

環境変数

ディレクトリ

ホスト

Web層

WEB_MW_HOME

/u02/private/oracle/products/web

WEBHOST1 WEBHOST2

Web層

WEB_ORACLE_INSTANCE

/u02/private/oracle/config/instances/webn

WEBHOST1 WEBHOST2

アプリケーション層

OUD_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oudn

IDMHOST1 IDMHOST2

MSERVER_HOME

/u02/private/oracle/config/domains/IDMDomain

IDMHOST1 IDMHOST2

図4-2 ローカル記憶域

この図は、ローカル記憶域のディレクトリ階層を示しています。最上位ディレクトリ/u02/private/oracle (LOCAL_ROOT)には2つのサブディレクトリconfigおよびproductsがあります。

ディレクトリconfigには2つのサブディレクトリinstancesおよびdomainsがあります。domainsディレクトリにはoudn (OUD_ORACLE_INSTANCE)(nはOUDインスタンス)およびwebn (WEB_ORACLE_INSTANCE)(nはOHSインスタンス)があります。domainsディレクトリにはIDMDomain (MSERVER_HOME)があり、これにはapplicationsおよびserversがあります。serversディレクトリにはwls_oimnおよびwls_oamnがあり、ここでnはそれぞれOIMおよびOAMのインスタンスです。

productsディレクトリにはwebディレクトリ(WEB_MW_HOME)があり、これには4つのサブディレクトリ(web (WEB_ORACLE_HOME)、webgate (WEBGATE_ORACLE_HOME)、oracle_common (ORACLE_COMMON_HOME)およびjrockit_version (JAVA_HOME))があります。

注意:

WEB_ORACLE_INSTANCEディレクトリをローカル記憶域に配置することをお薦めしますが、共有記憶域も使用できます。共有記憶域を使用する場合、HTTPロック・ファイルを別の場所に配置する必要があります。

5 エンタープライズ・デプロイメント用のサーバーの準備

この章では、エンタープライズ・デプロイメント用のサーバーを準備する方法を説明します。

次の項が含まれます:

- 第5.1項「サーバーの準備の概要」

- 第5.2項「サーバーおよびオペレーティング・システムの検証」

- 第5.3項「最小ハードウェア要件の達成」

- 第5.4項「オペレーティング・システム要件の達成」

- 第5.5項「Unicodeサポートの有効化」

- 第5.6項「仮想IPアドレスの有効化」

- 第5.7項「共有記憶域のホストへのマウント」

- 第5.8項「ユーザーおよびグループの構成」

- 第5.9項「複数のネットワーク・アドレスを持つサーバーへのOracleソフトウェアのインストール」

5.1 サーバーの準備の概要

Oracle Fusion Middlewareを新しいハードウェアにデプロイする前に、Oracleソフトウェアが最適に動作できるように、使用する計画のサーバーを設定する必要があります。具体的には、次のことを確認する必要があります。

- 必要なソフトウェア・パッチがインストールされている証明されたオペレーティング・システムをサーバーが実行中。

- UNIXカーネルを正しく構成済。

- Oracleソフトウェアを所有するユーザーおよびグループを作成済。

この章で説明する設定は単なる見本です。Oracleソフトウェアを使用した後、オペレーティング・システムのユーティリティを使用して構成を調整し、サーバーの能力を最大化していることを確認する必要があります。

5.2 サーバーおよびオペレーティング・システムの検証

使用する計画のサーバーおよびオペレーティング・システムが使用する計画の製品の証明済の組合せであることを確認します。詳細は、Oracleの証明マトリクスに関する項を参照してください。

5.3 最小ハードウェア要件の達成

Oracleエンタープライズ・デプロイメントでサーバーを使用するためには、第2.3項「エンタープライズ・デプロイメントのハードウェア要件」で説明されている最小仕様を満たしていることを検証する必要があります。別のデプロイメント・アーキテクチャ(様々な数のボックスにより多いまたはより少ないコンポーネントをデプロイしたアーキテクチャなど)を使用する計画の場合、Oracle Fusion Middlewareシステム要件および仕様を確認し、これらのサーバーにデプロイする計画の製品をサポートするための最小仕様を備えていることを確認する必要があります。

Oracle Exalogicなどの仮想サーバー環境にデプロイしている場合、仮想サーバーそれぞれが最小要件を満たしていることを確認します。

十分なローカル・ディスクがあり、共有記憶域が第4章「エンタープライズ・デプロイメント用の記憶域の準備」で説明されているように構成されていることを確認します。

十分なスワップ領域および一時領域を確保します。具体的には次のとおりです。

- スワップ領域: システムに500MB以上ある必要があります。

- 一時領域: /tmpに500MB以上の空き領域がある必要があります。

5.4 オペレーティング・システム要件の達成

オペレーティング・プロビジョニングを開始する前に、次のタスクを実行する必要があります。

1. 証明済オペレーティング・システムをインストールします。

2. リリース・ノートにリストされている必要なパッチおよびパッケージをすべてインストールします。

この項には次のトピックが含まれます:

- 第5.4.1項「UNIXおよびLinuxの要件の達成」

5.4.1 UNIXおよびLinuxの要件の達成

この項には次のトピックが含まれます:

- 第5.4.1.1項「カーネル・パラメータの構成」

- 第5.4.1.2項「オープン・ファイル制限の設定」

- 第5.4.1.3項「シェル制限の設定」

- 第5.4.1.4項「ローカルHostsファイルの構成」

5.4.1.1 カーネル・パラメータの構成

次のカーネル・パラメータおよびシェル制限の値は、単なる推奨値です。本番データベース・システムでは、これらの値を調整してシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータのチューニングの詳細は、オペレーティング・システムのドキュメントを参照してください。

カーネル・パラメータは、トポロジのすべてのノードで次の最小値以上の値に設定する必要があります。

次の表の値は、現行のLinuxの推奨値です。Linuxおよびその他のオペレーティング・システムの最新の推奨値は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

データベースをホストにデプロイしている場合、追加のカーネル・パラメータを変更する必要がある場合があります。ご使用のプラットフォームは、11gリリース2 Oracle Grid Infrastructureインストレーション・ガイドを参照してください。

表5-1 UNIXのカーネル・パラメータ

パラメータ

値

kernel.sem

256 32000 100 142

kernel.shmmax

4294967295

これらのパラメータを設定するには:

1. rootとしてログインし、ファイル/etc/sysctl.confのエントリを追加または修正します。

2. ファイルを保存します。

3. 次のコマンドを発行して変更をアクティブ化します。

4. /sbin/sysctl -p

5.4.1.2 オープン・ファイル制限の設定
すべてのUNIXオペレーティング・システムにおいて、最小オープン・ファイル制限は4096です。

注意:

次の例はLinuxオペレーティング・システム用です。オペレーティング・システムのドキュメントを確認して、システムで使用するコマンドを判別します。

次のコマンドでオープンになっているファイル数を確認できます。

/usr/sbin/lsof | wc -l

オープン・ファイル制限を確認するには、次のコマンドを使用します。

Cシェル:

limit descriptors

Bash:

ulimit -n

5.4.1.3 シェル制限の設定

シェル制限を変更するには、rootとしてログインし、/etc/security/limits.confファイルを編集します。

次の行を追加します。

* soft  nofile  4096
* hard  nofile  65536
* soft  nproc   2047
* hard  nproc   16384

最新の推奨値は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

ファイルを編集したら、マシンを再起動します。

5.4.1.4 ローカルHostsファイルの構成

Oracleソフトウェアのインストールを開始する前に、ローカルhostsファイルが次のようにフォーマットされていることを確認します。

IP_Address Fully_Qualified_Name Short_Name

5.5 Unicodeサポートの有効化

オペレーティング・システムの構成がOracle Fusion Middleware製品でサポートされる文字の動作に影響を与えることがあります。

UNIXオペレーティング・システムでは、LANGとLC_ALLの各環境変数をUTF-8キャラクタ・セットを使用したロケールに設定し、Unicodeサポートを有効化することを強くお薦めします。これにより、Unicodeのすべての文字が処理できるようになります。たとえば、Oracle SOA SuiteテクノロジはUnicodeに基づいています。

オペレーティング・システムがUTF-8以外のエンコードを使用するように構成されている場合、Oracle SOA Suiteコンポーネントが予期しない動作をする可能性があります。たとえば、ASCII以外のファイル名の場合は、ファイルにアクセスできず、エラーが発生する可能性があります。オペレーティング・システムの制約によって発生した問題は、オラクル社ではサポートしていません。

5.6 仮想IPアドレスの有効化

エンタープライズ・デプロイメントでは、WebLogic管理サーバーやSOA管理対象サーバーを実行する特定のホストは仮想IPアドレスを使用する必要があります。各サーバーで適切なIPアドレスを有効化する必要があります。

第3.5項「IPアドレスおよび仮想IPアドレスについて」でサーバーへのIPアドレスのマッピングを説明しています。

この項には次のトピックが含まれます:

- 第5.6.1項「有効化する仮想IPアドレス」

- 第5.6.2項「コマンドラインを使用した仮想アドレスの有効化」

5.6.1 有効化する仮想IPアドレス

他のOracle Fusion Middlewareコンポーネントを後でインストールするかしないかに関係なく、WebLogic管理サーバーのフェイルオーバーを行うには仮想IPアドレスが必要です。

管理サーバーを仮想IPアドレスと関連付けます。これにより、プライマリ・ホストで障害が発生している場合に、別のホストで管理サーバーを起動させることができます。

仮想ホストが次のように有効化されていることを確認します。

表5-2 ドメインの仮想ホスト

VIP

有効化されるホスト

ADMINVHN.mycompany.com

IDMHOST1

OIMHOST1VHN.mycompany.com

IDMHOST1

OIMHOST2VHN.mycompany.com

IDMHOST2

SOAHOST1VHN.mycompany.com

IDMHOST1

SOAHOST2VHN.mycompany.com

IDMHOST2

注意:

これは、浮動IPアドレスに関連付けられているDNS名です。これは、ロード・バランサ上で構成される仮想ホストのDNS名ではありません。

5.6.2 コマンドラインを使用した仮想アドレスの有効化

仮想IPアドレスを有効化するには、そのIPアドレスをネットワーク・インタフェースと関連付け、そのインタフェースのネットマスクを設定する必要があります。Linuxホストでは、この項にリストした手順を実行します。他のオペレーティング・システムについては、製造元のドキュメントを参照してください。

仮想IPアドレスを有効化するには、ifconfigコマンドを使用して、そのIPアドレスおよびインタフェースのネットマスクを設定します。次にarpingコマンドを使用して、ネットワークを有効化し、仮想IPアドレスの新しい場所を登録します。次のコマンドをrootとして実行します。

/sbin/ifconfig interface:index IPAddress netmask netmask
/sbin/arping -q -U -c 3 -I interface IPAddress

ここでinterfaceはeth0、eth1などで、indexは0、1、2などです。

例:

/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206

別のノードからpingを行って、アドレスが使用可能であることを検証します。例:

/bin/ping 100.200.140.206

5.7 共有記憶域のホストへのマウント

第4章「エンタープライズ・デプロイメント用の記憶域の準備」で構成した共有記憶域は、これを使用するホストで使用可能にする必要があります。共有記憶域にアクセスする必要があるすべてのサーバーにその共有記憶域をマウントします。

各ホストでは、適切な権限をNASまたはSAN内で設定し、共有記憶域への書込みを可能にする必要があります。

共有記憶域のマウントについては、組織のベスト・プラクティスに従ってください。この項では、NFS記憶域を使用してUNIXまたはLinuxでこれを行う方法の例を示します。

共有記憶域の場所を作成してマウントし、IDMHOST1とIDMHOST2が2つの別々のボリュームのバイナリ・インストール用に同じ場所を参照できるようにする必要があります。

次のコマンドを使用して、共有記憶域をNAS記憶域デバイスからLinuxホストにマウントします。別のタイプの記憶域デバイスまたはオペレーティング・システムを使用している場合、これを行う方法の詳細は製造元のドキュメントを参照してください。

注意:

共有記憶域のファイル・システムの作成に使用されるユーザーIDは、これらのファイルに対する読取り、書込みおよび実行権限を持ちます。オペレーティング・システム・グループにおける他のユーザーは、ファイルの読取りや実行は可能ですが、書込み権限はありません。インストールと構成の権限に関する詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストールと構成の権限およびユーザーに関する項を参照してください。

nasfilerは共有記憶域ファイラです。

IDMHOST1から:

mount -t nfs nasfiler:VOL1/OracleIDM /u01/oracle

IDMHOST2から:

mount -t nfs nasfiler:VOL1/OracleIDM /u01/oracle

共有記憶域の構成の検証

構成した共有記憶域にテスト・ファイルを作成し、新しくマウントしたディレクトリでファイルの読取りおよび書込みができることを確認します。

例:

$ cd newly mounted directory
$ touch testfile

所有者と権限が正しいことを確認します。

$ ls -l testfile

ファイルを削除します。

$ rm testfile

注意:

共有記憶域には、NASデバイスまたはSANデバイスを使用できます。次は、NASデバイスの記憶域をIDMHOST1から作成する例を示しています。オプションは、具体的な記憶域デバイスに応じて異なる場合があります。

mount -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768 nasfiler:VOL1/OracleIDM /u01/oracle

使用する環境に適切なオプションについては、ストレージ・ベンダーとマシン管理者と相談してください。

5.8 ユーザーおよびグループの構成

グループ

各ノードに次のグループを作成する必要があります。

- oinstall

- dba

Users

各ノードに次のユーザーを作成する必要があります。

- nobody: 権限のないユーザー。

- oracle: Oracleソフトウェアの所有者。別の名前も使用できます。このアカウントのプライマリ・グループはoinstallにする必要があります。このアカウントは、dbaグループにも属している必要があります。

注意:

- グループoinstallは、Oracleソフトウェアが使用する共有記憶域およびローカル記憶域のすべてのファイル・システムに対する書込み権限を持っている必要があります。

- 各グループは、ノードごとに同じグループIDを持っている必要があります。

- 各ユーザーは、ノードごとに同じユーザーIDを持っている必要があります。

5.9 複数のネットワーク・アドレスを持つサーバーへのOracleソフトウェアのインストール

Oracle Identity Managementコンポーネントを、複数のホームを持つシステムにインストールすることができます。マルチホーム・システムには複数のIPアドレスがあります。通常、各IPアドレスは、システム上の異なるネットワーク・カードに関連付けられています。IPアドレスはそれぞれホスト名に関連付けられています。各ホスト名に別名を作成できます。

インストーラは、/etc/hostsファイルの最初のエントリから完全修飾ドメイン名を取得します。たとえば、ファイルが次のサンプル・ファイルのようである場合、インストーラはMYHOST1.mycompany.comを取得して構成に使用します。

127.0.0.1 localhost.localdomain localhost
10.222.333.444 MYHOST1.mycompany.com myhost1
20.222.333.444 DEVHOST2.mycompany.com devhost2

6 エンタープライズ・デプロイメント用のデータベースの準備

この章では、Identity Managementデータベース・リポジトリをインストールし、構成する方法について説明します。

この章では、次の項目について説明します。

- 第6.1項「Identity Managementエンタープライズ・デプロイメント用のデータベースの準備の概要」

- 第6.2項「エンタープライズ・デプロイメント用のデータベース要件の検証」

- 第6.3項「エンタープライズ・デプロイメント用のデータベースのインストール」

- 第6.4項「データベース・サービスの作成」

- 第6.5項「リポジトリ作成ユーティリティ(RCU)用のデータベースの準備」

- 第6.6項「RCUを使用したOracle RAC DatabaseへのIdentity Managementスキーマのロード」

- 第6.7項「データベースのバックアップ」

6.1 Identity Managementエンタープライズ・デプロイメント用のデータベースの準備の概要

エンタープライズ・デプロイメントのIdentity Managementコンポーネントはデータベース・リポジトリを使用します。この章では、次の手順を実行する方法について説明します。

- 第6.2項「エンタープライズ・デプロイメントのデータベース要件の検証」で説明されているデータベース要件の検証。

- Oracleデータベース・リポジトリのインストールと構成。「はじめに」の関連ドキュメントに関する項にリストされているインストレーション・ガイドおよび第6.3項「エンタープライズ・デプロイメント用のデータベースのインストール」を参照してください。

- 第6.4項「データベース・サービスの作成」で説明されているデータベース・サービスの作成。

- リポジトリ作成ユーティリティ(RCU)を使用したデータベースで必要なOracleスキーマの作成。第6.6項「RCUを使用したOracle RAC DatabaseへのIdentity Managementスキーマのロード」を参照してください。

6.2 エンタープライズ・デプロイメントのデータベース要件の検証

メタデータ・リポジトリをデータベースにロードする前に、次の各項で説明されている要件をデータベースが満たしていることを確認してください。

- 第6.2.1項「必要なデータベース」

- 第6.2.2項「データベース・ホストの要件」

- 第6.2.3項「サポートされているデータベース・バージョン」

- 第6.2.4項「Oracle Databaseのパッチ適用」

- 第6.2.5項「初期化パラメータについて」

6.2.1 必要なデータベース

Oracleアイデンティティ管理では、多数の別個のデータベースを使用すること推奨します。表6-1には、これらのデータベースの概要が提供されます。どのデータベースを使用するかは、実装しているトポロジによって異なります。

Oracle Metadata Services (MDS)リポジトリは、一部のOracle Fusion Middlewareコンポーネントのメタデータを含む特定のリポジトリのタイプです、ユーザーの組織で開発したカスタムJava EEアプリケーションを含むこともできます。

表6-1 データベースとスキーマ間のマッピング

データベース名

データベース・ホスト

サービス名

データベースのスキーマ

IDMDB

IDMDBHOST1 IDMDBHOST2

OAMEDG.mycompany.com

OAM、IAU、ORASDPM、MDS

OIMEDG.mycompany.com

OIM、SOA_INFRA、MDS

OESEDG.mycompany.com

OPSS、MDS

次の各項は、表6-1にリストされたデータベースすべてに適用されます。

6.2.2 データベース・ホストの要件

メタデータ・リポジトリを格納するために使用するデータベースは、可用性を最大化するために本質的に高可用性を実現する必要があります。Oracleは、Oracle Real Application Clusters (RAC)データベースの使用をお薦めします。

データベースにデータを格納するにはOracle Automatic Storage Management (ASM)を使用することが理想的ですが、必須ではありません。

ASMを使用する場合、ASMを独自のOracleホームにインストールし、ASMに2つのディスク・グループを備える必要があります。

- 1つはデータベース・ファイル用です。

- 1つはフラッシュ・リカバリ領域用です。

Oracle ASMを使用している場合、Oracle管理対象ファイルも使用することをお薦めします。

6.2.3 サポートされるデータベース・バージョン

データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

インストール済Oracle Databaseのバージョンを判別するには、SQLプロンプトで次の問合せを実行します。

select version from sys.product_component_version where product like 'Oracle%';

6.2.4 Oracle Databaseのパッチ適用

Oracle Databaseの一部のバージョンにはパッチが必要です。

6.2.4.1 Oracle Database 11g (11.1.0.7)のパッチ要件

表6-2に、Oracle Database 11g (11.1.0.7)を使用するOracle Identity Managerの構成に必要なパッチをリストします。Oracle Identity Manager 11gを構成する前に、Oracle Database 11g (11.1.0.7)データベースに必ずパッチを適用してください。

表6-2 Oracle Database 11g (11.1.0.7)に必要なパッチ

プラットフォーム

My Oracle Supportでのパッチ番号および説明

Linux

7614692: 保存例外を伴うバルク機能はORACLE 11Gでは機能しません

7000281: 11GにおけるFORALL文の動作の違い

8327137: インライン・ビューおよび集計機能の結果が不正です

8617824: Oracle Bug#7628358および7598314に対する11.1.0.7の最上位でのマージ・ラベル・リクエスト

6.2.4.2 Oracle Database 11g (11.2.0.2.0)のパッチ要件

Oracle Database 11g (11.2.0.2.0)を使用する場合は、必ずRDBMSパッチ番号10259620に適した(プラットフォームに基づく)バージョンをダウンロードしてインストールしてください。これは、Oracle Identity Managerスキーマをインストールするための前提条件です。

表6-3に、Oracle Database 11gリリース2 (11.2.0.2.0)を使用するOracle Identity Managerの構成に必要なパッチをリストします。Oracle Identity Managerスキーマを作成する前に、必ず次のパッチをダウンロードしてインストールしてください。

表6-3 Oracle Database 11g (11.2.0.2.0)に必要なパッチ

プラットフォーム

My Oracle Supportでのパッチ番号および説明

Linux x86 (32ビット)

Linux x86 (64ビット)

RDBMS個別パッチ番号10259620。

このパッチが適用されない場合、ユーザーおよびロールの検索やマネージャのルックアップで問題が発生する可能性があります。また、検索結果として空の結果が戻されることもあります。

注意:

- このパッチはオンライン・モードで適用してください。実行するステップについては、パッチにバンドルされているreadme.txtファイルを参照してください。

- 一部の環境では、RDBMS個別パッチを使用して問題を解決することはできませんが、公開されている回避策が役立ちます。回避策については、不具合: 8352378 [MetalinkノートID 1264550.1]の修正が原因で機能ベースの索引およびOR拡張を使用した11.2.0.2で結果が正しくないのノートをhttp://support.oracle.comで参照してください。このノートを実行して、ALTER SYSTEM SET <param>=<value> scope=<memory>または<both>を使用してデータベース・インスタンス・レベルでパラメータを変更する必要があるという唯一の例外に応じてパラメータを設定できます。

6.2.5 初期化パラメータについて

データベースは、次の最小初期化パラメータを定義済である必要があります。

表6-4 Oracle RACデータベースの最小限の初期化パラメータ

パラメータ

値

aq_tm_processes

1

dml_locks

200

job_queue_processes

10

open_cursors

800脚注 1

session_max_open_files

50

sessions

500

processes

500

sga_target

512M

pga_aggregate_target

100M

sga_max_size

4G

session_cached_cursors

500

脚注 1 OAMには、データベース内で少なくとも800のオープン・カーソルが必要です。OIMとOAMを有効にする場合、必要なオープン・カーソルの数は1500です。

注意:

データベースの最適なパラメータを設定するためのガイドラインについては、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。

6.3 エンタープライズ・デプロイメント用のデータベースのインストール

次のようにデータベース・リポジトリをインストールして構成します。

Oracle Clusterware

- 10gリリース2 (10.2)については、「関連ドキュメント」で、ご使用のプラットフォームに対応したOracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイドを参照してください。

- 11gリリース1 (11.1)については、Oracle Clusterwareインストレーション・ガイドを参照してください。

自動ストレージ管理

- 10gリリース2 (10.2)については、「関連ドキュメント」で、ご使用のプラットフォームに対応したOracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイドを参照してください。

- 11gリリース1 (11.1)については、Oracle Clusterwareインストレーション・ガイドを参照してください。

- インストーラの実行時に構成の選択画面で「自動ストレージ管理(ASM)の構成」オプションを選択して、独立した自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

- 10gリリース2 (10.2)については、「関連ドキュメント」で、ご使用のプラットフォームに対応したOracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイドを参照してください。

- 11gリリース1 (11.1)については、Oracle Real Application Clustersインストレーション・ガイドを参照してください。

Oracle Real Application Clustersデータベース

次の特性を持つReal Applications Clustersデータベースを作成します。

- バックアップおよびリカバリを容易にするために、データベースはアーカイブ・ログ・モードにする必要がある。

- オプションで、フラッシュバック・データベースを有効にできる。

- Oracle Identity Managerのリコンシリエーション・プロセス時のロールバック要件に対応できるように、十分なサイズのUNDO表領域を作成する。

- データベースは、ALT32UTF8文字セットで作成されている。

6.4 データベース・サービスの作成

この項では、Oracle Fusion Middleware 11gメタデータ用のデータベースを構成する方法について説明します。次のトピックが含まれます:

- 第6.4.1項「10.xおよび11.1.xデータベース用のデータベース・サービスの作成」

- 第6.4.2項「11.2.xデータベース用のデータベース・サービスの作成」

- 第6.4.3項「データベースのチューニング」

6.4.1 10.xおよび11.1.xデータベース用のデータベース・サービスの作成

データベース・サービス作成の詳細な手順は、Oracle Database Oracle ClusterwareおよびOracle Real Application Clusters管理およびデプロイメント・ガイドのワークロード管理に関する章を参照してください。複数の製品スイートが同じデータベースを共有する場合でも、製品スイートに固有のデータベース・サービスを使用することをお薦めします。また、使用されるデータベース・サービスはデフォルトのデータベース・サービスとは別のものをお薦めします。

CREATE_SERVICEサブプログラムを使用して、トポロジ内のコンポーネント用のデータベース・サービスを作成します。作成されるサービスの一覧は、表6-1「データベースとスキーマ間のマッピング」に示されています。

1. 次のように入力して、sysdbaユーザーとしてSQL*Plusにログオンします。

sqlplus "sys/password as sysdba"

次のコマンドを実行して、Access Manager用のOAMEDG.mycompany.comというサービスを作成します。

EXECUTE DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'OAMEDG.mycompany.com',
NETWORK_NAME => 'OAMEDG.mycompany.com');

2. データベースにサービスを追加し、これをsrvctlを使用してインスタンスに割り当てます。

srvctl add service -d idmdb -s OAMEDG.mycompany.com -r idmdb1,idmdb2

3. srvctlを使用してサービスを開始します。

srvctl start service -d idmdb -s OAMEDG.mycompany.com

6.4.2 11.2.xデータベース用のデータベース・サービスの作成

srvctlを使用して、トポロジ内のコンポーネント用のデータベース・サービスを作成します。作成されるサービスの一覧は、表6-1「データベースとスキーマ間のマッピング」に示されています。

1. 次のように、コマンドsrvctl add serviceを使用してサービスを作成します。

srvctl add service -d idmdb -s OAMEDG.mycompany.com -r idmdb1,idmdb2 -q FALSE -m NONE -e SELECT -w 0 -z 0

コマンドライン引数の意味は、次のとおりです。

オプション

引数

-d

データベースの一意の名前

-s

サービス名

-r

優先インスタンスのカンマ区切りリスト

-q

AQ HA通知(TRUEまたはFALSE)

-e

フェイルオーバー・タイプ(NONE、SESSIONまたはSELECT)

-m

フェイルオーバー方式(NONEまたはBASIC)

-w

フェイルオーバー遅延(整数)

-z

フェイルオーバー再試行回数(整数)

2. srvctl start serviceを使用してサービスを開始します。

srvctl start service -d idmdb -s OAMEDG.mycompany.com

3. 次のようにsrvctl status serviceを使用して、開始したサービスを検証します。

srvctl status service -d idmdb -s OAMEDG.mycompany.com
Service OAMEDG.mycompany.com is running on instance(s) idmdb1,idmdb2

4. srvctl config serviceを使用して、サービスが正しく作成されたことを検証します。

srvctl config service -d idmdb -s OAMEDG.mycompany.com
Service name: OAMEDG.mycompany.com
Service is enabled
Server pool: IDMDB_OAMEDG.mycompany.com
Cardinality: 2
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: SELECT
Failover method: NONE
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Preferred instances: idmdb1,idmdb2
Available instances:

注意:

SRVCTLコマンドの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。

6.4.3 データベースのチューニング

第6.3項「エンタープライズ・デプロイメント用のデータベースのインストール」で定義したデータベース・パラメータは単なる見本です。システムの使用後、追加のチューニングを実行する必要が生じることがあります。詳細は、データベース・パフォーマンス・チューニング・ガイドを参照してください。

データベースを最初にロードした後、継続的に、データベース統計をリフレッシュしてください。このためには、次のSQL*Plusコマンドを発行します。

exec DBMS_STATS.GATHER_SCHEMA_STATS(OWNNAME=> '<OIM_SCHEMA>', ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE, DEGREE=>8, OPTIONS=>'GATHER AUTO', NO_INVALIDATE=>FALSE);

6.5 リポジトリ作成ユーティリティ(RCU)用のデータベースの準備

Oracle Databaseを準備するには、Oracle Fusion Middlewareのシステム要件と仕様のOracle DatabaseでのRCU要件に関する項を参照してください。

次のコマンドを実行してXATRANSビューを作成します。

cd DB_ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
@xaview.sql

6.6 RCUを使用したOracle RAC DatabaseへのIdentity Managementスキーマのロード

RCUを実行して、アイデンティティ管理および管理サービスで使用されるスキーマのコレクションを作成します。

1. 次のコマンドを発行して、RCUを起動します。

RCU_HOME/bin/rcu &

2. 「ようこそ」画面で、「次へ」をクリックします。

3. 「リポジトリの作成」画面で、「作成」操作を選択して、コンポーネント・スキーマをデータベースにロードします。「次へ」をクリックします。

4. 「データベース接続の詳細」画面で、既存のデータベースに接続するために必要な情報を入力します。例:
データベース・タイプ: Oracle Database

- ホスト名: RACデータベース・ノードの1つのVIPアドレスまたはデータベースSCANアドレスを入力します(たとえば、DB-SCAN.mycompany.com)

- ポート: データベース・リスナーのポート番号((DB_LSNR_PORT))。たとえば、1521です。

- サービス名: データベースのサービス名。たとえば、OAMEDG.mycompany.com。
手順6で表から選択するコンポーネントのサービス名を使用します。

- ユーザー名: sys

- パスワード: sysユーザーのパスワード

- ロール: SYSDBA

「次へ」をクリックします。

5. 「前提条件の確認」画面で前提条件を確認したら、「OK」をクリックします。

6. 「コンポーネントの選択」画面で、次の値を入力します。
新規接頭辞の作成: データベース・スキーマに追加する接頭辞を入力します。すべてのスキーマに接頭辞を付ける必要があります。たとえば、EDGと入力します。

コンポーネント: 使用しているトポロジに対して次の表から適切なコンポーネントを選択します。

製品

RCUオプション

サービス名

コメント

Oracle Platform Security Services

AS共通スキーマ: Oracle Platform Security Services

ポリシー・ストア情報を保持するために必要です。すべてのトポロジに対して必須です。

Oracle Access Management Access Manager

アイデンティティ管理: Access Manager

OAMEDG.mycompany.com

監査サービスも選択されます。

Oracle Identity Manager

Identity Management–Oracle Identity Manager

OAMEDG.mycompany.com

メタデータ・サービス、SOAインフラストラクチャおよびユーザー・メッセージングも選択されます。

「次へ」をクリックします。

注意:

ご使用のトポロジが複数のデータベースを必要とする場合、次の重要な考慮事項が適用されます。

- 正しいスキーマを正しいデータベースにインストールしてください。

- 指定のトポロジにすべてのスキーマを作成するためにRCUを複数回実行する必要がある場合があります。

- この章の表6-1にスキーマと対応するデータベースの間の推奨マッピングを示します。この表を参照して、正しい詳細情報をこの画面に入力してください。

7. 「前提条件の確認」画面で前提条件を確認したら、「OK」をクリックします。

8. 「スキーマ・パスワード」画面で、スキーマのパスワードを入力します。すべてのスキーマに同じパスワードを使用するか、またはスキーマそれぞれに異なるパスワードを使用することを選択できます。異なるスキーマに異なるパスワードを選択してセキュリティを高めることをお薦めします。
「次へ」をクリックします。

9. 「表領域のマップ」画面でデフォルトを受け入れ、「次へ」をクリックします。

10. 「確認」画面で「OK」をクリックして、表領域の作成を許可します。

11. 表領域の作成中画面で「OK」をクリックして、表領域の作成を確認します。

12. 「サマリー」画面で、入力した詳細情報が正確であることを確認します。「作成」をクリックして、スキーマ作成プロセスを開始します。

13. 「完了サマリー」画面で、スキーマが作成されたことを確認します。
「閉じる」をクリックして終了します。

6.7 データベースのバックアップ

データベースの準備が完了したら、第17.6.3.3項「データベースのバックアップ」の説明に従ってバックアップを作成します。

7 Oracle Unified Directoryのインストールおよび構成

この章では、エンタープライズ・デプロイメントでOracle Unified Directory (OUD)をインストールおよび構成する方法について説明します。

この章では、次の項目について説明します。

- 第7.1項「Oracle Unified Directoryのインストールおよび構成の概要」

- 第7.2項「Oracle Unified Directoryインスタンスを構成するための前提条件」

- 第7.3項「Oracle Unified Directoryのインストール」

- 第7.4項「Oracle Unified Directoryインスタンスの構成」

- 第7.5項「Oracle Unified Directoryのインストールのバックアップ」

7.1 Oracle Unified Directoryのインストールおよび構成の概要

Oracle Unified Directoryは、Identity Managementエンタープライズ・トポロジの必須コンポーネントです。これをアイデンティティ・ストアとして、つまりユーザーおよびグループの情報を格納するために使用します。

この章では、Oracle Unified Directory構成アシスタントを使用して、Oracle Unified Directoryの2つのインスタンスを構成します。

7.2 Oracle Unified Directoryインスタンスを構成するための前提条件

IDMHOST1とIDMHOST2でOracle Unified Directoryインスタンスを構成する前に、次の作業を実行済であることを確認してください。

- IDMHOSTノード間の時間差が250秒以下になるように、個々のIDMHOSTノードの時間を同期させます。

- ロード・バランサが構成されていることを確認します。

7.3 Oracle Unified Directoryのインストール

これらの手順を実行してOracle Unified Directoryを共有記憶域にインストールし、次の手順をIDMHOST1またはIDMHOST2のいずれかから実行します。

システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

第8.2.1.1項「JRockitのインストール」の説明に従ってJDKをインストールします。Oracle Fusion Middleware 11g Oracle Identity Managementインストーラを起動するには、インストール・メディアでディレクトリをDisk1に変更し、次のコマンドを入力します。

./runInstaller

次の手順を実行します。

「インベントリ・ディレクトリの指定」画面で、次の操作を行います。/u02/private/oracle/oraInventory

- HOME/oraInventory (/u02/private/oracle/oraInventory)と入力します。ここで、HOMEは、インストールを実行するユーザーのホーム・ディレクトリです(これが推奨場所です)。

- インストールを実行しているユーザーのOSグループを入力します。

- 「次へ」をクリックします。

画面に指示に従い、createCentralInventory.shをrootとして実行します。

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「ソフトウェア更新のインストール」画面で、更新をスキップするかどうかの選択、更新情報を入手するためにOracleサポートをチェックまたは更新のローカルでの検索を行います。
「次へ」をクリックします。

3. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

4. インストールの指定画面で、次を入力します。

- OUDベースの場所ホーム: IAM_MW_HOME

- Oracleホーム・ディレクトリ: oud

「次へ」をクリックします。

5. 「インストール・サマリー」画面で「インストール」をクリックします。

6. 「インストールの進行状況」画面で、「次へ」をクリックします。

7. 「インストール完了」画面で「終了」をクリックします。

7.4 Oracle Unified Directoryインスタンスの構成

次の手順に従って、IDMHOST1とIDMHOST2のアプリケーション層でOracle Unified Directoryコンポーネントを構成します。構成中、Oracle Unified Directoryレプリケーション・サーバーも構成します。

この項には次のトピックが含まれます:

- 第7.4.1項「IDMHOST1でのOracle Unified Directoryの構成」

- 第7.4.2項「IDMHOST1でのOracle Unified Directoryの検証」

- 第7.4.3項「IDMHOST2での追加のOracle Unified Directoryインスタンスの構成」

- 第7.4.4項「IDMHOST2でのOracle Unified Directoryの検証」

- 第7.4.5項「Oracle Unified Directory保証レプリケーションの有効化」

- 第7.4.7項「ロード・バランサを使用したOracle Unified Directoryの検証」

7.4.1 IDMHOST1でのOracle Unified Directoryの構成

使用しているオペレーティング・システムで次のコマンドを発行して、ポート1389 (LDAP_DIR_PORT)、1636 (LDAP_DIR_SSL_PORT)、4444 (LDAP_DIR_ADMIN_PORT)および8989 (LDAP_DIR_REPL_PORT)がコンピュータ上のサービスで使用されていないことを確認します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。

Linuxの場合:

netstat -an | grep "1389"

ポートが使用されている(コマンドからどちらかのポートを識別する出力が返された)場合は、ポートを解放する必要があります。

Linuxの場合:

/etc/servicesファイルでポート1389、1636、4444および8989のエントリを削除して、サービスまたはコンピュータを再起動します。

環境変数JAVA_HOMEを設定します

環境変数INSTANCE_NAMEを次のように設定します。

../../../../u02/private/oracle/config/instances/oud1

ツールはインスタンス・ホームをOUD_ORACLE_HOMEを基準にして作成するため、前のディレクトリを含めてOUD_ORACLE_INSTANCEで作成したインスタンスを取得する必要があります。

ディレクトリをOUD_ORACLE_HOMEに変更します

次のコマンドを実行してOracle Unified Directory構成アシスタントを起動します。

./oud-setup

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「サーバー設定」画面で、次を入力します。

- ホスト名: Oracle Unified Directoryが実行されているホストの名前(たとえばIDMHOST1.mycompany.com)

- LDAPリスナー・ポート: 1389 (LDAP_DIR_PORT)

- 管理コネクタ・ポート: 4444 (LDAP_DIR_ADMIN_PORT)

- LDAPセキュア・アクセス: 「構成」をクリックします

- 「セキュリティ・オプション」ページで次を入力します。

- SSLアクセス: 選択済。

- ポートでSSLを有効化: 1636 (LDAP_DIR_SSL_PORT)

- 証明書: 自己署名証明書を生成するまたは独自の証明書の詳細を提供します。

- 「OK」をクリックします。

- ルート・ユーザーDN: 管理ユーザーを入力します(たとえば、cn=oudadmin)

- パスワード: ouadminユーザーに割り当てるパスワードを入力します。

- パスワードの確認: パスワードを再入力します。

- 「次へ」をクリックします。

3. トポロジ・オプション画面で、次を入力します。

- 選択: このサーバーは、レプリケーション・トポロジの一部になります

- 入力: レプリケーション・ポート: 8989

- 選択: レプリケーション・トラフィックを暗号化する場合には、セキュアとして構成。

- トポロジにはすでにサーバーがあります。未選択のままにします。

「次へ」をクリックします。

4. ディレクトリ・データ画面で、次を入力します。

- ディレクトリ・ベースDN: dc=mycompany,dc=com

- ディレクトリ・データ: ベース・エントリのみを作成します

「次へ」をクリックします。

5. Oracleコンポーネントの統合画面で、「次へ」をクリックします。

6. ランタイム・オプション画面で、「次へ」をクリックします。

7. 「確認」画面で、表示された情報が正しいことを確認し、「終了」をクリックします。

8. 「終了」画面で、「閉じる」をクリックします。

7.4.2 IDMHOST1でのOracle Unified Directoryの検証

構成後、単純検索を実行することによってOracle Unified Directoryが動作することを検証できます。これを実行するには、次のコマンドを発行します。

OUD_ORACLE_INSTANCE/OUD/bin/ldapsearch -h IDMHOST1.mycompany.com -p 1389 -D cn=oudadmin -b "" -s base "(objectclass=*)" supportedControl

Oracle Unified Directoryが正常に動作している場合、リストsupportedControlエントリが返されます。

7.4.3 IDMHOST2での追加のOracle Unified Directoryインスタンスの構成

使用しているオペレーティング・システムで次のコマンドを発行して、ポート1389 (LDAP_DIR_PORT)、1636 (LDAP_DIR_SSL_PORT)、4444 (LDAP_DIR_ADMIN_PORT)および8989がコンピュータ上のサービスで使用されていないことを確認します。ポートが使用されていなければ、コマンドを実行しても何も出力されません。

Linuxの場合:

netstat -an | grep "1389"

ポートが使用されている(コマンドからどちらかのポートを識別する出力が返された)場合は、ポートを解放する必要があります。

Linuxの場合:

/etc/servicesファイルでポート1389、1636、4444および8989のエントリを削除して、サービスまたはコンピュータを再起動します。

環境変数JAVA_HOMEを設定します

環境変数INSTANCE_NAMEを../../../../u02/private/oracle/config/instances/oud2に設定します。

ツールはインスタンス・ホームをOUD_ORACLE_HOMEを基準にして作成するため、前のディレクトリを含めてOUD_ORACLE_INSTANCEで作成したインスタンスを取得する必要があります。

ディレクトリをOUD_ORACLE_HOMEに変更します

次のコマンドを実行してOracle Unified Directory構成アシスタントを起動します。

./oud-setup

1. 「ようこそ」画面で「次へ」をクリックします。

2. 「サーバー設定」画面で、次を入力します。

- ホスト名: Oracle Unified Directoryが実行されているホストの名前(たとえばIDMHOST2)

- LDAPリスナー・ポート: 1389 (LDAP_DIR_PORT)

- 管理コネクタ・ポート: 4444 (LDAP_DIR_ADMIN_PORT)

- LDAP保護アクセス

- 「構成」をクリックします

- SSLアクセスを選択します

- ポートでSSLを有効化: 1636 (LDAP_DIR_SSL_PORT)

- 証明書: 自己署名証明書を生成するまたは独自の証明書の詳細を提供します。

- 「OK」をクリックします。

- ルート・ユーザーDN: 管理ユーザーを入力します(たとえば、cn=oudadmin)

- パスワード: ouadminユーザーに割り当てるパスワードを入力します。

- パスワードの確認: パスワードを再入力します。

- 「次へ」をクリックします。

3. トポロジ・オプション画面で、次を入力します。

- このサーバーは、レプリケーション・トポロジの一部になります

- レプリケーション・ポート: 8989

- レプリケーション・トラフィックを暗号化する場合には、セキュアとして構成を選択します。

- トポロジにはすでにサーバーがあります: 選択済。
次を入力します。

- ホスト名: 既存のOracle Unified Directoryサーバー・ホストの名前(たとえば、IDMHOST1.mycompany.com)

- 管理者コネクタ・ポート: 4444 (LDAP_DIR_ADMIN_PORT)

- 管理ユーザー: IDMHOST1のOracle Unified Directory管理ユーザーの名前(たとえば、cn=oudadmin)

- 管理者パスワード: 管理者パスワード。

「次へ」をクリックします。

信頼されていない証明書ダイアログが表示される場合、これは自己署名証明書を使用しているためです。「永久受入れ」をクリックします。

「次へ」をクリックします。

4. グローバル管理者の作成画面で、次を入力します。

- グローバル管理者ID: Oracle Unified Directoryレプリケーションを管理するために使用するアカウントの名前(たとえば、oudmanager)

- グローバル管理者パスワード / 確認: このアカウントのパスワードを入力します。

「次へ」をクリックします。

5. データ・レプリケーション画面で、dc=mycompany,dc=comを選択し、「次へ」をクリックします。

6. Oracleコンポーネントの統合画面で、「次へ」をクリックします。

7. ランタイム・オプション画面で、「次へ」をクリックします。

8. 「確認」画面で、表示された情報が正しいことを確認し、「終了」をクリックします。

9. 「終了」画面で、「閉じる」をクリックします。

7.4.4 IDMHOST2でのOracle Unified Directoryの検証

構成後、単純検索を実行することによってOracle Unified Directoryが動作することを検証できます。これを実行するには、次のコマンドを発行します。

OUD_ORACLE_INSTANCE/OUD/bin/ldapsearch -h IDMHOST2.mycompany.com -p 1389 -D cn=oudadmin -b "" -s base "(objectclass=*)" supportedControl

Oracle Unified Directoryが正常に動作している場合、リストsupportedControlエントリが返されます。

7.4.5 Oracle Unified Directory保証レプリケーションの有効化

第2.2.2.2.1項「Oracle Unified Directoryについて」で説明したように、各Oracle Unified Directoryインスタンスから読み取られたデータが現在のものであることを確認する必要があります。これを実行するには、次のように安全読取りモードでOracle Unified Directory保証レプリケーションを有効化します。

1. IDMHOST1で次のコマンドを発行します。

OUD_ORACLE_INSTANCE/OUD/bin/dsconfig -h IDMHOST1 -p 4444 -D "cn=oudadmin" -j ./password_file -n \
set-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=mycompany,dc=com" \
--advanced \
--set assured-type:safe-read \
--trustAll

2. 次のコマンドを発行して、操作が成功したことを確認します。

OUD_ORACLE_INSTANCE/OUD/bin/dsconfig -h IDMHOST1 -p 4444 -D "cn=oudadmin" -j ./password_file -n \
get-replication-domain-prop \
--provider-name "Multimaster Synchronization" \
--domain-name "dc=mycompany,dc=com" \
--advanced \
--property assured-type --property assured-timeout --property group-id \
--trustAll

ここで、password_fileは、OUD管理者パスワードを含むファイルです。

安全モードが有効の場合、出力は次のようになります。

Property        : Value(s)
----------------:----------
assured-timeout : 2 s
assured-type    : safe-read
group-id        : 1

3. それぞれのOracle Unified Directoryインスタンス(たとえば、IDMHOST2)に対して手順1-2を繰り返します。

7.4.6 Oracle Unified Directoryオブジェクト作成制限の緩和

Oracle Identity Managementでは、Oracle Unified Directoryに多数のオブジェクト・クラスを作成する必要があります。次の手順を実行して、Oracle Unified Directoryで必要なオブジェクト・クラスの作成を可能にする必要があります。

各Oracle Unified Directoryインスタンスで次のコマンドを実行します。

OUD_ORACLE_INSTANCE/OUD/dsconfig -h IDMHOST1 -p 4444 -D "cn=oudadmin" -j ./password_file -n \
set-global-configuration-prop \
--set single-structural-objectclass-behavior:warn \
--trustAll

それぞれのOracle Unified Directoryインスタンス(たとえば、IDMHOST2)に対してこのコマンドを繰り返します。

7.4.7 ロード・バランサを使用したOracle Unified Directoryの検証

また、次のコマンドを発行して、ロード・バランサを使用してOracle Unified Directoryにアクセスできることを検証します。

OUD_ORACLE_INSTANCE/OUD/bin/ldapsearch -h LDAP_LBR_HOST -p LDAP_LBR_PORT -D OUD_Adminisitrator -b "" -s base "(objectclass=*)" supportedControl

例:

OUD_ORACLE_INSTANCE/OUD/bin/ldapsearch -h IDSTORE.mycompany.com -p 389 -D cn=oudadmin -b "" -s base "(objectclass=*)" supportedControl

Oracle Unified Directoryレプリケーションが有効になっていることを確認するには、次のコマンドを発行します。

OUD_ORACLE_INSTANCE/OUD/bin/status

サーバー証明書を信頼する方法を求められた場合、有効なオプションは次のとおりです。

- 自動的に信頼

- トラストストアを使用

- 手動で検証

いずれかを選択します。

管理者バインドDN (cn=oudadmin)およびそのパスワードの入力を要求されます。

次の例のような出力が表示されます。レプリケーションは有効に設定されます。

--- Server Status ---
Server Run Status: Started
Open Connections: 2

--- Server Details ---
Host Name: idmhost1
Administrative Users: cn=oudadmin
Installation Path: /u01/oracle/products/access/oud
Instance Path: /u02/private/oracle/config/instances/oud1/OUD
Version: Oracle Unified Directory 11.1.2.1.0
Java Version: 1.6.0_29
Administration Connector: Port 4444 (LDAPS)

--- Connection Handlers ---
Address:Port : Protocol : State
-------------:-------------:---------
-- : LDIF : Disabled
8989 : Replication : Enabled
0.0.0.0:161 : SNMP : Disabled
0.0.0.0:1389 : LDAP : Enabled
0.0.0.0:1636 : LDAPS : Enabled
0.0.0.0:1689 : JMX : Disabled

--- Data Sources ---
Base DN: dc=mycompany,dc=com
Backend ID: userRoot
Entries: 1
Replication: Enabled
Missing Changes: 0
Age Of Oldest Missing Change: <not available>

7.5 Oracle Unified Directoryのインストールのバックアップ

第17.6.3項「インストール時および構成時のバックアップの実行」の説明に従って、MiddlewareホームおよびOracle Unified Directoryのバックアップを実行します。

8 エンタープライズ・デプロイメント用のドメインの作成

この章では、構成ウィザード、Oracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlを使用してドメインを作成する方法について説明します。作成しているトポロジによって、作成する必要があるドメイン数が決まります。最初のドメインを作成すると、このドキュメントの後で説明するように、他の製品を使用してこれを拡張できます。

注意:

設定プロセスを開始する前にリリース・ノートを熟読してインストールとデプロイメントに関する考慮事項を確認することを強くお薦めします。

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

- 第8.1項「ドメイン作成の概要」

- 第8.2項「Oracle Fusion Middlewareホームのインストール」

- 第8.3章「コンソールURLおよびドメインについて」

- 第8.4項「構成ウィザードを実行してドメインを作成する方法」

- 第8.5項「構成後タスクおよび検証タスク」

- 第8.6項「WebLogic管理サーバーの手動フェイルオーバーのテスト」

- 第8.7項「WebLogicドメインのバックアップ」

8.1 ドメイン作成の概要

表8-1に、構成後タスクを含む、WebLogicドメインの作成手順を示します。

表8-1 WebLogicドメインの作成手順

手順

説明

詳細

WebLogicドメインの作成

構成ウィザードを起動してWebLogicドメインを作成します。

第8.4項「構成ウィザードを実行してドメインを作成する方法」

構成後タスクおよび検証タスク

構成後タスクおよび検証タスクの手順に従います。

第8.5項「構成後タスクおよび検証タスク」

ドメインのバックアップ

新しく構成したWebLogicドメインをバックアップします。

第8.7項「WebLogicドメインのバックアップ」

一度このドメインを作成し構成すると、次の章で説明するとおり、ドメインの拡張によって他のIdentity Managementコンポーネントを追加できます。

8.2 Oracle Fusion Middlewareホームのインストール

第4.4項「各種ディレクトリの推奨場所について」で説明したとおり、冗長性を確保するためにOracle Fusion Middlewareソフトウェアを少なくとも2つの記憶域にインストールします。

Middlewareホーム(MW_HOME)を作成するには、Oracle Fusion Middlewareの次に示すコンポーネントをインストールする必要があります。

1. Oracle WebLogic Server: 第8.2.1項「Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成」

2. 1つ以上のOracle Fusion Middlewareコンポーネント

1. 第8.2.2項「Oracle Identity and Access Managementのインストール」

2. 第8.2.3項「Oracle SOA Suiteのインストール」

3. アイデンティティ管理用Oracle Fusion Middleware

8.2.1 Oracle WebLogic ServerのインストールとFusion Middlewareホームの作成

この項では、Oracle WebLogic Serverを取得してインストールする方法について説明します。

8.2.1.1 JRockitのインストール

1. 次の場所からご使用のプラットフォーム用のバージョンのJRockitをダウンロードします。

http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html

2. 実行権限をJRockitに追加します。例:

chmod +x jrockit-1.6.0_29-R28.2.0-4.0.1-linux-x64.bin

3. 次のコマンドを発行して、JRockitインストーラを起動します。

./jrockit-version.bin

例:

./jrockit-1.6.0_29-R28.2.0-4.0.1-linux-x64.bin

4. 「ようこそ」画面で、「次へ」をクリックします。

5. 「製品インストール・ディレクトリの選択」画面で、Middlewareホーム内の製品インストール・ディレクトリを入力します。

6. オプション・コンポーネント画面で「次へ」をクリックします。

7. 「インストール 完了」画面で「完了」をクリックします。

8.2.1.2 汎用インストーラを使用したWebLogic Serverのインストール

1. Oracle WebLogic Serverの汎用インストーラをhttp://edelivery.oracle.comからダウンロードします

2. JRockitをパスに追加します。たとえば、Linuxの場合は次のコマンドを発行します。

export PATH=IAM_MW_HOME/jrockit-jdk1.6.0_29-R28.2.0-4.0.1/bin:$PATH

3. 次のコマンドを発行してJavaのバージョンを確認します。

java -version

64ビット・オペレーティング・システムを使用している場合、64ビット・バージョンが表示されていることを確認します。

4. 適切なコマンドを使用してWebLogicインストーラを起動します。
64ビット・オペレーティング・システム

java -d64 -jar wls1036_generic.jar

32ビット・オペレーティング・システム

java -jar wls1036_generic.jar

5. 「ようこそ」画面で「次へ」をクリックします。

6. Middlewareホームの選択画面で、「新しいミドルウェア・ホームを作成する」を選択します。
Middlewareホーム・ディレクトリとしてIAM_MW_HOMEへのパスを入力します。次の例:

/u01/oracle/products/access

「次へ」をクリックします。

7. ディレクトリが空ではないことを通知する警告が表示され、処理を進めるかどうか尋ねられます。
「はい」をクリックします。

8. 「セキュリティ更新のための登録」画面で、「My Oracle Support」のユーザー名およびパスワードを入力し、セキュリティ更新の通知を受信できるようにします。
「次へ」をクリックします。

9. 「インストール・タイプの選択」画面で、「標準」を選択します。

注意:

Oracle WebLogic ServerおよびOracle Coherenceがインストールされます。

10. 「JDKの選択」画面で、前にインスト-ルしたJRockit JDKを選択します。これはデフォルトでリストされます。

注意:

このガイドで説明する例ではJRockitを使用します。この手順では動作保証されたすべてのバージョンのJavaが使用可能であり、他に記載がないかぎり完全にサポートされます。

11. 「製品インストール・ディレクトリの選択」画面で、次の選択内容を受け入れます。

- Middlewareホーム・ディレクトリ: IAM_MW_HOME

- WebLogic Serverの製品インストール・ディレクトリ: IAM_MW_HOME/wlserver_10.3

- Oracle Coherence: IAM_MW_HOME/coherence_3.6

「次へ」をクリックします。

12. 「インストールの概要」画面で「次へ」をクリックして、インストール・プロセスを開始します

13. 「インストール完了」画面で、「Quickstartの実行」の選択を解除します。

14. 「完了」をクリックしてWebLogic Serverインストーラを終了します。

8.2.2 Oracle Identity and Access Managementのインストール

Oracle Identity and Access Managementには、次の製品が含まれます。

- Oracle Access Management Access Manager

- Oracle Identity Manager

この項の手順を実行して、表2-2「使用するソフトウェアのバージョン」に示されているホストにOracle Identity and Access Managementをインストールします。

システム、パッチ、カーネルなどの要件が満たされていることを確認します。それらの一覧は、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareのドキュメント・ライブラリの『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』にあります。

Oracle Identity and Access ManagementのOracle Fusion Middleware 11gインストーラを起動するには、ディレクトリをインストール・メディアのDisk1に変更し、次のコマンドを入力します。

./runInstaller

インストーラでJRE/JDKの場所を尋ねた場合、Oracle WebLogic Serverインストールで作成されたOracle SDKの場所を入力します。例:

IAM_MW_HOME/jrockit_version

次のインストール手順を実行します。

1. 「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:

- インベントリ・ディレクトリの指定: /u02/private/oracle/oraInventory

- オペレーティング・システムのグループ名: oinstall

次のメッセージのダイアログ・ボックスが表示されます。

Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u02/private/oracle/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option.

rootとしてログインし、次を実行します。

/u02/private/oracle/oraInventory/createCentralInventory.sh

これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。

注意:

すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。Oracle Inventory画面がこのインストールで表示されない場合、次を確認してください。

1. /etc/oraInst.locファイルが存在している。

2. 一覧のインベントリ・ディレクトリは有効である。

3. インストールを実行しているユーザーがインベントリ・ディレクトリに対する書込み権限を持っているか。

2. 「ソフトウェア更新のインストール」画面で、更新をスキップするかどうかの選択、更新情報を入手するためにOracleサポートをチェックまたは更新のローカルでの検索を行います。
「次へ」をクリックします。

3. 「ようこそ」画面で、「次へ」をクリックします。

4. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

5. 「インストール場所の指定」画面で、次の値を入力します。

- Oracle Middlewareホーム: すでにインストール済のMiddlewareホームをドロップダウン・リストから選択します。例: IAM_MW_HOME

- Oracleホーム・ディレクトリ: Oracleホーム・ディレクトリ名としてiamと入力します。

「次へ」をクリックします。

6. 「アプリケーション・サーバー」画面で、WebLogic Serverを選択し、「次へ」をクリックします。

7. 「インストール・サマリー」画面で「インストール」をクリックします。

8. 「インストールの進行状況」画面で、「次へ」をクリックします。

9. 「インストール完了」画面で「終了」をクリックします。

8.2.3 Oracle SOA Suiteのインストール

次の手順を実行し、Oracle SOA Suiteをインストールします。

システム、パッチ、カーネルなどの要件が満たされていることを確認します。これらは、使用しているプラットフォームおよびバージョンのOracle Fusion Middlewareドキュメント・ライブラリにあるOracle Fusion Middleware Oracle SOA Suite and Oracle Business Process Management Suiteインストレーション・ガイドにリストされています。

Oracle Fusion Middleware 11gSOA Suiteインストーラを起動するには、ディレクトリをインストール・メディアのDisk1に変更し、次のコマンドを入力します。

./runInstaller

インストーラでJRE/JDKの場所を尋ねた場合、Oracle WebLogic Serverインストールで作成されたOracle SDKの場所を入力します。例:

IAM_MW_HOME/jrockit_version

次のインストール手順を実行します。

1. 「インベントリ・ディレクトリの指定」画面で、Oracleインベントリ・ディレクトリおよびオペレーティング・システムのグループ名に値を入力します。例:

- インベントリ・ディレクトリの指定: /u02/private/oracle/oraInventory

- オペレーティング・システムのグループ名: oinstall

次のメッセージのダイアログ・ボックスが表示されます。

Certain actions need to be performed with root privileges before the install can continue. Please execute the script /u02/private/oracle/oraInventory/createCentralInventory.sh now from another window and then press "Ok" to continue the install. If you do not have the root privileges and wish to continue the install select the "Continue installation with local inventory" option.

rootとしてログインし、次を実行します。

/u02/private/oracle/oraInventory/createCentralInventory.sh

これにより、Oracleインベントリ・ディレクトリに必要な権限が設定され、「ようこそ」画面が表示されます。

注意:

すでにこのホストにOracle製品がインストールされている場合は、Oracleインベントリ画面は表示されません。Oracle Inventory画面がこのインストールで表示されない場合、次を確認してください。

1. /etc/oraInst.locファイルが存在している。

2. 一覧のインベントリ・ディレクトリは有効である。

3. インストールを実行しているユーザーがインベントリ・ディレクトリに対する書込み権限を持っているか。

2. 「ようこそ」画面で「次へ」をクリックします。

3. ソフトウェア更新のインストール画面で、更新情報を入手するためにOracleサポートに登録するか、ローカルに更新を検索するかを選択します。
「次へ」をクリックします。

4. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認してから、「次へ」をクリックします。

5. 「インストール場所の指定」画面で、次の値を入力します。

- Oracle Middlewareホーム: すでにインストール済のMiddlewareホームをドロップダウン・リストから選択します。例: IAM_MW_HOME

- Oracleホーム・ディレクトリ: Oracleホーム・ディレクトリ名としてsoaと入力します。

注意:

すべてのホスト上で、Oracle SOA Suiteに対して同じOracleホーム・ディレクトリ名を使用する必要があります。

6. 「次へ」をクリックします。

7. 「アプリケーション・サーバー」画面で、アプリケーション・サーバーを選択します(例: Web Logic Server)。
「次へ」をクリックします。

8. 「インストール・サマリー」画面で「インストール」をクリックします。

9. インストール・プロセス画面で、「次へ」をクリックします。

10. 「インストール完了」画面で「終了」をクリックします。

8.3 コンソールURLおよびドメインについて

ドメインに関連するコンポーネントURLおよびこれらにアクセスするために使用するユーザー名は、次の表にリストされています。

表8-2 Web層統合後に使用可能なURL

コンポーネント

URL

ユーザー

WebLogicコンソール

http://ADMIN.mycompany.com/console

weblogic

Fusion Middleware Control

http://ADMIN.mycompany.com/em

weblogic

8.4 構成ウィザードを実行してドメインを作成する方法

作成する各ドメインに対してIDMHOST1でWebLogic構成ウィザードを1回実行します。後の章で、これらのドメインを拡張して、トポロジのコンポーネントを追加します。

ドメインを作成するには:

1. リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースの場合は、後で実行する検証チェックの信頼性を確保するために、すべてのインスタンスを実行しておく必要があります。

2. 構成ウィザードの場所にディレクトリを変更します。これはORACLE_COMMON_HOME内にあります。

cd ORACLE_COMMON_HOME/common/bin

3. 次のように入力して、Oracle Fusion Middleware構成ウィザードを起動します。

./config.sh

4. 「ようこそ」画面で、「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

5. 「ドメイン・ソースの選択」画面で、次の製品を選択します。

- Oracle Entitlements Server for Admin Server [iam]

- Oracle Enterprise Manager [oracle_common]

- Oracle Platform Security Service [iam]

- Oracle Directory Services Manager [oud](Oracle Unified Directoryを使用している場合)

- Oracle JRF [oracle_common]

「次へ」をクリックします。

6. 「ドメイン名と場所の指定」画面で、次を入力します。

- ドメイン名: IDMDomain

- ドメインの場所:

/u01/oracle/config/domains

- アプリケーションの場所:

ASERVER_HOME/applications

ドメイン・ディレクトリが第4.4項「各種ディレクトリの推奨場所について」でお薦めされているディレクトリおよび共有記憶域のマウント・ポイントと一致していることを確認します。

「次へ」をクリックします。

7. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者用に使用するユーザー名(デフォルトはweblogic)とパスワードを入力します。例:

- 名前: weblogic

- ユーザー・パスワード: Weblogicユーザーのパスワード

- ユーザー・パスワードの確認: Weblogicユーザーのパスワード

- 説明: このユーザーはデフォルトの管理者です。

「次へ」をクリックします。

8. 「サーバーの起動モードおよびJDKの構成」画面で、次の手順を実行します。

- 「WebLogicドメインの起動モード」に「本番モード」を選択します。

- 「JDKの選択」では、「JRockit SDK」を選択します。

「次へ」をクリックします。

注意:

次の手順および手順12「コンポーネント・スキーマのテスト」までのすべての手順は、作成するドメインがIDMDomainまたはOIMDomainの場合のみ関係があります。

9. 「JDBCコンポーネント・スキーマの構成」画面で、次を選択します。

- OPSSスキーマ

「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。

「次へ」をクリックします。

10. GridLink RACコンポーネント・スキーマ画面が表示されます。この画面で、次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLink Connections用ドライバ(Thin)バージョン: 10以上を選択します。

- 「FANの有効化」を選択します。

- 次のいずれかの操作を実行します。

- 暗号化するONS通知としてSSLが選択されていない場合、SSLを選択解除します。

- SSLを選択し、適切なWalletおよびWalletのパスワードを指定します。

- サービス・リスナー: 使用するRACデータベースのためのSCANアドレスとポートを入力します。このアドレスは、データベース内のパラメータremote_listenerを問い合せれば識別できます。

SQL>show parameter remote_listener;
NAME            TYPE   VALUE
-------------------------------------------------------------
remote_listener string DB-SCAN.mycompany.com:1521

注意:

- Oracle Database 11gリリース1 (11.1)の場合、各データベース・インスタンスの仮想IPおよびポート(たとえば、DBHOST1-VIP.mycompany.com (ポート1521)やDBHOST2-VIP.mycompany.com (ポート1521))を使用します。ここで1521はDB_LSNR_PORTです

- Oracle Database 10gでは、Oracle RACデータベースへの接続にマルチ・データ・ソースを使用します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ONSホスト: 次のコマンドを呼び出すときにデータベースがレポートしたOracle RACデータベースのSCANアドレスおよびONSリモート・ポートを入力します。

srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:

Oracle Database 11gリリース1 (11.1)では、各データベースのONSサービスのホスト名とポートを使用します(たとえば、DBHOST1.mycompany.com (ポート6200)やDBHOST2.mycompany.com (ポート6200))

次のRACコンポーネント・スキーマ情報を入力します。

スキーマの名前

サービス名

スキーマの所有者

パスワード

OPSSスキーマ

OESEDG.mycompany.com

EDG_OPSS

password

RACマルチ・データ・ソースを使用する場合、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

「次へ」をクリックします。

11. 「JDBCデータ・ソースのテスト」画面で、すべての接続が正常であることを確認します。接続のテストは自動的に行われます。「ステータス」列に結果が表示されます。正常でない接続がある場合は、「前へ」をクリックして前の画面に戻り、入力を訂正します。
すべての接続が正常になったら「次へ」をクリックします。

12. 「コンポーネント・スキーマのテスト」画面で、ウィザードによりデータ・ソースを検証します。データ・ソースの検証が成功した場合、「次へ」をクリックします。失敗した場合、「前へ」をクリックして問題に対処してから、再試行します。

13. 「オプションの構成を選択」画面で、次を選択します。

- 管理サーバー

- 管理対象サーバー、クラスタ、およびマシン

「次へ」をクリックします。

14. 「管理サーバーの構成」画面で、次の値を入力します。

- 名前: AdminServer

- リスニング・アドレス: ADMINVHN.mycompany.com

- リスニング・ポート: 7001 (WLS_ADMIN_PORT)

- SSLリスニング・ポート: 7002 (WLS_ADMIN_SSL_PORT)

- SSL有効: 選択済

「次へ」をクリックします。

15. 「管理対象サーバーの構成」画面で、「次へ」をクリックします。

16. 「クラスタの構成」画面で、「次へ」をクリックします。

17. 「マシンの構成」画面で、「UNIXマシン」タブをクリックし、「追加」をクリックして次のマシンを追加します。マシン名が有効なホスト名またはリスニング・アドレスである必要はなく、単にノード・マネージャの場所の一意のIDです。

- 名前: ADMINHOST

- ノード・マネージャ・リスニング・アドレス: LOCALHOST

注意:

LOCALHOSTはすべてのアクティブなマシンの相対内部アドレスであるため、仮想ホスト・マシンはLOCALHOSTを指す必要があります。管理サーバーはlocalhost属性と1つ目のホストを組み合せて使用し、フェイルオーバー後は2つ目のホストも使用するため、管理サーバーのフェイルオーバー時には管理サーバーと関連付けられているノード・マネージャも変更されます。

18. 「次へ」をクリックします。

19. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- ADMINHOST: AdminServer

ここで、ADMINHOSTは手順17で入力した名前の値です。例:

ADVINVHN.mycompany.com

「次へ」をクリックします。

20. 「構成のサマリー」画面で、選択が正しいことを確認してから、「作成」をクリックします。

21. ドメインの作成画面で、「完了」をクリックします。

8.5 構成後タスクおよび検証タスク

構成ウィザードでドメインを構成したら、次の手順に従って構成後タスクと検証タスクを実行します。

この項には次のトピックが含まれます:

- 第8.5.1項「OIMアダプタ・テンプレートのコピー」

- 第8.5.2項「WebLogic管理サーバーのboot.propertiesの作成」

- 第8.5.3項「ドメインと既存のOPSSポリシー・ストアの再関連付け」

- 第8.5.4項「ノード・マネージャの起動」

- 第8.5.5項「ノード・マネージャ資格証明の更新」

- 第8.5.6項「WebLogic管理サーバーの検証」

- 第8.5.7項「WebLogicプラグインの有効化」

- 第8.5.8項「Oracle WebLogic管理サーバーのホスト名検証の無効化」

- 第8.5.9項「WebLogic管理サーバーの停止と起動」

8.5.1 OIMアダプタ・テンプレートのコピー

この項は、トポロジ・ダイアグラムに示すようにOracle Unified Directoryをアクティブ/アクティブ・モードで使用している場合のみ必要です。

Oracle Identity and Access Managementをインストールした後、パッチ16943171を適用します。

次に、ファイルadapter_template_oim.xmlをORACLE_COMMON_HOME/modules/oracle.ovd_11.1.1/templates/からIAM_ORACLE_HOME/libovd/に手動でコピーします。例:

cp ORACLE_COMMON_HOME/modules/oracle.ovd_11.1.1/templates/adapter_template_oim.xml IAM_ORACLE_HOME/libovd/

8.5.2 WebLogic管理サーバーのboot.propertiesの作成

ホストIDMHOST1に管理サーバー用のboot.propertiesファイルを作成します。ファイルがすでに存在する場合は、ファイルを編集します。boot.propertiesファイルを使用すると、管理者のユーザー名とパスワードを要求せずに管理サーバーを起動できます。

各管理サーバーに対して:

1. 次のディレクトリ構造を作成します。

mkdir -p ASERVER_HOME/servers/AdminServer/security

2. テキスト・エディタで、boot.propertiesというファイルを前の手順で作成された最後のディレクトリに作成し、このファイルにユーザー名とパスワードを入力します。例:

username=weblogic
password=password for weblogic user

3. ファイルを保存してエディタを閉じます。

注意:

ファイルのユーザー名およびパスワードのエントリは、第8.5.5項「ノード・マネージャ資格証明の更新」で説明されているように管理サーバーを起動するまで暗号化されません。セキュリティ上の理由から、ファイル内のエントリが暗号化されていない時間を最小に抑えてください。ファイルを編集した後、できるだけ速やかにサーバーを起動し、エントリを暗号化してください。

8.5.3 ドメインと既存のOPSSポリシー・ストアの再関連付け

初めてドメインを起動する前に、ドメインをデータベースのOPSSポリシー・ストアと再関連付けする必要があります。これを行うには、次の手順を実行します。

最初のドメインをOPSSセキュリティ・ストアと再関連付けするには、次のコマンドを使用します。

ORACLE_COMMON_HOME/common/bin/wlst.sh IAM_ORACLE_HOME/common/tools/configureSecurityStore.py -d ASERVER_HOME -c IAM -m create -p opss_schema_password

次のコマンドを発行して、前述のコマンドが成功したことを確認します。

ORACLE_COMMON_HOME/common/bin/wlst.sh IAM_ORACLE_HOME/common/tools/configureSecurityStore.py -d ASERVER_HOME -m validate

8.5.4 ノード・マネージャの起動

次の手順を実行して、IDMHOST1でノード・マネージャを起動し、nodemanager.propertiesファイルを作成します。

1. WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行します。

2. setNMProps.shスクリプトを実行して、StartScriptEnabledプロパティをtrueに設定します。

cd IAM_MW_HOME/oracle_common/common/bin
./setNMProps.sh

注意:

StartScriptEnabledプロパティを使用して、クラスのロード失敗などの問題を防止する必要があります。

3. ノード・マネージャ・プロセスを強制終了してノード・マネージャを停止します。

IAM_MW_HOME/wlserver_10.3/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、IDMHOST1とIDMHOST2でノード・マネージャを起動します。

8.5.5 ノード・マネージャ資格証明の更新

WLSTを使用し、ノード・マネージャに接続して、管理サーバーを起動します。ただし、ノード・マネージャを使用して管理サーバーを最初に起動するとき、構成ウィザードでノード・マネージャに設定するデフォルトのユーザー名とパスワードを変更する必要があります。したがって、最初に起動では管理サーバーの起動スクリプトを使用する必要があります。次の手順に従って、ノード・マネージャを使用して管理サーバーを起動します。最初の起動操作には手順1-4が必要ですが、2回目以降の起動には手順4のみが必要です。

1. ドメイン・ディレクトリの起動スクリプトを使用して、管理サーバーを起動します。

cd ASERVER_HOME/bin
./startWebLogic.sh

2. 管理コンソールを使用して、IDMDomainでノード・マネージャ資格証明を更新します。

1. ブラウザで、ドメインのリスニング・アドレスに移動します。例:
http://ADMINVHN.mycompany.com:7001/consoleここで、7001はWLS_ADMIN_PORTです(第B.3を参照)。

2. 管理者としてログインします。

3. 「ロックして編集」をクリックします。

4. 「ドメイン構造」メニューでdomain_nameをクリックします。

5. 「セキュリティ」タブを選択して、「一般」タブを選択します。

6. 「拡張オプション」を拡張します。

7. ノード・マネージャ用に新しいユーザー名を入力するか、または既存のユーザー名をメモしてノード・マネージャのパスワードを更新します。

8. 「保存」をクリックします。

9. 「変更のアクティブ化」をクリックします。

3. コマンドstopWebLogic.shを発行して、WebLogic管理サーバーを停止します。このコマンドは、ASERVER_HOME/binディレクトリの下にあります。

4. WLSTを起動し、nmConnectと更新した資格証明を使用してノード・マネージャに接続します。nmStartを使用して、WebLogic管理サーバーを起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

WLSTシェルで一度、次のコマンドを実行します。

nmConnect('Admin_User','Admin_Password', 'ADMINHOST1','Port',
'domain_name','ASERVER_HOME')
nmStart('AdminServer')

ここで、PortはNMGR_PORT(第B.3項)、domain_nameはドメインの名前、Admin_UserおよびAdmin_Passwordはノード・マネージャのユーザー名およびパスワード(手順2で入力)です。例:

nmConnect('admin','password', 'IDMHOST1','5556',
'IDMDomain','ASERVER_HOME')
nmStart('AdminServer')

8.5.6 WebLogic管理サーバーの検証

次の手順実行して、管理サーバーが正しく構成されていることを確認します。

1. ブラウザで、次のURLでOracle WebLogic Server管理コンソールに移動します。
http://ADMINVHN.mycompany.com:7001/consoleここで、7001はWLS_ADMIN_PORTです(第B.3項を参照)。

2. WebLogic管理者(たとえば、webLogic)としてログインします。

3. http://ADMINVHN.mycompany.com:7001/emでOracle Enterprise Manager Fusion Middleware Controlにアクセスできることを確認します。

4. WebLogic管理者(たとえば、webLogic)としてOracle Enterprise Manager Fusion Middleware Controlにログインします。

8.5.7 WebLogicプラグインの有効化

エンタープライズ・デプロイメントでは、Oracle HTTP ServerがOracle WebLogic Serverの前面になります。HTTP Serverの前面は、SSL変換を実行するロード・バランサとなります。https接頭辞を付けて内部ループバックURLを生成するには、Oracle HTTP Server WebLogicプラグイン経由でリクエストを受信するようOracle WebLogic Serverに通知する必要があります。

ドメイン、クラスタ、または管理対象サーバーのいずれかのレベルで、プラグインを設定できます。Oracle WebLogic ServerへのすべてのリクエストがOracle OHSプラグイン経由で送信されるので、ドメイン・レベルでこれを設定します。

これを行うには、次の手順を実行します。

1. http://ADMINVHN.mycompany.com/consoleでOracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. domain_nameをクリックします(たとえば、「ドメイン構造」メニューでIDMDomainをクリック)。

4. 「構成」タブをクリックします。

5. 「Webアプリケーション」サブタブをクリックします。

6. 「WebLogicプラグインの有効化」を選択します。

7. 「保存」をクリックして、「変更をアクティブ化します。」をクリックします。

8.5.8 Oracle WebLogic管理サーバーのホスト名検証の無効化

この手順が必要になるのは、管理サーバーで様々なノードの認証を行うための適切な証明書を設定していない場合です。(第13章「エンタープライズ・デプロイメント用のノード・マネージャの設定」を参照してください。)サーバー証明書を構成していない場合、異なるWebLogic Serverを管理するとエラーが発生します。これらのエラーを回避するには、ホスト名の検証を無効にする一方でトポロジの設定と検証を行い、第13章「エンタープライズ・デプロイメント用のノード・マネージャの設定」の説明に従ってEDGトポロジの構成を完了した後に再びホスト名の検証を有効にします

次の手順を実行してホスト名検証を無効します。

1. 次のURLでOracle WebLogic Server管理コンソールに移動します。http://ADMINVHN.mycompany.com:7001/console。ここで、7001はWLS_ADMIN_PORTです(第B.3項を参照)。

2. インストール時に指定したパスワードを使用して、ユーザーweblogicとしてログインします。

3. 「ロックして編集」をクリックします。

4. 「環境」ノードを「ドメイン構造」ウィンドウで開きます。

5. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

6. 表の「名前」列で、「AdminServer(admin)」を選択します。「AdminServer(admin)」の「設定」ページが表示されます。

7. 「SSL」タブをクリックします。

8. 「詳細」をクリックします。

9. 「ホスト名の検証」を「なし」に設定します(まだ設定されていない場合)。

10. 「保存」をクリックします。

11. 「変更のアクティブ化」をクリックします。

8.5.9 WebLogic管理サーバーの停止と起動

第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、管理サーバーを停止します。

注意:

Admin_UserとAdmin_Passwordのみを使用して、ノード・マネージャとクライアントとの間の接続を認証します。これらはサーバー管理IDおよびパスワードとは独立しており、ASERVER_HOME/config/nodemanager/nm_password.propertiesファイルに格納されます。

8.6 WebLogic管理サーバーの手動フェイルオーバーのテスト

管理サーバーからIDMHOST2へのフェイルオーバーおよびIDMHOST1への戻しをテストします(第17.9項「WebLogic管理サーバーの手動フェイルオーバー」を参照)

8.7 WebLogicドメインのバックアップ

第17.6.3項「インストール時および構成時のバックアップの実行」の説明に従って、Middlewareホーム、データベースおよびWebLogicドメインのバックアップを実行します。

9 アイデンティティ・ストアの準備

この章では、Oracle Identity Managementエンタープライズ・デプロイメントでアイデンティティ・ストアを準備する方法を説明します。

次の項が含まれます:

- 第9.1項「アイデンティティ・ストアの準備の概要」

- 第9.2項「LDAPディレクトリのバックアップ」

- 第9.3項「前提条件」

- 第9.4項「アイデンティティ・ストアの準備」

- 第9.5項「Oracle Virtual Directoryにおけるアダプタの作成」

- 第9.6項「アイデンティティ・ストアのバックアップ」

9.1 アイデンティティ・ストアの準備の概要

アイデンティティ・ストアの準備には、ディレクトリのスキーマを拡張してOracle Access Management Access ManagerおよびOracle Identity Managerをサポートし、アイデンティティ管理トポロジを構築する際に使用するシステム・ユーザーでアイデンティティ・ストアをシードすることが含まれます。

9.2 LDAPディレクトリのバックアップ

この章で説明する手順では、アイデンティティ・ストアをホストするLDAPディレクトリの構成を変更します。これらの作業を実行する前に、第17.6.3項「インストール時および構成時のバックアップの実行」の説明に従って、LDAPディレクトリのバックアップを作成します。

9.3 前提条件

続行する前に、次の条件を満たしていることを確認します。

- Oracle Unified Directoryなどの高可用性LDAPディレクトリが使用可能になっています。

- 必要に応じて、Active Directoryなどその他のディレクトリがインストールされ使用可能になっています。

9.4 アイデンティティ・ストアの準備

この項では、アイデンティティ・ストアを準備する方法について説明します。次のトピックが含まれます:

- 第9.4.1項「アイデンティティ・ストアの準備の概要」

- 第9.4.2項「構成ファイルの作成」

- 第9.4.3項「Access ManagerおよびOracle Identity Manager用のディレクトリの準備」

- 第9.4.4項「ユーザーとグループの作成」

- 第9.4.5項「不足しているOracle Internet Directoryオブジェクト・クラスの追加」

- 第9.4.6項「不足しているOracle Unified Directoryの権限の追加」

- 第9.4.7項「Oracle Unified Directory変更ログのアクセス権の付与」

- 第9.4.8項「Oracle Unified Directoryの索引の作成」

- 第9.4.9項「Oracle Internet DirectoryおよびOracle Unified Directory以外のディレクトリへのアクセス制御リストの作成」

9.4.1 アイデンティティ・ストアの準備の概要

ディレクトリを使用してAccess Managerをサポートできるようするには、その前にディレクトリを拡張して、使用しているLDAPディレクトリにAccess Managerで必要なオブジェクト・クラスを追加する必要があります。

ディレクトリ・スキーマの拡張に加えて、複数のユーザーを作成する必要もあります。これらのユーザーは、次の作業を行うためのガイドで後ほど使用します。

- 専用ユーザー使用によるディレクトリへのアクセス。

- Access Manager、ディレクトリおよびWebLogicが認証を外部ディレクトリにオフロードした後に、これらの製品へのアクセス。

9.4.2 構成ファイルの作成

プロパティ・ファイルidstore.propsをIDMHOST1に作成し、アイデンティティ・ストアを準備するときに使用します。ファイルの構造は次のとおりです。

Oracle Unified Directoryの例

# Common
IDSTORE_HOST: IDMHOST1.mycompany.com
IDSTORE_PORT: 1389
IDSTORE_ADMIN_PORT: 4444
IDSTORE_KEYSTORE_FILE: OUD_ORACLE_INSTANCE/OUD/config/admin-keystore
IDSTORE_KEYSTORE_PASSWORD: Password key
IDSTORE_BINDDN: cn=oudadmin
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com
IDSTORE_NEW_SETUP: true
POLICYSTORE_SHARES_IDSTORE: true
# OAM
IDSTORE_OAMADMINUSER:oamadmin
IDSTORE_OAMSOFTWAREUSER:oamLDAP
OAM11G_IDSTORE_ROLE_SECURITY_ADMIN:OAMAdministrators
# OAM and OIM
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,dc=com
# OIM
IDSTORE_OIMADMINGROUP: OIMAdministrators
IDSTORE_OIMADMINUSER: oimLDAP
# WebLogic
IDSTORE_WLSADMINUSER : weblogic_idm
IDSTORE_WLSADMINGROUP : WLSAdmins

Oracle Internet Directoryの例

# Common
IDSTORE_HOST: OIDHOST1.mycompany.com
IDSTORE_PORT: 3060
IDSTORE_BINDDN: cn=orcladmin
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com
POLICYSTORE_SHARES_IDSTORE: true
IDSTORE_NEW_SETUP: true
# OAM
IDSTORE_OAMADMINUSER:oamadmin
IDSTORE_OAMSOFTWAREUSER:oamLDAP
OAM11G_IDSTORE_ROLE_SECURITY_ADMIN:OAMAdministrators
# OAM and OIM
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,dc=com
# OIM
IDSTORE_OIMADMINGROUP: OIMAdministrators
IDSTORE_OIMADMINUSER: oimLDAP
# WebLogic
IDSTORE_WLSADMINUSER : weblogic_idm
IDSTORE_WLSADMINGROUP : WLSAdmins

ここで:

- IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストア・ディレクトリのホストおよびポートに対応します。OVDではなく、バックエンド・ディレクトリを指定します。OIDおよびOUDの場合、Oracle Internet DirectoryまたはOracle Unified Directoryのインスタンスの1つをそれぞれ指定します。例:
OID: OIDHOST1と3060

OUD: IDMHOST1と1389

- IDSTORE_ADMIN_PORT (LDAP_DIR_ADMIN_PORT)は、Oracle Unified Directoryインスタンスの管理ポートです。Oracle Unified Directoryを使用していない場合、このパラメータを省略できます。

- IDSTORE_KEYSTORE_FILEは、Oracle Unified Directoryのキーストア・ファイルの場所です。これは、Oracle Unified Directory管理ポートを使用したOracle Unified Directoryとの通信を有効にするために使用されます。これはadmin-keystoreと呼ばれ、OUD_ORACLE_INSTANCE/OUD/configにあります。Oracle Unified Directoryを使用していない場合、このパラメータを省略できます。このファイルは、idmConfigToolコマンドが実行されているホストと同じホストに配置する必要があります。コマンドは、このファイルを使用してOUDで自己認証します。

- IDSTORE_KEYSTORE_PASSWORDは、Oracle Unified Directoryのキーストアの暗号化されたパスワードです。この値は、ファイルOUD_ORACLE_INSTANCE/OUD/config/admin-keystore.pinにあります。Oracle Unified Directoryを使用していない場合、このパラメータを省略できます。

- IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。

- IDSTORE_GROUPSEARCHBASEは、グループが格納されるディレクトリの場所です。

- IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。

- IDSTORE_USERNAMEATTRIBUTEは、ユーザーの名前を含むディレクトリ属性の名前です。これはログイン名とは異なります。

- IDSTORE_LOGINATTRIBUTEは、ユーザーのログイン名を記述したLDAP属性です。

- IDSTORE_USERSEARCHBASEは、ユーザーが格納されるディレクトリの場所です。

- IDSTORE_NEW_SETUPは、Oracle Unified Directoryに対して常にtrueに設定されています。OUDを使用していない場合、この属性を指定する必要はありません。

- POLICYSTORE_SHARES_IDSTOREは、IDM 11gに対してtrueに設定されています。

- IDSTORE_OAMADMINUSERは、Access Manager管理者として作成するユーザーの名前です。

- IDSTORE_OAMSOFTWAREUSERは、LDAPに作成されるユーザーで、Access Managerが実行中にLDAPサーバーに接続するために使用されます。

- OAM11G_IDSTORE_ROLE_SECURITY_ADMINは、OAMコンソールへのアクセスを許可するために使用するグループの名前です。

- IDSTORE_SYSTEMIDBASEは、メイン・ユーザー・コンテナに配置する必要のないユーザーを配置できるディレクトリにあるコンテナの場所です。このような事態はほとんどありませんが、その一例としてOracle Virtual DirectoryアダプタのバインドDNユーザーにも使用されるOracle Identity Managerリコンシリエーション・ユーザーがあげられます。

- IDSTORE_OIMADMINGROUPは、Oracle Identity Manager管理ユーザーを保持するために作成するグループの名前です。

- IDSTORE_OIMADMINUSERは、アイデンティティ・ストアに接続するためにOracle Identity Managerが使用するユーザーです。

- IDSTORE_WLSADMINUSER: SSOによって有効化された後にWeb Logicドメインへのログインに使用するユーザー名。

- IDSTORE_WLSADMINGROUP: WebLogicシステム・コンポーネント(WLSコンソール、EMなど)へのログインを許可されたユーザーが属するグループの名前。

OIMエントリは、トポロジにOracle Identity Managerが含まれている場合のみ使用します。OAMエントリは、トポロジにAccess Managerが含まれている場合のみ使用します。

9.4.3 Access ManagerおよびOracle Identity Manager用のディレクトリの準備

この項では、Oracle Unified Directory、Oracle Internet DirectoryまたはActive Directoryをアイデンティティ・ストアとしてサポートするよう、Identity Managementコンポーネントをデプロイする方法を説明します。

次のトピックが含まれます:

- 第9.4.3.1項「Access ManagerおよびOracle Identity Managerで使用するためのOracle Unified DirectoryおよびOracle Internet Directoryの構成」

- 第9.4.3.2項「Access ManagerおよびOracle Identity Managerで使用するためのActive Directoryの構成」

9.4.3.1 Access ManagerおよびOracle Identity Managerで使用するためのOracle Unified DirectoryおよびOracle Internet Directoryの構成

アイデンティティ・ストアを事前構成すると、Oracle Unified DirectoryまたはOracle Internet Directoryでスキーマが拡張されます。

注意:

Access ManagerまたはOracle Identity Managerを使用していないかぎり、アイデンティティ・ストアを事前構成する必要はありません。

そのためには、IDMHOST1で次のタスクを実行します。

1. MW_HOMEをIAM_MW_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

JAVA_HOMEをJAVA_HOMEに設定します。

2. 次の場所にあるidmConfigToolコマンドを使用してアイデンティティ・ストアを構成します。
IAM_ORACLE_HOME/idmtools/bin

注意:

idmConfigToolを実行すると、idmDomainConfig.paramファイルが作成されるか、既存のこのファイルに情報が追加されます。このファイルは、idmConfigToolを実行したディレクトリに作成されます。このツールを実行するたびに同じファイルに情報が追加されるようにするには、必ず次のディレクトリでidmConfigToolを実行します。

IAM_ORACLE_HOME/idmtools/bin

このコマンドの構文は次のとおりです。

idmConfigTool.sh -preConfigIDStore input_file=configfile

例:

idmConfigTool.sh -preConfigIDStore input_file=idstore.props

このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを入力するように要求されます。このコマンドの実行には時間を要する場合があります。

コマンドの出力例:

Enter ID Store Bind DN password :
Dec 4, 2012 11:39:19 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: /u01/oracle/products/access/iam/idmtools/templates/oud/oud_schema_extn.ldif
Dec 4, 2012 11:39:20 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: /u01/oracle/products/access/iam/oam/server/oim-intg/ldif/ojd/schema/ojd_oam_pwd_schema_add.ldif
Dec 4, 2012 11:39:20 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: /u01/oracle/products/access/iam/oam/server/oim-intg/ldif/ojd/schema/ojd_user_schema_add.ldif
Dec 4, 2012 11:39:20 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: /u01/oracle/products/access/iam/oam/server/oim-intg/ldif/ojd/schema/ojd_user_index_generic.ldif
Dec 4, 2012 11:39:21 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: /u01/oracle/products/access/iam/idmtools/templates/oud/add_oraclecontext_container.ldif
Dec 4, 2012 11:39:21 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: /u01/oracle/products/access/iam/idmtools/templates/oud/oud_indexes_extn.ldif
Dec 4, 2012 11:39:21 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: /u01/oracle/products/access/iam/idmtools/templates/oud/idm_idstore_groups_template.ldif
Dec 4, 2012 11:39:21 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: /u01/oracle/products/access/iam/idmtools/templates/oud/idm_idstore_groups_acl_template.ldif
Dec 4, 2012 11:39:21 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: /u01/oracle/products/access/iam/idmtools/templates/oud/systemid_pwdpolicy.ldif
Dec 4, 2012 11:39:21 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING: /u01/oracle/products/access/iam/idmtools/templates/oud/fa_pwdpolicy.ldif
The tool has completed its operation. Details have been logged to automation.log

3. ログ・ファイルを確認して、エラーや警告を修正します。このツールを実行したディレクトリにautomation.logというファイルが作成されます。

注意:

idmConfigToolは、ユーザーを作成するだけでなく、次のグループも作成します。

- orclFAUserReadPrivilegeGroup

- orclFAUserWritePrivilegeGroup

- orclFAUserWritePrefsPrivilegeGroup

- orclFAGroupReadPrivilegeGroup

- orclFAGroupWritePrivilegeGroup

関連項目:

idmConfigToolコマンドの詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合概要』を参照してください。

9.4.3.2 Access ManagerおよびOracle Identity Managerで使用するためのActive Directoryの構成

この項では、Active Directoryを構成する方法を説明します。Active Directoryのスキーマを次のように拡張します。

注意:

手順の実行順序は重要です。

1. 次のファイルを探します。
IDM_ORACLE_HOME/oam/server/oim-intg/ldif/ad/schema/ADUserSchema.ldif

IDM_ORACLE_HOME/oam/server/oim-intg/ldif/ad/schema/AD_oam_pwd_schema_add.ldif

2. これらの両ファイルで、domain-dnを適切なdomain-dn値に置き換えます。

3. コマンドラインでldapaddを使用して、次のように2つのLDIFファイルをロードします。

ldapadd -h activedirectoryhostname -p activedirectoryportnumber -D AD_administrator -q -c -f file

ここで、AD_administratorは、ディレクトリに対するスキーマ拡張権限を持つユーザーです。

例:

ldapadd -h "ACTIVEDIRECTORYHOST.mycompany.com" -p 389 -D adminuser –q -c -f ADUserSchema.ldif
ldapadd -h "ACTIVEDIRECTORYHOST.mycompany.com" -p 389 -D adminuser -q -c -f AD_oam_pwd_schema_add.ldif

注意:

-Dの後に、DNまたはuser@domain.comのどちらかを指定できます。

4. 次のディレクトリに移動します。
IAM_MW_HOME/oracle_common/modules/oracle.ovd_11.1.1/oimtemplates

Active Directoryスキーマを拡張するには、次のコマンドを実行します。

sh extendadschema.sh -h AD_host -p AD_port -D 'administrator@mydomain.com' -AD "dc=mydomain,dc=com" -OAM true

9.4.4 ユーザーとグループの作成

Identity Managementコンポーネントで必要なユーザーとグループでアイデンティティ・ストアをシードする必要があります。

アイデンティティ・ストアをシードするには、IDMHOST1で次のタスクを実行する必要があります。

1. MW_HOMEをIAM_MW_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

JAVA_HOMEをJAVA_HOMEに設定します。

2. 次の場所にあるidmConfigToolコマンドを使用してアイデンティティ・ストアを構成します。
IAM_ORACLE_HOME/idmtools/bin

注意:

idmConfigToolを実行すると、idmDomainConfig.paramファイルが作成されるか、既存のこのファイルに情報が追加されます。このファイルは、idmConfigToolを実行したディレクトリに作成されます。このツールを実行するたびに同じファイルに情報が追加されるようにするには、必ず次のディレクトリでidmConfigToolを実行します。

IAM_ORACLE_HOME/idmtools/bin

Linuxの場合、このコマンドの構文は次のとおりです。

idmConfigTool.sh -prepareIDStore mode=MODE input_file=configfile

MODEに選択する値によって、作成するユーザーのタイプが決まります。指定可能なMODEの値は、OAM、OIM、WLSなどです。

トポロジにあるコンポーネントそれぞれに対してコマンドを1回実行します。

- すべてのトポロジにおいて、管理コンソールに対するシングル・サインオンを有効にする場合は、WebLogic管理コンソールとOracle Enterprise Manager Fusion Middleware Controlにログインする権限を持つユーザーがアイデンティティ・ストアに存在することを確認する必要があります。次のように入力します。

idmConfigTool.sh -prepareIDStore mode=WLS input_file=idstore.props

最初にこのコマンドを実行します。

- トポロジにAccess Managerが含まれている場合、Access Managerで必要なユーザーをアイデンティティ・ストアにシードしておく必要があります。次のように入力します。

idmConfigTool.sh -prepareIDStore mode=OAM input_file=idstore.props

- トポロジにOracle Identity Managerが含まれている場合、xelsysadmユーザーをアイデンティティ・ストアにシードし、Oracle Identity Manager管理グループにこのユーザーを割り当てる必要があります。また、リコンシリエーションを実行できるように、標準の場所cn=Users以外にもユーザーを作成します。このユーザーは、Oracle Virtual Directoryを使用してディレクトリに接続するときにバインドDNとして使用するユーザーにもなります。次のように入力します。

idmConfigTool.sh -prepareIDStore mode=OIM input_file=idstore.props

注意:

このコマンドでは、アイデンティティ・ストアに予約用のコンテナも作成します。

xelsysadmユーザーに割り当てるパスワードは、次のルールに準拠する必要があります。

- 6文字以上

- 1文字以上の数字

- 2文字以上の英字

- 先頭文字は英字

- 1文字以上の小文字

このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを入力するように要求されます。

3. 各コマンドを実行した後、ログ・ファイルでエラーまたは警告を確認し、修正します。このツールを実行したディレクトリにautomation.logというファイルが作成されます。

関連項目:

idmConfigToolコマンドの詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合概要』を参照してください。

9.4.5 不足しているOracle Internet Directoryオブジェクト・クラスの追加

不具合14341069は、Oracle Internet Directoryのオブジェクト・クラスが足りないことが原因です。この回避策は、このオブジェクト・クラスを手動で追加することです。

1. 次の内容でupdate_oid.ldifというファイルを作成します。

dn: cn=subschemasubentry
changetype: modify
delete: objectclasses
objectclasses: ( 2.16.840.1.113894.200.2.1 NAME 'orclIDXPerson' SUP inetorgperson AUXILIARY MAY ( middleName $ orclActiveStartDate $ orclActiveEndDate $ orclIsEnabled $ orclTimeZone $ c $ orclGenerationQualifier $ orclHireDate $ orclAccessibilityMode $ orclColorContrast $ orclFontSize $ orclnumberFormat $ orclcurrency $ orcldateFormat $ orcltimeFormat $ orclembeddedHelp $ orclFALanguage $ orclFATerritory $ orclDisplayNameLanguagePreference $ orclImpersonationGranter $ orclImpersonationGrantee $ orclMTTenantGUID $ orclMTTenantUName $ orclMTUid $ orclFAUserID $ orclFAPersonID $ orclFAPartyID ))

dn: cn=subschemasubentry
changetype: modify
add: attributetypes
attributetypes: ( 2.16.840.1.113894.200.1.7 NAME 'orclPwdExpirationDate' EQUALITY caseIgnoreMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE USAGE userApplications )

dn: cn=subschemasubentry
changetype: modify
add: objectclasses
objectclasses: ( 2.16.840.1.113894.200.2.1 NAME 'orclIDXPerson' SUP inetorgperson AUXILIARY MAY ( middleName $ orclActiveStartDate $ orclActiveEndDate $ orclIsEnabled $ orclTimeZone $ c $ orclGenerationQualifier $ orclHireDate $ orclAccessibilityMode $ orclColorContrast $ orclFontSize $ orclnumberFormat orclcurrency $ orcldateFormat $ orcltimeFormat $ orclembeddedHelp $ orclFALanguage $ orclFATerritory $ orclDisplayNameLanguagePreference $ orclImpersonationGranter $ orclImpersonationGrantee $ orclMTTenantGUID $ orclMTTenantUName $ orclMTUid $ orclFAUserID $ orclFAPersonID $ orclFAPartyID $ orclPwdExpirationDate ) )

2. 次のコマンドを使用してOracle Internet Directoryを更新します。

ldapmodify –D cn=orcladmin –h OIDHOST1.mycompany.com –p 3060 –f update_oid.ldif

9.4.6 不足しているOracle Unified Directoryの権限の追加

この項では、Oracle Unified Directoryの不足している権限の回避策を説明します。

次の内容でadd_aci.ldifというファイルを作成します。

dn: cn=Reserve,dc=mycompany,dc=com
changetype: modify
delete: aci
aci: (version 3.0; acl "oim reserve group container acl"; allow (read,add,delete) groupdn="ldap:///cn=OIMAdministrators,cn=Groups,dc=mycompany,dc=com"; deny (all) userdn="ldap:///anyone";)

dn: cn=Reserve,dc=mycompany,dc=com
changetype: modify
add: aci
aci: (target = "ldap:///cn=Reserve,dc=mycompany,dc=com")(targetattr = "*")(version 3.0; acl "Allow OIMAdministrators Group add, read and write access to all attributes"; allow (add, read, search, compare,write, delete, import,export) (groupdn = "ldap:///cn=OIMAdministrators,cn=Groups,dc=mycompany,dc=com");)

次のコマンドを使用してOracle Unified Directoryを更新します。

ldapmodify –D cn=oudadmin –h IDMHOST1.mycompany.com –p 1389 –f add_aci.ldif

9.4.7 Oracle Unified Directory変更ログのアクセス権の付与

Oracle Unified DirectoryおよびOracle Identity Managerを使用している場合、変更ログへのアクセス権を付与する必要があります。これを行うには、すべてのOUDホスト(つまりIDMHOST1とIDMHOST2)で次の手順を実行します。

1. OUDを実行しているホスト(たとえば、IDMHOST)で、OUDへの接続に使用するパスワードを含むmypasswordfileというファイルを作成します。

2. レプリケーションしたOUDホストのいずれかで次のコマンドを発行して、既存の変更ログの権限を削除します。

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--remove global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; deny (all) userdn=\"ldap:///anyone\";)" \
--hostname OUD_HOST \
--port OUD_ADMIN_PORT \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile passwordfile \
--no-prompt

例:

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--remove global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; deny (all) userdn=\"ldap:///anyone\";)" \
--hostname IDMHOST1.mycompany.com \
--port 4444 \
--trustAll  \
--bindDN cn=oudadmin \
--bindPasswordFile mypasswordfile \
--no-prompt

3. 次の新しいACIを追加します。

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--add global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; allow (read,search,compare,add,write,delete,export) groupdn=\"ldap:///cn=OIMAdministrators,cn=groups,dc=mycompany,dc=com\";)" \
--hostname OUD_HOST \
--port OUD_ADMIN_PORT \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile passwordfile \
--no-prompt

例:

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--add global-aci:"(target=\"ldap:///cn=changelog\")(targetattr=\"*\")(version 3.0; acl \"External changelog access\"; allow (read,search,compare,add,write,delete,export) groupdn=\"ldap:///cn=OIMAdministrators,cn=groups,dc=mycompany,dc=com\";)" \
--hostname IDMHOST1.mycompany.com \
--port 4444 \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile mypasswordfile \
--no-prompt

4. 次の新しいACIを追加します。

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--add global-aci:"(targetcontrol=\"1.3.6.1.4.1.26027.1.5.4\")(version 3.0; acl \"OIMAdministrators control access\"; allow(read)  groupdn=\"ldap:///cn=OIMAdministrators,cn=groups,dc=mycompany,dc=com\";)" \
--hostname OUD_HOST \
--port OUD_ADMIN_PORT \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile passwordfile \
--no-prompt

例:

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--add global-aci:"(targetcontrol=\"1.3.6.1.4.1.26027.1.5.4\")(version 3.0; acl \"OIMAdministrators control access\"; allow(read)  groupdn=\"ldap:///cn=OIMAdministrators,cn=groups,dc=mycompany,dc=com\";)" \
--hostname IDMHOST1.mycompany.com \
--port 4444 \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile mypasswordfile \
--no-prompt

5. 次のACIを追加します。

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--add global-aci:"(target=\"ldap:///\")(targetscope=\"base\")(targetattr=\"lastExternalChangelogCookie\")(version 3.0; acl \"User-Visible lastExternalChangelog\"; allow (read,search,compare) groupdn=\"ldap:///cn=OIMAdministrators,cn=groups,dc=mycompany,dc=com\";)" \
--hostname OUD_HOST \
--port OUD_ADMIN_PORT \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile passwordfile \
--no-prompt

例:

OUD_ORACLE_INSTANCE/bin/dsconfig set-access-control-handler-prop \
--add global-aci:"(target=\"ldap:///\")(targetscope=\"base\")(targetattr=\"lastExternalChangelogCookie\")(version 3.0; acl \"User-Visible lastExternalChangelog\"; allow (read,search,compare) groupdn=\"ldap:///cn=OIMAdministrators,cn=groups,dc=mycompany,dc=com\";)" \
--hostname IDMHOST1.mycompany.com \
--port 4444 \
--trustAll \
--bindDN cn=oudadmin \
--bindPasswordFile mypasswordfile \
--no-prompt

9.4.8 Oracle Unified Directoryの索引の作成

idmConfigToolを実行してOracle Unified Directoryアイデンティティ・ストアを準備すると、実行対象のインスタンスに関するデータの索引が作成されます。構成の残りのOracle Unified Directoryインスタンスそれぞれに関して索引を手動で作成する必要があります。

これを実行するには、IDMHOST2で次のコマンドを発行します。

OUD_ORACLE_INSTANCE/OUD/bin/ldapmodify -h IDMHOST2.mycompany.com -Z -X -p 4444 -a -D "cn=oudadmin" -j mypasswordfile -c  -f IAM_ORACLE_HOME/oam/server/oim-intg/ldif/ojd/schema/ojd_user_index_generic.ldif

OUD_ORACLE_INSTANCE/OUD/bin/ldapmodify -h IDMHOST2.mycompany.com -Z -X -p 4444 -a -D "cn=oudadmin" -j mypasswordfile -c  -f IAM_ORACLE_HOME/idmtools/templates/oud/oud_indexes_extn.ldif

各IDMHOSTに索引が作成されたら、次のように索引を再構築します。

1. 次のコマンドを発行してOracle Unified Directoryをシャットダウンします。

OUD_ORACLE_INSTANCE/OUD/bin/stop-ds

2. 次のコマンドを実行します。

OUD_ORACLE_INSTANCE/OUD/bin/rebuild-index --rebuildAll -b "dc=mycompany,dc=com"

3. 次のコマンドを発行してOracle Unified Directoryを再起動します。

OUD_ORACLE_INSTANCE/OUD/bin/start-ds

手順1-3を繰返し、各IDMHOST (idmConfigToolの実行対象だったホストを含む)に対する索引を再構築し、可用性を維持し、索引を再構築しているディレクトリのみを停止します。

9.4.9 Oracle Internet DirectoryおよびOracle Unified Directory以外のディレクトリへのアクセス制御リストの作成

前の項で、Oracleコンポーネントのユーザーおよびアーティファクトをアイデンティティ・ストアにシードしました。Microsoft Active DirectoryなどのOracle Internet DirectoryまたはOracle Unified Directory以外のディレクトリでアイデンティティ・ストアをホストしている場合、アクセス制御リスト(ACL)を設定して、作成したエンティティに適切な権限を指定する必要があります。この項では、作成されるアーティファクトおよびそのアーティファクトで必要な権限を示します。

- システムID: すべてのシステム識別子を格納するためのシステムIDコンテナが作成されます。ユーザーの作成場所であるコンテナが他に存在する場合は、それが管理の中で指定されます。

- Access Manager管理ユーザー。このユーザーは、OAM管理者グループに追加されます。このグループでは、Oracle Access Managementコンソールを管理する権限を提供します。このユーザーは単なるアプリケーション・ユーザーなので、LDAPスキーマ・レベルの権限は不要です。

- Access Managerソフトウェア・ユーザー。このユーザーは、コンテナに対する読取り権限を提供するグループに追加されます。このユーザーにはスキーマ管理権限も付与されます。

- システムIDコンテナに存在するOracle Identity ManagerユーザーoimLDAP: コンテナでは適宜パスワード・ポリシーが設定されます。システムIDコンテナのユーザーのパスワードは、期限切れにならないように設定する必要があります。

- Oracle Identity Manager管理グループ: Oracle Identity Managerのユーザーがこのメンバーとして追加されます。Oracle Identity Manager管理グループには、ディレクトリ内のすべてのユーザー・エンティティおよびグループ・エンティティに対する完全な読取り/書込み権限が付与されます。

- WebLogic管理者: Oracle Virtual DirectoryのIDMドメインの管理者です。

- WebLogic管理者グループ: WebLogic管理者がメンバーとして追加されます。Oracle Virtual DirectoryのIDMドメインの管理者グループです。

- 予約コンテナ: 読取り/書込み操作を実行するための権限がOracle Identity Manager管理グループに付与されます。

9.5 Oracle Virtual Directoryにおけるアダプタの作成

Oracle Virtual Directoryを使用してLDAPディレクトリにアクセスする場合、アダプタを作成してOracle Virtual DirectoryをバックエンドLDAPディレクトリにリンクする必要があります。この項では方法について説明します。

この手順は、接続先のディレクトリに応じて若干異なります。以降の項では、サポートされるディレクトリ用のアダプタを作成し、検証する方法を説明します。

- 第9.5.1項「変更ログ生成がOracle Internet Directoryで有効になっていることの確認」

- 第9.5.2項「Oracle Internet DirectoryおよびActive Directoryに対するOracle Virtual Directoryアダプタの作成」

- 第9.5.3項「Oracle Virtual Directoryアダプタの検証」

9.5.1 変更ログ生成がOracle Internet Directoryで有効になっていることの確認

Oracle Virtual Directoryで変更ログ・アダプタを作成する前に、バックエンドOracle Internet Directoryサーバーで変更ログ生成が有効になっていることを確認する必要があります。

ディレクトリ・サーバーで変更ログ生成が有効になっているかどうかをテストするには、次のように入力します。

ldapsearch -h directory_host -p ldap_port -D bind_dn -q -b '' -s base 'objectclass=*' lastchangenumber

例:

ldapsearch -h OIDHOST1 -p 3060 -D "cn=orcladmin" -q -b '' -s base 'objectclass=*' lastchangenumber

値を備えたlastchangenumberがコマンド出力に含まれている場合、変更ログ生成は有効になっています。変更ログ生成が有効でない場合は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のコマンドラインを使用した変更ログ生成の有効化および無効化に関する項の説明に従って、有効にしてください。

9.5.2 Oracle Internet DirectoryおよびActive Directoryに対するOracle Virtual Directoryアダプタの作成

idmConfgToolを使用すると、Oracle Internet DirectoryおよびActive Directory用のOracle Virtual Directoryユーザーおよび変更ログ・アダプタを作成できます。Oracle Identity Managerにはアダプタが必要です。Oracle Virtual Directoryを使用してOracle Internet Directoryに接続することを強くお薦めします。ただしこれは必須ではありません。

そのためには、IDMHOST1で次のタスクを実行します。

1. MW_HOMEをIAM_MW_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

JAVA_HOMEをJAVA_HOMEに設定します。

2. 構成しているアダプタのプロパティ・ファイルovd1.propsを作成します。このファイルの内容は、Oracle Internet Directoryアダプタを構成しているのか、Active Directoryアダプタを構成しているのかによって異なります。

- Oracle Internet Directoryアダプタ・プロパティ・ファイル:

ovd.host:OVDHOST1.mycompany.com
ovd.port:8899
ovd.binddn:cn=orcladmin
ovd.password:ovdpassword
ovd.oamenabled:true
ovd.ssl:true
ldap1.type:OID
ldap1.host:OIDIDSTORE.mycompany.com
ldap1.port:3060
ldap1.binddn:cn=oimLDAP,cn=systemids,dc=mycompany,dc=com
ldap1.password:oidpassword
ldap1.ssl:false
ldap1.base:dc=mycompany,dc=com
ldap1.ovd.base:dc=mycompany,dc=com
usecase.type: single

- Active Directoryアダプタ・プロパティ・ファイル:

ovd.host:OVDHOST1.mycompany.com
ovd.port:8899
ovd.binddn:cn=orcladmin
ovd.password:ovdpassword
ovd.oamenabled:true
ovd.ssl:true
ldap1.type:AD
ldap1.host:ADIDSTORE.mycompany.com
ldap1.port:636
ldap1.binddn:cn=adminuser
ldap1.password:adpassword
ldap1.ssl:true
ldap1.base:dc=mycompany,dc=com
ldap1.ovd.base:dc=mycompany,dc=com
usecase.type: single

次のリストで、プロパティ・ファイルで使用されるパラメータについて説明します。

- ovd.hostは、Oracle Virtual Directoryを実行しているサーバーのホスト名です。

- ovd.portは、Oracle Virtual Directoryへのアクセスに使用するHTTPSポートです。

- ovd.binddnは、Oracle Virtual Directoryへの接続に使用するユーザーDNです。

- ovd.passwordは、Oracle Virtual Directoryへの接続に使用するDNのパスワードです。

- ovd.oamenabledは、Fusion Applicationデプロイメントでは常にtrueです。

- ovd.sslは、HTTPSポートを使用している場合、trueに設定されます。

- ldap1.typeは、Oracle Internet Directoryバックエンド・ディレクトリの場合はOIDに、Active Directoryバックエンド・ディレクトリの場合はADに設定されます。

- ldap1.hostはバックエンド・ディレクトリが存在するホストです。ロード・バランサ名を使用します。

- ldap1.portは、バックエンド・ディレクトリとの通信に使用されるポートです。

- ldap1.binddnは、oimLDAPユーザーのバインドDNです。

- ldap1.passwordは、oimLDAPユーザーのパスワードです。

- ldap1.sslは、バックエンドのSSL接続を使用している場合、trueに設定され、使用していない場合、falseに設定されます。アダプタがAD用に作成されている場合、これは常にtrueに設定する必要があります。

- ldap1.baseは、ディレクトリ・ツリーのベースの場所です。

- ldap1.ovd.baseは、Oracle Virtual Directory内のマップされた場所です。

- usecase.typeは、単一ディレクトリ・タイプを使用している場合、Singleに設定されます。

3. 次の場所にあるidmConfigToolコマンドを使用してアダプタを構成します。
IAM_ORACLE_HOME/idmtools/bin

注意:

idmConfigToolを実行すると、idmDomainConfig.paramファイルが作成されるか、既存のこのファイルに情報が追加されます。このファイルは、idmConfigToolを実行したディレクトリに作成されます。このツールを実行するたびに同じファイルに情報が追加されるようにするには、必ず次のディレクトリでidmConfigToolを実行します。

IAM_ORACLE_HOME/idmtools/bin

Linuxの場合、このコマンドの構文は次のとおりです。

idmConfigTool.sh -configOVD input_file=configfile [log_file=logfile]

例:

idmConfigTool.sh -configOVD input_file=ovd1.props

このコマンドでは、入力は必要ありません。次のように出力されます。

The tool has completed its operation. Details have been logged to logfile

プロパティ・ファイルでovd.hostに適切な値を設定して、トポロジ内の各Oracle Virtual Directoryインスタンスに対してこのコマンドを実行します。

9.5.3 Oracle Virtual Directoryアダプタの検証

ODSMを使用して、次のタスクを実行します。

1. 次のURLでODSMにアクセスします。

http://HOSTNAME.mycompany.com:port/odsm

2. Oracle Virtual Directoryに接続します。

3. 「データ・ブラウザ」タブに移動します。

4. リストされたユーザー・アダプタ・ルートDNをそれぞれ確認できるように、「クライアント・ビュー」を展開します。

5. ユーザー・アダプタ・ルートDNを開きます。バックエンドLDAPサーバー内にすでにオブジェクトが存在する場合は、これらのオブジェクトがここに表示されます。

6. ODSMは変更ログ問合せをサポートしないので、cn=changelogサブツリーを開くことはできません。
コマンドラインを使用して、次のタスクを実行します。

- 次のように入力して、ユーザー・アダプタを検証します。

ldapsearch -h directory_host -p ldap_port -D "cn=orcladmin" -q  -b <user_search_base> -s sub "objectclass=inetorgperson" dn

例:

ldapsearch -h OVDHOST1.mycompany.com -p 6501 -D "cn=orcladmin" -q -b "cn=Users,dc=mycompany,dc=com" -s sub "objectclass=inetorgperson" dn

要求されたら、パスワードを入力します。

バックエンドLDAPサーバーにすでに存在するユーザー・エントリが表示されます。

- 次のように入力して、変更ログ・アダプタを検証します。

ldapsearch -h directory_host -p ldap_port -D "cn=orcladmin" -q  -b "cn=changelog" -s one "changenumber>=0"

例:

ldapsearch -h OVDHOST1 -p 6501 -D "cn=orcladmin" -q -b "cn=changelog" -s one "changenumber>=0"

コマンドは、データのログ(すべてのユーザーの作成など)を返します。変更ログ・アダプタが有効ならば、エラーを出さずに戻ります。

- 次のように入力して、最新変更番号問合せを検証します。

ldapsearch -h directory_host -p ldap_port -D "cn=orcladmin" -q -b "cn=changelog" -s base 'objectclass=*' lastchangenumber

例:

ldapsearch -h OVDHOST1 -p 6501 -D "cn=orcladmin" -q -b "cn=changelog" -s base 'objectclass=*' lastchangenumber

このコマンドは、バックエンドLDAPサーバーで生成された最新の変更番号を返します。

9.6 アイデンティティ・ストアのバックアップ

第17.6.3項「インストール時および構成時のバックアップの実行」の説明に従って、LDAPディレクトリのバックアップを作成します。

10 エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成

この章では、Oracle Identity Managementエンタープライズ・デプロイメント用のOracle Web層を構成する方法を説明します。

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

- 第10.1項「Web層のインストールおよび構成の概要」

- 第10.2項「Web層のインストールおよび構成」

- 第10.3項「構成後のタスク」

- 第10.4項「Oracle HTTP Serverの再起動」

- 第10.5項「管理コンソール用フロントエンドURLの設定」

- 第10.6項「構成の検証」

- 第10.7項「Web層のURLのまとめ」

- 第10.8項「Web層の構成のバックアップ」

10.1 Web層のインストールおよび構成の概要

この章では、Oracle HTTPサーバーをインストールし、Oracle Web層をWebLogic Serverドメインと関連付ける方法について説明します。Web層とWebLogic Serverを関連付けると、Oracle Fusion MiddlewareコンソールでWeb層を監視できるようになります。

その後、すべてのHTTPリクエストをWEBHOST1およびWEBHOST2にルーティングするようロード・バランサを構成します。

最後の項では、Oracle HTTP Serverディレクティブを定義して、第3章「エンタープライズ・デプロイメント用のネットワークの準備」で定義したロード・バランサ仮想ホストにリクエストをルーティングする方法について説明します。

10.2 Web層のインストールおよび構成

この項には次のトピックが含まれます:

- 第10.2.1項「前提条件」

- 第10.2.2項「JRockitのインストール」

- 第10.2.3項「Oracle HTTP Serverのインストール」

- 第10.2.4項「構成ウィザードによるHTTP Serverの構成」

10.2.1 前提条件

- Oracle Web層ソフトウェアを構成する前に、第10.2.3項「Oracle HTTP Serverのインストール」の説明に従ってこのソフトウェアをWEBHOST1とWEBHOST2にインストールする必要があります。構成ウィザードを実行して、インスタンス・ホーム、インスタンス名およびOracle HTTP Serverコンポーネント名を定義します。

- ポート7777 (OHS_PORT)が使用されていないことを確認します。Oracle HTTP Serverは、デフォルトではポート7777にインストールされるため、ノード上の他のサービスがポート7777を使用していないことを確認する必要があります。このポートが使用されているかどうかを確認するには、Oracle HTTP Serverをインストールする前に次のコマンドを実行します。このポートが使用されている場合は、解放する必要があります。

netstat -an | grep 7777

- Oracle HTTP Serverが使用するポートを含むファイルを作成します。インストール・メディアのDisk1で、ファイルstage/Response/staticports.iniを探します。これをohs_ports.iniというファイルにコピーします。ohs_ports.iniからOHS PORTとOPMN Local Portを除くすべてのエントリを削除します。これらのポートの値をそれぞれ7777と6700に変更します。

注意:

ファイルのポート名がOHS PORTおよびOPMN Local Portと若干異なる場合、ファイルでこれらの名前を使用します。

10.2.2 JRockitのインストール

第8.2.1.1項「JRockitのインストール」の説明に従って、JRockitをWEBHOST1およびWEBHOST2にインストールします。

10.2.3 Oracle HTTP Serverのインストール

この項では、Oracle HTTP ServerをWEBHOST1とWEBHOST2にインストールする方法を説明します。

この項には次のトピックが含まれます:

- 第10.2.3.1項「前提条件の検証」

- 第10.2.3.2項「インストーラの実行」

10.2.3.1 前提条件の検証

Oracle HTTP Serverをインストールする前に、ご使用のマシンが次の要件を満たしていることを確認します。

1. 『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』で指定されているように、システム、パッチ、カーネルの要件、およびその他の要件が満たされていることを確認します。

2. Linuxプラットフォームで、/etc/oraInst.locファイルが存在している場合には、その内容が次のようになっていることを確認します。

inventory_loc=/u02/private/oracle/oraInventory
inst_group=oinstall

インベントリ・ディレクトリが正しいことおよびそのディレクトリへの書込み権限があることを確認します。

/etc/oraInst.locファイルが存在しない場合、この手順をスキップできます。

10.2.3.2 インストーラの実行

第4.4項「各種ディレクトリの推奨場所について」で説明したとおり、ローカル・ディスクにOracle HTTP Serverをインストールします。共有記憶域にインストールすることもできますが、このようにする場合はWeb層DMZから共有ディスク・アレイへのアクセスを許可する必要があり、これは望ましくありません。共有ディスクにインストールする場合、構成情報の詳細は、リリース・ノートを参照してください。

インストールを開始する前に、Linuxプラットフォーム上で次の環境変数が設定されていないことを確認してください。

- LD_ASSUME_KERNEL

- ORACLE_INSTANCE

LinuxでOracle Universal Installerを起動するには、ディレクトリをインストール・メディアのディスク1に変更し、次のコマンドを発行します

./runInstaller

次のように実行します。

1. Oracleインベントリ・ディレクトリの指定画面で、HOME/oraInventoryと入力します。ここで、HOMEはインストールを実行するユーザーのホーム・ディレクトリです。ここで HOME はインストールを実行するユーザーのホーム・ディレクトリです (これは推奨場所です)。
インストールを実行しているユーザーのOSグループを入力します。

「次へ」をクリックします。

2. 「ようこそ」画面で、「次へ」をクリックします。

3. 「ソフトウェア更新のインストール」画面で、更新をスキップするかどうかの選択、更新情報を入手するためにOracleサポートをチェックまたは更新のローカルでの検索を行います。
「次へ」をクリックします。

4. 「インストール・タイプの選択」画面で、「ソフトウェアのインストール」→構成しないを選択します
「次へ」をクリックします。

5. 「前提条件のチェック」画面で、「次へ」をクリックします。

6. 「インストール場所の指定」画面で、次の値を指定します。

- Oracle Middlewareホームの場所(インストール場所): WEB_MW_HOME。例: /u02/private/oracle/products/web

- Oracleホーム・ディレクトリ: web

7. セキュリティ更新の指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。
「次へ」をクリックします。

8. 「インストール・サマリー」画面で、選択内容が正しいことを確認して(正しくない場合は「戻る」をクリックして前の画面に戻り、修正します)、「インストール」をクリックします。

10.2.4 構成ウィザードによるHTTP Serverの構成

Oracle Web層を構成するための手順は、WEBHOST1とWEBHOST2のどちらでも同じです。

次の手順を実行して、Oracle Web Tierを構成します。

1. Oracle Fusion Middleware構成ウィザードの場所にディレクトリを変更します。

cd WEB_ORACLE_HOME/bin

2. 構成ウィザードを起動します。

./config.sh

構成ウィザードに次の情報を入力します。

1. 「ようこそ」画面で、「次へ」をクリックします。

2. 「コンポーネントの構成」画面で「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」が選択されていることを確認します。

Oracle Web Cacheが選択されていないことを確認してください。

「次へ」をクリックします。

3. 「WebLogicドメインの指定」画面で、次を入力します。

- ドメイン・ホスト名: ADMINVHN.mycompany.com

- ドメインのポート番号: 7001。ここで7001は、 第B.3項のWLS_ADMIN_PORTです。

- ユーザー名: Weblogic管理ユーザー(たとえば、weblogic)

- パスワード: Weblogic管理ユーザー・アカウントのパスワード

「次へ」をクリックします。

4. 「コンポーネントの詳細の指定」画面で、次の値を指定します。
WEBHOSTnに次の値を入力します(nは1または2です)。

- インスタンス・ホームの場所: WEB_ORACLE_INSTANCE (/u02/private/oracle/config/instances/webn)

- インスタンス名: webn

- OHSコンポーネント名: ohsn

「次へ」をクリックします。

5. 「ポートの構成」画面で、第10.2.1項「前提条件」で作成したohs_ports.iniファイルを使用して、使用するポートを指定します。こうすることによって、自動ポート構成をバイパスできます。

1. 構成ファイルを使用してポートを指定を選択します。

2. 「ファイル名」フィールドでohs_ports.iniを指定します。

3. 「参照」をクリックしてから「次へ」をクリックします。

6. セキュリティ・アップデートの指定画面で、セキュリティ更新をOracleサポートから受信するかどうかを選択します。受信する場合は、電子メール・アドレスを入力します。

7. 「インストール・サマリー」画面で、選択内容が正しいことを確認します。そうでない場合は、「戻る」をクリックしてそれまでの画面に戻り、選択内容を変更します。
「構成」をクリックします。

「構成」画面で、複数のConfiguration Assistantが起動されます。このプロセスは、時間がかかることがあります。完了したら、「次へ」をクリックします。

「インストール完了」画面で「終了」をクリックして、終了を選択したことを確認します。

10.3 構成後のタスク

この項では、WebLogicドメインのOracle HTTP Serverの構成タスクと、構成の検証タスクについて説明します。Webホストごとに次の手順を実行します。

この項には次のトピックが含まれます:

- 第10.3.1項「ソフトウェア所有者として実行するためのOracle HTTP Serverの構成」

- 第10.3.2項「Oracle HTTP Serverのランタイム・パラメータの更新」

- 第10.3.3項「Identity Managementをサポートするための仮想ホストの作成」

10.3.1 ソフトウェア所有者として実行するためのOracle HTTP Serverの構成

デフォルトでは、Oracle HTTP Serverはユーザーnobodyとして実行されます。Identity Managementをインストールした環境では、ソフトウェア所有者およびグループとしてOracle HTTP Serverを実行する必要があります。

適切なユーザーおよびグループとしてこれを実行するには、次の場所にあるファイルhttpd.confを編集します。

WEB_ORACLE_INSTANCE/config/OHS/component_name

httpd.conf内で、Userが定義されているセクションを見つけます。

このセクションの内容を次のように変更します。

User User_who_installed_the_software
Group Group_under_which_the_HTTP_server_runs

Groupは、通常はデフォルト・ユーザー・グループです(例: oinstall)。

例:

<IfModule !mpm_winnt_module>
#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# . On SCO (ODT 3) use "User nouser" and "Group nogroup".
# . On HPUX you may not be able to use shared memory as nobody, and the
# suggested workaround is to create a user www and use that user.
# NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)
# when the value of (unsigned)Group is above 60000;
# don't use Group #-1 on these systems!
#
User oracle
Group oinstall
</IfModule>

10.3.2 Oracle HTTP Serverのランタイム・パラメータの更新

デフォルトでは、Oracle HTTP Serverには、ほとんどのアプリケーションに適したパラメータ値が含まれています。ただし、これらの値はIDMデプロイメントでは調整する必要があります。

次のように実行します。

次の場所にあるファイルhttpd.confを編集します。

WEB_ORACLE_INSTANCE/config/OHS/component_name/

次のようなエントリを探します。

<IfModule mpm_worker_module>

このセクションの値を次のように更新します。

<IfModule mpm_worker_module>
ServerLimit 20
StartServers 2
MaxClients 1000
MinSpareThreads 200
MaxSpareThreads 800
ThreadsPerChild 50
MaxRequestsPerChild 10000
AcceptMutex fcntl
LockFile "${ORACLE_INSTANCE}/diagnostics/logs/${COMPONENT_TYPE}/${COMPONENT_NAME}/http_lock"
</IfModule>

ファイルを保存します。

10.3.3 Identity Managementをサポートするための仮想ホストの作成

Oracle HTTPサーバーでOracle Identity Managementをサービスするために、複数のファイルを作成し、仮想ホストのサポートを追加する必要があります。次の各項のそれぞれのファイルは、仮想ホストの定義を作成し、内部からアクセスできる複数のURLを宣言します。仮想ホスト内部の場所ディレクティブを囲むことによって、これらの場所は、その仮想ホスト名を使用して呼び出された場合のみ使用可能になります。たとえば、URL http://ADMIN.mycompany.com/consoleを使用することによってWebLogicコンソールにアクセスできますが、URL: https://SSO.mycompany.com/consoleを使用してもアクセスできません

次の各項では、完全なIdentity Managementデプロイメントを実現するためのサンプルの構成ファイルを示します。部分的なデプロイメントのみを実行している場合、デプロイしているコンポーネントに該当するエントリのみを含めてください。後で追加のコンポーネントを使用してドメインを拡張する場合、使用しているコンポーネントをサポートするために必要なエントリで次のファイルを更新する必要があります。

10.3.3.1 仮想ホストのサポートの有効化

仮想ホストのディレクティブを作成する前に、Oracle HTTP Serverを有効化し、デフォルトのOHSリッスン・ポートで仮想ホストをリッスンする必要があります。

これを行うには、各Webホストで、ディレクトリWEB_ORACLE_INSTANCE/config/OHS/component_nameにあるファイルhttpd.confを編集します

次のような行を探します。

#NameVirtualHost *:80

7777であれ何であれ使用中のOHS_PORT値を使用し、次のエントリをファイルに追加してこのファイルを保存します。

NameVirtualHost *:7777

10.3.3.2 仮想ホストの定義の作成

ディレクトリWEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconfにある各Webホストに次のファイルを作成します。

10.3.3.2.1 ADMIN.mycompany.comの仮想ホストの作成

admin_vh.confというファイルを作成します。これには、ADMIN.mycompany.comを使用してドメインにアクセスしているクライアントがサポートしている場所のリストが含まれます。

<VirtualHost *:7777>

ServerName ADMIN.mycompany.com:80
RewriteEngine On
RewriteOptions inherit
ServerAdmin you@your.address

###################################
## General Domain Configuration
###################################

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN.mycompany.com
WebLogicPort 7001
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN.mycompany.com
WebLogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN.mycompany.com
WebLogicPort 7001
</Location>

###################################################
## Entries Required by Oracle Entitlements Server
###################################################

# APM
<Location /apm>
SetHandler weblogic-handler
WebLogicHost ADMINVHN.mycompany.com
WebLogicPort 7001
</Location>

##################################################
## Entries Required by Oracle Unified Directory
##################################################

# OUD ODSM
<Location /odsm>
SetHandler weblogic-handler
WebLogicHost ADMINVHN.mycompany.com
WebLogicPort 7001
</Location>

##############################################
## Entries Required by Oracle Access Manager
##############################################

# OAM Console
<Location /oamconsole>
SetHandler weblogic-handler
WebLogicHost ADMINVHN.mycompany.com
WebLogicPort 7001
</Location>

################################################
## Entries Required by Oracle Identity Manager
################################################

# OIM self and advanced admin webapp consoles(canonic webapp)
<Location /oim>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM, xlWebApp - Legacy 9.x webapp (struts based)
<Location /xlWebApp>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM self service console
<Location /identity>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM Nexaweb WebApp - used for workflow designer and DM
<Location /Nexaweb>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

<Location /sysadmin>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

</VirtualHost>

10.3.3.2.2 SSO.mycompany.comの仮想ホストの作成

sso_vh.confというファイルを作成します。これには、SSO.mycompany.comを使用してドメインにアクセスしているクライアントがサポートしている場所のリストが含まれます。これらは、外部ユーザーのメイン・エントリ・ポイントです。

<VirtualHost *:7777>
ServerName https://SSO.mycompany.com:443
RewriteEngine On
RewriteOptions inherit
ServerAdmin you@your.address

##############################################
## Entries Required by Oracle Access Manager
##############################################

# OAM Configuration
<Location /oam>
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
WLCookieName OAM_JSESSIONID
WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100
</Location>

# Required if using Oracle Identity Federation
<Location /oamfed>
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
WLCookieName OAM_JSESSIONID
WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100
</Location>
##################################################
## Entries Required by Oracle Identity Manager
##################################################

# OIM, xlWebApp - Legacy 9.x webapp (struts based)
<Location /xlWebApp>
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
WLCookieName    oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM self service console
<Location /identity>
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
WLCookieName oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

</VirtualHost>

10.3.3.2.3 IDMINTERNAL.mycompany.comの仮想ホストの作成

idminternal_vh.confというファイルを作成します。これには、IDMINTERNAL.mycompany.comを使用してドメインにアクセスしているクライアントがサポートしている場所のリストが含まれます。これらのエントリは内部コールバックによって使用されます。

<VirtualHost *:7777>
ServerName http://IDMINTERNAL.mycompany.com:80
RewriteEngine On
RewriteOptions inherit
ServerAdmin you@your.address

#################################################
## Entries Required by Oracle Identity Manager
#################################################

# Provide the OIM Managed Server Port
<Location /workflowservice>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM, SOA Infra
<Location /soa-infra>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster SOAHOST1VHN:8001,SOAHOST2VHN:8001
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM, Used for provisioning-callback.
<Location /provisioning-callback>
SetHandler weblogic-handler
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM, SOA Callback webservice for SOD - Provide the SOA Managed Server Ports
<Location /sodcheck>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster SOAHOST1VHN:8001,SOAHOST2VHN:8001
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM, SOA Callback
<Location /integration>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster SOAHOST1VHN:8001,SOAHOST2VHN:8001
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM, spml xsd profile
<Location /spml-xsd>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM, spml dsml profile
<Location /spmlws>
SetHandler weblogic-handler
PathTrim /weblogic
WLCookieName oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM, role-sod profile
<Location /role-sod>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM, used for Callback service.
<Location /callbackResponseService>
SetHandler weblogic-handler
WLCookieName    oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM, UMS Email Support
<Location /ucs>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster SOAHOST1VHN:8001,SOAHOST2VHN:8001
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

</VirtualHost>

10.4 Oracle HTTP Serverの再起動

OHSをWEBHOST1で次のように再起動します。

WEB_ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohs1

OHSをWEBHOST2で再起動します。

WEB_ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohs2

10.5 管理コンソール用フロントエンドURLの設定

Oracle WebLogic Server管理コンソールは、ポート、チャネルおよびセキュリティに対してコンソールを使用して行われる変更を追跡します。コンソールを使用して行われた変更をアクティブ化するとき、コンソールは現在のリスニング・アドレス、ポートおよびプロトコルを検証します。このリスニング・アドレス、ポートおよびプロトコルがまだ有効の場合、コンソールはHTTPリクエストをリダイレクトし、ホストとポートの情報を管理サーバーのリスニング・アドレスとポートに置き換えます。管理コンソールがロード・バランサを使用してアクセスされる場合、管理サーバーのフロントエンドURLを変更し、ユーザーのブラウザが適切なロード・バランサ・アドレスにリダイレクトされるようにする必要があります。

この項で説明したようにフロント・エンド・ホストおよびポートを設定すると、WebLogic管理サーバーにデプロイされたアプリケーションへのすべてのアクセスが強制的にOracle HTTPサーバーを介して行われるようになります。つまり、シングル・サイン・オンがドメインで有効になると、管理コンソール(Weblogicコンソール、OAM管理コンソールなど)へのアクセスがAccess Managerに制御されるようになります。

注意:

シングル・サインオンが有効になると、管理サーバーにデプロイされたアプリケーションへのアクセスは、Oracle HTTPサーバーを介してのみ実行できます。最低1台のAccess Manager管理対象サーバーが実行中である必要があります。

最低1台のAccess Manager管理対象サーバーを起動するまで、WebLogicコンソールを使用して管理対象サーバーを起動できません。コンソールを使用せずにAccess Manager管理対象サーバーを起動する手順については、第17.1.3.1項「Access Manager管理対象サーバーが1つも実行されていない場合の管理対象サーバーの起動」を参照してください。

管理サーバーにデプロイされたアプリケーションをOracleシングル・サインオンで保護しない場合、つまりこれらのアプリケーションへの直接アクセスを許可して企業セキュリティをバイパスするする場合、この項で説明したフロント・エンド・ホストおよびポートを設定しないことによってこれを実現できます。これはお薦めしません。

この変更を行うには、次の手順を実行します。

1. 次のURLを指定してOracle WebLogic Server管理コンソールにログインします。
http://ADMINVHN.mycompany.com:7001/consoleここで、7001はWLS_ADMIN_PORTです(第B.3項を参照)。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウの「環境」ノードを開きます。

4. 「サーバー」をクリックして、「サーバーの概要」ページを開きます。

5. 表の「名前」列で「AdminServer(admin)」を選択します。「AdminServer(admin)」の「設定」ページが表示されます。

6. 「プロトコル」タブをクリックします。

7. 「HTTP」タブをクリックします。

8. 「フロントエンド・ホスト」フィールドおよび「フロント・エンドHTTPポート」フィールドを次のように使用中のロード・バランサ・アドレスに設定します。

- フロントエンド・ホスト: ADMIN.mycompany.com

- フロント・エンドHTTPポート: 80 (HTTP_PORT)

9. 変更を保存およびアクティブ化します。

10. 管理サーバーを再起動します。

リダイレクトしないようにするには、管理コンソールの変更の追跡機能を無効にすることをお薦めします。これを実行するには、管理コンソールにログインし、「プリファレンス」→「共有プリファレンス」をクリックします。「構成変更の追跡」を選択解除し、「保存」をクリックします。

管理コンソールでサーバーの状態がRunningとして報告されていることを確認します。サーバーのステータスが「起動しています」または「再開中です」である場合は、「起動済み」になるまで待ちます。「管理」や「失敗」などの別のステータスが表示される場合は、サーバーの出力ログ・ファイルを調べ、エラーがないか確認します。可能性のある原因は、「Section 17.10, "Troubleshooting"」を参照してください。

注意:

ドメインおよびOracle HTTP Serverを再起動すると、そのOracle HTTP Serverは管理可能なターゲットとしてOracle Enterprise Manager Fusion Middleware Controlに表示されます。これを確認するには、Fusion Middleware Controlにログインします。ナビゲーション・ツリーのWeb層の項目にOracle HTTP Serverが登録されていることが示されます。

10.6 構成の検証

インストール完了後、次の検証を実行します。

- 次のURLを使用してOracle HTTP Serverにアクセスできることを確認します。
http://WEBHOST1.mycompany.com:7777/

(ここで、7777はOHS_PORTです(第B.3項を参照))

http://WEBHOST2.mycompany.com:7777/

https://SSO.mycompany.com/

http://IDMINTERNAL.mycompany.com

- 次のURLを使用して、Oracle Unified Directory用のOracle Directory Services Managerへのアクセスを検証します。
http://ADMIN.mycompany.com/odsm

ローカルOracle Unified Directoryサーバーの1つへの接続を作成します。

- 次のURLを使用して、Oracle Entitlements Server Policy Managerへのアクセスを検証します。
http://ADMIN.mycompany.com/apm

APMのWebLogic管理者アカウント(たとえば、weblogic)を使用して、ログインします

- 次のURLを使用して、WebLogicコンソールへのアクセスを検証します
http://ADMIN.mycompany.com/console

WebLogic管理者アカウント(たとえば、weblogic)を使用して、ログインします。

- 次のURLを使用して、Oracle Enterprise Manager Fusion Middleware Controlへのアクセスを検証します。
http://ADMIN.mycompany.com/em

WebLogic管理者アカウント(たとえば、weblogic)を使用して、ログインします。

10.7 Web層のURLのまとめ

表10-1 Web層のURL

サーバーまたはコンソール

URL

Oracle HTTP Server SSO

https://SSO.mycompany.com/

Oracle HTTP Server Internal

http://IDMINTERNAL.mycompany.com/

Oracle Unified Directory用のOracle Directory Services Manager

http://ADMIN.mycompany.com/odsm

Oracle Entitlements Serverポリシー・マネージャ

http://ADMIN.mycompany.com/apm

WebLogicコンソール

http://ADMIN.mycompany.com/console

Oracle Enterprise Manager Fusion Middleware Control

http://ADMIN.mycompany.com/em

10.8 Web層の構成のバックアップ

第17.6.3項「インストール時および構成時のバックアップの実行」の説明に従って、Web層のバイナリおよびドメイン・ホームのバックアップを作成します。

11 Oracle Access Managementを追加するためのドメインの拡張

この章では、Oracle Identity Managementエンタープライズ・デプロイメントにOracle Access Management Access Managerを追加するためにドメインを拡張する方法について説明します。

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

- 第11.1項「Oracle Access Management Access Managerを追加するためのドメインの拡張の概要」

- 第11.2項「ドメインのURLについて」

- 第11.3項「様々なディレクトリ構成の使用方法」

- 第11.4項「前提条件」

- 第11.5項「Access Managerでのドメインの拡張」

- 第11.6項「Access Managerの構成」

- 第11.7項「Web層からのアクセスの構成」

- 第11.8項「ローカル・ストレージへの管理対象サーバーの構成の展開」

- 第11.9項「管理対象サーバーWLS_OAM1およびWLS_OAM2の起動」

- 第11.10項「Access Managerの検証」

- 第11.11項「Access Managerと他のコンポーネントを統合するための単一のキーストアの作成」

- 第11.12項「Access Managerの構成のバックアップ」

11.1 Oracle Access Management Access Managerを追加するためのドメインの拡張の概要

Access Managerを使用すると、ユーザーは全社規模でWebアプリケーションおよびその他のITリソースにシームレスにアクセスできます。これによって、集中化および自動化したシングル・サインオン(SSO)ソリューションが実現し、拡張性のある認証手法とそれに関連するワークフローを定義する機能が得られます。また、これは、アクセスをリクエストするユーザーのプロパティとそのリクエストが発生した環境に基づいて、特定のリソースへのアクセス権を付与または拒否する認可エンジンも備えています。このコア機能は、包括的なポリシー管理、監査、ITインフラストラクチャの他のコンポーネントとの統合によって充実したものになります。

Access Managerは、OAMサーバー、Oracle Access Managementコンソール、Webゲートなどのいくつかのコンポーネントで構成されています。OAMサーバーには、エンタープライズ・リソースへのアクセスを制限するのに必要なすべてのコンポーネントが含まれています。Oracle Access ManagementコンソールはAccess Managerの管理コンソールです。Webゲートは、Access Managerの実際の強制ポイントとして機能するWebサーバー・エージェントです。エンタープライズ・デプロイメントに必要なAccess Managerコンポーネントをインストールして構成するには、この章の手順および第15章「エンタープライズ・デプロイメントにおける管理コンソールのシングル・サインオンの構成」の手順に従います。

11.2 ドメインのURLについて

この章を完了すると、次のURLが利用可能になります。

表11-1 Web層を構成した後のOAMのURL

コンポーネント

URL

ユーザー

SSOユーザー

OAMコンソール

http://ADMIN.mycompany.com/oamconsole

weblogic

oamadmin

Oracle Enterprise Manager Fusion Middleware Control

http://ADMIN.mycompany.com/em

weblogic

weblogic_idm

Oracle Directory Service Manager

http://ADMIN.mycompany.com/odsm

weblogic

weblogic_idm

Oracle Entitlements Serverポリシー・マネージャ

http://ADMIN.mycompany.com/apm

weblogic

oamadmin

11.3 様々なディレクトリ構成の使用方法

通常、Access Managerは単一のLDAPストアを使用してアイデンティティ情報を保持します。ただし、Oracle Access Management Access Managerを構成して、Oracle Virtual Directoryやサード・パーティのディレクトリなど、異なる種類の複数のディレクトリ・ストアを使用することもできます。

複数のディレクトリを使用する場合は、Oracle Virtual Directoryを使用して、それらのディレクトリを単一の統合されたディレクトリとしてAccess Managerに提示できます。または、それぞれのディレクトリに対して個別にアクセスするようにAccess Managerを構成することもできます。

詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』の次の章を参照してください。

- 「複数ディレクトリのアイデンティティ・ストアの構成」

- 「Oracle Internet DirectoryとOracle Access Managerとの統合」

Access Managerの各種ディレクトリ構成の詳細は、「はじめに」の「関連ドキュメント」に記載されているAccess Managerのドキュメントを参照してください。これらのバリエーションを検討するお客様は、バリエーションに応じてディレクトリとAccess Managerデプロイメントを調整する必要があります。

11.4 前提条件

Access Managerを構成する前に、次の作業がIDMHOST1とIDMHOST2で行われたことを確認してください。

1. 第9章「アイデンティティ・ストアの準備」の記述に従って、アイデンティティ・ストアを準備します。

2. 第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」の説明に従って、WEBHOST1とWEBHOST2でOracle Web Tierを構成します。

3. 第3.3項「トポロジで使用する仮想サーバー名について」の説明に従って、ロード・バランサを構成します。

11.5 Access Managerでのドメインの拡張

IDMHOST1で次のコマンドを実行して構成ウィザードを起動します。

IAM_MW_HOME/oracle_common/common/bin/config.sh

次のように実行します。

1. 「ようこそ」画面で「既存のWebLogicドメインの拡張」を選択します。「次へ」をクリックします。

2. WebLogicドメインの選択画面で、ナビゲータを使用してWebLogic管理サーバーのドメイン・ホームを選択します。例: ASERVER_HOME
「次へ」をクリックします。

3. 「拡張ソースの選択」画面で、Oracle Access Management [iam]を選択します。
「次へ」をクリックします。

4. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。
OAMインフラストラクチャを選択します。

「コンポーネント・スキーマのOracle RAC構成」については、「GridLinkへ変換」を選択します。

「次へ」をクリックします。

5. GridLink RACコンポーネント・スキーマ画面が表示されます。この画面で、次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

- 「FANの有効化」を選択します。

- 次のいずれかの操作を実行します。

- ONS通知を暗号化するためのSSLが構成されていない場合は、「SSL」の選択を解除します。

- SSLを選択し、適切なWalletおよびWalletのパスワードを指定します。

- サービス・リスナー: 使用するRACデータベースのためのSCANアドレスとポートを入力します。このアドレスは、データベース内のパラメータremote_listenerを問い合せれば識別できます。

SQL>show parameter remote_listener;
NAME            TYPE   VALUE
-------------------------------------------------------------
remote_listener string DB-SCAN.MYCOMPANY.COM:1521

注意:

- Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例: DBHOST1-VIP.mycompany.com (ポート1521)およびDBHOST2-VIP.mycompany.com (ポート1521)、ここでの1521はDB_LSNR_PORTです。

- Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- ONSホスト: Oracle RACデータベースのSCANアドレスおよびデータベースから報告されたONSリモート・ポートを入力します。

srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:

Oracle Database 11g リリース1 (11.1)では、次の例のように、各データベースのONSサービスのホスト名とポートを使用します。

DBHOST1.mycompany.com (port 6200)

および

DBHOST2.mycompany.com (port 6200)

次のRACコンポーネント・スキーマ情報を入力します。

スキーマの名前

サービス名

スキーマの所有者

パスワード

Access Management

OAMEDG.mycompany.com

EDG_OAM

password

6. 「JDBCデータ・ソースのテスト」画面で、すべての接続が正常であることを確認します。
接続のテストは自動的に行われます。「ステータス」列に結果が表示されます。正常でない接続がある場合は、「前へ」をクリックして前の画面に戻り、入力を訂正します。

すべての接続が正常になったら「次へ」をクリックします。

7. 「コンポーネント・スキーマのテスト」画面で、ウィザードによりデータ・ソースを検証します。データ・ソースの検証が成功した場合、「次へ」をクリックします。失敗した場合、「前へ」をクリックして問題に対処してから、再試行します。

8. 「オプションの構成を選択」画面で、「管理対象サーバー、クラスタ、およびマシン」を選択します。
「次へ」をクリックします。

9. 「管理対象サーバーの構成」画面を初めて表示するときは、oam_server1という名前の管理対象サーバーが自動的に作成されます。oam_server1の名前をWLS_OAM1に変更し、次の表に示すように属性を更新します。次に、WLS_OAM2という名前の新しい管理対象サーバーを追加し、次のように属性を設定します。

名前

Listen address

Listen port

ポート変数

SSLリスニング・ポート

SSL有効

WLS_OAM1

IDMHOST1.mycompany.com

14100

OAM_PORT

N/A

いいえ

WLS_OAM2

IDMHOST2.mycompany.com

14100

OAM_PORT

N/A

いいえ

注意:

- これまでのデプロイメントの過程で構成された管理対象サーバーの構成は変更しないでください。

- 作成したデフォルトの管理対象サーバーを削除しないでください。説明に従って名前を変更してください。

「次へ」をクリックします。

10. 「クラスタの構成」画面で、「追加」をクリックしてクラスタを作成します。次の情報を指定します。

名前

クラスタ・メッセージング・モード

oam_cluster

Unicast

他のフィールドはすべてデフォルト設定のままにして、「次へ」をクリックします。

11. 「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタに関連付けます。クラスタ名を右側のペインでクリックします。「サーバー」で管理対象サーバーをクリックしてから矢印をクリックして、これをクラスタに割り当てます。
次のように、サーバーをクラスタに割り当てます。

クラスタ

サーバー

oam_cluster

WLS_OAM1

WLS_OAM2

注意:

以前のアプリケーション・デプロイメントの一部として構成されているクラスタの構成は変更しないでください。

「次へ」をクリックします。

12. 「マシンの構成」画面で、トポロジにある各ホストに対してマシンを作成します。「UNIXマシン」タブをクリックし、「追加」をクリックして次のマシンを追加します。

注意:

「名前」には任意の一意な文字列を指定できます。「ノード・マネージャ・リスニング・アドレス」には解決可能なホスト名を指定する必要があります。

名前

ノード・マネージャのリスニング・アドレス

ノード・マネージャ・リスニング・ポート

ポート変数

IDMHOST1.mycompany.com

IDMHOST1.mycompany.com

5556

NMGR_PORT

IDMHOST2.mycompany.com

IDMHOST2.mycompany.com

5556

NMGR_PORT

その他すべてのフィールドはデフォルト値のままにします。

注意:

マシン名は有効なホスト名またはリスニング・アドレスである必要はありません。これはノード・マネージャの場所を示す一意の識別子です。

「次へ」をクリックします。

13. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。
IDMHOST1: WLS_OAM1

IDMHOST2: WLS_OAM2

「次へ」をクリックして、続行します。

14. 「構成のサマリー」画面で「拡張」をクリックして、ドメインを拡張します。

注意:

次に示す警告が出力された場合:

CFGFWK: Server listen ports in your domain configuration conflict with ports in use by active processes on this host

「OK」をクリックします。

管理対象サーバーが以前のインストールの一部として定義されている場合、この警告が表示されますが、無視してかまいません。

15. 「インストール 完了」画面で「完了」をクリックします。

16. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってWebLogic管理サーバーを再起動します。

11.6 Access Managerの構成

この項には次のトピックが含まれます:

- 第11.6.1項「IDMドメイン・エージェントの削除」

- 第11.6.2項「グローバル・パスフレーズの設定」

- 第11.6.3項「IDM構成ツールを使用したAccess Managerの構成」

- 第11.6.4項「構成の検証」

- 第11.6.5項「新規作成エージェントの更新」

- 第11.6.6項「既存のWebゲート・エージェントの更新」

- 第11.6.7項「バグ13824816の回避策の実行」

11.6.1 IDMドメイン・エージェントの削除

デフォルトでは、管理コンソールのシングル・サインオン機能はIDMDomainAgentが提供しています。エンタープライズ・デプロイメントではWebゲートでシングル・サインオンを扱うので、IDMDomainAgentを削除する必要があります。次の手順に従ってIDMDomainAgentを削除します。

第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、WebLogicコンソールにログインします。

次を実行します。

1. 「セキュリティ・レルム」を「ドメイン構造」メニューで選択します。

2. myrealmをクリックします。

3. 「プロバイダ」タブをクリックします。

4. 「チェンジ・センター」で「ロックして編集」をクリックします。

5. 認証プロバイダのリストで「IAMSuiteAgent」を選択します。

6. 「削除」をクリックします。

7. 「はい」をクリックして、削除を確認します。

8. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

9. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーと実行されているすべての管理対象サーバーを再起動します。

11.6.2 グローバル・パスフレーズの設定

Access Managerは、デフォルトでオープン・セキュリティ・モデルを使用するように構成されています。idmConfigToolを使用してこのモードを変更することを計画している場合は、グローバル・パスフレーズを設定する必要があります。グローバル・パスフレーズとWebゲートのアクセス・パスワードは同じにする必要はありませんが、同じにすることをお薦めします。これを行うには、次の手順を実行します。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、OAMコンソールにログインします。
ここではWebLogic管理ユーザーとしてログインします。

2. 「システム構成」タブをクリックします。

3. 「Access Manager」セクションの「Access Managerの設定」をクリックします。

4. 「オープン」を「アクション」メニューで選択します。Access Managerの設定が表示されます。

5. OAMサーバーで簡易セキュリティ・モードを使用することを計画している場合は、グローバル・パスフレーズを指定します。

6. 「適用」をクリックします。

11.6.3 IDM構成ツールを使用したAccess Managerの構成

初期インストールが完了したら、次のタスクを実行する必要があります。

- 外部のLDAPディレクトリ(IDSTORE.mycompany.com)を使用するようにAccess Managerを構成します。

- Access Manager Webゲート・エージェントを作成します。

idmConfigToolを使用して、次のタスクを実行します。

注意:

Access ManagerとOracle Identity Managerの統合の構成、またはAccess Managerの単独構成のいずれを行うかについては、2つのパラメータ設定によって決定します。

- Access ManagerとOracle Identity Managerの統合を構成するには、OAM11G_OIM_INTEGRATION_REQをtrueに設定し、OAM11G_OIM_OHS_URLの値を指定します。

- Oracle Identity Managerを使用せずにAccess Managerを構成するには、OAM11G_OIM_INTEGRATION_REQをfalseに設定します。

これらのパラメータを使用することによって、Access Managerの資格証明コレクション・ページにパスワードを忘れた場合などのリンクが追加されます。

Oracle Identity Managerを使用せずにAccess Managerを構成し、後になってOracle Identity Managerを追加することを決定した場合は、このコマンドを再度実行してAccess ManagerとOracle Identity Managerの統合を構成する必要があります。

IDMHOST1で次のタスクを実行します。

1. MW_HOMEをIAM_MW_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

JAVA_HOMEをJAVA_HOMEに設定します。

2. 次の内容でプロパティ・ファイルconfig_oam1.propsを作成します。

WLSHOST: ADMINVHN.mycompany.com
WLSPORT: 7001
WLSADMIN: weblogic
WLSPASSWD: Admin Password
IDSTORE_DIRECTORYTYPE: OUD
IDSTORE_HOST: IDSTORE.mycompany.com
IDSTORE_PORT: 389
IDSTORE_BINDDN: cn=oudadmin
IDSTORE_USERNAMEATTRIBUTE: cn
IDSTORE_LOGINATTRIBUTE: uid
OAM11G_SERVER_LOGIN_ATTRIBUTE: uid
IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com
IDSTORE_SEARCHBASE: dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=mycompany,dc=com
IDSTORE_OAMSOFTWAREUSER: oamLDAP
IDSTORE_OAMADMINUSER: oamadmin
PRIMARY_OAM_SERVERS: IDMHOST1.mycompany.com:5575,IDMHOST2.mycompany.com:5575
WEBGATE_TYPE: ohsWebgate11g
ACCESS_GATE_ID: Webgate_IDM
OAM11G_OIM_WEBGATE_PASSWD: password to be assigned to WebGate
COOKIE_DOMAIN: .mycompany.com
OAM11G_WG_DENY_ON_NOT_PROTECTED: true
OAM11G_IDM_DOMAIN_OHS_HOST: SSO.mycompany.com
OAM11G_IDM_DOMAIN_OHS_PORT: 443
OAM11G_IDM_DOMAIN_OHS_PROTOCOL: https
OAM11G_SERVER_LBR_HOST: SSO.mycompany.com
OAM11G_SERVER_LBR_PORT: 443
OAM11G_SERVER_LBR_PROTOCOL: https
OAM11G_OAM_SERVER_TRANSFER_MODE: simple
OAM_TRANSFER_MODE: simple
OAM11G_IDM_DOMAIN_LOGOUT_URLS: /console/jsp/common/logout.jsp,/em/targetauth/emaslogout.jsp
OAM11G_IDSTORE_ROLE_SECURITY_ADMIN: OAMAdministrators
OAM11G_SSO_ONLY_FLAG: false
COOKIE_EXPIRY_INTERVAL: 120
OAM11G_IMPERSONATION_FLAG: false
OAM11G_OIM_INTEGRATION_REQ: false
OAM11G_OIM_OHS_URL:https://SSO.mycompany.com:443
SPLIT_DOMAIN:true

ここで:

- WLSHOST (ADMINVHN)は管理サーバーのホストです。これは仮想名です。

- WLSPORTは管理サーバーのポートであり、第B.3項のWLS_ADMIN_PORTに相当します。

- WLSADMINは、WebLogicコンソールへのログインで使用するWebLogic管理ユーザーです。

- WLSPASSWDはWebLogic管理者のパスワードです。

- IDSTORE_DIRECTORYTYPEはOUD、OIDまたはOVDです。

- IDSTORE_HOSTおよびIDSTORE_PORTは、アイデンティティ・ストアのディレクトリにロード・バランサを通じてアクセスする際のホストおよびポートです。これらは、第B.3項のワークシートのLDAP_LBR_HOSTおよびLDAP_LBR_PORTに相当します。

- IDSTORE_BINDDNは、アイデンティティ・ストア・ディレクトリの管理ユーザーです。

- IDSTORE_USERSEARCHBASEは、ユーザーが格納されるディレクトリの場所です。

- IDSTORE_GROUPSEARCHBASEは、グループが格納されるディレクトリの場所です。

- IDSTORE_SEARCHBASEは、ユーザーおよびグループを格納するディレクトリの場所です。

- IDSTORE_SYSTEMIDBASEは、ディレクトリ内でユーザーのoamLDAPが格納されるコンテナの場所です。

- IDSTORE_OAMSOFTWAREUSERは、第9.4項「アイデンティティ・ストアの準備」で作成され、LDAPとの通信で使用されるユーザーの名前です。

- IDSTORE_OAMADMINUSERは、第9.4項「アイデンティティ・ストアの準備」で作成され、OAMコンソールへのアクセスで使用されるユーザーの名前です。

- PRIMARY_OAM_SERVERSは、OAMサーバーとそれらのサーバーが使用するプロキシ・ポートのカンマ区切りリストです。例: IDMHOST1:OAM_PROXY_PORT

注意:

OAMサーバーが使用しているプロキシ・ポートを確認する手順は次のとおりです。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、OAMコンソールにログインします。

2. 「システム構成」タブをクリックします。

3. 「共通構成」セクションで、「サーバー・インスタンス」を開きます。

4. OAMサーバー(WLS_OAM1など)をクリックして、「アクション」メニューで「開く」を選択します。

5. 「ポート」にプロキシ・ポートが表示されます。

- ACCESS_GATE_IDは、Webゲートに割り当てる名前です。

- OAM11G_OIM_WEBGATE_PASSWDは、Webゲートに割り当てるパスワードです。

- OAM11G_IDM_DOMAIN_OHS_HOSTは、OHSの前に配置したロード・バランサの名前です。

- OAM11G_IDM_DOMAIN_OHS_PORTは、ロード・バランサでリスニングするポートです(HTTP_SSL_PORT)。

- OAM11G_IDM_DOMAIN_OHS_PROTOCOLは、ロード・バランサでリクエストを送るときに使用するプロトコルです。

- OAM11G_WG_DENY_ON_NOT_PROTECTEDは、falseに設定すると、ログイン・ページを表示できます。webgate11gを使用する場合は、trueに設定する必要があります。

- OAM_TRANSFER_MODEは、Oracle Access Managerサーバーが機能するセキュリティ・モデルです。有効な値はsimpleおよびopenです。simpleモードを使用する場合は、第11.6.2項「グローバル・パスフレーズの設定」に従ってグローバル・パスフレーズを定義する必要があります。

- OAM11G_OAM_SERVER_TRANSFER_MODEは、OAMサーバーが機能するセキュリティ・モデルです(第11.6.2項「グローバル・パスフレーズの設定」を参照)。

- OAM11G_IDM_DOMAIN_LOGOUT_URLSは、様々なログアウトURLに設定されます。

- OAM11G_SSO_ONLY_FLAGは、認証専用モードまたは標準モード(認証と認可をサポート)としてAccess Managerを構成します。
OAM11G_SSO_ONLY_FLAGをtrueに設定すると、OAMサーバーは認証専用モードで動作します。この場合、デフォルトではすべての認可でポリシー検証が実行されずにtrueが戻されます。このモードでは、認可の処理に伴うオーバーヘッドがサーバーに発生しません。認可ポリシーに依存せず、OAMサーバーの認証機能のみを必要とするアプリケーションでは、このモードをお薦めします。

この値をfalseに設定すると、サーバーはデフォルトのモードで実行されます。このモードでは、それぞれの認証の後でOAMサーバーに対する認可リクエストが1つ以上発生します。WebゲートはOAMサーバーからの応答に基づいて、リクエストされたリソースへのアクセスを許可または拒否します。

- OAMの偽装を構成する場合は、OAM11G_IMPERSONATION_FLAGをtrueに設定します。

- OAM11G_SERVER_LBR_HOSTは、サイトの前面に配置するロード・バランサの名前です。この値と次の2つのパラメータを使用してログインURLを構成します。

- OAM11G_SERVER_LBR_PORTは、ロード・バランサでリスニングするポートです(HTTP_SSL_PORT)。

- OAM11G_SERVER_LBR_PROTOCOLは、使用するURL接頭辞です。

- OAMとOIMの両方が含まれるトポロジを構築する場合は、OAM11G_OIM_INTEGRATION_REQをtrueに設定する必要があります。それ以外の場合は、この時点ではfalseに設定します。この値はAccess ManagerとOracle Identity Managerとの統合を実行するときにのみtrueに設定され、その統合段階の間値が維持されます。

- OAM11G_OIM_OHS_URLはロード・バランサのURLに設定する必要があります。このパラメータは、トポロジにOAMとOIMの両方が含まれる場合のみ必要です。

- COOKIE_DOMAINは、Webゲートが機能するドメインです。

- WEBGATE_TYPEは、作成するWebゲート・エージェントのタイプです。

- OAM11G_IDSTORE_NAMEは、アイデンティティ・ストアの名前です。このツールでアイデンティティ・ストアを新規に作成せず、すでに運用中のアイデンティティ・ストアを再利用する場合は、このパラメータの値をその再利用するアイデンティティ・ストアの名前に設定します。

- OAM11G_SERVER_LOGIN_ATTRIBUTEをuidに設定することで、ユーザーのログイン時にそのユーザー名がLDAPのuid属性に対して検証されます。

- OAMのみのドメインを作成する場合、またはOIMとは別のドメインにOAMを置く場合(分割ドメイン)、SPLIT_DOMAINをtrueに設定する必要があります。それ以外の場合はこのパラメータを指定する必要はありません。

3. 次の場所のidmConfigToolコマンドを使用してAccess Managerを構成します。
IAM_ORACLE_HOME/idmtools/bin

注意:

idmConfigToolを実行すると、idmDomainConfig.paramファイルが作成されるか、既存のこのファイルに情報が追加されます。このファイルは、idmConfigToolを実行したディレクトリに作成されます。このツールを実行するたびに同じファイルに情報が追加されるようにするには、必ず次のディレクトリでidmConfigToolを実行します。

IAM_ORACLE_HOME/idmtools/bin

Linuxの場合、このコマンドの構文は次のとおりです。

idmConfigTool.sh -configOAM input_file=configfile

例:

idmConfigTool.sh -configOAM input_file=config_oam1.props

このコマンドを実行すると、アイデンティティ・ストアへの接続に使用しているアカウントのパスワードを入力するように要求されます。また、次のアカウントに割り当てるパスワードも指定するよう求められます。

- IDSTORE_PWD_OAMSOFTWAREUSER

- IDSTORE_PWD_OAMADMINUSER

4. ログ・ファイルを確認して、エラーや警告を修正します。このツールを実行したディレクトリにautomation.logというファイルが作成されます。

5. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってWebLogic管理サーバーを再起動します。

注意:

idmConfigToolを実行した後は、後続のタスクで必要になるファイルがいくつか作成されます。これらのファイルは安全な場所に格納してください。

2つの11g Webゲート・プロファイルが作成されます。コンポーネント間の通信に使用されるWebgate_IDM、および11g Webゲートで使用されるWebgate_IDM_11gです。

ASERVER_HOME/output/Webgate_IDM_11gディレクトリには次のファイルが存在します。これらは、Webゲート・ソフトウェアをインストールする際に必要になります。

- cwallet.sso

- ObAccessClient.xml

- password.xml

加えて、ファイルaaa_cert.pemおよびaaa_key.pemが必要になります。これらのファイルはディレクトリASERVER_HOME/output/Webgate_IDMにあります。

11.6.4 構成の検証

ここまでの操作が正しいことを確認する手順は次のとおりです。

1. OAMコンソール(http://ADMIN.mycompany.com/oamconsole)にアクセスします。

2. 第9.4項「アイデンティティ・ストアの準備」で作成したAccess Manager管理ユーザー(例: oamadmin)としてログインします。

3. 「システム構成」タブをクリックします。

4. 「Access Manager」→「SSOエージェント」→「OAMエージェント」を開きます。

5. フォルダを開くアイコンをクリックして「検索」をクリックします。

6. 第11.6.3項「IDM構成ツールを使用したAccess Managerの構成」で作成したWebゲート・エージェントWebgate_IDMおよびWebgate_IDM_11gが表示されます。

11.6.5 新規作成エージェントの更新

最初の構成を作成した後に、その構成を編集して、高度な構成エントリを追加します。

1. 「システム構成」タブを選択します。

2. ディレクトリ・ツリーで「Access Manager」→「SSOエージェント」→「OAMエージェント」を選択します。フォルダを開くアイコンをダブルクリックするか選択します。

3. 表示された検索ページで、「検索」をクリックして空の検索を実行します。

4. エージェントWebgate_IDMをクリックします。

5. 「アクション」メニューで「開く」を選択します。

6. プライマリ・サーバーのリストに表示されているすべてのOAMサーバーについて、「接続の最大数」を10に設定します。

7. 次のログアウトURLがリストにない場合は、追加します。

- /oamsso/logout.html

- /console/jsp/common/logout.jsp

- /em/targetauth/emaslogout.jsp

8. 「適用」をクリックします。

9. Webゲート・エージェントWebgate_IDM_11gに対しても手順4から手順7までを繰り返します。

10. 「ポリシー構成」タブをクリックします。

11. 「ホスト識別子」をクリックします。

12. 「開く」をクリックします。

13. 「検索」をクリックします。

14. 「IAMSuiteAgent」をクリックします。

15. 「ホスト名組合せ」ボックスの+記号をクリックします。

16. 次の情報を入力します。

- ホスト名: ADMIN.mycompany.com

- ポート: 80 (HTTP_PORT)

17. 「適用」をクリックします。

11.6.6 既存のWebゲート・エージェントの更新

idmConfigToolを使用してOAMセキュリティ・モデルを変更した場合、この変更を反映するためにすべての既存のWebゲートで使用されるセキュリティ・モデルを変更する必要があります。

このためには、次の手順を実行します。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用し、第9.4項「アイデンティティ・ストアの準備」で作成したAccess Manager管理ユーザーとしてOracle Access Managementコンソールにログインします。

2. 「システム構成」タブをクリックします。

3. 「Access Manager」→「SSOエージェント」を開きます。

4. 「OAMエージェント」をクリックし、「アクション」メニューで「開く」を選択します。

5. 「検索」ウィンドウで「検索」をクリックします。

6. 第11.6.3項「IDM構成ツールを使用したAccess Managerの構成」でidmconfigToolによって作成されたエージェント以外の各エージェントをクリックします(例: IAMSuiteAgent)。

7. 「セキュリティ」の値を新しいセキュリティ・モデルに設定します。表示されているリストに、必要なAccess Managerサーバーを追加します。
「適用」をクリックします。

11.6.7 バグ13824816の回避策の実行

バグ13824816に対する次の回避策を実行します。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、WebLogic管理サーバー・コンソールにログインします。

2. コンソールの左ペインで「セキュリティ・レルム」をクリックします。

3. 「セキュリティ・レルムのサマリー」ページで、「レルム」表の下の「myrealm」をクリックします。

4. 「myrealm」の「設定」ページで、「ロールとポリシー」タブをクリックします。

5. 「レルム・ロール」ページの表「ロール」の「グローバル・ロール」エントリを開きます。これにより、ロールのエントリが表示されます。

6. 「ロール」リンクをクリックして、「グローバル・ロール」ページに移動します。

7. 「グローバル・ロール」ページで、「管理」ロールをクリックして「グローバル・ロールの編集」ページに移動します。

8. 「グローバル・ロールの編集」ページで、「ロール条件」の下の「条件の追加」をクリックします。

9. 「述部の選択」ページで、述部のリストから「グループ」を選択し、「次へ」をクリックします。

10. 「引数の編集」ページのグループ引数フィールドにOAMAdministratorsを指定し、「追加」をクリックします。

11. 「終了」をクリックして、「グローバル・ロールの編集」ページに戻ります。
「ロール条件」に、OAMAdministratorsグループというエントリが表示されます。

12. 「保存」をクリックして、OAMAdministratorsグループへの管理ロールの追加を終了します。

11.7 Web層からのアクセスの構成

既存のドメインにAccess Managerを追加する場合、第10.3.3項「Identity Managementをサポートするための仮想ホストの作成」で説明されているように、Web層の構成にOAMを忘れずに含める必要があります。

11.8 ローカル・ストレージへの管理対象サーバーの構成の展開

構成が完了したら、IDMHOST1およびIDMHOST2の管理対象サーバーのディレクトリにOracle Identity Managerの構成を伝播する必要があります。

これを行うには、ドメインのパックと解凍を実行します。最初にIDMHOST1のIDMDomainでドメインのパックを実行し、次にIDMHOST1およびIDMHOST2でそれを解凍します。

次の手順を実行して、管理対象サーバーのドメイン・ディレクトリにドメインを伝播します。

1. IDMHOST1上で、ORACLE_COMMON_HOME/common/bin/からpackユーティリティを起動します。

./pack.sh -domain=ASERVER_HOME -template=iam_domain.jar  -template_name="IAM Domain" -managed=true

これによってiam_domain.jarというファイルが作成されます。このファイルをIDMHOST2にコピーします。

2. IDMHOST1とIDMHOST2でunpackユーティリティを起動します。このユーティリティもORACLE_COMMON_HOME/common/bin/ディレクトリにあります。

./unpack.sh -domain=MSERVER_HOME -template=iam_domain.jar -overwrite_domain=true -app_dir=MSERVER_HOME/applications

11.9 管理対象サーバーWLS_OAM1およびWLS_OAM2の起動

第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の手順に従い、管理対象サーバーWLS_OAM1およびWLS_OAM2を起動します。

11.10 Access Managerの検証

oamtestツールを使用してAccess Managerを検証できます。このためには、次の手順を実行します。

1. 環境にJAVA_HOMEが設定されていることを確認します。

2. PATHにJAVA_HOME/binを追加します。たとえば、次のように指定します。

export PATH=$JAVA_HOME/bin:$PATH

3. 次のディレクトリに移動します。
IAM_ORACLE_HOME/oam/server/tester

4. 次のコマンドを使用して、ターミナル・ウィンドウでこのテスト・ツールを起動します。

java -jar oamtest.jar

5. OAMテスト・ツールが起動したら、ページの「サーバー接続」セクションで次の情報を入力します。

- プライマリIPアドレス: IDMHOST1.mycompany.com

- ポート: 5575 (OAM_PROXY_PORT)

- エージェントID: Webgate_IDM_11g

- エージェント・パスワード: webgate password

注意:

簡易モードを構成している場合は、「簡易」を選択してグローバル・パスフレーズを指定する必要があります。

「接続」をクリックします。

ステータスのウィンドウには次のように表示されます。

[reponse] Connected to primary access server

6. 保護されているリソースのURIセクションで次の情報を入力します。

- スキーム: http

- ホスト: ADMIN.mycompany.com

- ポート: 80 (HTTP_PORT)

- リソース: /oamconsole

「検証」をクリックします。

ステータスのウィンドウには次のように表示されます。

[request][validate] yes

7. 「ユーザー・アイデンティティ」ウィンドウで次の情報を入力します。

- ユーザー名: oamadmin

- パスワード: oamadmin password

認証をクリックします。

ステータスのウィンドウには次のように表示されます。

[request] [authenticate] yes

「認可」をクリックします。

ステータスのウィンドウには次のように表示されます。

[request] [authorize] yes

テストの実行例を次に示します。

トポロジにあるすべてのアクセス・サーバーで、サーバーごとに接続の詳細を変更して、このテストを繰り返します。

11.11 Access Managerと他のコンポーネントを統合するための単一のキーストアの作成

シンプル・トランスポート・プロトコルを使用して動作するようにAccess Managerを構成すると、Access Managerへのすべてのトラフィックが暗号化されます。Access Managerと他のコンポーネント(Oracle Identity Managerなど)を統合する場合は、統合される製品がこの暗号化を理解できるようにする必要があります。(トランスポート・モデルがオープンの場合、これは必要ありません。)このためには、キーストアを使用します。

シンプル・プロトコルを使用するようにAccess Managerを変更すると、ディレクトリASERVER_HOME/output/webgate-ssl内にキーストアが自動的に作成されます。このディレクトリには次のファイルが含まれます。

- oamclient-keystore.jks: 秘密鍵が格納されます。

- oamclient-truststore.jks: Access Managerの簡易モードのCA証明書が格納されます。

これらのファイルには、簡易モードのAccess Managerを有効にしたときに定義されるグローバル・パスフレーズを使用してアクセスします。

一部の製品では、前述の両方のファイルの構成が必要になります。また、一部の製品(Oracle Identity Managerなど)では、統合された単一のキーストアが必要になります。

Oracle Identity Managerでの使用に適したキーストアを作成するには、次の手順を実行します。

1. 次の例に示すように、ディレクトリをASERVER_HOME/output/webgate-sslに変更します。

cd ASERVER_HOME/output/webgate-ssl

2. 次の例に示すように、ファイルoamclient-keystore.jksをssoKeystore.jksとしてコピーします。

cp oamclient-keystore.jks ssoKeystore.jks

3. 次のコマンドを使用して、新しいキーストアssoKeystore.jksにトラスト・ストアをインポートします。

keytool -importcert -file IAM_ORACLE_HOME/oam/server/config/cacert.der -trustcacerts -keystore PathName_to_keystore -storetype JKS

キーストア・パスワードを、求められたら入力します。

例:

keytool -importcert -file IAM_ORACLE_HOME/oam/server/config/cacert.der -trustcacerts -keystore ssoKeystore.jks -storetype JKS

注意:

ssoKeystore.jksファイルとoamclient-truststore.jksファイルは、簡易モードで実行されるAccess ManagerとOracle Identity Managerを統合するときに必要です。これらのコンポーネントを統合するとき、これらのファイルをASERVER_HOME/config/fmwconfigディレクトリにコピーするように求められます。この後、これらのファイルを配置したマシンで、pack/unpackを使用してドメインを拡張する場合は、unpackコマンドを実行した後でssoKeystore.jksとoamclient-truststore.jksをコピーしなおす必要があります。

11.12 Access Managerの構成のバックアップ

第17.6.3項「インストール時および構成時のバックアップの実行」で説明されているように、データベース、WebLogicドメインおよびLDAPディレクトリをバックアップします。

12 Oracle Identity Managerを追加するためのドメインの拡張

この章では、Oracle Identity Managementエンタープライズ・デプロイメント・トポロジで使用するために、Oracle Identity Managerのインストールと構成を行う方法について説明します。

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

- 第12.1項「Oracle Identity Managerを追加するためのドメイン拡張の概要」

- 第12.2項「ドメインのURLについて」

- 第12.3項「前提条件」

- 第12.4項「WebLogic Serverライブラリ・ディレクトリへのOIMログイン・モジュールのプロビジョニング」

- 第12.5項「wlfullclient.jarファイルの作成」

- 第12.6項「システム・クロックの同期」

- 第12.7項「Oracle Identity ManagerおよびOracle SOA Suiteを構成するためのドメインの拡張」

- 第12.8項「IDMHOST1およびIDMHOST2の管理対象サーバーのドメイン・ディレクトリへのOracle Identity ManagerおよびOracle SOAの展開」

- 第12.9項「コンポジットのデプロイでのOracle Coherenceの構成」

- 12.10項「Oracle Identity Managerの構成」

- 第12.11項「SOAディレクトリのコピー」

- 第12.12項「IDMHOST1およびIDMHOST2でのSOAおよびOracle Identity Managerの管理対象サーバーの起動」

- 第12.13項「IDMHOST1およびIDMHOST2におけるOracle Identity Managerインスタンスの確認」

- 第12.14項「IDストアから調整するためのOracle Identity Managerの構成」

- 第12.15項「Oracle Web Tierと連携するためのOracle Identity Managerの構成」

- 第12.16項「トランザクション・リカバリ用のデフォルト永続ストアの構成」

- 第12.17項「UMSの電子メール通知の構成」

- 第12.18項「SOAキーストアへのロード・バランサ証明書の追加」

- 第12.19項「Oracle Identity Managerのリコンシリエーションからのユーザーの除外」

- 第12.20項「LDAPでプロビジョニングした管理ユーザーを使用したOracle Identity ManagerからSOAへの接続の有効化」

- 第12.21項「Active DirectoryをサポートするためのOracle Identity Managerの変更」

- 第12.22項「Oracle Identity Managerのバックアップ」

- 第12.23項「Oracle Identity ManagerとOracle Access Management Access Managerの統合」

12.1 Oracle Identity Managerを追加するためのドメイン拡張の概要

Oracle Identity Managerは、アプリケーションおよびディレクトリからユーザー・アカウントを追加、更新および削除するプロセスを自動化するユーザー・プロビジョニングおよび管理ソリューションです。また、誰が何にアクセスしたかを示すきめ細かいレポートを提供することで、法規制コンプライアンスの向上にも寄与します。Oracle Identity Managerは、スタンドアロンの製品としても、Oracle Identity Managementの一部としても利用できます。

ユーザー・アイデンティティのプロビジョニングを自動化すると、情報テクノロジ(IT)の管理コストを削減でき、セキュリティを向上できます。また、プロビジョニングは規制遵守においても重要な役割を果たします。Oracle Identity Managerの主要機能には、パスワード管理、ワークフローとポリシーの管理、アイデンティティ調整、レポートと監査、アダプタによる拡張性などがあります。

Oracle Identity Managerには、次の主要機能が用意されています。

- ユーザー管理

- ワークフローとポリシー

- パスワード管理

- 監査とコンプライアンスの管理

- 統合ソリューション

- ユーザー・プロビジョニング

- 組織とロールの管理

Oracle Identity Managerの詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドを参照してください。

12.2 ドメインのURLについて

この章を完了すると、次のURLが利用可能になります。

表12-1 OIMのURL

コンポーネント

URL

SSOユーザー

セルフサービス・コンソール

https://SSO.mycompany.com/identity

xelsysadm

OIM管理コンソール

http://ADMIN.mycompany.com/sysadmin

xelsysadm

12.3 前提条件

ドメインをOracle Identity Managerで拡張する前に、次の作業が行われたことを確認してください。

1. Oracle Identity ManagerおよびSOAの管理対象サーバーの仮想IPアドレスがプロビジョニングされ、有効になっていることを確認します。詳細は、第3.5項「IPアドレスおよび仮想IPアドレスについて」を参照してください。

2. 第12.5項「wlfullclient.jarファイルの作成」の説明に従ってwlfullclient.jarファイルが作成されていることを確認します。

3. アイデンティティ・ストアがインストールされ、構成されていることを確認します。

4. 第9.4項「アイデンティティ・ストアの準備」の説明に従って、Oracle Identity Managementのユーザーをプロビジョニングします。

5. Oracle Identity Managerを使用してドメインを拡張する前に、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、ドメイン内で動作しているすべての管理対象サーバーを停止します。

注意:

Oracle Identity Managerとともに配置したOracle SOAは、Oracle Identity Managerのワークフロー専用に使用されます。他の目的では使用できません。

12.4 WebLogic Serverライブラリ・ディレクトリへのOIMログイン・モジュールのプロビジョニング

構成ウィザードのバージョンの問題のため、一部の環境変数はASERVER_HOME/bin/setDomainenv.shスクリプトに追加されません。このため、特定のインストール・シーケンスが失敗します。この項は、この問題の一時的な回避策です。この項の手順は、Oracle Identity Managerをホストするドメインに関連付けられているすべてのMW_HOME(つまりIAM_MW_HOME)に対して実行する必要があります。

ドメインのすべてのWebLogic Serverホームで次の手順を適用します。

1. IAM_ORACLE_HOME/server/loginmodule/wlsディレクトリにあるOIMAuthenticator.jar、oimmbean.jar、oimsigmbean.jarおよびoimsignaturembean.jarの各ファイルを、IAM_MW_HOME/wlserver_10.3/server/lib/mbeantypesディレクトリにコピーします。

cp $IAM_ORACLE_HOME/server/loginmodule/wls/* $IAM_MW_HOME/wlserver_10.3/server/lib/mbeantypes

2. ディレクトリをMW_HOME/wlserver_10.3/server/lib/mbeantypes/に変更します。

cd $IAM_MW_HOME/wlserver_10.3/server/lib/mbeantypes

3. chmodコマンドを使用して、これらのファイルに関する権限を750に変更します。

chmod 750 *

12.5 wlfullclient.jarファイルの作成

Oracle Identity Managerは、特定の操作にwlfullclient.jarライブラリを使用します。このライブラリは出荷されていないため、手動で作成する必要があります。環境のアプリケーション層でOracle Identity Managerをホストしているすべてのマシンで、IAM_MW_HOME/wlserver_10.3/server/libディレクトリの下にこのライブラリを作成することをお薦めします(IAM_MW_HOME、OIM_MW_HOMEなど)。

次の手順に従って、wlfullclient.jarファイルを作成します。

1. IAM_MW_HOME/wlserver_10.3/server/libディレクトリに移動します。

2. JAVA_HOME環境変数を設定して、JAVA_HOME/binディレクトリがパスに含まれていることを確認します。

3. 次のファイルを実行することによって、wlfullclient.jarファイルを作成します。

java -jar wljarbuilder.jar

12.6 システム・クロックの同期

Oracle SOAは、クォーツを使用してそのジョブとスケジュールをデータベースで管理します。ジョブ、アダプタおよびOracle B2Bを正常に機能させるため、SOA WebLogicクラスタのシステム・クロックを同期させます。

12.7 Oracle Identity ManagerおよびOracle SOA Suiteを構成するためのドメインの拡張

Oracle Identity Managerを追加するにはドメインを拡張する必要があります。ドメインの拡張は、ドメインの管理サーバーを実行しているホストから行う必要があります。これは、IDMHOST1上のドメインIDMDomainです。

Oracle Identity Managerを使用してドメインを拡張するには、IDMHOST1上で次のコマンドを実行して構成ウィザードを開始します。

ORACLE_COMMON_HOME/common/bin/config.sh

次のように実行します。

1. 「ようこそ」画面で「既存のWebLogicドメインの拡張」を選択します。
「次へ」をクリックします。

2. 「WebLogicドメイン・ディレクトリの選択」画面で、IDMDomainのドメイン・ディレクトリの場所を選択します。例: /u01/oracle/config/domains/IDMDomain

「次へ」をクリックします。

3. 「拡張ソースの選択」画面で、「以下の追加製品をサポートするために、自動的にドメインを拡張する:」を選択します。下にあるリストで、Oracle Identity Managerを選択します。

注意:

- Oracle SOA SuiteとOracle WSM Policy Managerは、自動的に選択されます。Oracle WSM Policy Managerをすでにインストールしてある場合、この選択は行われません。

- 「Oracle Identity Manager」を選択すると、Oracle JRF WebServices Asynchronousサービスも自動的に選択されます。

「次へ」を選択します。

4. 「JDBCコンポーネント・スキーマの構成」画面で、次の手順を実行します。
ページに表示されているすべてのデータ・ソースを選択します。

- SOAインフラストラクチャ

- ユーザー・メッセージング・サービス

- OIM MDSスキーマ

- OWSM MDSスキーマ

- SOA MDSスキーマ

- OIMスキーマ

「GridLinkへ変換」を選択します。

「次へ」をクリックします。

5. GridLink RACコンポーネント・スキーマ画面が表示されます。この画面で、次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
該当するコンポーネント用のすべてのスキーマを選択します。これまでに構成済のコンポーネントに指定しているスキーマは選択しないでください。

各エントリに対して次の共通の情報を指定します。

- ドライバ: OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。

- 「FANの有効化」を選択します。

- 次のいずれかの操作を実行します。

- ONS通知を暗号化するためのSSLが構成されていない場合は、「SSL」の選択を解除します。

- SSLを選択し、適切なWalletおよびWalletのパスワードを指定します。

- サービス・リスナー: 使用するRACデータベースのためのSCANアドレスとポートを入力します。このアドレスは、データベース内のパラメータremote_listenerを問い合せれば識別できます。

SQL>show parameter remote_listener;

NAME            TYPE   VALUE
-------------------------------------------------------------
remote_listener string DB-SCAN.mycompany.com:1521

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例:

DBHOST1-VIP.mycompany.com (port 1521)

および

DBHOST2-VIP.mycompany.com (port 1521) (DB_LSNR_PORT)

Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。複数のデータ・ソースの構成に関する情報は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のODSMを使用した複数のディレクトリ・アイデンティティ・ストア用のアダプタの検証に関する項を参照してください。

- ONSホスト: Oracle RACデータベースのSCANアドレスおよびデータベースから報告されたONSリモート・ポートを入力します。

srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016

注意:

Oracle Database 11g リリース1 (11.1)では、次の例のように、各データベースのONSサービスのホスト名とポートを使用します。

DBHOST1.mycompany.com (port 6200)

および

DBHOST2.mycompany.com (port 6200)

次のRACコンポーネント・スキーマ情報を入力します。

スキーマの名前

サービス名

スキーマの所有者

パスワード

OIMスキーマ

OIMEDG.mycompany.com

EDG_OIM

password

SOAインフラストラクチャ

OIMEDG.mycompany.com

EDG_SOAINFRA

password

ユーザー・メッセージング・サービス

OIMEDG.mycompany.com

EDG_ORASDPM

password

OIM MDSスキーマ

OIMEDG.mycompany.com

EDG_MDS

password

OWSM MDSスキーマ

OIMEDG.mycompany.com

EDG_MDS

password

SOA MDSスキーマ

OIMEDG.mycompany.com

EDG_MDS

password

RACマルチ・データソースを使用する場合は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』のODSMを使用した複数のディレクトリ・アイデンティティ・ストア用のアダプタの検証に関する項を参照してください。

「次へ」をクリックします。

6. 「コンポーネント・スキーマのテスト」画面で、構成ウィザードによりデータ・ソースを検証します。データ・ソースの検証が成功した場合、「次へ」をクリックします。失敗した場合、「前へ」をクリックして問題に対処してから、再試行します。
「次へ」をクリックします。

7. 「オプションの構成を選択」画面で、次を選択します。

- JMS分散宛先

- 管理対象サーバー、クラスタ、およびマシン

- JMSファイル・ストア

「次へ」をクリックします。

8. 「JMS分散宛先」画面で、画面にあるJMSシステム・リソースのすべてが共通分散宛先であることを確認します。そうでない場合、「UDD」をドロップダウンから選択します。エントリが次のようになることを確認します。

JMSシステム・リソース

共通/重み設定された分散宛先

UMSJMSSystemResource

UDD

SOAJMSModule

UDD

OIMJMSModule

UDD

BPMJMSModule

UDD

JRFWSAsyncjmsModule

UDD

「次へ」をクリックします。

「オーバーライドの警告」ボックスに次のメッセージが表示されます。

CFGFWK-40915: At least one JMS system resource has been selected for conversion to a Uniform Distributed Destination (UDD). This  conversion will take place only if the JMS System resource is assigned to a cluster

「OK」を「オーバーライドの警告」ボックスでクリックします。

9. 「管理対象サーバーの構成」画面を初めて表示すると、oim_server1およびsoa_server1の2つの管理対象サーバーが自動的に作成されます。soa_server1をWLS_SOA1に、oim_server1をWLS_OIM1にそれぞれ名前変更し、その各属性を次の表のように更新します。さらに、次の属性を持つWLS_OIM2およびWLS_SOA2という2つの新しい管理対象サーバーを追加します。

名前

Listen address

Listen port

ポート変数

SSLリスニング・ポート

SSL有効

WLS_SOA1

SOAHOST1VHN

8001

SOA_PORT

N/A

いいえ

WLS_SOA2

SOAHOST2VHN

8001

SOA_PORT

N/A

いいえ

WLS_OIM1

OIMHOST1VHN

14000

OIM_PORT

N/A

いいえ

WLS_OIM2

OIMHOST2VHN

14000

OIM_PORT

N/A

いいえ

注意:

- これまでのデプロイメントの過程で構成された管理対象サーバーの構成は変更しないでください。

- 作成したデフォルトの管理対象サーバーを削除しないでください。説明に従って名前を変更してください。

10. 「クラスタの構成」画面で、「追加」をクリックして各クラスタを作成します。次の情報を指定します。

名前

メッセージング・モード

マルチキャスト・アドレス

マルチキャスト・ポート

クラスタ・アドレス

oim_cluster

ユニキャスト

n/a

n/a

OIMHOST1VHN:14000、OIMHOST2VHN:14000脚注 1

soa_cluster

ユニキャスト

n/a

n/a

SOAHOST1VHN:8001、SOAHOST2VHN:8001脚注 2

脚注 1 14000は第B.3項のOIM_PORTに相当します。

脚注 2 8001は第B.3項のSOA_PORTに相当します。

他のフィールドはすべてデフォルト設定のままにして、「次へ」をクリックします。

注意:

これまでのデプロイメントの過程で構成されたクラスタの構成は変更しないでください。

11. 「サーバーのクラスタへの割当」画面で、管理対象サーバーをクラスタと関連付けます。クラスタ名を右側のペインでクリックします。「サーバー」で管理対象サーバーをクリックしてから矢印をクリックして、クラスタに割り当てます。次の値を割り当てます。

クラスタ

サーバー

oim_cluster

WLS_OIM1

WLS_OIM2

soa_cluster

WLS_SOA1

WLS_SOA2

注意:

エントリがすでに定義されているクラスタは変更しないでください。

「次へ」をクリックします。

12. 「マシンの構成」画面で、トポロジ内の各ホストに対してマシンがまだ作成されていない場合、マシンを作成します。

1. 「Unixマシン」タブをクリックします。

2. 名前: ホスト名です。DNS名を使用することをお薦めします。

3. ノード・マネージャ・リスニング・アドレス: マシンのDNS名です。

4. ノード・マネージャ・ポート: ノード・マネージャのポートです。

次の表に示す情報を指定します。

名前

ノード・マネージャのリスニング・アドレス

ノード・マネージャ・リスニング・ポート

ポート変数

IDMHOST1

IDMHOST1

5556

NMGR_PORT

IDMHOST2

IDMHOST2

5556

NMGR_PORT

他のフィールドはすべてデフォルト値のままとします。

「マシン」タブの下のデフォルトのローカル・マシン・エントリを削除します。

「次へ」をクリックします。

13. 「サーバーのマシンへの割当」画面で、次のようにサーバーをマシンに割り当てます。

- IDMHOST1: WLS_OIM1およびWLS_SOA1

- IDMHOST2: WLS_OIM2およびWLS_SOA2

「次へ」をクリックして、続行します。

14. 「JMSファイル・ストアの構成」画面で、JMSファイル・ストアのディレクトリの場所を更新します。次の表に示す情報を指定します。

名前

ディレクトリ

UMSJMSFileStore_auto_1

ASERVER_HOME/jms/UMSJMSFileStore_auto_1

UMSJMSFileStore_auto_2

ASERVER_HOME/jms/UMSJMSFileStore_auto_2

BPMJMSServer_auto_1

ASERVER_HOME/jms/BPMJMSServer_auto_1

BPMJMSServer_auto_2

ASERVER_HOME/jms/BPMJMSServer_auto_2

SOAJMSFileStore_auto_1

ASERVER_HOME/jms/SOAJMSFileStore_auto_1

SOAJMSFileStore_auto_2

ASERVER_HOME/jms/SOAJMSFileStore_auto_2

OIMJMSFileStore_auto_1

ASERVER_HOME/jms/OIMJMSFileStore_auto_1

OIMJMSFileStore_auto_2

ASERVER_HOME/jms/OIMJMSFileStore_auto_2

JRFWSAsyncFileStore_auto_1

ASERVER_HOME/jms/JRFWSAsyncFileStore_auto_1

JRFWSAsyncFileStore_auto_2

ASERVER_HOME/jms/JRFWSAsyncFileStore_auto_2

「次へ」をクリックします。

15. 「構成のサマリー」画面で「拡張」をクリックして、ドメインを拡張します。

16. 「インストール 完了」画面で「完了」をクリックします。

17. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。

12.8 IDMHOST1およびIDMHOST2の管理対象サーバーのドメイン・ディレクトリへのOracle Identity ManagerおよびOracle SOAの展開

構成が完了したら、IDMHOST1およびIDMHOST2の管理対象サーバーのディレクトリにOracle Identity Managerの構成を伝播する必要があります。

これを行うには、ドメインのパックと解凍を実行します。最初にIDMHOST1のIDMDomainでドメインのパックを実行し、次にIDMHOST1およびIDMHOST2でそれを解凍します。

次の手順を実行して、管理対象サーバーのドメイン・ディレクトリにドメインを伝播します。

1. IDMHOST1上で、ORACLE_COMMON_HOME/common/bin/からpackユーティリティを起動します。

./pack.sh -domain=ASERVER_HOME -template=oim_domain.jar -template_name="OIM Domain" -managed=true

2. これによってoim_domain.jarというファイルが作成されます。このファイルをIDMHOST2にコピーします。

3. IDMHOST1とIDMHOST2でunpackユーティリティを起動します。このユーティリティもORACLE_COMMON_HOME/common/bin/ディレクトリにあります。

./unpack.sh -domain=MSERVER_HOME -template=oim_domain.jar -overwrite_domain=true -app_dir=MSERVER_HOME/applications

12.9 コンポジットをデプロイするためのOracle Coherenceの構成

コンポジットのデプロイではマルチキャスト通信がデフォルトで使用されますが、SOAエンタープライズ・デプロイメントではユニキャスト通信の使用をお薦めします。セキュリティ上の理由からマルチキャスト通信を無効化した場合には、ユニキャスト通信を使用します。

ユニキャスト通信を使用した場合、この方法ではノードから他のクラスタ・メンバーを検出できません。そのため、クラスタに属するノードを指定する必要があります。ただし、クラスタのすべてのノードを指定する必要はありません。クラスタに追加された新しいノードが既存ノードの1つを検出するために必要なノードを指定するだけで済みます。これによって、新しいノードがクラスタに追加されたときに、クラスタ内の他のすべてのノードを検出できるようになります。また、同じシステムで複数のIPを使用できるSOAエンタープライズ・デプロイメントなどの構成では、特定のホスト名を使用してOracle Coherenceクラスタを作成するようにOracle Coherenceを構成する必要があります。

注意:

デプロイメントに使用するOracle Coherenceフレームワークの構成が正しくないと、SOAシステムを起動できないことがあります。SOAシステムが実行されるネットワーク環境に応じてデプロイメント・フレームワークを適切にカスタマイズする必要があります。この項で説明する構成をお薦めします。

この項には次のトピックが含まれます:

- 第12.9.1項「ユニキャスト通信を使用したデプロイメントの通信の有効化」

- 第12.9.2項「Oracle Coherenceによって使用されるホスト名の指定」

12.9.1 ユニキャスト通信を使用したデプロイメントの通信の有効化

tangosol.coherence.wka<n>システム・プロパティを使用してノードを指定します。<n>は、1から9の数字です。最大9つのノードを指定できます。番号は、1から開始します。連続した番号を指定する必要があり、途切れていてはなりません。また、Oracle Coherenceでクラスタを作成するために使用するホスト名をtangosol.coherence.localhostシステム・プロパティで指定します。このローカル・ホスト名には、SOAサーバーでリスナーのアドレスとして使用する仮想ホスト名を指定する必要があります(SOAHOST1VHNとSOAHOST2VHN)。このプロパティを設定するには、Oracle WebLogic Server管理コンソールの「サーバーの起動」タブにある「引数」フィールドに-Dtangosol.coherence.localhostパラメータを追加します。

ヒント:

SOAコンポジットのデプロイ時に高可用性を確保するには、適切な数のノードを指定して、どの時点でもそのうちのいずれかが必ず稼働しているようにします。

注意:

SOAHOST1VHNは、SOAHOST1でWLS_SOA1がリスニングする仮想IPにマップされる仮想ホスト名です。SOAHOST2VHNは、SOAHOST2でWLS_SOA2がリスニングする仮想IPにマップされる仮想ホスト名です。

12.9.2 Oracle Coherenceで使用するホスト名の指定

管理コンソールを使用して、Oracle Coherenceで使用するホスト名を指定します。

Oracle Coherenceで使用するホスト名を追加する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列にハイパーリンクで表示されているサーバーの名前(WLS_SOA1またはWLS_SOA2)をクリックします。選択したサーバーの設定ページが表示されます。

5. 「ロックして編集」をクリックします。

6. 「サーバーの起動」タブをクリックします。

7. 「引数」フィールドで、WLS_SOA1とWLS_SOA2について次のように入力します。
WLS_SOA1については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN
-Dtangosol.coherence.wka2=SOAHOST2VHN
-Dtangosol.coherence.localhost=SOAHOST1VHN

WLS_SOA2については次の値を入力します。

-Dtangosol.coherence.wka1=SOAHOST1VHN
-Dtangosol.coherence.wka2=SOAHOST2VHN
-Dtangosol.coherence.localhost=SOAHOST2VHN

注意:

異なる-Dパラメータの間には、空白の行を入れないでください。管理コンソールの引数テキスト・フィールドに、このテキストをコピーまたは貼り付けないでください。Java引数にHTMLタグが挿入される可能性があります。このテキストには、前述の例に含まれているテキスト文字以外の文字を入れないでください。

注意:

デプロイメントで使用されるCoherenceクラスタでは、ポート8088をデフォルトで使用します。このポートは、起動パラメータ-Dtangosol.coherence.wkan.portおよび-Dtangosol.coherence.localportで別なポート(8089など)を指定することで変更できます。例:

WLS_SOA1(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN
-Dtangosol.coherence.wka2=SOAHOST2VHN
-Dtangosol.coherence.localhost=SOAHOST1VHN
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

WLS_SOA2(「引数」フィールドに、改行なしで1行で次のように入力):

-Dtangosol.coherence.wka1=SOAHOST1VHN
-Dtangosol.coherence.wka2=SOAHOST2VHN
-Dtangosol.coherence.localhost=SOAHOST2VHN
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

Coherenceクラスタの詳細は、『Oracle Coherence開発者ガイド』を参照してください。

8. 「保存」→「変更のアクティブ化」をクリックします。

注意:

- これらの変数が管理対象サーバーに正しく渡されることを確認する必要があります(これらの変数はサーバーの出力ログに記録されます)。Oracle Coherenceフレームワークに問題があると、soa-infraアプリケーションを起動できないことがあります。

- マルチキャスト・アドレスとユニキャスト・アドレスは、クラスタ通信においてWebLogic Serverクラスタで使用するアドレスとは異なります。2つのエンティティ(コンポジットの配置先となるグループとWebLogic Serverクラスタ)における通信プロトコルが異なっていても、1つのWebLogic Serverクラスタに属するメンバーにコンポジットが配置されることがSOAで保証されます。

9. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従い、WebLogic管理コンソールを使用してIDMHOST1上のWebLogic管理サーバーを停止します。

10. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従い、ノード・マネージャを使用してIDMHOST1上の管理サーバーを起動します。

11. SOAサーバーWLS_SOA1を起動します。

12. 必要に応じて、第12.3項「前提条件」でシャットダウンした他のサーバーを起動します。

12.10 Oracle Identity Managerの構成

Oracle Identity ManagerおよびSOAの管理対象サーバーを起動する前に、Oracle Identity Managerサーバー・インスタンスを構成しておく必要があります。これはIDMHOST1で実行します。Oracle Identity Management構成ウィザードによって、Oracle Identity Managerメタデータがデータベースにロードされ、インスタンスが構成されます。

続行する前に、次の事項が正しいことを確認してください。

- 管理サーバーが起動されて、実行中であること。

- SOA管理対象サーバーが起動されて、実行中であること。

- 環境変数DOMAIN_HOMEおよびWL_HOMEが現在のシェル内で設定されていないこと。

Oracle Identity Managementの構成ウィザードは、Identity ManagementのOracleホームの下にあります。構成ウィザードを起動するには、次のように入力します。

IAM_ORACLE_HOME/bin/config.sh

次のように実行します。

1. 「ようこそ」画面で、「次へ」をクリックします。

2. 構成するコンポーネント画面でOIMサーバーを選択します。
「次へ」をクリックします。

3. 「データベース」画面で、次の値を入力します。

- 接続文字列: Oracle Identity Managerデータベースの接続文字列。
IDMDB1-VIP.mycompany.com:1521:OIMEDG1^IDMDB2-VIP.mycompany.com:1521:OIMEDG2@OIMEDG.mycompany.com、ここで1521は第B.3項のDB_LSNR_PORTポートに相当します。

Oracle Database 11.2を使用している場合は、vipのアドレスとポートを11.2 SCANのアドレスとポートに置き換えます。

- OIMスキーマ・ユーザー名: EDG_OIM

- OIMスキーマのパスワード: password

- MDSスキーマ・ユーザー名: EDG_MDS

- MDSスキーマのパスワード: password

「次へ」をクリックします。

4. WebLogic管理サーバー画面で、WebLogic管理サーバーについて次の詳細を入力します。

- URL: WebLogic管理サーバーに接続するためのURLです。例:
t3://ADMINVHN.mycompany.com:7001、ここでポート7001はWLS_ADMIN_PORTです。

- ユーザー名: weblogic

- パスワード: weblogicユーザーのパスワードです。

「次へ」をクリックします。

5. OIMサーバー画面で、次の値を入力します。

- OIM管理パスワード: Oracle Identity Manager管理者のパスワード。これはxelsysadmユーザーのパスワードです。このパスワードには、大文字と数字を使用する必要があります。ベスト・プラクティスは、第9.4項「アイデンティティ・ストアの準備」でユーザーxelsysadmに割り当てたパスワードと同じパスワードを使用することです。

- パスワードの確認: パスワードを確認するためのものです。

- OIM HTTP URL: Oracle Identity ManagerサーバーのプロキシURL。これは、Oracle Identity ManagerのOHSサーバーのフロントエンドに位置するハードウェア・ロード・バランサのURLです。例: http://IDMINTERNAL.mycompany.com:80

- LDAP同期の有効化: 選択されています。

「次へ」をクリックします。

6. 「LDAPサーバー」画面では、入力する情報が実際の実装によって異なります。次の詳細を指定します。

- ディレクトリ・サーバー・タイプ:

- アイデンティティ・ストアがOracle Unified Directoryの場合、OUD。

- アイデンティティ・ストアがOracle Internet Directory内にある場合、OID。

- Oracle Virtual Directoryを通じてアイデンティティ・ストアにアクセスする場合、OVD。

- ディレクトリ・サーバーID: ディレクトリ・サーバーの名前。たとえば、IdStoreを指定します。これは、ディレクトリ・タイプがOIDまたはOUDである場合にのみ必要です。

- サーバーURL: LDAPサーバーのURL。例: ldap://IDSTORE.mycompany.com:389

- サーバーのユーザー: LDAPサーバーに接続するためのユーザー名。例: cn=oimLDAP,cn=systemids,dc=mycompany,dc=com

- サーバーのパスワード: LDAPサーバーに接続するためのパスワード。

- サーバー検索DN: Oracle Virtual Directoryサーバーを使用してIDストアにアクセスする場合の検索DN。たとえば、dc=mycompany,dc=comです。

「次へ」をクリックします。

7. LDAPサーバー(続き)画面で、次のLDAPサーバー詳細を入力します。

- LDAPロールコンテナ: ロール・コンテナのDNです。これは、Oracle Identity Managerのロールが保存されるコンテナです。例: cn=Groups,dc=mycompany,dc=com

- LDAPユーザーコンテナ: ユーザー・コンテナのDNです。これは、Oracle Identity Managerユーザーが保存されるコンテナです。たとえば、cn=Users,dc=mycompany,dc=comです。

- ユーザー予約コンテナ: ユーザー予約コンテナのDNです。例: cn=Reserve,dc=mycompany,dc=com

「次へ」をクリックします。

8. 「構成サマリー」画面で、サマリー情報を確認します。
「構成」をクリックして、Oracle Identity Managerインスタンスを構成します。

9. 「構成の進行状況」画面で、構成が正常に完了すると、「次へ」をクリックします。

10. 「構成が完了しました」画面で、構成されたOracle Identity Managerインスタンスの詳細を確認します。
「終了(F)」をクリックして、構成ウィザードを終了します。

11. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。

12.11 SOAディレクトリのコピー

IDMHOST1のASERVER_HOMEの下にあるsoaディレクトリを、IDMHOST1およびIDMHOST2のMSERVER_HOMEディレクトリにコピーします。

例:

scp -rp ASERVER_HOME/soa user@IDMHOST2:MSERVER_HOME

12.12 IDMHOST1およびIDMHOST2でのSOAおよびOracle Identity Managerの管理対象サーバーの起動

次の一連の手順に従って、IDMHOST1上で管理対象サーバーWLS_OIM1とWLS_SOA1を起動します。

1. Oracle WebLogic管理コンソールを起動することで、管理サーバーが正常に起動することを確認します。

2. 管理対象サーバーWLS_SOA1が実行中である場合は、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従っていったん停止し、再起動します。

3. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従い、WebLogic管理コンソールを使用して管理対象サーバーWLS_OIM1を起動します。

次の一連の手順に従って、IDMHOST2上で管理対象サーバーWLS_OIM2とWLS_SOA2を起動します。

1. Oracle WebLogic管理コンソールを起動することで、管理サーバーが正常に起動することを確認します。

2. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従い、WebLogic管理コンソールを使用して管理対象サーバーWLS_SOA2を起動します。

3. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従い、WebLogic管理コンソールを使用して管理対象サーバーWLS_OIM2を起動します。

12.13 IDMHOST1およびIDMHOST2におけるOracle Identity Managerインスタンスの確認

Webブラウザで次のURLを指定してOracle Identity Managerコンソールを起動することによって、Oracle Identity Managerサーバー・インスタンスを検証します。

http://OIMHOST1VHN.mycompany.com:14000/identity

http://OIMHOST1VHN.mycompany.com:14000/sysadmin

http://OIMHOST2VHN.mycompany.com:14000/identity/

http://OIMHOST2VHN.mycompany.com:14000/sysadmin/

xelsysadmユーザー名とパスワードを使用して、ログインします。

注意:

初めてログインする際に、チャレンジ質問を設定するように求められます。続行する前に、これを行ってください。

次のURLを使用してOracle SOA Suiteを検証します。

http://SOAHOST1VHN.mycompany.com:8001/soa-infra

http://SOAHOST2VHN.mycompany.com:8001/soa-infra

ここで、8001は第B.3項のSOA_PORTになります。

weblogicユーザーとしてログインします。

12.14 IDストアから調整するためのOracle Identity Managerの構成

現在のリリースでは、LDAPConfigPostSetupスクリプトを使用すると、LDAPSync関連の増分リコンシリエーション・スケジューラ・ジョブがすべて有効になります。これらのジョブはデフォルトでは無効です。LDAP構成ポストセットアップ・スクリプトは、IAM_ORACLE_HOME/server/ldap_config_utilディレクトリにあります。スクリプトをIDMHOST1で次のように実行します。

1. IAM_ORACLE_HOME/server/ldap_config_utilディレクトリの下にあるldapconfig.propsファイルを編集して、次の値を指定します。

パラメータ

値

説明

OIMProviderURL

t3://OIMHOST1VHN.mycompany.com:14000,OIMHOST2VHN.mycompany.com:14000脚注 1

Oracle Identity Manager管理対象サーバーのリスト。

LDAPURL

次の例のような、Oracle Virtual DirectoryインスタンスのURLを指定します。ldap://IDSTORE.mycompany.com:389

アイデンティティ・ストアのURL。Oracle Virtual Directoryを使用してIDストアにアクセスする場合のみ必要です。

LDAPAdminUserName

cn=oimLDAP,cn=systemids,dc=mycompany,dc=com

アイデンティティ・ストアへの接続に使用するユーザーの名前。アイデンティティ・ストアがOracle Virtual Directoryに存在する場合のみ必要です。このユーザーは、cn=Users,dc=mycompany,dc=comに配置しないでください。

LIBOVD_PATH_PARAM

MSERVER_HOME/config/fmwconfig/ovd/oim

Oracle Virtual Directoryを使用してアイデンティティ・ストアにアクセスしない場合は必要です。

脚注 1 14000は第B.3項のOIM_PORTに相当します。

注意:

usercontainerName、rolecontainernameおよびreservationcontainernameは、この手順で使用しません。

2. ファイルを保存します。

3. MW_HOMEをIAM_MW_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

JAVA_HOMEをJAVA_HOMEに設定します。

WL_HOMEをMW_HOME/wlserver_10.3に設定します。

APP_SERVERをweblogicに設定します。

OIM_ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

DOMAIN_HOMEをMSERVER_HOMEに設定します。

4. LDAPConfigPostSetup.shを実行します。このスクリプトでは、LDAPの管理者パスワードとOracle Identity Managerの管理者パスワードが要求されます。例:

IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh path_to_property_file

例:

IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh IAM_ORACLE_HOME/server/ldap_config_util

12.15 Oracle Web Tierと連携するためのOracle Identity Managerの構成

この項では、Oracle Identity Managerを構成してOracle Web Tierと連携する方法について説明します。

この項には次のトピックが含まれます:

- 第12.15.1項「Oracle Identity ManagerおよびSOAの管理対象サーバーのフロント・エンドとして機能するためのOracle HTTP Serverの構成」

- 第12.15.2項「WebLogicにおけるホスト・アサーションの変更」

- 第12.15.3項「SOAエンドポイントの更新」

- 第12.15.4項「Web層統合の検証」

12.15.1 Oracle Identity ManagerおよびSOAの管理対象サーバーのフロント・エンドとして機能するためのOracle HTTP Serverの構成

既存のドメインにOIMを追加する場合、第10.3項「構成後のタスク」で説明されているように、Web層の構成にOIMを忘れずに含める必要があります。

12.15.2 WebLogicにおけるホスト・アサーションの変更

Oracle HTTP Serverは、WebLogicのプロキシとして機能するため、デフォルトでは、特定のCGI環境変数はWebLogicに渡されません。これらには、ホストとポートが含まれます。WebLogicには、内部URLを適切に生成できるように仮想サイト名およびポートを使用していることを指示する必要があります。

これを行うには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、WebLogic管理コンソールにログインします。

1. 「クラスタ」をホーム・ページで選択するか、「ドメイン」構造メニューで「環境」→「クラスタ」を選択します。

2. 「チェンジ・センター」ウィンドウの「ロックして編集」をクリックして、編集を有効にします。

3. 「クラスタ名」(soa_cluster)をクリックします。

4. 「構成」タブで、「HTTP」サブタブを選択します。
次を入力します。

- フロントエンド・ホスト: IDMINTERNAL.mycompany.com

- フロントエンドHTTPポート: 80 (HTTP_PORT)

5. 「保存」をクリックします。

6. 「チェンジ・センター」ウィンドウの「変更のアクティブ化」をクリックして、編集を有効にします。

12.15.3 SOAエンドポイントの更新

次の手順に従ってSOAエンドポイントを更新します。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているアドレスを使用して、Oracle Enterprise Manager Fusion Middleware Controlにログインします。

2. ナビゲーション・ペインでSOAフォルダを展開し、「soa-infra」を右クリックします。

3. 「SOA管理」→「共通プロパティ」を選択します。

4. 「詳細SOAインフラ拡張構成プロパティ」リンクをクリックします。

5. 次のプロパティを編集し、変更を適用します。

- ServerURL: http://IDMINTERNAL.mycompany.com:80

- CallbackServerURL: http://IDMINTERNAL.mycompany.com:80

- HttpServerURL: http://IDMINTERNAL.mycompany.com:80

6. 「適用」をクリックします。

7. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WLS_SOA1とWLS_SOA2を再起動します。

12.15.4 Web層統合の検証

次に示すようにWeb層の統合を検証します。

12.15.4.1 Web層からのOracle Identity Managerインスタンスの検証

Webブラウザで次のURLを指定してOracle Identity Managerコンソールを起動することによって、Oracle Identity Managerサーバー・インスタンスを検証します。

https://SSO.mycompany.com:443/identity

および

http://ADMIN.mycompany.com/sysadmin

xelsysadmユーザー名とパスワードを使用して、ログインします。

12.15.4.2 Web層からSOAへのアクセスの検証

次のURLにアクセスし、SOAを検証します。

http://IDMINTERNAL.mycompany.com:80/soa-infra

WebLogic管理ユーザーとしてログインします。

注意:

Webゲートを有効にすると、soa-infraは利用できなくなります。

12.16 トランザクション・リカバリ用のデフォルト永続ストアの構成

管理対象サーバーWLS_OIMとWLS_SOAには、サーバーがコーディネートする、完了していない可能性のあるコミット済トランザクションに関する情報を格納するトランザクション・ログがあります。WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内のサーバーでトランザクション回復サービスの移行機能を活用するには、サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

注意:

この場所は、デュアル・ポート型SCSIディスクまたはストレージ・エリア・ネットワーク(SAN)にすることをお薦めします。

Oracle Identity ManagerおよびSOAサーバーのデフォルトの永続ストアの場所を設定する手順は次のとおりです。

1. 共有記憶域に次のディレクトリを作成します。
ASERVER_HOME/tlogs

2. Oracle WebLogic Server管理コンソールにログインします。

3. 「ロックして編集」をクリックします。

4. 「ドメイン構造」ウィンドウで、「環境」ノードを開いてから、「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。

5. 表の「名前」列で、Oracle Identity ManagerまたはSOAサーバーの名前(ハイパーリンクで表示されています)をクリックします。

6. 選択したサーバーの「設定」ページが表示され、「構成」タブにデフォルト設定されます。

7. 「サービス」サブタブを開きます。

8. ページの「デフォルト・ストア」セクションで、共有記憶域にあるデフォルトの永続ストアへのパスを指定します。パスのディレクトリ構造は次のとおりです。

- Oracle Identity Managerサーバー: ASERVER_HOME/tlogs

- SOAサーバー: ASERVER_HOME/tlogs

注意:

トランザクション・リカバリ・サービスの移行機能を有効にするには、クラスタにある他のサーバーで使用可能な永続記憶域ソリューションの場所を指定します。クラスタに属するすべてのサーバーは、このディレクトリにアクセスできる必要があります。

9. 保存してアクティブ化するをクリックします。

10. 「サーバーのサマリー」ページで他のSOAサーバーを選択し、これらの手順を繰り返します。

11. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle Identity ManagerとSOAの管理対象サーバーを再起動します。これによって、変更が有効になります。

12.17 UMSの電子メール通知の構成

この項では、UMSの電子メール通知の構成方法について説明します。これはオプションです。次の手順では、電子メール・サーバーが設定済で、それを使用してOracle Identity Managementで電子メール通知を送信できることを前提としています。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle Identity Managerに関連付けられているOracle Enterprise Manager Fusion Middleware Controlのインスタンスにログインします。

2. 「ユーザー・メッセージング・サービス」を開きます。

3. 「usermessagingdriver-email (WLS_SOA1)」を右クリックし、「電子メール・ドライバ・プロパティ」を選択します。

4. 次の情報を入力します。

- OutgoingMailServer: SMTPサーバーの名前、例: SMTP.mycompany.com

- OutgoingMailServerPort: SMTPサーバーのポート、例: SSL送信メール・サーバーの場合は465、SSLを使用しない場合は25

- OutgoingMailServerSecurity: SMTPサーバーによって使用されるセキュリティ設定。使用可能な値はNone/TLS/SSL。SSLリクエストを受け付けるようにメール・サーバーを構成する場合は、次の追加手順を実行してSOA環境からDemoTrustストアの参照を削除します。

1. MSERVER_HOME/bin/setDomainEnv.shファイルを変更し、DemoTrustの参照である-Djavax.net.ssl.trustStore=WL_HOME/server/lib/DemoTrust.jksをEXTRA_JAVA_PROPERTIESから削除します。

2. IDMHOST1とIDMHOST2にあるstartManagedWeblogic.shファイルを変更します。このファイルのJAVA_OPTIONSにあるプロパティ・セットweblogic.security.SSL.trustedCAKeyStoreを削除します。削除するのは、次のような行です。

JAVA_OPTIONS="-Dweblogic.security.SSL.trustedCAKeyStore="{MW_HOME}/server/server/lib/cacerts" ${JAVA_OPTIONS}"

3. Oracle Identity Manager、OIMサーバー、SOA管理対象サーバーを再起動します。

- OutgoingUsername: 任意の有効なユーザー名

- OutgoingPassword:

1. 「間接パスワード、新規のユーザーの作成」を選択します。

2. 「間接ユーザー名/キー」に一意の文字列を入力します(OIMEmailConfigなど)。これによりパスワードがマスクされ、構成ファイルにクリア・テキストで公開されません。

3. このアカウントの有効なパスワードを指定します。

「適用」をクリックします。

各SOAサーバーで手順3、4を繰り返します。

5. ナビゲータで、「WebLogicドメイン」→「Domain@Name」を選択します。

6. メニューからシステムMeanブラウザを選択します。

7. 「アプリケーション定義のMBean」→「oracle.iam」→「サーバー: WLS_OIM1」→「アプリケーション: oim」→「IAMAppRuntimeMBean」を展開します。

8. 「UMSEmailNotificationProviderMBean」をクリックします。

9. 次を入力します。

- WSUrl: http://IDMINTERNAL.mycompany.com:80/ucs/messaging/webservice

- ポリシー: 空白のままにします。

- CSFKey: Notification.Provider.Key

10. 「適用」をクリックします。

12.18 SOAキーストアへのロード・バランサ証明書の追加

ブラウザを使用してSSO.mycompany.comの証明書を取得します。(この方法については、使用するブラウザのドキュメントを参照してください。)ファイルを.pemフォーマットでIDMHOST1に保存します(例: /tmp/sso.pem)。

次に、JDK (Java Development Kit)の一部として提供されているkeytoolコマンドを使用して、証明書をSOAキーストアにインポートします。次のように実行します。

1. 環境変数を設定します。

- JAVA_HOMEをJAVA_HOMEに設定します。

- PATHをJAVA_HOME/bin:$PATHに設定します。

2. ディレクトリをWL_HOME/server/libに変更します。

cd WL_HOME/server/lib

3. 次のコマンドを使用して、証明書をSOAキーストアに追加します。

keytool -import -file /tmp/sso.pem -alias SSOAlias -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase

12.19 Oracle Identity Managerのリコンシリエーションからのユーザーの除外

デフォルトでは、Oracle Identity ManagementはLDAP container cn=Usersに属するすべてのユーザーを調整します。調整後、これらのユーザーはOracle Identity Managerで定義されている通常のパスワード・エイジング・ポリシーに従います。これらの処置は、システム・アカウントにとっては適切でありません。このリコンシリエーションから次のアカウントを除外することをお薦めします。

- xelsysadm

- oimLDAP

- oamLDAP

リコンシリエーションからこれらのユーザーを除外し、失敗したリコンシリエーション・イベントを破棄するには、ODSMおよびOIMコンソールを使用して次の項に記載されている手順を実行します。

この項には次のトピックが含まれます:

- 第12.19.1項「ODSMを使用してユーザーにorclAppIDUserオブジェクト・クラスを追加」

- 第12.19.2項「失敗したリコンシリエーション・イベントをOIMコンソールを使用して閉じる」

12.19.1 ODSMを使用してユーザーにorclAppIDUserオブジェクト・クラスを追加

ユーザーにオブジェクト・クラスorclAppIDUserをアタッチすることによって、OIMリコンシリエーションからそのユーザーを除外できます。

次の例はOracle Unified Directoryの例であり、Oracle Unified Directory用のODSMを使用します。Oracle Internet DirectoryまたはOracle Virtual Directoryを使用する場合は、OID/OVD用のODSMを使用してこれを実行できます。Oracle Unified Directory、Oracle Internet DirectoryまたはOracle Virtual Directory以外のディレクトリについては、システム・ドキュメントを参照してこの処理を行う方法を参照してください。

1. 次のURLからODSMにログインします。
http://ADMIN.mycompany.com/odsm

2. 除外するユーザーをホストしているいずれかのLDAPインスタンスに接続します。

- サーバー: Oracle Unified Directoryのいずれかのホスト、例: IDMHOST1.mycompany.com

- 管理ポート: Oracle Unified Directoryの管理ポート(LDAP_DIR_ADMIN_PORT)、例: 4444

- ユーザー名: ディレクトリ管理者、例: cn=oudadmin

サーバー証明書を信頼するかを尋ねられたら、信頼するように指定します。

3. 「データ・ブラウザ」を選択します。

4. ディレクトリ・ツリーで除外対象のユーザーまで移動し、そのユーザーをクリックします。例: ルート→「dc=mycompany,dc=com」→「cn=systemids」→「cn=UserId」

5. 「属性」タブをクリックします。

6. 「オブジェクト・クラス」リスト(必須プロパティ内)で+記号をクリックします。

7. プロパティ名orclAppIDUserを入力します。

8. 「適用」をクリックします。

除外対象のすべてのユーザーに対して手順1-8を繰り返します。

12.19.2 失敗したリコンシリエーション・イベントをOIMコンソールを使用して閉じる

この手順は、失敗したリコンシリエーション・イベントをクリアするために必要です。失敗したリコンシリエーション・イベントは繰り返し再試行され、システムに不必要な負荷をかけます。

1. 次のURLを使用して、OIM管理コンソールにxelsysadmユーザーでログインします: http://ADMIN.mycompany.com/sysadmin

2. 「イベント管理」の下の「リコンシリエーション」をクリックします。

3. 「拡張検索」をクリックします。

4. 「現行のステータス」フィールドで「次と等しい」を選択します。「検索」ボックスで、リストから「作成に失敗しました」を選択します。

5. 「検索」をクリックします。

6. 各イベントを選択します。

7. 「アクション」メニューから、「イベントのクローズ」を選択します。

8. 「確認」ウィンドウで理由を入力します。たとえば、「失敗したリコンシリエーション・イベントを閉じる」などと入力します。

9. 「クローズ」をクリックします。

10. 「OK」をクリックし、確認メッセージを承認します。

12.20 LDAPでプロビジョニングした管理ユーザーを使用したOracle Identity ManagerからSOAへの接続の有効化

Oracle Identity Managerは、デフォルトではweblogicというユーザー名を使用して、SOA管理者としてSOAに接続します。前の項では、Identity Management WebLogicドメインを管理するために、新しい管理者ユーザーを中央のLDAPストアでプロビジョニングしました。

次のインストール後の手順を実行して、Oracle Identity Managerが、中央のLDAPストアでプロビジョニングしたOracle WebLogic Server管理者ユーザーを使用できるようにします。これにより、Oracle Identity Managerは問題なくSOAに接続できるようになります。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Enterprise Managerにログインします。

2. 「Farm_IDMDomain」→「Identity and Access」→「OIM」→「oim(11.1.2.0.0)」を選択します。

3. メニューから「システムMBeanブラウザ」を選択するか、または右クリックしてこの項目を選択します。

4. 「アプリケーション」を選択し、定義済Mbean→「oracle.iam」を選択します。「サーバー」には「WLS_OIM1」、「アプリケーション」には「oim」を選択します。XML構成→「構成」を選択し、「XMLConfig.SOAConfig」→「SOAConfig」を選択します。

5. username属性を、第9.4項「アイデンティティ・ストアの準備」でプロビジョニングしたOracle WebLogic Server管理者のユーザー名(例: weblogic_idm)に変更します。
「SOA構成RMI URL」を次のように変更します。

cluster:t3://soa_cluster

「SOA構成SOAP URL」を次のように変更します。

http://IDMINTERNAL.mycompany.com:80

6. 「適用」をクリックします。

7. ナビゲータで「WebLogicドメイン」→「IDMDomain」を選択します。

8. ドロップダウン・メニューで「セキュリティ」→「資格証明」を選択します。

9. キーoimを開きます。

10. 「SOAAdminPassword」をクリックします。

11. 「編集」をクリックします。

12. ユーザー名をweblogic_idmに変更し、そのパスワードをアカウントのパスワードに設定します。

13. 「OK」をクリックします。

14. 調整プロセスを実行して、Oracle WebLogic Serverの管理者であるweblogic_idmをOIMアイデンティティ・コンソールで表示できるようにします。次の手順に従います。

1. URL http://ADMIN.mycompany.com/sysadminを使用して、OIM管理コンソールにxelsysadmユーザーでログインします。

2. 「システム管理」の下の「スケジューラ」をクリックします。

3. 検索ボックスにLDAP*と入力します。

4. 「スケジュール済ジョブの検索」の矢印をクリックして、すべてのスケジューラを一覧表示します。

5. LDAPユーザー作成および完全なリコンシリエーションの更新を選択します。

6. 「即時実行」をクリックしてジョブを実行します。

7. LDAPロール作成および完全なリコンシリエーションの更新のジョブを繰り返します。

8. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、OIMアイデンティティ・コンソールにログインします。検索を実行し、ユーザーweblogic_idmが表示されるかどうかを確認します。

15. URL https://SSO.mycompany.com:443/identityを使用して、OIMアイデンティティ・コンソールにユーザーxelsysadmでログインします。
要求されたら、チャレンジ質問を設定します。これは、Oracle Identity Managerアイデンティティ・コンソールへの最初のログイン時に発生します。

16. 「管理」の下の「ロール」をクリックします。

17. 管理者ロールを検索します。
「表示名」検索ボックスにAdministratorsと入力し、「検索」をクリックします。

18. 「管理者」ロールをクリックします。
このロールの「プロパティ」ページが表示されます。

19. 「メンバー」タブをクリックします。

20. 「ルールの追加」をクリックします。
「オペランド値の選択」セクションから「ユーザー・ログイン」を選択し、「追加」をクリックします。

「値」ボックスにweblogic_idmと入力します。

21. 「追加(A)」をクリックします。

22. 「保存」をクリックします。

23. WebLogicコンソールにログインします。

24. 「チェンジ・センター」で「ロックして編集」をクリックします。

25. 「IDMDomain」→「サービス」→「外部JNDIプロバイダ」と移動します。

26. 「ForeignJNDIProvider-SOA」をクリックします。

27. 「構成」→「一般」タブの下で、ユーザーweblogicをweblogic_idmに変更し、対応するパスワードを指定します。

28. 「保存」→「変更のアクティブ化」をクリックします。

12.21 Active DirectoryをサポートするためのOracle Identity Managerの変更

次の各項の説明に従ってOracle Identity Managerを変更します。

この項には次のトピックが含まれます:

- 第12.21.1項「Active Directoryのユーザー名生成ポリシーの更新」

- 第12.21.2項「Active DirectoryをサポートするためのOracle Identity Managerのプロパティの変更」

12.21.1 Active Directoryのユーザー名生成ポリシーの更新

バック・エンド・ディレクトリがActive Directoryである場合は、長さが20文字までのユーザー名のみを許可するようにOracle Identity Managerを更新する必要があります。これはActive Directoryによる制限です。次の手順で、ユーザー名生成ポリシーをDefaultComboPolicyからFirstnameLastnamepolicyforADに更新します。

1. 第12.2項「ドメインのURLについて」に記載されているURLを使用して、OIM管理コンソールにログインします。

2. 「システム管理」の下の「システム構成」をクリックします。

3. 「検索」ボックスに「ユーザー名の生成に関するデフォルト・ポリシー」と入力し、「検索」をクリックします。

4. 「ユーザー名の生成に関するデフォルト・ポリシー」をクリックします。

5. 「値」フィールドで、エントリをoracle.iam.identity.usermgmt.impl.plugins.DefaultComboPolicyからoracle.iam.identity.usermgmt.impl.plugins.FirstNameLastNamePolicyForADに更新します。

6. 「保存」をクリックします。

12.21.2 Active DirectoryをサポートするためのOracle Identity Managerのプロパティの変更

最初にインストールした時点で、Oracle Identity Managerには、その操作に必要な一連のデフォルト・システム・プロパティがあります。

アイデンティティ・ストアがActive Directoryに存在する場合は、システム・プロパティXL.DefaultUserNamePolicyImplをoracle.iam.identity.usermgmt.impl.plugins.FirstNameLastNamePolicyForADまたはoracle.iam.identity.usermgmt.impl.plugins.LastNameFirstNamePolicyForADに変更する必要があります。

その方法の詳細は、『Oracle Fusion Middleware Oracle Identity Manager管理者ガイド』のシステム・プロパティの管理に関する項を参照してください。

12.22 Oracle Identity Managerのバックアップ

この時点で、Oracle Identity Managerの構成をバックアップします。第17.6.3項「インストール時および構成時のバックアップの実行」で説明されているように、データベース、WebLogicドメインおよびLDAPディレクトリをバックアップします。

12.23 Oracle Identity ManagerとOracle Access Management Access Managerの統合

この項では、Oracle Identity ManagerとOracle Access Management Access Managerの統合方法について説明します。

この項には次のトピックが含まれます:

- 第12.23.1項「前提条件」

- 第12.23.2項「OAMログイン・ページへの「パスワードを忘れた場合」リンクの追加」

- 第12.23.3項「IDMHOST1およびIDMHOST2へのOAMキーストア・ファイルのコピー」

- 第12.23.4項「idmConfigToolを使用したOracle Identity ManagerとOracle Access Managerの統合」

- 第12.23.5項「必須オブジェクト・クラスによる既存のLDAPユーザーの更新」

- 第12.23.6項「TAP認証スキームの更新」

- 第12.23.7項「xelsysadmユーザーのパスワードの管理」

- 第12.23.8項「統合の検証」

12.23.1 前提条件

1. 第12章「Oracle Identity Managerを追加するためのドメインの拡張」の説明に従ってOIM11gのインストールと構成が行われていることを確認します。

2. 第11章「Oracle Access Managementを追加するためのドメインの拡張」の説明に従ってOracle Access Managementのインストールと構成が行われていることを確認します。

3. 第10.2.3項「Oracle HTTP Serverのインストール」の説明に従ってOHSのインストールと構成が行われていることを確認します。

12.23.2 OAMログイン・ページへの「パスワードを忘れた場合」リンクの追加

第11.6.3項「IDM構成ツールを使用したAccess Managerの構成」でパラメータOAM11G_OIM_INTEGRATION_REQをtrueに設定してidmConfigToolを実行した場合、この手順はスキップできます。

OAM11G_INTEGRATION_FLAGをfalseに設定してこのコマンドを実行した場合は、OAM11G_OIM_INTEGRATION_REQをtrueに設定し、OAM11G_OIM_OHS_URLに値を指定してこのコマンドを再実行する必要があります。

12.23.3 IDMHOST1およびIDMHOST2へのOAMキーストア・ファイルのコピー

Access Managerをシンプル・セキュリティ・トランスポートで使用している場合は、第11.11項「Access Managerと他のコンポーネントを統合するための単一のキーストアの作成」で生成したOAMキーストア・ファイルをIDMHOST1およびIDMHOST2にコピーする必要があります。キーストア・ファイルssoKeystore.jksおよびoamclient-truststore.jksを、IDMHOST1およびIDMHOST2のMSERVER_HOME/config/fmwconfigにコピーします。

12.23.4 idmConfigToolを使用したOracle Identity ManagerとOracle Access Managerの統合

Webゲート・プロファイルを使用したOracle Identity ManagerとAccess Managerの統合では、Access Manager Trusted Authentication Protocol (TAP)スキームを利用します。これは以前のリリースとは異なる点です。以前のリリースでは、Network Assertion Protocol (NAP)を使用していました。

Access ManagerとOracle Identity Managerを統合するには、IDMHOST1で次の手順を実行します。

1. MW_HOMEをIAM_MW_HOMEに設定します。
ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。

JAVA_HOMEをJAVA_HOMEに設定します。

2. oimitg.propsという統合用のプロパティ・ファイルを、次の内容で作成します。

LOGINURI: /${app.context}/adfAuthentication
LOGOUTURI: /oamsso/logout.html
AUTOLOGINURI: None
ACCESS_SERVER_HOST: IDMHOST1.mycompany.com
ACCESS_SERVER_PORT: 5575
ACCESS_GATE_ID: Webgate_IDM
COOKIE_DOMAIN: .mycompany.com
COOKIE_EXPIRY_INTERVAL: 120
OAM_TRANSFER_MODE: simple
WEBGATE_TYPE: ohsWebgate11g
SSO_ENABLED_FLAG: true
IDSTORE_PORT: 389
IDSTORE_HOST: IDSTORE.mycompany.com
IDSTORE_DIRECTORYTYPE: OUD, OID or OVD
IDSTORE_ADMIN_USER: cn=oamLDAP,cn=systemids,dc=mycompany,dc=com
IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com
IDSTORE_LOGINATTRIBUTE: uid
MDS_DB_URL: jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(FAILOVER=on)(ADDRESS_LIST=(ADDRESS=(protocol=tcp)(host=IDMDBHOST1-VIP.mycompany.com)(port=1521))(ADDRESS=(protocol=tcp)(host=IDMDBHOST2-VIP.mycompany.com)(port=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=OIMEDG.mycompany.com)))
MDS_DB_SCHEMA_USERNAME: EDG_MDS
OIM_MANAGED_SERVER_NAME: WLS_OIM1
WLSADMIN: weblogic
WLSPORT: 7001
WLSHOST: ADMINVHN.mycompany.com
DOMAIN_NAME: IDMDomain
DOMAIN_LOCATION: ASERVER_HOME

ここで:

- ACCESS_SERVER_PORTはアクセス・サーバーのプロキシ・ポートです。これは、第B.3項のOAM_PROXY_PORTに相当します。

- OAM_TRANSFER_MODEは、簡易モードを使用してリクエストを受け入れるようにアクセス・マネージャ・サーバーが構成されている場合、simpleに設定します。それ以外の場合は、OAM_TRANSFER_MODEをopenに設定します。

- SSO_ENABLED_FLAGは常にtrueに設定します。

- WEBGATE_TYPEは、作成するWebゲート・エージェントのタイプです。有効な値はohsWebgate11gおよびohsWebgate10です。

- IDSTORE_HOSTは、アイデンティティ・ストアからの接続を受け付けるロード・バランサの仮想ホストです(LDAP_LBR_HOST)。

- IDSTORE_PORTは、アイデンティティ・ストアからの接続を受け付けるロード・バランサの仮想ポートです(LDAP_LBR_PORT)。

- IDSTORE_DIRECTORYTYPEは、Oracle Virtual Directoryを使用してOID以外のディレクトリまたはOracle Internet Directoryのいずれかに接続する場合にOVDに設定します。アイデンティティ・ストアがOracle Internet Directory内にある場合はOIDに設定します。Oracle Unified Directoryに接続する場合はOUDに設定します。

- IDSTORE_USERSEARCHBASEは、ユーザーが格納されるディレクトリの場所です。

- IDSTORE_GROUPSEARCHBASEは、グループが格納されるディレクトリの場所です。

- IDSTORE_LOGINATTRIBUTEは、ユーザーのログイン名を記述したLDAP属性です。

- MDS_DB_URLには、データベースのJDBC接続情報を次の形式で格納します: jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(FAILOVER=on)(ADDRESS_LIST=(ADDRESS=(protocol=tcp)(host=IDMDBHOST1-VIP.mycompany.com)(port=1521))(ADDRESS=(protocol=tcp)(host=IDMDBHOST2-VIP.mycompany.com)(port=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=OIMEDG.mycompany.com)))、ここで1521は第B.3項のDB_LSNR_PORTに相当します。

- MDS_DB_SCHEMA_USERNAMEは、MDSデータが格納されるアイデンティティ管理データベースのスキーマの名前です。第6.6項「RCUを使用したOracle RAC DatabaseへのIdentity Managementスキーマのロード」を参照してください。

- OIM_MANAGED_SERVER_NAMEは、いずれかのOIM管理対象サーバーの名前です。いずれを使用しても問題ありません。

- WLSHOST (ADMINVHN)は管理サーバーのホストであり、第B.3項のWLS_ADMIN_HOSTに相当します。これは仮想名です。

- WLSPORTは管理サーバーのポートであり、第B.3項のWLS_ADMIN_PORTに相当します。

- WLSADMINは、WebLogicコンソールへのログインで使用するWebLogic管理ユーザーです。

- DOMAIN_NAMEは、Oracle Identity Managerをホストするドメインの名前です。

- DOMAIN_LOCATIONは、ディスク上でのドメインのパス、つまりASERVER_HOMEです。

3. 次の場所にあるコマンドidmConfigToolを使用して、Access ManagerとOracle Identity Managerを統合します。

IAM_ORACLE_HOME/idmtools/bin

注意:

idmConfigToolを実行すると、idmDomainConfig.paramファイルが作成されるか、既存のこのファイルに情報が追加されます。このファイルは、idmConfigToolを実行したディレクトリに作成されます。このツールを実行するたびに同じファイルに情報が追加されるようにするには、必ず次のディレクトリでidmConfigToolを実行します。

IAM_ORACLE_HOME/idmtools/bin

このコマンドの構文は次のとおりです。

idmConfigTool.sh -configOIM input_file=configfile

例:

IAM_ORACLE_HOME/idmtools/bin/idmConfigTool.sh -configOIM input_file=oimitg.props

スクリプトを実行すると、次の情報を求められます。

- アクセス・ゲートのパスワード

- SSOキーストアのパスワード

- グローバル・パスフレーズ

- Idstore管理パスワード

- MDSデータベース・スキーマのパスワード

- 管理サーバーのユーザー・パスワード

出力例:

Enter sso access gate password :
Enter sso keystore jks password :
Enter sso global passphrase :
Enter mds db schema password :
Enter idstore admin password :
Enter admin server user password :

********* Seeding OAM Passwds in OIM *********

Completed loading user inputs for - CSF Config

Completed loading user inputs for - Dogwood Admin WLS

Connecting to t3://ADMINVHN.mycompany.com:7001

Connection to domain runtime mbean server established

Seeding credential :SSOAccessKey

Seeding credential :SSOGlobalPP

Seeding credential :SSOKeystoreKey

********* ********* *********

********* Activating OAM Notifications *********

Completed loading user inputs for - MDS DB Config

Apr 3, 2012 11:56:09 PM oracle.mds
NOTIFICATION: PManager instance is created without multitenancy support as JVM flag "oracle.multitenant.enabled" is not set to enable multitenancy support.
Initialized MDS resources

Apr 3, 2012 11:56:09 PM oracle.mds
NOTIFICATION: PManager instance is created without multitenancy support as JVM flag "oracle.multitenant.enabled" is not set to enable multitenancy support.
Apr 3, 2012 11:56:10 PM oracle.mds
NOTIFICATION: transfer operation started.
Apr 3, 2012 11:56:10 PM oracle.mds
NOTIFICATION: transfer is completed. Total number of documents successfully processed : 1, total number of documents failed : 0.
Upload to DB completed

Releasing all resources

Notifications activated.

********* ********* *********

********* Seeding OAM Config in OIM *********

Completed loading user inputs for - OAM Access Config

Validated input values

Initialized MDS resources

Apr 3, 2012 11:56:10 PM oracle.mds
NOTIFICATION: PManager instance is created without multitenancy support as JVM flag "oracle.multitenant.enabled" is not set to enable multitenancy support.
Apr 3, 2012 11:56:10 PM oracle.mds
NOTIFICATION: transfer operation started.
Apr 3, 2012 11:56:10 PM oracle.mds
NOTIFICATION: transfer is completed. Total number of documents successfully processed : 1, total number of documents failed : 0.
Download from DB completed

Releasing all resources

Updated /u01/oracle/products/access/iam/server/oamMetadata/db/oim-config.xml

Initialized MDS resources

Apr 3, 2012 11:56:10 PM oracle.mds
NOTIFICATION: PManager instance is created without multitenancy support as JVM flag "oracle.multitenant.enabled" is not set to enable multitenancy support.
Apr 3, 2012 11:56:10 PM oracle.mds
NOTIFICATION: transfer operation started.
Apr 3, 2012 11:56:10 PM oracle.mds
NOTIFICATION: transfer is completed. Total number of documents successfully processed : 1, total number of documents failed : 0.
Upload to DB completed

Releasing all resources

OAM configuration seeded. Please restart oim server.

********* ********* *********

********* Configuring Authenticators in OIM WLS *********

Completed loading user inputs for - LDAP connection info

Connecting to t3://ADMINVHN.mycompany.com:7001

Connection to domain runtime mbean server established

Starting edit session

Edit session started

Connected to security realm.

Validating provider configuration

Validated desired authentication providers

Created OAMIDAsserter successfuly

OAMIDAsserter is already configured to support 11g webgate

Created OIMSignatureAuthenticator successfuly

Created OVDAuthenticator successfuly

Setting attributes for OVDAuthenticator

All attributes set. Configured inOVDAuthenticatornow

LDAP details configured in OVDAuthenticator

Control flags for authenticators set sucessfully

Reordering of authenticators done sucessfully

Saving the transaction

Transaction saved

Activating the changes

Changes Activated. Edit session ended.

Connection closed sucessfully

********* ********* *********

The tool has completed its operation. Details have been logged to automation.log

注意:

このスクリプトの実行時にすでに第15.3項「WebLogicセキュリティ・プロバイダの構成」の説明に従ってWebLogic管理コンソールでシングル・サインオンを有効にしている場合、実行時に次のエラーが表示されることがあります。

ERROR: Desired authenticators already present. [Ljava.lang.String;@7fdb492]
ERROR: Error occurred while configuration. Authentication providers to be configured already present.
ERROR: Rolling back the operation..

これらのエラーは無視できます。

4. ログ・ファイルを確認し、必要に応じてエラーを修正します。

5. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、管理サーバーを再起動します。

12.23.5 必須オブジェクト・クラスによる既存のLDAPユーザーの更新

既存のLDAPユーザーを、オブジェクト・クラスOblixPersonPwdPolicy、OIMPersonPwdPolicy、およびOblixOrgPersonで更新する必要があります。

注意:

これは、既存のユーザーを持たない新規設定の場合、必要ありません。

1. IDMHOST1で、user.propsという統合用のプロパティ・ファイルを次の内容で作成します。

IDSTORE_HOST: IDSTORE.mycompany.com
IDSTORE_PORT: 389
IDSTORE_ADMIN_USER: cn=oudadmin
IDSTORE_DIRECTORYTYPE: OUD, OID, or OVD
IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com
PASSWORD_EXPIRY_PERIOD: 7300
IDSTORE_LOGINATTRIBUTE: uid

ここで:

- IDSTORE_HOSTはLDAPサーバーの名前です。例:
IDSTORE.mycompany.com

- IDSTORE_PORTはLDAPサーバーのポートです。

- IDSTORE_ADMIN_USERは、管理ユーザーのバインドDNです。例:
cn=orcladminまたはcn=oudadmin

- IDSTORE_DIRECTORYTYPEはディレクトリのタイプです。有効な値はOUD、OIDおよびOVDです。

- IDSTORE_USERSEARCHBASEは、ディレクトリ内でのユーザーの場所です。例:
cn=Users,dc=mycompany,dc=com

- IDSTORE_GROUPSEARCHBASEは、ディレクトリ内でのグループの場所です。例:
cn=Groups,dc=mycompany,dc=com

- IDSTORE_LOGINATTRIBUTEはディレクトリのログイン属性名です。例:
uid

- PASSWORD_EXPIRY_PERIODはパスワードの有効期間です。

2. ORACLE_HOMEをIAM_ORACLE_HOMEに設定します。
MW_HOMEをMW_HOMEに設定します。

JAVA_HOMEをJAVA_HOMEに設定します。

3. IAM_ORACLE_HOME/idmtools/binにあるコマンドidmConfigToolを使用して、既存のLDAPを更新します。

注意:

idmConfigToolを実行すると、idmDomainConfig.paramファイルが作成されるか、既存のこのファイルに情報が追加されます。このファイルは、idmConfigToolを実行したディレクトリに作成されます。このツールを実行するたびに同じファイルに情報が追加されるようにするには、必ず次のディレクトリでidmConfigToolを実行します。

IAM_ORACLE_HOME/idmtools/bin

このコマンドの構文は次のとおりです。

idmConfigTool.sh -upgradeLDAPUsersForSSO input_file=configfile

例:

idmConfigTool.sh -upgradeLDAPUsersForSSO input_file=user.props

アイデンティティ・ストアへの接続で使用するユーザーのパスワードの入力を求められたら、そのパスワードを入力します。

出力例:

Enter IDSTORE_ADMIN_PASSWD :

********* Upgrading LDAP Users With OAM ObjectClasses *********

Completed loading user inputs for - LDAP connection info

Completed loading user inputs for - LDAP Upgrade

Upgrading ldap users at - cn=Users,dc=mycompany,dc=com

Parsing - cn=weblogic_idm,cn=Users,dc=mycompany,dc=com

objectclass OIMPersonPwdPolicy not present in cn=weblogic_idm,cn=Users,dc=mycompany,dc=com. Seeding it

obpasswordexpirydate added in cn=weblogic_idm,cn=Users,dc=mycompany,dc=com

Parsing - cn=oamadmin,cn=Users,dc=mycompany,dc=com

objectclass OIMPersonPwdPolicy not present in cn=oamadmin,cn=Users,dc=mycompany,dc=com. Seeding it

obpasswordexpirydate added in cn=oamadmin,cn=Users,dc=mycompany,dc=com

Finished parsing LDAP

LDAP Users Upgraded.

関連項目:

idmConfigToolコマンドの詳細は、『Oracle Fusion Middleware Oracle Identity Management Suite統合概要』を参照してください。

12.23.6 TAP認証スキームの更新

Oracle Access Management Access ManagerとOracle Identity Managerを統合した後は、LDAP属性uidを使用してユーザー検証を実行するようにTAP認証スキームを更新する必要があります。

次のように実行します。

1. http://ADMIN.mycompany.com/oamconsoleからOAMコンソールにログインします。

2. 「ポリシー構成」をクリックします。

3. 「認証スキーム」の下でTAPResponseOnlySchemeをクリックします。

4. 「開く」をクリックします。

5. 「チャレンジ・パラメータ」フィールドにMatchLDAPAttribute=uidを追加します。

6. 「適用」をクリックします。

7. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、管理サーバーとAccess Managerの管理対象サーバーを再起動します。

12.23.7 xelsysadmユーザーのパスワードの管理

Oracle Identity ManagerとAccess Managerを統合した後は、2つのxelsysadmアカウントが存在します。1つはOracle Identity Managerで作成された内部アカウントです。もう1つは、第9.4項「アイデンティティ・ストアの準備」でアイデンティティ・ストア内に作成したアカウントです。

LDAPストアにあるxelsysadmアカウントは、OIMコンソールへのアクセスに使用するアカウントです。このアカウントのパスワードを変更する場合は、LDAPでこれを変更します。これはODSMを使用して行うことができます。OIMコンソールを介してこれを変更しないでください。

12.23.8 統合の検証

統合を検証するには、第15章「エンタープライズ・デプロイメントにおける管理コンソールのシングル・サインオンの構成」の説明に従って、Identity Management管理者をWebLogicセキュリティ・グループに割り当て、Webゲートをインストールする必要があります。

Access ManagerとOracle Identity Manager 11gが正常に接続されていることを検証するには、次のようにしてOracle Identity Managerセルフ・サービス・コンソールへのログインを試みます。

1. ブラウザを使用して次のアドレスにアクセスします。
https://SSO.mycompany.com/identity

これにより、OAM11gシングル・サインオン・ページにリダイレクトされます。

2. 第9.4項「アイデンティティ・ストアの準備」で作成したxelsysadmユーザー・アカウントを使用してログインします。

3. 「OIMセルフ・サービス・コンソール」ページが表示されれば、統合は成功です。

次の手順に従って追加の検証を実行します。

1. OIMコンソールにxelsysadmユーザーとしてログインします。

2. 新規ユーザーを作成します。

3. xelsysadmユーザーとしてログアウトします。

4. 新しく作成したユーザーでログインします。新規ユーザーであるため、「パスワード管理」ページにリダイレクトされます。

5. 資格証明を入力し、「送信」をクリックします。統合が正しく実行されているならば、アクセスしようとしているページに転送されます。

13 エンタープライズ・デプロイメント用のノード・マネージャの設定

この章では、Oracleのベスト・プラクティスの推奨事項に従ってノード・マネージャを構成する方法を説明します。

この章の構成は、次のとおりです。

- 第13.1項「ノード・マネージャの概要」

- 第13.2項「ノード・マネージャのログの場所の変更」

- 第13.3項「ノード・マネージャのホスト名検証証明書の有効化」

- 第13.4項「ノード・マネージャの起動」

13.1 ノード・マネージャの概要

ノード・マネージャを使用すると、管理サーバーおよび各管理対象サーバーの起動と停止が可能です。

手順

IDMHOST1およびIDMHOST2上で、第2章「導入と計画」で説明されているエンタープライズ・デプロイメント・トポロジの各種コンポーネントに対して、この章に記載されている手順を実行する必要があります。

コンポーネント固有の章に記載されている情報を使用して、VPとIPのペアごとにこの章の手順を繰返し実行する必要があります。

推奨事項

エンタープライズ・デプロイメント・トポロジでのノード・マネージャの構成についての主要な推奨事項は、次の2つです。

1. ノード・マネージャのログ・ファイルをデフォルトの場所(ノード・マネージャが配置されているミドルウェア・ホーム)とは異なる場所に置くことをお薦めします。詳細は、第13.2項「ノード・マネージャのログの場所の変更」を参照してください。

2. また、ノード・マネージャとドメイン内のサーバー間の通信についてホスト名検証を使用することもお薦めします。これには、ドメインで使用される各種アドレスの証明書を使用する必要があります。この章では、ホスト名検証用にホストで証明書を構成する手順について説明します。詳細は、第13.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

注意:

このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字および数字が不規則に連なるパスワードを使用します。

13.2 ノード・マネージャのログの場所の変更

IAM_MW_HOME/wlserver_10.3/common/nodemanager/nodemanager.propertiesにあるノード・マネージャのプロパティ・ファイルを編集します。次の行を使用して、ログ・ファイルの新しい場所を追加します。

LogFile=ORACLE_BASE/config/nodemanager.log

Oracleのベスト・プラクティスは、管理ディレクトリの内部で、MW_HOMEディレクトリの外部である場所を使用することです。

変更を有効にするために、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、ノード・マネージャを再起動します。

13.3 ノード・マネージャのホスト名検証証明書の有効化

この項では、ノード・マネージャと管理サーバーとの通信で使用するホスト名検証証明書を設定する方法について説明します。これには次の手順が含まれます。

- 第13.3.1項「utils.CertGenユーティリティを使用した自己署名証明書の生成」

- 第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」

- 第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」

- 第13.3.4項「カスタム・キーストアを使用するためのノード・マネージャの構成」

- 第13.3.5項「共通または共有記憶域インストールの使用」

- 第13.3.6項「カスタム・キーストアを使用するための管理対象WebLogic Serverの構成」

- 第13.3.7項「管理対象サーバーのホスト名検証設定の変更」

13.3.1 utils.CertGenユーティリティを使用した自己署名証明書の作成

この章で(例として)追加する証明書は、ノード・マネージャが物理ホスト名(HOST.mycompany.com)でリスニングし、WebLogic管理対象サーバーが仮想ホスト名(VIP.mycompany.com)でリスニングする構成に対応します。サーバーが仮想ホスト名を使用している場合は、サーバーを1つのノードから別のノードに移行できることを意味します。したがって、キーストアとトラスト・キーストアを理想的に保持するディレクトリは、フェイルオーバーからアクセス可能な共有記憶域に配置する必要があります。同じノードまたは別のノードで別のホスト名を使用する場合は、この例の手順を次のように拡張する必要があります。

1. 証明書ストアに必要なホスト名を追加します(必要なホスト名がHOST.mycompany.comおよびVIP.mycompany.comと異なる場合)。

2. アイデンティティ・ストアおよびトラスト・ストアの場所に関する情報を、ノード・マネージャ(ノード・マネージャで別のホスト名を使用する場合)またはサーバー(管理対象サーバーで別のホスト名を使用する場合)で変更します。

次の手順に従って、HOSTに自己署名証明書を作成します。これらの証明書はネットワーク名または別名を使用して作成する必要があります。かわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。次の例では、HOST.mycompany.comとVIP.mycompany.comの証明書を構成します。すなわち、HOSTで物理ホスト名(HOST)と仮想ホスト名(VIP)の両方を使用することを想定しています。また、HOST.mycompany.comはノード・マネージャが使用するアドレスであり、VIP.mycompany.comは管理対象サーバーまたは管理サーバーが使用するアドレスであることも想定しています。これは、管理サーバーとFusion Middlewareコンポーネントをホストするノードや、共存する2つの管理対象サーバーの一方が物理ホスト名をリスニングし、もう一方が仮想ホスト名を使用(移行サーバーを使用するサーバーの場合)するノードで、よく見られる状況です。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して、環境を設定します。Bourneシェルで、次のコマンドを実行します。

cd WL_HOME/server/bin
. ./setWLSEnv.sh

CLASSPATH環境変数が設定されていることを確認します。

echo $CLASSPATH

2. 証明書用のユーザー定義ディレクトリを作成します。たとえば、ASERVER_HOMEディレクトリの下にcertsというディレクトリを作成します。証明書はWebLogicドメイン間で共有できることに注意してください。

cd ASERVER_HOME
mkdir certs

注意:

サーバーが(手動またはサーバーの移行により)フェイルオーバーした際にフェイルオーバー・ノードから適切な証明書にアクセスできるように、キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセス可能な共有記憶域に存在している必要があります。各種目的(HTTPの起動用のSSL設定など)で使用する証明書には、中央ストアまたは共有ストアを使用することをお薦めします。

3. ディレクトリを今しがた作成したディレクトリに変更します。

cd certs

4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、HOST.mycompany.comおよびVIP.mycompany.comの両方に対する証明書を作成します。

構文(すべて1行に記述):

java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name
[export | domestic] [Host_Name]

次に例を示します。

java utils.CertGen Key_Passphrase IDMHOST1.mycompany.com_cert IDMHOST1.mycompany.com_key domestic IDMHOST1.mycompany.com

java utils.CertGen Key_Passphrase IDMHOST2.mycompany.com_cert IDMHOST2.mycompany.com_key domestic IDMHOST2.mycompany.com

java utils.CertGen Key_Passphrase ADMINVHN.mycompany.com_cert ADMINVHN.mycompany.com_key domestic ADMINVHN.mycompany.com

13.3.2 utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成

次の手順に従って、IDMHOST1にアイデンティティ・キーストアを作成します。

1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreというIDキーストアを新しく作成します。このキーストアの作成場所は、証明書と同じディレクトリ(ASERVER_HOME/certs)とします。

注意:

アイデンティティ・ストアは、utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をインポートすることで作成されます(存在していない場合)。

2. IDMHOST1.mycompany.com、IDMHOST2.mycompany.comおよびADMINVHN.mycompany.comの証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。
構文(すべて1行に記述):

java utils.ImportPrivateKey Keystore_File Keystore_Password
Certificate_Alias_to_Use Private_Key_Passphrase
Certificate_File
Private_Key_File
[Keystore_Type]

次に例を示します。

java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityIDMHOST1 Key_Passphrase ASERVER_HOME/certs/IDMHOST1.mycompany.com_cert.pem ASERVER_HOME/certs/IDMHOST1.mycompany.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityIDMHOST2 Key_Passphrase ASERVER_HOME/certs/IDMHOST2.mycompany.com_cert.pem ASERVER_HOME/certs/IDMHOST2.mycompany.com_key.pem

java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityADMINVHN Key_Passphrase ASERVER_HOME/certs/ADMINVHN.mycompany.com_cert.pem ASERVER_HOME/certs/ADMINVHN.mycompany.com_key.pem

13.3.3 keytoolユーティリティを使用したトラスト・キーストアの作成

次の手順に従って、IDMHOST1やIDMHOST2などの各ホストにトラスト・キーストアを作成します。

1. 新しいトラスト・キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在しているからです。標準のJavaトラスト・キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリにある標準のJavaキーストアCA証明書を、証明書が存在するディレクトリにコピーします。例:

cp WL_HOME/server/lib/cacerts ASERVER_HOME/certs/appTrustKeyStoreIDMHOST1.jks

2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。常にデフォルトのパスワードを変更することをお薦めします。それには、keytoolユーティリティを使用します。次に構文を示します。

keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password

例:

keytool -storepasswd -new Key_Passphrase -keystore appTrustKeyStoreIDMHOST1.jks -storepass changeit

3. このCA証明書(CertGenCA.der)は、utils.CertGenツールで生成するすべての証明書の署名に使用します。これは、WL_HOME/server/libディレクトリにあります。keytoolユーティリティを使用して、このCA証明書をappTrustKeyStoreにインポートする必要があります。次に構文を示します。

keytool -import -v -noprompt -trustcacerts -alias Alias_Name
-file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password

例:

keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStoreIDMHOST1.jks -storepass Key_Passphrase

13.3.4 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成するには、WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity_Keystore
CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password
CustomIdentityAlias=Identity_Keystore_Alias
CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate

例:

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ASERVER_HOME/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=Key_Passphrase
CustomIdentityAlias=appIdentityIDMHOST1
CustomIdentityPrivateKeyPassPhrase=Key_Passphrase

第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。このファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。

13.3.5 共通または共有記憶域インストールの使用

共通記憶域または共有記憶域のインストールをMW_HOMEに指定している場合、ノード・マネージャは同じ基本構成(nodemanager.properties)を使用してそれぞれのノードから起動します。第13.3.1項「utils.CertGenユーティリティを使用した自己署名証明書の生成」の説明のとおり、新しいノードの証明書を作成しappIdentityKeyStore.jksにインポートする方法で、バイナリを共有するすべてのノードの証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加します。このストアで証明書が使用できるようになった時点で、各ノード・マネージャはそれぞれのアイデンティティ別名を指定して、正しい証明書を管理サーバーに送信する必要があります。

各ノードでノード・マネージャを起動する前に、該当の環境変数を設定します。

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityIDMHOST1

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityIDMHOST2

注意:

各ホスト固有に割り当てられているカスタムのアイデンティティ別名を必ず指定します。たとえば、...HOST1にはappIdentity1を指定し、...HOST2にはappIdentity2を指定します。

13.3.6 カスタム・キーストアを使用するための管理対象WebLogic Serverの構成

次の手順に従って、WLS_SERVERのIDキーストアとトラスト・キーストアを構成します。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

5. IDキーストアとトラスト・キーストアを構成するサーバー名(WLS_SERVER)をクリックします。選択したサーバーの設定ページが表示されます。

6. 「構成」をクリックし、「キーストア」をクリックします。

7. 「キーストア」フィールドで、秘密鍵とデジタル証明書の組合せおよび信頼できるCA証明書の格納と管理のために「カスタムIDとカスタム信頼」メソッドを選択します。

8. 「ID」セクションで、IDキーストアの次の属性を定義します。

- カスタムIDキーストア: IDキーストアへの完全修飾パス。

ASERVER_HOME/certs/appIdentityKeyStore.jks

- カスタムIDキーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

- カスタムIDキーストアのパスフレーズ: 第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(Keystore_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

9. 「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。

- カスタム信頼キーストア: トラスト・キーストアへの完全修飾パス。

ASERVER_HOME/certs/appTrustKeyStoreIDMHOST1.jks

- カスタム信頼キーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

- カスタム信頼キーストアのパスフレーズ: 第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(New_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、キーストアによっては読取りにパスフレーズが不要な場合もあります。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

10. 「保存」をクリックします。

11. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

12. 「構成」をクリックし、「SSL」をクリックします。

13. 「ロックして編集」をクリックします。

14. 「秘密鍵の別名」フィールドに、管理対象サーバーでリスニングするホスト名に使用した別名を入力します。例:

- WLS_OAM1の場合は、appIdentityIDMHOST1を使用します。

- WLS_OAM2の場合は、appIdentityIDMHOST2を使用します。

- ADMINSERVERの場合は、appIdentityADMINVHNを使用します。

「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。

15. 「保存」をクリックします。

16. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

17. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、変更を適用したサーバーを再起動します。

13.3.7 管理対象サーバーのホスト名検証設定の変更

前述の手順を実行した後、影響を受ける管理対象サーバーのホスト名検証をBEA Hostname Verifierに設定します。このためには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」を選択します。

3. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

5. 表の「名前」列で管理対象サーバーを選択します。選択したサーバーの設定ページが表示されます。

6. 「SSL」タブを開きます。

7. このページの「詳細」セクションを展開します。

8. ホスト名検証をBEA Hostname Verifierに設定します。

9. 「保存」をクリックします。

10. 「変更のアクティブ化」をクリックします。

13.4 ノード・マネージャの起動

次のコマンドを実行してノード・マネージャを起動します。

cd WL_HOME/server/bin
./startNodeManager.sh

注意:

- ノード・マネージャが未構成で、まだ一度も起動していない場合は、第8.5.4項「ノード・マネージャの起動」の説明に従ってsetNMProps.shスクリプトを実行してください。これにより、Identity Managementのコンポーネントで必要な起動スクリプトを使用できるようになります。

- ノード・マネージャの出力にある適切なストアと別名を、そのノード・マネージャで使用していることを確認します。ノード・マネージャの起動時に次の内容が出力されます。

<Loading identity key store:
FileName=ASERVER_HOME/certs/appIdentityKeyStore.jks, Type=jks, PassPhraseUsed=true>

テスト構成の変更を該当のサーバーに適用して、ノード・マネージャからSSLエラーが報告されることなく、それが正常に完了していれば、ホスト名検証は機能しています。

14 エンタープライズ・デプロイメント用のサーバー移行の構成

サーバー移行を構成すると、SOAおよびOIMで管理されているサーバーをあるホストから別のホストに移行できるようになります。これにより、いずれかのサーバーをホストしているノードに障害が発生しても、他のノードでサービスを継続できます。この章では、Identity Managementのエンタープライズ・デプロイメントでサーバー移行を構成する方法について説明します。

この章で説明する手順は次のとおりです。

- 第14.1項「エンタープライズ・デプロイメント用のサーバー移行の概要」

- 第14.2項「サーバー移行leasing表のユーザーと表領域の設定」

- 第14.3項「Oracle WebLogic管理コンソールを使用したLeasingのGridLinkデータ・ソースの作成」

- 第14.4項「ノード・マネージャのプロパティ・ファイルの編集」

- 第14.5項「wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定」

- 第14.6項「サーバー移行ターゲットの構成」

- 第14.7項「サーバー移行のテスト」

- 第14.8項「サーバー移行構成のバックアップ」

14.1 エンタープライズ・デプロイメント用のサーバー移行の概要

WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2の各管理対象サーバーのサーバー移行を構成します。管理対象サーバーWLS_OIM1およびWLS_SOA1は、障害発生時にIDMHOST2上で再起動されるように構成されます。管理対象サーバーWLS_OIM2およびWLS_SOA2は、障害発生時にIDMHOST1上で再起動されるように構成されます。WLS_OIM1、WLS_SOA1、WLS_OIM2、およびWLS_SOA2サーバーは、WebLogicサーバー移行によってフェイルオーバーされる特定の浮動IPをリスニングします。

次の項の手順を実行し、WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2の管理対象サーバーのサーバー移行を構成します。

14.2 サーバー移行leasing表のユーザーと表領域の設定

この項では、サーバー移行leasing表のためのユーザーと表領域を設定します。

注意:

同一ドメイン内の他のサーバーがサーバー移行用にすでに構成されている場合には、同じ表領域とデータ・ソースを使用できます。その場合、データベースleasing用のデータソースおよびマルチ・データソースを再作成する必要はありませんが、サーバー移行で構成されているクラスタを再度ターゲットに設定する必要があります。

1. leasingという表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンして次のコマンドを実行します。

create tablespace leasing
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;

2. leasingという名前のユーザーを作成し、そのユーザーにleasing表領域を割り当てます。

create user leasing identified by password;
grant create table to leasing;
grant create session to leasing;
alter user leasing default tablespace leasing;
alter user leasing quota unlimited on leasing;

3. leasing.ddlスクリプトを使用してleasing表を作成します。

1. 次のいずれかのディレクトリにあるleasing.ddlファイルを、データベース・ノードにコピーします。

WL_HOME/server/db/oracle/817
WL_HOME/server/db/oracle/920

2. leasingユーザーとしてデータベースに接続します。

3. SQL*Plusでleasing.ddlスクリプトを実行します。

@Copy_Location/leasing.ddl;

4. この時点では、変更はまだコミットされていません。ツールの実行が完了したら、SQL*Plusプロンプトに次のように入力します。

commit;

14.3 Oracle WebLogic管理コンソールを使用したLeasingのGridLinkデータ・ソースの作成

この項では、Oracle WebLogic Server管理コンソールでリース表のGridLinkデータ・ソースを作成します。

GridLinkデータ・ソースを作成する手順は次のとおりです。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

- 名前: データ・ソースの論理名を入力します。たとえば、leasingです。

- 「JNDI」: JNDIの名前を入力します。たとえば、jdbc/leasingです。

- データベース・ドライバ: データベース・ドライバには、Oracle Driver (Thin) for GridLink Connections Versions: 11以上を選択します。

- 「次へ」をクリックします。

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

7. 次の接続プロパティを入力します。

- サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。たとえば、OIMEDG.mycompany.comです。

- ホスト名とポート: 使用中のRACデータベースのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。

show parameter remote_listener;

NAME                 TYPE        VALUE

--------------------------------------------------

remote_listener     string      DB-SCAN.mycompany.com:1521

注意:

Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例: DBHOST1-VIP.mycompany.com (ポート1521)およびDBHOST2-VIP.mycompany.com (ポート1521)、ここでの1521はDB_LSNR_PORTです。

Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

- データベース・ユーザー名: leasing。

- パスワード: たとえば、welcome1などを入力します。

- パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。接続が成功したときに表示される通知の一例を示します。

Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=DB-SCAN.mycompany.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=OIMEDG.mycompany.com))) succeeded.

ここでの1521はDB_LSNR_PORTです。

「次へ」をクリックします。

9. 「ONSクライアント構成」ページで、次の手順を実行します。

- 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

- ここにも、データベースから報告されたRACデータベースのSCANアドレスおよびONSリモート・ポートを次のように入力し、「追加」をクリックします。

srvctl config nodeapps -s

ONS exists: Local port 6100, remote port 6200, EM port 2016

- 「次へ」をクリックします。

注意:

Oracle Database 11g リリース1 (11.1)では、次の例のように、各データベースのONSサービスのホスト名とポートを使用します。

DBHOST1.mycompany.com (port 6200)

および

DBHOST2.mycompany.com (port 6200)

10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
接続が成功したときに表示される通知の一例を示します。

Connection test for DB-SCAN.mycompany.com:6200 succeeded.

「次へ」をクリックします。

11. 「ターゲットの選択」ページで、ターゲットとしてoim_clusterおよびsoa_clusterを選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 「変更のアクティブ化」をクリックします。

14.4 ノード・マネージャのプロパティ・ファイルの編集

この項では、ノード・マネージャのプロパティ・ファイルを編集します。この操作は、サーバーが実行されているノード上のノード・マネージャに対して行う必要があります(IDMHOST1およびIDMHOST2)。

nodemanager.propertiesファイルは次のディレクトリにあります。

WL_HOME/common/nodemanager

次のプロパティを追加してサーバー移行が正常に動作するようにします。

- Interface:

Interface=eth0

このプロパティは浮動IP (eth0など)のインタフェース名を指定します。

注意:

eth0:1やeth0:2などのサブインタフェースを指定しないでください。このインスタンスは、:0や:1なしに使用されます。ノード・マネージャのスクリプトでは、異なる:X対応IPを横断して、追加または削除の対象を特定します。たとえば、Linux環境で有効な値は、構成するインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

- NetMask:

NetMask=255.255.255.0

このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。このネット・マスクは、インタフェースのネット・マスクと同じにする必要があります。

- UseMACBroadcast:

UseMACBroadcast=true

このプロパティは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、言い換えれば、arpingコマンドで-bフラグを使用するかどうかを指定します。

これらのプロパティが使用されているか、または移行中に問題が発生していないかを、ノード・マネージャの出力(ノード・マネージャが起動されているシェル)で確認します。ノード・マネージャの出力は、次のように表示されます。

StateCheckInterval=500
eth0=*,NetMask=255.255.255.0
UseMACBroadcast=true

注意:

サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

1. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

2. WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行し、IDMHOST1とIDMHOST2でノード・マネージャを起動します。

注意:

共有記憶域インストールからノード・マネージャを実行する場合、同じnodemanager.propertiesファイルを使用して複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個々のパラメータを指定します。たとえば、HOSTnで別のインタフェース(eth3)を使用するには、Interface環境変数を次のように使用します。

export JAVA_OPTIONS=-DInterface=eth3

この変数がシェル内で設定された後、ノード・マネージャを起動します。

14.5 wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定

Linuxでは、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。

表14-1に一覧表示されているファイルがPATH環境変数に含まれていることを確認します。

表14-1 PATH環境変数に必要なファイル

ファイル

ディレクトリの場所

wlsifconfig.sh

MSERVER_HOME/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

WL_HOME/common/nodemanager

パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

セキュリティ上の理由から、sudoを、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定するには、次の手順を実行します。

注意:

この手順の実行に適するsudo権限とシステム権限については、システム管理者に問い合せてください。

スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。

パスワードによる制限を設けずにsudo権限をWebLogicユーザー('oracle')に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

14.6 サーバー移行ターゲットの構成

この項では、サーバー移行ターゲットを構成します。クラスタ移行を構成することにより、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。

クラスタ内の移行を構成する手順は次のとおりです。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

3. 表の「名前」列で、移行を構成するクラスタ(oim_cluster)をクリックします。

4. 「移行」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行先として許可するマシン(IDMHOST1およびIDMHOST2)を選択して、右向き矢印をクリックします。

7. 自動移行に使用するデータ・ソースを選択します。この場合は、リース・データ・ソースを選択します。

8. 「保存」をクリックします。

9. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

10. 移行を構成するサーバーを選択します。

11. 「移行」タブをクリックします。

12. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。

13. 「変更のアクティブ化」をクリックします。

14. SOAクラスタについて手順2 - 13を繰り返します。

15. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバー、ノード・マネージャ、およびサーバー移行を構成したサーバーを再起動します。

14.7 サーバー移行のテスト

この項では、サーバー移行をテストします。サーバーの移行が適切に行われていることを確認するには次の手順を実行します。

IDMHOST1からテストするには:

1. WLS_OIM1管理対象サーバーを停止します。これには、次のコマンドを実行します。

kill -9 pid

pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノードのPIDを識別できます。

ps -ef | grep WLS_OIM1

2. ノード・マネージャのコンソールを確認します。WLS_OIM1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_OIM1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャによってログに記録されます。

IDMHOST2からテストするには:

1. ローカルのノード・マネージャ・コンソールを確認します。IDMHOST1でWLS_OIM1の再起動が最後に試行されてから30秒経過した後、IDMHOST2のノード・マネージャによって、WLS_OIM1の浮動IPが有効化されていること、およびこのノードでサーバーが再起動されていることが表示されます。

2. 仮想ホスト名を使用してOIMコンソールにアクセスします。例: http://OIMHOST1VHN.mycompany.com:14000/identity

前述の手順に従い、管理対象サーバーWLS_OIM2、WLS_SOA1およびWLS_SOA2に対してサーバーの移行をテストします。

表14-2は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。

表14-2 管理対象サーバーの移行

管理対象サーバー

移行元

移行先

WLS_OIM1

IDMHOST1

IDMHOST2

WLS_OIM2

IDMHOST2

IDMHOST1

WLS_SOA1

IDMHOST1

IDMHOST2

WLS_SOA2

IDMHOST2

IDMHOST1

管理コンソールでの確認

移行は管理コンソールで確認することもできます。

1. 管理コンソールにログインします。

2. 左側のペインでIDMDomainをクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

14.8 サーバー移行構成のバックアップ

第17.6.3項「インストール時および構成時のバックアップの実行」の説明に従って、データベースとWebLogicドメインをバックアップします。

15 エンタープライズ・デプロイメントにおける管理コンソールのシングル・サインオンの構成

この章では、Identity Managementのエンタープライズ・デプロイメントにおいて管理コンソールのシングル・サインオン(SSO)を構成する方法について説明します。

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

- 第15.1項「エンタープライズ・デプロイメントにおける管理コンソールのシングル・サインオンの構成の概要」

- 第15.2項「前提条件」

- 第15.3項「WebLogicセキュリティ・プロバイダの構成」

- 第15.4項「WebLogic管理グループへのWLSAdminsグループの割当て」

- 第15.5項「Access Manager管理者によるAPMコンソールへのアクセスの認可」

- 第15.6項「boot.propertiesファイルの更新」

- 第15.7項「Webゲート11gのインストールと構成」

- 第15.8項「WebゲートおよびAccess Managerのシングル・サインオンのセットアップの検証」

- 第15.9項「シングル・サインオンのバックアップ」

15.1 エンタープライズ・デプロイメントにおける管理コンソールのシングル・サインオンの構成の概要

Oracle Access Management Access ManagerとOracle Identity Managerを統合していない場合、最初にWebLogicセキュリティ・プロバイダを作成する必要があります。次のように実行します。

WebLogic管理グループを割り当て、boot.propertiesを更新し、サーバーを再起動します。次にWebゲートのインストールと構成を行い、セットアップを検証します。Webゲートのインストールと構成が完了すると、Oracle HTTP Serverはコンソールのリクエストをインターセプトし、検証のためにAccess Managerに転送します。

章タイトルでの管理コンソールは次を指します。

- Oracle Enterprise Manager Fusion Middleware Control

- Oracle WebLogic Server管理コンソール

- Oracle Access Managementコンソール

- Oracle Identity Managerコンソール

15.2 前提条件

管理コンソールをシングル・サインオンと統合する前に、IDMDomainで次のタスクが完了していることを確認してください。

1. 第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」の説明に従ってOracle HTTP Serverを構成します。

2. 第11章「Oracle Access Managementを追加するためのドメインの拡張」の説明に従ってAccess Managerを構成します。

3. 第9.4項「アイデンティティ・ストアの準備」の説明に従って、LDAP内でWeblogic管理者をプロビジョニングします。

15.3 WebLogicセキュリティ・プロバイダの構成

configOAMオプションまたはconfigOIMオプションを指定してidmConfigToolを実行すると、ドメインIDMDomainおよびOIMDomainにセキュリティ・プロバイダが作成されます。これらのセキュリティ・プロバイダは、Access Managerのセキュリティ・ポリシーに基づいて、これらのドメイン内のコンソールへのアクセスを制限します。他のドメインがある場合は、それらのドメイン内に手動でセキュリティ・プロバイダを作成し、次の項の説明に従ってそれらのセキュリティ・プロバイダを更新する必要があります。

注意:

管理コンソールに対するシングル・サインオンを有効にしたら、コンソール・アクセスを可能にするために、1つ以上のOAMサーバーが稼働していることを確認してください。

Oracle WebLogicコンソールを使用してすべてのAccess Manager管理対象サーバーを停止した場合は、コンソールを再び使用する前に、これらの管理対象サーバーのいずれかを手動で再起動してください。

WLS_OAM1を手動で起動するには、次のコマンドを使用します。

MSERVER_HOME/bin/startManagedWeblogic.sh WLS_OAM1 t3://ADMINVHN:7001

この項では、セキュリティ・プロバイダを更新して管理コンソールへのシングル・サインオン・アクセスを可能にする方法について説明します。この項は、セキュリティ・プロバイダが存在するすべてのドメインで実行する必要があります(手動で作成されたセキュリティ・プロバイダを持つ補助ドメインも含む)。

この項には次のトピックが含まれます:

- 第15.3.1項「Oracle Unified Directoryオーセンティケータの更新」

- 第15.3.2項「セキュリティ・プロバイダの並び替え」

15.3.1 Oracle Unified Directoryオーセンティケータの更新

OUDオーセンティケータの作成時に一部の情報が不足しているため、それらを追加する必要があります。OUDをアイデンティティ・ストアとして使用する場合は、次の手順を実行してそれらの情報を追加する必要があります。

1. WebLogic管理コンソールにログインします。

2. 「ドメイン」構造メニューで「セキュリティ・レルム」をクリックします。

3. 「チェンジ・センター」で「ロックして編集」をクリックします。

4. myrealmをクリックします。

5. 「プロバイダ」をクリックします。

6. OUDAuthenticatorをクリックします。

7. 「プロバイダ固有」タブをクリックします。

8. 「プロバイダ固有」画面で次の値を更新します。

- すべてのユーザーのフィルタ: (&(uid=*)(objectclass=person))

- 名前指定によるユーザー・フィルタ: (&(uid=%u)(objectclass=person))

- ユーザー名属性: uid

- 静的グループ・オブジェクト・クラス: groupofuniquenames

- 静的メンバーDN属性: uniquemember

- メンバーDN指定による静的グループDNフィルタ: (&(uniquemember=%M)(objectclass=groupofuniquenames))

- 動的グループ名属性: cn

- 動的グループ・オブジェクト・クラス: groupOfURLs

- 動的メンバーURL属性: memberURL

9. 「保存」をクリックします。

10. 「変更のアクティブ化」をクリックします。

15.3.2 セキュリティ・プロバイダの並び替え

この項では、Access Managerアサーション・プロバイダを設定し、資格証明コレクションの職責をAccess Managerに委任できるようにします。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、WebLogic管理コンソールにログインします。

2. 「ドメイン」構造メニューで「セキュリティ・レルム」をクリックします。

3. 「チェンジ・センター」で「ロックして編集」をクリックします。

4. myrealmをクリックします。

5. 「プロバイダ」タブを選択します。

6. 「並替え」をクリックします。

7. 右側の矢印を使用して、プロバイダを次の順序に並べ替えます。

- OAMIDAsserter

- OIM署名オーセンティケータ(存在する場合)

- OIMAuthenticationProvider(存在する場合)

- OUD Authenticator、OVDAuthenticatorまたはOIDAuthenticator

- デフォルトのオーセンティケータ

- デフォルトのIDアサーション・プロバイダ

注意:

Oracle Identity Managerプロバイダは、Oracle Identity Managerが構成されている場合にのみ存在します。

8. 「OK」をクリックします。

9. 「変更のアクティブ化」をクリックします。

10. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーとすべての管理対象サーバーを再起動します。

15.4 WebLogic管理グループへのWLSAdminsグループの割当て

企業では、すべてのユーザー、グループおよびロールがプロビジョニングされる中央のアイデンティティ管理ドメインと、複数のアプリケーション・ドメイン(SOAドメインやWebCenter Portalドメインなど)を配置することが一般的です。これらのアプリケーション・ドメインは、中央のアイデンティティ管理ドメインを使用して認証するように構成されます。

第9.4項「アイデンティティ・ストアの準備」では、weblogic_idmという名前のユーザーを作成し、グループWLSAdminsに割り当てました。このアカウントを使用してWebLogicを管理できるようにするには、WLSAdminsグループをWebLogic管理グループのリストに追加する必要があります。この項では、WLSAdminsグループをWebLogic管理者のリストに追加する方法を説明します。

トポロジ内の各ドメインに対して次の手順を実行します。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、WebLogic管理サーバー・コンソールにログインします。

2. コンソールの左側のペインで、「セキュリティ・レルム」をクリックします。

3. 「セキュリティ・レルムのサマリー」ページで、「レルム」表のmyrealmをクリックします。

4. myrealmの「設定」ページで、「ロールとポリシー」タブをクリックします。

5. 「レルム・ロール」ページで、「ロール」表の「グローバル・ロール」エントリを開きます。これにより、ロールのエントリが表示されます。「ロール」リンクをクリックして、「グローバル・ロール」ページに移動します。

6. 「グローバル・ロール」ページで、「管理」ロールをクリックして「グローバル・ロールの編集」ページに移動します。

1. 「グローバル・ロールの編集」ページで、「ロール条件」表の「条件の追加」ボタンをクリックします。

2. 「述部の選択」ページで、述部のリストから「グループ」を選択して、「次へ」をクリックします。

3. 「引数の編集」ページのグループ引数フィールドにWLSAdminsを指定し、「追加」をクリックします。

7. 「終了」をクリックして「グローバル・ロールの編集」ページに戻ります。

8. これで、「ロール条件」の表にWLSAdminsのエントリが表示されるようになります。

9. 「保存」をクリックして、WLSAdminsグループへの管理ロールの追加を終了します。

10. Webブラウザを使用してWebLogic管理サーバー・コンソールを起動して、これらの変更が正常に加えられたことを確認します。weblogic_idmユーザーの資格証明を使用してログインします。

15.5 Access Manager管理者によるAPMコンソールへのアクセスの認可

デフォルトでは、WebLogic管理者グループに属するユーザーのみがAPMコンソールにアクセスできます。SSOを有効にした後は、Access Manager管理者としてログインすることになります。

この機能を有効にするには、次の手順を実行します。

1. APMコンソール(http://ADMIN.mycompany.com/apm)にWebLogic管理者としてログインします。

2. 「システム構成」タブをクリックします。

3. 「外部ロール・マッピング」ボックスの「追加」をクリックします。

4. 「検索」をクリックします。

5. 返された検索結果の中からOAMAdministratorsを選択します。

6. 「選択済の追加」をクリックします。

7. 「プリンシパルの追加」をクリックします。

15.6 boot.propertiesファイルの更新

管理サーバーのboot.propertiesファイルを更新し、LDAP内に作成したWebLogicのadminユーザーを指定します。

すべての管理サーバー・ノードのboot.propertiesを更新する必要があります。ファイルを更新するには、次の項の手順を実行します。

この項には次のトピックが含まれます:

- 第15.6.1項「すべてのドメインの管理サーバーの更新」

- 第15.6.2項「サーバーの再起動」

15.6.1 すべてのドメインの管理サーバーの更新

1. トポロジ内の各サーバーで、次のディレクトリに移動します。

ASERVER_HOME/servers/serverName/security

例:

cd ASERVER_HOME/servers/AdminServer/security

2. 既存のboot.propertiesファイルを別の名前に変更します。

3. テキスト・エディタを使用して、boot.propertiesという名前のファイルをsecurityディレクトリ内に作成します。次の行をこのファイルに入力します。

username=adminUser
password=adminUserPassword

例:

username=weblogic_idm
password=Password for weblogic_idm user

注意:

管理サーバーを起動すると、このファイル内のユーザー名とパスワードのエントリが暗号化されます。

セキュリティ上の理由で、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。このファイルを編集した後、できるだけ早くサーバーを起動して、これらのエントリを暗号化する必要があります。

15.6.2 サーバーの再起動

第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーとすべての管理対象サーバーを再起動します。

15.7 Webゲート11gのインストールと構成

この項では、Webゲートのインストールと構成について説明します。

この項には次のトピックが含まれます:

- 第15.7.1項「前提条件」

- 第15.7.2項「WEBHOST1およびWEBHOST2へのOracle WebGateのインストール」

15.7.1 前提条件

Oracle Web Gateをインストールする前に、次のタスクが完了していることを確認してください。

1. 第10章の説明に従って、Oracle Web層のインストールと構成を行います。

2. 第11章の説明に従って、Oracle Access Management Access Managerが構成されていることを確認します。

15.7.2 WEBHOST1およびWEBHOST2へのOracle WebGateのインストール

インストーラを起動する前に、マシンにJavaがインストールされていることを確認してください。

1. 次のコマンドを実行して、Webゲートのインストーラを起動します。

./runInstaller

Java Development Kitの場所を指定するように求められます。例:

WEB_MW_HOME/jrockit_version

2. 「ようこそ」画面で「次へ」をクリックします。

3. 「前提条件」画面ですべてのチェックが正常に完了したら、「次へ」をクリックします。

4. 「インストール場所」画面で、次の情報を入力します。

- Oracleミドルウェア・ホーム: WEB_MW_HOME

- Oracleホーム・ディレクトリ: webgate

「次へ」をクリックします。

5. 「インストール・サマリー」画面で、「インストール」をクリックします。

6. 「次へ」をクリックします。

7. 「終了」をクリックします。

次のように、WebゲートをOracle HTTPにデプロイします。

1. コマンドdeployWebGateInstance.shを実行します。このコマンドは次の場所にあります。
WEBGATE_ORACLE_HOME/webgate/ohs/tools/deployWebGate

このコマンドでは次の引数を使用します。

Oracle HTTPのインスタンス構成ディレクトリ

Webゲートのホーム・ディレクトリ

例:

./deployWebGateInstance.sh -w WEB_ORACLE_INSTANCE/config/OHS/component_name -oh WEBGATE_ORACLE_HOME

2. ライブラリのパスを設定し、ディレクトリを変更します。
Linuxシステムでは、ライブラリのパスにWEB_ORACLE_HOME/libディレクトリを含めるようにします。例:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:WEB_ORACLE_HOME/lib

ディレクトリを変更します。

ディレクトリの変更先: WEBGATE_ORACLE_HOME/webgate/ohs/tools/setup/InstallTools

3. 次のコマンドを実行して、Webゲートのホーム・ディレクトリからWebゲートのインスタンスの場所にファイルapache_WebGate.templateをコピーし(名前がwebgate.confに変更されます)、httpd.confファイルを更新してwebgate.confの名前が含まれる1つの行を追加します。

./EditHttpConf -w WEB_ORACLE_INSTANCE/config/OHS/component_name -oh WEBGATE_ORACLE_HOME

4. ファイルObAccessClient.xml、cwallet.ssoおよびpassword.xml(これらのファイルはIDMHOST1でディレクトリASERVER_HOME/output/Webgate_IDM_11gからエージェントを作成したときに生成されたものです)を、ディレクトリWEB_ORACLE_INSTANCE/config/OHS/component_name/webgate/configにコピーします。

5. ファイルaaa_key.pemおよびaaa_cert.pemは、IDMHOST1でディレクトリASERVER_HOME/output/Webgate_IDM_11gからエージェントを作成したときに生成されたものです。これらのファイルaaa_key.pemおよびaaa_cert.pemを、Webゲート・インスタンスのディレクトリWEB_ORACLE_INSTANCE/config/OHS/component_name/webgate/config/simpleにコピーします。

6. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを再起動します。

15.8 WebゲートおよびAccess Managerのシングル・サインオンのセットアップの検証

Webゲートが正しく機能していることを検証するには、Webブラウザを開き、第17.2項「Identity ManagementコンソールのURLについて」に記載されているOAMコンソールのURLにアクセスします。

Oracle Access Managementのログイン・ページが表示されます。OAM管理者ユーザー名(oamadminなど)とパスワードを入力し、「ログイン」をクリックします。Oracle Access Managementコンソールが表示されます。

シングル・サインオンの設定を検証するには、Webブラウザを開き、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogic管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにアクセスします。

「Oracle Access Managementのシングル・サインオン」ページが表示されます。weblogic_idmユーザーの資格証明を入力してログインします。

15.9 シングル・サインオンのバックアップ

第17.6.3項「インストール時および構成時のバックアップの実行」の説明に従って、Web層とWebLogicドメインをバックアップします。

16 分割ドメイン・トポロジの作成

この章では、分割ドメイン・トポロジの展開に必要な追加手順および手順変更について説明します。

この章では、次の項目について説明します。

- 第16.1項「分割ドメイン・トポロジの概要」

- 第16.2項「ネットワークに関する追加要件」

- 第16.3項「ファイル・システムの準備に関する追加要件」

- 第16.4項「サーバーの準備に関する追加要件」

- 第16.5項「追加ドメインの作成に関する要件」

- 第16.6項「Web層に関する追加要件」

- 第16.7項「Access Managerに関する追加要件」

- 第16.8項「Oracle Identity Managerに関する追加要件」

- 第16.9項「シングル・サインオンに関する追加要件」

- 第16.10項「ノード・マネージャに関する追加要件」

- 第16.11項「管理に関する追加要件」

16.1 分割ドメイン・トポロジの概要

第2.2.2.3項「アーキテクチャに関する注意」で説明されているように、分割ドメイン構成では、Oracle Identity Managerは他のコンポーネントとは別のドメインにインストールされます。分割ドメイン・トポロジの使用を決定した場合、このガイドに記載されている手順に対していくつかの変更や追加が必要になります。この章では、これらの変更や追加について説明します。

16.2 ネットワークに関する追加要件

分割ドメインの実装では、第3章で説明されているネットワークの準備に加えて次の追加準備を実行します。

この項には次のトピックが含まれます:

- 第16.2.1項「仮想サーバー名」

- 第16.2.2項「ロード・バランサの構成」

- 第16.2.3項「仮想IPアドレス」

- 第16.2.4項「仮想IPアドレスおよび物理IPアドレスをリスニングするためのサーバー構成」

- 第16.2.5項「ファイアウォールとポート」

16.2.1 仮想サーバー名

分割ドメイン・トポロジでは、第3.3項「トポロジで使用する仮想サーバー名について」に記載されている仮想サーバー名に加えて次の追加仮想サーバーが必要になります。

OIMADMIN.mycompany.com

- この仮想サーバーが必要になるのは、分割ドメイン・トポロジが使用される場合のみです。

- この仮想サーバーはLBR1上で有効になっています。これは、OIMドメイン内の管理サービスに送信されるすべての内部HTTPトラフィック用のアクセス・ポイントとして機能します。クライアントからの受信トラフィックはすべて非SSLに対応しています。このため、クライアントはアドレスOIMADMIN.mycompany.com:80 (HTTP_PORT)を使用してこのサービスにアクセスし、続いてトラフィックがWEBHOST1およびWEBHOST2のポート7777(OHS_PORT)に転送されます。この仮想ホスト上でアクセスされるサービスには、WebLogic管理サーバー・コンソール、Oracle Enterprise Manager Fusion Middleware Controlなどがあります。

- ファイアウォールでルールを作成し、この仮想ホストを使用して外部トラフィックが/console URLおよび/em URLにアクセスすることを防止します。DMZ内部のトラフィックのみがOIMADMIN.mycompany.com仮想ホスト上のこれらのURLにアクセスできる必要があります。

16.2.2 ロード・バランサの構成

第3.4.3項「ロード・バランサの構成」の表3-1には、ロード・バランサの構成が記載されています。分割ドメイン・トポロジでは、追加で次の仮想ホストを構成します。

表16-1 分割ドメインにおける追加のロード・バランサの構成

仮想ホスト

サーバー・プール

プロトコル

SSL終端

外部

OIMADMIN.mycompany.com:80 (HTTP_PORT)

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

いいえ

いいえ

16.2.3 仮想IPアドレス

第3.5項「IPアドレスおよび仮想IPアドレスについて」には、Oracle Identity Managementで必要な仮想IPアドレスが記載されています。分割ドメイン・トポロジでは、次の仮想IPアドレスが追加で必要になります。

OIMADMINVHN.mycompany.com

分割ドメイン・トポロジを使用する場合は、この仮想IPアドレスが必要になります。この機能はADMINVHN.mycompany.comと同様です。この仮想IPアドレスは、管理サーバーとともに、IDMHOST1からIDMHOST2に(またはIDMHOST2からIDMHOST1に)フェイルオーバーします。

16.2.4 仮想IPアドレスおよび物理IPアドレスをリスニングするためのサーバー構成

第3.5項「IPアドレスおよび仮想IPアドレスについて」では、様々な仮想IPや物理IPをリスニングするように管理サーバーおよび管理対象サーバーを構成する方法も説明しています。それは図3-1に示されています。次の図は図3-1の修正バージョンであり、OIMDomainのものも含めすべてのIPアドレスおよびVIPアドレスが記載されています。

図16-1 IPアドレスとVIPアドレス

表3-2には、VIPアドレスと仮想ホストのマッピングが記載されています。その表に記載されているすべてのVIPアドレスが必要になります。分割ドメイン・トポロジでは、次に示すように、OIMADMINVHNにマッピングされるVIPアドレスであるVIP6を有効にする必要があります。

表16-2 VIPアドレスと仮想ホスト

仮想IP

VIPのマップ先

説明

VIP6

OIMADMINVHN

OIMADMINVHNは、Oracle Identity Manager管理サーバーのリスニング・アドレスとなる仮想ホスト名です。これは、管理サーバーの手動フェイルオーバーに伴ってフェイルオーバーします。これは、Oracle Identity Manager管理サーバー・プロセスが実行されているノード(デフォルトはIDMHOST1)で有効化されます。

16.2.5 ファイアウォールとポート

第3.6項「ファイアウォールとポートについて」の表3-3には、トポロジで使用されるファイアウォールのポートの一覧が記載されています。Oracle WebLogic管理サーバーにWeb層からアクセスするには、次の追加ポートが必要になります。

表16-3 Oracle Identity Managementエンタープライズ・デプロイメント・トポロジで使用されるポート

タイプ

ファイアウォール

ポートとポート範囲

プロトコル/アプリケーション

インバウンド/アウトバウンド

タイムアウト

Web層からのOracle WebLogic管理サーバー・アクセス

FW1

7101 (SPLIT_WLS_ADMIN_PORT)

HTTP/Oracle HTTP Serverと管理サーバー

インバウンド

N/A

16.3 ファイル・システムの準備に関する追加要件

第4.4項「各種ディレクトリの推奨場所について」では、ディレクトリの使用について説明しています。様々な推奨事項の中に、複数のミドルウェア・ホーム(MW_HOME)を設定するという推奨事項があります。

分割ドメイン・トポロジを実装する場合は、さらに別のミドルウェア・ホーム(2番目のドメイン用のMW_HOME)が必要になります。これにより、個別のパッチ適用が可能になります。

共有およびローカルの記憶域の詳細は、次のように変更する必要があります。

- 第4.4.4.1項「共有記憶域」では、共有記憶域に格納する必要のあるボリュームについて説明しています。分割ドメイン・トポロジを使用する場合は、共有記憶域に格納される追加のボリュームがあります。表16-4にはお薦めされるレイアウトの説明が記載されており、図16-2にはそれが図で表されています。

表16-4 共有記憶域上のボリューム

環境変数

ボリューム

マウント・ポイント

マウントされるホスト

排他

OIM_MW_HOME

VOL1/OIM_MW_HOME

/u01/oracle/products/identity

IDMHOST1 IDMHOST2

いいえ

ASERVER_HOME

VOL1/ADMIN2

/u01/oracle/config/domains/OIMDomain

IDMHOST1 IDMHOST2

はい

図16-2 分割ドメイン・トポロジにおける共有記憶域

- 第4.4.4.2項「ローカル記憶域」では、ローカル記憶域に作成されるディレクトリについて説明しています。
表4-1では、ローカル記憶域でお薦めされるレイアウトが説明されています。分割ドメインでは、図16-3で示すようにOIMDomainに追加のMSERVER_HOMEが含まれるという点が異なります。

図16-3 ローカル記憶域

16.4 サーバーの準備に関する追加要件

第5章「エンタープライズ・デプロイメント用のサーバーの準備」の表5-2には、追加で有効にする必要のある仮想ホストの一覧が記載されています。分割ドメイン・トポロジでは、次に示すように仮想ホストOIMADMINVHN.mycompany.comも有効にする必要があります。

表16-5 仮想ホスト

VIP

有効化されるホスト

OIMADMINVHN.mycompany.com

IDMHOST1

16.5 追加ドメインの作成に関する要件

分割ドメイン・トポロジでは2つのドメインを作成する必要があります。1つはAccess Manager用で、もう1つはOracle Identity Manager用です。

注意:

このドメイン用に個別のノード・マネージャを作成する必要はありません。配置されるノード・マネージャは各ホストに1つだけであり、それを使用して両方のドメインのWebLogicコンポーネントが管理されます。

第8.4項「構成ウィザードを実行してドメインを作成する方法」の手順を実行して、IDMDomainという名前のAccess Manager用のドメインを作成します。次に、この手順に次の変更を加えて再度実行し、Oracle Identity ManagerのコンポーネントをホストするためのOIMDomainという名前の第2のドメインを作成します。

- 手順5の「ドメイン・ソースの選択」画面で、次の製品のみを選択します。

- Oracle Enterprise Manager [oracle_common]

- Oracle Platform Security Service [iam]

- Oracle JRF [oracle_common]

- 手順14の「管理サーバーの構成」画面で、「リスニング・アドレス」と「リスニング・ポート」に次の値を入力します。

- リスニング・アドレス: OIMADMINVHN.mycompany.com

- リスニング・ポート: 7101 (SPLIT_WLS_ADMIN_PORT)

- SSLリスニング・ポート: 7102 (SPLIT_WLS_ADMIN_SSL_PORT)

- SSL有効: 選択済

- 手順17の「マシンの構成」画面で、「名前」の値にADMINVHNではなくOIMADMINVHNを指定します。

Oracle Unified Directoryをアクティブ/アクティブ・モードで使用する場合は、第8.5.1項「OIMアダプタ・テンプレートのコピー」の説明に従って次の手順を実行する必要があります。

1. Oracle Identity and Access Managementをインストールした後、パッチ16943171を適用します。

2. ファイルadapter_template_oim.xmlをORACLE_COMMON_HOME/modules/oracle.ovd_11.1.1/templates/からIAM_ORACLE_HOME/libovd/に手動でコピーします。例:

cp ORACLE_COMMON_HOME/modules/oracle.ovd_11.1.1/templates/adapter_template_oim.xml IAM_ORACLE_HOME/libovd/

第8.5.3項「ドメインと既存のOPSSポリシー・ストアの再関連付け」では、最初のドメインをOPSSポリシー・ストアに関連付けます。分割ドメイン・トポロジでは、既存のポリシー・ストアに追加のドメインを関連付ける必要があります。これを行うには、最初にポリシー・ストアから暗号化鍵をエクスポートし、次に生成された暗号化鍵を使用して新しいドメインをポリシー・ストアに結合します。

既存のOPSSデータ・ストアを使用してOIMDomainを生成するには、次の手順を実行します。

1. 次のコマンドを使用してwlstを起動します。

ORACLE_COMMON_HOME/common/bin/wlst.sh

次のコマンドを実行して暗号化鍵を生成します。

exportEncryptionKey (jpsConfigFile="wls-domain-path/config/fmwconfig/jps-config.xml",keyFilePath="opss-keyfile-path",keyFilePassword="opss-keyfile-password" )

例:

exportEncryptionKey(jpsConfigFile="ASERVER_HOME/config/fmwconfig/jps-config.xml",keyFilePath="/u01/oracle/opss_keystore", keyFilePassword="password" )

ここで、ASERVER_HOMEはIDMDomainのASERVER_HOMEです。これにより、opss-keyfile-pathで指定した場所に、ewallet.p12という名前のファイルが作成されます。

注意:

このコマンドを実行する前に、opss-keyfile-pathで指定するディレクトリが存在している必要があります。

2. 次のコマンドを実行し、OIMDomainをポリシー・ストアに関連付けます。

ORACLE_COMMON_HOME/common/bin/wlst.sh IAM_ORACLE_HOME/common/tools/configureSecurityStore.py -d ASERVER_HOME -c IAM -m join -p opss_schema_password -k opss-keyfile-path -w opss-keyfile-password

ここで、ASERVER_HOMEはOIMDomainのASERVER_HOME、opss_schema_passwordはスキーマEDG_OPSSのパスワード、opss-keyfile-pathおよびopss-keyfile-passwordはエクスポート・コマンドで指定した値です。例:

ORACLE_COMMON_HOME/common/bin/wlst.sh IAM_ORACLE_HOME/common/tools/configureSecurityStore.py -d ASERVER_HOME -c IAM -m join -p opss_schema_password -k /u01/oracle/opss_keystore -w password

既存のポリシー・ストアに後からドメインを関連付けるには、最初にポリシー・ストアから暗号化鍵をエクスポートし、次に生成された暗号化鍵を使用して新しいドメインをポリシー・ストアに結合します。

ドメインの作成後にバックアップを実行する場合、IDMDomainに加えてOIMDomainもバックアップします。第17.6.3項「インストール時および構成時のバックアップの実行」を参照してください。

16.6 Web層に関する追加要件

第10.5項「管理コンソール用フロントエンドURLの設定」では、管理サーバーのフロントエンドURLを変更し、ユーザーのブラウザが適切なロード・バランサ・アドレスにリダイレクトされるようにする方法について説明しています。分割ドメイン・トポロジの場合は、手順8で、次に示すようにフロント・エンド・ホストとフロント・エンドHTTPポートの各フィールドをOIMADMINロード・バランサのアドレスに設定します。

- フロント・エンド・ホスト: OIMADMIN.mycompany.com

- フロント・エンドHTTPポート: 80 (HTTP_PORT)

第10.3.3.2項「仮想ホストの定義の作成」では、各WebホストのWEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconfに作成されるファイルについて説明しています。分割ドメインを使用する場合は、次の変更を加える必要があります。

- ADMIN.mycompany.comの仮想ホストを作成します。ファイルadmin_vh.confには、Oracle Identity Managerの構成を含めないようにする必要があります。このファイルには、次の行のみを含めるようにします。

<VirtualHost *:7777>

ServerName ADMIN.mycompany.com:80
RewriteEngine On
RewriteOptions inherit
ServerAdmin you@your.address

###################################
## General Domain Configuration
###################################

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost ADMINVHN.mycompany.com
WebLogicPort 7001
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost ADMINVHN.mycompany.com
WebLogicPort 7001
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost ADMINVHN.mycompany.com
WebLogicPort 7001
</Location>

###################################################
## Entries Required by Oracle Entitlements Server
###################################################

# APM
<Location /apm>
SetHandler weblogic-handler
WebLogicHost ADMINVHN.mycompany.com
WebLogicPort 7001
</Location>

##################################################
## Entries Required by Oracle Unified Directory
##################################################

# OUD ODSM
<Location /odsm>
SetHandler weblogic-handler
WebLogicHost ADMINVHN.mycompany.com
WebLogicPort 7001
</Location>

##############################################
## Entries Required by Oracle Access Manager
##############################################

# OAM Console
<Location /oamconsole>
SetHandler weblogic-handler
WebLogicHost ADMINVHN
WebLogicPort 7001
</Location>

</VirtualHost>

- OIMADMIN.mycompany.comの仮想ホストを作成します。分割ドメインの場合にかぎり、oimadmin_vh.confという名前のファイルを作成します。このファイルには、OIMADMIN.mycompany.comを使用してドメインにアクセスするクライアントによってサポートされる場所のリストが格納されます。これらのエントリは、OIMDomain内の管理コンポーネントにアクセスするクライアントによって使用されます。

<VirtualHost *:7777>
ServerName http://OIMADMIN.mycompany.com:80
RewriteEngine On
RewriteOptions inherit
ServerAdmin you@your.address

###########################
## Generic Entries
###########################

# Admin Server and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost OIMADMINVHN.mycompany.com
WebLogicPort 7101
</Location>

<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost OIMADMINVHN.mycompany.com
WebLogicPort 7101
</Location>

<Location /em>
SetHandler weblogic-handler
WebLogicHost OIMADMINVHN.mycompany.com
WebLogicPort 7101
</Location>

#################################################
## Entries required by Oracle Identity Manager
#################################################

# OIM self and advanced admin webapp consoles(canonic webapp)

<Location /oim>
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
WLCookieName    oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM, xlWebApp - Legacy 9.x webapp (struts based)
<Location /xlWebApp>
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
WLCookieName    oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM self service console
<Location /identity>
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
WLCookieName oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM Nexaweb WebApp - used for workflow designer and DM
<Location /Nexaweb>
SetHandler weblogic-handler
WLProxySSL ON
WLProxySSLPassThrough ON
WLCookieName    oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

# OIM System Admin Console
<Location /sysadmin>
SetHandler weblogic-handler
WLCookieName oimjsessionid
WebLogicCluster OIMHOST1VHN:14000,OIMHOST2VHN:14000
WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/oim_component.log"
</Location>

</VirtualHost>

16.7 Access Managerに関する追加要件

OAMエージェントを更新する場合、第11.6.5項「新規作成エージェントの更新」の説明に従いますが、その際に手順16の「ホスト名」と「ポート」に記載されている値に加えて、次の値を入力します。

- ホスト名: OIMADMIN.mycompany.com

- ポート: 80 (HTTP_PORT)

16.8 Oracle Identity Managerに関する追加要件

第12章「Oracle Identity Managerを追加するためのドメインの拡張」では、シングル・ドメイン・トポロジでOracle Identity Managerをインストールし、構成する方法が説明されています。全体として、分割ドメイン・トポロジを構築する場合でも手順は同様です。ただし、IDMDomainではなくOIMDomainを指定し、仮想ホストADMINVHNではなくOIMADMINVHNを指定します。次の項では、特定の変更事項について説明します。

この項には次のトピックが含まれます:

- 第16.8.1項「ドメインのURL」

- 第16.8.2項「ログイン・モジュールのプロビジョニングとwlfullclient.jarの作成」

- 第16.8.3項「Oracle Identity ManagerおよびOracle SOA Suiteを構成するためのドメインの拡張」

- 16.8.4項「Oracle Identity Managerの構成」

- 第16.8.5項「Oracle Identity ManagerとOracle SOAの配置」

- 第16.8.6項「Oracle Identity ManagerからSOAへの接続の有効化」

- 第16.8.7項「Access ManagerとOracle Identity Managerの統合の構成」

- 第16.8.8項「Oracle Identity Managerのバックアップ」

16.8.1 ドメインのURL

第12.2項「ドメインのURLについて」の表12-1には、インストールと構成が完了した後に利用可能になるOracle Identity ManagerのURLが記載されています。分割ドメイン・トポロジを構成する場合、Oracle Identity ManagerのURLは表12-1ではなく次のようになります。

表16-6 OIMのURL

コンポーネント

URL

SSOユーザー

OIM管理コンソール

http://OIMADMIN.mycompany.com/sysadmin

xelsysadm

16.8.2 ログイン・モジュールのプロビジョニングとwlfullclient.jarの作成

分割ドメイン・トポロジでは、第12.4項「WebLogic Serverライブラリ・ディレクトリへのOIMログイン・モジュールのプロビジョニング」の手順を実行しますが、その際にIAM_MW_HOMEではなくOIM_MW_HOMEで実行します。

第12.5項「wlfullclient.jarファイルの作成」で説明しているように、構築環境のアプリケーション層でOracle Identity ManagerをホストしているすべてのマシンのIAM_MW_HOME/wlserver_10.3/server/libディレクトリの下にwlfullclient.jarライブラリを作成する必要があります。分割ドメイン・トポロジでは、IAM_MW_HOMEではなくOIM_MW_HOMEにライブラリを作成します。具体的には、手順1でOIM_MW_HOME/wlserver_10.3/server/libディレクトリに移動する必要があります。

16.8.3 Oracle Identity ManagerおよびOracle SOA Suiteを構成するためのドメインの拡張

第12.7項「Oracle Identity ManagerおよびOracle SOA Suiteを構成するためのドメインの拡張」の説明に従って、Oracle Identity Managerのコンポーネントを含めるためにドメインを拡張する必要があります。分割ドメイン・トポロジを作成する場合は、IDMDomainではなくOIMDomainを拡張します。

手順2の「WebLogicドメイン・ディレクトリの選択」画面で、OIMDomainのドメイン・ディレクトリの場所(ASERVER_HOME)を選択します。例: /u01/oracle/config/domains/domain_name

16.8.4 Oracle Identity Managerの構成

Oracle Identity Managerを構成する際には、第12.10項「Oracle Identity Managerの構成」の説明に従って、手順4のWebLogic管理サーバー画面で、WebLogic管理サーバーに接続するためのURLを次のように指定します。

t3://OIMADMINVHN.mycompany.com:7101

ここで、7101は第B.3項のWLS_ADMIN_PORTに相当します。

16.8.5 Oracle Identity ManagerとOracle SOAの配置

第12.8項「IDMHOST1およびIDMHOST2の管理対象サーバーのドメイン・ディレクトリへのOracle Identity ManagerおよびOracle SOAの展開」で説明されているように、構成が完了したら、IDMHOST1およびIDMHOST2の管理対象サーバーのディレクトリにOracle Identity Managerの構成を伝播する必要があります。ドメインIDMDomainをパックするのではなく、OIMDomainでパックを実行します。

16.8.6 Oracle Identity ManagerからSOAへの接続の有効化

第12.20項「LDAPでプロビジョニングした管理ユーザーを使用したOracle Identity ManagerからSOAへの接続の有効化」では、中央のLDAPストアでプロビジョニングしたOracle WebLogic Server管理者ユーザーとOracle Identity Managerが連携できるようにするためのインストール後手順を実行します。次の手順の中で正しいドメインを指定してください。

- 手順2: 分割ドメイン・トポロジでは、「Farm_OIMDomain」→「Identity and Access」→「OIM」→「oim(11.1.2.0.0)」を選択します。

- 手順7: 分割ドメイン・トポロジでは、ナビゲータから「WebLogicドメイン」→「OIMDomain」を選択します。

- 手順14a: URLはhttp://ADMIN.mycompany.com/sysadminではなくhttp://OIMADMIN.mycompany.com/sysadminを使用して、ユーザーxelsysadmでOIM管理コンソールにログインします。

16.8.7 Access ManagerとOracle Identity Managerの統合の構成

第12.23.4項「idmConfigToolを使用したOracle Identity ManagerとOracle Access Managerの統合」では、Oracle Identity ManagerのコンポーネントはAccess Managerのコンポーネントとは別のドメインに存在するということを反映して構成を行う必要があります。次の変更が必要になります。

- 手順2でプロパティ・ファイルoimitg.propsを作成するときに、第12.23.4項で示されているコンテンツではなく、次のコンテンツを使用します。

LOGINURI: /${app.context}/adfAuthentication
LOGOUTURI: /oamsso/logout.html
AUTOLOGINURI: None
ACCESS_SERVER_HOST: IDMHOST1.mycompany.com
ACCESS_SERVER_PORT: 5575
ACCESS_GATE_ID: Webgate_IDM
COOKIE_DOMAIN: .mycompany.com
COOKIE_EXPIRY_INTERVAL: 120
OAM_TRANSFER_MODE: simple
WEBGATE_TYPE: ohsWebgate11g
SSO_ENABLED_FLAG: true
IDSTORE_PORT: 389
IDSTORE_HOST: IDSTORE.mycompany.com
IDSTORE_DIRECTORYTYPE: OUD, OID or OVD
IDSTORE_ADMIN_USER: cn=oamLDAP,cn=Users,dc=mycompany,dc=com
IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com
IDSTORE_LOGINATTRIBUTE: uid
MDS_DB_URL: jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(FAILOVER=on)(ADDRESS_LIST=(ADDRESS=(protocol=tcp)(host=OIDDBHOST1-VIP.mycompany.com)(port=1521))(ADDRESS=(protocol=tcp)(host=OIDDBHOST2-VIP.mycompany.com)(port=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=OIDEDG.mycompany.com)))
MDS_DB_SCHEMA_USERNAME: edg_mds
OIM_MANAGED_SERVER_NAME: WLS_OIM1
WLSADMIN: weblogic
WLSPORT: 7101
WLSHOST: OIMADMINVHN.mycompany.com
OAM11G_WLS_ADMIN_HOST: ADMINVHN.mycompany.com
OAM11G_WLS_ADMIN_PORT: 7001
OAM11G_WLS_ADMIN_USER: weblogic
DOMAIN_NAME: OIMDomain
DOMAIN_LOCATION: ASERVER_HOME

第12.23.4項の手順2に対して追加された値、および変更された値は太字で示されています。プロパティ定義は同じですが、1点、次の追加があります。

Oracle Identity ManagerのコンポーネントがAccess Managerのコンポーネントとは別のドメインにある場合、OAM11G_WLS_ADMIN_HOST、OAM11G_WLS_ADMIN_PORTおよびOAM11G_WLS_ADMIN_USERによってOAMドメインの詳細を指定します。

- スクリプトの実行時に、手順3で説明されているように情報の入力が求められます。Access ManagerとOracle Identity Managerが別のドメインにある場合は、さらに次の情報の入力が求められます。
Access Managerのドメイン・ユーザーのパスワード

- 第12.23.4項の手順の最後に、両方のドメインのWebLogic管理サーバーを再起動します。

16.8.8 Oracle Identity Managerのバックアップ

Oracle Identity Managerの構成後にバックアップを行う場合、IDMDomainに加えてOIMDomainもバックアップします。第17.6.3項「インストール時および構成時のバックアップの実行」を参照してください。

16.9 シングル・サインオンに関する追加要件

シングル・サインオンの構成後にバックアップを行う場合、IDMDomainに加えてOIMDomainもバックアップします。第17.6.3項「インストール時および構成時のバックアップの実行」を参照してください。

16.10 ノード・マネージャに関する追加要件

第13.3.1項「utils.CertGenユーティリティを使用した自己署名証明書の生成」の手順4で、utils.CertGenツールを実行するときにOIMADMINVHN.mycompany.comに関する追加の証明書を作成します。次に例を示します。

java utils.CertGen Key_Passphrase OIMADMINVHN.mycompany.com_cert OIMADMVHN.mycompany.com_key domestic OIMADMINVHN.mycompany.com

また、第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」でも、OIMADMINVHN.mycompany.comに関する手順を実行します。

16.11 管理に関する追加要件

分割ドメイン・トポロジを使用する場合は、次の管理タスクを追加で実行します。

この項には次のトピックが含まれます:

- 第16.11.1項「パッチの適用」

- 第16.11.2項「バックアップの実行」

16.11.1 パッチの適用

第17.7.2項「Identity and Access Managementへのパッチ適用」では、シングル・ドメイン・トポロジ内のIdentity and Access managementにパッチを適用する方法について説明しています。

分割ドメイン・トポロジでは、Oracle Identity Managerは他のコンポーネントとは別のドメインにあるため、次のようにパッチを適用します。

IDMDomainのMW_HOME

- 共通のパッチ

- Oracle Access Managerのパッチ

- IDMツールのパッチ

OIMDomain MW_HOME

- 共通のパッチ

- Oracle Identity Managerのパッチ

- IDMツールのパッチ

Identity Management MW_HOME

- 共通のパッチ

- Oracle Internet Directoryのパッチ

- Oracle Virtual Directoryのパッチ

OIMDomainにパッチを適用する間、IDMDomain内のプロセスを停止する必要はありません。同様に、IDMDomainにパッチを適用する間、OIMDomain内のプロセスを停止する必要はありません。

16.11.2 バックアップの実行

ドメインの作成後、Oracle Identity Managerの構成後、およびシングル・サインオンの構成後にバックアップを行う場合、IDMDomain内のディレクトリに加えてOIMDomainもバックアップします。第17.6.3項「インストール時および構成時のバックアップの実行」を参照してください。

17 エンタープライズ・デプロイメント用のトポロジの管理

この章では、Identity Managementのトポロジの設定後に実行できる操作について説明します。実行できる操作には、トポロジの監視、スケーリング、バックアップ、トラブルシューティングなどがあります。

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

- 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」

- 第17.2項「Identity ManagementコンソールのURLについて」

- 第17.3項「エンタープライズ・デプロイメントの監視」

- 第17.4項「エンタープライズ・デプロイメントのスケーリング」

- 第17.5項「アイデンティティ管理の監査」

- 第17.6項「バックアップとリカバリの実行」

- 第17.7項「エンタープライズ・デプロイメントへのパッチ適用」

- 第17.8項「SQLのタイムアウトの防止」

- 第17.9項「WebLogic管理サーバーの手動フェイルオーバー」

- 第17.10項「トラブルシューティング」

17.1Oracle Identity Managementコンポーネントの起動と停止

この項では、Oracle Identity Managementエンタープライズ・デプロイメントの各種コンポーネントを起動、停止および再起動する方法を説明します。

この項には次のトピックが含まれます:

- 第17.1.1項「起動順序」

- 第17.1.2項「Oracle Unified Directoryの起動と停止」

- 第17.1.3項「Access Managerの管理対象サーバーの起動、停止および再起動」

- 第17.1.4項「WebLogic管理サーバーの起動、停止および再起動」

- 第17.1.5項「ノード・マネージャの起動と停止」

- 17.1.6項「Oracle HTTP Serverの起動、停止および再起動」

- 第17.1.7項「Oracle Identity Managerの起動、停止および再起動」

17.1.1 起動順序

インフラストラクチャ全体を起動するときは、次の順序で各コンポーネントを起動します(トポロジ内に存在しないコンポーネントは無視してください)。

1. データベース

2. データベース・リスナー

3. LDAPディレクトリ・サーバー

4. ノード・マネージャ

5. Oracle Access Managerサーバー

6. WebLogic管理サーバー

7. Oracle HTTP Server

8. SOAサーバー

9. Oracle Identity Managerサーバー

17.1.2 Oracle Unified Directoryの起動と停止

Oracle Unified Directoryは次のように起動および停止します。

17.1.2.1 Oracle Unified Directoryの起動

Oracle Unified Directoryを起動するには、次のコマンドを実行します。

OUD_ORACLE_INSTANCE/OUD/bin/start-ds

17.1.2.2 Oracle Unified Directoryの停止

Oracle Unified Directoryを停止するには、次のコマンドを実行します。

OUD_ORACLE_INSTANCE/OUD/bin/stop-ds

17.1.3 Access Managerの管理対象サーバーの起動、停止および再起動

Oracle Access Managerの管理対象サーバーを起動および停止するには、次のようにします。

17.1.3.1 Access Manager管理対象サーバーが1つも実行されていない場合の管理対象サーバーの起動

通常、Access Managerの管理対象サーバーはWebLogicコンソールを使用して起動します。管理コンソールのシングル・サインオンを有効にした後は、コンソールにアクセスするには1つ以上のAccess Managerサーバーが実行されている必要があります。Access Managerサーバーが実行されていない場合は、WLSTを使用して起動できます。

LinuxまたはUNIXでWLSTを起動するには、次のコマンドを入力します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

WLSTシェルが開始されたら、次のコマンドを実行します。

nmConnect('Admin_User','Admin_Password', 'OAMHOST','Port',  'domain_name','MSERVER_HOME')
nmStart('OAMServer')

ここで、Portは第B.3項のNMGR_PORT、domain_nameはドメインの名前、Admin_UserおよびAdmin_Passwordは第8.5.5項「ノード・マネージャ資格証明の更新」の手順2で入力したノード・マネージャのユーザー名とパスワードです。例:

nmConnect('weblogic','password', 'IDMHOST1','5556',  'IDMDomain','MSERVER_HOME')
nmStart('WLS_OAM1')

17.1.3.1 別のAccess Manager管理対象サーバーが実行されている場合の管理対象サーバーの起動

すでに別のOracle Access Manager管理対象サーバーが実行されている場合にさらに管理対象サーバーを起動するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。

次のように実行します。

1. 「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。

2. 「制御」タブをクリックします。

3. OAMサーバー(WLS_OAM1またはWLS_OAM2、あるいはその両方)を選択します。

4. 「起動」ボタンをクリックします。

5. サーバーを起動してよいか確認を求められたら、「はい」をクリックします。

17.1.3.3 Access Manager管理対象サーバーの停止

Oracle Access Manager管理対象サーバーを停止するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインし、次の手順を実行します。

1. 「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。

2. 「制御」タブをクリックします。

3. OAMサーバー(WLS_OAM1またはWLS_OAM2、あるいはその両方)を選択します。

4. 「停止」ボタンをクリックし、「ただちに強制停止」を選択します。

5. サーバーを停止してよいか確認を求められたら、「はい」をクリックします。

17.1.3.4 Access Manager管理対象サーバーの再起動

前の各項で、停止と起動の手順を実行してサーバーを再起動します。

17.1.4 WebLogic管理サーバーの起動、停止および再起動

次の項の説明に従って、WebLogic管理サーバーの起動と停止を行います。

注意:

Admin_UserとAdmin_Passwordのみを使用して、ノード・マネージャとクライアントとの間における接続を認証します。これらはサーバー管理IDおよびパスワードとは独立しており、ASERVER_HOME/config/nodemanager/nm_password.propertiesファイルに格納されています。

17.1.4.1 WebLogic管理サーバーの起動

管理サーバーを起動するために推奨される方法は、WLSTを使用してノード・マネージャに接続することです。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

WLSTシェルが開始されたら、次のコマンドを実行します。

nmConnect('Admin_User','Admin_Password','ADMINVHN','5556', 'IDMDomain','ASERVER_HOME')
nmStart('AdminServer')

または、次のコマンドを使用して管理サーバーを起動することもできます。

ASERVER_HOME/bin/startWebLogic.sh

17.1.4.2 WebLogic管理サーバーの停止

管理サーバーを停止するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。

次のように実行します。

1. 「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。

2. 「制御」タブをクリックします。

3. 「AdminServer(admin)」を選択します。

4. 「停止」をクリックし、「ただちに強制停止」を選択します。

5. 管理サーバーを停止してよいか確認を求められたら「はい」をクリックします。

17.1.4.3 WebLogic管理サーバーの再起動

前の各項で、停止と起動の手順を実行してサーバーを再起動します。

17.1.5 ノード・マネージャの起動と停止

ノード・マネージャを起動および停止するには、次のようにします。

17.1.5.1 ノード・マネージャの起動

起動しようとするノード・マネージャが、管理サーバー(IDMHOST1またはIDMHOST2)を制御するノード・マネージャである場合は、その起動の前に次のコマンドを発行します。

export JAVA_OPTIONS=-DDomainRegistrationEnabled=true

ノード・マネージャで共有記憶域を使用している場合は、第13.3.5項「共通または共有記憶域インストールの使用」の説明に従ってJAVA_OPTIONSを設定します。

ノード・マネージャを起動するには、次のコマンドを実行します。

cd IAM_MW_HOME/wlserver_10.3/server/bin
./startNodeManager.sh

17.1.5.2 ノード・マネージャの停止

ノード・マネージャを停止するには、前の項で起動したプロセスを強制終了します。

17.1.5.3 管理サーバーのノード・マネージャの起動

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
./startNodeManager.sh

注意:

管理サーバーを管理するノード・マネージャを起動する場合は、-DDomainRegistrationEnabled=trueを設定することが重要です。

17.1.6 Oracle HTTP Serverの起動、停止および再起動

Oracle HTTP Serverを起動または停止する前に、環境変数WEB_ORACLE_HOMEおよびORACLE_INSTANCEが定義済であり、PATHにORACLE_HOME/opmn/binが記述済であることを確認します。例:

export ORACLE_HOME=WEB_ORACLE_HOME
export ORACLE_INSTANCE=WEB_ORACLE_INSTANCE
export PATH=$ORACLE_HOME/opmn/bin:$PATH

17.1.6.1 Oracle HTTP Serverの起動

次のコマンドを発行して、Oracle Web層を起動します。

opmnctl startall

17.1.6.2 Oracle HTTP Serverの停止

次のコマンドを実行して、Web層を停止します。

opmnctl stopall

前述を実行すると、Web層全体が停止します。

opmnctl stoproc process-type=OHS

前述を実行すると、Oracle HTTP Serverのみが停止します。

17.1.6.3 Oracle HTTP Serverの再起動

Web層を再起動するには、前述の各項における記載のとおりstopコマンドを実行してからstartコマンドを実行します。

Oracle HTTP Serverのみを再起動するには、次のコマンドを使用します。

opmnctl restartproc process-type=OHS

17.1.7 Oracle Identity Managerの起動、停止および再起動

Oracle Identity ManagerサーバーとOracle SOA Suiteサーバーを起動および停止するには、次のようにします。

17.1.7.1 Oracle Identity Managerの起動

Oracle Identity Manager管理対象サーバーを起動するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインします。

次のように実行します。

1. 「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。

2. 「制御」タブをクリックします。

3. SOAサーバー(WLS_SOA1またはWLS_SOA2、あるいはその両方)を選択します。

注意:

Oracle Identity ManagerサーバーとOracle SOA Suiteサーバーは相互に独立して起動できます。これらの起動順序には依存関係はありません。ただし、Oracle Identity Managerの機能をすべて使用可能にするには、SOAサーバーが起動され、実行されていることが必要です。

4. 「起動」ボタンをクリックします。

5. サーバーを起動してよいか確認を求められたら、「はい」をクリックします。

6. WLS_SOA1またはWLS_SOA2(あるいはその両方)が起動されたら、WLS_OIM1またはWLS_OIM2(あるいはその両方)を選択します。

7. 「起動」をクリックします。

8. サーバーを起動してよいか確認を求められたら、「はい」をクリックします。

17.1.7.2 Oracle Identity Managerの停止

Oracle Identity Manager管理対象サーバーを停止するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してWebLogicコンソールにログインし、次の手順を実行します。

1. 「ドメイン構造」メニューで「環境」→「サーバー」をクリックします。

2. 「制御」タブをクリックします。

3. OIMサーバー(WLS_OIM1またはWLS_OIM2、あるいはその両方)および(WLS_SOA1またはWLS_SOA2、あるいはその両方)を選択します。

4. 「停止」ボタンをクリックし、「ただちに強制停止」を選択します。

5. サーバーを停止してよいか確認を求められたら、「はい」をクリックします。

17.1.7.3 Oracle Identity Managerの再起動

前の各項で、停止と起動の手順を実行してサーバーを再起動します。

17.2 Identity ManagementコンソールのURLについて

表17-1は、このガイドの中で使用されている管理コンソールとそのURLの一覧です。

表17-1 コンソールのURL

ドメイン

コンソール

URL

IDMDomain

WebLogic管理コンソール

http://ADMIN.mycompany.com/console

Enterprise Manager FMWコントロール

http://ADMIN.mycompany.com/em

OAMコンソール

http://ADMIN.mycompany.com/oamconsole

ODSM

http://ADMIN.mycompany.com/odsm

OIMDomain

OIMコンソール

https://SSO.mycompany.com/identity

OIMDomain

WebLogic管理コンソール

http://OIMADMIN.mycompany.com/console

OIMDomain

Enterprise Manager FMWコントロール

http://OIMADMIN.mycompany.com/em

OIMDomain

認可ポリシー・マネージャ

http://OIMADMIN.mycompany.com/apm

17.3 エンタープライズ・デプロイメントの監視

この項では、このマニュアルで説明しているIdentity Managementエンタープライズ・デプロイメントの監視について説明します。

この項には次のトピックが含まれます:

- 第17.3.1項「WebLogic管理対象サーバーの監視」

- 第17.3.2項「Oracle Unified Directoryの監視」

17.3.1 WebLogic管理対象サーバーの監視

Oracle Enterprise Manager Fusion Middleware Controlを使用すると、管理対象サーバーや他のFusion Middlewareコンポーネント(Access Manager、Oracle Identity Manager、SOAなど)を監視できます。詳細は、「関連ドキュメント」の「はじめに」で一覧表示されている各管理者ガイドを参照してください。

17.3.2 Oracle Unified Directoryの監視

次のコマンドを実行することによって、Oracle Unified Directoryのステータスを確認できます。

OUD_ORACLE_INSTANCE/OUD/bin/status

このコマンドは、ローカルで実行されているOracle Unified Directoryのインスタンスにアクセスし、ディレクトリのステータスをレポートします(レプリケーションの有効/無効、LDAPまたはLDAPSの有効/無効など)。

17.4 エンタープライズ・デプロイメントのスケーリング

このマニュアルで取り上げている参照エンタープライズ・トポロジはきわめてスケーラブルです。スケール・アップもスケール・アウトも可能です。トポロジをスケール・アップすると、すでに1つ以上のサーバー・インスタンスを実行しているノードに新しいサーバー・インスタンスが追加されます。トポロジをスケール・アウトすると、新しいノードに新しいサーバーが追加されます。

この項には次のトピックが含まれます:

- 第17.4.1項「トポロジのスケール・アップ」

- 第17.4.2項「トポロジのスケール・アウト」

17.4.1 トポロジのスケール・アップ

このガイドで説明しているOracle Identity Managementトポロジには、データベース層、アプリケーション層およびWeb層という3つの層があります。すでに1つ以上のサーバー・インスタンスが実行されているノードに新しいサーバー・インスタンスを追加することで、3つすべての層内のコンポーネントをスケール・アップできます。

この項で説明する手順では、管理対象サーバーまたは管理対象ディレクトリの新しいインスタンスを作成する方法を示します。新しい管理対象サーバーを追加する場合は、その管理対象サーバーを追加した後で、Oracle HTTP Serverの構成ファイルをすべてのノードで更新し、既存のWebLogicクラスタ・ディレクティブにその新しいサーバーを追加する必要があります。

たとえば、Oracle Access Managerの新しいサーバーを追加する場合は、WEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconf/sso_vh.confを更新して、この新しい管理対象サーバーを含める必要があります。

sso_vh.confを次のように更新します。

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST3.mycompany.com:14100
</Location>

sso_vh.confを更新したら、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってOracle HTTPサーバーを再起動します。サービスの停止を防止するため、再起動は順次的に行うことをお薦めします。

この項には次のトピックが含まれます:

- 第17.4.1.1項「Oracle Unified Directoryのスケール・アップ」

- 第17.4.1.2項「Oracle Access Manager 11gのスケール・アップ」

- 第17.4.1.3項「Oracle Identity Managerのスケール・アップ」

- 第17.4.1.4項「Oracle HTTP Serverのスケール・アップ」

17.4.1.1 Oracle Unified Directoryのスケール・アップ

ディレクトリにはOracle Unified Directoryの2つのノード(IDMHOST1とIDMHOST2)があり、それぞれでOracle Unified Directoryインスタンスが実行されます。各ノードのOracle Unified Directoryバイナリを使用して、Oracle Unified Directoryの新しいインスタンスを作成できます。

Oracle Unified DirectoryのいずれかのホストにOracle Unified Directoryの新しいインスタンスを追加するには、第7.4.3項「IDMHOST2での追加のOracle Unified Directoryインスタンスの構成」の手順を実行します。ただし、手順に次の変更を加えます。

- 手順2および手順4で、1389 (LDAP_DIR_PORT)、1636 (LDAP_DIR_SSL_PORT)、4444 (LDAP_DIR_ADMIN_PORT)以外のポートを選択します。これらのポートは、ノード上の既存のOracle Unified Directoryインスタンスですでに使用されているためです。

- Oracle Unified Directoryの新しいインスタンスの場所をORACLE_INSTANCEの値として使用します。

- 新しいOracle Unified Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。

17.4.1.2 Oracle Access Manager 11gのスケール・アップ

次の手順でOracle Access Managerをスケール・アップします。

第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。

2. 「ロックして編集」を「チェンジ・センター」メニューでクリックします。

3. 拡張するホスト上の既存サーバーを選択します(例: WLS_OAM1)。

4. 「クローンの作成」をクリックします。

5. 次の情報を入力します。

- サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。

- サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。

- サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。

6. 「OK」をクリックします。

7. 新しく作成したサーバーWLS_OAM3をクリックします。

8. 「保存」をクリックします。

9. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。IDMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名検証を無効にする手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

10. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

Oracle Access Managerに新しい管理対象サーバーを登録します。この時点で、新しい管理対象サーバーをOracle Access Managerサーバーとして構成する必要があります。Oracle OAMコンソールでこれを行います。次のように実行します。

1. oamadminユーザーでOAMコンソールにログインします。第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用します。

2. 「システム構成」タブをクリックします。

3. 「サーバー・インスタンス」をクリックします。

4. 「作成」を「アクション」メニューで選択します。

5. 次の情報を入力します。

- サーバー名: WLS_OAM3

- ホスト: サーバーを実行するホスト。

- ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポートです。

- OAMプロキシ・ポート: Oracle Access Managerプロキシの実行対象とするポート。これは当該ホストについて一意のポートです。

- プロキシ・サーバーID: AccessServerConfigProxy

- モード: 既存のOracle Access Managerサーバーが動作しているモードに応じて、「オープン」または「簡易」を選択します。

- Coherenceローカル・ポート: 「ローカル・ポート」にホストで一意の値を設定します。

6. 「適用」をクリックします。

7. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。

新しく作成したOracle Access Managerサーバーを使用する可能性のあるすべてのWebゲート・プロファイル(Webgate_IDMやIAMSuiteAgent)にそのサーバーを追加します。

たとえば、Oracle Access ManagerサーバーをWebgate_IDMに追加するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してOAMコンソールにアクセスし、次の手順を実行します。

1. 第9.4項「アイデンティティ・ストアの準備」で作成したOracle Access Manager管理ユーザーとしてログインします。

2. 「システム構成」タブをクリックします。

3. 「Access Manager」→「SSOエージェント」→「OAMエージェント」を開きます。

4. フォルダを開くアイコンをクリックして「検索」をクリックします。
Webゲート・エージェントWebgate_IDMが表示されます。

5. エージェントWebgate_IDMをクリックします。

6. 「アクション」メニューで「編集」を選択します。

7. 「プライマリ・サーバー」リスト(これがセカンダリ・サーバーである場合は「セカンダリ・サーバー」リスト)で「+」をクリックします。

8. 「サーバー」リストから、新しく作成した管理対象サーバーを選択します。

9. 「接続の最大数」を10に設定します。

10. 「適用」をクリックします。

IAMSuiteAgentおよび、使用している可能性のあるその他すべてのWebゲートで、手順5 - 10を繰り返します。

Web層を更新します。新しい管理対象サーバーが作成され、起動されると、Web層から各種の要求がそのサーバーに送られるようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。

これを行うには、各Web層でファイルsso_vh.confを更新します。このファイルは、ディレクトリWEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconfにあります。

新しいサーバーをこのファイル内のWebLogicClusterディレクティブに追加します。次に変更前の例を示します。

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100
</Location>

変更後は次のようになります。

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST1.mycompany.com:14101
</Location>

このファイルを保存し、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってOracle HTTP Serverを再起動します。

これで第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の手順に従い、新しい管理対象サーバーを起動できるようになります。

17.4.1.3 Oracle Identity Managerのスケール・アップ

この場合は、すでに管理対象サーバーを実行するノードがOracle SOA SuiteおよびOracle Identity Managerのコンポーネントを使用するように構成されています。このノードには、ミドルウェア・ホーム、SOA Oracleホーム、Oracle Identity Manager Oracleホーム、および既存の管理対象サーバーのドメイン・ディレクトリが含まれています。

既存のインストール内容(ミドルウェア・ホームおよびドメイン・ディレクトリ)を使用して、新しいWLS_OIMサーバーとWLS_SOAサーバーを作成できます。新しい場所にOracle Identity and Access ManagementまたはOracle SOA Suiteバイナリをインストールする必要はありません。また、パックと解凍を実行する必要もありません。

次の手順に従って、トポロジをスケール・アップします。

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して管理コンソールにログインします。WLS_OIM1またはWLS_SOA1のいずれかを新しい管理対象サーバーにクローニングします。クローニング元となるソース管理対象サーバーは、新しい管理対象サーバーを実行するノード上にすでに存在している必要があります。
管理対象サーバーをクローニングする手順は次のとおりです。

1. 管理コンソールで「環境」→「サーバー」を選択します。

2. 「チェンジ・センター」メニューで「ロックして編集」をクリックします。

3. クローニングする管理対象サーバーを選択します(例: WLS_OIM1やWLS_SOA1)。

4. 「クローンの作成」を選択します。

新しい管理対象サーバーに、WLS_OIMnまたはWLS_SOAnという名前を付けます。nには、新しい管理対象サーバーを識別するための番号を指定します。

この後の手順では、すでにWLS_SOA1およびWLS_OIM1を実行しているIDMHOST1に新しいサーバーを追加することを想定しています。

2. リスニング・アドレスとして、この新しい管理対象サーバー用に使用するホスト名またはIPアドレスを割り当てます。このサーバーでお薦めしているサーバー移行を実行する予定の場合は、別のノードへの移動を可能にするために、このアドレスはVIP(別称: 浮動IP)である必要があります。このVIPは、すでに実行されている管理対象サーバーで使用されているものとは異なっている必要があります。

3. 新しい管理対象サーバー上に、SOA、Oracle Identity Manager、UMSおよびBPMそれぞれのJMSサーバーを作成します。この操作は次のように実行します。

1. WebLogic管理コンソールにログインし、「サービス」→「メッセージング」→「JMSサーバー」に移動します。

2. 「新規」をクリックします。

3. 「名前」に、BPMJMSServer_auto_3などの値を入力します。

4. 「新しいファイル・ストアの作成」をクリックします。

5. リストからFileStoreを選択します。

6. 「次へ」をクリックします。

7. 「名前」に、BPMJMSFileStore_auto_3などの値を入力します。

8. 次の値を入力します。
ターゲット: 現在作成している新しいサーバー。

ディレクトリ: ASERVER_HOME/jms/BPMJMSFileStore_auto_3

注意:

ディレクトリが存在していることを確認してください。存在しない場合、WLS_OIM3またはWLS_SOA3を起動できません。

9. 「OK」をクリックします。

10. 「JMSサーバー」画面に戻り、新しく作成したファイル・ストアをリストから選択します。

11. 「次へ」をクリックします。

12. 次の画面で、「ターゲット」を作成しているサーバーに設定します。

13. 「終了」をクリックします。

作成する管理対象サーバーに応じて、次のJMSキューを作成します。

サーバー

JMSサーバー名

ファイル・ストア名

ディレクトリ

ターゲット

WLS_SOAn

BPMJMSServer_auto_n

BPMJMSFileStore_auto_n

ASERVER_HOME/jms/BPMJMSFileStore_auto_n

WLS_SOAn

WLS_SOAn

SOAJMSServer_auto_n

SOAJMSFileStore_auto_n

ASERVER_HOME/jms/SOAJMSFileStore_auto_n

WLS_SOAn

WLS_SOAn

UMSJMSServer_auto_n

UMSJMSFileStore_auto_n

ASERVER_HOME/jms/UMSJMSFileStore_auto_n

WLS_SOAn

WLS_OIMn

OIMJMSServer_auto_n

OIMJMSFileStore_auto_n

ASERVER_HOME/jms/OIMJMSFileStore_auto_n

WLS_OIMn

WLS_OIMn

JRFWSAsyncJmsServer_auto_n

JRFWSAsyncFileStore_auto_n

ASERVER_HOME/jms/JRFWSAsyncFileStore_auto_n

WLS_OIMn

4. 次の手順を実行して、新しく作成したJMSキューを既存のJMSモジュールに追加します。

1. WebLogic管理コンソールにログインします。

2. 「サービス」→「メッセージング」→「JMSモジュール」に移動します。

3. SOAJMSModuleなどのJMSモジュールをクリックします。

4. 「サブデプロイメント」タブをクリックします。

5. 表示されたサブ・デプロイメントをクリックします。

注意:

このサブデプロイメント・モジュール名は、JMSServerNameXXXXXXという形式のランダムな名前で、構成ウィザードJMS構成から生成されます。

6. 新しく作成したJMSサーバーを割り当てます(SOAJMSServer_auto_3など)。

7. 「保存」をクリックします。

これを、次の表に記載されている各JMSモジュールに対して実行します。

JMSモジュール

JMSサーバー

BPMJMSModule

BPMJMSServer_auto_n

JRFWSAsyncJmsModule

JRFWSAsyncJmsServer_auto_n

OIMJMSModule

OIMJMSServer_auto_n

SOAJMSModule

SOAJMSServer_auto_n

UMSJMSSystemResource

UMSJMSServer_auto_n

5. 第12.9項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従ってOracle Coherenceを構成します。

注意:

変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。

6. 管理コンソールのFactoryPropertiesフィールドを使用して、新しいサーバーでJMSアダプタを再構成します。「プロパティ」値の該当するセルをクリックして、次を入力します。

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
java.naming.provider.url=t3://soahostvhn1:8001,soahos2tvhn1:8001;
java.naming.security.principal=weblogic;
java.naming.security.credentials=weblogic1

7. 新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで、「環境」ノードを開いてから、「サーバー」ノードをクリックします。
「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列で、Oracle Identity ManagerまたはSOAサーバーの名前(ハイパーリンクで表示されています)をクリックします。

5. 選択したサーバーの「設定」ページが表示され、「構成」タブにデフォルト設定されます。

6. 「サービス」サブタブを開きます。

7. ページの「デフォルト・ストア」セクションで、共有記憶域にあるデフォルトの永続ストアへのパスを指定します。パスのディレクトリ構造は次のとおりです。
Oracle Identity Managerサーバー: ASERVER_HOME/tlogs

SOAサーバー: ASERVER_HOME/tlogs

8. 保存してアクティブ化するをクリックします。

8. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_SOAn管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。IDMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。
ホスト名検証を無効にする手順は次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列で「WLS_SOAn」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

9. WLS_OIMnの各管理対象サーバーでも、手順6a - 6hを繰り返してホスト名検証を無効にします。手順6dでは、表の「名前」列で「WLS_OIMn」を選択します。

10. クラスタ・アドレス・リストに新しいサーバーを追加します。

1. WebLogic管理コンソールの「ドメイン構造」ウィンドウで「環境」ノードを展開します。

2. 「クラスタ」をクリックします。「クラスタの概要」ページが表示されます。

3. クラスタ名oim_clusterをクリックします。「クラスタのプロパティ」ページが表示されます。

4. クラスタ・アドレス・リストに新しいOIM管理対象サーバーを追加します。

5. 「保存」をクリックします。

11. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

12. Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順に従います。

1. ブラウザを開き、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してOracle Enterprise Manager Fusion Middleware Controlにアクセスします。

2. 管理ユーザー資格証明を使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。

注意:

前述の手順を実行する際に、1つ以上のOracle Identity Manager管理対象サーバーを実行している必要があります。

3. 「Farm_IDMDomain」→「Identity and Access」→「OIM」→「oim(11.1.2.0.0)」を選択します。

4. メニューから「システムMBeanブラウザ」を選択するか、または右クリックしてこの項目を選択します。

5. 「アプリケーション」を選択し、定義済Mbean→「oracle.iam」を選択します。「サーバー」には「WLS_OIM1」、「アプリケーション」には「oim」を選択します。XML構成→「構成」を選択し、「XMLConfig.SOAConfig」→「SOAConfig」を選択します。

6. 新しいSOAサーバーのホストとポートでRmiurl属性の値を更新します。「適用」をクリックして、変更を保存します。

7. Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。これがアプリケーション・サーバーのURLです。この属性の値の例を次に示します。
cluster:t3://soa_cluster

13. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。

14. 管理コンソールから新しい管理対象サーバーを起動して、テストします。

1. クラスタ内の既存の管理対象サーバーを停止します。

2. 新規作成した管理対象サーバーであるWLS_SOAnが稼働していることを確認します。

3. 新しく作成した管理対象サーバー(http://vip:port/soa-infra)上のアプリケーションにアクセスします。アプリケーションは機能している必要があります。

15. 新しく作成した管理対象サーバーを、サーバー移行ができるように構成します。第14.6項「サーバー移行ターゲットの構成」の手順に従って、サーバー移行を構成します。

16. この新規サーバーのサーバー移行をテストします。新規サーバーの追加先となったノードで、次の手順を実行します。

1. 管理対象サーバーWLS_SOAnを停止します。
このためには、次のコマンドを実行します。

kill -9 pid

このコマンドでは、その管理対象サーバーのプロセスID (PID)を指定します。ノードのPIDを確認するには、次のコマンドを使用します。

ps -ef | grep WLS_SOAn

2. ノード・マネージャ・コンソールを参照します。WLS_SOA1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。これを再起動する前に、分離するまでノード・マネージャで30秒待ちます。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。

17.4.1.4 Oracle HTTP Serverのスケール・アップ

Web層には、Oracle HTTP Serverのインスタンスが実行されている1つのノードがすでにあります。既存のOracle HTTP Serverバイナリを使用して、新しいOracle HTTP Serverインスタンスを作成できます。Oracle HTTP Serverをスケール・アップするには、第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」の手順に従います。

1. 第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」の説明に従い、Oracle Fusion Middleware 11gのWeb層ユーティリティ構成ウィザードを使用してトポロジをスケール・アップします。

2. 既存のWeb層構成のORACLE_INSTANCE/config/OHS/component/moduleconf内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。

3. 新しいOracle HTTP Serverインスタンスのホスト情報とポート情報に基づいてロード・バランサを再構成します。

17.4.2 トポロジのスケール・アウト

トポロジをスケール・アウトする際は、新しいサーバーを新しいノードに追加します。このマニュアルで説明しているOracle Identity Managementトポロジのコンポーネントは、新しいノードに新しいサーバー・インスタンスを追加することでスケール・アウトできます。

この項で説明する手順では、新しいWebLogic管理対象サーバーを作成する方法を示します。トポロジに新しい管理対象サーバーを追加する場合は、その管理対象サーバーを追加した後で、Oracle HTTP Serverの構成ファイルをすべてのノードで更新し、既存のWebLogicクラスタ・ディレクティブにその新しいサーバーを追加する必要があります。

たとえば、Oracle Access Managerの新しいサーバーを追加する場合は、WEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconf/sso_vh.confを更新して、この新しい管理対象サーバーを含める必要があります。

sso_vh.confを次のように更新します。

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster
IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST3.mycompany.com:14100
</Location>

sso_vh.confを更新したら、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従ってOracle HTTPサーバーを再起動します。サービスの停止を防止するため、再起動は順次的に行うことをお薦めします。

この項には次のトピックが含まれます:

- 第17.4.2.1項「Oracle Unified Directoryのスケール・アウト」

- 第17.4.2.2項「Oracle Access Manager 11gのスケール・アウト」

- 第17.4.2.3項「Oracle Identity Managerのスケール・アウト」

- 第17.4.2.4項「Oracle HTTP Serverのスケール・アウト」

17.4.2.1 Oracle Unified Directoryのスケール・アウト

ディレクトリにはOracle Unified Directoryの2つのノード(IDMHOST1とIDMHOST2)があり、それぞれでOracle Unified Directoryインスタンスが実行されます。Oracle Unified Directoryのインスタンスは、次に示すように、構成に新しいノードを追加することによってスケール・アウトできます。

1. 第7.3項「Oracle Unified Directoryのインストール」の手順に従って、新しいホストにOUDバイナリをインストールします。

2. 第7.4.3項「IDMHOST2での追加のOracle Unified Directoryインスタンスの構成」の手順に従います。

3. 新しいOracle Unified Directoryインスタンスにおけるホストとポートの情報でロード・バランサを再構成します。

17.4.2.2 Oracle Access Manager 11gのスケール・アウト

スケール・アウトはスケール・アップとよく似ていますが、最初に新しいノードにソフトウェアをインストールする必要がある点が異なります。

新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic ServerやIdentity Managementのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。

注意:

共有記憶域を使用している場合は、その共有記憶域に新しいホストがアクセスできるようにします。

1. 新しいノードで、Identity and Access Managementのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできるようにします。

2. ミドルウェア・ホーム・リストを更新するには、IAM_MW_HOME/bea/beahomelistファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、IAM_MW_HOME/product/fmwをこのファイルに追加します。

3. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

4. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」ノード→「サーバー」を開きます。「サーバーのサマリー」ページが表示されます。

5. 「ロックして編集」を「チェンジ・センター」メニューでクリックします。

6. 拡張するホスト上の既存サーバーを選択します(例: WLS_OAM1)。

7. 「クローンの作成」をクリックします。

8. 次の情報を入力します。

- サーバー名: サーバーの新しい名前です。たとえば、WLS_OAM3です。

- サーバー・リスニング・アドレス: 管理対象サーバーを実行するホストの名前です。

- サーバー・リスニング・ポート: 新しい管理対象サーバーが使用するポート。このポートはホスト内で一意にする必要があります。

9. 「OK」をクリックします。

10. 新規作成したサーバーである「WLS_OAM3」をクリックします。

11. SSLリスニング・ポートを設定します。このポートは、管理対象サーバーが実行されるホスト上で一意である必要があります。

12. 「保存」をクリックします。

13. 新しい管理対象サーバーのホスト名検証を無効にします。WLS_OAM3管理対象サーバーの起動と検証を行う前に、ホスト名検証を無効にする必要があります。IDMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。
新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。ホスト名の検証を無効化する手順は、次のとおりです。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「環境」ノードを「ドメイン構造」ペインで開きます。

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列で「WLS_OAM3」を選択します。サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

14. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

15. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバーを再起動します。

16. 次のコマンドを使用してIDMHOST1上のドメインをパックします。

pack.sh -domain=ASERVER_HOME -template=/tmp/IDMDomain.jar -template_name="OAM Domain" -managed=true

pack.shスクリプトは、ORACLE_COMMON_HOME/common/binにあります。

17. 次のコマンドを使用して新しいホスト上でドメインを解凍します。

unpack.sh -domain=MSERVER_HOME -template=/tmp/IDMDomain.jar -app_dir=MSERVER_HOME/applications

unpack.shスクリプトは、ORACLE_COMMON_HOME/common/binにあります。

18. ノード・マネージャを起動して、プロパティ・ファイルを更新します。

1. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の手順に従い、ノード・マネージャを起動および停止します。

2. ORACLE_COMMON_HOME/common/binにあるスクリプトsetNMProps.shを実行して、ノード・マネージャのプロパティ・ファイルを更新します。たとえば、次のように指定します。

cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

3. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の手順に従い、ノード・マネージャを再度起動します。

Oracle Access Managerに新しい管理対象サーバーを登録します。この時点で、新しい管理対象サーバーをOracle Access Managerサーバーとして構成する必要があります。このためには、Oracle OAMコンソールで次の手順を実行します。

1. oamadminユーザーでOAMコンソールにログインします。第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用します。

2. 「システム構成」タブをクリックします。

3. 「サーバー・インスタンス」をクリックします。

4. 「作成」を「アクション」メニューで選択します。

5. 次の情報を入力します。

- サーバー名: WLS_OAM3

- ホスト: サーバーを実行しているホストIDMHOST3。

- ポート: 管理対象サーバーが作成された際に割り当てられたリスニング・ポート。

- OAMプロキシ・ポート: Oracle Access Managerプロキシの実行対象とするポート。これは当該ホストについて一意のポートです。

- プロキシ・サーバーID: AccessServerConfigProxy

- モード: 既存のOracle Access Managerサーバーが動作しているモードに応じて、「オープン」または「簡易」を選択します。

6. 「適用」をクリックします。

新しく作成したOracle Access Managerサーバーを使用する可能性のあるすべてのWebゲート・プロファイル(Webgate_IDMやIAMSuiteAgent)にそのサーバーを追加します。

たとえば、Oracle Access ManagerサーバーをWebgate_IDMに追加するには、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してOAMコンソールにアクセスし、次の手順を実行します。

1. 第9.4項「アイデンティティ・ストアの準備」で作成したOracle Access Manager管理ユーザーとしてログインします。

2. 「システム構成」タブをクリックします。

3. 「Access Manager」→「SSOエージェント」→「OAMエージェント」を開きます。

4. フォルダを開くアイコンをクリックして「検索」をクリックします。
Webゲート・エージェントWebgate_IDMが表示されます。

5. エージェントWebgate_IDMをクリックします。

6. 「アクション」メニューで「編集」を選択します。

7. 「プライマリ・サーバー」リスト(これがセカンダリ・サーバーである場合は「セカンダリ・サーバー」リスト)で「+」をクリックします。

8. 「サーバー」リストから、新しく作成した管理対象サーバーを選択します。

9. 「最大接続数」を4に設定します。

10. 「適用」をクリックします。

IAMSuiteAgentおよび、使用しているその他すべてのWebゲートで、手順5 - 10を繰り返します。

Web層を更新します。これで新しい管理対象サーバーが作成され、起動されたので、Web層から各種の要求がそのサーバーに送られるようになります。ただし、ベスト・プラクティスは、新しい管理対象サーバーが作成されたことをWebサーバーに通知することです。

これを行うには、各Web層でファイルsso_vh.confを更新します。このファイルは、ディレクトリWEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconfにあります。

新しいサーバーをこのファイル内のWebLogicClusterディレクティブに追加します。次に変更前の例を示します。

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100
</Location>

変更後は次のようになります。

<Location /oam>
SetHandler weblogic-handler
WebLogicCluster IDMHOST1.mycompany.com:14100,IDMHOST2.mycompany.com:14100,IDMHOST3.mycompany.com:14100
</Location>

17.4.2.3 Oracle Identity Managerのスケール・アウト

トポロジをスケール・アウトする際は、OIMおよびSOAとともに構成された新しい管理対象サーバーを新しいノードに追加します。

この項の手順を実行する前に、次の要件を満たしていることを確認してください。

- OIMおよびSOAとともに構成された管理対象サーバーが実行されている既存のノードがトポロジ内に存在していること。

- 新しいノードがWebLogic Server、OIMおよびSOAの既存のホーム・ディレクトリにアクセスできること。
新しい管理対象サーバーWLS_SOAまたはWLS_OIMを作成するには、共有記憶域内の既存のインストールを使用します。新しい場所にWebLogic Server、OIMまたはSOAのバイナリをインストールする必要はありませんが、新しいノードでドメイン構成をブートストラップするためにパックと解凍を実行する必要があります。

注意:

- 共有記憶域に既存のインストールが存在しない場合は、第12.9項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従って、新しいノードにWebLogic Server、IAMおよびSOAをインストールする必要があります。

- ORACLE_HOMEまたはWL_HOMEが異なるノードの複数のサーバーによって共有されている場合、これらのノードのOracleインベントリとMiddlewareホーム・リストを常に最新の状態にして、インストールとパッチ・アプリケーションの整合性を確保することをお薦めします。ノード内のoraInventoryを更新して、共有記憶域内のインストール内容をそれにアタッチするには、次のスクリプトを使用します。
OIM_ORACLE_HOME/oui/bin/attachHome.sh

- Middlewareホームの一覧を更新してWL_HOMEを追加または削除するには、user_home/bea/beahomelistファイルを編集します。次の手順を参照してください。

次の手順に従って、トポロジをスケール・アウトします。

1. 新しいノードで、Oracle Fusion Middlewareのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできるようにします。

2. 共有記憶域内のORACLE_BASEをローカルOracleインベントリにアタッチするには、次のコマンドを実行します。

cd IAM_MW_HOME/product/fmw/iam/oui/bin
/attachHome.sh -jreLoc JAVA_HOME

3. ミドルウェア・ホーム・リストを更新するには、IAM_MW_HOME/bea/beahomelistファイルを作成して(別のWebLogicがそのノードにインストールされている場合は編集します)、IAM_MW_HOME/product/fmwをこのファイルに追加します。

4. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic管理コンソールにログインします。

5. 使用する新しいノード用の新しいマシンを作成して、そのマシンをドメインに追加します。

6. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPアドレスをマップします。

7. Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーWLS_OIM1およびWLS_SOA1を新しい管理対象サーバーにクローニングします。それらの管理対象サーバーに、それぞれWLS_SOAnおよびWLS_OIMnという名前を付けます。nは数字です。

注意:

これらの手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。

8. 新しい管理対象サーバーのリスニング・アドレスにホスト名またはIPアドレスを割り当てます。

9. 管理対象サーバーを新しく作成したマシンに割り当てます。

10. このサーバーに対してサーバー移行を実行する予定の場合は(これをお薦めします)、これはサーバーのVIPアドレス(別称: 浮動IPアドレス)である必要があります。このVIPアドレスは、既存の管理対象サーバーで使用されているものとは異なっている必要があります。

11. 新しい管理対象サーバー上に、SOA、Oracle Identity Manager、UMSおよびBPMそれぞれのJMSサーバーを作成します。この操作は次のように実行します。

1. WebLogic管理コンソールにログインし、「サービス」→「メッセージング」→「JMSサーバー」に移動します。

2. 「新規」をクリックします。

3. 「名前」に、BPMJMSServer_auto_3などの値を入力します。

4. 「新しいファイル・ストアの作成」をクリックします。

5. リストからFileStoreを選択します。

6. 「次へ」をクリックします。

7. 「名前」に、BPMJMSFileStore_3などの値を入力します。

8. 次の値を入力します。
ターゲット: 現在作成している新しいサーバー。

ディレクトリ: ASERVER_HOME/jms/BPMJMSFileStore_3

9. 「OK」をクリックします。

10. 「JMSサーバー」画面に戻り、新しく作成したファイル・ストアをリストから選択します。

11. 「次へ」をクリックします。

12. 次の画面で、「ターゲット」を作成しているサーバーに設定します。

13. 「終了」をクリックします。

作成する管理対象サーバーに応じて、次のJMSキューを作成します。

サーバー

JMSサーバー名

ファイル・ストア名

ディレクトリ

ターゲット

WLS_SOAn

BPMJMSServer_auto_n

BPMJMSFileStore_n

ASERVER_HOME/jms/BPMJMSFileStore_n

WLS_SOAn

WLS_SOAn

SOAJMSServer_auto_n

SOAJMSFileStore_n

ASERVER_HOME/jms/SOAJMSFileStore_n

WLS_SOAn

WLS_SOAn

UMSJMSServer_auto_n

UMSJMSFileStore_n

ASERVER_HOME/jms/UMSJMSFileStore_n

WLS_SOAn

WLS_OIMn

OIMJMSServer_auto_n

OIMJMSFileStore_n

ASERVER_HOME/jms/OIMJMSFileStore_n

WLS_OIMn

WLS_OIMn

JRFWSAsyncJmsServer_auto_n

JRFWSAsyncJmsServer_n

ASERVER_HOME/jms/JRFWSAsyncJmsServerJMSFileStore_n

WLS_OIMn

12. 次の手順を実行して、新しく作成したJMSキューを既存のJMSモジュールに追加します。

1. WebLogic管理コンソールにログインします。

2. 「サービス」→「メッセージング」→「JMSモジュール」に移動します。

3. SOAJMSModuleなどのJMSモジュールをクリックします。

4. 「サブデプロイメント」タブをクリックします。

5. 表示されたサブ・デプロイメントをクリックします。

注意:

このサブデプロイメント・モジュール名は、JMSServerNameXXXXXXという形式のランダムな名前で、構成ウィザードJMS構成から生成されます。

6. 新しく作成したJMSサーバーを割り当てます(SOAJMSServer_auto_3など)。

7. 「保存」をクリックします。

これを、次の表に記載されている各JMSモジュールに対して実行します。

JMSモジュール

JMSサーバー

BPMJMSModule

BPMJMSServer_auto_n

JRFWSAsyncJmsModule

JRFWSAsyncJmsServer_auto_n

OIMJMSModule

OIMJMSServer_auto_n

SOAJMSModule

SOAJMSServer_auto_n

UMSJMSSystemResource

UMSJMSServer_auto_n

13. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

14. pack、scpおよびunpackコマンドを使用して、ドメインのバックアップを作成します。これを行うには、次の手順を実行します。

1. IDMHOST1上でpackコマンドを実行して、テンプレートを作成します。

cd ORACLE_COMMON_HOME/common/bin
./pack.sh -managed=true -domain=ASERVER_HOME -template=/templates/oim_domain.jar -template_name="OIM Domain"

2. IDMHOST1上でscpコマンドを実行して、作成されたテンプレート・ファイルをIDMHOSTnにコピーします。例:

scp /templates/oim_domain.jar IDMHOSTN:/templates/oim_domain.jar

3. 次のようにIDMHOSTn上でunpackコマンドを実行し、テンプレートを管理対象サーバーのドメイン・ディレクトリに解凍します。

cd ORACLE_COMMON_HOME/oracle_common/bin
./unpack.sh -domain=MSERVER_HOME -template=/templates/oim_domain.jar -app_dir=MSERVER_HOME/applications

15. 第12.9項「コンポジットのデプロイでのOracle Coherenceの構成」の説明に従ってOracle Coherenceを構成します。

注意:

変更の必要があるのは、サーバーのlocalhostフィールドのみです。次に示すlocalhostを、追加された新しいサーバーのリスニング・アドレスに置き換えます。

16. Oracle Enterprise Manager Fusion Middleware Controlを使用して、SOAのホストとポートを更新します。次の手順に従います。

1. ブラウザを開き、第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用してOracle Enterprise Manager Fusion Middleware Controlにアクセスします。

2. WebLogic管理アカウントweblogic_idmを使用してOracle Enterprise Manager Fusion Middleware Controlにログインします。

注意:

前述の手順を実行する際に、1つ以上のOracle Identity Manager管理対象サーバーを実行している必要があります。

3. 「Farm_IDMDomain」→「Identity and Access」→「OIM」→「oim(11.1.2.0.0)」を選択します。

4. メニューから「システムMBeanブラウザ」を選択するか、または右クリックしてこの項目を選択します。

5. 「アプリケーション」を選択し、定義済Mbean→「oracle.iam」を選択します。「サーバー」には「WLS_OIM1」、「アプリケーション」には「oim」を選択します。XML構成→「構成」を選択し、「XMLConfig.SOAConfig」→「SOAConfig」を選択します。

6. 新しいSOAサーバーのホストとポートでRmiurl属性の値を更新します。「適用」をクリックして、変更を保存します。

7. Rmiurl属性は、SOA管理対象サーバーにデプロイされたSOA EJBにアクセスするために使用されます。これがアプリケーション・サーバーのURLです。この属性の値の例を次に示します。
cluster:t3://soa_cluster

17. クラスタ・アドレス・リストに新しいサーバーを追加します。

1. WebLogic管理コンソールの「ドメイン構造」ウィンドウで「環境」ノードを展開します。

2. 「クラスタ」をクリックします。「クラスタの概要」ページが表示されます。

3. クラスタ名oim_clusterをクリックします。「クラスタのプロパティ」ページが表示されます。

4. クラスタ・アドレス・リストに新しいOIM管理対象サーバーを追加します。

5. 「保存」をクリックします。

6. この手順を繰り返して、すべての新しいSOA管理対象サーバーをsoa_clusterアドレス・リストに追加します。

18. 新しいサーバーのTX永続ストアを構成します。共有記憶域に関する推奨事項に記載されているように、他のノードから参照可能な場所にする必要があります。
管理コンソールで、「Server_name」→「サービス」タブを選択します。「デフォルト・ストア」の下の「ディレクトリ」に、デフォルト永続ストアのデータ・ファイルを格納するフォルダのパスを入力します。

19. 新しい管理対象サーバーのホスト名検証を無効にします。管理対象サーバーWLS_SOAnおよびWLS_OIMnを起動して検証する前に、ホスト名検証を無効にする必要があります。IDMHOSTn上のノード・マネージャとOracle WebLogic管理サーバー間の通信用のサーバー証明書を構成した後で、ホスト名検証を再び有効にできます。新しいサーバーのクローン元となったソース・サーバーで、ホスト名の検証がすでに無効化されている場合、ホスト名の検証の設定はクローンされたサーバーに伝播されるので、これらの手順は不要です。
WLS_SOAnのホスト名検証を無効化する手順は次のとおりです。

1. 「環境」ノードを「ドメイン構造」ウィンドウで開きます。

2. Oracle WebLogic Server管理コンソールにログインします。

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. 表の「名前」列で「WLS_SOAn」を選択します。
サーバーの「設定」ページが表示されます。

5. 「SSL」タブをクリックします。

6. 「詳細」をクリックします。

7. 「ホスト名の検証」を「なし」に設定します。

8. 「保存」をクリックします。

WLS_OIMnのホスト名検証を無効にするには、手順dで「名前」列にWLS_OIMnを選択し、それ以外は同じ手順を繰り返します。

20. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

21. 新しいノード上でノード・マネージャを起動します。ノード・マネージャを起動するには、既存ノードの共有記憶域内のインストール内容を使用して、次のように新しいノードのホスト名をパラメータとして渡してノード・マネージャを起動します。

WL_HOME/server/bin/startNodeManager.sh

22. Oracle WebLogic Server管理コンソールから、新しい管理対象サーバーを起動してテストします。

1. クラスタ内の既存の管理対象サーバーをすべて停止します。

2. 新しく作成した管理対象サーバーであるWLS_SOAnとWLS_OIMnが実行されていることを確認します。

3. 新しく作成した管理対象サーバー上のアプリケーションにアクセスします(http://vip:port/soa-infraおよびhttp://vip:port/oim)。アプリケーションが機能している必要があります。

23. 新しい管理対象サーバーのサーバー移行を構成します。

注意:

この新しいノードでは既存の共有記憶域のインストール内容が使用されているため、このノードではすでにノード・マネージャが使用されているとともに、ネットマスク、インタフェースおよびwlsifconfigスクリプトのスーパーユーザー権限が含まれたサーバー移行向けに構成された環境が使用されています。新しいノードには、すでに新しい管理対象サーバーの浮動IPアドレスが存在します。

次の手順に従ってサーバー移行を構成します。

1. 管理コンソールにログインします。

2. 左側のペインで「環境」を開き、「サーバー」を選択します。

3. 移行を構成する対象となるサーバー(ハイパーリンクとして表示)を表の「名前」列から選択します。そのサーバーの「設定」ページが表示されます。

4. 「移行」タブをクリックします。

5. 「移行の構成」セクションの「使用可能」フィールドで、移行を有効にするマシンを選択して、右矢印をクリックします。

注意:

新しいサーバーの移行ターゲットとして、最も負荷が小さいマシンを指定してください。このノードで追加の管理対象サーバーを維持するのに十分なリソースを確保できるように、必要なキャパシティ・プランニング をあらかじめ行ってください。

6. 「サーバーの自動移行を有効化」オプションを選択します。これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

7. 「保存」をクリックします。

8. 管理サーバー、管理対象サーバーおよびノード・マネージャを再起動します。

9. 新しいサーバーWLS_SOAnおよびWLS_OIMnのサーバー移行をテストするには、次の手順を実行します。
1. 次のコマンドを入力し、WLS_SOAn管理対象サーバーのPIDを確認します。

ps -ef | grep WLS_SOAn

2. 新しいサーバーを追加したノードで次のコマンドを入力し、WLS_SOAn管理対象サーバーを強制終了します。

kill -9 pid

3. ノード・マネージャ・コンソールを参照します。WLS_SOA1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。

4. ノード・マネージャがWLS_SOAnの2回目の再起動を試行するまで待機します。これを再起動する前に、分離するまでノード・マネージャで30秒待ちます。

5. ノード・マネージャがサーバーを再起動した後で、そのサーバーをもう一度停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャでログに記録されます。

6. WLS_OIMnに関しても、手順1から5を繰り返します。

17.4.2.4 Oracle HTTP Serverのスケール・アウト

Web層には2つのノードがあり、それぞれOracle HTTP Serverインスタンスが実行されています。Oracle HTTP Serverを実行するように構成された新しいノードをWeb層に追加することで、Oracle HTTP Serverのコンポーネントをスケール・アウトできます。Oracle HTTP Serverをスケール・アウトするには、次の手順を実行します。

1. 第10.2.3項「Oracle HTTP Serverのインストール」の手順を実行します。または、共有記憶域を使用している場合は、新しいノード上で既存のミドルウェア・ホームをマウントします。

2. 第10章「エンタープライズ・デプロイメント用のOracle Web層のインストールおよび構成」の手順を実行します。

3. 既存のWeb層構成のWEB_ORACLE_INSTANCE/config/OHS/component_name/moduleconf内に作成されたすべてのファイルを、新しいWeb層構成にコピーします。

4. このトポロジでシングル・サインオンを有効にしている場合は、第15.7項「Webゲート11gのインストールと構成」の説明に従って、シングル・サインオンのWeb層構成を更新する必要があります。

5. 新しいOracle HTTP Serverインスタンスのホスト情報とポート情報に基づいてロード・バランサを再構成します。

17.5 アイデンティティ管理の監査

Oracle Fusion Middleware監査フレームワークは、Oracle Fusion Middleware 11gで追加された新しいサービスであり、ミドルウェア製品ファミリの集中監査フレームワークです。このフレームワークでは、Oracle Platform Security Services (OPSS)やOracle Web Servicesなどのプラットフォーム・コンポーネントに対して監査サービスが提供されます。また、これは、Oracle固有のJavaEEコンポーネントをはじめ、様々なJavaEEアプリケーションのフレームワークとしても機能します。Java EEアプリケーションは、アプリケーション固有の監査イベントを作成できます。ミドルウェアのOracleコンポーネントのうちJavaEE以外のもの、たとえばCやJavaSEのコンポーネントについても、JavaEEアプリケーションと同様、エンドツーエンドのフレームワーク構造を実現します。

図17-1は、Oracle Fusion Middleware監査フレームワーク・アーキテクチャの概要図です。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。

図17-1 監査イベント・フロー

Oracle Fusion Middleware監査フレームワークは、次の主要コンポーネントで構成されます。

- 監査API
このAPIは、Oracle Fusion Middleware監査フレームワークと統合される監査対応の任意のコンポーネントのために、監査フレームワークによって提供されます。これらのAPIは、実行中にアプリケーション・コード内で発生している特定イベントに関する必要な情報を監査するためにアプリケーションによってコールします。アプリケーションはこのインタフェースにより、監視対象イベントのコンテキストの提供に必要な、ユーザー名やその他属性などのイベント詳細を指定できます。

- 監査イベントと構成
Oracle Fusion Middleware監査フレームワークでは、アプリケーションの監査イベントに簡単にマッピングできる一連の汎用イベントが提供されます。それらの汎用イベントには、認証などの共通のイベントも含まれています。このフレームワークでは、アプリケーションでアプリケーション固有イベントも定義できます。

これらのイベントの定義と構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成は、Enterprise Manager (UI)およびWLST(コマンドライン・ツール)で更新できます。

- 監査バスストップ
バスストップは、監査リポジトリに送られる前の監査データを含むローカル・ファイルです。データベース・リポジトリが構成されていない場合には、バスストップ・ファイルをファイル・ベースの監査リポジトリとして使用できます。バスストップ・ファイルは、問い合せて特定の監査イベントを簡単に見つけることができるシンプルなテキスト・ファイルです。DBベースのリポジトリが作成されると、バスストップはコンポーネントと監査リポジトリの間で仲介役を勤めます。ローカル・ファイルは構成された周期で定期的に監査リポジトリにアップロードされます。

- 監査ローダー
名前が示すように、監査ローダーは監査バスストップから監査リポジトリにファイルをロードします。プラットフォームおよびJavaEEアプリケーション監査の場合、監査ローダーはJavaEEコンテナの起動と同時に起動されます。システム・コンポーネントの場合、監査ローダーは定期的に発生するプロセスです。

- 監査リポジトリ
監査リポジトリには、リポジトリ作成ユーティリティ(RCU)によって作成された定義済Oracle Fusion Middleware監査フレームワーク・スキーマが含まれます。一度構成されると、すべての監査ローダーはリポジトリを認識し、それに定期的にデータをアップロードします。監査リポジトリ内の監査データは累積され時間の経過とともに増加します。監査ストアは、他のアプリケーションによって使用される運用データベースではなく、監査専用のスタンドアロン型RDBMSであるのが理想的です。高可用性構成の場合、監査データ・ストアとしてOracle Real Application Cluster (RAC)データベースの使用をお薦めします。

- Oracle Business Intelligence Publisher
監査リポジトリ内のデータは、Oracle Business Intelligence Publisherの定義済レポートにより出力されます。このレポートでは、監査データを様々な条件に基づいてドリルダウンできます。例:

- ユーザー名

- 時間範囲

- アプリケーション・タイプ

- 実行コンテキストID (ECID)

Oracle Fusion Middleware監査フレームワークの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「Oracle Fusion Middleware監査フレームワークの概要」を参照してください。

Oracle Fusion Middleware監査フレームワーク用にリポジトリを構成する方法の詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査の構成と管理」を参照してください。

EDGトポロジには、Oracle Fusion Middleware監査フレームワーク構成が含まれていません。監査データをバスストップ・ファイルに生成する機能と監査ローダーの構成は、製品がインストールされた後に使用可能になります。主な留意点は、監査データを保管する監査データベース・リポジトリです。監査データのボリュームと履歴特性により、運用中のストアや他のミドルウェア・コンポーネントによって使用されるストアとは別のデータベースを使用することを強くお薦めします。

17.6 バックアップとリカバリの実行

ほとんどのバックアップでは、UNIXのtarコマンドを使用できます。一般的な使用方法は次のとおりです。

tar -cvpf BACKUP_LOCATION/backup_file.tar directories

また、リカバリでもUNIXのtarコマンドを使用できます。一般的な使用方法は次のとおりです。

tar -xvf BACKUP_LOCATION/backup_file.tar

データベースのバックアップとリカバリでは、データベース・ユーティリティのRMANを使用できます。このコマンドの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

この項には次のトピックが含まれます:

- 第17.6.1項「ベースライン・バックアップの実行」

- 第17.6.2項「ランタイム・バックアップの実行」

- 第17.6.3項「インストール時および構成時のバックアップの実行」

17.6.1 ベースライン・バックアップの実行

システムを構築するとき、およびOracleバイナリなどの静的なアーティファクトを更新するためのパッチを適用するときに、ベースライン・バックアップを実行します。

ベースライン・バックアップを実行した後は、ランタイム・バックアップも実行します。

表17-2 Identity Managementエンタープライズ・デプロイメントでバックアップする静的アーティファクト

タイプ

場所

タイプ

コメント

データベース

ORACLE_HOME

GridのORACLE_HOME

ファイル・コピー

詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

ミドルウェア・ホーム

IAM_MW_HOME

OIM_MW_HOME脚注 1

DIR_MW_HOME脚注 2

ファイル・コピー

共有記憶域にあるため、1つのホストでバックアップすることのみ必要です。

Webミドルウェア・ホーム

ミドルウェア・ホーム: WEB_MW_HOME

ファイル・コピー

ローカル記憶域に置かれます。それぞれのWEBHOSTを個別にバックアップします。

インストール関連

ORACLE_BASE/orainventory

/etc/oratab、/etc/oraInst.loc

HOME/bea/beahomelist

ファイル・コピー

ローカル記憶域に置かれます。それぞれのホストを個別にバックアップします。

ロード・バランサ

ファイル・コピー

ロード・バランサの構成をバックアップします。ベンダーのドキュメントを参照してください。

サーバー

オペレーティング・システムをバックアップします。ベンダーのドキュメントを参照してください。

脚注 1 分割ドメインのみ

脚注 2 Oracle Internet DirectoryまたはOracle Virtual Directoryのインストールのミドルウェア・ホーム。Oracle Identity Managementのインストールと構成については、このガイドでは扱っていません。

注意:

ロード・バランサの構成もバックアップすることをお薦めします。その方法については、ベンダーのドキュメントを参照してください。

Oracle Fusion Middlewareコンポーネントのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

17.6.2 ランタイム・バックアップの実行

ランタイム・バックアップは継続的に実行します。ランタイム・バックアップには、データベース内のデータ、ドメイン構成情報、LDAPディレクトリ内のアイデンティティ情報など、頻繁に変更される項目の情報が含まれます。

表17-3 Identity Managementエンタープライズ・デプロイメントでバックアップするランタイム・アーティファクト

タイプ

場所

タイプ

コメント

データベース

データ

RMAN

詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

Oracle Unified Directory

OUD_ORACLE_INSTANCE

Oracle Unified Directoryのデータ

ファイル・コピー

Oracle Unified Directoryのバックアップ

ローカル記憶域に置かれます。それぞれのWEBHOSTを個別にバックアップします。

詳細は、『Oracle Fusion Middleware Oracle Unified Directory管理者ガイド』を参照してください。

コールド・バックアップの実行では、OUD_INSTANCE_HOMEのバックアップで十分です。

Oracle Internet Directory

Oracle Internet Directoryのインスタンス

データベース内のOracle Internet Directoryのデータ

ファイル・コピー

RMAN

詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

Oracle Virtual Directory

Oracle Virtual Directoryのインスタンス

ファイル・コピー

詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

サード・パーティのLDAP

バイナリ

LDAPデータ

ベンダーのドキュメントを参照してください。

ドメイン・ホーム

ASERVER_HOME

MSERVER_HOME

ファイル・コピー

ASERVER_HOMEは共有記憶域にあるため、1つのホストでバックアップすることのみ必要です。

MSERVER_HOMEはローカル記憶域に置かれます。それぞれのホストを個別にバックアップします。

Oracle HTTP Server

WEB_ORACLE_INSTANCE

ファイル・コピー

WEB_ORACLE_INSTANCEはローカル記憶域に置かれます。それぞれのWEBHOSTを個別にバックアップします。

17.6.3 インストール時および構成時のバックアップの実行

ベスト・プラクティスとしては、インストールと各層の構成が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。インストールが正常に行われたことを確認したら、バックアップを作成します。これは、後の手順で問題が発生した場合に即座にリストアするための迅速なバックアップになります。バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

この項には次のトピックが含まれます:

- 第17.6.3.1項「ミドルウェア・ホームのバックアップ」

- 第17.6.3.2項「LDAPディレクトリのバックアップ」

- 第17.6.3.3項「データベースのバックアップ」

- 第17.6.3.4項「WebLogicドメインのバックアップ」

- 第17.6.3.5項「Web層のバックアップ」

17.6.3.1 ミドルウェア・ホームのバックアップ

新しいミドルウェア・ホームを作成する場合、またはミドルウェア・ホームにコンポーネントを追加する場合は、必ずミドルウェア・ホームをバックアップします。

17.6.3.2 LDAPディレクトリのバックアップ

LDAPのデータを更新する操作を実行する場合は、必ずディレクトリ・コンテンツをバックアップします。

この項には次のトピックが含まれます:

- 第17.6.3.2.1項「Oracle Unified Directoryのバックアップ」

- 第17.6.3.2.2項「Oracle Internet Directoryのバックアップ」

- 第17.6.3.2.3項「Oracle Virtual Directoryのバックアップ」

- 第17.6.3.2.4項「サード・パーティのディレクトリのバックアップ」

17.6.3.2.1 Oracle Unified Directoryのバックアップ

Oracle Unified Directoryをバックアップするには、次の手順を実行します。

1. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle Unified Directoryのインスタンスを停止します。

2. 各ホスト上のOracle Unified Directoryインスタンスのディレクトリをバックアップします。

3. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle Unified Directoryのインスタンスを再起動します。

17.6.3.2.2 Oracle Internet Directoryのバックアップ

Oracle Internet Directoryのインスタンスをバックアップするには、次の手順を実行します。

1. OID_ORACLE_INSTANCE/binディレクトリにあるopmnctlを使用してインスタンスを停止します。

OID_ORACLE_INSTANCE/bin/opmnctl stopall

2. Oracle Internet Directoryのデータをホストしているデータベース、および各ホスト上のOracle Internet Directoryインスタンス・ホームをバックアップします。

3. OID_ORACLE_INSTANCE/binディレクトリにあるopmnctlを使用してインスタンスを起動します。

OID_ORACLE_INSTANCE/bin/opmnctl startall

17.6.3.2.3 Oracle Virtual Directoryのバックアップ

Oracle Virtual Directoryのインスタンスをバックアップするには、次の手順を実行します。

1. OVD_ORACLE_INSTANCE/binディレクトリにあるopmnctlを使用してインスタンスを停止します。

OVD_ORACLE_INSTANCE/bin/opmnctl stopall

2. 各LDAPホスト上のOracle Virtual Directoryインスタンス・ホームをバックアップします。

3. OVD_ORACLE_INSTANCE/binディレクトリにあるopmnctlを使用してインスタンスを起動します。

OVD_ORACLE_INSTANCE/bin/opmnctl startall

17.6.3.2.4 サード・パーティのディレクトリのバックアップ

ディレクトリのバックアップの詳細は、オペレーティング・システムのベンダーのドキュメントを参照してください。

17.6.3.3 データベースのバックアップ

構成にコンポーネントを追加して作成する場合は、必ずIDMDBデータベースをバックアップします。このバックアップは、ドメインを作成した後、またはAccess Managerなどのコンポーネントを追加した後に実行します。

17.6.3.4 WebLogicドメインのバックアップ

WebLogicドメインをバックアップするには、次の手順を実行します。

1. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、ドメインで実行されているWebLogic管理サーバーとすべての管理対象サーバーを停止します。

2. 共有記憶域のASERVER_HOMEディレクトリをバックアップします。

3. 各ホストのMSERVER_HOMEディレクトリをバックアップします。

17.6.3.5 Web層のバックアップ

Web層をバックアップするには、次の手順を実行します。

1. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを停止します。

2. WEB_ORACLE_INSTANCEをバックアップします。

3. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、Oracle HTTP Serverを起動します。

17.7 エンタープライズ・デプロイメントへのパッチ適用

この項では、Oracle Fusion Middlewareのパッチ・ファイルを適用する方法、および最小限の停止時間でOracle Identity Managementコンポーネントにパッチを適用する方法を説明します。

この項には次のトピックが含まれます:

- 第17.7.1項「Oracle Fusion Middlewareソース・ファイルへのパッチ適用」

- 第17.7.2項「Identity and Access Managementへのパッチ適用」

- 第17.7.3項「Oracle Unified Directoryのコンポーネントへのパッチ適用」

17.7.1 Oracle Fusion Middlewareソース・ファイルへのパッチ適用

Oracle Fusion Middlewareソース・ファイルへのパッチ適用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

17.7.2 Identity and Access Managementへのパッチ適用

シングル・ドメインのトポロジでは、次のようにパッチを適用します。

IDMDomainのMW_HOME

- 共通のパッチ

- Oracle Access Managerのパッチ

- Oracle Identity Managerのパッチ

- IDMツールのパッチ

17.7.3 Oracle Unified Directoryのコンポーネントへのパッチ適用

最小限の停止時間でOracle Identity Managementコンポーネントにパッチを適用するには、次の指示に従うことをお薦めします。

1. LDAPのトラフィックをIDMHOST1からIDMHOST2にルーティングします。

2. パッチを適用するホスト(IDMHOST1)のOracle Unified DirectoryサーバーまたはOracle Virtual Directoryサーバーを停止します。

3. パッチを適用します。

4. Oracle Unified Directoryを再起動します。

5. パッチをテストします。

6. トラフィックを再びLDAPHOST1にルーティングします。

7. アプリケーションが正常に動作していることを確認します。

8. IDMHOST2のLDAPのトラフィックをIDMHOST1にルーティングします。

9. IDMHOST2に関しても手順2-5を繰り返します。

10. パッチを適用した両方のホスト(IDMHOST1とIDMHOST2)にトラフィックをルーティングします。

17.8 SQLのタイムアウトの防止

ほとんどの本番デプロイメント環境ではファイアウォールが使用されます。データベース接続は複数のファイアウォールにまたがって確立されるため、データベース接続がタイムアウトにならないようにファイアウォールを構成することをお薦めします。Oracle Real Application Cluster (Oracle RAC)については、データベース接続はOracle RAC VIPとデータベース・リスナー・ポートを使用して確立されます。ファイアウォールがこれらの接続をタイムアウトさせないように構成する必要があります。そのような構成が不可能な場合は、データベース・サーバー上のORACLE_HOME/network/admin/sqlnet.oraファイルで、SQLNET.EXPIRE_TIME=nというパラメータを設定します(nは分単位の時間)。この値を、ネットワーク・デバイス(ファイアウォール)の既知のタイムアウト値より小さい値に設定します。Oracle RACについては、このパラメータをすべてのOracleホーム・ディレクトリで設定します。

17.9 WebLogic管理サーバーの手動フェイルオーバー

この項では、管理サーバーをIDMHOST2にフェイルオーバーする方法と、これをIDMHOST1にフェイルバックする方法について説明します。

作成したすべてのドメインに同じ手順を適用できます。

この項には次のトピックが含まれます:

- 第17.9.1項「IDMHOST2への管理サーバーのフェイルオーバー」

- 第17.9.2項「IDMHOST2上での管理サーバーの起動」

- 第17.9.3項「Oracle HTTP Serverを使用したIDMHOST2へのアクセスの検証」

- 第17.9.4項「IDMHOST1への管理サーバーのフェイルバック」

17.9.1 IDMHOST2への管理サーバーのフェイルオーバー

あるノードで障害が発生した場合、管理サーバーを別のノードにフェイルオーバーできます。この項では、管理サーバーをIDMHOST1からIDMHOST2にフェイルオーバーする方法について説明します。

前提事項:

- 管理サーバーがADMINVHN.mycompany.comをリスニングし、任意のアドレスをリスニングしないように構成されている。第8.4項「構成ウィザードを実行してドメインを作成する方法」を参照してください。

- 管理サーバーはIDMHOST1からIDMHOST2にフェイルオーバーされ、この2つのノードに次のIPアドレスがある。

- IDMHOST1: 100.200.140.165

- IDMHOST2: 100.200.140.205

- ADMINVHN: 100.200.140.206
これは、管理サーバーが稼働している仮想IPアドレスで、IDMHOST1とIDMHOST2で使用可能なinterface:index (eth1:2など)に割り当てられています。

- 管理サーバーがIDMHOST1内で実行されるドメイン・ディレクトリは、共有記憶域にあり、IDMHOST2からもマウントされている。

注意:

IDMHOST2内のNMは、この時点ではドメインを制御しません。これは、unpack/nmEnrollがまだIDMHOST2上で実行されていないからです。ただし、AdminServerのフェイルオーバー、およびAdminServer自体の制御に対しては、ノード・マネージャは完全に機能します。

- Oracle WebLogic ServerおよびOracle Fusion Middlewareコンポーネントは前の章の説明のとおり、IDMHOST2にインストールされている。つまり、IDMHOST1に存在するIDM_ORACLE_HOMEとMW_HOMEのパスは、IDMHOST2でも使用できます。

次の手順は、管理サーバーを異なるノード(IDMHOST2)にフェイルオーバーする方法を示します。

Linux

1. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、管理サーバーを停止します。

2. IPアドレスを2番目のノードに移行します。

1. IDMHOST1で次のコマンドをrootとして実行します(ここでx:yはADMINVHN.mycompany.comが使用する現在のインタフェースです)。

/sbin/ifconfig x:y down

例:

/sbin/ifconfig eth0:1 down

2. IDMHOST2で次のコマンドを実行します。

/sbin/ifconfig interface:index IP_Address netmask netmask

例:

/sbin/ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0

注意:

使用するネットマスクおよびインタフェースがIDMHOST2の使用可能なネットワーク構成と一致することを確認します。

3. arpingを使用してルーティング表を更新します。例:

/sbin/arping -q -U -c 3 -I eth0 10.0.0.1

17.9.2 IDMHOST2上での管理サーバーの起動

次の手順を実行して、IDMHOST2上でノード・マネージャを起動します。

1. IDMHOST1上で、管理サーバー・ドメイン・ディレクトリをアンマウントします。例:

umount /u01/oracle

2. IDMHOST2で、管理サーバー・ドメイン・ディレクトリをマウントします。例:

mount /u01/oracle

3. 次のコマンドを使用してノード・マネージャを起動します。

cd WL_HOME/server/bin
./startNodeManager.sh

4. ノード・マネージャ・プロセスを強制終了してノード・マネージャを停止します。

注意:

この時点でのノード・マネージャの起動および停止は、ノード・マネージャを初めて実行するときにのみ必要です。起動および停止により、前もって定義されたテンプレートからプロパティ・ファイルが作成されます。次の手順では、そのプロパティ・ファイルにプロパティを追加します。

5. setNMProps.shスクリプトを実行して、ノード・マネージャを起動する前にStartScriptEnabledプロパティをtrueに設定します。

cd MW_HOME/oracle_common/common/bin
./setNMProps.sh

注意:

クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

6. 第17.1.5.3項「管理サーバーのノード・マネージャの起動」を参照して、ノード・マネージャを起動します。

7. IDMHOST2上で管理サーバーを起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

WLSTシェルで一度、次のコマンドを実行します。

nmConnect('Admin_User','Admin_Password', 'IDMHOST2','5556', 'IDMDomain','ASERVER_HOME')
nmStart('AdminServer')

注意:

WLSTのnmConnectコマンドのASERVER_HOMEにはフルパス名を使用します。

17.9.3 Oracle HTTP Serverを使用したIDMHOST2へのアクセスの検証

1. 次のアドレスを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://ADMINVHN.mycompany.com/console

ここで、7001は第B.3項のWLS_ADMIN_PORTに相当します。

2. 次のアドレスを使用してOracle Enterprise Managerのコンポーネントのステータスにアクセスし、検証できることを確認します。
http://ADMINVHN.mycompany.com/em

分割ドメイン・トポロジを使用しており、IDMHOST2で管理サーバーが実行されている場合は、同じ手順を実行してその管理サーバーにアクセスできることを確認します。

17.9.4 IDMHOST1への管理サーバーのフェイルバック

この手順では、管理サーバーをフェイルバックできる(つまり、IDMHOST2上で停止し、IDMHOST1上で実行できる)ことを確認します。これを行うには、次の手順に従って、ADMINVHNを元のIDMHOST1ノードに移行して戻します。

1. 管理サーバーが実行されていないことを確認してください。管理サーバーが実行中の場合、WebLogicコンソールから停止するか、またはコマンドstopWebLogic.shをASERVER_HOME/binから実行します。

2. IDMHOST2上で、管理サーバー・ドメイン・ディレクトリをアンマウントします。例:

umount /u01/oracle

3. IDMHOST1上で、管理サーバー・ドメイン・ディレクトリをマウントします。例:

mount /u01/oracle

4. IDMHOST2上のADMINVHN.mycompany.comの仮想IPアドレスを無効にして、IDMHOST2で次のコマンドをrootとして実行します。

/sbin/ifconfig x:y down

例:

/sbin/ifconfig eth0:1 down

5. IDMHOST1で次のコマンドを実行します。

/sbin/ifconfig interface:index IP_Address netmask netmask

例:

/sbin/ifconfig interface:index 100.200.140.206 netmask 255.255.255.0

注意:

使用するネットマスクおよびインタフェースがIDMHOST1の使用可能なネットワーク構成と一致することを確認します。

6. 次のコマンドを実行してルーティング表を更新します。

/sbin/arping -q -U -c 3 -I interface 100.200.140.206

たとえば、IDMHOST1から次のコマンドを実行します。

/sbin/arping -q -U -c 3 -I eth0 100.200.140.206

7. ノード・マネージャがまだIDMHOST1上で起動されていない場合は、第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って起動します。

8. IDMHOST1で管理サーバーを再起動します。

cd ORACLE_COMMON_HOME/common/bin
./wlst.sh

WLSTシェルが開始されたら、次のコマンドを実行します。

nmConnect(Admin_User,'Admin_Password, IDMHOST1,'5556','IDMDomain','ASERVER_HOME')
nmStart('AdminServer')

9. 次のアドレスを使用してOracle WebLogic Server管理コンソールにアクセスできることを確認します。
http://ADMINVHN.mycompany.com:7001/console

ここで、7001は第B.3項のWLS_ADMIN_PORTに相当します。

10. 次のアドレスを使用してOracle Enterprise Managerのコンポーネントのステータスにアクセスし、検証できることを確認します。
http://ADMINVHN.mycompany.com:7001/em

17.10 トラブルシューティング

この項では、このマニュアルで説明しているIdentity Managementエンタープライズ・デプロイメントで発生する可能性のある一般的な問題のトラブルシューティング方法を説明します。

この項には次のトピックが含まれます:

- 第17.10.1項「Oracle Internet Directoryのトラブルシューティング」

- 第17.10.2項「Oracle Virtual Directoryのトラブルシューティング」

- 第17.10.3項「Access Manager 11gのトラブルシューティング」

- 第17.10.4項「Oracle Identity Managerのトラブルシューティング」

- 第17.10.5項「Oracle SOA Suiteのトラブルシューティング」

- 第17.10.6項「My Oracle Supportを使用したその他のトラブルシューティング情報」

17.10.1 Oracle Internet Directoryのトラブルシューティング

この項では、Oracle Internet Directoryで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

- 第17.10.1.1項「Oracle Internet Directoryサーバーが応答しない」

- 第17.10.1.2項「SSO/LDAPアプリケーションの接続のタイムアウト」

- 第17.10.1.3項「LDAPアプリケーションがLDAPエラー53を受け取る(DSAが動作しない)」

- 第17.10.1.4項「TNSNAMES.ORA、TAF構成および関連する問題」

17.10.1.1 Oracle Internet Directoryサーバーが応答しない

問題

Oracle Internet Directoryサーバーが応答しません。監視のためLDAP SSLポートにICMPメッセージを送信するようにロード・バランシング・ルーターを構成すると、SSLネゴシエーションを開始したOracle Internet Directoryサーバーがハングすることがあります。これにより、ロード・バランシング・ルーターでは、LDAP SSLポートを監視するためのICMPメッセージを使用できません。

ソリューション

TCPやLDAPのプロトコル自体など、別のものを使用してください。

また、LDAPの非SSLポートを監視することも、LDAP可用性を検出するのに十分です。

17.10.1.2 SSO/LDAPアプリケーションの接続のタイムアウト

問題

Oracle Internet DirectoryサーバーへのSSO/LDAPアプリケーション接続が切断されています。

ソリューション

ロード・バランシング・ルーターのタイムアウトとSSO/Applicationタイムアウト構成パラメータを確認してください。SSO/LDAPアプリケーションのタイムアウト値は、LBR IDLEタイムアウト値未満にする必要があります。

17.10.1.3 LDAPアプリケーションがLDAPエラー53を受け取る(DSAが動作しない)

問題

LDAPアプリケーションがLDAPエラー53 (DSAが動作しようとしない)を受信しています。LDAPトランザクションの途中でいずれかのデータベース・ノードが停止すると、Oracle Internet Directoryサーバーはエラー53をLDAPクライアントに送信します。

ソリューション

Oracle Internet Directoryデータベース・ノードが停止した理由を確認するには、次の場所にあるOracle Internet Directoryのログを参照してください。

ORACLE_INSTANCE/diagnostics/logs/OID/oidldapd01s*.log

17.10.1.4 TNSNAMES.ORA、TAF構成および関連する問題

問題

TNSNAMES.ORAやTAFの構成に関連した問題があります。

ソリューション

Oracle Databaseの高可用性の概要に関するマニュアルを参照してください。

17.10.2 Oracle Virtual Directoryのトラブルシューティング

この項では、Oracle Virtual Directoryで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

- 第17.10.2.1項「SSLServerConfig.sh実行時のコマンドが見つからないエラー」

- 第17.10.2.2項「Oracle Virtual Directoryが応答しない」

- 第17.10.2.3項「SSO/LDAPアプリケーションの接続のタイムアウト」

- 第17.10.2.4項「TNSNAMES.ORA、TAF構成および関連する問題」

- 第17.10.2.5項「SSLServerConfig.shがエラーで失敗する」

17.10.2.1 SSLServerConfig.sh実行時のコマンドが見つからないエラー

問題

SSLServerConfig.shを実行すると、次のようにcommand not foundエラーが発生します。

./SSLServerConfig.sh: line 169: 20110520125611: command not found

ソリューション

ファイルorapki.sh (Linuxの場合)を編集して、ファイル末尾にある空白行をすべて削除します。このファイルを保存して、SSLServerConfig.shを再度実行します。

17.10.2.2 Oracle Virtual Directoryが応答しない

問題

Oracle Virtual Directoryが応答しません。監視のためLDAP SSLポートにICMPメッセージを送信するようにロード・バランシング・ルーターを構成すると、SSLネゴシエーションを開始したOracle Virtual Directoryサーバーがハングすることがあります。これにより、ロード・バランシング・ルーターでは、LDAP SSLポートを監視するためのICMPメッセージを使用できません。

ソリューション

TCPやLDAPのプロトコル自体など、別のものを使用してください。

また、LDAPの非SSLポートを監視することも、LDAP可用性を検出するのに十分です。

17.10.2.3 SSO/LDAPアプリケーションの接続のタイムアウト

問題

Oracle Virtual DirectoryサーバーへのSSO/LDAPアプリケーション接続が切断されています。

ソリューション

ロード・バランシング・ルーターのタイムアウトとSSO/Applicationタイムアウト構成パラメータを確認してください。SSO/LDAPアプリケーションのタイムアウト値は、LBR IDLEタイムアウト値未満にする必要があります。

17.10.2.4 TNSNAMES.ORA、TAF構成および関連する問題

問題

TNSNAMES.ORAやTAFの構成に関連した問題があります。

ソリューション

Oracle Databaseの高可用性の概要に関するマニュアルを参照してください。

17.10.2.5 SSLServerConfig.shがエラーで失敗する

問題

コンポーネントOVDでSSLServerConfig.shを実行すると、次のようなエラーが発生して失敗することがあります。

>>>Enter password for weblogic:
>>>Enter your keystore name [ovdks1.jks]:
Checking the existence of ovdks1.jks in the OVD...

>>>Failed to configure your SSL server wallet
>>>Please check /scratch/aime1/edgfa/idm//rootCA/keystores/ovd/ks_check.log for more information

ログ・ファイルには次のようなエラー・メッセージが記録されています。

Problem invoking WLST - Traceback (innermost last):
File "/scratch/aime1/edgfa/idm/rootCA/keystores/ovd/ovdssl-check.py", line 8, in ?
File "<iostream>", line 182, in cd
File "<iostream>", line 1848, in raiseWLSTExceptionWLSTException: Error occured while performing cd : Attributeoracle.as.ovd:type=component.listenersconfig.sslconfig,name=LDAP SSLEndpoint,instance=ovd1,component=ovd1 not found. Use ls(a) to view theattributes

ソリューション

この問題は断続的に発生します。この問題を回避するには、スクリプトを再実行します。

17.10.3 Access Manager 11gのトラブルシューティング

この項では、Access Managerで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

- 第17.10.3.1項「セッション数が最大許容値に達した」

- 第17.10.3.2項「Oracle Access Managerを初めてインストールしたときにポリシーが作成されない」

- 第17.10.3.3項「保護されたリソースにアクセスしても、資格証明を要求するメッセージが表示されない」

- 第17.10.3.4項「OAMコンソールにログインできない」

17.10.3.1 セッション数が最大許容値に達した

問題

Access Managerサーバーで次のようなエラー・メッセージが表示されます。

The user has already reached the maximum allowed number of sessions. Please close one of the existing sessions before trying to login again.

ソリューション

ログアウトせずに何回もログインすると、構成されているセッションの最大数を超えることがあります。OAM管理コンソールを使用して、構成されているセッションの最大数を変更できます。

OAM管理コンソールを使用してこの構成を変更するには、次の手順に従います。

1. 「システム構成」→「共通構成」→「セッション」を選択します。

2. どのユーザーにも想定されるすべての同時ログイン・セッションに対処できるように、「1ユーザー当たりの最大セッション数」フィールドの値を大きくします。このフィールドには、1以上の任意の値を指定できます。

17.10.3.2 Oracle Access Managerを初めてインストールしたときにポリシーが作成されない

問題

Oracle Access Managerを構成した後、管理サーバーの起動に長時間を要します。

ソリューション

OAMデータベースをチューニングします。Oracle Access Managerを構成した後で管理サーバーを初めて起動すると、データベースにいくつかのデフォルト・ポリシーが作成されます。データベースが遠方にある場合やチューニングを必要とする場合は、この作業に膨大な時間を要することがあります。

Resources
Authentication Policies
Protected Higher Level Policy
Protected Lower Level Policy
Publicl Policy
Authorization Policies
Authorization Policies

これらの項目が表示されない場合は、最初の移入に失敗しています。管理サーバーのログ・ファイルで詳細を確認します。

17.10.3.3 保護されたリソースにアクセスしても、資格証明を要求するメッセージが表示されない

問題

保護されたリソースにアクセスすると、本来はOracle Access Managerからユーザー名とパスワードの入力を要求されます。たとえば、簡単なHTMLページを作成してリソースとして追加すると、資格証明の入力画面が表示されます。

ソリューション

資格証明の入力画面が表示されない場合は、次の手順を実行します。

1. IDMDomainのホストの別名が設定されていることを確認します。IDMDomain:80、IDMDomain:Null、ADMIN.mycompany.com:80およびSSO.mycompany.com:443の別名が必要です。ここで、ポート80はHTTP_PORT、ポート443はHTTP_SSL_PORTです。

2. Webゲートがインストールされていることを確認します。

3. ASERVER_HOME/outputからWebゲートのLibディレクトリにOBAccessClient.xmlがコピーされ、OHSが再起動されたことを確認します。

4. OBAccessClient.xmlが最初に作成されたとき、このファイルは適切な形式になっていません。OHSを再起動すると、そのファイルが再検査されて適切な形式になります。OHSを初めて起動すると、このファイルの新しいバージョンがOracle Access Managerから取得されます。

5. Oracle Access Managerサーバーを停止し、保護されたリソースへのアクセスを試みます。Oracle Access Managerサーバーが使用できないというエラーが表示されます。このエラーが表示されない場合は、Webゲートをインストールしなおします。

17.10.3.4 OAMコンソールにログインできない

問題

OAMコンソールにログインできません。管理サーバーの診断ログに次のようなエラー・メッセージが含まれる場合があります。

Caused by: oracle.security.idm.OperationFailureException:
oracle.security.am.common.jndi.ldap.PoolingException [Root exception is oracle.ucp.UniversalConnectionPoolException:
Invalid life cycle state.
Check the status of the Universal Connection Pool]
at
oracle.security.idm.providers.stdldap.UCPool.acquireConnection(UCPool.java:112)

ソリューション

/tmp/UCP*のファイルを削除し、管理サーバーを再起動します。

17.10.4 Oracle Identity Managerのトラブルシューティング

この項では、Oracle Identity Managerで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

- 第17.10.4.1項「Oracle Identity Managerの構成実行時のjava.io.FileNotFoundException」

- 第17.10.4.2項「Oracle Identity Managerでのユーザー作成時のResourceConnectionValidationxception」

17.10.4.1 Oracle Identity Managerの構成実行時のjava.io.FileNotFoundException

問題

Oracle Identity Manager構成を実行すると、java.io.FileNotFoundException: soaconfigplan.xml (Permission denied)のエラーが表示され、Oracle Identity Manager構成が失敗することがあります。

ソリューション

この問題を回避するには、次の手順を実行します。

1. ファイル/tmp/oaconfigplan.xmlを削除します。

2. 構成を再度起動します(IAM_ORACLE_HOME/bin/config.sh)。

17.10.4.2 Oracle Identity Managerでのユーザー作成時のResourceConnectionValidationxception

問題

アクティブ/アクティブOracle Identity Manager構成において、Oracle Identity Managerでユーザーを作成(Oracle Identity Managerにログインし、「管理」タブをクリックし、「ユーザーの作成」リンクをクリックし、フィールドに必要な情報を入力してから、「保存」をクリック)していて、そのリクエストを処理中のOracle Identity Managerサーバーに障害が発生した場合、Oracle Identity Managerログ・ファイルに次に類似した「ResourceConnectionValidationxception」が記述されることがあります。

[2010-06-14T15:14:48.738-07:00] [oim_server2] [ERROR] [] [XELLERATE.SERVER]
[tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: xelsysadm] [ecid:
004YGJGmYrtEkJV6u3M6UH00073A0005EI,0:1] [APP: oim#11.1.1.3.0] [dcid:
12eb0f9c6e8796f4:-785b18b3:12938857792:-7ffd-0000000000000037] [URI:
/admin/faces/pages/Admin.jspx] Class/Method:
PooledResourceConnection/heartbeat encounter some problems: Operation timed
out[[
com.oracle.oim.gcp.exceptions.ResourceConnectionValidationxception: Operation
timed out
at
oracle.iam.ldapsync.impl.repository.LDAPConnection.heartbeat(LDAPConnection.ja
va:162)
at
com.oracle.oim.gcp.ucp.PooledResourceConnection.heartbeat(PooledResourceConnec
tion.java:52)
.
.
.

ソリューション

この例外が発生しても、ユーザーは正しく作成されます。

17.10.5 Oracle SOA Suiteのトラブルシューティング

この項では、Oracle SOA Suiteで発生する可能性のある一般的な問題とその解決策を紹介します。次のトピックが含まれます:

17.10.5.1 トランザクション・タイムアウト・エラー

問題: 次のトランザクション・タイムアウト・エラーがログに表示されます。

Internal Exception: java.sql.SQLException: Unexpected exception while enlisting
XAConnection java.sql.SQLException: XA error: XAResource.XAER_NOTA start()
failed on resource 'SOADataSource_soaedg_domain': XAER_NOTA : The XID
is not valid

解決方法: トランザクション・タイムアウト設定を確認し、JTAトランザクション・タイムアウトがデータ・ソースXAトランザクション・タイムアウトよりも短いことを確認します(後者はデータベースでのdistributed_lock_timeoutよりも短い)。

出荷時の設定では、SOAデータ・ソースではXAタイムアウト値は設定されていません。Set XA Transaction Timeout構成パラメータはWebLogic Server管理コンソールでは確認されません。この場合、データ・ソースはドメイン・レベルのJTAタイムアウトを使用します。これは30に設定されています。また、データベースのdistributed_lock_timeoutのデフォルト値は60です。この結果、トランザクションにかかる時間がこれらの値よりも短いと想定されるシステムでは、SOA構成は正しく動作します。特定の操作に想定されるトランザクション時間に合せて、これらの値を調整します。

17.10.6 My Oracle Supportを使用したその他のトラブルシューティング情報

Oracle Fusion Middlewareの問題の解決にMy Oracle Support(以前のMetaLink)を使用できます。My Oracle Supportには、次のような有用なトラブルシューティング・リソースが含まれています。

- ナレッジ・ベース記事

- コミュニティ・フォーラムとディスカッション

- パッチとアップグレード

- 動作保証情報

注意:

サービス・リクエストを登録する場合にMy Oracle Supportを使用することもできます。

My Oracle Supportにはhttps://support.oracle.comからアクセスできます。

A Oracle RACでのマルチ・データ・ソースの使用

新しいOracle RACアプリケーションの開発には、GridLinkデータ・ソースを使用することをお薦めします。しかし、GridLinkデータ・ソースをサポートしていない従来のアプリケーションおよびデータベースを使用している場合は、この付録の詳細を参照してください。

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

- 第A.1項「マルチ・データ・ソースとOracle RAC」

- 第A.2項「EDGトポロジ用のマルチ・データ・ソースを構成する標準手順」

A.1 マルチ・データ・ソースとOracle RAC

マルチ・データ・ソースでは、接続リクエストを満たすために使用する、データ・ソースの順序付きリストが提供されます。通常、このようなマルチ・データ・ソースへの接続リクエストはすべて、リストの先頭のデータ・ソースによって処理されます。データベース接続テストが失敗して接続を置き換えられなかった場合、またはデータ・ソースが中断された場合は、リストの次のデータ・ソースから順番に接続が検索されます。

Oracle RACを使用したマルチ・データ・ソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のOracle RACを使用したマルチ・データ・ソースの使用に関する項を参照してください。

A.2 EDGトポロジでマルチ・データ・ソースを構成するための標準的な手順

ドメインを構成する場合は、データ・ソースを構成します。たとえば、エンタープライズ・デプロイメント参照トポロジに最初の管理ドメインを構成する場合、構成ウィザードを使用してドメインの特性およびデータ・ソースを定義します。

このエンタープライズ・デプロイメント・ガイドに記載されているトポロジの構成手順では、Oracle RACを使用してGridLinkデータ・ソースを定義する固有の手順も説明しています。GridLinkデータ・ソースのかわりにマルチ・データ・ソースを使用する場合は、GridLink用の説明を次のように置き換えてください。

1. 「JDBCコンポーネント・スキーマの構成」画面で、次の操作を行います。

1. 適切なスキーマを選択します。

2. 「コンポーネント・スキーマのRAC構成」については、「RACマルチ・データ・ソースへ変換」を選択します。

3. リポジトリ作成ユーティリティを実行した際、次のデータ・ソースがスキーマの接頭辞とともに表示されることを確認してください。

4. 「次へ」をクリックします。

2. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面が表示されます。この画面で次の手順を実行します。

1. 次の各フィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。

- ドライバ: 「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。

- サービス名: データベースのサービス名を入力します。

- ユーザー名: スキーマの完全なユーザー名(接頭辞を含む)を入力します。

- パスワード: スキーマへのアクセスに使用するパスワードを入力します。

2. ホスト名、インスタンス名およびポートを入力します。

3. 「追加(A)」をクリックします。

4. この手順をOracle RACインスタンスごとに実行します。

5. 「次へ」をクリックします。

3. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常でない接続があった場合には、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続が正常になったら「次へ」をクリックします。

B Identity Managementのトポロジに関するワークシート

この付録には、マシン名、IPアドレス、ディレクトリ、およびその他の重要なデータを把握しておくためのワークシートが含まれています。

このガイドのPDFバージョンをPDFリーダーで開いて、この付録を印刷することをお薦めします。エンタープライズ・デプロイメントの設定を行ったら、ワークシートを更新してください。

この章には次のワークシートが含まれています。

- 第B.1項「Identity Managementのホスト、仮想ホストおよび仮想IPアドレス」

- 第B.2項「ディレクトリ・マッピング」

- 第B.3項「ポート・マッピング」

- 第B.4項「LDAPディレクトリの詳細情報」

- 第B.5項「データベースの詳細情報」

- 第B.6項「Web層の詳細情報」

- 第B.7項「アプリケーション層の詳細情報」

- 第B.8項「ユーザーとグループのマッピング」

B.1 Identity Managementのホスト、仮想ホストおよび仮想IPアドレス

このワークシートを使用して、ホストやIPアドレスの情報を記録します。

表B-1 ホスト、仮想ホストおよび仮想IPアドレス

ドキュメント内での別名

タイプ

ホスト名

IPアドレス

オペレーティング・システムとバージョン

WEBHOST1

ホスト

WEBHOST2

ホスト

IDMHOST1

ホスト

IDMHOST2

ホスト

IDMDBHOST1

データベース・ホスト

IDMDBHOST2

データベース・ホスト

OIMADMINVHN

仮想ホスト

ADMINVHN

仮想ホスト

SOAHOST1VHN

仮想ホスト

SOAHOST2VHN

仮想ホスト

OIMHOST1VHN

仮想ホスト

OIMHOST2VHN

仮想ホスト

IDMINTERNAL.mycompany.com

ロード・バランサの仮想名

SSO.mycompany.com

ロード・バランサの仮想名

ADMIN.mycompany.com

ロード・バランサの仮想名

OIMADMIN.mycompany.com

ロード・バランサの仮想名

IDSTORE.mycompany.com

ロード・バランサの仮想名

IDMDomain

ドメイン名

OIMDomain

ドメイン名

B.2 ディレクトリ・マッピング

このワークシートを使用してディレクトリを記録します。

表B-2 ディレクトリ・マッピング

ドキュメント内での変数

サンプルのディレクトリ・パス

実際のディレクトリ・パス

IAM_MW_HOME

/u01/oracle/products/access

IAM_ORACLE_HOME

/u01/oracle/products/access/iam

WEB_MW_HOME

/u02/private/oracle/products/web

SOA_ORACLE_HOME

/u01/oracle/products/access/soa

OUD_ORACLE_HOME

/u01/oracle/products/access/oud

WEB_ORACLE_HOME

/u02/private/oracle/products/web/web

WEBGATE_ORACLE_HOME

/u02/private/oracle/products/web/webgate

ORACLE_COMMON_HOME

/u01/oracle/products/access/oracle_common

WL_HOME

/u01/oracle/products/access/wlserver_10.3

JAVA_HOME

/u01/oracle/products/access/jrockit_version

OUD_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oudn

WEB_ORACLE_INSTANCE

/u02/private/oracle/config/instances/webn

ASERVER_HOME (IDMDomain)

/u01/oracle/config/domains/IDMDomain

MSERVER_HOME (IDMDomain)

/u02/private/oracle/config/domains/IDMDomain

ASERVER_HOME (OIMDomain)

/u01/oracle/config/domains/OIMDomain

MSERVER_HOME (OIMDomain)

/u02/private/oracle/config/domains/OIMDomain

B.3 ポート・マッピング

このワークシートを使用してポートを記録します。

表B-3 ポート・マッピング

ドキュメント内での変数

ドキュメント内でのポート

説明

実際のポート

HTTP_SSL_PORT

443

外部からサイトにアクセスする際のSSLポート

HTTP_PORT

80

内部で管理機能にアクセスする際に使用される非SSLポート

LDAP_LBR_PORT

389

ロード・バランサのLDAPアクセス・ポート

LDAP_LBR_SSL_PORT

636

ロード・バランサのLDAPSアクセス・ポート

LDAP_DIR_PORT

1389

OUDアクセス・ポート

LDAP_DIR_SSL_PORT

1636

OUD SSLアクセス・ポート

LDAP_DIR_ADMIN_PORT

4444

OUD管理ポート

LDAP_DIR_REPL_PORT

8989

OUDレプリケーション・ポート

OHS_PORT

7777

Oracle HTTP Serverリスニング・ポート

OAM_PROXY_PORT

5575

OAMリスニング・ポート

ONS_PORT

6200

ONSポート

DB_LSNR_PORT

1521

リスナー・ポート

OAM_PORT

14100

OAM管理対象サーバーのポート

OIM_PORT

14000

OIM管理対象サーバーのポート

WLS_ADMIN_PORT

7001

WLS管理ポート

WLS_ADMIN_SSL_PORT

7002

WLS管理SSLポート

NMGR_PORT

5556

ノード・マネージャ・リスニング・ポート

SOA_PORT

8001

SOAポート

SPLIT_WLS_ADMIN_PORT

7101

分割ドメインのWLS管理ポート

SPLIT_WLS_ADMIN_SSL_PORT

7102

分割ドメインのWLS管理SSLポート

B.4 LDAPディレクトリの詳細情報

このワークシートを使用してLDAPの情報を記録します。

表B-4 LDAPディレクトリの詳細情報

説明

ドキュメント内での値

実際の値

LDAPディレクトリのホスト

IDMHOST1

IDMHOST2

LDAPディレクトリのSSLポート

1636

LDAPディレクトリの非SSLポート

1389

LDAP管理ポート

4444

バック・エンドのディレクトリ・タイプ

OUD

LDAP仮想ホスト

IDSTORE.mycompany.com

LDAPのロード・バランスされたSSLポート

636

LDAPのロード・バランスされた非SSLポート

389

LDAP管理ユーザー

cn=oudadmin

OUD_ORACLE_INSTANCE

/u02/private/oracle/config/instances/oud1

/u02/private/oracle/config/instances/oud2

LDAPディレクトリ・ツリー

dc=mycompany,dc=com

LDAPグループ検索ベース

cn=Groups,dc=mycompany,dc=com

LDAPユーザー検索ベース

cn=Users,dc=mycompany,dc=com

LDAPの予約場所

cn=Reserve,dc=mycompany,dc=com

LDAPシステムIDの場所

cn=systemids,dc=mycompany,dc=com

B.5 データベースの詳細情報

このワークシートを使用してデータベースの情報を記録します。

表B-5 データベースの詳細情報

説明

ドキュメント内での値

実際の値

データベース・ホスト

IDMDBHOST1

IDMDBHOST2

SCANアドレス名

DB-SCAN.mycompany.com

データベース名

IDMDB.mycompany.com

定義されたデータベース・サービス名

OAMEDG.mycompany.com

OIMEDG.mycompany.com

OESEDG.mycompany.com

システム・アカウント名とパスワード

system/xxxxx

RCUスキーマ接頭辞

EDG

ONSポート

6200

リスナー・ポート

1521

B.6 Web層の詳細情報

このワークシートを使用してWeb層の情報を記録します。

表B-6 Web層の詳細情報

説明

ドキュメント内での値

実際の値

Web層のホスト

WEBHOST1

WEBHOST2

Oracle HTTP Serverリスニング・ポート

7777

WEB_ORACLE_HOME

/u02/private/oracle/products/web/web

WEBGATE_ORACLE_HOME

/u02/private/oracle/products/web/webgate

WEB_ORACLE_INSTANCE

/u02/private/oracle/config/instances/web1

/u02/private/oracle/config/instances/web2

仮想ホスト

ADMIN.mycompany.com

SSO.mycompany.com

IDMINTERNAL.mycompany.com

B.7 アプリケーション層の詳細情報

このワークシートを使用して、アプリケーション層の情報を記録します。

表B-7 アプリケーション層の詳細情報

説明

ドキュメント内での値

実際の値

ホスト(仮想ホスト)

ADMINVHN (IDMHOST1)

OIMADMINVHN (IDMHOST1)

OIMHOST1VHN (IDMHOST1)

SOAHOST1VHN (IDMHOST1)

OIMHOST2VHN (IDMHOST2)

OIMADMINVHN (IDMHOST2)

OIMHOST2VHN (IDMHOST2)

SOAHOST2VHN (IDMHOST2)

ドメイン名

IDMDomain

ASERVER_HOME

/u01/oracle/config/domains/IDMDomain

MSERVER_HOME

u02/private/oracle/config/domains/IDMDomain

ドメイン名

OIMDomain

ASERVER_HOME

/u01/oracle/config/domains/OIMDomain

MSERVER_HOME

u02/private/oracle/config/domains/OIMDomain

インストールされたコンポーネント

OAMコンソール、OESコンソール、OAM、OIM

OAM管理対象サーバーの名前

WLS_OAM1

WLS_OAM2

OIM管理対象サーバーの名前

WLS_OIM1

WLS_OIM2

OAM管理対象サーバーのポート

14100

OIM管理対象サーバーのポート

14000

B.8 ユーザーとグループのマッピング

このワークシートを使用して管理アカウントを記録します。

表B-8 ユーザー・マッピング

configToolのパラメータ

ドキュメント内での値

実際の値

IDSTORE_OAMADMINUSER

oamadmin

IDSTORE_OAMSOFTWAREUSER

oamLDAP

IDSTORE_OIMADMINUSER

oimLDAP

IDSTORE_WLSADMINUSER

weblogic_idm

表B-9 グループ・マッピング

configToolのパラメータ

ドキュメント内での値

実際の値

OAM11G_IDSTORE_ROLE_SECURITY_ADMIN

OAMAdministrators

IDSTORE_OIMADMINGROUP

OIMAdministrators

IDSTORE_WLSADMINGROUP

WLSAdmins

索引
A  B  C  D  E  F  G  H  I  K  L  M  N  O  P  R  S  T  U  V  W

A

Access Manager

「Oracle Access Manager」を参照

アクセス・サーバー

定義済, 11.1

Active Directory

Oracle Access ManagerおよびOracle Identity Manager用の構成, 9.4.3.2

アプリケーション層, 2.2.2 監査フレームワーク

概要, 17.5

アイデンティティ管理の監査, 17.5

B

バックアップ

リカバリ, 17.6

LDAPディレクトリ, 9.2

静的アーティファクト, 17.6.1

WebLogicドメイン, 8.7

boot.propertiesファイル

作成, 8.5.2

IDMHOST1とIDMHOST2での更新, 15.6

C

証明書

ホスト名の検証, 13.3

自己署名, 13.3.1

クラスタ・エージェント, 1.3 クラスタ, 1.3 クラスタウェア, 1.3 Coherence、「Oracle Coherence」を参照 コンポーネント

パッチ適用, 17.7.3

構成

Oracle Coherence, 12.9

構成ウィザード

ドメインの作成, 8.4

構成

ノード・マネージャのカスタム・キーストア, 13.3.4

Oracle Fusion Middlewareメタデータのデータベース, 6.4

データベース・リポジトリ, 6

ファイアウォール, 3.6

ノード・マネージャ, 13

ロード・バランサ用のポート, 3.4

サーバー移行のターゲット, 14.6

ロード・バランサ上の仮想サーバー名, 3.4

Web層と組み合せたOracle Access Managerの構成, 12.15 Fusion Middlewareホームの作成, 8.2.1 カスタム・キーストア, 13.3.4, 13.3.6

D

データ・ソース, 14.3

データ・ソース, A.2

データベース

サービスの作成, 6.4.1

Oracle Real Application Clusters, 6.2.2

必須, 6.2.1

バージョン, 6.2.3

ディレクトリ構造, 4.4.4

推奨事項, 4.4

用語, 4.2

ディレクトリ層

スケール・アウト, 17.4.2.1

ホスト名検証の無効化, 8.5.8 DNS、仮想サーバー名, 3.3.2 ドメイン・ディレクトリ

定義済, 4.2

E

WebLogicプラグインの有効化, 8.5.7

エンタープライズ・アーキテクチャ, 2.2.2.3

エンタープライズ・デプロイメント

ハードウェア要件, 2.3

高可用性, 1.4.2

パッチ適用, 17.7

ポートの割当て, 3.6

使用されるポート, 3.6, 16.2.5

スケーリング, 17.4

スケール・アウト, 17.4.2

スケール・アップ, 17.4.1

セキュリティ, 1.4.1

環境権限, 14.5

F

フェイルバック, 1.3

フェイルオーバー, 1.3

ファイアウォール

構成, 3.6

Fusion Middlewareホーム

インストール, 8.2

G

自己署名証明書の生成, 13.3.1

グリッド・サーバー, 1.1

H

ハードウェア・クラスタ, 1.3

高可用性, 2.2.2.4, 12.9.1

高可用性のプラクティス、Oracleサイト, 1.1

ホスト名

ネットワーク, 1.3

物理, 1.3

仮想, 1.3

ホスト名の検証

ノード・マネージャの証明書, 13.3

無効化, 8.5.8

管理対象サーバー, 13.3.7

HTTPサーバー

インストール, 10.2.3.1

I

アイデンティティ・キーストア, 13.3.2

アイデンティティ管理コンポーネント

停止と起動, 17.1

アイデンティティ・ストア

準備, 9.4

idmhost-vip.mycompany.com

WebLogic管理サーバーの仮想IPアドレス, 3.5

インストール

Fusion Middlewareホーム, 8.2.1

Oracle WebLogic Server, 8.2.1, 8.2.1, 8.2.1

インストール

Fusion Middlewareホーム, 8.2

HTTPサーバー, 10.2.3.1

Oracle HTTP Server, 10.2.3

Oracle IdentityおよびAccess Management, 8.2.2

ソフトウェア, 2.4

IP, 3.5

K

キーストア

カスタム, 13.3.4, 13.3.6

アイデンティティ, 13.3.2

トラスト, 13.3.3

Keytoolユーティリティ, 13.3.3

L

LDAP構成の事後設定スクリプト, 12.14

LDAPディレクトリ

バックアップ, 9.2

サーバー移行のleasing表, 14.2 leasing.ddlスクリプト, 14.2 ロード・バランサ

ポートの構成, 3.4

仮想サーバー名の構成, 3.4

必要な機能, 3.4.1

ディレクトリの場所, 4.4.4 ノード・マネージャのログ・ファイル, 13.1, 13.2

M

管理対象サーバー

カスタム・キーストア, 13.3.6

ホスト名の検証, 13.3.7

IPとVIPのマッピング, 3.5 ミドルウェア・ホーム, 1.3 マルチ・データソース, 14.3 MW_HOME

定義済, 4.2, 4.2

N

ネットワーク・ホスト名, 1.3

ノード・マネージャ, 13.3.1

カスタム・キーストア, 13.3.4

説明, 13.1

ホスト名検証の証明書, 13.3

アイデンティティ・キーストア, 13.3.2

ログ・ファイル, 13.1, 13.2

プロパティ・ファイル, 14.4

設定, 13

トラスト・キーストア, 13.3.3

ノード・マネージャのプロパティ・ファイル, 13.2 ノード

プライマリ, 1.3

セカンダリ, 1.3

O

ODSM

「Oracle Directory Services Manager」を参照

Oracle Access Manager

定義済, 11.1

ディレクトリ・スキーマの拡張, 9.4.3.1

Oracle Access Protocol (OAP), 3.7.1

Oracle Identity Protocol (OIP), 3.7.1

ユーザー・アクセス・リクエストの概要, 3.7.3

サーバー移行のテスト, 14.7

トラブルシューティング, 17.10.3

Oracle Access Manager 11g, 11

Oracle Identity Managerとの統合, 12.23

Oracle Access Protocol (OAP), 3.7.1 Oracle BI EE

アップグレード・ロードマップ表, 2.5.2

Oracle Coherence, 12.9 Oracle Fusion Middleware

エンタープライズ・デプロイメントの機能, 1.1

Oracle Fusion Middleware (FMW)

FMWホームの作成, 8.2.1

Oracle WebLogic Serverのインストール, 8.2.1

Oracleホーム, 1.3 Oracle HTTP Server

インストール, 10.2.3

Oracle Identity and Access Management

インストール, 8.2.2

Oracle Identity Manager

構成, 12.7

定義済, 12.1

Oracle Access Manager 11gとの統合, 12.23

トラブルシューティング, 17.10.4

サーバー移行の検証, 14.7

Oracle Identity Protocol (OIP), 3.7.1 Oracleインスタンス, 1.3 Oracle Internet Directory

トラブルシューティング, 17.10.1

Oracle Real Application Clustersデータベース, 6.2.2 Oracle Virtual Directory

トラブルシューティング, 17.10.2

Oracle WebLogic管理サーバー

「WebLogic管理サーバー」を参照

Oracle WebLogic Server (WLS)

インストール, 8.2.1

Oracle WebLogic Serverクラスタ

「WebLogic Serverクラスタ」を参照

Oracle WebLogic Serverドメイン

「WebLogic Serverドメイン」を参照

Oracle WebLogic Serverホーム

「WebLogic Serverホーム」を参照

ORACLE_BASE

定義済, 4.2

ORACLE_HOME

定義済, 4.2

ORACLE_INSTANCE

定義済, 4.2

P

パッチの適用

コンポーネント, 17.7.3

ソース・ファイル, 17.7.1

エンタープライズ・デプロイメント, 17.7

パフォーマンス、エンタープライズ・デプロイメント, 1.1 永続ストア, 12.16 物理ホスト名, 1.3 物理IP, 1.3 ポートの割当て, 3.6 ポート

ロード・バランサ向けの構成, 3.4

エンタープライズ・デプロイメントで使用, 3.6, 16.2.5

1次ノード, 1.3 ノード・マネージャのプロパティ・ファイル, 14.4

R

RACデータベース A.2

RCU

Identity Managementスキーマの作成, 6.6

S

スケーリング

エンタープライズ・デプロイメント, 17.4

スケール・アウト

ディレクトリ層, 17.4.2.1

エンタープライズ・デプロイメント, 17.4.2

スケール・アップ

エンタープライズ・デプロイメント, 17.4.1

スクリプト

leasing.ddl, 14.2

wlsifconfig.sh, 14.5

2次ノード, 1.3 セキュリティ, 2.2.2.5 自己署名証明書, 13.3.1 サーバー移行

ターゲットの構成, 14.6

マルチ・データソースの作成, 14.3

ノード・マネージャのプロパティ・ファイルの編集, 14.4

leasing表, 14.2

マルチ・データソース, 14.3

環境権限とスーパーユーザー権限の設定, 14.5

ユーザーと表領域の設定, 14.2

テスト, 14.7

サービス・レベル合意, 1.1 ノード・マネージャのセットアップ, 13 共有記憶域, 1.3 シングル・サインオン

Oracle Access Manager用の検証, 15.8

シングル・サインオン

管理コンソール向けの構成, 15

SOAHOST

Fusion Middlewareホームの作成, 8.2.1

Oracle WebLogic Serverのインストール, 8.2.1

SOAHOST1VHn仮想ホスト, 12.9.1 ソフトウェア

Oracle WebLogic Server, 8.2.1

ソフトウェアのインストール, 2.4

サマリー, 2.4.4

ソース・ファイル

パッチ適用, 17.7.1

起動

アイデンティティ管理コンポーネント, 17.1

停止

アイデンティティ管理コンポーネント, 17.1

スーパーユーザー権限, 14.5 スイッチバック, 1.3 スイッチオーバー, 1.3

T

サーバー移行の表領域, 14.2

サーバー移行のターゲット, 14.6

用語

ディレクトリ構造, 4.2

DOMAINディレクトリ, 4.2

MW_HOME, 4.2, 4.2

ORACLE_BASE, 4.2

ORACLE_HOME, 4.2

ORACLE_INSTANCE, 4.2

WL_HOME, 4.2

サーバー移行のテスト, 14.7 SQL*Net接続のタイムアウト

防止, 17.8

トラブルシューティング

Oracle Access Manager, 17.10.3

Oracle Identity Manager, 17.10.4

Oracle Internet Directory, 17.10.1

Oracle Virtual Directory, 17.10.2

トラスト・キーストア, 13.3.3

U

ユニキャスト通信, 12.9

utils.CertGenユーティリティ, 13.3.1

utils.ImportPrivateKeyユーティリティ, 13.3.2

V

検証

Oracle Access Managerのシングル・サインオン, 15.8

検証

サーバー移行, 14.7

VIP, 3.5 仮想ホスト名, 1.3 仮想IP, 1.3, 1.3 仮想IPアドレス, 3.5

WebLogic管理サーバーの関連付け, 5.6.1

WebLogic管理サーバーのための構成, 3.5

仮想IP (VIP), 3.5

W

Web層, 2.2.1

Webゲート

構成, 15.7

定義済, 11.1

インストール, 15.7

WebLogic

ドメインのバックアップ, 8.7

プラグインの有効化, 8.5.7

WebLogic管理サーバー

仮想IPアドレスとの関連付け, 5.6.1

仮想IPアドレスの構成, 3.5

フェイルオーバー, 8.6

フロント・エンドURL, 10.5, 16.6

WebLogic Serverドメイン

考慮事項, 2.2.2.1

WebLogic Serverホーム, 1.3 WL_HOME

定義済, 4.2

wlsifconfig.shスクリプト, 14.5

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2013, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。