| Oracle Application Serverリリース・ノート 10g（10.1.4.0.1） for HP-UX Itanium B31748-05 |
|
 戻る |
 次へ |
この章では、Oracle Access Managerの既知の問題およびその回避方法について説明します。内容は次のとおりです。
オラクル社では、定期的にソフトウェアの更新を提供しています。Oracle MetaLink Webサイトにアクセスして、最新のソフトウェアの更新を確認することをお薦めします。この項の内容は次のとおりです。
バンドル・パッチは正式なOracleパッチで、各プラットフォームのすべてのコア・コンポーネントのセット（Identity Server、WebPass、Access Manager、Access Server、WebGate）の他、1つ以上の修正を実装して再構築されたライブラリおよびファイルを提供します。各バンドル・パッチは、累積パッチです。最新のバンドル・パッチには、同じ製品リリース用の以前のバンドル・パッチのすべての修正が含まれます。バンドル・パッチのすべての修正はテスト済であり、互いに機能することが動作保証されています。リグレッション・テストも実施され、以前のWebGateとの下位互換性も確保されています。
バンドル・パッチ方式では、ある製品またはパッチ・セットのリリース後、次回のリリース前の製品の特定の修正を提供します。Oracle Access Manager 10g（10.1.4.0.1）のバンドル・パッチは、10g（10.1.4.0.1）の後にリリースされ、後のパッチ・セットに組み込まれます。
|
注意: 最初の10g（10.1.4.0.1）のバンドル・パッチは、2007年12月に提供が開始されました。2007年12月以前は、パッチ・セットの例外（PSEホット・フィックス）がリリースされました。 |
バンドル・パッチとは対照的に、各パッチ・セットの例外は（個別またはホット・フィックスとも呼ばれる）、通常は1つのプラットフォームの（ただし、必ずしも1つのプラットフォームとはかぎらない）1つのコンポーネントの1つの問題のみに対処します。
最新のバンドル・パッチの入手手順
Oracle MetaLinkにアクセスし、通常どおりログインします。
https://metalink.oracle.com
Oracle MetaLinkで「Quick Find」リストから「Patch Number」を選択し、次のようにしてプラットフォーム固有のバンドルを見つけます。
「Patches & Updates」タブをクリックします。
「Quick Links to the Latest Patchsets, Mini Packs, and Maintenance Packs」をクリックします。
「Quick Links」ページで、「Patch Sets for Product Bundles」表の「Oracle Oblix COREid」をクリックします。
表示される「Advanced Search」ページで、「Simple Search」ボタンをクリックします。
「Simple Search」ページで、次の詳細が指定されていることを確認します。
Search by: Oracle Oblix COREid Family製品またはファミリ
Release: Oracle Access Manager 10g（10.1.4.0.1）
Patch Type: Patch
Platform or Language: Your_Platform
「Go」ボタンをクリックして結果表を表示します。
「Results」表の「Patch」列で、最新のバンドル・パッチの番号をクリックします。たとえば、10.1.4.0.1の場合は6623277です。
「Patch Page」で、「Download」ボタン（一般情報を表示するには「View Readme」ボタン、バンドル名を表示するには「View Digest」ボタン）をクリックします。
パッケージに付属の「Bundle Patch Notes」のインストール手順を参照し、これに従います。
パッチ・セットは、それより前のバンドル・パッチで使用可能な、十分にテストされた製品の修正を統合したものを提供するメカニズムです。また、パッチ・セットに新機能が含まれることもあります。Oracle Access Managerリリース10.1.4パッチ・セット1（10.1.4.2.0）は、パッチ・セットです。
各パッチ・セットには、不具合の修正（および存在する場合は新機能）を実装して再構築されたライブラリおよびファイルが含まれます。ただし、パッチ・セットは完全なソフトウェア配布ではない場合もあり、すべてのプラットフォームのすべてのコンポーネント用のパッケージが含まれていないことがあります。パッチ・セットのすべての修正はテスト済であり、指定されたプラットフォームで互いに機能することが動作保証されています。
最新のパッチ・セットの入手手順
Oracle MetaLinkにアクセスし、通常どおりログインします。
https://metalink.oracle.com
Oracle MetaLinkで次の手順を実行します。
「Patches & Updates」タブをクリックします。
「Quick Links to the Latest Patchsets, Mini Packs, and Maintenance Packs」をクリックします。
「Quick Links」ページで、「Patch Sets for Product Bundles」表の「Oracle Oblix COREid」をクリックします。
表示される「Advanced Search」ページで、「Simple Search」ボタンをクリックします。
「Simple Search」ページで、次の詳細が指定されていることを確認します。
Search by: Oracle Oblix COREid Family製品またはファミリ
Release: Oracle Access Manager 10g（10.1.4.0.1）
Patch Type: Patch
Platform or Language: Your_Platform
「Go」ボタンをクリックして結果表を表示します。
「Results」表の「Patch」列で、最新のバンドル・パッチの番号をクリックします。たとえば、5957301です。
「Patch Page」で、「Download」ボタン（一般情報を表示するには「View Readme」ボタン、バンドル名を表示するには「View Digest」ボタン）をクリックします。
新機能やパッチ・セットを適用するための前提条件と手順の詳細は、パッケージに付属のリリース・ノートを参照してください。
この項では、一般的な問題および回避方法について説明します。内容は次のとおりです。
最新のプラットフォーム・サポート・マトリックスへのアクセス方法は次のとおりです。
ブラウザで、次のURLを入力します。
MetaLinkにログインします。
「Certify」タブをクリックします。
「View Certifications by Product」をクリックします。
「Application Server」オプションを選択し、「Submit」をクリックします。
「Oracle Identity Manager」を選択し、「Submit」をクリックします。
「Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html)」をクリックすると、「Oracle Identity Management」ページが表示されます。
「Section 6, Oracle Access Manager Certification」のリンクをクリックすると、動作保証のマトリックスが表示されます。
次のリリースのドキュメントには、プラットフォーム・サポートのマトリックスへのアクセスに関する更新情報が掲載される予定です。
JDK 1.1.7のJavaアプレットに既知の問題があります。ASCII以外のデータを持つアプレットは、このリリースのOracle Access Managerで使用した場合、オペレーティング・システムがネイティブ・エンコードされたコンピュータでのみ適切に表示されます。ブラウザのエンコード設定は機能しません。
ASCII以外のデータを使用する場合、オペレーティング・システムがネイティブ・エンコードされたコンピュータでOracle Access Managerを実行してください。
このリリースでは、他言語のロケールで「クエリー・ビルダー（Query Builder）」という名前が翻訳されている箇所と翻訳されていない箇所があります。「セレクタ（Selector）」という用語は、各ロケールのすべての箇所で翻訳されています。
ユーザーが、パスワードをリセットした後に再認証なしでリソースにアクセスできるように設定できます。この情報はマニュアルに記載されていませんでした。
パスワードの変更後にユーザーをログインさせるには、パスワード変更のリダイレクトURLにパラメータとしてSTLogin=%applySTLogin%が含まれる必要があります。
ユーザーがログインできる、パスワード変更のリダイレクトURLの例を次に示します。
/http://machinename:portnumber/identity/oblix/apps/lost_password_mgmt/bin/lost_password_mgmt.cgi?program=redirectforchangepwd&login=%login%%userid%&backURL=% HostTarget%%RESOURCE%&STLogin=%applySTLogin%&target=top
パスワード変更後の自動ログインをフォームベースの認証スキームを使用して実装するには、credsチャレンジ・パラメータを構成して、最初のトークンにユーザー名の資格証明パラメータ、2番目のトークンにパスワードの資格証明パラメータ、続いてその他の資格証明パラメータを指定する必要があります。
時間の管理には、夏時間の変更が含まれます。アメリカ合衆国で、2005年エネルギ政策法が法制化されて夏時間が延長されました。2007年暦年に、夏時間の施行期間が変更されます。新しい規制のもとで、米国のDST（夏時間）の開始日は3月第2日曜日、終了日は11月第1日曜日になります。従来、夏時間の開始日は4月第1日曜日、終了日は10月最終日曜日でした。この変更はカナダにも影響を与えます。
Oracle Access Managerの2007年米国夏時間（DST）への対応: 夏時間の変更に対応するためにIdentity ServerまたはAccess Serverにパッチを適用する必要はありません。ただし、Oracle Access Managerは、DSTの変更による影響を受ける可能性があるWebサーバー、アプリケーション・サーバー、LDAPディレクトリおよびデータベースなどの他のコンポーネントと対話します。各ベンダーのドキュメントを参照し、影響を受ける他のコンポーネントに必要なパッチが適用されていることを確認してください。
夏時間の調整が必要な場合はオペレーティング・システムのベンダーの推奨事項に従ってください。また、『Oracle Access Managerインストレーション・ガイド』に記載されているように、Oracle Access Managerコンポーネントのホスト・コンピュータのシステム・クロックを同期してください。
OracleデータベースおよびOracle Fusion Middleware製品の2007年米国DSTへの対応の詳細は、OracleMetalink Webサイト（https://metalink.oracle.com）のNote: 397281.1を参照してください。
『Oracle Access Manager IDおよび共通管理ガイド』の「グローバル設定の構成」の「特定ドメイン用のパスワード・ポリシーの作成」に注意が追加されました。次の新しい注意は、「パスワード・ポリシーを作成する手順」の手順16を参照してください。
16. 管理者によるパスワードのリセット後、ユーザーが最初にシステムにログインしたときにパスワードの変更を強制する場合は、「リセット時に変更」を選択します。デフォルトでは、「リセット時に変更」フラグは設定されません。自己登録時にも「リセット時に変更」フラグは設定されません。このフィールドは、アイデンティティ・システムとアクセス・システムの両方に適用されます。アクセス・システム専用の場合、パスワード変更のためのリダイレクトURLも構成できます。詳細は、「パスワードのリダイレクトURLの構成」を参照してください。
|
注意: 「リセット時に変更」機能が有効でパスワード変更のリダイレクトURLを指定せずに、アクセス・システムでパスワード・ポリシーを使用すると、ログイン・プロンプトが再表示されます。これによって、ユーザーがパスワードを変更して最終的にログインすることを防ぎます。 |
以前のリリースからOracle Access Manager 10g（10.1.4.0.1）に正常にアップグレードするには、『Oracle Access Managerアップグレード・ガイド』に記載されたすべての準備タスクを完了し、要件をすべて満たす必要があります。このガイドには、6.1.1以下のリリースから10g（10.1.4.0.1）にアップグレードする場合に実行する手順も記載されています。
この項では、インストールとアップグレードに関する次の問題および回避方法について説明します。
5.3.10項「Identity ServerまたはPolicy Managerのインストール時のディレクトリの自動更新での問題」
5.3.13項「Sun Java Directory Server 6.0を使用したIdentity Server 10.1.4.0.1のインストール」
トランスポート・セキュリティ・モードは、クライアントとサーバーなど、2点間の通信方法です。『Oracle Access Managerインストレーション・ガイド』に記載されているように、Oracle Access Managerではコンポーネント間の通信用に次のトランスポート・セキュリティ・モードが提供されています。
オープン: 通信は暗号化されません。
簡易: Oracle Access Managerの内部CAで通信が暗号化されます。
証明書: 外部CAで通信が暗号化されます。「証明書」モードでは、TLSバージョン1を使用して通信が暗号化されます。また、クライアントとサーバーは両方とも接続の確立時にX.509証明書を（BASE64形式で）提示する必要があります。
Oracle Access Managerインストール環境は、デフォルトで「オープン」モードを使用します。これは、WebPassとIdentity Server間などのOracle Access Managerコンポーネント間のディレクトリ接続および通信に適用されます。「オープン」モードでは、傍受者に対して通信チャネルが開かれています。ディレクトリにSSL接続を使用し、Oracle Access Managerコンポーネント間で「証明書」モードを使用することで、ネットワークを保護することをお薦めします。
次のリリースの『Oracle Access Managerインストレーション・ガイド』には、トランスポート・セキュリティの推奨事項が次のように記載される予定です。
「インストール中に、Oracle Access Managerコンポーネントのデフォルトは「オープン」モードに設定されます。しかしこれでは、Identity ServerとWebPass間やAccess ServerとWebGate間などのコンポーネント間の通信およびLDAP接続の通信が保護されません。「オープン」モードでは、通信チャネルが傍受者の影響を受けやすくなります。デプロイを保護するために、Oracle Access Managerコンポーネント間のトランスポート・セキュリティに「証明書」モードを選択し、Oracle Access Managerコンポーネントとディレクトリ・サーバー間にSSL対応のセキュリティを選択することをお薦めします。」
iPlanet管理コンソールからOracle Access Managerをチューニングすると、サーバーが機能しなくなります。たとえば、ネイティブ・スレッド・プールのスレッド数を変更した後、サーバーを再起動できません。
チューニングにiPlanetコンソールを使用しないでください。これを行うと、サーバーから既存のOracle Access Manager構成情報が削除されます。$Web_Server_home\config\magnus.confファイルを使用してOracle Access ManagerのWebコンポーネントをロードし、チューニング・パラメータを保存します。
Oracle Internet Directoryに対してOracle Access Managerをインストールした後、検索リクエストやその他のファンクションを処理する際の十分なパフォーマンスを確保するためにディレクトリをチューニングする必要があります。
Oracle Internet Directoryをチューニングするには、次のldapmodifyコマンドを使用します。
ldapmodify -D cn=orcladmin -w <adminPsswd> -h <host> -p <port> << eof dn: cn=dsaconfig, cn=configsets, cn=oracle internet directory changetype: modify add: orclinmemfiltprocess orclinmemfiltprocess: (|(obuseraccountcontrol=activated)(!(obuseraccountcontrol=*))) orclinmemfiltprocess: (|(!(obuseraccountcontrol=*))(obuseraccountcontrol=activated)) eof
サンプル・コマンドの<host>および<port>には、Oracle Internet Directoryインストール環境のホストおよびポートを指定します。
|
注意: 属性orclinmemfiltprocess:の後および属性値の各継続行の先頭に、空白を1つ挿入してください。属性orclinmemfiltprocess:と継続行の間に改行はありません。インストールする追加のOracle Internet Directoryサーバーごとに手順1を繰り返します。 |
詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
Siemens DirXディレクトリ・サーバーは、このリリースからは非推奨です。しかし、インストール画面やシステム・コンソールの「IDシステム構成」ページおよび「アクセス・システム構成」ページにDirXの選択および構成オプションが表示されます。
製品インストーラおよび構成ユーザー・インタフェースにあるSiemens DirXオプションはすべて無視してください。
数個の言語パックを使用してコンソール・モードでインストーラを実行すると、LDAPパスワードの入力を求める画面が文字化けします。
ほとんどの場合に通用する解決策は、Oracle Access Managerのインストールを実行するコンピュータに、使用可能な言語サポートをすべてインストールすることです。その言語に必要なフォントをすべてインストールしてください。マシンにローカルでログインし、ログイン画面で表示言語を選択します。
識別数字2が付く言語パックを削除（アンインストール）できないことがあります。たとえば、_uninstAccessLP_ko-krを使用した後_uninstAccessLP_ko-kr2を使用して（または逆の順序で使用して）アンインストールできないことがあります。
この問題の回避方法は次のとおりです。
次の手順を実行します。次の例では言語として韓国語（ko-kr）を使用していますが、環境に応じて変更してください。
_jvmAccessLP_ko-krをバックアップ・フォルダにコピーします。
_uninstAccessLp_ko-kr2のuninstaller.exeを実行します。
_jvmAccessLP_ko-krと_uninstAccessLP_ko-kr2の両方が自動的に削除されます。
_jvmAccessLP_ko-krを元のComponent_install_dir/WebComponent/access/ディレクトリにコピーします。
_uninstAccessLP_ko-krのuninstaller.exeを実行します。
_jvmAccessLP_ko-krと_uninstAccessLP_ko-krが自動的に削除されます。
Identity Server、Access ServerおよびWebコンポーネントのWebサーバーを再起動します。
アップグレード前のAccess Serverが「簡易」モードであった場合は、10g（10.1.4.0.1）へのアップグレード中にpassword.lstファイルがpassword.xmlに変換されません。そのため、コマンドライン・パラメータを使用して、起動時にパスフレーズが渡されるようにしないかぎり、「サービス」ウィンドウでAccess Serverが起動されるようにすることはできません。また、「簡易」モードのWebGateをアップグレードした後にWebサーバーを起動すると、次のエラーが表示される場合があります。
"Exception thrown during WebGate initialization"
Error^Oracle AccessGate API is not initialized.
最初の「アクセス・システム(Access System)」ページは表示されます。しかし、いずれのリンクをクリックしても、前述のエラーがコンソールにエコーされ、ブラウザにサーバー・エラーが表示されます。システムにはアクセスできません。
アップグレードされた領域にはpassword.xmlファイルは作成されません。
|
注意: 10.1.4より前のリリースでは、パスワード・ファイルはpassword.lstとして命名および書式設定されていました。10.1.4以降のリリースでは、パスワード・ファイルはpassword.xmlとして命名および書式設定されます。 |
次の情報は、同じ「簡易」モード・パスワードがIDシステムで使用されている場合の、この問題の回避方法です。この場合、「同じ「簡易」モード・パスワードがIDシステムで使用されている場合の回避方法」の手順に従って、アップグレード後のIdentity Serverからアップグレード後のAccess ServerおよびWebGateにpassword.xmlをコピーできます。パスワードは、「簡易」モードを選択した後すぐにたずねられます。
ただし、パスワードがIdentity Server上とAccess Server上で同じでない場合は、その次の手順に進んでください。その場合も、パスワードは「簡易」モードを選択した後すぐにたずねられます。
同じ「簡易」モード・パスワードがIDシステムで使用されている場合の回避方法
同じ「簡易」モードのパスワードがIDシステムで使用される場合、password.xmlファイルを次のようにコピーします。
/oblix/config/password.xml/oblix/config /password.xml/oblix/config/password.xmlAccess Serverを起動します。
WebGateのWebサーバーを再起動します。
アクセス・システムの「簡易」モード・パスワードがIDシステムの「簡易」モード・パスワードと同じでない場合は、次のツールと手順でパスワードを変更する必要があります。
/access/oblix/tools/configureAAAServer/access/oblix/tools/configureWebGate
「簡易」モード・パスワードがIDシステムとAccess Serverとで異なる場合の回避方法
configureAAAserverが置かれているフォルダに移動します。次に例を示します。
AccessServer_install_dir\access\oblix\tools\configureAAAServer
次のコマンドを実行します。
configureAAAServer chpasswd AccessServer_install_dir
画面に表示される質問に答えます。
Access Serverを再起動します。
「簡易」モード・パスワードがIDシステムとWebGateとで異なる場合の回避方法
次のディレクトリに移動します。
WebGate_install_dir\access\oblix\tools\configureWebGate
WebGate_install_dirの部分には、WebGateがインストールされているディレクトリを指定します。
次のコマンドを実行します。
configureWebGate -i WebGate_install_dir -t WebGate -k
-kオプションを指定した場合、「簡易」モードまたは「証明書」モードのトランスポート・セキュリティについてのみパスワードの入力が求められます。
画面の質問に答えます。
WebGateのWebサーバーを再起動します。
configureAAAServerおよびconfigureWebGateツールの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
10g（10.1.4.0.1）のインストーラでは、アップグレード中、移行バンドルをダウンロードしてそれらを特定のディレクトリに配置するよう求めるメッセージが表示されます。これらのバンドルは、10g（10.1.4.0.1）の『Oracle Access Managerアップグレード・ガイド』には記載されておらず、提供もされていません。
この問題の回避方法: 次のメッセージを無視してください。このメッセージはSoftware Developer Kit（SDK）インストーラから削除される予定です。
Please download and extract COREid 6.5 migration bundles To ensure success when upgrading a COREid 6.5 installation, you need to perform the following steps before you continue. For information, see the Oracle Access Manager Upgrade Guide chapter on preparing your environment. 1) Log in to the download Web site. http://www.oracle.com/support/contact.html Retrieve appropriate _msg and _param files for the older version of this component. For example: Netpoint_65_orig_en_<Component>_msg.zip Netpoint_65_orig_<Component>_param.zip Note: Retrieve only the files that are relevant to your older installation. Files for version 6.5 include _65_ in their name; files for version 6.5.2 or later include _652_ in their name. Press ENTER to read the text [Type q to quit]. 3) Extract or unzip these files in to your <Component Installation Directory>. For example: <Component Installation Directory>/identity <Component Installation Directory>/access A directory named "orig" is created during this process. For example: <Component Installation Directory>/identity/oblix/orig. <Component Installation Directory>/access/oblix/orig. Press 1 for Next, 2 for Previous, 3 to Cancel or 4 to Redisplay [1]
『Oracle Access Managerアップグレード・ガイド』では、リリース6.x環境の準備に関する記述の中で、アップグレード前に特定のCOREid 6.x用バンドルをインストール・メディアから入手する方法が説明されています。しかし、これらのファイルはメディアからは入手できません。
この問題の回避方法は次のとおりです。COREid 6.xを10g（10.1.4.0.1）にアップグレードする前に、次の手順を実行して、足りないパッケージ（任意のプラットフォーム用のテキスト・ファイルが含まれています）をダウンロードしてください。
ブラウザで、次のURLを入力します。
MetaLinkにログインします。
「Quick Find」リストから「Patch Number」を選択します。
「Quick Find Patch Number」の隣のフィールドに5724938と入力し、「Go」ボタンをクリックします。
パッチ5724938の検索結果と、「UNABLE TO LOCATE MIGRATION BUNDLE FOR 6.5-10.1.4 UPGRADE.」というメッセージが表示されます。
|
注意: 「Platform」は自動的にMicrosoft Windows 2000と指定されます。これは、すべてのプラットフォームで使用できるテキスト・ファイルしかバンドルに含まれていないためです。バイナリ・ファイルはありません。 |
「Download」ボタンをクリックし、画面の指示に従います。
アップグレードを続ける前に、次の各項の内容を確認し、その後『Oracle Access Managerアップグレード・ガイド』の説明に従ってファイルを抽出し、コンポーネントの準備を完了してください。
AIX上のリリース6.1.1用のパッケージ
AIXプラットフォームで6.1.1から10g（10.1.4.0.1）にアップグレードする場合に必要なファイルについては、『Oracle Access Managerアップグレード・ガイド』で説明しています。ただし、これらのファイルはメディアに収録されておらず、AIXプラットフォームはまだサポートされていない可能性があります。
リリース6.5.0.x用のパッケージ
リリース6.5用のパッケージとしては、Netpoint_65_orig_en_AccessServerSdk_msg.zipが新たに追加されました。Oracle Access Managerを6.5.0.xからアップグレードする前には、次のパッケージをダウンロードし、オリジナルのComponent_install_dirに追加する必要があります。
| オリジナルのComponent_install_dirに追加するExtract 65-origパッケージ |
|---|
Netpoint_65_orig_en_COREid_Server_msg.zip |
Netpoint_65_orig_COREid_Server_param.zip |
Netpoint_65_orig_en_Access_Manager_msg.zip |
Netpoint_65_orig_Access_Manager_param.zip |
Netpoint_65_orig_en_WebPass_msg.zip |
Netpoint_65_orig_WebPass_param.zip |
Netpoint_65_orig_en_Access_Server_msg.zip |
Netpoint_65_orig_Access_Server_param.zip |
Netpoint_65_orig_en_WebGate_msg.zip |
Netpoint_65_orig_WebGate_param.zip |
Netpoint_65_orig_en_AccessServerSdk_msg.zip |
リリース6.5.2.xパッチ用のパッケージ
6.5.2用のパッケージとしては、Netpoint_652_orig_AccessServerSdk_param.zipとNetpoint_652_orig_en_AccessServerSdk_msg.zipが新たに追加されました。最初にリリース6.5.0.xをインストールし、その後6.5.2.xをインストールした場合は、アップグレードの前に次のパッケージをダウンロードし、オリジナルのComponent_install_dirに追加する必要があります。
| オリジナルのComponent_install_dirに追加するExtract 652_origパッケージ |
|---|
Netpoint_652_orig_en_COREid_Server_msg.zip |
Netpoint_652_orig_COREid_Server_param.zip |
Netpoint_652_orig_en_WebPass_msg.zip |
Netpoint_652_orig_WebPass_param.zip |
Netpoint_652_orig_en_Access_Manager_msg.zip |
Netpoint_652_orig_Access_Manager_param.zip |
Netpoint_652_orig_en_Access_Server_msg.zip |
Netpoint_652_orig_Access_Server_param.zip |
Netpoint_652_orig_en_WebGate_msg.zip |
Netpoint_652_orig_WebGate_param.zip |
Netpoint_652_orig_AccessServerSdk_param.zip |
Netpoint_652_orig_en_AccessServerSdk_msg.zip |
マルチ言語を使用するリリース6.5用のバンドルの無視
『Oracle Access Managerアップグレード・ガイド』には、リリース6.5から10g（10.1.4.0.1）へのアップグレードには特定のマルチ言語パッケージが必要であると記載されています。しかし、マルチ言語バンドルは必要ではなく、提供もされていません。『Oracle Access Managerアップグレード・ガイド』にある、マルチ言語のインストール準備に関する情報は無視してください。
Novell eDirectoryを使用する場合、Identity Serverのインストールでのディレクトリ・サーバーの更新中にエラーが発生します。このエラーは、ポリシー・データに別のディレクトリを使用している場合、Policy Managerのインストール中にも発生します。
"Error 16: Unable to update Identity System Configuration - Unknown LDAP error occurred."
このエラー・メッセージは処理全体の失敗という印象を与えますが、obLPMnameという1つの属性以外に索引が適用されています。
この問題の回避方法は次のとおりです。詳細は、Novell eDirectoryのドキュメントを参照してください。
エラー・メッセージを放棄します。
Novellの索引管理ツールを使用して、obLPMname属性を手動で索引付けして同等にします。
マスターAccess Managerの10g（10.1.4.0.1）へのアップグレード中に、認証スキームのチャレンジ・パラメータに複数の行があると、チャレンジ・パラメータの最初の行のみが移行されます。チャレンジ・パラメータの残りの行は破棄されます。
次のリリースの『Oracle Access Managerアップグレード・ガイド』には、次の回避方法が追加される予定です。
次の手順を実行してOracleMetaLinkからPSE Hotfix 02を取得します。
OracleMetaLinkにアクセスし、通常どおりログインします。
https://metalink.oracle.com
「Patches & Updates」タブをクリックします。
「Quick Links to the Latest Patchsets, Mini Packs, and Maintenance Packs」をクリックします。
「Quick Links」ページで、「Patch Sets for Product Bundles」表の「Oracle Oblix COREid」をクリックします。
表示される「Advanced Search」ページで、「Simple Search」ボタンをクリックします。
「Simple Search」ページで、次の詳細が指定されていることを確認します。
Search by: Oracle Oblix COREid Family製品またはファミリ
Release: Oracle Oblix COREid 10g（10.1.4.0.1）
Patch Type: Patch
Platform or Language: Linux-64またはMSwin2000
「Go」ボタンをクリックして結果表を表示します。
「Results」表の「Patch」列で、パッチ番号をクリックします。たとえば、5569442
「Patch Page」で、「Download」ボタン（一般情報を表示するには「View Readme」ボタン、または「View Digest」ボタン）をクリックします。
『Oracle Access Manager Patchset Exception (PSE) Notes 02 for Release 10g (10.1.4.0.1) for All Operating Systems』の説明に従ってPSE Hotfix 02をインストールします。
『Oracle Access Managerアップグレード・ガイド』の説明に従って、スキーマおよびデータのアップグレード時に使用するマスターAccess Managerコンポーネントを作成します。
『Oracle Access Managerアップグレード・ガイド』の説明に従って、10g（10.1.4.0.1）インストーラを使用してマスターAccess Managerコンポーネントのアップグレードを開始し、次の操作を行います。
通常どおり、「はい」をクリックしてアップグレードを受け入れます。
通常どおり、アップグレードするインストール済の言語を確認し、タイムスタンプ付きのディレクトリ名を記録します。
続行する前に、PSE Hotfix 10.1.4.0.1-02のobmigratedataツールに移動し、そのツールを使用してマスターAccess Managerインストール・ディレクトリのobmigratedataツールを置換します。
「自動」モードまたは「確認済」モードのいずれかを指定し、『Oracle Access Managerアップグレード・ガイド』の説明に従ってアップグレードを終了します。
SNMPエージェントのinstallshieldウィザードでは変換はサポートされていません。
問題
ディレクトリの詳細の定義時に、Sun Java Directory Server 6.0を使用した10g（10.1.4.0.1）Identity Serverのインストールが失敗します。Sun Directory Server 5.xを指定してSun Directory Server 6のホスト名、ポート番号および資格証明を指定し、LDAPサーバー・スキーマ構成の自動更新で「はい」を選択すると、次のエラーが表示されます。
Error 32: LDAP Invalid credentials. Or invalid directory type supplied. Or no such object.
これは、Sun Directory Server 6を使用してPolicy Managerをインストールする場合も起こります。
原因
Sun Java Directory Server 6.0とOracle Access Manager 10g（10.1.4.0.1）の組合せは、10g（10.1.4.0.1）のリリース後に動作保証されました。このため、Identity Serverのインストール時にSun Java Directory Server 6.0を選択するオプションがありません。Sun Directory Server 5.xを選択した場合、スキーマの自動更新時に構成に失敗します。
Sun Java Directory Server 6.0を使用したインストールでは、スキーマの自動更新オプションは使用できません。スキーマを手動で更新する必要があります。
解決策
『Oracle Access Managerインストレーション・ガイド』に記載のとおり、Oracle Access Manager 10g（10.1.4.0.1）をインストールし、Sun Directory Server 5.xオプションを選択します。
Sun Directory Server 6のホスト名、ポート番号および資格証明を指定します。
Sun Java System Directory Server 6.0 Management Consoleまたはldapmodifyコマンドラインを使用し、次のLDIFファイルを使用してOracle Access Managerスキーマと索引ファイルをSun Java System Directory Server 6.0にロードします。
ユーザー・データのみをホストするLDAPサーバー・インスタンス:
IdentityServer/identity/oblix/data.ldap/common/iPlanet_user_schema_add.ldif IdentityServer_installdir/identity/oblix/data.ldap/common/iPlanet5_user_index_add.ldif
ユーザー・データと構成データ（または構成データとポリシー・データ、あるいはポリシー・データのみ）をホストするLDAPサーバー・インスタンス:
installdir/identity|access/oblix/data.ldap/common/iPlanet_oblix_schema_add.ldif installdir/identity|access/oblix/data.ldap/common/iPlanet5_oblix_index_add.ldif
前述のパスでidentityと|accessの間のパイプ（|）は、「または」を意味します。Identity Serverをインストールする場合、パスはIdentityServer_installdir/identityで、Policy Managerをインストールする場合、パスはPolicyManager_installdir/accessです。
|
注意: ldapmodifyコマンドの例は、http://docs.sun.com/app/docs/doc/819-0995/6n3cq3avf?a=viewのSunのドキュメントを参照してください。 |
通常どおり、Identity ServerまたはPolicy Managerの設定に進みます。
|
注意: Oracleサポートでは、10g（10.1.4.0.1）のインストール後すぐに最新のパッチセット10.1.4.2を適用することを強くお薦めします。このパッチセットは、Metalink: Patch 5957301からダウンロードできます。詳細は、5.1項「Oracle Access Manager 10g（10.1.4.0.1）パッチ・セットおよびバンドル・パッチ」を参照してください。 |
この項では、削除の問題および回避方法について説明します。内容は次のとおりです。
言語パックをアンインストールした後、サーバーを停止して再起動する必要があります。たとえば、韓国語の言語パックを使用してIdentity ServerとWebPassをインストールしたとします。各コンポーネント・ホストで韓国語の言語パックをアンインストールした後、Identity ServerサービスとWebPass Webサーバー・インスタンスの両方を停止して再起動する必要があります。これにより、該当するコンポーネントが適切な言語サポートで再初期化されます。
言語パックのインストールおよび削除方法の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
インストール中に選択したデフォルトの管理者言語に関連付けられた言語パックの削除（アンインストール）はサポートされていません。この言語パックを削除するとエラーが発生し、IDシステムおよびアクセス・システムにアクセスできなくなります。
リカバリするには、『Oracle Access Managerインストレーション・ガイド』の「トラブルシューティング」の章に記載されている言語パックの問題についての説明を参照してください。
指定したインストール・ディレクトリにコンポーネント・ファイルを抽出した後、コンポーネントのインストールが終了した場合（またはユーザーが指定してインストールを終了した場合）、同じ場所に再インストールする前に、コンポーネントに対してアンインストーラを実行してインストール・ディレクトリを削除する必要があります。単にインストール・ディレクトリを削除して同じ場所にコンポーネントを再インストールしようとすると、vpd.propertiesファイルが一貫性のない状態になり、再インストールが機能しません。
たとえば、コンポーネント・ファイルの抽出後WebGateのインストールを終了し、インストール・ディレクトリをWebGateアンインストーラを使用せず手動で削除したとします。この場合、抽出されたファイルは削除されますが、vpd.propertiesファイルは削除されません。このためvpd.propertiesファイルが一貫性のない状態になり、インストールは失敗します。
アンインストールの詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
Oracle Access Manager 10g（10.1.4.0.1）ではoblixOrgPersonおよびoblixConfigのobVer属性の使用方法が変更されたため、以前のリリースから10g（10.1.4.0.1）にアップグレードした後でロールバックの問題が起こる可能性があります。この問題は、次のリリースの『Oracle Access Managerアップグレード・ガイド』に記載される予定です。詳細は、5.9項「ドキュメントの問題」を参照してください。
このロールバックの問題は次の回避方法によって解決できますが、『Oracle Access Managerアップグレード・ガイド』には次のリリースで記載される予定です。
以前のリリースからOracle Access Manager 10g（10.1.4.0.1）にアップグレードする際、ディレクトリ・サーバーのoblixツリーに格納されている構成データは自動的に移行され、obVer属性の値は10.1.4.0に変更されます。ただし、ユーザー・データはアップグレード後の最初のログインまで移行されません。つまり、ユーザー・データ（OblixOrgPersonクラス内）のobVer属性の値は10.1.4.0以前の値のままになります。
ユーザー・エントリは、ユーザー・データの即時（オンザフライ）移行を一時的に停止しないかぎり、10g（10.1.4.0.1）にアップグレードした後のユーザーの初回ログイン時に即座に移行されます。そのユーザーの既存のチャレンジ値とレスポンス値はすべてエンコード（末尾に@1#が追加）され、OblixOrgPersonクラスでのそのユーザーのobVer属性値が10.1.4.0に変更されます。しかし、ロールバック・プロセスではこれらの変更は元に戻されません。以前のリリースにロールバックした場合、OblixOrgPersonクラスのユーザー・エントリのobVer値は10.1.4.0のままになり、チャレンジ値とレスポンス値はエンコード後の形式のままになります。
フェーズ1は、データをバックアップした後、ホスト・マシンでアップグレードの準備をする前に、『Oracle Access Managerアップグレード・ガイド』の第5章の説明に従って実行する必要があります。フェーズ1では、マスター管理者エントリのobVer属性を設定し、その後スキーマとデータを10g（10.1.4.0.1）にアップグレードします。フェーズ2は、スキーマとデータのアップグレード後に実行します。フェーズ2では、チャレンジおよびレスポンス・セマンティック型をタブ・レベルとオブジェクト・クラス・レベルの両方で削除します。
次のフェーズ1の手順を実行する前に、次の条件について考慮する必要があります。
ユーザー・エントリのobjectclassリスト内にOblixOrgPersonが存在しない場合は、手順1に従ってOblixOrgPersonを追加する必要があります。存在する場合は、手順2から開始します。
最後の手順を実行した後には、ロスト・パスワード管理機能は機能しなくなります。
最初のログインでのユーザー・データのオンザフライ移行を一時的に停止した後には、ユーザー・データの下位互換性を維持するために、次のアクションの実行は避けることをお薦めします。
ワークフロー・チケットの処理（ユーザーの作成、属性の変更など）。
チャレンジおよびレスポンス属性の「プロファイルの変更」ページからの修正。
ユーザー・データの即時移行を一時的に停止する手順（フェーズ1）
OblixOrgPersonをマスター管理者のユーザー・エントリに追加します（必要な場合）。
ldapmodify.exe -h <Host> \
-p <Port>
-D <Bind DN>
-w <Bind Password> \
-f <ldif file containing attribute to be added>
OblixOrgPersonをobjectclassリストに追加したときに作成されるLDIFファイルの形式は次のとおりです。ここでは、Netscapeディレクトリ・サーバーの場合の例を示します。
dn: <Administrator DN>
changetype: modify
add: objectclass
objectclass: OblixOrgPerson
次のコマンドを使用して、LDAPディレクトリ・サーバー内のマスター管理者エントリのobVer属性を7.0.4に設定します。
ldapmodify.exe -h <Host> \
-p <Port>
-D <Bind DN>
-w <Bind Password> \
-f <ldif file containing attribute to be modified>
作成されるLDIFファイルの形式は次のとおりです。ここでは、Netscapeディレクトリ・サーバーの場合の例を示します。
dn: <Administrator DN>
changetype: modify
replace: obver
obver: 7.0.4
『Oracle Access Managerアップグレード・ガイド』の第5章の説明に従って、残りの準備タスクを最後まで実行します。
『Oracle Access Managerアップグレード・ガイド』の第6章の説明に従って、対象のデプロイに対するスキーマとデータのアップグレードを実行します。この章には、この手順のフェーズ2の実行方法も記載されています。詳細は、5.4.4.2項「ユーザー・データのオンザフライ移行の停止: フェーズ2」を参照してください。
フェーズ2を実行する前に、『Oracle Access Managerアップグレード・ガイド』の第5章のすべての操作と、第6章で説明している次のタスクを完了している必要があります。第6章の前提条件タスクは次のとおりです。
マスターIdentity Serverでのスキーマおよびデータのアップグレード
マスターWebPassのアップグレード
IDシステムのスキーマおよびデータのアップグレードの検証
ディレクトリ・サーバーの索引ファイルのアップロード
アップグレードされたIDデータのバックアップ
|
注意: フェーズ2は、IDシステムとアクセス・システムを組み合せたデプロイがある場合でも、すべての管理者およびユーザーの初回ログインより前に実行する必要があります。 |
フェーズ2では、チャレンジおよびレスポンス・セマンティック型をタブ・レベルとオブジェクト・クラス・レベルの両方で削除する必要があります。
|
注意: このフェーズ2を完了すると、ロスト・パスワード管理は機能しなくなります。 |
フェーズ2を完了した後には、ユーザー・データの下位互換性を維持するために、次のアクションの実行は避けることをお薦めします。
ワークフロー・チケットの処理（ユーザーの作成、属性の変更など）。
チャレンジおよびレスポンス属性の「プロファイルの変更」ページからの修正。
ユーザー・データの即時移行を一時的に停止する手順（フェーズ2）
スキーマとデータをアップグレードしたら、次のコマンドを使用して、構成ベースのobVerの値を7.0.4に変更します。
ldapmodify.exe -h <Host> \
-p <Port>
-D <Bind DN>
-w <Bind Password> \
-f <ldif file containing attribute to be modified>
構成データのバインドDN（構成DN）は、ユーザー・データの検索ベースのようなものです。構成バインドDNを指定するのは、IDシステムとアクセス・システムについて、Oracle Access Managerのスキーマとすべての構成データが格納されるDIT内のノードを識別する必要があるためです。
作成されるLDIFファイルの形式は次のとおりです。ここでは、Netscapeディレクトリ・サーバーの場合の例を示します。
dn: o=oblix,<configuration DN>
changetype: modify
replace: obver
obver: 7.0.4
マスターIdentity Serverを再起動します。
使用している環境のURLを指定してIDシステム・コンソールに移動し、マスター管理者としてログインます。次に例を示します。
http://hostname:port/identity/oblix
ここで、hostnameにはWebPass Webサーバーをホストするマシンの名前を、portにはWebPass Webサーバー・インスタンスのHTTPポート番号を指定します。/identity/oblixはIDシステム・コンソールに接続する働きをします。
タブ・レベル: 次の手順に従って、チャレンジおよびレスポンス・セマンティク型をタブ・レベルで削除します。
IDシステム・コンソールをクリックし、「User Manager構成」をクリックした後、「タブ」をクリックします。
ページにリストされる「既存のタブ」から「従業員」を選択して、そのPersonクラス・タブに関する情報を「タブの表示」ページに表示します。
|
注意: 「タブの表示」ページの「オブジェクト・クラス」には、OblixOrgPerson以外のクラス（gensiteorgpersonなど）が含まれる場合もあります。ただし、obVer属性はOblixOrgPersonクラスのみに属するメンバーです。その他のオブジェクト・クラスには影響しません。 |
「タブの表示」ページで、「属性の変更」をクリックして「属性の変更」ページを開きます。
「属性」リストから、「セマンティク型」が「チャレンジ」に設定されている属性を選択し、「セマンティク型」を「なし」に設定して、「保存」をクリックします。
「属性」リストから、「セマンティク型」が「レスポンス」に設定されている属性を選択し、「セマンティク型」を「なし」に設定して、「保存」をクリックします。
「完了」をクリックします。
オブジェクト・クラス・レベル: 次の手順に従って、チャレンジおよびレスポンス・セマンティク型をオブジェクト・クラス・レベルで削除します。
IDシステム・コンソールをクリックし、「共通構成」をクリックした後、「オブジェクト・クラス」をクリックします。
リストからpersonオブジェクト・クラスを選択し、「属性の変更」をクリックして「属性の変更」ページを開きます。
「属性」リストから、「セマンティク型」が「チャレンジ」に設定されている属性を選択し、「セマンティク型」を「なし」に設定して、「保存」をクリックします。
「属性」リストから、「セマンティク型」が「レスポンス」に設定されている属性を選択し、「セマンティク型」を「なし」に設定して、「保存」をクリックします。
「完了」をクリックします。
対象のデプロイが正常にアップグレードされたことを検証した後にユーザー・データの移行を再開する方法の詳細は、5.4.4.3項「ユーザー・データのオンザフライ移行の再開」を参照してください。
このタスクを実行する前に、着手中のアップグレード・タスクをすべて完了し、アップグレードしたデプロイが想定どおりに稼働していることを検証して、ロールバックの必要が生じないようにしてください。
この項の手順は、次の状況に該当する場合に、ユーザー・データの即時（オンザフライ）移行を再開する目的で実行します。
ユーザー・データの即時（オンザフライ）移行が一時的に停止されている場合。
アップグレードしたデプロイが想定どおりに稼働していることを検証し、以前のリリースへのロールバックが必要ないことが確認できた場合。
|
注意: この項の操作を実行した後で以前のリリースにロールバックした場合、移行した一切のユーザー・データは元に戻りません。 |
次の手順では、チャレンジおよびレスポンスに使用されている属性をタブ・レベルとオブジェクト・クラス・レベルの両方で再構成する必要があります。
タブ・レベル: 次の手順に従って、チャレンジおよびレスポンス・セマンティク型をタブ・レベルで再構成します。
IDシステム・コンソールをクリックし、「User Manager構成」をクリックした後、「タブ」をクリックします。
リストから「従業員」を選択し、「属性の変更」をクリックして「属性の変更」ページを開きます。
「属性」リストから「チャレンジ」に使用されている属性を選択し、「セマンティク型」を「チャレンジ」に、「表示タイプ」を「単一行テキスト」に設定して「保存」をクリックします。
「属性」リストから「レスポンス」に使用されている属性を選択し、「セマンティク型」を「レスポンス」に、「表示タイプ」を「パスワード」に設定して「保存」をクリックします。
「完了」をクリックします。
オブジェクト・クラス・レベル: 次の手順に従って、チャレンジおよびレスポンス・セマンティク型をオブジェクト・クラス・レベルで再構成します。
IDシステム・コンソールをクリックし、「共通構成」をクリックした後、「オブジェクト・クラス」をクリックします。
リストからpersonオブジェクト・クラスを選択し、「属性の変更」をクリックして「属性の変更」ページを開きます。
「属性」リストから「チャレンジ」に使用されている属性を選択し、「セマンティク型」を「チャレンジ」に、「表示タイプ」を「単一行テキスト」に設定して「保存」をクリックします。
「属性」リストから「レスポンス」に使用されている属性を選択し、「セマンティク型」を「レスポンス」に、「表示タイプ」を「パスワード」に設定して「保存」をクリックします。
「完了」をクリックします。
次のコマンドを使用して、oblixConfig（LDAPディレクトリ・サーバー内の構成データのルート・ノード）のobVer属性を10.1.4.0に設定します。
ldapmodify.exe -h <Host> \
-p <Port>
-D <Bind DN>
-w <Bind Password> \
-f <ldif file containing attribute to be modified>
作成されるLDIFファイルの形式は次のとおりです。ここでは、Netscapeディレクトリ・サーバーの場合の例を示します。
dn: o=oblix,<configuration DN>
changetype: modify
replace: obver
obver: 10.1.4.0
アップグレードしたすべてのIdentity ServerとAccess Serverを再起動します。
この項では、アクセス・システムの問題および回避方法について説明します。内容は次のとおりです。
『Oracle Access Managerアクセス管理ガイド』で説明されているように、Access Serverのユーザー・キャッシュは構成可能です。しかし同ガイドでは、このキャッシュを無効にするために指定する値が省略されています。
キャッシュを無効にするには、Access Serverの「ユーザー・キャッシュ内の最大要素」フィールドに-1と指定します。
『Oracle Access Managerアクセス管理ガイド』に記載されているように、WebGateの診断URLでは、WebGateが接続されているAccess Serverのステータスが報告されます。このURLに到達するページで、Access Serverが実際には稼働しているにもかかわらず停止していると報告されることがあります。
この問題は、WebGateに関連付けられたAccess Serverの数がWebGateの「最大接続数」プロパティの値を超える場合に発生します。このような場合、最大接続数を超えるすべてのAccess Serverのステータスが、実際のステータスに関係なくWebGateの診断ページに「停止中」と表示されます。
たとえば、WebGate Aの「最大接続数」の値を1に設定し、3個のAccess Serverをこれに関連付け、AAA1、AAA2およびAAA3としたとします。診断ページには、AAA1が稼働中、AAA2およびAAA3が停止中と表示されます。AAA1が停止している場合、このページにはAAA2が稼働中、AAA3が停止中と表示されます。
この問題を修正するには、WebGateとAccess Server間の接続数をAccess Serverの数よりも大きい値に構成します。
「最大接続数」フィールドを構成するには、次のようにします。
アクセス・システム・コンソールで、「アクセス・システム構成」をクリックし、「AccessGate構成」をクリックします。
「Access Gateの検索」ページが表示されます。
このページに検索基準を入力するか、「すべて」ボタンをクリックします。
「実行」をクリックします。
検索基準に一致するAccessGateがこのページにリストされます。
WebGateのリンクをクリックします。
「AccessGateの詳細」ページが表示されます。
「変更」をクリックします。
「AccessGateの変更」ページにこのWebGateの設定が表示されます。
IIS 6でWebPassまたはWebGateをインストールしロギングを有効にした場合、WebPassまたはWebGateは、関連付けられたIdentity ServerまたはAccess Serverに接続できません。特に、この問題はMPFileLogWriterにログを送信する場合に発生します。FileLogWriterにログを送信する場合には発生しません。
この問題は、ログ・ファイルを含むディレクトリへのアクセス権を持つ匿名ユーザーがいない場合にMPFileLogWriterで発生します。MPFileLogWriterは、<logfile name>.lckという名前のファイルを使用して、該当するログ・ファイルへの複数の書込みプロセスを同期化します。MPFileLogWriterは、oblog.logファイルに書き込む前に.lckファイルに対して書込みロックを行います。
ログ・ファイルを含むディレクトリへのアクセス権を持つ匿名ユーザーを構成します。書込みロックの取得に使用されるユーザー・コンテキストがIISの匿名Webユーザーになることもあります。デフォルトでは、このユーザーにIUSR_<computer name>という名前が付けられますが、この目的のために匿名ユーザーを構成することができます。
管理者は、認証や認可の成功と失敗に対応するリダイレクト・アクションを指定できます。ただし、Webサーバーに関してこのアクションを指定すると、使用しているWebGateがOracle HTTP Serverバージョン2にインストールされている場合に、リダイレクトが失敗することがあります。
たとえば、次の操作を行った場合、HTTPSではなくHTTPリダイレクトを使用してリダイレクトされることがあります。
Policy Managerで、リソースを保護するためのポリシーを作成した場合。
フォームベースの認証スキームを使用してリソースを保護した場合。
認証の成功に対するリダイレクト・アクションを指定した場合。
ブラウザで、保護されたリソースのURLを入力した場合。
ログイン・フォームでログイン資格証明を入力した場合。
この問題を回避するには、ssl.confファイルで、仮想ホスト定義のセクションに次の行を追加します。
LoadModule certheaders_module modules/mod_certheaders.so AddCertHeader HTTPS AddCertHeader SSL_CLIENT_CERT SimulateHttps On
ディレクトリ・サーバー・プロファイルの構成後、Access ServerまたはPolicy Managerのメモリー使用率が異常に高くなります。
ディレクトリ・サーバー・プロファイルを構成すると、最大セッション時間を指定するように要求されます。セッション時間のデフォルト値は0（無制限）です。これにより、Access ServerおよびPolicy ManagerへのLDAP接続のキャッシュ・サイズが一定期間増加するため、パフォーマンス上の問題が発生します。Oracle Access Managerはこのキャッシュを直接制御しません。
キャッシュ・サイズでパフォーマンス上の問題を回避するには、ディレクトリ・サーバー・プロファイルの「最大セッション時間（分）」の値を、次のようにして有限値（例では10時間）に設定します。
IDシステム・コンソールで、「システム構成」をクリックし、「ディレクトリ・プロファイル」をクリックします。
変更するプロファイルのリンクをクリックします。
「最長セッション時間（分）」フィールドの値を600に設定します。
フォームベースの一部の認証スキームでは、passthrough:チャレンジ・パラメータの指定に問題があります。特にこのパラメータは、フォームベースのログインにPOSTメソッドを使用する場合にDomino Webサーバーで機能しません。
現在、この問題の解決策はありません。
『Oracle Access Manager統合ガイド』には、アクセス・システムのシングル・サインオンとOracleAS Single Sign-Onとの統合に関する章があります。アクセス・システムをOracleAS Single Sign-On 10.1.2.0.2と統合するには、『Oracle Access Manager統合ガイド』の説明に従うだけでなく、次の手順を実行する必要があります。
統合を構成するには、次のようにします。
『Oracle Access Manager統合ガイド』のアクセス・システムのシングル・サインオンとOracleAS Single Sign-Onとの統合に関する章の手順に従います。
アクセス・システム・コンソールで、「システム構成」をクリックし、「サーバー設定」をクリックして、次のログアウトURLを構成します。
http://[host.domain]:[port]/pls/orasso/ORASSO.wwsso_app_admin.ls_logout?p_done_url=http%3A%2F%2F[host.domain]%3A[port]
p_done_urlの値をURLエンコードします。
シングル・サインオンのログアウト・リンクの構成に関する詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。このリリース・ノートの最後に、この目的のために使用できるサンプルJSPが記載されています。
サンプルJSPを使用する場合、アクセス・システム・コンソールで「アクセス・システム構成」をクリックし、「AccessGate構成」をクリックして、使用する環境の各WebGateのLogOutURLsパラメータに次の内容を含めます。
/access/oblix/lang/en-us/style2/oblixlogo.gif
次にサンプルlogout.jspファイルを示します。
<!-- Copyright (c) 1999, 2003, Oracle. All rights reserved. -->
<%@page autoFlush="true" session="false"%>
<%
// Declare English Message Strings
String msg1 = "Single Sign-Off";
String msg2 = "Application Name";
String msg3 = "Logout Status";
String msg4 = "ERROR: The return URL value not found.";
String msg5 = "ERROR: Logout URL for partner applications not found.";
// Get the user language preference
String userLocaleParam = null;
java.util.Locale myLocale = null;
// Get the user locale preference sent by the SSO server
try
{
userLocaleParam = request.getParameterValues("locale")[0];
}
catch(Exception e)
{
userLocaleParam = null;
}
if( (userLocaleParam == null) || userLocaleParam.equals("") )
{
myLocale = request.getLocale();
}
else
{
if(userLocaleParam.indexOf("-") > 0 )
{
// SSO server sent the language and territory value (e.g. en-us)
myLocale = new java.util.Locale(userLocaleParam.substring(0, 2),
userLocaleParam.substring(3, 5));
}
else
{
// SSO server sent only the language value (e.g. en)
myLocale = new java.util.Locale(userLocaleParam, "");
}
}
// The following two lines will be used only for the Multilingual support
with
// proper resource bundle class supplied
// java.util.ResourceBundle myMsgBundle
// = java.util.ResourceBundle.getBundle("MyMsgBundleClassName", myLocale);
// Get the message string in the appropriate language using the message key.
// Use this string to display the message in this page.
// String mesg = myMsgBundle.getString("mesg_key");
%>
<html>
<body bgcolor="#FFFFFF">
<h1><%=msg1%></h1>
<%
String done_url = null;
int i = 0;
// Get the return URL value
try
{
done_url = request.getParameterValues("p_done_url")[0];
}
catch(Exception e)
{
done_url = "";
}
// Get the application name and logout URL for each partner application
try
{
%>
<b> <%=msg2%> <%=msg3%> </b>
<br>
// Substitute an actual host, domain, and port for
myhost.us.mydomain.com:7777
// that points to the WebGate.
<img
src="http://myhost.us.mydomain.com:7777/access/oblix/lang/en-us/style2/oblixlo
go.gif">
<%
for(;;)
{
i++;
String app_name = request.getParameterValues("p_app_name"+i)[0];
String url_name = request.getParameterValues("p_app_logout_url"+i)[0];
%>
<%=app_name%>
<img src="<%=url_name%>">
<br>
<%
}
}
catch(Exception e)
{
if(done_url == null)
{
%>
<%=msg4%> <br>
<%
}
if(i>1)
{
%>
<br> <a href="<%=done_url%>">Return</a>
<%
}
else
{
%>
<%=msg5%><br>
<%
}
}
%>
</body>
</html>
このリリースでは、認証アクションや認可アクションの特定のパラメータで大/小文字が区別されます。たとえば、以前のリリースではポリシー・ドメインをPolicy Managerに設定し、cookieパラメータを使用する認証アクションまたは認可アクションを組み込むことができました。このリリースでは、このようにしてもアクションに対してcookieが設定されません。保護されているリソースにブラウザからアクセスして、ブラウザへのHTTPトラフィックを監視することで、この構成の問題を確認できます。この問題を回避するには、次のアクション・タイプのパラメータをポリシーで使用するときは、大文字と小文字を変更せずに指定します。
Cookie
HeaderVar
Oracle Identity Management 9.0.2とOracle Access Manager 10g（10.1.4.0.1）の間にシングル・サインオンを実装しようとすると、問題が発生することがあります。cookieではなくHTTPヘッダーを使用して認証を構成する場合、ASCIIテキストが使用されているヘッダーしかサポートされません。HTTPヘッダーと非ASCIIデータを統合するには、パッチをインストールする必要があります。Oracleサポート・サービスに問い合せて、Oracle Bug#5552617用のパッチを入手してください。
以前のアクセス・システム・コンソールのページの「AMサービスの状態」は、「アクセス管理サービス」に変更されました。10.1.4のAccess ServerおよびAccessGateの構成ページでは、「アクセス管理サービス」は正しく表示されます。
ただし、次の箇所では「アクセス管理サービス」ではなく、「ポリシー・マネージャAPIサポート」と誤って表示されます。
アクセス・サーバー・クラスタ構成ページ
Access ServerおよびAccessGateの構成ページのヘルプ
この項では、IDシステムの問題および回避方法について説明します。内容は次のとおりです。
RDN属性値を変更しようとすると、IDシステムからユーザー・エントリが削除されます。RDNはDNの一番左にある属性です。RDN属性は通常cnまたはFull Nameです。
この問題は、Oracle Internet Directoryをバックエンド・リポジトリとして使用する場合に発生します。この問題を修正するには、次のようにします。
次のディレクトリにあるファイルldapreferentialintegrityparams.xmlを編集します。
Identity_Server_installation_directory\identity\oblix\data\common
次のように、referential_integrity_usingパラメータの値をoblixからdsに変更します。
<NameValPair ParamName="referential_integrity_using" Value="ds"/>
ファイルを保存します。
Identity Serverを再起動して変更を反映します。
RDN属性値を問題なく変更できるようになります。
複数のIdentity Serverインスタンスをインストールしている場合、Identity Serverインスタンスごとにこの変更を加えます。
RDN属性値を変更しようとすると、IDシステムからユーザー・エントリが削除されます。RDNはDNの一番左にある属性です。RDN属性は通常cnまたはFull Nameです。
この問題は、Oracle Internet Directoryをバックエンド・リポジトリとして使用する場合に発生します。この問題を修正するには、次のようにします。
次のディレクトリにあるファイルldapreferentialintegrityparams.xmlを編集します。
Identity_Server_installation_directory\identity\oblix\data\common
次のように、referential_integrity_usingパラメータの値をoblixからdsに変更します。
<NameValPair ParamName="referential_integrity_using" Value="ds"/>
ファイルを保存します。
Identity Serverを再起動して変更を反映します。
RDN属性値を問題なく変更できるようになります。
複数のIdentity Serverインスタンスをインストールしている場合、Identity Serverインスタンスごとにこの変更を加えます。
複数のReal Application Clusters（RAC）データベースに対して監査を構成している場合、監査は一定期間適切に機能します。しかし、前回停止したRACインスタンス以外のRACインスタンスを停止して再起動すると、監査が停止します。
この問題を回避するには、Identity Serverを再起動します。
スタイルシートをカスタマイズすると、Identity Serverがクラッシュするか、または捕捉されたWin32例外に関するエラーを発行します。
スタイルシートのxsl:include構成メンバーのパス・セパレータとして円記号を使用した場合、円記号をスラッシュに置換します。たとえば、次のように変更するとします。
<xsl:include href=".\style.xsl" />
これを次のように変更します。
<xsl:include href="./style.xsl" />
IIS 6でWebPassをインストールしロギングを有効にした場合、WebGateは、関連付けられたIdentity ServerまたはAccess Serverに接続できません。特に、この問題はMPFileLogWriterにログを送信する場合に発生します。FileLogWriterにログを送信する場合には発生しません。
この問題は、ログ・ファイルを含むディレクトリへのアクセス権を持つ匿名ユーザーがいない場合にMPFileLogWriterで発生します。MPFileLogWriterは、<logfile name>.lckという名前のファイルを使用して、該当するログ・ファイルへの複数の書込みプロセスを同期化します。MPFileLogWriterは、oblog.logファイルに書き込む前に.lckファイルに対して書込みロックを行います。
ログ・ファイルを含むディレクトリへのアクセス権を持つ匿名ユーザーを構成します。書込みロックの取得に使用されるユーザー・コンテキストがIISの匿名Webユーザーになることもあります。デフォルトでは、このユーザーにIUSR_<computer name>という名前が付けられますが、この目的のために匿名ユーザーを構成することができます。
ディレクトリ・サーバー・プロファイルの構成後、Identity Serverのメモリー使用率が異常に高くなります。
ディレクトリ・サーバー・プロファイルを構成すると、最大セッション時間を指定するように要求されます。セッション時間のデフォルト値は0（無制限）です。これにより、Identity ServerへのLDAP接続のキャッシュ・サイズが一定期間増加するため、パフォーマンス上の問題が発生します。Oracle Access Managerはこのキャッシュを直接制御しません。
キャッシュ・サイズでパフォーマンス上の問題を回避するには、ディレクトリ・サーバー・プロファイルの「最大セッション時間（分）」の値を、次のようにして有限値（例では10時間）に設定します。
IDシステム・コンソールで、「システム構成」をクリックし、「ディレクトリ・プロファイル」をクリックします。
変更するプロファイルのリンクをクリックします。
「最長セッション時間（分）」フィールドの値を600に設定します。
『Oracle Access Managerインストレーション・ガイド』のIDシステムの設定に関する章に記載されているプロセスを実行した後に、日本語の言語パックをインストールすると、次のログ・ファイルにエラーが表示されます。
ORACLE_OHS_HOME/Apache/Apache/logs/error_log.*
ORACLE_OHS_HOMEはOracle HTTP Serverのインストール・ディレクトリです。このエラーは次の例のような書式です。
[Sun Jun 4 16:31:06 2006] [error] [client 12.345.678.99] [ecid: 1149406266:12.345.678.82:28663:0:3,0] File does not exist: /home/as1014/as1014coreid/COREid/webcomponent_3/identity/oblix//apps/admin/ bin/com/oblix/data/resource.class
このエラーは影響がないため、無視してかまいません。
オブジェクト・クラス属性を変更およびエクスポートすると、report.csvファイルが作成されます。日本語ロケールまたは簡体字中国語ロケールでは、UTF-8エンコードのデータが含まれているCSVファイルを処理できないというMicrosoft Excelの制限事項によるエンコードの問題があります。
エクスポートされたレポートを処理するには、次のプロセスを実行します。
report.csvをreport.txtという名前に変更します。
report.txtをExcel 2003で開きます（Excel 2000はUTF-8エンコードをサポートしていません）。
テキスト・インポート・ウィザードで、エンコードとしてUTF- 8を選択し、フィールド・セパレータとしてカンマを選択します。
「完了」をクリックします。
複数言語環境では、IDシステム・コンソールの構成タブ名（「User Manager構成（User Manager Configuration）」、「Group Manager構成（Group Manager Configuration）」および「Org. Manager構成（Org. Manager Configuration）」）の一部しか翻訳されていません。「構成（Configuration）」のみが翻訳されており、その前のアプリケーション名は翻訳されていません。
たとえば、ブラウザを使用してIDシステム・コンソールを表示した場合、「User Manager Configuration」タブのアプリケーション名「User Manager」は翻訳されていません。簡体字中国語では「User Manager Configuration」は完全に翻訳されています。
現在、この問題の解決策はありません。
IDシステム・コンソールでは、表示タイプ（ラジオ・ボタン、チェック・ボックスなど）のリストの項目値として表示される表示名が、Javaアプレットおよび国際化文字の既知の制限により正しく表示されません。ブラウザのJVMは、現在のロケールにある文字のみを表示します。国際化文字は、ブラウザを同じロケールに設定した場合のみアプレットに適切に表示されます。
表示名の値を設定したときに使用したロケールにブラウザを設定します。
新しい情報または変更した情報をOrg. Managerアプリケーションのオブジェクト・プロファイルに保存すると、データの一部が失われます。この問題は、パネルのない「Org. Manager」タブで発生します。Org. Managerのオブジェクト・プロファイルを変更する場合にデータが失われないようにするには、タブに1つ以上のパネルを構成する必要があります。このパネルの属性は、タブのヘッダー・パネルと同じ属性にする必要があります。
たとえば、ヘッダー・パネルに「ロケーション・タイトル」および「ロケーション名」という名前の2つの属性がある場合、次の手順を実行します。
IDシステムに到達するページで「IDシステム・コンソール」を選択します。
「Org. Manager構成」をクリックします。
「タブ」をクリックします。
パネルを追加するタブのリンクをクリックします。
「オブジェクト・プロファイルの表示」をクリックします。
「パネルの構成」をクリックします。
「作成」をクリックします。
「パネルの作成」ページで、パネル名を指定し、「ロケーション・タイトル」および「ロケーション名」属性を追加します。
『Oracle Access Manager開発者ガイド』には、.NETおよびJava形式のサンプルUDDI登録プログラムが次の場所に置かれていると記載されています。
webpass_install_dir\oblix\WebServices\UDDI\dotnet
および
webpass_install_dir\oblix\WebServices\UDDI\java
しかし、実際には次のパスにあります。
webpass_install_dir\oblix\WebServices\samples\UDDI\dotnet
および
webpass_install_dir\oblix\WebServices\samples\UDDI\java
『Oracle Access Manager開発者ガイド』の「JavaによるWSDLベースのWebサービスの起動」には、サンプル・コードをコンパイルおよび実行する際に、インストールしたAccess Manager SDKへのパスを次のように設定すると記載されています。
set PATH=f:\temp\AccessServerSDK\oblix\lib;F:\j2sdk1.4.2_05\bin;path
しかし、実際にはAccess Manager SDKへのパスは次のように設定します。
set PATH=AccessServerSDK_install_dir\oblix\lib;F:\j2sdk1.4.2_05\bin;%PATH%
AccessServer_install_dirの部分には、Access Managerがインストールされたディレクトリを指定します。
問題
英語以外のキーボードを使用してパスワードにマルチバイト・キャラクタを含むユーザーを作成すると、ユーザーの作成に失敗する場合があります。「ディレクトリ・サーバーのパスワード・ポリシー違反がありました。」というエラーが表示される場合があります。
原因
この問題は、uid属性とuserpassword属性の7ビット・チェック・プラグインを有効にした場合に発生します。この場合、既存ユーザーのパスワードを変更すると、新規に入力したパスワードの7ビット・チェックが実行されます。新規に入力したパスワードにマルチバイト・キャラクタが含まれている場合、パスワードは7ビット・クリーンとしてみなされません。この製品はこのように機能するように設計されています。
たとえば、ワークフローを作成すると、obcontainerId=workflowInstances,o=Oblix,o=company,c=usノードに値が格納されます。パスワード値は、obattrvals: <value>として格納され、7ビット・クリーンとしてエンコードされます。承認者がワークフローを承認すると、パスワード値は復号化され、userpassword属性に保存されます。
解決策
次の解決策は、『Oracle Access Manager IDおよび共通管理ガイド』の付録Fのトラブルシューティングに関する項に記載されています。
ワークフロー・ステップの7ビット・チェックを有効にする場合は、独自のプラグインを記述する必要があります。
|
注意: 使用するディレクトリ・サーバーによっては、7ビット・チェックがサポートされない場合もあります。どちらの場合でも、マルチバイト・キャラクタを使用してユーザーを作成できることが必要です。 |
ユーザー・パスワード（または他の任意の属性）にマルチバイト・キャラクタを含める場合は、その特定の属性の7ビット・チェックを無効にする必要があります。次の手順では、Sun（以前のiPlanet）ディレクトリ・サーバーの手順を示しています。ベンダーごとに詳細および手順が異なる可能性があります。詳細はベンダーのドキュメントを参照してください。
7ビット・チェックを無効にする手順
管理者としてディレクトリ・サーバーにログインします。
「Server Group」で、ディレクトリ・サーバー・インスタンスをクリックします。
ディレクトリ・サーバー・インスタンスの「Configuration」タブに移動します。
「Plug-ins」ノードを開いて、ディレクトリ・サーバー・インスタンスに適用されているプラグインのリストを表示します。
「7-bit check」をクリックして、このプラグインの影響を受ける属性のリストを表示します。
次に示すように、必要な属性を削除するか、プラグイン全体を無効にします。
obattrvalsを削除します。
「Advanced」ボタンをクリックし、nsslapd-pluginenabledをoffに設定してプラグインを無効にします。
ユーザーは、自身のユーザー・プロファイルを変更することで、ロスト・パスワード管理に使用されるチャレンジおよびレスポンスを変更できます。ただし、パネルの選択ボックスを使用してチャレンジとレスポンスを変更すると、予期しない結果が生じます。
Challenge phrase is blank. Provide values for all challenge phrases
この問題を解決するために、basic.xsl（標準的なラッパー・スタイルシート）とmisc.js（多くのスタイルシートに使用されるシステムレベルのファイル）が変更されています。これらの更新されたファイルはLPMChallengeResponsePatch.zipにあり、バンドル・パッチ10.1.4.2.0-BP04に含まれています。これらのファイルと、これに含まれる変更をデプロイメントに導入する必要があります。
|
注意: 以前のリリースを10g（10.1.4.2.0）にアップグレードすることをお薦めします。ただし、最新のbasic.xslとmisc.jsファイルを10.1.4.2.0バンドル・パッチ（10.1.4.2.0-BP04）から抽出し、以前にカスタマイズした点を最新バージョンに追加して、10g（10.1.4.0.1）デプロイメントの以前のバージョンを更新バージョンに置き換えることもできます。 |
LPMChallengeResponsePatch.zipは、10.1.4.2.0-BP04バンドル・パッチの各プラットフォームのZIPファイルに含まれています。パッチとLPMChallengeResponsePatch.zipは、次のようにして入手できます。ただし、他のバンドル・パッチ・コンポーネントは実際は使用しません。
バンドル・パッチ・ファイルのダウンロードおよび格納手順
バンドル・パッチ・ファイルをホストするマシンで、ダウンロードするプラットフォーム固有のバンドルを保存する一時ディレクトリを作成します。次に例を示します。
Oracle MetaLinkにアクセスし、通常どおりログインします。
https://metalink.oracle.com
Oracle MetaLinkから次のようにします。
「Patches & Updates」タブをクリックします。
「Quick Links to the Latest Patchsets, Mini Packs, and Maintenance Packs」をクリックします。
「Quick Links」ページで、「Patch Sets for Product Bundles」表の「Oracle Oblix COREid」をクリックします。
表示される「Advanced Search」ページで、「Simple Search」ボタンをクリックします。
「Simple Search」ページで、次の詳細が指定されていることを確認します。
Search by: Oracle Oblix COREid Family製品またはファミリ
Release: Oracle Access Manager 10g（10.1.4.0.1）
Patch Type: Patch
Platform or Language: Your_Platform
「Go」ボタンをクリックして結果表を表示します。
「Results」表の「Patch」列で、最新のバンドル・パッチの番号をクリックします。たとえば、7113405です。
「Patch Page」で、「Download」ボタン（一般情報を表示するには「View Readme」ボタン、バンドル名を表示するには「View Digest」ボタン）をクリックします。
ダウンロードしたZIPファイルを格納した一時ディレクトリで、ZIPを解凍してコンポーネント固有のバンドルとLPMChallengeResponsePatch.zipを抽出します。
『Oracle Access Manager Bundle Patch Notes, Bundle Patch 04 for 10g (10.1.4.0.2)』の「Details for Bug 6804657」の使用方法を参照してください。
この項では、サード・パーティの統合に関する問題とその回避方法について説明します。内容は次のとおりです。
Oracle Access Manager 10.1.4 SSPIコネクタでWeblogic Application Serverバージョン9.2を使用すると、ユーザーがエラーを受信する可能性があります。
具体的には、Oracle Access Managerに構成されたポリシーによりアクセス可能なページにアクセスすると、「権限がない」というエラーをユーザーが受信する可能性があります。
Weblogic 9.2にアプリケーションをデプロイする場合は、Webアプリケーションの適切なデプロイメント・ディスクリプタを使用してデプロイしてください。Webアプリケーションのデプロイメント・ディスクリプタはweb.xmlとweblogic.xmlです。また、アプリケーションのデプロイには、EJBアプリケーションのデプロイメント・ディスクリプタを使用してください。EJBアプリケーションのデプロイメント・ディスクリプタはejb-jar.xmlファイルとweblogic-ejb-jar.xmlファイルです。
WebLogic Server SSPIコネクタを構成した後、管理者以外のユーザーが「Deploy」リンクを選択すると、WebLogic Serverコンソールが応答しません。つまり、「Deploy」リンクはロールなしでログインしたユーザーには応答しなくなります。
この問題は、発生する状況が環境によって異なります。
コネクタがRedHat Enterprise Linux AS4.0またはSolaris 10上のWebLogic Serverインスタンスに対してデプロイされている環境では、以前にデプロイされたアプリケーションがない場合に、リンクがロールのないユーザーに応答しません。
コネクタがSolaris 8上のWebLogic Serverインスタンスに対して構成されている場合は、以前にデプロイされていたアプリケーションの有無にかかわらず、リンクは応答に失敗します。
このエラーはまた、WebLogic Serverのバージョンによっても発生状況が多少異なります。WebLogic Server 8.1では、WebLogicコンソールで「User does not have access to this page.」というエラー・メッセージが表示されます。WebLogic Server 9.2では、WebLogicコンソールのエラー・メッセージは表示されません。かわりに、「The page cannot be displayed.」というメッセージが表示されます。
現在のところ、回避方法はありません。
RedHat Enterprise Linux AS4.0またはSolaris 10上のWebLogic Server 9.2に対してWebLogicコンソールを使用している場合、すでに存在するグループを作成しても、WebLogic Serverコンソールでエラー・メッセージが表示されません。エラー・メッセージが表示されないまま、グループ作成ページが表示されます。ただし、例外スタックは生成されます。
現在のところ、回避方法は確認されていません。
WebLogic SSPIコネクタをインストールする際には、言語を選択するよう求められます。日本語、簡体字中国語または繁体字中国語を選択した場合、インストールは一見正常に完了します。しかし、ファイルは正常に抽出されず、選択した言語に対応するディレクトリもinstall_dir/connector/oblix/langに作成されません。
以前にインストールしたコネクタの言語バックを抽出しようとすると、「Oracle Access Manager 10.1.4.0.1アクセス・システムの日本語言語パックをインストールするために、既存のAccessインストール・ディレクトリを指定してください。ディレクトリ名を指定するか、[Enter]を押してください。」というようなエラー・メッセージが表示されます。
さらに、SSPIコネクタのインストール・ディレクトリを指定しようとすると、「このディレクトリは存在しません。有効なOracle Access Managerインストール場所を入力します」というメッセージが表示されます。
言語パックが適切にインストールされ、適切なプロパティ・ファイルが抽出されていないと、configureWebgate、configureAccessGateおよびPolicyDeployerツールは文字を正しく表示できません。
このリリースでは、日本語、簡体字中国語および繁体字中国語の文字は英語の文字に置き換えられます。
『Oracle Access Manager統合ガイド』にある、アクセス・システムとOracleAS Single Sign-On 10.1.2.0.2との統合に関する章は内容が不完全です。このトピックの正しい内容は次のとおりです。
アクセス・システムとOracleAS Single Sign-On 10.1.2.0.2との統合に関する章の手順をすべて実行します。
アクセス・システム・コンソールで、「システム構成」をクリックし、「サーバー設定」をクリックして、次のログアウトURLを構成します。
http://[host.domain]:[port]/pls/orasso/ORASSO.wwsso_app_admin.ls_logout?p_done_url=http%3A%2F%2F[host.domain]%3A[port]
p_done_urlの値をURLエンコードします。
シングル・サインオンのログアウト・リンクの構成に関する詳細は、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。このリリース・ノートの最後に、この目的のために使用できるサンプルJSPが記載されています。
次のサンプルJSPを使用する場合、アクセス・システム・コンソールで「アクセス・システム構成」をクリックし、「AccessGate構成」をクリックして、使用する環境の各WebGateのLogOutURLsパラメータに次の内容を含めます。
/access/oblix/lang/en-us/style2/oblixlogo.gif
次にサンプルlogout.jspファイルを示します。
<!-- Copyright (c) 1999, 2003, Oracle. All rights reserved. -->
<%@page autoFlush="true" session="false"%>
<%
// Declare English Message Strings
String msg1 = "Single Sign-Off";
String msg2 = "Application Name";
String msg3 = "Logout Status";
String msg4 = "ERROR: The return URL value not found.";
String msg5 = "ERROR: Logout URL for partner applications not found.";
// Get the user language preference
String userLocaleParam = null;
java.util.Locale myLocale = null;
// Get the user locale preference sent by the SSO server
try
{
userLocaleParam = request.getParameterValues("locale")[0];
}
catch(Exception e)
{
userLocaleParam = null;
}
if( (userLocaleParam == null) || userLocaleParam.equals("") )
{
myLocale = request.getLocale();
}
else
{
if(userLocaleParam.indexOf("-") > 0 )
{
// SSO server sent the language and territory value (e.g. en-us)
myLocale = new java.util.Locale(userLocaleParam.substring(0, 2),
userLocaleParam.substring(3, 5));
}
else
{
// SSO server sent only the language value (e.g. en)
myLocale = new java.util.Locale(userLocaleParam, "");
}
}
// The following two lines will be used only for the Multilingual support
with
// proper resource bundle class supplied
// java.util.ResourceBundle myMsgBundle
// = java.util.ResourceBundle.getBundle("MyMsgBundleClassName", myLocale);
// Get the message string in the appropriate language using the message key.
// Use this string to display the message in this page.
// String mesg = myMsgBundle.getString("mesg_key");
%>
<html>
<body bgcolor="#FFFFFF">
<h1><%=msg1%></h1>
<%
String done_url = null;
int i = 0;
// Get the return URL value
try
{
done_url = request.getParameterValues("p_done_url")[0];
}
catch(Exception e)
{
done_url = "";
}
// Get the application name and logout URL for each partner application
try
{
%>
<b> <%=msg2%> <%=msg3%> </b>
<br>
// Substitute an actual host, domain, and port for
myhost.us.mydomain.com:7777
// that points to the WebGate.
<img
src="http://myhost.us.mydomain.com:7777/access/oblix/lang/en-us/style2/oblixlo
go.gif">
<%
for(;;)
{
i++;
String app_name = request.getParameterValues("p_app_name"+i)[0];
String url_name = request.getParameterValues("p_app_logout_url"+i)[0];
%>
<%=app_name%>
<img src="<%=url_name%>">
<br>
<%
}
}
catch(Exception e)
{
if(done_url == null)
{
%>
<%=msg4%> <br>
<%
}
if(i>1)
{
%>
<br> <a href="<%=done_url%>">Return</a>
<%
}
else
{
%>
<%=msg5%><br>
<%
}
}
%>
</body>
</html>
NetPointWASRegistryを有効にする前に、registryTesterプログラムを実行して、NetPointWASRegistryが登録されていて、IDシステムに正常に接続できることを確認する必要があります。WAS_install_dirに、registrytesterの実行に必要なファイルが提供されていました。ただし、現在では、このファイルはOracle Access Manager WebSphere用コネクタにバンドルされていません。そのため、Oracle Access Manager Connector for WebSphere 6.1ではregistrytesterを実行できません。
回避方法: WAS_INSTALL_DIR\pluginsにあるcom.ibm.ws.runtime_6.1.0.jarファイルをコピーし、RegistryTester.bat/ RegistryTester.shファイルのクラスパスを適宜設定します。次に例を示します。
set CLASSPATH=.:${CLASSPATH}:${INSTALL_DIR}/oblix/lib/NetPointWASRegistry.jar
:${INSTALL_DIR}/oblix/lib/jobaccess.jar
:${WAS_INSTALL_DIR}/lib/wssec.jar
:${WAS_INSTALL_DIR/lib/sas.jar
:${WAS_INSTALL_DIR}/lib/j2ee.jar
:${WAS_INSTALL_DIR}/java/jre/lib/security.jar
:${WAS_INSTALL_DIR}/java/jre/lib/xml.jar
%WAS_INSTALL_DIR%\plugins\com.ibm.ws.runtime_6.1.0.jar
この項では、ディレクトリの問題および回避方法について説明します。内容は次のとおりです。
Oracle Internet Directoryでは、orcladminユーザー（dn: cn=orcladmin）は管理権限を持つ疑似ユーザーであるとみなされます。Oracle Internet Directoryにはこのユーザーに対応するLDAPエントリがありません。このユーザーは、Oracle Internet Directoryに作成される特殊グループの一部です。Identity Serverでは、各ユーザーは独立したエントリとしてディレクトリ内に存在する必要があります。Group Managerを使用してこれらの特殊グループを表示または変更すると、「この種類のオブジェクトに構成されたプロファイルはありません。」というメッセージが表示されます。
この問題が発生した場合、Oracle Directory Managerアプリケーションを使用してOracle Internet Directoryの特殊グループを表示および更新します。
Oracle Internet Directoryには循環動作を見せる特殊グループもあることに注意してください。このグループの管理には、Group ManagerやIdentity ServerではなくOracle Directory Managerを使用することをお薦めします。
ネイティブ・キャラクタ・セットを使用するOracle Internet DirectoryのあるOracle Access Managerの一部のインストール環境では、メッセージの表示に問題があります。これらの環境でサポートされる言語の一部では、ネイティブ・キャラクタ・セットと互換性のないOracle Access Managerメッセージ・カタログ内のメッセージが適切に表示されません。
Oracle Internet Directoryの言語には、ネイティブ・キャラクタ・セットのかわりにAL32UTF8キャラクタ・セットを使用します。
Novel eDirectory 8.7.3を使用して検索を行うと、属性アクセス制御および検索ベース・フィルタが要求どおりに機能しません。たとえば、次のように、eDirectory 8.7.3を使用してDITの最上位ノードの下に組織単位（OU）を返すようにフィルタを構成できます。
(&(objectclass=*)(!(|(objectclass=oblixconfig)(objectclass=oblixlocation)(objectclass=genSiteOrgPerson)(objectclass=genSiteGroup)))(objectclass=*))
しかし、除外しようとした情報が検索結果として返されます。たとえば、ユーザーが返されます。
この問題を回避するには、eDirectoryパッチ8.7.3.7を適用します。詳細は、次のURLを参照してください。
この項では、ドキュメントとオンライン・ヘルプに関する問題および回避方法について説明します。内容は次のとおりです。
5.9.1項「インストール準備のチェック・リストにOracle Internet Directoryを追加する必要がある」
5.9.5項「Active Directory MaxPageSizeパラメータがPageSizeパラメータとして説明されている」
5.9.12項「Oracle Virtual Directory SSLリスナーの証明書ユーティリティのフラグが正しくない」
5.9.13項「Oracle Access ManagerのOracle Internet Directoryのチューニング」
5.9.14項「Oracle Virtual Directoryのサンプル・アダプタおよびマッピング・テンプレートの取得と更新」
5.9.16項「Oracle Access Manager Configuration Managerのスキーマをアップロードする際に必要なデータベース・ユーザーの権限についての追記」
5.9.21項「『Oracle Access Managerアップグレード・ガイド』のスキーマの索引ファイルのパス名の訂正」
5.9.22項「『Oracle Access Manager Configuration Managerインストレーションおよび管理ガイド』の環境URLの訂正」
5.9.24項「インストレーション・ガイドに、SELinux上のCOREid Webコンポーネントに関する不適切な説明が記載されている」
5.9.25項「『Oracle Access Managerインストレーション・ガイド』のIISでのクライアント証明書の有効化に関する紛らわしいタイトル」
5.9.26項「oblixCoreidServerDownの説明がoblixCoreidServerFailureと同じ」
5.9.28項「ldapreferentialintegrityparams.xmlのunique_value_attrsの説明」
『Oracle Access Managerインストレーション・ガイド』の次のリリースでは、第2章「インストールの準備」の表2-3のインストール準備のチェック・リストにOracle Internet Directoryが追加されます。
アクセス・システムの一部の言語バージョンのオンライン・ヘルプでは、廃止されたWebGateStatic.lstファイルについて次のように説明しています。
WebGateで、ユーザーが「ログアウト」ボタンをクリックしたときにIdentityおよびAccessアプリケーションから確実にログアウトするには、WebGateStatic.lstのLogOutUrlsパラメータをSSOログアウトURLと同じ値に設定します。WebGateStatic.lstは次の場所にあります。
WebGate_install_dir/oblix/apps/Webgate/
リリース10g（10.1.4.0.1）では、WebGateStatic.lstファイルは廃止されました。WebGateStatic.lstで設定していた各種パラメータは、現在、アクセス・システム・コンソールで定義されます。
LogOutURLsパラメータの構成方法を次に示します。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
LogOutUrlsパラメータを設定するには、次のようにします。
アクセス・システム・コンソールを起動して、「アクセス・システム構成」をクリックします。
左側のナビゲーション・ペインで「AccessGate構成」をクリックします。
既存のAccessGatesの検索を行い、変更するAccessGateのリンクをクリックします。
LogOutURLsパラメータを変更します。
『Oracle Access Managerアクセス管理ガイド』の認証の構成に関する章で、obEnableCredentialCacheパラメータが間違ってEnableCredentialCacheと記載されています。
このパラメータを構成する場合、訂正後のobEnableCredentialCacheを使用してください。
『Oracle Access Managerアクセス管理ガイド』に記載されているように、認可スキームは外部ソースからデータを取得できます。このデータはカスタムの認可プラグインに渡されます。外部データを（通常はユーザーに関する情報の形式で）取得することにより、ユーザー入力に基づいて認可の判断が動的に行われます。
たとえば、ユーザーが商品を1000ドルで購入するフォームに進んだ場合、この1000ドルという値が（データベースなどに格納されている）制限値に対して動的に評価され、購入を認可するかどうかが判断されます。
外部ソースから認可データを取得するプロセスは、リバース・アクションとしても知られています。
リバース・アクションを使用する認可プラグインを作成するとき、リバース・アクションが存在しない場合でも、リバース・アクションの取得コールは失敗しません。たとえば、RequestContextにuser-agent値がない場合、次を実行するとリストについてNULLが返されます。
ObASPluginList_t list = pFnBlock->GetDataFn(pInfo->RequestContext, "user-agent");
プラグインは、リバース・アクション（またはその他すべて）について返されるデータ・リストを個々のデータ値の取得に使用する前に、このリストがNULLかどうかをチェックする必要があります。新しいAccess Serverでも、クライアントがリバース・アクションの値を指定しないと、この状況は発生します。
この情報は、認可プラグインAPIドキュメントに追加されます。
『Oracle Access Manager IDおよび共通管理ガイド』の付録Bの「Oracle Access Manager ADSI構成ファイル」の表B-2「adsi_paramsファイルのパラメータと値」内に、次のような2つのpagesizeパラメータの説明があります。
pageSize: サーバーに対するADSIリクエストの結果のページ・サイズ。
pageSize: pageSize値を有限の値（デフォルトは0）に設定するとLDAP参照がオフになる。これにより、クライアント・アプリケーションがディレクトリ検索を実行するときのパフォーマンスが向上する。
訂正: この表の2つ目のpageSizeパラメータはMaxPageSizeパラメータを意味します。
次の情報が、『Oracle Access Managerカスタマイズ・ガイド』に追加されています。また、関連する注意が『Oracle Access Manager IDおよび共通管理ガイド』に追加されています。
パラメータexcludeOCsForTreeInAppletによって、IDシステムに表示しないオブジェクトのオブジェクト・クラスのリストが指定されます。たとえば、リストからグループ・オブジェクト・クラス項目を削除すると、グループ・オブジェクトはIDシステム・アプリケーションに表示されます。
デフォルトでは、IDシステムにはディレクトリのすべてのオブジェクトと属性が表示されません。このパラメータを使用して、デフォルトで非表示になるオブジェクト・クラスをIDシステム・アプリケーションで公開することができます。
『Oracle Access Managerアップグレード・ガイド』では、IDシステムとアクセス・システムのスキーマ・アップグレードを検証する手順で、構成ディレクトリ・サーバーの構成ノードを参照し、obver属性の値が10.1.4.0.1であることを確認するよう説明しています。しかし、実際の値は10.1.4.0です。
次のリリースの『Oracle Access Managerアップグレード・ガイド』では、次の手順は実際の属性値（10.1.4.0）を反映した内容に訂正される予定です。
スキーマに、10g（10.1.4.0.1）の属性obPolicyEnabledとオブジェクト・クラスoblixLPMPolicyが含まれていることを確認します。
構成ディレクトリ・サーバーの構成ノードを参照し、obver属性の値が10.1.4.0になっていることを確認します。
アクセス・システムのスキーマおよびデータのアップグレードを検証する手順
ディレクトリ管理コンソールを使用して、スキーマに、『Oracle Access Managerスキーマ詳細』で定義されているオブジェクト・クラスと属性がすべて含まれていることを確認します。
ディレクトリ管理コンソールを使用して、すべての索引が追加されていることを確認します。
様々なディレクトリ・サーバー・インスタンスがある場合: 次にリストする手順を実行して、スキーマも更新されたことを確認します。
構成ディレクトリ・サーバーの構成ノードを参照し、obver属性の値が10.1.4.0になっていることを確認します。
スキーマに、10g（10.1.4.0.1）の属性obPolicyEnabledとオブジェクト・クラスoblixLPMPolicyが含まれていることを確認します。
『Oracle Access Managerスキーマ詳細』および『Oracle Access Managerアップグレード・ガイド』には、obVer属性に対するシステム動作の変更点が記載されていません。
次のリリースの『Oracle Access Managerスキーマ詳細』には、次の情報が追加される予定です。
oblixConfigクラス: この値は、ロスト・パスワード管理機能でIdentity ServerおよびAccess Serverによって使用されます。
OblixOrgPersonクラス: OblixOrgPersonでの値が10.1.4.0以上の場合、チャレンジ・フレーズ属性とレスポンス属性はエンコードされ、複数の値の間がデリミタ@n#で区切られます。なお、このデリミタで、nはチャレンジまたはレスポンスの番号を示します。
複数のチャレンジ/レスポンス属性に関する詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。以前のリリースからOracle Access Manager 10g（10.1.4.0.1）にアップグレードする際の注意点については、『Oracle Access Managerアップグレード・ガイド』を参照してください。
次のリリースの『Oracle Access Managerアップグレード・ガイド』では、システム動作の概要に関する章に次の情報が追加される予定です。
obVer属性は、現在のOracle Access Managerのリリースを識別するもので、たくさんのOracle Access Managerオブジェクトのクラス定義に含まれるいくつかの属性のうちの1つです。たとえば、obVer属性は、oblixPanel、oblixConfig、oblixLocation、oblixMetaAttribute、oblixEnum、OblixOrgPersonなど（他多数）に含まれます。
リリース10g（10.1.4.0.1）以前は、obVer属性は単に情報を記録するためだけのものでした。しかし、リリース10g（10.1.4.0.1）から、obVer属性は、複数のチャレンジ・フレーズ属性とレスポンス属性をエンコードしてロスト・パスワード管理機能をサポートするために、Identity ServerおよびAccess Serverによって使用されます。この機能では、Oracle Access Manager 10g（10.1.4.0.1）は次のクラスでobVer属性を読み取ります。
oblixConfigクラス: Oracle Access Manager構成データのコンテナ・ノードを定義する構造化クラス。
oblixConfigでは、obVer属性は常に存在し、現在の製品リリースを示します。
OblixOrgPersonクラス: Oracle Access Managerの個人情報を、構造型Personオブジェクト・クラスとして構成されたクラスに関連付けるために使用される補助クラス。次のリリースの『Oracle Access Managerスキーマ詳細』には、次の情報が記載される予定です。
OblixOrgPersonでは、obVerは存在する場合としない場合があります。obVerがユーザー・エントリ内に存在しない場合、値は10.1.4.0より前のものであると考えられます。
Oracle Access Manager 10g（10.1.4.0.1）では、OblixOrgPersonクラスのobVer属性は次のように使用されます。
obVer値が10.1.4.0より古い場合、チャレンジ・フレーズとレスポンスはそれぞれ単一の値を持ち、エンコードは使用されません。次に例を示します。
ChallengeAttribute: what is your name?
ResponseAttribute: xxxxxxxx (encrypted form of Ramakrishna)
obVer値が10.1.4.0以上の場合、チャレンジ・フレーズ属性とレスポンス属性はエンコードされ、複数の値の間がデリミタ@n#で区切られます。なお、このデリミタで、nはチャレンジまたはレスポンスの番号を示します。次に例を示します。
ChallengeAttribute: what is your name?@1#what is your school name?@2#
ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the
name@1#SGschool@2#)
ChallengeAttribute: what is your name?@1#
ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the
name@1#
以前のリリースからOracle Access Manager 10g（10.1.4.0.1）にアップグレードする際、oblixツリーに格納されている構成データは自動的に移行され、obVer属性の値は10.1.4.0に変更されます。ただし、ユーザー・データはアップグレード後の最初のログインまで移行されません。つまり、ユーザー・データ（OblixOrgPersonクラス内）のobVer属性の値は10.1.4.0以前の値のままになります。その場合、ユーザー・データは初回ログイン時に移行され、その際に次の処理が行われます。
既存のチャレンジ・フレーズ値とレスポンス値がエンコードされます（既存の値の末尾に@1#が追加されます）。
ユーザー・データ（OblixOrgPersonクラス）内のobVer属性の値が、oblixツリーのルート・ノードにある、移行後の構成データ（oblixConfig）内のobVer属性の値に設定されます。
|
注意: ユーザーがアップグレード後最初にログインすると、そのユーザーのエントリはただちに移行されます。そのユーザーの既存のチャレンジ値とレスポンス値はすべてエンコード（末尾に@1#が追加）され、obVer属性値は10.1.4.0に変更されます。ただし、以前のリリースにリストアする場合、これらの変更はロールバック・プロセスで元に戻されません。以前のリリースにロールバックした場合、OblixOrgPersonクラスのユーザー・エントリのobVer値は10.1.4.0のままになり、チャレンジ値とレスポンス値はエンコード後の形式のままになります。ロールバックの問題を回避するためにユーザー・データの即時移行（オンザフライ移行）を一時的に停止する方法については、5.4.4項「Oracle Access Manager 10g（10.1.4.0.1）にアップグレードした後のロールバックの問題」を参照してください。 |
『Oracle Access Manager統合ガイド』は、WebLogic 9.2上のWebLogic SSPI用セキュリティ・プロバイダに関して、最新のサポート内容に対応するよう情報を更新する必要があります。更新が必要な箇所は、WebLogic SSPI用セキュリティ・プロバイダとの統合に関する章の、WebLogic環境の準備についての説明です。
リリース10.1.4パッチ・セット1（10.1.4.2.0）とともにリリースされた『Oracle Access Manager統合ガイド』には、次の手順の手順1にある注意と、手順12にあるサブ項目bおよびcへの追加情報が記載される予定です。
次の場所からmbean jarファイルをコピーします。
ファイルのコピー元
install_dir/oblix/lib/mbeantypes
ファイルのコピー先
WebLogic_Home/server/lib/mbeantypes
|
注意: WebLogic 9.2を使用している場合は、wl8NetPointSecurityProviders_Upgraded.jarをコピーします。WebLogic 8.1を使用している場合は、wl8NetPointSecurityProviders.jarをコピーします。WebLogic 7.0 SP2以上を使用している場合は、wl7NetPointSecurityProviders.jarをコピーします。 |
次のファイルをSecurity_Provider_install_dirからWebLogicドメイン・フォルダにコピーします。
NetPointProvidersConfig.properties
NetPointResourceMap.conf: WebLogic Serverドメインの場合のみ
NetPointProvidersConfig.propertiesファイル内に、次のAdmin資格証明がクリアテキストで設定されていることを確認します。
OB_AdminUserName=admin
OB_AdminUserCreds=password
NetPointProvidersConfig.propertiesファイルにクリア・テキストのパスワードがある場合、SSPIはそのパスワードを読み取り、暗号化して、暗号化されたパスワードでpropertiesファイルを書きなおします。
|
注意: Oracle Access Managerが暗号化されたパスワードでNetPointProvidersConfig.propertiesファイルを書きなおすと、このファイルの書式設定は失われます。そのため、NetPointProvidersConfig.propertiesファイルのコピーを保存しておくことをお薦めします。また、すべてのパラメータが、『Oracle Access Manager統合ガイド』に記載されているように適切に指定されていることを確認してください。 |
SSPIがWebGateによって保護されているWebPassと通信する場合は、次の手順を実行します。それ以外の場合は、手順5に進みます。
WebGateによって保護されているWebPass: Oracle Access Manager SSPIがWebGateによって保護されているWebPassと通信する場合は、次の操作を実行します。
NetPointProvidersConfig.propertiesファイルで、OB_WebPassIsProtectedがtrueに設定されていることを確認します。OB_CookiePathパラメータとOB_CookieDomainパラメータが適切に構成されていることを確認します。
アクセス・システム・コンソールから、「アクセス・システム構成」をクリックし、左側のナビゲーション・ペインの「AccessGate構成」をクリックし、WebPassを保護するWebGateのリンクをクリックして、「IPValidation」フィールドで「オフ」オプションを選択します。
Oracle Access Manager 10g（10.1.4.0.1）の場合、WebGateStatic.lstファイルは存在しません。このファイルのオプションはアクセス・システム・コンソールに移行されました。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
|
注意: IPValidationをTrueに設定する場合、IPアドレスを含むようにIPValidationExceptionsパラメータを構成します。 |
Webサーバーを再起動します。
|
注意: この認証スキームのセキュリティ・レベルが、WebLogic認証スキームに指定したレベル以下であることを確認してください。 |
次に、WebPassをホストするマシンがSSLを実行しているかどうかを確認する必要があります。実行している場合は、手順5を実行します。それ以外の場合は、手順6に進みます。
SSL対応のWebPassホスト: WebPassをホストするマシンがSSLを実行しているかどうかを確認します。実行している場合は、次の手順を行います。
NetPointProvidersConfig.propertiesファイルを開き、OB_WebPassSSLEnabled = Trueを設定します。
WebPassをホストしている、またはSSLモードでWebGateを実行しているWebサーバーの登録先である認証局からCA証明書を取得し、ca.cerファイル内に配置します。
JAVA_HOME\binまたはJAVA_HOME\jre\binのkeytoolを使用して、次のCA証明書をcacertsキーストアに追加します。
JAVA_HOME\jre\lib\security folder for weblogic jdk keytool -import -alias ca -file ca.cer -keystore JAVA_HOME\jre\lib\ security\cacerts
サーバーを起動するコマンドの前に、次に示すWebLogic Server起動スクリプトの環境変数を追加します。
次の記述をCLASSPATHに追加します。
/install_dir/oblix/lib/wlNetPoint.jar
/install_dir/oblix/lib/bcprov-jdk14-125.jar
/install_dir/oblix/lib/xerces.jar
/install_dir/oblix/lib/jobaccess.jar
サーバーを起動するコマンドの前に、次に示すWebLogic Server起動スクリプトの環境変数を追加します。
HP-UX: 次の記述をSHLIB_PATHに追加します。
install_dir/oblix/lib
ポータル・ドメイン: CLASSPATH変数とPATH変数は、startWebLogic.shスクリプトのSAVE_JAVA_OPTIONS環境変数のすぐ後に追加してください。
LD_ASSUME_KERNEL環境変数を次のように2.4.19に設定します。
LD_ASSUME_KERNEL=2.4.19 export LD_ASSUME_KERNEL
WebLogicドメイン・ディレクトリからboot.propertiesファイルを削除します。
これにより、次の手順で説明するstartWebLogicスクリプトによってユーザー名とパスワードが要求されます。
WebLogicドメイン・ディレクトリで、適切な起動スクリプトを次のように編集します。
UNIX: startWeblogic.shスクリプト
スクリプトに次のパスが設定されていることを確認します。
/install_dir/oblix/lib/wlNetPoint.jar
/install_dir/oblix/lib/bcprov-jdk14-125.jar
/install_dir/oblix/lib/xerces.jar
/install_dir/oblix/lib/jobaccess.jar
WebLogicドメイン・ディレクトリで、適切な起動スクリプトを使用してWebLogic Serverを起動します。
UNIX: startWeblogic.shコマンド
WebLogic 8.1 Domain Configuration Wizardを使用すると、新しいWebLogic 8.1ドメインのインスタンス（mydomainなど）と新しいWebLogic 8.1サーバーのインスタンス（myserverなど）を作成できます。新しいWebLogic 8.1.3のポータル・ドメインのインスタンス（portalDomainなど）と新しいWebLogic 8.1.3のポータル・サーバーのインスタンス（portalServerなど）も作成できます。
Oracle Access Managerセキュリティ・プロバイダを使用するレルムを次のように設定します。
Weblogic環境を設定します。
UNIX: サーバー・ドメイン・ディレクトリにあるsetEnv.shスクリプトを使用します。
ポータル・ドメイン: setDomainEnv.shスクリプトを使用します。
次のスクリプトを実行し、ユーザー名、パスワードおよびURLの値が正しいことを確認します。
UNIX: install_dir/setupNetPointRealm.sh
|
注意: WebLogic SSPIのWebおよびEJBアプリケーション用のロールに基づくポリシーを使用するには、setupNetPointRealmツールをsspi_roleパラメータを使用して実行します。
次に例を示します。
install_dir/setupNetPointRealm.sh sspi_role
|
ポータル・ドメイン: パラメータ"portal"を使用してスクリプトを実行します。
WebLogic Server 7.0: スクリプトが機能しないので、NetPointRealmを手動で設定する必要があります。
UNIX上のWebLogic Application Server 9.2: install_dir/setupNetPointRealm.propertiesファイルでdomName変数を設定します。その後、install_dir/setupNetPointRealm_wl92.shスクリプトを実行します。
WebLogic管理コンソールにログインし、「Domain」、「Security」、「Realms」の順に移動して、次の操作を行います。
NetPointRealmがデフォルトとして設定されていることを確認します。
NetPointRealmでセキュリティ・プロバイダが適切に設定されていることを確認します。
WebLogic Server 9.2の場合、次の手順を実行します。
WebLogic管理コンソールで「Lock and Edit」をクリックします。
「NetpointRealm」、「Providers」、「Certification Path」、「WebLogicCertPathProvider」の順に移動します。移動したら「Current Builder」オプションを選択し、WebLogicCertPathProviderを現在のビルダーとして指定します。「Activate Changes」をクリックしてすべての変更をアクティブにします。
NetPointRealmをデフォルトのレルムとして設定します。
まず左側のペインで、使用するドメインを選択し、ドメインの「Settings」ページを開きます。次に「Security」タブをクリックします。さらに「General」をクリックします。ここで、デフォルトのセキュリティ・レルムとして「NetPointRealm」を選択します。その後「Save」をクリックします。「Activate Changes」をクリックしてすべての変更をアクティブにします。
スクリプトの失敗: スクリプトが失敗した場合は、Oracle Access Managerのセキュリティ・レルム（NetPointRealm）を次のように手動で追加する必要があります。
「Domain」、「Security」、「Realms」の順に移動し、「Configure a new Realm」を選択します。
「Check Roles and Policies for」オプションに対して、「All Web Applications and EJBs」が選択されていることを確認します。
「Providers」、「Authentication」の順に移動し、新しいAuthenticatorとIdentity Asserterを構成します。
Identity Asserter: トークン・タイプObSSOCookieを選択し、「Details」タブで「Base64Decoding Required」の選択を解除します。
ポータル・ドメイン: Authenticatorの制御フラグをOPTIONALに設定し、Default Authenticatorも構成します。
「Providers」、「Authorization」の順に移動し、新しいAuthorizerを構成します（ポータル・ドメインの場合は、Default Authorizerのみを構成します）。
ロール・ベースのポリシーの場合は、Default Authorization Providerも構成する必要があります。「Providers」、「Authorization」の順に移動し、「Default Authorization Provider」を構成します。
ロール・ベースのポリシーの場合は、「Providers」、「Adjudication」の順に移動し、新しいAdjudication Providerを構成します。
「Providers」、「Role Mapping」の順に移動し、新しいRole mapperを構成します（ポータル・ドメインの場合は、Default Role mapperのみを構成します）。
「Providers」、「Credential Mapping」の順に移動し、新しい「Default Credential mapper」を構成します。
「Domain」、「Security」の順に移動し、このレルムをデフォルトのレルムとして選択します。
ポータル・サーバー・ドメイン: 次の手順を実行してWebLogic Portalドメインを構成します。
前に使用したものと同じWebLogic資格証明を使用してサーバーを再起動します。
WebLogic Serverコンソールで、「Domain」、「Security」、「Realms」、「NetPointRealm」、「Providers」、「Authentication」の順に移動し、次の操作を行います。
Default Authenticatorを削除します。
Authenticatorの制御フラグをREQUIREDに変更します。
Group Managerを使用して、BEA WebLogic ServerのAdminロールにマップされた、BEA Portalのすべての管理者を含むグループをOracle Access Managerに作成します。
次に例を示します。
BEA_Administrators
ユーザー（portaladmin）を作成してBEA_Administratorsグループに追加します。後でサーバーを再起動するときに、このユーザー（portaladmin）としてログインします。
WebLogic Serverコンソールの管理コンソールで、「Security」、「Realms」、「NetPointRealm」の順に移動し、次の操作を実行します。
「Groups」をクリックして、すべてのOracle Access Managerグループを表示します。
この手順で作成したBEA Adminグループを検索します。検索には、ワイルド・カードを使用できます。
グループの名前をコピーします。
「Global Roles」、「Admin role」、「Conditions」タブの順にクリックして次の操作を行います。
「Caller is a member of the group」を指定したロール条件を追加します。
コピーしたグループ名を貼り付けます。
ロール条件をandからorに変更し、「Apply」をクリックします。
PortalSystemAdministratorロールに対して、この手順を繰り返します。
|
注意: Oracle Access Managerのグループやユーザーにマップできるロールには、これ以外のBEAロールもあります。WebLogic Serverを再起動する際には、BEA Adminロールに関連付けられたOracle Access Managerグループのユーザーとしてログインしていることを確認してください。 |
WebLogic Serverを再起動します。
次回WebLogicコンソールにログインする際には、マスターOracle Access Manager管理者の資格証明を入力します。その際、認証にはNetPointRealmが使用されます。
Webアプリケーションを保護する認証メカニズムとしてIDアサーションを使用している場合は、次の手順を実行します。
プロキシWebサーバーにWebGateをインストールします。このタイプのインストールの図は、『Oracle Access Manager統合ガイド』を参照してください。
Webアプリケーションを保護するOracle Access Managerポリシーを構成して、wl_urlではなくHTTPをリソース・タイプとして使用するように指定します。
|
注意: リソース・タイプの構成には1つ例外があります。WebLogic管理コンソールでは、必ずフォーム・ログインが使用されます。そのため、/consoleポリシーにはリソース・タイプwl_urlを使用する必要があります。 |
Oracle Access Managerのフォーム・ベース認証スキーム以外に、HTTPリソース・タイプで構成されたポリシーを保護するスキームがある場合は、WebGateがインストールされている別のWebサーバーにユーザーをリダイレクトするためのチャレンジ・リダイレクト・パラメータを構成します。
|
注意: この手順を実行しなかった場合、ユーザーが目的のページにアクセスするためにはブラウザのリフレッシュが必要になります。これは、WebGateによってHTTPリクエストに設定されたObSSOCookieが、まだWebLogicサーバーに送信されていないためです。 |
必要に応じて、『Oracle Access Manager統合ガイド』の後続の手順に進みます。
表5-1に示すように、『Oracle Access Managerインストレーション・ガイド』には、コンポーネントのデフォルト・パス名の記述に誤りがあります。
表5-1 デフォルトのインストール・パス名の誤り
| コンポーネント | インストール・ディレクトリ |
|---|---|
|
Identity Server |
Windows: UNIX: このガイド: |
|
WebPass |
Windows: UNIX: このガイド: |
|
Access Server |
Windows: UNIX: このガイド: |
|
Policy Manager |
Windows: UNIX: このガイド: |
|
WebGate |
Windows: UNIX: このガイド: |
このマニュアルの次のリリース（リリース10.1.4パッチ・セット1（10.1.4.2.0））では、表5-2に示すようにパス名が訂正されます。
表5-2 正しいデフォルトのインストール・パス名
| コンポーネント | インストール・ディレクトリ |
|---|---|
|
Identity Server |
Windows: UNIX: このガイド: |
|
WebPass |
Windows: UNIX: このガイド: |
|
Access Server |
Windows: UNIX: このガイド: |
|
Policy Manager |
Windows: UNIX: このガイド: |
|
WebGate |
デフォルトのWebGateインストール・ディレクトリ・パス名は、プラットフォームおよびWebサーバーのタイプに応じて異なります。次に例を示します。 Win32 ISAPI WebGate: Win32 OHS2 WebGate: Win32 NSAPI WebGate: Linux Apache2 WebGate: Linux OHS2 WebGates: このガイド: |
『Oracle Access Managerインストレーション・ガイド』の「アイデンティティ・サーバーのインストール」で、Identity Serverのインストールの終了手順に関する記述の手順6に、デフォルトでIdentity ServerとAccess Serverのサービスが手動で起動されるように設定されているという誤った記述があります。
Windows: 「サービス」ウィンドウを開き、Identity Serverサービスを見つけて起動します。
デフォルトでは、Identity Server（Oracle Identity Server（OIS））は手動で起動しますが、起動タイプを「自動」に設定できます。詳細は、Microsoft Windowsのヘルプを参照してください。
UNIX: 次のコマンドを実行します。
/IdentityServer_install_dir/identity/oblix/apps/common/bin/start_ois_server
リリース10.1.4パッチ・セット1（10.1.4.2.0）で提供される『Oracle Access Managerインストレーション・ガイド』ではこの記述が訂正されて、手順6の情報が次のように更新されます。
Windows: 「サービス」ウィンドウを開き、Identity Serverサービスが起動していることを確認します。
デフォルトでは、Identity Server（Oracle Identity Server（OIS）とも呼ばれる）は自動的に起動されます。デフォルトを変更して手動で起動するには、Microsoft Windowsのヘルプを参照してください。
UNIX: 次のコマンドを実行してIdentity Serverサービスを起動します。
/IdentityServer_install_dir/identity/oblix/apps/common/bin/start_ois_server
また、「アクセス・サーバーのインストール」のAccess Serverのインストールの終了手順に記載された類似の情報も訂正されました。
『Oracle Access Managerインストレーション・ガイド』の「Oracle Virtual Directoryを使用したOracle Access Managerの設定」に、Oracle Virtual Directory SSLリスナーを構成する手順が記載されています。この手順の手順8に記載されたコマンドライン構文に誤りがあります。
構文の行の誤りは次のように変更され、明確に説明するために新しい注意書きが追加されます。
8. 次のコマンドを使用してルートCAをIdentity Serverにインポートします。
certutil -d IdentityServer_install_dir\identity\oblix\config -A -n ldap -a -t "C,," -i root_ca_file
|
注意: certutilコマンドの-t（トラステッド引数）フラグの後に、証明書に割り当てるトラスト属性を二重引用符で囲んで指定する必要があります。 |
『Oracle Access Managerインストレーション・ガイド』では、ldapmodifyコマンドを使用してOracle Internet Directoryをチューニングする方法を説明しています。ただし、Identity Serverのインストールに関する章で説明しているようにldapmodifyコマンドを使用してOracle Internet Directory 10.1.2（またはそれ以前）をチューニングすると、次のエラー・メッセージが表示されます。
"Attribute orclinmemfiltprocess is not supported in schema."
orclinmemfiltprocess属性は、Oracle Internet Directory 10.1.4以降のスキーマでサポートされるようになりました。そのため、ldapmodifyコマンドを使用してOracle Internet Directoryをチューニングできません。
『Oracle Access Managerインストレーション・ガイド』の次のリリースで、これを明確に説明する予定です。
『Oracle Access Managerインストレーション・ガイド』のOracle Virtual DirectoryとOracle Access Managerの統合に関する章で、オラクル社提供のサンプル・アダプタおよびマッピング・テンプレート・ファイルがDNConversionToolkit内にあり、記載された手順を使用してこれらを取得し、Oracle Virtual Directory Managerに格納する必要があると説明しています。
ただし、Oracle Virtual Directory 10.1.4以上では、Oracle Access Managerのテンプレートとマッピングがすぐに使用できる状態でOracle Virtual Directory Managerに提供されています。これらのサンプル・アダプタ・テンプレートは、Oracle Virtual Directory Managerのアダプタ・テンプレート・リストに自動的に表示されます。
次のリリースの『Oracle Access Managerインストレーション・ガイド』には、次の情報が記載される予定です。
Oracle Virtual Directory 10.1.4以上では、Oracle Access Managerのテンプレートとマッピングがすぐに使用できる状態でOracle Virtual Directory Managerに提供されています。使用するOracle Virtual Directoryリリースに応じて、次のように進みます。
Oracle Virtual Directory 10.1.4以上を使用する場合は、このサンプル・アダプタおよびマッピング・テンプレートの取得と更新に関する項をスキップし、使用する環境に適用可能な次のトピックに進みます。アダプタおよびマッピング・テンプレートの使用方法は、この章で後述します。
Oracle Virtual Directory 10.1.4より前のリリースを使用する場合、またはOracle Access Manager配布のサンプル・アダプタおよびマッピング・テンプレートを使用する場合は、このトピックの説明および手順を続行してください。
『Oracle Access Managerアクセス管理ガイド』のトラブルシューティングの章で、「ログイン・フォームが繰り返し表示される」の解決策に誤字があります。これは次のリリースの『Oracle Access Managerアクセス管理ガイド』で訂正される予定です。
正しくない: ユーザーのセッションが有効かどうかを検証するには、ブラウザのURL用フィールドに次のように入力します。
javascript:altert(document.cookie)
正しい: ユーザーのセッションが有効かどうかを検証するには、ブラウザのURL用フィールドに次のように入力します。
javascript:alert(document.cookie)
『Oracle Access Manager Configuration Managerインストレーションおよび管理ガイド』には、リポジトリの詳細を追加した後、Oracle Access Manager Configuration Managerのスキーマをアップロードする際に必要なデータベース・ユーザーの権限が記載されていません。
この問題については、リリース10.1.4パッチ・セット1（10.1.4.2.0）で提供されるリリース10.1.4.2.0のマニュアルに、次の説明が追記される予定です。
スキーマのアップロード・ボタンは、Oracle DatabaseリポジトリにOracle Access Manager Configuration Managerスキーマが存在しない場合にのみ表示されます。スキーマを正常にアップロードするには、表の作成、順序の作成、トリガーの作成およびプロシージャの作成のシステム権限がデータベース・ユーザーに必要です。
リリース10.1.4パッチ・セット1（10.1.4.2.0）で入手できるリリース10.1.4.2.0の『Oracle Access Managerアップグレード・ガイド』に、新しい説明が追加されました。次の新しい手順では、複数のIdentity Serverをアップグレードした後、監査ファイルのパス名を変更する方法について説明しています。
7.0より前のリリースからIdentity Serverをアップグレードした後、このタスクを実行して監査ファイルのパス名を修正する必要があります。リリース7.xからのアップグレードの場合は、この操作をスキップできます。
700より前のリリースから、マスターIdentity Server、スキーマおよびデータをアップグレードすると、監査ファイル名の接頭辞にマスターIdentity Serverのパスが付加されます。
複数のIdentity Serverを含むデプロイでは、各監査ファイル名の接頭辞に、データのアップグレードを実行する元のIdentity Serverと同じIdentity Serverインストール・ディレクトリ・パスが付加されます。その結果、Identity Serverのアップグレード中に元の構成が失われます。たとえば、2つのIdentity Serverインスタンスの監査ファイルが次のように格納されている場合があります。
D:\611\ois_one\identity\oblix\engine\auditfile_1.lstD:\611\ois_two\identity\oblix\engine\auditfile_2.lstアップグレード後、この2つの監査ファイルは、マスターIdentity Serverのディレクトリ・パス（611\ois_one）に格納されます。次に例を示します。
D:\611\ois_one\identity\oblix\engine\auditfile_1.lstD:\611\ois_one\identity\oblix\engine\auditfile_2.lst複数のIdentity Serverをアップグレードした後、監査ファイルをリカバリするには、次のタスクを実行して監査ファイルのパスを変更し、特定のIdentity Serverインスタンスの適切なパスを指定する必要があります。
Identity Serverのアップグレード後に元の監査ファイルをリカバリする手順
IDシステム・コンソールに移動し、通常どおりログインします。
http://hostname:port/identity/oblix
ここで、hostnameにはWebサーバーをホストするマシンの名前を、portにはWebPass Webサーバー・インスタンスのHTTPポート番号を指定します。/identity/oblixはIDシステム・コンソールに接続する働きをします。
IDシステム・コンソールで、「システム構成」をクリックし、「Identity Server」をクリックします。
アップグレードしたIdentity Serverの名前を選択して、このインスタンスの情報を表示します。
「監査ファイル名」フィールドで、パス名が正しいかどうかを確認します。
パス名が正しい場合は、「取消」をクリックし、手順3と4を繰り返して別のインスタンスの監査ファイルのパス名を確認します。パス名が正しくない場合は、手順5に進みます。
ページの下部にある「変更」ボタンをクリックします。
「変更」ページで、「監査ファイル名」フィールドのパス名をこのインスタンスの正しいパスに変更し、「保存」をクリックします。次に例を示します。
D:\611\ois_one\identity\oblix\engine\auditfile_2.lstD:\611\ois_two\identity\oblix\engine\auditfile_2.lst詳細が更新されたIdentity Serverを再起動します。
アップグレードしたIdentity Serverインスタンスごとに、このすべての手順を繰り返します。
『Oracle Access Managerインストレーション・ガイド』のディレクトリ・スキーマの拡張についての説明では、vde_user_schema_add.ldifファイルとaduserschema.ldifファイルの場所をIdentityServer_install_dir\identity\oblix\tools\DNConversionToolkit\tools\DataAnyWhere\OblixUserSchemaとして示しています。DNConversionToolkitは、リリース10g（10.1.4.0.1）で提供されました。ただし、次の場所も提供されており、リリース10.1.4パッチ・セット1（10.1.4.2.0）で入手できるリリース10.1.4.2.0の『Oracle Access Managerインストレーション・ガイド』に記載されます。
IdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\OblixUserSchema\vde_user_schema_add.ldifIdentityServer_install_dir\identity\oblix\tools\DataAnyWhere\OblixUserSchema\aduser_schema.ldif『Oracle Access Managerインストレーション・ガイド』のディレクトリ・スキーマの拡張についての説明で、ldapmodifyコマンド構文のVDE_user_schema_add.ldifファイル名が省略されています。現在、マニュアルには次の構文が示されています。
ldapmodify -h host -p port -D bind-dn -w password -a -f
この構文は、リリース10.1.4パッチ・セット1（10.1.4.2.0）で入手できるリリース10.1.4.2.0の『Oracle Access Managerインストレーション・ガイド』で、次のように訂正されます。
ldapmodify -h host -p port -D bind-dn -w password -a -f VDE_user_schema_add.ldif
『Oracle Access Managerアップグレード・ガイド』では、マスターAccess Managerコンポーネントをインストールし、スキーマとデータのアップグレードに使用する場合、ディレクトリ・サーバーとの通信にSSL対応の通信が必要になる場合があることを説明していません。
リリース10.1.4パッチ・セット1（10.1.4.2.0）で入手できるリリース10.1.4.2.0の『Oracle Access Managerアップグレード・ガイド』のスキーマとデータのアップグレード準備に関する章に、次の情報が追加されます。
元のAccess Managerコンポーネントがディレクトリ・サーバーとの通信にSSL対応の通信を使用するように構成されている場合は、追加するマスターもディレクトリとの通信にSSL対応の通信を使用するように構成する必要があります。
リリース10.1.4パッチ・セット1（10.1.4.2.0）で入手できるリリース10.1.4.2.0の『Oracle Access Managerアップグレード・ガイド』に、データ・アクセス問題のトラブルシューティングに役立つ次の情報が追加されます。
スキーマおよびデータのアップグレード後に「<person>オブジェクト・クラスが見つかりません」というエラーを受け取った場合、スキーマおよびデータのアップグレードに使用したマスターAccess Managerコンポーネントが、元のコンポーネントと同じトランスポート・セキュリティを使用しなかったことに問題がある可能性があります。元のAccess Managerコンポーネントがディレクトリ・サーバーとの通信にSSL対応の通信を使用するように構成されている場合は、追加するマスターもディレクトリとの通信にSSL対応の通信を使用するように構成する必要があります。
『Oracle Access Managerアップグレード・ガイド』には、データの移行後、Sun（以前のiPlanet）ディレクトリ、Novell eDirectory（NDS）およびOracle Internet Directoryのスキーマの索引ファイルをアップロードするとき、正しくないパスが記載されています。これはリリース10.1.4パッチ・セット1（10.1.4.2.0）で入手できる10.1.4.2.0の『Oracle Access Managerアップグレード・ガイド』の「ディレクトリ・サーバーの索引ファイルのアップロード」で訂正されます。
訂正後のパスを次に示します。
IdentityServer_install_dir/identity/oblix/data.ldap/common
PolicyManager_install_dir/access/oblix/data.ldap/common
『Oracle Access Manager Configuration Managerインストレーションおよび管理ガイド』の構成データの変更の移行に関する章で、環境URLの説明が正しくありません。ここに記載されたとおり変更されました。
訂正前の説明
環境の追加ページには、LDAPディレクトリ環境について、環境の名前、オプションの説明、ホスト名とポート、構成DN、ユーザーDN、パスワード、URLなど、他の情報を入力するフィールドが表示されます。環境の名前および説明を定義する際には、英数字の大/小文字の組合せの他、空白文字と句読点を使用できます。
環境の追加ページには、この環境に関連するOracle Access Managerのデプロイについて、環境の名前、オプションの説明、ホスト名とポート、構成DN、ユーザーDN、パスワード、URL（オプション）など、他の情報を入力するフィールドが表示されます。環境の名前および説明を定義する際には、英数字の大/小文字の組合せの他、空白文字と句読点を使用できます。
環境URL: LDAPディレクトリへのURL。次に例を示します。
http://141.144.74.35:3333/access/oblix/
訂正後の説明
環境の追加ページには、この環境に関連するOracle Access Managerのデプロイについて、環境の名前、オプションの説明、ホスト名とポート、構成DN、ユーザーDN、パスワード、URL（オプション）など、他の情報を入力するフィールドが表示されます。環境の名前および説明を定義する際には、英数字の大/小文字の組合せの他、空白文字と句読点を使用できます。
環境URL: この環境に関連するOracle Access ManagerのデプロイへのURL。次に例を示します。
http://141.144.74.35:3333/access/oblix/
realmunique:yesの欠落Oracle Access ManagerとOracle SSOを統合し、Oracle SSOからのグローバル・ログアウトを実装した後、ObSSOCookie Cookieがログアウトにより削除されません。ユーザーがログアウトをクリックして保護されたURLに戻ろうとしても、ユーザーはログインされたままです。
Basic over LDAP認証を使用する場合、ブラウザはタイムアウト後にキャッシュされた資格証明を返します。この問題を修正するため、Oracle COREid 7.0.4.2で新しいチャレンジ・パラメータrealmunique:yesが導入されました。ただし、この情報は、最新のマニュアルに記載されていません。
『Oracle Access Manager統合ガイド』の今後のリリースに、新しい情報が記載されます。
|
関連項目: Oracle MetaLinkのNote: 443493.1 |
Oracle MetaLinkのNote 443493.1にアクセスする手順
OracleMetaLinkにアクセスし、通常どおりログインします。
https://metalink.oracle.com
Oracle MetaLinkで次の手順を実行します。
「Quick Find」リストで「Knowledge Base」を選択します。
右側のフィールドに443493.1と入力し、「Go」をクリックします。
結果ページでタイトル「After Integration of Oracle Access Manager and Oracle SSO Logout Does Not Rem...」をクリックします。
記事を読みます。
問題
「Oracle Access ManagerのポリシーをRed Hat Enterprise Linux 4バンドルのApacheに追加する手順」の手順4および手順5に、次のような不適切な記載があります。
手順4で次のテキストが2行に示されています。
Oracle_Access_Manager_install_dir(/.*)? system_u:object_r:oracle_access_manager_t
これは、1行に示される必要があります。
Oracle_Access_Manager_install_dir(/.*)? system_u:object_r:oracle_access_manager_t
手順5に「run make load」と記載されています。
cd $SELINUX_SRC run make load ...
これは、「make load」とのみ記載される必要があります。
cd $SELINUX_SRC make load ...
解決策
このマニュアルの次のリリース（10.1.4.3.0）で修正されます。
『Oracle Access Managerインストレーション・ガイド』の第9章「WebGateのインストール」に誤解を招くおそれのあるタイトルがあります。
不適切なタイトル
IIS Webサーバー上のSSLの有効化
このマニュアルの10.1.4.3.0で正しいタイトルになります。この情報は、別の章である第19章「IIS Webサーバーを使用するWebコンポーネントのインストール」に移動しました。
正しいタイトル
IIS Webサーバーでのクライアント証明書の有効化
『Oracle Access Manager IDおよび共通管理ガイド』の「SNMPモニタリング」でOBLIXCOREIDSERVERDOWNとOBLIXCOREIDSERVERFAILUREの両方に同じ説明があります。
不適切な表現
oblixCoreidServerDown
アイデンティティ・サーバーの停止（の可能性）がSNMPエージェントにより検出された場合に生成されるトラップ。このトラップには、サーバーID、ホスト名およびポートが含まれます。
oblixCoreidServerFailure
このトラップは、アイデンティティ・サーバーに障害が発生したことがSNMPエージェントにより検出された場合に生成されます。このトラップには、サーバーID、ホスト名およびポートが含まれます。
正しい表現
oblixCoreidServerDown
アイデンティティ・サーバーの停止（の可能性）がSNMPエージェントにより検出された場合に生成されるトラップ。このトラップには、サーバーID、ホスト名およびポートが含まれます。
oblixCoreidServerFailure
このトラップは、アイデンティティ・サーバーに障害が発生したことがSNMPエージェントにより検出された場合に生成されます。このトラップには、サーバーID、ホスト名およびポートが含まれます。
『Oracle Access Managerカスタマイズ・ガイド』の「各XSLスタイルシートとともに使用するアイデンティティ・システムXMLファイルをインポートする手順」の手順2の構文エラーが修正されました。$format=xmlnoxsyは、&format=xmlnoxslになっています。
この情報は、10g（10.1.4.3）のこのマニュアルに記載されます。
unique_value_attrsの説明『Oracle Access Managerカスタマイズ・ガイド』のldapreferentialintegrityparams.xmlに関する表で、unique_value_attrsの説明に次の情報が不足しています。
注意: Oracle Access Managerでは、「ログイン」セマンティク型の属性にのみ一意性が適用されます。このため、uid属性またはsamaccountname属性に一意性が適用されます。
unique_value_attrsパラメータは、LDAP参照整合性を適用するOracle Access Managerのコンテキストでのみ使用されます。一部の参照整合性では、更新されたDNを持つ同じエントリをOracle Access Managerで削除して追加する必要があります。このような場合、削除をまず行う必要があるかがunique_value_attrsで識別されます。
この情報は、10g（10.1.4.3）のこのマニュアルに記載されます。
『Oracle Access Managerデプロイメント・ガイド』の移行に関する章に、次の手順を追加する必要があります。COREid ServerとWebPassを再構成する手順の新しい手順4によって、ディレクトリのエントリの削除後にCOREid Serverが必ず再起動されます。
4. 次のファイル・システム・ディレクトリ・パスからsetup_oisを見つけ、実行します。
./start_setup_ois -i IdentityServer_install_dir/identity/
この情報は、10g（10.1.4.3）のこのマニュアルに記載されます。
『Oracle COREid Access and Identity Installation Guide』にNovell eDirectoryスキーマの更新に関する情報が不足しています。次の情報が、10g（10.1.4.3）のこのマニュアルに記載されます。
Novell eDirectoryの詳細
デフォルトでは、ブラウザベースのIDシステムの設定時にドメイン・ノード（dc=us、dc=oracle、dc=comなど）下にoblixノード（o=oblix,<config-dn>）を作成することは、Novell eDirectoryのOracleスキーマではサポートされません。つまり、ブラウザベースのIDシステムの設定時に、構成ベースとしてドメイン・ノードを使用できません。トラブルシューティングの章の「Novell eDirectory Issues」に回避方法が記載されています。
Novell eDirectoryでのブラウザベースのIDシステムの設定で検索ベースを"dc=nc"に設定する場合、"o=Oblix"（oblixconfig）オブジェクトクラスを含めるCONTAINMENTオブジェクトを定義する必要があります。eDirectoryのスキーマ内で、domainを有効なCONTAINMENTオブジェクトとしてoblixconfigオブジェクトクラスに含めることができます。
回避方法
次の回避方法が、10.1.4.3の『Oracle Access Managerインストレーション・ガイド』の「トラブルシューティング」に記載されます。
Identity Serverのインストール時、ディレクトリ・サーバー・スキーマを拡張するかどうかが尋ねられます。ここで、Identity Serverのインストール・ディレクトリに移動してNDS_oblix_schema_add.ldifファイルを検索します。次の手順を使用して、このオブジェクトクラスのCONTAINMENTにdomainが含まれるようファイル・エディタで編集します。
Identity Serverのインストール時にディレクトリ・スキーマを拡張するかどうかを尋ねられたら、NDS_oblix_schema_add.ldifファイルを見つけます。
IdentityServer_install_dir\identity\oblix\data.ldap\common\'NDS_oblix_schema_
add.ldif
エディタでNDS_oblix_schema_add.ldifを開き、oblixconfigオブジェクトクラスを見つけます。ここに、このオブジェクトクラスのCONTAINMENTも定義されています。次に例を示します。
dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.3831.0.1.2 NAME 'oblixconfig' SUP top STRUCTURAL MUST ( obpersonoc $ obsearchbase $ organizationName ) MAY ( obsearchbasestr $ obgroupoc $ ………………………………..$ obver $ obduplicateAction ) X-NDS_NAMING ( 'O' ) X-NDS_CONTAINMENT ( 'organization' 'organizationalUnit' 'country' 'locality' ) )
このエントリを変更して、domainをoblixconfigオブジェクトクラスのCONTAINMENTクラスの1つに指定します。次に例を示します。
dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.3831.0.1.2 NAME 'oblixconfig' SUP top STRUCTURAL MUST ( obpersonoc $ obsearchbase $ organizationName ) MAY ( obsearchbasestr $ obgroupoc $ ………………………………..$ obver $ obduplicateAction ) X-NDS_NAMING ( 'O' ) X-NDS_CONTAINMENT ( 'domain' 'organization' 'organizationalUnit' 'country' 'locality' ) )
変更したスキーマ・ファイルを保存し、インストールとブラウザベースの設定を続けます。
『Oracle Access Manager統合ガイド』のWebLogicの章の「統合アーキテクチャ」で、次の注意が欠落しています。
フォームベースの認証では、Oracle Access ManagerとWebLogicアプリケーションとの間のSSOが可能です。ただし、Basic Over LDAP認証ではSSOは提供されません。
前述の段落が、10g（10.1.4.3）のこのマニュアルに記載されます。
Oracle Access Managerのマニュアルでは、新機能の章に製品名の変更の表が記載されています。この章に、「アクセス・システム・サービス」（アクセス・システム・コンソール・ページのAMサービスの状態）が「ポリシー・マネージャAPIサポート・モード」に変更されたと誤って記載されています。「アクセス・システム・サービス」は実際には「アクセス管理サービス」に変更されました。Oracle Access Manager 10g（10.1.4.3）のすべてのマニュアルの新機能の章に、次の修正が記載されます。
『Oracle Access Managerアクセス管理ガイド』の「WebGateおよびアクセス・サーバーの構成」も次のように修正されています。
アクセス・サーバー構成パラメータの表
アクセス・ゲート構成パラメータの表
URLパターンは、1つのポリシーで保護されている特定タイプの異なるリソースを識別するために、アクセス・システムでサポートされているメカニズムです。次の属性のパターンは無効です。
]と対になっていない[
}と対になっていない{
{}内のエスケープされていない{
[ ]内のエスケープされていない/
次の情報が、『Oracle Access Managerアクセス管理ガイド』の「ポリシー・ドメインによるリソースの保護」の「無効なパターン」に追加されました。
{}の内部にある場合、次のURLパターンは認識されません。
{pattern_1, pattern_2, /.../cleanup.asp}
{}を使用していない場合のみ、URLパターンは認識されます。
/.../cleanup.asp
{}内部のURLパターンには、次のような単純な式を想定しています。
a{ab,bc}bは、aabbおよびabcbに一致します。
a{x*y,y?x}bは、axyb、axabayb、ayaxbなどに一致します。
[]内部のURLパターンには、/で始まる複雑なサブ式を含めることはできません。次に例を示します。
[/.../cleanup.asp OR /c*/webservice/webservice.asp]
かわりに、3つの異なるポリシーを作成することを検討します。
??/admin/* /c*/webservice/webservice.asp /.../cleanup.asp
