Deploying DirectAccess in Windows Server 2012

In Windows Server 2008 R2, installing and configuring DirectAccess is painful. It requires a very complicated setup process that involves meeting public key infrastructure (PKI) requirements, getting server certificates, setting up a network location server, making sure the targets support IPv6, and using the Forefront Unified Access Gateway (UAG). That has all changed. In Windows Server 2012, installing and configuring DirectAccess is simple if you're using Windows 8 clients. Before I describe the vastly improved setup process, I'll take a step back and tell you what DirectAccess is and how it can help your organization.

What Is DirectAccess?

In my first job as a VAX/VMS systems administrator, I got to the office at 8:00 a.m. and left at 5:00 p.m. Those were the hours I interacted with the work systems (including email), and I never accessed the systems outside the office. Today, the concept of 8-to-5 office hours has disappeared, and the line between work and personal life has blurred. IT administrators and end users alike need to be able to access company systems and data all the time, so they always need connectivity.

Related Articles:
"DirectAccess Improvements in Forefront Unified Access Gateway SP1"
"Q. What technologies does DirectAccess use?"
"Q. Is it true that DirectAccess only works with IPv6?"
"Q: If I'm implementing DirectAccess in my organization, can I drop my VPN solution?"

There are two traditional approaches for managing access to corporate systems from outside the corporate network:

Using HTTPS is a great solution when it's available. It has the advantage of typically "just working" and is available on many different types of devices. However, the HTTPS approach doesn't work for many types of services, such as line of business (LOB) applications. And sometimes organizations don't want to use it, even if it's a viable option. For these situations, the traditional VPN approach can be used. But this approach also has challenges:

To provide another option, Microsoft introduced DirectAccess in Server 2008 R2 and Windows 7 (Enterprise and Ultimate editions). DirectAccess enables an always-on connection from the client to the corporate network, without any user action. When users are accessing an Internet resource, their regular Internet connection is used. When users are accessing a corporate resource, the DirectAccess tunnel is used, giving them transparent corporate resource access from anywhere. To determine whether the target is a corporate resource, DirectAccess compares the target's DNS suffix against a Name Resolution Policy Table. This table basically contains rules that identify the DNS suffixes that must communicate through the corporate intranet to be reachable.

Although DirectAccess looks similar to a VPN in terms of creating a tunnel between the computer and the corporate environment, there's an important difference. Behind the scenes, there are actually two tunnels used with DirectAccess. The first tunnel is the infrastructure tunnel, which is established when the machine is turned on. It allows key IT infrastructure systems to talk to the machine and perform management. After a user logs on, a second tunnel is created. This intranet tunnel allows the user to access the systems on the corporate network. Because there's no user action required, the user can access corporate resources seamlessly. Note that it's possible to use only the infrastructure tunnel for management and not the intranet tunnel, in which case users wouldn't be able to access the corporate resources.

As you can see, DirectAccess is great for users, but it's even better for the IT department. With DirectAccess, all the communications traveling across the Internet are authenticated and encrypted using IPSec, which gives users a seamless but highly secure connection from their machines to the corporate network. In addition, because users' computers are connected to the key IT infrastructure systems whenever the users turn on their computers, it's easy to manage those computers.

DirectAccess is built on IPv6. Although the industry is certainly moving toward using IPv6, it's a very slow transition and many networks, including the Internet, are primarily using IPv4. As a result, DirectAccess leverages IPv6 transition technologies to establish communication between the DirectAccess server and those clients using IPv4 to connect to the Internet. The common transition technologies being used are Teredo and IP over HTTPS (IP-HTTPS), both of which allow the tunneling of IPv6 within IPv4. Technically, the 6to4 transition technology can also be used. However, 6to4 doesn't work when the client is behind a Network Address Translation (NAT) device. Because most Internet-based clients are behind a NAT device of some kind, 6to4 is rarely used in real life.

DirectAccess is a fantastic technology, but it's highly unlikely that you'll be able to get rid of your VPN solution. For example, DirectAccess in Server 2012 works only with domain-joined Windows 8 Enterprise and Windows 7 Enterprise machines. For all other devices—e.g., home machines that aren't domain-joined, non-Enterprise editions of Windows 8 and 7, mobile phones, non-Windows devices—you'll still need to leverage a VPN. I recommend that when you can use DirectAccess, use it. For everything else, you'll need to continue to use a VPN. (If you're struggling to understand the difference between a VPN and DirectAccess, I've heard this summary: The VPN connects the user to the network, whereas DirectAccess extends the network to the computer and user.)

