Steve Riley on Security : Active Directory

Directly connect to your corpnet with IPsec and IPv6

Steve Riley — Wed, 25 Jun 2008 23:55:00 GMT

Contrary to popular belief, the rumors of my demise have been greatly exaggerated. Well, ok, no actual rumors, but hey, one can dream, huh? My spring calendar was full of events in Asia and Australia, then TechEd US seemed to suddenly appear out of nowhere! So I've been kinda swamped. I've missed writing here; it's good to get back into the swing.

At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)

I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:

Windows Vista Enterprise or Ultimate editions (those with Business edition and Software Assurance can upgrade to Enterprise)
That are domain-joined
Users run as non-admin
Group policy applies numerous settings
UAC is enabled
BitLocker is configured to protect confidential information stored offline
The Windows Firewall is enabled
NAP is used for checking health
Forefront Client Security for keeping malware off the box
Smart cards for strong authentication of users
IPsec is required for connection authentication and traffic encryption
IPv6 is required for worldwide Internet connectivity
A DNS suffix search list represents the data center name space
Static IPv6 DNS servers provide name resolution for hosts in the data center

What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog :)

Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!

Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).

Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.

Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"http://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.

For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.

My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.

I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.

Why administrative passwords will never be like nuclear missile launchers

Steve Riley — Tue, 21 Nov 2006 13:16:22 GMT

During the past few months many people have lamented that Windows lacks a nuclear missile style control option for administrator passwords. Surely you've read about or seen photographs of missile silos where two operators, separated by a distance greater than the span of a single human's arms, must each simultaneously turn a key in a switch to launch a missile. Such a fail-safe is important when considering missile launches: presumably a nation can't thus be committed to global thermonuclear war on the deranged whims of a single raving lunatic.

At first glance, it seems reasonable to allow for similar control over domain and enterprise administrator accounts. A while back I wrote about the fundamental requirement of trust in administrators; missile control-style passwords (is there some official term for this?) might lessen the requirement for such trust, goes the thinking. Well, I'm not convinced that the logic that works for missile silos extends to administrator passwords. Let's examine the differences.

It works for missile silos because the fail-safe is tuned to the characteristics of its environment. It takes two keys, each of which must be rotated simultaneously, and they're separated by around ten feet or so: therefore, two humans absolutely are required. To accidentally or intentionally launch a missile when not under orders, both people must be either equally stupid or equally insane -- and in the second case, also equally trust that each is, in fact, a criminal, rather than one acting as a double agent attempting to entrap the other. Furthermore, both operators perform the function in full view of a whole lot of government staff and military officers. The environment and the fail-safe work together to keep the deadly missiles in the ground. Another important aspect is this: the silo and its control system are designed by and operated by the same entity, the government.

Now compare that to a domain controller. Let's say that it's possible to enable a feature that requires entering two passwords. Where would you do this? A logon screen with two password entry fields lacks both physical and human separation: one person could enter both passwords if he or she knew them. It's no better with smartcards -- again, one person could insert both cards into the readers. Replicating a silo-like environment using a pair of computers isn't the answer, because unlike the silos and their control systems, Microsoft designs Windows but you operate it. The fail-safe works for the silos because of the required physical separation. Microsoft can't dictate, and certainly can't enforce, that you have two domain controllers, separated by at least ten feet. Not everyone can afford all the necessary hardware; plus, think of the demands that would place on space and power in a data center. And besides, even with separated domain controllers, a malicious admin need only to enter the first password or insert the first smartcard in one computer then wheel over to the other one and enter the second password or smarcard there. I'm not sure there's a way to check for simultaneous credential entry.

Separation and delegation of administrative duties is, of course, a good and important concept, one that we'll continue to refine throughout the operating system. There's a lot of power granted to administrators right now, this power we will help you segregate among multiple roles (humans) in your organization. But because of the nature of computer systems, any human granted a particular bit of administrative power must be trusted with that power. Computer systems and the data they store, process, and protect aren't silos; applying silo-style security is the wrong approach to mitigating security risk.

Domain controller security: it starts at layer zero

Steve Riley — Sat, 11 Mar 2006 00:15:00 GMT

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
http://www.microsoft.com/downloads/details.aspx?FamilyID=c0dbeb7e-d476-4498-9f6c-24974fb81f1e&DisplayLang=en

Security considerations for trusts
http://technet2.microsoft.com/WindowsServer/en/Library/1f33e9a1-c3c5-431c-a5cc-c3c2bd579ff11033.mspx