この付録では、Oracle Access Managerおよびコンポーネントの実行または再起動中に発生する可能性のある一般的な問題について説明します。次の項があります。
問題
アクセス・サーバー・プロファイルのデバッグ・フラグがオンになっています。アクセス・サーバーのデバッグ・ログのサイズが2GBに達するとアクセス・サーバーは停止し、再起動できなくなります。
原因
アクセス・サーバーのデバッグ・オプションを使用した場合、アクセス・サーバーのデバッグ・ログ・ファイルはリサイクルされません。一部のオペレーティング・システムでは、許容されるログ・ファイル・サイズの上限が、デバッグ・ロギングが正常に行われるサイズの限度を超えています。ログ・ファイルのサイズがこの限度を超えたとき、アクセス・サーバーが機能しなくなる可能性があります。
解決策
デバッグ・ログ・ファイルを削除するか、アクセス・サーバー・プロファイルでデバッグ・フラグを無効にします。
デバッグ機能は、アクセス・サーバーとWebGateの間で発生した接続関連の問題を診断する場合のみ使用してください。デバッグ・ロギングよりも、トレース・レベル・ロギングを長時間使用することをお薦めします。詳細は、第10章「ロギング」を参照してください。
問題
アイデンティティ・システムの一部の機能(クエリー・ビルダーや導出属性など)が期待どおりに動作しません。たとえば、「グループ・マネージャ」、「グループの変更」、「フィルタの作成」を使用するとします。クエリー・ビルダーでの、「自動車免許」や「部門番号」に基づく問合せが(これらの属性のデータが有効で、フィルタによってこれらのユーザーが表示されると予測されるにもかかわらず)期待どおりに動作しない場合があります。
原因
Oracle Access Managerで使用されるディレクトリ・サーバー内のすべての属性は、索引付け(カタログ化とも呼ぶ)される必要があります。一部の属性は、手動でカタログ化する必要があります。
解決策
ディレクトリ・サーバー内の属性が索引付けおよびカタログ化されていることを確認します。属性が索引付けおよびカタログ化されていない場合は、手動で行います。
ユーザー・アイデンティティの作成手順は、ユーザーの作成ワークフローが管理者によってどのように定義されたかにより異なります。
問題
「ユーザー・マネージャ」の「ユーザー・アイデンティティの作成」タブをクリックすると、十分なアクセス権がないことを示すメッセージが表示されます。
原因
ユーザーの作成ワークフローが定義されていない場合は、管理者が「ユーザー・アイデンティティの作成」タブを選択しても、十分なアクセス権限がないことを示すメッセージが表示されます。
解決策
ユーザーの作成ワークフローを作成して有効にします。詳細は、次の各項を参照してください。
この項では、ディレクトリおよびデータベースの一般的な問題と解決策を説明します。内容は次のとおりです。
アイデンティティ・サーバーとActive Directory間でSSLを構成すると、アイデンティティ・サーバーがクラッシュします。
問題
Active Directoryは、読込みおよび書込み操作で、Lightweight Directory Access Protocol(LDAP)を使用します。デフォルトでは、LDAPトラフィックは、オープン・チャネルを通じてクリア・テキストで送信されます。Secure Sockets Layer(SSL)Transport Layer Security(TLS)を使用すると、保護されたバージョンのLDAPを有効化できます。
SSLを構成していない、または構成に問題がある場合、LDAPS有効のActive DirectoryサーバーとのSSL接続を確立すると、アイデンティティ・サーバーがクラッシュします。イベント・ビューア・アプリケーション・ログは、次のようなレポートを生成します。
Faulting application ois_server.exe, version 0.0.0.0, faulting module NSLDAPSSL32V41.dll, version 16512.0.0.10521, fault address 0x0004d3cd.
解決策
LDAPサービスを有効化するドメイン・コントローラ上に、有効な証明書をインストールし、LDAPのSSL接続およびグローバル・カタログ・トラフィックをリスニングし、自動的に受け入れます。
LDAPS有効のActive Directoryサーバーに対するSSL接続を確立するコンポーネントでは、server.domain.comなどのActive Directoryドメイン・コントローラの完全修飾ドメイン名がサーバー証明書に含まれている必要があります。この情報は、「サブジェクト」フィールドの「共通名(cn)」に表示されます。
クライアント証明書を受け取ると、証明書を発行したCAが信頼されているかどうかを、LDAPサーバーが判別します。CAが信頼されている場合、サーバーは証明書内のサブジェクト名を使用して、クライアントにリクエストされた操作を実行するアクセス権限があるかどうかを判別します。
通常の操作で、ディレクトリ・サーバーが操作できないことを示すエラーを受け取ることがあります。
問題
アクセス・サーバーまたはポリシー・マネージャが、次のいずれかのエラー・メッセージを発行することがあります。
「ディレクトリ・サーバーが実行中であることを確認してください。」
「ディレクトリ・サーバーが応答していることを確認してください。」
これらのメッセージは、Oracle Access Managerコンポーネントがユーザー構成可能な時間内にディレクトリ・サーバーからのレスポンスを受け取らない場合に生成されます。
解決策
この問題に対する考えられる解決策は、次のとおりです。
globalparams.xml内のLDAPOperationTimeoutパラメータの値を確認します。
このパラメータにより、Oracle Access Managerコンポーネントは、プライマリ・ディレクトリの応答時間が長すぎる場合、セカンダリ・ディレクトリにフェイルオーバーします。詳細は、『Oracle Access Managerカスタマイズ・ガイド』の付録「パラメータ・ファイル」を参照してください。
このディレクトリ・サーバーにフェイルオーバーが構成されていることを確認してください。
ディレクトリ・サーバー・プロファイルの構成に関する詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。『Oracle Access Managerデプロイメント・ガイド』の「フェイルオーバー」の章も参照してください。
Novell eDirectory上でのアクセス制御および検索ベースのサポートのために、パッチを適用する必要があります。
Novell 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を参照してください。
http://support.novell.com/servlet/downloadfile?file=/uns/ftf/edir8737ftf_1.exe
アイデンティティ・システムおよびアクセス・システム・コンポーネントで使用するディレクトリ・サーバー・プロファイルを保存する際に、次のようなエラーが表示されることがあります。「ディレクトリ・サーバー・プロファイルが保存できません。アプリケーションが正常に機能するために、ディレクトリ・サーバー・プロファイルは検索、変更および削除の各操作でポリシー・ベースにアクセスする必要があります。また、このディレクトリ・サーバー・プロファイルはサーバー間のロード・バランスもできません。」
アクセス・システム(少なくともポリシー・マネージャ)のインストール時に、ディレクトリ内でのポリシー情報の場所を識別するよう求められます。ディレクトリ内のこのブランチは、アイデンティティ・システム構成データが格納されているブランチと同じである場合または異なる場合があります。また、ポリシー・マネージャのインストール時に、ポリシー・ブランチに対する権限をアイデンティティ・サーバーに付与するディレクトリ・プロファイルが作成されます。アイデンティティ・サーバーは、アイデンティティ・システムとアクセス・システム間の参照整合性を保つために、アクセス・システムのポリシー・ブランチ内のオブジェクトを検索、変更および削除できる必要があります。たとえば、アクセス・システムのポリシーの「アクセスの許可」ページで特定のリソースへのアクセスをユーザーに許可するとします。アイデンティティ・システムからユーザーを削除した場合、参照整合性により、ユーザーがアクセス・システムのポリシーからも削除されることが保証されます。
アイデンティティ・システムとアクセス・システム間に参照整合性を提供するディレクトリ・プロファイルがない場合、「...を保存できません」というエラーが発生します。このメッセージが表示される場合は、このプロファイルを削除または編集した可能性があります。
静的グループへのユーザーの追加は、ある程度までしか正しく動作しません。
問題
静的グループにメンバーを追加し続けると、グループ・サイズが縮小します。
解決策
globalparams.xmlでパラメータmaxForRangedMemberRetrievalの値を必要なグループ・メンバーシップ・サイズより大きい数値に変更します。
Windows 2003でActive Directoryを使用している場合は、globalparams.xmlでパラメータmaxForRangedMemberRetrievalを1500に設定します。
Windows 2000でActive Directoryを使用している場合は、1000に設定します。
Active Directoryを使用している場合は、アイデンティティ・システム・コンソールを使用して、ユーザー・データのディレクトリ・プロファイルをADSIからLDAPに、またはLDAPからADSIに変更できます。ただし、構成またはポリシー・データに対してこの処理を行うことはできません。
アイデンティティ・システム・コンソールからポリシーまたは構成データのディレクトリ・プロファイルを変更しようとすると、エラーが発生します。たとえば、LDAPを使用してActive Directoryフォレストにユーザー・データを格納し、ADSIを使用して別のActive Directoryフォレストに構成およびポリシー・データを格納するとします。アイデンティティ・システム・コンソールを使用して構成データ・データベース・プロファイル内のADSIフラグをLDAPに変更する場合は、Oracle Access Managerサーバーおよびサービスの再起動後に、ADSIフラグは有効なままになり、次のメッセージが表示されます。
「別のフォレスト内のユーザーおよび構成DBプロファイルに対してADSIを有効化することができます。このDBプロファイルにはADSIが有効化できません。」
構成またはポリシー・データのディレクトリ・プロファイルをADSIに変更しようとすると、Oracle Access ManagerはプロファイルをADSI対応と認識するためエラーが発生します。
アイデンティティ・システム・コンソールで、RDBMSプロファイルの新規データベース・インスタンスを保存しようとすると、「データベースの検証に失敗しました。」というメッセージが表示されることがあります。
この問題は、「RDBMSプロファイルの管理」の説明に従ってRDBMSプロファイルを作成するときに発生することがあります。通常は、次のファイルのSQLDBTypeパラメータの値が不正なために問題が発生します。
component_install_dir/identity/apps/common/bin/globalparams.xml
component_install_dirは、アイデンティティ・サーバーがインストールされている場所です。
問題
ロスト・パスワード管理のチャレンジ属性とレスポンス属性の構成時に、レスポンス属性が(入力時には大/小文字が区別されるにもかかわらず)「大/小文字を区別しない」に設定されます。
解決策
ロスト・パスワード管理で大/小文字の比較を構成可能にするには、アイデンティティ・サーバーのglobalparams.xmlファイルに新規パラメータisLPMResponseCaseSensitive
を追加します。このパラメータによって、Oracle Access Managerの動作が次のように指定されます。
true: このパラメータがglobalparams.xmlファイルに含まれていない場合のデフォルト値です。値true(またはパラメータなし)は、LPMレスポンスの大/小文字を区別した比較をトリガーします。
false: パラメータが存在し、LPMレスポンスの大/小文字を区別した比較を無効にする場合は、この値を入力します。
大/小文字の比較を有効または無効にする手順
次の場所で、アイデンティティ・サーバーのglobalparams.xmlファイルを探します。
IdentityServer_install_dir/identity/oblix/apps/common/bin/
LPMレスポンスの大/小文字を区別した比較を無効にする場合:
<SimpleList> <NameValPair ParamName="isLPMResponseCaseSensitive" Value="false"></NameValPair> </SimpleList>
LPMレスポンスの大/小文字を区別した比較を有効にする場合:
<SimpleList> <NameValPair ParamName="isLPMResponseCaseSensitive" Value="true"></NameValPair> </SimpleList>
アイデンティティ・サーバーを再起動します。
デプロイ内のアイデンティティ・サーバーごとに、手順を繰り返します。
Oracle Access Manager 10g(10.1.4.3)のフレッシュ・インストールを使用している場合は、この項の内容を無視してください。このフレッシュ・インストールにはbasic.xslおよびmisc.jsへの最新の変更が含まれています。更新の対象となる古いカスタマイズが存在しないため、この項の手順を実行する必要はありません。
問題
ロスト・パスワード管理のチャレンジまたはレスポンスのフレーズを自分のユーザー・プロファイルで再設定しようとすると、エラーが発生します。たとえば、パネル内の選択ボックスを使用してチャレンジまたはレスポンスを変更する際に、エラーが発生する場合があります。
Challenge phrase is blank. Provide values for all challenge phrases.
注意: LPM機能では、チャレンジ属性とレスポンス属性を同時に変更する必要はありません。たとえば、委任管理者にユーザーのチャレンジ質問の設定を許可する一方で、レスポンスの設定を許可しないことも可能です。レスポンス・フレーズを変更せずにチャンレンジ・フレーズを変更しても、エラーは発生しません。 |
解決策
この問題の解決のために、Oracle Access Managerバンドル・バッチ10.1.4.2-BP04には、basic.xslおよびmisc.jsへの変更が同梱されています。更新済のbasic.xsl(典型的なラッパー・スタイルシート)およびmisc.js(多くのスタイルシートで使用されるシステム・レベルのファイル)をデプロイに導入する必要があります。
このバンドル・パッチで使用できる更新済のbasic.xslファイルおよびmisc.jsファイルは、個別のzipファイルに含まれています。これは、それぞれの環境でこれらのファイルに対して行われたカスタマイズが上書きされるのを防ぐためです。
バンドル・パッチ10.1.4.2-BP04に同梱されているbasic.xslは、IdentityServer_install_dir\identity\oblix\lang\sharedおよびWebPass_install_dir\identity\oblix\lang\sharedにある古いバージョンと置き換える必要があります。使用する環境にカスタム・スタイル・ディレクトリが含まれる場合は、カスタマイズ済のbasic.xslを更新して、この新しいbasic.xslファイルに同梱されている変更を含める必要があります。
バンドル・パッチ10.1.4.2-BP04に同梱されているmisc.jsファイルは、WebPass_install_dir\identity\oblix\lang\sharedにある古いバージョンと置き換える必要があります。
注意: Oracleに同梱されているスタイルシートをそのまま保持し、Oracleのガイドラインに従って、スタイルシートを新しいディレクトリにコピーしてから、そのコピーをカスタマイズすることをお薦めします。\sharedディレクトリにある元のスタイルシートをカスタマイズした場合は、このパッチに同梱されている変更が組み込まれると同時にカスタマイズが保持されたかを確認するために、追加の手順を行う必要があります。 |
既存のbasic.xslファイルおよびmisc.jsファイルは、次の場所に格納されています。
\shared\basic.xsl: IdentityServer_install_dir\identity\oblix\lang\shared
\shared
には、言語中立のデフォルト・グローバル・スタイルシートが含まれます。既存の\shared\basic.xslをこのパッチに同梱されている新しいファイルに置き換えることができます。
注意: 既存の\shared\basic.xslがカスタマイズされてカスタム・スタイル・ディレクトリに格納されている場合は、「\CustomStyle\basic.xsl」を参照してください。 |
\CustomStyle\basic.xsl: IdentityServer_install_dir\identity\oblix\lang\en-us\CustomStyle
使用する環境にカスタム・スタイルのディレクトリおよびスタイルシートが含まれる場合は、\CustomStyle\basic.xslを更新して、この新しいbasic.xslファイルに同梱されている変更(Oracle提供の元のバージョンと、このパッチに同梱されているバージョンの差異)を含めることができます。カスタマイズ済ファイルを新しいファイルに置き換えると、カスタマイズはすべて失われます。
\style0\basic.xsl: IdentityServer_install_dir\identity\oblix\lang\en-us\style0
このパッチには、basic.xslシン・ラッパー・ファイルは含まれません。\style0
には、対応する言語固有のデフォルト・シン・ラッパー・ファイルが含まれます。これは、\sharedにあるデフォルト・グローバル・スタイルシートとは異なります。言語固有の\style0ディレクトリは、インストールされている言語ごとに存在する可能性があります。通常、これらの言語固有のラッパーは、\sharedにあるグローバル・スタイルシートを呼び出します。
注意: \style0\basic.xslをこのパッチに同梱されているファイルに置き換えないでください。ただし、言語固有の\style0にあるbasic.xslシン・ラッパーがカスタマイズされており、\shared\basic.xslへの参照を含まない場合は、この新しいshared\basic.xslに同梱されている変更を言語固有の\style0にあるbasic.xslに適用する必要があります。 |
basic.xsl: WebPass_install_dir\identity\oblix\lang\shared
Webパスの既存の\shared\basic.xslをこのパッチに同梱されている新しいファイルに置き換えてください。
misc.js: WebPass_install_dir\identity\oblix\lang\shared
既存の\shared\misc.jsをこのパッチに同梱されている新しいファイルに置き換えることができます。
注意: mics.jsを変更しないことを強くお薦めします。このシステム・レベル・ファイルは、インクルード・ファイルとしてほぼすべてのスタイルシートに含まれます。このファイルにエラーがあると、システムが使用するすべてのスタイルシートに影響します。このファイルを変更することで、目に見えない問題が生じたり、将来問題が起こる可能性があります。 |
これらのファイル、スタイルシートおよびカスタマイズの詳細は、『Oracle Access Managerカスタマイズ・ガイド』の「PresentationXMLを使用したGUIの設計」の章を参照してください。
注意: LPMChallengeResponsePatch.zipは、各プラットフォームのzipファイルに含まれます。パッケージをダウンロードして解凍し、次の手順を実行すると、最新のbasic.xslファイルおよびmics.jsファイルを入手して使用できます。 |
それぞれの環境でbasic.xslおよびmics.jsの新規ファイルを準備して使用する手順
LPMChallengeResponsePatch.zipの内容を保持するための一時ディレクトリを作成します。
temp\lpm_cr_patch
LPMChallengeResponsePatch.zip
を解凍して内容を抽出します。
作成した一時ディレクトリで次の新規ファイルを探します。
temp\lpm_cr_patch\basic.xsl
temp\lpm_cr_patch\mics.js
古い\shared\basic.xslファイルと\shared\misc.jsファイルをバックアップします。
カスタマイズ済スタイルシートを含むカスタマイズ済スタイル・ディレクトリがデプロイに含まれる場合は、古い\CustomStyle\basic.xslファイルをバックアップします。
カスタマイズなし: 既存の\shared\basic.xslファイルまたは\shared\misc.jsファイルが(カスタマイズされていない)初期の状態の場合は、既存のバージョンを新規バージョンに置き換えます(古いバージョンを上書きします)。
basic.xsl: IdentityServer_install_dir\identity\oblix\lang\shared\basic.xsl
basic.xsl: WebPass_install_dir\identity\oblix\lang\shared\basic.xsl
misc.js: WebPass_install_dir\identity\oblix\lang\shared\misc.js
カスタマイズ済: このパッチに同梱されているbasic.xslファイルまたはmisc.jsファイル内の変更を、カスタマイズ済バージョン(通常はカスタム・スタイル・ディレクトリ内のみ)にすべてコピーします。
basic.xsl: IdentityServer_install_dir\identity\oblix\lang\ langtag\CustomStyle\
basic.xsl: IdentityServer_install_dir\identity\oblix\lang\shared
basic.xsl: WebPass_install_dir\identity\oblix\lang\shared\basic.xsl
misc.js: WebPass_install_dir\identity\oblix\lang\shared
これで準備は完了です。ここからは、通常どおりにユーザー・プロファイル・パネルでロスト・パスワード管理のチャレンジおよびレスポンスを変更します。次に例を示します。
アイデンティティ・システム・コンソールで「ユーザー・マネージャ」タブ→「プロファイル」タブをクリックします。
「プロファイル」ページで「パネルの表示」ボタンをクリックします。
チャレンジおよびレスポンスを構成したパネルで「変更」ボタンをクリックします。
チャレンジおよびレスポンスを変更して「保存」をクリックします。
すべてのコマンドライン・ユーティリティおよびツールは、製品をインストールしたユーザーとして実行する必要があります(『Oracle Access Managerインストレーション・ガイド』を参照してください)。インストール後にファイルの所有権やアクセス権の変更を試みないことをお薦めします。
問題
アイデンティティ・サーバーのログに、ユーザー・データが改ざんされたと示されます。チャレンジ属性とレスポンス属性の設定後にユーザー・プロファイルを変更し、チャレンジおよびレスポンスの値を入力せずに保存すると、この問題が発生します。次のメッセージがログに表示されます。
"Delimiter not found. User data seems to be tampered."
このエラーは、変更されたユーザー・プロファイルごとに一度のみ記録されます。
原因
この問題は、チャレンジおよびレスポンス・フレーズに対してすでに使用可能になっており、値が指定されている可能性がある属性を選択した場合のみ発生します。
解決策
推奨されている次の方法でロスト・パスワード管理のチャレンジ・タイプとレスポンス・タイプを構成します。ディレクトリに2つの新規属性を作成します。1つはユーザーに表示されるチャレンジ用、もう1つはチャレンジに対してユーザーが提供するレスポンス用です。ユーザーのチャレンジおよびレスポンスに使用する未使用で空の属性を2つディレクトリに用意します。すでに値が割り当てられている属性ではなく、未使用の属性を選択することをお薦めします。ロスト・パスワード管理の詳細は、「ロスト・パスワード管理」を参照してください。
IdentityServer_install_dirの次のパスにあるglobalparams.xmlファイルには、新規パラメータ(UseDefaultOptionsForAllMails
)が含まれています。
/apps/common/bin/globalparams.xml
このパラメータを使用して、すべての電子メール通知の送信に使用する電子メールIDを構成できます。
このUseDefaultOptionsForAllMails
パラメータをtrue
に設定すると、アイデンティティ・サーバーから送信されるすべての電子メールについて、次の処理が行われます。
送信者名フィールドの値は、globalparams.xmlファイルで定義されているsendMailFromName
パラメータから取得されます。
送信者の電子メールフィールドの値は、globalparams.xmlファイルで定義されているsendMailFromEmail
パラメータから取得されます。
問題
電子メール通知は、送信者名フィールド内のsendMailFromEmail
パラメータの値を使用して送信されます。
電子メール通知が送信されません。かわりに、メッセージがユーザーに送信され、通知用電子メールを送信できなかったことを示すエラーが記録されます。
原因
UseDefaultOptionsForAllMails
はtrue
に設定されていますが、globalparams.xmlファイルで値が定義されていません。詳細は次のとおりです。
sendMailFromNameが定義されていない場合: 送信者名フィールドにsendMailFromEmail
パラメータの値を使用して、電子メールが送信されます。
sendMailFromEmailが定義されていない場合: UseDefaultOptionsForAllMails
がtrue
でsendMailFromEmail
が定義されていない場合、電子メールは送信されません。かわりに、適切なメッセージがユーザーに送信され、通知用電子メールを送信できなかったことを示すエラーが記録されます。
解決策
UseDefaultOptionsForAllMails
をtrue
に設定し、globalparams.xmlファイルで次の値を適切に定義します。
sendMailFromName not definedsendMailFromEmail not defined
詳細は、「ステップ・アクションの説明」のUseDefaultOptionsForAllMailに関する記述、および『Oracle Access Managerカスタマイズ・ガイド』の「パラメータ」の章を参照してください。
Linux用Oracle Access Managerの旧リリースでは、LinuxThreadsライブラリのみが使用されていました。LinuxThreadsを使用するためには、使用するライブラリの実装を決定するために動的リンカによって使用される、環境変数LD_ASSUME_KERNELを手動で設定する必要がありました。LD_ASSUME_KERNELを2.4.19に設定すると、/lib/i686にあるライブラリが動的に使用されました。
Red Hat Linux v5以降のリリースでは、Native POSIX Thread Library(NPTL)のみがサポートされており、LinuxThreadsはサポートされていません。この変更への対応として、Oracle Access Managerは現在、NPTL仕様に準拠しています。ただし、デフォルトではLinuxThreadsが使用されます。
Oracle Access Managerでは、Native POSIX Thread Library(NPTL)またはLinuxThreadsのどちらかが使用されます。デフォルト・モードはLinuxThreadsです。このデフォルトをサポートするために、start_ois_serverおよびstart_access_serverはLinuxThreadsモードで起動します。この場合、変数LD_ASSUME_KERNELは自動的に2.4.19に設定されます。コンソールおよびサーバーのoblogファイルに「Using Linux Threading Library.」というメッセージが表示されます。ただし、start_ois_server_nptlスクリプトまたはstart_access_server_nptlスクリプトを使用してサーバーを起動した場合は、NPTLモードが使用されます。また、restart_ois_server_nptlスクリプトまたはrestart_access_server_nptlスクリプトを使用してサーバーを再起動することもできます。その場合は、コンソールおよびサーバーのoblogファイルに「Using NPTL Threading Library.」というメッセージが表示されます。
Oracle Access ManagerでNPTLを使用した場合、Oracle Access Manager用に作成したカスタム・プラグインおよびAPIへの影響はありません。ただし、アップグレードの際には、GCC v3.3.2 C++コンパイラを使用してOracle Access Managerリリース6.xのカスタム・プラグインを再コンパイルする必要があります。NPTLを使用する場合は、Oracle Access Managerで使用するWebコンポーネントやサード・パーティのコネクタのインストール時に、環境変数LD_ASSUME_KERNELを2.4.19に設定する必要はありません。
NPTL対応のスクリプトは次のとおりです。
アイデンティティ・サーバー: start_ois_server_nptlおよびrestart_ois_server_nptl
アクセス・サーバー: start_access_server_nptlおよびrestart_access_server_nptl
注意: 標準の停止スクリプトおよび次に示す標準の設定スクリプトは、LinuxThreadsとNPTLのどちらを使用した場合でも正常に動作します。start_setup_ois、start_setup_webpass、start_setup_access_manager、start_configureAAAServer、stop_snmp_agent、start_configureWebGateおよびstart_configureAccessGate。 |
SNMPエージェントの設定スクリプトstart_snmp_agentには、LD_ASSUME_KERNELのエントリが含まれます。Oracle Access ManagerでNPTLを使用する場合は、次のファイルからLD_ASSUME_KERNEL=2.4.19環境変数を削除するか、コメント・アウトする必要があります。
SNMPエージェント: start_snmp_agent
注意: NPTLを使用してOracle Access Managerサーバーを実行する一方で、Oracle Access Manager WebコンポーネントにLinuxThreadsを使用すること(またはその逆)が可能です。NPTLを使用する場合は、Oracle Access ManagerのWebコンポーネントやサード・パーティのコネクタのインストール時に、環境変数LD_ASSUME_KERNELを2.4.19に設定する必要はありません。 |
NPTLおよびOracle Access Managerのスクリプトを使用または変更する際には、次の手順を参考にしてください。
Oracle Access ManagerでNPTLを使用する手順
アイデンティティ・サーバーおよびアクセス・サーバーのNPTLバージョンの起動スクリプトは、次の場所にあります。
SNMPエージェント: start_snmp_agentスクリプトからLD_ASSUME_KERNEL=2.4.19環境変数を削除またはコメント・アウトするために、次の手順を実行します。
次のパスでstart_snmp_agentスクリプトを探します。
テキスト・エディタで次の行を削除またはコメント・アウトします。
LD_ASSUME_KERNEL =2.4.19
ファイルを保存します。
デプロイ内のSNMPエージェントごとに、手順を繰り返します。
次に示す標準の設定スクリプトおよび停止スクリプトを使用します。
NPTLを使用するWebコンポーネントまたはサード・パーティのコネクタ: Oracle Access ManagerでNPTLを使用する場合は、環境変数LD_ASSUME_KERNELを2.4.19に設定しないでください。
問題
ユーザー名およびパスワードがHTTPヘッダーにクリア・テキストで表示されます。
原因
ユーザー名およびパスワードは、HTTP POSTデータとしてブラウザからWebサーバーに送信されます。WebサーバーでSSLが有効化されていない場合は、ユーザー名およびパスワードがHTTPヘッダーにクリア・テキストで表示されます。
解決策
資格証明(ユーザー名およびパスワード)をOracle Access ManagerのWebコンポーネントに渡すWebサーバーで、SSLを有効にする必要があります。SSLが有効なWebサーバーを使用すれば、HTTP POSTのデータを傍受されることはありません。それ以外のWebサーバーでは、SSLを有効化する必要はありません。
この項では、ディレクトリおよびデータベース以外のコンポーネントの一般的な問題と解決策を説明します。内容は次のとおりです。
複数のRead Application Cluster(RAC)データベースに監査を構成する場合、監査がしばらくの間正しく動作しないことがあります。
スタイルシートのカスタマイズ後、アイデンティティ・サーバーがクラッシュする、またはWin32例外に関するエラーが発行されます。
RDN属性値を変更すると、アイデンティティ・システムでユーザー・エントリが削除されます。RDNは、DNの一番左の属性です。通常、RDN属性は、cn
またはフルネーム
です。
この問題は、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"/>
ファイルを保存します。
変更を有効化するため、アイデンティティ・サーバーを再起動します。
これにより、問題なくRDN属性値を変更できます。
インストールされたアイデンティティ・サーバーに複数のインスタンスがある場合、アイデンティティ・サーバーのすべてのインスタンスでこの変更を実行してください。
アイデンティティ・アプリケーションで写真を変更しようとしたときに、JPEG写真イメージが更新されません。
ディレクトリ・サーバー・プロファイルの構成後に、アイデンティティ・サーバーのメモリー使用量が非常に多くなります。この問題は、アクセス・サーバーまたはポリシー・マネージャにも適用されます。
システムまたは特定のコンポーネントのパフォーマンスが、期待よりも低下します。
重い負荷を処理している、またはリクエストを処理するのに特に時間を要しているコンポーネントを情報ログを使用して識別します。詳細は、「ロギング」を参照してください。特に、コール処理時間に注目してください。詳細は、「リクエストの処理に要する時間のロギング」を参照してください。
関連項目: 詳細は、『Oracle Access Managerデプロイメント・ガイド』の「パフォーマンス・チューニング」の章を参照してください。 |
オブジェクト・クラス属性を変更して、エクスポートすると、report.csvファイルが作成されます。一部の言語では、レポートにエンコーディングの問題が発生する場合があります。
簡易トランスポート・セキュリティ・モード証明書の有効期間のデフォルト値は365日です。
Oracle Access Managerコンポーネント間のトランスポート・セキュリティを構成する際に、「オープン」、「簡易」および「証明書」モードから選択できます。デフォルトでは、「簡易」モードは1年間のみ動作します。
簡易モード証明書の有効期限を延長できます。そのためには、アイデンティティ・サーバー、Webパス・インスタンス、ポリシー・マネージャ・インスタンス、アクセス・サーバーおよびWebGateのすべてについて、関連する構成ファイルを更新し、コンポーネント関連ユーティリティを使用して変更を実装します。次に手順を示します。
次のファイルを開きます。
component_install_dir/identity/oblix/tools/openssl/openssl.cnf
component_install_dir/access/oblix/tools/openssl/openssl_silent.cnf
component_install_dirは、アイデンティティ・システムまたはアクセス・システムのコンポーネントがインストールされているディレクトリです。アイデンティティ・コンポーネントにはopenssl.cnfが必要です(アイデンティティ・サーバーおよびWebパス・インスタンス)。アクセス・コンポーネントにはopenssl_silent.cnfが必要です(ポリシー・マネージャ・インスタンス、アクセス・サーバーおよびWebGate)。
これらのファイルで、default_days
という名前のパラメータを探します。
デフォルトでは、次のようにこのパラメータの値は365日です。
default_days = 730 # Duration to certify for
有効期限までのデフォルトの日数を増やすことで、証明書の有効期限を延長します。たとえば、次のように証明書の有効期限を2年に延長できます。
default_days = 730 # Duration for the certificate
注意: 両方のファイルで、デフォルトの日数を同じ値で更新します。 |
openssl_silent.cnfファイルおよびopenssl.cnfファイルで設定した期間を使用して簡易モード証明書を再生するために次のタスクを実行し、コンポーネントを再起動します。
アイデンティティ・サーバー: setup_ois.exeユーティリティ(-iコマンドを使用)および次の場所にあるopenssl.cnfファイルを使用します。
IdentityServer_install_dir/oblix/tools/openssl/openssl.cnf
Windowsのsetup_ois.exeユーティリティ(またはUNIXのstart_setup_ois)を実行します。
IdentityServer_install_dir/oblix/tools/setup/setup_ois -i install_dir
Webパス: setup_webpass.exe(-iオプションを使用)および次の場所にあるopenssl.cnfファイルを使用します。
WebPass_install_dir/oblix/tools/openssl/openssl.cnf
Windowsのsetup_webpass.exeユーティリティ(またはUNIXのstart_setup_webpass)を実行します。
WebPass_install_dir/oblix/tools/setup/setupWebPass -i c:/OracleAccessManager/identity
アイデンティティ・システム・ユーティリティの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
ポリシー・マネージャ: genCertユーティリティ(-i、-mおよび-pオプションを使用)および次の場所にあるopenssl_silent.cnfファイルを使用します。
PolicyManager_install_dir/oblix/tools/openssl/openssl_silent.cnf
genCert.exeユーティリティを実行します。
PolicyManager_install_dir/oblix/tools/gencert/gencert -i install_dir -m simple -P password
アクセス・サーバー: configureAAAServer(-iオプションを使用)および次の場所にあるopenssl_silent.cnfファイルを使用します。
AccessServer_install_dir/oblix/tools/openssl/openssl_silent.cnf
WindowsのconfigureAAAServer(またはUNIXのstart_configureAAAServer)を実行します。
AccessServer_install_dir/oblix/tools/configureAAAServer/configureAAAServer -i C:/OracleAccessManager/access
WebGate: configureWebGate(-Iおよび-tオプションを使用および次の場所にあるopenssl_silent.cnfファイルを使用します。
WebGate_install_dir/oblix/tools/openssl/openssl_silent.cnf
WindowsのconfigureWebGate(またはUNIXのstart_configureWebGate)を実行します。
WebGate_install_dir/oblix/tools/configureAccessGate/configureWebGate -i C:/OracleAccessManager/access -t WebGate
アクセス・システム・ユーティリティの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。
プレゼンテーションXMLを使用してスタイルシートを作成またはカスタマイズするときに、スタイルシートのコンパイル・エラーが発生します。
問題
英語以外のキーボードを使用してパスワードにマルチバイト文字が含まれるユーザーを作成すると、ユーザーの作成に失敗します。ディレクトリ・サーバーのパスワード・ポリシー違反に関するエラーが表示されます。
原因
この問題は、7ビット・チェック・プラグインが"uid"および"userpassword"属性で有効化されている場合に発生します。このとき、既存のユーザーのパスワードを変更すると、新しく入力されたパスワードに"7ビット・チェック"が強制されます。新しく入力されたパスワードにマルチバイト文字が含まれている場合、"7ビット・クリーン"とみなされません。製品は、このように機能するように設計されています。
たとえば、ワークフローを作成する場合、値は"obcontainerId=workflowInstances,o=Oblix,o=company,c=us"ノードの下に格納されます。パスワード値は、"obattrvals: <value>"として格納され、"7ビット・クリーン"としてエンコーディングされます。承認者がワークフローを承認すると、パスワード値は、暗号解除され"userpassword"属性の下に格納されます。
解決策
"7ビット・チェック"をワークフロー・ステップで有効化する場合、独自のプラグインを記述する必要があります。
注意: 使用するディレクトリ・サーバーが、7ビット・チェックをサポートしていない場合があります。どのような場合でも、マルチバイト文字を使用してユーザーを作成できる必要があります。 |
ユーザー・パスワード(またはいずれかの別の属性)でマルチバイト文字を使用する場合、特定の属性の"7ビット・チェック"を無効化する必要があります。次の手順では、Sun(旧名称iPlanet)ディレクトリ・サーバーのステップについて説明します。詳細およびステップは、使用するサーバーにより異なります。詳細は、使用しているベンダーのドキュメントを参照してください。
7ビット・チェックを無効化する方法
使用しているディレクトリ・サーバーに管理者としてログインします。
「サーバー・グループ」の下の使用しているディレクトリ・サーバー・インスタンスをクリックします。
ディレクトリ・サーバー・インスタンスの構成タブに移動します。
プラグイン・ノードを拡張して、使用するディレクトリ・サーバー・インスタンスに適用するプラグインのリストを表示します。
「7ビット・チェック」をクリックし、このプラグインにより動作する属性のリストを表示します。
次のようにして、必要な属性を削除する、またはプラグインを完全に無効化します。
"obattrvals"を削除します。
「拡張」ボタンをクリックしプラグインを無効化し、"nsslapd-pluginenabled"を"off"に設定します。
IIS 6上にWebパスをインストールし、ロギングを有効化した場合、関連付けられたアイデンティティ・サーバーにWebパスが接続できないことがあります。
次に、エラー・メッセージおよびその処理に対するトラブルシューティングのヒントについて、説明します。
ワークフローを実行しているときに、「xenroll.cabが見つかりません」という404エラーが発生することがあります。
この問題は、ユーザーが次のようにアイデンティティ・システム・アプリケーションでワークフローを実行したときに発生します。
ユーザー・マネージャを開きます。
ユーザー・プロファイルを表示します。
「証明書登録」ワークフローを起動するプロファイルで「変更」ボタンをクリックします。
旧バージョンのOracle Access Managerでは、ファイルxenroll.cabは「証明書登録」ワークフローおよび「証明書失効」ワークフローに使用されていました。ただし、これらのワークフローのサポートは削除されました。現在このファイルは使用されていません。
スタイルシートから、xenroll.cabへの参照を安全に削除できます。次に、この参照の例を示します。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
<head> ... <object id="cenroll" classid="clsid:43F8F289-7A20-11D0-8F06-00C04FC295E1" codebase="/identity/oblix/apps/common/bin/xenroll.cab" /> ... <script src="http://km.oraclecorp.com/identity/oblix/apps/common/bin/installCert.vbx" language="VBScript" /> </head>
ユーザーがワークフローを実行したときに、そのワークフローが失敗します。
この問題は、ユーザーが次のようにアイデンティティ・システム・アプリケーションでワークフローを実行したときに発生します。
ユーザー・マネージャを開きます。
ユーザー・プロファイルを表示します。
「属性の変更」ワークフローを起動するプロファイルで「変更」ボタンをクリックします。
予期した結果: ワークフローが予想どおりに動作します。
実際の結果: 「有効化に失敗しました」エラーが発生します。
ワークフロー構成は多くの理由で失敗するため、この問題に対する明確な解決策はありません。ただし、可能性の高い原因として、ワークフロー構成中に無効な検索ベースを選択したことが考えられます。検索ベースを削除し、ワークフローを再構成します。詳細は、「検索ベースの概要」を参照してください。
Oracle Internet Directoryを使用する環境で管理者の管理中に、このエラーを受け取る場合があります。
Oracle Internet Directoryでは、orcladminユーザー(dn: cn=orcladmin
)は、管理者権限を持つ擬似ユーザーとみなされます。Oracle Internet Directoryには、このユーザーに対応するLDAPエントリはありません。このユーザーは、Oracle Internet Directoryで作成される特別なグループの一部です。アイデンティティ・サーバーでは、ユーザーはそれぞれディレクトリ内の別個のエントリに存在する必要があります。グループ・マネージャを使用してこれらの特別なグループを表示または変更すると、メッセージ「この種類のグループに対してプロファイルが構成されていません。」が表示されます。
アイデンティティ・システム・アプリケーションで検索を実行後、「戻る」ボタンをクリックすると、このエラーを受け取る場合があります。
Oracle Access Manager 10.1.4.2では、アクセス・サーバーおよびアイデンティティ・サーバーで診断ツールが提供され、Oracleサポート・サービスを利用して問題のトラブルシューティングをする際に役立ちます。
これらのツールは、日常の管理のためのものではありません。Oracleサポート・サービスの支援が必要な問題の調査に役立てるために使用します。
診断ツールを使用すると、次のことができます。
コンポーネントの構成および動作に関する見つけにくい情報の取得
たとえば、メモリー消費または応答しないサーバーを調査する場合、診断を実行して、キャッシュおよびスレッドに関する情報を取得できます。この情報は、Oracleサポート・サービスを利用して、問題の原因を特定する際に役立ちます。
Oracle Access Managerでは、これらのイベントのスタック・トレースはログ・ファイルに自動的に書き込まれます。これらのログ・ファイルをOracleに送信すると、Oracleサポートにより分析されます。
アイデンティティ・システムまたはAccessシステム内のいずれかのイベントのスタック・トレースの手動による取得
診断ツールを使用して取得した特殊なスタック・トレースを、Oracleに送信すると、Oracleサポートによる分析が可能です。たとえば、サーバーの停止時にスタック・トレースを起動できます。
この項には、次の各項目が含まれます。
重大な問題を分析する場合にのみ、診断データを収集します。一般に、Oracleサポートを利用する場合にのみ、診断を実行します。
診断ツールは、アクセス・サーバーおよびアイデンティティ・サーバーとともにインストールされます。診断は、キャッシュおよびスレッドを対象にします。診断ツールを使用すると、戻されたデータをオンスクリーンに表示し、データをファイルに保存できます。
ベスト・プラクティスとして、同一の診断を数回実行して、問題が一時的であるか永続的であるかどうかを特定してください。たとえば、診断出力を比較して、メモリーまたはキャッシュ・サイズが増加しているか確認できます。
次のツールを使用すると、それぞれのシステム(アクセス・サーバーまたはアイデンティティ・サーバー)の診断データを収集できます。
次の手順では、これらのツールを使用する方法について説明します。この手順では、縦線("|")はオプションの選択肢を表します。たとえば、パス名install_dir内の選択肢は、accessまたはidentity、もしくは特定のツール名(トランスポート・セキュリティ・モードの選択肢はopen、simpleまたはcert)です。
注意: 診断ツールを実行すると、オーバーヘッドが発生し、システム・パフォーマンスに影響する場合があります。診断ツールの実行中に詳細なリクエストをすると、メモリーの消費が増加します。この理由により、詳細な診断をキャッシュ問合せに対してリクエストしないでください。 |
アクセス・サーバーまたはアイデンティティ・サーバーの次のディレクトリにナビゲートします。
install_dir\identity|access\oblix\tools\ois_mon|aaa_mon
ここで、install_dirは、アイデンティティ・サーバーまたはアクセス・サーバーがインストールされているディレクトリです。
次のコマンドを発行します。
aaa_mon.exe|ois_mon.exe -sserver
-pport
-iinstall_dir
-m mode open|simple|cert -o optype=GetListofSupportedOperations
意味:
Serverは、情報を収集するホスト・コンピュータの名前です。
Portは、ホストのリスナー・ポートです。
install_dirは、診断されているコンポーネントのインストール・ディレクトリです。
-m
パラメータで、トランスポート・セキュリティ・モードとしてopen
、simple
またはcert
を指定します。
詳細は、「トランスポート・セキュリティ・モードの変更」を参照してください。cert
を指定した場合は、次のパラメータも指定します。
-c path_for_certs
ここで、path_for_certsは、証明書ファイルへの完全修飾パスです。
次のディレクトリにナビゲートします。
install_dir\identity|access\oblix\tools\ois_mon|aaa_mon
ここで、install_dirは、アイデンティティ・サーバーまたはアクセス・サーバーがインストールされているディレクトリです。
特定のタイプのすべてのオブジェクトの名前を取得するには、縦線で区切られたオプションの1つを使用して次のコマンドを発行します。
aaa_mon.exe|ois_mon.exe -sserver
-pport
-iinstall_dir
-m open|simple|cert -o optype=GetDiagnosticInformation,object=cache|thread,mode=list
意味:
Serverは、情報を収集するホスト・コンピュータの名前です。
Portは、ホストのリスナー・ポートです。
install_dirは、診断されているコンポーネントのインストール・ディレクトリです。
-m
パラメータで、トランスポート・セキュリティ・モードとしてopen
、simple
またはcert
を指定します。
詳細は、「トランスポート・セキュリティ・モードの変更」を参照してください。cert
を指定した場合は、次のパラメータも指定します。
-c path_for_certs
ここで、path_for_certsは、証明書ファイルへの完全修飾パスです。
object
パラメータは、結果を特定のオブジェクト・タイプに限定します。
デフォルトでは、すべての診断可能なオブジェクトの情報をフェッチします。次に、使用できる値を示します。
次のディレクトリ・パスにある適切なツールにナビゲートします。
install_dir\identity|access\oblix\tools\ois_mon|aaa_mon
ここで、install_dirは、アイデンティティ・サーバーまたはアクセス・サーバーがインストールされているディレクトリです。
次のコマンドを発行します。
aaa_mon.exe|ois_mon.exe -sserver
-pport
-iinstall_dir
-m open|simple|cert -o optype=GetDiagnosticInformation[, object=cache|thread, mode=brief|detail|list|usage, name=name
]
意味:
Serverは、情報を収集するホスト・コンピュータの名前です。
Portは、ホストのリスナー・ポートです。
install_dirは、診断されているコンポーネントのインストール・ディレクトリです。
-m
パラメータで、トランスポート・セキュリティ・モードとしてopen
、simple
またはcert
を指定します。
詳細は、「トランスポート・セキュリティ・モードの変更」を参照してください。cert
を指定した場合は、次のパラメータも指定します。
-c path_for_certs
ここで、path_for_certsは、証明書ファイルへの完全修飾パスです。
GetDiagnosticInformation
のオプションのobject
パラメータは、結果を特定のオブジェクト・タイプに限定します。
デフォルトでは、すべての診断可能なオブジェクトの情報をフェッチします。次に、使用できる値を示します。
cache
: キャッシュは、最近アクセスされたデータのコピーをメモリー内に保持します。キャッシュは、データをディスクに格納し、プログラムが同一の情報をインターネットからダウンロードすることを防ぐことができます。
thread
: 同時に実行される2つ以上のスレッドにプログラムを分割して、それぞれ異なるジョブを同時に実行できます。
GetDiagnosticInformation
のオプションのmode
パラメータは、戻される結果の数量およびタイプを判別します。
次に、使用できる値を示します。
brief
: 診断可能なオブジェクトのサマリーをスクリーン上に出力します。
detail
: 次のディレクトリのファイル内に、指定されたタイプのすべての診断可能なオブジェクトの現行の値を書き込みます。
install_dir\identity|access\oblix\tools\ois_mon|aaa_mon\OISDiag_datetime|AAADiag_datetime
ここで、install_dirは、アイデンティティ・サーバーまたはアクセス・サーバーがインストールされているディレクトリで、determineはファイルが作成された日付および時刻です。
detail
モードをキャッシュに指定しないでください。
list
: 指定されたタイプのすべての診断可能なオブジェクトのリストを表示します。
usage
: 診断ツールのヘルプ・テキストを表示します。
GetDiagnosticInformation
のオプションのname
パラメータは、コマンド出力を特定のオブジェクトに限定します。
Oracleサポートを利用する場合にのみ、診断出力の解析を実行します。この項では、診断XML出力ファイルを読み込む方法の簡単なガイドラインを説明します。
この項には、次の各項目が含まれます。
list
パラメータを使用した場合)診断コマンドでlist
パラメータを使用すると、出力はスクリーンおよびログ・ファイルに書き込まれます。最も重要な情報は、出力ファイルのname
要素で戻されます。キャッシュの名前および各キャッシュの簡単な説明のリストは、表F-1および表F-2を参照してください。
次のコマンドの抜粋では、list
モードを使用してキャッシュ名のリストを取得します。
-o optype=GetDiagnosticInformation,mode=list,object=cache
例F-1に、次の診断コマンドの抜粋の出力を示します。
例F-1 listモードを使用する診断コマンドのサンプル出力
<?xml version="1.0" encoding="utf-8"?> <DiagnosticReport> <Command> <CommandArg name="optype"> <Value>GetDiagnosticInformation</Value> </CommandArg> <CommandArg name="mode"> <Value>list</Value> </CommandArg> <CommandArg name="object"> <Value>cache</Value> </CommandArg> </Command> <CommandOutput> <Objects> <Object type="cache"> <Name>UidInfoCache</Name> <Name>PersonOOOIndicatorCache</Name> <Name>AuditCache</Name> <Name>AuditUserCache</Name> <Name>AuditMasterAuditPolicyCache</Name> <Name>AuditServerInfoCache</Name> <Name>WfDefCache</Name> <Name>WfDefSetCache</Name> <Name>xsllib_stylesheet</Name> <Name>PortalIdCache</Name> </Object> </Objects> </CommandOutput> </DiagnosticReport>
detail
パラメータを使用した場合)コマンドでdetail
パラメータを使用して、診断情報を取得すると、オブジェクトに設定された値、現在の状態およびパフォーマンスに関する複数のデータのポイントに関する情報が、出力ファイルに含まれます。出力ファイル内で重要な項目は、オブジェクトのタイプにより異なります。たとえば、キャッシュ・オブジェクトの場合、キャッシュ・サイズおよびキャッシュがフラッシュされたかどうかが重要になります。
一般に、診断の意味を解析できるOracleサポートを利用する場合にのみ、詳細な出力に目を通す必要があります。
例F-2に、list
パラメータを使用して生成されたxmlファイルの汎用構造を示します。
例F-2 mode=detailまたはmode=briefを使用した診断の汎用XML出力
<?xml version="1.0" encoding="utf-8"?> <DiagnosticReport> <Command type=CommandType1> <CommandArg name=Arg1> <Value>ArgValue1</Value> </CommandArg> <CommandArg name=Arg2> <Value>ArgValue2-1</Value> <Value>ArgValue2-2</Value> </CommandArg> </Command> <CommandOutput> <Objects> <Object type=ObjectType1 name=ObjectName1> <Attribute name=Attribute1> <Value>Value1</Value> </Attribute> <Attribute name=Arribute2> <Value> Value2-1</Value> <Value> Value2-2</Value> ----- </Attribute> </Object> <Object type=ObjectType2 name=ObjectName2> <Attribute name=Attribute3> <Value>Value3</Value> </Attribute> ----- ----- </Object> ----- ----- </Objects> <CommandOutput> </DiagnosticReport>
たとえば、詳細な診断データを生成するコマンドの抜粋を次に示します。
. . . -o optype=GetDiagnosticInformation,mode=detail,object=cache,name=XSLXDKCache
前のコマンドの抜粋は、例F-3の出力を生成します。
例F-3 mode=detailを使用する診断コマンドの出力
<?xml version="1.0" encoding="utf-8" ?> <DiagnosticReport> <Command> <CommandArg name="optype"> <Value>GetDiagnosticInformation</Value> </CommandArg> <CommandArg name="mode"> <Value>detail</Value> </CommandArg> <CommandArg name="object"> <Value>cache</Value> </CommandArg> <CommandArg name="name"> <Value>XSLXDKCache</Value> </CommandArg> </Command> <CommandOutput> <Objects> <Object type="cache" name="XSLXDKCache"> <Attribute name="state"> <Value>active</Value> </Attribute> <Attribute name="Maximum Elements"> <Value>200</Value> </Attribute> <Attribute name="Current Elements"> <Value>11</Value> </Attribute> <Attribute name="Timeout"> <Value>0</Value> </Attribute> <Attribute name="Hit Count"> <Value>4</Value> </Attribute> <Attribute name="Miss Count"> <Value>11</Value> </Attribute> <Attribute name="Expire Count"> <Value>0</Value> </Attribute> <Attribute name="Flush Count"> <Value>0</Value> </Attribute> <Attribute name="Memory footprint"> <Value>945008</Value> </Attribute> <Attribute name="keys"> <Value>../../../lang/en-us/style0/predefinedreports.xsl</Value> <Value>../../../lang/en-us/style0/reports.xsl</Value> <Value>../../../lang/en-us/style0/usc_admin_main.xsl</Value> <Value>../../../lang/en-us/style0/admin_wf_definition.xsl</Value> <Value>../../../lang/en-us/style0/wf_quickstart_report.xsl</Value> <Value>../../../lang/en-us/style0/reportresults.xsl</Value> <Value>../../../lang/en-us/style0/usc_searchresults.xsl</Value> <Value>../../../lang/en-us/style0/usc_profile.xsl</Value> <Value>../../../lang/en-us/style0/login.xsl</Value> <Value>../../../lang/en-us/style0/qbmodify.xsl</Value> <Value>../../../lang/en-us/style0/wf_quickstart.xsl</Value> </Attribute> </Object> </Objects> </CommandOutput> </DiagnosticReport>
Oracleサポートは、診断データを解析する際に役立ちます。キャッシュの診断を実行している場合、診断出力の理解に表F-1および表F-2が役立ちます。
表F-1 アイデンティティ・システムのキャッシュ名および説明
キャッシュ名 | 説明 |
---|---|
UidInfoCache |
各ユーザーの構造化オブジェクト・クラスに関する情報を格納します。 |
PersonOOOIndicatorCache |
各ユーザーの外出中インジケータをキャッシュします。 |
WfDefCache |
これは、すべてのワークフロー定義のキャッシュです。 |
WfDefSetCache |
これは、ユーザーの作成タイプのワークフローなど、特定のタイプのすべてのワークフロー定義のキャッシュです。 |
xsllib_stylesheet |
これは本番環境では使用されていません。 |
PortalIdCache |
これは本番環境では使用されていません。 |
AuditCache |
これは、サーバーの監査構成情報のキャッシュです。 |
AuditUserCache |
これは、ユーザー・マネージャ監査ポリシーのキャッシュです。 |
AuditMasterAuditPolicyCache |
これは、マスター監査ポリシーのキャッシュです。 |
XMLStructureCache |
これは、ブラウザにレンダリングされた各ページを表す内部XMLデータ構造のキャッシュです。 |
XSLXDKCache |
これのキャッシュは、アイデンティティ・システムで使用された各スタイルシート(XSL)のコンパイルされた形式を含みます。 |
表F-2 アクセス・システムのキャッシュ名および説明
キャッシュ名 | 説明 |
---|---|
UserAccessCache |
評価の認可フェーズ中に使用されます。ユーザーが満たすルールおよびグループのハッシュ表を保持します。 |
AAASyncRequestCache |
Accessシステム内のキャッシュ一貫性を維持し、Accessクライアントに更新を提供するために使用されます。 |
AAAUserCache |
ユーザー・プロセスファイル属性のリストを保持します。リクエスト評価の認証、IsAuthorizedおよび監査イベント・フェーズ中に使用されます。 |
AAAUserCredCache |
ユーザー・パスワードを保持します。パスワードを検証するリクエスト評価の認証フェーズ中に使用されます。 |
AuditPolicyCache |
監査マスクを取得するIsResrcProtectedイベントの処理中に使用されます。監査イベント中にも使用されます。監査ポリシーを格納します。 |
AuthentPluginCache |
カスタム認証プラグインのラッパー。認証中に使用されます。 |
AuthentSchemeCache |
IsResrcProtectedイベントの処理中およびリソース・リリースの認証フェーズ中に使用されます。認証スキームの詳細を格納します。 |
AuthzDSOCache |
カスタム認可プラグインのラッパー。IsAuthorizedイベントの処理中に使用されます。 |
AuthzRuleCache |
ユーザーのリソースへのアクセス権限を評価し、アクション情報を取得するIsAuthorizedイベントの処理中に使用されます。ポリシー詳細を格納します。 |
AuthzSchemeCache |
カスタム認可スキーム情報を保持します。IsAuthorizedイベントの処理中に使用されます。 |
ClientConfigCache |
AccessクライアントのUpdateConfigurationリクエストの処理中に使用されます。 |
DomainPasswdPolicyIDMapper |
パスワード・ポリシーIDを保持します。パスワード・ポリシー情報を取得するAuthenticateイベントの処理中に使用されます。 |
GrpQueryCache |
ユーザーが属するグループのリストを保持します。ObMyGroupsの評価中に使用されます。 |
HostIdHashString |
一致するポリシーを探すIsResrcProtectedイベントの処理中に使用されます。ホスト識別子を格納します。 |
LPMPolicyCache |
ロスト・パスワード管理ポリシーの情報を取得する評価の認証フェーズ中に使用されます。 |
PSCGrpDefnCache |
動的グループのネストされたグループおよびルールを保持します。 |
PSCUid2OcCache |
評価の認可フェーズ中に使用されます。ユーザーが満たすルールおよびグループのハッシュ表を含みます。 |
PasswdPolicyCache |
パスワード・ポリシー情報を取得する評価の認証フェーズ中に使用されます。 |
PasswdPolicyUserCache |
パスワード・ポリシー情報を取得する評価の認証フェーズ中に使用されます。 |
PolicyCache |
ユーザーのリソースへのアクセス権限を評価し、アクション情報を取得するIsAuthorizedフェーズの処理中に使用されます。ポリシー・ルールを格納します。 |
SDCache |
一致するポリシーおよび認証スキームを探すIsResrcProtectedフェーズ中に使用されます。サイト・ドメイン・オブジェクトを格納します。 |
SessionTokenCache |
暗号解除されたセッション・トークンを格納します。セッション・トークンの暗号解除のオーバーヘッドを削減します。 |
URLPrefixCache |
リソースがマッピングされたポリシー・ドメインを探す際に使用されます。ポリシー・ドメインIDを格納します。 |
WRORCache |
認証チャレンジ・スキームおよび認証の詳細を探すIsResrcProtectedイベントの処理中に使用されます。認証スキームの詳細を格納します。 |
jobstatuscache |
ジョブのレポートのステータスが保持されます。 |
Oracle Access Managerでコア・ダンプが発生すると、コア・ダンプのスタック・トレースをログ・ファイルに書き込めます。スタック・トレースは、ダンプ直前にコールされた機能をリストします。トレースの情報はトラブルシューティングに役立ちます。たとえば、スレッドがプロセスから抜け出せず、ディレクトリ・サーバーからレスポンスを受け取っていないかどうか、またはメッセージ・リーダー・スレッドが動作しているかどうかを、スタック・トレースで表示できます。
スタック・トレースをログ・ファイルに書き込む場合、ロギングを有効にする必要があります。いずれのロギング・レベルでも、スタック・トレースを書き込めます。詳細は、「ロギング」を参照してください。
スタック・トレースを含むログ・ファイルをOracleサポートに送信して、コア・ダンプの診断に役立てることができます。常に、スタック・トレースの最初の3つのエントリは、同一です。これらのエントリは、スタック・トレース機能に属します。4番目のエントリは、コア・ダンプのキャッシュで失敗した機能、またはスタックとレースを開始した際にスレッドが実行した最後の機能です。
この情報は、Oracleサポートによってのみ解析されます。
詳細は、次の各項を参照してください。
アクセス・サーバーまたはアイデンティティ・サーバーのOracle Access Managerでコア・ダンプが発生した場合、スタック・トレースをログ・ファイルに書き込めます。ただし、スタック・トレースの書込みによりコア・ダンプが書き込まれなくなる場合があります。診断の問題の追跡時またはOracleサポートによりコア・ダンプの状況を再現するよう求められた場合は、globalparams.xmlファイルのStackDumpEnabled
パラメータを無効化する必要があります。値は次のとおりです。
0: 機能を無効化します。
1: デフォルト値。アクセス・サーバーまたはアイデンティティ・サーバー上のOracle Access Managerでコア・ダンプが発生した場合に、ログ・ファイルにスタック・トレースを書き込む機能を有効化します。
2: スタック・トレースを手動でリクエストする場合は、StackDumpEnabled
の値を2に設定する必要があります。詳細は、「スタック・トレースの手動でのリクエスト」を参照してください。
目的のアクションに適したStackDumpEnabled
パラメータ値を正しく設定する手順を次に示します。関連する手順のみを実行してください。
注意: コア・ファイルの収集時に有効な値は0または2です。ただし、値1はコア・ファイルの生成と競合します。 |
StackDumpEnabledの値を設定する手順
アイデンティティ・サーバーまたはアクセス・サーバーの適切なパスでglobalparams.xmlファイルを探します。
install_dir
/access|identity/oblix/apps/common/bin/globalparams.xml
スタック・トレースの無効化: StackDumpEnabled
を探して値を0
に設定します。
<SimpleList> <NameValPair ParamName="StackDumpEnabled" Value="0"></NameValPair> </SimpleList>
スタック・トレースの有効化: StackDumpEnabled
を探して値が1
に設定されていることを検証します。
<SimpleList> <NameValPair ParamName="StackDumpEnabled" Value="1"></NameValPair> </SimpleList>
スタック・トレースの手動でのリクエスト: StackDumpEnabled
を探して値を2
に設定します。
<SimpleList> <NameValPair ParamName="StackDumpEnabled" Value="2"></NameValPair> </SimpleList>
ファイルを保存します。
「スタック・トレースの手動でのリクエスト」に進みます。
アクセス・サーバーまたはアイデンティティ・サーバーの実行中にスタック・トレースを手動でリクエストする手順を次に示します。
次のパスにある適切なツールにナビゲートします。
install_dir\identity|access\oblix\tools\ois_mon|aaa_mon
ここで、install_dirは、アイデンティティ・サーバーまたはアクセス・サーバーがインストールされているディレクトリです。
次のコマンドを発行します。
aaa_mon.exe|ois_mon.exe -sserver
-pport
-iinstall_dir
-m open|simple|cert -o optype=GenerateStackTrace
ここで、縦線("|")はコマンドの選択肢、serverは情報を収集するホスト・コンピュータの名前、portはホストのリスナー・ポート、install_dirは診断中のコンポーネントのインストール・ディレクトリです。
-m
パラメータで、トランスポート・セキュリティ・モードとしてopen
、simple
またはcert
を指定します。詳細は、「トランスポート・セキュリティ・モードの変更」を参照してください。cert
を指定した場合は、次のパラメータも指定します。
-c path_for_certs
ここで、path_for_certsは、証明書ファイルへの完全修飾パスです。
結果を表示するには、トレースが実行されたサーバーのログ・ファイルを開きます。
詳細は、「ロギング」を参照してください。
Oracleサポート(旧名称MetaLink、URLはhttp://metalink.oracle.com
)には、さらに多くの解決策が記載されています。問題の解決策が見つからない場合は、サービス・リクエストを記録してください。