Docker Community Forums

Share and learn in the Docker community.

LDAP: Nested Group Support


(Michael Wilde) #1

Currently it appears UCP does not interrogate an LDAP all the way down through nested groups.

Story: As a UCP / DTR admin, I need to create a team that maps to an MSAD / LDAP group “all_demo_users”. In AD, the “CN=all_demo_users…” group has two members: CN=all_employee_users and CN=all_certified_partners.

When DTR / UCP reads the members of a group, it does not appear to traverse through nested groups.

(Ldano) #2

I too am having this issue. I can’t even get it to work with just the first group layer. In your case, all_demo_users.

(Michael Wilde) #3

try putting one user in the top layer next to the groups and see UCP/DTR picks up that one user. it should.

(Ldano) #4

For our AD infrastructure as well as most companies. We have separate groups with users inside each group, this way we can use groups for specific access. I’ve tried all sorts of ways trying to get the Teams to use our ldap groups.

(Michael Wilde) #5

Right… i was just helping you diagnose the top use case to show that Docker sees only users, and not groups within a group. Vivek needs to make this a priority for enterprises…

(Ldano) #6

Hi Michael,

Yes, I’ve already connected DC to Ldap and that works fine to populate all our domain users. It’s just this Team creation feature using ldap groups.

Thanks for all your replies.


(Josh Hawn) #7


I am the dev that implemented Docker UCP’s LDAP integration features. I was hoping I could help you with this issue on syncing members of nested groups in Microsoft Active Directory. This forum post is also the top search result on Google for the query Docker LDAP nested groups, and I want to make sure it offers a solution. We currently have documentation on this subject but it is lacking specifics on how to sync members from recursive groups:

At a high level, what you need to know is that we let you sync teams in one of two ways:

  • By Matching Users with Direct Group Membership
  • By Matching Users with a Search Filter

My guess is that you have been trying to configure a team with the “Match Group Members” option, which only finds direct group members - it does not search recursively. This is done as a performance optimization. Our LDAP sync job only does a single lookup of the group in question, gets all of the member attribute values, and intersects those with the DNs of already-imported users. It does not recursively lookup those DNs - if it turns out that they are not groups themselves then it would be wasteful, and could also greatly increase the number of requests made to your LDAP server during sync jobs.

In order to match members of arbitrarily-nested groups, Microsoft Active Directory has a search filter specifically for doing this named LDAP_MATCHING_RULE_IN_CHAIN and is described here (just below the linked section):

For matching members of your group and those of any nested groups a search filter like this example lets the Active Directory server do all of the heavy lifting for you:


To configure your team sync this way, you need to select the “Match Search Results” option and provide a search filter like this along with the search base DN and scope for the users that it would match.

As described in the above-linked MSDN article, the memberOf:1.2.840.113556.1.4.1941: attribute filter is a special LDAP_MATCHING_RULE_IN_CHAIN matching rule. It will match any object which has a memberOf attribute equal to the given DN value, or which has a memberOf attribute whose value is the DN of another object which has a memberOf attribute equal to the given DN value, and so on in a chain … this is how it can be used to sync members of nested groups. I assume that Active Directory has an index on the member/memberOf attributes which make this method very efficient. The unfortunate part of this is that it appears to be a feature of Microsoft Active Directory only and I don’t believe there is a way to do it with other LDAP servers (like OpenLDAP).

Let me know if you have any more questions on this subject - or suggestions on how we can improve the product to make it more clear how to match members of nested groups. We will already be working on improving our documentation on this subject soon.