Cannot get specific user directory configuration working

[Andy Murtagh]

Hi all,

I'm running into an issue with a configuration that I want to put in place using Confluence's LDAP function. I'm relatively certain I must be missing something through sheer fundamental lack of understanding so hopefully someone can push me in the right direction.

Existing Configuration

At present I have a fully working LDAP configuration within user directories on Confluence 5.5.2. It is wide open and pulls all users and groups from our AD infrastructure using Confluence's "Read Only, with Local Groups" mode. All users can authenticate without issue, and all users are automatically added to the "confluence-users" group.

Intended Configuration

I have need of having a second group auto-populated, one I have created called "confluence-technicalstaff". This local group has permissions assigned to it. My wish is to have all users within AD that have a specific group membership added to this group as well as "confluence-users" and all staff NOT in that same specific AD group added JUST to "confluence-users" as normal.

What I have tried

To the above end, I created a second user directory profile with almost identical settings but under User Schema Settings I altered the user object filter. I used the following

(&(objectCategory=Person)(sAMAccountName=*)(memberOf:1.2.840.113556.1.4.1941:=CN=ADGroupName,DC=domain,DC=local))

The filter has been verified as working and returning the users I want via LDP.exe and is a fairly basic filter, so I didn't expect any issues. I set the default group memberships for this directory profile to add users fitting the criteria to "confluence-technicalstaff,confluence-users" to encompass both groups.

My understanding was that all I would need to do is save the above config and then shift the priority of this new directory profile higher than the existing one. Users fitting this would then authenticate against the top profile and would get those two new group memberships the first time they logged in. As I appreciate this only happens the first time they log in, I manually added the members I wanted to the new "confluence-technicalstaff" group to ensure the initial population was done.

What happened

Everything on the second directory profile saved fine, but when I shifted it above the existing working directory profile in priority everybody logged in with an AD account lost all permissions; everyone. Lowering it below the original directory profile instantly ensured that everyone got their permissions back.

I did some hunting and found this Atlassian Answers post which detailed a similar answer and the user had kindly posted a response to their own question, highlighting that duplicate group names were responsible. As the symptoms were identical I decided to work with this and see about filtering the groups too.

I first tried just putting a random base DN string into "Additional Group DN" in LDAP Schema to eliminate the ability for the second profile to pull ANY groups. This failed the checks on save so I reverted it.

Instead I tried using a filter within "Group Schema Settings" to allow my new profile to pull only one group. I used the following:

(&(objectCategory=Group)(CN=ADGroupName))

In the original directory profile I then used the following:

(&(objectCategory=Group)(!(CN=ADGroupName)))

I thought that this would ensure that my new profile could pull ONLY that one new AD group of note, and the existing profile would then be able to pull everything EXCEPT that one new AD group of note. The second example works fine on the existing directory profile to eliminate the new group, but the first code does not work, failing the extended checks upon saving.

Out of ideas!

I'm now just about at my wit's end. I can't think of why the above wouldn't work and must assume there's a fundamental limitation within Confluence somewhere that I don't know about. Has anyone had cause to carry out work like this before, or need to set up something similar with two different directory profiles pointing to the same directory service but with different filters for a similar purpose?

Help me Obi-Wan Atlassian Answers, you're my only hope!

[Nic Brough [Adaptavist]]

Hmm.

>when I shifted it above the existing working directory profile in priority everybody logged in with an AD account lost all permissions

I think that's the problem.  Let's say I'm nbrough, in group badger in AD1, password mushroom.  You have nbrough in AD2 as well, but no badger, and password snake.

I can log in when AD1 is top of the list with nbrough/mushroom.  I can't log in with nbrough/mushroom when you reverse them because the system finds nbrough in AD2 first, and mushroom != snake.  I can log in with nbrough/snake, but I'm also not going to belong to badger, because that's the other nbrough account.   My AD2 account is now "shielding" my AD1 account.

The same "shielding" happens with groups, and the problem you have is here.  If I log in as nbrough(AD1), I'm in group "badger (AD1)".  If I log in as nbrough(AD2), I can't be in group badger(AD1) because that's in AD1 and not AD2.  If you add it to AD2, then that will shield the badger in AD1, and I'll still not have any access because you've now shielded the badger.

The duplicates will block access to the system.  If you want to use this setup effectively, then the best you can do is add badger to AD1, and maybe weebl to AD2 as groups and give both groups access to Confluence.

