Chapter 5: The Domain Controller Baseline Policy

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

Overview

Addressing security in the Domain Controller server role is one of the most important aspects of any environment with computers that run Microsoft® Windows Server™ 2003 with Service Pack 1 (SP1) and the Active Directory® directory service. Any loss or compromise of a domain controller in such an environment could seriously affect client computers, servers, and applications that rely on domain controllers for authentication, Group Policy, and a centralized lightweight directory access protocol (LDAP) directory.

Because of their importance, domain controllers should always be stored in physically secure locations that are accessible only to qualified administrative staff. When domain controllers must be stored in unsecured locations, such as branch offices, several security settings can be adjusted to limit the potential damage from physical threats.

Domain Controller Baseline Policy

Unlike the other server role policies that are detailed later in this guide, the Group Policy for the Domain Controllers server role is a baseline policy like the Member Server Baseline Policy (MSBP) defined in Chapter 4, "The Member Server Baseline Policy." The Domain Controller Baseline Policy (DCBP) is linked to the Domain Controllers organizational unit (OU) and takes precedence over the Default Domain Controllers Policy. The policy settings that are included in the DCBP will strengthen the overall security of all domain controllers in any environment.

Most of the DCBP is copied from the MSBP. Therefore, you should carefully review Chapter 4, "The Member Server Baseline Policy" to fully understand the many policy settings that are also included in the DCBP. Only the DCBP settings that differ from those in the MSBP are documented in this chapter.

Domain controller templates are uniquely designed to address the security needs of the three environments that are defined in this guide. The following table shows the domain controller .inf files that are included with this guide for the Legacy Client (LC), Enterprise Client (EC), and Specialized Security – Limited Functionality (SSLF) environments. For example, the EC-Domain Controller.inf file is the security template for the Enterprise Client environment.

Table 5.1 Domain Controller Baseline Security Templates

Legacy Client Enterprise Client Specialized Security – Limited Functionality

LC-Domain Controller.inf

EC-Domain Controller.inf

SSLF-Domain Controller.inf

Note: Domain operations could be severely impaired if an incorrectly configured Group Policy object (GPO) is linked to the Domain Controllers OU. Use extreme care when you import these security templates, and verify that all imported policy settings are correct before you link a GPO to the Domain Controllers OU.

Audit Policy Settings

The Audit policy settings for domain controllers are almost the same as those specified in the MSBP. For more information, see Chapter 4, "The Member Server Baseline Policy." The policy settings in the DCBP ensure that all the relevant security audit information is logged on the domain controllers.

Table 5.2 Recommended Audit Policy Settings

Setting Legacy Client Enterprise Client Specialized Security – Limited Functionality

Audit directory service access

No auditing

No auditing

Failure

Audit directory service access

This policy setting determines whether to audit user access to an Active Directory object that has its own specified system access control list (SACL). If you define the Audit directory service access setting, you can specify whether to audit successes, failures, or not audit the event type at all. Success audits generate an audit entry when a user successfully accesses an Active Directory object that has a specified SACL. Failure audits generate an audit entry when a user unsuccessfully attempts to access an Active Directory object that has a specified SACL.

If you enable the Audit directory service access setting in the DCBP and configure SACLs on directory objects, a large volume of entries can be generated in the Security logs on domain controllers. You should only enable this setting if you actually intend to use the information that is created.

The Audit directory service access setting is configured to No auditing in the LC and EC environments. It is configured to log Failure events in the SSLF environment.

The following table includes the important security events that the Audit directory service access setting records in the Security log.

Table 5.3 Directory Service Access Events

Event ID Event description

ID

Description

566

A generic object operation took place.

User Rights Assignment Settings

The DCBP specifies a number of user rights assignments for the domain controllers. In addition to the default configuration, several user rights settings were modified to strengthen the security for the domain controllers in the three environments that are defined in this guide.

This section provides details about the prescribed user rights settings for the DCBP that differ from those in the MSBP. For a summary of the prescribed settings in this section, refer to the Microsoft Excel® workbook "Windows Server 2003 Security Guide Settings" that is included with the downloadable version of this guide.

The following table summarizes the recommended user rights assignment settings for the DCBP. Additional information for each setting is provided in the sections that follow the table.

