The most misleading thing about Group Policy is its name—Group Policy is simply not a way of applying policies to groups! Instead, Group Policy is applied to individual user accounts and computer accounts by linking Group Policy Objects (GPOs), which are collections of policy settings, to Active Directory containers (usually OUs but also domains and sites) where these user and computer accounts reside. So the newbie’s question concerning Group Policy is usually, “How can I get this GPO to apply to this group?” The answer to this question is: by implementing security filtering.
Understanding Security Filtering
Security filtering is based on the fact that GPOs have access control lists (ACLs) associated with them. These ACLs contain a series of ACEs for different security principals (user accounts, computer accounts, security groups and built-in special identities), and you can view the default ACL on a typical GPO as follows:
- Open the Group Policy Management Console (GPMC)
- Expand the console tree until you see the Group Policy Objects node.
- Select a particular GPO under the Group Policy Objects node.
- Select the Delegation tab in the right-hand pane (see Figure 1).
Figure 1: Viewing the ACL for the Vancouver GPO using the Delegation tab
For a more detailed view of the ACEs in this GPO ACL, click the Advanced button to display the familiar ACL Editor (Figure 2):
Figure 2: Viewing the ACL for the Vancouver GPO using the ACL Editor
An obvious difference between these two views is that the ACL Editor displays the Apply Group Policy permission while the Delegation tab doesn’t. This is because the Delegation tab only displays ACEs for security principles that actually process the GPO, and that implicitly means those security principals have the Apply Group Policy permission set to Allow. More specifically, if you want a GPO to be processed by a security principal in a container linked to the GPO, the security principal requires at a minimum the following permissions:
- Allow Read
- Allow Apply Group Policy
The actual details of the default ACEs for a newly created GPO are somewhat complex if you include advanced permissions, but here are the essentials as far as security filtering is concerned:
| Security Principal | Read | Apply Group Policy |
| Authenticated Users | Allow | Allow |
| CREATOR OWNER | Allow (implicit) | |
| Domain Admins | Allow | |
| Enterprise Admins | Allow | |
| ENTERPRISE DOMAIN CONTROLLERS | Allow | |
| SYSTEM | Allow |
Note that Domain Admins, Enterprise Admins and the SYSTEM built-in identity have additional permissions (Write, Create, Delete) that let these users create and manage the GPO. But since these additional permissions are not relevant as far as security filtering is concerned, we’ll ignore them for now.
The fact that Authenticated Users have both Read and Apply Group Policy permission means that the settings in the GPO are applied to them when the GPO is processed, that is, if they reside in a container to which the GPO is linked. But who exactly are Authenticated Users? The membership of this special identity is all security principals that have been authenticated by Active Directory. In other words, Authenticated Users includes all domain user accounts and computer accounts that have been authenticated by a domain controller on the network. So what this means is that by default the settings in a GPO apply to all user and computer accounts residing in the container linked to the GPO.
Using Security Filtering
Let’s now look at a simple scenario where you might use security filtering to resolve an issue in Group Policy design. Figure 3 below shows an OU structure I developed in a previous article. Note that the Vancouver top-level OU has three departments under it defined as second-level OUs, with user and computer accounts stored below these departments in third-level OUs:
Figure 3: Sample OU structure for Vancouver office
Let’s say that of the fifteen users who work in the Sales and Marketing Department in Vancouver, three of them are senior people who have special requirements, for example access to certain software that other people in the department shouldn’t have access to. Such software could be provided to them by publishing it in Add or Remove Programs using a user policy-based software installation GPO. The trouble is, if you link this GPO to the Sales and Marketing Users OU then all fifteen users in the department will have access to it through Add or Remove Programs. But you only want this special group of three users to be able to access the software, so what do you do?
You could create another OU beneath the Sales and Marketing Users OU and call this new OU the Senior Sales and Marketing Users OU. Then you could move the user accounts for the three senior employees to this new OU and create your software installation GPO and link it to the new OU. While this approach will work, it has several disadvantages:
- It makes your OU structure deeper and more complicated, making it harder to understand.
- It disperses user accounts into more containers making them more difficult to manage.
A better solution is to leave your existing OU structure intact and all fifteen Sales and Marketing users in the Sales and Marketing Users OU, create your software installation GPO and link it to the Sales and Marketing Users OU (see Figure 4), and then use security filtering to configure the ACL on the software installation GPO to ensure that only the three senior users receive the policy.
Figure 4: Senior Sales and Marketing Users Software Installation GPO
To filter the software installation GPO so that only users Bob Smith, Mary Jones, and Tom Lee receive it during policy processing, let’s first use Active Directory Users and Computers to create a global group called Senior Sales and Marketing Users that has only these three users as members (see Figure 5):
Figure 5: Membership of the Senior Sales and Marketing Users global group
Note that you can store this security group in any container in the domain, but for simplicity you’ll probably want to store it in the Sales and Marketing Users GPO since that’s where its members reside.
Now go back to the GPMC with the software installation GPO selected in the left-hand pane, and on the Scope tab of the right-hand pane, remove the Authenticated Users special identity from the Security Filtering section and then add the Senior Sales and Marketing Users global group (Figure 6):
Figure 6: Filtering the GPO so it only targets the Senior Sales and Marketing Users group
That’s it, we’re done! Now when policy is processed for a user account residing in the Sales and Marketing Users OU, the Group Policy engine on the client will first determine which GPOs need to be applied to the user. If the user is a member of the Senior Sales and Marketing Users security group, the following GPOs will be applied in the following order (assuming we haven’t used blocking or enforcement anywhere):
- Default Domain Policy
- Vancouver GPO
- Sales and Marketing GPO
- Sales and Marketing Users GPO
- Senior Sales and Marketing Users GPO
If however the user is one of the other twelve (junior) members of the Sales and Marketing Department, then the last policy above (Senior Sales and Marketing Users GPO) will not be applied to them. In other words, the published software will only be made available to Bob, Mary and Tom as desired.
The Power of Security Filtering
The power of security filtering is that it allows us to simplify our OU structure while still ensuring that Group Policy is processed as designed. For example, in my original OU structure for Vancouver (see Figure 3 above) I created separate OUs for three departments in that location, namely the IT Department, Management, and Sales and Marketing. In Toronto however I could have taken a different approach and lump all my users and computers together like this (Figure 7):
Figure 7: Toronto has a simpler OU structure than Vancouver
Then I could group user and computer accounts in Toronto into global groups like this:
- IT Department Users
- IT Department Computers
- Management Users
- Management Computers
- Sales and Marketing Users
- Sales and Marketing Computers
I could then create GPOs for each group of users and computers in Toronto, link these GPOs to the appropriate container, and use security filtering to ensure they are applied only to the desired security principals (Figure 8):
Figure 8: Using Group Policy to manage users in Toronto
The main downside of this approach is that as you flatten your OU structure you can end up with lots of GPOs linked to each OU, which can make it harder at first glance to figure out which policies are processed by each user or computer unless you examine in detail the security filtering setup.
Conclusion
In the end then, it’s a simple matter of give and take—make your OU structure too flat and it can be harder to manage policy; make your OU structure too deep and it can be harder to manage accounts. It’s up to you to decide on which approach to take for implementing Group Policy for your enterprise.Source: http://www.windowsnetworking.com/articles_tutorials/Group-Policy-Security-Filtering.html
Note:
Menambah WSUS Administrative Template
