WAS v8.5 > Reference > Troubleshooting tips

Security enablement followed by errors

Use this information if you are experiencing errors after security is enabled.

IBM recommends using the HPEL log and trace infrastructure. With HPEL, one views logs using the LogViewer command-line tool in PROFILE/bin.

What kind of error are you seeing?

  1. Authentication error accessing a Web page
  2. Authorization error accessing a Web page
  3. Authentication fails when code pages differ between the client and the server
  4. Error Message: CWSCJ0314E: Current
  5. Error message: CWMSG0508E: The JMS Server security service was unable to authenticate user ID:" error displayed in SystemOut.log when starting an application server
  6. Error message: CWSCJ0237E: One or more vital LTPAServerObject configuration attributes are null or not available after enabling security and starting the application server
  7. The AccessControlException exception, is reported in the SystemOut.log
  8. Error Message: CWSCJ0336E: Authentication failed for user {0} because of the following exception {1}
  9. Error Message: An unexpected exception occurred initializing the security collaborator.java.lang.SecurityException:
  10. Error Message: SECJ8032W: AuthConfigFactory
  11. Error Message: SECJ0352E: Could not get the users matching the pattern {0} because of the following exception {1}
  12. Validation of LTPA token failed
  13. Generate keys error when using the Profile Management tool to create a new profile
  14. Some security roles are not immediately available for a secured application where LDAP has Tivoli Access Manager enabled
  15. After setting domain realm to not trusted, global security settings cannot be used
  16. Updated global security realm names are duplicated
  17. Errors may occur when the session security feature is turned on

For general tips on diagnosing and resolving security-related problems, see the topic Troubleshooting the security component.

IBM Support has documents and tools that can save you time gathering information needed to resolve problems. Before opening a problem report, see the Support page:


Authentication error accessing a Web page

Possible causes for authentication errors include:

If the user registry configuration, user ID, and password appear correct, use the WAS trace to determine the cause of the problem. To enable security trace, use the com.ibm.ws.security.*=all=enabled trace specification.


Authorization error accessing a Web page

If a user who is supposed to have access to a resource does not, a configuration step is probably missing. Review Authorizing access to administrative roles.

Specifically:

If the user is granted required roles, but still fails to access the secured resources, enable security trace, using com.ibm.ws.security.*=all=enabled as the trace specification. Collect trace information for further resolution.


Authentication fails when code pages differ between the client and the server

When a client uses a code page that is different from the server, and non-US-ASCII characters are used for the user ID and password during basic authentication, the login does not succeed. The HTTP header does not include the encoding method information that is necessary to translate the encoded data, so the server does not know how to decode the information correctly.

Use a login form that relies on POST parameters, which are in the HTML body text. The encoding for the text is sent by the browser and so is capable of being decoded properly.

Web services customers are not able to use form login to resolve this problem. Users must ensure there is consistency in the code pages between the client and the server.


Error Message: CWSCJ0314E: Current Java 2 security policy reported a potential violation on server

If you find errors on your server similar to:

Error Message: CWSCJ0314E: Current Java 2 Security policy reported a potential violation of 
Java 2 Security Permission. Please refer to Problem Determination Guide for further information.
{0}Permission/:{1}Code/:{2}{3}Stack Trace/:{4}Code Base Location/:{5}
The Java security manager checkPermission method has reported a SecurityException exception .

The reported exception might be critical to the secure system. Turn on security trace to determine the potential code that might have violated the security policy. Once the violating code is determined, verify if the attempted operation is permitted with respect to Java 2 Security, by examining all applicable Java 2 security policy files and the application code.

A more detailed report is enabled by either configuring RAS trace into debug mode, or specifying a Java property.

For a review of Java security policies, see the Java 2 Security documentation at http://java.sun.com/j2se/1.3/docs/guide/security/index.html.

Tip: If the application is running with a Java Mail API, this message might be benign. We can update the installed Enterprise Application root/META-INF/was.policy file to grant the following permissions to the application:


Error message: CWMSG0508E: The JMS Server security service was unable to authenticate user ID:" error displayed in SystemOut.log when starting an application server

This error can result from installing the JMS API sample and then enabling security. We can follow the instructions in the Configure and Run page of the corresponding JMS sample documentation to configure the sample to work with WAS security.

We can verify the installation of the message-driven bean sample by launching the installation program, selecting Custom, and browsing the components which are already installed in the Select the features you like to install panel. The JMS sample is shown as Message-Driven Bean Sample, under Embedded Messaging.

We can also verify this installation using the dmgr console to open the properties of the application server containing the samples. Select MDBSamples and click uninstall.


Error message: CWSCJ0237E: One or more vital LTPAServerObject configuration attributes are null or not available after enabling security and starting the application server

