GPO Security

Managing the security configuration on your hundreds or thousands of Windows machines is one of the most important tasks IT administrators must perform these days. The failure to do so, as we all know, can result in lost data, countless hours spent rebuilding machines, or in the worst case, a compromise of your business. Fortunately, in Windows 2000, Microsoft introduced Group Policy, a powerful tool for quickly and easily deploying security-configuration changes to all the Win2K and later machines in your Active Directory (AD) environment.

Let's look at how to use Group Policy to deploy and manage security configuration and at some caveats for deploying the various types of available security policies. Let's also review some of the more useful settings within Group Policy–based security policies and examine how to get the most from these settings. But let's start by understanding how to set domain security policy—that is, how to configure security settings on a Group Policy Object (GPO) that's linked to an AD domain (you can link GPOs to AD sites, domains, or organizational units—OUs).

Note that all the features I talk about here are available in Windows Server 2003, Windows XP, and Win2K unless I specifically mention that a certain version is required. For an introduction to Group Policy and GPOs, see "Introducing Group Policy," September 1999, http://www.winnetmag.com, InstantDoc ID 7066.

Domain Security Policies
One of the first security areas that you need to deal with when you deploy AD is account policy. Account policy is the portion of a GPO's security settings that lets you set required password length, password complexity, and intruder lockout for domain user accounts. To set account policy on a GPO, open the Microsoft Management Console (MMC) Group Policy Object Editor, locate the GPO, and navigate to Computer Configuration\Windows Settings\Security Settings\Account Policies under that GPO.

When you need an account policy to apply to AD domain logons (i.e., user accounts defined in AD), you need to define that policy within a GPO that's linked to the domain because the domain controllers (DCs) in an AD domain process only account policies that are contained in GPOs that are linked to the domain. DCs also ignore three other security policies unless these policies are linked to the domain:

• Automatically log off users when logon time expires
• Rename administrator account
• Rename guest account

These three policies are located in Computer Configuration\Windows SettingsSecurity Settings\Local Policies\Security Options under the GPO.

You might wonder why Microsoft requires account policies and these three security policies to be in a domain-linked GPO. As you know, when you promote a member server to a DC in an AD domain, AD stores the DC in the Domain Controllers OU by default. However, if you move a DC to another OU, the DC can then receive different security policies. Account policies and the three specified security policies need to be consistent across all DCs, so Microsoft designed the GPO processing code to ignore these policies unless they're linked to the domain, thus ensuring that all DCs, regardless of location, receive the same policies. (Microsoft permits other security policies, such as audit policy and restricted groups, to be different on DCs in different OUs. Be aware of this tolerance if you get the itch to start moving DCs out of the Domain Controllers OU.)