Safely Deploy Security Templates

In addition to providing valuable guidance for hardening your Windows Server 2003 systems, Microsoft's Windows Server 2003 Security Guide contains a series of security templates that you can apply to servers in your environment according to their role. You can choose from three categories of templates:

For each template category, the guide provides templates for such roles as Domain Controller, Member Server, File Server, and WebServer. Using the templates, you can quicklycomply with Microsoft's best practices on asingle server or across a series of servers throughActive Directory (AD) and Group Policy (GP).

But isn't Windows Server 2003 secure out ofthe box? And if so, why would you need to usethese security templates?

Windows Server 2003 is indeed moresecure than any previous version of WindowsServer, but different server roles have varyingsecurity requirements. And there's still a hugerange of additional security settings that youcan configure for your particular needs.

In addition, by using these templates to configure server security, you can control, manage, and enforce your servers' security configuration from a central location—AD. Instead of having different or unknown settings that are manually configured (or not controlled by policy) on every server, you can be sure of the configuration and easily manage it.

Although the templates give you an easyway to comply with Microsoft's best practices and simplify configuration management,deploying the templates can create compatibility problems with other applications andaffect functionality. To successfully deploy thetemplates, you need to plan for them early inthe security design stage as well as understandthe changes they make to your systems andhow to roll them out without affecting functionality. You also need to know how to override the templates to meet your organization'ssecurity needs.

Inside the Templates
When you deploy the Security Guide templates, they configure four main areas of security. Those areas are

Unlike previous versions of the SecurityGuide, Version 2.1 doesn't include a SystemServices section for defining services andrelated security settings. Now, you need toeither define the settings for each servicemanually or use the Security ConfigurationWizard (SCW) to create a Group Policy Object(GPO) that is based on combined settings froma security template and the wizard's recommended configuration for services when yourun it against a reference machine. You canalso use the SCW to add Windows Firewall andIPSec configuration settings to a GPO.

The settings configured under the Account Policies, Event Log, and Restricted Groups sections are relatively straightforward and shouldn't cause many problems as long as you understand how the features work. (You can read an overview of the Security Guide at http://technet.microsoft.com/en-us/library/cc163140.aspx.) However, User Rights Assignment and Security Options settings under the Local Policies section can cause functionality problems in your environment if you don't plan for them carefully.

For example, deploying the EC – MemberServer security template to a member serverrunning Exchange Server 2003 could limit orbreak your Exchange Server functionality. IfExchange SMTP is configured to accept connections using Windows Integrated Authentication from a server in another Exchangeorganization, the EC – Member Server securitytemplate will prevent SMTP communicationbetween the two servers. The SMTP queuewill begin to fill up, and your email won't goanywhere.

Windows Integrated Authentication for Exchange SMTP relies on legacy NTLM authentication, and at the root of the problem are the NTLM settings configured in the EC – Member Server template. Table 1 describes the NTLM configuration before and after the template is deployed. As you can see, in an environment where the EC security templates have not been deployed, there are no special requirements for NTLM session security. However, the EC security templates configure the maximum security requirements, causing Windows Integrated Authentication on Exchange SMTP connectors to fail.

However, as we'll see in a moment, you can override the templates' security policies for particular servers to maintain needed functionality.

Deploying the Templates
As you can see from the Exchange SMTP example, a couple of simple tweaks to server security can spell disaster for server and application functionality. Ideally, you should plan for and integrate the templates into your Group Policy design at an early stage, testing all functionality before going live. After you've moved an environment into production, implementing the changes required to deploy these templates becomes very difficult.

Whether you deploy the templates in the early stages of a system's life or after the system has gone live, you must thoroughly test the GPOs in a lab environment to ensure that functionality isn't affected.

Because the templates use many additional registry values that are not true Group Policy settings—and thus can't be reversed by simply unlinking the policy—you must back up your system (including the system state) before deploying policies created by using the templates. The SoftwarePolicies and SoftwareMicrosoftWindowsCurrentVersionPolicies subkeys under HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE are the only places where true, non-persistent policies are defined. Figure 1 shows some examples of TCP/IP parameters that are configured in other areas of the registry. Because the TCP/IP parameters defined in the template are not located in the areas of the registry mentioned above, the changes will be persistent and can't be reversed by removing the GPO.

Creating a New GPO
You should always create new GPOs for deploying the Security Guide templates. Don't import settings into existing policies such as the Default Domain Policy. Importing settings into an already configured policy (unless you clear the security database beforehand) will create a confusing combination of settings from the template and the original policy. For ease of use and management, the policies should be unique known quantities, as defined in Microsoft's documentation. You should also retain the original configuration of the Default Domain Policy in case you need to roll back to the previous configuration.

Before you start to configure the new policy, you need to choose (or create) a reference machine that has the same general configuration as the machines to which you want to deploy the policy. For instance, if you want to deploy a policy to Exchange servers in your organization, the reference machine should have Exchange installed and all necessary services running.

Let's walk through using the SCW to import template settings into a new GPO along with recommended System Services start-up settings by using a reference machine. Before working through the following steps, install the SCW from Add/Remove Windows Components under the Add/Remove Programs Control Panel applet. You also need to download the Security Guide (available at http://www.microsoft.com/downloads/details.aspx?&FamilyID=8a2643c1-0685-4d89-b655-521ea6c7b4db) and install the guide and its tools.

To convert the resulting SCW *.xml file into a GPO, open a command prompt and execute the following command:

scwcmd transform  /p:c:ec_memberserver.xml  /g:"EC - Member Server Baseline" 

When the command has completed, you will see the new EC – Member Server Baseline policy in the Group Policy Management Console (GPMC) under the Group Policy Objects node for the domain. (Note that there is a bug in GPMC when used on Windows Server 2003 Release 2. If you use GPMC to view the settings for the new policy, System Services are not displayed. However, if you view the policy using Group Policy Editor, you will see that System Services start-up settings have been defined in the policy.)

Creating Override Policies
To resolve the problem with SMTP functionality that we looked at earlier, you can create a new GPO called an override policy that you apply only to the affected servers. The override policy contains just a few modifications to lower specific security requirements for the affected servers and leave the other configuration settings intact. The policy is then applied with a higher priority than the EC – Member Server policy to ensure that the modifications are implemented successfully. In the SMTP example, the override policy contains only the three settings that Table 2 shows.

Figure 2 shows how you can use the Group Policy Management screen's Group Policy Inheritance tab to link various GPOs in an order that ensures appropriate application of the settings. EC policies that you configure by using the Security Guide templates should have a higher precedence than Default policies, and override policies should have higher precedence than the EC policies.

Different policies apply depending on which organizational unit (OU) the server resides in. You can view all the GPOs that apply to an OU (either directly or by inheritance) by selecting the Group Policy Inheritance tab.

A More Secure System
Deploying the Security Guide templates requires a lot of planning and a preproduction lab environment where you can test functionality. However, using the security templates in combination with the SCW to create policies for your Windows servers gives you control over your security environment. You'll be able to make changes across many servers, comply with Microsoft's security best practices, and add reliability and stability to your environment. See "Dos and Don'ts of Using Security Templates," below, for tips to successfully use the security templates.

If Microsoft wants organizations to take security seriously, Exchange (and other servers and applications) should work out of the box with the EC security templates. At the very least, Microsoft should document the problems that this article identifies. This article summarizes the benefits and problems involved in using the security templates and the SCW; however, it's not a replacement for reading the documentation that comes with the guide.