This error message can result from selecting LTPA (LTPA) as the authentication mechanism, but not generating the LTPA keys. The LTPA keys encrypt the LTPA token.

To resolve this problem:

  1. Click Security > Global security > Authentication > Authentication mechanisms and expiration > LTPA.

  2. Enter a password, which can be anything.

  3. Enter the same password in Confirm Password.

  4. Click Apply.

  5. Click Generate Keys.

  6. Click Save.


The AccessControlException exception, is reported in the SystemOut.log

The problem is related to the Java 2 security feature of WAS, the API-level security framework that is implemented in WAS. An exception similar to the following example displays. The error message and number can vary.

CWSRV0020E: [Servlet Error]-[validator]: Failed to load servlet: 
java.security.AccessControlException: access denied 
(java.io.FilePermission 
app_server_root/systemApps/isclite.ear/isclite.war/WEB-INF/validation.xml read) 

For an explanation of Java 2 security, how and why to enable or disable it, how it relates to policy files, and how to edit policy files, see the Java 2 security topic in the information center navigation. The topic explains that Java 2 security is not only used by this product, but developers can also implement it for their business applications. Administrators might need to involve developers, if this exception is created when a client tries to access a resource that is hosted by WAS.

Possible causes of these errors include:

To resolve these problems:

If the application is running with the Java Mail API, we can update the installed Enterprise Application root/META-INF/was.policy file to grant the following permissions to the application:


Error Message: CWSCJ0336E: Authentication failed for user {0} because of the following exception {1}

This error message results if the user ID that is indicated is not found in the LDAP user registry. To resolve this problem:

  1. Verify the user ID and password are correct.
  2. Verify the user ID exists in the registry.
  3. Verify the base distinguished name (DN) is correct.
  4. Verify the user filter is correct.
  5. Verify the bind DN and the password for the bind DN are correct. If the bind DN and password are not specified, add the missing information and retry.
  6. Verify the host name and LDAP type are correct.

Consult with the administrator of the user registry if the problem persists.


Error Message: An unexpected exception occurred initializing the security collaborator.java.lang.SecurityException: AuthConfigFactory error: java.lang.ClassNotFoundException: org.apache.geronimo.components.jaspi.AuthConfigFactoryImpl

This error message occurs when the java.security file is missing an entry for the JASPI Provider. The default location for the java.security file is install_dir/properties. Edit the java.security file and add the following lines to it:.

#
# The fully qualified class name of the default JASPI factory implementation class.
#
authconfigprovider.factory=com.ibm.ws.security.jaspi.ProviderRegistry

This error only appears if you explicitly set your configuration to use this class. Otherwise, you might see error message SECJ8032W below.


Error Message: SECJ8032W: AuthConfigFactory is undefined, using the default JASPI factory implementation class

This error message occurs if the JASPI factory implementation is not defined. The default JASPI factory implementation has been set in the server runtime. However, JASPI might not function for a client.

To resolve, set the fully qualified class name of the default JASPI factory implementation class as the value for the property authconfigprovider.factory in the java.security file as in below:

#
# The fully qualified class name of the default JASPI factory implementation class.
#
authconfigprovider.factory=com.ibm.ws.security.jaspi.ProviderRegistry


Error Message: SECJ0352E: Could not get the users matching the pattern {0} because of the following exception {1}

This authentication failure message displays when an external user account repository is corrupted or unavailable, and WAS is unable to authenticate the user name in the repository. Generally, authentication error messages are followed by additional information that indicates the nature or root cause of the problem, such as:

This additional information might not provide a clear user action if the user account repository is corrupted or the user loses connectivity between WAS and an external user account repository. The external user account repository, which is referred to as a repository in this document, might be a LDAP product.

To resolve this problem, we might need to re-install the repository and verify that it installs successfully by testing the connection.

CAUTION:

Proceed with the following steps only if we have ensured that all WAS-related configuration settings are accurate. To resolve the issue:

  1. Restart both the repository and WAS.
  2. Test the connection to the repository. If the connection attempt still fails, it might be necessary to re-install the repository.

  3. If diagnostics are provided with the repository, run them to avoid having to re-install the repository.

    If the previous steps do not fix the problem, we might need to re-install the repository. Before proceeding, generate a complete list of all the configured users and groups; you will need to re-populate these fields after the re-installation.

  4. If necessary, re-install the corrupted repository.
  5. Populate the users and groups from your list into the newly installed repository.

  6. Restart both the repository and WAS.
  7. In the dmgr console, navigate to Security > Global security, and select the appropriate user account repository. For example, select Standalone LDAP registry if you are using a stand-alone Lightweight Directory Access Protocol repository.

  8. Click Test connection to ensure that WAS can connect to the repository.


Validation of LTPA token failed due to invalid keys or token type

