Users are unable to log in to JIRA (LDAP: error code 49, data 52e)

Atlassian Knowledge Base

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Problem

Users are unable to log in. Nothing has changed in JIRA side.

The following appears in the atlassian-jira.log:

2017-10-25 14:13:07,009 ERROR [scheduler_Worker-3] [atlassian.crowd.directory.DbCachingDirectoryPoller] pollChanges Error occurred while refreshing the cache for directory [ 31064065 ].
com.atlassian.crowd.exception.OperationFailedException: Error looking up attributes for highestCommittedUSN
	at com.atlassian.crowd.directory.MicrosoftActiveDirectory.fetchHighestCommittedUSN(MicrosoftActiveDirectory.java:847)

...

Caused by: org.springframework.ldap.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580 ]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580 ]

Cause

LDAP Error 49 data 52e means that the credentials of the user configured to bind LDAP directory with JIRA are incorrect, as described here: https://confluence.atlassian.com/kb/common-user-management-errors-820119309.html#CommonUserManagementErrors-ActiveDirectoryError49

This can happen when that user is either removed or has its password changed from LDAP side.

Resolution 1

Follow the steps outlined at Restore Passwords To Recover Admin User Rights. By doing so, you'll be able to access the User Directory settings and change the "Username" field with a valid admin user or change the "Password" field with the new password, allowing JIRA to connect to LDAP.

As an alternative to Recovery Mode, you could utilize auth_fallback by following the guide: Bypass SAML authentication for Jira Data Center 

Resolution 2

Alternatively, you can run the following query against your database to find out which one is the admin account that JIRA uses to connect to the LDAP:

SELECT * FROM cwd_directory_attribute WHERE attribute_name = 'ldap.userdn'; 


Note: The query may return multiple results in case you have more than one User Directory in your JIRA instance.

Re-adding the user back to the LDAP with the same password should resolve the issue.

Resolution 3

As JIRA storing LDAP Login credential in the database without encryption, you may also update those LDAP credential in your database:

lDAP Password Field

Select * from cwd_directory_attribute where attribute_name = 'ldap.password'

LDAP User Name Field

SELECT * FROM cwd_directory_attribute WHERE attribute_name = 'ldap.userdn';

(info) attribute_value is the fields which storing those data.

(info)  Always perform a backup before you perform edit/update query in the database. It is also highly recommended for you to perform this in a test instance before proceeding with production instance.


Last modified on Jan 25, 2023

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.