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

   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

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

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!

What would seem like a quick reference item to find on Google, seems to have been lost in the billions of web pages. This article is intended as a quick reference to what the Default Domain Policies are for Windows Server 2003 SP2 and Windows Server 2008 R2. Please note that while some of the policies appear to be identical, the hierarchical structure behind the policies are different.

Default Domain Policies: Windows Server 2003 SP2

+ Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy

- Enforce Password History = 24 Passwords

- Maximum Password Age = 42 Days

- Minimum Password Age = 1 Days

- Minimum Password Length = 7 Characters

- Password must meet complexity requirements = Enabled

- Store Passwords using reversible encryption = Disabled

+ Computer Configuration > Windows Settings > Security Settings > Account Policies > Account Lockout Policy

- Account lockout threshold = 0 invalid logon attempts

+ Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy

- Enforce user logon restrictions = Enabled

- Maximum lifetime for service ticket = 600 minutes

- Maximum lifetime for user ticket = 10 hours

- Maximum lifetime for user ticket renewal = 7 days

- Maximum tolerance for computer clock synchronization = 5 minutes

+ Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

- Network Security: Force Logoff when logon hours expire = Disabled

+ Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Encrypting File System

- Administrator Issued File Recovery Certificate

+ User Settings > Windows Settings > Security Settings > Public Key Policies > Autoenrollment Settings

- Enroll Certificates Automatically

Default Domain Policies: Windows Server 2008 R2 64-bit

+ Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy

- Enforce Password History = 24 Passwords

- Maximum Password Age = 42 Days

- Minimum Password Age = 1 Days

- Minimum Password Length = 7 Characters

- Password must meet complexity requirements = Enabled

- Store Passwords using reversible encryption = Disabled

+ Computer Configuration > Policy > Windows Settings > Security Settings > Account Policies > Account Lockout Policy

- Account lockout threshold = 0 invalid logon attempts

+ Computer Configuration > Policy > Windows Settings > Security Settings > Account Policies > Kerberos Policy

- Enforce user logon restrictions = Enabled

- Maximum lifetime for service ticket = 600 minutes

- Maximum lifetime for user ticket = 10 hours

- Maximum lifetime for user ticket renewal = 7 days

- Maximum tolerance for computer clock synchronization = 5 minutes

+ Computer Configuration > Policy > Windows Settings > Security Settings > Local Policies > Security Options

- Network access: Allow anonymous SID/Name translation = Disabled

- Network security: Do not store LAN Manager hash value on next password change = Enabled

- Network Security: Force Logoff when logon hours expire = Disabled

+ Computer Configuration > Policy > Windows Settings > Security Settings > Public Key Policies > Encrypting File System

- Administrator Issued File Recovery Certificate

+ Computer Configuration > Policy > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities

- Allow users to select new root certification authorities (CAs) to trust = Enable

- Client computers can trust the following certificate stores = Third-Party Root Certification Authorities and Enterprise Root Certification Authorities

- To perform certificate-based authentication of users and computers, CAs must meet the criteria = Registered in Active Directory only

Default Domain Policy Differences: Windows Server 2003 / Windows Server 2008

Default Domain Policies added to Windows Server 2008

+ Computer Configuration > Policy > Windows Settings > Security Settings > Local Policies > Security Options

- Network access: Allow anonymous SID/Name translation = Disabled

- Network security: Do not store LAN Manager hash value on next password change = Enabled

+ Computer Configuration > Policy > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities

- Allow users to select new root certification authorities (CAs) to trust = Enable

- Client computers can trust the following certificate stores = Third-Party Root Certification Authorities and Enterprise Root Certification Authorities

- To perform certificate-based authentication of users and computers, CAs must meet the criteria = Registered in Active Directory only

Removed from Windows Server 2008

+ User Settings > Windows Settings > Security Settings > Public Key Policies > Autoenrollment Settings

- Autoenrollment Settings: Enroll Certificates Automatically

** NOTE: All re-productions / digital copies of this content must be approved in writing by an authorized representative of BIT Tangents.**