Administrator login doesn't work with Jira/Crowd

[Simon Churcher]

I have Jira/Confluence/Bitbucket all authenticating correctly with Crowd.

I can log in to Jira with user 'john' who is both a user and a System Administrator. When I go to the system settings however, the re-authentication box appears and the password for 'john' isn't accepted. The user is in the correct group for System Administrators and the group has been assigned into the System Administrators role. It also works fine with Confluence and Bitbucket - it's just Jira.

Any ideas?

[Andy Heinzer]

HI Simon,

I understand that this user can login to Jira, and apparently sees the menus for system administration which a Jira Admin should have, but then the secure sessions option in Jira appears and this user cannot seem to authenticate again in this box.

One quick option to work-around this would be to disable the secure sessions in Jira.  This can be done by creating a jira-config.properties file in the $JIRAHOME/ root directory, and then adding a line of

jira.websudo.is.disabled = true

to that file, save it, and restart Jira.  More details in Configuring secure administrator sessions.

However admittedly, that work-around doesn't really address what must be the source of the problem, it just drops the barrier of Admins to enter that system page.   If you would prefer to do some more troubleshooting here, I'd recommend taking a look at the KB Unable to login to JIRA applications.  It has some steps in the further troubleshooting section I would be interested to have you try out to see if we can learn more about this

1. Please set com.atlassian.jira.login & com.atlassian.jira.login.securityto DEBUG in Administration > System > Troubleshooting and Support > Logging and Profiling.
2. Have the user (attempt to) login.
3. Set those log levels back to the WARN so they don't spam the logs.

Perhaps then we can take a closer look at the $JIRAHOME/log/atlassian-jira.log and/or the atlassian-jira-security.log files at the time that this 2nd authentication attempt fails.  The logs should be able to give us more information about this login failure.

I'm also interested to learn more about this problem. Is it affecting all Jira admins, or just this 'john' account?  Can you let us know more about your configuration from Jira's side? Specifically, in regards to the User Directories, is Crowd in the top ordered position?  Or is the Jira internal or some other directory higher ordered here?

Andy

[Mirko Schäfer (Seibert Solutions)]

Hi @Andy Heinzer

I would like to discuss this issue even if it was created in 2019 but we have the same problem. Maybe I can support you with more information:

I am admin in Jira and the user directory is crowd. I can login as user and for a while I can also user admin functions (by entereing my PW again). This works for a while (some days, maybe 1 of 2 weeks). After a while I still can login as user (same PW) but then trying to use admin functions and entering the same PW fails.

If I then go into Crowd and reset the PW of that admin user account by entering THE SAME PW as before, I can simply click on the (still opened and with the previously enetered PW fillwd) admin PW screen in JIra and it works.

This curious behaviour still repeats for months. Some days all is working, after a while we have to reset the PW in Crowd and then it again works for a while.

In Jira the JIra Internal Directory is at first position, the Crowd Server on the second (no further user directories). This configuration is necessary as we do not want to get new customer accounts created in Crowd but only in the internal Jira directory. Making the Crowd dir only readable also is no option for us.

In the past the admin user account was also present in the Jira internal dir but has been removed. Could it be that there are still old data from that user in the database and sometimes Jira tries to check the PW against the old data instead of against the current PW in Crowd? But why only from time to time???

Really strange...

Cheers Mirko

[Mirko Schäfer (Seibert Solutions)]

Additional Info:

We also have disabled the Crowd directory and logged in in Jira with a local admin account to check if the regular admin account is still listed in the internal user dir from Jira (as it previously was). But there is nothing. We have successfully removed that user completely from the internal Jira dir.

I also checked the database. There are no old data regarding that user.

[Andy Heinzer]

Hi Mirko,

It is difficult to say for sure what is happening here.  I have a suspicion that Jira might not be able to authenticate this admin session against the crowd instance for some yet unknown reason.  But that seems like the only way I could explain the behavior described here.

I think that creating a support case would be best here.  I expect that Atlassian support will want to capture some DEBUG level logging within Jira itself on the package I mentioned above.  I don't suggest posting that information here in Community, but rather a confidential support ticket would be a better environment.

Jira does not require that the internal user directory have an administrator account, as long as another active user directory does have a system admin, you should be alright.  I personally prefer to have at least one system admin in the internal directory because if Crowd ever goes down in this setup (or is unreachable from Jira for any reason), there are no users that can make administrator changes to Jira until Crowd is brought back up.

I would be interested to try to help here further, but I still think creating a support case over in https://support.atlassian.com/contact/ would probably be the better avenue to investigate this because we can then gather logs from Jira and Crowd to better understand what is happening between the applications here.

Andy