IBM Support

Users cannot login due to a PasswordCheckFailedException/CWWIM4529E error.



There may be multiple different causes of a PasswordCheckFailedException/CWWIM4529E error, not limited to an incorrect password.


A user login may fail due to a PasswordCheckFailedException/CWWIM4529E error in SystemOut.log. Here is an example:
CWWIM4529E The password verification for the 'principal_name' principal name failed. Root cause: 'root_exception'.

The root_exception will be provided by the LDAP system. For example, here is an exception from Microsoft (R) Active Directory:

javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1];
Resolved object: 'com.sun.jndi.ldap.LdapCtx@74d874d8''.

Resolving The Problem

Some common causes are:

1. Incorrect password.
2. Incorrect principal name.
3. User account disabled.
4. User account locked.
5. The user account distinguished name has changed in LDAP but the old distinguished name is still cached in WAS in the LDAP search results cache based on the configured timeout [2].

In general, to determine the root cause, consult the message and detailed error codes in the root_exception.

In the above example, we can break down the error code details as follows:

1. LDAP: error code 49 (= 0x31) = LDAP_INVALID_CREDENTIALS; The supplied credential is invalid. [3]
2. data 52e = 0x0000052E; ERROR_LOGON_FAILURE; Logon failure: Unknown user name or bad password. [4]
3. AcceptSecurityContext error 80090308 = SEC_E_INVALID_TOKEN; 0x80090308L; The function failed. The token passed to the function is not valid. [5]
4. "The DSID number is an ID that helps Microsoft Product Support Services debug the line of code from which the error was returned, if needed." (Microsoft)

In this example, ERROR_LOGON_FAILURE says that the cause is either an unknown user name or a bad password. The latter is usually determined by the LDAP administrator. The former can be caused by common cause #5 above: Before authentication, WAS may need to map a user name into a distinguished name. WAS will then send the distinguished name along with the password to the LDAP server. The mapping from user name to distinguished name may be done through an LDAP search. If "Cache the search results" is enabled in WAS [2], then the results of this search are cached in memory and may be used during the next authentication (if the cached result hasn't been removed due to a cache timeout).

For example, a user authenticates and LDAP returns the distinguished name CN=User,OU=Org1,DC=example,DC=com. If this user's distinguished name is updated in LDAP and the user attempts to authenticate again before the cached result has timed out, then WAS will send the old distinguished name to the LDAP server and an error such as the example error above will be returned due to an unknown user name.

For this reason, in general, we recommend a non-infinite (0) timeout for caching search results [2]. The default timeout is generally recommended as it is usually acceptable that user distinguished name changes take time to propagate through various backend systems and caches.

[1] CWWIM4529E
[2] Lightweight Directory Access Protocol performance settings

[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF012","label":"IBM i"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"},{"code":"PF035","label":"z\/OS"}],"Version":"8.5.5;8.5;8.0;7.0;6.1","Edition":"","Line of Business":{"code":"LOB15","label":"Integration"}}]

Document Information

Modified date:
15 June 2018