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

Recently, when I presented a Windows 2000 security seminar, one of my students made a simple change to rights assignments in Group Policy, and I discovered how easy it is to lock everyone out of an Active Directory (AD) domain. The incident taught me how important it is to use strict change-management controls, to follow least-privilege doctrine, and to implement some fail-safe measures in AD to protect domain controllers (DCs).

The student, Bob, had completed the hands-on exercises for working with rights assignments using Group Policy and decided to experiment—something I always encourage. Bob edited the Default Domain Policy Group Policy Object (GPO), maneuvered to Computer Configuration, Windows Settings, Security Settings, Local Policies, Rights Assignments, and assigned the Deny access to this computer from network right to Everyone. This deny right prevents users with the proper permissions from connecting to any Win2K resources on the computer over the network—basically, all file or printer sharing and any resources in Computer Management, such as the event log, services, and local users and groups. (Users can still connect to other services that don’t use Win2K authentication, such as anonymous Web or FTP connections.) Because Bob assigned this right at the root of the domain, the deny right applied to all computers in his domain. Furthermore, because Bob assigned the right to the special Everyone group, he locked everyone out of all the computers in the domain.

When Bob brought the problem to my attention, we thought we could simply log on locally to the DC. Then we tried to edit the Default Domain Policy GPO to correct the problem, thinking that we’d be using a local connection and would bypass the Deny access to this computer from network right.] Unfortunately, that approach didn’t work either. Whenever you try to edit a GPO, even when you're logged on locally to the DC, Win2K uses a Lightweight Directory Access Protocol (LDAP) network connection to access the AD groupPolicyContainer object, and uses a file-sharing connection to access Group Policy-related files on a shared folder on the DC called sysvol. If the classroom test domain had been a production domain, Bob would have been in big trouble because no one could log on and use any resource on any computer in the domain. Although the problem was the result of one simple change, Bob's only recourse was to restore the DC from a backup, or do a low-level edit of the appropriate Group Policy file on the DC while logged on locally. Unfortunately, the latter option isn’t much of an option—the format of Group Policy files is not well documented. You can use three strategies to protect your domain from accidents like this. Let's look at the first strategy.

Isolate Your DCs from Accidental Changes to Group Policy
If you can keep your DCs stable, you should always be able to get into AD and Group Policy to correct any problems. To isolate your DCs, you need to lock down the Group Policy options on the root of your domain and each DC's organizational unit (OU). To lock down a DC's OU, open Active Directory Users and Computers, and click the OU of Domain Controllers. Create a new group called Domain Controllers GPO Administrators, and populate it with only the people who you have authorized to configure DCs. Right-click the Domain Controllers OU, select Properties, and click the Group Policy tab, as Figure 1 shows. Check Block Policy inheritance to prevent GPOs at the root of the domain from affecting DCs. (Note: You might need to duplicate some policies in the Domain Controllers OU if you want to apply the policies to all computers in the domain, including DCs.) Next, select the GPO for the Default Domain Controllers Policy, and click Properties. Select the Security tab, and click Advanced. Under the Permissions tab, click Remove to delete the entries for Domain Administrators and for Enterprise Administrators. Click Add to create an entry that grants full control to the Domain Controllers GPO Administrators, as Figure 2 shows. This step also implements a safeguard that prevents Domain Administrators or Enterprise Administrators from changing this GPO unless they purposely take ownership of it. Next, go back to the Domain Controllers Properties, as Figure 1 shows, and select the Security tab. Clear Allow inheritable permissions from parent to propagate to this object. When you are prompted to copy or remove inherited permissions, select Copy, and remove any entries that grant any access to Administrators, Domain Administrators, or Enterprise Administrators. Give full control to your new Domain Controllers GPO Administrators group, as Figure 3 shows. These two changes prevent other administrators from accidentally creating new GPOs in the Domain Controllers OU or clearing Block Policy inheritance check box.

At this point, you've isolated your DCs from changes that users make outside their OU and from mistakes administrators might make. However, DCs will still receive any policies you defined in GPOs that you linked to the domain root, where you can check the No override check box—No override takes precedence over Block Policy inheritance. To guard against overriding your policies, you can add an ACL entry on each GPO linked to the root of the domain that explicitly denies Read and Apply Group Policy access to the Domain Controllers Group. If you've flagged a domain root-linked GPO as No override, when a DC tries to read and apply the GPO, the GPO will deny access. In Part 2, I’ll show you how to use change control techniques and least privilege to protect the rest of your domain from administrator mistakes.