Oracle® Fusion Middlewareリリース・ノート 11gリリース1(11.1.1) for Linux x86 B55924-02 |
|
戻る |
次へ |
この章では、Oracle Identity Managerに関連する問題について説明します。内容は次のとおりです。
この項では、Oracle Identity Manager 11gリリース1(11.1.1)のパッチ要件について説明します。内容は次のとおりです。
My Oracle Support(旧OracleMetaLink)からパッチを入手するには、次のURLに移動し、パッチと更新版をクリックしてパッチ番号を検索してください。
表36-1に、Oracle Database 11g(11.1.0.7)を使用するOracle Identity Manager 11gリリース1(11.1.1)の構成に必要なパッチをリストします。Oracle Identity Manager 11gを構成する前に、Oracle Database 11g(11.1.0.7)データベースに必ずパッチを適用してください。
表36-1 Oracle Database 11g(11.1.0.7)に必要なパッチ
プラットフォーム | My Oracle Supportでのパッチ番号および説明 |
---|---|
UNIX / Linux |
7614692: 保存例外を伴うバルク機能はORACLE 11Gでは機能しません |
7000281: 11GではFORALL文の動作が異なります |
|
8327137: インライン・ビューおよび集計機能の結果が不正です |
|
8617824: Oracle Bug#7628358および7598314に対する11.1.0.7の最上位でのマージ・ラベル・リクエスト |
|
Windows 32ビット |
8689191: Windows 32ビットでのORACLE 11G 11.1.0.7パッチ16のバグ |
Windows 64ビット |
8689199: WINDOWS(64ビットAMD64およびINTEL EM64T)でのORACLE 11G 11.1.0.7パッチ16のバグ |
表36-2に、職務の分離(SoD)機能の既知の問題を解決するパッチをリストします。
表36-2 SoDのパッチ
パッチ番号/ ID | 説明および用途 |
---|---|
パッチ番号9819201(My Oracle Support) |
「デフォルトのSoD構成を使用した場合にSAMLトークンのクライアント・ポリシーを使用する際のリクエスト・プロビジョニング時のSoDチェックが失敗する」に記述されている既知の問題を解決するために、SOAサーバーにこのパッチを適用します。 My Oracle Supportでは、このパッチを次のように説明しています。コールバックのためのSAMLトークン・クライアント・ポリシー使用時のエラー |
パッチID 3M68(Oracle Smart Updateユーティリティを使用)。必要なパスコード: 6LUNDUC7。 |
「リクエスト・プロビジョニング時にクライアント側ポリシーを使用してコールバックを起動するとSoDチェックが失敗する」に記述されている既知の問題を解決するために、Oracle Smart Updateユーティリティを使用して、このパッチをOracle WebLogic Serverに適用します。 |
Oracle Identity Manager提供のパッチの適用時に、次のエラーが生成されます。
ApplySession failed: ApplySession failed to prepare the system.
バージョン要件を満たすために、OPatchバージョン11.1.0.8.1をバージョン11.1.0.8.2にアップグレードする必要があります。
My Oracle SupportからOPatchをダウンロードする方法は、「My Oracle Support(旧OracleMetaLink)からのパッチの取得」を参照してください。
この項では、一般的な問題および回避方法について説明します。内容は次のとおりです。
「ユーザーがロックを解除しようとするとmaxloginattemptsシステム・プロパティによって自動ログインが失敗する」
「Oracle Identity ManagerとOracle Access Managerの統合の設定時に「ユーザーが見つかりません」エラー・メッセージが管理サーバー・コンソールに表示される」
「デフォルトのSoD構成を使用した場合にSAMLトークンのクライアント・ポリシーを使用する際のリクエスト・プロビジョニング時のSoDチェックが失敗する」
「ACCESS POLICY ADMINISTRATORSロールを持たないユーザーはアクセス・ポリシー・レポートのデータを表示できない」
「スケジューラによってRequiredParameterNotSetExceptionのかわりにParameterValueTypeNotSupportedExceptionがスローされる」
「Oracle Identity Manager 11gのアテステーションで一部の新規ユーザー属性がサポートされていない」
「変更リクエストの結果を読み込む際に「Design Consoleのアクセス」フィールドのユーザー詳細を正しい値にマップする必要がある」
「「ユーザーの作成」APIではユーザー.パスワードの有効期限なし、ユーザー.パスワードの変更不可およびユーザー.パスワードの変更が必要フィールドに任意の値を設定できる」
現在、プラットフォーム・アーカイブ・ユーティリティはサポートされていないため、使用しないでください。
この問題を回避するために、編成プロセス・クリーンアップ・タスクという事前に定義されたスケジュール済タスクを使用して、完了した編成プロセスおよび関連データをすべて削除します。
現在、ADFの制限により、ブラウザのタイムゾーンはOracle Identity Managerにアクセスできません。Oracle Identity Manageのすべての日付値のタイムゾーン情報は、サーバーのタイムゾーンに基づきます。そのため、エンド・ユーザーは日付値のタイムゾーン情報を確認できますが、タイムゾーン値に表示されるのはサーバーのタイムゾーンです。
SoDチェックページの職務の分離(SoD)チェックのタイムスタンプフィールドでエンド・ユーザーに表示される日時値は、常にYYYY-MM-DD hh:mm:ss形式で表示されます。この書式はローカライズできません。
このローカライズの問題を回避するには、次の手順を実行します。
Oracle_eBusiness_User_Management_9.1.0.1.0/xml/Oracle-eBusinessSuite-TCA-Main-ConnectorConfig.xmlファイルを開きます。
EBS Connector import xmlでProcess FormのSoDCheckTimeStampフィールドを探します。次のように、<SDC_FIELD_TYPE>をDateFieldDlgに、また<SDC_VARIANT_TYPE>をDateに変更します。
<FormField name = "UD_EBST_USR_SODCHECKTIMESTAMP"> <SDC_UPDATE>!Do not change this field!</SDC_UPDATE> <SDC_LABEL>SoDCheckTimestamp</SDC_LABEL> <SDC_VERSION>1</SDC_VERSION> <SDC_ORDER>23</SDC_ORDER> <SDC_FIELD_TYPE>DateFieldDlg</SDC_FIELD_TYPE> <SDC_DEFAULT>0</SDC_DEFAULT> <SDC_ENCRYPTED>0</SDC_ENCRYPTED> <!--SDC_SQL_LENGTH>50</SDC_SQL_LENGTH--> <SDC_VARIANT_TYPE>Date</SDC_VARIANT_TYPE> </FormField>
コネクタをインポートします。
SoDチェックを有効化します。
SoDチェックをトリガーするために、権限を使用してEBSリソースをプロビジョニングします。
Process FormのSoDCheckTimeStampフィールドがフォームの他の日付フィールドと同様にローカライズされていることを確認します。
UTF-8 BOM(byte order mark)エンコーディングが指定されているCSVファイルのバルク・ロードでエラーが発生します。ただし、no BOMエンコーディングを指定すると、UTF-8エンコード済CSVファイルのバルク・ロードは正常に機能します。
この問題を回避するには次のようにします。
ASCII以外のデータをロードする場合は、CSVファイルをロードする前に、CSVファイルのエンコーディングをUTF-8 no BOMに変更する必要があります。
UTF-8 BOMエンコーディングを使用するCSVファイルにデータが格納されている場合は、bulkloadスクリプトを実行する前に、これらのファイルをUTF-8 no BOMエンコーディングに変更する必要があります。
デフォルトのスケジューラ・ジョブであるジョブ履歴アーカイブでは、日付タイプ属性がサポートされていません。
ジョブ履歴アーカイブのアーカイブ日属性パラメータでは、ddMMyyyyやMMM DD, yyyyなどの文字列パターンのみが受け入れられます。
スケジューラ・ジョブを実行すると、コードによって日付書式がチェックされます。不正な書式を入力すると、実行ステータス・リストおよびログ・コンソールに次の例のようなエラーが表示されます。
<IAM-1020063> <アーカイブ日パラメータの書式が不正です。アーカイブ日はDDMMYYYYまたはUI日付書式で指定する必要があります。>
アーカイブ日の正しい情報を入力するまで、ジョブは正常に実行されません。
ファイル制限が低すぎる値に設定されているマシンでは、エンティティ・アダプタを作成およびコンパイルしようとすると、開いているファイルが多すぎるというエラーが発生し、アダプタがコンパイルされません。
この問題を回避するために、(/etc/security/limits.confにある)マシンのファイル制限を次のように変更し、マシンを再起動します。
soft nofile 4096
hard nofile 4096
現在、Oracle Identity Manager 11gリリース1(11.1.1)のリコンシリエーション・エンジンでは、リコンシリエーションの各コネクタについて、ユーザーを識別するための一致ルールを定義することが求められます。ユーザーを識別するための一致ルールを定義しない場合、リコンシリエーション時にエラーが発生します。
activeStartDateやhireDateなどの日付を不正な書式で指定した場合、これらの値はWebサーバーからSPMLレイヤーに渡されません。有効な日付のみが解析され、SPMLで使用可能になります。そのため、無効な日付書式を含むすべてのSPMLリクエストは無視され、その操作に使用できなくなります。たとえば、HireDateの月を08ではなく8と指定した場合、作成リクエストの完了後にHireDateの値は移入されず、エラー・メッセージは表示されません。
サポートされる日付書式は次のとおりです。
yyyy-MM-dd hh:mm:ss.fffffffff
これ以外の書式はサポートされません。
SoD機能ではJMSベースの処理が使用されます。Oracle Identity Managerは、各SoDリクエストに対してoimSODQueueにメッセージを送信します。なんらかの理由で1つのSoDメッセージが常にエラーになる場合、Oracle Identity Managerは、oimSODQueue内の次のメッセージを処理しません。エラーになるメッセージをoimSODQueueから削除するまで、Oracle Identity Managerでは常に、処理の対象としてそのメッセージが選択されます。
この問題を回避するには、次の手順を使用して、キューのプロパティを編集し、oimSODQueue内のSoDメッセージを削除します。
http://<hostname>:<port>/consoleでWebLogic管理コンソールにログオンします。
コンソールから「サービス」→「メッセージング」→「JMSモジュール」の順に選択します。
OIMJMSModuleをクリックします。すべてのキューが表示されます。
oimSODQueueをクリックします。
構成タブ→「配信の失敗」タブの順に選択します。
再試行回数を変更して、指定した回数のみメッセージが送信されるようにします。
「再配信の制限」のデフォルト値を、無限を意味する-1から特定の値に変更します。たとえば、1を指定するとメッセージは1回のみ送信されます。
SoDエラー・メッセージを確認して削除するには、「監視」タブに移動し、メッセージを選択して削除します。
リソース・オブジェクトの検索時には、リソース名にアンダースコア(_)を使用しないでください。検索機能ではアンダースコアは無視されるため、予期しない結果につながります。
リコンシリエーションでは、Assign to Administratorアクション・ルールがサポートされていません。
この問題を回避するには、コネクタをインポートする前に、コネクタXMLでAssign to AdministratorをNone
に変更します。ただし、値をNoneに変更した後でAssign to Administratorに戻すことはできません。
Firefox Webブラウザでアテステーションを作成する際、特定のボタンをクリックしても何も起こりません。
この問題を回避するには、「更新」ボタンをクリックしてページをリフレッシュします。
WLSセキュリティ・レルムのデフォルトのロックアウト・ポリシーにより、ログイン試行に数回失敗すると、しばらくしてユーザーがロックアウトされます。このポリシーは、Oracle Identity Managerのロックおよびロック解除の機能と競合する可能性があります。
WLSセキュリティ・レルムのロックアウト・ポリシーによるOracle Identity Managerのロック/ロック解除機能への影響を回避するには、WLSのユーザー・ロックアウト・ポリシーの「ロックアウトしきい値」の値をOracle Identity Managerの値より5以上大きく設定する必要があります。たとえば、Oracle Identity Managerの値が10に設定されている場合は、WLSの「ロックアウトしきい値」の値を15に設定します。
ユーザー・ロックアウト・ポリシーのデフォルト値を変更するには、次の手順を実行します。
WebLogic Server管理コンソールを開きます。
「セキュリティ・レルム」でREALM_NAMEを選択します。
「ユーザーのロックアウト」タブを選択します。
構成の編集が有効になっていない場合は、「ロックと編集」ボタンをクリックして構成の編集を有効化します。
ロックアウトしきい値を必要な値に変更します。
「保存」をクリックして変更を保存します。
「アクティブ化」をクリックして変更をアクティブ化します。
ドメイン内のすべてのサーバーを再起動します。
JAVAエージェントを使用してOracle Identity ManagerとOracle Access Managerの統合を設定する際に管理サーバー・コンソールにログインすると、「ユーザーが見つかりません」というエラー・メッセージが表示されます。このメッセージは、ログインが正常に行われた場合でも表示されます。
消込照合ルールで一重引用符(')を使用すると(例: 'B'1USER1')、例外が発生して消込が失敗します。
Oracle SOAインフラストラクチャの制限により、LDAPのロールの調整時には、ロール名、グループ名またはコンテナの説明にカンマ(,)などの特殊文字を使用できません。Oracle Identity Managerの内部コードでは、特殊文字がデリミタとして使用されます。たとえばカンマ(,)は、Oracle Identity Managerでは承認者デリミタとして使用され、SOA HWFレベルのグローバル構成では割当て先デリミタとして使用されます。
デフォルトのSoDチェック構成を使用した場合のみ、リクエスト・プロビジョニング時のSoDチェックが実行されるとSoDチェックが失敗し、SOAコンソールに次のエラーが表示されます。
SEVERE: FabricProviderServlet.handleException Error during retrieval of test page or composite resourcejavax.servlet.ServletException: java.lang.NullPointerException
このエラーは、Sodcheckの結果を使用してOIMからSOAへのコールバックが行われると発生します。
この問題を解決するには、SOAサーバーにパッチ9819201を適用します。パッチ9819201はMy Oracle Supportから入手できます。My Oracle Supportでは、このパッチを次のように説明しています。コールバックのためのSAMLトークン・クライアント・ポリシー使用時のエラー
詳細は、次を参照してください。
デフォルトのSoDチェック構成を使用した場合のみ、リクエスト・プロビジョニング時のSoDチェックが実行されるとSoDチェックが失敗し、Oracle Identity Manager管理およびユーザー・コンソールに次のエラーが表示されます。
<Error> <oracle.wsm.resources.policymanager><WSM-02264> <"/base_domain/oim_server1/oim/unknown/iam-ejb.jar/WEBSERVICECLIENTs/SoDCheckResultService/PORTs/ResultPort" is not a recognized resource pattern.> <Error> <oracle.iam.sod.impl> <IAM-4040002><Error getting Request Service : java.lang.IllegalArgumentException: WSM-02264 "/base_domain/oim_server1/oim/unknown/iam-ejb.jar/WEBSERVICECLIENTs/SoDCheckResultService/PORTs/ResultPort" is not a recognized resource pattern.>
この問題を解決するには、Oracle WebLogic ServerでOracle Smart Updateユーティリティを使用してパッチID3M68を適用します。その際、パスコード6LUNDUC7が要求されます。詳細は、次を参照してください。
Oracle Smart Update Installing Patches and Maintenance Packsのドキュメント
SPMLを使用する汎用テクノロジ・コネクタを使用している場合、プロビジョニング時に次のエラーが表示される場合があります。
<SPMLProvisioningFormatProvider.formatData :problem with Velocity Template Unable to find resource 'com/thortech/xl/gc/impl/prov/SpmlRequest.vm'>
このエラーが発生すると、事前定義済SPML GTCプロビジョニング・フォーマット・プロバイダを使用してプロビジョニングがブロックされます。Oracle Identity Managerサーバーを再起動すると、このエラーの再表示を回避できます。
リポジトリ作成ユーティリティ(RCU)を使用してジョブのスケジュールをシードすると、SeedSchedulerData.logファイルに次の例外が表示される場合があります。
***** Seeding job and trigger Exception occurs during scheduling org.quartz.JobPersistenceException: Couldn't obtain triggers for job: oracle.iam.scheduler.vo.Trigger [See nested exception: java.lang.ClassNotFoundException: oracle.iam.scheduler.vo.Trigger]Exception: Couldn't obtain triggers for job: oracle.iam.scheduler.vo.Triggerorg.quartz.JobPersistenceException: Couldn't obtain triggers for job: oracle.iam.scheduler.vo.Trigger [See nested exception: java.lang.ClassNotFoundException: oracle.iam.scheduler.vo.Trigger]
このエラーは無害で機能が失われることはないため、無視して構いません。
Oracle Identity Managerサーバーを再起動すると、既存の承認ポリシーを削除できなくなります。ただし、サーバーの再起動後に追加した承認ポリシーは削除できます。
この問題を回避するには、サーバーの再起動後、削除する承認ポリシーを開き、問題にならない程度の変更(説明をわずかに変更するなど)を行って更新した承認ポリシーを保存します。これで、更新済承認ポリシーを削除できます。
Mozilla Firefoxブラウザを使用した場合、特定の状況下でレガシー・ユーザー・インタフェース(TransUIとも呼ばれる)の一部のボタンをクリックできません。この問題は断続的に発生し、Firefoxの再ロード(リフレッシュ)機能を使用して解決できます。
ロールの作成、変更または削除時にLDAPハンドラによって例外が発生すると、「システム・エラー」
や「ロールが存在しません」
などの無効なエラー・メッセージが表示される場合があります。
この問題を回避するには、ログ・ファイルに表示される正しいエラー・メッセージを確認します。
ユーザーのパスワードがASCII以外の文字で構成されている場合にユーザーがORACLE Identity Managerセルフ・サービスのプロファイルまたは初期ログイン画面からパスワードをリセットしようとすると、リセットが失敗して次のエラー・メッセージが表示されます。
Failed to change password during the validation of the old password
注意: ユーザー・パスワードがASCII文字のみで構成されている場合は、このエラーは発生しません。 |
この問題を回避するには、次の手順を実行します。
JVMファイルのエンコーディングをUTF8に設定します(例: -Dfile.encoding=UTF-8
)。
注意: これにより、Windowsシステムではコンソールの出力がゆがんで表示される場合がありますが、ログ・ファイルでは正しく表示されます。 |
Oracle WebLogic Serverを再起動します。
Oracle Identity Managerに含まれる認可ポリシーにパッチを適用し、JavaSE環境によってOracle JDBCドライバが登録されると、java.security.AccessControlException
がレポートされ、次のエラー・メッセージが表示されます。
Error while registering Oracle JDBC Diagnosability MBean
この例外は無害です。例外およびエラー・メッセージに反して認可ポリシーは正常にシードされるため、無視して構いません。
Microsoft Windows Internet ExplorerのWebブラウザでロケールがth_THに設定されている場合、Oracle Identity Managerの日時はタイの仏暦に従います。管理およびユーザー・コンソールのアテステーションの作成ページで開始時間の日付を選択すると、タイの仏暦の年が表示されます(例: 2553)。「OK」をクリックするとグレゴリオ暦の同じ年(2010)が「開始時間」フィールドに表示されます。ただし、「次へ」をクリックしてアテステーションの作成を続行すると、処理の開始時間を過去の時間にすることはできないという内容のエラー・メッセージが表示されます。
この問題を回避するには、次のいずれかを実行します。
日時を手動で指定する。
グレゴリオ暦が使用されるMozilla FirefoxのWebブラウザを使用する。
リクエストは、「Design Consoleのアクセス」フラグがオンに設定されている受益者に対して要求されます。このフラグがオンの場合にユーザーに付与される権限は、「エンドユーザー管理者」ロールの権限です。
この問題を回避するには、このようなユーザーのリクエストを要求する際に、権限が維持されるようにフラグの選択または再設定を必ず行います。これを行わなかった場合は、フラグがクリアされるため、別の管理者ユーザーが元の権限をユーザーに付与する必要があります。
ACCESS POLICY ADMINISTRATORSロールを持たないOIMユーザーは、次のレポートのデータを表示できません。
アクセス・ポリシー詳細
ロール別のアクセス・ポリシー・リスト
この問題を回避するには、次の手順を実行します。
ACCESS POLICY ADMINISTRATORSロールをOIMユーザーに割り当てます。
手順1と同じユーザー名を使用してBI Publisherユーザーを作成します。レポートを表示するのに適したBI Publisherロールを割り当てます。
手順2のBI Publisherユーザーとしてログインします。「アクセス・ポリシー詳細」レポートおよび「ロール別のアクセス・ポリシー・リスト」レポートを表示します。すべてのアクセス・ポリシーが表示されます。
日付が空の場合、アーカイブ・ユーティリティによってエラー・メッセージがスローされますが、現在の日付にマップしてデータのアーカイブが続行されます。現在、この問題を回避する方法はありません。
デフォルト値を使用してユーザー定義フィールド(UDF)が作成された場合、ダイレクト・プロビジョニング時にTransUIが閉じます。この問題を回避するには、LKU/LKV表でINTEGER/DOUBLE型のUDFの参照コードを作成する必要があります。
AIXプラットフォームでは、スケジューラ・ジョブの作成時に必要なパラメータがない場合、「スケジュル・タスクの必須パラメータに値が設定されていません。」エラー・メッセージとともにRequiredParameterNotSetExceptionがスローされるのではなく、かわりに「パラメータ値が正しく設定されていません。」エラー・メッセージとともにParameterValueTypeNotSupportedExceptionがスローされます。現在、この問題を回避する方法はありません。
Oracle Identity Manager 11gには新規のユーザー属性が追加されています。その一部は、ユーザー・スコープを定義する際にアテステーションに使用できません。ただし、アテステーションが拡張され次のユーザー属性が追加されています。
USR_COUNTRY
USR_LDAP_ORGANIZATION
USR_LDAP_ORGANIZATION_UNIT
USR_LDAP_GUID
現在、この問題を回避する方法はありません。
LDAP-SYNCが有効なインストールで、信頼されているリソースのいずれかのフィールドにLDAP GUIDがマップされている場合、更新が失敗します。この問題を回避するために、信頼されているリソースのリコンシリエーション・フィールド・マッピングを作成する際には、LDAP GUIDフィールドをマッピングしないことをお薦めします。
変更リクエストが要求された場合、「Design Consoleのアクセス」フィールドに「エンドユーザー」および「エンドユーザー管理者」の値が表示されます。これらの値は、ユーザー詳細を解釈する際にFalseまたはTrueにマップされる必要があります。
承認ポリシー・ルールにASCII以外の文字が含まれる場合、デプロイメント・マネージャでポリシーをエクスポートした後、これらの文字がUIに正しく表示されない可能性があります。
現在、この問題を回避する方法はありません。
ユーザーの作成後、アスタリスク(*)を含む類似した名前のユーザーを作成しようとすると失敗します。たとえば、test1testというユーザーの作成後にtest*testを作成しようとしても作成できません。
「ユーザー・ログイン」フィールドではアスタリスクを含むユーザーを作成しないことをお薦めします。
「過去のプロキシ」ページの「ステータス」フィールドは空白です。ただし、「現行のプロキシ」ページでは、アクティブなプロキシが正しく表示されます。
現在、この問題を回避する方法はありません。
「パスワード」フィールドは、リコンシリエーション・プロファイルでマップ可能ですが、使用しないでください。このフィールドをマップしようとすると、ユーザーを作成しないリコンシリエーション・イベントが生成されます。(このイベントは、一致するものが見つからない状態で終了します。)また、このイベントを再評価したり、手動でリンクすることもできません。
拡張管理の「検索構成」ページの「検索結果表構成」リストからUID属性を選択できますが、「拡張検索: ユーザー」の結果表には「UID」フィールドのかわりに「ユーザー・ログイン」フィールドが表示されます。
組織を削除すると、組織およびロールの参照ツリーが表示されなくなる場合があります。
この問題を回避するには、「検索結果」タブ→「参照」タブの順にクリックします。ロールおよび組織の参照ツリーが正しく表示されます。
プロセス・フォームでデータを収集する際の権限(子表)の選択は、「依存先」属性に関してはオプションではありません。依存参照が構成されている場合、データ収集時にユーザーは親参照値を選択する必要があります。これは、子参照のフィルタ処理が実行され、選択する権限の最終リストを取得できるようにするためです。現在、子参照に基づいて値を直接フィルタ処理するための回避方法はありません。
デプロイメント・マネージャのインポート、手動によるプロファイル変更、またはDesign Console経由のプロファイル変更が発生するたびに、サーバー・ログに一般例外が表示されます。これは、WLSINTERNALがOracle Identity Managerの認可されたユーザーではないためです。WLSINTERNALはWebLogic Serverの内部ユーザーであり、MDSに格納されているXMLに変更があった場合に、MDSがMDSリスナーを起動する際に使用されます。現在、この問題を回避する方法はありません。
「ユーザーの作成」APIでは、ユーザー.パスワードの有効期限なし、ユーザー.パスワードの変更不可およびユーザー.パスワードの変更が必要フィールドに対して、0か1ではなく、0〜9までの任意の値を設定できます。ただし、0以外の値はTRUE、0はFALSEとみなされ、作成されるユーザーに応じてフラグが設定されます。現在、この問題を回避する方法はありません。
2つのリソースをプロビジョニングする際に、一方のリソースが他方に依存する場合、最初に依存される側のリソースでユーザーの承認およびプロビジョニングを行う必要があります。たとえば、ユーザーにMicrosoft ExchangeおよびActive Directoryをプロビジョニングする場合、最初にActive Directoryユーザーの承認とプロビジョニングを行う必要があります。Exchangeではリクエスト時に提供されるデータが必要なため、Active Directoryより先に承認されるとデータが失われます。
この状況を回避するには、Exchangeに対して別のリクエストを作成する必要があります。その際は、Exchangeに対して1つのリクエスト承認タスクを要求します。これは、ユーザーにActive Directoryがすでにプロビジョニングされているためです。リクエスト・タスクの承認後、Exchangeのプロビジョニングが実行されます。
JGraph画面の「ユーザー・タイプ」ラベルが、誤って「Design Consoleのアクセス」と表示されます。「ユーザー・タイプ」と表示するには、OIM_HOME/server/customResources/customResources.propertiesファイルにXellerate_Type=User Type
行を追加します。
Oracle Identity Managerのクラスタ化デプロイメントでワークフロー登録ユーティリティを実行すると、次のエラーが生成されます。
[java] oracle.iam.platform.utils.NoSuchServiceException: java.lang.reflect.InvocationTargetException
このエラー・メッセージは無視してください。
Solaris 64ビット・コンピュータ上のOracle Identity Manager JVMインストールでは、Oracle WebLogicのログに次のエラーが表示されます。
Unable to load performance pack. Using Java I/O instead. Please ensure that a native performance library is in:
この問題を回避するには、JDKによって64ビットのネイティブ・パフォーマンスが確実に選択されるように、次の手順を実行します。
テキスト・エディタでMIDDLEWARE_HOME/wlserver_10.3/common/bin/commEnv.shファイルを開きます。
次のテキストを探します。
SUN_ARCH_DATA_MODEL="32"
これを次のテキストに置き換えます。
SUN_ARCH_DATA_MODEL="64"
commEnv.shファイルを保存して閉じます。
アプリケーション・サーバーを再起動します。
汎用テクノロジ・コネクタの作成ウィザードでデータベースの不正な資格証明を入力すると、システム・エラー・ウィンドウが表示されます。このウィンドウを閉じてウィザードを再実行する必要があります。
Oracle Identity Manager 11gリリース 1(11.1.1)では、SPML WebサービスのDSMLプロファイルはデフォルトでデプロイされません。Microsoft Active Directory Password Synchronizationをサポートするために、SPML-DSMLバイナリはOracle Identity Managerインストーラとバンドルされています。spml-dsml.earファイルを手動でデプロイする必要があります。
新規ヒューマン・タスクを既存のSOAコンポジットに追加する場合は、元のヒューマン・タスクに含まれる属性のすべてのコピー操作を新規ヒューマン・タスクに追加する必要があります。追加されていない場合、「タスクの詳細の表示」ページにエラーが表示される可能性があります。
プロビジョニング済リソースの変更リクエストを介して標準アカウントをサービス・アカウントに変更することはできません。同様に、サービス・アカウントを標準アカウントに変更することもできません。
この項では、構成に関する問題およびその回避方法について説明します。内容は次のとおりです。
ADFの問題により、Sun JDKでOracle Identity Managerを使用するとStringIndexOutOfBoundsExceptionエラーが発生します。この問題を回避するには、DOMAIN_HOME/bin/setSOADomainEnv.shまたはsetSOADomainEnv.cmdファイルに次のオプションを追加します。
DOMAIN_HOME/bin/setSOADomainEnv.shまたはsetSOADomainEnv.cmdファイルを開きます。
JVMオプションに-XX:-UseSSE42Intrinsics行を追加します。
setSOADomainEnv.shまたはsetSOADomainEnv.cmdファイルを保存します。
注意: JRockitを使用する場合にはこのエラーは発生しません。 |
Oracle Identity ManagerとOracle Access Manager(OAM)が統合された環境では、Oracle Identity Manager管理およびユーザー・コンソールにログインしてNexawebアプレットを開くためのリンクをクリックしても、アプレットがロードされません。
この問題を回避するには、Oracle Identity ManagerとOAMの統合環境でNexaWebアプレットのロードを構成します。これを行うには、次の手順を実行します。
Oracle Access Managerコンソールにログインします。
次の手順で新規WebゲートIDを作成します。
「システム構成」タブをクリックします。
10Webゲート→「作成」アイコンの順にクリックします。
次の属性の値を指定します。
名前: NAME_OF_NEW_WEBGATE_ID
アクセス・クライアント・パスワード: PASSWORD_FOR_ACCESSING_CLIENT
ホスト識別子: IDMDomain
「適用」をクリックします。
WebゲートIDを次のように編集します。
set 'Logout URL' = /oamsso/logout.html
「保護されていない場合に拒否」チェック・ボックスを選択解除します。
2つ目のOracle HTTP Server(OHS)およびWebゲートをインストールします。Webゲートの構成中にWebゲートIDおよびパスワードを要求された場合は、手順2cで指定した2つ目のWebゲートのWebゲートID名およびパスワードを使用します。
Oracle Access Managerコンソールにログインします。「ポリシー構成」タブで「アプリケーション・ドメイン」を展開し、IdMDomainAgentを開きます。
「認証ポリシー」を展開してパブリック・ポリシーを開きます。「リソース」タブで次のURLを削除します。
/xlWebApp/.../*
/xlWebApp
/Nexaweb/.../*
/Nexaweb
「認可ポリシー」を展開して保護リソース・ポリシーを開きます。「リソース」タブで次のURLを削除します。
/xlWebApp/.../*
/xlWebApp
/Nexaweb/.../*
/Nexaweb
すべてのサーバーを再起動します。
2つ目のWebゲートのobAccessClient.xmlファイルを更新します。これを行うには、次の手順を実行します。
SECOND_WEBGATE_HOME/access/oblix/lib/ObAccessClient.xmlファイルのバックアップを作成します。
DOMAIN_HOME/output/WEBGATE_ID_FOR_SECOND_WEBGATE/ObAccessClient.xmlファイルを開きます。
注意: DenyOnNotProtectedパラメータが0に設定されていることを確認してください。 |
DOMAIN_HOME/output/WEBGATE_ID_FOR_SECOND_WEBGATE/ObAccessClient.xmlファイルをSECOND_WEBGATE_HOME/access/oblix/lib/ディレクトリにコピーします。
FIRST_OHS_INSTANCE_HOME/config/OHS_NAME/ディレクトリからSECOND_OHS_INSTANCE_HOME/config/OHS_NAME/ディレクトリへ、mod_wls_ohs.confをコピーします。さらに、2つ目のOHSのmod_wls_host.confを開いて、WebLogicHostおよびWeblogicPortによってOracle Identity Managerの管理対象サーバーのホストとポートが引き続き指定されていることを確認します。
SECOND_OHS_INSTANCE_HOME/config/OHS_NAME/httpd.confファイルの次の行を削除するか、コメント・アウトします。
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
FIRST_WEBGATE_HOME/access/oamsso/ディレクトリからSECOND_WEBGATE_HOME/access/oamsso/ディレクトリへ、logout.htmlファイルをコピーします。さらに、2つ目のWebゲートのlogout.htmlファイルを開いて、SERVER_LOGOUTURL変数のホストとポートの設定がOAMの正しいホストとポートを指定していることを確認します。
Oracle Access Managerコンソールにログインします。「ポリシー構成」タブで「ホスト識別子」を展開し、2つ目のWebゲートID名と同じ名前のホスト識別子を開きます。「操作」セクションで、2つ目のOHSのホストとポートがリストされていることを確認します。リストされていない場合は、追加アイコン(+記号)をクリックして追加します。さらに「適用」をクリックします。
Oracle Identity ManagerのOAMログイン・ページのURLに、2つ目のOHSのホストとポートを使用します。このURLは次の書式で記述する必要があります。
http://SECOND_OHS_HOST:SECOND_OHS_PORT/admin/faces/pages/Admin.jspx
ドメインがmanaged=falseオプションを使用して圧縮され、別のコンピュータ上で解凍される場合、Oracle Identity Managerの認証プロバイダがWebLogicによって認識されず、Oracle Identity Managerの管理対象サーバーの起動時に、基本の管理者認証が失敗します。
Oracle Identity Managerの認証プロバイダを介して認証を正常に実行させるには、次の回避方法を適用できます。
次のURLを使用してOracle WebLogic管理コンソールにログインします。
http://HOST_NAME:ADMIN_PORT/console
「セキュリティ・レルム」→Realm(myrealm)→「プロバイダ」の順にナビゲートします。
OIMAuthenticationProviderを削除します。
注意: プロバイダを削除する前に、プロバイダ固有の詳細(データベースURL、パスワードおよびドライバなど)をメモしておいてください。 |
WebLogic管理サーバーを再起動します。
「セキュリティ・レルム」→Realm(myrealm)→「プロバイダ」の順にナビゲートします。
タイプOIMAuthenticationProviderの新規認証プロバイダを作成します。
プロバイダ固有の詳細を入力し、制御フラグをSUFFICIENTとマーク付けします。
WebLogic管理サーバーを再起動します。
Oracle Identity Managerおよび他のサーバー(存在する場合)を再起動します。
Oracle Identity Manager Design Consoleの構成時に、Design ConsoleをSSL対応にするかどうかを指定できません。
この問題を回避するには、Oracle Identity Manager Design Consoleのインストール後にOIM_HOME/designconsole/config/xlconfig.xmlファイルを編集して、Oracle Identity Manager URLのプロトコルをt3からt3sに変更します。
クライアント・ブラウザにJDK/JREバージョン1.6.0_20がインストールされている場合、デプロイメント・マネージャおよびワークフロー・ビジュアライザが機能しない場合があります。この問題を回避するには、クライアント・ブラウザからJDK/JREバージョン1.6.0_20をアンインストールし、JDK/JREバージョン1.6.0_15を再インストールします。
この項では、多言語の問題および制限について説明します。内容は次のとおりです。
Oracle Identity Managerでは、多言語値に対して「表示名」属性のみがサポートされます。SPMLでは、commonNameやsurnameなどの追加の属性がPSOスキーマで多言語値として指定されます。SPMLリクエストでこれらの属性のいずれかに対して複数のロケール値が指定されている場合は、単一の値のみが選択され、Oracle Identity Managerに渡されます。リクエストは失敗せず、属性およびOracle Identity Managerに渡された値を識別する警告メッセージがレスポンスに含まれます。
Oracle Identity Managerでは、ユーザー・ログイン名の大/小文字は区別されません。ユーザーが作成されると、ログイン名は大文字に変換されてデータベースに保存されます。一方、パスワードは常に大/小文字が区別されます。ただし、Oracle Identity Managerへの登録時に、次の一部の特殊文字によってエラーが発生します。
ギリシャ文字σ(シグマ)およびς(ファイナル・シグマ)は、いずれも文字Σにマップされます。
英文字iおよびトルコ文字ıは、いずれも文字Iにマップされます。
ドイツ文字ßおよび英文字列SSは、いずれも文字列SSにマップされます。
そのため、これらの特殊文字を含み、その他の文字が同じである2つのユーザー・ログイン名は作成できません。たとえば、ユーザー・ログイン名のJohnßとJohnSSは、同じユーザー・ログイン名にマップされます。文字ßと文字列SSはいずれも文字列SSにマップされるため、Johnßがすでに存在する場合、JohnSSの作成は許可されません。
「ロールの作成」、「ロールの変更」および「ロールの削除」リクエスト・テンプレートは、リクエストの作成ウィザードの「リクエスト・テンプレート」リストでは使用できません。これは、「ロールの作成」、「ロールの変更」および「ロールの削除」リクエスト・モデルに基づくリクエスト・テンプレートを使用したリクエストの作成は、UIではなく、APIからサポートされるためです。ただし、「リクエスト・テンプレート」タブではこれらのリクエスト・テンプレートを検索できます。さらに、「ロールの作成」、「ロールの変更」および「ロールの削除」リクエスト・モデルは、承認ポリシーおよび新規リクエスト・テンプレートの作成に使用できます。
Oracle Identity Manager拡張管理の「ジョブの作成」ページでは、「パラメータ」セクションのフィールドおよび値が翻訳されていません。パラメータ・フィールドの名前および値は、英語のみで表示されます。
xlWebApp warファイルに含まれるレガシー・ユーザー・インタフェース(TransUIとも呼ばれる)の既知の問題を次に示します。
ヘブライ語の双方向性はサポートされていません。
アラビア語およびヘブライ語のワークフロー・デザイナの双方向性はサポートされていません。
ロール名、カテゴリおよび説明のローカライズは、このリリースではサポートされていません。
プロビジョニング・タスク表リストの「タスク名」のすべての値はハードコードされており、これらの事前定義済プロセス・タスクの名前はローカライズされていません。
単純検索または拡張検索を使用してスケジューラ・タスクを検索した場合の検索結果はローカライズされていません。
タスク承認検索ページで「割り当てられたタスクの表示」→「自分が管理するユーザー」の順に選択し、ログイン名にトルコ文字のı(点なし)またはİ(点あり)が含まれているユーザーを選択すると、ユーザーが見つからないというエラーが発生します。
通知テンプレートの「使用可能なデータ」リスト値のローカライズは、このリリースではサポートされていません。Oracle Identity Managerは、トークンと実際の値のマージをVelocityフレームワークに依存していますが、Velocityフレームワークではトークン名でのスペースの使用が許可されていません。
特殊なドイツ文字ß(ベータ)を含むエンティティ名を管理コンソールから検索した場合、次の機能で検索が失敗します。
システム構成
リクエスト・テンプレート
承認ポリシー
通知
これらの機能では、文字ßは、その文字自体ではなくssと一致します。そのため、検索機能ではドイツのベータ文字を含むエンティティ名を検出できません。
Oracle Identity Managerでは特殊文字がサポートされていますが、アスタリスク(*)の使用によって問題が発生する場合があります。ユーザー・ロールおよび組織の作成または変更時には、アスタリスクを使用しないことをお薦めします。
Oracle Identity Managerでは、ユーザー・インタフェースでのエラー・メッセージ表示のカスタム・リソース・バンドルはサポートされていません。現在のところ、この問題の回避方法はありません。
リコンシリエーション・イベント詳細ページの一部の表データ文字列は、ハードコードされたカスタマイズ済フィールド名です。これらの文字列はローカライズされていません。
Oracle Bug#9539501に従って記載されています。
パスワード・ポリシーのヘルプの説明は、文字列が長すぎる場合や一部の言語で、色の付いたボックスの外にはみ出す場合があります。現在、この問題を回避する方法はありません。
双方向言語でジョブの詳細ページを開くと、日付書式検証エラーによってこのページから別の場所にナビゲートできなくなります。この問題を回避するには、日時コントロールを使用して「開始日」の値を選択し、別のページに移動します。
日本語ロケール(LANG=ja_JP.UTF-8)では、「ジョブの作成」ページのFourth Wednesdayが、誤って「第4金曜日」と翻訳されています。これは、「スケジュール・タイプ」で「cron」を選択し、「定期実行間隔」で「毎月指定曜日」を選択した場合に表示されます。
ドキュメントの訂正箇所: 現時点ではドキュメントの問題はありません。