Domain controller security: it starts at layer zero
Recently I seem to have had the same conversation over and over again, in places as far apart as Jakarta, Winnipeg, and Berlin. The question is usually worded like this:
"What happens if someone steals one of my domain controllers?"
There is, essentially, only one correct answer, which is this:
"You flatten and rebuild the entire forest."
Not very comforting, I know. Consider this example.
A customer once liked to display all their shiny computer gear behind a large plate-glass window that faced the street (complete with labels indicating the telephone numbers of all the modems, but that's a different problem). One day, some dishonorable thugs decided to help themselves to a computer, so they smashed their pickup truck through the window, snarfed the first computer they saw, threw it into the back of the truck, and sped away. It just so happened that this computer was . . . a domain controller! They called the police and described the truck and the theft; the police found the thieves, recovered the computer, and returned it to the customer -- who proceeded to reconnect it to the network. Alas, a very unwise decision.
Think about it for a moment: a bad guy had physical access to that which is the source of authority for every security principal in the forest. Who knows what he's done? Some possibilities:
- Extract password hashes from the AD database (no need to crack the passwords themselves now)
- Install malicious self-replicating code
- Add rogue user, service, and administrator accounts
- Create or modify logon scripts
Honestly, this is a machine you can no longer trust. And if the bad guy still possesses the computer and manages to reconnect that Typhoid Mary of a DC back to your network, and forces a replication to the other DCs in the forest, well...it frightens me to think of the ramifications.
Back in the Windows 2000 days, Microsoft published some best practices for securing domain controllers. Part II (which I've linked below) contains a section called "Recovering from the physical breach of a domain controller." Ten thickly worded pages guide you numerous manual and time-consuming (read: potentially error-prone) steps for working the bad guy out of your forest. I suppose all that might succeed, but really you can't trust that forest anymore. Rebuilding it from the ground up is your only practical choice. Yes, FDISK is your friend.
Managing risk
Regular readers of my articles and attendees at my conferences know the point I'm making here. In the case of domain controller physical security, the question usually arises when customers begin placing domain controllers in locations outside the central headquarters. For we in the United States, where connectivity is amazingly cheap and highly reliable, no one thinks of placing domain controllers in far-flung offices with only three people, two cats, and a creaky vending machine disgorging year-old pretzels (when it's in the mood).
But in other areas of the world -- areas where bureaucracy-laden telcos, often remnants of tin-pot dictatorships, dispense bandwidth as if it were glittering emerald encased in pure platinum (with stratospheric monthly charges to match) -- organizations must make a security vs. usability tradeoff. Security prefers that all DCs remain safe in a central data center and all authentication traffic traverse the WAN; usability demands that DCs be placed where the people log on because WAN links die so frequently. In this scenario, I hope you agree with me that usability wins: if the people can't log on, they probably can't do their jobs; secure environments are useless if idle workers can't access them.
Therefore, you have to accept the risk, and situate domain controllers as close to the people and resources as possible. I have two suggestions for mitigating risk.
Cage that beast. Numerous manufacturers offer steel cages in which you can encase your remote domain controllers. Limit your selection to those that include some form of physical anchoring, such as a large heavy chain attaching the cage to a bolt or eye screwed deep into a concrete floor. Be sure the cage includes a decent lock -- an electronic lock is best, one that can audit all access. Remember, you're protecting not only the hard drive but the whole computer.
Consider multiple forests and selective authentication. Surely you've learned that Microsoft long ago stopped recommending single forest/single domain AD designs; yes, we were wrong about that. Because the forest is the true security boundary, implementing multiple forests helps contain the spread of any compromise. But to make multiple forests useful, you need to implement trusts. Typically, those are unidirectional: central corporate resource forests trust distributed user forests. There is the potential, at least, that the central forests might be trusting a compromised forest -- at least for a time -- and could themselves become compromised.
A feature known as selective authentication lessens the risk. It's an authentication permission set on the security descriptor of the resource computer object located in AD, not on the security descriptor physically located on the resource computer itself. Controlling authentication in this way provides an extra layer of protection to shared resources by preventing them from being randomly accessed by any authenticated user in the trusted distributed user forests. Now, if one of these user forests is attacked and requires a rebuild, you don't have to rebuild the entire trusting forest also -- only the machines in that forest enabled with selective authentication of principals in the attacked trusted forest. See the second article below for more information on selective authentication; scroll down about one-third.
So protect those domain controllers! No, they don't store your company secrets; yes, they're pretty much just plumbing in your network, but I'm sure many of you have experienced the painful inconvenience and overwhelming urgency associated with malfunctioning plumbing... Plus, consider Active Directory designs that contain threats and mitigate risk. Perhaps my 60-second AD design will work for you:
- Forests and domains represent geography (geography is stable and doesn't move -- much)
- Organizational units mirror your administrative model (types of machines and people)
- Security groups follow your organizational chart
- Selective authentication, not mere trusts, controls and limits access
It's simple, it's effective, it removes the politics from the design, and you don't need to pay an army of too-smart-for-school suits -- I mean consultants -- to pretend to labor over a customized design "just for you" that's really the same thing they did for the previous 1,000 customers but still costs you dearly.
Best practice guide for securing Active Directory installations and day-to-day operations: part II
https://www.microsoft.com/downloads/details.aspx?FamilyID=c0dbeb7e-d476-4498-9f6c-24974fb81f1e&DisplayLang=en
Security considerations for trusts
https://technet2.microsoft.com/WindowsServer/en/Library/1f33e9a1-c3c5-431c-a5cc-c3c2bd579ff11033.mspx