I thought that it would be fitting for my first real blog post here on directaccess.richardhicks.com to provide a high level overview of what DirectAccess is all about. DirectAccess is an always-on remote access solution for Microsoft managed systems. DirectAccess is not a protocol; rather it is a collection of technologies used to provide network connectivity to users who are located outside of the corporate office. Some of these technologies include IPsec, IPv6, certificates, and Active Directory and group policy. On the client side, DirectAccess leverages the Windows Firewall with Advanced Security (WFAS) and the Name Resolution Policy Table (NRPT).

DirectAccess is a paradigm shift in remote access technology. Traditional (legacy?) client-based remote access is user-initiated, requiring the user to establish a Virtual Private Network (VPN) connection any time they need access to the corporate network. By contrast, DirectAccess is completely transparent to the user. The corporate network connection is established in the background automatically whenever the user has access to the Internet. Fundamentally, DirectAccess isn’t really a VPN at all. There’s nothing virtual about this network – it is the private network!

DirectAccess is a feature of the Windows Server 2008 R2 operating system. Often I’ll refer to this as native DirectAccess. However, there is a serious limitation that comes with native DirectAccess. Since DirectAccess clients communicate using only IPv6, this requires that any systems on the internal private network that the DirectAccess client communicates with be configured with IPv6. Sadly, very few organizations have IPv6 deployed today. Obviously this is a barrier to entry for many companies. To address this limitation, the Forefront Unified Access Gateway (UAG) 2010 can be deployed as a DirectAccess server. I typically refer to this as UAG DirectAccess. UAG includes protocol translators for DNS and NAT (DNS64 and NAT64) that allow the DirectAccess client to communicate with native IPv4 only networks, eliminating the requirement to deploy IPv6 on your internal network (for now).

So what are the benefits to deploying DirectAccess for remote access? Well, here are a few things to consider:

User experience – Seamless and transparent! Since DirectAccess is an always-on connection it requires no action from the user to establish remote network connectivity. When a user travels outside of the corporate office they can access data and applications from their mobile computer in exactly the same way as they do when they are in the office.

Systems management – Since corporate network connectivity with the DirectAccess client is established any time it has access to the Internet, management agents running on the DirectAccess client will be able to communicate with management servers to receive updates and report compliance. This also means that DirectAccess clients regularly receive group policy updates. In addition, the DirectAccess communication channel is bi-directional, which allows hosts on the corporate network to initiate communication outbound to DirectAccess clients whenever they are connected to the Internet. For example, if a remote user calls the help desk for assistance, the help desk engineer can initiate a remote desktop session to the DirectAccess client to assist the user.

Authentication – The DirectAccess communication channel is fully authenticated and encrypted. Initial remote connectivity is established to infrastructure services such as domain controllers, DNS servers, and systems management servers. When the user presses CTRL-ALT-DELETE to log on to their system they are authenticated against a domain controller and not using cached credentials (as long as they have Internet access prior to logging on). This means password changes can be done using CTRL-ALT-DELETE and password lockouts due to out of sync passwords are virtually a thing of the past.

As wonderful as DirectAccess is, it does have some potential drawbacks and limitations. First, DirectAccess is only for managed Windows clients running Windows 7 Ultimate or Enterprise, or Windows 8 Enterprise. The DirectAccess server and clients must be members of an Active Directory domain. DirectAccess is not supported for non-domain joined systems, non-Microsoft operating systems, or mobile devices of any type. Some applications many not work over a DirectAccess connection due to the requirement for DirectAccess clients to use IPv6. If an application has hard-coded references to IPv4 resources, or if the protocol itself has IPv4 addresses embedded in it, communication over a DirectAccess connection will fail. These scenarios will require the use of another VPN technology such as SSL VPN or traditional network-layer VPN.

Looking ahead, Windows Server 2012 will bring some very exciting changes to DirectAccess and remote access in general. I’ll be writing about those things in more detail soon. Stay tuned!