Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Deploying Secure Domain Controllers

One of the best ways to ensure secure domain controllers is to install them securely configured to start and to deploy them in a secure manner. The DC is secured before it is placed into production. Many of these security steps can be incorporated into an automated installation process.

Preparation

Before a domain controller is established on the network, prepare for its installation. Some steps are done before the first DC in the forest is established and then maintained, while others need to be prepared before each new DC is installed. Prior to installing the first domain controller, do the following:

Secure DNS
Active Directory depends on DNS. Securing DNS is paramount. Steps for securing DNS are detailed in Chapter 11.

Secure the Network Infrastructure.
Although the DC itself should be hardened, it should always be operated in a secure environment. Routers, network segments, and switches should all be secure. An excellent source of information on network infrastructure security can be found in Hardening Network Infrastructure by Wes Noonan (McGraw-Hill Osborne Media, 2004).

Prepare a secure physical location
Specifics may vary from a locked cabinet in a small branch office to a data center. The objective is to secure from theft, restrict access, and prevent the addition of rogue applications, drivers, services, or configuration.

Secure the computer itself
Hardening the server hardware includes removing or securing removable drives, establishing a boot policy, and removing access to unnecessary ports, such as unused USB or serial ports.

Prepare the server post installation but prior to dcpromo.

Establish policy and procedures for domain controller installation
Prior to establishing the first DC of the production network, policy and procedures should be written. If those responsible for writing policies and procedures are unfamiliar with Active Directory, a test network should be provided along with proper education and training.

Policies and Procedures for Domain Controller Installation

Policies and procedures for domain controller installation should include the following:

Specifying who has the authority to install the DC.

Specifying that if the server can't be physically secured from console access during installation, it should not be left unattended.

Specifying where domain controller installation can be done, such as doing as much as possible outside the production network.

Providing automated processes for as many phases of installation as possible.

Developing a procedure for secure installation of DCs at remote locations. Some organizations install the DC and then ship them. Specify a secure shipping method to prevent theft of the DC during shipping.

Specifying that only service administrators do DC installations.

Here are the sound steps to include in policies and procedures:

Provide multiple physical drives so that Active Directory components can be on separate drives, and the AD database can be separate from the Windows Server 2003 operating system. Taking these actions improves performance and availability and protects AD from potential directory traversal attacks and disk-filling DoS attacks. In a directory traversal attack, an attacker gains access to one directory on a disk, then uses tools and commands in an attempt to access other folders. Thus, access to a mundane folder with no sensitive items might be leveraged into access to more sensitive ones, such as AD. By placing components on different physical disks, you can thwart these attacks.

Create or modify security templates that meet the DC security baselinepotential settings were described previously, and potential preconfigured secure DC baselines can be downloaded from Microsoft.

Prepare a separate build network for installations if network install is your choice. Otherwise, prepare custom bootable CD-ROMs with changes made.

Modify default security settings by modifying default security templates used by server install and dcpromo. Make sure these modified templates are available to the system during install by modifying the defaults and ensuring that they are located on the installation media where the system expects to find them during install.

Server Installation

Before a server becomes a DC, the Windows operating system must be installed. The following steps will provide a more secure base on which to create a DC:

After Server Installation But Before dcpromo

After the server is installed, scan for viruses and create a reserve file.

Virus scanning should always be done before dcpromo to ensure that the server is virus-free. Then, the virus scanner should be turned off.

Create a reserve file to enable recovery in the case of disk space attacks. A reserve file is a file created on the same drive as the ntds.dit (the AD directory) file. The reserve file does not contain useful data; it just takes up room on the disk. If these attacks include adding objects to the Active Directory, even though the administrator deletes the unneeded objects, it will take a while before their tombstones are gone, thus the size of the AD is not reduced. This is only one type of disk space attack. A disk space attack can fill up the disk and cripple AD, but it won't overwrite the reserve file. The administrator can recover AD by removing the reserve file and thus giving AD room to operate while the unneeded objects' tombstones are still present.

