Chapter 2: Windows Server 2003 Hardening Mechanisms

Published: December 31, 2003   |   Updated: April 26, 2006

Overview

This chapter introduces the mechanisms that can be used to implement security settings on Microsoft® Windows Server™ 2003. Service Pack 1 (SP1) of Windows Server 2003 provides the Security Configuration Wizard (SCW), a new role-based tool you can use to make your servers more secure. When used in conjunction with Group Policy objects (GPOs), SCW allows greater control, flexibility, and consistency in the hardening process.

This chapter focuses on the following topics:

  • How SCW is used to create, test, and deploy role-based hardening policies.
  • How the Active Directory® directory service facilitates consistent enterprise hardening through the use of GPOs.
  • How the Active Directory domain design, the organizational unit (OU) design, Group Policy design, and administrative group design affect security deployments.
  • How to use both SCW and Group Policy to create a manageable, role-based approach to harden servers that run Windows Server 2003 with SP1.

This information provides a foundation and a vision that you can use to evolve from a Legacy Client (LC) environment to a Specialized Security – Limited Functionality (SSLF) environment within a domain infrastructure.

Hardening with the Security Configuration Wizard

The purpose of SCW is to provide a flexible, step-by-step process to reduce the attack surface on servers that run Windows Server 2003 with SP1. SCW is actually a collection of tools that is combined with an XML rules database. Its purpose is to help administrators quickly and accurately determine the minimum functionality that is required for the roles that specific servers must fulfill.

With SCW, administrators can author, test, troubleshoot, and deploy security policies that disable all non-essential functionality. It also provides the ability to roll back security policies. SCW provides native support for security policy management on single servers as well as groups of servers that share related functionality.

SCW is a comprehensive tool that can help you accomplish the following tasks:

  • Determine which services must be active, which services need to run when required, and which services can be disabled.
  • Manage network port filtering in combination with Windows Firewall.
  • Control which IIS Web extensions are allowed for Web servers.
  • Reduce protocol exposure to the server message block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Lightweight Directory Access Protocol (LDAP).
  • Create useful Audit policies that capture the events of interest.

Detailed instructions about how to install, use, and troubleshoot SCW are available in a downloadable version of the Security Configuration Wizard Documentation at www.microsoft.com/downloads/details.aspx?FamilyID=903fd496-9eb9-4a45-aa00-3f2f20fd6171&displaylang=en.

Note: SCW can only be used with Windows Server 2003 with SP1. It cannot be used to create policies for Windows 2000 Server, Windows XP, or Windows Small Business Server 2003. To harden significant numbers of computers that run these operating systems, you will need to take advantage of the Group Policy–based hardening mechanisms described later in this chapter.

Creating and Testing Policies

You can use SCW to rapidly create and test security policies for multiple servers or groups of servers from a single computer. This capability allows you to manage policies throughout the enterprise from a single location. These policies provide consistent, supported hardening measures that are appropriate for the functions that each server provides within the organization. If you use SCW to create and test policies, you should deploy SCW to all targeted servers. Although you create the policy on a management station, SCW will attempt to communicate with the target servers to inspect their configuration and fine-tune the resulting policy.

SCW is integrated with the IPsec and Windows Firewall subsystems and will modify those settings accordingly. Unless prevented, SCW will configure the Windows Firewall to permit inbound network traffic to important ports that are required by the operating system as well as listening applications. If additional port filters are required, SCW can create them. As a result, policies that are created by SCW address the need for custom scripts to set or modify IPsec filters to block unwanted traffic. This capability simplifies the management of network hardening. The configuration of network filters for services that make use of RPC or dynamic ports can also be simplified.

SCW also provides the capability to significantly customize the policies that you create. This flexibility helps you create a configuration that permits necessary functionality but also helps to reduce security risks. In addition to the baseline behaviors and settings, you can override SCW in the following areas:

  • Services
  • Network ports
  • Windows Firewall-approved applications
  • Registry settings
  • IIS settings
  • Inclusion of pre-existing security templates (.inf files)

SCW advises the administrator about some of the most important registry settings. To reduce the complexity of the tool, the designers chose to only include those settings that have the greatest impacts on security. However, this guide discusses many more registry settings. To overcome the limitations of SCW, you can combine security templates with the results of SCW to create a more complete configuration.

When you use SCW to create a new policy, it uses the current configuration of a server as an initial configuration. Therefore, you should target a server of the same type as the servers on which you intend to deploy the policy so that you can accurately describe the configuration of the server's roles. When you use the SCW graphical user interface (GUI) to create a new policy, it creates an XML file and saves it in the %systemdir%\security\msscw\Policies folder by default. After you create your policies, you can use either the SCW GUI or the Scwcmd command-line tool to apply the policies to your test servers.

When you test the policies, you may need to remove a policy that you deployed. You can use either the GUI or the command-line tool to roll back the last policy you applied to a server or group of servers. SCW saves the previous configuration settings in XML files.

For organizations that have limited resources to design and test security configurations, SCW may be sufficient. Those organizations that lack such resources should not even attempt to harden servers, because such efforts often result in unexpected problems and lost productivity. If your organization does not have the expertise and time available to deal with these types of issues, then you should focus on other important security activities such as application and operating system upgrades to current versions and update management.

Deploying Policies

There are three different options you can use to deploy your policies:

  • Apply the policy with the SCW GUI
  • Apply the policy with the Scwcmd command-line tool
  • Convert the SCW policy to a Group Policy object and link it to a domain or OU

