I have installed Jira 8.13 on a new server. I updated the database from our old server so all internal users are there. We did not have ldap in the old server but have configured it on the new one. I've seen lots of documentation on how to make the existing internal users ldap but not sure which route to take.
If I change the order under User Directories to make Active Directory Server the first, then I'm assuming when an existing internal user connects it will take their ldap logon and not prompt them for credentials. When this happens do all their connections to Projects/Issues etc. come over to that ldap acct?
Please take a look at our UserManagement for Jira – this will allow you to move users around between internal and delegated LDAP directories in bulk.
I usually recommend migrating users to a delegated LDAP directory first, testing everything out, then (if desired) creating a full-sync one (which often comes with a filter based on the LDAP/AD groups e.g. "only members of JIRA_Users") and by placing it above the delegated one – overriding the users in the delegated one. You can then find what users are in the delegated one and not in the sync'ed one (i.e. were already in Jira, but didn't come through the LDAP filter) and decide what to do with them – keep them in a delegated one or fix the group membership on the LDAP side.
The ideal configuration (this is an opinion!) is to have the internal director on top, but only containing the "local" users, LDAP synced one below, and LDAP delegated one below that (for all "leftovers").
Further, if you have a lot of historic users who are by now inactive (as in "do not login anymore") – you can move them to yet another delegated directory, and deactivate them.
All of this can be done on evaluation license free of charge.
Oh, and we are a Single Sign-On vendor too – we can make your "not prompted for credentials" a reality with our EasySSO for Jira, with NTLM or Kerberos authentication against Windows domain.
Please feel free to reach out to our 24x7 support if you have any questions – either via Service Desk portal or the chat widget on our website.
I ended up making sure all Internal accounts matched AD usernames, then built a new directory and elevated it to the top. Then when users logged on all their issues etc. came over to them. thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Teresa,
that sounds not too bad!
As for the question of the order:
it really depends if a user is present with same usernames in both directories (internal and LDAP/AD as you mentioned). If so, the upper one takes precedence.
As per documentation:
When a user attempts to log in, the application will search the directories in the order specified, and will use the credentials (password) of the first occurrence of the user to validate the login attempt.
Source: https://confluence.atlassian.com/adminjiraserver/managing-multiple-directories-938847057.html
This does not necessarily mean there is no prompt for credentials at all.
There are cases it could be the case but generally this could mean you need to introduce a single-sign-on solution additionally (SSO).
Without it there is still the option to "remember my login" - so not every time the user is seeing Jira he needs to authenticate:
https://confluence.atlassian.com/adminjiraserver0711/jira-application-cookies-955168821.html
The projects and issues are not tied to the LDAP account in that means - but in case you are using different usernames on LDAP (or Active Directory) than in internal user directory there is no logic connection between those accounts. In other words: for Jira this looks like a separate person (as of: jdoe = internal directory, j.doe = Active Directory/LDAP - will not be the same).
Cheers,
Daniel
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.