Implementing Security on Domain Controllers

To prevent attacks against Windows 2000 domain controllers, you must implement security measures that lessen the vulnerabilities. These security measures range from physically securing domain controllers in order to prevent direct access by attackers, to logically configuring domain controllers to reduce threats. Specifically, you must take the following security measures to secure Windows 2000 domain controllers:

Provide physical security.
Increase the security of stored passwords.
Eliminate nonessential services.
Apply security settings by using Group Policy.
Protect against the failure of a domain controller.
Implement Syskey.
Secure built-in accounts and groups.
Enable auditing.
Secure Active Directory communications.

Providing Physical Security

A physical compromise of a domain controller can easily lead to the compromise of the Active Directory database copy stored at the domain controller. You must protect domain controllers by storing them in physically secure locations, such as a server room that requires card-key access.

For example, if attackers gain physical access to a domain controller, they can boot the computer with a third-party boot disk. Once attackers have administrator access, they can back up Active Directory by performing a System State backup, restore Active Directory to another server, and run any number of offline password attacks against the Active Directory database.

Increasing the Security of Stored Passwords

To protect passwords stored in Active Directory, enable the following configuration options:

Do not implement protocols that require passwords to be stored in a reversibly encrypted format, such as Challenge Handshake Authentication Protocol (CHAP) or digest authentication for Web applications. A password stored in this format is more susceptible to password attacks if attackers gain physical access to a domain controller. A password attack can easily decrypt passwords if they are stored in this format.

A password cracker can still crack passwords stored in Active Directory that are not reversibly encrypted. The difference is that cracking a normally stored password takes much longer.
Disable LAN Manager (LM) hash values in the Active Directory database. A password stored in an LM hash value is more susceptible to password attacks. You can disable the storage of passwords in this format by enabling the Network Security: Do Not Store LAN Manager Hash Values On Next Password Change Group Policy setting in Security Options. This security option is available only when you modify the GPO from a Microsoft Windows XP computer. Group Policy is applicable to Windows 2000 computers with Service Pack 2 or later, or to Windows XP.

Ensure that no client computers that use LM authentication exist on the network. For Microsoft Windows 95 and Windows 98 clients, install the Directory Services Client software from the Windows 2000 Server CD. This client software ensures that Windows 95 and Windows 98 computers authenticate by using NT LAN Manager version 2 (NTLMv2) authentication.

Enable password complexity at the domain. When the Password Must Meet Complexity Requirements group policy is enabled, passwords must be at least six characters in length and consist of at least three of the following four forms:

English uppercase letters	A, B, C, Z
English lowercase letters	a, b, c, z
Westernized Arabic numerals	1, 2, 9
Nonalphanumeric characters	!, @, #, and so on

Eliminating Nonessential Services

A domain controller should not run nonrequired services. In its most secure configuration, a domain controller does not run any services other than the DNS service to allow for Active Directory integrated zones.

The Security Operations Guide for Windows 2000 Server recommends that only specific services be enabled at a Windows 2000 domain controller. Table 14-1 shows the recommended startup configuration for services required by a Windows 2000 domain controller.

Table 14-1. Windows 2000 Domain Controller Services
Service	Manual	Automatic
COM+ Event System	X
DHCP Client		X
Distributed File System		X
Distributed Link Tracking Client		X
DNS Server		X
DNS Client		X
Event Log		X
File Replication Service		X
Kerberos Key Distribution Center		X
Logical Disk Manager	X
Logical Disk Manager Administrative Service		X
Net Logon		X
Network Connections	X
NT LM Security Support Provider		X
Performance Logs and Alerts	X
Plug and Play		X
Protected Storage		X
Remote Procedure Call (RPC)		X
Remote Procedure Call (RPC) Locator		X
Remote Registry Service		X
Security Accounts Manager		X
Server		X
System Event Notification		X
TCP/IP Net BIOS Helper Service		X
Windows Management Instrumentation Driver Extensions	X
Windows Time		X
Workstation		X

In addition to the services listed in Table 14-1, a Windows 2000 domain controller might require other services, depending on your network s configuration. These services include the following:

Simple Mail Transport Protocol (SMTP)
This service is required if your intersite replication topology implements SMTP replication.
Intersite Messaging
If your replication topology implements SMTP replication, you must start this service in order to direct inbound and outbound intersite messages to the appropriate replication protocol: remote procedure calls or SMTP.
IIS Admin Service
If you implement the SMTP service, you must load the IIS Admin Service to manage the SMTP service. In addition, the SMTP service is dependent on the IIS Admin Service to start.
Distributed Link Tracking Server Service
If you implement the Distributed Link Tracking Client Service, you must start the Distributed Link Tracking Server Service so that clients can contact the server service when tracking files on NTFS file system volumes.

