Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Users cannot Login with Active Directory credentials after server reboot.

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.

1 answer

0 votes
Daniel Ebers Community Leader Dec 30, 2020

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.

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

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 Community Leader Dec 30, 2020

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.

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 Community Leader Dec 30, 2020

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.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
SERVER
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you