Table 5.4 Recommended User Rights Assignments Settings

Setting Legacy Client Enterprise Client Specialized Security – Limited Functionality

Access this computer from the network

Not defined

Not defined

Administrators, Authenticated Users, ENTERPRISE DOMAIN CONTROLLERS

Add workstations to domain

Not defined

Not defined

Administrators

Allow log on locally

Administrators, Server Operators, Backup Operators

Administrators, Server Operators, Backup Operators

Administrators

Allow log on through Terminal Services

Administrators

Administrators

Administrators

Change the system time

Administrators, LOCAL SERVICE

Administrators, LOCAL SERVICE

Administrators, LOCAL SERVICE

Enable computer and user accounts to be trusted for delegation

Not Defined

Not Defined

Administrators

Load and unload device drivers

Administrators

Administrators

Administrators

Restore files and directories

Administrators

Administrators

Administrators

Shutdown the system

Administrators

Administrators

Administrators

Access this computer from the network

This policy setting determines which users and groups are allowed to connect to the domain controller over the network. It is required by a number of network operations, including Active Directory replication between domain controllers, authentication requests to domain controllers from users and from computers, and for access to shared folders and printers.

Although permissions that are assigned to the Everyone security group no longer provide access to anonymous users in Windows Server 2003 with SP1, guest groups and accounts can still be provided with access through the Everyone security group.

For this reason, the Everyone security group is removed from the Access this computer from the network user right in the DCBP for the SSLF environment. Removal of this group provides an extra safeguard against attacks that target guest access to the domain. This policy setting is configured to Not defined for the LC and EC environments.

Add workstations to domain

This policy setting specifies which users can add computer workstations to a specific domain. For this policy setting to take effect, it must be assigned to the user as part of the Default Domain Controller Policy for the domain. A user who has been assigned this right can add up to 10 workstations to the domain. Users who have been assigned the Create Computer Objects permission for an OU or the Computers container in Active Directory can add an unlimited number of computers to the domain, regardless of whether they have been assigned the Add workstations to a domain user right.

By default, all users in the Authenticated Users group have the ability to add up to 10 computer accounts to an Active Directory domain. These new computer accounts are created in the Computers container.

In Windows–based networks, the term security principal is defined as a user, group, or computer that is automatically assigned a security identifier to control access to resources. In an Active Directory domain, each computer account is a full security principal with the ability to authenticate and access domain resources. However, some organizations may want to limit the number of computers in an Active Directory environment so that they can consistently track, build, and manage the computers. If users are allowed to add computers to the domain, tracking and management efforts would be hampered. Also, users could perform activities that are more difficult to trace because of their ability to create additional unauthorized domain computers.

For these reasons, the Add workstations to domain user right is assigned only to the Administrators group in the DCBP for the SSLF environment. This policy setting is configured to Not defined for the LC and EC environments.

Allow log on locally

This policy setting specifies which users can start interactive sessions on the domain controller. Users who do not have this right are still able to start a remote interactive session on the domain controller if they have been assigned the Allow logon through Terminal Services user right.

You should restrict the number of accounts that can log on to domain controller consoles to help prevent unauthorized access to domain controller file systems and system services. A user who is able to log on to the console of a domain controller could maliciously exploit the computer and possibly compromise the security of an entire domain or forest.

By default, the Account Operators, Backup Operators, Print Operators, and Server Operators groups are assigned the Allow log on locally user right on domain controllers. Users in these groups should not need to log on to a domain controller to perform their management tasks, and they should be able to perform their duties from other workstations. Only users in the Administrators group should perform maintenance tasks on domain controllers.

If you assign the Allow log on locally user right only to the Administrators group, physical and interactive domain controller access is limited to only highly trusted users, which enhances security. For this reason, the Allow log on locally user right is assigned only to the Administrators group in the DCBP for the SSLF environment. This policy setting is configured to include the Server Operators and Backup Operators groups for the LC and EC environments.

Allow log on through Terminal Services

This policy setting specifies which users can log on to the domain controller through a Remote Desktop connection.

You should restrict the number of accounts that can log on to domain controller consoles through Terminal Services to help prevent unauthorized access to domain controller file systems and system services. A user who is able to log on to the console of a domain controller through Terminal Services can exploit that computer and possibly compromise the security of an entire domain or forest.

