How to limit AD-synchronization to AD-Groups

[Martin Krimpelbein]

Hi there,

I'm a newbee in the Atlassian world - using Confluence and Jira Software/Servicedesk on our own infrastructure/network on a server.

I could manage to connect Confluence and Jira to our Active Directory. Works like a charme.

But I need to limit the synchronization to only one specifiy active directory group - our complete AD got about 200.000 users and the sync needs at last 60-90 seconds.

But i could't find any (for me) suitable "admin manual".

Can anybody help me and tell me what I need to set in the AD-configuration that the sync only work with a specific global group?

Thanks in advance. Have a nice day.

[Andrew Laden]

They don't describe it well for someone who isnt well versed in LDAP.

Remember that you are looking at a hierarchical directory. ie, a tree structure.

BaseDN is the topmost point in the tree that you will be looking for anything.

Additional User DN is a way to pick a lower point in the tree to start looking for users. ie, if the users you care about are all in a specific OU, you can tell LDAP to just look in that OU. It is preponderated to the Base DN. (ie if your baseDN is "DC=Company,DC=com" and your Additonal User DN is "OU=users" then it will only look for users in the full DN "OU=users,DC=company,DC=com" Users outside of that OU will not be seen.

Additional Group DN is the same but for GROUPS. It has nothing to do with looking up users. If you Additional Group DN is "OU=groups" then it will only look for groups in the DN "OU=groups,DC=Company,DC=com" It doesnt limit in any way what users a imported.

So to limit your users, you can do a few things.

1: If possible. put them all in the same OU, then you can use the Additional User OU setting to limit your import to those users.

2:  Under "User Schema Settings" there is an option "User Object Filter". This allows you to filter what users are imported. But it has to be a valid LDAP filter.

 https://ldap.com/ldap-filters/

https://confluence.atlassian.com/kb/how-to-write-ldap-search-filters-792496933.html (has good examples for AD)

Here is where it gets tricky, Some LDAP servers support the "memberOf" attribute. If yours does, you should be able to write 

(&(objectCategory=Person)(sAMAccountName=*)(memberOf=cn=CaptainPlanet,ou=users,dc=company,dc=com))

But there are lots of caveats. (doesnt work with nested groups, for example)

You are best off using ldapsearch to help build your filter to make sure it catches what you want, and then putting that filter in the User Object Filter.

[Martin Krimpelbein]

Hey - thanks for your help. I think I got it now :)

I have to choose Option 2 due to massive restrictions of our company AD. 

First I have to check, if my group isn't a nested group - hopefully not. 

If it's not - and our LDAP support the "memberof" attributes, I got a chance that you already provide the valid string :) 

Due to the limitation of Windows based PCs I need to use the powershell ad-cmdlets. 

I'll try on Thursday and give a feedback. 

Thanks again! 

[Andrew Laden]

Take a look at the atlassian link, they talk about Nested groups with AD

And this will search for users that are a member of this group, either directly or via nesting:

(&(objectCategory=Person)(sAMAccountName=*)(memberOf:1.2.840.113556.1.4.1941:=cn=CaptainPlanet,ou=users,dc=company,dc=com))

Important for Active Directory to have memberOf:1.2.840.113556.1.4.1941 if you want to find nested groups (do not replace the numeric string) inside CaptainPlanet group.

[JP _AC Bielefeld Leader_]

Hi,

you can try out the Softterra LDAP Browser to play around with LDAP filters.

@Andrew Laden is right: The Additional User/Group DN just set the start search branches in the LDAP tree to search for users / groups.

The way to go is to use the User Object Filter. One hint: Make sure that an email attribute is set on an LDAP user object & don't let user object in your Jira without an email attribute.

We use:

(&(sAMAccountType=805306368)(mail=*)(!(|(cn=ws*)(cn=ts*))))

The filter on users having a cn starting with ws (webservice) and ts (technical service) is specific to our AD. The sAMAccountType accelerates search for users. 

Be careful with nested groups.

Best

JP

[Vickey Palzor Lepcha]

User or Group Filters on the AD Configuration Page.

If you can add all JIRA Users to one group in AD.

Using that Group as the basis - filter all other users except users in that group in AD.

[Martin Krimpelbein]

Sorry, but I need to describe it step by step, because I'm not an AD-specialist. I was lucky that I found the Base DN Settings in another document for a complete diffrent topic, so I just copied and pasted it.

Otherwise I'would never be able to pass that configuration :)

