GPO Security

Best Practices for Domain Security Policies
When you create a new AD domain, two GPOs are created within that domain: the Default Domain Policy, linked to the domain, and the Default Domain Controllers Policy, linked to the Domain Controllers OU. Windows provides these GPOs to help you set domain account and other security policies, but I've seen advice that instructs you not to touch these out-of-the-box GPOs. Consequently, many administrators are confused about whether they should use these GPOs for their security policies or create their own. You can do either.

You should follow a couple of best practices when you're deploying domainwide security policies. As I've mentioned, you can set domainwide account policy only on a GPO that's linked to the domain. If you need to set other domainwide security policies (e.g., the default size of the Security log on all the DCs in a domain), set these policies in a GPO linked to the Domain Controllers OU (assuming that you haven't moved your DCs out of the Domain Controllers OU). Because Windows processes GPOs in the order of local, site, domain, then OU, setting security policies in a Domain Controllers OU–linked GPO ensures that these policies are processed last and thus override any domain-linked policies.

This best practice, though, can conflict with another best practice: setting the No Override option on your domain-linked GPO. Setting the No Override option on a GPO prevents any "downstream" GPOs with conflicting settings from overriding that higher-level policy. It can be a good idea to set No Override on a domain-linked GPO that dictates account policy if you want that account policy to be the dominant account policy in all cases. However, if you use that same domain-linked GPO to set other security policies (e.g., audit policy), it will override any audit settings you create in GPOs linked to the Domain Controllers OU. Thus, I recommend that the GPO that defines your account policy do nothing else. That way, you can delegate the administration of that GPO and your domain account policy to the security experts in your organization and ensure that you can set other security policies as needed on downstream computers.

Viewing Current Effective Security Policy
One request I often hear is, "How can I view the effective security policy on my DCs, servers, and workstations?" Of course, you can use the various Resultant Set of Policies (RSoP) tools such as those in the Group Policy Management Console (GPMC) or command-line tools such as GPResult to view the security settings on a given computer. However, a simpler way is to use the Group Policy Object Editor to view the local GPO on a given computer.

For all policy settings except security, when you view the local GPO on a computer, you see the settings stored in static files on the local file system (in %systemroot%\system32\grouppolicy). However, when you view local GPO security policy, the Group Policy Object Editor shows you the effective settings in use on the computer. On a Win2K system, you see side-by-side the local settings and the effective settings that are delivered by AD-linked GPOs, as Figure 1 shows.

Windows 2003 and XP give you a slightly different view. When you view the local GPO security policy in either of these Windows versions, you see only the effective settings. If you double-click a setting, it's uneditable if an AD-linked GPO is controlling it or editable if it's a local setting.

Also note that in the absence of an AD-linked security policy, when you make changes to local GPO security policy, you're actually making those changes to the live SAM database of that local machine, rather than making the changes to a set of files that reside in the local GPO's file structure in %systemroot%\system32\grouppolicy, as is the case for other local GPO settings.

Guaranteeing Security Policy Delivery
The way Windows processes group policies can sometimes be at odds with the goal of delivering a guaranteed security policy. To understand this conflict, you first need to understand a bit about how Group Policy processing happens. When you use the Group Policy Object Editor to create and edit an AD-linked GPO, you're storing the GPO's settings in the computer's AD and the system volume (\sysvol) and dictating the policy that the GPO will deliver on the computer. Client-side extensions (CSEs) on the computer process the settings and make configuration changes happen. Microsoft implements CSEs as DLLs and ships them with the OS. Each major policy area has a CSE; for example, CSEs exist for the software installation, security, and administrative templates policies.