If you assign the Allow log on through Terminal Services user right only to the Administrators group, interactive domain controller access is limited to only highly trusted users, which enhances security. For this reason, the Allow log on through Terminal Services user right is assigned only to the Administrators group in the DCBP for all three environments that are defined in this guide. Although logon to a domain controller through Terminal Services requires administrative access by default, configuration of this policy setting helps protect against inadvertent or malicious actions that might compromise the network.

As an additional security measure, the DCBP denies the default Administrator account the Allow log on through Terminal Services user right. This configuration prevents attempts by malicious users to remotely break into a domain controller with the default Administrator account. For more details about this policy setting, see Chapter 4, "The Member Server Baseline Policy."

Change the system time

This policy setting specifies which users can adjust the time on a computer's internal clock. However, it is not needed to change the time zone or other display characteristics of the system time.

Synchronized system time is critical to the operation of Active Directory. Proper Active Directory replication and authentication ticket generation processes that are used by the Kerberos authentication protocol rely on time being synchronized across any environment.

A domain controller clock that is not synchronized with the system time on other domain controllers in the environment could interfere with the operation of domain services. If only administrators are allowed to modify system time, the possibility of incorrect system time on a domain controller is minimized.

By default, the Server Operators group has the ability to modify system time on domain controllers. Because of the problems that could be caused by incorrect modification of a domain controller's clock by members of this group, the Change the system time user right is assigned in the DCBP to only the Administrators group and the Local Service account for all three environments that are defined in this guide.

For more information on the Microsoft Windows® Time Service, see the Windows Time Service Technical Reference at https://technet2.microsoft.com/WindowsServer/en/Library/a0fcd250-e5f7-41b3-b0e8-240f8236e2101033.mspx.

Enable computer and user accounts to be trusted for delegation

This policy setting specifies which users can change the Trusted for Delegation setting on a user or computer object in Active Directory. Delegation of authentication is a capability that is used by multi-tier client/server applications. It allows a front-end service, such as an application, to use the credentials of a client in authenticating to a back-end service, such as a database. For such authentication to be possible, both client and server must run under accounts that are trusted for delegation.

Misuse of this user right could allow unauthorized users to impersonate other users on the network. An attacker could exploit this user right to gain access to network resources as if they were a different user, which could make it difficult to determine what has happened after a security incident.

The Enable computer and user accounts to be trusted for delegation user right is assigned only to the Administrators group on domain controllers for the SSLF environment. This policy setting is configured to Not defined for the LC and EC environments.

Note: Although the Default Domain Controllers Policy assigns the Administrators group this user right, the DCBP enforces this right in the SSLF environment only because it was originally based on the MSBP. The MSBP assigns this right a null value.

Load and unload device drivers

This policy setting specifies which users can load and unload device drivers, and is necessary to load and unload Plug and Play devices.

Careless device driver management on domain controllers provides opportunities for bugs or malicious code to adversely impact the operation of the domain controllers. If the accounts that can load and unload device drivers are restricted in the DCBP to only the most trusted users, you minimize the potential for device drivers to be used to compromise domain controllers.

By default, the Load and unload device drivers user right is assigned to the Print Operators group. As mentioned earlier, creation of printer shares is not recommended on domain controllers, which removes the need for Print Operators to have the ability to load and unload device drivers. Therefore, the Load and unload device drivers user right is assigned only to the Administrators group in the DCBP for all three environments that are defined in this guide.

Restore files and directories

This policy setting specifies which users can circumvent file and directory permissions during the restore process. Any valid security principal could be set as the owner of an object.

An account that has the ability to restore files and directories to the file system of a domain controller can easily modify executable files. Malicious users could exploit this capability to not only render a domain controller useless, but also to compromise the security of a domain or an entire forest.

By default, the Restore files and directories user right is assigned to the Server Operators and Backup Operators groups. If you remove this user right from these groups and assign it only to the Administrators group, the likelihood of domain controller compromise by improper modifications to the file system is reduced. Therefore, the Restore files and directories user right is assigned only to the Administrators group in the DCBP for all three environments that are defined in this guide.

Shutdown the system

This policy setting specifies which users can shut down the local computer.

