nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

(&amp;(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:

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

In the original directory profile I then used the following:

(&amp;(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!

Accepted answers

All comments

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?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

confluence-administration

active-directory

ldap