Each option has its own advantages and drawbacks, which are described in the following subsections.

Apply the Policy with the SCW GUI

The main advantage of the SCW GUI option is simplicity. The GUI permits administrators to easily select a predefined policy and apply it to a single computer.

The disadvantage of the SCW GUI option is that it only permits application of policies to a single computer at a time. This option does not scale for large environments, and this guide does not use this method.

Apply the Policy with the Scwcmd Command-line Tool

One way to apply native SCW policies to multiple computers without Active Directory is to use the Scwcmd tool. You can also combine the use of Scwcmd with scripting technologies to provide a degree of automated policy deployment, perhaps as part of an existing process that is used to build and deploy servers.

The main disadvantage of the Scwcmd option is that it is not automatic. You have to specify the policy and target server, either manually or through some scripting solution, which means there are multiple chances to push the wrong policy to the wrong computer. If you have servers in a group with slightly different configurations, you will need to craft a separate policy for each of those computers and apply them separately. Because of these limitations, this guide does not use this method.

Convert the SCW Policy to a Group Policy Object

The third option for SCW policy deployment is to use the Scwcmd tool to convert the XML-based policy into a Group Policy object (GPO). Although at first this conversion might seem to be an unnecessary step, its advantages include the following:

  • Policies are replicated, deployed, and applied with familiar Active Directory–based mechanisms.
  • Because they are native GPOs, policies can be used with OUs, policy inheritance, and incremental policies to fine-tune the hardening of servers that are configured similarly but not exactly the same as other servers. With Group Policy, you put these servers in a child OU and apply an incremental policy, whereas with SCW you would need to create a new policy for each unique configuration.
  • Policies are automatically applied to all servers that are placed in the corresponding OUs. Native SCW policies must be either manually applied or used in conjunction with some custom scripting solution.

Hardening Servers with Active Directory Group Policy

Active Directory enables applications to find, use, and manage directory resources in a distributed computing environment. Although detailed information about how to design an Active Directory infrastructure could fill an entire book, this section briefly discusses these concepts to establish a context for the rest of the guide. This design information is necessary to provide insight into the use of Group Policy to securely administer your organization's domains, domain controllers, and specific server roles. If your organization already has an Active Directory design, this chapter may provide insight into some of its security benefits or potential issues.

This guide does not offer any specific guidance about how to secure the Active Directory database. For such guidance, see the "Best Practice Guide for Securing Active Directory Installations" at www.microsoft.com/downloads/details.aspx?FamilyID=4e734065-3f18-488a-be1e-f03390ec5f91&.

When you create an Active Directory infrastructure, you must carefully consider the environment's security boundaries. If you adequately plan an organization's security delegation and implementation schedule, the result will be a more secure Active Directory design for the organization. You should only need to restructure the design for major changes to the environment, such as an acquisition or reorganization.

Active Directory Boundaries

There are several different types of boundaries within Active Directory. These boundaries define the forest, the domain, the site topology, and permission delegation, and they are automatically established when you install Active Directory. However, you must ensure that permission boundaries incorporate organizational requirements and policies. Administrative permissions delegation can be quite flexible to accommodate different organizations' requirements. For example, to maintain a proper balance between security and administrative functionality, you can divide the permission delegation boundaries between security boundaries and administrative boundaries.

Security Boundaries

Security boundaries help define the autonomy or isolation of different groups within an organization. It is difficult to balance the tradeoffs between adequate security (based on how the organization’s business boundaries are established) and the need to maintain a consistent level of base functionality. To successfully achieve this balance, you must weigh the threats to your organization against the security implications of delegated administration permissions and other choices that involve your environment's network architecture.

The forest is the true security boundary of your network environment. This guide recommends that you create separate forests to keep your environment secure from potential compromise by administrators of other domains. This approach also helps ensure that the compromise of one forest does not automatically lead to the compromise of the entire enterprise.

A domain is a management boundary of Active Directory, not a security boundary. With an organization of well-intentioned individuals, a domain boundary will provide autonomous management of services and data within each domain of the organization. Unfortunately, with regard to security, isolation is not so simple to achieve. A domain, for example, will not completely isolate an attack from a rogue domain administrator. This level of separation can only be achieved at the forest level.

Within the domain, the organizational unit (OU) provides another level of management boundary. OUs provide a flexible way to group related resources and delegate management access to the appropriate personnel without providing them the ability to manage the entire domain. Like domains, OUs are not a true security boundary. Although you can assign permissions to an OU, all OUs in the same domain authenticate resources against the domain and forest resources. Still, a well-designed OU hierarchy will aid the development, deployment, and management of effective security measures.

Your organization may need to consider divided administrative control of services and data within the current Active Directory design. Effective Active Directory design requires that you completely understand your organization's requirements for service autonomy and isolation as well as for data autonomy and isolation.

Administrative Boundaries

Because of the potential need to segment services and data, you must define the different administration levels that are required. In addition to administrators who may perform unique services for your organization, this guidance recommends that you consider the following types of administrators.

Service Administrators

Active Directory service administrators are responsible for the configuration and delivery of the directory service. For example, service administrators maintain domain controller servers, control directory-wide configuration settings, and ensure service availability. You should consider the Active Directory administrators in your organization to be your service administrators.