Malicious users with the ability to shut down domain controllers can easily initiate a denial of service (DoS) attack that could severely affect an entire domain or forest. An attacker could exploit this user right to launch an elevation of privilege attack on a domain controller's account when it restarts services. A successful elevation of privilege attack on a domain controller compromises the security of a domain or an entire forest.

By default, the Shutdown the system user right is assigned to the Administrators, Server Operators, Print Operators, and Backup Operators groups. In secure environments, none of these groups except Administrators require this right to perform administrative tasks. For this reason, the Shutdown the system user right is assigned only to the Administrators group in the DCBP for all three environments that are defined in this guide.

Security Options

Most of the security option settings for domain controllers are the same as those specified in the MSBP. For more information, see Chapter 4, "The Member Server Baseline Policy." Differences between the MSBP and the DCBP policy settings are described in the following sections.

Domain Controller Settings

Table 5.5 Security Options: Domain Controller Setting Recommendations

Setting Legacy Client Enterprise Client Specialized Security – Limited Functionality

Allow server operators to schedule tasks

Disabled

Disabled

Disabled

LDAP server signing requirements

Not defined

Not defined

Require signing

Refuse machine account password changes

Disabled

Disabled

Disabled

Domain controller: Allow server operators to schedule tasks

This policy setting determines whether members of the Server Operators group are allowed to submit jobs by means of the AT schedule facility.

The Domain controller: Allow server operators to schedule tasks setting is configured to Disabled in the DCBP for all three environments that are defined in this guide. The impact of this policy setting configuration should be small for most organizations. Users, including those in the Server Operators group, will still be able to create jobs by means of the Task Scheduler Wizard, but those jobs will run in the context of the account with which the user authenticates when they set up the job.

Note: An AT Service Account can be modified to select a different account rather than the LOCAL SYSTEM account. To change the account, open System Tools, click Scheduled Tasks, and then click Accessories folder. Then click AT Service Account on the Advanced menu.

Domain controller: LDAP server signing requirements

This policy setting determines whether the LDAP server requires a signature before it will negotiate with LDAP clients. Network traffic that is neither signed nor encrypted is susceptible to man-in-the-middle attacks in which an intruder captures packets between the server and the client, modifies them, and then forwards them to the client. For an LDAP server, an attacker could cause a client to make decisions that are based on false records from the LDAP directory.

If all domain controllers run Windows 2000 or Windows Server 2003, configure the Domain controller: LDAP server signing requirements setting to Require signing. Otherwise, leave this policy setting configured as Not defined, which is the DCBP configuration for the LC and EC environments. This policy setting is configured to Require signing in the DCBP for the SSLF environment because all computers in this environment run either Windows 2000 or Windows Server 2003.

Domain controller: Refuse machine account password changes

This policy setting determines whether domain controllers will refuse requests from member computers to change computer account passwords. If you enable this policy setting on all domain controllers in a domain, computer account passwords on domain members will not be able to be changed and they will be more susceptible to attack.

Therefore, the Domain controller: Refuse machine account password changes setting is configured to Disabled in the DCBP for all three environments that are defined in this guide.

Network Security Settings

Table 5.6 Security Options: Network Security Settings Recommendations

Setting Legacy Client Enterprise Client Specialized Security – Limited Functionality

Do not store LAN Manager hash value on next password change

Enabled

Enabled

Enabled

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 DCBP enables the Network security: Do not store LAN Manager hash value on next password change setting in all three environments that are defined in this guide.

Note: Older operating systems and some third-party applications may fail if you enable this policy setting. For example, Windows 95 and Windows 98 will fail if they do not have the Active Directory Client Extension installed. Also, all accounts will be required to change their password if you enable this policy setting.

Event Log Settings

The event log settings for domain controllers are the same as those that are specified in the MSBP. For more information, see Chapter 4, "The Member Server Baseline Policy." The baseline settings in the DCBP ensure that all the relevant security audit information is logged on the domain controllers, including Directory Services Access.

Restricted Groups

As described in the previous chapter, the Restricted Groups setting allows you to manage the membership of groups in Windows Server 2003 with SP1 through Active Directory Group Policy. First, review the needs of your organization to determine the groups you want to restrict. For domain controllers, the Server Operators and Backup Operators groups are restricted in all three environments that are defined in this guide. Although members of the Server Operators and Backup Operator 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 Server Users group, you may want to implement the optional file system permissions that are described in the “Securing the File System” section in the previous chapter.

