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:

• Legacy Client (LC) for environments still running legacy applications that aren't compatible with standard security settings

• Enterprise Client (EC) for environments aiming to implement the standard level of security recommended by Microsoft

• Specialized Security – Limited Functionality (SSLF) for high-security environments in which limited functionality is acceptable

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

But isn't Windows Server 2003 secure out of the box? And if so, why would you need to use these security templates?

Windows Server 2003 is indeed more secure than any previous version of Windows Server, but different server roles have varying security requirements. And there's still a huge range of additional security settings that you can 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 easy way to comply with Microsoft's best practices and simplify configuration management, deploying the templates can create compatibility problems with other applications and affect functionality. To successfully deploy the templates, you need to plan for them early in the security design stage as well as understand the changes they make to your systems and how to roll them out without affecting functionality. You also need to know how to override the templates to meet your organization's security needs.

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

• Account Policies (Password, Lockout, Kerberos)

• Local Policies (Audit, User Rights Assignment, Security Options)

• Event Log

• Restricted Groups

Unlike previous versions of the Security Guide, Version 2.1 doesn't include a System Services section for defining services and related security settings. Now, you need to either define the settings for each service manually or use the Security Configuration Wizard (SCW) to create a Group Policy Object (GPO) that is based on combined settings from a security template and the wizard's recommended configuration for services when you run it against a reference machine. You can also use the SCW to add Windows Firewall and IPSec 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://www.microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.mspx.) 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 – Member Server security template to a member server running Exchange Server 2003 could limit or break your Exchange Server functionality. If Exchange SMTP is configured to accept connections using Windows Integrated Authentication from a server in another Exchange organization, the EC – Member Server security template will prevent SMTP communication between the two servers. The SMTP queue will begin to fill up, and your email won't go anywhere.

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 \Software\Policies and \Software\Microsoft\Windows\CurrentVersion\Policies 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-4D89B655-521EA6C7B4DB) and install the guide and its tools.

1. Start the SCW from Control Panel, Administration Tools. Click Next on the Welcome screen.

2. Select Create a new security policy, and click Next.

3. Select the name of the reference machine. Use Browse if the machine you're running SCW on is not the reference machine. I recommend that you run SCW from the reference machine instead of remotely because certain files are required on the local machine if you are configuring IIS security, for example.

4. When security database processing is complete, click Next until you reach the Selected Server Roles screen.

5. Ensure that the selected server roles are the ones you want the server to perform, and click Next.

6. Confirm the installed features and options, and click Next.

7. Review additional services, and click Next.

8. Decide whether to leave the additional services as is or disable them, and click Next.

9. Review the changes that will be made to the start-up type of each service listed, and click Next.

10. Skip the configuration of Network Security, Registry Settings, and Audit Policy, and click Next until you reach the Security Policy File Name screen. (Configuring network security is outside the scope of this article, but of course, you should configure it as part of this procedure. Registry Settings and Audit Policy are already configured in the security template, and SCW should not override those settings.)

11. Click the Include Security Templates button, and then click Add.

12. Browse to the location where you installed the Security Guide templates and select the *.inf file for the role and security level you want to configure—for example, ECMember Server Baseline.inf. Click OK.

13. In the Security Policy file name text box, save the new policy file to the root of your C drive (e.g., c:\ec_memberserver) and click Next.

14. Select Apply later, click Next, and then click Finish.

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 "Do's 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.