A Complete Guide to UAG DirectAccess (Part 1)

by [Published on 14 July 2011 / Last Updated on 14 July 2011]

In this article I will provide a broad overview of what DirectAccess does and how it can provide value both to you as an administrator and to your users.

If you would like to read the other parts in this article series please go to:

Introduction

DirectAccess is a new remote access technology enabled by Windows 7 and Window

s Server 2008 R2 that allows users to be connected to the corporate network at all times. From a user’s point of view, the computer experience is the same regardless of location. Users can move from the corpnet to an Internet café, to a hotel room, to a conference center and even to an airplane that offers wi-fi connectivity. As long as these users are connected to the Internet, they will be able to reach resources on the corpnet as if they were directly connected to it via an Ethernet connection or 802.11 wireless link.

The always-on aspect of DirectAccess at first might seem like the most compelling component of the solution. Users never need to fire up a VPN connection; they don’t need to remember the URL for an SSL VPN gateway (even if that SSL VPN gateway is a UAG server). They don’t really need to do anything – they just click links in their email or on their desktop or type in the server names they always use, and then they just connect. It would be hard to argue against the idea that this seamless connectivity should lead to increased productivity.

However, DirectAccess has even more to offer than transparent connectivity for your users. The benefits go both ways. Because the DirectAccess connection is a bidirectional link, you – the network administrator – will always have the ability to connect to the DirectAccess clients over the Internet. Whenever a DirectAccess client computer is turned on, you can connect and manage the DirectAccess clients. Your users don’t even need to log on in order for you to connect to DirectAccess clients from within your corpnet. This means that the management infrastructure that you use now to control and configure hosts on the corpnet will always be available for managingcomputers that are connected via DirectAccess.

In fact, from my work with number of enterprise administrators so far, it appears that this ability to “manage out” (manage DirectAccess clients) is even more compelling than the transparent connectivity users have to resources on the corpnet. These enterprise administrators consider the always-on connectivity to the corpnet interesting, but they really get excited by the idea that they will always be able to manage the DirectAccess clients. This appears to be a real problem for many enterprises; employees are given corporate laptops and then users don’t return to the corpnet for weeks, months, years and sometimes never again. They might occasionally connect over a VPN connection. But the result is always that these machines slowly but surely fall out of compliance with company update policies and become increasingly vulnerable to malware and other types of compromise. Even system stability issues slip in after a while, which ends up decreasing employee productivity and costing your organization money in terms of help desk calls and other administrative overhead. If DirectAccess can prevent all that, it truly is a miracle worker.

How DirectAccess Works

DirectAccess brings to the table a number of technologies that are part of the Windows 7 and Windows Server 2008 R2 platforms. Some of these technologies are new, and some of them you have been using for a long time. However, whether you’re working with old or new technologies, none of them need to be prohibitively complex. It’s important to keep this in mind, because you might have read in other places that DirectAccess isn’t worth the effort because of the level of complexity involved.

This perception might be due to the fact that before UAG 2010 was released, the only way you could deploy DirectAccess was by using the built-in Windows DirectAccess solution. While the Windows DirectAccess solution does work, it has many limitations compared to the UAG DirectAccess solution:

  • Windows DirectAccess has limited support for high availability, and the mechanism that’s recommended involves using Hyper-V and Windows failover clustering to provide a cold stand-by. There is no support for Network Load Balancing.
  • Window DirectAccess does not support DirectAccess arrays. If you want to set up multiple Windows DirectAccess servers, you need to configure and manage them individually. In contrast, UAG DirectAccess servers can be configured in arrays of up to 8.
  • Windows DirectAccess servers do not support IPv4 only servers. DirectAccess clients on the Internet will not be able to connect to IPv4 only servers. That means that if you want to use the Windows DirectAccess solution, you have to upgrade your servers to Windows Server 2008 or above. In contrast, the UAG DirectAccess solution fully supports IPv4 only servers on the corpnet.

If you plan to deploy DirectAccess on your enterprise network, the best way to do it is to use the UAG DirectAccess solution.

DirectAccess Client Connectivity

IPv6 is the core of the DirectAccess solution, which is one of the reasons many administrators feel as if they can’t deploy it at this time. IPv6 has the potential to be complex, and with your IT group and budget shrinking, you might not have the time to devote to learning an entirely new networking protocol. The good news is that, with UAG, you don’t have to become an IPv6 genius to make DirectAccess work for you and your company, because the UAG DirectAccess solution automatically deploys the IPv6 infrastructure you need to get started.

When the DirectAccess client is on the Internet, it will try to establish two IPsec tunnels to the UAG DirectAccess server. These tunnels use IPsec tunnel mode and the Encapsulating Security Payload (ESP) protocol with AES 192bit encryption for privacy over the Internet.

