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

By: Brenton Blawat

“Broken By Design”

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()

   3:  

   4: # Make the ADSI Call into the Computer

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

   6:  

   7: # Create the worker variable

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

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

  10:  

  11: # Create Object from worker variable

  12: $objworker.setinfo()

  13:  

  14: # Create the Group Association

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

  16:  

  17: # Create the worker variable

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

  19:  

  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

I still firmly believe this is a bug, however, Microsoft says it’s by design – an undocumented feature so to say. 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

http://technet.microsoft.com/en-us/library/ee681621(WS.10).aspx … “This is the expected behavior of the Computer Management snap-in.”

and

http://support.microsoft.com/kb/974815 … 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.”

Let me explain this one a bit more – Microsoft does not have a GOOD reason for why this doesn’t work, however, it is by design and is expected. On a serious note, 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.

** 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. **