WAS v8.5 > Reference > Troubleshooting

Liberty profile: Troubleshooting


Overview

WAS v8.5 has a unified logging component that logs exception messages. The Java API document for each Liberty profile API is available as a JAR file under...


Check the JDKs are at a supported level

If we experience problems that are not readily explained, check the JDKs you are using are compliant with Java V6 or later, and are at a current service level.


Troubleshooting security

This section describes some common security problems and solutions we can choose.

SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:LdapRegistry/cn=steven,o=myCompany,c=US.

This error happens when an unauthenticated user tries to access a session created by an authenticated user. Default session security prevents unauthorized access of the sessions. Only the user who created a session can access it.

This error can happen when you use a JSP (login.jsp for example) for the form-login and the SSO token sent by the browser is expired. Because the SSO token is expired, the user is prompted to log in again using the login.jsp page configured for the form-login. The jsp page, by default, tries to get a session. This session was originally created by the user whose token is expired. However, the token is expired and the user is not authenticated, no credentials are established when accessing this session that results in this error.

To avoid this error, restart the browser that starts a new session, or configure the login.jsp file to not create the session by default. If we choose to update the login.jsp file, set...

    <%@ page session="false" %>

CWWKS9104A: Authorization failed for user {0} while invoking {1} on {2}. The user is not granted access to any of the required roles: {3}.

This error occurs when we do not have authorization to the roles required by the application. Verify the user or the group it belongs to is mapped to at least one of the roles that are mentioned in the error message. A user-to-role mapping defined in the ibm-application-bnd.xmi/xml file takes precedence over a mapping defined in server.xml. Check both resources to ensure the correct mapping is defined.

CWWKZ0013E: It is not possible to start two applications called {0} followed by unexpected security behavior and error messages such as CWWKS9104A.

This error occurs when you specifies the application in both the server.xml using theapplication element and in the dropins folder. As a result, the application is attempted to be installed twice and the security configuration in server.xml might or might not take effect. To fix this, you must remove the application from the dropins folder and copy it to another directory. If we have to leave it in the dropins folder, you must disable the application monitoring using the following code in server.xml:

An unauthenticated user was able to access my servlet or JSP.

A user with a principal of UNAUTHENTICATED (or the unauthenticated SAF user on z/OS ) is created when authentication fails or when the servlet or JSP is unprotected. An unauthenticated user can access the servlet or JSP if we do not define any security constraints or if you map the EVERYONE special subject to the role required by the application. Review the user-to-role mappings in the ibm-application-bnd.xmi/xml and server.xml files. Take one of the following options:

  • If the servlet or JSP is unprotected, add security constraints to the deployment descriptor of the application.

  • If we do not want any unauthenticated user to access the application, remove the EVERYONE special subject from the mapping for that role.

  • If a certain user cannot be authorized to the servlet or JSP, review who is mapped to that role by examining the ibm-application-bnd.xmi/xml and server.xml files. We can map a role to a user, group, or special subject. If the role is mapped to the EVERYONE special subject, any user is granted access. If the role is mapped to the ALL_AUTHENTICATED special subject, any authenticated user is granted access. Remove these special subjects to further limit who can access the servlet or JSP. Finally, check what group the user belongs to. Although the user might not have explicit access, the group might be mapped to the role. In this case, remove the user from the authorized group or remove the group from role mapping.

Single sign-on (SSO) does not work.

If SSO does not work, verify the different Liberty profile servers that use the same LTPA keys, password, and ssoCookieName attribute of webAppSecurity element, each server has the same Universal Time (UTC), and the same user registry is shared. Also, if the token expires or if the cookie is sent from a web browser after changing the user registry in a manner inconsistent, like modifying the realm or removing the user the cookie represents, the SSO fails and the user is prompted to enter the credential information again.

Debugging security public APIs.

WSSecurityHelper and RegistryHelper are loaded even if security is not enabled. For example, if a security feature - appSecurity-1.0 or zosSecurity-1.0 - is not specified. If security is not enabled, then...

  • WSSecurityHelper.isServerSecurityEnabled()
  • WSSecurityHelper.isGlobalSecurityEnabled()

... both return false, and...

  • RegistryHelper.getUserRegistry()

...returns null.

Other security public API classes might not be loaded if security is not enabled. If we try to access these classes and call a method on one of these classes, you might get exception...

    java.lang.NoClassDefFoundError

To avoid getting java.lang.NoClassDefFoundError exceptions, first test to see whether security is enabled by calling either...

  • WSSecurityHelper.isServerSecurityEnabled()
  • WSSecurityHelper.isGlobalSecurityEnabled()

...and then call other security public API classes only when security is enabled.

This behavior is different from the full profile. In full profile, all classes are always loaded regardless of whether security is enabled or not.


Troubleshooting LDAP

This section describes some common LDAP problems and solutions we can choose.

FFDC1015I: An FFDC Incident has been created: "javax.naming.ServiceUnavailableException: myldapserver.mycompany.com:636; socket closed com.ibm.ws.security.registry.ldap.internal.LdapRegistry 298

