CLM 4.0.1: Users are unable to login to RTC, RQM and RRC
My environment:
CLM 4.0.1 installed on Windows Server 2008 R2. Database is SQL Server, Application server is WebSphere Application Server 8.0. CLM has been configured to use LDAP authentication.
Since yesterday users are unable to login to RTC, RQM and RRC. The login page appears and everyone gets invalid user name and password error when using AD credentials. Users are able to log in to ClearQuest and RequisitePro which use AD authentication so the issue is not with AD accounts.
I looked at the SystemOut.log file located in the folder C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\server1\ and it has these entries for each user attempting to log in. I tried restarting the server and it didn't resolve the issue.
[4/23/13 8:51:31:124 EDT] 00000058 LdapRegistryI E SECJ0336E: Authentication failed for user potti-narayanan because of the following exception com.ibm.websphere.security.CustomRegistryException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1 ]
[4/23/13 8:51:31:125 EDT] 00000058 LTPAServerObj E SECJ0369E: Authentication failed when using LTPA. The exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1\u0000]
Please help ! Extended outage of CM applications has put the entire project at risk. Any help will be greatly appreciated.
Thank You
NP
CLM 4.0.1 installed on Windows Server 2008 R2. Database is SQL Server, Application server is WebSphere Application Server 8.0. CLM has been configured to use LDAP authentication.
Since yesterday users are unable to login to RTC, RQM and RRC. The login page appears and everyone gets invalid user name and password error when using AD credentials. Users are able to log in to ClearQuest and RequisitePro which use AD authentication so the issue is not with AD accounts.
I looked at the SystemOut.log file located in the folder C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\server1\ and it has these entries for each user attempting to log in. I tried restarting the server and it didn't resolve the issue.
[4/23/13 8:51:31:124 EDT] 00000058 LdapRegistryI E SECJ0336E: Authentication failed for user potti-narayanan because of the following exception com.ibm.websphere.security.CustomRegistryException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1 ]
[4/23/13 8:51:31:125 EDT] 00000058 LTPAServerObj E SECJ0369E: Authentication failed when using LTPA. The exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1\u0000]
Please help ! Extended outage of CM applications has put the entire project at risk. Any help will be greatly appreciated.
Thank You
NP
Accepted answer
This was resolved by correcting the bind user in the WAS admin console. It appears as though someone may have moved the bind account to a different OU which prevented WAS from being able to communicate with Active Directory.
3 other answers
I did a quick internet search of the error codes and according to https://wiki.servicenow.com/index.php?title=LDAP_Error_Codes, the error code 52e is AD_INVALID CREDENTIALS and means:
Indicates an Active Directory (AD) AcceptSecurityContext error, which is returned when the username is valid but the combination of password and user credential is invalid.This is the AD equivalent of LDAP error code 49.
http://www-01.ibm.com/support/docview.wss?uid=swg21290631 may also be useful.
Have you verified that your LDAP settings are correct?
Indicates an Active Directory (AD) AcceptSecurityContext error, which is returned when the username is valid but the combination of password and user credential is invalid.This is the AD equivalent of LDAP error code 49.
http://www-01.ibm.com/support/docview.wss?uid=swg21290631 may also be useful.
Have you verified that your LDAP settings are correct?
@Bo Chulindra,
There was no configuration changes done in WebSphere application server or Jazz Team Server. LThat's what makes the problem scary. When CLM was configured to use AD authentication settings were done in WAS Administration Console. WAS Admin is unable to log in to the WAS Admin console so I am not able to verify the settings.
@Indradi Basu,
Password of the bind user used to connect to LDAP server has not expired. There was no change to the bind user's credentials. Bind user is able to log in to ClearQuest using AD credentials.
Are there any other log files to look into besides WAS SystemOut.log ? Please let me know.
Thank You
NP
There was no configuration changes done in WebSphere application server or Jazz Team Server. LThat's what makes the problem scary. When CLM was configured to use AD authentication settings were done in WAS Administration Console. WAS Admin is unable to log in to the WAS Admin console so I am not able to verify the settings.
@Indradi Basu,
Password of the bind user used to connect to LDAP server has not expired. There was no change to the bind user's credentials. Bind user is able to log in to ClearQuest using AD credentials.
Are there any other log files to look into besides WAS SystemOut.log ? Please let me know.
Thank You
NP
Comments
Anthony Kesterton
JAZZ DEVELOPER Apr 23 '13, 4:14 p.m.Definitely raise this with support as it is a production outage and it needs to be fixed quickly.
In the meantime - is there any way to check you can see the AD server from the server running CLM. Then check absolutely nothing has changed on the AD server, users moved to a new domain or sub-domain, etc. Remember that your AD/LDAP accounts need to belong to a group like JazzUser or JazzAdmin - and if anyone has either changed the LDAP to RTC user group mapping, or changed the name of the LDAP group - that will cause problems.
Another obscure idea to try - type in your password in the text box for the user id - to check the letters you type are as expected. Very unlikely this is the problem - but if something has changed the keyboard/language settings on your clients...