The Active Directory service configuration is often determined by attribute values. These attribute values correspond to settings for their respective objects, which are stored in the directory. Consequently, service administrators in Active Directory are also data administrators. Your organizational needs may require you to consider other service administrator groups for your Active Directory service design. Some examples include:

  • A domain administration group that is primarily responsible for directory services.The forest administrator chooses the group to administer each domain. Because of the high-level access that is granted to the administrator for each domain, these administrators should be highly trusted individuals. The domain administrators control the domains through the Domain Administrators group and other built-in groups.
  • Groups of administrators who manage DNS.The DNS administrator group completes the DNS design and manages the DNS infrastructure. The DNS administrator manages the DNS infrastructure through the DNS Administrators group.
  • Groups of administrators who manage OUs.The OU administrator designates a group or individual as a manager for each OU. Each OU administrator manages the data that is stored within the assigned Active Directory OU. These groups can control how administration is delegated, and how policy is applied to objects within their OUs. OU administrators can also create new subtrees and delegate administration of the OUs for which they are responsible.
  • Groups of administrators who manage infrastructure servers.The group that is responsible for infrastructure server administration manages WINS, DHCP, and potentially the DNS infrastructure. In some cases, the group that handles domain management will manage the DNS infrastructure because Active Directory is integrated with DNS and is stored and managed on the domain controllers.

Data Administrators

Active Directory data administrators manage data that is stored in Active Directory or on computers that are joined to Active Directory. These administrators have no control over the configuration or delivery of the directory service. Data administrators are members of a security group that is created by your organization. Sometimes the default security groups in Windows do not make sense for all situations in the organization. Therefore, organizations can develop their own security group naming standards and meanings to best fit their environment. Some of the data administrators' daily tasks include:

  • Control a subset of objects in the directory. Through inheritable attribute-level access control, data administrators can be granted control of very specific sections of the directory but no control over the configuration of the service itself.
  • Manage member computers in the directory and the data that is on those computers.

Note: In many cases, attribute values for objects that are stored in the directory determine the directory's service configuration.

To summarize, before the owners of Active Directory service and directory structures are allowed to join a forest or domain infrastructure, the organization must trust all service administrators in the forest and all domains. Also, enterprise security programs must develop standard policies and procedures that perform appropriate background checks for the administrators. In the context of this security guide, to trust service administrators means to:

  • Reasonably believe that service administrators will primarily concern themselves with the organization's best interests. Organizations should not elect to join a forest or domain if the owners of that forest or domain might have legitimate reasons to act maliciously against the organization.
  • Reasonably believe that service administrators will follow best practices and restrict physical access to the domain controllers.
  • Understand and accept the risks to the organization that include the possibility for:
    • Rogue administrators. Trusted administrators might become rogue administrators and abuse the privileges they have on the network. A rogue administrator within a forest could easily look up the security identifier (SID) for another administrator from another domain. The rogue administrator could then use an application programming interface (API) tool, disk editor, or debugger to add the stolen SID to the SID History list of an account within their own domain. With the stolen SID added to the user's SID History, the rogue administrator would have administrative privileges in the stolen SID's domain as well as their own domain.
    • Coerced administrators. A trusted administrator might be coerced or compelled to perform operations that breach the security of a computer or the network. A user or administrator may use social engineering techniques or threats of physical or other harm on legitimate administrators of a computer to obtain the information that is needed to gain access to the computer.

Some organizations might accept the risk of a security breach by a rogue or a coerced service administrator from another part of the organization. Such organizations might determine that the collaborative and cost-saving benefit of participating in a shared infrastructure outweighs this risk. However, other organizations might not accept the risk because the potential consequences of a security breach are too severe.

Active Directory and Group Policy

Although OUs offer an easy way to group computers, users, groups, and other security principals, they also provide an effective way to segment administrative boundaries. Additionally, OUs provide a crucial structure for the deployment of Group Policy objects (GPOs) because they can segment resources by security need and allow you to provide different security to different OUs. The use of OUs to manage and assign security policies based on server role is an integral piece of the overall security architecture for the organization.

Delegating Administration and Applying Group Policy

OUs are containers within the directory structure of a domain. These containers can hold any security principal in the domain, although they are usually used to hold objects of one specific type. To grant or revoke OU access permissions to a group or individual user, you can set specific access control lists (ACLs) on the OU and the permissions will be inherited by all of the objects within the OU.

You can use an OU to provide role-based administrative capabilities. For example, one group of administrators could be responsible for the user and group OUs while another group could manage the OUs that contain the servers. You can also create an OU to contain a group of resource servers to be administered by other users through a process called delegation of control. This approach provides the delegated group with autonomous control over a particular OU but does not isolate them from the remainder of the domain.

Administrators that delegate control over specific OUs are likely to be service administrators. At a lower level of authority, users that control the OUs are usually data administrators.

Administrative Groups

Administrators can create administrative groups to segment clusters of users, security groups, or servers into containers for autonomous administration.

For example, consider the infrastructure servers that reside in a domain. Infrastructure servers include all of the non-domain controllers that run basic network services, including servers that provide WINS and DHCP services. Oftentimes an operations group or an infrastructure administration group maintains these servers. You can use an OU to easily provide administrative capabilities to these servers.

The following illustration provides a high-level view of such an OU configuration.

 

Figure 2.1 OU delegation of administration

Figure 2.1 OU delegation of administration

 

When the Infrastructure Admin group is delegated control of the Infrastructure OU, the members of this group will have full control of the Infrastructure OU and all servers and objects within the OU. This capability allows members of the group to secure the server roles with Group Policy.

