Virtual private networks (VPNs) have provided secure remote access to corporate network resources for more than a decade. Administrators have griped about time-consuming tasks, from client installs to policy configuration, and vendors have responded by offering everything from browser clients to role-based access controls. More recently, when wireless users grumbled about roaming disruption, vendors responded with persistently connected mobile VPNs.
Now, Microsoft claims to have a better answer: DirectAccess. With this Windows 7 feature, users can obtain secure remote end-to-edge and end-to-end access, tunneled through a Windows Server 2008 R2 DirectAccess Server. But is DirectAccess really a novel alternative? And more importantly: What are the advantages and limitations of DirectAccess for midmarket businesses?
WHAT DIRECTACCESS IS
DirectAccess uses auto-initiated, authenticated, encrypted IPv6/IPsec ESP tunnels to connect remote Windows 7 users to private network (intranet) resources. As in most IPsec VPNs, tunnels can connect the Windows 7 host (DirectAccess Client) to a gateway at the edge of the private network (DirectAccess Server). Alternatively, DirectAccess Clients can use IPsec transport mode, tunneled through a DirectAccess Server, for a secure end-to-end session with any IPv6 Windows Server 2008-based intranet server.
For starters, each DirectAccess client tries to reach a designated server on the corporate intranet. If reachable, the user must be locally connected to the intranet and DirectAccess is not used. Otherwise, the user must be remote, so DirectAccess tries to establish a bidirectional secure tunnel to the intranet over any available network connection.
- First, the DirectAccess client and server authenticate each other by machine certificate. The server consults the Intranet's ActiveDirectory to validate the client PC's group memberships (and the intranet's Health Registration Authority if a PC health check is required by NAP.) If all goes well, the result is an IPsec ESP tunnel, maintained continuously whenever the client can reach the server.
- At this point, the client can use that secure tunnel to reach the intranet's DNS server and Windows Domain Controller. A Name Resolution Policy Table determines whether hostnames referenced by remote applications should be resolved by an intranet or Internet DNS server. All remote traffic destined for Internet servers is sent directly, in the clear.
- When any remote application tries to send traffic to an intranet server, the DirectAccess Client automatically establishes a second IPsec ESP session. Depending on configured policy, this may involve end-to-edge tunnel mode IPsec or end-to-end transport mode IPsec. For both, authentication is based on machine certificate and user credentials (e.g., domain password, smart card). If all goes well, the user can now communicate securely with permitted intranet resource(s), just as if he or she were locally connected.
Note that DirectAccess depends on IPv6. DirectAccess clients always try to establish IPsec tunnels over native IPv6. If that fails (as it will in most home and public networks), the client tries encapsulating IPv6 inside IPv4 packets, using a transition technique like 6to4 or Teredo. If that fails (as it will behind many firewalls and proxies), the client falls back to stuffing IPv6 inside HTTPS packets, using Microsoft's IP-HTTPS protocol. Because most networks, firewalls and proxies permit outbound HTTP over SSL, this usually works. However, in all cases, the intranet must support IPv6, including an IPv6 DNS namespace and IP address prefix for all intranet resources and a public-routable IPv6 IP address assigned to the DirectAccess client.
WHAT DIRECTACCESS IS NOT
DirectAccess uses VPN protocols, including IPsec ESP and MOBIKE. When used for end-to-edge protection, DirectAccess delivers secure tunnels that are similar to those offered by any vanilla IPsec VPN.
Where DirectAccess differs is the degree to which tunnel management has been automated and integrated with other Microsoft infrastructures. Many other vendor VPNs provide fully automated tunnel establishment -- even application persistence to hide brief connectivity losses. However, Microsoft's VPN gateway -- Routing and Remote Access (RRAS) in Windows Server 2008 -- does not. RRAS users are typically required to launch their VPN connection and log in (via L2TP/IPsec or PPTP). If the underlying wireless or wired connection breaks, the VPN tunnel must be re-established. DirectAccess avoids this end-user involvement and inconvenience.
Another key difference is routing. Many other vendor VPNs -- especially SSL VPNs -- differentiate between intranet and Internet destinations and route traffic on remote clients. However, layer-two tunneling protocols (e.g., L2TP and PPTP) simply route all outbound traffic over a (non-split) tunnel to the VPN gateway, which must then forward traffic on to Internet or intranet destinations. By default, DirectAccess exploits IPv6 namespaces to operate more efficiently, without messy IPsec selectors or SSL URL maps. However, a DirectAccess Client can still tunnel non-intranet traffic if desired, based on Windows Firewall group policy.
Finally, although DirectAccess supports end-to-edge protection, Microsoft recommends end-to-end protection where possible (that is, when the destination is an IPv6 Windows Server 2008. As networks migrate to IPv6, DirectAccess can support the kind of security architecture needed as the lines between local and remote evaporate.
WHERE AND HOW TO USE DIRECTACCESS
At first glance, DirectAccess might seem to be for large enterprises. However, many midmarket businesses which try to make the most of purchased hardware and software use Windows RRAS as their VPN platform. Those shops may well look at DirectAccess as an RRAS upgrade.
Furthermore, midmarket businesses that buy VPN concentrators have been slower to invest in more sophisticated SSL and Mobile VPNs. DirectAccess promises some of the benefits afforded by those third-party VPNs (e.g., always-on tunnels, firewall/proxy traversal), without hardware purchase or client installation.
But DirectAccess is no slam dunk. The DirectAccess client is embedded in Windows 7 Enterprise/Ultimate Editions and Windows Server 2008 R2 -- but cannot currently be used to deliver access to any other kind of remote device. (Other VPN solutions, including RRAS, can still be used in tandem.)
Second, a DirectAccess server must be installed on a Windows Server 2008 R2 PC with at least two NICs. The Internet-facing adapter must be publicly routable through two IPv4 addresses (i.e., on a DMZ). Businesses worried about availability or scalability can install multiple DirectAccess servers.
Next, your intranet must be (at least to some degree) IPv6-capable. This includes an IPv6-connected domain controller and DNS server running Windows Server 2008 (SP2 or R2). IPv6-connected application servers that run any version of Windows Server 2008 can be reached in end-to-end or end-to-edge mode. All other intranet application servers (including IPv4 servers reached via NAT-PT) are limited to end-to-edge access only.
Finally, DirectAccess is clearly slated for intranets that rely on Windows infrastructure. For example, DirectAccess cannot be used to connect remote devices that have not been enrolled in ActiveDirectory and issued machine certificates. Businesses that have adopted Windows authentication infrastructure will find DirectAccess more readily accessible. In fact, DirectAccess can help remote users tap other new Windows network features, including NAP, Windows 7 Federated Search and Windows 7 Folder Redirection.
Lisa Phifer is vice president of Core Competence Inc. She has been involved in the design, implementation and evaluation of networking, security and management products for more than 25 years, and has advised companies large and small regarding security needs, product assessment, and the use of emerging technologies and best practices.
Send comments on this technical tip editor@searchmidmarketsecurity.com.
Join our IT Knowledge Exchange discussion forum; please use the midmarket security tag.
