Chapter 4: The Member Server Baseline Policy

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

Overview

This chapter documents the configuration requirements to manage a baseline security template for all servers that run Microsoft® Windows Server™ 2003 with Service Pack 1 (SP1). The chapter also provides administrative guidance for the setup and configuration of a secure Windows Server 2003 with SP1 configuration in three distinct environments. The configuration requirements in this chapter form the baseline for all of the procedures that are described in later chapters of this guide. These chapters describe how to harden specific server roles.

The setting recommendations in this chapter will help establish security at the foundation of business application servers in an enterprise environment. However, you must comprehensively test the coexistence of these security configurations with your organization's business applications before you implement them in production environments.

The recommendations in this chapter are suitable for most organizations and may be deployed on either existing or new computers that run Windows Server 2003 with SP1. The default security configurations within Windows Server 2003 with SP1 were researched, reviewed, and tested by the team that created this guide. For information about all default settings and a detailed explanation of each of the settings that are discussed in this chapter, see the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP, which is available at https://go.microsoft.com/fwlink/?LinkId=15159. Generally, most of the following configuration recommendations provide greater security than the default settings.

The security settings that are discussed in this chapter relate to the following three environments:

• Legacy Client (LC). This environment includes computers that run Windows NT® 4.0 and Microsoft Windows® 98, which are sometimes referred to as legacy operating systems. Although this environment provides adequate security, it is the least secure of the three environments that are defined in this guide. To provide stronger security, organizations may choose to migrate to the more secure Enterprise Client environment. In addition to the referenced legacy operating systems, the LC environment includes Windows 2000 Professional and Windows XP Professional workstations. This environment only contains Windows 2000 or Windows Server 2003 domain controllers. There are no Windows NT 4.0 domain controllers in this environment, but Windows NT member servers may exist.
• Enterprise Client (EC). This environment provides solid security and is designed for more recent versions of the Windows operating system. The EC environment includes client computers that run Windows 2000 Professional and Windows XP Professional. Most of the work that is required to migrate from the LC environment to the EC environment involves upgrades of legacy clients such as Windows 98 and Windows NT 4.0 Workstation to Windows 2000 or Windows XP. All domain controllers and member servers in this environment run Windows 2000 Server or Windows Server 2003.
• Specialized Security – Limited Functionality (SSLF). This environment provides much stronger security than the EC environment. Migration from the EC environment to the Specialized Security – Limited Functionality (SSLF) environment requires compliance with stringent security policies for both client computers and servers. This environment includes client computers that run Windows 2000 Professional and Windows XP Professional, and domain controllers that run Windows 2000 Server or Windows Server 2003. In the SSLF environment, security concerns are so great that significant loss of client functionality and manageability is considered an acceptable tradeoff if the highest levels of security can be achieved. Member servers in this environment run Windows 2000 Server or Windows Server 2003.

You will notice that in many cases the SSLF environment will explicitly set the default value. You should assume that this configuration will affect compatibility, because it may cause applications that attempt to adjust some settings locally to fail. For example, some applications need to adjust user rights assignments to grant their service account additional privileges. Because Group Policies take precedence over local machine policy, these operations will fail. You should thoroughly test all applications before you deploy any of the recommended settings to your production computers—especially SSLF settings.

The following figure shows the three security environments and the clients that are supported in each.

Organizations that want to secure their environments by means of a phased approach may choose to start at the Legacy Client environment level and then gradually migrate to more secure environments as they upgrade and test their applications and client computers with tightened security settings.

The following figure shows how the .inf file security templates are used as a foundation for the Enterprise Client – Member Server Baseline Policy (MSBP). The figure also shows one possible way to link this policy and apply it to all servers in an organization.

Windows Server 2003 with SP1 ships with default setting values that are configured to create a secure environment. In many instances, this chapter prescribes settings that are different than the default values. The chapter also enforces specific defaults for all three environments. For information about all default settings, see the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP at https://go.microsoft.com/fwlink/?LinkId=15159.

Procedures to harden specific server roles are defined in the remaining chapters of this guide. The primary server roles that are discussed in this guide include:

• Domain controllers that include DNS services
• Infrastructure servers that include WINS and DHCP services
• File servers
• Print servers
• Web servers that run Internet Information Services (IIS)
• Microsoft Internet Authentication Server (IAS) servers
• Certificate Services (CA) servers
• Bastion hosts

Many of the following settings that appear in the Enterprise Client MSBP also apply to these server roles in the three environments that are defined in this guide. The security templates are uniquely designed to address the security needs of each particular environment. The following table shows the names of the baseline security templates for the three environments.

Table 4.1 Baseline Security Templates for All Three Environments

The security settings that are common to all three environments and therefore all Member Server Baseline security templates are described throughout the rest of this chapter.

The baseline security templates are also the basis for the domain controller security templates that are defined in Chapter 5, "The Domain Controller Baseline Policy." The Domain Controllers Role security templates include baseline settings for the Domain Controllers Group Policy GPO, which is linked to the Domain Controllers OU in all three environments. Step-by-step instructions for how to create the OUs and Group Policies and then import the appropriate security template into each GPO are provided in Chapter 2, "Windows Server 2003 Hardening Mechanisms."

Note: Some procedures that are used to harden servers cannot be automated by means of Group Policy. These procedures are described in the “Additional Security Settings” section of this chapter.

Windows Server 2003 Baseline Policy

Settings at the Member Server OU level define the common settings for all member server roles that are discussed in this guide. To apply these settings, you can create a GPO that is linked to the Member Server OU, which is known as a baseline policy. The GPO automates the configuration of specific security settings on each server. You will have to move the server accounts to the appropriate child OUs of the Member Server OU based on each server's role.

The following settings are described as they appear in the user interface (UI) of the Microsoft Management Console (MMC) Security Configuration Editor (SCE) snap-in.

Audit Policy

Administrators should create an Audit policy that defines which security events get reported, and that records user or computer activity in specified event categories. Administrators can monitor security-related activity, such as who accesses an object, if a user logs on to or off from a computer, or if changes are made to an Audit policy setting.

Before you implement an Audit policy, you must decide which event categories to audit for the environment. The audit settings that an administrator chooses for the event categories define the organization's Audit policy. When audit settings for specific event categories are defined, administrators can create an Audit policy that suits the security needs of the organization.

If no Audit policy exists, it will be difficult or impossible to determine what took place during a security incident. However, if audit settings are configured so that many authorized activities generate events, the Security log will fill up with useless data. The following recommendations and setting descriptions are provided to help you determine what to monitor so that the collected data is relevant.

Oftentimes, failure logs are much more informative than success logs because failures typically indicate errors. For example, successful logon to a computer by a user would typically be considered normal. However, if someone unsuccessfully tries to log on to a computer multiple times, it may indicate an attempt to break into the computer with someone else's account credentials. The event logs record events on the computer. In Microsoft Windows operating systems, there are separate event logs for applications, security events, and system events. The Security log records audit events. The event log container of Group Policy is used to define attributes that are related to the Application, Security, and System event logs, such as maximum log size, access rights for each log, and retention settings and methods.

Before an Audit policy implementation, organizations should determine how they will collect, organize, and analyze the data. Large volumes of audit data have little value if there is no plan to exploit it. Also, performance may be affected when computer networks are audited. The impact for a given combination of settings may be negligible on an end-user computer but quite noticeable on a busy server. Therefore, you should test whether performance will be affected before you deploy new audit settings in your production environment.

The following table includes the Audit policy setting recommendations for all three environments that are defined in this guide. You may notice that the settings for most values are similar for all three environments. Additional information about each setting is provided in the subsections that follow the table.

You can configure the Audit policy setting values in Windows Server 2003 with SP1 at the following location within the Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy

For a summary of the prescribed settings in this section, see the Microsoft Excel® workbook "Windows Server 2003 Security Guide Settings," which is included with the downloadable version of this guide. For more information about the default settings and a detailed explanation of each of the settings that are discussed in this section, see the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP, which is available at https://go.microsoft.com/fwlink/?LinkId=15159.

Table 4.2 Audit Policy Settings

Audit account logon events

This policy setting determines whether to audit each instance of a user who logs on to or off from another computer that validates the account. Authentication of a domain user account on a domain controller generates an account logon event that is logged in the domain controller's Security log. Authentication of a local user on a local computer generates a logon event that is logged in the local Security log. No account logoff events are logged.

The Audit account logon events setting is configured to log Success values for the LC and EC baseline policies, and to log both Success and Failure events for the SSLF baseline policy.

The following table includes the important security events that this policy setting logs in the Security log. These event IDs can be useful when you want to create custom alerts to monitor any software suite, such as Microsoft Operations Manager (MOM).

Table 4.3 Account Logon Events

Audit account management

This policy setting determines whether to audit each account management event on a computer. Examples of account management events include:

• A user account or group is created, changed, or deleted.
• A user account is renamed, disabled, or enabled.
• A password is set or changed.

Organizations need to be able to determine who creates, modifies, or deletes both domain and local accounts. Unauthorized changes could indicate mistaken changes made by an administrator who does not understand how to follow organizational policies, but could also indicate a deliberate attack.

For example, account management failure events often indicate attempts by a lower-level administrator—or an attacker who has compromised a lower-level administrator's account—to elevate their privileges. The logs can help you determine which accounts an attacker has modified and created.

The Audit account management setting is configured to log Success values for the LC and EC baseline policies, and to log both Success and Failure values for the SSLF baseline policy.

The following table includes the important security events that this policy setting records in the Security log. These event IDs can be useful when you want to create custom alerts to monitor any software suite, such as MOM. Most operational management software can be customized with scripts to capture or flag events that are based on these event IDs.

Table 4.4 Account Management Events

Audit logon events

This policy setting determines whether to audit each instance of user logon and logoff from a computer. The Audit logon events setting generates records on domain controllers to monitor domain account activity and on local computers to monitor local account activity.

If you configure the Audit logon events setting to No auditing, it is difficult or impossible to determine which users have either logged on or attempted to log on to computers in the organization. If you enable the Success value for the Audit logon events setting on a domain member, an event will be generated each time that someone logs on to the network, regardless of where the accounts reside on the network. If the user logs on to a local account and the Audit account logon events setting is Enabled, the user logon will generate two events.

Even if you do not modify the default values for this policy setting, no audit record evidence will be available for analysis after a security incident takes place. The Audit logon events setting is configured to log Success values in the LC and EC baseline policies and to log both Success and Failure values for the SSLF policy.

The following table includes the important security events that this policy setting records in the Security log.

Table 4.5 Audit Logon Events

Audit object access

By itself, this policy setting will not cause any events to be audited. The Audit object access setting determines whether to audit the event when a user accesses an object—for example, a file, folder, registry key, or printer—that has a specified system access control list (SACL).

A SACL is comprised of access control entries (ACE). Each ACE contains three pieces of information:

• The security principal (user, computer, or group) to be audited.
• The specific access type to be audited (called an access mask).
• A flag to indicate whether to audit failed access events, successful access events, or both.

If you configure the Audit object access setting to log Success values, an audit entry will be generated each time that a user successfully accesses an object with a specified SACL. If you configure this policy setting to log Failure values, an audit entry will be generated each time that a user unsuccessfully attempts to access an object with a specified SACL.

Organizations should define only the actions they want enabled when SACLs are configured. For example, you might want to enable the Write and Append Data audit setting on executable files to track when they are changed or replaced, because computer viruses, worms, and Trojan horses typically target executable files. Similarly, you might want to track when sensitive documents are accessed or changed.

The Audit object access setting is configured to the default value of No auditing in the baseline policy for the LC and EC environments. However, this policy setting is configured to log Failure values in the baseline policy for the SSLF environment.

The following table includes the important security events that this policy setting records in the Security log.

Table 4.6 Object Access Events

Audit policy change

This policy setting determines whether to audit every incident of a change to user rights assignment policies, trust policies or the Audit policy itself.

If you configure the Audit policy change setting to log Success values, an audit entry will be generated for each successful change to user rights assignment policies, trust policies, or Audit policies. If you configure this policy setting to log Failure values, an audit entry will be generated for each failed change to user rights assignment policies, trust policies, or Audit policies.

The recommended settings would allow you to you see any account privileges that an attacker attempts to elevate—for example, if they tried to add the Debug programs privilege or the Back up files and directories privilege.

