LDAP Filter for Members Of a Group

Question

I'm attempting to run an LDAP filter to return all users within a group. Pretty simple, and there are hundreds of Stack Overflow questions which already provide example queries. However the one I'm using is basic, and returns nothing when run in Powershell.

What I've Tried

Get-ADUser -LDAPFilter "(&(objectclass=user)(objectcategory=person)(memberOf=CN=MyGroup,OU=Users,DC=MyDomain,DC=com))"

I've also tried "CN=Users" instead of "OU=Users

Where "MyGroup" is located in the OU:

"MyDomain" (Forest) > "Users" (OU) > "MyGroup" (CN)

Any ideas what I'm doing wrong, and why none of the 100-200 members of the "MyGroup" are being returned?

Solution

The first thing I'd do is double check that the DN of the group you're trying to match is actually correct. I'd usually do something like this:

(Get-ADGroup MyGroup).distinguishedName

# optionally, save it to a variable
$groupDN = (Get-ADGroup MyGroup).distinguishedName

Get-ADUser will limit your results to user objects on its own, so you can leave out the objectclass/objectcategory pieces of the LDAP Filter and just include the memberOf part. You can use the DN variable we set earlier like this:

Get-ADUser -LDAPFilter "(memberOf=$groupDN)"

The important thing to note about this particular query is that it will only return users who are direct members of the group. It will not return nested members. So if one of the group's members is another group, that second group's members won't show up in the results without additional effort. You can get those nested members by tweaking the filter like this:

Get-ADUser -LDAPFilter "(memberOf:1.2.840.113556.1.4.1941:=$groupDN)"

That crazy dotted number in the middle is an OID called LDAP_MATCHING_RULE_IN_CHAIN. From the docs:

The LDAP_MATCHING_RULE_IN_CHAIN is a matching rule OID that is designed to provide a method to look up the ancestry of an object. Many applications using AD and AD LDS usually work with hierarchical data, which is ordered by parent-child relationships. Previously, applications performed transitive group expansion to figure out group membership, which used too much network bandwidth; applications needed to make multiple roundtrips to figure out if an object fell "in the chain" if a link is traversed through to the end.

The other reason your query might not return results is if the user you're running the query as doesn't have read access to some/all of the users for some reason.

Comments

[Jake Y]

What an amazing reply! This helped me immensely! Following your advice, I went ahead and manually added a member to this group to see if the hundred or so existing members are in fact inherited. It turns out, when I add a member manually they do begin to output in the query. So they must be inherited like you said. This brings me to my next issue, the suggested OID function still only returns the few members and excludes inherited members. Any suggestions there? I'll read up on OID.

[Jake Y]

Upon further research on OID, it seems 1.2.840.113556.1.4.1941 should in fact be returning all users regardless of their nested membership. However for me it yields the same result as my initial post. I know it's not a permission issue, since I am querying as Domain Admin. Any ideas?

[Ryan Bolger]

Does your AD forest have more than one domain? I'm not sure exactly how the nested query works with group members who might live in another domain. The other thing I'd test if you haven't already is making sure your powershell session is running elevated.

[Ryan Bolger]

The other thing you could do is come at this from another angle (at least until you understand what's going on). Do something like Get-ADGroup MyGroup -Properties member | Select -expand member and see what shows up. It will be a list of DNs, but that should give you a better idea of what's in there.

[Jake Y]

Wow.. my PowerShell was not elevated. Yikes. I swore I created an elevated session, but I guess not. Still strange, since adding a user manually to the group (Using the Domain Admin) allowed the non-elevated powershell to see this user in subsequent queries. On a side note, do you know which AD permissions a user requires to query group membership? Is it an AD group, or do I have to change the Schema? Again, I very much appreciate your time.

[Ryan Bolger]

Querying group memberships via Get-ADUser like this would basically need read access to the various attributes and objects the query touches. So read on the group's memberOf, read on the users' various attributes you're returning, read on nested groups' memberOf, etc. And in a default installed AD domain, I believe that's allowed by default to all of Domain Users. But sometimes people end up modifying default permissions to try and lock things down, protect PII data, etc. So if the permissions are such that you need that Domain Admin group membership, elevation is necessary.