nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Open LDAP has no synchronizing option

Bruce Boutet

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?

Thanks,

Bruce

Accepted answers

Andy Heinzer

Hi Bruce,

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.

Cheers,

Andy

All comments

Andy Heinzer

Hi Bruce,

So if the user can't login after changing their password, there might be something else happening here.

Cheers,

Andy

Bruce Boutet

Andy,

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.

Cheers,

Bruce

Phil Evans_nhgl6h

@Bruce Boutetwere you able to find out what was the problem?

So, i guess they activated my old account in AD, admin put his ASD123 password and gave it to me. I changed the password.

Now, i cant login to Jira and other instance of Jira and Confluence with new password, but previous (made by network admin) password works.