DirectAccess, Windows 10, and Network Access Protection (NAP)

Windows 10, DirectAccess, and NAPFirst introduced with Windows Server 2008, Microsoft Network Access Protection (NAP) is a technology that allows IT administrators to create and enforce system health requirements that must be met before a computer can connect to the network. Common NAP enforcement points include Ethernet switches (802.1x), DHCP, IPsec, remote access VPN, and Terminal Services Gateway (TS Gateway) connections. DirectAccess also supports NAP integration, which allows administrators to extend this solution to include their DirectAccess clients.

Unfortunately, NAP has proven not to be very popular, and the adoption rate for this technology has been quite minimal. With that, Microsoft formally deprecated NAP in Windows Server 2012 R2, and removed it completely from Windows Server 2016.

Crucially the plumbing for NAP integration in the Windows 10 client operating system has also been removed. For DirectAccess deployments that have been configured to use NAP, this obviously presents a problem. In this scenario, Windows 7/8 clients will function normally. However, Windows 10 clients will not be able to connect. Since NAP integration with DirectAccess is a global setting, all clients must conform to NAP. There is no option to exclude only Windows 10 clients from NAP.

DirectAccess, Windows 10, and NAP

There are two ways in which to resolve this problem. The first is simply to disable NAP integration. However, if you still want to enforce NAP requirements for Windows 7/8 clients, but at the same time also want to allow Windows 10 clients to use DirectAccess, a separate dedicated DirectAccess deployment without NAP integration configured will have to be deployed to support Windows 10 DirectAccess clients.

Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

DirectAccess in Windows Server 2012 R2 supports many different deployment configurations. It can be deployed with a single server, multiple servers in a single location, multiple servers in multiple locations, edge facing, in a perimeter or DMZ network, etc.

Global Settings

There are a number of important DirectAccess settings that are global in scope and apply to all DirectAccess clients, such as certificate authentication, force tunneling, one-time password, and many more. For example, if you configure DirectAccess to use Kerberos Proxy instead of certificates for authentication, Windows 7 clients are not supported. In this scenario it is advantageous to have a second parallel DirectAccess deployment configured specifically for Windows 7 clients. This allows Windows 8 clients to take advantage of the performance gains afforded by Kerberos Proxy, while at the same time providing an avenue of support for Windows 7 clients.

Parallel Deployments

To the surprise of many, it is indeed possible to deploy DirectAccess more than once in an organization. I’ve been helping customers deploy DirectAccess for nearly five years now, and I’ve done this on more than a few occasions. In fact, there are some additional important uses cases that having more than one DirectAccess deployment can address.

Common Use Cases

QA and Testing – Having a separate DirectAccess deployment to perform testing and quality assurance can be quite helpful. Here you can validate configuration changes and verify updates without potential negative impact on the production deployment.

Delegated Administration – DirectAccess provides support for geographic redundancy, allowing administrators to create DirectAccess entry points in many different locations. DirectAccess in Windows Server 2012 R2 lacks support for delegated administration though, and in some cases it may make more sense to have multiple separate deployments as opposed to a single, multisite deployment. For example, many organizations are divided in to different business units internally and may operate autonomously. They may also have different configuration requirements, which can be better addressed using individual DirectAccess implementations.

Migration – If you have currently deployed DirectAccess using Windows Server 2008 R2 with or without Forefront UAG 2010, migrating to Windows Server 2012 R2 can be challenging because a direct, in-place upgrade is not supported. You can, however, deploy DirectAccess using Windows Server 2012 R2 in parallel to your existing deployment and simply migrate users to the new solution by moving the DirectAccess client computer accounts to a new security group assigned to the new deployment.

Major Configuration Changes – This strategy is also useful for scenarios where implementing changes to the DirectAccess configuration would be disruptive for remote users. For example, changing from a single site to a multisite configuration would typically require that all DirectAccess clients be on the LAN or connect remotely out-of-band to receive group policy settings changes after multisite is first configured. In addition, parallel deployments can significantly ease the pain of transitioning to a new root CA if required.

Unique Client Requirements – Having a separate deployment may be required to take advantage of the unique capabilities of each client operating system. For example, Windows 10 clients do not support Microsoft Network Access Protection (NAP) integration. NAP is a global setting in DirectAccess and applies to all clients. If you still require NAP integration and endpoint validation using NAP for Windows 7 and Windows 8.x, another DirectAccess deployment will be required to support Windows 10 clients.


To support multiple Windows Server 2012 R2 DirectAccess deployments in the same organization, the following is required:

