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.