Table 5.7 Restricted Groups Recommendations

Local Group Legacy Client Enterprise Client Specialized Security – Limited Functionality

Backup Operators

No members

No members

No members

Server Operators

No members

No members

No members

The Restricted Groups setting can be configured in Windows Server 2003 with SP1 at the following location in the Group Policy Object Editor:

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

To configure restricted groups for a GPO, administrators can add the desired group directly to the Restricted Groups node of the GPO namespace.

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 is left totally restricted. Groups can only be restricted with security templates.

To view or modify the Restricted Groups setting

  1. Open the Security Templates Management Console.Note: The Security Templates Management Console is not added to the Administrative Tools menu by default. To add it, start the Microsoft Management Console (mmc.exe) and add the Security Templates Add-in.
  2. Double-click the configuration file directory, and then the configuration file.
  3. Double-click the Restricted Groups item.
  4. Right-click Restricted Groups.
  5. Select Add Group.
  6. Click the Browse button, then Locations, select the locations you want to browse, and then click OK.Note: Typically, this action will cause a local computer to display at the top of the list.
  7. Type the group name in the Enter the object names to select text box and then click the Check Names button. – or – Click the Advanced button, and then the Find Now button to list all available groups.
  8. Select the groups you want to restrict, and then click OK.
  9. Click OK on the Add Groups dialog box to close it.

In this guidance, all members—users and groups—of the Server Operators and Backup Operators groups were removed to totally restrict them in both environments. Also, for the SSLF environment, all members were removed for the Remote Desktop Users group. Microsoft recommends that you restrict any built-in group you do not plan to use in your organization.

Note: The configuration of Restricted Groups that is described in this section is very simple. Versions of Windows XP with SP1 and SP2 as well as Windows Server 2003 support more complex designs. For more information, see the Microsoft Knowledge Base article “Updates to Restricted Groups ("Member of") Behavior of User-Defined Local Groups” at https://support.microsoft.com/default.aspx?kbid=810076.

Additional Security Settings

This section describes modifications that must be made to the DCBP manually, as well as additional settings and countermeasures that cannot be implemented through Group Policy.

Manually Adding Unique Security Groups to User Rights Assignments

Most user rights assignments that are applied through the DCBP are properly specified in the security templates that accompany this guide. However, there are a few accounts and security groups that cannot be included in the templates because their security identifiers (SIDs) are specific to individual Windows Server 2003 domains. User rights assignments that must be configured manually are specified in the following table.

Warning: The following table contains values for the built-in Administrator account. This account is not to be confused with the built-in Administrators security group. If you add the Administrators security group to any of the following deny access user rights, you will need to log on locally to correct the mistake. Also, if you renamed the built-in Administrator account in accordance with the recommendations in Chapter 4, "The Member Server Baseline Policy," ensure that you select the newly renamed administrator account when you add the account to any deny access user rights.

Table 5.8 Manually Added User Rights Assignments

Setting Legacy Client Enterprise Client Specialized Security – Limited Functionality

Deny access to this computer from the network

Built-in Administrator; Support_388945a0;

Guest; all NON-Operating System service accounts

Built-in Administrator; Support_388945a0;

Guest; all NON-Operating System service accounts

Built-in Administrator; Support_388945a0;

Guest; all NON-Operating System service accounts

Deny log on as a batch job

Support_388945a0 and Guest

Support_388945a0 and Guest

Support_388945a0 and Guest

Deny log on through Terminal Services

Built-in Administrator; all NON-operating system service accounts

Built-in Administrator; all NON-operating system service accounts

Built-in Administrator; all NON-operating system service accounts

Important: “All non-operating system service accounts” includes service accounts that are used for specific applications across an enterprise, but does NOT include LOCAL SYSTEM, LOCAL SERVICE or the NETWORK SERVICE accounts (the built-in accounts that the operating system uses).

Directory Services

Domain controllers that run Windows Server 2003 with SP1 store directory data and manage user and domain interactions, including user logon processes, authentication, and directory searches.

Relocating Data – Active Directory Database and Log Files

To maintain directory integrity and reliability, it is essential that you safeguard the Active Directory database and its log files.

