Can DirectAccess take over the world?

IPv6 for the masses

The original implementation of DirectAccess as an IPv6-only connection broker was as useful as a chocolate teapot. It is a necessary technology to cope with the future, but was put in place more than five years before it would be required by anything other than edge cases.

The Server 2012 version works (more or less) without the IPv6 requirement. The client computers need to have the IPv6 stack installed and enabled and the DirectAccess server needs a globally addressable IPv6 address.

(This doesn't have to be provided by the ISP; IPs handed out by transition technologies such as Teredo tunnelling, an IPv6 transition mechanism, will do.)

If the client does not have a proper IPv6 address, it can connect to the DirectAccess server using any of the common transition technologies. If the client is in a place where things like 6to4 or do not work (which covers a lot of places), the client can establish an SSL tunnel to the DirectAccess server (IP-HTTPS), obtain an address from there and communicate with the corporate network entirely through this tunnel.

This allows clients with IPv4 network connectivity to establish an IPv6 connection with the DirectAccess server. IPv6 connectivity is a basic element required to use DirectAccess. If the internal servers were all IPv6, you'd be good; most aren't.

The NAT64 and DNS64 protocol translators enable clients to access IPv4 servers and resources across that IPv6 DirectAccess connection.

Additional technologies

Once the basic IPv6 connectivity between server and client exists, additional applications are required to make everything work properly. The NLS is required to let clients determine if they are connected to the corporate network (and thus should not require DirectAccess) or are connected via the internet (at which point DirectAccess will connect automatically.)

If NLS detects that the client is not part of the domain, NRPT is enabled on the client. This is a fundamental element of DirectAccess and requires some exploring.

Briefly, NRPT is a DNS for DNS servers. Normally, you query a DNS server to discover the IP address of a server you would like to communicate with. NRPT is a technology you query when you are not sure which DNS server you should use to fulfill that request, so you look it up against the NRPT rule set.

Get it together

The take home is simple: if you are not on the corporate network (as determined by NLS) and you attempt to access any DNS requests that match the subnets, IPs or fully qualified domain name suffixes used by the corporate network, NRPT tells your computer to query the corporate DNS servers and not simply use the DNS servers coded into the NIC configuration.

Group policy is how all these technologies are lashed together. It is also why your clients must start out domain-joined: when you first deploy DirectAccess, the configuration for all the subsidiary technologies (Windows Firewall, NLS, NRPT, IP-HTTPS) is pushed out to the clients via GPO.

The client systems will receive changes in configuration even when not logged in by a user because the operating system periodically checks in via DirectAccess just as if it were on the local network.

Other options

I have a few niggles about DirectAccess, starting with overhead. It seems silly to utilise IPv6 inside an SSL tunnel running across an IPv4 network, then getting network addresses translated simply to access IPv4 resources on the corporate network.

The other option is little better: the Teredo network can be excruciatingly slow. Teredo relays are generally saturated because the bandwidth they can provide any given client is jittery and unreliable. You can set up your own Teredo server/relay if you want, but why bother, given that it doesn't offer you much over the IP-HTTPS approach?

If your network does not contain IPv6 servers (and many don't) then DirectAccess is of questionable value. The client is built directly into the operating system, but a traditional SSL VPN such as Microsoft SSTP or OpenVPN would give you great connectivity with a lot less hassle and fewer moving parts to worry about.

The advantage of DirectAccess is that as an IPv6 technology it was designed to be always on. There is no connecting as with a traditional VPN: it is simply there, the same as if your computer were plugged in to the corporate LAN.

Global domination

Setting up DirectAccess to allow Windows 8 to connect to Server 2012 takes just three mouse clicks. If you want to get Windows 7 to play there is more to it.

This is a shame, as few big organisations are in a rush to deploy Windows 8. That is not how enterprise lifecycles work.

Windows 7 is not legacy insomuch as it is the new XP. A large chunk of the world will be using and supporting this until at least 2020.

DirectAccess represents a massive ease-of-use improvement in corporate IPv6 security, but it won’t gain any traction if it is a pain to set up and maintain.

DirectAccess is not just good technology, it is great technology. Microsoft should port the Windows 8 DirectAccess client to Windows 7 as a goodwill gesture to further the security of the future internet.

If you can deploy DirectAccess – all your mobile clients are Windows 7 or Windows 8 Enterprise – then you should. It provides remote users with unprecedented ease of use and sets you on a path towards a future where IPv6 access for your organisation is done securely.

When looking to set up connectivity to your corporate network bear in mind what DirectAccess really is: an access control connection broker for IPv6 connectivity and not a VPN. This new IPv6 way of thinking about access is the inevitable future.

For more traditional connectivity requirements, turn to the other features within the Remote Access role. They provide a combination of technologies allowing a secure transition from the old to the new, from our familiar IPv4 world to the wild and whacky directly accessible world of IPv6. ®