If you've worked with Active Directory for any length of time, you've certainly done at least a certain amount of work with Group Policy Objects (GPOs). On the off-chance that you've never worked with them before, GPOs allow you to apply various configuration settings to an entire group of user and computer objects by linking one or more GPOs to an Active Directory container (you can link Active Directory GPOs at the site, domain and OU level). By default, once you've linked a GPO to an AD container, every user and computer object within that container will receive the settings configured in that GPO. The reason for this is that a GPO, like anything else within Active Directory, is an object that you can apply permissions to using its Access Control List (ACL).
In addition to the usual Read, Write, and Full Control permissions, you can also grant or deny the Apply Group Policy permission to a GPO. It is this permission in conjunction with Read that controls whether a particular GPO will apply to a particular user or not. The default ACL for a newly-created Group Policy Object grants the Read and Apply Group Policy permissions to the Authenticated Users group. This is a special security group that applies to all users (including administrators) who have successfully authenticated against your Active Directory domain. That parenthetical is a fairly important point to keep in mind, because if you're not careful in testing your Group Policy settings before deploying them to a production environment, you can inadvertently lock your own administrative and support staff out of portions of the Windows operating system.
As you might imagine, you can use these ACLs to exert really fine control over how Group Policy is applied in your organization (and of course leave yourself open for troubleshooting issues if you're not careful).
Let's say that you administer a smallish network where you've placed all of your users in a single OU, and now you want to use Group Policy to lock down certain operating system features. So you create a GPO called Global-Settings that mandates a number of settings. One of the settings included in the Global-Settings GPO disables access to the Settings tab in the Display Control Panel applet, to cut down on support calls from users who have "fooled around" with their display settings and rendered their screens unreadable. However, after you deploy this policy, you learn from your web developer and graphics designers that this is hindering their ability to do their jobs, since they often switch to different screen resolutions to test how your company's web applications appear at lower and higher settings. Since you don't want to roll back this GPO restriction entirely, you can use security filtering to apply a different setting to this small subset of users.
The steps involved in this process are as follows:
1. Create a security group called WebDev that contains all of the users who should be held exempt from this setting.
2. Create a second GPO called WebDev-Display-Settings containing a setting that explicitly enables access to the Settings tab of the Display applet.
3. Remove the entry for the Authenticated Users group in the ACL for this new GPO. Add the WebDev security group you created in Step 1 to the GPO's ACL, and then grant the Read and Apply Group Policy permissions to the WebDev-Display-Settings GPO.
4. Link this second GPO to the OU containing your user accounts, and make sure that it appears first in the list of GPOs, also referred to as the link order.
That last step deserves a bit of additional explanation. When multiple GPOs are linked to a single OU, they are processed in order from the bottom of the link order to the top. If any settings conflict, like access to the Settings tab in our example, the setting that is applied last will be the one that is applied. (Think of it as having an argument in which the person who gets the last word in is the one who wins.) So, in our example, when a web designer logs onto Active Directory, Group Policy processing happens in the following order:
1. The Global-Settings GPO is applied first, and access to the Settings tab is disabled.
2. Since this user is a member of the WebDev security group, the WebDev-Display-Settings GPO is applied second (and last), and access to the Settings tab is enabled.
Since only the members of the WebDev security group have the Read and Apply Group Policy permission to the WebDev-Settings GPO, a user who isn't a member of the WebDev group will only have the Global-Settings GPO applied, and will therefore have his or her access to the Settings tab disabled.
As you can probably guess, we've only just scratched the surface of the ways that you can control Group Policy behavior on your network. In future articles, we'll discuss other ways that you can customize how GPOs are deployed within an Active Directory environment.
Laura E. Hunter (CISSP, MCSE: Security, MCDBA, Microsoft MVP) is a senior IT specialist with the University of Pennsylvania, where she provides network planning, implementation and troubleshooting services for business units and schools within the university. Hunter is a two-time recipient of the prestigious Microsoft "Most Valuable Professional" award in the area of Windows Server-Networking. She is the author of the Active Directory Field Guide (APress Publishing). You can contact her at [email protected]