This approach is only one way that OUs can be used to provide administrative segmentation. For more complex organizations, see the "More Information" section at the end of this chapter.

Note: Because Active Directory depends so heavily on DNS, it is common practice to run the DNS service on domain controllers. Domain controllers are placed in the built-in Domain Controllers OU by default. The examples in this guide follow this practice, so the infrastructure server role does not include the DNS service.

Group Policy Application

Use Group Policy and delegate administration to apply specific settings, rights, and behavior to all servers within an OU. When you use Group Policy instead of manual steps, it is simple to update multiple servers with any additional changes that might be required.

Group Policies are accumulated and applied in the order that is shown in the following illustration.

 

Figure 2.2 GPO application hierarchy

Figure 2.2 GPO application hierarchy

See full-sized image

 

As seen in the illustration, policies are applied first at the local policy level of the computer. After that, any GPOs are applied at the site level, and then at the domain level. If the server is nested in several OUs, GPOs that exist at the highest level OU are applied first. The GPO application process continues down the OU hierarchy. The final GPO to be applied is at the child OU level that contains the server object. The order of precedence for processing Group Policy extends from the highest OU (farthest from the user or computer account) to the lowest OU (the one that actually contains the user or computer account).

Remember the following basic considerations when you apply Group Policy:

  • You must set the GPO application order for Group Policy levels with multiple GPOs. If multiple policies specify the same option, the last one that is applied will take precedence.
  • You must configure a Group Policy with the No Override option if you do not want other GPOs to override it. If you use the Group Policy Management Console (GPMC) to manage your GPOs, the name of this option is Enforced.

Time Configuration

Many security services, especially authentication, rely on an accurate computer clock to perform their jobs. You should ensure computer time is accurate and that all servers in your organization use the same time source. The Windows Server 2003 W32Time service provides time synchronization for Windows Server 2003 and Microsoft Windows XP–based computers that run in an Active Directory domain.

The W32Time service synchronizes the clocks of Windows Server 2003–based computers with the domain controllers in a domain. This synchronization is necessary for the Kerberos protocol and other authentication protocols to work properly. To function correctly, a number of Windows Server family components rely on accurate and synchronized time. If the clocks are not synchronized on the clients, the Kerberos authentication protocol might deny access to users.

Another important benefit that time synchronization provides is event correlation on all of the clients in your enterprise. Synchronized clocks on the clients in your environment ensure that you can correctly analyze events that take place in uniform sequence on those clients throughout the organization.

The W32Time service uses the Network Time Protocol (NTP) to synchronize clocks on computers that run Windows Server 2003. In a Windows Server 2003 forest, time is synchronized by default in the following manner:

  • The primary domain controller (PDC) emulator operations master in the forest root domain is the authoritative time source for the organization.
  • All PDC operation masters in other domains in the forest follow the hierarchy of domains when they select a PDC emulator with which to synchronize their time.
  • All domain controllers in a domain synchronize their time with the PDC emulator operations master in their domain as their inbound time partner.
  • All member servers and client desktop computers use the authenticating domain controller as their inbound time partner.

To ensure that the time is accurate, the PDC emulator in the forest root domain can be synchronized to an authoritative time source, such as a reliable NTP source or a highly accurate clock on your network. Note that NTP synchronization uses UDP port 123 traffic. Before you synchronize with an external server, you should weigh the benefits of opening this port against the potential security risk.

Also, if you synchronize with an external server that you do not control, you risk configuring your servers with the incorrect time. The external server could be compromised or spoofed by an attacker to maliciously manipulate the clocks on your computers. As explained earlier, the Kerberos authentication protocol requires synchronized computer clocks. If they are not synchronized, a denial of service may occur.

Security Template Management

Security templates are text–based files that you can use to apply a security configuration to a computer. You can modify security templates with the Microsoft Management Console (MMC) Security Templates snap-in or with a text editor such as Notepad. Some sections of the template files contain specific ACLs that are written in the Security Descriptor Definition Language (SDDL). You can find more information about how to edit security templates and SDDL on the "Security Descriptor Definition Language" page on Microsoft MSDN® at https://msdn2.microsoft.com/en-us/library/Aa379567.

By default, authenticated users have the right to read all settings in a Group Policy object. Therefore, it is very important to store security templates for a production environment in a secure location that only administrators who implement Group Policy can access. The purpose is not to prevent *.inf files from being viewed, but rather to prevent unauthorized changes to the source security templates.

All computers that run Windows Server 2003 store security templates in their local %SystemRoot%\security\templates folder. This folder is not replicated across multiple domain controllers, so you will need to designate one location to hold the master copy of the security templates to prevent version control problems with the templates. After the centrally-located template is modified, it can be redeployed to the appropriate computers. This approach will ensure that you always modify the same copy of the templates.

Successful GPO Application Events

Although an administrator can manually check all of the settings to ensure that they have been appropriately applied to the servers in your organization, an event should also appear in the event log to inform the administrator that the domain policy was successfully downloaded to each of the servers. An event similar to the following should display in the Application log with its own unique Event ID number:

Type: Information

Source ID: SceCli

Event ID: 1704

Description: Security policy in the Group Policy objects has been applied successfully.

By default, the security settings are refreshed every 90 minutes on a workstation or server and every 5 minutes on a domain controller. You will see this type of event if any changes occurred during these intervals. Also, the settings are refreshed every 16 hours, regardless of whether any changes were made. You can also manually force Group Policy settings to update using the procedure that is described later in this chapter.