If the security context deserialization of an LTPA token fails with a WSSecurityException containing this message: Validation of LTPA token failed due to invalid keys or token type, set the com.ibm.websphere.security.recoverContextWithNewKeys property to true.


Generate keys error when using the Profile Management tool to create a new profile

When creating a new profile using either the Profile Management tool or the command-line manageprofiles utility, an error message displays that indicates either partial success or failure. The error message, located in the install_dir/logs/manageprofiles/profile_name_create.log file, might point to an error in either the generateKeysforSingleProfile task or the generateKeysForCellProfile task.

The Profile Creation tool and the manageprofiles utility invoke several tasks. The generateKeysForSingleProfile task is invoked when we create a stand-alone application server or a deployment manager profile. The generateKeysForCellProfile task is invoked when we create a cell profile. Both of these tasks are the first tasks to invoke wsadmins. Although the log indicates an error in one of these tasks, the error might actually result from a wsadmin command failure and not an error in the security tasks.

To determine the actual cause of the problem, review the information provided in the following log files:


Some security roles are not immediately available for a secured application where LDAP has Tivoli Access Manager enabled

In some instances, some security roles might not be immediately available when we deploy a secured application where LDAP has Tivoli Access Manager enabled.

You might see an error such as the following:

You might be able to address this issue by doing the following:

  1. Allocate more memory to the minimum and maximum java heap size.

    1. In the dmgr console, select Servers > server types > WebSphere Application servers > server1.

    2. Select Server Infrastructure > Java and Process Management > Process Definition.

    3. Select Java Virtual Machine.

    4. Set the initial heap size to 512 MB and the maximum heap size to 1024 MB.

    5. Select OK and then Save.

    6. Restart WAS.

  2. While WebSphere Application Sever is stopped, add some performance tuning properties for embedded Tivoli Access Manager.

    1. In the config/cells/CELLNAME directory, edit the amwas.amjacc.template.properties file by adding the following properties to it:
      com.tivoli.pd.as.jacc.DBRefresh=0
      com.tivoli.pd.as.jacc.AuthTableRemoteMode=yes
      com.tivoli.pd.as.rbpf.NoUncheckedRoles=true

      This helps when embedded Tivoli Access Manager is re-configured

    2. Because embedded Tivoli Access Manager is already configured, we can update the generated configuration files with the above properties. For each WAS instance in the ND (dmgr, NAs and servers), go to the profiles/NAME/etc/tam directory and do the following.

      For each file that ends in amjacc.properties, add the 3 properties above:

      com.tivoli.pd.as.jacc.DBRefresh=0
      com.tivoli.pd.as.jacc.AuthTableRemoteMode=yes
      com.tivoli.pd.as.rbpf.NoUncheckedRoles=true

      For each file that ends in pdperm.properties, update the appsvr-dbrefresh property to be:

        appsvr-dbrefresh=0

      For each file that ends in authztable.pdperm.properties, update the appsvr-mode property to be:

        appsvr-mode=remote

  3. Restart the cell.


After setting domain realm to not trusted, global security settings cannot be used

If you add a trusted domain realm and later on decide to set this realm to "Not Trusted" from the dmgr console, an empty inboundTrustedAuthenticationRealm entry might be generated in the domain-security.xml file. This empty inbound or outbound trusted realm definition in the domain-security.xml file blocks this domain from using global security settings.

To resolve this issue, do the following:

  1. Remove the current domain.

  2. Create a new domain.
  3. Do not add the incorrect realm as "Trusted".


Updated global security realm names are duplicated

When the global security realm names are updated, the realm names of the application security domain are also updated with the same realm names

In WAS v8.0, we can configure a unique instance of a federated repository at the domain level in a multiple security domain environment in addition to having an instance at the global level. However, if the federated repositories user registry is configured at the global level, or if the realm names are changed at the global level after configuring security domains, the realm names for all security domains using federated repositories are also updated. This causes all of the domains using federated repository to use the federated repository defined at the global level.

To resolve this issue, update security domains using federated repository with the original realm name after you create federated repositories or change realm names at the global level. The problem can be avoided if a federated repository at the global level is configured before you configure a federated repository in a security domain.

When the global security realm names are updated, the realm names of the application security domain are not updated with the same realm names in Fix Pack 2.


Errors may occur when the session security feature is turned on

When the session security feature is turned on (which is the default in WAS v8.0), and multiple sessions are using the same user ID, when a user logs out of one session, another session might receive the following error when a different user who has logged in with the same user ID logs out:

To resolve this issue, ensure the previous user is logged out before another user logs in using the same user ID.

This issue might also occur in some instances when the session security feature is not turned on. If so, the resolution is the same: ensure the previous user is logged out before another user logs in using the same user ID. gotcha


Related concepts:

Troubleshoot


Reference:

Access problems after enabling security


+

Search Tips   |   Advanced Search