'AD Ldap query for user nested groups by sAMAccountName
I'm trying to make a query that outputs all the groups (and nested groups) that a user is part off, queried for by sAMAccountName value.
For example, the following query works and gives the expected output but uses the displayname instead.
(&(objectCategory=group)(member:1.2.840.113556.1.4.1941:=cn=Tester,ou=people,dc=Windomain,dc=local))
Simply changing "cn" to "sAMAccountName" doesn't work (I did verify that the sAMAccountName value is correct)
Is it possible to do this with LDAP queries?
Solution 1:[1]
There are a couple of options to display the complete group membership of a user, including all nested groups.
The simplest method is to query the TokenGroups attribute of the user object. This is a constructed attribute, that will return all the SIDs of the groups that will be added to the user's access token when the user authenticates. The only condition for the constructed attribute, the search scope must be Base scope for the attribute to be returned.
The LDAP_MATCHING_RULE_IN_CHAIN (1.2.840.113556.1.4.1941) matching rule is limited in its functionality, it will only return the groups that the user's DN has been added to the member attribute of the group, so some nested groups will not be included in the query.
The other option is to use a 3rd party tool to return the nested groups by transverse the groups membership to see the group membership. Such as NetTools User's membership option https://nettools.net/users-membership and the NetTools AD Properties dialog which includes the TokenGroups tab which will display the TokenGroups attribute with the SIDs resolved.
Solution 2:[2]
You can search for the user by the sAMAccountName and ask for the msds-memberOfTransitive attribute, which contains a recursive list of the distinguished names of the groups the user is a member of.
There is also the msds-tokenGroupNames attribute, which contains the distinguished names of all the groups whose SIDs appear in the tokenGroups attribute.
The difference is that tokenGroups only includes security groups, whereas memberOf includes distribution lists as well. Only security groups can be used to assign permissions.
Both are constructed attributes, so you have to specifically put it in the list of attributes to return in the search.
Solution 3:[3]
Sorry unable to add comments
Be careful of the msds-memberoftransitive attribute, it has some funky logic which doesn't follow the normal value ranging rules and can return incomplete results, see https://blog.joeware.net/2021/04/19/6068/
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | gazza |
| Solution 2 | Gabriel Luci |
| Solution 3 | gazza |