The Audit policy change setting is configured to log Success values in the baseline policy for all three environments that are defined in this guide. Currently, the Failure setting value does not capture meaningful events.

The following table includes the important security events that this policy setting records in the Security log.

Table 4.7 Audit Policy Change Events

Audit privilege use

This policy setting determines whether to audit each exercise of a user right. If you configure the Audit privilege use setting to log Success values, an audit entry will be generated each time that a user right is exercised successfully. If you configure this policy setting to log Failure values, an audit entry will be generated each time that a user right is exercised unsuccessfully.

Audits are not generated when the following user rights are exercised, even if you configure the Audit privilege use setting, because these user rights generate many events in the Security log. Performance of your computers would likely be affected if these user rights were audited:

• Bypass traverse checking
• Debug programs
• Create a token object
• Replace process level token
• Generate security audits
• Back up files and directories
• Restore files and directories

Note: If you wish to audit these user rights, you must enable the Audit: Audit the use of Backup and Restore privilege security option in Group Policy.

The Audit privilege use setting is left at the default value of No auditing in the baseline policy for the LC and EC environments. However, this policy setting is configured to log Failure values in the baseline policy for the SSLF environment. Failed use of a user right is an indicator of a general network problem, and can often indicate an attempted security breach. Organizations should configure the Audit privilege use setting to Enable only if there is a specific business reason to do so.

The following table includes the important security events that this setting records in the Security log.

Table 4.8 Privilege Use Events

Audit process tracking

This policy setting determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access. If you configure this policy setting to log Success values, an audit entry is generated each time that the process that is being tracked succeeds. If you configure this policy setting to log Failure values, an audit entry is generated each time that the process that is being tracked fails.

The Audit process tracking setting will generate a large number of events, so it is typically configured to No auditing, as it is in the baseline policy for all three environments that are defined in this guide. However, this policy setting can be very helpful during an incident response because it provides a detailed log of the processes that are started and the time when each one was launched.

The following table includes the important security events that this setting records in the Security log.

Table 4.9 Process Tracking Events

Audit system events

This policy setting determines whether to audit when a user restarts or shuts down a computer or when an event occurs that affects either the computer’s security or the Security log. If you configure this policy setting to log Success values, an audit entry is generated when a system event is executed successfully. If you configure this policy setting to log Failure events, an audit entry is generated when a system event is attempted unsuccessfully.

The following table includes the most useful successful events for this setting.

Table 4.10 System Event Messages for Audit System Events

User Rights Assignments

User rights assignments provide users and groups with logon rights or privileges on the computers in your organization. An example of a logon right is the right to log on to a computer interactively. An example of a privilege is the right to shut down the computer. Both types are assigned by administrators to individual users or groups as part of the security settings for the computer.

Note: Throughout this section, "Not defined" applies only to users; Administrators still have the user right. Local administrators can make changes, but any domain-based Group Policy settings will override them the next time that the Group Policies are refreshed or reapplied.

You can configure the user rights assignment settings in Windows Server 2003 with SP1 at the following location within the Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

The default user rights assignments are different for the various types of servers in your organization. For example, Windows Server 2003 assigns different rights to built-in groups on member servers and domain controllers. (Similarities between built-in groups on different server types are not documented in the following list.

• Member Servers
  • Power Users. Possess most administrative powers with some restrictions. Power Users can run legacy applications in addition to applications that are certified for Windows Server 2003 with SP1 or Windows XP.
  • HelpServicesGroup. The group for the Help and Support Center. Support_388945a0 is a member of this group by default.
  • TelnetClients. Members of this group have access to the Telnet server on the network.
• Domain Controllers
  • Server Operators. Members of this group can administer domain servers.
  • Terminal Server License Services. Members of this group have access to Terminal Server License Servers on the network.
  • Windows Authorization Access Group. Members of this group have access to the computed tokenGroupsGlobalAndUniversal attribute on user objects.

The Guests group and the user accounts Guest and Support_388945a0 have unique SIDs between different domains. Therefore, this Group Policy for user rights assignments may need to be modified on a computer on which only the specific target group exists. Alternatively, the policy templates can be edited individually to include the appropriate groups within the .inf files. For example, a domain controller Group Policy could be created on a domain controller in a test environment.

Note: Because of the unique SIDs that exist between members of the Guests group, Support_388945a0, and Guest, some settings that are used to harden servers cannot be automated by means of the security templates that are included with this guide. These settings are described in the "Additional Security Settings" section later in this chapter.

This section provides details about the prescribed MSBP user rights assignment settings for all three environments that are defined in this guide. For a summary of the prescribed settings in this section, see the Microsoft Excel workbook "Windows Server 2003 Security Guide Settings," which is included with the downloadable version of this guide. For information about the default settings and a detailed explanation of each of the settings that are discussed in this section, see the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP.

The following table includes the user rights assignments setting recommendations for all three environments that are defined in this guide. Additional information about each setting is provided in the subsections that follow the table.

Table 4.11 User Rights Assignments Setting Recommendations

Access this computer from the network

This policy setting determines which users and groups are allowed to connect to the computer over the network. It is required by a number of network protocols, including server message block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), HTTP, and Component Object Model Plus (COM+).

The Access this computer from the network setting is configured to Not defined for the LC and EC environments. However, although permissions that are assigned to the Everyone security group in Windows Server 2003 with SP1 no longer provide access to anonymous users, guest groups and accounts can still be assigned access through the Everyone security group. For this reason, the Everyone security group is denied the Access this computer from the network user right in the SSLF environment, which helps guard against attacks that target guest access to the domain. Only the Administrators, Authenticated Users, and ENTERPRISE DOMAIN CONTROLLERS groups are assigned this user right in the SSLF environment.

Act as part of the operating system

This policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right.

The Act as part of the operating system user right is configured to Not defined for the LC and EC environments. However, for the SSLF environment this policy setting is configured to a null value or blank, which denies this user right to all security groups and accounts.

Adjust memory quotas for a process

This policy setting determines whether users can adjust the maximum amount of memory that is available to a process. It is useful for computer tuning purposes, but it can be abused. An attacker could exploit this user right to launch a DoS attack.

The Adjust memory quotas for a process setting is configured to Not defined for the LC and EC environments. However, this user right is assigned to the Administrators group, NETWORK SERVICE, and LOCAL SERVICE for the SSLF environment.

Allow log on locally

This policy setting determines which users can log on interactively to the specified computer. Logons that are initiated with the CTRL+ALT+DEL key combination on the keyboard require the user to have this user right. Any account with this user right could be used to log on to the computer’s local console.

The Allow log on locally user right is restricted to the Administrators, Backup Operators, and Power Users groups for the LC and EC environments, which helps prevent logon by unauthorized users who may want to elevate their privileges or introduce viruses into the environment. This user right is assigned to only the Administrators group for the SSLF environment.

Allow log on through Terminal Services

This policy setting determines which users or groups have permission to log on as a Terminal Services client.

For the LC and EC environments, the Allow log on through Terminal Services user right is restricted to the Administrators and Remote Desktop Users groups. For the SSLF environment, only members of the Administrators group are assigned this user right.

Back up files and directories

This policy setting determines whether users can circumvent file and directory permissions to back up the computer. It is used only when an application attempts access through the NTFS backup application programming interface (API) with a backup utility such as NTBACKUP.EXE. Otherwise, normal file and directory permissions apply.

The Back up files and directories setting is configured to Not defined for the LC and EC environments. This user right is assigned to only the Administrators group for the SSLF environment.

Bypass traverse checking

This policy setting determines whether users can pass through folders without being checked for the special “Traverse Folder” access permission when they navigate an object path in the NTFS file system or in the registry. The user right does not allow the user to list the contents of a folder; it only allows the user to traverse its directories.

The Bypass traverse checking setting is configured to Not defined for the LC and EC environments. This user right is assigned to only the Authenticated Users group for the SSLF environment.

Change the system time

This policy setting determines which users can change the time and date on the internal clock of the computer. Users who are assigned this user right can affect the appearance of event logs, which are time stamped by the computer's internal clock. If the computer’s time is changed, the logs will not reflect the actual time that events occurred.

The Change the system time setting is configured to Not defined for the LC and EC environments. This user right is assigned to only the Administrators group and the Local Service account for the SSLF environment.

Note: Discrepancies between the time on the local computer and on the domain controllers may cause problems for the Kerberos authentication protocol, which could make it impossible for users to log on to the domain or to obtain authorization to access domain resources after they log on.

Create a pagefile

This policy setting determines whether users can create and change the size of pagefiles. To perform this task, the user specifies a page file size for a particular drive in the Performance Options box that is located on the Advanced tab of the System Properties dialog box.

The Create a pagefile setting is configured to Not defined for the LC and EC environments, This user right is assigned to only the Administrators group for the SSLF environment.

Create a token object

This policy setting determines whether a process can create a token, which the process can then use to gain access to any local resources when it uses NtCreateToken() or other token-creation APIs.

The Create a token object setting is configured to Not defined for the LC and EC environments. However, for the SSLF environment this policy setting is configured to a null value or blank, which means no security group or account will have this user right.

Create global objects

This policy setting allows users to create global objects that are available to all sessions. Users can still create objects that are specific to their own session without being assigned this user right.

The Create global objects setting is configured to Not defined for the LC and EC environments. For the SSLF environment, this user right is only assigned to the SERVICE and Administrators groups.

Create permanent shared objects

This policy setting determines whether users can create directory objects in the object manager, which means that they can create shared folders, printers, and other objects. It is useful to kernel-mode components that extend the object namespace, and such components have this user right inherently. Therefore, it is typically not necessary to specifically assign this user right to users.

The Create permanent shared objects setting is configured to Not defined for the LC and EC environments. However, for the SSLF environment this policy setting is configured to a null value or blank, which means no security group or account will have this user right.

Debug programs

This policy setting determines which users can attach a debugger to any process or to the kernel. It provides complete access to sensitive and critical operating system components. Programs should not be debugged in production environments except in extreme circumstances, such as when there is a need to troubleshoot a business-critical application that cannot be effectively assessed in the test environment.

The Debug programs setting is configured to Not defined for the LC environment. For the EC environment, this user right is assigned only to the Administrators group. However, for the SSLF environment this policy setting is configured to a null value or blank, which means no security group or account will have this user right.

Note: On Windows Server 2003 with SP1, removal of the Debug programs user right may result in an inability to use the Windows Update service. However, patches can still be manually downloaded and installed or applied through other means. Removal of this user right may also interfere with the Cluster Service. For more information, see the Microsoft Knowledge Base article "How to apply more restrictive security settings on a Windows Server 2003-based cluster server" at https://support.microsoft.com/?kbid=891597.

Deny access to this computer from the network

Note: ANONOYMOUS LOGON, Built-in Administrator, Support_388945a0, Guest, and all NON-operating system service accounts are not included in the .inf security template. These accounts and groups have unique SIDs for each domain in your organization. Therefore, they must be added manually. For more information, see the “Manual Hardening Procedures” section near the end of this chapter.

This policy setting determines which users will not be able to access a computer over the network. It denies a number of network protocols, including SMB-based protocols, NetBIOS, CIFS, HTTP, and COM+. This policy setting supersedes the Access this computer from the network user right when a user account is subject to both settings.

For all three environments that are defined in this guide, the Deny access to this computer from the network user right is assigned to the Guests group, ANONOYMOUS LOGON, Support_388945a0, and all service accounts that are not part of the operating system.

Configuration of this policy setting for other groups could limit the abilities of users who are assigned to specific administrative roles in your environment. You should verify that delegated tasks will not be negatively affected.

Deny log on as a batch job

Note: ANONOYMOUS LOGON, Built-in Administrator, Support_388945a0, Guest, and all NON-operating system service accounts are not included in the .inf security template. These accounts and groups have unique SIDs for each domain in your organization. Therefore, they must be added manually. For more information, see the “Manual Hardening Procedures” section near the end of this chapter.

This policy setting determines which accounts will not be able to log on to the computer as a batch job. A batch job is not a batch (.bat) file, but rather a batch-queue facility. Accounts that use the Task Scheduler to schedule jobs need this user right.

The Deny log on as a batch job user right overrides the Log on as a batch job user right, which could be used to allow accounts to schedule jobs that consume excessive system resources. Such an occurrence could cause a DoS condition. For this reason, the Deny log on as a batch job user right is assigned to the Guests group and the Support_388945a0 user account in the baseline policy for all three environments that are defined in this guide. Failure to assign this user right to the recommended accounts can be a security risk.

