I am attempting to create an AD/LDAP filter for confluence. We currently have our own AD services, however are about to start to have to use the primary organizations AD and we do not want to pull in all the users, 170k, and want to restrict it to just our staff. we have a group setup lets say it is as follows:
we then have 3 groups assigned to it
DN: CN=fulltime,OU=Managed Groups,OU=organization,DC=tech,DC=ad,DC=example,DC=com
DN: CN=contract,OU=Managed Groups,OU=organization,DC=tech,DC=ad,DC=example,DC=com
DN: CN=parttime,OU=Managed Groups,OU=organization,DC=tech,DC=ad,DC=example,DC=com
One of these groups are assigned to each of our staff memebers.
I have attempted to create the search filter as such:
But it is not finding my users.
Any help on this would be appreciated.
Additional information I probably should have included. I have the option to include nested groups checked.
For base DN I have used both OU=Security,OU=Groups,OU=depatment,OU=organization,DC=tech,DC=ad,DC=example,DC=com as well as path to the 170k users.
There is an option in the ldap setup for nested groups. It is under Advanced Settings. It does say that performance can be degraded and I did find that with one of our plugins the nested groups was seriously degrading performance. Once we flattened it out again everything went back to normal. The performance degradation didn't come right away. It started off working just dandy and I would love to have left it that way. It was after we had been using the system for a while and got more and more users into it that things started to slow down. So, do some testing and realize that your current testing may not stay that way going forward.
Also, you should not need the (sAMAccountName=*).
With your extra info I notice that the three groups included in the confluece-users group are not within your base DN. My hunch is that is your issue. Why not take you base DN down to OU=organization,DC=tech,DC=ad,DC=example,DC=com. Since you are also supplying is a filter you shouldn't get extra users in Confluence.
I am also facing a similar issue. I have a requirement where only members of specific groups in our ldap structure should be able to login to Confluence.
My current configuration looks like this:
Base DN: o=mycompany
User DN: ou=worker
User Object Class: person
User Object Filter: (objectclass=person)
Group DN: ou=ssogroups,ou=groups
Group Object Class: ssogroups
Group Object Filter: (|(displayname=team1)(displayname=team2)(displayname=team3))
Group Name Attribute: displayname
What I found was that with this configuration, only the groups team1-3 were synced in when a user logged in, but ANY member of the company could login as they pass the user object filter.
Can anyone provide an example of what the user object filter would look like to filter access to person who is also a member of groups with displayname team1 or team2 or team3?
In my opinion, and think this is really the easiest way to mange it, you should have a group that simply allows you to login to confluence. When you first get confluence going there is a group called confluence-users. This would be the ideal group for this. This group does nothing be give you the can use permission. Space permissions will be done with additional group.
Then your user object filter should be something like this ...
This says that you are a confluence user if your account is a person and it is not disabled and it is a member of the confluence-users group.
For the group filter we have have standardized that all our confluence groups star with confluence-. So our group filter is this ...
But you could also do something like this if you wanted to add other groups ...
Thanks for the reply Davin. My requirement is for a restricted instance of confluence that we use to host devops and infrastructure maintenance information relating our company-wide available Confluence instance. For the scenario when we have maintenance or upgrades happening on the generally available instance, we still have access to our operations and support documentation.
So the issue I am facing is that all company users can login to the restricted instance by passing the user object filter of person, since there is no group membership restriction with a logical AND operator.
In pseudo, I need the filter to restrict access to login to Confluence by a person who is a member to an authorized group.
Otherwise any user passes the user object filter of being a person and can login to the restricted instance. The group object filter only restricts the specified groups and memberships from being pulled into Confluence for use in permissions - it doesn't control access based on who is a member of the specified groups.
If the user is not in confluence in the first place then they will not be able to login. That is why I have the ...
But beyond that in the Global permissions you can set the groups that can log in ... this is the "can use" permission. Also, anyone with "can use" permissions assigned to then either directly or via a group membership will consume a license.
Your first statement is not correct. First time users can login when logging into a user directory configured to add new users on first login, and can specify to add them to the confluence-users group, as well as sync in their ldap group memberships. So long as their user authentication is accepted and they pass the object filters.
Part of my requirement is to not have to expressly add users to confluence and micro-manage global permissions or space permissions. Since this instance of confluence is for ops and support team members only, we don't have restrictions on the content in various spaces. Being a member of confluence-users gets you access to everything. When a new space is created, by default, confluence-users have "can use" permissions. This is how we want it. We don't want to have to expressly restrict to our specific ldap groups. That's a lot of additional configuration each time a space is created or modification of the space templates (which I've considered, but would rather do things this way, if possible).
We have a self-managed system for employees to join ldap groups. When we add an employee to our team, they request to join the groups our team controls. Once the group manager approves the new employee request, they are a member of said group. When the new employee logs in to the Ops Confluence for the first time, their user should pass the object filter that requires them to be a person and a member of a group with access, get created, and add them to the confluence-users group. At that point they have access to all content unless it is expressly restricted.
What happens now with the user object filter not restricting access based on the groups, is that all employees pass the filter, so they get logged in and a user is created.
I have turned off users being automatically added to the confluence-users group, so they do not have access to any content, but a user is created anyways (even though it may not consume a license).
In order to grant team members access to the content, i have to login and manually add them to the confluence-users group.
I know this seems obscure and a fringe case, but I'm surprised more people haven't run into this. Control access to Confluence based on a user and group filter combination seems like a logical thing to me, but my attempt at combining the two into one user object filter have failed.
Based on this article, it is possible to restrict based on user and group membership - https://confluence.atlassian.com/kb/how-to-write-ldap-search-filters-792496933.html
My own attempts at this haven't been successful yet - working on it and will report if I am able to configure this.
Hi team, I’m Avinoam, a product manager on Confluence Cloud, and today I’m really excited to let the Community know that all customers can now try out the new editing experience and see some of the ...
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