Sever Role Organizational Units

The previous example showed a way to manage an organization's infrastructure servers. This method can be extended to encompass other servers and services in an organization. The goals are to create a seamless Group Policy for all servers and to ensure that the servers that reside within Active Directory meet the security standards for your environment.

This type of Group Policy forms a consistent baseline of standard settings for all of the servers in your organization. Also, the OU structure and the application of Group Policies must provide a detailed design to provide security settings for specific types of servers in an organization. For example, Internet Information Server (IIS), file, print, Internet Authentication Server (IAS), and Certificate Services are a few of the server roles in an organization that may require unique Group Policies.

Important: For simplicity, the examples in this chapter assume the use of the Enterprise Client environment. If you use one of the other two environments, substitute the appropriate file names. The differences between the three environments and their functionality are discussed in Chapter 1, "Introduction to the Windows Server 2003 Security Guide."

Member Server Baseline Policy

The first step in the establishment of server role OUs is to create a baseline policy. To create such a policy, you can use SCW on a standard member server to create a Member Servers Baseline.xml file. As part of the XML creation, use SCW to include one of the supplied Member Server Baseline security templates (LC-Member Server Baseline.inf, EC-Member Server Baseline.inf, or SSLF-Member Server Baseline.inf).

After you generate the SCW policy, it is converted into a GPO and linked with the Member Servers OU. This new baseline GPO will apply the settings of the baseline Group Policy to any servers in the Member Servers OU, as well as any servers in child OUs. The Member Server Baseline Policy is discussed in Chapter 4, "The Member Server Baseline Policy."

You should define the desired settings for most of the servers in your organization in the baseline Group Policy. Although there may be some servers that should not receive the baseline policy, these should not be many. If you create your own baseline Group Policy, make it as restrictive as possible and segment any servers that need to differ from this policy into separate server-specific OUs.

Server Role Types and Organizational Units

Each identified server role requires an additional SCW policy, security template, and OU in addition to the baseline OU. This approach permits the creation of separate policies for the incremental changes that are required by each role.

In a previous example, the infrastructure servers were placed into the Infrastructure OU, which is a child of the Member Servers OU. The next step is to apply the appropriate configuration to these servers. Three security templates are provided with this solution, one for each security environment: LC-Infrastructure Server.inf, EC-Infrastructure Server.inf, and SSLF-Infrastructure Server.inf. When used together with SCW, these security templates will help you create a security policy that contains the specific adjustments that are required by DHCP and WINS. The resultant policy is then converted into a new GPO and linked to the Infrastructure OU.

This GPO uses the Restricted Groups setting to add the following three groups to the Local Administrators group of all servers in the Infrastructure OU:

  • Domain Administrators
  • Enterprise Administrators
  • Infrastructure Administrators

As mentioned earlier in this chapter, this approach is only one of many ways to create an OU structure that you can use to deploy GPOs. For more information about how to create OUs for Group Policy implementation, see "Designing the Active Directory Structure" and related topics at www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/deploy/dgbd_ads_heqs.mspx.

The following table lists the Windows Server 2003 server roles and corresponding template files that are defined in this guide. The security template file names are prefixed with the

All template files except those for the bastion host servers are applied to the corresponding child OUs. Each of these child OUs require that you apply the specific configuration to define the role that each computer will fulfill in the organization.

The security requirements for each of these server roles are different. Appropriate security settings for each role are discussed in detail in later chapters. Note that not all roles have templates that correspond to all environments. For example, the bastion host role is always considered to be in the SSLF environment.

Important: This guide assumes that computers that run Windows Server 2003 will perform specifically defined roles. If the servers in your organization do not match these roles, or if you have multipurpose servers, use the settings that are defined here as guidelines for your own security templates. However, remember that the more functions that each of your servers perform, the more vulnerable they are to attack.

An example of the final OU design to support these defined server roles in the EC environment is shown in the following illustration.

 

Figure 2.3 OU design example

Figure 2.3 OU design example

See full-sized image

 

OU, GPO, and Group Design

The recommended OUs and policies that were discussed in the previous section create a baseline or new environment to restructure an organization's existing OU structure for computers that run Windows Server 2003. Administrators use their predefined administration boundaries to create their respective administrative groups. An example of the correlation of these groups to the OUs they manage is shown in the following table.

Table 2.2 OUs and Administrative Groups

OU name Administrative group

Domain Controllers

Domain Engineering

Member Servers

Domain Engineering

Infrastructure

Infrastructure Admins

File

Infrastructure Admins

Print

Infrastructure Admins

IAS

Domain Engineering

Web

Web Services

CA

Enterprise Administrators

Each administrative group was created as a global group within the domain by the Domain Engineering members, who are responsible for Active Directory infrastructure and security. They used the corresponding GPO to add each of these administrative groups to the appropriate restricted group. The administrative groups that are listed in the table will only be members of the Local Administrators group for the computers that are located in the OUs that specifically contain computers that are related to their job functions.

Finally, the Domain Engineering members set permissions on each GPO so that only administrators in their group are able to edit them.

Note that the creation and configuration of these groups is a part of your overall Active Directory design and implementation process. It is not part of this guide.

Process Overview

This guide combines the strengths of the SCW-based and Group Policy-based approaches. This hybrid approach allows you to create and test security configurations more easily, but still provides the flexibility and scalability that is required in large Windows networks.

