Troubleshooting
Problem
Use this document to troubleshoot WebSphere and Liberty core security. This document contains troubleshooting information for core security problems in WebSphere® Application Server and Liberty. This document might help address common issues with this component before you call IBM support and save you time.
Resolving The Problem
Overview
This topic contains error messages and common issues that might require a Security trace to determine the root cause of the problem. The instructions to obtain a Security trace are on the Collect data tab. If a trace string different than what is on the Collect data is required for a specific problem, that trace string is noted in the steps to diagnose the problem.
WSKeyStore E CWPKI0033E: The keystore located at "C:/Program Files/IBM/Websphere/Appserver/profile/profilename/config/cells/ltpa.jceks" failed to load due to the following error: Keystore was tampered with, or password was incorrect. WSKeyPairRefe E CWPKI0201E: Error retrieving key alias CELLLTPAKeyPair from KeySet LTPAKeyPair_1. The exception that occurred is: Keystore was tampered with, or password was incorrect. |
Check that CellLTPAKeys, LTPAKeyPair, and LTPASecret password match in your security.xml file in the WAS_HOME/profiles/profileName/config/cells/cellName directory. If the password for CellLTPAKeys, LTPAKeyPair and LTPASecret is not matching then you encounter CWPKI0033E and CWPKI0201E errors.
Solution:
Disable security, then update the CellLTPAKeys password, re-enable security, and restart the application server.
javax.security.auth.login.LoginException: Login Failure: all modules ignored
[9/3/15 12:43:45:213 EDT] 0000002c WSSecurityGen 3 Error in security handler: org.apache.axis2.AxisFault: CWWSS6521E: The Login failed because of an exception: javax.security.auth.login.LoginException: Login Failure: all modules ignored at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430) at com.ibm.ws.wssecurity.handler.WSSecurityGeneratorBase.invoke(WSSecurityGeneratorBase.java:151) at com.ibm.ws.wssecurity.handler.WSSecurityGeneratorHandler._invoke(WSSecurityGeneratorHandler.java:606) .... (~60 entries snipped) Caused by: javax.security.auth.login.LoginException: Login Failure: all modules ignored at javax.security.auth.login.LoginContext.invoke(LoginContext.java:929) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:211) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:703) at java.security.AccessController.doPrivileged(AccessController.java:362) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:700) at javax.security.auth.login.LoginContext.login(LoginContext.java:606) at com.ibm.ws.wssecurity.wssapi.token.impl.WSSObjectCommonTokenGenerator.invoke(WSSObjectCommonTokenGenerator.java:290) ... 79 more |
What this means is that one of the login modules in your JAAS config threw an exception. It indicates "I was working through the login modules and there was an error so I'm not going to do the rest of them".
Unfortunately, this error doesn't really indicate why the exception occurred in the login module or which login module the exception occurred. In the 'caused by stack', you can see who invoked lc.login(). If the invoker of lc.login() has logging code of its own, it is printed earlier in the thread.
How to fix 'LDAP: error code 49 in the Microsoft Active Directory'?
[date/time] 0000000a LdapRegistryI A SECJ0419I: The user registry is currently connected to the LDAP server ldap:// [date/time] 0000000a LTPAServerObj E SECJ0369E: Authentication failed when using LTPA. The exception is [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 775, vece ]. [date/time] 0000000a distContextMa E SECJ0270E: Failed to get actual credentials. The exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 775, vece ] at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3005) |
Check the trace.log file for:
"The exception is [ LDAP: error code 49 - 80090308: LdapErr: DSID-0Cxxxxxx, comment: AcceptSecurityContext error, data xxx, vece ]." |
This error means that the credentials provided are not valid. Either the userid or password is incorrect or the bindDN or password is incorrect. You might see Active Directory specific error codes:
525 | user not found |
52e | invalid credentials |
530 | not permitted to logon at this time |
531 | not permitted to logon at this workstation |
532 | password expired |
533 | account disabled |
534 | The user has not been granted the requested logon type at this machine |
701 | account expired |
773 | user must reset password |
775 | user account locked |
Consult the Microsoft documentation for a list of Active Directory LDAP bind errors and information on how to resolve these errors.
See the System Error Codes: System Error Codes
Also, check the Microsoft Error Lookup Tool: Microsoft Error Lookup Tool
SECJ0129E - Authorization failed for user wasadmin:DefaultWIMFileBasedRealm while invoking GET on default_host exception?
[3/26/15 9:58:14:076 GMT+05:30] 0000021c WebCollaborat A SECJ0129E: Authorization failed for user wasadmin:defaultWIMFileBasedRealm while invoking GET on default_host:/path_to_servlet/servlet/servletname, Authorization failed, Not granted any of the required roles: monitor |
Add the user or group from the error message to the security role that the application requires:
1. In the WebSphere Admin Console, go to Applications > Application types > WebSphere enterprise applications >application_name. Under Detail Properties, click Security role to user/group mapping
2. Select the security role to which you’d like to add the user (in this example “monitor”)
3. Click to Map Users
4. Search for and select the user to which you’d like to assign the security role (in this example “wasadmin”)
5. In the Security role to user/group-mapping configuration window, verify that the user is successfully mapped to the security role
For reference, see Security role to user or group mapping
I changed the LDAP server hostname or port in my stand-alone LDAP configuration and now I am getting authorization errors when I log in to my application
The role mappings become invalid if the realm name of the WebSphere cell changes because all the users authenticating to the cell is from a different realm than the one with which the mappings were made.
One way to fix the issue is to re-create the mappings with the new realm name. This behavior comes into play more often with stand-alone LDAP because, by default, any changes to a stand-alone LDAP host and port affect the realm name. The WebSphere security property com.ibm.websphere.security.ldap.logicRealm can be used to prevent this realm name change.
This problem is not specific to LDAP; it does not depend on the registry type at all. The issue is dependent upon the realm name, not the registry configuration.
The com.ibm.websphere.security.ldap.logicRealm property is documented at https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.5/com.ibm.websphere.nd.multiplatform.doc/ae/usec_seccustomprop.html#logicrealm.
Why am I unable to assign administrative user roles when I choose a non-default user realm?
The selected realm cannot be accessed at this time. You may need to start the server. Otherwise, you can use the following fields to add users by their unique user IDs. |
- The current repository's realm name:
- Security > Global security > Realm name
- The federated repository default is defaultWIMFileBaseRealm
- Trusted external realms:
- Security > Global security > RMI/IIOP security > CSIv2 inbound communications > Trusted authentication realms - inbound
- Choosing the Trusted external realm value under User realm assigns a role to a user from a foreign realm.
- Operating with the administrative agent and job manager topology allows more situations where you might need to add an administrative user from a different registry into your administrative authorization table (admin-authz.xml).
- Each administrative user that needs to be added requires the accessID format of the user from the remote registry.
- When the user is active in the local cell, the authorization table already has the accessID that is required.
- Usually, you only need to assign the administrative role to users in the local realm.
- When you do need to add an administrative user from a different registry, directly input expected values into the fields. Example:
- User short name: user1
- User realm name: foreignrealm1
- Unique user ID: trustedexternalrealmname/user1@foreignrealm1
Which algorithm does WebSphere Application Server use to store user passwords?
First, check which registry is in use:
- In the Admin Console, navigate to Security > Global security.
- The registry that is in use is listed under Current realm definition.
If the registry in use is Local operating system, Standalone LDAP registry, or Standalone custom registry, the password is not stored in WebSphere. Check with the LDAP administrator or custom registry developer to determine which algorithm is used to store the passwords.
If the registry in use is Federated repositories, perform the following actions to find the algorithm:
- Click Configure...
- Under Repositories in the realm, if only LDAP servers are listed, then all passwords are stored on the LDAP server.
- Check with the LDAP administrator to determine which algorithm is used to store the passwords.
- If InternalFileRepository is listed, iit is the WebSphere file registry:
- Click Manage repositories > InternalFileRepository
- On this page, the algorithm used to store user passwords for the file registry is listed under Message digest algorithm
- The default value is PBKDF2WithHmacSHA1. Before 8.5.5.17 and 9.0.5.1, the default was SHA-1.
Cookie “LTPAToken2” does not have a proper “SameSite” attribute value.
Some cookies are misusing the recommended “SameSite“ attribute:
- Cookie “LTPAToken2” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite for navigator request
|
- WebSphere Application Server traditional
- To prevent this warning, set the com.ibm.websphere.security.addSameSiteAttributeToCookie global security custom property to Lax.
- Liberty
- sameSiteCookie attribute in the webAppSecurity element in your server.xml file to Lax. See Setting the SameSite attribute on cookies with Open Liberty. To prevent this warning, set the
- Example:
<webAppSecurity sameSiteCookie="Lax"/>
Note:
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
10 January 2024
UID
ibm11079535