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://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 – 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.