Getting a User’s Group Membership the Easy Way in Active Directory

Retrieving a user’s LDAP group membership, at first glance, is straightforward.  This is a common and important thing to do in Identity Management solutions that work with your LDAP directory including Active Directory.  There are several ways to do it in one line in PowerShell:

Get-ADPrincipalGroupMembership username | select name

A search in your favorite search-engine will find countless solutions like this.  What’s wrong with this?  Why another blog post on the topic?

1.  This solution is Active Directory-centric.  It uses a command that’s specific to Active Directory and not other LDAP directories
2.  It doesn’t necessarily get you all of the user’s groups which can be dangerous.  In other words, it doesn’t do a good job at retrieving a User’s LDAP group membership completely.

Why is this Dangerous?

#1 isn’t probably a big deal for you; if you’re using these types of commands you’re probably working with Active Directory anyway.  But what’s up with #2 and why is it dangerous?  It turns out a user can be a member of a group that itself is a member of another group or groups.  For example, user “Jane” could be a member of group “Geeks”.  “Geeks” itself can be a  member of “Domain Admins”.  By transitive application, Jane will effectively be a domain administrator in your directory environment.  If you run the above command on Jane you’ll only see that she’s a member of “Geeks”.  Identity Management solutions that use these kinds of techniques to retrieve a user’s group membership are missing the boat.  If your user Jane is a domain administrator, and you’re responsible for keeping track of such things, you’ll want to know it.

This a simple example but in complex setups where the associations between different groups aren’t so clear, it can be easy to have users with too much access because of the transitive nature of how group membership works.  Unfortunately if you’re running commands like the above or using tools such as Active Directory Users and Computers (which doesn’t traverse the group to group associations), you won’t know there’s a problem.  This is one reason why owning an effective auditing solution is important.

Simple Solutions Also Have Caveats

You can try the LDAP_MATCHING_RULE_IN_CHAIN LDAP query.  This is designed to look up the ancestry of an object in a way that will handle the above case.  The catch here is that the method is extremely slow.  (Also see this article.)  Even though it’s an LDAP query, it’s also Active Directory specific.  Users these days don’t expect queries that take minutes to complete.

Enter Recursion:  Retrieving a User’s LDAP Group Membership Completely

There are a lot of cheap/easy articles that use recursion to solve the problem.  Recursion involves using a function that calls itself to walk the chain of dependencies between groups to find a complete solution.  Unfortunately, most algorithms are inefficient because they unnecessarily traverse the same branches repeatedly.  This is a fantastic article that uses an efficient mechanism to perform recursion:  https://www.sysadmins.lv/blog-en/efficient-way-to-get-ad-user-membership-recursively-with-powershell.aspx but it again is a completely Active Directory-centric solution.

Identity Management Solutions

Identity Management solutions such as PeoplePlatform offer administrators the ability to retrieve and update full group membership information for users in a way that performs optimally.  Such solutions should offer the ability to recursively get of a user’s transitive group membership for auditing purposes.  Otherwise this can be one of the ways that big security problems can occur as you might not see a user’s full access by looking at their immediate membership.  As an administrator turning off the functionality when you don’t need it can also be important for performance.  Finally, if you’re not using Active Directory you should have a solution that works more generically with other LDAP directories.