Reducing the Risks Associated with Windows 2000's Group Policy

Last time, I introduced you to Windows 2000's (Win2K's) Group Policy and described how it replaces the tools you used to control security in Windows NT. Although Group Policy is a powerful tool for handling the gargantuan task of configuring Win2K security, it can also cause problems. To avoid these pitfalls, you need to understand how Group Policy works internally, as well as how it works with various Win2K components. Let's look at several important, undocumented caveats that you need to be aware of when using Group Policy that can help you prevent some serious mistakes.

Group Policy Interworkings Win2K includes shortcuts to two security policies, Domain Security Policy and Domain Controller Security Policy, under Administrative Tools, as Screen 1 shows. Domain Security Policy is a Group Policy Object (GPO) in Active Directory (AD) that links to the domain, and Domain Controller Security policy is a GPO that links to an organizational unit (OU) called Domain Controllers.

When you promote a member server to a domain controller using dcpromo.exe, Win2K moves that server’s computer object in AD to the Domain Controllers OU. At first glance, you might think that Domain Security Policy specifies the default policy for general computers in the domain and that Domain Controller Security Policy specifies the policy for all domain controllers and domain accounts—that’s almost true. The one exception has to do with Account Policies, which is the first folder under a GPO’s Security settings, as Screen 2 shows.

Applying Account Policies Account Policies defines user account password requirements and lockout thresholds. In NT 4.0, the OS stores domain user accounts in the domain controller’s SAM, which is simply a Registry hive under HKEY_LOCAL_MACHINE. Any account policies that you define in the domain controller’s SAM control domain user accounts. In Win2K, the OS doesn't store domain user accounts in the SAM. Instead, it stores these accounts in the AD replica on the domain controller. Although every Win2K domain controller has a SAM, its users and groups are dormant. As a result, the local password requirements and lockout policies on domain controllers don’t apply to domain user accounts.

Any account policies that you define in GPOs that link to domain controllers also don’t apply. To prove it, try this little experiment. Set the Minimum Password Length to 0 in Domain Security Policy, and set the Minimum Password Length to 7 in Domain Controller Security Policy. Force an immediate application of Group Policy by typing

secedit /refreshpolicy machine_policy /enforce

at command prompt, and give the system a few seconds to refresh. Next, try to create a user account with a password that has fewer than seven characters, such as "abc." Win2k will permit the operation. This caveat means you might have a false sense of security if you have specified stricter account and lockout policies at the domain controller level than at the domain level, thinking you are protecting domain accounts. GPOs linked at the domain level are the only ones that affect account policies for domain user accounts. Account Policy is the only setting under GPOs that is subject to this phenomenon. Win2K applies other policy settings, including rights, permissions, and services, according to the relevant GPOs for each computer, which leads to another caveat.

Hide the Domain Controller Win2K initially places new domain controllers in the Domain Controllers OU, but they don’t have to stay here—you can move them to any other OU in the domain, yet another difference between Win2K and NT domain controllers. In NT, the entire SAM and Security Registry hives replicate to each domain controller. These two Registry hives constitute all the options under User Manager, including accounts, groups, account policy, audit policy, and rights assignments. Thus, you can’t specify different audit policies or user rights assignments for each domain controller in NT. In Win2K, AD—not the SAM and Security Registry hives—replicates to each domain controller. Therefore, if you scatter domain controllers into other OUs, they can easily end up with different policies. I don’t recommend that you do this, but you need to be aware of the technical capability to protect yourself from seemingly unexplainable network changes that occur over time as administrators come and go. Make sure you include a check in your assessments to verify that all domain controllers are still in the same OU.

Security Without the Shortcuts A final related caveat involves the Domain Security Policy and Domain Controller Security Policy shortcuts under Administrative Tools, which I mentioned earlier. Although these two shortcuts correspond to GPOs that typically link to their respective places in AD, don’t count on it. I’ve already seen a situation where someone inadvertently deleted the link to the Domain Security Policy GPO in the Group Policy tab of the domain properties. The administrator was scrupulously maintaining policy using the appropriately labeled shortcut, but because the domain no longer linked to this GPO, his changes had no effect and the entire domain was using an outdated security policy. The same scenario can appear in several other ways. For instance, someone might accidentally disable the default GPO or link the domain to another GPO and give it a higher priority. If you are a paranoid control freak like me, you’ll delete these shortcuts and maintain policy from AD Users and Computers where you can see which GPOs are actually linked at each domain and OU, their priority, and other options.

As you can see, Group Policy is a powerful tool, but many pieces are involved and the group policy inheritance algorithm is complex. Are the policies you define really making it down to the actual systems you must protect? To know for sure, you must look behind the illusory curtain of simplicity that Microsoft has drawn across the largest OS in the world because good intentions don’t count for much in security. In a future article, I'll give you strategies for ensuring that your Group Policy settings are working as you intended.

Discuss this Article 2

Mike Kelley (not verified)

on Jun 21, 2001

The section "Applying Account Policies" which leads to the conclusion "As a result, the local password requirements and lockout policies on domain controllers don’t apply to domain user accounts." makes no sense to me.
Where can I find this "part 2" article explained in a more basic fashion?
Sincerely,
Mike Kelley
NT 3.51 & NT 4.0 MCSE
909-820-4576 work/home