Active Directory groups make managing access and assigning permissions in a domain much easier. One AD group can be added to another. Nested Active Directory groups are what they’re called. Nested groups are a simple approach to control access in Active Directory based on business responsibilities.
Administrators may discover that nested groups are the root of permission difficulties when diagnosing permission issues. When diagnosing denying access rules and Group Policies, difficulties with nested groups are most common.
Using the Active Directory Users and Computers console, you won’t be able to see user membership in nested AD groups (dsa.msc). We’ll show you how to find out which nested groups a user belongs to in this post.
The screenshot below shows that the user is a member of two AD groups besides the standard Domain Users: CA_IT_dept and CA_Server_Admins. You don’t see if the user is a member of any nested group.
You can use the dsget tool on the domain controller to display the full list of groups that the user is a member of, taking into account nested groups (the -expand and -memberof parameters):
dsget user "CN=Jon Brion,OU=Users,OU=California,OU=USA,DC=test,DC=com" -expand -memberof
In this example, the user is a member of 6 AD groups.
The following cmdlets do not provide information about nested groups if you use cmdlets from the AD PowerShell module to collect data about group members (https://solutionviews.com/check-active-directory-group-membership/) or users.
Get-ADUser jbrion -properties memberof | select memberof -expandproperty memberof
You can list all members of a group, even nested ones, by using the Get-ADGroupMember cmdlet with the –Recursive argument. However, the results of such a command will only contain objects that do not have any children. The returned results will not include any information about nested groups.
In PowerShell, utilise the LDAP MATCHING RULE IN CHAIN special extensible LDAP filter option to acquire information about nested user groups (1.2.840.1135220.127.116.111). This filter searches for a match throughout the full chain from the root to locate nested groups (available starting from Windows Server 2003 SP2).
Without using an LDAP filter, show all domain groups of which the user is a member:
Get-ADGroup –LDAPFilter “(member= CN=Jon Brion,OU=Users,OU=California,OU=USA,DC=test,DC=com)”|ft –a
And then use the LDAP_MATCHING_RULE_IN_CHAIN rule.
Get-ADGroup –LDAPFilter “(member:1.2.840.113518.104.22.1681:= CN=Jon Brion,OU=Users,OU=California,OU=USA,DC=test,DC=com)”|ft –a
As you can see, the second command displayed all of the user’s groups in the domain, including the nested ones.
You may also see if the user belongs to a specific security group. The first command will only display the group’s direct members:
Get-ADUser –LDAPFilter “(memberOf=CN=CA_Users,OU=Groups,OU=California,OU=USA,DC=test,DC=com)”|ft -a
Nobody has been added to the group directly. Now let’s use a nested group to display the members of this group:
Get-ADUser –LDAPFilter "(memberOf:1.2.840.113522.214.171.1241:=CN=CA_Users,OU=Groups,OU=California,OU=USA,DC=test,DC=com)"|ft –a
The following are some guidelines from Microsoft for using nested groups to make AD management easier:
- Using more than one level of group nesting is not advised.
- Only one parent group can be a member of a security group.
- If denying permissions is implemented via layered groups, don’t utilise them.
- Top-level privileges must not be granted to the nested global security group.