The process that is used to create, test, and deploy the policies is as follows:

  1. Create the Active Directory environment, including groups and OUs. You should create the appropriate administrative groups and delegate OU permissions to the corresponding groups.
  2. Configure time synchronization on the domain controller that hosts the PDC Emulator FSMO.
  3. Configure the domain policies.
  4. Create the baseline policies with SCW.
  5. Test the baseline policies with SCW.
  6. Convert the baseline policies to GPOs and link them to the appropriate GPOs.
  7. Create the role policies with SCW and the included security templates.
  8. Test the role policies with SCW.
  9. Convert the role policies to GPOs and link them to the appropriate GPOs.

The following sections describe these steps in greater detail.

Note: For simplicity, the examples in this section assume the use of the Enterprise Client (EC) environment. If you use one of the other two environments, substitute the appropriate file names. The differences between the three environments and their functionality are discussed in Chapter 1, "Introduction to the Windows Server 2003 Security Guide."

Create the Active Directory Environment

Before you can begin the hardening process, you must have an appropriate Active Directory domain and OU structure in place. The following procedure lists the steps that you will use to create the OUs and groups that are used in this guide and configure them for the appropriate administrative access.

  1. Open the MMC Active Directory Users Computers snap-in (Dsa.msc).
  2. In the root of the domain object, create an OU called Member Servers.
  3. Navigate to this new OU and create a child OU within it called Infrastructure.
  4. Move all WINS and DHCP servers into the Infrastructure OU.
  5. Create a global security group called Infrastructure Admins and add the appropriate domain accounts to it.
  6. Run the Delegation of Control Wizard to provide the Infrastructure Admins group with Full Control of the OU.
  7. Repeat steps 3 through 6 for the file server, print server, web server, IAS server, and Certificate Services server roles. Use the information in Table 2.2 for the appropriate OU and group names.

Configure Time Synchronization

The following procedure ensures that the domain controllers and member servers are synchronized with an external time source. This synchronization will help ensure that Kerberos authentication works properly and allow you to keep your Active Directory domain synchronized with any external computers that you may have.

  1. On the domain controller with the PDC Emulator FSMO, open a command prompt and execute the following command, where
    w32tm /config /syncfromflags:manual /manualpeerlist:<i><PeerList></i>
    
  2. To update the configuration, execute the following command:
    w32tm /config /update
    
  3. Check the event log. If the computer cannot reach the servers, the procedure will fail and an entry will be written to the event log.

The most common use of this procedure is to synchronize the internal network's authoritative time source with a very precise external time source. However, this procedure can be run on any computer that runs Windows XP or member of the Windows Server 2003 family. It is not usually necessary to synchronize all servers' time clocks with an external source if they are synchronized with the same internal source. By default, member computers always synchronize their clocks with domain controllers.

Note: For accurate log analysis, you should also synchronize the clocks of network computers that run operating systems other than Windows to the Windows Server 2003 PDC emulator or to the same time source for that server.

Configure the Domain Policy

The following procedure imports the security templates that are provided with this guide for the domain-level policy. This policy is provided as a security template, because SCW does not address domain-level policies. Before you implement the following procedure, the specific policy (.inf) file must be located on your computer.

Warning: The security templates in this guide are designed to increase security in your environment. It is quite possible that their installation could cause some functionality in your environment to be lost, and mission critical applications could fail. It is essential that you thoroughly test these settings before you deploy them in a production environment. Back up each domain controller and server in your environment before you apply any new security settings. Ensure the system state is included in the backup, which will enable registry settings and Active Directory objects to be restored if necessary.

To import the Domain Policy security templates

  1. In Active Directory Users and Computers, right-click the domain, and then select Properties.
  2. On the Group Policy tab, click New to add a new GPO.
  3. Type EC-Domain Policy, and then press ENTER.
  4. Right-click EC-Domain Policy, and then select No Override.
  5. Select EC-Domain Policy, and then click Edit.
  6. In the Group Policy Object Editor window, click Computer Configuration\Windows Settings. Right-click Security Settings, and then select Import Policy.
  7. In the Import Policy From dialog box, navigate to "\Tools and Templates\Security Guide\Security Templates" and then double-click EC-Domain.inf.
  8. Close the Group Policy that has been modified.
  9. Close the Domain Properties window.
  10. If you do not want to wait for scheduled Group Policy application, you can initiate the process manually. Open a command prompt, type gpupdate /Force and press ENTER.
  11. Verify in the event log that the Group Policy downloaded successfully and that the server can communicate with the other domain controllers in the domain.

Warning: When you create the EC-Domain Policy, ensure that the No Override option is enabled to enforce this policy throughout the domain. This Group Policy is the only one in this guide in which the No Override option must be enabled. Do not enable this option in any of the other Group Policies that are specified in this guide. Also, do not modify the Windows Server 2003 default domain policy—in case you need to return to its default settings.

To ensure that this new Group Policy has precedence over the default policy, position it to have the highest priority among the GPO links.

Important: You should import this Group Policy into any additional domains in the organization to ensure consistent application of password policy. However, it is not uncommon to find environments in which the root domain password policy is much stricter than any of the other domains. You should also ensure that any other domains that will use this same policy have the same business requirements. Because the password policy can only be set at the domain level, there may be business or legal requirements that segment some users into a separate domain simply to enforce the use of a stricter password policy on that group.

To clear the Allow Inheritable Permissions option

