Users cannot Login with Active Directory credentials after server reboot.

[Reto Kämpfer]

We rebooted the server that is hosting the Jira server local and now we cannot login with our AD credentials. The message is Username and password is wrong. We have looked in the log (atlassian-jira-security.log) and found this:

2020-12-30 11:54:20,258+0100 https-openssl-nio-8443-exec-5 anonymous 714x118x1 - 192.168.0.250 /secure/Dashboard.jspa HttpSession created [16dqcn3]
2020-12-30 12:34:31,876+0100 https-openssl-nio-8443-exec-20 anonymous 754x183x1 - 89.247.124.152 /secure/Dashboard.jspa HttpSession created [1vnifdw]
2020-12-30 12:54:50,423+0100 ContainerBackgroundProcessor[StandardEngine[Catalina]] HttpSession [16dqcn3] destroyed for 'anonymous'
2020-12-30 13:07:05,282+0100 https-openssl-nio-8443-exec-7 anonymous 787x311x1 - 192.168.0.63 / HttpSession created [112j09n]
2020-12-30 13:14:50,122+0100 https-openssl-nio-8443-exec-10 anonymous 794x352x1 - 192.168.0.250 /secure/Dashboard.jspa HttpSession created [1yk8m5d]
2020-12-30 13:15:44,256+0100 https-openssl-nio-8443-exec-14 anonymous 795x371x1 - 192.168.0.250 /secure/Dashboard.jspa HttpSession created [1934a64]
2020-12-30 13:24:20,737+0100 https-openssl-nio-8443-exec-18 anonymous 804x414x1 - 192.168.0.250 /secure/MyJiraHome.jspa HttpSession created [xoatsv]
2020-12-30 13:34:52,371+0100 ContainerBackgroundProcessor[StandardEngine[Catalina]] HttpSession [1vnifdw] destroyed for 'anonymous'
2020-12-30 13:41:52,694+0100 ContainerBackgroundProcessor[StandardEngine[Catalina]] HttpSession [43kb4r] destroyed for 'anonymous'
2020-12-30 13:51:35,607+0100 https-openssl-nio-8443-exec-10 anonymous 831x492x1 - 192.168.0.250 / HttpSession created [ntozzm]

Can it be this the problem.We have also looked about this problem but it seems to be something else.

[Daniel Ebers]

Hi Reto,

a reboot should not kill anything but on the other side there is nothing unusual from the logs you posted.
Also a healthy system shows those lines during authentication.

There are two entries in knowledge base but but of them report that those errors would write to atlassian-jira.log - you mentioned atlassian-jira-security.log which is also an important one but probably will never show in-depth trouble with the authentication mechanism itself (rather information to the actually logins/failed logins - rather security relevant information).

So in first steps I'd like you to review atlassian-jira.log for any potential errors.

• Active Directory users fail to logon intermittently
  https://confluence.atlassian.com/jirakb/active-directory-users-fail-to-logon-intermittently-945118456.html
• Users not able to log into JIRA using LDAP Connector AD
  https://confluence.atlassian.com/jirakb/users-not-able-to-log-into-jira-using-ldap-connector-ad-297666580.html

Something theoretical before stopping here: could it be due to a missing SSL certificate agains Active Directory which were present until reboot? This, unfortunately is only a wild guess without knowing the server.

Please let us know what you found out.

Regards,
Daniel

[Reto Kämpfer]

hello Daniel

thank you for your fast response. Here is a part from my atlassian-jira.log:

