Can DirectAccess take over the world?
Significant Server 2012 overhaul, but some niggles to iron out
Review Microsoft believes that DirectAccess is such a critical feature of Windows that we will soon wonder how we lived without this fundamental part of network infrastructure.
Having played with it I think Microsoft is very close to being right, but there are some bugs to work out and misconceptions to dispel.
Internet Protocol version 6 (IPv6) promises rainbows and kittens because every device with an IPv6 address can communicate directly with any other. That is a happy world for application developers.
Many who preach the gospel of end-to-end connectivity have assured me that the world will collapse unless we drastically lower the knowledge required to develop an internet-connected application.
But network and systems administrators are somewhat less keen on having their network attack surface transformed from a single externally addressable system into every system plugged into the network.
For reasons of "you do not pay me enough for this", administrators prefer defending one device instead of thousands.
Sadly, application developers won the war: instead of a shared security requirement, the burden of securing the future rests on network administrators. And that is why DirectAccess was created.
In its original incarnation DirectAccess mediated communication between a client's public IPv6 and a company's IPv6-enabled server fleet. DirectAccess verified that the computer attempting access was domain-joined, patched, authorised for access and so forth. It provided a single point of defence, even in an IPv6 world.
In a future where the right of anyone with a computer to directly address every device on your network (from your internet-connected light bulb to a hospital's medical equipment) is enshrined in nerd law, DirectAccess gives Microsoft-using administrators a fighting chance.
If you can master DirectAccess, then you can take advantage of the benefits end-to-end connectivity can offer while mitigating the risks.
Most of the confusion surrounding DirectAccess stems from the fact that it is no more a single technology than Microsoft Exchange is. What we think of as Exchange is a large collection of highly interdependent applications. These in turn are dependent upon applications that we usually think of as entirely separate, such as Internet Information Services (IIS) and certificate management.
DirectAccess is no different. The second misconception we need to deal with is that, despite layers of confusing marketing, DirectAccess access is not a virtual private network (VPN). VPN-like technologies are almost always involved in a DirectAccess configuration, but they are to DirectAccess as IIS is to Exchange (or DNS to Active Directory).
DirectAccess is a first attempt at making an IPv6 firewall that mere mortals can (supposedly) comprehend. In essence, the core executable is a connection broker. You connect to it, it verifies you are who you say you are and then lets you access company resources.
Indeed, DirectAccess will not work if you disable Windows Firewall. If you think of DirectAccess as an extension of Windows Firewall (rather than a VPN technology) the rest of this overview will make a lot more sense.
In the real world, almost no one has IPv6 for all internal servers, for all the servers hosted by their ISP and for all possible locations that you might want to have a client connect to your network. It will be decades before this becomes a reality.
This means that any practical DirectAccess deployment relies upon some other technologies. At a minimum it uses Isatap to ensure IPv6 connectivity between all intranet sites and connected clients.
The Network Location Server (NLS), the Name Resolution Policy Table (NRPT) and Active Directory via its Group Policy Object (GPO) feature are also requirements.
DirectAccess also uses the NAT64 and DNS64 protocol translators to ensure that clients can access IPv4 systems on your network. The Server 2008 R2 version did not include these elements as part of the core offering; Server 2012 does.
In addition to being made up of several sub technologies, DirectAccess has been merged into the larger Remote Access role within Server 2012. It is no longer seen as a novel technology and has become merely one more sub-component of RemoteAccess.
Here it sits alongside traditional VPN, dial-up access, IP routing and site-to-site connectivity as part of Windows's ever-expanding bit-flinging capabilities.
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.
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.
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.
DirectAccess server requirements
The DirectAccess server must have a globally addressable IPv6 address. It doesn't really matter where it gets it from, so long as it can talk to the internet using that IP. The DirectAccess server must be domain joined. It cannot be a domain controller.
The DirectAccess server must have Windows Firewall enabled and needs to be able to use Intra-Site Automatic Tunnel Addressing Protocol to ensure cross-site connectivity. You must create a Network Location Server, NAT64 and DNS 64 or allow the DirectAccess 2012 wizard to do so for you. IP-HTTPS is required for almost all real-world scenarios; you can set that up yourself or let the wizard do it for you.
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. ®
DirectAccess client requirements
Clients must be Windows 7 (Enterprise or Ultimate) or Windows 8 (Enterprise only). Windows 7 clients are considered legacy clients and there are some additional steps required to get them to work. Linux, Unix and OSX are supported via third-party software.
Clients must have a globally addressable IPv6 address. They can obtain this through the standard transition mechanisms or by using IP-HTTPS to obtain one from the DirectAccess server. The clients must be domain joined.