A domain controller is just that—a controller. They control authentication, possibly authorization, some accounting, and generally hold the lifecycle of security identities for everything in your company that uses
As such, special security considerations exist for domain controllers. How do you score on this front? Check out these five tips for hardening the entire environment around your domain controllers (DCs).
1. Limit physical access. This is the single biggest mitigating factor you can provide to
your overall domain controller security package. The overarching issue here is, your domain
controller is the central security authority over everything on your network, and as you well know,
there are many trivial ways to obtain information right off a hard disk if you have local, physical
access to a machine. Hashes themselves offer everything a cracker needs in order to pass himself
off as a true, legitimate, authenticated user, and these are easy to grab if you have the domain
controller’s disk in hand. Not to mention the possibilities of actually logging on via those hashes
and modifying logon scripts, installing malicious programs that replicate to other domain
controllers, and so on.
If you have physical (not virtualized) domain controllers, then before you do anything else, buy a cage and a secure lock and put them behind it. Don’t let a DC run under the admin’s desk, or have your data center be a small closet with no lock. It holds the keys to the kingdom, your company’s security treasury, so secure it like you would blank checks: under lock and key.
2. Design correctly from the start. A properly designed Active Directory topology will contain threats so that even if a DC is compromised, your entire network of forests doesn’t have to be flattened and rebuilt. Make sure your forest and domains reflect the real, physical locations you have in different cities, counties, and countries; have your organizational units match the types of machines and people you have in your company; and let security groups represent the hierarchy of your organizational chart. Then, if a DC in one forest for Europe is compromised, you don’t have to rebuild Asia.
3. Virtualize your domain controllers. By using virtual machines (VMs) as your domain controllers, you can then encrypt the disks on which your virtual hard disks reside using BitLocker or some other full-drive-encryption product. Then, ensure the host machines running those VMs are not joined to the domain. If by some chance someone makes off with your host machine and the DCs, the chances of decrypting the hard drive to get access to the VHDs presents yet another obstacle to an attacker planting nefarious things in your directory.
4. Follow security trust best practices. Know your boundaries, as security experts say. There’s a fantastic guide to understanding trusts and the various considerations therein on TechNet. Pay close attention to the Selective Authentication section, a great way to prevent random access attacks.
5. Secure the Directory Services Restore Mode password moreso than any other password. Directory Services Restore Mode (DSRM) is a special mode for fixing Active Directory offline when something’s gone wrong. The DSRM password is a special back door that provides administrative access to the directory. You use this in an offline, text mode state. Protect this password like it’s the one thing that can sink your forest, because it is just that. You can also download a hotfix for Windows Server 2008 that will sync the DSRM password with the domain administrator account—or, if you already have installed Service Pack 2, you have this utility already. Just use this command:
ntdsutil "set dsrm password" "sync from domain account
<DomainAdminAccount>" q q
Overall, if a domain controller is stolen or otherwise leaves your company’s possession in an unauthorized way, you can no longer trust that machine—but unfortunately, since that domain controller contains everything valuable and secret about your IT identities, the best (and most regrettable and painful) advice is simply to destroy that forest and rebuild it. Which makes the first point in this article the most prescriptive and proactive best practice there is.
ABOUT THE AUTHOR
Jonathan Hassell is president of The Sun Valley Group Inc. He's an author, consultant and speaker in Charlotte, N.C. Hassell's books include RADIUS, Learning Windows Server 2003, Hardening Windows and, most recently, Windows Vista: Beyond the Manual. Contact him at firstname.lastname@example.org.
This was first published in August 2011