effects of a GPO by restricting which user or computer groups can “view” that GPO. In most cases, the best way to restrict which computers or users will process a GPO is to link that GPO at an appropriate level within Active Directory (AD). If you don’t want a GPO to be processed by all users in an AD domain, don’t link it to the domain level but rather to the site or organizational unit (OU) level.
However, there may be cases in which you need to apply a GPO to most of the users in your domain, but you want to exclude a small group of users. Similarly, you may have a GPO linked to an OU, but you want to let only a small group of users within that OU process the GPO. In either case, using security group filtering is the right solution.
Security group filtering of GPOs is very similar to restricting access to certain NT File System (NTFS) files and folders on a server or workstation. In both cases, you are applying access permissions to the resource in question to allow or deny certain groups of users or computers access to that resource. The access control list (ACL) on a resource contains a list of access control entries (ACEs) that specify who can access that resource—regardless of whether the resource is a file folder on a server or a GPO defined in AD. Figure 2.3 shows an example of what an ACL on a GPO looks like.
To navigate to the dialog box that Figure 2.3 shows, you need to load a Group Policy Microsoft Management Console (MMC) snap-in tool, focused on a GPO within your AD domain, or you can view the properties on a GPO from either the Active Directory Users and Computers snap-in or the AD Sites and Services snap-in. If you choose the latter approach, once the tool is loaded, highlight the container object (site, domain, or OU) to which the GPO of interest is linked, right- click the container, and select Properties from the context menu. Next, select the Group Policy tab, highlight the GPO you want to view, click Properties, and select the Security tab.
The ACL that Figure 2.2 shows has two roles. The first role is to set permissions for who can edit the GPO. The second role is to control who will process the GPO. For now, we’re interested in the latter role. There are two permissions that control whether a particular user or computer will process a GPO—the Read permission and the Apply Group Policy permission. The
combination of these two permissions allows a user or computer the ability to process a GPO. In fact, a computer or user must have both permissions defined to process the GPO—having one but not the other will not work.
Before you’re ready to start applying security group filters to your GPOs, you should understand a few key points. First, by default, all GPOs will have the Authenticated Users group with Read and Apply Group Policy permissions set. This setting means that all users and computers (yes, computers) will process the GPO. Computers are considered part of the Authenticated Users group as well as users because each computer account in an AD domain has a user account created for it to allow it to securely connect to the domain.
All domain computers and users are considered part of an AD domain’s Authenticated Users group. The next step for using security group filtering depends upon whether you’re restricting the GPO to a small group of users or computers or allowing all but a small group of users or computers to process a GPO. Let’s look at the first case.
If you want to restrict a GPO so that only a particular group of users or computers can process it, the first thing you’re going to need to do is remove the ACE for the Authenticated Users group. From the ACL editor that Figure 2.3 shows, simply highlight the Authenticated Users group and click Remove to remove the ACE. Next, you need to add the new ACE for the computer or user group that you want to grant access to the GPO. Click Add at the top of the ACL editor dialog box, and choose the computer or user group you want to grant access to.
You can add ACEs granting Read and Apply Group Policy rights to individual users and computers instead of groups. However, doing so is not recommended because it adds complexity and, as the list of permissions on a GPO grows, slows down the processing of this GPO as the computer or user sifts through all the ACEs.
Once you’ve added the group, select the Read and Apply Group Policy permissions under the Allow column in the ACL editor, as Figure 2.4 shows.
Figure 2.4: Adding a new ACE on a GPO.
In Figure 2.4, the Finance Users group has been granted access to process a GPO called Desktop Lockdown Policy that has been linked to the Finance GPO. Notice that the Authenticated Users group is nowhere to be found on this GPO. Thus, only the Finance Users group (and any other group that has Read and Apply Group Policy rights) will process this GPO.
Now, let’s look at the second case, in which we want to exclude a small group of users or
computers from processing a GPO that otherwise would be processed by every user or computer. In this case, we will use a Deny ACE to prevent a group from processing the GPO. Figure 2.5 shows an example of this.
In Figure 2.5, I’ve added an ACE for the Finance Servers group to the Default Domain Policy GPO. The Finance Servers group is a group of servers in the Finance OU that I don’t want to process the computer portion of the Default Domain Policy GPO. As you can see, the
Authenticated Users ACE is still in place on this GPO, guaranteeing that all users and computers subject to this GPO (which is linked at the AD domain level) will process it. However, by adding a Deny ACE for the Finance Servers, which overrides any Allow ACEs automatically, I
effectively prevent this computer group from processing the GPO.
In this example scenario, I could have simply added a Deny ACE for the Read permission because denying Read effectively prevents the group from processing the GPO, regardless of whether the Apply Group Policy permission was allowed. Remember, a group must have both permissions to process a GPO.
You can use these methods of adding Allow and Deny ACEs to selectively filter the effects of a GPO for particular groups of users and computers. However, because long ACLs on a GPO add to the time required to process that GPO, I recommend being judicious about how you use security group filtering. In addition, you can create a confusing situation if you add many ACEs to a GPO—some that allow access to particular groups and some that deny access—especially if users or computers belong to groups that have both been granted and denied access (the Deny ACE will always take precedence over an Allow ACE). In the case of security group filtering, keeping it simple is a good rule to follow.