TIP: Don't Let Virus Scanners Scan SYSVOL

After dcpromo, virus scanners should be modified to prevent the scanning of SYSVOL and other folders that are replicated by the file-replication service. Many anti-virus products modify file settings when scanning files. This modification on folders that are replicated can trigger replication. A large amount of file replication can severely affect the performance on the network.

During dcpromo

The dcpromo process promotes an ordinary server and makes it a DC. Here are the guidelines to follow for dcpromo:

Disable pre-Windows 2000 compatibility. Pre-Windows 2000 compatibility needs to be enabled if legacy applications that require anonymous access to AD are present, such as RRAS or RAS on NT 4.0 or SQL Server 6.0 applications. It also provides access to many files, folders, Active Directory objects, and registry keys to members of the group. For example, it provides read permission on the domain root and on all user, computer, and group objects when enabled. The group Everyone is added to the Pre-Windows 2000 Compatibility group. In Windows Server 2003, this does not include the anonymous SID; it does, however, provide access to every authenticated user and the Guest account. This access is far too broad.

Place database and SYSVOL on same physical drive but separate from the system volume. The system volume is a common place where large print jobs are spoofed, thus filling up the folder. If AD is on the same drive, it may be crippled because the drive may be filled by other activity, and AD will not have room enough to operate. (If the DC will not be a print server, disable the print service.)

Improve performance by placing log files and the paging file on their own dedicated physical drive(s)not the system drive.

After Installation

After the DC is installed, additional steps should be taken:

Configure virus protection to skip virus checking on any drives that are or will be configured for the File-Replication Service. (Otherwise, every replication will trigger excessive virus checking.) Turn virus checking back on.

Prepare for secure replication and other communications.

Move the domain controller into a secured place in the data center.

Automate Domain Controller Installation

Where possible, automate domain controller installation. This has more benefits than just speeding up the task and removing some of its labor. When procedures are automated, they are done the same exact way every time. When procedures are done manually, mistakes and omissions can happen. It's also true that because installations can take a while, systems may be left open with administrator privileges for some time before anyone returns to start the next stage of the process. Automated installation, when done correctly and tested, will complete the process without any gaps. Several possibilities for configuring automated installation exist. Remote Installation Services (RIS), sysprep, and third-party products all do a good job. The basic process consists of preparing the automated installation media or process, starting the installation, and moving the DC into production. To prepare and utilize an automated install, follow these steps:

Hklm\software\microsoft\windows\currentversion\runonce

[GuiRunOnce]
Command0 = "dcpromo /answer:ansfile.txt"

Secure Replication

Active Directory changes are replicated between all domain controllers in a domain and between the Global catalog servers in each domain in the forest. By default, all replication is encrypted and authenticated. Securing replication is part securing the domain controllers, part adding security to the data transfer, and part improving the security of the networks over which it may pass. Govern the private network with sound network security practices, and this will do much to ensure the security of AD replicated data. When replication data must pass over untrusted networks, additional steps should be taken. Possibilities are using SMTP as a replication protocol and using IPSec or a VPN.

SMTP-Based Replication

Normal Active Directory replication uses RPC over TCP/IP. SMTP can be also be used for replication but requires certificates and can be used only to replicate schema, configuration, and application directory partitions. SMTP cannot be used to replicate domain directory partitions. Hence, if a DC for a domain resides in one site, it may be possible to use only SMTP replication, but where DCs of a domain are spread across multiple sites, RPC over TCP/IP must also be used. Using SMTP can improve security because RPC ports do not need to be opened on firewalls and because using SMTP requires certificate-based authentication.

Using IPSec or a VPN

An extra layer of security can be achieved by using an IPSec Policy for domain replication or, where data must traverse networks such as the Internet, a VPN connection between the two sites should be established and used for replication.