Deny logon as a service

This policy setting determines whether services can be launched in the context of the specified account.

The Deny logon as a service setting is configured to Not defined for the LC and EC environments. However, for the SSLF environment this policy setting is configured to a null value or blank, which means no security group or account will have this user right.

Deny logon locally

This policy setting determines whether users can log on directly at the computer's keyboard.

The Deny logon locally setting is configured to Not defined for the EC and LC environments. However, this user right is assigned only to the Guests group and the Support_388945a0 user account for the SSLF environment. Failure to assign this user right to the recommended accounts can be a security risk.

Deny log on through Terminal Services

Note: ANONOYMOUS LOGON, Built-in Administrator, Support_388945a0, Guest, and all NON-operating system service accounts are not included in the .inf security template. These accounts and groups have unique SIDs for each domain in your organization. Therefore, they must be added manually. For more information, see the “Manual Hardening Procedures” section near the end of this chapter.

This policy setting determines whether users can log on as Terminal Services clients. After the baseline member server is joined to a domain environment, there is no need to use local accounts to access the server from the network. Domain accounts can access the server for administration and end-user processing.

For all three environments that are defined in this guide, the Guests group is assigned the Deny log on through Terminal Services user right so that they cannot log on through Terminal Services.

Enable computer and user accounts to be trusted for delegation

This policy setting determines whether users can change the Trusted for Delegation setting on a user or computer object in Active Directory. Users or computers that are assigned this user right must also have write access to the account control flags on the object. Misuse of this user right could cause unauthorized impersonation of other users on the network.

The Enable computer and user accounts to be trusted for delegation setting is configured to Not defined for the LC and EC environments. However, this user right is assigned only to the Administrators group for the SSLF environment.

Force shutdown from a remote system

This policy setting determines whether users can shut down computers from remote locations on the network. Any user who can shut down a computer could cause a DoS condition. Therefore, this user right should be tightly restricted.

The Force shutdown from a remote system setting is configured to Not defined for the LC and EC environments. This user right is assigned only to the Administrators group for the SSLF environment.

Generate security audits

This policy setting determines whether a process can generate audit records in the Security log. Because the Security log can be used to trace unauthorized access, accounts that can write to the Security log could be used by an attacker to fill that log with meaningless events. If you configure the computer to overwrite events as needed, an attacker could use this capability to remove evidence of their unauthorized activities. If you configure the computer to shut down when it is unable to write to the Security log, an attacker could use this capability to create a DoS condition.

The Generate security audits setting is configured to Not defined for the LC and EC environments. This user right is assigned only to the NETWORK SERVICE and LOCAL SERVICE accounts for the SSLF environment.  

Impersonate a client after authentication

This policy setting determines whether applications that run on behalf of an authenticated user can impersonate clients. If this user right is required for this type of impersonation, unauthorized users will not be able to convince a client to connect—for example, by remote procedure call (RPC) or named pipes—to a service that they created to impersonate that client. The unauthorized user could use this capability to elevate their permissions to administrative or system levels.

The Impersonate a client after authentication setting is configured to Not defined for the LC and EC environments. However, this user right is assigned only to the Administrators group and SERVICE for the SSLF environment.

Increase scheduling priority

This policy setting determines whether users can increase the base priority class of a process. Increasing relative priority within a priority class is not a privileged operation. This user right is not required by administrative tools that are supplied with the operating system, but it might be required by software development tools. A user who is assigned this user right can increase the scheduling priority of a process to Real-Time and leave little processing time for all other processes, which could cause a DoS condition.

The Increase scheduling priority setting is configured to Not defined for the LC and EC environments. However, this user right is assigned only to the Administrators group for the SSLF environment.

Load and unload device drivers

This policy setting determines which users can dynamically load and unload device drivers. This user right is not required if a signed driver for the new hardware already exists in the Driver.cab file on the computer. Device drivers run as highly privileged code. A user who is assigned the Load and unload device drivers user right can install malicious code that masquerades as a device driver (unintentionally or otherwise). (Administrators should exercise greater care and install only drivers with verified digital signatures.)

The Load and unload device drivers setting is configured to Not defined for the LC and EC environments. However, this user right is assigned to only the Administrators group for the SSLF environment.

Lock pages in memory

This policy setting determines whether a process can keep data in physical memory, which prevents the computer from paging the data to virtual memory on disk. Such an occurrence could significantly degrade performance. Users who are assigned this user right can assign physical memory to several processes and leave little or no random access memory (RAM) for other processes, which could lead to a DoS condition.

The Lock pages in memory setting is configured to Not defined for the LC and EC environments. However, for the SSLF environment this policy setting is configured to a null value or blank, which means no security group or account will have this user right.

Log on as a service

This policy setting determines whether a security principal can log on as a service. Services can be configured to run under the Local System, Local Service, or Network Service accounts, which have built-in rights to log on as a service. Any service that runs under a separate user account must be assigned this user right.

The Log on as a service setting is configured to Not defined for the LC and EC environments. However, this user right is assigned only to the Network Service account for the SSLF environment.

Manage auditing and security log

This policy setting determines whether users can specify object access auditing options for individual resources such as files, Active Directory objects, and registry keys. This user right is powerful and should be closely guarded. Anyone with this user right can clear the Security log and possibly erase important evidence of unauthorized activity.

The Manage auditing and security log setting is configured to Not defined for the LC and EC environments. However, this user right is assigned only to Administrators in the SSLF environment.

Important: Microsoft Exchange Server 2003 modifies this user right in the Default Domain Controller Policy during the installation process. For details, see Exchange Server 2003 Deployment online at www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3ADPerm/110e37bf-a68c-47bb-b4d5-1cfd539d9cba.mspx. If this user right is restricted to the Administrator’s group, Exchange will frequently record error messages to the Application event log. If you use Exchange Server 2003 you will need to adjust the value of this setting for the domain controllers. As with all of the settings that are recommended in this guide, you may need to make some adjustments to allow your organization’s applications to function normally.

Modify firmware environment values

This policy setting determines whether the computer’s environment variables can be modified, either by a process through an API or by a user through System Properties. Anyone who is assigned this user right could configure the settings of a hardware component to cause it to fail, which could lead to data corruption or a DoS condition.

The Modify firmware environment values setting is configured to Not defined for the LC and EC environments. However, this user right is assigned to only the Administrators group for the SSLF environment.

Perform volume maintenance tasks

This policy setting determines whether a non-administrative or remote user can manage volumes or disks. A user who is assigned this user right could delete a volume and cause the loss of data or a DoS condition.

The Perform volume maintenance tasks setting is configured to Not defined for the LC and EC environments. However, this user right is assigned only to the Administrators group for the SSLF environment.

Profile single process

This policy setting determines which users can use performance monitoring tools to monitor the performance of non-system processes. This user right presents a moderate vulnerability, in that an attacker with this capability could monitor a computer's performance to help identify critical processes that they might want to attack directly. An attacker could also determine what processes run on the computer so that they could identify countermeasures to avoid, such as antivirus software, an intrusion detection system, or other users logged onto a computer.

The Profile single process setting is configured to Not defined for the LC and EC environments. For greater security, ensure that the Power Users group is not assigned this user right in the SSLF environment; only members of the Administrators group should have this capability in such an environment.

Profile system performance

This policy setting is similar to the previous setting. It determines whether users can monitor the performance of system processes. This user right presents a moderate vulnerability, in that an attacker with this privilege could monitor a computer's performance to help identify critical processes that they might want to attack directly. An attacker could also determine what processes run on the computer to identify countermeasures to avoid, such as antivirus software or an intrusion detection system.

The Profile system performance setting is configured to Not defined for the LC and EC environments. However, this user right is assigned to only the Administrators group for the SSLF environment.

Remove computer from docking station

This policy setting determines whether users of portable computers can click Eject PC on the Start menu to undock the computers. Anyone who is assigned this user right can remove a portable computer from its docking station.

The Remove computer from docking station setting is configured to Not defined for the LC and EC environments. However, this user right is assigned to only the Administrators group for the SSLF environment.

Replace a process level token

This policy setting determines whether a parent process can replace the access token that is associated with a child process.

The Replace a process level token setting is configured to Not defined for the LC and EC environments. However, this user right is assigned to only the LOCAL SERVICE and NETWORK SERVICE accounts for the SSLF environment.

Restore files and directories

This policy setting determines which users can bypass file, directory, registry, and other persistent objects permissions when they restore backed up files and directories. It also determines which users can set any valid security principal as the owner of an object.

The Restore files and directories setting is configured to Not defined for the LC and EC environments. However, only the Administrators group is assigned this user right for the SSLF environment. File restoration tasks are usually performed by administrators or members of another specifically delegated security group, especially for highly sensitive servers and domain controllers.

Shut down the system

This policy setting determines which locally logged on users can shut down the operating system with the Shut Down command. Because misuse of this capability could cause a DoS condition, the ability to shut down domain controllers should be limited to a very small number of trusted administrators. Even though a system shutdown requires the ability to log on to the server, you should be very careful about the accounts and groups that you allow to shut down a domain controller.

The Shut down the system setting is configured to Not defined for the LC and EC environments. However, only the Administrators group is assigned this user right for the SSLF environment.

Synchronize directory service data

This policy setting determines whether a process can read all objects and properties in the directory, regardless of the protection on the objects and properties. This user right is required to use LDAP directory synchronization (Dirsync) services.

The default configuration of the Synchronize directory service data setting is Not defined, which is sufficient for the LC and EC environments. However, for the SSLF environment this policy setting is configured to a null value or blank, which means no security group or account will have this user right.

Take ownership of files or other objects

This policy setting determines whether users can take ownership of any securable object in the network, including Active Directory objects, NTFS file system (NTFS) files, and folders, printers, registry keys, services, processes, and threads.

The Take ownership of files or other objects setting is configured to Not defined for the LC and EC environments. However, you should assign this user right only to the local Administrators group for the SSLF environment.

Security Options

The policy settings in the Security Options section of Group Policy are used to enable or disable capabilities and features such as floppy disk drive access, CD-ROM drive access, and logon prompts. These policy settings are also used to configure various other settings, such as those for the digital signing of data, administrator and guest account names, and how driver installation works.

You can configure the security options settings in Windows Server 2003 with SP1 at the following location within the Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Not all of the settings that are included in this section exist on all types of computers. Therefore, the settings that comprise the Security Options portion of Group Policy that are defined in this section may need to be manually modified on computers in which these settings are present to make them fully operable.

The following sections provide information about the prescribed MSBP security options settings for all three environments that are defined in this guide. For a summary of the prescribed settings, see the Microsoft Excel workbook "Windows Server 2003 Security Guide Settings," which is included with the downloadable version of this guide. For information about the default configuration and a detailed explanation of each of the settings, see the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP.

The tables in each of the following sections summarize the recommended settings for the different types of security option settings. Detailed information about the settings is provided in the subsections that follow each table.

Accounts Settings

Table 4.12 Security Options: Accounts Setting Recommendations

Accounts: Administrator account status

This policy setting enables or disables the Administrator account during normal operation. When you start a computer in safe mode, the Administrator account is always enabled, regardless of this setting.

The Accounts: Administrator account status setting is configured to Not defined for the LC and EC environments and to Enabled for the SSLF environment.

Accounts: Guest account status

This policy setting determines whether the Guest account is enabled or disabled. This account allows unauthenticated network users to log on as Guest and gain access to the computer.

The Accounts: Guest account status setting is configured to Disabled in the baseline policy for all three environments that are defined in this guide.

Accounts: Limit local account use of blank passwords to console logon only

This policy setting determines whether local accounts that are not password protected can be used to log on from locations other than the physical computer console. If this policy setting is enabled, local accounts with nonblank passwords will not be able to log on to the network from a remote client, and local accounts that are not password protected will only be able to log on while physically located at the keyboard of the computer.

The Accounts: Limit local account use of blank passwords to console logon only setting is configured to the default value of Enabled in the baseline policy for all three of the environments that are defined in this guide.

Audit Settings

Table 4.13 Security Options: Audit Setting Recommendations

Audit: Audit the access of global system objects

This policy setting audits the access of global system objects when it is in effect. If both the Audit: Audit the access of global system objects and the Audit object access audit policy settings are enabled, a large number of audit events will be generated.