Applying Security Settings by Using Group Policy

The simplest way to ensure consistent security settings across all domain controllers is to create a security template that defines the required settings and to apply the template by using Group Policy. When defining Group Policy settings, remember the following guidelines:

Define account policy settings in the default domain policy. The account policy settings include the domain s password policy, account lockout policy, and Kerberos policy. These settings must be defined at the domain rather than at individual OUs because they are attributes related to the Security Accounts Manager (SAM). Also, the domain is the only Group Policy container that ensures that every domain controller has a uniform account policy defined if domain controller computer accounts are moved from the Domain Controllers OU.
Review the recommended security settings for domain controllers presented in the BaselineDC.inf security template included in the Security Operations Guide for Windows 2000 Server and the U.S. National Security Agency s (NSA) W2kdc.inf security template.

Use these recommended security templates as the starting point for your company s domain controller security configuration. You should modify these security templates to enforce your company s security policy.

Protecting Against the Failure of a Domain Controller

You can protect against the failure of a domain controller in two ways: by performing regular backups of your domain controller and by implementing at least two domain controllers for each domain.

By performing regular backups of your company s domain controllers, you ensure that the domain controllers can be quickly recovered in the event of hardware failure or data corruption on the hard disk. To back up Active Directory, you must include the System State, which comprises the Active Directory database and log files, in your backup set. The backup strategy should make certain that backups are performed at regular intervals and are periodically tested by performing test restores, which ensure that disaster recovery will work in the event of a domain controller failure.

In addition to performing regular backups, you should make sure that at least two domain controllers exist in each domain in your forest. Doing so ensures that if a single domain controller fails, an additional domain controller can service authentication requests and maintain the Active Directory database.

Implementing Syskey

Windows 2000, by default, implements strong encryption of the account information stored in Active Directory. This information is protected by the System Key. The level of protection offered by the System Key is configured by using the Syskey.exe utility. When you run the Syskey.exe utility, you can choose to protect the System Key by using one of three methods:

A machine-generated random key stored on the local system by using a complex encryption algorithm
This is the default configuration of Syskey.exe, and it provides strong encryption of password information in the registry. Because the System Key is stored on the local system, this method allows for unattended system restarts.
A machine-generated random key stored on a floppy disk
The floppy disk with the System Key is required for the system to start. This disk must be inserted when Windows 2000 prompts you for it after beginning the startup sequence, but before the system is available for users to log on.
An administrator-chosen password to derive the System Key
Windows 2000 will prompt you for the System Key password when the system is in the initial startup sequence, but before the system is available for users to log on. An MD5 digest of the password is used as the System Key to protect the password encryption key.

The method you use to protect the System Key will depend on your company s security policy. Although storing the System Key on a floppy disk or requiring a password to start the computer increases the security of the Active Directory database, both of these methods remove the possibility of an unattended domain controller startup.

Securing Built-In Accounts and Groups

Several built-in groups and user accounts must be protected in an Active Directory environment. These users and groups are assigned specific permissions and user rights that allow them to manage Active Directory. Specifically, you should manage the membership of the following user and group accounts:

Administrator
The Administrator account in each domain is a built-in user account that is a member of the Domain Admins and Administrators groups in each domain. In the forest root domain, this account is also a member of the Schema Admins and Enterprise Admins groups. To secure this group, consider renaming the Administrator account and changing the description of the user account because it is a well-known description.

Consider creating another account named Administrator with the description Built-In Account For Administering The Computer/Domain. This user account should be tracked to determine whether anyone is attempting to connect to the account with the user s credentials. Verify that this account is only a member of the Domain Guests global group to ensure that the group is assigned minimum network privileges.
Administrators
The Administrators built-in local group is assigned administrative permissions and user rights for a domain. Members of this group can manage all aspects of the Active Directory domain in which the Administrators group exists.
Domain Admins
In each domain, the Domain Admins global group is a member of the Administrators built-in local group. Through this membership, the group can modify the membership of the Administrators group and has full administrative privileges for the domain. In the forest root domain, members of this group can modify the membership of the Enterprise Admins and Schema Admins groups.
Enterprise Admins
The Enterprise Admins group can administer all domains in the forest and is assigned permissions to manage several objects stored in the configuration-naming context. For example, members of the Enterprise Admins group can add enterprise Certification Authorities (CAs) to the forest.
Schema Admins
The members of the Schema Admins group can modify the schema by defining new attributes and classes in the Active Directory schema.

You can manage the membership of these groups by using the restricted groups group policy. The restricted groups group policy prevents the addition and deletion of user accounts and groups from a group defined in this policy.

For more information on implementing restricted groups, please see 320045, How to Restrict Group Membership By Using Group Policy in Windows 2000.

Enabling Auditing

