Unable to login to Jira after a data refresh from the production environment
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. 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
Summary
Users are unable to log-in to the TEST Jira instance after a data refresh from production environment.
Environment
8.14
Diagnosis
Below error was seen in atlassian-jira.log .
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
2021-09-30 05:46:16,258+0000 https-jsse-nio-8443-exec-22 ERROR anonymous 346x1944x1 - xx.xx.xx.xx / [c.a.j.security.login.JiraSeraphAuthenticator] Error occurred while trying to authenticate user 'xxxxx'.
com.atlassian.crowd.exception.runtime.OperationFailedException
at com.atlassian.crowd.embedded.core.CrowdServiceImpl.convertOperationFailedException(CrowdServiceImpl.java:676)
at com.atlassian.crowd.embedded.core.CrowdServiceImpl.authenticate(CrowdServiceImpl.java:76)
at com.atlassian.jira.security.login.JiraSeraphAuthenticator.crowdServiceAuthenticate(JiraSeraphAuthenticator.java:75)
at com.atlassian.jira.security.login.JiraSeraphAuthenticator.authenticate(JiraSeraphAuthenticator.java:49)
at com.atlassian.seraph.auth.DefaultAuthenticator.login(DefaultAuthenticator.java:90)
at com.atlassian.jira.security.login.JiraSeraphAuthenticator.getUserFromBasicAuthentication(JiraSeraphAuthenticator.java:131)
at com.atlassian.seraph.auth.DefaultAuthenticator.getUser(DefaultAuthenticator.java:341)
.....more
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.springframework.ldap.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09044E, comment: AcceptSecurityContext error, data 57, v2580]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09044E, comment: AcceptSecurityContext error, data 57, v2580]
at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:191)
at org.springframework.ldap.core.support.AbstractContextSource.createContext(AbstractContextSource.java:355)
at org.springframework.ldap.core.support.AbstractContextSource.doGetContext(AbstractContextSource.java:139)
at org.springframework.ldap.core.support.AbstractContextSource.getReadWriteContext(AbstractContextSource.java:174)
at org.springframework.ldap.transaction.compensating.manager.TransactionAwareContextSourceProxy.getReadWriteContext(TransactionAwareContextSourceProxy.java:88)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:357)
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper$10.timedGet(SpringLdapTemplateWrapper.java:232)
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper$10.timedGet(SpringLdapTemplateWrapper.java:229)
at com.atlassian.crowd.directory.ldap.monitoring.TimedSupplier.get(TimedSupplier.java:37)
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper.invokeWithContextClassLoader(SpringLdapTemplateWrapper.java:96)
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper.search(SpringLdapTemplateWrapper.java:229)
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper.searchWithLimitedResults(SpringLdapTemplateWrapper.java:266)
at com.atlassian.crowd.directory.SpringLDAPConnector.searchEntitiesWithRequestControls(SpringLDAPConnector.java:471)
at com.atlassian.crowd.directory.SpringLDAPConnector.searchEntities(SpringLDAPConnector.java:438)
at com.atlassian.crowd.directory.SpringLDAPConnector.searchUserObjects(SpringLDAPConnector.java:641)
at com.atlassian.crowd.directory.SpringLDAPConnector.findUserWithAttributesByName(SpringLDAPConnector.java:597)
at com.atlassian.crowd.directory.SpringLDAPConnector.findUserByName(SpringLDAPConnector.java:584)
at com.atlassian.crowd.directory.SpringLDAPConnector.authenticate(SpringLDAPConnector.java:1007)
at com.atlassian.crowd.directory.DelegatedAuthenticationDirectory.authenticateAndUpdateOrCreate(DelegatedAuthenticationDirectory.java:187)
at com.atlassian.crowd.directory.DelegatedAuthenticationDirectory.authenticate(DelegatedAuthenticationDirectory.java:149)
at com.atlassian.crowd.manager.directory.DirectoryManagerGeneric.authenticateUser(DirectoryManagerGeneric.java:305)
at com.atlassian.crowd.manager.application.ApplicationServiceGeneric.authenticateUser(ApplicationServiceGeneric.java:176)
at com.atlassian.crowd.embedded.core.CrowdServiceImpl.authenticate(CrowdServiceImpl.java:70)
... 145 more
Caused by: javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C09044E, comment: AcceptSecurityContext error, data 57, v2580]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3261)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3207)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2993)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2907)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:347)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:189)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:243)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.init(InitialContext.java:244)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.springframework.ldap.core.support.LdapContextSource.getDirContextInstance(LdapContextSource.java:42)
at org.springframework.ldap.core.support.AbstractContextSource.createContext(AbstractContextSource.java:343)
... 167 moreThe exception "LDAP: error code 49" usually indicates an issue with authentication during the LDAP binding. However, the customer did not change any other configuration other than importing data from PROD. Also, the same environment was configured to use this LDAP earlier, and it was working fine. So, the same password was working fine earlier for the LDAP binding.
Cause
Until 8.14, passwords used for connection with external User Directories like Active Directory, OpenLDAP, or Crowd were stored as plaintext (JRASERVER-45612 - Active Directory/LDAP credentials stored in database in cleartext). It created security risks for customers. Starting Jira 8.14 passwords to External User Directories are encrypted using symmetric encryption. Encrypted passwords are stored in Jira table cwd_directory_attributes and are stored in their encrypted form along with the key location.
So, when the database was restored/copied to TEST env, it started looking for the file from the production and when you saved the password again, the system updated the encrypted value with the correct key location. Mentioned above encryption keys are stored in Jira shared home in directory namedkeys. Encryption keys are not part of backups generated by Jira. If sysadmin wants to backup encryption keys he must do it manually.
Solution
Use Recover Admin User option and gain the access to the system
Update the External User Directory configuration with the password which will fix the issue
OR
Copy directory namedkeys from Jira shared directory to the target environment as well
Note: The chances of getting into this situation while creating a new test instance are less as per the steps from the TEST env creation guide because it includes the steps to replicate JIRA_HOME and JIRA_INSTALL directories which will take care of the keys directory as well.
Was this helpful?