Better security, simpler deployment, and easier management
DirectAccess is a breakthrough technology first released in Windows Server 2008 R2 and Windows 7 that gives remote users seamless access to the corporate network from anywhere on the Internet, without the need to manually connect to the corporate network. IPv6 and IPsec let organizations extend their network to any point in the world where Internet connectivity is available, thus improving users’ productivity and experience.
Microsoft has released several improvements to DirectAccess since the technology’s original release. DirectAccess server support was added to Microsoft Forefront Unified Access Gateway (UAG), with features that simplify deployment, such as IPv6-to-IPv4 translation (NAT64/DNS64) and support for scaling and high availability using server arrays. On the client side, a free DirectAccess Connectivity Assistant (DCA) tool was released that provides end-user notifications and client troubleshooting.
Microsoft has now released Forefront UAG SP1. In addition to fixing several bugs, Forefront UAG SP1 incorporates several improvements in DirectAccess support. These changes include “always managed” functionality, native support for Force Tunneling, one-time password (OTP) authentication, enhanced monitoring and logging capabilities, and easier deployment. With these improvements, DirectAccess is an even more appealing technology for enterprises than ever before.
Although much of the hype around DirectAccess has centered around users’ transparent access to internal network resources, for many IT departments the most appealing aspect of DirectAccess is the ability to extend desktop management functions beyond corporate network boundaries. DirectAccess provides this functionality by using two different IPsec tunnels when connecting to the Forefront UAG DirectAccess server. The first tunnel, called the infrastructure tunnel, connects the machine to the domain controllers (DCs) and management servers. The infrastructure tunnel uses only machine credentials for authentication and remains connected as long as the machine has Internet connectivity. The second tunnel, called the intranet tunnel, uses both machine and user credentials to connect the user to the other servers on the internal network and is active only when the user logs on and tries to reach one of those servers.
Because the infrastructure tunnel is always connected, standard Windows features such as Group Policy settings and password changes, as well as management software such as antivirus, software distribution, and monitoring and compliance tools, can now transparently work from anywhere on the Internet. For example, an organization can push a new antivirus update or a critical patch down to all its computers and receive a report of the success of the operation without waiting for users to eventually connect their machines back to the corporate network, or without setting up an additional remote management infrastructure in a demilitarized zone (DMZ) network.
Forefront UAG SP1 introduces support for an organization to deploy DirectAccess for remote management only, without actually providing end users access to the internal network. Machines can use DirectAccess to access Active Directory (AD) and desktop management services, while end users continue to use their existing remote access technologies—such as VPNs or web publishing portals—to connect to internal resources.
In this “always managed” mode, which Figure 1 shows, clients are configured only with the IPsec infrastructure tunnel, with no intranet tunnel. This approach greatly simplifies DirectAccess deployment, because the scope of the deployment is narrowed to only the servers that will be exposed to external clients. DirectAccess becomes a powerful tool for IT departments to extend their management capabilities, such as transparently using Microsoft System Center Configuration Manager (SCCM) and AD Group Policy Objects (GPOs) with clients anywhere on the Internet, without immediately replacing the existing remote access technologies that end users already have in place to connect to the corporate network.
The infrastructure tunnel is established only with the IP addresses specified in the DirectAccess policy, allowing an organization to determine exactly which servers DirectAccess clients can reach. Forefront UAG SP1 can automatically discover AD DCs, as well as Network Access Protection (NAP) and SCCM servers, as Figure 2 shows. In addition, Forefront UAG SP1 provides an optional safeguard to allow only service accounts to connect through the tunnel, blocking non-administrative users from connecting to these servers.
Because only management traffic goes through DirectAccess in this mode, a Forefront UAG SP1 server will likely support a lot more concurrent machines than a default DirectAccess deployment with end user connectivity. In a test conducted by the Forefront UAG product group, a Forefront UAG server that supported 2,300 concurrent users in the default DirectAccess configuration was able to handle 4,000 concurrent users with DirectAccess in “always managed” mode. With easier deployment, better scalability, and no end-user impact, this approach can be the best way for many organizations to take advantage of DirectAccess’s benefits.
On the opposite end of the spectrum, some organizations require that every communication from end users is routed through the corporate network, then back to the Internet if necessary. To address this requirement, Forefront UAG SP1 adds native support for the Force Tunneling option, which previously had to be configured separately through a Group Policy setting.
Split tunneling is enabled by default in DirectAccess. For those not familiar with the term, this means that the client sends traffic through its DirectAccess tunnels only to destinations in the internal network. Traffic to the Internet is delivered directly, without passing through the DirectAccess server. The same approach is used for DNS queries: Names in the internal DNS namespaces are sent for resolution by internal DNS servers, whereas names from other namespaces are resolved by the DNS server provided by the local network. Split tunneling typically provides the best user experience because it tends to use the most direct route to reach the destination, while reducing network and CPU consumption on the DirectAccess server.
However, many organizations are wary of using split tunneling because of security reasons. Some companies have policy or regulation requirements to inspect all traffic from the client, whereas others are worried that clients connecting from open wireless networks (such as those found in hotels, coffee shops, and airport lounges) could be targets for attack. In such networks, an attacker could steal authentication cookies from HTTP connections and impersonate the user, or manipulate name resolution to perform man-in-the-middle attacks. Not using split tunneling ensures that all communication from the client is sent in a secure channel to the internal network, blocking those attacks and making sure the client is adhering to the organization’s policies when browsing the Internet.
Forefront UAG SP1 lets you change the DirectAccess behavior from split tunneling to force tunneling, as Figure 3 shows. When force tunneling mode is enabled, all client communication is sent through the DirectAccess server, with the exception of local subnet traffic. All names are resolved by the internal DNS servers regardless of the namespace.
Force tunneling comes with a price. When force tunneling is enabled, all traffic from the client is transported to the DirectAccess server over HTTPS using the IP-HTTPS interface, introducing another layer of encryption in addition to IPsec. The double encryption increases CPU consumption on the DirectAccess server, which also must cope with the additional traffic from the client to the Internet. A Forefront UAG DirectAccess server supports significantly fewer concurrent users in force tunneling mode than in split tunneling mode.
The biggest impact, though, might be in terms of application compatibility. With force tunneling, all traffic from the DirectAccess client can use only the IPv6 protocol, because the traffic must go through the DirectAccess tunnels that are IPv6 only. (IPv6 isn’t required on the server side, because Forefront UAG can translate the client traffic to IPv4 using NAT64.) Client applications that don’t support IPv6, such as Microsoft Communicator, won’t be able to communicate even to IPv4 hosts on the Internet and can’t be used on DirectAccess clients with force tunneling.
Although Microsoft supports the use of DirectAccess with force tunneling, this mode should be used only when absolutely necessary. In addition, organizations should carefully evaluate and test this option before enabling it in a production environment.
For many organizations, two-factor authentication is a must-have for any remote access service. In its first release, DirectAccess offered two-factor user authentication using smart cards; Forefront UAG SP1 introduces support for authentication using OTP tokens, such as RSA SecurID. OTP authentication is used to authenticate the IPsec intranet tunnel; only users in possession of the token can connect to servers on the internal network.
One of the challenges Microsoft faced to incorporate support for OTPs in DirectAccess was the fact that Windows’s IPsec implementation can’t use OTP credentials. Forefront UAG SP1 goes around this limitation by using OTP authentication to issue users a short-lived certificate, which is then used to authenticate the IPsec intranet tunnel. Figure 4 shows how the authentication process works.
A key piece of the underlying infrastructure is the CA that issues the short-lived certificates. This CA needs to run on a Server 2008 R2 server, and it can’t be the same CA that issues the machine IPsec certificates, nor can it be one of that CA’s parents. To simplify deployment, Forefront UAG SP1 includes a PowerShell script that configures the appropriate certificate templates and permissions on the CA server.
The OTP authentication support lets organizations preserve the investments they’ve made in deploying OTP tokens for VPN or remote web access. In addition, OTP authentication eliminates one of the most common deterrents to DirectAccess deployment.
Another area of improvement is monitoring. Forefront UAG SP1 introduces integrated monitoring of DirectAccess connections in the Forefront UAG Web Monitor tool. The DirectAccess monitor provides a list of currently logged on users, including machine and user account, IPv6 source address, level of access (infrastructure or intranet), and health status if NAP is being used.
This information, which Figure 5 shows, is persisted in the local SQL Server database. You can use the Forefront Threat Management Gateway (TMG) management tool, which is also included in the Forefront UAG SP1 installation, to view the historical data. You can also configure logging to a remote SQL Server machine, which is great for consolidating logs from servers in an array.
Speaking of arrays, the Web Monitor tool now includes a consolidated status view of all the DirectAccess servers in an array, indicating the health condition for each array member, as Figure 6 shows. The Web Monitor tool can be used remotely from any browser, providing operators an easy way to quickly check the status of the DirectAccess infrastructure.
Forefront UAG SP1 incorporates several improvements to ease DirectAccess deployment. The UAG DirectAccess Configuration Wizard can now configure DirectAccess settings across multiple domains, as well as use existing GPOs for client, gateway, and application server configuration instead of creating new ones. The flexibility also exists to link these GPOs to organizational units (OUs) instead of using groups and to customize the names of the GPOs directly from the wizard.
NAP configuration is also integrated into the UAG DirectAccess Configuration Wizard. If NAP is selected, Forefront UAG SP1 sets up Health Registration Authority (HRA) and Network Policy Server (NPS) on the UAG server and configures the network policies for reporting and enforcing system health requirements on the DirectAccess clients. The NAP components report into the Forefront UAG monitoring and logging infrastructure, so administrators can see the latest information in the Web Monitor tool and query the SQL Server database for historical data about client health status.
On the client side, the DCA tool configuration is now part of the UAG DirectAccess Configuration Wizard, and its settings are incorporated into the client configuration GPO. Deploying the tool still isn’t part of the wizard, but because the tool installation package consists of a single Windows Installer (MSI) file, organizations could even use the same GPO to install it.
Overall, Forefront UAG SP1 is a huge step forward in making DirectAccess more secure, simpler to deploy, and easier to operate. With the increasing mobility of the workforce and the trend toward deperimeterization reaching many enterprises, no Windows 7 deployment is complete without a remote access and management technology—and DirectAccess is now an even stronger contender for this role.