| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.2.1) E72537-01 |
|
 前 |
| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.2.1) E72537-01 |
|
前 |
この付録では、OPSSの構成および使用時に発生する可能性のある一般的な問題と、その解決方法について説明します。
次の項が含まれます:
OPSSには、問題の解決時間を短縮できるよう支援するフレームワークが組み込まれています。このフレームワークでは、ドメインの内部状態を抽出し、その情報をファイルにダンプできます。フレームワークには、そのドメイン内のドメイン・サーバーおよびドメイン・サービスの特性を記録するダンプを生成するためのテストが多数用意されています。
OPSS診断フレームワークに用意されているテストは次のとおりです。
構成テスト
oracle.security.jps.diag.test.JpsConfigTest
接続テスト
oracle.security.jps.diag.test.JpsContainerAuthenticationLdapConnectivityTest
oracle.security.jps.diag.test.JpsIdentityStoreUserRoleApiLdapConnectivityTest
資格証明ストア・テスト
oracle.security.jps.diag.test.JpsCredentialStoreConfigTest
oracle.security.jps.diag.test.JpsCredentialStoreTest
アイデンティティ・ストア・テスト
oracle.security.jps.diag.test.JpsIdentityStoreIDSSearchTest
oracle.security.jps.diag.test.JpsIdentityStoreLibOvdConfigTest
oracle.security.jps.diag.test.JpsIdentityStoreUserRoleApiSearchTest
キーストア・テスト
oracle.security.jps.diag.test.JpsKeyStoreTest
oracle.security.jps.diag.test.JpsKeyStoreConfigTest
テストの実行
テストをコールするには、次の構文でexecuteDumpコマンドを使用します。
executeDump(name='opss.diagTest', outputFile='dumpLocation', args={'testtname':'testName'})
説明:
最初の引数name='opss.diagTest'は変更できません。
outputFileでは、ダンプの生成場所を、コマンドが実行される場所を基準とした相対パスで指定します。
3つ目の引数の文字列はすべて決まっていますが、testName文字列は例外で、テストの1つを設定します。ワイルドカード(*)を使用すると、すべてのテストが次の順序で実行されます。
oracle.security.jps.diag.test.JpsConfigTest oracle.security.jps.diag.test.JpsContainerAuthenticationLdapConnectivityTest oracle.security.jps.diag.test.JpsCredentialStoreConfigTest oracle.security.jps.diag.test.JpsCredentialStoreTest oracle.security.jps.diag.test.JpsIdentityStoreIDSSearchTest oracle.security.jps.diag.test.JpsIdentityStoreLibOvdConfigTest oracle.security.jps.diag.test.JpsIdentityStoreUserRoleApiLdapConnectivityTest oracle.security.jps.diag.test.JpsIdentityStoreUserRoleApiSearchTest oracle.security.jps.diag.test.JpsKeyStoreConfigTest oracle.security.jps.diag.test.JpsKeyStoreTest
使用例
診断フレームワークを使用する状況の流れは、次のとおりです。
顧客から問題を受け取ります。
ログに記録された障害から、問題が(たとえば)接続に関係していると判断します。
問題になっているドメインで、oracle.security.jps.diag.test.JpsContainerAuthenticationLdapConnectivityTestなど、テストを1つ以上実行します。
Oracle WebLogic Serverに接続します。
wls:/offline> connect('adminuser', 'adminpass', 't3://localhost:7001')
次のように、テストをコールします。
>executeDump(name='opss.diagTest', outputFile='myDumpTest',
args={'testname': 'oracle.security.jps.diag.test.JpsContainerAuthenticationLdapConnectivityTest'})
テストにより、指定の場所にダンプが生成されます。ダンプに、次の行が含まれています。
LDAP authenticator : OID
host : myHost.com
port : 7066
principal : cn=orcladmin
password : ********
Is SSL? false
Testing LDAP connection to ldap://myHost.com:7066 with principal cn=orcladmin.
JNDI settings:
java.naming.provider.url = ldap://myHost.com:7066
java.naming.factory.initial = com.sun.jndi.ldap.LdapCtxFactory
com.sun.jndi.ldap.connect.timeout = 5000
java.naming.security.principal = cn=orcladmin
java.naming.security.authentication = simple
java.naming.security.credentials = ********
Failed to establish LDAP connection to ldap://myHost.com:7066.
The stack trace:
javax.naming.CommunicationException: myHost.com:7066 [Root exception is java.net.ConnectException: Connection refused]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:214) …
エラーおよび障害がないかダンプを調べます。この例では、太字のテキストはLDAPプロバイダへの接続を確立できなかったことを示しています。
OPSS診断フレームワークに加えて、次の各項で説明しているように、ロガーを使用して様々なセキュリティ問題を診断して解決します。
次の各項では、OPSSでサポートされているログ・ファイルとロガーを紹介し、Fusion Middleware ControlおよびWebLogic Scripting Tool (WLST)を使用して、ロガー・レベルを構成および設定する方法と、ログ・ファイルを表示する方法について説明します。
ドメイン内の各サーバー・インスタンスは、アプリケーションで発生したOPSS例外をすべて、ローカル・ホスト・コンピュータのファイル・システムにあるサーバー・ログ・ファイルに書き込みます。
デフォルトでは、このログ・ファイルは、サーバー・インスタンス・ルート・ディレクトリの下のlogsディレクトリにあります。これらのログ・ファイルの名前の形式は、ServerName-diagnostic.logxxxxxとなっています。ここで、xxxxxは1から99999の整数を示します。
サーバーは、セキュリティ関連のエラーを診断ファイルに書き込みます。サーバー関連のセキュリティ・エラー(サブジェクトやプリンシパルの問題で発生した例外など)やドメイン・セキュリティ・データの移行または再関連付けのときに発生するエラーは、管理サーバー診断ログに書き込まれます。アプリケーション関連のセキュリティ・エラー(アプリケーション固有のポリシーまたは資格証明で発生した例外など)は、アプリケーションが実行されている管理対象サーバーの診断ログに書き込まれます。
デフォルトでは、サーバー・ログ・ファイルは、診断ログ・ファイルと同様に、サーバー・インスタンス・ルート・ディレクトリの下のlogsディレクトリにあります。ドメイン・ログ・ファイルは、管理サーバー・ルート・ディレクトリの下のlogsディレクトリにあります。これらのログ・ファイルの名前の形式は、ServerName.logxxxxxおよびdomain.logxxxxxとなっています。ここで、xxxxxは1から99999の整数を示します。
ドメイン・ログは、サーバー・ログのメッセージと一部重複しており、多数のサーバーで構成されたドメインで障害が発生したサーバーを特定するのに役立ちます。
新しいログ・ファイルの生成は、ファイル・サイズによって決まります。ログ・ファイルが指定されたサイズを超えると、整数の接尾辞が1つ増えた名前を持つ、新しいログ・ファイルが生成されます。
|
関連項目: 『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のサーバー・ログ・ファイルとドメイン・ログ・ファイルに関する項 Oracle WebLogic Server診断フレームワークの構成と使用 Oracle WebLogic ServerにデプロイされたアプリケーションへのWebLogicロギング・サービスの追加 『Oracle Fusion Middlewareの管理』の「ログ・ファイルと診断データの管理」 |
オンラインWLSTコマンドの場合、ロギングは自動ですが、オフライン・コマンドの場合は自動ではありません。migrateSecurityStoreコマンドなどのオフライン・コマンドの使用時には、次のシステム・プロパティを指定してJava仮想マシン(JVM)を起動することにより、ロギングを有効にします。
wlst.offiline.log: <filename>、stdout、sterrまたはdisableのいずれかの値を指定します。指定しない場合、ログ・ファイルは$MW_HOME/logsディレクトリに置かれます。
wlst.offline.log.priority: OFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST、ALL、debug、info、warn、error、fatalのいずれかの値を指定します。
次の各項では、サービスごとに使用可能なロガーを示します。
サーバーを停止して再起動しなくても、ロガーを有効および無効にできます。通常、ロガーのレベルはTRACE:32に設定します。
OPSSでは、実行時の認可の失敗をトラブルシューティングするのに役立つロガーがいくつか用意されています。
oracle.security.jps.util.JpsAuth - checkPermissionの起動とリターンをログに記録します。
oracle.security.jps.trace.logger - アプリケーション・ロール、パーミッション、ターゲット、プリンシパルおよび付与されたポリシーと拒否されたポリシーに関する情報をログに記録します。このロガーは、大規模な出力を生成します。単一のユースケースのデバッグにのみ使用します。
oracle.jps.authorization - 実行時の認可中のメッセージをログに記録します。
oracle.jps.common - サービス管理やユーザー管理など、OPSS共通機能領域でのメッセージをログに記録します。
oracle.security.jps.dbg.logger - JpsFilterフィルタ・パーミッション・チェックのデバッグに使用されるメッセージをログに記録します。
oracle.security.jps.az.internal.runtime.policy.AbstractPolicyImpl - oracle.security.jps.az.internal.runtime.policy.AbstractPolicyImplクラスのメッセージをログに記録します。
oracle.security.jps.internal.policystore.JavaPolicyProvider - oracle.security.jps.internal.policystore.JavaPolicyProviderクラスのメッセージをログに記録します。
この項では、監査ログ・メッセージを解釈する方法と、それらのメッセージを使用してコンポーネントの障害を診断する方法について説明します。ログ・ファイルの場所は次のとおりです。
DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log
表J-1に、使用可能な診断ログ・ファイルを示します。
表J-1 監査診断のログ・ファイル
| コンポーネント | ログの保存場所 | ロガーの構成 |
|---|---|---|
|
Java EEコンポーネント |
DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log |
oracle.security.audit.logger(この表の下の手順を参照) |
|
OPMNコンポーネント |
第J.2.2.2項を参照してください。 |
第J.2.2.2項を参照してください。 |
|
起動クラス監査ローダー |
DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log |
oracle.security.audit.logger(この表の下の手順を参照) |
|
OPMN監査ローダー |
$ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/rmd.out |
java.util.logging.config.fileシステム・プロパティを、OPMN監査ローダーのログ・レベルを含むファイルに設定できます。 |
|
構成/プロキシMbeans |
DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log |
oracle.security.audit.logger(この表の下の手順を参照) |
|
監査スキーマ・サポート |
Oracle Fusion Middlewareリポジトリ作成ユーティリティのログの場所(デフォルトでは$ORACLE_HOME/rcu/log/)。RCU_LOG_LOCATIONを設定すると、この場所を変更できます。 |
リポジトリ作成ユーティリティのログ・レベル。デフォルトは、ERRORです。 |
監査ロガーの構成
Fusion Middleware Controlを使用して、oracle.security.audit.loggerロガーを構成し、ロガーを表示します。ログ・ファイルの詳細は、『Oracle Fusion Middlewareの管理』の「ログ・ファイルと診断データの管理」を参照してください。
監査エラー・メッセージには、IAU-XXXという番号が付けられます。
OPMNで管理されるシステム・コンポーネントの監査ロギングを構成するには、auditconfig.xmlファイルを編集して、コンポーネントの監査ログが書き込まれるログ・ディレクトリの場所を指定します。
<LogsDirectory> <MaxFileSize></MaxFileSize> <Location>/tmp/audit/auditlogs</Location> </LogsDirectory>
OPSSのユーザーおよびロールAPIコールを追跡するには、oracle.idm.userroleapiロガーをTRACE:32に設定します。
加えて、OPSSには次のロガーも用意されています。
oracle.jps.deploymentは、アプリケーションのデプロイ時に、アプリケーションとともにパックされたOPSSアーティファクトに関する問題をログに記録します。
oracle.jps.openazは、PEP APIコールに関する問題をログに記録します。oracle.jps.openaz.levelをFINESTに設定すると、送信されたリクエストに関する情報(アイデンティティ、リソース、アクション、コンテキスト)および認可結果が記録されます。
oracle.jps.attributeは、OPSS属性サービスに関する問題をログに記録します。
次のプロパティを使用して、サーバー起動時のデバッグを構成します。
jps.auth.debug: 失敗したパーミッション・チェックのみをログに記録します。パーミッション・チェックのメッセージを無効にするには、このプロパティをfalseに設定します。デフォルトは、trueです。
jps.auth.debug.verbose: 失敗したパーミッション・チェックをログに記録します。jps.auth.debubよりも多くの情報をログに記録します。デフォルトは、falseです。
DebugOPSSPolicyLoading: ポリシー・プロバイダの進行状況と設定を監視するフラグ。
java.security.debug=policy: ファイル・システムでの場所、付与するパーミッション、使用する証明書など、解析したとおりにポリシー・ファイルに関する印刷情報を生成する、標準のJavaセキュリティ・デバッグ・フラグ。
setDomainEnv.shスクリプトを編集し、必要なプロパティをシステム・プロパティEXTRA_JAVA_PROPERTIESに追加します。この変更には、サーバーの再起動が必要です。
|
注意: ロギング出力を高く設定すると、特にファイルのロード時に、スレッドがスタックする可能性があります。この状況を回避するには、WebLogic Serverでスレッドをスタックとマークするために使用するタイムアウト値を、さらに高い値に変更します。 |
その他のシステム・プロパティ
デバッグに役立つその他のシステム・プロパティは、次のとおりです。
oracle.security.jps.log.for.approle.substring: 指定した部分文字列が含まれるアプリケーション・ロールの名前をログに記録します。照合する部分文字列を指定しないと、すべてのアプリケーション・ロール名がログに記録されます。
oracle.security.jps.log.for.permeffect: 付与または拒否された権限をログに記録します。値を指定しないと、(付与または拒否にかかわらず)すべての権限がログに記録されます。
oracle.security.jps.log.for.permclassname: 指定した名前に完全一致するパーミッション・クラスの名前をログに記録します。照合する名前を指定しないと、すべてのパーミッション・クラス名がログに記録されます。
oracle.security.jps.log.for.permtarget.substring: 指定した部分文字列が含まれるパーミッション・ターゲットの名前をログに記録します。照合する部分文字列を指定しないと、すべてのパーミッション・ターゲットがログに記録されます。
oracle.security.jps.log.for.enterprise.principalname: 指定した名前に完全一致するプリンシパル(エンタープライズ・ユーザーまたはエンタープライズ・ロール)の名前をログに記録します。照合する名前を指定しないと、すべてのプリンシパル名がログに記録されます。
使用例
次の例では、システム・プロパティの一般的な設定を示します。
文字列myAppRoleが含まれるすべてのアプリケーション・ロール名をログに記録するには、次のようにします。
-Doracle.security.jps.log.for.approle.substring=myAppRole
拒否されたすべてのパーミッション・チェックをログに記録するには、次のようにします。
-Doracle.security.jps.log.for.permeffect=deny
付与されたすべてのパーミッション・チェックをログに記録するには、次のようにします。
-Doracle.security.jps.log.for.permeffect=grant
付与されたか、または拒否されたすべてのパーミッション・チェックをログに記録するには、oracle.security.jps.log.for.permeffectは設定しません。
java.util.PropertyPermissionに完全一致するすべてのパーミッション・チェックをログに記録するには、次のようにします。
-Doracle.security.jps.log.for.permclassname=java.util.PropertyPermission
文字列p.monが含まれるすべてのターゲット名をログに記録するには、次のようにします。
-Doracle.security.jps.log.for.permtarget.substring=p.mon
プリンシパル名managerに関連するすべての認可をログに記録するには、次のようにします。
-Doracle.security.jps.log.for.enterprise.principalname=manager
部分文字列に一致するアプリケーション・ロール名または文字列に一致するプリンシパル名をログに記録するには、oracle.security.jps.log.for.approle.substringとoracle.security.jps.log.for.enterprise.principalnameの両方を使用します。
エラーを分離して解決するには、ログ・エラーを理解することが重要です。この項では、次のような診断ログ・ファイルの内容を解釈する方法について説明します。
[2009-01-07T09:15:02.393-08:00] [AdminServer] [ERROR] [JPS-00004] [oracle.jps.admin]
[tid: [ACTIVE].ExecuteThread: '3' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: weblogic] [ecid: 0000Hum5kxw7MAn54nU4Ui19PD8S000005,0]
Unable to add principal to the application role. Reason: Principal
"abc.xxx@myComp.com" is already a member of the application role
"BPMWorkflowAdmin"[[
java.security.PrivilegedActionException:
oracle.security.jps.service.policystore.PolicyObjectAlreadyExistsException:
Unable to add principal to the application role. Reason: Principal "abc.xxx@myComp.com" is already a member of the application role
"BPMWorkflowAdmin"
at java.security.AccessController.doPrivileged(Native Method)
at oracle.security.jps.mas.mgmt.jmx.policy.JpsApplicationPolicyStoreImpl.
addRemoveMembersToRole(JpsApplicationPolicyStoreImpl.java:408)
at oracle.security.jps.mas.mgmt.jmx.policy.JpsApplicationPolicyStoreImpl.
addMembersToApplicationRole(JpsApplicationPolicyStoreImpl.java:385)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
前述のメッセージの各フィールドの意味は、次のとおりです。
[2009-01-07T09:15:02.393-08:00]
エラーがログに記録された日時を識別します。
[AdminServer]
エラーが発生したサーバーの名前を識別します。
[JPS-00004]
エラー・コードを識別し、発生したエラーの種類に関するヒントを示します。すべてのJPSエラー・コードのリストについては、エラー・メッセージの第41章を参照してください。
[oracle.jps.admin]
ロガー・カテゴリを識別します。oracle.jpsのサブカテゴリ(adminなど)は、発生したエラーの種類を示します。これには次の機能が含まれます。
common - 一般的なエラー
upgrade - アップグレード・エラー
config - 構成エラー
deployment - デプロイ・エラー
authentication - ログイン・モジュール・エラー(Java SEアプリケーションのみ)
idmgmt - アイデンティティ・ストア・エラー。
credstore - 資格証明ストア・エラー。
authorization - 実行時のポリシー・ストア・エラー
policymgmt - ポリシー・ストア管理エラー。
admin - JMXエラーおよびWLSTエラー。
[tid: [ACTIVE].ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)']
エラーが発生したスレッドを識別します。
[userId: weblogic]
エラーを生成した操作を実行したユーザーを識別します。
[ecid: 0000Hum5kxw7MAn54nU4Ui19PD8S000005,0]
実行コンテキストIDを識別します。イベントの順序を相互に関連付けて追跡します。実行コンテキストID (ECID)は、リクエストからWebLogic ServerやOIDサーバーへなど、プロセスをまたがるフローに関する情報を提供します。
Unable to add principal to the application role. Reason: Principal abc.xxx@myComp.com is already a member of the application role BPMWorkflowAdmin
エラーがログに記録された理由を識別します。
java.security.PrivilegedActionException: oracle.security.jps.service.policystore.PolicyObjectAlreadyExistsException: Unable to add principal to the application role. Reason: Principal abc.xxx@myComp.com is already a member of the application role BPMWorkflowAdmin
発生した例外とその理由を識別します。
次の各項では、データベース・セキュリティ操作の問題について説明します。
この項では、ファイルからLDAPストアへの再関連付けに失敗する3つの理由について説明します。
現象1- エラー・コード32
再関連付けが失敗し、次のようなエラーがMyServerName.diagnostic.logファイルに記録されます。
[LDAP: error code 32 - No Such Object] Authentication to LDAP server ldap://myServer.com:3060 is unsuccessful.
診断1
このエラーは、指定されたノードがLDAPサーバーに存在しないことを意味しています。
ストアの再関連付けを開始する前に、指定したルート・ノードがLDAPに存在する必要があります。
解決策1
「JPSルートDN」テキスト・フィールドに入力したデータが、ターゲットLDAPディレクトリのノードの名前に一致することを確認してから、再関連付けを再実行します。
現象2- エラー・コード68
再関連付けが失敗し、次のようなエラーがserverName.diagnostic.logファイルに記録されます。
Authentication to LDAP server ldap://myServer.com:3060 is successful. Starting to migrate policy store... Set up security provider reassociation successfully. Checked and seeded security store schema successfully. null [LDAP: error code 68 - Object already exists]:cn=SystemPolicy,cn=domain1,cn=JPSContext,cn=nb_policy Error occurred while migrating LDAP based policy store.
診断2
このエラーは、「WebLogicドメイン名」テキスト・フィールドに指定した名前がターゲットLDAPディレクトリの「JPSルートDN」ノードの孫であることを示しています。
cnはルート・ノードの子孫ではない必要があります。
解決策2
「WebLogicドメイン名」テキスト・フィールドに入力した名前が、指定した「JPSルートDN」ノードの子孫の名前に一致していないことを確認してから、再関連付けを再実行します。
現象3
Fusion Middleware Controlを使用して実行された再関連付けが失敗し、次のようなエラーがserverName.diagnostic.logファイルに記録されます。
[2009-01-21T10:09:24.326-08:00] [AdminServer] [ERROR] [] [oracle.jps.admin] [tid
: [ACTIVE].ExecuteThread: '15' for queue: 'weblogic.kernel.Default (self-tuning)
'] [userId: weblogic] [ecid: 0000HvuOTpe7q2T6uBADUH19Tpyb000006,0] Unable to rem
ove the principal from the application role. Reason: Principal "Managers" is not
a member of the application role "test-role"[[
java.security.PrivilegedActionException: oracle.security.jps.service.policystore
.PolicyObjectNotFoundException: Unable to remove the principal from the applicat
ion role. Reason: Principal "Managers" is not a member of the application role "
test-role"
at oracle.security.jps.mas.mgmt.jmx.policy.JpsApplicationPolicyStoreImpl
.addRemoveMembersToRole(JpsApplicationPolicyStoreImpl.java:408)...
診断3
このエラーは、test-roleアプリケーション・ロールに関連するなんらかの問題を示しています。
データを入力し、Fusion Middleware Controlを使用して再関連付けを実行する際、必ずターゲットLDAPサーバーに接続するために必要なすべての値の入力が完了した直後に、「LDAP認証のテスト」ボタンを使用します。このテストにより、再関連付けが開始される前に、これらの値を使用したときに発生する可能性のある問題を見つけることができます。
解決策3
この例では、system-jazn-data.xmlを迅速に検査した結果、test-roleロールがポリシーで使用されているのに、定義されていないことが明らかになりました。次の例では、必要なデータが欠落している場合を示します。
<application>
<name>myApp</name>
<app-roles>
<--! test-role should have been defined here -->
</app-roles>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>test-role</name>
<guid>66368900E7E511DD9F62F9ADA4233FE2</guid>
</principal>
</principals>...
このエラーを解決するには、(a) アプリケーションtest-roleの定義を挿入してsystem-jazn-data.xmlを修正し、(b) 修正したファイルを使用してファイル・ストアに戻り、(c) 再関連付けを再実行します。
現象4 - 監査ストアが再関連付けされていない
この注意が該当するのはリリース11.1.1.6.0です。Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)を使用した再関連付けが正常に完了しても、ターゲット・ストアに監査ストアは表示されません。これは、このリリースでは、reassociateSecurityStore WLSTコマンドを使用してのみ監査ストアの再関連付けができるためです。
解決策4
元の環境で、reassociateSecurityStoreコマンドを異なるjpsrootノードで実行します。これによって、LDAPディレクトリ間の再関連付けが行われ、データ(監査データを含む)が新しいノードに移行されます。
この項では、LDAPサーバーへの再関連付けに失敗する理由について説明します。
現象
LDAPリポジトリへのセキュリティ・ストアの再関連付けに失敗すると、管理サーバー・ログに次のようなエラーがレポートされます。
[2011-02-09T07:01:13.884-05:00] [AdminServer] [ERROR] [] [oracle.jps.admin] [tid: [ACTIVE].ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: weblogic] [ecid: 41050d66ef2ec40b:-4c1fb689:12e06cc7b6c:-8000-00000000000001e1,0] Schema seeding failed, check the server type of the given ldap url.[[
oracle.security.jps.JpsException: Error Modifying JPS Schema, Record: dn: cn=schema
changetype: modify
delete: objectclasses
objectclasses: ( 2.16.840.1.113894.7.2.2 NAME 'orclContainer' SUP ( top ) MUS
T ( cn ) MAY ( orclVersion $ orclServiceType ) )
-
: [LDAP: error code 32 - No Such Object]:cn=schema
診断
このエラーは、ターゲットLDAPリポジトリのスキーマがサポートされていないことを示しています。
解決策
ターゲットLDAPリポジトリをサポートされているものに更新して、再関連付けを再試行します。Oracle Internet Directoryのバージョンは10.1.4.3以上である必要があります。サポートされているバージョンのリストは、第9.2項「LDAPセキュリティ・ストアの使用」を参照してください。
現象
ファイル・ストアをLDAPストアに正常に再関連付けしたのに、コードソース・ポリシーがターゲット・ストアに存在しません。
診断
実行時に、サーバーは次のようなスタック・トレースをレポートします。
<BEA-000000> <JspServlet: initialization complete>
####<May 4, 2009 8:32:50 AM PDT> <Error> <HTTP> <ap626atg> <WLS_Spaces>
<[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default
(self-tuning)'> <<WLS Kernel>> <> <> <1241451170341> <BEA-101020>
<[ServletContext@20193148[app:webcenter module:/webcenter path:/webcenter
spec-version:2.5]] Servlet failed with Exception
java.security.AccessControlException: access denied
(oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=APPLICATION,name=webcenter getApplicationPolicy)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at
oracle.security.jps.util.JpsAuth$AuthorizationMechanism$3.checkPermission(JpsAuth.java:348)
at
oracle.security.jps.util.JpsAuth$Diagnostic.checkPermission(JpsAuth.java:268)
at
oracle.security.jps.util.JpsAuth$AuthorizationMechanism$6.checkPermission(JpsAuth.java:372)
at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:408)
at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:431)
at
oracle.security.jps.internal.policystore.AbstractPolicyStore.checkPolicyStoreAccessPermission(AbstractPolicyStore.java:246)
at
oracle.security.jps.internal.policystore.ldap.LdapPolicyStore.getApplicationPolicy(LdapPolicyStore.java:281)
at
oracle.security.jps.internal.policystore.PolicyUtil.getGrantedAppRoles(PolicyUtil.java:898)
at
oracle.security.jps.internal.policystore.PolicyUtil.getJpsAppRoles(PolicyUtil.java:1354)
at
oracle.security.jps.wls.JpsWlsSubjectResolver$1.run(JpsWlsSubjectResolver.java:273)
at
oracle.security.jps.wls.JpsWlsSubjectResolver$1.run(JpsWlsSubjectResolver.java:270)
at java.security.AccessController.doPrivileged(Native Method)
パーミッションは次のとおりです。
oracle.security.jps.service.policystore.PolicyStoreAccessPermission context=APPLICATION,name=webcenter getApplicationPolicy
コードソースに付与され、falseと評価されたために認可できません。
解決策
管理サーバー・ログに、再関連付けの際にスキーマがシードされなかったことを示す、次のようなメッセージがないか確認します。
AdminServer-diagnostic.log:[2009-05-28T02:27:52.249-07:00] [AdminServer] [NOTIFICATION] [JPS-00072] [oracle.jps.config] [tid: Thread-39] [ecid: 0000I66Z0KH0fplp4sm3Ui1A7_Rl00002s,1:5001] [arg: 11.1.1.1.0] [arg: 11.1.1.0.0] Policy schema upgrade not required. Store Schema version 11.1.1.1.0 is compatible to the seed schema version 11.1.1.0.0 AdminServer-diagnostic.log:[2009-05-28T02:28:58.012-07:00] [AdminServer] [NOTIFICATION] [JPS-00078] [oracle.jps.config] [tid: Thread-39] [ecid: 0000I66Z0KH0fplp4sm3Ui1A7_Rl00002s,1:5001] [arg: 11.1.1.1.0] [arg: 11.1.1.0.0] Credential store schema upgrade not required. Store Schema version 11.1.1.1.0 is compatible to the seed schema version 11.1.1.0.0
再関連付けの際にスキーマがシードされるようにするには、次のようにします。
LDAPのcn=OracleSchemaVersionコンテナの下にあるcn=OPSSコンテナを削除します。
ファイル・ポリシー・ストアの正常に動作しているインスタンスを起動します。
ファイル・ストアをターゲットLDAPストアに再関連付けします。
管理サーバー・ログで、次のようなメッセージを検索してOPSSスキーマがLDAPサーバーでシードされたことを確認します。
AdminServer-diagnostic.log:[2009-05-29T07:18:18.002-07:00] [AdminServer] [NOTIFICATION] [JPS-00078] [oracle.jps.config] [tid: Thread-12] [ecid: 0000I61Z0MH0fplp4sm3Ui1A7_Ll00002s,1:5001] [arg: 11.1.1.0.0] Policy schema version set to 11.1.1.0.0
リリース11g Oracle Internet Directoryサーバーに再関連付けした場合、スキーマのバージョンは11.1.1.1.0になります。
リリース10.1.4.3 Oracle Internet Directoryサーバーに再関連付けした場合、スキーマのバージョンは11.1.1.0.0になります。
ポリシー・ストアのバージョンは、LDAPの次のコンテナの下に設定されます。
cn=PolicyStore,cn=OPSS,cn=OracleSchemaVersion
資格証明ストアのバージョンは、LDAPの次のコンテナの下に設定されます。
cn=CredentialStore,cn=OPSS,cn=OracleSchemaVersion
この項では、アプリケーションのデプロイ時にポリシーの移行が失敗する理由について説明します。アプリケーションのデプロイは、移行に失敗しても、成功する場合があることに注意してください。バージョンの問題の詳細は、「セキュリティ・ストアのバージョンの非互換性」も参照してください。
現象
デプロイ時にポリシーを移行するようにアプリケーションを構成しました。アプリケーションのデプロイには成功しますが、サーバーの診断ファイルに次のようなメッセージが出力されます。
[2009-01-21T13:34:48.144-08:00] [server_soa] [NOTIFICATION] []
[oracle.jps.deployment] [tid: [ACTIVE].ExecuteThread: '2' for queue:
'weblogic.kernel.Default (self-tuning)'] [userId: weblogic]
[ecid: 0000Hvv7U_H7q2T6uBADUH19Tq0B00002I,0] [APP: JpsJdev#V2.0]
Application [JpsJdev#V2.0] is being deployed, start policy migration.
[2009-01-21T13:34:48.770-08:00] [server_soa] [WARNING] []
[oracle.jps.deployment] [tid: [ACTIVE].ExecuteThread: '2' for queue:
'weblogic.kernel.Default (self-tuning)'] [userId: weblogic]
[ecid: 0000Hvv7U_H7q2T6uBADUH19Tq0B00002I,0] [APP: JpsJdev#V2.0]
Exception in application policy migration.[[
oracle.security.jps.JpsException: appplication Role:
test_role not found for the application in the destination policy store
at oracle.utility.destination.apibased.JpsDstPolicy.convertAppPolicyPrincipal
(JpsDstPolicy.java:815)
at oracle.utility.destination.apibased.JpsDstPolicy.clone
(JpsDstPolicy.java:691)...
この例では、JpsJdevアプリケーションがserver_soa管理対象サーバーにデプロイされました。このようなエラーを探すために検索するキー・フレーズが、出力例で強調表示されています。さらに、このエラーには、例外を引き起こしたアーティファクトであるtest_roleアプリケーション・ロールが記載されています。
診断
jazn-data.xmlを確認すると、granteeでtest_roleロールが参照されていることがわかります。
<grantee>
<display-name>myPolicy</display-name>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>test_role</name>
</principal>
</principals>
</grantee> ...
しかし、名前がtest_rolleとスペルミスされています。
<application>
<name>JpsJdev</name>
<app-roles>
<app-role>
<name>test_rolle</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members> ...
解決策
アプリケーション・ポリシーで参照されているアプリケーション・ロールがすべて定義されていることを確認します。参照されたロール名が一致しない場合、移行は失敗します。
この項では、次の各項でOracle WebLogic Serverの起動に失敗する理由をいくつか説明します。
この項では、ドメイン内の認証プロバイダのリストを変更した後に、WebLogic Serverの起動に失敗する理由について説明します。
現象
ドメイン内のプロバイダのリストを変更すると、WebLogic Serverの起動に失敗し、エラー・メッセージは次のような内容になります。
java.lang.IllegalArgumentException: null KeyStore name
診断
この問題の原因の1つは、ドメイン内のリストにLDAPプロバイダが含まれていないことです。OPSSを使用するすべてのドメインで、このリストにはLDAPプロバイダが必須です。
解決策
プロバイダを追加するには、次の手順を実行します。
DOMAIN_NAME/config/config.xmlを開きます。
<realm>要素内にLDAPプロバイダが含まれるように編集します。
<realm> ... <sec:authentication-provider xsi:type="wls:default-authenticatorType"> </sec:authentication-provider> ... </realm>
サーバーを再起動します。
サーバーが稼働したら、Oracle WebLogic Server管理コンソールを使用して、希望のプロバイダが含まれるようにプロバイダのリストを変更し、必ずそれらの少なくとも1つをLDAP認証プロバイダにします。
WebLogic Server管理コンソールを使用して、次の手順を実行します。
「新しい認証プロバイダの作成」ページに移動します。
名前を入力して、タイプを選択します。
ActiveDirectoryAuthenticator
WebLogic Default Authenticator (例では、これは手動で挿入したものです)
LDAPAuthenticator
LDAPX509IdentityAsserter
OpenLDAPAuthenticator
OracleInternetDirectoryAuthenticator
OracleVirtualDirectoryAuthenticator
この項では、WebLogic Serverの起動に失敗する理由について説明します。
現象
構成済の認証プロバイダを削除してOID認証プロバイダを追加すると、サーバーの起動に失敗します。
診断
追加したプロバイダにAdministratorsグループのアカウント・メンバーを入力することを忘れた可能性が高いと考えられます。サーバーでは、1つの認証プロバイダにこのようなアカウントが存在する必要があります。このアカウントは、デフォルトの認証プロバイダに常に存在します。
解決策
削除したLDAPプロバイダを手動で追加します。
DOMAIN_NAME/config/config.xmlを開きます。
<realm>要素内にデフォルトのプロバイダが含まれるように編集します。
<realm> ... <sec:authentication-provider xsi:type="wls:default-authenticatorType"> </sec:authentication-provider> ... </realm>
サーバーを再起動します。
サーバーが稼働したら、次の手順を実行します。
Administratorsグループのメンバーにアカウントを作成します。
フラグをSUFFICIENTに設定します。
サーバーを再起動します(デフォルトのプロバイダに指定されたAdministratorsグループのアカウントを使用しているため、問題なく起動するはずです)。
フラグをREQUIREDにリセットして、デフォルトのプロバイダを削除します。これで、サーバーは作成したAdministratorsグループのアカウントを使用して起動します。
この項では、WebLogic Serverの起動に失敗する理由について説明します。
現象
システム・プロパティ-Djava.security.managerを使用して、セキュリティ・マネージャを有効にした状態でサーバーを起動しようとすると、起動に失敗します。
診断
サーバー起動時にセキュリティ・マネージャを有効にする際、oraclepki.jarの公開鍵メソッドへのアクセスを許可する権限付与が見つかりません。
解決策
weblogic.policyファイルに次のような権限付与が存在することを確認し、存在しない場合は追加します。
grant codeBase "file:${oracle.home}/modules/oracle.pki_${opss.version}/*" {
permission java.security.AllPermission;
};
デフォルトでは、この権限付与が指定されています。セキュリティ・マネージャを有効にする際、すべてのシステム・リソースへのアクセスに、コードソース・パーミッションの権限付与が必要であることに注意してください。
WebLogicリソースを保護するためのJava Security Managerの詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』を参照してください。
この項では、WebLogic Serverの起動に失敗する2つの理由について説明します。
現象1
${domain.home}/config/fmwconfigドメイン・ディレクトリはNFSマウントされたパーティション上にあり、サーバーの起動時に次のようなエラー・メッセージがログに記録されます。
JPS-01050: Opening of wallet based credential store failed. Reason java.io.IOException: PKI-02002: Unable to open the wallet. Check password.
さらに、orapkiデバッグをオンにしてサーバーを再度起動すると、次のメッセージがログに記録されます。
java.io.IOException: No locks available.
診断1
OPSSではファイル・ストアでセキュリティ・データを管理するためにファイルのロックが必要であるため、エラー・メッセージNo locks availableはドメイン・ディレクトリがNFSマウントされているファイル・システムでファイルのロックがサポートされていないことを示しています。
解決策1
次の手順のいずれかを実行して、サーバーを再起動します。
NFS v3からNFS v4にアップグレードします。
nolockオプションを有効にしてリモート・ファイル・システムをマウントします。
${domain.home}/config/fmwconfig内のファイルをローカル記憶域に移動します。
現象2
資格証明操作に例外が発生したため、サーバーの起動は失敗します。さらに、orapkiデバッグをオンにしてサーバーを再度起動すると、ファイル・パーミッション・エラーがログに記録されます。
診断2
資格証明操作では、/tmpディレクトリに一時ファイルを作成して使用します。パターン/tmp/*pki*と一致するファイルはすべて、サーバーを起動したユーザーが所有する必要があります。ファイル・パーミッション・エラー・メッセージは、そのパターンと一致するファイルの一部が適切なユーザーにより所有されていないことを示しています。
解決策2
サーバーを起動しているユーザーが所有していないパターン/tmp/*pki*と一致するファイルをすべて削除し、サーバーを再起動します。
現象3
この現象は現象2と同様ですが、解決策が異なります。資格証明操作に例外が発生したため、サーバーの起動は失敗します。さらに、orapkiデバッグをオンにしてサーバーを再度起動すると、ファイル・パーミッション・エラーがログに記録されます。
診断3
サーバーの起動は、ドメインをインストールしたユーザーと同じOSユーザーにより実行される必要があります。インストーラが属するOSグループのメンバーでも、別のメンバーによりサーバーが起動された場合は失敗します。
解決策3
ドメインをインストールしたOSユーザーを使用してサーバーを再起動します。
この項では、WebLogic Serverの起動に失敗する理由をいくつか説明します。
現象
ポリシー・プロバイダをロードして設定しようとすると、WebLogic Serverの起動に失敗し、次のような例外がログに記録されます。
<Mar 30, 2010 3:15:54 PM EDT> <Error> <Security> <BEA-090892> <The dynamic loading of the OPSS java security policy provider class oracle.security.jps.internal.policystore.JavaPolicyProvider failed due to problem inside OPSS java security policy provider. Exception was thrown when loading or setting the JPSS policy provider. ... <Mar 30, 2010 3:15:54 PM EDT> <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed. Reason: weblogic.security.SecurityInitializationException: The dynamic loading of the OPSS java security policy provider class oracle.security.jps.internal.policystore.JavaPolicyProvider failed due to problem inside OPSS java security policy provider. Exception was thrown when loading or setting the JPSS policy provider. ... weblogic.security.SecurityInitializationException: The dynamic loading of the OPSS java security policy provider class oracle.security.jps.internal.policystore.JavaPolicyProvider failed due to problem inside OPSS java security policy provider. Exception was thrown when loading or setting the JPSS policy provider. ...
診断
サーバーの起動では、jps-config.xml構成ファイルに定義されているように、ポリシー・プロバイダのロードおよび設定を行います。このタスクが正常に完了しないと、WebLogic Serverの起動に失敗します。このタイプの失敗は、サーバーのログで次の文字列によって識別されます。
Exception was thrown when loading or setting the JPSS policy provider.
サーバーの起動失敗の根本原因を突き止めるには、そのサーバーのログ・ファイルを確認し、記録されたスタック・トレースを調べます。エラーの特定の詳細は、「セキュリティ・エラーの診断」を参照してください。
サーバーが起動に失敗する理由を次にいくつか示します。
構成ファイルのパスの指定に誤りがあります。
構成ファイルにデフォルトのコンテンツが欠落しています。
XMLパーサーが利用不能です。
システム・ポリシーに指定されたコードソースURLに誤りがあります。この状況は、次の文字列を含む例外がログに記録されていることで識別されます。
java.net.MalformedURLException: unknown protocol.
解決策
次の手順では、前述の各理由に対する解決策について説明します。
システム・パラメータoracle.security.jps.configに正しいパスが指定されていることを確認します。
-Doracle.security.jps.config=<full-path-to-jps-config.xml>
フルパスの指定時には、特殊文字(バックスラッシュや空白文字など)は正しくエスケープ処理する必要がある点に注意してください。誤りがないことを確認する方法の1つとして、コマンドラインにそのフルパスを指定してテストしてみます。
構成ファイルには、デフォルトのコンテキストが含まれている必要があります。デフォルトのコンテキストの例は、<jpsContext>を参照してください。
使用システムでXMLパーサーが利用できることと、クラスパスにXMLパーサーのJARファイルが含まれていることを確認します。
次の例では、誤ったコードソースURLと修正したコードソースURLを示します。
Example 1 - Incorrect URL
<grantee>
<codesource>
<url>${my.oracle.home}/jlib/webcacheua.jar</url>
</codesource>
</grantee>
Example 1 - Corrected URL (in bold)
<grantee>
<codesource>
<url>file:/${my.oracle.home}/jlib/webcacheua.jar</url>
</codesource>
</grantee>
Example 2 - Incorrect URL
<grantee>
<codesource>
<url>c:/myfolder/jlib/webcacheua.jar</url>
</codesource>
</grantee>
Example 2 - The corrected URL (in bold) is either one of the following three:
<grantee>
<codesource>
<url>file:///c:/myfolder/jlib/webcacheua.jar</url>
</codesource>
</grantee>
<grantee>
<codesource>
<url>file:c:/myfolder/jlib/webcacheua.jar</url>
</codesource>
</grantee>
<grantee>
<codesource>
<url>file:/c:/myfolder/jlib/webcacheua.jar</url>
</codesource>
</grantee>
コードソースでのURLの指定構文の詳細は、<url>を参照してください。
この項では、サーバーが起動フェーズを完了する前にパーミッション・チェックが失敗する理由について説明します。
現象
サーバーの起動前に認可チェックが失敗します。サーバーは起動しましたが、サーバーの診断ファイルに次の行が出力されます。
<WebLogicServer> <BEA-000365> <Server state changed to STARTING>
診断
サーバーのステータスがSTARTINGに変わる前のパーミッション・チェック・エラーは通常、そのパーミッションのチェックに必要なサービスがリクエスト時に完全には初期化されていなかったことを示します。
解決策
この問題を回避するには:
weblogic.policyファイルを編集して、適切な権限付与を追加します。
次のシステム・プロパティを設定してWebLogic Serverを起動します。
java.security.policyをweblogic.policyファイルの場所に設定します。
jps.policystore.hybrid.modeをtrueに設定します。
この項では、次の問題について説明します。
システム・ポリシーは、プリンシパルまたはコードソースが実行を許可される権限セットを指定するポリシーで、ドメイン全体に適用されます。たとえば、アプリケーション・コードでポリシー、資格証明、キーまたは監査に対して管理操作を実行する必要がある場合、コードソースの権限付与は必須です。このような操作のいずれかで実行時の認可に失敗すると、java.security.AccessControlException例外がスローされます。この項では、問題を診断するために実行する手順について説明します。
現象
実行時の認可で障害が発生します。
java.security.AccessControlException: access denied (oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM,mapName=oracle.patching,keyName=FUSION_APPS_PATCH_WLS_ADMIN-KEY read)
まず、障害に関する情報を得るために、次のロガーを有効にして障害を再現します。
setLogLevel(target="serverName", logger="oracle.security.jps.util.JpsAuth", level="TRACE:32", persist=1); setLogLevel(target="serverName", logger="oracle.security.jps.trace.logger", level="TRACE:32", persist=1); setLogLevel(target="serverName", logger="oracle.security.jps.dbg.logger", level="TRACE:32", persist=1); setLogLevel(target="serverName", logger="oracle.security.jps.internal.policystore.JavaPolicyProvider", level="TRACE:32", persist=1); setLogLevel(target="serverName", logger="oracle.jps.common", level="TRACE:32", persist=1);
JpsAuthロガーの出力で文字列"Failed ProtectionDomain"を探します。次の出力例は、この文字列に関連している行を示しています。
Failed ProtectionDomain:ClassLoader=sun.misc.Launcher$AppClassLoader@1823ab20 CodeSource=file:/scratch/idmprov/idmtop/products/iam/patch_wls1036/patch_jars/BUG14331527_1036.jar Principals=total 0 of principals<no principals> Permissions=((java.io.FilePermission /scratch/idmprov/idmtop/products/iam/patch_wls1036/patch_jars/BUG14331527_1036.jar read) … Call Stack: java.security.AccessControlException: access denied (oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM, mapName=OAM_STORE, keyName=jks write) e] java.security.AccessControlContext.checkPermission(AccessControlContext.java:374) e] java.security.AccessController.checkPermission(AccessController.java:546) e] oracle.security.jps.util.JpsAuth$AuthorizationMechanism$3.checkPermission (JpsAuth.java:463)
診断
この障害では、プロビジョニングされたコードソースの権限付与と、その権限付与に対するランタイムの拡張評価が一致しないことを示しています。
解決策
この問題を解決するには、ランタイムが評価するパーミッション、ターゲットおよびアクションと一致するように、プロビジョニングされたコードソースの権限付与を更新する必要があります。そのためには、次の手順を実行します。
第10.3項「Fusion Middleware Controlを使用したポリシーの管理」の説明に従ってFusion Middleware Controlを使用するか、listCodeSourcePermissions WLSTコマンドを使用して、プロビジョニングされたコードソースの権限付与を調べます。このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。
プロビジョニングされたコードソースの権限付与がランタイム・エラーのデータと一致しない場合、Fusion Middleware ControlまたはgrantPermission WLSTコマンドを使用して、この権限付与を変更します。このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。
ドメインおよびその他の変数が、指定された権限付与に正しく展開されることを確認します。ロガーでは、コードソースはJARファイルへの絶対パスを使用して書き込まれますが、URLは環境変数を使用して書き込まれることに注意してください。
system-jazn-data.xmlファイルで権限付与を指定している場合、アプリケーションを新しい環境でデプロイしたときに修正が有効になるように、このファイルの権限付与を確認します。
権限が付与されたブロック内でコードを実行する必要がある場合は、そのブロック内で実行されていることを確認します。
この項では、エンタープライズ・ユーザーまたはロール(グループ)のパーミッションの取得に失敗する理由をいくつか説明します。
現象
認証プロバイダに適切に入力されたエンタープライズ・ユーザーまたはグループに権限付与で定義されたパーミッションが付与されません。
診断
この問題は、格納されている名前と指定された名前の間に、大文字小文字の不一致がある場合によく発生します。たとえば、このような不一致は、格納されているユーザー名がjDoeで、指定されたユーザー名がjdoeの場合に発生します。
解決策1
1つ目の解決策では、ドメイン内で使用されている認証プロバイダで適切なプロパティを設定します。両方の文字列(指定された文字列と格納されている文字列)にまったく同じ順序の文字が(大文字と小文字に関係なく)含まれているかぎり、この設定により、対応する文字の大文字と小文字が異なっている場合でも、サブジェクトに移入されたユーザー名が、認証プロバイダに存在するユーザー名に一致することが保証されます。
プロバイダのプロパティを設定するには、次の手順を実行します。
WebLogic Server管理コンソールを使用してプロバイダを構成するページに移動します。たとえば、デフォルトのプロバイダを使用している場合は、Realms.myrealm.Providers.Default Authenticatorでデフォルト・オーセンティケータのページに移動します。
「プロバイダ固有」タブを選択します。
プロパティuserRetrievedUserNameAsPrincipalをtrueに設定します。
サーバーを再起動します。
解決策2
2つ目の解決策では、ユーザー名からプリンシパルを生成する必要がある場合を考えます。
ユーザーまたはロール・プリンシパルを作成する場合、次のコードを使用します。
Principal userPrincipal = new WLSUserImpl(user.getUserProfile()getName()); Principal rolePrincipal = new WLSGroupImpl(role.getRoleProfile().getName());
次のコードは使用しません。
Principal userPrincipal = new WLSUserImpl(user.getName()); Principal rolePrincipal = new WLSGroupImpl(role.getName());
正しいユーザーまたはグループ名を取得するには、認証プロバイダに格納されている名前を正確にそのまま渡すか、次のコール・シーケンスを使用します。
import weblogic.security.principal.WLSGroupImpl; import weblogic.security.principal.WLSUserImpl; // Set the context JpsContextFactory ctxFact = JpsContextFactory.getContextFactory(); ServerContextFactory scf = (ServerContextFactory) ctxFact; JpsContext ctx = scf.getContext(ServerContextFactory.Scope.SYSTEM); ctx = ctxFact.getContext(); // Set the identity store IdentityStore identityStore = ctx.getServiceInstance(IdentityStoreService.class).getIdmStore(); // In case of a user name, search the user that matches the supplied name User user = idStore.searchUser(IdentityStore.SEARCH_BY_NAME, suppliedUserName); // Use the obtained object (user) to obtain the stored user name and create // the Principal String storedUserName = user.getName(); Principal userPrincipal = new WLSUserImpl(storedUserName); // Similarily, in case of a role name, search the role that matches // the supplied role name Role role = identityStore.searchRole(IdentityStore.SEARCH_BY_NAME, suppliedRoleName); // Use the obtained object (role) to obtain the stored role name and create // the Principal String storedRoleName = role.getName(); Principal rolePrincipal = new WLSGroupImpl(storedRoleName);
この項では、認可チェックが失敗する理由について説明します。
現象
アプリケーションによるユーザーの認可が失敗し、次のような行を含むエラーがログに記録されます。
Servlet failed with Exception oracle.adf.controller.security.AuthorizationException:ADFC-0619: Authorization check failed: '/StartHere.jspx' 'VIEW'.
診断
このような認可の失敗が発生する理由の1つは、コンテキストと、アプリケーションで使用しているストライプとの間の不一致です。
一方では、アプリケーションで使用するアプリケーション・ストライプが、JpsFilterフィルタまたはJpsInterceptorインターセプタの構成でapplication.nameパラメータを使用してweb.xmlファイルに指定されています。アプリケーション・ストライプが指定されていない場合、アプリケーション名に基づいて、アプリケーション・ストライプが取得されます。
他方では、アプリケーションで使用する実行時ポリシーが、<application.name>要素を使用してsystem-jazn-data.xmlファイルに指定されています。
この2つの名前が一致しない場合または使用するストライプを明示的に指定されていない場合、アプリケーションが間違ったポリシー・ストライプにアクセスし、予期したとおりにアプリケーションのユーザーを認可できない可能性が高くなります。
解決策
アプリケーション・ストライプを明示的に指定し、そのストライプが、アプリケーションで使用することになっているストライプであることを確認します。ほとんどの場合、この2つの異なるファイルに指定された2つの名前は一致します。ただし、複数のアプリケーションが同じポリシー・ストライプを共有する場合は、異なる可能性があります。
この項では、ユーザーが予期したもの以外のパーミッションを取得する、よくある理由について説明します。
現象
新しいユーザーまたは変更されたユーザーが、予期しないパーミッションを取得します。
診断
この問題は、すでに削除されたユーザーの名前を使用してユーザーを追加した場合、または古いユーザーがその名前またはuidを変更した場合に、よく起こります。ユーザーが予期したより多いまたは少ないパーミッションを取得する一般的な理由は、ユーザーの削除前またはユーザー・データの変更前にセキュリティ・ストアが適切に更新されていないことです。
解決策
ユーザーを削除する前に、そのユーザーに付与されていたパーミッション、アプリケーション・ロールおよびエンタープライズ・グループをすべて取り消します。このユーザーを参照するセキュリティ・データの一部を削除できなかった場合、そのようなデータは中途半端な状態のままになり、同じ名前の別のユーザーが後で作成された場合に継承される可能性があります。
ユーザー名を変更する場合にも、同様の考え方が当てはまります。新しいデータでも予期したとおりに機能するように、古いデータを参照するポリシー(権限付与、パーミッション、ロール)をすべて更新する必要があります。
この項では、Java SEアプリケーションで権限付与を適切にコーディングする方法を説明します。ここ説明している問題はJava EEアプリケーションの問題ではありませんが、高い移植性を実現するために、この解決策をJava EEアプリケーションでも使用することをお薦めします。
現象
アプリケーション・コードに次のような行があります。
Permission p = new FilePermission(resourceName, "write");
PrincipalEntry myPrincipal2 = InfoFactory.newPrincipalEntry("weblogic.security.principal.WLSGroupImpl", enterpriseRoleName2);
ap.grant(new Principal[]{myPrincipal2.getPrincipal()}, null, new Permission[]{p});
ところが、実行時に権限が予期したとおりに適用されません。
診断
簡単な調査で、次の属性がセキュリティ・ストアにあることがわかります。
orcljaznjavaclass=oracle.security.jps.internal.policystore.UnresolvedPrincipal+cn=enterpriseRoleName2
解決策
このコードを次の行で置換する必要があります。
Permission p = new FilePermission (resourceName, "write");
PermissionEntry permEntry = InfoFactory.newPermissionEntry(p.getClassName(), p.getName(), p.getActions());
ap.grant (new PrincipalEntry[] {myPrincipal2}, null, new PermissionEntry[] {permEntry});
この解決策では、Principal配列ではなくPrincipalEntry配列と、Permission配列ではなくPermissionEntry配列を使用しています。
この項では、12c HA (高可用性)ドメインでアプリケーション・ポリシーが有効にならなくなる順序と、その解決方法について説明します。
現象
次の順序によって、例外がスローされます。
12c HAドメインで、管理サーバーまたは管理対象サーバーのいずれか(一方のみ)に(アプリケーション・ポリシーとともにパックされた)カスタム・アプリケーションをデプロイします。
アプリケーションをアンデプロイします。
手順1のサーバーとは異なるサーバーにアプリケーションを再デプロイします。
手順3の結果、例外が発生し、アプリケーション・ポリシーは有効になりません。この問題は、12c HAドメインでのみ検出されます。
診断
この問題は、ドメイン・サーバーでキャッシュが同期されていないために発生します。様々なサーバーが個別のJVM (Java仮想マシン)で実行されていることに注意してください。
たとえば、HAドメインにサーバーA (管理サーバー)、サーバーB (管理対象サーバー)およびサーバーC (管理対象サーバー)の3つのサーバーがあるとします。さらに、アプリケーションが最初にサーバーA(管理サーバー)にデプロイされた後に、3つのサーバーすべてが再起動されたとします。サーバーA、BおよびCのキャッシュが(セキュリティ・ストアから読み込まれたポリシーで)初期化され、同期します。
アプリケーションが(サーバーAから)アンデプロイされると、サーバーAのキャッシュは消去されますが、サーバーBおよびCのキャッシュは消去されません。また、アプリケーションが(たとえばサーバーBに)再デプロイされた場合は、キャッシュが同期しなくなり、例外がスローされます(これは、ポリシー・オブジェクトがすでに存在するためです)。
解決策
アプリケーションをアンデプロイし、デプロイ前に、HAドメインのすべてのサーバーを再起動します。このように、修正した手順によってHAドメイン内のすべてのサーバーでキャッシュが同期するため、アプリケーション・ポリシーが予期したとおりに表示されます。
この項では、次の問題について説明します。
この項では、Java Naming and Directory Interface (JNDI)接続がタイムアウト例外をスローする理由について説明します。
現象
JNDIがjavax.naming.NamingException: LDAP response read timed out, timeout used:-1ms例外をスローします。
診断
このエラーは、ドメインでLDAPセキュリティ・ストアを使用し、Java SE Development Kit (JDK)バージョンJava SE 6u85、7u72または8u20のいずれかを実行している場合に発生します。
解決策
JDKをJava SE 6u95、7u80または8u45に更新します。認証済のJDKバージョンについては、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlにある『Oracle Fusion Middleware 12c Certifications』を参照してください。
この項では、組込みLDAPサーバーへの接続に失敗する理由について説明します。
現象
クライアント・アプリケーションでユーザーおよびロールAPIを使用して組込みLDAPサーバーに問合せをリクエストするために使用される接続は、接続プールに格納され、保持されます。デフォルトでは、このプールはjps-config.xmlファイルに指定されてるJNDIプールです。
このプールの同時接続数がLDAPサービスの最大許容数を超えると、クライアント・アプリケーションはサービスに接続できなくなり、すでに接続している場合でも、「ソケットがクローズされました」という例外を受信します。この場合、サーバーのログで、許容される同時接続数を超えたことが示されます。
診断
この制限を超えないようにするには、LDAPサービスで許容する最大同時接続数をアプリケーションのニーズに合わせて調整する必要があります。このしきい値は細かく調整する必要があります。最大値が小さすぎると十分でなく、例外が発生します。最大値が大きすぎると、サービス妨害(DOS)攻撃のリスクが生じます。適切な最大値は、アプリケーションと、そのアプリケーションで使用する特定のLDAPサービスに依存します。
解決策
この問題の解決方法として次の2つの選択肢があります。
プロバイダで許容する最大同時接続数を増やします。
アプリケーションで使用しているプロバイダが組込みLDAPサーバーである場合は、DomainName/servers/MyServerName/data/ldap/conf/vde.propファイルを編集してvde.quota.max.conpersubjectプロパティの値をデフォルトの100から200などの値に増やします。
そうではなく、アプリケーションでその他のプロバイダを使用している場合は、プロバイダのドキュメントで最大値の変更方法を確認してください。
DomainName/config/fmwconfig/jps-config.xmlファイルを編集して、CONNECTION_POOL_CLASSプロパティをプロバイダ・サーバー・インスタンスから削除します(デフォルトでは、このプロパティの値はoracle.security.idm.providers.stdldap.JNDIPoolです)。
これらの設定は相互排他的ではなく、いずれの場合も、変更を有効にするにはサーバーを再起動する必要があることに注意してください。
この項では、LDAPサーバーへの接続が失敗する、よくある理由について説明します。この失敗は、再関連付け時にも発生する可能性があります。
現象
ソース・リポジトリからターゲットLDAPサーバーへのデータの移行が失敗します。
診断
この種の問題は、ターゲットLDAPサーバーのパラメータ値が間違っていることが原因です。
WebLogic Serverのログ・ファイルをさらに調査する場合は、DomainName/servers/AdminServerディレクトリまたはDomainName/servers/ManagedServersディレクトリのログ・ファイルで<Error>、<Critical>および<Warning>という文字列を検索します。
エラーを特定して解決する方法の詳細は、第J.2項「セキュリティ・エラーの診断」を参照してください。
解決策
移行用に指定したターゲット・サーバー・データが、すべて有効であることを確認します。Fusion Middleware Controlを使用して、LDAPサーバーへの再関連付けを行う場合、必ず操作を開始する前に「LDAP認証のテスト」ボタンを使用してください。このテストにより、間違ったパラメータが見つかります。
この項では、ドメイン資格証明ストアのデータへのアクセスに失敗する、よくある理由について説明します。
現象
アプリケーションが、ドメインの資格証明ストアからの資格証明データの取得に失敗し、次のような行を含むエラー・メッセージがログに記録されます。
07/07/26 18:22:22 [JpsAuth] For permisson ( CredentialAccessPermission [target] [actions]), domain that failed: ProtectionDomain
cs(file:somePath/aWarFile.war/WEB-INF/classes/), []
診断
アプリケーションが資格証明ストアにアクセスして操作(ユーザー・パスワードの取得など)を実行する場合、保護された操作を実行するために、そのコードに適切なパーミッションを付与する必要があります。そうしないと、アプリケーションでエラーが発生します。
解決策
資格証明ストアへのアクセスにアプリケーションが必要とするパーミッションを付与するには、アプリケーションのjazn-data.xmlに適切なCredentialAccessPermissionパーミッションを含めます。この権限付与は、アプリケーションをデプロイまたは再デプロイすると有効になります。
Fusion Middleware Controlを使用してパーミッションを追加するには、第10.3項「Fusion Middleware Controlを使用したポリシーの管理」を参照してください。
WLSTコマンドを使用してパーミッションを追加するには、第10.4項「WLSTを使用したポリシーの管理」を参照してください。
次の例では、myAppアプリケーションの内のすべてのコードに、myAliasフォルダ内のすべての資格証明を読み取るパーミッションを付与する方法を示します。
<jazn-data>
<!-- codesource policy -->
<jazn-policy>
<grant>
<grantee>
<codesource>
<!-- This grants applies to all code in the following directory -->
<url>${domain.home}/tmp/_WL_user/myApp/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.credstore.CredentialAccessPermission</class>
<!-- Allow read permission to all credentials under folder MY_MAP -->
<name>context=SYSTEM,mapName=MY_MAP,keyName=*</name>
<actions>read</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</jazn-data>
この項では、コードでセキュリティ・アクセス制御の例外が発生する理由について説明します。
現象
実行時に、アプリケーションが次のようなエラーを出力します(最初の数行のみが示されています)。
<Jan 20, 2009 5:45:33 PM PST> <Error> <HTTP> <BEA-101020> <[weblogic.servlet.internal.WebAppServletContext@140cf52 - appName: 'Application2', name: 'Application2.war', context-path: '/Application2', spec-version: '2.5'] Servlet failed with Exceptionjava.lang.RuntimeException:java.security.AccessControlException:access denied ...
診断
このエラーは、コード内のコールに、保護された操作を実行するための十分なパーミッションがないことを意味しています。
解決策
保護された操作を実行するために、コードに十分なパーミッションを付与する必要があります。設定するパーミッションの範囲に応じて、2つの選択肢があります。
1つ目は、アプリケーションのエンタープライズ・アーカイブ(EAR)ファイルまたはWebアプリケーション・アーカイブ(WAR)ファイル内のすべてのアプリケーション・コードにパーミッションを付与します。この場合、操作へのコールはアプリケーション・コードの任意の場所に挿入できます。
2つ目は、JARファイルにのみパーミッションを付与します。この場合、操作へのコールは権限が付与されたブロック内にある必要があります。
これらの解決策をそれぞれ、資格証明ストアへのアクセスを試みるアプリケーションの例によって次に示します。
次の例では、資格証明ストアにあるマップMY_MAP内のあらゆるキーをBasicAuthディレクトリ内の任意のコードに読み取るためのパーミッションの設定方法を示します。
<jazn-policy>
<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/_WL_user/BasicAuth/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>
oracle.security.jps.service.credstore.CredentialAccessPermission
</class>
<name>context=SYSTEM,mapName=MY_MAP,keyName=*</name>
<actions>read</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
特定のEARファイルまたはWARファイル内のコードにパーミッションを付与する場合は、url指定を次のように変更します。
<url>file:${domain.home}/servers/_WL_user/jpsBasicAuth/.../BasicAuth.ear</url>
特定のJARファイル内のコードにのみパーミッションを付与する場合は、url指定を次のように変更します。
<url>file:${domain.home}/servers/_WL_user/jpsBasicAuth/myJars/Foo.jar</url>
その場合は、資格証明ストアに対する読取り操作をコールするFoo.jarファイル内のコードを、AccessController.doPrivilegedブロック内に配置する必要があります。
import oracle.security.jps.*;
import oracle.security.jps.service.credstore.*;
JpsContextFactory factory = JpsContextFactory.getContextFactory();
JpsContext jpsContext = factory.getContext();
final CredentialStore store = jpsContext.getServiceInstance(CredentialStore.class);
Credential cred = AccessController.doPrivileged(new PrivilegedExceptionAction<PasswordCredential>() {
public PasswordCredential run() throws JpsException {
return store.getCredential("MY_MAP", "anyKey");
}
});
PasswordCredential pwdCred = (PasswordCredential)cred;
...
この例では、権限付与で読取りパーミッションのみを許可しているため、権限が付与されたブロック内であっても、設定操作またはリセット操作のいずれも機能しないことに注意してください。
この項では、ポリシーと資格証明の再関連付けを行う際に匿名Secure Sockets Layer (SSL)接続を確立できない、よくある理由について説明します。
現象
Fusion Middleware Controlを使用したLDAPサーバーへのファイル・セキュリティ・ストアの再関連付けでは、LDAPサーバーへの匿名SSL接続をテストします。「LDAPのテスト」をクリックすると、テストに失敗します。
診断
ターゲットLDAPサーバーがWebLogic Serverによって信頼され、LDAPサーバーへの接続に使用するポート番号がSSLポートである必要があります。
解決策
LDAPサーバーへのSSL接続を確立するには、LDAPサーバーの追加構成が必要です。この構成の詳細は、第9.2.1項「LDAPセキュリティ・ストアを使用する場合の前提条件」を参照してください。
さらに、匿名SSL接続を使用するには、セキュアなデータを受信するために設定されたポートを入力する必要があります。このようなポートを使用してLDAPサーバーを構成していない場合、接続は失敗します。
指定されたLDAPサーバー・ポートが、匿名SSLモードでリスニングするように構成されたSSLポートであること、および指定されたサーバー名にアクセス可能であることを確認します。
BI Publisherとデータベースが、異なるタイムゾーンのサイトにインストールされている場合、監査レポートに問題が発生することがあります。必ずBI Publisherとデータベースを同じタイムゾーンにインストールします。
この項では、問合せの問題について説明します。
この項では、属性のカタログ化が必要な理由について説明します。
現象
セキュリティ・ストアに問い合せると、次のような例外が発生します。
oracle.security.jps.service.policystore.PolicyStoreOperationNotAllowedException javax.naming.OperationNotSupportedException: [LDAP: error code 53 - Function Not Implemented, search filter attribute orcljpsresourcetypename is not indexed/cataloged]; remaining name 'cn=Permissions,cn=JAASPolicy,cn=IDCCS, cn=sprint6_policy_domain,cn=JPSContext,cn=FusionAppsPolicies'
診断
orcljpsresourcetypenameカタログは、フィルタで使用してセキュリティ・ストアを検索する前に、カタログ化する必要があります。
解決策
検索フィルタで使用するLDAP属性は、索引付けしてカタログ化する必要があります。索引作成やカタログ化は通常は必須ではありませんが、OPSS関連の属性の場合は必須です。属性の索引付けおよびカタログ化は、reassociateSecurityStore WLSTコマンドによって自動的に実行されます。
属性を手動でカタログ化するには、ldapmodifyコマンドを使用します。
>ldapmodify -h <host> -p <port> -D <bind DN> -w <bind password> -v -f <catalogue modify ldif file name>
たとえば、createtimestamp属性とmodifytimestamp属性をカタログ化するには、次のようなLDAPデータ交換形式(LDIF)ファイルを使用します。
dn: cn=catalogs changetype: modify add: orclindexedattribute orclindexedattribute: modifytimestamp orclindexedattribute: createtimestamp
索引付けが必要なLDAP属性のリストは次のとおりです。
OrclJpsAllResourcKeyword OrclJpsAllResourceActionKeyword OrclJpsEncodedAttributes OrclJpsExtensionType OrclJpsResourceConverter OrclJpsResourceMatchingAlg OrclJpsResourceMatchingAlgorithm OrclJpsResourceNameExpression OrclJpsRoleType orcOesAppAttributes orclASInstanceName orclFarmName orclJPSObjGUID orclJavaApplicationEntityRef orclJpsPolicyDomainName orclJpsResourceActionsetMembers orclJpsResourceExpression orclJpsResourceLocalityRef orclJpsResourceMatcherJavaclass orclJpsResourceName orclJpsResourceTypeActionAttrs orclJpsResourceTypeActionNames orclJpsResourceTypeName orclJpsResourceTypeProviderName orclJpsResourceTypeResourceAttrs orclJpsRoleCategory orclJpsRoleMemberExpression orclJpsSuperResourceType orclOESActCollectionName orclOESActCollectionRfs orclOESActionAttributes orclOESActionConstraint orclOESAlgorithmJavaClass orclOESAllResourceType orclOESAllowAdviceRef orclOESAllowObligationRef orclOESAttributeCategory orclOESAttributeCollectionHandlerFunctionName orclOESAttributeCollectionHandlerPackageName orclOESAttributeCollectionHandlerSchemaName orclOESAttributeCollectionName orclOESAttributeDataType orclOESAttributeIssuer orclOESAttributeNamespace orclOESAttributeType orclOESCombinerParameter orclOESConditionExpression orclOESDSColumnAttrs orclOESDSPrimKey orclOESDataSourceCtrnt orclOESDataSourceName orclOESDataSourceType orclOESDefaultPolSetRef orclOESDenyAdviceRef orclOESDenyObligationRef orclOESDistributionEndTime orclOESDistributionID orclOESDistributionIssuer orclOESDistributionMessage orclOESDistributionPercentComplete orclOESDistributionStartTime orclOESEffect orclOESEnvAttributes orclOESEnvConstraint orclOESExecutionFrequency orclOESExpression orclOESFunctionCategory orclOESFunctionClass orclOESFunctionParameters orclOESFunctionReturnType orclOESIsSensitive orclOESIsSingleValued orclOESMatchInfo orclOESMaxDelegationDepth orclOESObligationFulfillOn orclOESPDPAddress orclOESPDPConfigurationID orclOESPDPInstanceName orclOESPDPStatusSuccess orclOESPIPType orclOESPolicyCategory orclOESPolicyCombinerParameter orclOESPolicyCombiningAlgorithmRef orclOESPolicyDefaults orclOESPolicyExtension orclOESPolicyIssuer orclOESPolicyRef orclOESPolicyRuleOrder orclOESPolicyRuleRef orclOESPolicySetCategory orclOESPolicySetDefaults orclOESPolicySetRef orclOESPolicySetType orclOESPolicyType orclOESPolicyVersion orclOESPresenceRequired orclOESPrincConstraint orclOESPrincipalAttributes orclOESResConstraint orclOESResTypeCategory orclOESResourceAttributes orclOESResourceHirchyType orclOESResourceNameDelim orclOESResourceParentName orclOESRoleMapping orclOESRuleCombinerParameter orclOESRuleCombiningAlgorithmRef orclOESSQLExpression orclOESSetCombinerParameter orclOESSetMemberOrder orclOESTargetExpression orclOESXMLExpression orclassignedpermissions orclassignedroles orcldistributionversion orcljazncodebase orcljaznjavaclass orcljaznpermissionactions orcljaznpermissionresourceref orcljaznpermissionsigner orcljaznpermissiontarget orcljaznpermissiontargetexpr orcljaznprincipal orcljaznsigner orcljpsRuleCombiningAlgorithmRef orcljpsactionsdelim orcljpsassignee orclrolescope
Microsoft Active Directory (LDAP参照用に構成)で検索する際、参照先のホストがActive Directoryサーバーと異なるドメインにある場合、参照は失敗します。
現象
ユーザーがリソースをリクエストしたときに、ディレクトリでのユーザーのアイデンティティの検証が不可能なためにユーザーのアイデンティティの検証に失敗することがあります。このエラーは、ブラウザがMicrosoft Windows以外のシステムで実行されている場合またはブラウザがMicrosoft Windowsで実行されていてもMicrosoft Active Directoryが稼働しているサーバーにない場合に、Microsoft Active Directoryで発生します。
診断
この問題はLDAP参照の追跡が原因で発生することがあります。LDAP参照は、リクエスト対象のオブジェクトが存在するディレクトリ・ツリー・セクションをドメイン・コントローラが保有していないときに発生します。ドメイン・コントローラは、クライアントが別のドメイン・コントローラのDNS検索を実施できるように、クライアントに別のターゲットを参照させます。クライアントが参照を追跡するよう構成されている場合は、検索を継続できます。
ユーザーがWindowsベースのコンピュータを使用しているシナリオでは、クライアントのドメイン・コントローラとActive Directoryドメイン・コントローラとの間に信頼が確立されていない場合に、LDAP参照で問題が発生することがあります。
解決策
Active Directoryホストのアドレスのエントリを次のリストに追加します。
WINDOWS_HOME_DIRECTORY\system32\drivers\etc\hosts
Windows XPの場合、リストは次の場所にあります。
C:\WINDOWS\system32\drivers\etc\host
Unixベースのシステムの場合は、このエントリを次の形式で/etc/hostsファイルに追加します。
ADhost_IPaddress ADhost_name
AD_host_nameは、参照で指定されるホスト名です(例: 123.123.123.123 my2003ad.com)。
次の各項では、バージョンの問題について説明します。
この項では、サーバーがPolicyStoreIncompatibleVersionException例外をスローする理由について説明します。
現象
次のようなエラーが発生します。
Oracle.security.jps.service.policystore. PolicyStoreIncompatibleVersionException JPS-06100: Policy Store version 11.1.1.5.0 and Oracle Platform Security Services version 11.1.1.4.0 are not compatible.
診断
この例外は、ドメインのOPSSバイナリ・バージョン(11.1.1.4.0)と、そのドメインで使用しているセキュリティ・ストアのバージョン(11.1.1.5.0)に互換性がないことを示しています。セキュリティ・ストアのバージョンは再関連付け時に設定され、セキュリティ・ストアを新しいバージョンにアップグレードするまでそのバージョンが使用されます。
OPSSドメイン・バイナリ・バージョンは、セキュリティ・ストアのバージョンと下位互換性はありますが、上位互換性はありません。したがって、このエラーは、セキュリティ・ストアのバージョンがOPSSバイナリのバージョンよりも新しいことを示しています。
OPSSバイナリで非互換性が発生するシナリオには、次の3つがあります。
シナリオ1
Domain1とDomain2は同じセキュリティ・ストアを指しています。Domain1、Domain2およびそのセキュリティ・ストアのバージョンはいずれも11.1.1.3.0です。
Domain1のバイナリを11.1.1.4.0にアップグレードします。
セキュリティ・ストアを11.1.1.4.0に(upgradeOPSSコマンドを使用して)アップグレードします。
Domain2を再起動すると、バイナリとセキュリティ・ストアのバージョンに互換性がありません。
シナリオ2
Domain1はセキュリティ・ストアを指しており、バイナリおよびセキュリティ・ストアのバージョンはどちらも11.1.1.3.0です。
セキュリティ・ストアを11.1.1.4.0に移行しようとすると、移行によってバージョンの非互換性が発生するため、失敗します。
移行は、OPSSバイナリとセキュリティ・ストアのバージョンが同じ場合にのみサポートされます。
シナリオ3
11.1.1.3.0のDomain1で、join引数を指定したreassociateSecurityStore WLSTコマンドを使用して、11.1.1.4.0のセキュリティ・ストア(他のドメインにあるもの)を結合しようとします。
この操作は失敗します。この共有によってバージョンの非互換性が発生するためです。
再関連付けは、OPSSバイナリとセキュリティ・ストアのバージョンが同じ場合にのみサポートされます。
解決策
3つのシナリオすべてに対する解決策は、次のいずれかです。
OPSSバイナリを更新して、ドメインが使用しているセキュリティ・ストアのバージョンと一致させます。
そのセキュリティ・ストアを、バージョンがOPSSバイナリのバージョン以下のセキュリティ・ストアに再関連付けします。
この項では、セキュリティ・ストアの移行中にPolicyStoreIncompatibleVersionException例外が発生する理由について説明します。
PolicyStoreIncompatibleVersionException例外は、ソース・ストアのバージョンがターゲット・ストアのバージョンよりも高いことを示しています。移行は、ソースのバージョンがターゲットのバージョン以下である場合にのみ実行されます。
回避策は、移行先のストアのバージョンを移行元のストアのバージョンと互換性のあるバージョンにアップグレードすることです。
次の各項では、様々な問題について説明します。
この項では、パーミッションで、パーミッション・チェックに合格できない理由について説明します。
現象
アプリケーションが次のようなエラーを出力します。
[JpsAuth] Check Permission
PolicyContext: [null]
Resource/Target: [test]
Action: [null]
Permission Class: [com.oracle.permission.SimplePermission]
Evaluator: [ACC]
Result: [FAILED]
Failed ProtectionDomain:ClassLoader=weblogic.utils.classloaders.ChangeAwareClassLoader@14061a8
finder: weblogic.utils.classloaders.CodeGenClassFinder@2dce7a8
annotation: Application2@Application2.war
CodeSource=file:/scratch/servers/AdminServer/tmp/permission/TestServlet$1.class
Principals=total 0 of principals<no principals>
Permissions=(
(oracle.security.jps.service.credstore.CredentialAccessPermission
context=SYSTEM,mapName=default,keyName=* read,write)
(java.net.SocketPermission localhost:1024- listen,resolve)
(oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=APPLICATION,name=* getApplicationPolicy)
(oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=SYSTEM getConfiguredApplications)
(com.oracle.permission.SimplePermission *)
...
java.security.AccessControlException: access denied
(com.oracle.permission.SimplePermission test)...
診断
2つ以上のアプリケーションがパーミッション・クラスを共有している場合、そのパーミッション・クラスをシステム・クラス・パスに設定して、そのクラスを一度だけロードする必要があります。そうしないと、クラスをロードする最初のアプリケーションのみがパーミッション・チェックに合格します。その後、同じクラスをロードする他のアプリケーションは、パーミッション・チェックに合格せず、同様のエラーを出力します。
パーミッション・クラスがパーミッション・コレクション内にあっても、環境に同じ名前のパーミッション・クラスのインスタンスが複数存在するため、チェックに合格せず、アクセスが拒否されることに注意してください。
解決策
同じドメイン内で実行されている2つ以上のアプリケーションが1つのパーミッション・クラスを共有する場合、必ずシステム・クラス・パスにそのクラスを含めます。
この項では、DBセキュリティ・ストアで、SQL操作が失敗する場合の理由について説明します。
現象
ポリシー操作の実行中に、データベースが次のようなエラーを発行します。
"ORA-1652: unable to extend temp segment by 128 in tablespace"
診断
理由は、操作で使用される一時表に使用できる空きブロックがないことです。
解決策
この問題を解決するには:
一時表のサイズを4096Mに拡張します。
ALTER TABLESPACE "<TEMP_TABLESPACE_NAME>" ADD TEMPFILE '<data_file_name>' size 4096M
管理サーバーを再起動します。
Oracle Internet Directory 11.1.1.6.0をセキュリティ・ストアとして使用しているドメインでは、次のような例外が発生します。
[LDAP: error code 53 - OID-5018: Cataloging for attr orcljpsextensiontype is already in progress.]:cn=catalogs
Oracle Internet Directory 11.1.1.6.0では、Oracle Bug#13782459を修正するパッチを適用する必要があります。Oracle Internet Directoryのパッチ・リストは、第9.2項「LDAPセキュリティ・ストアの使用」を参照してください。
この項では、ユーザーおよびロールAPIによる認証プロバイダのデータへのアクセスに失敗する理由について説明します。
現象
ユーザーおよびロールAPIで、データへのアクセスに失敗します。
診断1
ユーザーおよびロールAPIでは、ドメイン内で最初に構成されたLDAPプロバイダのデータにのみアクセスできます。このようなプロバイダが少なくとも1つ、ドメイン内に存在する必要があります。その最初のLDAPプロバイダにターゲット・ユーザーが存在しない場合、そのユーザーが他の認証プロバイダに存在しても、APIはそのプロバイダへのアクセスに失敗します。
解決策1
この存在しないユーザーを最初のLDAP認証プロバイダに入力するか、ドメイン内のLDAPプロバイダのリストの順序を並べ替えます。
診断2
ドメイン内で最初に構成されたLDAPプロバイダに、失敗したAPIのターゲット・ユーザーが存在するとします。
デフォルトでは、ユーザーおよびロールAPIでは、uid属性を使用してLDAPプロバイダでユーザー検索を実行します。らかの理由で、LDAPで入力したユーザーにこの属性が欠落している場合、ユーザーおよびロールAPIは失敗します。
解決策2
最初のLDAP認証プロバイダのすべてのユーザーに、uid属性が設定されていることを確認します。
Java SEアプリケーションを開発していて、ユーザーおよびロールAPIでuid以外の属性(mailなど)を使用してユーザーを検索する場合は、username.attr属性とuser.login.attr属性をアイデンティティ・ストアのLDAPプロバイダ・インスタンス(jps-config-jse.xmlファイル)で構成する必要があります。
<serviceInstance provider="idstore.ldap.provider" name="idstore.ldap"> ... <property name="username.attr" value="mail"/> <property name="user.login.attr" value="mail"/> ... </serviceInstance>
所定のスクリプトを使用してプロバイダ・インスタンスにプロパティを追加する方法の詳細は、第E.1項「スクリプトを使用したサービスの構成」を参照してください。
次の各項では、ポリシーでの文字に関連するいくつかの問題について説明します。
セキュリティ・ストアがOracle Internet Directory 10.1.4.3の場合、RFC 2252/2253フィルタで'*'、'('、')'または'\'の各文字を使用するとエラー53 (DSAによる操作拒否)が発生します。このエラーを解決するには、バグ番号7711351用のパッチをOracle Internet Directory 10.1.4.3に適用します。
この項で説明する問題は、ファイル・ストアにのみ当てはまります。
ここで問題となる文字は次のとおりです。
< " & $ ? * , / \ ` : ( ) ^ ' % + { }
これらをファイル・ストア内でロール名に使用しないことをお薦めします。
ロールを作成するために、これらのいずれかの文字を使用する場合は、正しい結果が返されるように、ApplicationPolicy.searchAppRolesなどのメソッドへの引数で必ずその文字をエスケープ処理します。たとえば、アプリケーション・ロールにappRole^$という名前を付けた場合、セキュリティ・ストアで一致を検索するにはappRole\\^\\$のように引数を渡します。
あるいは、このようなエスケープ処理した特殊文字を含めるのではなく、appRole*のように、検索式にワイルド・カードを使用することもできます。
アプリケーション・ロール名は、空白を含まない、英数字(ASCIIまたはUnicode)とその他の印刷可能文字(アンダースコアや大カッコなど)の文字列です。このルールは、どの種類の記憶域のロール名にも適用されます。
ファイル・ストアでは、<permission>または<principal>の終了タグと次の開始タグとの間に改行文字が必要です。
次に、正しくない形式と正しい形式の例を示します。
正しくない形式:
<permission>
<class>java.lang.RuntimePermission</class>
<name>getClassLoader</name>
</permission><permission>
<class>java.io.FilePermission</class>
<name>/foo</name>
<actions>read,write</actions>
</permission>
修正した形式:
<permission>
<class>java.lang.RuntimePermission</class>
<name>getClassLoader</name>
</permission>
<permission>
<class>java.io.FilePermission</class>
<name>/foo</name>
<actions>read,write</actions>
</permission>
この項では、無効な鍵サイズの例外が発生する理由について説明します。
現象
次の例外が発生します。
java.security.InvalidKeyException: Illegal key size
診断1
ドメインの作成時、OPSSではキーストア・サービスを使用して、セキュリティ・ストア・データの暗号化に使用される高度暗号化標準(AES)対称鍵を作成します。OPSSは、最初に256ビットの鍵を生成しようとします。これがサポートされていない場合は、192ビットの鍵の生成を試行しますが、それもサポートされていない場合は、128ビットの鍵を作成します。128ビットの鍵がサポートされていない場合は、invalidKeyException例外がスローされます。
診断2
OPSSの起動時、ランタイムJDKでAESアルゴリズムがサポートされていないためにOPSS暗号化鍵が読取り不可能な場合、またはドメインのプロビジョニングされた鍵サイズがJDKでサポートされているサイズと異なる場合、invalidKeyException例外がスローされます。
解決策
JDKにJava Cryptography Extension (JCE)無制限強度の管轄ポリシー・ファイルをインストールし、ドメインの作成またはOPSSの起動を再試行します。
Oracleサポートの詳細は、http://myoraclesupport.oracle.comにアクセスしてください。問題に対する解決策が見つからない場合は、サービス・リクエストを登録してください。
