Deploying DirectAccess – Notes from the field

DirectAccess is one of those technologies that when deployed right, can deliver a huge benefit to users. Unfortunately, when deployed not-so-right things can go awry fairly quickly.

In my role I get to perform health checks on customer deployments of DirectAccess on a regular basis, and wanted to share the top issues and recommendations I run across so you can take them onboard as part of your planning and implementation.

That said, I won’t cover everything - my goal is to cover the top things I see not considered in real world deployments.

In the beginning…

For those that aren’t aware – DirectAccess (DA) is a remote access solution that allows seamless access back to the corporate network, regardless of the location of the client computer. In a nutshell, DirectAccess works by establishing tunnels (IPSec) back to edge servers (called DirectAccess Servers) – these tunnels are established automatically, without user intervention (that's the “seamless” part :-))

DirectAccess has evolved from it’s original introduction in Windows 7 and Windows Server 2008 where there were a large number of deployment blockers. DA is an IPv6-only technology and in it’s initial conception only supported access networks and resources that were IPv6 enabled. To access IPv4 networks you required a 3rd party device or server to perform NAT64 and DNS64 which translates traffic between IPv6 (DirectAccess) networks, and IPv4 (corporate) networks, similar to the way NAT works on your home router by translating traffic from the public internet to your internal network.

In our Unified Access Gateway (UAG) product, we introduced these capabilities in box. For the first time, a single server could both act as a DA server, and perform the NAT64 translation specified above. We also made it easy to scale beyond a single server by supporting array functionality in-box, which is essentially Windows NLB. Even though the UAG release was a huge step forward for DirectAccess there were still some issues – most notably the requirement of two consecutive public IPv4 addresses for Teredo and the need to place the DirectAccess server in such a way that it could accept traffic directly from the Internet, yet needed to be domain joined. As you might imagine, this gave people shivers up their back a little for various reasons – some unfounded but others quite real especially in terms of needing to burn multiple consecutive public IP addresses for the purpose.

Enter Windows Server 2012 DirectAccess – where all the great features from the UAG release were integrated in-box in the OS once again, with two primary added benefits (there are actually heaps of others – but in the interests of brevity..):

• Multisite support – Clients can automatically connect to a configured DirectAccess server or array that is nearby them in terms of Internet connectivity. This feature requires Windows 8 or later clients.
• Simplified deployment eliminating the need for a PKI – This is a big deal as well, especially for smaller environments that do not have or don’t want to have a Public Key Infrastructure configured to issues certificates for IPSec. In this model, we still use IPSec but use a new Windows Server feature called Kerberos Proxy to provide strong authentication and associated keying for IPSec. This feature also requires Windows 8 or later clients.
• IPHTTPS-only deployment – The big one. This means that DirectAccess servers can be deployed behind a ‘edge device’ and only be configured for IPHTTPS (instead of IPHTTPS, Teredo and 6to4). This way you can put a reverse proxy or load balancer in front of DirectAccess without needing DirectAccess servers to listen on the Internet. This also by extension eliminates the two consecutive IP address issue discussed earlier.

Anyway, onward and upward.. I’ve divided the categories of frequent issues into two categories; Deployment Model and Security.

Deployment Model

One of the things that should be decided early on is around the planned deployment model. Essentially there are three primary decisions to be made here – the access model, high availability, and public key infrastructure (PKI).

Access Model

There are two access models, end-to-end and end-to-edge.

In the end-to-end model, traffic is secured via IPSec from the endpoint (client) right through until it reaches the destination server on the corporate network. Such a configuration provides the best security, and works well for organisations already employing IPSec to secure server communications today.

 
Above: End-to-end access model

In the end-to-edge model, the IPSec encryption associated with the clients access terminates at the DirectAccess server. Traffic is then emitted on the corporate network in it’s native protocol and format (for example, HTTP, or SMB traffic) and is not further protected over and above what the protocol natively offers. This model is most analogous to the VPN model where the endpoint is the VPN server or appliance.

Above: End-to-edge access model

High Availability

Do you need high availability? If you don’t want users to have an outage every time you patch the server, or if it fails – then you most certainly do!

Remember that deploying with HA now with at least two nodes will save you the headache later of moving to a load balanced model (although you can change if you need to). Management also looks slightly different when you’re dealing with an array of servers, so if that's your likely path, best set down that road now.

Obviously to achieve HA you’ll need at least two servers, and they’ll need to meet the standard Windows NLB requirements if using that, otherwise you can use an external load balancer.

Public Key Infrastructure

This is a curly one. So with PKI there are two options – with PKI, or without PKI. I’ve drawn a handy chart to help you make the choice:

What does this mean? If you aren’t completely allergic to PKI – you should use that as it opens up far more features and capability. However, if you just can’t stand PKI and the requirements listed below, you can safely deploy without PKI, it’s just not recommended because you won’t be able to get HA support (that’s bad – see section above).

You will have two types of certificates for this:

• SSL/TLS Certificate for DA servers for use with IPHTTPS
• Computer certificates for the DA Servers and Clients for IPSec authentication and tunnelling

The Certificate Revocation List (CRL) location should be highly available – particularly for the SSL certificate as without being able to check this clients will be unable to connect. By default, strong CRL checking is not enabled for IPSec, but you can turn that on if you want a way to ensure that revoked certificates are immediately unusable by DA clients.

The other catch about the CRL location is that it must be accessible from the Internet, so publishing just to Active Directory or an internal web / file server is not sufficient. For this reason, many customers use an external vendor issued SSL certificate as they already have CRL locations that are available on the internet and are (generally) highly available.

Security

Look! It’s everyone’s favourite topic – security!

As you would expect there are a number of security considerations with DirectAccess, the ones I see mostly overlooked are:

Full Hard Disk Encryption

With DirectAccess you are essentially extending your corporate network to include clients as they move around. This does mean that you want to ensure that client endpoint security is well suited to that. One of the key things you can do is to enable full hard disk encryption on the mobile computers that are enrolled for DirectAccess.

There are many good reasons why you should enable full hard disk encryption (such as BitLocker) on your machines that have nothing to do with DirectAccess (let’s cover that another day..) but the key consideration for DirectAccess is you want to prevent offline attacks against the machine by removing the hard disk or booting to another operating system other than your desired, secured one.

Enabling BitLocker doesn’t have to be a headache – if you’re fortunate enough to have access to the Microsoft Desktop Optimization Pack (MDOP) when you have access to a tool called Microsoft BitLocker Advanced Management (MBAM) which can give you lots of control and reporting for BitLocker. It also has snazzy features such as a portal that your helpdesk can use to retrieve BitLocker recovery keys, which is very useful and saves you writing your own to pull the info out of AD.

Revocation Process

With DirectAccess, client computers can connect and bring up the infrastructure tunnel without the user needing to do anything, or even log on. For this reason (and general security cleanliness) you should be ready to respond if a DirectAccess device is lost or stolen. Your existing procedures might already include resetting the user’s password, but because DirectAccess is a computer centric technology (config is delivered to the computer, first level of authentication is computer auth, etc) you’ll need to take additional action to ensure the device can no longer connect.

This is best achieved by disabling the computer account of the lost or stolen device. Once the device cannot authenticate as it’s computer account, it’s going to be dead in the water. It’s good practice to also revoke the client’s certificate if PKI is in use, although the killing blow is dealt by disabling the computer account – so do that as a matter of urgency.

However, here is the most important part: document your access revocation process! If you don’t have one documented before now – it’s more important than even now that you’re expanding the types (and potentially, the prevalence) of remote access in your organisation.

Well, that’s all from me, how about you? Are there any other areas you think need documenting or I’ve missed?

Definitely more to come later on DirectAccess and as promised, BitLocker.

Ash.