IdM診断ツールとは、次のタスクを実行することを目的としたスタンドアロン診断ツールです。
アイデンティティ管理デプロイメントにおける問題の識別
アプリケーション問題を解決する修正の提案
診断テストの実行および詳細な診断レポートの収集
Oracleサポートや開発チームの支援、分析の実行およびアプリケーション問題のトラブルシューティング
この章では、Oracle Identity Managerでの、動的構成に関連するテスト・ケースのための診断の有効化について詳しく説明します。動的構成は、実行時に構成に対して行われた変更に関連しており、問題の発生時に静的構成診断テストによって検出することは容易ではありません。また、動的な問題はOracle Identity Managerの実行中に発生します。
Oracle Identity Managerにおける診断の有効化および動的構成に関連するテスト・ケースについては、次の各項で説明します。
Oracle Identity Managerでは、実行時に診断を有効化できます。これを行うには、次のようにします。
Oracle Identity System Administrationにログインし、「システム構成」に移動します。
次の詳細を使用して、システム・プロパティを作成します。
プロパティ名: OIM Diagnostic Enabled
キーワード: OIM.DiagnosticEnabled
値: True
デバッグの目的でOracle Identity Managerの診断を有効にするには、OIM Diagnostic Enabledシステム・プロパティを設定する必要があります。診断を有効化するには、このプロパティの値をTRUEに設定します。この値がFALSEに設定されているか、またはプロパティが欠落している場合、診断は無効化されます。システム・プロパティの作成の詳細は、「システム・プロパティの作成と管理」を参照してください。
診断関連ロギング用のロガーを追加します。これを行うには、次のようにします。
アプリケーション・サーバーのDOMAIN_NAME/config/fmwconfig/servers/SERVER_NAME/logging.xmlファイルに、新しいログ・ハンドラを次のように追加します。
注意: ここで、DOMAIN_NAMEとSERVER_NAMEは、それぞれOracle Identity Managerのインストール時に指定されたドメイン名とサーバー名です。 |
<log_handler name='ldap-diagnostic-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory' level='TRACE:16'> <property name='logreader:' value='off'/> <property name='path' value='${domain.home}/servers/${weblogic.Name}/logs/ldapsync-diagnostic.log'/> <property name='format' value='ODL-Text'/> <property name='useThreadName' value='false'/> <property name='locale' value='en'/> <property name='maxFileSize' value='5242880'/> <property name='maxLogSize' value='52428800'/> <property name='encoding' value='UTF-8'/> </log_handler>
次に示すように、新規ロガーを追加します。
注意: handler name属性の値がステップ3aと同じであることを確認します。 |
<logger name='oracle.iam.ldapsync.diagnostic.logger' level='TRACE:16' useParentHandlers='false'> <handler name="ldap-diagnostic-handler"/> </logger>
logging.xmlファイルを保存します。
注意: 新規ロガーを有効にするために、Oracle Identity Managerの再起動は必要ありません。 |
この項では、次の動的構成に関連する問題およびトラブルシューティングの手順について説明します。
Oracle Identity Managerデータベースおよびアイデンティティ・ストアのロール(Oracle Internet Directory (OID)、Microsoft Active Directory (AD)、Oracle Directory Server Enterprise Edition (ODSSE)など)は、予期しない動作を引き起こす一貫性のない状態になる可能性があります。
プロビジョニング・プロセスの一環として、ロールなどの一部のデータがバックエンド・ディレクトリ・サーバー(OIDなど)に移入されます。これらのロールは、Oracle Identity ManagerとOIDがロールに関して同期化されるよう、スケジュール済ジョブによってOracle Identity Managerにリコンサイルされます。表26-1に示すように、Oracle Identity Managerを一貫性のない状態にする操作セットには様々なものが考えられます。
表26-1 一貫性のないロールのトラブルシューティング
問題 | 解決策 |
---|---|
次の操作が実行されます。
|
この問題を修正するには:
|
次の操作が実行されます。
|
この問題を修正するには:
|
ユーザー・プロビジョニングの完了後にOVD構成のoamEnabledフラグが設定される場合、プロビジョニングされたユーザーには「パスワードのリセット」ページが表示されません。
Oracle Identity ManagerおよびOracle Access Manager (OAM)の構成後、oamEnabledフラグがtrueになるようOVDアダプタを構成する必要があります。OVDアダプタでの適切なOblix属性の設定は、このフラグに依存します。この設定を失敗すると、「パスワードのリセット」ページが最初の想定どおりに表示されません。このことは、プロビジョニングされたユーザー・エントリにObPasswordChangeFlag属性が欠落しているために発生します。この状況は、次の手順を実行した場合に発生します。
ユーザーがOracle Identity Managerにプロビジョニングされ、LDAP同期によってバックエンドのアイデンティティ・ストア(OIDなど)でも作成されます。
ユーザーが割り当てられた一時パスワードを使用して、保護されたリソースに始めてアクセスを試行します。
ユーザーは、oamEnabledフラグに基づき、OAMによってOracle Identity Managerの「パスワードのリセット」ページにリダイレクトされます。フラグが設定されていないため、かわりにユーザーは保護されているリソースへのアクセスが許可されます。
OVD管理者がOVDアダプタのoamEnabledフラグをtrueに設定します。
ユーザーが「セルフ・サービス」ページからパスワードのリセットを試行します。次のようなエラーが表示されます。
LDAP: error code 65 - Failed to find orclpwdexpirationdate in mandatory or optional attribute list.
この問題のトラブルシューティングを行うには、次の手順を実行します。
すべてのOblix関連クラスがバックエンドのアイデンティティ・ストアでロードされていることを確認します。
必要なオブジェクト・クラスおよび属性を既存のユーザー・エントリに追加します。
LDAP同期がOracle Identity Managerで有効化されている場合、エントリ(ユーザーおよびロール)が作成されるLDAPコンテナが、LDAPContainerRules.xmlで定義されているルールに基づいて決定されます。LDAPContainerRules.xmlで定義されるコンテナ評価のタイプは、次のとおりです。
関連項目: LDAPコンテナ・ルールの詳細は、『Oracle Fusion Middleware Oracle Identity Manager開発者ガイド』のLDAPコンテナ・ルールの構成に関する説明を参照してください。 |
静的: 次に示すように、静的コンテナは事前定義されており、パラメータ置換は行われません。
"<container>cn=Groups,dc=us,dc=mydomain,dc=com</container>"
動的: 次に示すように、動的コンテナは事前定義することができず、パラメータ置換の後、実行時に評価されます。
<container>cn=FusionGroups,cn=$Role Description$,dc=us,dc=mydomain,dc=com</container>
動的コンテナの場合、$Role Descriptionの値を置換するときに、エントリ作成のためのコンテナが決まります。また、式やコンテナ要素がそれぞれ異なるよう定義されたルール要素が、1つ以上存在する場合があります。渡されたパラメータが指定されたルールの式を満たしている場合、パラメータ値の置換後、対応するコンテナが実行時に評価されます。そのため、コンテナDNの優先度を決定することはできません。これにより、評価されたコンテナ値が存在しないため、エンティティ作成(ユーザーやロール)が失敗した場合の問題分析が困難になることがよくあります。診断が有効化されていると、コンテナのランタイム評価が実行され、さらに、指定されたルールのRDNに基づいて使用可能なコンテナ値がリストされます。たとえば、LDAPContainerRules.xmlで定義された次のルールを考えてみます。
<rule> <expression>Role Description=*</expression> <container>cn=FusionGroups,cn=$Role Description$,dc=us,dc=mydomain,dc=com</container> <description>$Role Description$</description> </rule>
<expression>要素にRole Description=*が含まれているため、<container>要素のcn=$Role Description$の値が、ロール作成時にロール説明として渡されたパラメータに対して評価されます。
作成中のロールのロール説明がTemporary Admin
である場合、この値はRole Description=*式に当てはめられ、コンテナの値はcn=FusionGroups,cn=Temporary Admin,dc=us,dc=mydomain,dc=comとなります。
cn=FusionGroups,cn=Temporary Admin,dc=us,dc=mydomain,dc=comコンテナがバックエンド・ディレクトリ・サーバー(OIDなど)に存在しない場合、診断により、この情報が構成されているログ・ファイルに記録されます。また、診断により、構成されたバックエンド・ディレクトリ・サーバー内の使用可能なLDAPコンテナすべてのRDN (cn=FusionGroups)について検索が実行され、ログに記録されます。これは、使用可能なコンテナの調査に役立ちます。