Professor Windows - April 2005

Windows Server 2003 Service Pack 1

Professor Windows

Written By:

Reviewed By:
Elliot Lewis, Security Architect, Microsoft Corporation
Dave Louw, Program Manager, Microsoft Corporation
Jesper Johansson, Program Manager, Microsoft Corporation


Microsoft presented its most secured operating system, when Windows Server 2003 was released in April 2003; however, since its release, many new and formidable threats have appeared, and hackers and script kiddies with an Internet connection keep finding new ways to compromise systems.

On the client side, with features such as the Windows Firewall, Remote Procedure Call (RPC) lockdown and a plethora of Internet Explorer security enhancements, Windows XP Service Pack 2 was considered a huge stride in host-based security, and is viewed as a critical update for online systems.

Microsoft continues on the journey in "Trustworthy Computing" with the release of Service Pack 1 (SP1) for Windows Server 2003.

Windows Server 2003 SP1 is called a service pack, but with the amount of new features (specifically security features), we would surely call this a feature pack. In this article, we will cover some of these features and show how you can increase enterprise server security and availability.

Security Configuration Wizard

In a world of a plethora of security guides, it seems that every organization and security consulting company has its own view of how to lock down servers. That is all fine and dandy, until something goes wrong, and when systems behave bad, you need to know what you've done exactly. This is where the new Security Configuration Wizard (SCW) comes in! Think if it as consistent and predictable way to lock down your servers!

The SCW uses a roles-based metaphor, driven by an extensible XML knowledge base that defines the services, ports, and other functional requirements for over 50 different server roles, including roles for Windows Server System applications such as Microsoft Exchange, AD, SQL Server, and more.

Security Configuration Wizard uses this extensible XML knowledge base to perform role discovery, solicit user input, and author security policies that disable services, block ports, modify registry values, and configure audit settings. Even ports that are left open can be restricted to specific populations or secured using Internet Protocol security (IPsec).

The Security Configuration Wizard also allows you to roll back previously applied policy settings and includes a command-line tool you can use to apply a security configuration and perform compliance analysis to groups of servers in your organization. The Security Configuration Wizard also integrates with Active Directory to support deployment of SCW-generated policy settings through Group Policy.

The Security Configuration Wizard allows server administrators to increase security by:

  • Disabling unnecessary services
  • Disabling unnecessary IIS Web extensions
  • Blocking unused ports, including support for multi-homed scenarios
  • Securing ports that are left open using IPsec
  • Reducing protocol exposure for Lightweight Directory Access Protocol (LDAP), LAN Manager, and server message block (SMB) traffic
  • Configuring audit settings consistently
  • Importing Windows security templates for coverage of settings that are not configured by the wizard

32 Bit

You can find the new SCW in the Add/Remove programs after installing SP1.

Post-Setup Security Updates

For those that don't have SUS, WUS or SMS there is a great new capability that will protect your server during the phase when you bring up a new server, connect to the Internet, and hit the Windows Update.

With this new feature, once you finish a Windows Server 2003 installation (with SP1 slipstreamed), the server will block all incoming communication through the Windows Firewall until you install all of the latest security updates, to prevent worms, Web attacks, spyware installations and other unwanted elements (Read: dA bAd gUyz) from exploiting and attacking your server through unpatched security holes. See Figure 2.

If your browser does not support inline frames, click here to view on a separate page.

A very welcome feature indeed!

Remote Access Quarantine

After you've tried Remote Access Quarantine, you'll wonder how you ever lived without it. Remote Access Quarantine provides network administrators the ability to validate the configuration of remote client computers before they are permitted to access the corporate network. Think of it as a state of health" check for your incoming connections.

Remote access connections only validate the credentials of the remote access user. This means the computer used to connect to a corporate network can access resources even when its configuration does not comply with security policy.

For example, a remote access user with valid credentials could connect to a network with a computer that does not have the latest security patches installed, does not contain the latest antivirus definitions or worse - may carry malicious code or spyware. Laptops or other computers used from employee's homes or even the same computers they use at the internal organization when coming from an external network may not meet corporate security requirements. Usability and mobility are the name of the game today, but how can we determine the health state of these connections?

The Remote Access Quarantine, a new feature in Windows Server 2003 Service Pack 1 helps solve this problem by delaying normal remote access to a private network until the configuration of the remote access computer has been examined and validated by an administrator-provided script. When a remote computer initiates a connection to a remote access server, the user is authenticated and the remote computer is placed in a quarantine state with limited access with the use of an IP filter on the remote access server. Then the administrator-provided script is run on the remote computer. Note that the script can be either a post-connect or pre-connect act with Connection Manager. When the script notifies the remote access server that the remote computer complies with current network policies, quarantine mode is removed and the remote computer is granted normal remote access.

