Use this information to troubleshoot problems with configuring or enabling security. What kind of error are you seeing?
For general tips on diagnosing and resolving security-related problems, see the topic Troubleshooting the security component.
grant codeBase "file:/<EWLM_Install_Home>/classes/ARM/arm4.jar" { permission java.security.AllPermission; };Otherwise, you might encounter a Java 2 security exception for violating the Java 2 security permission.
Refer to server.policy file permissions for more information on configuring server.policy files.
For current information available from IBM Support on known problems and their resolution, see the IBM Support page.
IBM Support has documents that can save you time gathering information needed to resolve this problem. Before opening a PMR, see the IBM Support page.
If you use CSIv2 inbound authentication, basic authentication is required, and Java™ clients running with com.ibm.CORBA.validateBasicAuth=true might fail with the following exception: NMSV0610I: A NamingException is being thrown from a javax.naming.Context implementation. Details follow: Context implementation: com.ibm.ws.naming.jndicos.CNContextImpl Context method: lookupExt Context name: TestaburgerNode01Cell/nodes/TestaburgerNode01/servers/server1 Target name: SecurityServer Other data: "" Exception stack trace: javax.naming.NoPermissionException: NO_PERMISSION exception caught. Root exception is org.omg.CORBA.NO_PERMISSION: vmcid: 0x49421000 minor code: 92 completed: No ... SECJ0395E: Could not locate the SecurityServer at host/port:9.42.72.27/9100 to validate the userid and password entered. You may need to specify valid securityServerHost/Port in (WAS_INSTALL_ROOT)/properties/sas.client.props file.
To fix this problem, modify the com.ibm.CORBA.validateBasicAuth=false property in the clients.sas.clients.props file and then run the client.
In WebSphere Application Server V6.1, when administrative security is enabled, the administration service is locked down. However, if application security is not enabled, an authentication challenge does not occur for incoming requests and, consequently, credentials do not exist for the performance servlet to access the administration service.
If administrative security is enabled, you also must enable application security for the performance servlet to process incoming requests.
When you use the migrateEAR utility to migrate the changes that were made to console users and groups after the JACC provider for Tivoli Access Manager is configured, the following configuration error displays in the systemOut.log file.
<specialSubjects> name value is invalid
The migrateEAR utility migrates the user and group data that is contained in the admin-authz.xml file. However, the migrateEAR utility does not convert the XML tags that are listed in the admin-authz.xml file if the pdwas-admin group is added to the administrator access control list (ACL) in Tivoli Access Manager prior to migration.
To resolve this error, enter the following command in padadmin to check whether the pdwas-admin group is in the administrator ACL before you migrate:
acl show _WebAppServer_deployedResources_Roles_administrator_admin-authz_ACL
The following result should display:
ACL Name: _WebAppServer_deployedResources_Roles_administrator_admin-authz_ACL Description: Created by the Tivoli Access Manager for Websphere Application Server Migration Tool. Entries: User sec_master TcmdbsvaBR1 Group pdwas-admin T[WebAppServer]i
If the pdwas-admin group is not listed, then enter the following command in pdadmin to modify the ACL to add the pdwas-admin group:
acl modify _WebAppServer_deployedResources_Roles_administrator_admin -authz_ACL set gruop pdwas-admin T [WebAppServer]i
A Sun JDK is not able to read a PKCS12 keystore created by the Application Server. The reason for this is that the PKCS12 implementation used by the IBM SDK and the Application Server is different than the implementation used by the Sun JDK. The difference causes problems when a Sun JDK is used to read the default trustore, trust.p12, or keystore, key.P12 created by the Application Server.
Because the trustore can not be read by the Sun JDK, first extract
the certificates from the trustore using an IBM SDK. You can then import these
certificates into a keystore that the Sun JDK can recognize correctly, such
as a JKS keystore.