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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.