Maintaining Physical Security

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

All of the previous domain controller security measures assume that your domain controllers are physically secure. Physical security ensures that unauthorized users cannot turn domain controllers on or off, add or remove hardware, insert or remove removable media, log on by using the domain controllers’ keyboards and displays, or remove backup media.

To maintain physical security for your domain controllers:

• Secure domain controllers against physical access.

• Prevent domain controllers from booting into alternate operating systems.

• Protect domain controllers on restart by using SYSKEY.

• Secure backup media against physical access.

• Enhance the security of the network infrastructure.

• Secure the remote restart of domain controllers.

Securing Domain Controllers Against Physical Access

The first line of defense in maintaining physical security is to secure domain controllers against any attacks that can be accomplished with physical access to a domain controller. Note that changes in a domain controller’s environmental conditions, such as power failures, can also compromise the security of the domain controller.

Take the following common security precautions for restricting physical access to your domain controllers:

• Use UPSs to prevent loss of power.

• Place domain controllers and UPSs in a locked room.

• Require cardkey locks or cipher-locks on the entrances to the locked room.

• Require locks on individual domain controllers or on doors to the racks that house the domain controllers.

• Require specific processes and procedures for any administration or repair of the domain controllers.

These security precautions are intended to prevent an attacker from gaining physical access to your domain controllers. However, in an environment where these recommendations cannot be strictly enforced, such as in branch offices, additional security measures might be required, as described in the following sections.

Preventing Domain Controllers from Booting into Alternate Operating Systems

A domain controller can be booted into an alternate operating system. For example, public domain drivers exist for MSDOS that an attacker can use to boot the domain controller and directly access files that are stored on NTFS disk volumes, bypassing existing NTFS permissions. Similar utilities exist for Linux and UNIX operating systems. You can take steps to avoid this type of attack.

To minimize the possibility of domain controllers booting into an alternate operating system:

• Disable or remove the floppy disk drive, unless it is required by SYSKEY. For more information, see the Protecting Domain Controllers on Restart by Using SYSKEY section.

• Disable or remove the CD-ROM or DVD drive.

• Set the [timeout] parameter in the Boot.ini file to 0.

• Disable remote network boot and installation, for example, by RIS or Bootstrap Protocol (BOOTP).

• When you are unable to use SYSKEY with a password or floppy disk, require a basic input/output system (BIOS) password to boot the computer.

Protecting Domain Controllers on Restart by Using SYSKEY

Generally, in secure datacenter environments, only authorized personnel can restart domain controllers. However, in an environment where these recommendations cannot be strictly enforced, such as in branch offices, there is increased potential for an unauthorized person to restart a domain controller.

An unplanned or unexpected restart of a domain controller could indicate that an attacker has booted a domain controller with an alternate operating system and compromised the security of the domain controller. On the other hand, the restart might simply be due to a loss of power or to scheduled maintenance on the domain controller.

Evaluating the Need for SYSKEY

The system key (SYSKEY) in Windows Server 2003 protects security information (including password information) in the Active Directory database and other Local Security Authority (LSA) secrets against offline attacks by encrypting their storage on a domain controller. SYSKEY can either be derived from a secret password that you specify, or it can be stored on offline media, such as a floppy disk. On a domain controller reboot, either the password or the floppy disk containing SYSKEY must be supplied to successfully restart the computer.

Implementing SYSKEY provides two security advantages:

• Point-in-time control of the domain controller restart, which evaluates the reason for the domain controller restart and determines if security has been compromised.

• Protection for passwords that are stored in the directory database against offline attacks if the domain controller or a disk are stolen.

You can use the system key utility (Syskey.exe), which is installed on the domain controller during Windows Server 2003 installation, to select one of two configurations for the SYSKEY source.

The use of SYSKEY involves the following logistic operational issues:

• Management of SYSKEY passwords or floppy disks can present challenges.

  Requiring a branch manager or local administrative staff to come to the office at 3 A.M. to enter passwords or insert a floppy disk might be difficult.

  Alternatively, allowing centralized IT operations personnel to provide the SYSKEY password remotely requires additional hardware, such as Compaq Remote Insight Lights-out (RILO) or Dell Remote Access Card (DRAC III) boards. For more information about restarting domain controllers remotely, see the Securing the Remote Restart of Domain Controllers section.

• Loss of the SYSKEY password or floppy disk leaves the domain controller in a state in which it cannot be restarted.

  There is no way to recover a domain controller if the SYSKEY password or floppy disk is lost. In this situation, it is necessary to rebuild the domain controller.

Selecting a Method for Securing Domain Controller Restarts with SYSKEY