The Audit: Audit the access of global system objects setting is configured to the default value of Disabled in the baseline policy for all three environments that are defined in this guide.

Note: Changes to the configuration of this policy setting will not take effect until you restart Windows Server 2003.

Audit: Audit the use of Backup and Restore privilege

This policy setting determines whether to audit the use of all user privileges, including Backup and Restore, when the Audit privilege use policy setting is in effect. If you enable this policy setting, a large number of security events could be generated, which would cause servers to respond slowly and the Security log to record numerous events of little significance.

Therefore, the Audit: Audit the use of Backup and Restore privilege setting is configured to the default value of Disabled in the baseline policy for all three environments that are defined in this guide.

Note: Changes to the configuration of this policy setting will not take effect until you restart Windows Server 2003.

Audit: Shut down system immediately if unable to log security audits

This policy setting determines whether the computer shuts down immediately if it is unable to log security events.

The amount of administrative overhead that was required to enable the Audit: Shut down system immediately if unable to log security audits setting in the LC and EC environments was determined to be too great. Therefore, this policy setting is configured to Disabled in the baseline policy for those environments. However, this policy setting is configured to Enabled in the baseline policy for the SSLF environment because the additional administrative overhead was deemed acceptable to prevent the deletion of events from the Security log unless an administrator specifically chooses to do so.

Devices Settings

Table 4.14 Security Options: Devices Setting Recommendations

Devices: Allow undock without having to log on

This policy setting determines whether a portable computer can be undocked without the user having to log on to the computer. You can enable this policy setting to eliminate a logon requirement and allow use of an external hardware eject button to undock the computer. If you disable this policy setting, a user who is not logged on must be assigned the Remove computer from docking station user right.

The Devices: Allow undock without having to log on setting is configured to Disabled in the baseline policy for all three environments that are defined in this guide.

Devices: Allowed to format and eject removable media

This policy setting determines who can format and eject removable media. Only administrators should be able to eject removable media on servers.

Therefore, the recommended value for the Devices: Allowed to format and eject removable media setting is the default value of Administrators in the baseline policy for all three environments that are defined in this guide.

Devices: Prevent users from installing printer drivers

For a computer to print to a network printer, it must have the driver for that network printer installed. If you enable the Devices: Prevent users from installing printer drivers setting, only those in the Administrators or Power Users groups or those with Server Operator privileges are allowed to install a printer driver to add a network printer. If you disable this policy setting, any user can install a printer driver.

The Devices: Prevent users from installing printer drivers setting is configured to the default value of Enabled in the baseline policy for all three environments that are defined in this guide.

Devices: Restrict CD-ROM access to locally logged-on user only

This policy setting determines whether a CD-ROM is accessible to both local and remote users simultaneously. If you enable this policy setting, only the interactively logged-on user is allowed to access removable CD-ROM media. When this policy setting is enabled and no one is logged on interactively, the CD-ROM is accessible over the network.

The Devices: Restrict CD-ROM access to locally logged-on user only setting is configured to Not defined in the baseline policy for the LC and EC environments. In the baseline policy for the SSLF environment, this policy setting is configured to Disabled.

Devices: Restrict floppy access to locally logged-on user only

This policy setting determines whether removable floppy media are accessible to both local and remote users simultaneously. If you enable this policy setting, only the interactively logged-on user is allowed to access removable floppy media. If this policy setting is enabled and no one is logged on interactively, the floppy media is accessible over the network.

The Devices: Restrict floppy access to locally logged-on user only setting is configured to Not defined in the baseline policy for the LC and EC environments. In the baseline policy for the SSLF environment, this policy setting is configured to Disabled.

Devices: Unsigned driver installation behavior

This policy setting determines what happens when an attempt is made to install a device driver (by means of Setup API) that has not been approved and signed by the Windows Hardware Quality Lab (WHQL). Depending on how you configure it, this policy setting will prevent the installation of unsigned drivers or warn the administrator that an unsigned driver is about to be installed.

The Devices: Unsigned driver installation behavior setting can be used to prevent the installation of drivers that have not been certified to run on Windows Server 2003 with SP1. However, this policy setting is configured to Warn but allow installation in the baseline policy for all three environments that are defined in this guide. One potential problem with this configuration is that unattended installation scripts will fail when they attempt to install unsigned drivers.

Domain Member Settings

Table 4.15 Security Options: Domain Member Setting Recommendations

Domain member: Digitally encrypt or sign secure channel data (always)

This policy setting determines whether all secure channel traffic that is initiated by the domain member must be signed or encrypted. If a computer is set to always encrypt or sign secure channel data, then it cannot establish a secure channel with a domain controller that cannot sign or encrypt all secure channel traffic.

The Domain member: Digitally encrypt or sign secure channel data (always) setting is configured to Disabled in the baseline policy for the LC environment and to Enabled for the EC and SSLF environments.

Note: To take advantage of this setting on member workstations and servers, all domain controllers that constitute the member’s domain must run Windows NT 4.0 with Service Pack 6a or la more recent version of Windows. Also, this policy setting is not supported in Windows 98 Second Edition clients unless they have the Dsclient installed.

Domain member: Digitally encrypt secure channel data (when possible)

This policy setting determines whether a domain member may attempt to negotiate encryption for all secure channel traffic that it initiates. If you enable this policy setting, the domain member will request encryption of all secure channel traffic. If you disable this policy setting, the domain member will not be allowed to negotiate secure channel encryption.

Therefore, the Domain member: Digitally encrypt secure channel data (when possible) setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

Domain member: Digitally sign secure channel data (when possible)

This policy setting determines whether a domain member may attempt to negotiate a signature for all secure channel traffic that it initiates. Requirement of a signature protects the traffic from modification by anyone who might capture the data.

The Domain member: Digitally sign secure channel data (when possible) setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

Domain member: Disable machine account password changes

This policy setting determines whether a domain member may periodically change its computer account password. If you enable this policy setting, the domain member will not be able to change its computer account password. If you disable this policy setting, the domain member will be able to change its computer account password as specified by the Domain Member: Maximum machine account password age setting, which is every 30 days by default.

Computers that are no longer able to automatically change their account passwords are at risk of attack by someone who has determined the password for the computer's domain account. Therefore, the Domain member: Disable machine account password changes setting is configured to Disabled in the baseline policy for all three environments that are defined in this guide.

Domain member: Maximum machine account password age

This policy setting determines the maximum allowable age for a computer account password. It also applies to computers that run Windows 2000, but is not available through the Security Configuration Manager tools on these computers. By default, the domain members automatically change their domain passwords every 30 days. If this interval is increased significantly, or if it is set to 0 so that the computers no longer change their passwords, an attacker will have more time to undertake a brute force attack and guess the password of one or more computer accounts.

Therefore, the Domain member: Maximum machine account password age setting is configured to 30 days in the baseline policy for all three environments that are defined in this guide.

Domain member: Require strong (Windows 2000 or later) session key

This policy setting determines whether 128-bit key strength is required for encrypted secure channel data. If you enable this policy setting, a secure channel will not be able to be established without 128-bit encryption. If you disable this policy setting, the domain member is required to negotiate key strength with the domain controller. Session keys that are used to establish secure channel communications between domain controllers and member computers are much stronger in Windows 2000 than they were in previous Microsoft operating systems.

Therefore, because the three security environments described in this guide contain Windows 2000 domain controllers or later, the Domain member: Require strong (Windows 2000 or later) session key setting is configured to Enabled in the baseline policy for all three environments.

Note: If you enable this policy setting you will not be able to join computers that run Windows 2000 to Windows NT 4.0 domains.

Interactive Logon Settings

Table 4.16 Security Options: Interactive Logon Setting Recommendations

Interactive logon: Display user information when the session is locked

This policy setting determines whether the account name of the last user to log on to the client computers in your organization will display in each computer's respective Windows logon screen. If you enable this policy setting, intruders will not be able to collect account names visually from the screens of desktop or laptop computers in your organization.

The Interactive logon: Display user information when the session is locked setting is configured to Not defined for the LC and EC environments. It is configured to User display name, domain and user names in the baseline server policy for the SSLF environment.

Interactive logon: Do not display last user name

This policy setting determines whether the name of the last user to log on to the computer is displayed in the Windows logon screen. If you enable this policy setting, the last logged on user's name will not display in the Log On to Windows dialog box.

The Interactive logon: Do not display last user name setting is configured to Enabled in the baseline server policy for all three environments that are defined in this guide.

Interactive logon: Do not require CTRL+ALT+DEL

This policy setting determines whether a user must press CTRL+ALT+DEL before they can log on. If you disable this policy setting, all users will be required to press CTRL+ALT+DEL before they log on to Windows (unless they use a smart card for Windows logon).

The Interactive logon: Do not require CTRL+ALT+DEL setting is configured to Disabled in the baseline policy for all three environments that are defined in this guide to decrease the chance of an attacker being able to intercept user passwords by means of a Trojan horse program.

Interactive logon: Message text for users attempting to log on

This policy setting specifies a text message that displays to users when they log on. Typically, this text is used for legal reasons—for example, to warn users about the ramifications of unauthorized access, misuse of company information, or that their actions may be audited.

The Interactive logon: Message text for users attempting to log on security option setting is recommended. You should consult with the relevant people in your organization to determine what this text should say.

Note: Both the Interactive logon: Message text for users attempting to log on and the Interactive logon: Message title for users attempting to log on settings must be enabled for either one to work properly.

Interactive logon: Message title for users attempting to log on

This policy setting allows a title to be specified in the title bar of the interactive logon dialog box that displays when users log on to the computer. The reason for this policy setting is the same as that for the Message text for user attempting to log on setting.

Therefore, the Interactive logon: Message title for users attempting to log on setting is recommended. You should consult with the relevant people in your organization to determine what this text should say

Note: Both the Interactive logon: Message text for users attempting to log on and Interactive logon: Message title for users attempting to log on settings must be enabled for either one to work properly.

Interactive logon: Number of previous logons to cache (in case domain controller is not available)

This policy setting determines whether a user can log on to a Windows domain with cached account information. Logon information for domain accounts can be cached locally so that if a domain controller cannot be contacted on subsequent logons, a user can still log on. This capability may allow users to log on after their account has been disabled or deleted, because the workstation does not contact the domain controller. This policy setting determines the number of unique users for whom logon information is cached locally. If you configure this setting to 0, the logon cache is disabled.

The Interactive logon: Number of previous logons to cache (in case domain controller is not available) setting is configured to 0 in the baseline policy for the EC and SSLF environments. In the LC environment, the setting is configured to 1 to allow access for legitimate clients when they are unable to contact the domain controller.

Interactive logon: Prompt user to change password before expiration

This policy setting determines how many days in advance users are warned that their passwords are about to expire. The “Account Policies” section in Chapter 3 recommends that user passwords be configured to expire periodically. If users are not notified when their passwords are about to expire, they may not realize it until the passwords have already expired, which could cause confusion for local users who find it difficult to change their passwords. Unexpected expirations also make it impossible for remote users to log on through dial-up or virtual private networking (VPN) connections.

Therefore, the Interactive logon: Prompt user to change password before expiration setting is configured to the default setting of 14 days in the baseline policy for all three environments that are defined in this guide.

Interactive logon: Require Domain Controller authentication to unlock workstation

For domain accounts, this policy setting determines whether a domain controller must be contacted to unlock a computer. This policy setting addresses a potential vulnerability that is similar to one for the Interactive logon: Number of previous logons to cache (in case domain controller is not available) setting. A user could disconnect the network cable of the server, unlock the server with an old password, and unlock the server without authentication.

To prevent such an occurrence, the Interactive logon: Require Domain Controller authentication to unlock workstation setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

Important: This policy setting applies to computers that run Windows 2000, Windows XP, and Windows Server 2003, but it is not available through the Security Configuration Manager tools on computers that run Windows 2000.

Interactive logon: Require smart card

This policy setting requires users to log on to a computer with a smart card. Security is enhanced when users are required to use long, complex passwords for authentication, especially if they are required to change their passwords regularly. This approach reduces the chance that an attacker will be able to guess a user’s password by means of a brute force attack. However, it is difficult to make users choose strong passwords, and even strong passwords are still vulnerable to brute-force attacks.