Unique IP Addresses – It probably goes without saying, but each DirectAccess deployment must have unique internal and external IPv4 addresses.

Distinct Public Hostname – The public hostname used for each deployment must also be unique. Multi-SAN certificates have limited support for DirectAccess IP-HTTPS (public hostname must be the first entry in the list), so consider using a wildcard certificate or obtain certificates individually for each deployment.

Group Policy Objects – You must use unique Active Directory Group Policy Objects (GPOs) to support multiple DirectAccess deployments in a single organization. You have the option to specify a unique GPO when you configure DirectAccess for the first time by clicking the Change link next to GPO Settings on the Remote Access Review screen.

Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

Enter a distinct name for both the client and server GPOs. Click Ok and then click Apply to apply the DirectAccess settings for this deployment.

Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

Windows 7 DirectAccess Connectivity Assistant (DCA) GPOs – If the DirectAccess Connectivity Assistant (DCA) v2.0 has been deployed for Windows 7 clients, separate GPOs containing the DCA client settings for each individual deployment will have to be configured. Each DirectAccess deployment will have unique Dynamic Tunnel Endpoint (DTE) IPv6 addresses which are used by the DCA to confirm corporate network connectivity. The rest of the DCA settings can be the same, if desired.

Supporting Infrastructure

The rest of the supporting infrastructure (AD DS, PKI, NLS, etc.) can be shared between the individual DirectAccess deployments without issue. Once you’ve deployed multiple DirectAccess deployments, make sure that DirectAccess clients DO NOT belong to more than one DirectAccess client security group to prevent connectivity issues.


DirectAccess with Windows Server 2012 R2 supports many different deployment models. For a given DirectAccess deployment model, some settings are global in scope and may not provide the flexibility required by some organizations. To address these challenges, consider a parallel deployment of DirectAccess. This will enable you to take advantage of the unique capabilities of each client operating system, or allow you to meet the often disparate configuration requirements that a single deployment cannot support.

Features Deprecated in Forefront UAG Service Pack 3

With the recent release of Service Pack 3 (SP3) for Microsoft Forefront Unified Access Gateway (UAG) 2010, Microsoft has published a list of features in UAG SP3 that have been deprecated. To be clear, this does not mean these features cease to function after you install SP3 on UAG! It is simply meant to give network engineers and security administrators an idea about what features are likely to be removed from future releases of Forefront UAG. Some of the deprecated features should come as no surprise. For example, DirectAccess support in Forefront UAG is now deprecated in favor of DirectAccess in Windows Server 2012. Also, features such as Secure Sockets Tunneling Protocol (SSTP) for client-based remote access are better handled using the remote access role in Windows Server 2012. Other deprecated features may present more of a challenge if you’ve been relying on them to provide secure remote access to applications, such as the deprecation of support for some authentication repositories (e.g. Novell Directory, Notes Directory, TACACS) or the Java-based Session Cleanup tool. For a complete list of deprecated features in Forefront UAG SP3, click here.

Overview of New DirectAccess Features in Windows Server 2012

Microsoft recently announced the Release to Manufacturing (RTM) for Windows Server 2012. Windows Server 2012 includes a new Unified Remote Access role that provides many new and exciting features. Along with significant enhancements to DirectAccess, the Routing and Remote Access Service (RRAS) can now be co-located with DirectAccess server to provide legacy remote access VPN client connectivity (PPTP, L2TP/IPsec, and SSTP) as well as site-to-site VPN. Windows Server 2012 can now serve as your consolidated remote access solution and can be managed from a single management console. Here’s an overview of some of the compelling new features found in Windows Server 2012 DirectAccess.

Simplified and Flexible Deployment

Windows Server 2012 DirectAccess includes a new simplified deployment model makes implementing DirectAccess incredibly simple. After adding the Remote Access role, configuring DirectAccess can be done, quite literally, in just three mouse clicks. The new simplified deployment model does have some limitations, so the deployment wizard includes the flexibility to fully customize the implementation according to your specific requirements. Also, DirectAccess in Windows Server 2012 now supports deployment behind an existing edge firewall or border router/NAT device. Previous versions of DirectAccess had a hard requirement to be placed directly on the network edge and have two public IPv4 addresses assigned to it. In addition, Windows Server 2012 DirectAccess now also supports a single network adapter configuration, allowing the remote access gateway to be deployed inside of an existing perimeter network or DMZ. Another significant improvement with DirectAccess in Windows Server 2012 is support for multiple network entry points for DirectAccess clients. This feature is essential for large organizations with a requirement for automatic and transparent redundancy and intelligent client roaming. To simplify deployment and management, PowerShell 3.0 included with Windows Server 2012 can be used to fully automate and manage all aspects of the Unified Remote Access and DirectAccess gateway role. Finally, Windows Server 2012 also supports Offline Domain Join which allows administrators to join computers to the domain without having corporate network connectivity.

