An administrator can add both computers and users to security groups. Then the administrator can specify which security groups are affected by the GPO by using the Access Control List (ACL) editor. To start the ACL editor, select the Security tab of the property page for the GPO. Then set access permissions using discretionary access control lists (DACLs) to allow or deny access to the GPO by specified groups. By changing the Access Control Entries (ACEs) within the DACL, the effect of any GPO can be modified to exclude or include the members of any security group. For more information about security groups, see How Security Groups are Used in Access Control.

To apply a GPO to a specific group, both the Read and Apply Group Policy ACEs are required. By default, all Authenticated Users have both these permissions set to Allow. Because everyone in an organizational unit is automatically an Authenticated User, the default behavior is for every GPO to apply to every Authenticated User. However, domain administrators, enterprise administrators, and the LocalSystem account already have full control permissions, by default, without the Apply Group Policy ACE. Therefore, because administrators are also …

Read More

Group Policy WMI Filtering was introduced with Windows XP, and is a great way to add a decision on when to apply a given group policy. WMI Filters, written in WMI Query Language (WQL), allow an administrator to specify a WMI-based query to filter the application of a GPO. WMI Filtering can be very useful when users or computers are located in a relatively flat OU structure in Active Directory, for example. WMI Filters can also allow you to apply specific policies based on server roles, operating system version, network configuration, and other criteria. Windows evaluates these filters in the following order of overall Group Policy Processing:

1. Policies are located in hierarchy.
2. The WMI Filters are checked.
3. The security settings are checked.
4. A policy is either filtered or applied depending on the results of the previous checks.

Breakdown: We locate all of the policies that exist in the user or computer’s Local, Site, Domain, and OU hierarchy. We then determine if the WMI Filter (if any are defined) returns TRUE. We then verify that the user or computer has both Read and Apply group policy permissions for the GPO. Once all of that is validated, the group policy is …

Read More

I thought it might be useful to outline the approach that I take to designing group policy infrastructure in environments that I manage. Architecting group policy can be a daunting and time consuming task, so it’s good to know how it works before you start. All of what you’re about to read was gathered from Microsoft documentation, and should be accurate to the date of this writing. Everything you’re about to read has been compiled over the last 10 years from a combination of Microsoft best practices and real world experiences tweaking GPOs in production environments.

I use the terms functional and monolithic to describe the two possible approaches:

• Functional GPOs Contain one or more settings from a single policy area and often target a single function (e.g., Browser Security, Workstation Lock)
• Monolithic GPOs Contain a variety of settings from multiple policy areas (e.g., Administrative Templates, security, Group Policy preferences)

The majority of the corporate environments I’ve managed contain Functional GPOs when I start. Most environments should have a mix of both Monolithic and Functional GPOs. This is driven by factors such as the need for delegating certain GPOs to a particular business unit administrator, the desire to manage …

Read More