Architecting, Deploying and Operating Direct Access (Part 3)

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


In the previous articles about Direct Access, you read about Direct Access is driving IPv6 planning and adoption in enterprises large and small. We covered sizing and capacity planning for the environment based on your requirements including the number of devices that are DA-enabled, as well as the throughput requirements and encryption types that are configurable for the service.

We also touched on a valuable component to the Direct Access Equation: Forefront Unified Access Gateway 2010 (UAG). As you’re planning the deployment of Direct Access, it’s advisable to take some time to review UAG, understand what it brings to the table and whether it’s worth putting into the equation for a Direct Access deployment in your environment.

What is Unified Access Gateway?

Microsoft acquired a small company called Whale Communications in 2006. Whale offered a niche SSL/VPN product which was competing with the large network providers (Cisco, Juniper, etc.). It offered some very rich application integration for remote publishing and a flexible host inspection engine to review system settings, such as up to date anti-virus, security updates installed, etc. This technology evolved into Microsoft’s Intelligent Application Gateway 2007 (IAG) product and most recently renamed to Forefront Unified Access Gateway 2010 (UAG) release. UAG installs on a Windows Server 2008 R2 system, is 64-bit and can either run on standard server hardware or be purchased as an appliance via OEM from a Microsoft partner. UAG is designed to do a few things very well, as seen in Figure 1 and listed below:

  • Publish applications remotely. UAG can easily be used to publish Exchange remote access (e.g.: Outlook Web Access) and SharePoint remotely as well. UAG has built in application-level filtering capabilities. This very granular filtering capability could even stop a user from uploading content via SharePoint when they are outside of the network, but permit it when they are coming from inside or from a more trusted machine, for example.
  • Provide a ‘remote access portal’ for a user to select and launch apps. You’re able to provide the list of available apps based on who the user is as well as what the health status of their machine is. Full IP connectivity via an SSL tunnel is configurable as well.
  • Making Direct Access available via the Internet. UAG can act as a reverse proxy to accept Direct Access connections via the Internet and route them into the internal corporate network. UAG is also able to do IPv6 <-> IPv4 translation, providing Direct Access connectivity to ‘legacy’ devices internally that may not be IPv6 addressable.
Figure 1: High level architectural overview of UAG capabilities. (Source:

UAG is a great way to simplify the architecture for your Direct Access environment; by consolidating all external connections to a few UAG servers, you’re able to have a single choke point in and out of the environment to monitor client connections. UAG may not replace the traditional SSL/VPN that you have in place for your users today, but let’s focus on the Direct Access publishing capabilities for the purposes of this article.

One final note on the attractiveness of UAG, especially in enterprise deployments, UAG is licensed per server (see above) and with Client Access Licenses (CALs) like most Microsoft products. The UAG CALs are included in the Microsoft Enterprise CAL Suite, which your organization may already own. This could help sizably reduce the cost of your Direct Access implementation or even help reduce some cost as you look to consolidate remote access solutions. This advantage alone is pushing many IT Pros to evaluate how UAG may be a fit in their environment.

UAG and Direct Access

In a nutshell, UAG makes Direct Access more flexible and provides additional application capability by simplifying some of the translation issues that can occur moving from IPv6 <-> IPv4 inside and outside of the corporate network. A great example of where UAG was able to provide ‘it just works’ functionality are ‘peer to peer’ type applications like Microsoft Lync or Remote Desktop. It also allows for the isolation of Direct Access ingress and egress to one ‘exposure’ point. From a security perspective, your organization may be more comfortable with a UAG device on the network edge versus a generic Windows Server 2008 R2. UAG is built on top of Microsoft’s Threat Management Gateway (TMG) technology, formerly ISA Server. At some point, the Direct Access architecture needs to be ‘dual homed’ with connectivity to both the external network and the corporate network; what better place than at the UAG device? UAG also provides for easy configuration of two-factor authentication integrated into the Direct Access environment. Smart card authentication is supported as is RSA SecurID. The configuration wizards and tools that are available for UAG seemed a lot easier to configure than some of the out of box configuration options for the same functionality in Windows Server, which can be seen in Figure 2. The UAG and Direct Access functionality can be seen in Figure 3.
Figure 2: Direct Access configuration wizard screen shot. (Source:
Figure 3: UAG and Direct Access functional data flow graph. (Source:

Offloading the authentication and encryption requirements of the Direct Access infrastructure onto the UAG devices is also an attractive proposition. Rather than having to scale the individual DA servers, a robust set of UAG devices can support encryption/decryption of the DA tunnels and perform authentication and authorization of the endpoints. One of the most compelling reason in deploying UAG + Direct Access was the extended access to IPv4-only resources. With so many backend applications hosted on older platforms with no compelling reason to upgrade them, easily extending Direct Access without justifying infrastructure upgrades is a huge advantage.

Deploying Unified Access Gateway: Highlighted Options

Once the UAG infrastructure (Windows Server 2008 R2 Servers with two physical network adapters each) is built and the software is installed, configuration options can quickly be set up on the UAG devices. Design decisions to be made include whether or not to force all traffic through the DA tunnel or just internally-routed corpnet traffic, two-factor authentication options, whether or not to enable Network Access Protection to enforce configuration and client health over the Direct Access tunnel and several others. If you’d like to use the IPv4 connectivity option for servers inside your environment, pay close attention to the IP64 and DNS64 configuration options (Direct Access Server Wizard -> Manage Direct Access Services -> Identifying DNS Servers).

Configuring IPv6 prefix addresses and authentication options should also be reviewed in detail prior to putting UAG in front of your Direct Access deployment. Configurable options for UAG include a root and intermediate certificates in the CA chain, IP-HTTPS certificates, health certificates for Network Access Protection, smart cards, and IPsec cryptography settings.


In short, it seems like UAG is a great deployment option for Direct Access deployments both large and small. The ease of configuration and the ‘wizard’ driven functionality allowed this reviewer to quickly accomplish the same tasks for Direct Access setup in a much easier way. If your organization already owns the UAG Client Access Licenses in your Microsoft agreement, consider UAG as a ‘must have’ for your deployment. As always, integrating it into the plan as early as possible will make the deployment more seamless and avoid interruption of DA tunnel service.

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

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top