crowd groups and existing Jira groups - migrating to Crowd

[Tom Lister]

Hi

We are setting up and evaluating Crowd as our user management.

Is it possible to have users in Crowd but groups in Jira. The behaviour we are seeing suggests we need to move our groups to crowd.

we have two LDAP directories in Jira, both read-only, local groups.

I have added these two LDAP directories in Crowd and added Crowd to Jira. The existing LDAP is still in place. If I move the Crowd directory to the top of the list to take precedence I can see all the users as before but there are no group memberships shown or only a test group set up in crowd.

I had assumed the previous memberships would still appear associated with the user of the same original username,

So my question is, if we implement crowd , do we have to rebuild all the group memberships either in Jira or Crowd, in order to cutover to the new crowd directory. I can see how to do this with a mixture of groovy and REST calls but it's quite a commitment

Tom

[Anurag Jalan]

You see this behavior as aggregate group membership doesn’t apply in JIRA (unlike Confluence & Bitbucket). JIRA will only see groups which exist in the first directory where user is found. Nothing after that.

[Bruno Vincent]

Hello @Tom Lister 

Since you mentioned that your LDAP directories are read-only, my understanding is that you don't want to use those LDAP directories to store your Jira groups and that the LDAP directories should only be used for authentication.

Thus I suggest that you create two Delegated Authentication Directories in Crowd (one for each LDAP directory). Let's call them Delegated Authentication Directory A and Delegated Authentication Directory B.

Then use Atlassian Importer twice to import Jira's users and groups in both Crowd's delegated authentication directories.

At this point, you will need to remove the users of LDAP Directory B from Delegated Authentication Directory A, and the users of LDAP Directory A from Delegated Authentication Directory B. This can be done manually or with a script relying upon Crowd's REST API.

Then, still in Crowd, in Jira's application settings, click 'Aggregate group memberships across directories'. Thus, if you initially had a group named 'foo-group' in Jira, you will have that 'foo-group' in Crowd in two distinct directories (Delegated Authentication Directory A and Delegated Authentication Directory B) but since you configured the application for group memberships aggregation, from Jira's perspective, it will be as if there was only one 'foo-group' that contained users from both Delegated Authentication Directory A and Delegated Authentication Directory B.

Hope this helps!

[Tom Lister]

Hi @Bruno Vincent 

Thats an interesting approach - we'll discuss that next week.

We don't use LDAP groups at the moment but have considered it. It's a large org with a huge LDAP tree so we are looking at ways to fit in with the overall setup.

My understanding of delegated LDAP is that users must already exist in LDAP. Then we create the user profile in crowd, without the need for any authentication info. i.e. a two stage process. Although that will probably not be an issue as there is always some setup work for new users.

We have a 3rd user population which are users in partner companies who need Jira access to collaborate. We would use and internal Crowd directory for those users.

I'm not sure how we would clean up the users from LDAP A now in Delegated Directory B. manual is not feasible as we have 1600+ users, ~70/30 split between LDAP directories.

Tom

[Bruno Vincent]

Hi @Tom Lister 

You do not need to create the user profile in Crowd once the user exists in LDAP. 

As per Atlassian's documentation

If a user logs in successfully via LDAP authentication but does not yet exist in Crowd, Crowd will automatically add them to the Delegated Authentication directory

Regarding the users removal, yes you would obviously need some information to identify which users are from LDAP A/LDAP B (do they have a specific identifier format?). Once you have identified them, a simple DELETE using Crowd REST API will do the trick.