You can move the Ntds.dit, Edb.log, and Temp.edb files from their default location, which will help to conceal them from an attacker if a domain controller is compromised. If you move the files off the system volume to a separate physical disk, you will gain the added benefit of improved domain controller performance.

For these reasons, this guide recommends that you move the Active Directory database and log files for the domain controllers to a striped or striped/mirrored disk volume that does not contain the operating system. These files should be moved for all three environments that are defined in this guide.

Resizing Active Directory Log Files

An adequate amount of information must be logged to effectively monitor and maintain the integrity, reliability, and availability of Active Directory. Information is needed from all domain controllers in the environment.

You can increase the maximum size of the log files to support this effort. More log information will allow administrators to perform meaningful audits if hacker attacks occur.

This guide recommends that you increase the maximum size of the Directory Service and File Replication Service log files from the 512 KB default to 16 MB on the domain controllers in the three environments that are defined in this guide.

Using Syskey

On domain controllers, password information is stored in Active Directory. It is not unusual for password-cracking software to target the Security Accounts Manager (SAM) database or directory services to access passwords for user accounts.

The System Key utility (Syskey) provides an extra line of defense against offline password-cracking software. Syskey uses strong encryption techniques to secure account password information that is stored in the SAM on the domain controller.

Table 5.9 Syskey Modes

System Key option Security level Description

Mode 1: System Generated Password, Store Startup Key Locally

Secure

Uses a computer-generated random key as the system key and stores an encrypted version of the key on the local computer. This option provides strong encryption of password information in the registry, and enables the user to restart the computer without the need for an administrator to enter a password or insert a disk.

Mode 2: Administrator generated password, Password Startup

More secure

Uses a computer-generated random key as the system key and stores an encrypted version of the key on the local computer. The key is also protected by an administrator-chosen password. Users are prompted for the system key password when the computer is in the initial startup sequence. The system key password is not stored anywhere on the computer.

Mode 3: System Generated Password, Store Startup Key on Floppy Disk

Most secure

Uses a computer-generated random key and stores the key on a floppy disk. The floppy disk that contains the system key is required for the computer to start, and it must be inserted at a prompt during the startup sequence. The system key is not stored anywhere on the computer.

Syskey is enabled on all Windows Server 2003 with SP1 servers in Mode 1 (obfuscated key). From a security standpoint, this configuration appears sensible at first. However, Syskey in Mode 1 allows an attacker to read and alter the contents of the directory, which would render the domain controller easily vulnerable to an attacker with physical access.

There are many reasons to recommend using Syskey in Mode 2 (console password) or Mode 3 (floppy storage of Syskey password) for any domain controller that is exposed to physical security threats. However, the operational need to restart domain controllers tends to make Syskey Mode 2 or Mode 3 difficult to support. To take advantage of the added protection provided by these Syskey modes, the proper operational processes must be implemented in your environment to meet specific availability requirements for the domain controllers.

The logistics of Syskey password or floppy disk management can be quite complex, especially in branch offices. For example, it can be very expensive to require one of your branch managers or local administrative staff to come to the office at 3 A.M. to enter passwords or insert a floppy to enable user access. Such expensive requirements can make the achievement of high availability service level agreements (SLAs) a significant challenge.

Alternatively, if you decide to allow your centralized IT operations personnel to provide the Syskey password remotely, additional hardware is required. Some hardware vendors have add-on solutions that allow you to remotely access server consoles.

Finally, the loss of the Syskey password or floppy disk would leave your domain controller in a state where it cannot be restarted. There is no method for you to recover a domain controller if the Syskey password or floppy disk is lost. If this happens, the domain controller must be rebuilt.

With the proper operational procedures in place, Syskey can provide an increased level of security to protect sensitive directory information on domain controllers. For these reasons, Syskey Mode 2 or Mode 3 is recommended for domain controllers in locations without strong physical storage security. This configuration applies to domain controllers in all three environments that are described in this guide.

To create or update a system key

  1. Click Start, click Run, type syskey, and then click OK.
  2. Click Encryption Enabled, and then click Update.
  3. Click the desired option, and then click OK.

Active Directory-Integrated DNS

