Securing Server 2003 Domain Controllers

Physically Securing the DCs

The first (but probably most overlooked) step in securing your network’s domain controllers is to ensure that they cannot be tampered with physically. This means locating them in a locked server room to which access is strictly controlled and documented. Don’t depend on a physical version of “security through obscurity,” thinking that putting these critical computers in an out-of-the-way but unlocked closet will thwart a determined data thief or saboteur.

As police officers who specialize in crime prevention will tell you, there is no way to make a home, a business, a car – or a server! – one hundred percent secure. Security measures are designed not with the objective of making it impossible for the “bad guys” to get to your valuables (which is sure to fall short), but with the goal of making it as difficult and inconvenient as possible. Every minute by which you can slow them down makes it more likely that they will give up and stop trying or, even better, that they will be caught in the act.

Physical security, then, should be deployed in multiple layers. The lock on the server room door is only the first layer. This can be considered perimeter security, like the fence around your yard or the locks on the doors of your home. In case this outer security is breached, there should be further security measures as you get closer to the “prize” (in this case, the DCs). In protecting your personal valuables, you might deploy a security alarm system to notify you and/or the police if the fences and locks don’t do their job. Likewise, you might consider an alarm system in the server room that will sound if an unauthorized person (who doesn’t know the code for disarming it) does get into the room. In addition to door sensors, if the room has alternate means of entry such as windows or large vents (we recommend that these be removed but that’s not always possible), consider motion detectors.

As you construct your multi-layer security plan, work your way inward, always asking the question “What if this security measure is defeated? What new obstacle can we then place in the intruder’s path?” Just as you might place your money and jewelry inside a safe inside your alarm-protected, locked and fenced house, you should consider security at the server itself. Some measures include:

• Removing all external or removable media drives, such as floppy drives, CD/DVD drivers, external hard drives, zip drives, flash memory drives, etc. This will make it more difficult for the intruder to upload a program (such as a virus) to the server or download data from it. If you aren’t using them, it is also wise to disable (either through the BIOS or by physically removing them) ports that could be used to connect external devices, including USB/IEEE 1394, serial ports, parallel ports, SCSI ports, etc.
  
• Locking the case so that an unauthorized person cannot steal the hard disk or damage the machine’s components.
  
• Completely enclosing the server in a locked cabinet or cage (be sure to provide adequate ventilation) into which electrical outlets are built so that the intruder cannot easily get to the computer’s power cord or UPS to interfere with power to the system.

Protecting the DCs from Remote Intrusions

Once you feel comfortable with your physical security plan, you must turn your attention to preventing hackers, crackers and attackers from accessing the domain controllers over the network. Of course, the “best” way to do that is to unplug the machines from the network – but that would render them useless. So instead, you need to take steps to harden them against common attack methods.

Securing the Domain Accounts

One of the easiest (for the hacker) and surprisingly, one of the most common ways of gaining access to the network and the domain controllers is by logging on with a valid account and password.

With a typical setup, there are only two things a hacker needs to know in order to log on: a valid account name and the password that goes with the account. You make his job easier if you continue to use the default administrator account, the name of which (“Administrator”) every hacker knows. Now he only needs to discover one piece of information. And unlike other accounts, the default administrator account can’t be locked out if excessive failed attempts to log on occur. This means the hacker can just keep on guessing (using the “brute force” method to crack the password) until he gets it right.

That’s why you should always rename the built-in administrator account first thing. Of course, renaming won’t do much good if you forget to delete the default description (“Built-in account for administering the computer/domain”). The whole idea is not to help the intruder along by quickly identifying for him the account that has administrative privileges. Remember, all you’re doing with all these measures is slowing down the intruder. A truly determined and knowledgeable hacker may find a way around your security measures (for example, the SID for the administrator account can’t be changed, and it always ends in 500. There are software programs hackers can use to discover the SID and thus identify the admin account).

