Cannot log into JIRA Service Desk issue

We installed this about six months ago.   None of the 3 users could log in successfully.

Need assistance.

2 answers

This widget could not be displayed.

You'll need to give us some basic information.

Error message: Sorry, an error occurred trying to log you in - please try again

 

Attempted password reset but received this message: 

This user account is managed in an external User Directory and JIRA is not able to update your password.

Please contact your System Administrator if you have any further queries.

Here are the details of your account:
---------------------------------------------------------------------
Username: xxxx
Email: xx
Full Name: xxxx

 

I know the password for my account is good and I can log on to the network.

Do you know what directory the JIRA is hooked up to?  Are you certain it's the same as your "network" one?

If so, then the next step is to go to the system admins for JIRA and ask them to look at why it's not reading/synchronising correctly with that directory.

This widget could not be displayed.

We have only 3 users.  All are administrators.  None of us can log on.  Is there a backway to access the server to find out why?  Is there a way to see the log?

No, you have to be able to log in.

There are ways to reset a log in or swap to another known directory, but there's no point in trying them until you know what the problem is. 

You need to talk to your system admins (as in the server people), get them to read the logs to find out what the problem is.

Here is another background.   The Hyper-V image running this application had its 180-day trial expired.   It was extended for another 180-day.

After the extension, the authentication start to fail.  How did that affect the Jira application?

I don't know.  Would a trial expiration disconnect your user management system?

The logs might tell you what happened there.

Jira was licensed.

I originally used a local account when I set up the Jira.  Then switched to our company LDAP for authentication.  I removed the local user account.

However, I am still able to log on to the Jira using that username but my access was limited for I cannot see anything more than "You can raise Group request from the options provided.

Ok, that might be useful information later.

Your next step is to read the logs.

 

The only entry I noticed was an application warning.

Log Name: Application
Source: Microsoft-Windows-MSDTC Client 2
Date: 7/18/2017 11:56:34 AM
Event ID: 4879
Task Category: CM
Level: Warning
Keywords: Classic
User: N/A
Computer: BSSG-JIRA
Description:
MSDTC encountered an error (HR=0x80000171) while attempting to establish a secure connection with system BSSG-JIRA.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-MSDTC Client 2" Guid="{155CB334-3D7F-4ff1-B107-DF8AFC3C0363}" EventSourceName="MSDTC Client 2" />
<EventID Qualifiers="32768">4879</EventID>
<Version>0</Version>
<Level>3</Level>
<Task>3</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2017-07-18T15:56:34.000000000Z" />
<EventRecordID>48241</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>Application</Channel>
<Computer>BSSG-JIRA</Computer>
<Security />
</System>
<EventData>
<Data Name="param1">80000171</Data>
<Data Name="param2">BSSG-JIRA</Data>
</EventData>
</Event>

Ah, sorry, I was not clear.  I mean the actual logs, not the semi-useless stuff Windows pretends is a log.

What do the application logs say?  You need to look in <jira home>/logs - probably for the atlassian-jira.log .  The simple experiment is to be "tailing" the log (i.e. reading it live) as someone tries oneof the logins that is failing.

Your Admin -> System Information page can tell you where the log is if you're not sure where your <jira-home> is.

a sample of log output:

2017-07-19 08:00:31,220 Caesium-1-4 ERROR ServiceRunner [c.atlassian.scheduler.JobRunnerResponse] Unable to synchronise directory
com.atlassian.crowd.exception.OperationFailedException: Error looking up attributes for highestCommittedUSN
at com.atlassian.crowd.directory.MicrosoftActiveDirectory.fetchHighestCommittedUSN(MicrosoftActiveDirectory.java:807)
at com.atlassian.crowd.directory.ldap.cache.UsnChangedCacheRefresher.synchroniseAll(UsnChangedCacheRefresher.java:161)
at com.atlassian.crowd.directory.DbCachingRemoteDirectory.synchroniseCache(DbCachingRemoteDirectory.java:1186)
at com.atlassian.crowd.manager.directory.DirectorySynchroniserImpl.synchronise(DirectorySynchroniserImpl.java:74)
at com.atlassian.jira.crowd.embedded.JiraDirectorySynchroniser.synchronizeDirectory(JiraDirectorySynchroniser.java:77)
at com.atlassian.jira.crowd.embedded.JiraDirectorySynchroniser.runJob(JiraDirectorySynchroniser.java:52)
at com.atlassian.scheduler.core.JobLauncher.runJob(JobLauncher.java:153)
at com.atlassian.scheduler.core.JobLauncher.launchAndBuildResponse(JobLauncher.java:118)
at com.atlassian.scheduler.core.JobLauncher.launch(JobLauncher.java:97)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.launchJob(CaesiumSchedulerService.java:443)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeClusteredJob(CaesiumSchedulerService.java:438)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeClusteredJobWithRecoveryGuard(CaesiumSchedulerService.java:462)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService.executeQueuedJob(CaesiumSchedulerService.java:390)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService$1.consume(CaesiumSchedulerService.java:285)
at com.atlassian.scheduler.caesium.impl.CaesiumSchedulerService$1.consume(CaesiumSchedulerService.java:282)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeJob(SchedulerQueueWorker.java:65)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.executeNextJob(SchedulerQueueWorker.java:59)
at com.atlassian.scheduler.caesium.impl.SchedulerQueueWorker.run(SchedulerQueueWorker.java:34)
at java.lang.Thread.run(Thread.java:745)