The two types of tunnels are:

  • Infrastructure tunnel: The infrastructure tunnel starts up when the computer starts but before the user logs on. The DirectAccess computer is always a domain member and the computer account is used to log on via a computer certificate and NTLMv2 authentication. In addition, the computer must belong to a security group dedicated to DirectAccess client computers. This tunnel is bidirectional and management agents on the client can call in to management servers on the corpnet. Your IT management servers can initiate connections to the DirectAccess clients while the infrastructure tunnel is up. The DirectAccess clients can connect through the infrastructure tunnel only to servers that you specify. This tunnel does not allow open access to the entire corpnet.
  • Intranet tunnel: The intranet tunnel is established after the user logs on. This tunnel is also encrypted using ESP and AES 192. Tunnel authentication is performed using a computer certificate (similar to that used by the infrastructure tunnel) and Kerberos authentication for the user account. The intranet tunnel allows the user to access any resource on the corpnet for which that user is authorized.

There are two access models that you can use when enabling DirectAccess clients to connect to the corpnet. You always have to enable end to edge, but the end to end deployment model is optional. Let’s take a closer look at both models:

  • End to Edge: When you use the “end to edge” connection model, the DirectAccess clients establish an authenticated IPsec tunnel mode link to the UAG DirectAccess server. After terminating the IPsec connection at the DirectAccess server, the traffic moving from the DirectAccess server to servers on the corpnet is in the clear and is neither authenticated nor encrypted at the network level.
  • End to End: The“end to end” network security model enables you to secure connections with IPsec from end to end. The connection between the DirectAccess client and server is encrypted and authenticated using IPsec tunnel mode. After the traffic leaves the DirectAccess server to travel to a server on the corpnet, that connection is passed over the corpnet using IPsec transport mode. However, the default setting is for authentication to the endpoint only; the transport mode connection is not encrypted so that network IDS and other security gear can evaluate the connections over the network. This also reduces some of the processing overhead involved with IPsec connectivity.

In addition to the computer certificate, computer account (NTLMv2) and user account authentication used in creating the DirectAccess tunnels, you also have the option to force users to use Smart Card authentication to establish the intranet tunnel, thus further enhancing the overall security of the solution. And if smart card authentication is not secure enough for your purposes, you can enforce endpoint detection and enforcement on the DirectAccess client using NAP, so that non-compliant computers will be quarantined and remediated before allowing establishment of the infrastructure and intranet tunnels.

It is important to note that End to Edge connectivity supports all networks, so that you don’t have to have any IPv6-ready hosts on the corpnet to support End to Edge scenarios. However, if you want to deploy end to end security with IPsec tunnel and transport mode, this requires you to have Windows Server 2008 or above servers behind the DirectAccess server. In addition, you can mix End to Edge and End to End connectivity models; they are not mutually exclusive.

All traffic moving between the DirectAccess client and server is IPv6 traffic. That will always be the case. The implication of this is that while your servers behind the UAG DirectAccess don’t have to be IPv6 aware, the client application must always be IPv6 aware. For this reason,you must make sure you qualify your client applications to verify that they’re IPv6 compatible before you fully roll out your DirectAccess deployment.

Note:
You might have noticed that terms such as “IPv6 aware” and “IPv6 capable” and “IPv6 only” and “native IPv6” have been used, but not defined. This is something that you’ll encounter with the public documentation of DirectAccess and it can be somewhat confusing to someone who’s new to the IPv6 space. When referring to “native IPv6” networks, there is the implication that all network infrastructure (routers, DNS, DHCP, etc.) as well asall clients and servers are using a full blown IPv6 deployment. In contrast, an “IPv6 aware” deployment isn’t using IPv6 from end to end, but client and server applications can take advantage of IPv6 transition technologies to work on IPv4 networks. The “IPv6 capable” network has hosts on it that support the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) so that IPv6 messages can be sent over an IPv6 network. When you install UAG as your DirectAccess server, it will configure itself as an ISATAP router so that IPv6 messages can be tunneled within an IPv4 header over your IPv4 network, so that you won’tbe required to upgrade your routers and switches and DNS and DHCP servers to work with IPv6 connectivity.

Summary

In this article, part 1 of our multi-part Complete Guide to UAG DirectAccess, I provided a broad overview of what DirectAccess does and how it can provide value both to you as an administrator and to your users. We saw how DirectAccess establishes two tunnels, an intranet and an infrastructure tunnel. In addition, we saw that there are two deployment modes: end to edge and end to end. In the next part of this series, we will go into some of the details of the IPv6 transition technologies used by UAG DirectAccess.

If you would like to read the other parts in this article series please go to:

The Author — Deb Shinder

Deb Shinder avatar

DEBRA LITTLEJOHN SHINDER, MCSE, MVP (Security) is a technology consultant, trainer and writer who has authored a number of books on computer operating systems, networking, and security.

Latest Contributions

Advertisement

Featured Links