The use of smart cards instead of passwords for authentication dramatically increases security, because current technology makes it almost impossible for an attacker to impersonate another user. Smart cards that require personal identification numbers (PINs) provide two-factor authentication: the user must possess the smart card and know its PIN. An attacker who captures the authentication traffic between the user’s computer and the domain controller will find it extremely difficult to decrypt the traffic. Even if they can decrypt the traffic, the next time the user logs onto the network a new session key will be generated to encrypt traffic between the user and the domain controller.

Microsoft encourages organizations to migrate to smart cards or other strong authentication technologies. However, you should only enable the Interactive logon: Require smart card setting if smart cards are already deployed. For this reason, this policy setting is configured to Not defined in the baseline policy for the LC and EC environments. This policy setting is configured to Disabled in the baseline policy for the SSLF environment.

Interactive logon: Smart card removal behavior

This policy setting determines what happens when the smart card for a logged-on user is removed from the smart card reader. If you configure this setting to Lock Workstation, the workstation is locked when the smart card is removed, which allows users to leave the area and take their smart cards with them. If you configure this setting to Force Logoff, the user is automatically logged off when the smart card is removed.

The Interactive logon: Smart card removal behavior setting is configured to Not defined in the baseline policy for the LC environment and to Lock Workstation for the EC and SSLF environments.

Microsoft Network Client Settings

Table 4.17 Security Options: Microsoft Network Client Setting Recommendations

Microsoft network client: Digitally sign communications (always)

This policy setting determines whether packet signing is required by the SMB client component. If you enable this setting, Microsoft network clients will not be able to communicate with a Microsoft network server unless that server agrees to perform SMB packet signing. In mixed environments with legacy clients you should set this option to Disabled, because these clients will not be able to authenticate or gain access to domain controllers. However, you can use this setting in environments that run Windows 2000, Windows XP, and Windows Server 2003. The EC and SSLF environments that are defined in this guide only contain computers that run these operating systems, all of which support digital signatures.

Therefore, to increase communications security between computers in this environment, the Microsoft network client: Digitally sign communications (always) setting is configured to Enabled in the baseline policy for the EC and SSLF environments.

Microsoft network client: Digitally sign communications (if server agrees)

This policy setting determines whether the SMB client will attempt to negotiate SMB packet signatures. The implementation of digital signatures in Windows networks helps to prevent sessions from being hijacked. If you enable this policy setting, the Microsoft network clients on member servers will request signatures only if the servers with which they communicate accept digitally signed communication.

The Microsoft network client: Digitally sign communications (if server agrees) setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

Microsoft network client: Send unencrypted password to third-party SMB servers

If you enable this policy setting, the SMB redirector is allowed to send plaintext passwords to non-Microsoft SMB servers that do not support password encryption during authentication.

The Microsoft network client: Send unencrypted password to third-party SMB servers setting is configured to the default value of Disabled in the baseline policy for the three environments that are defined in this guide, unless application requirements supersede the need to maintain secret passwords.

Microsoft Network Server Settings

Table 4.18 Security Options: Microsoft Network Server Setting Recommendations

Microsoft network server: Amount of idle time required before suspending session

This policy setting determines the amount of continuous idle time that must pass in an SMB session before the session is suspended because of inactivity. Administrators can use this policy setting to control when a computer suspends an inactive SMB session. If client activity resumes, the session is automatically reestablished.

The Microsoft network server: Amount of idle time required before suspending session setting is configured to 15 minutes in the baseline policy for all three environments that are defined in this guide.

Microsoft network server: Digitally sign communications (always)

This policy setting determines whether packet signing is required by the SMB server component before further communication with an SMB client is permitted. Windows 2000 Server, Windows 2000 Professional, Windows Server 2003, and Windows XP Professional include versions of SMB that support mutual authentication, which prevents attempts to hijack sessions and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication because it places a digital signature into each SMB packet, which is then verified by both the client and the server. When computers are configured to ignore all unsigned SMB communications, legacy applications and operating systems will be unable to connect. If all SMB signing is completely disabled, computers are vulnerable to attacks that attempt to hijack their communications sessions.

The Microsoft network server: Digitally sign communications (always) setting is configured to Disabled in the baseline policy for the LC and environment and to Enabled for the EC and SSLF environments.

Microsoft network server: Digitally sign communications (if client agrees)

This policy setting determines whether the SMB server will negotiate SMB packet signing with clients that request it. Windows 2000 Server, Windows 2000 Professional, Windows Server 2003, and Windows XP Professional include versions of SMB that support mutual authentication, which blocks attempts to hijack sessions and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication because it places a digital signature into each SMB packet, which is then verified by both the client and the server. When computers are configured to ignore all unsigned SMB communications, legacy applications and operating systems will be unable to connect. If all SMB signing is completely disabled, computers are vulnerable to attacks that attempt to hijack their communications sessions.

The Microsoft network server: Digitally sign communications (if client agrees) setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

Microsoft network server: Disconnect clients when logon hours expire

This policy setting determines whether to disconnect users who are connected to a network computer outside of their user account's valid logon hours. This policy setting affects the SMB component. If your organization has configured logon hours for users, then it makes sense to enable this policy setting. Otherwise, users should not be able to access network resources outside of their logon hours or they may be able to continue to use those resources with sessions that were established during allowed hours.

The Microsoft network server: Disconnect clients when logon hours expire setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

Network Access Settings

Table 4.19 Security Options: Network Access Setting Recommendations

Network access: Allow anonymous SID/name translation

This policy setting determines whether an anonymous user can request SID attributes for another user. If this policy setting is enabled, a user with local access could use the well-known Administrators SID to obtain the real name of the built-in Administrator account, even if the account has been renamed. That person could then use the account to initiate a password guessing attack.

The Network access: Allow anonymous SID/Name translation setting is configured to Not defined in the baseline policy for the LC and EC environments. This policy setting is configured to Disabled in the baseline policy for the SSLF environment.

Network access: Do not allow anonymous enumeration of SAM accounts

This policy setting determines what additional permissions will be granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerate the names of domain accounts. This capability is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. However, even if this setting is enabled, anonymous users will still have access to any resources that have permissions that explicitly include the special built-in group ANONYMOUS LOGON.

The Network access: Do not allow anonymous enumeration of SAM accounts setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

Network access: Do not allow anonymous enumeration of SAM accounts and shares

This policy setting determines whether anonymous enumeration of SAM accounts and shares is allowed.

The Network access: Do not allow anonymous enumeration of SAM accounts and shares setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

Network access: Do not allow storage of credentials or .NET Passports for network authentication

This policy setting determines whether settings for Stored User Names and Passwords will save passwords, credentials, or Microsoft .NET Passports for later use after domain authentication is achieved.

The Network access: Do not allow storage of credentials or .NET Passports for network authentication setting is configured to Enabled in the baseline policy for all three security environments that are defined in this guide.

Note: Changes that are made to the configuration of this policy setting will not take effect until you restart Windows.

Network access: Let Everyone permissions apply to anonymous users

This policy setting determines what additional permissions are granted for anonymous connections to the computer. If you enable this policy setting, anonymous Windows users will be able to perform certain activities, such as enumerate the names of domain accounts and network shares. An unauthorized user could anonymously list account names and shared resources and use the information to guess passwords or perform social engineering attacks.

Therefore, the Network access: Let Everyone permissions apply to anonymous users setting is configured to Disabled in the baseline policy for all three environments that are defined in this guide.

Note: Domains that have this policy setting enabled will be unable to establish or maintain trusts with Windows NT 4.0 domains or domain controllers.

Network access: Named Pipes that can be accessed anonymously

This policy setting determines which communication sessions (named pipes) will have attributes and permissions that allow anonymous access.

You should enforce the default values for the Network access: Named Pipes that can be accessed anonymously setting in the SSLF environment. The default values consist of the following named pipes:

• COMNAP – SNA session access
• COMNODE – SNA session access
• SQL\QUERY – SQL instance access
• SPOOLSS – Spooler service
• LLSRPC – License Logging service
• Netlogon – Net Logon service
• Lsarpc – LSA access
• Samr – SAM access
• browser – Computer Browser service

Important: If you need to enable this policy setting, ensure that you only add the named pipes that are needed to support the applications in your environment. As with all recommended settings in this guide, you should carefully test this policy setting before you deploy it in a production environment.

Network access: Remotely accessible registry paths

This policy setting determines which registry paths can be accessed over the network.

The Network access: Remotely accessible registry paths setting is configured to its default value in the baseline security templates for all three security environments that are defined in this guide.

Note: Even if you configure this policy setting, you must also start the Remote Registry system service if authorized users need to be able to access the registry over the network.

Network access: Remotely accessible registry paths and sub-paths

This policy setting determines which registry paths and sub-paths can be accessed over the network.

The default values for the Network access: Remotely accessible registry paths and sub-paths setting are enforced in the baseline security templates for all three security environments that are defined in this guide. The default values consist of the following paths and sub-paths:

• System\CurrentControlSet\Control\Print\Printers
• System\CurrentControlSet\Services\Eventlog
• Software\Microsoft\OLAP Server
• Software\Microsoft\Windows NT\CurrentVersion\Print
• Software\Microsoft\Windows NT\CurrentVersion\Windows
• System\CurrentControlSet\Control\ContentIndex
• System\CurrentControlSet\Control\Terminal Server
• System\CurrentControlSet\Control\Terminal Server\UserConfig
• System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration
• Software\Microsoft\Windows NT\CurrentVersion\Perflib
• System\CurrentControlSet\Services\SysmonLog

Network access: Restrict anonymous access to Named Pipes and Shares

This policy setting can be used to restrict anonymous access to shares and named pipes in the following settings:

• Network access: Named pipes that can be accessed anonymously
• Network access: Shares that can be accessed anonymously

The Network access: Restrict anonymous access to Named Pipes and Shares setting is configured to the default setting of Enabled in the baseline policy for all three environments that are defined in this guide.

Network access: Shares that can be accessed anonymously

This policy setting determines which network shares can be accessed by anonymous users. The default configuration for this setting has little impact, because all users must be authenticated before they can access shared resources on the server.

The Network access: Shares that can be accessed anonymously setting is configured to Not defined for the LC and EC environments and to None for the SSLF environment.

Note: This policy setting can be very dangerous, because any shares that are listed can be accessed by any network user. Sensitive data could be exposed or corrupted if this policy setting is enabled.

Network access: Sharing and security model for local accounts

This policy setting determines how network logons that use local accounts are authenticated. The Classic configuration allows fine control over access to resources, and allows you to provide different types of access to different users for the same resource. The Guest only setting allows you to treat all users equally. In this context, all users authenticate as Guest only to receive the same access level to a given resource.

The Network access: Sharing and security model for local accounts setting is configured to the default configuration of Classic in the baseline policy for all three environments that are defined in this guide.

Network Security Settings

Table 4.20 Security Options: Network Security Setting Recommendations

Network security: Do not store LAN Manager hash value on next password change

This policy setting determines whether the LAN Manager (LM) hash value for the new password is stored when the password is changed. The LM hash is relatively weak and prone to attack compared to the cryptographically stronger Windows NT hash.

For this reason, the Network security: Do not store LAN Manager hash value on next password change setting is configured to Enabled in the baseline policy for all three security environments that are defined in this guide.

Note: Very old legacy operating systems and some applications may fail when this policy setting is enabled. Also, you will need to change the password on all accounts after this policy setting is enabled.

Network security: LAN Manager authentication level

This policy setting determines which challenge/response authentication protocol is used for network logons. This choice affects the level of authentication protocol that is used by client computers, the level of security that is negotiated, and the level of authentication that is accepted by servers as follows. The numbers in the following table are the actual settings for the LMCompatibilityLevel registry value.

Table 4.21 LMCompatibilityLevel Registry Value Settings

You should configure this policy setting to the highest level that your environment allows according to the following guidelines:

In an environment that includes only Windows NT 4.0 SP4, Windows 2000, and Windows XP Professional, configure this policy setting to Send NTLMv2 response only\refuse LM & NTLM on all clients, and then to Send NTLMv2 response only\refuse LM & NTLM on all servers after all clients are configured. The exception to this recommendation is Windows Server 2003 Routing and Remote Access servers, which will not function properly if this policy setting is configured higher than Send NTLMv2 response only\refuse LM.

The EC environment may need to support Routing and Remote Access servers, therefore the Network security: LAN Manager authentication level setting for this environment is configured to Send NTLMv2 response only\refuse LM in the baseline policy. Routing and Remote Access servers are not supported in the SSLF environment, so the policy setting for this environment is configured to Send NTLMv2 response only\refuse LM & NTLM.