This message in messages.log indicates the configured LDAP server cannot be reached. Check the LDAP server to verify that it is running and that its IP address can be accessed from the Liberty profile server.

The javax.naming.CommunicationException: simple bind failed: myldapserver.mycompany.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g: PKIX path building failed: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target]

If we enable SSL on the LDAP server without copying the signer of the LDAP server into the truststore referenced in the LDAPSSLSettings element, a connection with the LDAP server fails with an SSL handshake error. Make sure that you copy the signer of the LDAP server into the truststore.

The javax.naming.CommunicationException: myldapserver.mycompany.com:389 [Root exception is java.net.BindException: Address already in use: connect]

This message might appear in the FFDC logs and indicates the usable sockets on the local server are exhausted, which can result in a failure when connecting to the LDAP server. Verify the socket is not used and try again.

CWWKS1100A: Authentication did not succeed for user ID xxxxx. An invalid user ID or password was specified

This FFDC exception might happen on the server even though the user mentioned in the message above is a valid user on the LDAP server under heavy load. With the LDAP configuration, we can add the reuseConnection=false property or disable it using the developer tools. To fix the problem, set this property to the default value of true.


Troubleshooting SSL

This section describes some common SSL problems and solutions we can choose.

CWWKS9105E: Could not determine the SSL port for automatic redirection.

This error occurs when you try to access an application that redirects to an SSL port and the SSL port is not available. The port might not be available because of a missing SSL configuration or some error in the SSL configuration definition. Check the SSL configuration in server.xml to verify it exists and is correct.

FFDC1015I: An FFDC Incident has been created: "java.lang.IllegalArgumentException: Unknown, incomplete configuration: missing id field com.ibm.ws.config.internal.cm.ManagedServiceFactoryTracker aSyncReadNupdate. Exception thrown while trying to read configuration and update ManagedServiceFactory. Exception = java.lang.IllegalArgumentException: Unknown, incomplete configuration: missing id field" at ffdc_12.04.18_16.09.42.0.log

This error occurs when a keystore element exists in the configuration without an ID field. If we use a minimal SSL configuration, set the ID field to defaultKeyStore.

The HTTPS port for VirtualHost name in plugin-cfg.xml file is missing

To use HTTPS ports in the plugin-cfg.xml when Configure the Liberty profile with a web server plug-in, we have to add a missing line for the VirtualHost element manually besides the configurations generated using the com.ibm.ws.jmx.mbeans.generatePluginConfig MBean. This line specifies the HTTPS port for the VirtualHost element.

The code example of HTTPS port for the VirtualHost element is as following: 
    ...
 <VirtualHostGroup Name="default_host">
    < VirtualHost Name="*:80"/>
    <VirtualHost Name="*:443"/>
    <VirtualHost Name="*:9080"/>
    <VirtualHost Name="*:9044">      
</VirtualHostGroup> ...

<Server CloneID="b564bdc7-2c27-4a4b-ad37-9213c66e60d1" ConnectTimeout="0" 

    ExtendedHandshake="false" MaxConnections="-1" Name="default_node_defaultServer0" 

    ServerIOTimeout="900" WaitForContinue="false">
    <Transport Hostname="somehost.example.com" Port="9080" Protocol="http"/>
    <Transport Hostname="somehost.example.com" Port="9044" Protocol="https">
    <Property Name="keyring" Value="PATH/FILE"/>
    <Property Name="stashfile" Value="PATH/FILE"/>
    <Property Name="certLabel" Value="REPLACE"/>
    </Transport>
</Server> 
...

You might get an exception if using a LDAP user registry with sslEnabled and a sslRef value is not specified.

For example, a configuration has sslEnable set to true but there is not a sslRef value, as shown in the following example:
    <ltldapRegistrySampleLdapIDSRealm" host="ccwin12.austin.ibm.com" port="636" ignoreCase="true"
    baseDN="o=ibm,c=us" bindDN="cn=root" bindPassword="rootpwd"
    ldapType="IBM Tivoli Directory Server"
    idsFilters="ibm_dir_server"
    sslEnabled="true"
    searchTimeout="8m" />

You must enter a sslRef value. If we are using a minimal SSL configuration similar to the following:

    <ltkeyStore id="defaultKeyStore" location="key.jks" password="mypassword" />

the sslRef field should be set to defaultSSLConfig.

If a custom SSL configuration is configured, the name of that configuration should be placed in the sslRef field.


Apply fix packs and interim fixes to an archive install

If we installed the Liberty profile runtime environment from an archive file, rather than through Installation Manager, you need to take special measures when you apply service updates. For more information, see Apply a fix pack to a Liberty profile archive install and Apply an interim fix to a Liberty profile archive install


See also

  1. Liberty profile: Trace and logging
  2. Liberty profile: Runtime environment known restrictions
  3. Liberty profile: Messages


Related


The Liberty profile


Related :

Liberty profile: Runtime environment known restrictions.
Liberty profile: Developer Tools known restrictions.


|