OK....
I know little about LDAP but I am being asked questions about using it for our JIRA installation. I have read various documentation (https://confluence.atlassian.com/display/JIRA/Connecting+to+an+Internal+Directory+with+LDAP+Authentication) and there seem to be multiple ways of implementing it. so to my questions...
1. It appears it can be used just for authentication or can be used to control group membership - is that correct?
2. If we implemenet only LDAP Authentication my assumption is that all the existing user accounts have to be linked to the LDAP account in someway to get the groups etc. But I havent seen anything about this or how to do it. Is my thinking wrong?
3. I am in a global organisation with a very large number of users is it possible to only let certain users access JIRA? i.e. we dont want to blow the licence limit because curious employees have been trying to login.
4. Obviously I do not want to bring the whole system down, so what would be the best way to trail and roll such a change out?
5. Do we loose anything by switching to LDAP?
Many thanks for four help
Nick
Hey Nick,
Regarding your questions:
1. It appears it can be used just for authentication or can be used to control group membership - is that correct?
You can implement JIRA/LDAP integration in two ways:
You can use the groups from your LDAP in both options.
2. If we implemenet only LDAP Authentication my assumption is that all the existing user accounts have to be linked to the LDAP account in someway to get the groups etc. But I havent seen anything about this or how to do it. Is my thinking wrong?
Since version 5.0.3 (JRA-24213), JIRA has a feature to migrate users between the Internal and Internal with Delegated Authentication directories.
However, after this migration, the LDAP authentication will only work if the usernames are exactly the same as the usernames in your LDAP (including case sensitive).
3. I am in a global organisation with a very large number of users is it possible to only let certain users access JIRA? i.e. we dont want to blow the licence limit because curious employees have been trying to login.
You can restric the LDAP scope as in this doc. It's for Crowd appliction, but it's pretty much the same for JIRA.
4. Obviously I do not want to bring the whole system down, so what would be the best way to trail and roll such a change out?
You may create a test instance as suggested in this doc.
5. Do we loose anything by switching to LDAP?
The tickets and other settings in JIRA rely on usernames, so if the usernamea in JIRA and LDAP match you won't loose anything.
I hope it helps.
Cheers
BOOM!!! that was my brain exploding!! Thanks for the response Tiago..
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey Nick,
When using Internal with LDAP Authentication directory, if you don't want to manage the group in your LDAP, you just need to leave the option Synchronise Group Memberships unmarked.
After the new Internal with LDAP Authentication directory is created, you can just move it to the top position. I don't usually suggest to delete the other directories, intead you can disable them if you wish. It has the same effect and delete the directory, but with the advantage of being able to enable it again if it's needed for some reason.
And yes, befone migrate the users between the directories, the first thing I advise you to do is adjust usernames in JIRA and LDAP to match.
Since JIRA version 6.x it's now possible to rename users that belong to the Internal directory (see this improvement request). However, it's only possible one user at a time and, at this stage, this is the only supported option to rename users.
Cheers
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.