If you have Windows 9x clients on which you can install the DSClient, configure this policy setting to Send NTLMv2 response only\refuse LM & NTLM on computers that run Windows NT (Windows NT, Windows 2000, and Windows XP Professional). Otherwise, you must leave this policy setting configured to no higher than Send NTLMv2 responses only in the baseline policy for computers that do not run Windows 9x, which is how the setting is configured for the LC environment.

If you find applications that break when this policy setting is enabled, roll it back one step at a time to discover what breaks. At a minimum, you should configure this policy setting to Send LM & NTLM – use NTLMv2 session security if negotiated in the baseline policy on all computers. Typically, you can configure it to Send NTLMv2 responses only on all computers in the environment.

Network security: LDAP client signing requirements

This policy setting determines the level of data signing that is requested on behalf of clients that issue LDAP BIND requests. Unsigned network traffic is susceptible to man-in-the-middle attacks. For an LDAP server, an attacker could cause a server to make decisions that are based on false queries from the LDAP client.

Therefore, the Network security: LDAP client signing requirements setting is configured to Negotiate signing in the baseline policy for all three environments that are defined in this guide.

Network security: Minimum session security for NTLM SSP based (including secure RPC) clients

This policy setting allows a client to require the negotiation of message confidentiality (encryption), message signing, 128-bit encryption, or NTLM version 2 (NTLMv2) session security. Configure this policy setting to as high a security level as possible, but remember that you still need to allow the applications on the network to function. Proper configuration of this policy setting will help ensure that network traffic from NTLM SSP–based servers is protected from man-in-the-middle attacks and data exposure.

The Network security: Minimum session security for NTLM SSP based (including secure RPC) clients setting is configured to No minimum in the baseline policy for the LC environment. All settings are enabled for the EC and SSLF environments.

Network security: Minimum session security for NTLM SSP based (including secure RPC) servers

This policy setting allows a server to require the negotiation of message confidentiality (encryption), message integrity, 128-bit encryption, or NTLMv2 session security. Configure this policy setting to as high a security level as possible, but remember that you still need to allow the applications on the network to function. Like the previous policy setting, proper configuration of this policy setting will help ensure that network traffic from NTLM SSP–based clients is protected from man-in-the-middle attacks and data exposure.

The Network security: Minimum session security for NTLM SSP based (including secure RPC) servers security option setting is configured to No minimum in the baseline policy for the LC environment. All settings are enabled for the EC and SSLF environments.

Recovery Console Settings

Table 4.22 Security Options: Recovery Console Setting Recommendations

Recovery console: Allow automatic administrative logon

This policy setting determines whether the password for the Administrator account must be entered before computer access is granted. If you enable this policy setting, the Recovery Console does not require you to provide a password, and it automatically logs on to the computer. The Recovery Console can be very useful when you need to work with computers that have startup problems. However, it can be detrimental to enable this setting because anyone can then walk up to the server, disconnect its power to shut it down, restart it, select Recover Console from the Restart menu, and then assume full control of the server.

Therefore, the Recovery console: Allow automatic administrative logon setting is configured to the default setting of Disabled in the baseline policy for all three environments that are defined in this guide. To use the Recovery Console when this setting is disabled, the user will have to enter a user name and password to access the Recovery Console account.

Recovery console: Allow floppy copy and access to all drives and all folders

You can enable this policy setting to make the Recovery Console SET command available, which allows you to set the following Recovery Console environment variables:

• AllowWildCards. Enables wildcard support for some commands (such as the DEL command).
• AllowAllPaths. Allows access to all files and folders on the computer.
• AllowRemovableMedia. Allows files to be copied to removable media, such as a floppy disk.
• NoCopyPrompt. Does not prompt when overwriting an existing file.

For maximum security, the Recovery console: Allow floppy copy and access to all drives and all folders setting is configured to Disabled in the baseline policy for the SSLF environment. However, this policy setting is configured to Enabled for the LC and EC environments.

Shutdown Settings

Table 4.23 Security Options: Shutdown Setting Recommendations

Shutdown: Allow system to be shut down without having to log on

This policy setting determines whether a computer can be shut down by a user who is not required to log on to the Windows operating system. Users who can access the console could shut down the computer. An attacker or misguided user could connect to the server through Terminal Services and shut it down or restart it without having to identify themselves.

Therefore, the Shutdown: Allow system to be shut down without having to log on setting is configured to the default setting of Disabled in the baseline policy for all three environments that are defined in this guide.

Shutdown: Clear virtual memory page file

This policy setting determines whether the virtual memory pagefile is cleared when the computer is shut down. When this policy setting is enabled, it causes the system pagefile to be cleared each time that the computer shuts down gracefully. If you enable this policy setting, the hibernation file (Hiberfil.sys) is also zeroed out when hibernation is disabled on a portable computer. Server shutdowns and restarts will take longer and will be especially noticeable on servers with large pagefiles.

For these reasons, the Shutdown: Clear virtual memory page file setting is configured to Disabled in all three environments that are defined in this guide.

Note: An attacker who has physical access to the server could simply unplug the server from its power source to bypass this countermeasure.

System Cryptography Settings

Table 4.24 Security Options: System Cryptography Setting Recommendations

System cryptography: Force strong key protection for user keys stored on the computer

This policy setting determines whether users' private keys (such as their S-MIME keys) require a password to be used. If you configure this policy setting so that users must provide a password—distinct from their domain password—every time that they use a key, then it will be more difficult for an attacker to access locally stored keys, even an attacker who discovers logon passwords.

For usability requirements in the LC and EC environments, the System cryptography: Force strong key protection for user keys stored on the computer setting is configured to User is prompted when the key is first used in the baseline policy. To provide additional security, this policy setting is configured to User must enter a password each time they use a key for the SSLF environment.

System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

This policy setting determines whether the Transport Layer Security/Secure Sockets Layer (TLS/SSL) Security Provider supports only the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. Although this policy setting increases security, most public Web sites that are secured with TLS or SSL do not support these algorithms. Many client computers are also not configured to support these algorithms.

For these reasons, the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing setting is configured to Disabled in the baseline policy for the LC and EC environments. This policy setting is configured to Enabled for the SSLF environment.

System Objects Settings

Table 4.25 Security Options: System Objects Setting Recommendations

System objects: Default owner for objects created by members of the Administrators group

This policy setting determines whether the Administrators group or an object creator is the default owner of any system objects that are created. When system objects are created, the ownership will reflect which account created the object rather than the more generic Administrators group.

The System objects: Default owner for objects created by members of the Administrators group setting is configured to Object creator in the baseline policy for all three environments that are defined in this guide.

System objects: Require case insensitivity for non-Windows subsystems

This policy setting determines whether case insensitivity is enforced for all subsystems. The Microsoft Win32® subsystem is case insensitive. However, the kernel supports case sensitivity for other subsystems, such as the Portable Operating System Interface for UNIX (POSIX). Because Windows is case insensitive and the POSIX subsystem supports case sensitivity, failure to enforce this setting makes it possible for a POSIX user to create a file with the same name as another file if they use mixed case letters to label it. Such an occurrence may block another user's access to these files with typical Win32 tools, because only one of the files will be available.

To ensure consistency of file names, the System objects: Require case insensitivity for non-Windows subsystems setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)

This policy setting determines the strength of the default discretionary access control list (DACL) for objects, and helps secure objects that can be located and shared among processes. To strengthen the DACL you can use the default value of Enabled, which it allows users who are not administrators to read shared objects but not to modify any that they did not create.

The System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links) setting is configured to the default value of Enabled in the baseline policy for all three environments that are defined in this guide.

System Settings

Table 4.26 Security Options: System Setting Recommendations

System settings: Optional subsystems

This policy setting determines which subsystems are used to support applications in your environment. The default value for this policy setting in Windows Server 2003 is POSIX.

To disable the POSIX subsystem, the System settings: Optional subsystems setting is configured to None in the baseline policy for all three environments that are defined in this guide.

System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies

This policy setting determines whether digital certificates are processed when software restriction policies are enabled and a user or process attempts to run software with an .exe file name extension. It enables or disables certificate rules (a type of software restriction policies rule). With software restriction policies, you can create a certificate rule that will allow or disallow the execution of Authenticode®-signed software, based on the digital certificate that is associated with the software. For certificate rules to take effect in software restriction policies, you must enable this policy setting.

The System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies setting is configured to Enabled in the SSLF environment. However, it is configured to Disabled in the EC environment and to Not defined in the LC environment because of the potential performance impact.

Event Log

The event log records events on the computer, and the Security log records audit events. The event log container of Group Policy is used to define attributes of the Application, Security, and System event logs, such as maximum log size, access rights for each log, and retention settings and methods. The settings for the Application, Security, and System event logs are configured in the MSBP and applied to all member servers in the domain.

You can configure the event log settings in Windows Server 2003 with SP1 at the following location within the Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Event Log

This section provides details about the prescribed MSBP event log settings for all three environments that are defined in this guide. For a summary of the prescribed settings in this section, see the Microsoft Excel workbook "Windows Server 2003 Security Guide Settings," which is available in the downloadable version of this guide. For information about the default configuration and a detailed explanation of each of the settings, see the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP, which is available at https://go.microsoft.com/fwlink/?LinkId=15159.

The following table summarizes the event log setting recommendations for the three environments that are defined in this guide. Additional information about each setting is provided in the subsections that follow the table.

Table 4.27 Event Log Setting Recommendations

Maximum application log size

This policy setting specifies the maximum size of the Application event log, which has a maximum capacity of 4 GB. However, this size is not recommended because of the risk of memory fragmentation, which causes slow performance and unreliable event logging. Requirements for the Application log size vary, and depend on the function of the platform and the need for historical records of application-related events.

The Maximum application log size setting is configured to the default value of 16,384 KB in the baseline policy for all three environments that are defined in this guide.

Maximum security log size

This policy setting specifies the maximum size of the Security event log, which has a maximum capacity of 4 GB. You should configure the Security log to at least 80 MB on domain controllers and stand-alone servers, which should adequately store enough information to conduct audits. How you configure this policy setting for other computers depends on factors that include how frequently the log will be reviewed, available disk space, and so on.

The Maximum security log size security setting is configured to 81,920 KB in the baseline policy for all three environments that are defined in this guide.

Maximum system log size

This policy setting specifies the maximum size of the System event log, which has a maximum capacity of 4 GB. However, this size is not recommended because of the risk of memory fragmentation, which causes slow performance and unreliable event logging. Requirements for the System log size vary, and depend on the function of the platform and the need for historical records.

The Maximum system log size setting is configured to the default value of 16,384 KB in the baseline policy for all three environments that are defined in this guide.

Prevent local guests group from accessing application log

This policy setting determines whether guests are denied access to the Application event log. By default in Windows Server 2003 with SP1, guest access is prohibited on all computers. Therefore, this policy setting has no real effect on computers with default configurations.

However, because this configuration is considered a defense-in-depth measure with no side effects, the Prevent local guests group from accessing application log setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

Note: This setting does not appear in the Local Computer Policy object.

Prevent local guests group from accessing security log

This policy setting determines whether guests are denied access to the Security event log. A user must be assigned the Manage auditing and security log user right (not defined in this guidance) to access the Security log. Therefore, this policy setting has no real effect on computers with default configurations.

However, because this configuration is considered a defense-in-depth measure with no side effects, the Prevent local guests group from accessing security log setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

Note: This setting does not appear in the Local Computer Policy object.

Prevent local guests group from accessing system log

This policy setting determines whether guests are denied access to the System event log. By default in Windows Server 2003 with SP1, guest access is prohibited on all computers. Therefore, this policy setting has no real effect on computers with default configurations.

However, because this configuration is considered a defense-in-depth setting measure with no side effects, the Prevent local guests group from accessing system log setting is configured to Enabled in the baseline policy for all three environments that are defined in this guide.

Note: This setting does not appear in the Local Computer Policy object.

Retention method for application log

This policy setting determines the "wrapping" method for the Application log. It is imperative that the Application log be archived regularly if historical events are needed for either forensics or troubleshooting purposes. If events are overwritten as needed, the log will always store the most recent events—although this configuration could result in a loss of historical data.

The Retention method for application log setting is configured to As needed in the baseline policy for all three environments that are defined in this guide.

Retention method for security log

