I hope I can describe this issue properly, if not, please clarify with me so we can have clear picture.
the problem here is -
take an example:
after data migration, we see in jira -
we need quan can login by its corporate password. right now, no quan can login unless we delete the internal one. we see 'twins', cannot choose the right one, either. After all quan is the same person using same address.
please advise us how properly manage this situation. I only think about the order to do 1,2 matters, but not sure.
many thanks in advance
With Jira there are a few rules that happen when dealing with multiple user directories. It might also help to take a look at the documentation on Managing multiple directories in order to better understand these.
If you have multiple user directories in Jira, and each of them contain the same user name(s), then the directory ordered at the top within Jira takes precedence. Hence if the username 'quan' exists in both directories, say with a different password for each directory, the username 'quan' will only be able to login to Jira in the top ordered directory that contains that user account.
However let's say that username 'bob' does not exist in the top ordered directory such as an LDAP directory. If 'bob' does exist in the lower ordered directory, such as the internal directory to Jira, then 'bob' can still login to Jira, but it would be with the password set in the Jira internal directory for that user.
If adding the LDAP account did not bring in the email address, then there is likely something wrong with the attribute in the directory configuration that should be bringing that value into Jira. I would recommend reviewing the Connecting To an LDAP directory doc, specifically the User Schema Settings. Depending on the different kinds of LDAP directories, the attribute used to find the email addresses could be different than what Jira is currently set to look for.
Jira Server does not base the uniqueness of the account on the email address, but rather the username itself. Jira Cloud does this a bit differently, in Jira Cloud the uniqueness of the account is requiring the user to have a unique email address that also could be their username in Cloud.
is there meaning we must have AD one on top of internal directory in order to ensure every one using own id/pwd and later any changes onto pwd can be effective ?
your 'bob' case we cannot produce since we don't know what would be its password set in internal directory.
Another case with 'restore'
adding LDAP account before 'restore' or doesn't matter ?
'restore' did update or overwrite the user directory ?
Most instances tend to have their LDAP/AD user directory on top in Jira. Mostly because it contains the majority of their users. But you are not required to do this. It really depends on where most of your users exist right now, and what credentials you expect these users to use in order to login to Jira.
If you were not using an LDAP user directory, and you only had the Jira internal user directory, then you would have to create that user in Jira directly. When you do this, you do this as an admin, you get to specify the password for that account at that time.
If you are doing a complete system restore (with the XML backup), that process completely wipes the existing database. So it doesn't make sense to add in the LDAP directory to Jira before this restore, since all those users and the settings would be removed by the restore process itself.
by the way, I want to mention we run into problems twice when we restore zip onto a fresh jira where no ldap configured, but the zip file containing ldap information. I raised a ticket in support site.
in the past, we always have a site with ldap configured , sync okay, then restore on top of it, but some odd stuff appear :-(
We're looking for participants for a workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sha...
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