Each method noted in the previous section (namely, manually entering SYSKEY passwords or supplying SYSKEY on a floppy disk) has advantages and difficulties. If you choose to add SYSKEY protection to your domain controllers, you should first evaluate your security environment to determine which method will work best for you.

Providing SYSKEY Passwords to Secure Domain Controller Restarts

SYSKEY passwords do not require physical media that could be lost because there are no floppy disks to lose. Trusted personnel must enter a password in the event that the domain controller needs to be restarted. The password should be known to only a small group of trusted administrators, preferably only members of the Domain Admins group. The disadvantage of using passwords to secure SYSKEY is that trusted personnel are required to memorize passwords and be on-site to enter the passwords.

To support branch offices, you might need to provide SYSKEY passwords remotely through central IT trusted personnel. However, this method requires additional hardware, such as Compaq RILO or Dell DRAC III boards. For more information about restarting domain controllers remotely, see the Securing the Remote Restart of Domain Controllers section.

Because passwords can be compromised, you might be able to increase the security of passwords that are used for SYSKEY restarts by:

• Using strong passwords.

• Storing the passwords in a secure environment, such as a bank safety deposit box.

• Requiring the periodic changing of the SYSKEY passwords.

Providing SYSKEY Floppy Disks to Secure Domain Controller Restarts

Using SYSKEY with a password that is stored on a floppy disk does not require that a password be memorized by trusted personnel. However, implementing SYSKEY with a floppy disk does introduce the risk of a lost or damaged floppy disk. Furthermore, trusted personnel are required to insert the floppy disk during domain controller restart. Again, only trusted personnel, preferably members of the Domain Admins group, should have access to the SYSKEY floppy disk.

To support branch offices, you might need to install other hardware devices, such as Compaq RILO or Dell DRAC III boards, so that images of floppy disks can be remotely transferred to the domain controller. Using these devices, central IT trusted personnel can transfer a copy of the SYSKEY disk image to a remote domain controller. After the domain controller is restarted, IT operations personnel can delete the remote image of the SYSKEY floppy disk.

Because the floppy disk contains the cryptographic key for SYSKEY, you should take measures to ensure that the floppy disk is not stolen, lost, destroyed, or copied by an unauthorized person. You can mitigate these risks by doing the following:

• Copy the floppy disk and storing the copy off-site, such as in a bank safe deposit box.

• Store the working copy of the floppy disk in a secure place on-site.

• Remove the floppy disk from the domain controller immediately after it restarts.

Securing Backup Media Against Physical Access

As part of your normal operational practices, you should regularly back up your domain controllers and secure the backup media to minimize the risk of data tampering or theft.

Because the backup contains all the information in the Active Directory database, theft of the backup media presents the same risks as theft of a domain controller or theft of a disk drive from the domain controller. An attacker could restore the information elsewhere and illegally access the Active Directory data.

You can help prevent unauthorized users from gaining physical access to backup media by doing the following:

• Store backup media that is used on-site in a secure location where access is audited.

• Store archival backup media securely off-site.

• Establish processes and procedures that require the signatures of authorized administrators when any archival backup media is brought back on-site.

• Ensure that backup media is only in the backup device during the backup or recovery process.

Enhancing the Security of the Network Infrastructure

The placement of domain controllers in your network environment directly affects the security of your domain controllers. The primary focus in network security is to isolate the domain controllers from unauthorized users, while providing high-speed, secure access to authorized users. To ensure that domain controllers are properly isolated, secure any cabling rooms and place domain controllers on secured segments in your network.

Securing Cabling Rooms

If an attacker can gain access to your cabling rooms, the attacker can use a protocol analyzer to capture network traffic and compromise your network’s security, including domain controller security. In intranet and perimeter network datacenters, the possibility of unauthorized personnel gaining access to these cabling rooms is negligible. However, in branch offices, the cabling rooms might be shared with telephony wiring and other utilities.

Typically, your cabling rooms are where some of your routers and switches are located. The routers and switches contain a logical diagram of your network, because they manage and maintain routing information. This routing information is used by Active Directory to determine Internet Protocol (IP) subnets, and it determines the preferred domain controller for computers in the network.

Attackers can gain access to your switches and routers by using Telnet or Web interfaces that are provided by these devices. If attackers gain access to the configuration information of these devices, they can use this information to mount attacks on your domain controllers.

In most environments, the routers and switches all use the same password for reading and configuring information. The management software for routers and switches might support the use of only a single name, or you might want to use a single password to simplify the management of a large number of switches. For example, organizations can use the same Simple Network Management Protocol (SNMP) community name for all these devices to make management easier.