Caused by: org.springframework.ldap.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A8, comment: AcceptSecurityContext error, data 52e, v1db1 ]; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A8, comment: AcceptSecurityContext error, data 52e, v1db1 ]
at org.springframework.ldap.support.LdapUtils.convertLdapException(LdapUtils.java:191)
at org.springframework.ldap.core.support.AbstractContextSource.createContext(AbstractContextSource.java:356)
at org.springframework.ldap.core.support.AbstractContextSource.doGetContext(AbstractContextSource.java:140)
at org.springframework.ldap.core.support.AbstractContextSource.getReadWriteContext(AbstractContextSource.java:175)
at org.springframework.ldap.transaction.compensating.manager.TransactionAwareContextSourceProxy.getReadWriteContext(TransactionAwareContextSourceProxy.java:88)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:357)
at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:440)
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper$2.timedCall(SpringLdapTemplateWrapper.java:205)
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper$TimedCallable.call(SpringLdapTemplateWrapper.java:146)
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper.invokeWithContextClassLoader(SpringLdapTemplateWrapper.java:109)
at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper.lookup(SpringLdapTemplateWrapper.java:194)
at com.atlassian.crowd.directory.MicrosoftActiveDirectory.fetchHighestCommittedUSN(MicrosoftActiveDirectory.java:783)

Caused by: javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A8, comment: AcceptSecurityContext error, data 52e, v1db1 ]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3136)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3082)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2883)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2797)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)

I need some help here.  Looks like the application is having issue with authentication. 

I know all users can authenticate to the target LDAP.

We need to resolve this or this application is useless.

Ah, that's a really simple one.  "LDAP: error code 49 ... data 52e" means "the user you are trying to connect to LDAP with has been rejected because the username and password combination is wrong".  It's not the users themselves, it's the account you are using to talk to LDAP with.

Check the directory settings in JIRA - the user name should be there, and you can paste a new password in to correct it.  After checking with your LDAP people that the user exists and has access.

All three users cannot log into the application.  How do I go about accessing this configuration and verify the settings?

Ok.  When you set it up, there should have been an administrator set up automatically, in the internal directory, before you hooked it up to LDAP.

This can get a bit complex, because there are a number of possible blockers here:

  • You don't know that account
  • It is similar to your LDAP account, so the LDAP account blocks the internal one
  • You may have removed its rights after adding the LDAP directory
  • You may have turned off the internal directory
  • You might have removed the account

What you need to do is set up access to an account you can use to do admin, and make sure it appears in the first directory.  To work through that, see https://confluence.atlassian.com/doc/restore-passwords-to-recover-admin-user-rights-158390.html

Ann Worley Atlassian Team Jul 21, 2017

I think Nic meant to link: Retrieving the JIRA Administrator

Yes, sorry.  The change of style in the docs for 7 hasn't caught up on google...

My version is v7.3.1#73012-sha1:68837e3

I do not see similar directories per the instruction on the link sent.

Am I missing something?

You may well have very different directories.  You need to identify the "internal" one.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Aug 13, 2018 in Jira Service Desk

Jira Service Desk – Don’t be afraid, the journey begins with curiosity!

...be more productive while being fun to use at the same time. For some, getting started can be a bit intimidating. This is especially true if Jira Service Desk is your first exposure to Atlassian...

8,727 views 9 28
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you