We have JIRA 5.1.3 and use internal directory for authentication, user and group management. We want to move to LDAP for authentication and user/group management. We are also going to implement confluence in the next month so I want to get the authentication groups and LDAP sorted before that happens.
Can you give me advice on what the best methods for ldap authentication and user and group management? I was thinking of having LDAP for authentication and user/group management. We are moving to have LDAP as our single user authentication database. However for group management I am not sure if LDAP will work. The main issue I see is that for our projects in JIRA we have a mail group list name as the project lead. This is so any issues created for that specific project will have email notifications sent to a group of people. I don't see how I could manage those mail group names which are also users in JIRA. As it is also specific for JIRA I don't see how they would be of any use in Confluence.
I did some playing in our test JIRA and I could not work out how to simply change the group names. This would be easiest. Would I need to create the new groups, add the users in and then change all the references from the old group name to the new name such as in the permission schemes, workflow post conditions, etc? I am hoping not as that would be a huge amount of work which I would not know where to begin.
Is it better to manage confluence and jira authentication differently? We want to integrate them as much as we can.
Appreciate any advice
Good luck for pushing the changes live and thanks for the info. I am stilll unclear about the password migration. You have mentioned that we manually entered all the jira-users to AD, did that include the password too? From my initial review Atlassian used SHA512 before they introduced Crowd structure to all its products. This change forced the new Hashing Algorithm which Atlassian calls "ATLASSIAN SECURITY" which as per my knowledge no LDAP including AD supports. Having the Password intact is very critical for a smooth trasition.
The migration went over without any problems. Users simply logged in with their AD password. 8 of them had different user id's in jira to AD. I simply bulk edited those issues and changed the assignee and reporter field to the updated AD User ID. We changed from internal directory to Active Directory. We did not use crowd. I did not have to do anything with password migration. I'd recommend you test thoroughly in a test environment first. I did it twice to make sure all went OK.
All the best and hope your migration goes well.
You can have LDAP for authentications and manage the groups in local JIRA only, this permission won't write any changes made in JIRA to LDAP. You might be interested in https://confluence.atlassian.com/display/JIRA/Connecting+to+an+LDAP+Directory#ConnectingtoanLDAPDirectory-PermissionSettings
If you are planning to have all the current JIRA users copied into LDAP, you can consider creating a Delegated LDAP which then can have the option to move user from one directory to another. https://confluence.atlassian.com/display/JIRA/Connecting+to+an+Internal+Directory+with+LDAP+Authentication#ConnectingtoanInternalDirectorywithLDAPAuthentication-CopyingUsersonFirstLogin
When managing user groups in LDAP, you can just have the group to be included in JIRA Users permission to give the users permission to login. If you would like to continue using the group name in JIRA, you can have LDAP configure groups with the same name.
I have having problems moving from our the current internal directory in JIRA to LDAP authentication for user and group management. I was not sure on the migration process from our current set up and can find no documentation. It looks like all the documentation is for those starting from a new JIRA set up.
I can see that Atlassian recommends to have LDAP for authentication and internal directory for user and group managment.
We would prefer to have LDAP for authentication and group management. We have created the new directory to Microsoft Active Directory (Read Only). We have tested and it states it has syncronised successfully. I cannot see however that it has imported anything. I also created a new user in AD. Put into the jira-users group in AD. When I select to test that use (under Test Remote Directory Connection) and put in its user id and password it states that the user does not exist.
I am wondering if after creating the new AD directory do I need to delete the existing internal directory? Problem is I cannot find out how. I imagine there are issues having both the directories there at present? I have put the AD directory on top of the internal directory so JIRA looks for that first.
We need to implement confluence in the next week but I cannot until I can configure JIRA access, users and groups.
Andrew we are planning for a similar implementation where I need all the users in Confluence to be imported to the LDAP external directory in Crowd and not use Crowd internal directory. Did you have any success on implementing it? Also I will need the Confluence user credentials including password to be imported to LDAP as well.
With Confluence it was easy as it was a new instance. For JIRA the tests I have done so far seem to be working. I have only done them in our test environment to date. This is what I did.
I am putting the change into our live environment tomorrow night. Will let you know if I have any problems.
All the best, Andrew
I am planning to do same setup as you have described here, move Jira internal directory to LDAP authentication. With "Read-only. with local group" enabled is it mandatory to create existing local groups in LDAP? or LDAP user would get automatically assigned to existing local group?
Also would like to know how did the production migration go?
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
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