Regardless of the environment, you can improve the security of your cabling rooms by doing the following:

• Require cardkey locks or cipher-locks on the entrances to the cabling rooms.

• Require locks on the racks that house wiring panels, switches, or routers.

• Include UPSs to prevent loss of power.

• Require specific processes and procedures for any administration or repair of cabling, switches, or routers.

• Use strong passwords to secure the configuration of routers and switches.

• Use different passwords for reading and configuring routers and switches.

Placing Domain Controllers in Secure Network Segments

The manner in which you place domain controllers in your network can optimize isolation of domain controllers from unauthorized users. At the same time, ensure that users and computers have high-speed connectivity to their respective domain controllers.

Placing Domain Controllers in Datacenters

Place domain controllers in the datacenter so that only designated personnel have direct physical contact with the domain controllers. Place your forest root, application, and regional domain controllers for use within your organization’s private network in the datacenter. The placement of domain controllers in your perimeter network is discussed in a later section.

Place domain controllers so that firewalls protect domain controllers from Internet users and so that routers, and possibly firewalls, protect domain controllers from users within the organization’s private network. Figure 7 illustrates the placement of domain controllers in a datacenter.

Placing Domain Controllers in Perimeter Networks

Place domain controllers in your perimeter networks so that the domain controllers are not directly accessible by Internet users. Ensure that only Web servers, database servers, file servers, users within the private network, and computers within the private network have direct access to the domain controllers.

Placing the domain controller behind a stand-alone router helps prevent Internet users from directly accessing the domain controller. To minimize security risks, place the domain controller on the same network segment as the client computers. In addition, use VPN tunnels to ensure that the router communicates exclusively with the organization’s hub or central location. Prevent any other requests that originate from the Internet from reaching the network segment of the branch office and, subsequently, the domain controller.

Figure 8 shows a perimeter network in which domain controllers are positioned outside the firewall that protects the internal network.

Placing Domain Controllers in Branch Offices

In branch offices, domain controllers often provide other services, such as file or print services, to users in the branch office. These multifunction domain controllers communicate with the rest of the organization through a routed connection, possibly a dial-up modem that is managed by a stand-alone router. The stand-alone router provides the isolation and firewall functionality to protect the domain controller and the users in the branch office.

Place the domain controller behind the stand-alone router to prevent Internet users from directly accessing the domain controller. Place the domain controller on the same network segment as the client computers. Ensure that the router communicates exclusively with the organization’s hub or central location by using VPN tunnels. Prevent any other requests that originate from the Internet from reaching the branch office’s network segment and, subsequently, the domain controller.

Figure 9 illustrates the placement of a domain controller in a branch office.

In addition, a modem can provide out-of-band management capability for a remote domain controller. The modem directly connects to a COM port on the domain controller, to remote management hardware (such as the Compaq RILO board), or to an intelligent UPS. This out-of-band management capability can provide the ability to perform BIOS configuration, boot process monitoring and selection, and turn the domain controller on and off.

Ensure that the number to the modem is kept secret. Require the modem to call back to a predetermined list of numbers, and require user identification for callback.

Securing the Remote Restart of Domain Controllers

In some situations, your domain controllers might require remotely administered management, or they might be placed in branch offices outside your organization’s datacenter. In these situations, the restart of a domain controller must be performed remotely. You can use a Terminal Services client on Windows 2000 and earlier computers. On Windows XP and later desktops, Remote Desktop Connection is the Terminal Services client.

Tasks that must be performed during the remote restart of a domain controller include the following:

• Selection of the Windows Server 2003 boot options

• Configuration of the BIOS on the domain controller

Terminal Services is unable to perform these tasks because Windows Server 2003 must be running to support Terminal Services. These tasks require additional hardware to support remote restart functionality. Examples of this type of hardware include the following:

• Smart UPSs

• Remote access hardware that is integrated into the server, such as Compaq RILO or Dell DRAC III boards

• Video switches that connect to the keyboard, mouse, and display that provide services that are similar to Terminal Services

Most of these devices communicate by using RS-232 or Ethernet, and they have only rudimentary security, such as a password. In datacenters, the devices that communicate through RS232 are connected to a terminal concentrator. The terminal concentrator multiplexes a number of RS-232 connections into a single RS-232 or Ethernet connection. Smart UPS and remote access hardware typically communicate through Telnet.

Secure the remote restart of domain controllers by doing the following:

• When the domain controller is in a datacenter, connect the remote restart device’s RS232 or Ethernet connection to a network segment that is dedicated to network management and that is isolated from clients.

When the domain controller is in a branch office, connect the remote restart device to a dedicated modem, and require the modem to provide password identification and callback functionality.