But now it seems, that I need to make special commands :(

So here's what I understand:

I need to go to the AD Configuration page.

Than going to the entrie "Additional Group DN"

and now? What do I need to write in there?

Just the group I want the synchronization to work with - or do I need some of that (for me) cryptic things like OU=, DC= blablabla.

Info: The AD itself or any content can not be edited due to restrictions. It's just possible to use it for authentification - nothing more.

[Vickey Palzor Lepcha]

You need to find a commonality between all the users that you would want to sync from your AD.

All your JIRA Users in the AD, if they fall under one common group then you can use the DN which is common between all users .

You will have to get a help from some AD Admin who administers your organization AD and who can give you the requisite DN format 

Like in some firms I know, all users are a member of one common group in AD - so that is the common point from where you can start.

[Martin Krimpelbein]

Mhhh seems that I dont understand it right.

I thought the Base DN that I set up ist the commonality between all users - complete AD with 200.000 people.

And to minimize this full sync I have to add a parameter in the field "Additional Group DN"

But your last post confused me because it sounds for me that i have to set the Base DN including the parameter for the specific AD-group.

Sorry, but english is not my native language - maybe theres a translation error in my brain :)

[Mark Mulik]

Hi, @Martin Krimpelbein

I have the same question. Did you come up with a graceful solution? 

Our AD sync appears to be limited to active AD users, but we are only assigning Jira or Confluence seats to a small subset of those users right now, and have specific AD security groups linked to Jira or Confluence groups.. It would be useful to have the AD sync happening but exclude the many thousand users who are not attached to one of the Atlassian-specific AD security groups, so that those many thousand users do not show up when mentioning users or assigning issues to users. Here we also have a lot of service accounts and secondary AD accounts for admin users. Right now, our biggest concern is that we would assign an issue to the "wrong" user, because there are just too many to choose from. 

Any ideas on this would be appreciated. 

Thanks. 

[Martin Krimpelbein]

@Mark Mulik 

Sadly - I ended up and setting up a specific group in our active directory and syncing only this group to Jira.

So every new user (or customer) need to order the group membership first.

I know that this isn't a good solution - but I couldn't find any better solution if you are working for a multi national company with 200.000+ employees.

[Mark Mulik]

Thanks, @Martin Krimpelbein . Not what I was hoping to hear, but I appreciate your response.

We manage Jira and Confluence permissions via membership in several different AD security groups, which match up with appropriate Atlassian groups. In this way, we are managing the user permissions from within AD and not having to make changes in Jira and Confluence as users come and go. We are already used to having an AD administrator have to manually add users to the appropriate security groups. Do you use the same approach? I'm wondering at the prospect of having an "Atlassian" OU, then associating all of those security groups with that OU, then syncing only that new OU. That would seemingly do the same thing I'm trying to achieve. 

Thanks.

[Martin Krimpelbein]

Yes - I think we doing it the same way - but a little bit simpler because I just got ONE group for jira and confluence user.

So if a user request the group membership via the AD-group (and is granted) the user is only capable to add issues via Jira SD.

Everything else (licence for service desk / software or confluence) has to be done manually by me. :)

That's the price of the not "user friendly" licence topic by Atlassian. Due to the extrem steps (100-250-500) I need to revise my licences very accurate.

Only focusing to never get over 250 licences ... because worst case - i need to pay 500 licences for only 251 users...

And NO - the cloud with the "per user" mode is not a solution. At least not if you're interested in data security. Only stupid people will host their personal data (customers e.g) in a cloud that is always full accessible by the US law enforcements...

[Mark Mulik]

Hi, @Martin Krimpelbein 

A consultant working for us came up with a solution that relies on Group Object Filter settings, which can be found under Admin>User management>User Directories>Configure LDAP User Directory. 

Basically, he made it so the AD sync takes place against the whole of our AD, but then filters out users who are not members of specific AD security groups, so that we don't see those users when we assign issues in Jira or Mention users in Jira or Confluence. It's exactly what we were looking for.

We already use the AD security groups to provide different access permissions within Jira and Confluence. Active AD users who aren't a member of such a security group do not have access to the Atlassian tools, but until the Group Object Filter changes were applied, those non-Atlassian users showed up in Jira when going to assign an issue and in Jira and Confluence when Mentioning a user. Effectively, they cluttered up the systems. 

Very happy with the solution. If interested in the solution, please advise. 

[Dan Tombs]

Hi @Mark Mulik

i'd love to hear what the consultant actually did in terms of settings changed etc.

Dan