Use Group Policy to deploy and manage your security configuration
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:
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.)
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.
You can view the CSEs that are currently registered on a given machine by opening the registry and viewing the subkeys under the HKEY_LOCAL_MACHINE\SOFTWARE\MicrosoftWindowsNT\CurrentVersionWinlogon\GPExtensions subkey. Each globally unique identifier (GUID)–named subkey under the GPExtensions subkey represents a CSE. Within those GUID-named subkeys are the name of the DLL that implements the policy functionality and values that control the behavior of the CSE when it processes policy settings.
One default behavior for all CSEs is that they don't reprocess a GPO's settings if the GPO hasn't changed since the last time it was processed. Windows processes a computer-specific policy such as a security policy at machine startup (or shutdown), whereas a user-specific policy is processed at user logon (or logoff). These two events are called foreground processes. In addition to performing these two processes, Windows processes policies in the background every 90 minutes (plus a skew value) on workstations and member servers and every 5 minutes on DCs. However, the CSEs skip foreground or background processing of a given GPO if it hasn't changed since the last processing cycle. So, if a user somehow makes a change to his or her local configuration that contravenes the policy that your AD-linked GPO dictates, that local change remains in effect until someone changes the GPO that controls that policy, which might not occur for some time. For that reason, the security CSE periodically refreshes the security policy, regardless of whether the GPO has changed. The MaxNoGPOListChangesInterval value of the HKEY_LOCAL_MACHINE\SOFTWARE\MicrosoftWindowsNT\CurrentVersionWinlogon\GPExtensions\\{827D319E-6EAC-11D2-A4EA-00C04F79F83A\} subkey controls the refreshment interval. The default value is 960 minutes (16 hours), but you can increase or decrease the interval by modifying the registry value.
If you want to ensure maximum enforcement of your security policy, you can set the security CSE to process security policy at every processing cycle, regardless of whether the GPO has changed. This extra processing will create additional overhead, of course, but you can enable the processing on a per-machine basis to ensure that your most crucial servers or workstations always have the most up-to-date security configuration.
To modify the behavior of the security CSE on a computer, open the Group Policy Object Editor and navigate to Computer Configuration\Administrative Templates\System\Group Policy\Security Policy Processing under a GPO thtat's processed by the computer. Select Process even if the Group Policy objects have not changed, as Figure 2 shows. The machine will now refresh the security policy during every foreground and background processing cycle.
I've covered some of the mechanics for deploying GPO-based security policies. Now let's look at how you can get the most from some of the more popular Windows security policy areas.
Exploiting Windows Security Policies
Windows 2003, XP, and Win2K have truly hundreds of settings that you can deploy to ensure the secure configuration of your servers and workstations. The questions are, how do you find all of these settings, and what do they all do? A good starting point for understanding security policy settings is Microsoft.
In April, Microsoft released the Windows Server 2003 Security Guide (http:// www.microsoft.com/technet/security/prodtech/windows/win2003/w2003hg/sgch00.asp), which provides security templates for a variety of typical server roles (e.g., high-security file servers and enterprise DCs). You can download similar templates for Win2K Server at http://www.microsoft.com/downloads/details.aspx?familyid=9964cf42-e236-4d73-aef4-7b4fdc0a25f6&displaylang=en#filelist. XP includes some basic security templates in the %systemroot%\security\templates folder.
To use a template in your Group Policy environment, you simply import the .inf template file into the GPO that will hold the settings by right-clicking the Security Settings node in the Group Policy Object Editor and selecting Import Policy. You can also use the MMC Security Templates snap-in to view and edit the Windows 2003 and Win2K templates, as Figure 3 shows.
Addressing Windows Vulnerabilities
If you examine the templates, you'll notice that many of them set security options under the GPO's Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options node. I call this area of security policy the vulnerability defense page because it contains settings that address Windows configuration vulnerabilities that have been identified over time.
Settings under the Security Options node let you perform actions such as renaming the administrator and guest accounts across all your boxes or turning off anonymous enumeration of SAM accounts. The Windows 2003 and Win2K security templates provide some best practices for securing your Windows boxes by turning off known vulnerabilities, but you should test the settings in your environment before widely deploying them. Some of the settings can prevent the proper operation of your network, especially if you have earlier client OSs that don't support them.
The Software Restriction Policy
I don't have the space to cover all the various security policies that are available in Group Policy, but one policy area that merits some attention is the software restriction policy. This policy is new in Windows 2003 and XP; thus, you must be running one of these OS versions to use this policy. The software restriction policy is available in a Group Policy as either per-computer or per-user settings. In a nutshell, the software restriction policy lets you prevent certain applications from running. You can restrict an application according to the X.509 certificate that signed it, its file hash value, the Internet zone it came from, or its file path.
The easiest way to explain how you can use the software restriction policy is to walk through an example. Let's say I want to prevent all users in my AD domain from being able to run any applications that are launched from the Temporary Internet Files folder under their user profile. Files downloaded by Microsoft Internet Explorer (IE) are typically stored in this folder temporarily; thus, it's a good place to restrict code execution.
The first thing I need to do is enable software restriction within my GPO by navigating to Computer Configuration\Windows Settings\Security Settings, right-clicking the Software Restriction Policies node, and choosing Create New Policies. Windows immediately creates a set of objects I can use to modify software restriction behavior and displays them in the Group Policy Object Editor, as Figure 4 shows.
The three leaf nodes in the right pane—Enforcement, Designated File Types, and Trusted Publishers—let you set global options for a software restriction policy. In most cases, you can take the defaults for each.
The Security Levels folder contains two options to choose from: Disallowed and Unrestricted. The default state is Unrestricted, which lets users run all software except for programs explicitly disallowed by the software restriction policy. The Disallowed option prevents users from running any software except programs explicitly permitted by the software restriction policy. For the purposes of this example, I use the default Unrestricted value.
The real meat of the software restriction policy is in the Additional Rules folder. If you right-click this folder, you see that you can create rules according to the four criteria I identified above. For my example, I want to create a rule that prevents any software that's located in the user profile's Temporary Internet Files folder from running. So, I create a new path rule, set the path to %userprofile%\local settingstemporary internet files, then set the security level for this rule to Disallowed, as Figure 5 shows.
When a computer processes this policy, the system won't run any application files in the Temporary Internet Files folder whose types are on the Designated File Types list. As you can see, the software restriction policy can be a powerful policy for preventing unknown executable code from running amok on your network.
More Security Controls
Hopefully, I've whetted your appetite for learning about and using all the Windows Group Policy security configuration settings in your environment. In addition to policies I've mentioned here, you can set file, registry, and service permissions and even use a restricted groups policy to control group membership. Windows 2003 offers a wireless network policy that lets you control which Access Points (APs) your wireless Windows clients can connect to and whether they must use Wired Equivalent Privacy (WEP).
Overall, Group Policy security policies give you an unprecedented amount of control over your Windows security configurations. You owe it to yourself and your company to explore these capabilities to their fullest.