Microsoft recommends the use of Active Directory-integrated DNS in the three environments that are defined in this guide. Part of the reason for this recommendation is because Active Directory zone integration makes it simpler to secure the DNS infrastructure in an environment that uses Active Directory-integrated DNS than in an environment that does not use Active Directory-integrated DNS.

Protecting DNS Servers

It is essential to safeguard DNS servers in any Active Directory environment. The following sections provide several recommendations and explanations about how to safeguard DNS servers.

When a DNS server is attacked, one possible goal of the attacker is to control the DNS information that is returned in response to DNS client queries. If an attacker controls this information, clients may be unknowingly redirected to unauthorized computers. IP spoofing and cache poisoning are examples of this type of attack.

In IP spoofing, a transmission is given the IP address of an authorized user to obtain access to a computer or network. Cache poisoning is an attack in which an unauthorized host transmits false information about another host into the cache of a DNS server. The attack causes clients to be redirected to unauthorized computers.

If client computers are allowed to communicate with unauthorized computers, the unauthorized computers may attempt to gain access to information on the client computers.

Not all attacks focus on spoofing DNS servers. Some DoS attacks could alter DNS records in legitimate DNS servers to provide invalid addresses in response to client queries. If a DNS server responds with invalid addresses, clients and servers cannot locate the resources they need to function, such as domain controllers, Web servers, or file shares.

For these reasons, the routers that are used in the three environments that are defined in this guide are configured to drop spoofed IP packets, which helps ensure that the IP addresses of the DNS servers are not spoofed by other computers.

Configuring Secure Dynamic Updates

The DNS client service in Windows Server 2003 with SP1 supports dynamic DNS updates, which allow client computers to add DNS records directly into the database. If a dynamic DNS server is configured to accept unsecured updates, an attacker could transmit malicious or unauthorized updates from a client computer that supports the DNS dynamic update protocol.

At a minimum, an attacker can add false entries to the DNS database. At worst, an attacker can overwrite or delete legitimate entries in the DNS database. Such an attacker could accomplish any of the following:

  • Direct clients to unauthorized domain controllers. When a client submits a DNS query to find the address of a domain controller, a compromised DNS server can be instructed to return the address of an unauthorized server. Then, with the use of other non-DNS related attacks, the client might be tricked and convinced to transmit secure information to the unauthorized server.
  • Respond to DNS queries with invalid addresses. Clients and servers would be unable to locate one another. If clients cannot locate servers, they cannot access the directory. When domain controllers cannot locate other domain controllers, directory replication stops, which creates a DoS condition that could affect users throughout a forest.
  • Create a DoS condition. A server’s disk space could be exhausted by a huge zone file that is filled with dummy records or large numbers of entries that slow down replication.

Use of secure dynamic DNS updates guarantees that registration requests are only processed if they are sent from valid clients in an Active Directory forest. This method severely limits the ability of an attacker to compromise the integrity of a DNS server.

For these reasons, the Active Directory DNS servers in the three environments that are defined in this guide are configured to accept only secure dynamic updates.

Limiting Zone Transfers to Authorized Systems

Because of the importance of zones in DNS, they should be available from more than one DNS server on the network to provide adequate availability and fault tolerance for name resolution queries. When additional servers host a zone, zone transfers are required to replicate and synchronize all copies of the zone for each server that is configured to host the zone.

Also, a DNS server that does not limit who can request zone transfers is vulnerable to transfer of the entire DNS zone to anyone who requests it. This transfer can be easily accomplished with tools such as Nslookup.exe. Such tools can expose the entire domain's DNS dataset, including such things as which hosts serve as domain controllers, directory-integrated Web servers, or Microsoft SQL Server™ databases.

For these reasons, Active Directory-integrated DNS servers in the three environments that are defined in this guide are configured to allow zone transfers, but to limit which computers can make transfer requests.

Resizing the Event Log and DNS Service Log

An adequate amount of information must be logged to effectively monitor and maintain the DNS service. Information is needed from all domain controllers in the environment.

You can increase the maximum size of the DNS service log file, which will allow administrators to perform meaningful audits in the event of an attack.

