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.
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.
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
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.
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:
In the original directory profile I then used the following:
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!
>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.
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?
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.
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?
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.
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:
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.
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.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Atlassian market place contains number of Apps/Addons which improves the capability of out of the box Atlassian products. It is good to follow a plugin evaluation process before install add-ons. So t...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs