Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,299,254
Community Members
 
Community Events
165
Community Groups

Migrate users from internal directory to corporate LDAP

We recently had the opportunity to connect our Crowd server to our corporate LDAP directory, and thus eliminate the need to maintain separate usernames/passwords for our users. We set up Crowd with a secondary Delegated Authentication directory pointing to the corporate LDAP (eDirectory), with the idea that we'd continue to manage user groups and so forth in Crowd.

Pretty quickly this caused a problem because as people started to log in to connected applications, Crowd would authenticate them against LDAP and create a new user in Crowd's version of the LDAP directory. Hence users ended up with two separate Crowd accounts - their previous version in Crowd's internal directory, and a second version in Crowd's representation of the LDAP directory. After a bit this caused us to exceed our licensed user limit and broke Crowd.

This raises a host of important questions:

- How does Crowd resolve users logging in to connected applications that have the same username/password in Crowd's internal directory and an LDAP directory? It appears that Crowd is correctly authenticating people against LDAP, but people seem to be getting their group membership from the internal Crowd directory - so it seems like Crowd sort of thinks of these people as one user with two representations, in which case why are they counted as two licensed users each? This seems like double counting.

- It seems like one solution would be to replicate the user setup we have in our internal directory into the LDAP directory. Unfortunately we have about 30 groups that we use to control access to JIRA, Confluence, etc, and the prospect of replicating all those groups into the LDAP directory and re-creating all the membership is a little daunting. I don't see a way to move a user from one directory to another, to move groups from one directory to another, or to add a user in one directory to a group in another directory. So the question is, is there any way to move or copy the set of groups and/or group memberships that we have in the internal directory into the LDAP directory? SQL query, perhaps?

- The permissions model and how groups are handled is terribly unclear in this scenario. If I look at the permissions for the LDAP directory, I see options like: Add Group: Allow groups to be added to the directory. But since this is set up as a Delegated Authentication directory, I can't imagine that if I add a group to the directory I'd actually be adding it to the LDAP directory. This would be explicitly counter to the statement on:

http://confluence.atlassian.com/display/CROWD/Configuring+a+Delegated+Authentication+Directory

that says: you can set up a simple group configuration *in Crowd* for use with Confluence and other Atlassian products, while authenticating your users against the corporate LDAP directory. This implies that, at least for Delegated Auth, groups I set up in Crowd are actually stored in Crowd, even if they are part of that directory. So what I imagine is happening is that Crowd is creating a group overlay that it stores internally for this remote LDAP directory. If this is correct, this is entirely non-obvious based on the documentation and the permission descriptions.

- Overall I think the documentation for Delegate Auth (cited above) needs to be greatly improved, and the impact of selecting that option on how groups are handled needs to be explained MUCH more clearly. The person that set this up originally disable all the Add/Modify/Remove Group permissions for the LDAP directory, because he didn't want us to actually write to the LDAP directory, and it's not at all clear if that's actually what would happen.

- Do you have any other recommendations on how to achieve this migration, ideally that won't blow my license limit out of the water?

2 answers

1 accepted

4 votes
Answer accepted

In case anyone's interested, I used a SQL script ( (migrate-user.txt) ) to migrate my users. First I cloned all the existing groups from the internal directory (dumped out the table to a text file, then modified the directory_id, id, and is_local), then I just run the attached. The two directory_ids are hard-coded but could easily be parametrized or looked up.

Comments/criticism welcome ;-)

Thanks for your script, we're planning on doing the same as you. Once you've run this, everything that was created by John Smith (internal) suddenly appeared as John Smith (LDAP), correct?

It's been a long, long time but that's my recollection, yes.

This is a tricky service effort, and we have done this for a few clients.

AppFusions can get you through this, but not as simple as an Answers.atlassian.com answer b/c of environment scenarios to consider - and us suggesting a quick solution would be too risky given the large impact.

Contact us at info at appfusions dot com if you would like our assist to make this happen!

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Confluence

An update on Confluence Cloud customer feedback – June 2022

Hi everyone, We’re always looking at how to improve Confluence and customer feedback plays an important role in making sure we're investing in the areas that will bring the most value to the most c...

264 views 2 5
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you