Security Advisor

Protect Your Crown Jewels

Tips and tricks for making sure your network's domain controllers remain as secure as possible.

• By Joern Wettern
• 08/01/2007

The first step to securing a DC is to establish and maintain a configuration baseline. Most of this is basic: install current security patches, run anti-virus software, configure auditing and implement a backup strategy. Throw in a few DC-specific hardening steps and you're done. Follow Microsoft's own published tips and the process is fairly painless.

The harder part is figuring out who should belong to privileged groups like Domain Admins and Enterprise Admins. Only the most trusted individuals in your IT organization should be Domain Admins, as they have the power to get to almost any information stored within Active Directory or even destroy an entire AD forest.

Domain controllers are spread throughout branch offices, so there's often the chance that someone who doesn't work in the IT department will be doing some basic administration tasks, like restarting a non-responsive server. When you make someone a DC admin, they automatically become a Domain Administrator and therefore get complete access to AD. Unfortunately, there's little you can do about this other than be careful about whom you let into the exclusive club of Domain Admin.

The simple task of someone logging on to a DC can spell danger. Anyone who learns a Domain Admin's password can completely take over your entire network. It's a good idea to ditch passwords for privileged accounts and require a smart card for logging on with these accounts. Unfortunately, few organizations have the infrastructure for smart cards. You'll most likely be logging on with passwords and taking extra steps to safeguard the passwords for privileged accounts.

Get into the habit of only typing the password at the DC itself. If you need to establish a remote connection, do so from a secure administrative terminal. Unless you completely trust any client computer's security level, don't log on to that computer using an account with domain or enterprise-wide privileges. Malicious software or a hardware keystroke logger could capture the password.

If you need an account to administer your client computers, don't rely on the built-in ability of Domain Admin accounts to do this. You should use a separate account that you add to the local Administrators group on each client computer.

Another option to prevent a Domain Admin password from being recorded is to log on to DCs only at the server itself. Hopefully you've secured your DCs and hardened them more than most of your other computers. If someone managed to install a password capture program on a DC, though, your network's security has already been so badly breached that disclosing your password won't make the situation any worse.

What's the Worst that Can Happen?
The worst potential AD security risks are the breach of a DC's physical security or a rogue administrator. In a nutshell, anyone who gets physical access to your DC or its backup tapes gets unrestricted access to AD.

If you have a compromised DC running in your domain, you have to assume an attacker has taken complete control. They may have also installed hidden backdoors, so the only secure way to recover is to chop down your entire AD forest. Reformat the disks on all DCs and create an entirely new AD infrastructure from scratch.

When a DC is stolen, there may be a short window of opportunity to recover before the thief takes over your network. The recovery steps are still tedious and time-consuming, though.

A dishonest Domain Admin, or anyone who discovers a Domain Admin's password, can cause the same amount of damage as someone who stole a DC. As with a compromised DC, if you have even the slightest suspicion an individual has created hidden backdoors, rebuilding AD is the only secure recovery strategy.

RODCs to the Rescue
Read-only domain controllers (RODCs) are a new feature coming in Windows Server 2008's Active Directory Domain Services. RODCs are designed primarily for branch offices, but you can also use them to minimize the impact of security breaches from a compromised DC or rogue administrator, regardless of the DC's location.

Unlike a regular DC, an RODC saves only a read-only copy of the same data, except for user and computer passwords. The most significant features of an RODC are:

• Unidirectional replication: A rogue administrator or someone who gains unauthorized access to the RODC can't make or replicate changes that will end up on other DCs. If you discover a security breach, you don't need extensive emergency procedures to prevent it from replicating to the rest of your AD.
• Filtered attributes: If you have an application that stores sensitive data in AD, you can prevent the attributes holding this data from being replicated to an RODC where they may not be as secure as on a DC in the data center.
• Credential caching: Since RODCs don't store passwords, authentication depends on having a regular DC available. If that DC is located in a remote data center, it will lead to a large amount of network traffic and users won't be able to log on if the link is down. Configure a subset of accounts for which an RODC can cache credentials to prevent slowdowns.
• Administrator role separation: Unlike regular DCs, an RODC can have local administrators who don't require special rights. This means you can safely delegate administrative tasks-like installing software updates-to someone working in the remote office.
• Read-only DNS: You can configure Windows DCs as DNS servers. This lets client computers dynamically update their addresses in DNS. To prevent replication of bogus dynamic DNS information from an RODC, install DNS on an RODC.

So You Want an RODC?
If you're adventurous enough to run beta software in your production environment, you could add an RODC to your existing AD environment. Typically, though, the computer must run Windows Server 2008.

One thing to keep in mind: If your AD forest functional level is set to Windows Server 2003, a malicious administrator could still re-configure the RODC to replicate data to other DCs. You only get the full protection of RODCs after changing the forest functional level to Windows Server 2008, which requires all DCs to run Windows Server 2008.