DirectAccess in Server 2012

To deploy a usable DirectAccess implementation in Server 2008 R2, you really need to use the Forefront UAG. It provides a simpler setup experience and enables support for IPv4 targets. Server 2012 includes all of Forefront UAG's technologies related to DirectAccess, such as DNS for IPv6 to IPv4 (DNS64) and Network Address Translation for IPv6 to IPv4 (NAT64). As a result, DirectAccess will work in a Server 2012 network, without requiring you to install an additional product like Forefront UAG.

Server 2012 introduces a new connectivity-related role named Remote Access. Through this role, you can manage DirectAccess and VPNs (including site-to-site VPNs) as a unified service.

Server 2012 also introduces multi-site support and geographical awareness, which means you can have multiple DirectAccess deployments (single servers or arrays) at different locations, and clients will use whichever site is closest based on response time. The response time is determined using an HTTP probe that tests connectivity to all the DirectAccess deployments identified in its policy. If a site fails, clients will use the remaining DirectAccess deployments. Multi-site awareness is a Windows 8 native capability. However, if you really need this capability for Windows 7 clients, there are ways to make it work to a certain extent. (There are some constraints.)

If you have only Windows 8 clients, the requirement for a PKI is removed in Server 2012 DirectAccess. In Windows 7 clients, PKI is needed for IPSec, but now IPSec can actually use Kerberos tickets through the Kerberos proxy running on domain controllers (DCs).

One common concern when using DirectAccess is security. It's a completely automated technology—the computer automatically connects to the intranet through its secure tunnel and is always on. For authentication, DirectAccess uses:

You could consider this a kind of "1.5 factor" authentication because you have the certificate bound to the machine and user password. However, many organizations require two-factor authentication, so smart cards are often used for DirectAccess deployments that have Windows 7 clients. For Windows 8 clients, physical smart cards are no longer required (but are still supported) because you can use the new Windows 8 virtual smart card feature that leverages the machine's Trusted Platform Module (TPM). This makes deployments much simpler, reduces costs, and increases security. A one-time password is also supported with Server 2012 DirectAccess.

Changes in DirectAccess Requirements

Because Microsoft made many changes in the way DirectAccess works in Server 2012, there are many changes in what is required to use it. Here are the most noteworthy changes made to the IP address requirements, Active Directory (AD) requirements, server requirements, and client requirements.

Changes in IP address requirements. In Server 2008 R2, two consecutive public IPv4 addresses are required for the DirectAccess service because Teredo requires two IP addresses to ascertain the type of NAT device the client is behind. (For more details, see "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs).") In Server 2012, you can place the DirectAccess server behind the NAT device. Thus, if the NAT device is present in the demilitarized zone (DMZ), the DirectAccess server can be deployed using private IP addresses. This means you can now set up DirectAccess on home computers if desired.

It's important to note that while most DirectAccess deployments are behind the NAT device, the most optimal deployment over the Internet is using Teredo, which doesn't support NAT. So, having two consecutive public IP addresses is ideal, but if it isn't possible, you just need to use IP-HTTPS. (Most times, clients don't have public IP addresses, so 6to4 can't be used. Even when it can be used, such as on mobile networks, I've seen problems arise.)

Changes in AD requirements. A single DirectAccess deployment can now service multi-forest deployments, provided there's a bi-directional trust between the forests. Although you still need to configure cross-forest scenarios, the graphical tools in DirectAccess do all the heavy lifting, provided that a bi-direction forest trust exists between the forest containing the DirectAccess servers and the forests containing the users.

Changes in server requirements. In Server 2012, Server Core is fully supported for the DirectAccess server. Interestingly, Microsoft now recommends running the DirectAccess server on a virtual machine (VM). If you run it on a VM, you can still offload the IPSec traffic to the network adapter (assuming it supports IPSec offload) and still fully leverage technologies such as Receive Side Scaling for best performance.

Previously, Microsoft recommended running DirectAccess on physical hosts because of the high workloads related to encryption. In Server 2008 R2, DirectAccess uses double encryption if HTTPS is used because encryption occurs for the IPSec traffic and then again for the HTTPS traffic. In Server 2012, DirectAccess can use IP-HTTPS NULL encryption instead of double encryption, thereby reducing the overhead for the client and DirectAccess server. Ultimately, this means less resource usage and more users per server—I've heard as high as four times the number of users. In Server 2012, using IP-HTTPS is almost on performance parity with using Teredo.

