Windows Server 2003 Security Guide

On This Page

	Overview
	Windows Server 2003 Baseline Policy
	Audit Policy
	User Rights Assignments
	Security Options
	Event Log
	Additional Registry Entries
	Restricted Groups
	Securing the File System
	Additional Security Settings
	Summary

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 http://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:

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.

Figure 4.1 Existing and planned security environments
See full-sized image

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 http://go.microsoft.com/fwlink/?LinkId=15159.

Figure 4.2 The EC-Member Server Baseline.inf security template is imported into the MSBP, which is then linked to the Member Servers organizational unit (OU)
See full-sized image

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:

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.

Top of page

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.

Top of page

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 http://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:

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:

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:

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

Top of page

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.

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

Top of page

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