Nested User Groups (Groups in Groups) / Built-in Local Groups Issue

Posted on July 13, 2010. Filed under: Server Tangents |

By: Brenton Blawat

“Broken By Design”

UPDATED! After hours of conference calls with Microsoft, and multiple tiers of support, we come to the conclusion that Nested Local Groups in Built-in Groups are “broken by design”. What does this really mean? When you nest a Local Group into a Built-in Local Group, the effective permission set for the Users within that Local Group is reduced to Guest. This remains true unless the Users are specifically added into the Built-in Local Groups, which will result in proper permissions being passed to the Users.


Nesting Issue Explained


Lets take the above graphic, where we created a new local group called ‘Geeks’ which contains users named “Brenton B” and “Jason P”. From there, we added the ‘Geeks’ local to the Built-in ‘Administrators’ local group. From that hierarchy, we should assume any users in the ‘Geeks’ Local Group, should obtain Administrative privileges by traversing through the security pathway. Unfortunately, this is not the case.

Note: This issue is for all of the Built-in Groups on the system including, but not limited to, Administrators, Backup Operators, Power Users, and Users. I used the Administrators Group, as it’s easiest to work with.



The issue has to do with second level security traversing with Built-in Groups. While the first level traversing is a trusted security relationship in the operating system, the second security relationship is not trusted. This means that the ’Geeks’ Local Group object is effectively a member of the ‘Administrators’ Group and it also means that Brenton B. and Jason P. are members of the ‘Geeks’ Local Group. It will not, however, traverse to the second level and grant Brenton B. and Jason P. group membership to Administrators.


What About Restricted Groups in Group Policies?









This issue unfortunately is also present when you have Restricted Groups. Restricted Groups within Group Policies force group associations to the local groups in the Operating System. While you mandate the ‘TestAdmin’ Group as part of the Built-in Administrators Local Group, the permission lookup occurs on the Windows Operating System; thus the Nested Groups do not traverse.

Can You Still Add Groups To Built-in Groups?


Yes, as shown above! While the GUI of Windows does not provide a method to directly add Groups within Built-in Groups, you can execute two commands that would provide for adding Groups in Groups.

Method 1 – Powershell

   1: # Obtain the Current Computer Name

   2: $cmpName = [System.Net.DNS]::GetHostName()


   4: # Make the ADSI Call into the Computer

   5: $adsiCall = [ADSI] ("WinNT://$cmpName,computer")


   7: # Create the worker variable

   8: $objworker = $adsiCall.Create("group","Geeks")

   9: $objworker.put("description","Geeks Local Group")


  11: # Create Object from worker variable

  12: $objworker.setinfo()


  14: # Create the Group Association

  15: $adsistring = "$cmpName/Administrators,group"


  17: # Create the worker variable

  18: $group = [adsi] ("WinNT://$adsistring")


  20: # Add the group

  21: $group.add("WinNT://$cmpName/Geeks")

Method 2 – NET Commands in BAT File

   1: net localgroup "Geeks" /Add

   2: net localgroup "Administrators" "Geeks" /Add

* The above Methods add the ‘Geeks’ local Group, then add the ‘Geeks’ Local Group to the ‘Administrators’ Group


Resolution to the Issue

The following can be performed to resolve the issue:

#1 Add the Users of the Geeks Group directly to the Built-in Administrators Group.

#2 Create a Domain Global Group named ‘Geeks’ and place the Domain Global Group ‘Geeks’ in the Local Administrators Restricted Group.

Supporting documents: According to Microsoft’s knowledge Base articles … “This is the expected behavior of the Computer Management snap-in.”

and … where we can quote directly “This behavior is by design. Windows does not support the nesting of local groups on domain clients or on workgroup clients.”


UPDATED! Let me explain this one a bit more – I received an email From Microsoft that explained the nesting functionality as follows:

“The process of determining the security-groups a user belongs to is called group expansion, which is an integral part of user authentication. It is necessary that the group expansion accurately generates a list containing the groups that the user is a member of (directly or indirectly) in order to allow the user accesses to various resources. It is by design that group membership does not expand nested local groups.

Microsoft’s intention was to disallow nesting groups in group authoring experience (as in the case of the UI) to accurately reflect group expansion constraints. As your examples point out, there are several ways of nesting local groups, contrary to our intention. Our suggestion is to never nest local groups even when it is allowed by a group authoring tool like “net local group” because such nesting doesn’t reflect the group expansion constraints and the end results would be different from the expected results.”

What Microsoft is saying in a formal way – Their design for group expansion model does not include the ability to look through multiple levels of local Nested Groups. It only provides the ability to look one level deep due to the way it was developed by Microsoft. By not knowing how large of an impact it would be to add the ability to nest local groups, I can only assume that Microsoft does not think it is advantageous to add this functionality due to the number of users that will be using the system in this way – which makes sense.

We were able to get the Local Groups to Accept “Global” and “Domain Local”* active directory groups. While this doesn’t help a stand alone system for nesting of groups, it does provide a work around for authentication. This means that if you were to make the ‘Geeks’ Group, from the first example above, a Active Directory Group, the local system will pass the authentication query to Active Directory which then has the mechanisms to traverse through nested groups.

** Be cautious when adding Domain Local Groups to the system as if you have any forests, or trusts, the security will not traverse through the forest or any trusts. **

A special thanks to Jim Tan, Richard Leung, and Sunil Naik from Microsoft with their help on my issue!

Make a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

2 Responses to “Nested User Groups (Groups in Groups) / Built-in Local Groups Issue”

RSS Feed for Business and Information Technology Tangents Comments RSS Feed

Thanks, good post.
I was just locking down the built in group via the GPO and wanted an “escape” mechanism via a local group. No-go…


You can still provide an escape mechanism…. just add a domain group as part of your restricted group… The security will traverse two levels –> #1 to the Group –> #2 to the Active Directory Group … which will send the request to Active Directory… Or you can just create and use an escape user.

Good luck and Happy Programming!


Where's The Comment Form?


    Business and Information Technology Tangents is dedicated to providing quality content while informing the world about technology.


    Subscribe Via RSS

    • Subscribe with Bloglines
    • Add your feed to Newsburst from CNET
    • Subscribe in Google Reader
    • Add to My Yahoo!
    • Subscribe in NewsGator Online
    • The latest comments to all posts in RSS


Liked it here?
Why not try sites on the blogroll...

%d bloggers like this: