Jira Data Center requests intermittently fail with 401 Error
Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.
Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles 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
Jira REST API responds with a 401 error intermittently for a valid user.
External integration requests to Jira are sometimes rejected, with 401 unauthorized responses.
Environment
Jira 8.x, 9.x
Diagnosis
Check security logs and see that the user is sometimes failing to authenticate:
2023-02-20 17:09:00,982+0000 ajp-nio-0.0.0.0-8600-exec-1613 anonymous 1029x10688423x2 13chojl 10.1.103.156 /rest/api/2/serverInfo login : '<username>' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.
...
2023-02-20 17:09:00,989+0000 ajp-nio-0.0.0.0-8600-exec-1613 anonymous 1029x10688423x2 13chojl 10.1.103.156 /rest/api/2/serverInfo The user '<username>' has FAILED authentication. Failure count equals 15Enable debug logging for these classes:
com.atlassian.jira.login
com.atlassian.jira.login.security
com.atlassian.crowd.directory.SpringLDAPConnector
com.atlassian.crowd.embedded.atlassianuser.EmbeddedCrowdAuthenticator
org.springframework.ldap.core
com.atlassian.crowd.embedded
com.atlassian.crowd.directory
com.sun.jndi.ldapFurther, on a successful login, all the expected groups are found for the user:
2023-02-20 16:48:05,133+0000 ajp-nio-0.0.0.0-8600-exec-1630 DEBUG anonymous 1008x10665967x3 - 10.1.103.156 /rest/api/2/serverInfo [o.s.l.core.support.AbstractContextSource] Got Ldap context on server 'ldaps://ldap.server.com:1636'
2023-02-20 16:48:05,142+0000 ajp-nio-0.0.0.0-8600-exec-1630 DEBUG anonymous 1008x10665967x3 - 10.1.103.156 /rest/api/2/serverInfo [c.a.c.d.ldap.monitoring.ExecutionInfoNameClassPairCallbackHandler] The operation returned 4 results
2023-02-20 16:48:05,142+0000 ajp-nio-0.0.0.0-8600-exec-1630 DEBUG anonymous 1008x10665967x3 - 10.1.103.156 /rest/api/2/serverInfo [c.a.c.d.ldap.monitoring.TimedSupplier] Timed call for search with handler on baseDN: ou=Jira,ou=WebServer,ou=...,ou=ACLs,dc=...,dc=com, filter: (&(objectclass=groupOfUniqueNames)(uniqueMember=uid=...,ou=people,dc=...,dc=com)) took 90ms
2023-02-20 16:48:05,142+0000 ajp-nio-0.0.0.0-8600-exec-1630 DEBUG anonymous 1008x10665967x3 - 10.1.103.156 /rest/api/2/serverInfo [c.a.crowd.directory.DbCachingRemoteDirectory] Updating groups on login for user <username>Cause 1
Jira does a lookup for the user and if the user is in groups, it will query for the groups as well.
In this case where the login succeeded, the user '<username>' was returned with several groups from the active directory: ou=Jira,ou=WebServer,ou=...,ou=ACLs.
In the case where login fails, the user's groups are not returned.
Cause 2
If LDAP is clustered, it's possible that the LDAP nodes have differing data, and Jira cannot reconcile this.
Solution 1
This is not something that Jira controls since it is synchronized from the active directory. However, you may be able to verify in Jira that the user's groups are not as expected at the time of failure in user management.
Solution 2
To remedy this, it's best to always connect Jira to the same LDAP server and ensure that Jira's authentication requests don't get sent to multiple LDAP nodes.