| Oracle Access Managerインストレーション・ガイド 10g（10.1.4.3） B55482-01 |
|
 戻る |
 次へ |
この章では、Oracle Access Managerコンポーネントのインストール・プロセスを開始する前に、環境を準備するために必要な重要情報について説明します。すべての前提条件を満たさない場合、インストールに悪影響を及ぼすことがあります。次の項目について説明します。
Oracle Access Managerのコンポーネント、特徴、機能、対象者およびマニュアルの概要は、『Oracle Access Manager概要』を参照してください。
Oracle Access Managerをインストールする前に次の前提条件を満たすと、インストールを正常に実行できます。
タスクの概要: Oracle Access Managerのインストールの準備
様々なデプロイ・タイプとシナリオの特性、およびキャパシティ・プランニングとパフォーマンス・チューニングの推奨事項について理解するために、『Oracle Access Managerデプロイメント・ガイド』の内容を確認します。
Oracle Access Managerの完全なフレッシュ・インストールを実行するための正しいパッケージがそろっていることを確認するには、「インストール・パッケージ、パッチ・セット、バンドル・パッチおよび新たに動作保証されたエージェントの概要」を確認します。
「インストール・タスク、オプションおよびメソッドの概要」を確認し、環境に最も適したインストール・オプションを判断します。
複数のコンピュータにインストールする場合は、「システム・クロックの同期化」で説明されているように、ホスト・クロックを同期化します。
「Oracle Access Managerの要件の実現」全体を確認し、アクティビティを完了します。
Webサーバー・インスタンスを作成し、「Webサーバーの要件の実現」を参照します。
サポートされているディレクトリ・サーバー・インスタンスを作成し、ディレクトリ・サーバーに管理者レベルのユーザーを少なくとも1名定義し（ベンダーのドキュメントを参照）、「ディレクトリ・サーバーの要件の実現」に記載されているすべての項目を確認します。
「動作保証要件の確認」で説明されているように、環境がプラットフォームおよびサポートの要件を満たしていることを確認します。
ソフトウェアをオラクル社提供のインストール・メディアから取得し、「インストーラ用の一時ディレクトリの準備」で説明されているように、一時ディレクトリを準備します。
「インストール準備のチェックリスト」で説明されているように、インストール・プロセス中に指定する環境に関する情報を収集および文書化します。
オラクル社提供の言語パックを一緒にインストールする場合、または英語（アメリカ）以外の言語または地域のオペレーティング・システムを実行しているコンピュータにインストールする場合は、マルチ言語環境の詳細について第3章を参照し、必要なアクティビティをすべて完了します。
Oracle Access Managerは、時刻を正しく管理するために、同期化されたタイム・クロックおよび各ホスト・コンピュータのオペレーティング・システムに依存します。アクセス・サーバーのクロックは、WebGateより60秒以上進めないでください。WebGateのクロックは、アクセス・サーバーのクロックより進めないでください。
オペレーティング・システムのタイム・クロックが正常に機能しているときは、Oracle Access Managerも正しく機能します。通常、オペレーティング・システムのタイム・クロックの管理および同期化には、Network Time Protocol（NTP）が使用されます。
Oracle Access Managerコンポーネントを複数のコンピュータにインストールする場合は、すべてのシステム・クロックが同期化されていることを確認します。これは、ソフトウェアを証明書モードまたはシンプル・モードで実行する場合に特に重要です。
たとえば、WebPassのWebサーバーのシステム・クロックがアイデンティティ・サーバーのシステム・クロックより進んで設定されている場合、Webサーバー上のWebPassプラグインから送信されるログイン・リクエストには、アイデンティティ・サーバーではまだ発生していない時刻が含まれます。これは、アクセス・システムの場合も同様です。Webサーバーのクロックがアクセス・サーバーのクロックより進んでいる場合、ポリシー・マネージャからアクセス・サーバーに送信されるリクエストには、アクセス・サーバーではまだ発生していない時刻が含まれます。これは、ログイン・イベントの失敗の原因になります。シンプル・モードまたは証明書モードで実行している場合、タイムスタンプの同期が取れなくなるか、クライアント証明書が無効として表示される可能性があります。
正常に操作するには、次のようにします。
すべてのコンピュータのクロックが同期化されていることを確認します。時間の許容差は設定できません。たとえば、WebGateのクロックがアクセス・サーバーのクロックよりわずかでも進んでいる場合、WebGateで生成されたCookieは将来のものと認識され、アクセス・サーバーで問題の原因になります。
WebGateを実行している各コンピュータのクロックが、それが関連付けられているアクセス・サーバーより進んでいないことを確認してください。アクセス・サーバーがWebGateのクロックよりも進んでいる場合、そのずれは60秒以内である必要があります。
WebPassを実行している各コンピュータのクロックが、それが関連付けられているアイデンティティ・サーバーおよびポリシー・マネージャより進んでいないことを確認してください。
|
注意: 時刻の管理には、夏時間の変更も含まれます。夏時間の変更によるOracle Access Managerへの影響はありません。 |
OracleデータベースおよびOracle Fusion Middleware製品に関する2007年のアメリカ合衆国の夏時間（DST）準拠: 2007年は、夏時間の実施日程が変更されます。アメリカ合衆国では、2005年エネルギ政策法が法制化され、夏時間が延長されることになりました。この新しい規則では、アメリカ合衆国のDSTは3月の第2日曜日に開始され、11月の第1日曜日に終了します。以前の夏時間は、4月の第1日曜日に開始され10月の最後の日曜日に終了していました。
この変更はカナダにも影響します。必要なパッチを適用していない場合は、2007年3月11日から2007年4月1日まで、および2007年10月28日から2007年11月4日まで（翌年以降は異なる日付）の期間、データベースによって不正なタイムゾーン・データが報告されます。メキシコでは、引き続き以前のDST規則が使用されます。
OracleデータベースおよびOracle Fusion Middleware製品に関する、2007年のアメリカ合衆国の夏時間（DST）準拠による影響の詳細は、My Oracle Support（旧Metalink）のWebサイト（https://metalink.oracle.com）の「Note: 397281.1」を参照してください。
Oracle Access Manager製品に関する2007年のアメリカ合衆国の夏時間（DST）準拠: 必要なDSTの変更は、オペレーティング・システムのベンダーの推奨に従ってください。また、Oracle Access Managerのコンポーネントをホストしているコンピュータのシステム・クロックが、この項で前述したように同期化されていることを確認してください。
|
注意: アイデンティティ・サーバーまたはアクセス・サーバーにはOracle Access Managerのパッチのみが必要です。ただし、Oracle Access Managerは、DSTの変更によって影響を受ける可能性があるその他のコンポーネント（Webサーバー、アプリケーション・サーバー、LDAPディレクトリおよびデータベースなど）と対話します。ベンダーのドキュメントを参照して、影響を受ける他のコンポーネントに必要なパッチが適用されていることを確認してください。 |
Oracle Internet DirectoryおよびOracle Application Serverに関する2007年のアメリカ合衆国のDST変更: 2007年のDST変更によってDSTの問題が発生する可能性があるのはデータベースのみで、タイムゾーンが設定されている場合に限られます。準拠するオペレーティング・システムが必要です。詳細は、My Oracle Support（旧MetaLink）に記載されている次の項目を参照してください。
Note 357056.1: 夏時間（DST）規則の変更によるOracleデータベースへの影響
Note 359145.1: 2007年のアメリカ合衆国の夏時間変更によるOracleデータベースへの影響
Note 360803.1: AUタイムゾーンのデータベースおよびFusion Middlewareの推奨事項
Note 397281.1: データベースおよびFusion Middlewareに関する2007年のアメリカ合衆国の夏時間（DST）準拠
Note 401010.1: 西オーストラリアの夏時間変更に関するデータベースおよびFusion Middlewareの推奨事項
My Oracle Support（旧MetaLink）でのナレッジ・ベース項目の検索手順
https://metalink.oracle.comにあるMy Oracle Supportに移動します。
指示に従ってログインします。
「ナレッジ」タブをクリックします。
クイック検索リストから「ナレッジ・ベース」を選択し、項目番号を入力して「実行」ボタンをクリックします。
表示する項目の名前を結果リストでクリックします。
地理的に異なるタイムゾーンにあるOracle Access Managerコンポーネントを同期化するには、Network Time Protocol（NTP）を使用できます。NTPでは、複数のコンピュータの時刻を数ミリ秒以内に同期化できます。時刻の同期化の詳細は、次のWebサイトにアクセスしてください。
また、comp.protocols.time.ntpニュース・グループを参照してください。
ntp.confファイルには、少なくとも次の内容が含まれています。
server <some NTP server name>.com
driftfile /etc/ntp.drift
ntp.confファイルを作成する方法は、次のサイトで確認できます。
http://www.sun.com/products-n-solutions/hardware/docs/html/816-3626-10/after.html
http://inetsd01.boulder.ibm.com/pseries/fr_FR/files/aixfiles/ntp.conf.htm
UNIXコンピュータでは、UTC（GMTとも呼ばれる）を内部で使用し、表示で必要なローカル時間に変換します。Windowsコンピュータではクロックをローカル時間で維持しますが、NTP同期化プログラムを使用すると、Windows上での正確な時刻が保証されます。
すべてのUNIXオペレーティング・システムには、いずれかのバージョンのNTPが含まれています。Solaris上でNTPを構成するには、ntp.confファイルを作成します。Solarisに付属のNTPデーモンを使用するntp.confファイルの名前は、/etc/inet/ntp.confです。このファイルの作成後は、オペレーティング・システムの起動時に、xntpが自動的に起動されます。
すべてのUNIXプラットフォーム上: 最新（および、よりセキュアな）バージョンのNTPデーモンをhttp://www.ntp.org/から入手します。
Windowsコンピュータでは、いずれかのバージョンのNTPを使用して、コンピュータの時刻をそのドメイン・コントローラと自動的に同期化します。ドメイン・コントローラは、時刻ソースと同期化されるように構成する必要があります。
ネットワーク全体を同期化するための公式な時刻を取得できるように、多数のISPからカスタマ向けの時刻サービスが提供されています。
NTP: このプロトコルには、http://www.ntp.orgから入手できるオープンなstratum-1サーバーのリストがあります。
ただし、このサイトは、最もセキュアな選択肢ではない場合があります。時間ベースの攻撃の例としては、時刻を実際の時刻より進めて見せかけることでCookieを有効に保つことがあります。
GPSベースのクロック: このクロックでは、衛星テクノロジを使用して、非常に正確な時刻を提供します。
これらのクロックを使用して、ネットワーク全体を同じ時刻に設定できます。GPSテクノロジでは、非常に正確な時刻を必要とします。各衛星には3つの原子時計が組み込まれていて、これらの時計の時刻は、相対論的効果を補正するために地上から送信される値によって絶えず修正されます。つまり、現在時刻の正確な推定値は、GPS受信機の位置を検出することの副次的な効果として得られます。
次の情報を参考にしてください。
「動作保証要件の確認」で説明されているように、各コンポーネントにはサポートされているホスト・コンピュータが必要です。
コンポーネントのインストールを実行するアカウントには管理権限が必要です。Oracle Access Managerコンポーネントのインストールおよび構成に使用する、専用のユーザー名およびグループを作成することをお薦めします。また、次のことを考慮してください。
Windows上の.NET: Windowsプラットフォームでは、Oracle Access Managerコンポーネントをインストールする前に.NET Frameworkがインストールされている必要があります。インストールされていない場合、Oracle Access Managerサーバーの起動が失敗します。詳細は、「.NETランタイム用のWindowsの準備」を参照してください。
コマンドライン・ツールの管理要件: 製品がある特定のユーザーとしてインストールされている場合、すべてのコマンドライン・ユーティリティとツールは、製品をインストールしたユーザーとして実行する必要があります。インストール後は、ファイルの所有権や権限を変更しないことをお薦めします。
管理権限: アイデンティティ・サーバーとアクセス・サーバーの両方のサーバーは、サービスとして実行されます。アイデンティティ・サーバーおよびアクセス・サーバーのサービスを実行するために使用するユーザー・アカウントには、サービスとしてログオンするための権限が必要です。この権限は、「管理ツール」→「ローカル セキュリティ ポリシー」→「ローカル ポリシー」→「ユーザー権利の割り当て」→「サービスとしてログオン」で設定できます。
Microsoft Windows上: アイデンティティ・サーバーのサービスを実行するために使用するユーザー・アカウントには、サービスとしてログオンするための権限が必要です。これは、「管理ツール」で設定できます。次に例を示します。
「管理ツール」→「ローカル セキュリティ ポリシー」→「ローカル ポリシー」→「ユーザー権利の割り当て」→「サービスとしてログオン」
Linuxプラットフォーム上: ユーザーおよびグループのアカウントは、コンポーネントのインストール後に作成できます。
ユーザー名nobodyおよびグループnobodyは使用しないでください。
Oracle Access Managerコンポーネントのインストールおよび管理に関しては、rootを一切使用しないでください。
UNIXプラットフォーム上: コンポーネントのインストール中に、Oracle Access Managerコンポーネントで使用するユーザー名およびグループを指定するよう求められます。ユーザー名nobodyおよびグループnobodyを使用しないことをお薦めします。HP-UXでは、デフォルトはWWW（ユーザー名）およびothers（グループ）です。
正しいコマンドがインストールされていることを確認し、Webサーバーの実行に使用するユーザー名を確認します。次に例を示します。
次のコマンドを検索し（通常は、/usr/bin、/usr/sbinまたは/usr/csb内）、その場所が検索パスに含まれていることを確認します。
sed、tar、cp、ls、mkdir、rmdir
Webサーバーの実行に使用するユーザー名は任意で指定できます。Webサーバーのユーザーおよびグループを調べるには、Webサーバーの構成ファイルを確認するか、Webサーバーの管理コンソールを実行してサーバーの設定を表示します。
|
注意: WebPass、ポリシー・マネージャおよびWebGateは、Webサーバーと同じユーザーおよびグループを使用してインストールする必要があります。WebGateのインストールに使用されるアカウントは、WebGateを実行するアカウントではありません。 |
オンラインのコンピュータ: インストールの前に、各コンポーネントが実行されるコンピュータにpingを実行できる必要があります。また、インストール中に、アイデンティティ・サーバーとアクセス・サーバーのインストール・コンピュータのDNSホスト名を指定するよう求められます。
コンポーネントのセキュリティ: インストール中に、Oracle Access Managerコンポーネント間の通信のトランスポート・セキュリティ・モードを指定する必要があります。「Oracle Access Managerコンポーネントの通信の保護」を参照してください。
ディレクトリのセキュリティ: インストール中（アイデンティティ・サーバー、ポリシー・マネージャおよびアクセス・サーバー）に、コンポーネントが通信するディレクトリ・サーバーのホスト名、DNおよびトランスポート・セキュリティ・モードを指定する必要があります。この情報およびその他の重要な情報は、「ディレクトリ・サーバーの要件の実現」を参照してください。
既存のアイデンティティ・サーバー名: 既存のアイデンティティ・サーバー名を再利用する場合は、「アイデンティティ・サーバー・インスタンス名のリサイクル」を参照してください。
LinuxおよびSolaris用のGCCランタイム・ライブラリ: コンポーネントをLinuxコンピュータにインストールする前に、GCC 3.3.2と互換性のある追加のGCCランタイム・ライブラリ（libgcc_s.so.1およびlibstdc++.so.5）をインストールする必要があります。「LinuxおよびSolarisホスト・コンピュータの準備」を参照してください。
LinuxThreadsとNPTL: Red Hat Linux v4（およびそれ以前のリリース）では、カーネル2.0.0以降で動作するLinux用のPosix 1003.1cスレッド・パッケージ（LinuxThreads）の実装を使用していました。以前のリリースのOracle Access Manager for Linuxでは、LinuxThreadsライブラリのみを使用していました。この場合、環境変数LD_ASSUME_KERNELを設定する必要がありました。この変数は、ライブラリのどの実装を使用するかを判断するために動的リンカーによって使用されます。LD_ASSUME_KERNELを2.4.19に設定すると、/lib/i686のライブラリが動的に使用されます。
Red Hat Linux v5以降のリリースでは、ネイティブPOSIXスレッド・ライブラリ（NPTL）のみがサポートされ、LinuxThreadsはサポートされません。この変更に対処するために、Oracle Access Manager 10g（10.1.4.3）ではNPTL仕様に準拠して機能が拡張されました。ただし、デフォルトではLinuxThreadsが使用されます。
Oracle Access Manager 10g（10.1.4.3）では、NPTL仕様に準拠した他のサポート対象Linux環境でNPTLを使用できます。NPTLを使用する場合、環境変数LD_ASSUME_KERNELを2.4.19に設定する必要はありません。ただし、一部のWebGateパッケージでは依然としてLD_ASSUME_KERNELを2.4.19に設定する必要があります。詳細は、「動作保証要件の確認」を参照してください。
|
注意: Oracle Access Manager 10g（10.1.4.3）では、以前と同様にデフォルトでLinuxThreadsが使用されます。ただし、NPTLを使用する場合、手動で環境変数LD_ASSUME_KERNELを2.4.19に設定する必要はありません。さらに、変更されているスクリプトや、ユーザーによる変更が必要なスクリプトがあります。詳細は、「NPTLの要件とインストール後のタスク」を参照してください。 |
セキュリティ強化Linux（SELinux）: SELinuxはOracle Enterprise Linuxと一緒に提供されます。SELinuxの変更では、Linuxカーネル内でLinuxセキュリティ・モジュール（LSM）を使用することにより、様々なセキュリティ・ポリシーが提供されます。SELinuxでは、Oracle Access Manager Webコンポーネントのインストール後、関連するWebサーバーを起動する前に追加の手順を実行する必要があります。これは、サポート対象でSELinuxを使用するすべてのLinuxバージョンで行う必要があります。
インストールの取消し: インストールの取消しまたはインストールしたコンポーネントの削除が必要な場合は、「Oracle Access Managerコンポーネントのアンインストール」を参照してください。
マルチ言語環境: 最新の10g（10.1.4.3）言語パック・インストーラを使用し、次のガイドラインを考慮してください。
英語（アメリカ）以外の言語またはロケールのオペレーティング・システムを使用しているコンピュータへのインストールでは、LANG環境変数、または任意のNLS_LANGあるいはCOREID_NLS_LANG環境変数を設定できます。
アイデンティティ・サーバーをオラクル社提供の1つ以上の言語パックとともにインストールする場合は、WebPassも同じ言語パックとともにインストールする必要があります（対応するアクセス・システムの言語パックとすべてのアクセス・システム・コンポーネントもインストールする必要があります）。
コンポーネントを1つの言語パックとともにUNIXシステムにインストールする場合は、メイン・インストーラを起動する前に、言語パックのインストーラがコンポーネントと同じディレクトリに存在し、言語パックのインストーラに実行権限があることを確認してください。次に例を示します。
chmod +x "Oracle_Access_Manager10_1_4_3_0_FR_sparc-s2_LP_Identity_System" chmod +x "Oracle_Access_Manager10_1_4_3_0_FR_sparc-s2_LP_Access_System"
|
注意: マイナー・リリース（10g（10.1.4.2.0）および10g（10.1.4.3））で追加された新機能のメッセージの一部は翻訳されておらず、英語のみで表示される可能性があります。 |
詳細は、第3章「マルチ言語環境の概要」を参照してください。
LinuxまたはSolarisコンピュータへのOracle Access Managerコンポーネントのインストール中、追加のGCCランタイム・ライブラリの場所を指定するよう求められます。
Linux: Oracle Access Managerでは、GCC 3.3.2と互換性のあるlibgcc_s.so.1およびlibstdc++.so.5が必要です。
Solaris: Oracle Access Managerインストーラはハード・コーディングされたlibstdc++.so.5のファイル名を検索します。Solarisライブラリ（libstdc++.s0.6）がlibstdc++.so.5にコピーされている場合でも、インストーラはその後のインストール中に停止します。オラクル社では、libgcc-3.3-sol10-sparc-localを提供しています。これはOracle Access Managerで問題なく使用されます。
LinuxとSolaris用のGCCランタイム・ライブラリはOracle製品に付属していませんが、Oracle Technology Networkから入手できます。
|
注意: Red Hat Linux AS 3.0用のアイデンティティ・サーバー・インストーラおよびWebPassインストーラは、インストーラを起動し、インストール・パスを指定して[Enter]を押した後、インストーラの設定前にハングする可能性があります。回避方法は、「Linuxでのインストーラのハング」を参照してください。 |
GCCランタイム・ライブラリをLinuxまたはSolarisホストにインストールする手順
プラットフォームのベンダーまたはOracle Technology NetworkからGCCランタイム・ライブラリを入手します。次に例を示します。
http://www.oracle.com/technology/software/products/ias/htdocs/101401.html
「GCC Libraries for Oracle Access Manager」という行を見つけます。
ホスト・コンピュータに該当する列から、LinuxまたはSolarisのCDをクリックします。次に例を示します。
Solaris 10: CD1
Linux: CD1
zipファイルから、次のファイルを抽出し、1つ以上のOracle Access Managerコンポーネントをインストールするローカル・コンピュータに格納します。次に例を示します。
Solaris 10: libgcc-3.3-sol10-sparc-local
Linux:
Oracle Access Managerのインストール中に、ローカル・コンピュータ上のライブラリの場所を入力するように求められたら指定し、インストールを続行します。
Windowsプラットフォームでは、Oracle Access Managerコンポーネントをインストールする前に.NETランタイムがインストールされている必要があります。インストールされていない場合、Oracle Access Managerサーバーの起動が失敗します。
|
注意: 標準のAccess Manager SDKには、.NET 1.1サポートが必要です。さらに、カスタムAccessGateのために.NET 2をサポートするSDKを任意で追加する場合、ホスト・コンピュータに.NET 2が必要です。 |
.NETランタイムが使用可能かどうかを確認する手順
Internet Explorerのアドレス・フィールドに次のように入力し、表示されたポップアップで.NETの詳細を確認します。
javascript:alert(navigator.userAgent)
Windowsレジストリを開き、次に移動して、ホスト上で使用可能なすべての.NETバージョンの一覧を表示します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\
|
関連項目: 『Oracle Access Manager開発者ガイド』の、.NET 2カスタムAccessGate用の部分的なSDKの詳細 |
アイデンティティ・サーバーは、他のOracle Access Managerコンポーネントやアプリケーションと同じホスト・システム上に存在する必要はありません。アイデンティティ・サーバーとアクセス・サーバーは異なるコンピュータにインストールすることをお薦めします。そのうえ、アイデンティティ・サーバーは、他のOracle Access Managerコンポーネントやアプリケーションと同じホスト・システム上に存在する必要はありません。1つ以上のアイデンティティ・サーバーをインストールする方法の詳細は、第4章「アイデンティティ・サーバーのインストール」を参照してください。
アイデンティティ・サーバーと通信する各Webサーバー・インスタンスには、WebPassを構成する必要があります。1つのWebPassは、複数のアイデンティティ・サーバーと通信できます。複数のWebPassが同一のアイデンティティ・サーバーと通信できます。ロード・バランシングでは、この方法をお薦めします。「システム・クロックの同期化」も参照してください。
Oracle Access Managerコンポーネントのインストールおよび構成に使用する、専用のユーザーおよびグループを作成することをお薦めします。WebPassインスタンスは、その構成対象であるWebサーバーと同じユーザーおよびグループを使用してインストールする必要があります。
インストール中に指定するWebPassインスタンスのIDは、一意である必要があります。WebPassインスタンスのIDは、インストール後にWebサーバーが起動するまで検証されません。
WebPassは、各ポリシー・マネージャでも同じディレクトリ・レベルで、同じWebサーバー・インスタンス上にインストールする必要があります。
1つ以上のWebPassインスタンスをインストールする方法の詳細は、第5章「WebPassのインストール」を参照してください。
アイデンティティ・システムの設定中に、すべてのOracle Access Manager機能へのアクセス権が付与されるユーザーを定義する必要があります。これは、マスター管理者です。詳細は、第6章「アイデンティティ・システムの設定」を参照してください。
Oracle Access Managerコンポーネントのインストールおよび構成に使用する、専用のユーザーおよびグループを作成することをお薦めします。WebPass、ポリシー・マネージャおよびWebGateは、Webサーバーと同じユーザーおよびグループを使用してインストールする必要があります。WebGateのインストールに使用されるアカウントは、WebGateを実行するアカウントではありません。
次の各項目は、アクセス・システムの要件とガイドラインの概要について説明します。
ポリシー・マネージャは、WebPassと同じディレクトリ・レベルで、WebPassと同じWebサーバー・インスタンス上にインストールする必要があります。「システム・クロックの同期化」も参照してください。
ポリシー・マネージャとディレクトリ・サーバー間には、ファイアウォールを設定しないことをお薦めします。これは、ヘルス・チェックが実行されないためです。非アクティブ期間の後に、ファイアウォールは警告なしにポリシー・マネージャ接続を削除する場合があります。このような問題を回避するために、ポリシー・マネージャとディレクトリ・サーバーがファイアウォールの同じ側に存在するようにするか、可能な場合は、ポリシー・マネージャとディレクトリ・サーバー間のファイアウォール接続のタイムアウトを無効化します。ただし、一部のファイアウォールではこれをサポートしていません。
NETWORKアカウントには、ボリューム・ルートでの変更権限が必要です。
ポリシー・マネージャで使用するディレクトリ・サーバーに応じて、次の点を検討してください。
ポリシー・マネージャのインストール中にWindows Server 2003上のActive Directoryをディレクトリ・サーバーとして指定すると、動的補助クラスをサポートするかどうかを尋ねる新しいページが表示されます。ADSIを使用している場合は、ポリシー・マネージャのインストール後および設定前に、IIS Webサーバーの匿名ユーザー・ログイン・アカウントをドメイン・ユーザーに設定する必要があります。
ポリシー・マネージャがSun（以前のNetscape）のWebサーバーを使用するSolaris上にインストールされた場合、Oracle Access Managerはディレクトリ・サーバーとポリシー・マネージャ間のSSL対応通信をサポートします。
ポリシー・マネージャのインストールに使用しているWebサーバーに応じて、次のような考慮点があります。
Apache: Oracle Access Managerは、SSL対応または非対応のApacheをサポートしています。SSL対応通信では、Oracle Access Managerは、Apache-SSLではなく、mod_ssl付きのApacheのみをサポートしています。mod_sslは、Apache-SSLから導出され、Apache-SSLにかわるモジュールです。Webサーバーの実行に使用するユーザーおよびグループを、httpd.confで構成してください。
IIS: ポリシー・マネージャのインストーラでは、複数のWebサーバー・インスタンスは更新できません。複数のIIS Webサーバー・インスタンスがインストールされている場合は、各Webサーバー・インスタンスに個別のポリシー・マネージャをインストールしてください。
IISを実行しているWindows 2000にポリシー・マネージャをインストールする場合は、Everyoneという名前のグループに\tempディレクトリおよび\tempディレクトリが属するドライブ（CやDなど）への完全なアクセス権があることを確認してください。
TEMP変数は、システム全体またはIISユーザーに対して、有効なディレクトリを指すように設定する必要があります。TEMP変数はシステム全体に対して設定することをお薦めします。
1つ以上のポリシー・マネージャをインストールする方法の詳細は、第7章「ポリシー・マネージャのインストール」を参照してください。
アイデンティティ・サーバーとアクセス・サーバーは異なるコンピュータにインストールすることをお薦めします。アイデンティティ・サーバーは、他のOracle Access Managerコンポーネントやアプリケーションと同じホスト・システム上に存在する必要はありません。
ポリシー・マネージャと同じディレクトリにアクセス・サーバーをインストールしないでください。同一のディレクトリに複数のアクセス・サーバーをインストールしないでください。
フェイルオーバーおよびロード・バランシング: フェイルオーバーおよびロード・バランシングのために、複数のアクセス・サーバーをインストールすることをお薦めします。
ファイアウォール: アクセス・サーバーをインストールするコンピュータをファイアウォールで保護することをお薦めします。
アップグレードされた環境: 以前のWebGateを含んでいるアップグレードされた環境に10.1.4アクセス・サーバーをインストールする場合は、インストール後にアクセス・サーバーのglobalparams.xmlファイルの"IsBackwardCompatible" Value="true"を手動で変更する必要があります。新しくインストールされた10.1.4アクセス・サーバーでは、以前のWebGateとの下位互換性は自動的に提供されません。ただし、アップグレードされたアクセス・サーバーは、自動的に以前のWebGateとの下位互換性を備えます。詳細は、『Oracle Access Managerアップグレード・ガイド』を参照してください。
1つ以上のアクセス・サーバーをインストールする方法の詳細は、第8章「アクセス・サーバーのインストール」を参照してください。
この項目では、WebGateのインストールに固有のガイドラインについて説明します。
アイデンティティ・システムまたはアクセス・システムの保護: WebGateは、Webサーバーをホストするコンピュータにインストールする必要があります。アイデンティティ・システムまたはアクセス・システムを保護するには、WebPassおよびポリシー・マネージャをホストする各コンピュータにWebPassまたはポリシー・マネージャと同じWebサーバー・インスタンスを使用してWebGateをインストールする必要があります。
インストール・パス: WebGateは、Webサーバーからアクセス可能なほとんどのディレクトリにインストールできます。一般に、WebGateは、WebPassまたはポリシー・マネージャとは異なるディレクトリにインストールすることをお薦めします。インストール・パスに関する次の追加のガイドラインを考慮してください。
Microsoft IIS Webサーバー、フォームベース認証およびシングル・サインオン（SSO）: WebGateは、ポリシー・マネージャと同じディレクトリおよびWebPassと同じディレクトリ・レベルにインストールする必要があります。
Microsoft IIS Webサーバー、Basic-over-LDAP認証: WebGateは、ポリシー・マネージャのディレクトリとは別のパスにインストールできます。また、任意のディレクトリ・レベルにインストールできます。
認証方法に関係なくその他のすべてのWebサーバー: WebGateは、ポリシー・マネージャのディレクトリとは別のパスにインストールできます。また、任意のディレクトリ・レベルにインストールできます。
|
注意: WebGateをポリシー・マネージャと同じディレクトリにインストールする必要があるのは、Microsoft IIS Webサーバーでフォームベース認証およびSSOを使用する場合のみです。 |
ルート・レベルまたはサイト・レベル: WebGateは、ルート・レベルまたはサイト・レベルでインストールできます。WebGateを複数の仮想サイトにインストールしても、生成されるWebGateのインスタンスは1つのみです。Webサーバー・プロセスをroot以外のユーザーとして実行する場合、root以外のユーザーを使用してWebGateをインストールすることもできます。
コンピュータ・レベルまたは仮想Webサーバー・レベル: WebGateは、コンピュータ・レベルまたは仮想Webサーバー・レベルで実行するように構成できます。ただし、コンピュータ・レベルと仮想Webサーバー・レベルの両方にインストールしないでください。「システム・クロックの同期化」も参照してください。
以前のWebGateのガイドライン: 以前のWebGateは、10.1.4アクセス・サーバーと共存できます。この場合、次の暗号化スキームのガイドラインを考慮する必要があります。
デプロイメントに以前のWebGateが含まれる場合は、アクセス・サーバーに以前のWebGateとの下位互換性を設定する必要があります。詳細は、『Oracle Access Managerアップグレード・ガイド』を参照してください。
環境のガイドライン: Webサーバーおよびオペレーティング・システムのタイプは、WebGateとアクセス・サーバー間の通信では考慮されません。ただし、各種環境において、WebGateには次のような考慮点があります。
UNIX WebGate: WebGateをインストールするには、rootとしてログインします。Webサーバー・プロセスをroot以外のユーザーとして実行する場合は、root以外のユーザーを使用してWebGateをインストールできます。
Apache Webサーバー: Oracle Access Managerは、SSL対応または非対応のApacheをサポートしています。SSL対応通信では、Oracle Access Managerは、Apache-SSLではなく、mod_ssl付きのApacheのみをサポートしています。mod_sslは、Apache-SSLから導出され、Apache-SSLにかわるモジュールです。詳細は、第16章および第17章を参照してください。
IBM HTTP Server（IHS）v2 Webサーバー: Oracle Access Managerは、SSL対応または非対応のIHS v2およびIHS v2リバース・プロキシ・サーバーをサポートしています。詳細は、「Oracle Access Manager WebコンポーネントのためのWebサーバー構成の更新」を参照してください。
Domino Webサーバー: Domino WebサーバーにWebGateをインストールする前に、Domino Enterprise Server R5を正しくインストールおよび設定する必要があります。詳細は、「WebGateのためのLotus Domino Webサーバーの設定」を参照してください。
IIS Webサーバー: WebGateをインストールする前に、IIS Webサーバーがロックダウン・モードでないことを確認してください。ロックダウン・モードの場合、サーバーが再起動されてメタベースが再初期化されるまで、つまり、ロックダウン後に発生したアクティビティをIISが無視するまで、処理が進行しているように表示されます。
クライアント証明書認証を使用する場合は、WebGateのクライアント証明書を有効化する前にWebGateをホストするIIS Webサーバー上のSSLを有効化する必要があります。
NTFSをサポートするファイル・システムにインストールする場合にのみ、IIS WebGateでは、/accessディレクトリに対する様々な権限の設定が必要です。たとえば、FAT32ファイル・システムを実行しているWindows 2000コンピュータに、シンプル・モードまたは証明書モードでISAPI WebGateをインストールするとします。最後のインストール・パネルには、FAT32ファイル・システム上で設定できない様々な権限を手動で設定するための指示が表示されます。この場合、この指示は無視してください。
各IIS仮想Webサーバーには、独自のWebGate.dllファイルを仮想レベルでインストールするか、全サイトに影響を与える1つのWebGateをサイト・レベルでインストールできます。WebGate.dllをサイト・レベルでインストールしてすべての仮想ホストを制御するか、1つまたはすべての仮想ホスト用にWebGate.dllをインストールします。
postgate.dllファイルをコンピュータ・レベルでインストールする必要がある場合もあります。postgate.dllは、「IIS Webサーバー上におけるpostgate.dllのインストール」で説明されているように、\WebGate_install_dirにあります。インストールを複数回実行すると、このファイルの複数のバージョンが作成され、異常なOracle Access Managerの動作が発生する場合があります。この場合は、webgate.dllおよびpostgate.dllがそれぞれ1つずつ存在することを確認してください。
|
注意: postgate.dllは、常にサイト・レベルでインストールされます。なんらかの理由でWebGateを再インストールすると、postgate.dllも再インストールされます。この場合は、postgate.dllのコピーがサイト・レベルで1つのみ存在することを確認してください。 |
WebGateおよび関連フィルタをIISから完全に削除するには、フィルタをIISのリストから削除するだけでなく、他の手順も必要になります。IISは、その設定をすべてメタベース・ファイルに保持します。Windows 2000以降では、これは手動で変更できるXMLファイルです。また、メタベースの編集に利用できるツール（MetaEdit）もあります。MetaEditはRegeditに類似しており、一貫性チェックとブラウザ/エディタの機能があります。WebGateをIISから完全に削除するには、MetaEditを使用してメタベースを編集します。
ISAプロキシ・サーバー: ISAプロキシ・サーバーでは、すべてのISAPIフィルタをISAのインストール・ディレクトリ内にインストールする必要があります。ISAのインストール・ディレクトリ構造内では、任意の場所にインストールできます。
|
注意: 10g（10.1.4.3）ISAPI WebGateは、初期リリースでは利用できません。後日、利用可能になる予定です。 |
WebGateをISAプロキシ・サーバーにインストールする前に、次の手順を実行します。
ISA命令を含む一般ISAPIフィルタを次の場所でチェックします。
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/isa/isaisapi_5cq8.asp
内部および外部通信レイヤーが正しく構成されて動作していることを確認します。
インストール中に、これがISAのインストールかどうかの指定を求められます。次の点に注意してください。
質問に対し、これがISAプロキシ・サーバーのインストールであることを示します。
ISAのインストール・ディレクトリのパスをWebGateのインストール・パスとして指定します。
自動Webサーバー更新機能を使用して、WebGateのインストール中にISAプロキシ・サーバーを更新します。
WebGateのインストール後、ファイルconfigureISA4webgate.batを検索します。このファイルにより、プログラム的に追加する必要があるISAサーバー・フィルタを構成する多数のvbscriptおよびプロセスがコールされます。
Oracle HTTP Server Webサーバー: Oracle HTTP Server用のOracle Access Manager Webコンポーネントは、オープン・ソースのApacheに基づいています。
インストールするコンポーネントに対して十分な空きディスク領域がホスト・コンピュータにあることを確認する必要があります。ファイルを受け入れるために必要な空きディスク領域の容量は、コンポーネントのインストール・プログラムによって示されます。
参考として、各コンポーネントに必要な空きディスク領域の一般的な推定値を表2-1に示します。これらはあくまで例にすぎません。実際に必要となる領域は、プラットフォーム、インストールする言語およびその他の要因によって変わります。
コンポーネントは、デフォルトのディレクトリまたは任意のディレクトリにインストールできます。パス名を変更する際は、オペレーティング・システムで許容されている任意の文字を含めることができます。たとえば、Windowsシステムでは空白を含めることができますが、UNIXシステムではできません。
すべてのファイルおよびパス名は英語の文字のみで指定してください。ファイルおよびパス名に、国際文字は使用できません。
自動的に提供されるデフォルト名を変更する場合は、プラットフォームに関係なく、一貫したネーミング規則を使用することをお薦めします。たとえば、WindowsとUNIXベースの両方のプラットフォームで一貫したネーミングを提供するために、Windowsプラットフォームでのネーミングにスペースを使用せず、アンダースコアを使用するなどしてください。通常、Oracle Access Managerのデフォルトのインストール・ディレクトリは次のとおりです。
Windowsプラットフォーム: \Program Files\NetPoint\
UNIXプラットフォーム: /opt/netpoint/（すべて小文字）
表2-2に示すように、インストールするコンポーネントによって、パスは若干異なります。次に例を示します。
すべてのIdentityコンポーネントのパス名には、\identityが自動的に追加されます。
すべてのAccessコンポーネントのパス名には、\accessが自動的に追加されます。
WebPassおよびポリシー・マネージャでは、デフォルトのパス名に\WebComponentが（\identityまたは\accessとともに）自動的に追加されます。WebGateのパス名は、プラットフォームおよびWebサーバーのタイプによって異なります。
WebGateのパス名は、プラットフォームおよびWebサーバーのタイプによって異なります。たとえば、WebGateは、ポリシー・マネージャと同じ\webcomponent\accessディレクトリにインストールする必要があります（WebGateをポリシー・マネージャと同じディレクトリに格納して含めることが可能です）。
表2-2 デフォルトのディレクトリ・パス名
| コンポーネント | インストール・ディレクトリ |
|---|---|
|
アイデンティティ・サーバー |
Windows: \Program Files\NetPoint\identity UNIX: /opt/netpoint/identity このガイド内: \IdentityServer_install_dir\identity |
|
WebPass |
Windows: \Program Files\NetPoint\WebComponent\identity UNIX: /opt/netpoint/webcomponent/identity このガイド内: \WebPass_install_dir\identity |
|
アクセス・サーバー |
Windows: \Program Files\NetPoint\access UNIX: /opt/netpoint/access このガイド内: \AccessServer_install_dir\access |
|
ポリシー・マネージャ |
Windows: \Program Files\NetPoint\WebComponent\access UNIX: /opt/netpoint/webcomponent/access このガイド内: \PolicyManager_install_dir\access |
|
WebGate |
WebGateのデフォルトのインストール・ディレクトリ・パス名は、プラットフォームおよびWebサーバーのタイプによって異なります。次に例を示します。 Win32 ISAPI WebGate: \Program Files\NetPoint\Webgate Win32 OHS2 WebGate: \Program Files\NetPoint\WebComponent Win32 NSAPI WebGate: \Program Files\NetPoint\WebGate Linux Apache2 WebGate: /opt/netpoint/webgate Linux OHS2 WebGate: /opt/netpoint/webgate 注意: ポリシー・マネージャおよびWebPassを保護するには、「WebGateのガイドライン」で説明されているようにWebGateをインストールする必要があります。 このガイド内: \WebGate_install_dir\accessはWebGateインストール・ディレクトリ。 |
このマニュアルでは、各Oracle Access Managerコンポーネントのインストール・ディレクトリのパスは、表2-2に示すように、\component_install_dirに続いて、このパスに自動的に設定される接尾辞が追加されて表されます。一般的な形式を使用する場合、component_install_dir/identity|accessのように、component_install_dirの後に、一般的な接尾辞であるidentity|accessが続きます。
Oracle Access ManagerのインストールをUNIXシステムで開始する場合、-is:tempdirパス・パラメータを使用して、十分な領域のあるディレクトリをインストール先として指定できます。
-is:tempdirパラメータを次のコマンドで使用します。次に例を示します。
./ Oracle_Access_Manager10_1_4_3_0_sparc-s2_Identity_Server -is:tempdir /export/home/oblix/temp
パスは、相対パスではなく、絶対パスである必要があります。
パス/export/home/oblix/tempを、十分な領域があるファイル・システムに変更します。
インストールの前に、コンポーネント間で使用するトランスポート・セキュリティのタイプを決定する必要があります。Oracle Access Managerでは、コンポーネント間の通信に次の3つのタイプのトランスポート・セキュリティをサポートしています。
オープン: 暗号化されていない通信を許可、「オープン・モード」を参照
シンプル: Oracleによる暗号化をサポート、「シンプル・モード」を参照
証明書: サード・パーティの証明書が必要、「証明書モード」を参照
インストールと設定の後にキャッシュのフラッシュ操作を行う場合、Oracle Access Managerでは「キャッシュ・フラッシュ操作のための混合モード通信」を使用できます。
ここでは、インストール中にOracle Access Managerコンポーネント間にトランスポート・セキュリティを計画および実装する際に従う必要のあるガイドラインについて説明します。特に、次の点に注意してください。
すべてのアイデンティティ・システムのコンポーネント（アイデンティティ・サーバー・インスタンスおよびWebPassインスタンス）間のトランスポート・セキュリティは一致している必要があります（すべてオープン、シンプルまたは証明書モード）。
すべてのアクセス・システム・コンポーネント（ポリシー・マネージャ、アクセス・サーバーおよび関連WebGate）間のトランスポート・セキュリティは一致している必要があります（すべてオープン、シンプルまたは証明書モード）。
通告
アクセス・キャッシュ・フラッシュがアイデンティティ・サーバーで有効化されている場合、アイデンティティ・サーバーはアクセス・サーバーと通信します。この場合、次の5つの全コンポーネント間のトランスポート・セキュリティ・モードが同じである必要があります。
アイデンティティ・サーバーおよびWebPassインスタンス
ポリシー・マネージャ、アクセス・サーバーおよび関連付けられているWebGate
トランスポート・セキュリティが環境内で問題ない場合は、オープン・モードを使用します。オープン・モードでは、AccessGateとアクセス・サーバー間で認証や暗号化は行われません。AccessGateはアクセス・サーバーのIDの証明を要求せず、アクセス・サーバーはすべてのAccessGateからの接続を受け入れます。同様に、アイデンティティ・サーバーはWebPassからのIDの証明を要求しません。
ある程度のセキュリティを確保する場合は、シンプル・モードを使用します。たとえば、独自の認証局（CA）は管理しないけれども、パスワードをプレーン・テキストで送信することは避ける場合などです。
シンプル・モードでは、Webクライアント間（WebPassとアイデンティティ・サーバー間、ポリシー・マネージャとWebPass間、およびアクセス・サーバーとWebGate間）の通信は、TLS v1を使用して暗号化されます。シンプル・モードと証明書モードの両方では、Oracle Access ManagerコンポーネントはX.509デジタル証明書のみを使用します。この機能では、標準cert-decodeプラグインが証明書をデコードし、証明書情報を標準credential_mapping認証プラグインに渡す証明書認証がWebGateとアクセス・サーバー間で行われます。
Oracle Access Managerでは、すべてのAccessGateおよびアクセス・サーバー・コンポーネントにインストールされる独自の秘密鍵を持つCAが用意されています。Oracle Access Managerでは、追加のパスワード・チェックを行い、他のカスタマが同じCAを使用することを防止します。
各公開鍵には、対応する秘密鍵があり、この秘密鍵はOracle Access Managerによってaaa_key.pemファイル（Oracle Access Managerの場合はois_key.pem）に格納されます。\toolsサブディレクトリにあるopenSSLという名前のプログラムにより、秘密鍵が生成されます。openSSLプログラムは、各AccessGateおよびアクセス・サーバーのインストール中に自動的にコールされます。証明書モードとは異なり、Oracle Access Managerによって秘密鍵はすでに生成されています。この鍵は、インストール中に自動的に提供されます。
シンプル・モードでは、証明書モードと同様に、各コンポーネントのインストール中に指定するPrivacy Enhanced Mail（PEM）パスフレーズを使用して秘密鍵を保護します。インストール中に、PEMパスフレーズはグローバル・アクセス・プロトコル・パスフレーズとして参照される場合もあります。このマニュアルでは、パスフレーズという総称を一般に使用します。
|
注意: AccessGateまたはアクセス・サーバーは、秘密鍵を使用する前に、正しいパスフレーズを必要とします。パスフレーズは、名目上暗号化されているpassword.lstというファイルに格納されます。シンプル・モードでは、PEMパスフレーズは各WebGateおよびアクセス・サーバー・インスタンスで同一のものです。 |
アクセス・サーバーのインストール中にパスワードをファイルに格納しない場合、次のようになります。
Windowsでは、アクセス・サーバーを起動するたびにパスフレーズを求められます。
UNIXでは、start_access_serverスクリプトを起動するたびに、-Pオプションを使用してパスワードを渡す必要があります。
サーバー証明書を処理する認証局（CA）が内部にある場合は、証明書（SSL）モードを使用します。証明書モードでは、WebGateとアクセス・サーバー間、およびアイデンティティ・サーバーとWebPass間の通信は、Transport Layer Security、RFC 2246（TLS v1）を使用して暗号化されます。シンプル・モードと証明書モードの両方では、Oracle Access ManagerコンポーネントはX.509デジタル証明書のみを使用します。この機能では、標準cert-decodeプラグインが証明書をデコードし、証明書情報を標準credential_mapping認証プラグインに渡す証明書認証がWebGateとアクセス・サーバー間で行われます。
各公開鍵には、対応する秘密鍵があり、この秘密鍵はOracle Access Managerによってアクセス・サーバーの場合はaaa_key.pemファイル（アイデンティティ・サーバーの場合はois_key.pem）に格納されます。
\toolsサブディレクトリにあるopenSSLという名前のプログラムにより、秘密鍵が生成されます。このプログラムは、各AccessGateおよびアクセス・サーバーのインストール中に自動的にコールされます。インストール中に、CAから取得した証明書を提示します。
秘密鍵は、各コンポーネントのインストール時に指定するPrivacy Enhanced Mail（PEM）パスフレーズを使用して保護します。このマニュアルでは、パスフレーズという用語を使用します。
|
注意: WebGateまたはアクセス・サーバーは、秘密鍵を使用する前に、正しいPEMパスフレーズを必要とします。PEMパスフレーズは、WebGateパスフレーズおよびトランスポート・パスワードとしても参照されます。このパスフレーズは、名目上暗号化されているpassword.lstというファイル（Oracle Access Managerの場合はpassword.xml）に格納できます。これは、各WebGateおよびアクセス・サーバーで異なるパスフレーズにすることができます。 |
Oracle Access Managerのインストール中に、証明書をまだ取得していない場合はこれをリクエストできます。この場合、ステータスが証明書保留中でも、インストールを完了できます。ただし、証明書が発行されて適切なディレクトリにコピーされるまで、コンポーネントまたはシステムは設定できません。
証明書リクエストを生成する場合は、次の点に注意してください。
リクエストが保留中の場合、インストールは通常どおり完了できますが、設定は実行できません。
リクエストは、コンポーネントのインストール・ディレクトリに配置する必要があります。次に例を示します。
IdentityServer_install_dir\identity\oblix\config\ois_req.pem
通常、.pemファイルには、リクエストを表す暗号化された文字列の他に、余分なデータも含まれています。
選択したCAから次の情報を「証明書リクエスト」フィールドにコピーし、リクエストをCAに送信する必要があります（Oracleではこれを行いません）。
*-----------Begin request--------------- A97C7u54Sd0000lotsofrandomstuff864Ouwst 89111mmmIyoSSTKHS9670sd *-----------End request-----------------
CAから証明書が返されたら、証明書ファイルを適切なコンポーネントのインストール・ディレクトリにコピーし、コンポーネント・サーバーまたはサービスを再起動できます。次に例を示します。
\IdentityServer_install_dir\identity\oblix\config
詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
アクセス・サーバーのインストール中にパスフレーズまたはパスワードをファイルに格納しない場合、次のようになります。
Windows上: アクセス・サーバーを起動するたびにパスフレーズを求められます。
UNIX上: start_access_serverスクリプトを起動するたびに、-Pオプションを使用してパスワードを渡す必要があります。
各トランスポート・セキュリティ・モードの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
Oracle Access Managerのインストールおよび構成時には、前述のように、特定のトランスポート・セキュリティ・ガイドラインに従う必要があります。インストールおよび設定後、キャッシュ・フラッシュ操作を行うために混合モード通信の使用を選択できます。
Oracle Access Manager 10g（10.1.4.2.0）では、オープン・モード通信を使用してアイデンティティ・サーバーとアクセス・サーバー間のキャッシュ・フラッシュ・リクエストを処理する一方で、それ以外のすべてのリクエストの処理に、シンプル・モードと証明書モードを維持する方法が提供されました。このタイプの構成は、混合セキュリティ・モード（または混合トランスポート・セキュリティ・モード）通信と呼ばれます。Oracle Access Manager 10g（10.1.4.3）では、キャッシュ・フラッシュ・リクエストを処理するための混合モード通信を実装する方法が効率化されています。
詳細は、『Oracle Access Managerデプロイメント・ガイド』のキャッシングとクローニングに関する章を参照してください。
WebPass、ポリシー・マネージャおよびWebGateコンポーネントをホストするWebサーバーが1つ以上必要です。アイデンティティ・サーバーおよびアクセス・サーバーでは、Webサーバー・インスタンスは不要です。
WebPassとアイデンティティ・サーバーを同じコンピュータにインストールする場合、WebPassのインストール先をアイデンティティ・サーバーと同じにすることはできません。
ポリシー・マネージャとWebPassを同じコンピュータにインストールする場合は、この2つを同じレベルに配置する必要があります。たとえば、WebPassのインストール・パスがC:\OracleAccessManager\WebComponentの場合、同じコンピュータのポリシー・マネージャのインストール・パスも同じにする必要があります。
WebPassのインストール・パスには\identityが自動的に追加されます。
ポリシー・マネージャのインストール・パスには\accessが自動的に追加されます。
インストールを開始する前に、Webサーバーがすべての要件を満たすことを確認してください。詳細は、次を参照してください。
「動作保証要件の確認」の手順に従って、使用するWebサーバーのバージョンがサポートされているプラットフォーム（ポリシー・マネージャ、WebPassのWebサーバーおよびWebGateのWebサーバー）のリストに含まれていることを確認します。
データに基づいて実行されるWebサーバーの新しいインスタンスを作成し、他のアプリケーションのサービスを停止せずに変更を容易に行えるようにします。詳細は、Webサーバーのドキュメントを参照してください。
Webサーバーのインストール先を計画し、詳細をインストール準備のチェックリストに記録します。
詳細は、次を参照してください。
Oracle Access Manager Webコンポーネント（WebPass、ポリシー・マネージャおよびWebGate）には、個別のWebサーバー固有のパッケージが提供されています。必ず使用しているWebサーバーおよびプラットフォームに適したパッケージを選択してください。
10g（10.1.4.3）初期リリースでは、サポート対象WebサーバーのWebコンポーネントのうち、含まれていないものもあります。詳細は、「動作保証要件の確認」および「最新のインストーラ、パッチ・セット、バンドル・パッチおよび動作保証されたエージェントの入手」を参照してください。
Oracle Access Manager Webコンポーネント・パッケージでは、次のネーミング規則が使用されます。
ISAPI: Microsoft Internet Information Serverと通信するWebサーバー・コンポーネント（Windows環境の場合はIIS Webサーバー）の識別にOracle Access Managerで使用するインターネットWebサーバー拡張機能。IIS WebサーバーおよびOracle Access Managerの詳細は、第19章を参照してください。
NSAPI: WindowsまたはSolaris上で実行されているSun（以前のNetscape/iPlanet）のWebサーバーと通信するWebコンポーネントの識別にOracle Access Managerで使用するインターネットWebサーバー拡張機能。
|
注意: NSAPI Policy Manager for Solaris: ポリシー・マネージャとディレクトリ・サーバーの間のSSL対応通信がサポートされます。 |
Apache: Windows、Solaris、Linuxなどの各種プラットフォーム上で実行されているApache Webサーバーと通信するWebコンポーネントの識別にOracle Access Managerで使用するインターネットWebサーバー拡張機能。詳細は、「動作保証要件の確認」を参照してください。
|
注意: Oracle Access Managerは、SSL対応または非対応のApacheをサポートしています。SSL対応通信では、Apache-SSLではなく、mod_ssl付きのApacheがサポートされています。mod_sslは、Apache-SSLから導出され、Apache-SSLにかわるモジュールです。 |
Oracle Access Managerでは、SSL対応または非対応のApacheをサポートするコンポーネント用の単一パッケージが用意されています。次に例を示します。
IHS: 各種プラットフォーム上で実行されているIBM HTTP（IHS）Webサーバー（powered by Apache）と通信するOracle Access Manager Webコンポーネントを識別するインターネットWebサーバー拡張機能。次に例を示します。
IBM-AIX上のIHS2_WebGate powered by Apache v2。第17章を参照してください。
|
注意: Apache v1.3に基づくIHS用のWebコンポーネントはサポートされていません。 |
OHSはインターネットWebサーバーの拡張機能です。これは、オープン・ソースApacheに基づくOracle HTTP Server（OHS）と通信するOracle Access Manager Webコンポーネントを識別します。
Oracle Access Managerパッケージ名は、OHS11g（Apache v2.2に基づく）、OHS2（Apache v2に基づく）およびOHS（Apache v1.3に基づく）です。
『Oracle Fusion Middlewareセキュリティ・ガイド』で説明されているように、OHS11g WebGateは、他の任意のWebGateとして使用できます。また、Oracle Fusion Middleware 11gでエンタープライズレベルのSSOをサポートする場合に必要になります。
『Oracle Access Manager統合ガイド』で説明されているように、10gのシングル・サインオンを有効にするには、OHSまたはOHS2 WebGateをOracle Application Serverとともにインストールする必要があります。
OHSまたはOHS2 WebPassおよびポリシー・マネージャは、Oracle Application Serverで使用できます。ただし、Apache用のWebPassとポリシー・マネージャもこのアプリケーションに対してサポートされます。
詳細は、第16章および第17章を参照してください。バージョン・サポートは、「動作保証要件の確認」で説明されているように、Oracle Technology Networkを参照してください。
Domino: 各種プラットフォーム上で実行されているLotus Domino Webサーバーと通信するWebコンポーネントの識別にOracle Access Managerで使用するインターネットWebサーバー拡張機能。
第18章を参照してください。バージョン・サポートは、「動作保証要件の確認」で説明されているように、Oracle Technology Networkを参照してください。
Oracle Access Managerのインストールに含まれるWebサーバーに関しては、次の一般的な考慮点を理解しておくことをお薦めします。
アイデンティティ・サーバーの各インスタンスは、Webサーバーのホスト上にインストールされているWebPassプラグインを介してWebサーバーと通信します。
ポリシー・マネージャとWebPassを同じWebサーバーにインストールする場合は、この2つを同じディレクトリ・レベルに配置する必要があります。たとえば、WebPassとポリシー・マネージャの両コンポーネントを同じコンピュータにインストールする際、WebPassのインストール・ディレクトリとしてC:\OracleAccessManager\WebComponentを指定した場合は、ポリシー・マネージャのインストール・ディレクトリにもこのディレクトリを指定する必要があります。WebPassのインストール・ディレクトリには\identityが追加され、ポリシー・マネージャのインストール・ディレクトリには\accessが追加されます。
資格証明（ユーザー名とパスワード）をOracle Access Manager Webコンポーネントに渡すWebサーバーは、SSL対応である必要があります。それ以外のWebサーバーは、SSL対応である必要はありません。ユーザー名とパスワードは、HTTP POSTデータとしてブラウザからWebサーバーに送信されます。WebサーバーがSSL対応でないと、ユーザー名とパスワードはHTTPヘッダーにクリア・テキストとして含まれます。SSL対応Webサーバーでは、データはHTTP POSTであるため、より安全になります。
WebPass、ポリシー・マネージャおよびWebGateのインストール中は、Oracle Access Managerと連動するようにWebサーバーを構成する必要があります。このWebサーバー構成の更新を自動または手動で実行するように指定できます。
|
注意: Webサーバーの更新プロセスを簡素化してエラーを回避するために、自動構成オプションを使用することをお薦めします。 |
アイデンティティ・システムまたはポリシー・マネージャにアクセスする場合は、対象のアイデンティティ・システムまたはポリシー・マネージャに接続されているWebPassインスタンスのWebサーバーのホスト名とWebPassのWebサーバー・インスタンスのHTTPポートを指定する必要があります。
UNIXシステムでは、WebPass、ポリシー・マネージャおよびWebGateのインストール中に、Webサーバーで使用するユーザー名とグループを指定する必要があります。通常、デフォルトはnobodyです。HP-UXでは、デフォルトはWWW（ユーザー名）およびothers（グループ）です。
Linuxシステムでは、ApacheおよびOracle HTTP Serverを使用するOracle Access Manager Webコンポーネントをインストールする場合、Webサーバーを実行しているのと同じユーザーとしてインストールするよう求められます。この情報は、UserおよびGroupディレクティブ・エントリのhttpd.confファイルにあります。
WebGateのWebサーバーに関する追加のガイドラインは、「WebGateのガイドライン」を参照してください。
インストールには、1つ以上のディレクトリ・サーバーが必要です。インストールを開始する前に、ディレクトリ・サーバーがOracle Access Managerの要件を満たし、適切に準備されていることを確認してください。
Active Directory（またはADAM）と一緒にOracle Access Managerをインストールする場合の詳細は、付録A（または付録B）を参照してください。
「動作保証要件の確認」で説明されているように、ディレクトリ・サーバーがサポートされているプラットフォームのリストに記載されていることを確認します。
|
注意: Siemens DirXディレクトリは、サポートされていません。ただし、インストール画面では、可能なオプションとしてDirXが表示される場合があります。 |
「バインドDNの割当て」で説明されているように、インストールおよび設定を完了するマスター管理者として使用される担当者をディレクトリで1名以上特定します。
「ディレクトリ・サーバーの領域の評価」で説明されているように、ディレクトリ・サーバーの領域を推定し、十分な領域があることを確認します。
「ディレクトリ・サーバーの通信の保護」で説明されているように、ディレクトリ・サーバーとOracle Access Managerコンポーネントとの通信を保護する方法を決定します。
1つ以上のディレクトリ・サーバー・インスタンスがOracle Access Managerのインストールに使用可能であることを確認し、「データ記憶域の要件」で説明されているように、ユーザー・データを構成およびポリシー・データとは別に格納するかどうかを決定します。
次の項で説明されているように、データの検索ベース、構成DNおよびポリシー・ベースを確立します。
「Personオブジェクト・クラスおよびGroupオブジェクト・クラスの概要」で説明されているように、PersonおよびGroupオブジェクト・クラスを記録します。
「インストール準備のチェックリスト」で説明されているように、次のようなディレクトリ・サーバーの詳細を記録します。
各ディレクトリ・サーバーのホスト名、IPアドレス、ネットワーク・ポートおよびルートDN。
ディレクトリ・サーバーのユーザー・ログオンIDおよびパスワード。
「スキーマおよび属性の自動更新と手動更新」で説明されているように、スキーマの更新方法（自動または手動）を決定します。
Oracle Access Managerで使用可能なスキーマ・データを作成する方法の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
すべてのオブジェクトの継承は、スーパー・クラスが構造化オブジェクト・クラスと補助クラスの両方に共通するという仮定に基づきます。この仮定以外では、オブジェクト・クラスの拡張は不可能です。
アイデンティティ・サーバーとポリシー・マネージャのインストールおよび設定中に、バインドDN（Oracle Access ManagerではルートDNとも呼ばれる）を指定するよう求められます。Oracle Access Managerのバインド先のディレクトリ・アカウントには、読取り、書込み、追加、削除、検索、比較および自己書込み権限が必要です。これらの権限を持つユーザーの作成方法は、ディレクトリ・ベンダーによって異なります。詳細は、ディレクトリのドキュメントを参照してください。
ネイティブ・ディレクトリのアクセス制御命令（ACI）およびアクセス制御リスト（ACL）によってOracle Access ManagerのバインドDNアカウントのアクセスがユーザーおよび構成ブランチに制限されないようにしてください。制限されると、Oracle Access ManagerのバインドDNは、パスワード・ポリシーなどのネイティブ・ディレクトリ・サーバーの制約によって影響を受ける場合があります。
また、バインドDNとして作成するユーザーは、Oracle Access Managerソフトウェアのアップグレードの実行時にスキーマにアクセスできる必要があります。これはスキーマがアップグレード中に変更される場合があるためです。スキーマがバインドDNにアクセスできない場合、アップグレードは失敗し、アップグレードの完了には手動の操作が必要になります。これには、ACLでディレクトリ・スキーマ・エントリを変更することが含まれます。
次のガイドラインを考慮してください。
Oracle Internet Directory: Oracle Internet Directoryを使用するアイデンティティ・サーバーをインストールする場合、完全修飾されたDN（cn=orcladmin,cn=users,dc=us,dc=mycompany,dc=com）ではなく、ルートDNをスーパーユーザーcn=orcladminとして指定する必要があります。
Sun（以前のiPlanet）: バインドDNユーザーをディレクトリ・マネージャ以外にすることをお薦めします。かわりに、別のユーザーをバインドDNとして作成します。ディレクトリ・マネージャ・アカウントは、ディレクトリ・サーバーのサイズとタイムアウトの制限を無視します。このため、大規模な検索によってディレクトリ・サーバーの動作が妨げられる場合があります。
詳細は、「ユーザー・データおよび検索ベース」を参照してください。
ディレクトリ・サーバーでは、各ユーザー・オブジェクトに対して少なくとも1KBのRAMが必要です。各Oracleオブジェクトには、少なくとも16KBのRAMが必要です。次の情報を参照し、インストールに必要な領域を計算してください。
250,000のユーザー・オブジェクトが含まれるディレクトリ・サーバーでは、最大で250MBのRAMが必要です。
このサイズのディレクトリでは、5,000のOracleオブジェクト（250,000のユーザー・エントリに対する高い見積り）を含むことができ、これによって追加の80MBが必要になります。
このデータ量に対する索引には、Oracleオブジェクトの約2倍の領域（約160MB）が必要です。
アイデンティティ・サーバー、ポリシー・マネージャおよびアクセス・サーバーは、ディレクトリ・サーバーと通信します。Oracle Access Managerのインストールおよび設定中に、ディレクトリ・サーバーと通信するコンポーネント用のデフォルトのディレクトリ・プロファイルが作成されます。各ディレクトリ・プロファイルには、ディレクトリ・サーバーの通信方法などが示されているデータベース（DB）インスタンス・プロファイルが含まれています。Oracle Access Managerとディレクトリ・サーバー間では、非セキュアとセキュアの2つの通信方法を使用できます。Oracle Access Managerとディレクトリ・サーバー間のセキュア通信は、SSL対応通信とも呼ばれます。非セキュア通信は、オープン通信とも呼ばれます。
Oracle Access Managerは、base64形式のCA証明書をサポートしています。SSL対応通信では、サード・パーティの認証局から提供されるbase64形式の署名者の証明書（ルートCA証明書）を必要とします。たとえば、アイデンティティ・サーバーとディレクトリ・サーバー間でSSLを使用する場合、アイデンティティ・サーバーのインストール中に、SSL対応通信を確立するための証明書へのパスを指定するよう求められます。この場合、ディレクトリ・サーバーの指示に従い、証明書がディレクトリ・サーバーにインストールされる必要があります。ディレクトリ・サーバーがクライアント認証を要求しないようにしてください（この方法は、ディレクトリ・サーバーのドキュメントを参照してください）。
ディレクトリ・サーバーにSSLを構成する場合、Oracle Access Managerではサーバー認証のみをサポートしていることに注意してください。クライアント認証はサポートされていません。Oracle Access Managerでは、製品の設定中にインポートされたルートCA証明書に対してサーバー証明書を検証します。
Oracle Access Managerとディレクトリ・サーバー間の通信を計画および構成する際は、次のガイドラインが適用されます。
アイデンティティ・サーバーとディレクトリ・サーバー間の通信は同じである必要はありません。
アクセス・サーバーとディレクトリ・サーバー間の通信は同じである必要はありません。
すべてのポリシー・マネージャとディレクトリ・サーバー間の通信は一貫している必要があります（すべてSSL対応またはすべてオープン）。
|
注意: ユーザー・データを構成およびポリシー・データとは異なるディレクトリ・サーバー・タイプに格納する場合、複数のルートCA証明書がサポートされます。ユーザー・データ、構成データおよびポリシー・データをディレクトリ・サーバー・タイプに格納すると、それぞれが個別のルートCAを使用できます。詳細は、「データ記憶域の要件」を参照してください。 |
ポリシー・マネージャがSun（以前のNetscape）Webサーバーを使用するSolaris上にインストールされた場合、ディレクトリ・サーバーとのSSL対応通信はサポートされません。Solaris上にポリシー・マネージャがある異機種間環境では、ディレクトリ・サーバーとインストールするすべてのポリシー・マネージャとの間にオープン通信を指定してください。
Oracle Access Managerコンポーネントは、ディレクトリ・サーバーとの通信に同じモードを使用するようにインストールされていなくても、DBプロファイルを共有できます。たとえば、アイデンティティ・サーバーとアクセス・サーバーがオープン・モードでインストールされており、ポリシー・マネージャがSSL対応でインストールされているとします。この場合、ディレクトリ・サーバーと通信する各Oracle Access Managerコンポーネントに対してcert8.dbおよびkey3.dbファイルが存在する必要があり、これらのファイルがOracle Access Managerのcomponent_install_dir\identity|access\oblix\configディレクトリに置かれている必要があります。これらのファイルは、他のOracle Access Managerコンポーネント・ディレクトリからコピーするか、genCert（ポリシー・マネージャ）またはその他のユーティリティを実行して生成できます。
|
注意: Oracle Access Managerは、cert7.db（アップグレードされた環境）とcert8.db（新規インストール）の両方の証明書ストアと連動します。アップグレードされた環境の詳細は、『Oracle Access Managerアップグレード・ガイド』を参照してください。 |
すべてのディレクトリ・サーバー: ディレクトリ・サーバーにSSLを構成する場合、Oracle Access Managerではサーバー認証のみをサポートしていることに注意してください。クライアント認証はサポートされていません。Oracle Access Managerでは、製品の設定中にインポートされたルートCA証明書に対してサーバー証明書を検証します。
Sun One Directory Server v5.1またはv5.2: SSL対応の場合、Oracle Access Managerサーバーはリクエストを完了できない場合があります。この問題を回避するには、「Sun One Directory Server v5 SSLの問題」を参照してください。
タスクの概要: ディレクトリ・サーバーの通信のセキュリティの定義
Oracle Access Managerをインストールする前に、この項および「ディレクトリ・サーバーの要件の実現」で説明されているように、すべてのディレクトリ・サーバー要件を確認してください。
Oracle Access Managerをインストールする前に、ディレクトリ・サーバーのベンダーおよび証明書のドキュメントに従い、必要に応じてSSLをディレクトリ・サーバーで有効化します。次に例を示します。
ディレクトリ・サーバー・インスタンスがない場合は、これを作成します。
そのインスタンスの証明書をCAに申請します。
証明書をインストールしてディレクトリ・サーバー・インスタンスを暗号化し、ディレクトリ・サーバーを再起動します。
|
注意: ユーザー・データを構成およびポリシー・データとは異なるディレクトリ・サーバー・タイプに格納する場合、複数のルートCA証明書がサポートされます。 |
「ディレクトリ・サーバーの通信の保護」で説明されているように、アイデンティティ・サーバーのインストール中に、ディレクトリ・サーバーとアイデンティティ・サーバー間に適切な通信を選択します。
この項および第6章「アイデンティティ・システムの設定」で説明されているように、アイデンティティ・システムの設定中に、ディレクトリ・サーバーとアイデンティティ・システム間に適切な通信を選択します。
|
注意: 下位CAによって生成された証明書を使用している場合、ルートCAの証明書は下位CA証明書とともに、xxx_chain.pemに存在する必要があります。検証を適切に行い、アイデンティティ・システムを正常に設定するためには、両方の証明書が存在する必要があります。 |
「ディレクトリ・サーバーの通信の保護」で説明されているように、ポリシー・マネージャのインストールおよび設定中に、ディレクトリ・サーバーとポリシー・マネージャ間に適切な通信を選択します。
「ディレクトリ・サーバーの通信の保護」で説明されているように、アクセス・サーバーのインストール中に、ディレクトリ・サーバーとアクセス・サーバー間に適切な通信を選択します。
『Oracle Access Manager IDおよび共通管理ガイド』で説明されているように、インストール後に、Oracle Access Managerとディレクトリ・サーバー間の通信モードを変更できます。
ここでは、データ記憶域のオプションと要件の詳細を説明します。この情報は、アイデンティティ・サーバー、ポリシー・マネージャおよびアクセス・サーバーに関係があります。
すべてのディレクトリ・サーバー・タイプ: Oracle Access Managerは、単一のディレクトリ・サーバーへのユーザー・データ、Oracle Access Manager構成データおよびポリシー・データの格納をサポートしています。
また、ユーザー・データをあるディレクトリ・サーバー・タイプに格納し、Oracle Access Managerの構成およびポリシー・データを別のタイプのディレクトリ・サーバーに格納することもできます。たとえば、ユーザー・データをActive Directoryに格納し、Oracle Access Managerの構成およびポリシー・データをADAM（またはOracle Internet Directory）に格納できます。
ユーザー・データを構成およびポリシー・データとは別のディレクトリ・サーバーのタイプに格納する場合、次のようになります。
SSLでは、個別のルートCAがサポートされます。
図2-1は、ユーザー・データを構成およびポリシー・データとは別のディレクトリ・サーバー・タイプに格納した場合を示しています。
データを異なるディレクトリのタイプに格納する場合、ユーザー・データの検索ベース、構成DNおよびポリシー・ベースは一意である必要があります。
Oracle Access Managerのインストールおよび設定中に、環境に適したユーザーおよび構成ディレクトリ・サーバー・タイプを選択する必要があります。
構成およびポリシー・データの両方をユーザー・データとは異なるディレクトリ・サーバー・タイプに格納した場合、次のファイルが機能します。
IdentityServer_install_dir\identity\oblix\data\common\ldaposdreferentialintegrityparams.xml
これは、構成およびポリシー・データがユーザー・データとは異なるディレクトリ・サーバー・タイプに格納される場合、ldapreferentialintegrityparams.xmlファイル内の"referential_integrity_using" Value="oblix"が適用されないためです。
また、この場合は、サーバーをDBプロファイルにマップするために、元のexclude_attrsファイルではなく、次のファイルがアイデンティティ・システムとアクセス・システムによって使用されます。
IdentityServer_install_dir\identity\oblix\data\common\
PolicyManager_install_dir\access\oblix\data\common\
AccessServer_install_dir\access\oblix\data\common\
exclude_oblix_attrs.lst
ユーザー・データのディレクトリ・サーバーのすべてのパラメータは、DBプロファイルを使用して読み取られます。構成データのディレクトリ・サーバーでは、DBサブタイプは次の場所から読み取られます。
component_install_dir\identity|access\oblix\config\ldap\*DB.xml
Data Anywhere: 第10章「Oracle Virtual Directoryを使用したOracle Access Managerの設定」で説明されているように、このディレクトリ・サーバー・オプションは、ユーザー・データのディレクトリ・サーバーおよびOracle Virtual Directoryを使用した実装でのみ使用できます。
Data Anywhereは、ユーザー・データを複数のソース（RDBMSおよびLDAPディレクトリなど）から、アイデンティティ・システムで管理できる仮想LDAPツリーに集約および統合するデータ管理レイヤーであり、アクセス・システムを使用した認証および認可のサポートに使用されます。
Oracle Virtual Directoryを使用するようにOracle Access Managerを構成する場合、Userオブジェクト・クラスとGroupオブジェクト・クラスにinetOrgPersonおよびgroupOfUniqueNamesが必要です。
Oracle Access Manager構成およびポリシー・データを含むLDAPディレクトリ・ブランチは、VDSまたはユーザー・データのホストであるディレクトリ・サーバーとは別の1つ以上のディレクトリ・サーバーに存在する必要があります。Oracle Access Managerアプリケーションは、VDS仮想ディレクトリ外に存在する構成およびポリシー情報のみを認識します。
|
警告: Data Anywhereとともに使用するOracle Access Managerをインストールする前に、第10章「Oracle Virtual Directoryを使用したOracle Access Managerの設定」を読み、指定されているアクティビティを完了してください。 |
IBM Directory Server（以前のSecureWay）: すべてのディレクトリ・サーバー・タイプについての前述の詳細を参照してください。
Oracle Internet DirectoryおよびSun: Oracle Access Managerでは、Oracle Internet Directory（複数レルム）およびSunディレクトリ・サーバーを使用して、構成およびポリシー・データとは別にユーザー・データを格納できます。これらのディレクトリ・サーバーを使用すると、データを同じディレクトリ・サーバーに格納するか、同じタイプの別のディレクトリ・サーバーに格納できます。次に例を示します。
データを異なるディレクトリに格納する場合、ユーザー・データの検索ベース、構成DNおよびポリシー・ベースは結合されていない必要があります。つまり、ポリシーおよび構成データを異なるSunディレクトリ、または複数のOracle Internet Directoryレルムに格納する場合、これらのDNは一意である必要があります。
|
注意: Oracle Internet Directoryでは、構成DNの値は、ID管理レルムのコンテキスト（cn=OracleContext）から移入されます。また、デフォルトでは、検索ベースは構成DNと同じです。 |
複数のユーザー・データ・ディレクトリおよび検索ベースを使用する場合、インストールおよび設定中にメインのユーザー・データ・ディレクトリと検索ベースを指定してください。
アイデンティティ・サーバーのインストールとSun Java System Directory Server 6.0: Sun Java Directory Server 6.0とOracle Access Managerの動作保証は、10g（10.1.4.0.1）のリリース後に行われました。そのため、アイデンティティ・サーバーのインストール中に、Sun Java Directory Server 6.0を選択するオプションはありません。Sun Directory Server 5.xを選択すると、自動スキーマ更新の実行時に構成が失敗します。詳細は、「アイデンティティ・サーバーのインストールとSun Java System Directory Server 6.0」を参照してください。
Sun One Directory Server v5では、問題を解決するためにパッチが必要です。Sun One Directory Server v6.3では、Oracle Access Managerが使用するノードの構造が変更されています。詳細は、次の項のトラブルシューティングのヒントを参照してください。
Active Directory、ADAMおよびNovell eDirectoryに関する通告
Novell社のeDirectory、Active DirectoryおよびActive Directoryアプリケーション・モード（ADAM）による参照整合性の厳格な保持のため、Oracle Access Managerの構成データおよびポリシー・データは、共通のディレクトリ環境に格納する必要があります。Novell eDirectory、Active DirectoryおよびADAMは、LDAPの実装ではより厳格であり、参照整合性を強化します。これらのディレクトリ・サーバーでは、相互参照（DN参照など）を使用してデータを2つの個別のツリー/フォレストに格納することはできません。Oracle Access Managerでは、ユーザー・データを製品の構成データおよびポリシー・データとは別のディレクトリを用意すると、同じNovellディレクトリ・サーバー・ツリーまたはActive Directoryフォレストに意図せず存在する複数の異なるサーバー上で個別のLDAP（非結合）ツリーを使用できます。Oracle Access Managerの構成データおよびポリシー・データは、ディレクトリ環境全体の個別の部分に格納でき、このため、Oracle Access Manager固有の情報をユーザー・データから分離できます。
Active Directory上: Active Directory環境では、Oracle Access Managerの構成データをある特定のドメイン・コントローラに格納し、ポリシー・データを別のコントローラに格納できます。ポリシー・データと構成データのドメイン・コントローラは、同じフォレスト内に存在する必要があります。ユーザー・データは、同じフォレスト内に存在する必要はありません。レプリケーションについては、これを回避するか、十分に理解することが重要です。詳細は、付録A「Active Directoryに対するOracle Access Managerのインストール」を参照してください。
ユーザー・データを構成およびポリシー・データとは別のディレクトリ・サーバー・タイプに格納する場合、補助クラスのサポートが一致する必要があります。Oracle Access Managerでは、動的補助に対する混合モードはサポートしていません。ユーザー・データのディレクトリ・サーバーと構成データのディレクトリ・サーバーが別々のフォレストに存在する場合は、ADSIを使用していずれかのディレクトリ・サーバーに接続できます。ADSIでは、両方のフォレストに対して同時にバインドを実行することはできません。ADSIが有効化されている場合、次のようになります。
ユーザー・データのディレクトリ・サーバー: アイデンティティ・サーバーおよびポリシー・マネージャの設定中に、ADSIがユーザー・データのディレクトリ・サーバー・タイプに選択された場合、構成のディレクトリ・サーバー・タイプの詳細を選択する際に「ADSI」チェック・ボックスは使用できません。
構成データのサーバー: このディレクトリ・タイプでADSIが有効化されている場合、次のようになります。
アイデンティティ・サーバーのglobalparams.xmlファイルで、パラメータ"IsADSIEnabled"および値"true"が表示されます。
ポリシー・マネージャのglobalparams.lstファイルで、パラメータ"adsiEnabled"=trueが表示されます。
Active DirectoryのdbSubType "adsiEnabled"フラグは、DBプロファイルを使用して読み取られます。ADSIがユーザー・データのディレクトリ・サーバーに対して有効化されている場合、この値はADSIです。ActiveDirectoryおよびADAMフラグはglobalparams.xmlファイルから削除されます。
詳細は、付録A「Active Directoryに対するOracle Access Managerのインストール」を参照してください。
ユーザー・データのディレクトリ・サーバー・タイプがActive Directoryの場合、exclude_attrs-ad.xmlのコンテンツは次の場所にコピーされます。
IdentityServer_install_dir\identity\oblix\data\common\exclude_user_attrs.xml
構成およびポリシー・データのディレクトリ・タイプがActive Directoryの場合、exclude_attrs-ad.xml .lstのコンテンツは次の場所にコピーされます。
IdentityServer_install_dir\identity\oblix\data\common\exclude_oblix_attrs.xml
PolicyManager_install_dir \access\oblix\data\common\exclude_oblix_attrs.lst
AccessServer_install_dir\access\oblix\data\common\exclude_oblix_attrs.lst
|
注意: ActiveDirectoryフラグはglobalparams.xmlで表示されなくなります。 |
ユーザー・データは、構成およびポリシー・データとは異なるパーティションに格納できます。
ユーザー・データは、構成およびポリシー・データとは別のディレクトリ・サーバー・タイプに格納できます。
Oracle Access Managerは、構成およびポリシーDNに対して、オブジェクト・クラス属性の値がorganizationalUnit（ou）のノードを必要とします。
構成およびポリシー・データは、同じADAMインスタンスを共有するか、異なるADAMインスタンスに格納できます。
詳細は、付録B「ADAMに対するOracle Access Managerのインストール」を参照してください。
Novell eDirectory: デフォルトでは、Novell eDirectory用のOracleスキーマでは、ブラウザベースでのアイデンティティ・システムの設定中に、ドメイン・ノード（dc=us,dc=oracle,dc=comなど）の下にoblixノード（o=oblix,<config-dn>）を作成することはサポートされていません。つまり、ブラウザベースでアイデンティティ・システムを設定しているときは、ドメイン・ノードを構成のベースとして使用できません。回避方法は、「Novell eDirectoryの問題」で説明されています。
GroupOfUniqueNamesに関する問題を回避するために、LDAPグループ・オブジェクトのGroupsに対するクラス・マッピングを変更し、groupOfNames（デフォルト）ではなくGroupOfUniqueNamesを参照するようにします。変更しない場合、いずれかの属性を保存するたびに、スキーマ違反が発生する可能性があり、グループが正しく機能しないことがあります。たとえば、NDSの場合、groupOfUniqueNames LDAPグループ・オブジェクトは、groupOfNamesオブジェクトより前に一覧表示される必要があります。
NDS Console1による2つのグループ・オブジェクトの表示順序変更の手順
NDSツリーを開きます。
左側のペインのNDSノードに対し、右側のペインで「LDAP Group」オブジェクトを右クリックし、「Properties」→「Class Map」タブを選択します。
2つのグループ・オブジェクトが表示される順序を変更します。
このマッピングを追加する方法の詳細は、Novell eDirectoryのドキュメントを参照してください。
ユーザー・データは、アイデンティティ・システムで管理されるユーザー・ディレクトリのエントリで構成されます。このデータには、アイデンティティ・システムで管理されるユーザー、グループ、場所およびその他の汎用オブジェクトに関する情報が含まれます。
Oracle Access Managerのインストール時は、メイン・ディレクトリ・サーバーのプロファイルを設定するために、次の情報を指定する必要があります。
DNSホスト名、ポート、ユーザー名（バインドDN）、パスワードなどのバインド情報
検索ベース（このデータが格納されるディレクトリ情報ツリー、すなわちDIT内のノードと、すべてのユーザー・データ検索に使用可能な最上位のベースを識別する）
マスター管理者（1名以上）
構成情報を含むOracle Access Managerスキーマ・クラスをロードするために、設定中にディレクトリを自動的に更新することをお薦めします。
次のガイドラインに従ってください。
Oracle Internet Directory: Oracle Internet Directoryを使用するアイデンティティ・サーバーをインストールする場合、完全修飾されたDN（cn=orcladmin,cn=users,dc=us,dc=mycompany,dc=com）ではなく、ルートDNをスーパーユーザーcn=orcladminとして指定する必要があります。
Sun（以前のiPlanet）: バインドDNユーザーをディレクトリ・マネージャ以外にすることをお薦めします。かわりに、別のユーザーをバインドDNとして作成します。ディレクトリ・マネージャ・アカウントは、ディレクトリ・サーバーのサイズとタイムアウトの制限を無視します。このため、大規模な検索によってディレクトリ・サーバーの動作が妨げられる場合があります。
詳細は、「データ記憶域の要件」を参照してください。
構成データ（Oracle Access Managerの構成の詳細）は、ディレクトリに格納されます。このデータには、アイデンティティ・システムおよびアクセス・システムの表示形式と機能を決定するワークフローおよび構成情報が含まれます。構成データは、アイデンティティ・システムで管理されます。
Oracle Access Managerのインストール時は、構成データを格納するディレクトリ・サーバーの詳細を指定する必要があります。構成データとユーザー・データを一緒に格納する場合、この情報は同じになります。次の通告が適用されます。
構成データのバインドDNは、ベース接尾辞以外の任意の場所にすることができます。
構成データのバインドDN（構成DNとも呼ばれる）は、ユーザー・データの検索ベースと類似しており、アイデンティティ・システムおよびアクセス・システムのOracle Access Managerスキーマとすべての構成データが格納されるDIT内のノードを識別するために指定する必要があります。
「データ記憶域の要件」で説明されているように、追加の通告が適用される場合もあります。
|
注意: Oracle Internet Directoryでは、構成DNの値は、ID管理レルムのコンテキスト（cn=OracleContext）から移入されます。また、デフォルトでは、検索ベースは構成DNと同じです。 |
この場合も、構成情報を含むOracle Access Managerスキーマ・クラスをロードするために、設定中にディレクトリを自動的に更新することをお薦めします。
Oracle Internet Directory: Oracle Internet Directoryでは、構成DNの値は、ID管理レルムのコンテキスト（cn=OracleContext）から移入されます。また、デフォルトでは、検索ベースは構成DNと同じです。複数レルム・インストールの場合、アイデンティティ・システムのインストールおよび設定後に非結合検索ベースを設定する方法の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
ポリシー・データは、リソースへのアクセスを決定するポリシー定義およびルールで構成されます。このデータは、ポリシー・マネージャによってディレクトリ・サーバーで管理されます。
Oracle Access Managerのインストール時は、ポリシー・データをインストールするディレクトリ・サーバーの詳細を指定する必要があります。ポリシー・データをユーザー・データとは別に格納する場合、ディレクトリ・サーバーの詳細は、ユーザーまたは構成データに指定する詳細とは異なります。詳細は、「データ記憶域の要件」を参照してください。
ポリシー・マネージャの設定中は、Oracle Access Managerのすべてのポリシー・データが格納されるDIT内の場所と、すべてのポリシー検索に使用可能な最上位のベースを識別するために、ポリシー・ベースも指定する必要があります。ポリシー・マネージャの設定時にデフォルトの"/"をポリシー・ドメインとして受け入れると、Webサーバー全体が保護されます。
Oracle Access Managerでは、UserとGroupを標準のPersonおよびGroupオブジェクト・クラスとしてそれぞれサポートしています。また、Oracle Access Managerでは、UserとGroupをサポートしています。
Personオブジェクト・クラスは、ユーザーのプロファイル情報を定義します。使用する特定のオブジェクト・クラスがない場合、Oracle Access Managerでは一般的なPersonオブジェクト・クラス定義を自動的に構成できます。
User: Active Directory
InetOrgPerson: ADAM、Data Anywhere（Oracle Virtual Directory）、IBM、Oracle Internet DirectoryおよびSunディレクトリ・サーバー
|
注意: Oracle Virtual Directoryを使用するようにOracle Access Managerを構成する場合、Userオブジェクト・クラスにinetOrgPersonが、Groupオブジェクト・クラスにgroupOfUniqueNamesが必要です。 |
Groupオブジェクト・クラスは、グループの属性を定義します。使用する特定のオブジェクト・クラスがない場合、Oracle Access Managerでは一般的なGroupオブジェクト・クラス定義を次のように自動的に構成できます。
Oracle Access Managerでは、様々なオペレーティング・システム、ディレクトリ・サーバー、Webサーバー、コンパイラおよびブラウザをサポートしており、多数のアプリケーション・サーバー、ポータル・サーバー、システム管理製品およびアプリケーション・パッケージとの統合もサポートしています。
リリース・ノート、ホワイト・ペーパーまたはその他の付帯的な最新のサポートと動作保証に関する情報をダウンロードしたり、Oracle Access Managerのリリースに含まれる各CDの詳細を入手したりするには、Oracle Technology Network（OTN）にアクセスしてください。
ソフトウェアをダウンロードするには、オンライン登録が必要です。登録は無料であり、次のサイトで行うことができます。
https://www.oracle.com/technology/membership/
OTNのユーザー名とパスワードがすでにある場合は、OTNのWebサイトの次のドキュメント・セクションに直接アクセスできます。
https://www.oracle.com/technology/documentation/
最新のOracle Access Managerの動作保証は、次のOracle Technology Networkを参照してください。
http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls
ここでは、次の項目について説明します。
Oracle Media Packは物理的なCDまたはDVDとして入手するか、次のように仮想CDおよびMedia Packとしてダウンロードできます。
Oracle Media Pack
物理的なMedia Packは、EPD Plus Media Packオーダー・タイプをご指定のうえ、営業担当者からご購入ください。この場合、物理的なMedia Packは契約締結後に出荷されます。
Oracle Technology Network（OTN）: 各Oracle Access Manager Readmeリンクでは、サイト上の各ダウンロード・リンクの内容や関連ドキュメントの検索方法などに関する情報を参照できます。次のリンクがあります。
Oracle Access Manager Core Components Readme
アイデンティティ・サーバー、WebPass、ポリシー・マネージャ、アクセス・サーバー、SNMP Agent、Software Developer Kitの各コンポーネントの場所は、このREADMEで確認してください。
Oracle Access Manager WebGate Readme
Oracle HTTP Server 11g用を含むWebGateの場所は、このREADMEで確認してください。サード・パーティ製品用のOracle Access Manager Webコンポーネントおよびコネクタについても記載されています。
Oracle Access Manager NLS Readme
様々な言語パック・インストーラの場所は、このREADMEで確認してください。
必要なインストーラは、実行するタスクに応じて異なります。たとえば、次のようになります。
10g（10.1.4.3）インストール: 次の手順の説明に従って10g（10.1.4.3）インストーラを入手します。
既存の6.xまたは7.xデプロイメントからのアップグレード: 次のサイトで説明されているように、OTNから10g（10.1.4.0.1）を入手します。
http://www.oracle.com/technology/software/products/ias/htdocs/101401.html
停止時間ゼロのアップグレード: 10g（10.1.4.0.1）インストーラをOTNから入手します。また、「最新のパッチ・セットの入手」で説明されているように、10g（10.1.4.2.0）パッチ・セットを入手します。
OTNから最新のインストーラを入手する手順
Oracle Technology Network（OTN）に移動し、通常と同様にログインします。
10g（10.1.4.3）インストーラ
http://www.oracle.com/technology/software/products/ias/htdocs/idm_11g.html
OTNの表の「Oracle Access Manager」セクションから、「Readme」をクリックします。
|
注意: Oracle Access Manager WebGateは、コア・コンポーネントとは別に記載されています。表の「Oracle Access Manager - 3rd Party Integration」の下に記載されている、サード・パーティ・アプリケーション用の他のパッケージを探してください。詳細は、「Readme」をクリックして参照してください。 |
READMEの詳細を印刷し、次の操作方法を確認します。
表内の該当するCDリンクの検索。
ダウンロード用のドキュメント・ライブラリの検索。
パッケージのダウンロード: ダウンロードするパッケージのCDリンクを見つけてクリックします。
ドキュメントの入手: READMEの手順に従って関連ドキュメントとリリース・ノートを入手します。一部のコンポーネントでは追加のドキュメントが提供されている場合もあります。
コンポーネントのインストール: 『Oracle Access Managerインストレーション・ガイド』の手順に従って、コンポーネントをインストールおよび設定します。
必要に応じて、最新のパッチ・セットまたはバンドル・パッチを適用します。
最新のパッチ・セットは、My Oracle Support（旧MetaLink）から入手できます。Oracle Access Managerのどのリリース以降をデプロイするかによって、必要なパッチ・セットが決まります。たとえば、次のリリース以降をデプロイする場合:
リリース10g（10.1.4.0.1）: 次の手順の両方を実行します。
リリース10g（10.1.4.2.0）: 手順1をスキップし、10g（10.1.4.3）パッチのみを適用します。
|
関連項目: 10g（10.1.4.0.1）よりも前のリリースをデプロイする場合は、『Oracle Access Managerアップグレード・ガイド』を参照してください。 |
最新のパッチ・セットの入手手順
10g（10.1.4.2.0）パッチのダウンロード:
My Oracle Support（旧MetaLink）に移動し、通常と同様にログインします。
http://metalink.oracle.com
クイック検索リストから、「パッチ番号」を選択し、右側の空のフィールドに「5957301」と入力して、「実行」をクリックします。
「パッチ5957301」ページで、各zipファイル名の横にある「ダウンロード」ボタンをクリックします。
README: リリース・ノートを表示するには、「READMEの表示」ボタンをクリックします。リリース・ノートを印刷し、修正された不具合、機能拡張などの一覧を確認できます。
パッチのインストール: すべての前提条件、パッチ・インストールおよびパッチ適用後の手順は、README（oam_101420_readme.pdf）を参照してください。
10g（10.1.4.3）パッチのダウンロード:
My Oracle Support（旧MetaLink）に移動し、通常と同様にログインします。
http://metalink.oracle.com
クイック検索リストから、「パッチ番号」を選択し、右側の空のフィールドに「8276055」と入力して、「実行」をクリックします。
「パッチ8276055」ページで、各zipファイル名の横にある「ダウンロード」ボタンをクリックします。
README: リリース・ノートを表示するには、「READMEの表示」ボタンをクリックします。リリース・ノートを印刷し、修正された不具合、機能拡張などの一覧を確認できます。
パッチのインストール: すべての前提条件、パッチ・インストールおよびパッチ適用後の手順は、10g（10.1.4.3）のREADME（oam_101430_readme.pdf）を参照してください。
オラクル社では、デプロイメントに含まれる報告された問題を修正するためのバンドル・パッチをリリースしています。最新のバンドル・パッチを入手して適用することをお薦めします。
バンドル・パッチのドキュメントには、パッチの適用または削除の手順、およびそのリリースで修正された不具合のリストが含まれます。バンドル・パッチ製品パッケージと関連ドキュメントは、次のMy Oracle Support（旧MetaLink）Webサイトからのみ入手できます。
https://metalink.oracle.com
|
関連項目: OAM Bundle Patch Release History: My Oracle Supportのナレッジ・ベースの記事#736372.1。このドキュメントでは、バンドル・パッチとその番号付けについて詳細に説明されています。 |
システム構成が、Windowsプラットフォームの.NETに関する要件も含め、すべての要件を満たしていることを確認します。
バンドル・パッチ・ファイルをホストするマシン上で、ダウンロードするプラットフォーム固有のバンドルを格納するための一時ディレクトリを作成します。次に例を示します。
My Oracle Support（旧MetaLink）に移動し、通常と同様にログインします。
https://metalink.oracle.com
My Oracle Support（旧MetaLink）で次の操作を実行します。
「パッチと更新版」タブをクリックします。
「クイックリンク」をクリックして、「最新のパッチセット、ミニ・パック、メンテナンス・パック」に移動します。
「クイックリンク」ページの製品バンドルのパッチセット表で、「Oracle Oblix COREid」をクリックします。
表示された「拡張検索」ページで、「簡易検索」ボタンをクリックします。
「簡易検索」ページで、次の詳細が指定されていることを確認します。
検索基準: 製品またはファミリ、Oracle Oblix COREidファミリ
リリース: Oracle Access Manager 10g（10.1.4.3.0）
パッチ・タイプ: パッチ
プラットフォームまたは言語: 使用するプラットフォーム
「実行」ボタンをクリックして結果の表を表示します。
「結果」表の「パッチ」列で、最新のバンドル・パッチ（リストの先頭）を見つけ、対応する番号をクリックします。
「パッチ」ページ: 「ダウンロード」ボタンをクリックします（または、一般情報を表示するには「READMEの表示」ボタン、バンドル名を確認するには「ダイジェストの表示」ボタンをクリックします）。
zipファイルを格納した一時ディレクトリで、コンポーネント固有のファイルを解凍して抽出します。
|
注意: コンポーネント固有のtarファイルはインストール時に自動的に解凍されます。 |
この手順を繰り返して、10g（10.1.4.3）コア・コンポーネントを含むプラットフォームごとにバンドル・パッチを取得します。
パッケージに付属するバンドル・パッチのドキュメントのインストール手順を実行します。
オラクル社では、新たに動作保証されたプラットフォームのコンポーネントに対応したOracle Access Managerのパッケージを逐次提供しています。一部のコネクタには、前提条件とインストール後の構成タスクを示すドキュメントが付属しています。
新たに動作保証されたエージェント・パッケージをOracle Technology Network（OTN）から入手するには、次の手順を実行します。
最新の動作保証されたエージェント・パッケージの入手の手順
Oracle Technology Networkに移動し、通常と同様にログインします。
http://www.oracle.com/technology/software/products/ias/htdocs/101401.html
表の「Oracle Access Manager - 3rd Party Integration」セクションから、「Readme」をクリックします。
READMEの詳細を印刷し、次の操作方法を確認します。
該当するサード・パーティの仮想CDリンクの検索（OTNの表）。
ダウンロード用のドキュメント・ライブラリの検索。
パッケージのダウンロード: ダウンロードするパッケージのCDリンクを見つけてクリックします。
ドキュメントの入手: READMEの手順に従って関連ドキュメントとリリース・ノートを入手します。
コンポーネントのインストール: 『Oracle Access Managerインストレーション・ガイド』とREADMEの手順に従って、コンポーネントをインストールおよび設定します。
Oracle Access Managerのインストール・メディアには、言語パックなど、Oracle Access Managerコンポーネントのインストールに必要なすべての製品パッケージが用意されています。これらのパッケージは、Oracle Access Managerコンポーネントをインストールするディレクトリとは別の一時ディレクトリにコピーすることをお薦めします。
Oracle Access Managerのコンポーネントを1つ以上の言語パックとともにインストールする場合は、必要な言語パッケージをコンポーネント・インストーラと同じ一時ディレクトリにコピーする必要があります。別のディレクトリにコピーすると、コンポーネント・インストーラは言語パックを検出できず、インストール時に言語パックを提供できません。言語パックをインストールしない場合は、目的のOracle Access Managerコンポーネントをインストール・メディアから直接インストールできます。
Oracle Access Managerコンポーネント・インストーラ（アイデンティティ・システムおよびアクセス・システムに必要なすべての言語パック・インストーラを含む）を格納する一時ディレクトリを作成します。
インストール・メディアから、コンポーネントと言語パックを同時にインストールできる一時ディレクトリに、Oracle Access Managerパッケージをコピーします。
コンポーネントのインストール中: このマニュアルの該当する章で説明されているように、インストーラを一時ディレクトリから実行します。
Oracle Access Managerコンポーネントのインストール時には、特定の操作を行った後に情報が保存されます。情報が保存されるまでは、前に戻って、詳細を指定しなおすことができます。ただし、コンポーネントがインストール中であると通知された後は、ファイル・システムにOracle Access Managerファイルが追加されています。
Oracle Access Managerに加えられた変更の一部は、自動的には処理されず、アンインストーラ・プログラムの終了時に手動で削除する必要があります。Oracle Access Managerコンポーネントを削除する方法の詳細は、第22章「Oracle Access Managerの削除」を参照してください。
状況によっては、既存のアイデンティティ・サーバー名を再利用する場合があります。システム・コンソールで元のアイデンティティ・サーバー名を削除しないと、新しいインスタンスの設定の後でログインしたときに、「アプリケーションが設定されていません」というメッセージが表示されることがあります。アイデンティティ・サーバー名をリサイクルするときは、アプリケーションを設定してログインするために特別な手順を実行する必要があります。詳細は、「アイデンティティ・サーバー・インスタンス名のリサイクル」を参照してください。
Oracle Access Managerをインストールするには、多少の計画が必要です。このためチェックリストが用意されています。たとえば、表2-3のチェックリストは次のように使用できます。
実際の環境を計画し、記録できるスペースがあります。
Oracle Access Managerのインストールおよび設定中に表示されるプロンプトに応答するための準備に役立ちます。
「インストール・タスクの概要」に記載のコンポーネントの推奨されるインストール順序と、各コンポーネントのインストール・プロセスに従って編成されています。
このマニュアル内の特定のページ番号への参照があり、追加情報を検索できます。
| タスク | サブタスク | チェックリスト: Oracle Access Managerのインストールおよび設定の準備 | 参照 |
|---|---|---|---|
|
1〜3 |
アイデンティティ・システムのインストールおよび設定の準備 |
||
|
1 |
アイデンティティ・サーバーのインストールの準備 |
||
|
1.1 |
デフォルト・ロケール（管理者の言語） |
||
|
言語 言語パック |
|||
|
1.2 |
アイデンティティ・サーバーとWebPass間のトランスポート・セキュリティ・モード:
|
||
|
1.3 |
このアイデンティティ・サーバー・インスタンスを識別するためにOracle Access Manager内で使用される一意のアイデンティティ・サーバーID: |
||
|
アイデンティティ・サーバーがインストールされるコンピュータのホスト名: |
|||
|
アイデンティティ・サーバー/WebPass通信用のポート番号: |
|||
|
これがこのディレクトリ・サーバーにインストールされる最初のアイデンティティ・サーバーかどうか
|
|||
|
1.4 |
ディレクトリ・サーバーとアイデンティティ・サーバー間のセキュリティ・モード:
|
||
|
SSLの場合、ルートCA証明書へのパス: |
|||
|
シンプル・モードのみ |
|||
|
証明書モードのみ |
|||
|
証明書リクエスト・ファイルのパス（証明書リクエストのみ）: |
|||
|
証明書ファイルのパス（証明書モードのみ）: |
|||
|
キー・ファイルのパス（証明書モードのみ）: |
|||
|
連鎖ファイルのパス（証明書モードのみ）: |
|||
|
1.5 |
ディレクトリ・サーバー詳細の準備
|
||
|
ディレクトリ・サーバー・タイプ:
注意: Data Anywhere（Oracle Virtual Directory Server）は、ユーザー・データのディレクトリ・サーバーでのみ使用できます。構成およびポリシー・データは、ネイティブ・ディレクトリに格納する必要があります。 |
Data Anywhereとともに使用するOracle Access Managerをインストールする前に、第10章「Oracle Virtual Directoryを使用したOracle Access Managerの設定」を参照してください。 |
||
|
ディレクトリ・サーバーのホスト・コンピュータの名前またはIPアドレス: |
|||
|
ディレクトリ・サーバーのポート番号: |
|||
|
ディレクトリ・サーバーのバインドDN: |
|||
|
ディレクトリ・サーバーの管理パスワード: |
|||
|
1.6 |
（Windowsのみ）アイデンティティ・サーバーの複数インスタンスをインストールする場合は、このインスタンスを「サービス」ウィンドウで識別する一意のアイデンティティ・サーバー・サービス名: |
||
|
2 |
WebPassをインストールする準備。次を決定する: |
||
|
2.1 |
デフォルト・ロケール（管理者の言語） |
||
|
言語 言語パック アイデンティティ・サーバーと同じ言語パック |
|||
|
Webサーバーのユーザー名（UNIXのみ）: |
|||
|
Webサーバーのグループ（UNIXのみ）: |
|||
|
WebPassのインストール・ディレクトリ。アイデンティティ・サーバーと同じコンピュータにインストールする場合は、アイデンティティ・サーバーのインストール・ディレクトリと同じにすることはできません。 |
|||
|
2.2 |
アイデンティティ・サーバーとWebPass間のトランスポート・セキュリティ・モード: |
この表のタスク1を参照 |
|
|
WebPassインスタンスの識別にOracle Access Managerで使用されるWebPass ID: |
|||
|
2.3 |
WebPassのホスト名: |
||
|
アイデンティティ・サーバー/WebPass通信用のポート番号: |
この表のタスク1を参照 |
||
|
シンプル・モードのみ |
この表のタスク1を参照 |
||
|
証明書モードのみ |
|||
|
証明書リクエスト・ファイルのパス（証明書リクエストのみ）: |
|||
|
証明書ファイルのパス（証明書モードのみ）: |
|||
|
キー・ファイルのパス（証明書モードのみ）: |
|||
|
連鎖ファイルのパス（証明書モードのみ）: |
|||
|
2.4 |
WebサーバーをWebPassの情報に基づいて自動的に更新するかどうか
|
||
|
更新する場合、obj.confファイル（Apacheの場合はhttpd.confファイル）を含んでいるWebサーバーの構成ディレクトリの絶対パス: |
|||
|
3 |
アイデンティティ・システムの設定の準備 次を決定する: |
||
|
3.1 |
ディレクトリ・サーバー・タイプ: |
この表のタスク1を参照 |
|
|
ディレクトリ・サーバーのホスト・コンピュータの名前またはIPアドレス: |
この表のタスク1を参照 |
||
|
ディレクトリ・サーバーのポート番号: |
この表のタスク1を参照 |
||
|
ディレクトリ・サーバーのバインドDN: |
この表のタスク1を参照 |
||
|
ディレクトリ・サーバーの管理パスワード: |
この表のタスク1を参照 |
||
|
ディレクトリ・サーバーとアイデンティティ・サーバー間のセキュリティ・モード: |
この表のタスク1を参照 |
||
|
構成データがユーザー・データのディレクトリ・サーバーに格納されるかどうか |
この表のタスク1を参照 |
||
|
構成DN: |
|||
|
ユーザー・データを格納するディレクトリ検索ベース: |
|||
|
3.2 |
Personオブジェクト・クラス: |
||
|
Personオブジェクト・クラスを自動構成するかどうか
|
|||
|
Groupオブジェクト・クラス: |
|||
|
Groupオブジェクト・クラスを自動構成するかどうか
|
|||
|
Personオブジェクト・クラスの構成（手動プロセスはオプション）。Personオブジェクト・クラスを自動構成しないと選択した場合は、次の属性を構成する: |
|||
|
ユーザーのフルネーム属性: |
|||
|
ユーザーのログインID属性: |
|||
|
パスワード属性: |
|||
|
3.3 |
Groupオブジェクト・クラスの構成（手動プロセスはオプション）。Groupオブジェクト・クラスを自動構成しないと選択した場合は、次の属性を構成する: |
||
|
グループ名属性: |
|||
|
3.4 |
マスター管理者を定義する準備 |
||
|
マスター管理者（1名または複数）: |
|||
|
4〜8 |
アクセス・システムのインストールおよび設定の準備 |
||
|
4 |
ポリシー・マネージャをインストールする準備。次を決定する: |
||
|
4.1 |
第5章「WebPassのインストール」で説明されているように、このポリシー・マネージャのWebPassをインストールして、次を実行する。
|
||
|
4.2 |
デフォルト・ロケール（管理者の言語） |
||
|
言語 言語パック アイデンティティ・システムと同じ言語パック |
この表のタスク1を参照 |
||
|
Webサーバーのユーザー名（UNIXのみ）: |
この表のタスク2を参照 |
||
|
Webサーバーのグループ（UNIXのみ）: |
この表のタスク2を参照 |
||
|
WebPassのインストール・ディレクトリ: |
この表のタスク2を参照 |
||
|
4.3 |
ディレクトリ・サーバー・タイプ:
注意: Data Anywhere（Oracle Virtual Directory Server）は、ユーザー・データのディレクトリ・サーバーでのみ使用でき、ポリシー・マネージャとアクセス・サーバーでは使用できません。 |
構成およびポリシー・データは、第10章「Oracle Virtual Directoryを使用したOracle Access Managerの設定」で説明されているように、ネイティブ・ディレクトリへの格納が必要。 |
|
|
ポリシー・データをユーザー・データのディレクトリ・サーバーとは別に格納するかどうか
|
|||
|
4.4 |
ポリシー・マネージャとアクセス・サーバー間のトランスポート・セキュリティ・モード:
|
||
|
シンプル・モードのみ |
|||
|
証明書モードのみ |
|||
|
証明書リクエスト・ファイルのパス（証明書モードのみ）: |
|||
|
証明書ファイルのパス（証明書モードのみ）: |
|||
|
キー・ファイルのパス（証明書モードのみ）: |
|||
|
連鎖ファイルのパス（証明書モードのみ）: |
|||
|
4.5 |
Webサーバーの構成ファイルをアクセス・システムの情報に基づいて自動的に更新するかどうか - ○ - × |
||
|
更新する場合、obj.confファイル（Apacheの場合はhttpd.confファイル）を含んでいるWebサーバーの構成ディレクトリの絶対パス: |
タスク2を参照 |
||
|
5 |
ポリシー・マネージャを設定する準備。 このポリシー・マネージャのインストールに基づいて次を記入: |
||
|
5.1 |
ディレクトリ・サーバー・タイプ: |
タスク4を参照 |
|
|
ディレクトリ・サーバーのホスト・コンピュータの名前またはIPアドレス: |
タスク4を参照 |
||
|
ディレクトリ・サーバーのポート番号: |
タスク4を参照 |
||
|
ディレクトリ・サーバーのバインドDN: |
タスク4を参照 |
||
|
ディレクトリ・サーバーの管理パスワード: |
タスク4を参照 |
||
|
ディレクトリ・サーバーとポリシー・マネージャ間のセキュリティ・モード: - オープン - SSL |
|||
|
SSLの場合、SSL証明書へのパス: |
|||
|
ディレクトリ・サーバー内の構成データの場所: - ユーザー・データ・ディレクトリ・サーバー - 個別のディレクトリ・サーバー |
|||
|
個別のディレクトリ・サーバー上の場合、ディレクトリ・サーバーのホスト・コンピュータの名前またはIPアドレス: |
|||
|
個別のディレクトリ・サーバー上の場合、ディレクトリ・サーバーのポート番号: |
|||
|
個別のディレクトリ・サーバー上の場合、ディレクトリ・サーバーのバインドDN: |
|||
|
個別のディレクトリ・サーバー上の場合、ディレクトリ・サーバーの管理パスワード: |
|||
|
個別のディレクトリ・サーバー上の場合、ディレクトリ・サーバーとポリシー・マネージャ間のセキュリティ・モード: - オープン - SSL |
|||
|
SSLの場合、SSL証明書へのパス: |
|||
|
ディレクトリ・サーバー内のポリシー・データの場所: - ユーザー・データ・ディレクトリ・サーバー |
|||
|
個別のディレクトリ・サーバー上の場合、ディレクトリ・サーバーのホスト・コンピュータ: |
|||
|
個別のディレクトリ・サーバー上の場合、ディレクトリ・サーバーのポート番号: |
|||
|
個別のディレクトリ・サーバー上の場合、ディレクトリ・サーバーのバインドDN: |
|||
|
個別のディレクトリ・サーバー上の場合、ディレクトリ・サーバーの管理パスワード: |
|||
|
個別のディレクトリ・サーバー上の場合、ディレクトリ・サーバーとポリシー・マネージャ間のセキュリティ・モード: - オープン - SSL |
|||
|
SSLの場合、SSL証明書へのパス: |
|||
|
ユーザー・データを格納するディレクトリ検索ベース: |
タスク3を参照 |
||
|
構成DN: |
タスク3を参照 |
||
|
ポリシー・ベース: |
|||
|
Personオブジェクト・クラス名: |
タスク3を参照 |
||
|
ポリシー・マネージャのポリシー・ドメイン・ルート: |
|||
|
5.2 |
認証スキームを構成するかどうか - ○ - × |
||
|
構成する場合、1つ以上の認証スキームを選択: Oracle Access Manager関連の認証スキームおよびポリシー・ドメインの構成 認証スキーム - Basic Over LDAP - クライアント証明書 - 匿名 - Oracle Access and Identity Basic Over LDAP - AD Forest用のOracle Access and Identity Basic Over LDAP ポリシー・ドメイン - Identityドメイン - Accessドメイン |
|||
|
Oracle Access Manager関連のURLを保護するポリシーを構成するかどうか - ○ - × |
|||
|
6 |
アクセス・システム・コンソールでアクセス・サーバー・インスタンスを作成する準備 続行する前に次を決定する: |
||
|
6.1 |
アクセス・サーバー名（スペースは使用不可）: |
||
|
アクセス・サーバーのホスト名: |
|||
|
アクセス・サーバーがリスニングするポート番号: |
|||
|
アクセス・サーバーとWebGate間のトランスポート・セキュリティ・モード: - オープン - シンプル - 証明書 |
|||
|
6.2 |
アクセス・システム・コンソールでのアクセス・サーバー・インスタンスの作成 |
||
|
7 |
アクセス・サーバーをインストールする準備 |
||
|
7.1 |
デフォルト・ロケール（管理者の言語） |
||
|
言語 言語パック ポリシー・マネージャと同じ言語パック |
|||
|
Webサーバーのユーザー名（UNIXのみ）: |
|||
|
Webサーバーのグループ（UNIXのみ）: |
|||
|
アクセス・サーバーのインストール・ディレクトリ: |
|||
|
7.2 |
アクセス・サーバーとWebGate/AccessGate間のトランスポート・セキュリティ・モード: |
タスク6を参照 |
|
|
7.3 |
構成データ・ディレクトリ・サーバーとアクセス・サーバー間のセキュリティ・モード: - オープン - SSL |
||
|
構成データ・ディレクトリ・サーバーのホスト・コンピュータ: ポリシー・マネージャのDSと同じかどうか --○ --× |
|||
|
構成データ・ディレクトリ・サーバーのポート番号: ポリシー・マネージャのDSと同じかどうか --○ --× |
|||
|
構成データ・ディレクトリ・サーバーのバインドDN: ポリシー・マネージャのDSと同じかどうか --○ --× |
|||
|
構成データ・ディレクトリ・サーバーの管理パスワード: ポリシー・マネージャのDSと同じかどうか --○ --× |
|||
|
構成データ・ディレクトリ・サーバーのタイプ: - Sun Directory Server 5.x - NDS - Active Directory - Active Directoryアプリケーション・モード - IBM Directory Server 注意: アクセス・サーバーのインストールがWindowsプラットフォーム上で行われるたびに、ADSIを使用するActive Directoryについて指定を求められます。 |
|||
|
どのディレクトリ・サーバーで構成データを格納するか |
タスク1を参照 |
||
|
どのディレクトリ・サーバーでポリシー・データを格納するか |
タスク1を参照 |
||
|
アクセス・サーバー名: |
タスク6を参照 |
||
|
構成DN: |
タスク3を参照 |
||
|
ポリシー・ベース: |
タスク4を参照 |
||
|
シンプル・モードのみ |
タスク4を参照 |
||
|
証明書モードのみ |
|||
|
PEMフレーズをパスワード・ファイルに保存するかどうか（シンプルおよび証明書モードのみ）: - ○ - × |
|||
|
証明書リクエスト・ファイルのパス（証明書モードのみ）: |
|||
|
証明書ファイルのパス（証明書モードのみ）: |
|||
|
キー・ファイルのパス（証明書モードのみ）: |
|||
|
連鎖ファイルのパス（証明書モードのみ）: |
|||
|
8 |
アクセス・システム・コンソールでWebGateインスタンスを作成する準備。続行する前に次を決定する: |
||
|
8.1 |
WebGate名（スペースは使用不可）: |
||
|
WebGateのホスト名: |
|||
|
Webサーバーのポート番号: |
|||
|
WebGateのパスワード/パスワードの確認: |
|||
|
アクセス・サーバーとWebGate間のトランスポート・セキュリティ・モード: |
タスク6を参照 |
||
|
8.2 |
アクセス・システム・コンソールでのWebGateインスタンスの定義 |
||
|
8.3 |
WebGateとアクセス・サーバーの関連付け |
||
|
9 |
WebGateをインストールする準備。続行する前に次を決定する: |
||
|
9.1 |
デフォルト・ロケール（管理者の言語） |
||
|
言語 言語パック ポリシー・マネージャおよびアクセス・サーバーと同じ言語パック |
|||
|
Webサーバーのユーザー名（UNIXのみ）: |
|||
|
Webサーバーのグループ（UNIXのみ）: |
|||
|
WebGateのインストール・パス（WebPassと同じインストール・パスを使用可能）: |
|||
|
9.2 |
アクセス・サーバーとWebGate間のトランスポート・セキュリティ・モード: |
タスク6を参照 |
|
|
9.3 |
WebGateのID: |
タスク8を参照 |
|
|
WebGateのパスワード: |
タスク8を参照 |
||
|
アクセス・サーバーID: |
タスク6を参照 |
||
|
アクセス・サーバーのホスト名: |
タスク6を参照 |
||
|
アクセス・サーバーのポート番号: |
タスク6を参照 |
||
|
シンプル・モードのみ グローバル・アクセス・プロトコル・パスフレーズ: |
タスク6を参照 |
||
|
証明書モードのみ 証明書PEMフレーズ: |
|||
|
証明書リクエスト・ファイルのパス（証明書モードのみ）: |
|||
|
証明書ファイルのパス（証明書モードのみ）: |
|||
|
キー・ファイルのパス（証明書モードのみ）: |
|||
|
連鎖ファイルのパス（証明書モードのみ）: |
|||
|
9.5 |
Webサーバーの構成ファイルを自動的に更新するかどうか - ○ - × |
||
|
更新する場合、obj.confファイル（Apacheの場合はhttpd.confファイル）を含んでいるWebサーバーの構成ディレクトリの絶対パス: |
|||
|
10〜14 |
使用するオプション・コンポーネント |
||
|
10 |
Oracle Virtual Directory Server（Data Anywhereコンポーネント） - ○ - × |
第10章「Oracle Virtual Directoryを使用したOracle Access Managerの設定」を参照 |
|
|
11 |
SNMPエージェント（オプション） - ○ - × |
||
|
12 |
データベースの監査コンポーネント - ○ - × |
||
|
13 |
言語パック、個別インストール（オプション） - ○ - × |
||
|
14 |
ソフトウェア開発キット（SDK）はオプションかどうか - ○ - × |
『Oracle Access Manager開発者ガイド』を参照 |