It is possible, in Server 2003, to disable the built-in administrator account completely. In this case, you must first create another account and give it administrative privileges. Otherwise, you’ll find yourself unable to perform some essential tasks. The built-in guest account should always be disabled (as it is by default). If you want to give guest privileges to some users, create a new account with a more obscure name and limit its access.

All accounts – but especially administrative accounts – should have strong passwords consisting of 8 or more characters, alpha, numeric and symbol characters, lower and uppercase letters, that are not dictionary words. Users should be cautioned not to write down their passwords or share them with anyone (social engineering is one of the most common means by which unauthorized persons gain access), and policies should be in place forcing a password change on a regular basis.

Relocating the AD Database

The Active Directory database is full of critical information and should be protected from attack. One way to do this is to move these files from the default location where an attacker will expect them to be (on the system volume). For further protection, consider moving them to a striped or mirrored volume so they can be recovered in case of disk failure.

The files in question include:

• Ntds.dit
  
• Edb.log
  
• Temp.edb

NOTE

You can use the NTDSUTIL.EXE tool to move the database and log files. Here’s how:

1. Restart the domain controller.
   
2. Press F8 on startup to access the Advanced Options menu.
   
3. From the menu, select Directory Services Restore Mode.
   
4. If you have more than one installation of Windows Server 2003, select the correct one and press ENTER.
   
5. At the logon prompt, log on with the administrator account that was selected during the DCPROMO process to be used for Active Directory Restore.
   
6. Click Start | Run and type cmd to bring up a command window.
   
7. At the command prompt, enter NTDSUTIL.EXE
   
8. At the NTDSUTIL prompt, enter FILES
   
9. Select the database or log file you want to move. Enter MOVE DB TO or MOVE LOGS to
   
10. Enter QUIT twice to return to the command prompt and close the command window.
    
11. Restart again to boot into Server 2003 normally.

Securing Password Information with Syskey

Some of the most security-sensitive data that’s stored in Active Directory is password information for domain accounts. The System Key (Syskey) is used to encrypt the account password information stored in the directory services database on the domain controller.

There are three modes in which Syskey operates. In mode one, enabled on all Server 2003 computers by default, a system key is generated by the computer randomly and an encrypted version of the key is stored locally. In this mode, you can still restart the computer normally.

In mode 2, the system key is generated and stored in the same way as with mode 1, but an additional password, selected by the administrator, provides further protection. When you restart the computer, you must enter this system key password during startup. This additional password is not stored locally.

Mode 3 is the most secure method of operation. The computer-generated key is stored on a floppy disk instead of locally. You can’t start the computer unless you have physical possession of the floppy disk, as it must be inserted in the disk drive when you are prompted during startup.

Note

Before implementing mode 2 or 3, consider logistical factors involved. For example, inserting the floppy disk containing the syskey password requires an administrator on-site; this means you would not be able to reboot the server from a remote location if no one is on-site to insert the floppy disk.

Here’s how to create a system key:

1. Click Start | Run and type CMD.
   
2. At the command prompt, enter SYSKEY.
   
3. Click UPDATE. The ENCRYPTION ENABLED option should be selected.
   
4. To require a syskey startup password, click PASSWORD STARTUP.
   
5. Enter a strong password (the password can be from 12 to 128 characters).
   
6. If you don’t want to require a startup password, click SYSTEM GENERATED PASSWORD.
   
7. The default option is STORE STARTUP KEY LOCALLY. If you want to store the key on a floppy disk, select STORE STARTUP KEY ON FLOPPY DISK.

If you use the mode 3 option, storing the password on a floppy disk, be sure to create a backup of the floppy disk.

It’s important to understand that if you lose the floppy disk or it becomes damaged, or if you forget the administrator-selected syskey password, there is no way to recover other than reinstalling the domain controller.

Summary

Protecting your domain controllers is a vital part of your network security strategy. In this article, we discussed how to physically secure the DCs, how to secure domain accounts, relocating the Active Directory database files, and how the Syskey utility is used to protect account password information stored on the domain controller.