Consideration to enable AD integration for Confluence

[Mark]

Our company is using Confluence 6.4.1. Only Internal directory is enabled. Recently we are planning to enable AD integration. As far as I know, internal directory can work parallel with AD. Therefore, user can be created with internal directory OR login with an AD account. Am I correct?

Our existing practice to create Confluence account is always follow the user's AD login name. (e.g. my AD login is "Domain\mark". Then my confluence login will be "mark") What will happen if we enabled AD integration and enabled "domain\mark" to sing in confluence? When I login, which account Confluence will be recognized?

Finally, anyway we can tell Confluence two logins are referring to same account? (e.g. Domain\mark = mark)

[Shannon S]

Hi Mark,

When adding Active Directory to Confluence, you may want to consider the following:

Managing Multiple Directories

In summary, whichever directory you want to use for login, you will want to make sure that it's in the first place. You can read the above article for some other considerations.

Group permissions will be aggregated, so if the username is the same then the groups listed in both Internal and AD will be combined for that user.

I think this should answer your questions. Once you have reviewed the above article, can you let us know if you have any additional questions?

Regards,

Shannon

[Mark]

After some tests, I found 1 user existing in 2 directories will be counted as 2 user license... Have I missed something?

In this way, permission aggregation is not very helpful because I have to remove all user in Internal directory. Otherwise license will be doubled..

[Igor M.]

Hello,

You are correct, you can use both directories in parallel, so you can create or login user with both.

You can read Connecting to an LDAP Directory for more details and specifications on how exactly integration is happening and what attributes are used and how.

For your final question, as long as you follow your existing practice or maintaining the same user ID, local and external directory accounts should merge. The only time they would not merge, would be if user IDs are different, as described in Merging user accounts in Confluence - Local and External Directories KB, but even then, there is a workaround.

Hope this clarifies your questions, let us know if you have any further queries.

Regards,

Igor

[Mark]

Hi Igor, thanks for your reply.

It seems we need to review all Internal directory's username before adding AD. Because we have some username (e.g. tester) have a matching name in AD but belonging to different users or purpose. Confluence will treat them as same person and the only condition is "same username".

Also, do Atlassian have some document or guideline how to remove all non-admin user from Internal directory? Our ultimate goal switch Confluence to 100% AD controlled. I think we only need to check the permission setup for each Internal user. Anything else we need to consider?

Sorry just have another question in mind, how about the user count (for license) if we are using both AD and ID? The same user will not be double counted?

[Igor M.]

Hello,

If the users are in fact merged after AD is added, they should not count towards license individually, if they are, try clearing the cache from General Configuration >> Cache management >> Flush All.

See License count is incorrect or disabled users are counted towards the license KB for more information.

In some situations, they might count individually towards license if they did more merge properly.

License count is based only on Global Permission membership. So a user will count towards license if:

• If the user belongs to a group that has global Can Use permissions to use Confluence
• If the user is individually granted global Can Use permissions to use Confluence

To have proper testing and control over whom of your AD users are counted towards the license or have access to Confluence, after adding AD you can modify global permissions to only allow a certain group/groups to have global permissions, and remove any other groups, this way only members of the group/groups in question will be counted towards license. 

This should also prevent users that did not merge properly for whatever reason, from counting towards your license. For example:

1. 10 Local users in Confluence are members of the confluence-users group that has Can Use Global Permissions.
2. AD is added to Confluence, 9 or those 10 users have the same username in AD and Local Confluence directory. All AD groups also become known to Confluence, one of those groups is a hypothetical ad-users-confluence group where all users that need access to Confluence are members off.
3. 9 of 10 users that merged have a new hybrid account that is now a member of AD ad-users-confluence as well as the Local confluence-users group.
4. You modify Global Permissions, remove confluence-users from the access list, thus removing Can Use permission, at the same time, you grant AD group ad-users-confluence global Can Use permission. 
5. You will be left with 9 users that feel no difference in modifying their content, as their accounts were merged, 1 user that can still log in to Confluence but no longer has access to his old content created under local confluence user. For that user you follow Merging user accounts in Confluence - Local and External Directories to manually merge his account.

Hope this explained a bit how merging could work. 

Kind Regards,

Igor Muzaliov

[Mark]

Hi Igor,

The approach sounds great. Just to clarify step 4 [You modify Global Permissions, remove confluence-users from the access list, thus removing Can Use permission, at the same time, you grant AD group ad-users-confluence global Can Use permission. ]

In our existing confluence, some pages have setup restriction that is not easy to identity unless you check page by page.

So, after remove confluence-users, the 9 users still remain same permission including restricted pages? They still exist in Confluence groups that previously joined?

[Igor M.]

Hey,

Sorry for late reply, slipped my eyes. 

Yes, all groups will remain the same, and confluence-users can always be added back and given Can Use permissions. Local accounts and their properties will not go away. There is a DB query way to identify which users have access to which spaces if that helps How to list which spaces a user can access.

Regards,

Igor