[Andy Murtagh]

Hi Nic,

My apologies, you'd think with a post that long I could have been clearer but perhaps I missed this out.

There *is* only one AD environment.

What I'm trying to achieve basically is "conditional" additions to the internal directory in Confluence. More specifically; our Confluence holds two specific types of info, general and technical, and only some staff should see technical info. What I'm trying to achieve is:

Profile 1: If the logging in user exists in the "Technical Users" AD group then add him to both "Confluence Users" & "Confluence Technical Users", the latter giving access to technical info.

The default Confluence behavior from the documentation is that if a match is not made in the highest priority LDAP profile it then fails over to subsequent profiles:

Profile 2: If the logging in user exists in the base "Domain Users" AD group then add him only to "Confluence Users" group which gives access to general info but not technical.

The documentation doesn't expressly document that this is possible, nor does it document that it is not, but from what is said I had no reason to believe that it wasn't as it seems like just plain failover. Before doing this I also tried simply having the one working LDAP profile adding everyone to "Confluence Users" as normal, and then trying to put my "Technical Users" AD group as a member of "Confluence Technical Users" but Confluence doesn't seem to permit that either as I thought that would have been much simpler...

Any subsequent ideas?

[Nic Brough [Adaptavist]]

Yes, I saw that it's one AD with two "links", but the problem remains the duplicate entries

Confluence sees two directories with duplicates.  It does not "fail over", because it sees the users as different entries, even when they have the same login.

[Andy Murtagh]

Hi Nic,

I can see where that might cause an issue. I attempted to make them completely exclusive by ensuring that there's no overlap but that's where my knowledge of BaseDN formattng failed me as I'm no LDAP whiz. I would have thought that if one profile was looking for only users that WERE in a given group and the other was looking for only users that WEREN'T then there could inherently be no overlap.

When I searched on the forums the only similar post was resolved by someone with more knowledge of LDAP string formatting than I and was attributed to the fact that the LDAP profiles within Confluence use a separate BaseDN string for users and groups, so whilst there was no overlap in users there was an overlap in group names. I tried to do something similar with groups and have one profile pulling ONLY the group I wanted to query and the other profile pulling all groups EXCEPT the one in the first profile but I clearly got something wrong somewhere.

Do you have any suggestions? Or is there any simpler way to do it such as being able to use AD groups within confluence groups to do permissions that way?

[Nic Brough [Adaptavist]]

I'm sorry, I'm a bit lost now.

Are you trying to work with duplicated users/groups or not?

[Andy Murtagh]

Hi Nic,

Apologies, I couldn't reply more promptly due to the response timers for new accounts.

I've tried to eliminate duplication but clearly I've not been successful. In essence all I'm trying to achieve is to ensure that EVERYONE that logs in goes into confluence-users (which already works) and that everyone who's a member of another certain AD group also goes into confluence-technicalusers, which is the bit that I can't seem to get working at present.

If there's any other way to achieve the same thing I'm more than happy to go that route but I can't seem to find one.

[Nic Brough [Adaptavist]]

Ok, how are you trying to get the second AD group to be auto-filled?  What makes you think you can do that?

[Andy Murtagh]

Initially I thought it would be as easy as just making "AD Technical Users" a member of "confluence-technicalusers" but I can't make AD groups members of internal groups.

I then thought I would set up two LDAP profiles as the documentation illustrated that:

1. I could use an LDAP profile to add a user to multiple confluence groups simultaneously
2. I could use two LDAP profiles, and if users were not found in the first profile it would check the second for them

This led me to surmise that I could likely have profile 1 pulling just members that were in the AD group and adding them to both confluence groups, and then profile 2 pulling remaining members that were not in the AD group and adding them just to the confluence-users group.

The entire premise was me thinking of a way of managing access and reading something into what was in the documentation that wasn't expressly listed as impossible. It seems at its' heart to be something so fundamentally easy though, so I can't see how it shouldn't be possible somehow.

[Nic Brough [Adaptavist]]

1 will work if the groups and users are in the same directory

2 will work, but not for duplicates, and you can't put the users into groups in the other directory

[Andy Murtagh]

Aye 1 in-and-of itself isn't sufficient, I have that working but I can't just add all users to both groups as that doesn't differentiate between the two security levels. I tried to eliminate the duplicates from 2 but don't seem to be succeeding; that was the context of my original query.