| Oracle Access Managerアクセス管理ガイド 10g（10.1.4.3） B55477-01 |
|
 戻る |
 次へ |
この付録では、Oracle Access Managerの実行中またはインストール中に発生する可能性のある一般的な問題について説明します。この付録は次の項から構成されます。
この項では、Oracle Access Managerの一般的なエラー・メッセージ、原因および解決策について説明します。内容は次のとおりです。
この項では、次の問題について説明します。
Microsoft Windows 2003で、アクセス・サーバーへのキャッシュ・フラッシュがあるアクセス・サーバーまたはアイデンティティ・サーバーがハングします。この問題は、Microsoft Windows 2003のセキュリティ上の変更により、アクセス・サーバーに送信されるキュー（Q）パラメータが反映されないために発生します。キューの数を設定できないと、アクセス・サーバーの使用可能なスレッド数が不足します。
リクエストは、アクセス・サーバーに送信されるとキューに登録されます。各リクエストは1つのスレッドで処理されます。たとえば、現在2つのリクエスト・キューと60のスレッドがある場合には、アクセス・サーバーにより120のスレッドが生成されます。アクセス・サーバーに対して作成されるスレッド・セットの数は、キューの数に応じて決定され、これによってアクセス・サーバーの処理能力が決まります。
Qパラメータが起動コマンドで使用されているかどうかを確認してください。このパラメータは、「サービス」パネルの「起動」パラメータ・フィールドに指定するか、ImagePathパラメータのレジストリ・キーを使用して次のように指定します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ObAAAServer-Access_Server_ID
起動コマンドでキュー（Q）パラメータを使用する場合は、アクセス・サーバー構成の現在のスレッド数にキュー・サイズを掛け、その結果を使用してスレッド数を更新します。たとえば、アクセス・サーバーで現在2つのキューと30のスレッドを使用している場合、スレッド数を60に変更します。このパラメータは、アクセス・サーバーの構成の詳細ページで設定します。
アクセス・サーバーのスレッド数を構成する手順
アクセス・システム・コンソールを起動します。
「アクセス・システム構成」をクリックして、「アクセス・サーバー構成」を選択します。
既存のアクセス・サーバーがページにリストされます。
構成を表示するアクセス・サーバーを選択します。
アクセス・サーバーの構成の詳細が表示されます。
「スレッド数」フィールドに、アクセス・サーバーで許可される最大スレッド数を構成します。
データベースに監査を出力しようとすると、アクセス・サーバーの監査機能が動作しません。ただし、ファイル・ベースの監査は機能します。
問題
この問題は、RDBMSプロファイルの作成時に様々な原因で発生します。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』のグローバル設定の構成に関する章を参照してください。
この問題は、たとえば、次を行うと発生します。
新しいデータベース・インスタンスを作成して、そこにoblix_audit_events表を作成します（『Oracle Access Manager IDおよび共通管理ガイド』の監査に関する章を参照）。
システム・コンソールでRDBMSプロファイルを作成します（『Oracle Access Manager IDおよび共通管理ガイド』の監査に関する章を参照）。
アクセス・システム・コンソールで、「システム構成」→「アクセス・サーバー構成」の順にクリックし、変更するアクセス・サーバーのリンクをクリックします。
「変更」をクリックして、データベースとファイルに対する監査が有効になっていることを確認します。
アクセス・システム・コンソールで、「アクセス・システム構成」→「共通情報の構成」→「マスター監査ルール」の順にクリックします。
マスター監査ルールにおいて認証成功、認証失敗、認可成功および認可失敗の各イベントを選択します。
WebGateを介してOracle Access Managerにログインし、認証成功、認証失敗、認可成功および認可失敗の各イベントがロギングされているかどうかをチェックします。
たとえば、「The database audit writer was unable to perform the write」というメッセージがアクセス・サーバーのoblog.logファイルにERRORレベルでロギングされているかどうかをチェックできます。
また、SQL Serverの「クエリ アナライザ」ウィンドウまたはOracleのiSQL*Plusウィンドウで次のコマンドを実行することもできます。
select * from oblix_audit_events
このコマンドにより、oblix_audit_events表の既存の監査レコードのリストが表示されます。リストに新しい認証および認可イベントが含まれていない場合は、データベースへの監査出力が失敗したことを意味します。
解決策
この問題はよく発生しますが、原因は、次のファイルのSQLDBTypeパラメータ値が不正なためです。
AccessServer_install_dir/identity/apps/common/bin/globalparams.xml
ここで、AccessServer_install_dirはアクセス・サーバーがインストールされている場所です。SQLDBTypeパラメータの値を次のように設定します。
接続タイプがODBCの場合は、値をOracleに設定します。
接続タイプがOCIの場合は、値をOracle_OCIに設定します。
SQL Serverデータベースの場合は、値をSQLServerに設定します。
この項では、次の問題について説明します。
認証スキームの形式は適切であり、アクセス・サーバーにリクエストが転送されますが、ユーザーが認証されません。
問題
認証スキームを構成し、アクセス・テスターを使用してテストした後、認証スキームは正しく機能すると思われました。ところが、ユーザーの認証が必要なときに、ユーザーが認証されません。ディレクトリ・サーバーのデバッグ・ログには、アクセス・サーバーがディレクトリ・サーバーの検索を行った形跡が見つかりません。
解決策
認証スキームに資格証明マッピング・プラグインを追加する場合は、credential_mappingプラグインがvalidate_passwordプラグインよりも前に配置されるようにします。認証スキームでは、パスワードを検証する前に、ログインIDの属性を検証するプラグインを処理する必要があります。
問題
ユーザー・データがNetscape/Sun Directory Serverに格納されており、ログイン属性が索引ldifインポートを使用して索引付けされている場合、ユーザーの認証中にOracle Access Managerが失敗します。
原因
これはNetscape/Sun Directory Serverの問題です。属性の索引付けをするには、Sun ONE Sever Consoleを使用する必要があります。
解決策
次の手順に従います。
Sun ONE Server Consoleを使用して属性の索引付けをする手順
Sun ONE Server Consoleにログインし、関連するディレクトリ・サーバー・インスタンスを開きます。
「Configuration」タブに移動し、「Data」ノードを展開してsearchbaseノードを選択します（属性を索引付けする接尾辞）。次に例を示します。
dc=us,dc=oracle,dc=com
右側のパネルには、システム索引と追加の索引のリストが表示されます。
「Add Attribute」ボタンをクリックして索引付けする属性を追加し、これに等価、実在、部分文字列の一致を構成します。
「Save」をクリックすると、警告が表示されます。
「Reindex Suffix」を選択し、先ほど追加した属性を選択します。
「OK」をクリックします。
問題
長い認可条件式の追加ができない問題が発生することがあります（たとえば、Oracle Internet Directoryを使用している場合は、4000文字の制限があります）。長い式を追加して保存すると、次のようなメッセージが表示される場合があります。
No Authorization Defined
原因
問題の原因は、ディレクトリ・サーバーの制限です。ただし、ディレクトリ・ベンダーによっては、属性の最大長の増加をサポートしている場合があります。
解決策
長い認可条件式を追加する前に、ポリシー・マネージャのglobalparams.xmlファイルにpolicyDSMaxAttrValueLengthパラメータを追加する必要があります。追加する値は、ディレクトリ・サーバーによって制限される属性の最大長にします。Oracle Internet Directoryでは、この値は4000文字を超えてはいけません。その他のディレクトリ・サーバーについては、詳細はベンダー固有のドキュメントを参照してください。
Access Manager SDKのAPIを使用してポリシーを追加する場合は、policyDSMaxAttrValueLengthパラメータを関連するアクセス・サーバーのglobalparams.xmlファイルに追加する必要があります。
|
注意: ディレクトリの制限を変更できない場合または条件式のサイズに対応させられない場合は、policyDSMaxAttrValueLengthパラメータによってOracle Access Managerで制限が補正され、より長い式の作成ができるようになります。 |
制限を補正してより長い式の作成を許可する手順
次のパスでglobalparams.xmlファイルを検索します。
Access Manager SDKのAPIから変更する場合:
AccessServer_install_dir/access/oblix/apps/
common/bin/globalparams.xml
ポリシー・マネージャから変更する場合:
PolicyManager_install_dir/access/oblix/apps/
common/bin/globalparams.xml
次の行をglobalparams.xmlファイルの任意の場所に追加します。
<SimpleList>
<NameValPair
ParamName="policyDSMaxAttrValueLength"
Value="4000">
</NameValPair>
</SimpleList>
アクセス・サーバーまたはポリシー・マネージャWebサーバーを再起動します。
認可条件式をOracle Access Managerに追加します。
第8章で説明するように、Oracle Access Managerデプロイには、アイデンティティ・サーバー、アクセス・サーバーおよびポリシー・マネージャの複数のインスタンスを含めることができます。動作の一貫性を保つために、ユーザー・プロファイルおよびポリシー情報の変更（またはアクセス・サーバーの構成変更）はすべてディレクトリ・サーバーに書き込み、すべてのコンポーネントに伝播する必要があります。
問題
アクセス・サーバー10g（10.1.4.2.0）以降でActive Directoryをバックエンド・ディレクトリ・サーバーとして使用する場合、キャッシュ・フラッシュ操作はアクセス・システム上で有効になりません。さらに、キャッシュ・フラッシュ操作中に、スキーマ違反のエラー・ログがアクセス・サーバーのログ・ファイルに記録されます。
原因
Active Directoryでのスキーマ制限です。
解決策
Active Directoryをバックエンド・ディレクトリ・サーバーとして使用する場合、アクセス・サーバーのglobalparams.xmlファイルにあるUserMgmtNodeEnabledパラメータの値をfalseに設定する必要があります。
|
関連項目: 『Oracle Access Managerカスタマイズ・ガイド』のパラメータに関する章 |
Active Directoryでの適切なキャッシュ同期を確認する手順
次のパスからアクセス・サーバーのglobalparams.xmlファイルを探します。
AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xml
UserMgmtNodeEnabledパラメータの値がfalseに設定されていることを確認（または変更）します。
アクセス・サーバーを再起動します。
これらの手順をデプロイ内のすべてのアクセス・サーバーで繰り返します。
|
注意: 元の10g（10.1.4.2.0）リリースでは、これはデフォルトで有効になっていました。バンドル・パッチ10g（10.1.4.2.0）-07を適用すると、10g（10.1.4.01）と同じようにデフォルトで無効（false）になります。
Oracle Access Manager 10g（10.1.4.3）（または10g（10.1.4.2.0）バンドル・パッチ07）では、 |
この項の内容は次のとおりです。
通常の動作中に、ディレクトリ・サーバーが動作していないというエラーが表示されることがあります。
問題
アクセス・サーバーまたはポリシー・マネージャが、次のいずれかのエラー・メッセージを発行する場合があります。
「ディレクトリ・サーバーが実行中であることを確認してください。」
「ディレクトリ・サーバーが応答していることを確認してください。」
ユーザーが構成可能な時間内に、Oracle Access Managerコンポーネントがディレクトリ・サーバーからのレスポンスを受信しないと、これらのエラー・メッセージが生成されます。
解決策
次の解決策により、この問題が解決される可能性があります。
globalparams.xmlのLDAPOperationTimeoutパラメータの値を確認してください。
このパラメータを使用すると、プライマリ・ディレクトリ・サーバーからのレスポンス時間が長すぎる場合にOracle Access Managerコンポーネントのセカンダリ・ディレクトリ・サーバーへのフェイルオーバーが可能になります。詳細は、『Oracle Access Managerカスタマイズ・ガイド』のパラメータ・ファイルに関する付録を参照してください。
このディレクトリ・サーバーのフェイルオーバーの構成を確認してください。
『Oracle Access Manager IDおよび共通管理ガイド』のディレクトリ・サーバー・プロファイルの構成に関する情報を参照してください。『Oracle Access Managerデプロイメント・ガイド』のフェイルオーバーに関する章も参照してください。
ディレクトリ・サーバー・プロファイルを構成した後、アクセス・サーバーまたはポリシー・マネージャのメモリー使用量が非常に高くなります。
「検索」アイコンを選択してから検索を実行すると、「製品により次のメッセージが生成されました。問題を解決するにはWebマスターに連絡してください。」というエラー・メッセージが表示されます。limitAMPolicyDomainResourceDisplayパラメータが、ポリシー・マネージャのglobalparams.xmlファイルでtrueに設定されています。
問題
ポリシー・ドメインの数が現行制限数の350を超えています。400のポリシー・ドメインがアクセス・システムに作成され、それぞれについてリソースとポリシーが10個ずつあります。
解決策
Active Directoryでのポリシー・ドメインが350を超えないようにしてください。
『Oracle Access Managerインストレーション・ガイド』で説明するように、すべてのコマンドライン・ユーティリティとコマンドライン・ツールは、製品をインストールしたユーザーとして実行する必要があります。ファイルの所有者や権限は、インストール後に変更しないことをお薦めします。
この項では、次の問題について説明します。
ユーザーが資格証明を入力しても、ログイン・フォームが繰返し再表示されます。
問題
ログイン資格証明のパラメータの構成、認証プラグインの構成、および認証スキームの構成が原因で、ログイン・フォームがポップアップし続けることがあります。
解決策
この問題には次の解決策のいずれかを適用できます。
フォーム・スキームのcredsチャレンジ・パラメータ内の資格証明が、フォームの該当する入力フィールドに一致することを確認します。
フォーム・スキームの認証プラグインが正しいことを確認します。
IISを使用していてフォーム・アクションがwebgate.dllでない場合は、WebGateフィルタの後処理がレジストリ・エントリによって有効になっていることを確認してください。
HKEY_LOCAL_MACHINE\SOFTWARE\Oblix\Oblix COREid\version\WebGate\postdata="yes"
ここで、versionは、インストールされているOracle Access Manager製品のバージョン番号です。
認証スキームが正しく設定されていることを確認するため、資格証明を問合せ文字列パラメータとして追加して、認証スキームで保護されたリソースへのアクセスを試みることができます。これにより、実際にフォームを使用しないでも、GETメソッドのフォームがシミュレートされます。
たとえば、認証スキームが次のcredsチャレンジ・パラメータを使用するとします。
creds:login password
この例で、保護されたURLがhttp://server/protected/page.htmlである場合は、ブラウザ・インスタンスを起動して次のように入力できます。
http://server/protected/page.html?login=jsmith&password=MyPwd
jsmithとMyPwdが有効な資格証明である場合、[Enter]を押すと、認証スキームが正常に機能していればログイン・フォームではなくページが表示されますが、この場合は、フォームのHTMLコードまたはレジストリ（IISサーバーの場合）が不正と考えられます。
ユーザーのセッションが有効かどうかを検証するには、ブラウザのURL用フィールドに次のように入力します。
javascript:alert(document.cookie)
ポップアップされるウィンドウには、ObSSOCookieなど、ブラウザに関連付けられた現行のCookieが含まれている必要があります。これは、Cookieドメインや無効なログアウト状況がログイン手順に影響を与えているかを判断するためにも役立ちます。
WebGateがApache/Oracle HTTP Server 1.3.x Webサーバーにインストールされている場合、フォーム・ベース認証スキームで保護されたリソースにアクセスすると、次のいずれの状況でもWebブラウザに302応答が表示されます。
チャレンジ・リダイレクトが使用されている
WebGateで保護されているWebサーバーを隠すために、リバース・プロキシ・サーバーが使用されている
問題
302応答には、HTTPプロトコルごとに、次のリクエストに使用されるLocation:urlが含まれています。ブラウザには次のメッセージが表示されます。
Found
The document has moved here
原因
プロキシ・サーバー（またはクライアント）とApache/Oracle HTTP Server間のプロトコルの不一致により、Apache/Oracle HTTP Server 1.3.xによって余分なデータが追加されています。Oracle HTTP ServerはApache 1.x.xに基づいていますが、Apache 1.3.27ではKeepAliveとHTTP/1.1が正しく実装されていません。この場合、データはプロキシ・サーバー/クライアント（ブラウザ）にチャンク形式で戻されます。チャンク形式のデータはすべて一時キャッシュに集められ、そのキャッシュのリンクがユーザーに表示されます。
回避方法
これにはいくつかの回避方法があります。項目2の方法が最善の解決策であり、これをお薦めします。HTTP 1.0を使用するのは、HTTP 1.1と比べてパフォーマンスの点で不利です。回避方法3、4、5は、回避方法1と2が適切でないか機能しない場合にのみ使用してください。次の中から、使用環境に最適な回避方法を選択します。
APACHE/Oracle HTTP Server 1.3.Xを上位バージョンにアップグレードします。
次の行をWebGate Webサーバーのhttpd.confファイルに追加します。
ErrorDocument 302 "
WebGate Webサーバーのhttpd.confファイルのmod_setenvifモジュールにBrowserMatchディレクティブを追加し、特定のブラウザに対してKeepAliveを無効にします。
リバース・プロキシのhttpd.confファイルでプロトコル調整用の2つの環境変数を使用します。これにより、リクエストでKeepAliveなしのHTTP/1.0を強制的に使用することができます。次に例を示します。
1)force-proxy-request-1.0 2)proxy-nokeepalive
クライアント・ブラウザ設定をHTTP /1.0プロトコルを使用するように構成します。
ログイン・フォームを送信すると、エラーが表示されるか、ログイン・フォームが応答を停止します。
問題
ログイン・フォームを送信すると、次のメッセージのいずれかまたは両方が表示されます。
500 内部サーバー・エラー
新しいログイン・チャレンジ（基本ログイン・ダイアログ・ボックスなど）が表示されました
フォームが応答を停止する場合は、リダイレクション・アクションが誤って構成されている可能性があります。
解決策
エラー・メッセージが表示された場合は、フォームのアクションURLがポリシー・ドメインによって保護されていること、およびフォーム・スキームのアクションのチャレンジ・パラメータがフォーム・アクションURLに一致することを確認します。
認証が成功しても、フォームが応答を停止する場合は、同じログイン・フォームがリダイレクション・アクションによってユーザーに再表示されないようにしてください。
問題
この問題は、複数のアクセス・サーバーを1つのディレクトリ・サーバーで構成している場合に、デフォルト設定で新しいインストールを行ったときに発生する可能性があります。ポリシー・マネージャからのキャッシュ・フラッシュのリクエスト中に1つのアクセス・サーバーがハングした場合、「キャッシュの更新」オプションを有効にして、ポリシー・マネージャ・コンソールを使用してパラメータを変更および保存すると、ポリシー・マネージャがハングする可能性があります。たとえば、「キャッシュの更新」オプションを有効にして、ホスト識別子、ポリシー・ドメイン、URL接頭辞を変更した場合などです。
解決策
CacheFlushTimeOutパラメータをポリシー・マネージャのglobalparams.xmlファイルに追加します。詳細は、『Oracle Access Managerデプロイメント・ガイド』で、待機時間を使用した複数のアクセス・サーバー間での同期キャッシュ・フラッシュのリクエストの構成に関する項を参照してください。
この項では、次の問題について説明します。
あるシステム（アクセス・システムなど）にログインした後、別のシステム（アイデンティティ・システムなど）にログインしようとすると、次のようなエラー・メッセージが表示されることがあります。
アイデンティティ・サーバーにはログインできましたが、アクセス・システム（ポリシー・マネージャまたはシステム・コンソール）にはログインできませんでした。
問題
これには次の問題のうちの1つ以上が原因になっていることがあります。
アイデンティティ・サーバーおよびアクセス・サーバーが別々のコンピュータで実行され、それぞれのクロックが異なる時間に設定されている。
ポリシー・ドメインでアイデンティティ・システムは保護しているが、アクセス・システムは保護していない。または、その逆である。
oblixbaseparams.xmlファイルのloginslackパラメータが正しく構成されていない。
解決策
次の解決策のうち、1つ以上を適用します。
アイデンティティ・サーバーおよびアクセス・サーバーのシステム・クロックを同期化します。
アイデンティティ・システムとアクセス・システムの両方を保護するポリシー・ドメインが作成されていることを確認します。
詳細は、「ポリシー・ドメインによるリソースの保護」を参照してください。
次のファイルを開いてloginslackパラメータの値を編集します。
PolicyManager_install_dir/access/oblix/apps/common/bin/oblixbaseparams.xml
loginslackパラメータには、ポリシー・マネージャ・ホスト・コンピュータとアイデンティティ・ホスト・コンピュータ間の許容時差を設定します。このパラメータは、WebPassに影響を与えることで、ポリシー・マネージャとアイデンティティ・システム間のシングル・サインオンに影響します。WebGateが提供するシングル・サインオンには影響しません。loginslackパラメータが有用なのは、WebGateがポリシー・マネージャやWebPassを保護しておらず、WebGateがシングル・サインオンに使用されない場合のみです。このタイプの使用例では、ポリシー・マネージャやWebPassはログインとシングル・サインオンにはObSSOCookieとは異なるCookieを使用します。このCookieにはタイムスタンプがあります。
デフォルト値は60秒です。
次のようなシングル・サインオンに関する問題が発生することがあります。
予期しないセッション・タイムアウト。
シングル・サインオンの失敗（常にログイン・プロンプトが表示される）。
認証が失敗する。
ユーザーは最初は認証されるが、別のホストのリソースにアクセスすると認可に失敗する。
保護されたWebサイトに認証されても、同じ認証レベルを持つ別のサイトにアクセスすると、シングル・サインオンが機能しない。
問題
次の問題のうちの1つ以上が原因となっている可能性があります。
予期しないセッション・タイムアウト: セッション・タイムアウト・パラメータが正しく設定されていないか、ホストのシステム・クロック間で同期されていません。
シングル・サインオンの失敗: Cookieの定義に誤ったドメイン名が含まれているか、WebGate間で同一のプライマリHTTP Cookieドメインまたは共有シークレットがありません。
ユーザーの認証の失敗: ユーザーのIDまたはドメイン名がドメインに指定された認証ルールに適合しないか、マルチドメイン・シングル・サインオンを有効にする認証スキームでチャレンジ・リダイレクトが指定されていません。
別ホストのリソースへのアクセス時におけるユーザー認可の失敗: 2番目のホストに構成された認証スキームが最初のホストの認証スキームより厳格か、共有シークレットが破損している可能性があります。
解決策
次の解決策のうちの1つ以上を使用することで、この問題が解決される可能性があります。
タイムアウトの問題:
セッション・タイムアウト・パラメータの「最大ユーザー・セッション時間」および「アイドル・セッション時間」の値を大きくします。詳細は、「アクセス・ゲート構成パラメータ」を参照してください。
シングル・サインオンに関係する各ホストのシステム・クロックを同期します。
ホストのシステム・クロックが同期されていないと、実際にはタイムアウトの問題がない場合にも、Cookieが将来または過去のものになり、セッション・タイムアウト・ルールが適用される可能性があります。
シングル・サインオンの失敗:
ObSSOCookieの定義をチェックします。Cookieの定義に誤ったドメイン名が含まれている可能性があります。
必ず両方のWebGateが同一のプライマリHTTP Cookieドメインを持つようにしてください。
2つのWebGateが必ず同じアクセス・サーバーに構成されるようにしてください。
ユーザーの認証の失敗:
必ずこのユーザーのIDがドメインに指定された認証ルールに適合するようにします。
また、ユーザーが必ず完全修飾のドメイン名を指定するようにします。ユーザーが完全修飾ドメイン名を指定するようにする方法を複数構成できます。詳細は、「ホスト識別子とホスト・コンテキストの使用方法」を参照してください。
最後に、マルチドメイン・シングル・サインオンを有効にする認証スキームで、チャレンジ・リダイレクトが設定されていることを確認します。
ユーザーは最初は認証されるが、別のホストのリソースにアクセスすると認可に失敗する。
2番目のホストに構成された認証ルールが、リソースへのリクエスタのアクセスを拒否している可能性があります。厳格なスキームで認証されたユーザーは、緩いスキームでも認証されますが、その逆はできません。たとえば、Basic Over LDAP認証スキームへの適合を要求するリソースに対するアクセスをあるユーザーが認証されている場合、そのユーザーは、それ以下の厳格さのスキームを持つ他のリソースにアクセスできます。これに対して、この同じユーザーがより厳格な認証チャレンジ（クライアント証明書など）のあるリソースにアクセスしようとする場合には、再認証を受けることが必要です。ユーザーが同じスキーム（ただし、より高レベルの認証チャレンジ）で保護されているリソースにアクセスしようとする場合でも、再認証が必要です。
シングル・サインオンが、同じ認証レベルを持つ別のサイトへのアクセス時に機能しない。
共有シークレットが破損している可能性があります。共有シークレットを再生成してWebサーバーおよびアクセス・サーバーを再起動します。
この項では、次の問題について説明します。
次の新しいパラメータが追加され、これを使用して「優先HTTPホスト」フィールドを空のままにしておいたり、フィールドのエントリにエラーがないか検証したりできるようになりました。
AllowEmptyPreferredHost: 値がtrueの場合、アクセス・システム・コンソールのWebGate構成プロファイルで、「優先HTTPホスト」フィールドを空にしておくことができます。
値がfalse（またはデフォルトの空白）の場合は、「優先HTTPホスト」フィールドを空にしておくことはできません。空にすると、プロファイルの保存時にエラーが発生します。
PreferredHostValidityCheckEnabled: 値がtrue（またはデフォルトの空白）の場合、「優先HTTPホスト」フィールドの値にタイプミスがないかどうかを検証します。
|
関連項目: Oracle Metalink（https://metalink.oracle.com）のナレッジ・ベース番号416329.1。この注意事項は、優先HTTPホスト機能を使用するかどうか、そして使用環境では優先ホストを使用するよりも仮想ホストを有効にする方がより重要だと判断した場合は、どのように迂回するかを決定するためのガイドラインとなります。 |
空の「優先HTTPホスト」フィールドを許可するか、値の妥当性をチェックするための手順
wrsc_admin.jsファイルを探して、このスクリプトから検証を削除します。
次のパスから、ポリシー・マネージャのglobalparams.xmlファイルを探します。
PolicyManager_install_dir/access/oblix/apps/common/bin/
空の優先HTTPホストフィールドを許可: 次のようにAllowEmptyPreferredHostをtrueに設定し、ファイルを保存します。
<SimpleList>
<NameValPair
ParamName="AllowEmptyPreferredHost" Value="true">
</NameValPair>
</SimpleList>
優先HTTPホストの妥当性チェックを有効化: 次のようにPreferredHostValidityCheckEnabledをtrueに設定し、ファイルを保存します。
<SimpleList>
<NameValPair
ParamName="PreferredHostValidityCheckEnabled" Value="true">
</NameValPair>
</SimpleList>
WebGateの診断URLでは、WebGateが接続されているアクセス・サーバーのステータスが報告されます。このURLのランディング・ページで、実際にはアクセス・サーバーが実行中であるにもかかわらず停止していると報告されることがあります。
問題
この問題は、WebGateに関連付けられたアクセス・サーバーの数が、WebGateの「最大接続数」プロパティの値より多い場合に発生します。このような状況では、アクセス・サーバーのステータスとは無関係に、最大接続数を超えるすべてのアクセス・サーバーのステータスがWebGate診断ページで「停止中」と表示されます。たとえば、WebGate Aの「最大接続数」の値を1に設定し、これに3つのアクセス・サーバーAAA1、AAA2およびAAA3を関連付けたとします。診断ページには、AAA1が稼働中、AAA2およびAAA3が停止中と表示されます。AAA1が停止している場合、このページには、AAA2が稼働中、AAA3が停止中と表示されます。
解決策
この問題を修正するには、WebGateとアクセス・サーバー間に構成された接続の数が、アクセス・サーバーの数よりも多いことを確認します。詳細は、「アクセス・ゲート・プロファイルの表示」および「アクセス・ゲート構成パラメータ」を参照してください。
IIS 6でWebPassまたはWebGateをインストールし、ロギングを有効にした場合、WebPassまたはWebGateは、関連付けられたアイデンティティ・サーバーまたはアクセス・サーバーに接続できない場合があります。
問題
この問題は、MPFileLogWriterにログを送信する場合に発生します。FileLogWriterにログを送信する場合は発生しません。
この問題は、ログ・ファイルを含むディレクトリへのアクセス権を持つ匿名ユーザーがいない場合にMPFileLogWriterで発生します。MPFileLogWriterは、<logfile name>.lckという名前のファイルを使用して、該当するログ・ファイルへの書込みを行う複数のプロセスを同期します。MPFileLogWriterは、oblog.logへの書込みの前に、.lckファイルに対して書込みロックを行います。
解決策
ログ・ファイルを含むディレクトリへのアクセス権を持つ匿名ユーザーを構成します。書込みロックの取得に使用されるユーザー・コンテキストがIISの匿名Webユーザーになることもあります。デフォルトでは、このユーザーにIUSR_<computer name>という名前が付けられますが、この目的を果す任意の匿名ユーザーを構成できます。
Webサーバーでは、401Webサーバー応答を使用して、情報データを送信できます。コンテンツとコンテンツ長の間に不一致があると、ブラウザにデータが表示されないか、またはブラウザにエラー・メッセージが表示されます。Mozillaで有効な資格証明を使用して製品URLにアクセスした後で、次のエラーが表示されます。
HTTP Error 401 401.1 Unauthorized: Logon Failed This error indicates that the credentials passed to the server do not match the credentials required to log on to the server. Please contact the Web server's administrator to verify that you have permission to access the requested resource
ただし、ブラウザをリフレッシュすると、製品のホームページが表示されます。
Miscosoft Internet Explorerでは、有効な資格証明を使用して製品URLにアクセスするとブランクページが表示されますが、ページをリフレッシュすると製品ホームページが表示されます。
WebGateが特定のブラウザやプロキシなどで動作するように構成するために、特定のユーザー定義のパラメータを設定できます。次の新しいWebGateユーザー定義パラメータを使用して、すべての401応答に対してContent-Lengthを0に設定できます。
パラメータ: ContentLengthFor401Response
値: 0（その他の値は無視されます）
注意: WebGateに影響を与えるため、パッチを適用する必要があります。
ContentLengthFor401ResponseパラメータをWebGate構成に追加する手順
アクセス・システム・コンソールを起動し、「アクセス・システム構成」をクリックします。
「アクセス・ゲート構成」をクリックします。
WebGateの検索基準を入力し、「実行」をクリックします。
「検索結果」表で、WebGate名をクリックします。
「アクセス・ゲートの詳細」ページで、最下部にある「変更」をクリックします。
「アクセス・ゲートの変更」ページで、そのページの「ユーザー定義パラメータ」セクションを探し、次のパラメータと値を入力して「追加」ボタンをクリックします。
パラメータ: ContentLengthFor401Response
値: 0
さらにユーザー定義パラメータを追加するには、「追加」ボタンをクリックします。
「保存」をクリックし、この新しい情報を保存します。
デプロイ内の各WebGateに対して手順を繰り返します。
Oracle Access Managerは、コア・ダンプ情報のログ・ファイルへの記録をサポートします。また、スタックをトレースし、トレース情報を記録できます。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』のトラブルシューティングの付録を参照してください。
ここにない解決策については、My Oracle Support（旧MetaLink、https://metalink.oracle.com）で検索できます。そこでも問題の解決策が見つからない場合は、サービス・リクエストを登録してください。
