Degraded performance Customers may experience intermittent errors using Community search. Our platform vendor is investigating.
I have a user whose password has changed but it has not been picked up by JIRA. In the past I would simply synchronize the AD user directory. We have migrated from Windows A.D to Open LDAP and now I find there is no synchronize option.
How does one get a synchronize task to run?
- no entry under scheduler administration?
What am I missing?
I understand that a user is having problems logging into Jira after a password change. However something confuses me about this, because if you have that user login to Jira and their user account is in a connected LDAP directory, Jira isn't actually storing the user's password at all. Jira only stores user account passwords to the Jira database if the user account exists in the internal directory.
In both kinds of LDAP connectors for Jira (Connected and Delegated), Jira has to connect to the LDAP instance each time a user has to authenticate in order to process the request. Jira doesn't really know what the password is for the account, it's just passing it to LDAP and awaiting a reply as to whether or not authentication passed/failed.
Delegated LDAP in Jira doesn't sync on any regular schedule. The connected directory will sync on a set interval (default I think is 60 minutes), but this only syncs over username, email address, and other LDAP attributes. The Jira database doesn't actually sync or store the password for that end user account in the database. Connecting to an LDAP directory explains this a bit more.
So if the user can't login after changing their password, there might be something else happening here.
First check to make sure that this user account is in the directory you think it is, and that directory is in the top order in Jira. One way to do this is to check the User Management within jira to make sure this account is associated with that user directory and not also in the "Jira internal directory". If a username exists in more than one connected directory to Jira, only the credentials in the top ordered directory can be used for that account. So if 'bobsmith' username exists in both directories, Bob has to use the credentials for the top ordered directory. That is another way to test this, see if that user can login to Jira with their old password. If they can, then I suspect their account in Jira is not actually coming from the LDAP connector, but the internal directory.
If that isn't the case here though, the next steps are to try to follow this guide: Unable to login to JIRA applications. The Further Troubleshooting steps will have to enable debug logging on a few different packages in Jira. From there if you can have that user try to login to Jira once more, we should then be able to see in the logs why that user can't login now.
The user was formerly in our Internal User Database, but then was added to LDAP. I suspect the issue is that his entry was still in the Internal User database. Though the AD directory is the top level directory, I disabled the Internal directory and he still could not login. I have requested he try his old password, because despite the fact his user account is delegated. I too suspect it is still coming from the internal directory.
Andy, I cannot thank you enough for your help. You are the man.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Hey Atlassian Community! Today we are launching a bunch of customer stories about the amazing work teams, like Dropbox and Twilio, are doing with Jira. You can check out the stories here. The thi...
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!
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