This page describes how Crowd determines group memberships for an integrated application that is mapped to multiple directories, where duplicate user names and group names are used across those directories.

In Crowd 2.8, and later versions, there are two different schemes that Crowd can use with multiple directories. We have called these 'aggregating membership' and 'non-aggregating membership', and have described them below.

These schemes are only used to determine the group memberships that the integrated application uses for authorization purposes. Authentication is determined on the basis of the group mappings for an integrated application. See Specifying which Groups can access an Application.

When you map multiple directories to an integrated application (with duplicate user names), non-aggregating membership is applied by default. You can easily configure the application to use aggregating membership, as described below.

Non-aggregating membership

This is the 'masking' case – Crowd sees the directories mapped to an application from the top down, and will determine the effective group memberships based on the first instance of a user that is detected, working from the highest priority directory down to the lowest. Occurrences of the user in a lower priority directory are 'masked', and are not effective.

For example, Crowd will only consider Sam to be a member of the Admin group if that membership exists in the first directory in which Sam is found. If Sam is not a member of the Admin group in the first directory in which Sam is found, Crowd will not consider that membership even if Sam is a member of Admin in a lower directory . 

Note that the priority order of the mapped directories is essential to this scheme. See Specifying the Directory Order for an Application.

In the diagram of non-aggregating membership below, users or groups in a directory 'mask' themselves in lower priority directories.

For non-aggregating memberships:

A user effectively belongs to only those groups where the user is a group member in the highest directory that contains the user.

So, in the diagram:

• User A is only a member of Group A.
• User B is only a member of Group A.
• User C is only a member of Group B.

A group's members are all the 'top-most' users that belong to the group. If a group contains the user in a 'lower' directory, that membership is 'masked out' and is not effective.

So, in the diagram:

• Group A contains Users A and B.
• Group B only contains User C.

Aggregating membership

This is the 'blending' case - Crowd sees across all the directories mapped to an application, and will determine the effective group memberships based on a union of the directories. 

For example, if Sam is a member of the Admin group in any directory, Crowd will consider Sam to be a member of the Admin group.

In the diagram of aggregating membership  below, effective membership is a blend of the memberships in all mapped directories.

For aggregating memberships:

A user effectively belongs to all the groups of which the user is a member, in any directory.

So, in the diagram:

• User A is a member of Groups A and B.
• User B is a member of Groups A and B.
• User C is a member of Group B.

A group effectively contains all the users that belong to that group in any directory.

So, in the diagram:

• Group A contains Users A and B.
• Group B contains Users A, B and C.

Understand how access-based synchronization affects membership aggregation

If you're using aggregated group memberships and also sync users based on their access rights to the application, we recommend that you have a look at Syncing users based on their access rights, where we've described and explained a few cases that might appear confusing.

Configure the aggregation scheme for an application

When you map multiple directories to an integrated application in Crowd, non-aggregating membership is applied by default. 

You can change the aggregation scheme for each integrated application by checking, or clearing, the Aggregate group memberships... checkbox on the Directories tab for the application:

The aggregation scheme applies across all the directories mapped to the application.

Directory update operations

When a user is added to a group, they are only added to the first writeable directory available, in priority order. This applies for both the aggregating and non-aggregating membership schemes.

When a user is removed from a group, the behavior depends on the membership scheme:

• With non-aggregating membership, the user is only removed from the group in the first directory the user is found in. 
• With aggregating membership, the user is removed from the group in all directories the user is found in.

Inactive users

The membership schemes described above are not used when Crowd determines if a user should be able to authenticate.

Crowd only checks if the user is active in the first (highest priority) directory in which they are found when determining authentication.

For example, an application in Crowd is mapped to two directories: Crowd Internal Directory (primary) and an AD Delegated Authentication Directory (secondary).

• User A is inactive in the primary directory
• User A is active in secondary directory

Result: Crowd rejects access (authentication), because user A is first found in the primary directory, and the user is inactive there.