New features of DirectAccess in Windows Server 2012

Microsoft gave us DirectAccess in Windows Server 2008 R2 as a way for remote users to have an “always on” secure connection to your internal Active Directory domain. In this post I describe Microsoft's remote access technology and give an overview of the new features of DirectAccess in Windows Server 2012.

Contents

DirectAccess feature improvements
Server Setup Basics
The client experience
Conclusion

Author
Recent Posts

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

Azure PowerShell vs. Azure CLI - Wed, Mar 15 2023
Use Azure Storage for backup - Thu, Feb 23 2023
Azure Data Studio vs. SQL Server Management (SSMS) - Wed, Feb 8 2023

Traditional virtual private network (VPN) connections are generally a pain both for network administrators as well as users. For instance, we admins have to deal with the following pain points (among others):

Remote user unwillingness to use their VPN connections
Support tickets based on VPN-related user error
Balancing firewall rules, protocols, port numbers, and encryption methodologies on the VPN concentrator side and the client side
Connectivity issues arising from IPv4/IPv6 mixed networks, network address translation (NAT) devices, etc.

With DirectAccess, the packet encapsulation, data encryption, and user/computer authentication happens as soon as the TCP/IP protocol stack initializes on the client, even before user logon.

The problem with the original release of DirectAccess, though, was its restrictive requirements generally represented too large a hurdle for many Windows systems administrators to overcome. For example, DirectAccess in Windows Server 2008 R2 required (at least) the following for your environment:

Public key infrastructure (PKI) with your infrastructure servers and all client devices requiring digital certificates
The internal network must be running IPv6
To support IPv6 to IPv4 translation inside your corporate LAN, you had to purchase a license for Microsoft Forefront Unified Access Gateway (UAG)
The DA server must have two NICs with two consecutive public IP addresses

Those were some daunting requirements, right? The great news for those of us who need to support remote users but who are not VPN experts is that Microsoft did away with most of those restrictions in the Windows Server 2012 release of DirectAccess.

DirectAccess feature improvements

Let’s begin by providing you with a laundry list of feature improvements that Microsoft made to DirectAccess in Windows Server 2012:

Rich client monitoring: You can view connected DA clients from the server
Client troubleshooting: You can use DA client PowerShell cmdlets or the Netsh command to troubleshoot DA client configuration settings
Unified management wizard: A “simple” setup option hides most of the underlying complexity of DirectAccess (encryption protocols, certificates, IPv6-to-IPv4 translation, and so forth)
DA server can use a single IP address, and can even be placed behind a NAT
Server Core support

Technically, DirectAccess works by building an IPv6-based, IPsec-encrypted tunnel between the DA client and a DA server endpoint. Multiple protocols come into play in building this tunnel; the specific one(s) that the server and client negotiate depend upon a number of factors, such as the presence or absence of a NAT and any configured firewall rules.

Here’s a smattering of information concerning the DirectAccess remote access protocols:

IP-HTTPS: This is a good choice because the secure tunneling occurs over TCP 443, which is never blocked by firewalls
6to4: We can successfully encapsulate IPv6 packets inside of IPv4 packets when the client and server are directly connected to the Internet (no NAT)
Teredo: This IPv6-to-IPv4 encapsulation method works great when a NAT is involved in the connection
DNS64, NAT64: These protocols, run on the DA server, allow the client to communicate with IPv4-based internal server resources

Server Setup Basics

To get DirectAccess up and running by using the simple wizard, follow these steps:

Install the Remote Access server role on your DA server and install the DirectAccess and VPN (RAS) role services.
After installation, fire up the Remote Access console.
Run the Getting Started Wizard. This is the simple wizard that abstracts most of the setup complexity from you. Don’t worry, though—you will have the chance to modify your configuration later if you need to.
After the wizard completes, navigate to the Operations Status page in the Direct Access console and periodically refresh the view until all DA components are listed in a Working state. This interface is shown in the following screenshot.

Operations Status page in the Remote Access console

That’s literally all there is to basic DirectAccess setup in Windows Server 2012! Now, the downside to the simple setup is that the wizard abstracts the complexity from you and minimizes your initial choices. For instance, you may need to return to your DirectAccess server setup to perform the following tasks:

Switch from a self-signed DA server certificate to a genuine one
Modify the GPO scope for client devices and/or servers

To do this, simply open your Remote Access console and click the desired DA server from the list. You’ll get a live graphic (shown in the following screenshot) that you can click to modify settings for remote clients, remote access servers, infrastructure (back-end) servers, and application (user resource) servers.

Modifying our DirectAccess configuration

The client experience

First off, be aware that DirectAccess is supported only by Windows 8 Enterprise Edition or Windows 7 Enterprise or Ulitimate Edition. To that point, the certificate-less Kerberos proxy works only with Windows 8 clients. That is, you’ll need to deploy a PKI if any of your DA clients run Windows 7.

As far as the user experience of DirectAccess, there is no VPN clients to start. Actually, there is no action required of them at all—all protocol negotiations take place under the hood.

In Windows 8, we can open the Charms bar and click our network connection to see if were are connected via DirectAccess or another network connection type.

Windows 8 client notification that DirectAccess is active

Finally, we can use either the old-school Netsh name show effectivepolicy command or the new-school Get-DAClientExperienceConfiguration PowerShell 3 cmdlet to view client DirectAccess configuration.

Troubleshooting DirectAccess client settings via PowerShell 3

Note that we have rich reporting of client connection data on our DA server via the management console as well.

Conclusion

In my opinion, Microsoft did a fantastic job at making DirectAccess easier to implement and use in Windows Server 2012 and Windows 8. I’ll leave you with some hand-picked resources that you can use as a basis for further study:

Want to write for 4sysops? We are looking for new authors.

4sysops members can earn and read without ads!