This policy setting determines the "wrapping" method for the Security log. It is imperative that the Security log be archived regularly if historical events are needed for either forensics or troubleshooting purposes. If events are overwritten as needed, the log will always store the most recent events—although this configuration could result in a loss of historical data.

The Retention method for security log setting is configured to As needed in the baseline policy for all three environments that are defined in this guide.

Retention method for system log

This policy setting determines the "wrapping" method for the System log. It is imperative that the logs be archived regularly if historical events are needed for either forensics or troubleshooting purposes. If events are overwritten as needed, the log will always store the most recent events—although this configuration could result in a loss of historical data.

The Retention method for system log setting is configured to As needed in the baseline policy for all three environments that are defined in this guide.

Additional Registry Entries

Additional registry entries (also called registry values) were created for the baseline security template files that are not defined within the default Administrative Template (.adm) file for the three security environments that are defined in this guide. The .adm files define the policies and restrictions for the desktop, shell, and security for Windows Server 2003.

These registry entries are embedded within the security templates (in the "Security Options" section) to automate the changes. If the policy is removed, these registry entries are not automatically removed with it; they must be manually changed with a registry editing tool such as Regedt32.exe. The same registry entries are applied across all three environments.

This guide includes additional registry entries that are added to the Security Configuration Editor (SCE). To add these registry entries, you need to modify the Sceregvl.inf file (located in the %windir%\inf folder) and re-register the Scecli.dll file. The original security entries, as well as the additional ones, appear under Local Policies\Security in the snap-ins and tools that are listed earlier in this chapter. You will need to update the Sceregvl.inf file and re-register the Scecli.dll file for any computers on which you will edit the security templates and Group Policies that are provided with this guide. Details about how to update these files are provided in the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP, which is available at https://go.microsoft.com/fwlink/?LinkId=15159.

This section is only a summary of the additional registry entries that are described in detail in the companion guide. For information about the default settings and a detailed explanation of each of the settings that are discussed in this section, see Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP.

Security Consideration for Network Attacks

Denial of service (DoS) attacks are network attacks that attempt to make a computer or a particular service on a computer unavailable to network users. DoS attacks can be difficult to defend against.

To help prevent these attacks, you should keep your computer updated with the latest security fixes and harden the TCP/IP protocol stack on computers that run Windows Server 2003 with SP1 and are exposed to potential attackers. The default TCP/IP stack configuration is tuned to handle standard intranet traffic. If you connect a computer directly to the Internet, Microsoft recommends that you harden the TCP/IP stack against DoS attacks.

You can add the registry values in the following table to the template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\

subkey.

Table 4.28 TCP/IP Registry Entry Recommendations

Other Registry Entries

Other recommended registry entries that are not specific to TCP/IP are listed in the following table. Additional information about each entry is provided in the subsections that follow the table.

Table 4.29 Other Registry Entry Recommendations

Configure NetBIOS Name Release Security: Allow the computer to ignore NetBIOS name release requests except from WINS servers

This entry appears as MSS: (NoNameReleaseOnDemand) Allow the computer to ignore NetBIOS name release requests except from WINS servers in the SCE.

NetBIOS over TCP/IP is a network protocol that (among other things) provides a way to easily resolve NetBIOS names that are registered on Windows-based computers to the IP addresses that are configured on those computers. This value determines whether the computer releases its NetBIOS name when it receives a name-release request.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters\

subkey.

Disable Auto Generation of 8.3 File Names: Enable the computer to stop generating 8.3 style filenames

This entry appears as MSS: (NtfsDisable8dot3NameCreation) Enable the computer to stop generating 8.3 style filenames (recommended) in the SCE.

Windows Server 2003 with SP1 supports 8.3 file name formats for backward compatibility with16-bit applications. The 8.3 file name convention is a format that only allows file names of eight characters or less.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\

subkey.

Disable Autorun: Disable Autorun for all drives

This entry appears as MSS: (NoDriveTypeAutoRun) Disable Autorun for all drives (recommended) in the SCE.

Autorun begins to read from a drive on your computer as soon as media is inserted into it. As a result, things like the setup file (for programs) or the sound (for audio content) start immediately.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\

subkey.

Make Screensaver Password Protection Immediate: The time in seconds before the screen saver grace period expires (0 recommended)

This entry appears as MSS: (ScreenSaverGracePeriod) The time in seconds before the screen saver grace period expires (0 recommended) in the SCE.

Windows includes a grace period between when the screen saver is launched and when the console is actually locked automatically when screen saver locking is enabled.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\

subkey.

Security Log Near Capacity Warning: Percentage threshold for the security event log at which the system will generate a warning

This entry appears as MSS: (WarningLevel) Percentage threshold for the security event log at which the system will generate a warning in the SCE.

This option became available with SP3 for Windows 2000. It generates a security audit in the Security log when its size reaches a user-defined threshold. For example, if you configure the value for this registry entry to 90 and the Security log reaches 90 percent of capacity, the log will show one entry with an eventID of 523 that reads as follows: “The security event log is 90 percent full.”

Note: If you configure log settings to Overwrite events as needed or Overwrite events older than x days, this event will not be generated.

You can add this registry value to the security template file in the

HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\Eventlog\Security\

subkey.

Enable Safe DLL Search Order: Enable Safe DLL search mode (recommended)

This entry appears as MSS: (SafeDllSearchMode) Enable Safe DLL search mode (recommended) in the SCE.

The DLL search order can be configured to search for DLLs that are requested by running processes in one of two ways:

• Search folders that are specified in the system path first, and then search the current working folder.
• Search the current working folder first, and then search the folders that are specified in the system path.

The registry value is configured to 1, which causes the computer to first search the folders that are specified in the system path and then the current working folder. If you configure this entry to 0, the computer first searches the current working folder and then the folders that are specified in the system path.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\Session Manager\

subkey.

Automatic Reboot: Allow Windows to automatically restart after a system crash

This entry appears as MSS: (AutoReboot) Allow Windows to automatically restart after a system crash (recommended except for highly secure environments) in the SCE.

This entry, when enabled, permits a server to automatically reboot after a fatal crash. It is enabled by default, which is undesirable on highly secure servers.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl\

subkey.

Automatic Logon: Enable Automatic Logon

This entry appears as MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended) in the SCE. By default, this entry is not enabled and should never be used on a server in practically any conceivable circumstance.

For more information, see the Microsoft Knowledge Base article "How to turn on automatic logon in Windows XP" at https://support.microsoft.com/default.aspx?kbid=315231.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\

subkey.    

Administrative Shares: Enable Administrative Shares

This entry appears as MSS: (AutoShareWks) Enable Administrative Shares (recommended except for highly secure environments) in the SCE. By default, when Windows networking is active on a server, Windows will create hidden administrative shares—which is undesirable on highly secure servers.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\Parameters\

subkey.

Disable Saved Passwords: Prevent the dial-up password from being saved

This entry appears as MSS: (DisableSavePassword) Prevent the dial-up password from being saved (recommended) in the SCE. By default, Windows will offer the option to save passwords for dial-up and VPN connections, which is not desirable on a server.

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\

subkey.

Enable IPSec to protect Kerberos RSVP Traffic: Enable NoDefaultExempt for IPSec Filtering

This entry appears as MSS: (NoDefaultExempt) Enable NoDefaultExempt for IPSec Filtering (recommended) in the SCE. The default exemptions to IPsec policy filters are documented in the Microsoft Windows Server 2003 online help. These filters make it possible for Internet Key Exchange (IKE) and the Kerberos authentication protocol to function. The filters also make it possible for the network Quality of Service (QoS) to be signaled (RSVP) when the data traffic is secured by IPsec, and for traffic that IPsec might not secure (such as multicast and broadcast traffic).

You can add this registry value to the template file in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSEC\

subkey.

Restricted Groups

The Restricted Groups capability allows you to manage group membership through policy mechanisms and prevent either deliberate or inadvertent exploitation of groups that have powerful user rights. You should first review the needs of your organization to determine the groups that you want to restrict.

The Backup Operators and Power Users groups are restricted in all three environments that are defined in this guide. Although members of the Backup Operators and Power Users groups have less access than members in the Administrators group, they still have powerful capabilities.

Note: If your organization uses any of these groups, then carefully control their membership and do not implement the guidance for the Restricted Groups setting. If your organization adds users to the Power Users group, you may want to implement the optional file system permissions that are described in the following “Securing the File System” section.

You can configure the Restricted Groups setting in Windows Server 2003 with SP1 at the following location within the Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Restricted Groups\

Administrators may configure restricted groups by adding the desired group directly to the MSBP. When a group is restricted, you can define its members and any other groups to which it belongs. If you do not specify these group members, the group remains totally restricted.

Securing the File System

The NTFS file system has been improved with each new version of Microsoft Windows, and the default permissions for NTFS are adequate for most organizations. The settings that are discussed in this section are provided for optional use by organizations that do not use restricted groups but still wish to have an additional level of hardening on their servers.

You can configure the file system security settings at the following location in the Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\File System

Note: You should thoroughly test any changes to the default file system security settings in a lab environment before you deploy them in a large organization. There have been cases in which file permissions have been altered to a point that required the affected computers to be completely rebuilt.

The default file permissions in Windows Server 2003 with SP1 are sufficient for most situations. However, if you do not plan to block membership of the Power Users group with the Restricted Groups feature or if you plan to enable the Network access: Let Everyone permissions apply to anonymous users setting, you may want to apply the optional permissions that are described in the paragraph that follows. They are very specific, and they apply additional restrictions to certain executable tools that a malicious user with elevated privileges may use to further compromise the computer or network.

Note how these changes do not affect multiple folders or the root of the system volume. It can be very risky to change permissions in that manner, and doing so can often cause computer instability. All of the following files are located in the %SystemRoot%\System32\ folder, and they are all given the following permissions: Administrators: Full Control, System: Full Control.

• regedit.exe
• arp.exe
• at.exe
• attrib.exe
• cacls.exe
• debug.exe
• edlin.exe
• eventcreate.exe
• eventtriggers.exe
• ftp.exe
• nbtstat.exe
• net.exe
• net1.exe
• netsh.exe
• netstat.exe
• nslookup.exe
• ntbackup.exe
• rcp.exe
• reg.exe
• regedt32.exe
• regini.exe
• regsvr32.exe
• rexec.exe
• route.exe
• rsh.exe
• sc.exe
• secedit.exe
• subst.exe
• systeminfo.exe
• telnet.exe
• tftp.exe
• tlntsvr.exe

For your convenience, these optional permissions are already configured in the security template called Optional-File-Permissions.inf, which is included with the downloadable version of this guide.

Additional Security Settings

Although most of the countermeasures that are used to harden the baseline servers in this guide were applied through Group Policy, there are additional settings that are difficult or impossible to apply with Group Policy. For a detailed explanation of each of the countermeasures discussed in this section, see the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP, which is available at https://go.microsoft.com/fwlink/?LinkId=15159.

Manual Hardening Procedures

This section describes how some additional countermeasures (such as securing accounts) were implemented manually for each of the security environments that are defined in this guide.

Manually Adding Unique Security Groups to User Rights Assignments

Most of the recommended security groups for user rights assignments were configured within the security templates that accompany this guide. However, there are a few rights that cannot be included in the security templates, because the SIDs of the specific security groups are unique between different Windows Server 2003 domains. The problem is that the RID (Relative Identifier), which is part of the SID, is unique. These rights are referenced in the following table.

Warning: The following table contains values for Built-in Administrator. The Built-in Administrator is the built-in user account, not the security group Administrators. If the Administrators security group is added to any of the following deny access user rights, you will need to log on locally to correct the mistake. Also, the Built-in Administrator account may have a new name if you followed the recommendation to rename it earlier in this guide. When you add this account to any deny access user rights, make sure that you select the newly renamed administrator account.

Table 4.30 Manually Added User Rights Assignments

Important: All NON-operating system service accounts are service accounts for specific applications in your enterprise. These accounts do not include LOCAL SYSTEM, LOCAL SERVICE, or the NETWORK SERVICE accounts that are built-in accounts for the operating system.

To manually add the listed security groups to the Enterprise Client - Member Server Baseline Policy, complete the following steps.

To add security groups to the User Rights Assignments

In Active Directory Users and Computers, right-click the Member Servers OU, and then select Properties.