To ensure that attacks against domain controllers are detected, enable auditing in the default domain controllers policy. Auditing will record events to the Windows 2000 Security Log that can aid in detecting intrusion attempts and attacks against the domain controller. Table 14-2 outlines the recommended auditing settings for a domain controller.

Table 14-2. Windows 2000 Domain Controller Audit Settings
Audit Policy	Prescribed Setting
Audit account logon events	Success, Failure
Audit account management	Success, Failure
Audit directory service access	Failure
Audit logon events	Success, Failure
Audit object access	Success, Failure
Audit policy change	Success, Failure
Audit privilege use	Failure
Audit system events	Success, Failure

For more details on configuring auditing in a Windows 2000 network environment, see Chapter 12, Auditing Microsoft Windows Security Events.

Securing Active Directory Communications

You can increase the security of data transmitted to and from domain controllers by implementing different strategies. These strategies include restricting which users and computers can connect to the domain controller and protecting the data as it is transmitted to and from domain controllers.

Implementing SMB Signing

You can restrict which users and computers can connect to a domain controller by implementing Server Message Block (SMB) signing or IP Security (IPSec) by using Authentication Headers (AHs). Both solutions provide mutual authentication of the client and the server and protect the data against modification during transmission.

To implement SMB signing, you must implement the Digitally Sign Server Communications (Always) security option in a GPO applied to the domain controller s OU. To ensure that client computers also implement SMB signing, you must implement the Digitally Sign Client Communications (Always) security option in a GPO linked to the domain. This GPO will affect only Windows 2000 and Windows XP computers.

If you need to enable SMB signing for Windows 98 or Microsoft Windows NT computers, see 230545, How to Enable SMB Signing in Windows 98, and 161372, How to Enable SMB Signing in Windows NT.

Disabling Anonymous Connections

In some cases, you might want to prevent anonymous access to resources on a domain controller. You can do this by configuring the RestrictAnonymous registry key at each domain controller. You can implement this in a GPO by configuring the Additional Restrictions For Anonymous Connections policy under Security Options.

To ensure the highest level of security, you can define Group Policy to be set to No Access Without Explicit Anonymous Permissions (a registry value of 2). This registry value ensures that the access token built for nonauthenticated users does not include the security identifier (SID) of the Everyone group. This effectively restricts anonymous users to accessing resources that explicitly allow access by anonymous users.

Enable the RestrictAnonymous registry entry only if your domain does not include downlevel member workstations, servers, or Windows NT 4.0 backup domain controllers. When you enable this option, the following conditions will be in effect:

Windows 95, Windows 98, and Windows NT 4.0 member workstations or servers cannot set up a Netlogon secure channel.
Windows NT 4.0 domain controllers in trusting domains cannot set up a Netlogon secure channel.
Macintosh users cannot change their passwords at all.
The Browser service cannot retrieve domain lists or server lists from backup browsers, master browsers, or domain master browsers that have the RestrictAnonymous registry key set to a value of 2.

Implementing IPSec Encryption

To protect data transmitted to and from domain controllers from inspection, you can implement IPSec encryption. Because communications with domain controllers might also require communications with other services, such as DNS, you typically will implement IPSec encryption for all network traffic.

To implement IPSec encryption for all network traffic, all network clients must be running Windows 2000 or Windows XP as the OS. IPSec encryption is not available to previous versions of the Microsoft OS.

If you want to implement IPSec to protect all data transmitted to and from a domain controller, you must first ensure that all other computers in the domain are configured to implement IPSec, if required to do so. You can accomplish this by assigning the default Client (Respond Only) IPSec policy at the domain. This policy will allow any client computer to use IPSec to protect data if requested to do so by a Windows 2000 server.

The Client (Respond Only) IPSec policy assumes that a server protected by IPSec has the Accept Unsecured Communications, But Always Respond Using IPSec option enabled. If this option is not enabled, the Client (Respond Only) IPSec policy will not work because IPSec is implemented only if the server requests IPSec. Because the client always initiates communications with the server, all communications will fail if this option is not enabled.

To ensure that IPSec is used to protect data transmitted to and from domain controllers, assign the Secure Server (Require Security) IPSec policy in a GPO linked to the domain controller s OU. This IPSec policy ensures that all network traffic is encrypted by using Encapsulating Security Payload (ESP). The actual encryption and integrity algorithms are negotiated between the client and the server during the Internet Key Exchange (IKE) negotiations.

Do not implement IPSec if the data that is transmitted between any clients on the network to the domain controllers must pass through network devices that perform network address translation (NAT). Currently, IPSec is unable to pass through NAT devices. Microsoft is considering implementing the Internet Engineering Task Force (IETF) Draft entitled UDP Encapsulation of IPSec Packets, which will allow IPSec to pass through NAT devices in a future service pack or security update.