By default, the new OU structure inherits many security settings from its parent container. For each OU, clear the check box for Allow inheritable permissions from parent to propagate to this object and all child objects.

  1. Open Active Directory Users and Computers.
  2. Click View and then Advanced Features to select the Advanced view.
  3. Right-click the appropriate OU, and then click Properties.
  4. Click the Security tab, and then click Advanced.
  5. Clear the Allow inheritable permissions from parent to propagate to this object and all child objects. Include these with entries specifically defined here checkbox.

Remove any unnecessary groups that were previously added by administrators, and add the domain group that corresponds to each server role OU. Retain the Full Control setting for the Domain Administrators group.

Create the Baseline Policies Manually Using SCW

The next step is to use SCW to create the member server baseline policy.

You should use a new installation of the operating system to begin your configuration work, which helps ensure that there are no legacy settings or software from previous configurations. If possible, you should use hardware that is similar to the hardware that you will use in your deployment, which will help ensure as much compatibility as possible. The new installation is called a reference computer.

During the member server baseline policy (MSBP) creation steps, note that you remove the File server role from the list of detected roles. This role is commonly configured on servers that do not require it and could be considered a security risk. To enable the File server role for servers that require it, you can apply a second policy later in this process.

To create the Member Server Baseline Policy

  1. Create a new installation of Windows Server 2003 with SP1 on a new reference computer.
  2. Install the Security Configuration Wizard component on the computer through Control Panel, Add/Remove Programs, Add/Remove Windows Components.
  3. Join the computer to the domain.
  4. Install only the mandatory applications that should be on every server in your environment. Examples include your software and management agents, tape backup agents, and antivirus or antispyware utilities.
  5. Launch SCW, select Create new policy, and point it to the reference computer.
  6. Remove the File server role from the listed of detected roles.
  7. Ensure that the detected client features are appropriate for your environment.
  8. Ensure that the detected administrative options are appropriate for your environment.
  9. Ensure that any additional services that required by your baseline, such as backup agents or antivirus software, are detected.
  10. Decide how to handle unspecified services in your environment. For extra security, you may wish to configure this setting to Disable. You should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer.
  11. Review the network settings and ensure that the appropriate ports and applications have been detected and will be configured as exceptions for the Windows Firewall.
  12. Skip the "Registry Settings" section.
  13. Skip the "Audit Policy" section.
  14. Include the appropriate security template (for example, EC-Member Server Baseline.inf).
  15. Save the policy with an appropriate name (for example, Member Server Baseline.xml).

To create the Domain Controller policy

You must use a computer that is configured as a domain controller to create the Domain Controller policy. You can use either an existing domain controller or create a reference computer and use the Dcpromo tool to make the computer a domain controller. However, most organizations do not want to add a domain controller to their production environment because it may violate their security policy. If you use an existing domain controller, make sure that you do not apply any setting to it with SCW or modify its configuration.

  1. Install the Security Configuration Wizard component on the computer through Control Panel, Add/Remove Programs, Add/Remove Windows Components.
  2. Install only the mandatory applications that should be on every server in your environment. Examples include your software and management agents, tape backup agents, and antivirus or antispyware utilities.
  3. Launch the SCW GUI, select Create new policy, and point it to the reference computer.
  4. Ensure that the detected roles are appropriate for your environment.
  5. Ensure that the detected client features are appropriate for your environment.
  6. Ensure that the detected administrative options are appropriate for your environment.
  7. Ensure that any additional services that are required by your baseline, such as backup agents or antivirus software, are detected.
  8. Decide how to handle unspecified services in your environment. For extra security, you may wish to configure this policy setting to Disable. You should test this configuration before you deploy it to your production network, because it may cause problems if your production servers run additional services that are not duplicated on your reference computer.
  9. Review the network settings and ensure that the appropriate ports and applications have been detected and will be configured as exceptions for the Windows Firewall.
  10. Skip the "Registry Settings" section.
  11. Skip the "Audit Policy" section.
  12. Include the appropriate security template (for example, EC-Domain Controller.inf).
  13. Save the policy with an appropriate name (for example, Domain Controller.xml).

Test the Baseline Policies Using SCW

After you create and save the baseline policies, Microsoft strongly recommends that you deploy them to your test environment. Ideally, your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fix potential problems, such as the presence of unexpected services that are required by specific hardware devices.

Two options are available to test the policies. You can use the native SCW deployment facilities, or deploy the policies through a GPO.

When you start to author your policies, you should consider using the native SCW deployment facilities. You can use SCW to push policies to a single server at a time, or use Scwcmd to push them to a group of servers. The native deployment method offers the advantage of the ability to easily roll back deployed policies from within SCW. This capability can be very useful when you make multiple changes to your policies during the testing process.

The policies are tested to ensure that their application to the target servers will not adversely affect their critical functions. After you apply the configuration changes, you should begin to verify the core functionality of the computer. For example, if the server is configured as a certification authority (CA), ensure that clients can request and obtain certificates, download a certificate revocation list, and so on.

When you are confident in your policy configurations, you can use Scwcmd as shown in the following procedure to convert the policies to GPOs.

For more detailed information about how to test SCW policies, see "Deployment Guide for the Security Configuration Wizard" at https://technet2.microsoft.com/WindowsServer/en/Library/5254f8cd-143e-4559-a299-9c723b3669461033.mspx and the downloadable version of the Security Configuration Wizard Documentation at https://go.microsoft.com/fwlink/?linkid=43450.

Convert the Baseline Policies to GPOs

