Managing Multiple Directories

This page describes what happens when you have defined more than one user directory in Confluence. For example, you may have an internal directory and you may also connect to an LDAP directory server and/or other types of user directories. When you connect to a new directory server, you also need to define the directory order.

Avoid duplicate usernames across directories. If you are connecting to more than one user directory, we recommend that you ensure the usernames are unique to one directory. For example, we do not recommend that you have a user jsmith in both 'Directory1' and 'Directory2'. The reason is the potential for confusion, especially if you swap the order of the directories. Changing the directory order can change the user that a given username refers to.

tip/resting Created with Sketch.

Managing 500+ users across Atlassian products?
Find out how easy, scalable and effective it can be with Crowd!
See centralized user management.

On this page:

Overview

Here is a summary of how the directory order affects the processing:

  • The order of the directories is the order in which they will be searched for users and groups.
  • Changes to users and groups will be made only in the first directory where the application has permission to make changes.

Configuring the Directory Order

You can change the order of your directories as defined to Confluence. Select 'User Directories' from the Confluence Administration Console and click the blue up- and down-arrows next to each directory.

Notes:

  • Please read the rest of this page to understand what effect the directory order will have on authentication (login) and permissions in Confluence, and what happens when you update users and groups in Confluence.
  • Before you move an external directory above Confluence's internal directory, make sure you (and your admin users) are members of a group called confluence-administrators in your external directory or you may accidentally lock yourself out of the Confluence admin console. 

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). 

Here's an example scenario...

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:

Turning on non-aggregating membership...

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.

Last modified on Jan 18, 2019

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.