If we think about the threat that we are trying to mitigate here (knowing which contaminated machines are connecting to the network), then this is an excellent solution for this type of threat. It is about health control rather than security control. Remote Access Quarantine is not a security solution for other threats that you might be trying to mitigate. It is designed to help prevent computers with unsafe configurations from connecting to a private network.

Moving forward (beyond Windows Server 2003), you will be seeing this type of technology advance to include DHCP, IPsec and 802.1x. For more information, see .

RPC and DCOM Security Enhancements

In an effort to reduce the attack surface of Windows Server-based servers, Microsoft has implemented some key low-level changes from Windows XP SP2 in Windows Server 2003 SP1. Changes have been made to the Remote Procedure Call (RPC) and Distributed COM (DCOM) interfaces to be more secure by default.

So again, what are we trying to mitigate here?

If you think about it, it is much more difficult to attack an interface if that interface requires calls to perform authentication, even a relatively low level of authentication.

RPC Enhancements

One cool registry addition within Windows Server 2003 SP1 is the new RestrictRemoteClients registry key. Using this key can be a particularly useful mitigation against worms that rely on exploitable buffer overruns that can be invoked remotely through anonymous connections. If you are an application developer and you know which clients will be accessing your application, and you have an environment where all clients are properly authenticated, then set this registry value to 2 (the default value is 0). However, if your RPC application expects to receive calls from remote anonymous RPC clients, using this feature may not allow your application to run correctly.

Key Reference

Key name: RestrictRemoteClients


Configurable through User Interface: Yes. This key can be configured using the Group Policy Object Editor.

Value Description
(default value)
This value is the default in Windows Server 2003 Service Pack 1. It causes the system to bypass the RPC interface restriction. This corresponds to the value RPC_RESTRICT_REMOTE_CLIENT_NONE in rpcdce.h. It is entirely the responsibility of the server application to impose appropriate RPC restrictions. This setting is equivalent to the behavior in previous versions of Windows.
1 This value is the default value in Windows XP Service Pack 2. It restricts access to all RPC interfaces. All remote anonymous calls are rejected by the RPC runtime. This corresponds to the value RPC_RESTRICT_REMOTE_CLIENT_DEFAULT in rpcdce.h. If an interface registers a security callback and provides the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag, then this restriction does not apply to that interface.
2 All remote anonymous calls are rejected by the RPC runtime with no exemptions. This corresponds to the value RPC_RESTRICT_REMOTE_CLIENT_HIGH in rpcdce.h. When this value is set, a system cannot receive remote anonymous calls using RPC.

DCOM Enhancements

In terms of DCOM security enhancements, a change has been made in COM to provide computerwide access controls that govern access to all call, activation, or launch requests on the computer. The simplest way to think about these access controls is as an additional AccessCheck call that is done against a computerwide access control list (ACL) on each call, activation, or launch of any COM server on the computer. If the AccessCheck fails, the call, activation, or launch request will be denied. (This is in addition to any AccessCheck that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to access any COM server on the computer.

Access Based Directory Enumeration

The last highlight is definitely not leastever wondered why users can see shares that they don't have access to? Moving forward, this will be a feature of the past!

Windows Server 2003 SP1 adds new functionality called Access-based Directory Enumeration". This feature allows users of Windows Server 2003 based file servers to list only the files and folders to which they have access when browsing content on the file server. This eliminates user confusion that can be caused when users connect to a file server and encounter a large number of files and folders that they cannot access.

Keep in mind that this feature is not enabled by default and to get this up and running, you are going to have to programmatically set a property on a file share to allow access-based enumeration.

This property is an attribute of the NetShareSetInfo application programming interface (API). Check out for more information about the NetShareSetInfo API set.

Key Takeaways

In Windows Server 2003 Service Pack 1, Microsoft has incorporated a set of security technologies that helps reduce the attack surface of Windows Server systems and ease the administrative tasks associated with configuring server security.

Information security is a defense in depth strategy, and we should always assume that previous layers will fail.

Defending the host with the centrally controlled Microsoft Firewall, hardening the servers based on roles, hardening the RPC and DCOM protocols, and putting remote clients into quarantine until they are checked, all these and more help better defend our servers from dA bAd gUyz!

For More Information

For more information, see the following links:

Windows Server 2003 Service Pack 1

Windows Server 2003 Service Pack 1 Product Overview Guide

Microsoft Network Access Protection

For a list and additional information on all Professor Windows columns, click here .

For any feedback regarding the content of this column, please write to Microsoft TechNet . Please be aware that this is not a technical support alias and a response is not guaranteed.