2020-12-30 14:52:00,002+0100 Caesium-1-4 WARN ServiceRunner [o.o.c.entity.transaction.JNDIFactory] [JNDIFactory.getUserTransaction] Failed to find UserTransaction named java:comp/env/UserTransaction in JNDI.
2020-12-30 14:52:00,017+0100 Caesium-1-4 WARN ServiceRunner [o.o.c.entity.transaction.JNDIFactory] NamingException while finding UserTransaction named java:comp/env/UserTransaction in JNDI.
javax.naming.NamingException: Could not create resource instance
at org.apache.naming.factory.FactoryBase.getObjectInstance(FactoryBase.java:98)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
at org.apache.naming.NamingContext.lookup(NamingContext.java:839)
at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
at org.apache.naming.NamingContext.lookup(NamingContext.java:173)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:163)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.ofbiz.core.entity.transaction.JNDIFactory.getUserTransaction(JNDIFactory.java:125)
at com.atlassian.jira.ofbiz.sql.TransactionFactoryInterfaceWrapper.getUserTransaction(TransactionFactoryInterfaceWrapper.java:31)
at org.ofbiz.core.entity.TransactionFactory.getUserTransaction(TransactionFactory.java:106)
at org.ofbiz.core.entity.TransactionUtil.getStatus(TransactionUtil.java:91)
at org.ofbiz.core.entity.jdbc.SQLProcessor.getConnection(SQLProcessor.java:369)
at org.ofbiz.core.entity.jdbc.SQLProcessor.prepareStatement(SQLProcessor.java:456)
at org.ofbiz.core.entity.jdbc.SQLProcessor.prepareStatement(SQLProcessor.java:436)
at org.ofbiz.core.entity.GenericDAO.deleteByCondition(GenericDAO.java:1232)
at org.ofbiz.core.entity.GenericHelperDAO.removeByCondition(GenericHelperDAO.java:244)
at org.ofbiz.core.entity.GenericDelegator.removeByCondition(GenericDelegator.java:1370)
at com.atlassian.jira.ofbiz.DefaultOfBizDelegator.removeByCondition(DefaultOfBizDelegator.java:142)
at com.atlassian.jira.ofbiz.WrappingOfBizDelegator.removeByCondition(WrappingOfBizDelegator.java:136)
at com.atlassian.jira.entity.Delete$DeleteWhereContext.execute(Delete.java:154)
at com.atlassian.jira.entity.EntityEngineImpl.delete(EntityEngineImpl.java:55)
at com.atlassian.jira.entity.Delete$DeleteWhereContext.execute(Delete.java:136)
at com.atlassian.jira.scheduler.OfBizRunDetailsDao.addRunDetails(OfBizRunDetailsDao.java:116)
at com.atlassian.scheduler.core.AbstractSchedulerService.addRunDetails(AbstractSchedulerService.java:136)
at com.atlassian.scheduler.core.JobLauncher.launch(JobLauncher.java:91)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.launchJob(CaesiumSchedulerService.java:435)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeClusteredJob(CaesiumSchedulerService.java:430)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeClusteredJobWithRecoveryGuard(CaesiumSchedulerService.java:454)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeQueuedJob(CaesiumSchedulerService.java:382)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeJob(SchedulerQueueWorker.java:66)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeNextJob(SchedulerQueueWorker.java:60)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.run(SchedulerQueueWorker.java:35)
at java.lang.Thread.run(Thread.java:748)
2020-12-30 14:52:00,017+0100 Caesium-1-4 WARN ServiceRunner [o.o.c.entity.transaction.JNDIFactory] [JNDIFactory.getUserTransaction] Failed to find UserTransaction named java:comp/env/UserTransaction in JNDI.

This error it keeps repeating . About the SSL Certificate against the AD can you explain me how do i find that if is missing?

Many thanks!

[Daniel Ebers]

You could view the keystore using the following guide from the knowledge base. It might make sense to postpone this idea.
At least there was a match for your latest error message from knowledge base:
https://confluence.atlassian.com/jirakb/namingexception-while-finding-usertransaction-named-java-comp-env-usertransaction-in-jndi-283641257.html

I have never faced it so I cannot recommend anything special here yet but using a non-production environment (that probably shows the same error) you should be able to test if this has some kind of contribution or if it is just an independent occurrence / some coincidence.

[Reto Kämpfer]

I have checked some old logs before the restart and this error is for a long time. I think is more of a problem about the user cannot authenticate against the AD server. But also there everything works.

[Daniel Ebers]

Yes, I understand. Unfortunately the option from far remote here are a bit limited.
If there is not much additionally from the logs maybe a experience Jira<->AD admin will chime in later.