After you thoroughly test the baseline policies, complete the following steps to convert them into GPOs and link them to the appropriate OUs:

  1. At a command prompt, type the following:
    scwcmd transform /p:<i><PathToPolicy.xml> </i>/g:<i><GPODisplayName></i>
    

    and then press ENTER. For example:Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

        scwcmd transform /p:"C:\Windows\Security\msscw\Policies\
        Infrastructure.xml" /g:"Infrastructure Policy"
    

    Note: The information to be entered at the command prompt shows on more than one line here because of display limitations. This information should all be entered on one line.

  2. Use the Group Policy Management Console to link the newly created GPO to the appropriate OU.

Note that if the SCW security policy file contains Windows Firewall settings, Windows Firewall must be active on the local computer for this procedure to complete successfully. To verify that Windows Firewall is active, open Control Panel and then double-click Windows Firewall.

You should now perform a final test to ensure that the GPO applies the desired settings. To complete this procedure, confirm that the appropriate settings were made and that functionality is not affected.

Create the Role Policies Using SCW

The next step is to use SCW to create the role policies for each server role.

The steps to create the role-specific policies are similar to the steps you followed when you created the MSBP. You should once again use a reference computer to help ensure that there are no legacy settings or software from previous configurations.

To create the role policies

  1. Create a new installation of Windows Server 2003 with SP1 on a new reference computer.
  2. Install the Security Configuration Wizard component on the computer through Control Panel, Add/Remove Programs, Add/Remove Windows Components.
  3. Join the new server to the domain.
  4. Install the mandatory applications that should be on every server in your environment. Examples include your software and management agents, tape backup agents, and antivirus or antispyware utilities.
  5. Configure the appropriate roles for the computer. For example, if your target servers will run DHCP and WINS, install those components. They do not need to be configured exactly the same as the deployed servers, but the roles must be installed.
  6. Launch SCW.
  7. Select Create new policy and point it to the reference computer.
  8. Ensure that the detected roles are appropriate for your environment.
  9. Ensure that the detected client features are appropriate for your environment.
  10. Ensure that the detected administrative options are appropriate for your environment.
  11. Ensure that any additional services required by your baseline, such as backup agents or antivirus software, are detected.
  12. Decide how to handle unspecified services in your environment. For stronger security (and reduced functionality) you may wish to configure this policy setting to Disable, which will disable any new service that was not explicitly allowed through SCW. You should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer.
  13. Confirm all service changes that are listed.
  14. Review the network settings and ensure that SCW detected the appropriate ports and applications to configure as exceptions for the Windows Firewall.
  15. Skip the "Registry Settings" section.
  16. Skip the "Audit Policy" section.
  17. If the server is configured with the Web server role, complete the steps in the “Internet Information Services” section to ensure that SCW is configured to support the necessary IIS features.
  18. Click Include Security Templates to add the appropriate security template.
  19. Save the policy with an appropriate name.

Test the Role Policies Using SCW

As with the baseline policies, there are two different ways to test the policies. You can use the native SCW deployment facilities, or you can deploy the policies through GPOs. Again, Microsoft strongly recommends that you deploy your role policies in a test environment before you use them in production. This approach will help minimize downtime and failures in your production environment. After you thoroughly test the new configuration, you can convert the policies into GPOs as shown in the following procedure and apply them to the appropriate OU.

Convert the Role Policies to GPOs

After you thoroughly test the role policies, complete the following steps to convert them into GPOs and link them to the appropriate OUs:

  1. At a command prompt, type the following:
    scwcmd transform /p:<i><PathToPolicy.xml> </i>/g:<i><GPODisplayName></i>
    

    and then press ENTER. For example: Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

        scwcmd transform /p:"C:\Windows\Security\msscw\Policies\
        Infrastructure.xml" /g:"Infrastructure Policy"
    

    Note: The information to be entered at the command prompt shows on more than one line here because of display limitations. This information should all be entered on one line.

  2. Use the Group Policy Management Console to link the newly created GPO to the appropriate OU, and make sure to move it above the Default Domain Controllers Policy so that it receives the highest priority.

Note that if the SCW security policy file contains Windows Firewall settings, Windows Firewall must be active on the local computer for this procedure to complete successfully. To verify that Windows Firewall is active, open Control Panel and then double-click Windows Firewall.

Summary

Security administrators need to understand the strengths and weaknesses of SCW compared to conventional Group Policy-based hardening methods so that they can choose the right methodology for their environment. SCW and Group Policy can be used together to gain the ability to rapidly and consistently prototype policies that SCW provides together with the scalable deployment and management capabilities of Group Policy.

Several design considerations are involved when forest, domain, and OU designs are reviewed to secure an environment.

It is important to research and document any specific autonomy and isolation requirements for the organization. Political autonomy, operational isolation, and legal or regulatory isolation are all valid reasons to consider complex forest designs.

It is important that you understand how to control service administrators. Malicious service administrators can present a great risk to an organization. At a lower level, malicious domain administrators can access data in any domain in the forest.

Although it may not be easy to change the forest or domain design in an organization, it may be necessary to remediate some security risks. It is also important to plan the OU deployment in the organization to accommodate the needs of both service administrators and data administrators. This chapter provided detailed information about how to create an OU model that will support the use of GPOs for the ongoing management of different server roles in the organization.

More Information

The following links provide additional information about topics that relate to hardening servers that run Windows Server 2003 with SP1.

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.

Download

Get the Windows Server 2003 Security Guide

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions