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.