Windows Server Customer Engineering : Identity and Access Control

Using the FREE network security tools you get in Windows (and who doesn't love free tools?)

pfetty — Fri, 20 Feb 2009 01:42:00 GMT

In my last post I talked extensively about the use of 802.1x for network authentication (wired or wireless) and talked about the benefits of the 2 common approaches to controlling machine access (VLAN vs. Port ACL). While 802.1x remains a very popular mechanism for controlling port based access for machines coming onto the network, it also has some significant requirements associated with it, primarily, having 802.1x capable switches and/or access points in place today. You would be surprised how many people think that their devices support this capability, but in reality, they may find that this is not the case. What this means is that if your hardware vendor tells you that what you have isn't 802.1x capable, be prepared for some sticker shock when you find out how much it will cost for an upgrade!

Given the state of IT budgets today, doing a massive hardware upgrade is probably not something you are prepared to do now, or any time in the near future. That being said, you still have the requirement of securing the endpoints that are on your network and ensuring that they are kept up to date with patches, AV signatures, Anti-Malware Definitions etc. These 2 efforts may seem to conflict, but they certainly don't have to.

Let me introduce you to Server and Domain Isolation (SDI) with IPsec, all built into Windows, all free of charge!

Now, as to not sound like a late night infomercial peddler of dodgy wares, I will explain what I mean by "free of charge". What this means is that if you have purchased Windows Server (any SKU or version) and a Windows Desktop OS (Windows 2000 or later) and an associated Client Access License (CAL) (you usually purchase a CAL when you buy a server from Microsoft), these technologies do not have any additional licensing requirements whatsoever.

Now that we have the cost definition out of the way, let's talk about what these technologies can do for you.

Server and Domain Isolation (SDI)

Simply put, SDI utilizes the IPsec (Internet Protocol Security) technologies that have existed in Windows ever since the days of Windows 2000. What SDI allows you to do is to create access policies based on Active Directory groupings that can require authentication between any set of machines in the network (or all machines). The tools for creating and distributing these policies are also built into Windows and policies are distributed via the Group Policy mechanism, meaning that yes, a machine must be joined to the domain to easily take advantage of SDI. Since we are talking machine and/or user authentication here, there are 2 options for credential use in SDI, they are X509 certificates, or a Kerberos ticket. There are advantages and disadvantages to the use of each of these credentials which I won't go into here, but the message is that there is flexibility here with both credentials being secure (i.e no passwords.)

Now, let's talk about one big option that 802.1x cannot offer you, and that is data encryption.

Many customers have never really ever considered doing any kind of encryption on their network because they probably never understood how easy it is to implement. Many think that there is some hardware requirement, or that their machines will come to a crawl performance wise, when in reality, neither are true. Granted, you have the option to create very stringent policies that require stronger encryption, but in many cases you simply won't need to do something like this, or may choose to bypass encryption all together.

Example

Here's a real world example of how SDI can be used:

The Microsoft network uses SDI technologies to protect our assets. Pat Fetty (aka me) is a known and trusted employee and is allowed to access the network from his office, or remotely every day. However, since Pat is not a Windows developer, pat is unable to access or even see or ping our source code servers. Pat is also unable to see things like our HR server, financial servers etc. How is that you ask, well, Pat is not in the proper security groups in AD to have the proper policy applied to him, or his machines, that allow this type of access.

Using this simple example, think of some of the other scenarios that you, or your customers may be faced with that you may be able to solve. Here are some others I have come across in my job in the WinCAT team:

- Allow only doctors to see patient records, and encrypt all traffic going to and from those servers

- Allow only attorneys to be able to see servers X, Y and Z

- Encrypt all traffic to and from an ATM machine to the banks home offices

- Encrypt all Active Directory synchronizations between servers where traffic is going over the Internet

- Authenticate all traffic from my Windows machines, but exempt traffic from my main frame machines and all Macintosh machines (we'll talk a bit more about this)

This is just a small sample list of real business problems that are out there that SDI can help to solve.

Now, getting back to the last item regarding mainframes (let's just say all *ix) and Macs. There are Ipsec stack implementations available for these platforms, but I have personally not seem them work. As previously mentioned, the Microsoft SDI set of technologies are based 100% on public RFC's so there is no reason to expect that any implementation that is RFC compliant wouldn't work with any Windows machine.

Another reason why this is important is because the tools to build and manage SDI policies allow you to create very simply policies to address this scenario. For instance, you can have a policy that looks like this:

If you are a machine in group A, and you are capable of negotiating IPsec, then negotiate IPsec with a (Kerb ticket or cert)

else

Allow traffic to flow in the clear

You may be asking yourself "what kind of security policy is that" and the answer is that it is one that doesn't disrupt the flow of traffic on the network, and yet will negotiate the security you dictate when possible. This is a very important concept since the reality is that your machines today are most likely not doing any kind of SDI today, so by having your policies based on AD group membership, and by having a "best effort" type of policy like this you can ease this type of technology into your network with little or no disruption!

SDI versus 802.1x

We talked about this at the beginning and I think that SDI is the hands down winner here given that if you are a Windows environment

Deployment

To do 802.1x means you will have to touch all the switches and AP's in your network and configure them to do 1x on their ports, and to then send all traffic to a back end authentication server. In many cases, the group that manages desktops and servers in your company is not the same group that manages the infrastructure, so you now are getting more people involved in the effort.

SDI utilizes Group Policy and other built in tools to distribute policies and credentials, and the best part about this whole thing, is that SDI will work across whatever hardware you have in place today!

Management

This is a bit of a toss up, but I'd give SDI an edge since you can use a variety of methods to manage who is on the network accessing resources. 802.1x usually requires an enterprise ready SNMP (Simple Network Management Protocol) solution either from our hardware vendor or from a third party

Security

This is the one that gets the networking guys feathers ruffled, but I give SDI the advantage here for a couple of reasons. First, SDI offers you the ability to encrypt traffic which is something that 1x cannot offer. Second, in 802.1x, once you get passed the switch you are on the network doing what you please until you either reboot, or the switch kicks you off the port. SDI allows you to control the credential that is given to that client so that if for some reason you need to remove the client from the network, you can more quickly do so via SDI than 1x.

Overall I feel that both technologies here offer up some nice benefits (we didn't even touch on Guest Access which I feel is better done with 802.1x than SDI), but in the end, you should evaluate what your business needs are and make your technology decision on that. Usually the second phase of that decision process is cost, and that is where using the tools we have built into Windows can save you loads of money down the road assuming you plan on running Windows for the foreseeable future (which we hope that you are of course!)

With budgets shrinking and/or disappearing I would encourage everyone to take a look at what you have purchased in the Windows platform and ask Microsoft how to best utilize it because we are definitely here to help you get the most out of Windows!

We need our directory to replicate immediately!

rdeluca — Fri, 21 Jul 2006 08:15:00 GMT

A customer of ours is in the process of evaluating Active Directory and ADAM for use as their primary enterprise application directory. I was just informed that they've dropped Active Directory from the running (it's not in their "top three" directory servers) because "AD replication is scheduled and not event driven". When pressed for more info, they gave the following points:

Event driven replication is perceived to be faster than scheduled replication
AD replication is “pull” vs “push”
AD can't do sub-second replication and they need it
AD performance was great but running everything on one box means no redundancy

It sounds like their app doesn't handle replication latency very well. It expects to be able to read the same data it has written... and a multi-master replication system can cause problems with this. Perhaps their technique for dealing with latency is to wait until replication is complete? Some of the points above are easily refuted, but it leads to a much more interesting question. Let's start with the refuting part.

Event driven replication - Change notification is on by default within a site and is effectively "event driven". The same behaviour can be turned on between sites as well.

Pull vs push - Instead of pushing changes, we push a notification and the destination pulls the changes. Not much difference there.

Replication time - We can reduce replication intervals to about 1 second, but this shouldn't be required if the app handles latency intelligently. Even with other directories, replication is best effort and isn't guaranteed... thus the app needs to handle latency or it will experience intermittent errors.

Perf, single server - Running everything on one box solves the replication latency problem. Moreover, having a second server for redundancy won't necessarily cause a problem with latency, provided the app talks to the second box only when the first box has failed. Other customers have used this model because their third-party middleware solution doesn't handle latency.

What became immediately apparent is that we need to do a better job of explaining how to deal with replication latency in a multi-master environment. I suspect that a lot of LDAP apps have been written without this in mind... some work, some don't, and many will exhibit intermittent errors given the right conditions.

Here's a quote from Don Hacherl on a closely related topic. It sheds some light on why being latency-aware is important:

You'll never see a meaningful urgent replication flag because AD exposes the X.500 data model in which reads from different servers can have different results. If apps aren't prepared to deal with that then all you'll get is an infinite regression of "Well, Urgent wasn't fast enough and my app crashed again. Can I have a Really Truly Super Duper Urgent setting?"

I can imagine an unreliable urgent mechanism (say, urgent changes are multicast out by the source), but even with that you'd still end up with temporary inconsistencies and an inability to offer QOS-like guaranties. If a source server accepts an originating change while a destination server is flat out 100% CPU and I/O working to catch up on other replication (heck, say other urgent replication), what should happen? You'll still end up with latency, and apps will still have to deal with it.

Now what I consider the interesting question. What mechanisms are available to deal with replication latency?

One approach is designating a master server for write operations and critical readbacks. Regular read operations would still hit any of the replicas. In the case of failure, one of the replicas can be quickly designated as the master. This model may require applications to handle reads, writes, and critical reads differently, because they may need to be routed to different replicas. A variation of this approach is to route writes/readbacks in a predictive way to multiple masters, effectively dividing ownership over writes accross multiple masters.

Another approach is to ensure client affinity. There are variations on this model as well - affinity may be handled on a per-session or per-user basis by the application, or perhaps by a hardware or software load balancer. Multiple masters are still used, but each application session or client will communicate with a single master at a time. The decision on how to balance transactions safely across the available masters may need to be handled by the application.

A third approach is to cache the directory data at the application level. This might get tricky, especially when dealing with web clients and application state... but it's certainly possible. The complexity of the caching layer may end up being too high to be practical.

Personally, I think the first approach is the simplest to implement. The application logic is least complex and failover is relatively easy. There is still the potential for the loss of small number committed transactions, but this is a common problem in any multi-master LDAP system. I'm going to dig around a bit and find out how others handle the latency issue. Public and private comments are definitely welcome on this one.

More on multiple forests

rdeluca — Sun, 04 Jun 2006 07:55:00 GMT

I've received a few interesting email messages about my last post on multiple forests (http://blogs.technet.com/wincat/archive/2006/05/23/429988.aspx).

Here's a good excerpt from one of them, verbatim:

“More forests equals more administrative tasks”.

I’d say that it necessarily must also be more complex administrative tasks. It may not seem that way to folks that have been working with multiple forests or are very experienced, but the bottom line is that having another forest to work with means you must either:

a) You need to handle an arbitrary number of forests in code. This code is thus longer and more complex than one that works against a single forest and AD namespace. It may not be much more complex or longer, but it must be to some degree. So now your administrative burden is increased (more code to write, more code to test and vet).

b) Have your scripts run only with one forest in mind and depend on the administrator to be able to keep track of the different forests and make changes as appropriate. Holy bejesus. Can you say operator error?

Which leads us to this:

“If you use scripting, the impact in a multi-forest environment is similar to the impact in single forest because the automated tasks will span all forests.”

But from above, if you use scripts to span multiple forests, I don’t think you can be at the same level of risk. Either your scripts are more complex or your administrators must be. Thus, best case scenario is a higher risk than a single forest.

I also got a few "multiple forests work just fine for us, thank you very much" messages. I want to dig into that a bit more. I'm looking at the risk of multiple forests, not the overall suitability of them. Isolation from service administrators is still the right reason to move towards multiple forests. The risk issues I'm talking about should be used to decide if the isolation requirement is a true requirement or actually more of a preference. Let's look at some cases where multiple forests are effective at reducing risk.

In my prior post, I described one of the scenarios where multiple forests work well - when every business function is covered by at least two forests. The downside is often an environment with significant cross-forest access and added complexity. Let me describe a good exception to this (albeit rare and expensive). I was reviewing a customer AD design with one of our infrastructure architects this week. The customer built two completely independent forests to support a mission-critical application. Half of the app servers are joined to one forest and half to the other. Redundancy is provided at the application level so everything keeps working seamlessly if half of the environment fails. With proper change management controls in place, this helps reduce overall risk. Scripting is still important to ensure adminstrators don't make accidents while making changes, but the impact of an error is limited because the app can run fine if one of the two forests disappears. The only missing piece here is forest recovery. A good forest recovery plan acts as a stop-loss measure, ensuring that the impact of a forest failure is capped at a known quantity. There's a lot to say about forest recovery so I'll save it for another post.

Other multi-forest scenarios that makes sense from a risk perspective? Political reasons always rise to the top of my list. In some cases, a business unit may have no control over the quality of forest admins. Probability of failure is all about administrator error, so a business unit with strong admins might be better off with their own forest instead of relying on weaker admins from another part of the organization. In a perfect world, the strongest admins would run a big forest for the whole company. In reality, the strong admins set up a separate forest for their business unit. Not ideal, but sometimes realistic... especially if the business unit is more important that the others.

Myth debunking: "Multiple forests help us reduce the risk of a forest-wide Active Directory failure"

rdeluca — Wed, 24 May 2006 08:25:00 GMT

More and more customers seem to be using "lower risk" as justification for their multiple forest plan. It may seem reasonable at first glance, but something about it doesn't feel right to me. Since recognizing this pattern a couple of months ago, I've spent a lot of time mulling it over with numerous colleagues.

The first question that pops to mind: how would you decide on the number of forests? Is the right number two? Five? Ten? Fifty? A failure that impacts 50% of your users is probably as bad from a business perspective as one impacting 100% of your users, especially if the forests are divided along business unit or geographic boundaries. Even a 10% outage could be catastrophic. This model could work if every business function were covered by at least two forests, but this would probably result in a complex, difficult-to-manage environment with significant cross-forest resource access.

One of my customers recently proposed ten forests to reduce their risk of failure. Let's use this as an example and compare the ten forest approach to a single forest.

A commonly used formula for quantifying risk is Probability x Impact = Exposure. In a single forest environment, the impact of a forest-wide failure is incredibly high. "Losing the forest" would mean downtime for practically everyone. I'm not sure exactly how to assign a dollar value to this. What I do know is the cost of a 10% partial outage (one of the ten forests) is higher than simply dividing the cost of a total outage by 10. If I had the choice between ten 10% outages and one 100% outage, I'd choose the latter. Based on my conversations with others, I estimate the cost of a partial outage to be 20%-40% of the full outage cost.

What about the other side of the equation - probability? What would cause a forest outage? I'm assuming an enterprise environment with dozens of domain controllers, so hardware failures are out. Some sort of replicated corruption is a possibility, but it is extremely rare. It's so rare that I don't think an accurate probability of replicated corruption can be calculated. The lion's share of forest problems are a direct result of administrator error. What factors can affect the rate of administrator error?
- Environment complexity
- Administrative skill and experience
- Adherence to testing processes
- Automation vs. manual changes

Given the close tie between forest failure and administrator error, I've come up with the following logic:

- Scripting is goodness. It reduces administrative errors in production when coupled with a comprehensive testing process.
- More forests equals more administrative tasks. You can either handle this with more administrators or more scripting.
- If you use more administrators instead of more scripting, your probability of failure increases faster than the corresponding reduction in impact.
- If you use scripting, the impact in a multi-forest environment is similar to the impact in single forest because the automated tasks will span all forests.

And so we're back to square one. The multiple forest environment ends up being a riskier venture, or at best it results in the same risk as a well-managed single forest.

Time for an Active Directory Redesign?

rdeluca — Thu, 06 Apr 2006 10:26:00 GMT

Hi all... I'm Robert DeLuca, the Identity Management guy on WinCAT.

After a year or two of slowly dwindling requests for AD design reviews, there appears to be a growing trend among many of my enterprise customers - full Active Directory redesign. I guess 5 years of living with suboptimal AD designs (You have HOW MANY domains? Site-based group policy for WHAT? Firewalls WHERE?) leads to people wanting a fresh start. I generally don't like messing with things that aren't broken, but a lot of the big players are starting to recognize how much those suboptimal designs are costing them to operate. Extra DCs everywhere... problems supporting roaming laptops and users... difficulty keeping group policy consistent... the list goes on. Then there's the difficult-to-quantify impact on enterprise applications. What is the true cost of not having a stable, standardized corp-wide directory service for app developers to rely on? Redesign sure seems like a nice way out. Or maybe the AD guys are just bored and/or looking for job security? :) Either way, it's gaining traction with management and they often seem willing to swallow the costs of a major migration.

Is a fresh start really the correct way forward? The most important question is why the redesign is desired in the first place. What requirements will be addressed by the new system that weren't being addressed by the old one? I try to separate the operational issues from the true architecture/design issues. If the existing AD implementation is troublesome because of... let's call it a "lack of operational prowess"... building a new forest right beside it won't help unless the root cause of the problem is dealt with too. What seemed like a fresh start quickly ends up in the same operationally degraded state.

I typically recommend that customers go through an AD Risk Assessment (formerly known as an AD Health Check - talk to your Microsoft TAM for details) to help shake these problems from the tree. I'm tempted to make them mandatory before I'll dig into a major redesign effort. Why? Once the operational issues are out of the way, there's much more clarity. If there are still underlying issues related to the forest or domain structure, they can be mulled over without the added pressure of constant operational problems.

Back to the original question - time for a redesign? In reality, most of the troubled forests I see are fundamentally sound. Some customers do have broken designs, but in a vast majority of cases it makes more sense to leverage parts of the existing environment as the basis for the "new" environment instead of building anything from scratch. Granted, figuring out which parts to keep is often a challenging mix of technology, strategy, finances, and politics... but that's the fun part. If the trend holds, it looks like were going to see much better AD implementations in the years to come.