This guide recommends that you increase the maximum size of the DNS service log file to at least 16 MB on the domain controllers in the three environments that are defined in this guide. Also, ensure that the Overwrite events as needed option in the DNS service is selected to maximize the amount of log entries preserved.

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, you should rename the built-in Administrator account and alter its description to help prevent compromise of remote servers 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 security identifier (SID) 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 this 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 policy setting was not implemented in any of the security templates that are provided with this guide 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.

Terminal Services Settings

Table 5.10 Recommended Terminal Services Settings

Default Legacy Client Enterprise Client Specialized Security – Limited Functionality

Set client connection encryption level

High

High

High

The Set client connection encryption level setting determines the level of encryption for Terminal Services client connections in your environment. The High Level 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.

The Set client connection encryption level setting is configured to Enabled and High Level encryption is selected in the DCBP for the three security environments that are defined in this guide.

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

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

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

Table 5.11 Terminal Services Encryption Levels

Encryption level Description

High level

Encrypts data that is sent from client to server and from server to client with strong 128-bit encryption. Use this level when the Terminal Server runs in an environment that contains 128-bit clients only (such as Remote Desktop Connection clients). Clients that do not support this level of encryption will not be able to connect.

Client Compatible

Encrypts data that is sent between the client and the server at the maximum key strength that is supported by the client. Use this level when the Terminal Server runs in an environment that contains mixed or legacy clients.

Low level

Encrypts data that is sent from the client to the server with 56-bit encryption.

Important: Data sent from the server to the client is not encrypted.

Error Reporting

Table 5.12 Recommended Error Reporting Settings

Setting Legacy Client Enterprise Client Specialized Security – Limited Functionality

Turn off Windows Error Reporting

Enabled

Enabled

Enabled

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 controls 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.

Creating the Policy Using SCW

To deploy the necessary security settings, you must use both the Security Configuration Wizard (SCW) and the security templates that are included with the downloadable version of this guide to create a domain controller baseline policy.

When you create your own policy, be sure to skip the "Registry Settings" and “Audit Policy” sections. These policy 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 are 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 install the operating system on 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.

To create the Domain Controller Baseline Policy

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

  1. Install the Security Configuration Wizard component on the computer through Control Panel, Add/Remove Programs, Add/Remove Windows Components.
  2. Launch the SCW GUI, select Create new policy, and point it to the reference computer.
  3. Ensure that the detected server roles are appropriate for your environment. Do not remove the File server role, because it is required for the proper operation of domain controllers.
  4. Ensure that the detected client features are appropriate for your environment.
  5. Ensure that the detected administrative options are appropriate for your environment.Note: If your environment contains domain controllers in multiple sites, ensure that Mail-based Active Directory replication is selected.
  6. Ensure that any additional services that are required by your baseline, such as backup agents or antivirus software, are detected.
  7. 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.
  8. Ensure that 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.Note: Ensure that Ports for System RPC Applications is selected.
  9. 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.
  10. 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.
  11. Include the appropriate security template (for example, EC-Domain Controller.inf).
  12. Save the policy with an appropriate name (for example, Domain Controller.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:<PathToPolicy.xml> /g:<GPODisplayName>
    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\
        Domain Controller.xml" /g:"Domain Controller 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 Domain Controllers OU, and make sure to move it above the Default Domain Controllers Policy so that it receives the highest priority.

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

Remember that the newly created GPO can take some time to replicate to all domain controllers, especially in environments with domain controllers in multiple sites. After you verify that the GPO has replicated successfully, you should perform a final test to ensure that the GPO applies the desired policy settings. To complete this procedure, confirm that the appropriate settings were made and that functionality is not affected.

Summary

This chapter explained how to harden domain controller servers that run Windows Server 2003 with SP1 in each of the three environments that are defined in this guide. Most of the policy settings that were discussed were configured and applied through Group Policy. The Domain Controller Baseline Policy (DCBP) that complements the Default Domain Controller Policy was linked to the Domain Controllers OU.

The DCBP settings will enhance overall security for domain controllers in any environment. The use of two GPOs to secure domain controllers allows the default environment to be preserved and simplifies troubleshooting.

Several of the settings that were discussed cannot be applied through Group Policy. For these settings, manual configuration details were provided.

After the domain controllers are configured for security, other server roles can be made more secure. The following chapters of this guide focus on how to secure several other specific server roles.

More Information

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

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

Download

Get the Windows Server 2003 Security Guide

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions