Crowd directory in Jira lists "jira" groups. Where do they come from if the only group in Crowd is crowd-administrators?

[Dina Goncharenko]

Hi All,

This is what I have:

Crowd which is using LDAP for authentication. It has Jira setup as an application.

Jira application which has two directories: an internal one and an Atlassian Crowd. Atlassian Crowd directory is linked to Crowd.

Now this is where I get confused:

In Jira I click on User Directories and see that JIRA Internal Directory is the first one in order. 

I click on Groups, filter them by "JIRA" and see five group (jira-administrators, jira-developers, jira-servicedesk-users, jira-system-administrators, jira-users). Each group has a certain number of users in it.

Then I switch the order of directories and have Atlassian Crowd to be the first one. I click on Groups, filter them by "JIRA" and see the same five groups as in the JIRA Internal Directory. The number of users and users themselves are different though from the ones in JIRA Internal Directory. 

I am confused as the only group that is setup in Crowd is crowd-administrators. 

Can someone explain to me where does this information come from please?

Many thanks, 

Dina

[Caspar Krieger · Accepted solution]

Since you mentioned that the apparent group memberships change when you change the order of directories in JIRA, I would say this is very likely due to the membership aggregation semantics in JIRA/Crowd.

Internally, JIRA uses libraries provided by Crowd to connect to Crowd, and until Crowd 2.8, Crowd (and hence JIRA) had some inconsistencies in how it answers queries of "is user A a member of Group X?" vs "does group X have user A as a member?".

The complexity there arises from the fact that user A can be a member of group X in directory 1, but not in directory 2 (or vice versa); furthermore, user A could exist in directory 1 but not in directory 2 (or vice versa); or group X could exist in directory 1 but not in 2 (or vice versa).

So prior to Crowd 2.8, for performance reasons, Crowd would answer the questions from the second paragraph differently for the same scenarios in certain cases (i.e. "is user a member of the group" gave a different answer to "does group have this user as a member").

The exact behaviour for this has been clarified in Crowd 2.8 (as long as you don't use nested groups - it's by allowing users of Crowd to choose between 2 semantics, "aggregating" or "non-aggregating", which you can read about here. When JIRA upgraded to a version of the Crowd libraries which use Crowd 2.8, they picked one these 2 behaviours on behalf of their users, but unfortunately I cannot remember which one they picked (it was a year or two ago).

The simplest advice (from my perspective) that comes out of this is:

1. Upgrade to the latest version of Crowd if you haven't already to pick up the consistency fixes
2. Disable JIRA's internal directory so that Crowd's directory is the only one enabled in JIRA (I believe you'll need to do this while logged in as a JIRA admin user that exists only in the Crowd directory), so that Crowd has full control over membership aggregation. (If I remember correctly, this is a necessary prerequisite for Crowd SSO as well.)
3. Read the page I linked earlier and choose whether or not Crowd should aggregate memberships, then configure Crowd appropriately.

If that doesn't work or you want more information (I don't blame you - it's stupidly complicated!), please raise a support ticket with your JIRA and Crowd versions.

(source: I'm a former Crowd developer.)

[Dina Goncharenko]

Thank you, Caspar! This helps!

I do have the latest Crowd installed. I will have to migrate users prior to disabling JIRA Internal directory as Crowd is a new installation for us which will be authenticating users both from JIRA and from Confluence.

Wish me luck!

Dina