Security configuration and enablement errors

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.

"LTPA password not set. validation failed" message displayed as error in the administrative console after saving Global security settings

This error can be caused when you configure WebSphere Application Server security, select "LTPA" as the authentication mechanism, and the Lightweight Third Party Authentication (LTPA) password field is not set. To resolve this problem:
  • Select Security > Global security > Authentication mechanisms > LTPA .
  • Complete the password and confirm password fields.
  • Click OK.
  • Try setting Global security again.

"Validation failed for user userid. Please try again..." displayed in the administrative console after saving security settings

This typically indicates that a setting in the user registry configuration is not valid:
  • If the user registry is on a local operating system, it is likely that either the server user ID and password are not valid or the server user ID does not have "Act As Part of the Operating System" for Windows operating systems or root authority for UNIX platforms. The server user ID needs this authority for authentication using the local OS user registry.
  • If the user registry is Lightweight Directory Access Protocol (LDAP):
    • Verify whether your LDAP server requires the Bind Distinguished Name (DN) to find the user in the LDAP directory. If the bind distinguished name is required, you must specify a DN instead of a short name. You can specify the bind distinguished name by clicking Security > Global security. Under User registries, click LDAP. For example, you might add cn=root.
    • Any of the settings that enable WebSphere Application Server to communicate with LDAP might not be valid, such as the LDAP server's user ID, password, host, port, or LDAP filter. When you select Apply or OK to configure LDAP, a validation routine connects to the user registry just as it would during runtime when security is enabled. This validation routine is done to verify any configuration problems immediately, instead of waiting until the server restarts.
    • Sometimes the LDAP server might be down during configuration. The best way to check this is to issue a command line search using a utility such as idsldapsearch to search for the server ID. This way you can determine if the server is running and if the server ID is a valid entry in the LDAP. The idsldapsearch utility is installed during an LDAP or Lotus Notes installation.
  • If the user registry is custom , double check that your implementation is in the class path. Also, check to see if your implementation is authenticating properly.
  • Regardless of user registry type, check the user registry configuration panels to see if you can find a configuration error:
    • Go back to the User Registries configuration panels and retype the password for the server ID.
  • See if there is an obvious configuration error. Double check the attributes specified.

The setupClient.bat or setupClient.sh file is not working correctly

The setupClient.bat file on Windows operating systems and the setupClient.sh file on Linux and UNIX-based platforms incorrectly specify the location of the SOAP security properties file.
[Windows] In the setupClient.bat file, the correct location is:
set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%WAS_HOME%/properties/soap.client.props
[AIX] [Linux] [AIX HP-UX Solaris] In the setupClient.sh file, the CLIENTSOAP variable is:
CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:$WAS_HOME/properties/soap.client.props
In the setupClient.bat and the setupClient.sh files, complete the following steps:
  1. Remove the leading slash ( / ) after file:.
  2. Change sas to soap.

Java HotSpot Server VM warning: Unexpected Signal 11 occurred under user-defined signal handler 0x7895710a message occurs in the native_stdout.log file when enabling security on the HP-UX11i platform [HP-UX]

After you enable security on HP-UX 11i platforms, the following error in the native_stdout.log file occurs, along with a core dump and WebSphere Application Server does not start:
Java HotSpot(TM) Server VM warning: 
Unexpected Signal 11 occurred under user-defined signal handler 0x7895710a
To work around this error, apply the fixes recommended by Hewlett Packard for Java at the following URL: http://www.hp.com/products1/unix/java/infolibrary/patches.html.

WebSphere Application Server Version 6 is not working correctly with Enterprise Workload Manager (EWLM)

To use WebSphere Application Server Version 6 with EWLM, you must manually update the WebSphere Application Server server.policy files. For example:
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.

NMSV0610I: A NamingException is being thrown from a javax.naming.Context implementation

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:
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 client's sas.clients.props file, which is located in WAS_HOME/profiles/<profile-name>/properties, and then run the client.

"Name value is invalid" displays when migrating users and groups after the JACC provider for Tivoli is configured

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 can not read a PKCS12 keystore created by the Application Server

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 truststore can not be read by the Sun JDK, you must 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.




Related concepts
welc6toptroubleshooting.html
Related tasks
Troubleshooting security configurations
Reference topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 5:25:00 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-base-dist&topic=rtrb_secconfigprobs
File name: rtrb_secconfigprobs.html