2003 Migration and Domain Isolation Policies

You’re migrating from Server 2003 to Server 2012 R2, why not take the opportunity to enhance security with domain isolation policies?

Migrating from Server 2003 gives you many opportunities to change the way that clients in your organization interact with servers. One of the changes you can make is to implement domain isolation policies. The basic idea is that you configure a firewall policy so that servers in your organization will only communicate with clients that have been authenticated using a chosen method. That method could be proof of domain membership, a correct certificate, or even, though it’s less secure, a shared secret password.

The idea behind domain isolation comes from the recognition that the LANs of the early 21^st century are very different environments from the LANs of the late 20^th. Unfortunately much of the thinking around LAN security comes from people who learned about technology in the late 20^th century and a not-insubstantial number of these people haven’t really got around to adjusting their thinking.

In the 1990’s, for example, an organization could be reasonably sure that any computer that was connected to their internal network was authorized. Most people weren’t carrying around laptops and not every network had DHCP deployed. If you were going to connect a computer to a network (many of which were coax 10Base2 networks) you needed a network adapter. Unlike today where network adapters are ubiquitous, back in the mid 1990’s, for most people they weren’t something that was a part of their regular computing experience. So internal networks hosted computers that were put there by IT Pros who were likely the ones that installed the network adapter hardware, loaded the drivers, and connected the network adapters physically to the wired network.

When Windows Server 2003 was released, patch cables weren’t generally something you found on the shelves of your local office supplies store for a couple of bucks. For the most part, computers on your organizational network back in 2003 were also put there by IT Pros. Very few people were trying to connect their own personal computers to the organizational network.

Today, a substantial number of computers don’t need to physically connect to an organizational network because they do it wirelessly. Connecting personal computers to organizational networks is so common that the term BYOD has entered the professional slang.

Where is the past we could be reasonably sure that any computer on the internal network making a connection to a server was a computer that should be able to make such a connection, today there’s less reason to believe that a host on the internal network is always going to be legit.

This is where domain isolation policies come in.

Domain isolation policies allow you to limit which hosts a server will communicate with on the basis of whether that host can correctly identify itself. The idea being that you can improve security and reduce the chance of a successful attack against a server by restricting which hosts can communicate with that server.

You can configure domain isolation policies using Group Policy. You can use them in conjunction with IPsec policies to ensure that not only will servers only communicate with authenticated clients, but to ensure that the communication between client and server is encrypted.

Domain isolation policies won’t make your servers “bulletproof” – but when migrating from Server 2003 to Server 2012 R2, you should also consider all the ways that you could improve security. Domain isolation policies are one aspect of possible improvement.

You can learn more about configuring domain isolation policies by consulting the Server and Domain Isolation Using IPsec and Group Policy guide, available to download from Microsoft’s website at: http://www.microsoft.com/en-au/download/details.aspx?id=18358