Effect of Directory Order

This section summarizes the effect the order of the directories will have on login and permissions, and on the updating of users and groups.

Login

The directory order is significant during the authentication of the user, in cases where the same user exists in multiple directories. When a user attempts to log in, the application will search the directories in the order specified, and will use the credentials (password) of the first occurrence of the user to validate the login attempt.

Permissions

Aggregating membership (default)

The directory order is not significant when granting the user permissions based on group membership as Confluence uses an aggregating membership scheme by default. If the same username exists in more than one directory, the application will aggregate (combine) group membership from all directories where the username appears.

Example:

  • You have connected two directories: The Customers directory and the Partners directory.
  • The Customers directory is first in the directory order.
  • A username jsmith exists in both the Customers directory and the Partners directory.
  • The user jsmith is a member of group G1 in the Customers directory and group G2 in the Partners directory.
  • The user jsmith will have permissions based on membership of both G1 and G2 regardless of the directory order. 

For administrators upgrading to Confluence 5.7 or later:

How group memberships are determined for users that belong to multiple user directories (such as  LDAP, Active Directory, Crowd) changed in Confluence 5.7.  Group memberships are now aggregated from all directories, not the first one the user appears in.  In most cases, this change will have no impact as users generally only exist in one directory, or their memberships are correctly synchronized between user directories. In some rare cases, where group memberships are out of synch, the change may lead to users gaining permissions to view spaces and pages (if they are a member a group in a user directory that was previously being ignored by Confluence). 

This is Issac. Something went wrong a while ago, so he's got the same username in two user directories, but belongs to different groups.


Right now, the user directories in his organization's Confluence site look like this:

and Issac's group memberships in each directory looks like this:

The 'Dev Team' page is restricted to the developers group.

  •  In Confluence 5.6 and earlier, Issac couldn't see this page as we determined his group membership from Active Directory - because it's the first directory in the list it had the highest priority. 
  • In Confluence 5.7 and beyond, Issac will see the page because we determine his group membership from all directories, not just the highest one.

To Confluence his group membership looks like this:

This means after the 5.7 upgrade he can see any pages and spaces that are restricted to the 'developers' group. 


Non-aggregating membership 

It is possible to use the REST API to tell Confluence to use a non-aggregating membership scheme as follows:

The REST resource supported JSON and XML. You'll need to be a system administrator and logged in to do this.

# To GET the current setting
curl -H 'Accept: application/json' -u <username> <base-url>/rest/crowd/latest/application

# To PUT the setting
curl -H 'Content-type: application/json' -X PUT -d '{"membershipAggregationEnabled":false}' -u <username> <base-url>/rest/crowd/latest/application

If you've chosen non-aggregating membership, the directory order is significant. If the same username exists in more than one directory, the application will look for group membership only in the first directory where the username appears, based on the directory order.

Example:

  • You have connected two directories: The Customers directory and the Partners directory.
  • The Customers directory is first in the directory order.
  • A username jsmith exists in both the Customers directory and the Partners directory.
  • The user jsmith is a member of group G1 in the Customers directory and group G2 in the Partners directory.
  • The user jsmith will have permissions based on membership of G1 only, not G2.

Updating Users and groups

If you update a user or group via the application's administration screens, the update will be made in the first directory where the application has write permissions.

Example 1:

  • You have connected two directories: The Customers directory and the Partners directory.
  • The application has permission to update both directories.
  • The Customers directory is first in the directory order.
  • A username jsmith exists in both the Customers directory and the Partners directory.
  • You update the email address of user jsmith via the application's administration screens.
  • The email address will be updated in the Customers directory only, not the Partners directory.

Example 2:

  • You have connected two directories: A read/write LDAP directory and the internal directory.
  • The LDAP directory is first in the directory order.
  • All new users will be added to the LDAP directory. It is not possible to add a new user to the internal directory.
  • No labels