1. On the Group Policy tab, select the Enterprise Client Member Server Baseline Policy to edit the linked GPO.
2. Select Enterprise Client – Member Server Baseline Policy, and then click Edit.
3. In the Group Policy window, click Computer Configuration\Windows Settings\Security Setting\Local Policies\User Rights Assignment to add the unique security groups from the previous table for each right.
4. Close the Group Policy that you modified.
5. Close the Member Servers OU Properties window.
6. Force replication between the domain controllers so that all have the policy applied to them by doing the following:
   1. Open a command prompt, type gpupdate /Force and press ENTER to force the server to refresh the policy.
   2. Reboot the server.
7. 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.

Securing Well-Known Accounts

Windows Server 2003 with SP1 has a number of built-in user accounts that cannot be deleted but can be renamed. Two of the most well-known built-in accounts in Windows Server 2003 are Guest and Administrator.

By default, the Guest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built-in Administrator account in an initial attempt to compromise a server. Therefore, the built-in Administrator account is renamed and the description altered to help prevent compromise of a remote server by attackers who try to use this well-known account.

The value of this configuration change has diminished over the past few years since the release of attack tools that specify the SID (security identifier) of the built-in Administrator account to determine its true name and then break in to the server. A SID is the value that uniquely identifies each user, group, computer account, and logon session on a network. It is not possible to change the SID of this built-in account. However, your operations groups can easily monitor attempted attacks against the Administrator account if you rename it with a unique name.

Complete the following steps to secure well-known accounts on domains and servers:

• Rename the Administrator and Guest accounts, and change their passwords to long and complex values on every domain and server.
• Use different names and passwords on each server. If the same account names and passwords are used on all domains and servers, an attacker who gains access to one member server will be able to gain access to all others with the same account name and password.
• Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts.
• Record any changes that you make in a secure location.

Note: The built-in Administrator account can be renamed through Group Policy. This setting was not implemented in the baseline policy because every organization should choose a unique name for this account. However, you can configure the Accounts: Rename administrator account setting to rename administrator accounts in all three environments that are defined in this guide. This policy setting is a part of the Security Options settings of a GPO.

Securing Service Accounts

Never configure a service to run under the security context of a domain account unless it is unavoidable. If the server is physically compromised, domain account passwords could be easily obtained by dumping LSA secrets. For more information about how to secure service accounts, see The Services and Service Accounts Security Planning Guide at https://go.microsoft.com/fwlink/?LinkId=41311.

NTFS

NTFS partitions support ACLs at the file and folder levels. This support is not available with the file allocation table (FAT) or FAT32 file systems. FAT32 is a version of the FAT file system that has been updated to permit significantly smaller default cluster sizes and to support hard disks up to two terabytes in size. FAT32 is included in Windows 95 OSR2, Windows 98, Microsoft Windows Me, Windows 2000, Windows XP Professional, and Windows Server 2003.

Format all partitions on every server with NTFS. Use the convert utility to carefully convert FAT partitions to NTFS, but remember that the convert utility will set the ACLs for the converted drive to Everyone: Full Control.

For computers that run Windows 2003 Server with SP1, apply the following two security templates locally to configure the default file system ACLs for member servers and domain controllers respectively:

• %windir%\inf\defltsv.inf
• %windir%\inf\defltdc.inf

Note: The default domain controller security settings are applied during the promotion of a server to a domain controller.

All partitions on servers in all three environments that are defined in this guide are formatted with NTFS partitions to provide the means for file and directory security management through ACLs.

Terminal Services Settings

The Set client connection encryption level setting determines the level of encryption for Terminal Services client connections in your environment. The High Level setting option that uses 128-bit encryption prevents an attacker from eavesdropping on Terminal Services sessions with a packet analyzer. Some older versions of the Terminal Services client do not support this high level of encryption. If your network contains such clients, set the encryption level of the connection to send and receive data at the highest encryption level that is supported by the client.

You can configure this setting in Group Policy at the following location:

Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Encryption and Security

Table 4.31 Client Connection Encryption Level Setting Recommendation

The three available levels of encryption are described in the following table:

Table 4.32 Terminal Services Encryption Levels

Error Reporting

Table 4.33 Recommended Error Reporting Settings

This service helps Microsoft track and address errors. You can configure this service to generate reports for operating system errors, Windows component errors, or program errors. It is only available in Windows XP Professional and Windows Server 2003.

The Error Reporting service can report such errors to Microsoft through the Internet or to an internal file share. Although error reports can potentially contain sensitive or even confidential data, the Microsoft privacy policy with regard to error reporting ensures that Microsoft will not use such data improperly. However, the data is transmitted in plaintext HTTP, which could be intercepted on the Internet and viewed by third parties.

The Turn off Windows Error Reporting setting can control whether the Error Reporting service transmits any data.

You can configure this policy setting in Windows Server 2003 at the following location within the Group Policy Object Editor:

Computer Configuration\Administrative Templates\System\Internet Communications Management\Internet Communications settings

Configure the Turn off Windows Error Reporting setting to Enabled in the DCBP for all three environments that are defined in this guide.

Enable Manual Memory Dumps

Windows Server 2003 with SP1 includes a feature that you can use to halt the computer and generate a Memory.dmp file. You must explicitly enable this feature, and it may not be appropriate for all servers in your organization. If you determine that it would be valuable to capture memory dumps on some servers, you can follow the instructions that are provided in Windows feature allows a Memory.dmp file to be generated with the keyboard at https://support.microsoft.com/default.aspx?kbid=244139.

Important: When memory is copied to disk as described in the referenced article, sensitive information may be included in the Memory.dmp file. Ideally, all servers are protected from unauthorized physical access. If you generate a memory dump file on a server that is at risk for physical compromise, be sure to delete the dump file after troubleshooting is concluded.

Creating the Baseline Policy Using SCW

To deploy the necessary security settings, you first need to create a member server baseline policy (MSBP). To do so, you must use SCW (the Security Configuration Wizard tool) and the security templates that are included with the downloadable version of this guide.

When you create your own policy, be sure to skip the "Registry Settings" and “Audit Policy” sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SCW.

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 is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference computer.

During the MSBP creation steps you will probably 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 and configure only the mandatory applications that will be on every server in your environment. Examples include your software and management agents, tape backup agents, and antivirus or antispyware utilities.
5. Launch the SCW GUI, 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 server roles are appropriate for your environment.
8. Ensure that the detected client features are appropriate for your environment.
9. Ensure that the detected administrative options are appropriate for your environment.
10. Ensure that any additional services that are required by your baseline, such as backup agents or antivirus software, are detected.
11. 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.
12. Ensure the Skip this section checkbox is unchecked in the "Network Security" section, and then click Next. The appropriate ports and applications identified earlier are configured as exceptions for Windows Firewall.
13. In the "Registry Settings" section, click the Skip this section checkbox and then click Next. These policy settings are imported from the supplied INF file.
14. In the "Audit Policy" section, click the Skip this section checkbox and then click Next. These policy settings are imported from the supplied INF file.
15. Include the appropriate security template (for example, EC-Member Server Baseline.inf).
16. Save the policy with an appropriate name (for example, Member Server Baseline.xml).

Test the Policy Using SCW

After you create and save the policy, Microsoft strongly recommends that you deploy it 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 policy. 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 a policy to a single server at a time, or use Scwcmd to push the policy 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 test process.

The policy is tested to ensure that the application of this policy 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 details about how to test SCW policies, see the Deployment Guide for the Security Configuration Wizard at https://technet2.microsoft.com/WindowsServer/en/Library/5254f8cd-143e-4559-a299-9c723b3669461033.mspx and the Security Configuration Wizard Documentation at https://go.microsoft.com/fwlink/?linkid=43450.

Convert and Deploy the Policy

After you thoroughly test the policy, complete the following steps to convert it into a GPO and deploy it:

1. At the command prompt, type the following command:

   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\
       Member Server Baseline.xml" /g:"Member Server Baseline 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.

Summary

This chapter explained the server hardening procedures that were initially applied to all of the servers that run Windows Server 2003 with SP1 in all three security environments that are defined in this guide. Most of these procedures created a unique security template for each security environment and imported it into a GPO that is linked to the parent OU for the member server to achieve the targeted level of security.

However, some of these hardening procedures cannot be applied through Group Policy. Guidance was provided about how to configure these settings manually. Additional steps were taken for specific server roles to enable them to function within their roles as securely as possible.

Server role-specific steps include both additional hardening procedures and procedures to reduce the security settings in the baseline security policy. These changes are discussed in detail in the following chapters of this guide.

More Information

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

• For more information about Windows Server 2003 security settings, see the Security Setting Descriptions page at https://technet2.microsoft.com/WindowsServer/en/Library/dd980ca3-f686-4ffc-a617-50c6240f55821033.mspx.
• For more information about security for Windows Server 2003, see the Windows Server 2003 Security Center at www.microsoft.com/technet/security/prodtech/windowsserver2003.mspx.
• For more information about audit policy for Windows Server 2003, see the Auditing Policy page at https://technet2.microsoft.com/WindowsServer/en/Library/6847e72b-9c47-42ab-b3e3-691addac9f331033.mspx.
• For more information about Microsoft Operations Manger (MOM), see the Microsoft Operations Manager page at www.microsoft.com/mom/.
• For more information about user rights in Windows Server 2003, see the User rights page at https://technet2.microsoft.com/WindowsServer/en/Library/589980fb-1a83-490e-a745-357750ced3d91033.mspx.
• For more information about default security settings for Windows Server 2003, see the Differences in default security settings page at https://technet2.microsoft.com/WindowsServer/en/Library/1494bf2c-b596-4785-93bb-bc86f8e548d51033.mspx.
• For more information about how to secure Windows 2000 Terminal Services, see “Securing Windows 2000 Terminal Services” at www.microsoft.com/technet/prodtechnol/win2kts/maintain/optimize/secw2kts.mspx.
• For more information about how to secure the Windows Server 2003 TCP/IP stack, see the Microsoft Knowledge Base article "How To Harden the TCP/IP Stack Against Denial of Service Attacks in Windows Server 2003" at https://support.microsoft.com/?kbid=324270.
• For more details about how to harden the settings for Windows Sockets applications, see the Microsoft Knowledge Base article "Internet Server Unavailable Because of Malicious SYN Attacks" at https://support.microsoft.com/?kbid=142641.
• For more information about the location of .adm files, see the Microsoft Knowledge Base article "Location of ADM (Administrative Template) Files in Windows" at https://support.microsoft.com/?kbid=228460.
• For more information about how to customize the Security Configuration Editor user interface, see the Microsoft Knowledge Base article “How to Add Custom Registry Settings to Security Configuration Editor” at https://support.microsoft.com/?kbid=214752.
• For more information about how to create custom administrative template files in Windows, see the Microsoft Knowledge Base article “HOW TO: Create Custom Administrative Templates in Windows 2000” at https://support.microsoft.com/?kbid=323639. Also review the white paper “Using Administrative Template Files with Registry-Based Group Policy” at www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/management/gp/admtgp.mspx.
• For more information about ensuring that more secure LAN Manager authentication level settings work in networks with a mix of Windows 2000 and Windows NT 4.0 computers, see the Microsoft Knowledge Base article "Authentication Problems in Windows 2000 with NTLM 2 Levels Above 2 in a Windows NT 4.0 Domain" at https://support.microsoft.com/?kbid=305379.
• For more information about NTLMv2 authentication, see the Microsoft Knowledge Base article "How to enable NTLM 2 authentication" at https://support.microsoft.com/?kbid=239869.
• For more information about the default settings for services in Windows Server 2003, see the Default settings for services page at https://technet2.microsoft.com/WindowsServer/en/Library/2b1dc6cf-2e34-4681-9aa6-8d0ffba2d3e31033.mspx.
• For more information about smart card deployment, see “Get Smart! Boost Your Network’s IQ With Smart Cards” at www.microsoft.com/technet/technetmag/issues/2005/01/SmartCards/default.aspx.
• For more information about the "Restrict Anonymous" registry value and Windows 2000, see the Microsoft Knowledge Base article “The "RestrictAnonymous" Registry Value May Break the Trust to a Windows 2000 Domain” at https://support.microsoft.com/?kbid=296405.
• For more information about error reporting, see the Corporate Error Reporting page at www.microsoft.com/resources/satech/cer/.
• For information about network ports used by Microsoft applications, see the Microsoft Knowledge Base article "Service overview and network port requirements for the Windows Server system" at https://support.microsoft.com/kb/832017.