Reduced Infrastructure Requirements

A major limitation to DirectAccess in Windows Server 2008 R2 was the requirement for running IPv6 on the internal corporate network. As a workaround, Forefront Unified Access Gateway (UAG) 2010 could be deployed in the DirectAccess gateway role as it included protocol translators (DNS64 and NAT64) which allowed DirectAccess clients to communicate with intranet resources that were running only IPv4. However, deploying Forefront UAG added expense and complexity to the solution. Forefront UAG 2010 is no longer required to support this scenario, as the DNS64 and NAT64 protocol translators are now included in Windows Server 2012 DirectAccess. The new simplified deployment model eliminates the requirement for a Public Key Infrastructure (PKI), although certificates are still required for authentication so self-signed certificates are employed. A PKI is still the recommended and preferred way to implement certificates, and in fact a PKI is a requirement in certain deployment scenarios, such as when forced tunneling is configured, or when strong authentication or Network Access Protection integration is required.

Performance, Scalability and High Availability Improvements

The Microsoft core networking team did a tremendous job addressing the performance and scalability limitations of previous iterations of DirectAccess. A common complaint from those who have deployed earlier versions of DirectAccess was the performance of the IP-HTTPS transition protocol. In a nutshell, a DirectAccess client would fall back to using IP-HTTPS for DirectAccess communication when it was located behind a NAT device that was also preventing outbound UDP 3544. When this occurred, IPsec encrypted tunnels would then be encrypted again with SSL/TLS. This placed heavy demands on both the client and server side of the tunnel and severely reduced performance and limited scalability. In Windows Server 2012 DirectAccess, IP-HTTPS performance is on par with that of Teredo, as IP-HTTPS now uses null encryption for DirectAccess communication, eliminating the redundant and needless double encryption. With the simplified deployment scenario, only a single IPsec tunnel is required for DirectAccess corporate network connectivity. Requiring just one IPsec tunnel for each client reduces the processing load on the DirectAccess gateway significantly in large scale deployments. In terms of reliability, true high availability is now included with DirectAccess in Windows Server 2012 with the inclusion of Network Load Balancing (NLB) support for DirectAccess gateways. NLB provides efficient active/active clustering capabilities that offer more flexible scalability than using failover clustering in previous DirectAccess releases.


DirectAccess in Windows Server 2012 includes additional security options. DirectAccess now natively supports strong authentication using RADIUS One-Time Passwords (OTP), and also supports Virtual Smart Cards hosted on the mobile computer’s Trusted Platform Module (TPM). The Unified Remote Access role can be deployed on Server Core, which substantially improves the overall security of the solution by reducing the attack surface, while at the same time decreasing system downtime by reducing the number of updates required by the operating system. In addition, a new feature of the Windows 8 client prompts the user for network credentials, if necessary, to facilitate remote corporate network connectivity when the DirectAccess client is located behind an authenticating proxy.

As you can see, there are many new and exciting features and capabilities included in the new Unified Remote Access role on Windows Server 2012. Many of these features will greatly simplify the configuration, deployment, and management of remote access and DirectAccess. Also, many of the new capabilities provided with Windows Server 2012 DirectAccess effectively eliminate the need to deploy Forefront Unified Access Gateway (UAG) 2010, making the overall solution less complex and more cost effective. Windows Server 2012 DirectAccess will provide support for Windows 7 Enterprise and Ultimate clients. However, Windows 8 Enterprise clients will be required to take full advantage of many of the new advanced features of Windows Server 2012 DirectAccess.

Hello World!

It starts…again! Welcome to my new Microsoft DirectAccess blog! After many years of writing about the Microsoft Forefront edge security suite at, I’ve decided to create a blog to post articles pertaining to DirectAccess. DirectAccess is an always-on remote access solution that provides seamless and transparent connectivity to corporate network resources regardless of where the client is physically located. As long as the client has Internet connectivity they can securely access applications and data that reside on the internal corporate network. In addition, I will use this blog to post information about related technologies such as VPN, IPv6, NAP, and other operating system core networking functionality. For the record, I have no plans to abandon my Forefront TMG 2010 blog any time soon. However, if you are interested in Microsoft DirectAccess or other remote access and core networking features, continue to watch this space. Stay tuned for more!

%d bloggers like this: