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.
How do I fix this error CWPKI0033E CWPKI0201E ltpa.jceks Keystore was tampered with, or password was incorrect?
javax.security.auth.login.LoginException: Login Failure: all modules ignored
How to fix 'LDAP: error code 49 in the Microsoft Active Directory'?
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:
SECJ0129E - Authorization failed for user wasadmin:DefaultWIMFileBasedRealm while invoking GET on default_host exception?
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
Why am I unable to assign administrative user roles when I choose a non-default user realm?
Which algorithm does WebSphere Application Server use to store user passwords?
Cookie “LTPAToken2” does not have a proper “SameSite” attribute value.
I am unable to start the node agent or deployment manager. I see the following error in the SystemOut.log:
| 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. |
Problem determination:
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.
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
I'm getting this error when my web services application runs on WebSphere Application Server:
| [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 |
Problem determination:
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.
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'?
Symptoms of this error are usually seen in the SystemOut.log file. You might see the following error messages:
| [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) |
Problem determination:
Check the trace.log file for:
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 |
Solution:
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
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?
A web application is deployed on my WebSphere Application Server and I get the following error when accessing the web application with my browser:
| [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 |
Problem determination:
The SECJ0129E error message indicates that the user mentioned in the error message failed authorization and is therefore not allowed to access the web application. This error might be caused by a missing user or group to security role mapping.
Solution:
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
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 problem is that role mappings are made with realm-qualified accessIds.
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.
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?
In the WebSphere Admin Console's Users and Groups > Administrative user roles panel, under Search and Select Users, when User realm lists multiple realms, selecting a realm other than the WebSphere current realm (for example, the default realm is called defaultWIMFileBaseRealm), results in the following output:
| 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. |
Cause:
There are multiple values listed under User realm on the panel that originate from:
- 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.
Consider the following:
- 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.
Solution:
- 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.
In the FireFox browser, you might encounter a warning that is similar to this one for the LTPAToken2, JWT, or WAS_* cookies:
|
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
|
Action:
- WebSphere Application Server traditional
- To prevent this warning, set the com.ibm.websphere.security.addSameSiteAttributeToCookie global security custom property to Lax.
- Liberty
- To prevent this warning, set the sameSiteCookie attribute in the webAppSecurity element in your server.xml file to Lax. See Setting the SameSite attribute on cookies with Open Liberty.
- Example:
<webAppSecurity sameSiteCookie="Lax"/>
Note:
This document uses the term WebSphere traditional to refer to WebSphere Application Server v9.0 traditional, WebSphere Application Server v8.5 full profile, WebSphere Application Server v8.0 and earlier, WebSphere classic, traditional WebSphere, traditional WAS, and tWAS.
Document Location
Worldwide
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Component":"Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
10 January 2024
UID
ibm11079535