Security WatchLock Up Your Domain Controllers

Steve Riley

Recently I seem to have had the same conversation over and over again, in places as far apart as Jakarta, Winnipeg, and Berlin. It starts with a question, usually worded like this:

"What happens if someone steals one of my domain controllers?"

There is only one correct answer:

"You flatten and then rebuild the entire forest."

Not very comforting, I know. Consider this example. A customer once liked to display all of the company's 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 thugs decided to help themselves to a computer, so they smashed their pickup truck through the window, snatched 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! The customer 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 the system that is the source of authority for every security principal in your forest. Who knows what he's done? Here are some possibilities:

• Extract password hashes from the Active Directory® database (no need to crack the passwords themselves now—see "Frequently Asked Questions About Passwords" for more information).
• Install a malicious self-replicating virus or other malware.
• 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, manages to reconnect that Typhoid Mary of a domain controller (DC) back to your network, and forces a replication to the other DCs in the forest... well, it frightens me to think of the possible ramifications.

Back in the days of Windows® 2000, Microsoft published some best practices for securing DCs. Part 2 contains a section called "Recovering from the physical breach of a domain controller." Ten thickly worded pages guide you through 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 you really 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 conferences where I've presented know the point I'm making here. In the case of DC physical security, the question usually arises when customers begin placing DCs in locations outside the central headquarters. In the United States, where connectivity is amazingly cheap and highly reliable, we rarely need to bother with placing DCs 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 governments now long gone, dispense bandwidth as if it were a glittering emerald encased in pure platinum (with stratospheric monthly charges to match)—organizations must make a security-versus-usability trade-off. Security prefers that all DCs remain safe in a central datacenter 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 four suggestions for mitigating risk.

Cage that beast. Numerous manufacturers offer steel cages in which you can encase your remote DCs (See MSN Search results). 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 stopped recommending single forest/single domain Active Directory designs long ago. 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 that the central forests might be trusting a compromised forest—at least for a period of time—and therefore 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 Active Directory, 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 I've highlighted in the "Security Resources" sidebar, Security Considerations for Trusts, for more information on selective authentication.

Deploy read-only domain controllers. A third alternative, scheduled to be available in the forthcoming release of Windows Server®, code-named "Longhorn," is to use read-only domain controllers in branch offices. The unattended version of the DC promotion utility gives you the option. A DC promoted this way contains a read-only replica of the Active Directory database. When users log on, they are authenticated via Kerberos referral from a full DC; the read-only DC caches password hashes only for those users in the branch office. This somewhat reduces the scope of the threat to a forest—if someone steals a read-only DC, then only the branch-office user accounts will need to have passwords reset.

Consider Active Directory designs that contain threats and mitigate risk. Perhaps my 60-second Active Directory 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.

This design is 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—er, 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.

So protect those domain controllers! No, they don't store your company secrets, and yes, they're pretty much just plumbing in your network. But when you recall the painful inconvenience and overwhelming urgency associated with malfunctioning plumbing, I'm sure you'll agree that repeating such an experience is certainly something to avoid.

Security Resources

• Best Practice Guide for Securing Active Directory installations and Day-To-Day Operations: Part II
• Security Considerations for Trusts

Laws of Security

Law #3: If a bad guy has unrestricted physical access to your computer, it isn’t your computer anymore.

The 10 Immutable Laws of Security

Steve Riley, a senior security strategist in the Microsoft Security Technology Unit and contributing editor for TechNet Magazine, jets around the world to speak at conferences and spend time with customers to help them get and stay secure. His latest book is Protect Your Windows Network (Addison-Wesley, 2005). You can reach him at steve.riley@microsoft.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.