Don't Shoot Yourself in the Foot with Group Policy Security Settings, Part 2

Nowhere is change control more important than in Active Directory (AD) and Group Policy: a directory service (i.e., AD) and centralized configuration solution (i.e., Group Policy) are fundamental to your IT infrastructure. However, many systems administrators make the mistake of implementing changes in production without a review-and-release cycle that includes peer review and advance maintenance announcements. Change control has always been strong in the mainframe world, but it's never fully matured in the Windows world. Unfortunately, as the opening example illustrates in Part 1 of this article, Windows 2000 can make a potentially devastating and wide-ranging change appear to be simple and harmless.

Change Controls
Change control is a concept that software developers adopted after they learned the hard way that uncontrolled changes to source code in production environments wreaks havoc. The key items to implement in your change control process are formalized testing, impact analysis, and separation of the developer and the installer. You should always test new policies before actually changing them in production GPOs. I recommend that you first create a Testing OU, add a computer and some test users to this OU, and test your proposed changes. When you're satisfied with the results, carefully make the same changes in the appropriate production GPO. Prior to making the changes in production, ask a colleague to check your work, and discuss any impact issues that you need to take care of, such as informing users of changes to their desktop that some Group Policy settings cause. If you have a large domain of many users in which the possible damage from mistakes is high, you might consider creating a special GPMaintenance user account where you can lock down GPOs so that only GPMaintenance has Write access. You can channel all changes to Group Policy through the person to whom you assign that account. Not only will using least privilege and change control protect your from mistakes, you'll also have a neater domain that's easier to manage because subadministrators won’t be able to clutter up the domain with unneeded objects.

Least Privilege
One of the best ways to facilitate change control is to follow the least-privilege doctrine, whereby you grant all IT staff members the minimum authority they need to do their jobs. If you limit their authority to change your environment, fewer users can shoot themselves in the foot. You couldn't follow least-privilege practices with Windows NT because of NT’s monolithic, all-or-nothing administrative authority structure. However, with Win2K, you can follow least-privilege practices because each object (e.g., domain, site, OU, user, group, Group Policy Object—GPO) has its own ACL that controls who can do what to each object. To follow least-privilege practices, follow a few simple rules. First, don’t put users in AD's Enterprise Admins, Domain Admins, or Administrators groups. Hardly anyone in a medium-to-large organization should have unlimited authority to the entire network. Second, when delegating maintenance of an OU in your domain to another administrator, don’t delegate full control of the OU. Typically, the work you delegate involves maintaining the users or groups in that OU. If you grant full control of the OU, you also let that administrator completely change how to apply Group Policy to the users and computers in that OU.

Two types of objects in AD control who can edit and impact Group Policy: OUs and GPOs. Be careful when you edit the ACLs of these two types of objects—don’t delegate more authority than necessary; you can end up with policy changes you don’t want.

Each GPO has an ACL that controls who can access the GPO and how. To view a GPO's ACL, open AD, the Active Users and Directory Computers Microsoft Management Console (MMC) snap-in, right-click an OU where you know you have a linked GPO, and select Properties. In the Properties window of that OU, click the Group Policy tab. To view that GPO's properties, select the GPO you want as Figure 1 shows, and click the Properties button, which will display the Properties window for the GPO you selected in Figure 1, and select the Security tab to view the GPO’s ACL, as Figure 2 shows. Note any user or group that you've assigned Full Control or Write access. Either of these permissions lets the user edit the GPO, which affects all users and computers associated with this GPO. Because GPOs define policies for almost every aspect of a Win2K computer, anyone with write access to a GPO has, in effect, administrator authority over all the computers where Win2K applies the GPO. Remember: You can link a GPO to more than one OU; however, no matter how many places you link a GPO, it has only one ACL.

To keep control of Group Policy changes, you should also be careful with OU permissions. The list and options you see on the Group Policy tab of an OU’s Properties window correspond to two properties present on every OU: gpLink and gpOptions. gpLink corresponds to the List of GPOs in Figure 1. gpOptions corresponds to the Block policy inheritance check box, as the same figure shows. Any user who has Write access to gpOptions can select this check box and prevent important policies you’ve already defined from taking effect with the users and computers in this OU. Any user with Write access to gpOptions can add or delete GPOs that link to the OU. To view property-level permissions for an OU, select the Security tab in Figure 1 shows, and click Advanced, which will display Figure 3, to display the advanced view of the OU's ACL, as Figure 4 shows. Double-click any of the access control entries, and select the Properties tab, as Figure 5 shows. Be aware that granting high-level Full Control or Write access, as Figure 3 shows, also grants Write access permission to gpLink and gpOptions.

If you tightly control who has write access to existing GPOs and to gpLink and gpOptions properties on OUs, you'll be able to worry less about careless or uncooperative administrators who want to contradict policies you define higher in the domain. When you need to delegate authority over an OU to another administrator, think carefully about what abilities the person really needs rather than assigning full control to them. Use the delegation of the control wizard to create custom tasks that include only the amount of authority the other administrator needs.