Changes in client requirements. When you use Windows 7 clients with DirectAccess in Server 2012 or Server 2008 R2, you need to install a separate DirectAccess Connectivity Assistant (DCA), which gives a system tray icon that shows the DirectAccess connection state. When you use Windows 8 clients with DirectAccess in Server 2012, the DCA isn't needed because DirectAccess support is integrated with the rest of the networking features in the Windows 8 OS. The DirectAccess connectivity status is shown alongside the status of other connections (e.g., wireless connections) in the networking UI. The networking UI also exposes a DirectAccess properties interface, which is typically used for troubleshooting. The DirectAccess properties interface allows DirectAccess logs to be exported to a file, which can then be sent to the IT Help desk. It also allows users to override the chosen DirectAccess site and specify which site they'd rather connect to.

Offsite provisioning is useful if you need to set up clients that aren't physically connected to the corporate network. In Windows 8 clients, full offsite provisioning is possible, including a Windows-To-Go based installation. (A Windows-To-Go based installation isn't possible when using Windows 7 clients with Server 2012 DirectAccess.) It's still necessary to connect to a corporate network resource to download the DirectAccess setup file, but this could be as basic as a secure website. (Note that offsite DirectAccess configuration is possible in Server 2008 R2, but it requires a time-intensive workaround that involves creating a temporary VPN connection.)

Setup and Management of DirectAccess in Server 2012

It's no exaggeration to say that deploying a DirectAccess server is quick and easy in Server 2012. For example, the following describes how to perform a complete single-server DirectAccess deployment for a small or midsized organization. This deployment assumes that an external DNS name exists and points to the correct IP address. Here are the steps:

If you want to watch these steps being performed, check out the accompanying video.

Besides setting up the DirectAccess server, you need to set up the clients. When you deploy a DirectAccess server, DirectAccess automatically creates a GPO named DirectAccess Client Settings, which contains the DirectAccess client configurations. If you want a client to use DirectAccess, you need to join it to the domain and apply that GPO. This can be difficult if that client isn't connected to the corporate network, in which case you need to join the domain offline and apply the policy. To accomplish this in a Windows 8 client, you can use the Djoin.exe command-line utility.

To use Djoin.exe, you first need to provision the machine account in AD and save the provisioning data to a file. For example, the following command provisions a computer account named DAclientExample in the domain savilltech.net, specifies that the DirectAccess Client Settings GPO be applied, and saves the provisioning information in the clientda.txt file:

Djoin.exe /provision  /domain savilltech.net  /machine DAclientExample  /policynames "DirectAccess Client Settings"  /savefile clientda.txt

(Although this command wraps here, you'd enter it all on one line in Cmd.exe. The same holds true for the next command.) After the client has created the clientda.txt file, you can run the following command to request an offline domain join the next time the client starts up:

djoin.exe /requestodj /loadfile clientda.txt  /windowspath %windir% /localos

So, the next time the client starts, it will join the savilltech.net domain and apply the DirectAccess Client Settings GPO.

Note that if you have Windows 7 clients, there are some additional steps required. However, I won't cover them here, because my goal is to show you how easy it is to apply Server 2012 DirectAccess when you're using Windows 8 clients.

The DirectAccess server and client setups I demonstrated here are minimal deployments. Realistically, you'll probably want to make a few changes:

These customizations are possible and desirable in most instances. You can easily make them (as well as many other customizations) after DirectAccess is deployed using the Remote Access Setup page shown in Figure 1, which is the starting page for DirectAccess configuration.

Figure 1: Remote Access Setup Page

In addition to tweaking the initial deployment, you can use the Remote Access Setup page throughout the life cycle of DirectAccess, as your company's needs change. For example, you can use it to add servers, change public names, and change the topology. In addition, there's full Windows PowerShell support for automating tasks such as applying GPO and configuration changes. In Server 2008 R2, you would need to get up at 2:00 a.m. to manually apply GPO and configuration changes through a GUI.

A Vast Improvement

As you can see, DirectAccess is far easier to set up in Server 2012 than it was in Server 2008 R2. Plus, it offers a great end-user experience and powerful management capabilities for your IT department—capabilities far beyond what's possible with a manually initiated VPN connection. But remember, you'll still need a VPN for those non–DirectAccess-capable machines. Fortunately, Server 2012 offers a great VPN experience as well.