Share via

Domain controller security: it starts at layer zero

  • Article

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

Comments

  • Anonymous
    March 11, 2006
    "Consider multiple forests and selective authentication" - Can we start to consider that after your products do? Exchange, SMS, etc (mention IIFP as a 'workaround' and I'll stop reading your blog :)? It would really be helpful if there was a strong unification of the best practices and the way the products are designed and work perhaps with a focus on physical as well as data security.

    RODC's don't help much in this scenario either (BDC?) since they don't support the other products. But they are something you didn't bring up in your blog.  Why?  

    I have to be honest, I have a hard time considering a geographical boundary in this day and age as the boundary for forests. It's extremely hard to justify the return to a NT 3.51/4 topology after all of these years and because the products don't fit together very well with it, this comes across as a security only requirement that doesn't take into account the business side.  Am I missing something?

    -ajm
  • Anonymous
    March 11, 2006
    What you're missing, ajm, are some specifics :) ...in what ways do the products lack the support you claim is required?

    I didn't mention read-only DCs because that's a Longhorn feature -- and is therefore not available for customers to use in production right now. I'm rarely in favor of using "wait for the next version" as a routine solution.

    My 60-second design is only a suggestion, one that has actually worked very well for many customers because it does, in fact, address business needs too, for them. I don't see how it's the same as NT topology. In any event, if it doesn't work for you, you don't have to use it.
  • Anonymous
    March 11, 2006
    Thanks Steve. For this, "..I'm rarely in favor of using "wait for the next version" as a routine solution. " I've always respected your opinion. That's why I ask the questions.

    As for the products such as Exchange, a multi-forest scenario does have quite a few issues such as folder sharing of any kind (such as calendar folders, public folders, or shared mailboxes), identity mapping between forests, etc. SMS is not a straightforward deployment either if you use multiple forests and identity management can be quite difficult to map back to the business processes. It's close to unnatural in many companies I've seen. Opinions vary I'm sure, but I can't get behind a geographical boundary as the forest demarcation.  Can you expand on what would warrant that as a boundary (I'm sure it's likely as much to do with the way the business runs as it is geography, but I'm interested to hear your perspective.)

  • Anonymous
    March 14, 2006
    I guess I'm having difficulty understanding the specific scenarios you've got in mind. In my own world (Microsoft corpnet), I live with multiple forests just fine. And I've known customers for whom multi-forest deployments work smoothly.

    Regarding my 60-second design, many of the customers I work with tend to manage environments regionally -- it's their business model and administrative model. Like I said, it's one suggestion among many, one that's worked well for some organizations.
  • Anonymous
    March 31, 2006
    If you had to answer this question in one sentence, the answer would be - You have to (re-)bootstrapping trust across your enterprise.

    Thanks,
    Sanjay
    Formerly Program Manager,
    Active Directory Security
    Windows Server Dev Team
    Microsoft Corporation.

    http://www.sanjaytandon.com/btrust.html
  • Anonymous
    April 04, 2006
    Uh, Steve?  "Physical" is layer 1 already.
    The acronym is: PDNTSPA.
    You can remember it as "People Don't Need To See Paula Abdul", and the letters represent Physical, Datalink, Network, Transport, Session, Presentation, Application.
    What's layer 0, quantum field energy?
  • Anonymous
    April 05, 2006
    Alun, I like to differentiate between two physical layers.

    OSI's layer 1 is about connectors, cabling, pinouts, electrical signals, air interfaces, and so on.

    My layer 0 is about buildings, doors, locks, cages, surveillance cameras, that kind of thing. It's also about an attitude that understands no amount of sophisticated network, host, application, or data security will be effective if your physical security is lacking.

    So yeah, maybe it's a gimmick, but I've been referring to what I call layer 0, or "meatspace," security for some time now. It's an effective device for getting people to think about it!
  • Anonymous
    June 01, 2006
    http://msmvps.com/blogs/ulfbsimonweidner/archive/2004/10/24/16568.aspx - I'm interested in your opinion.

    Ulf