3 Important Things You Need to Know about Windows 10 and DirectAccess

DirectAccess and Windows 10 - Better TogetherDirectAccess has been with us for quite some time know, having been originally introduced with Windows Server 2008 R2, later enhanced with Forefront Unified Access Gateway (UAG) 2010, and finally integrated in to the base operating system in Windows Server 2012 R2. Client support for DirectAccess begins with Windows 7 (Enterprise or Ultimate), and also includes Windows 8.x (Enterprise) and Windows 10 (Enterprise or Education).

Although Windows 7 clients are supported for DirectAccess, Windows 10 is highly preferred. Here are three important things you need to know about using Windows 10 with DirectAccess.

  1. Windows 10 Provides Improved Performance and Scalability – Windows 10 includes support for null encryption when using the IP-HTTPS IPv6 transition protocol. This eliminates the needless double-encryption performed by Windows 7 clients, and dramatically reduces the protocol overhead for clients connecting behind port-restricted firewalls. DirectAccess servers can support many more concurrent IP-HTTPS sessions with Windows 10, and it has the added benefit of making the more secure perimeter/DMZ deployment behind an edge security device performing NAT much more attractive.
  2. Windows 10 Supports Geographic Redundancy – Windows 10 includes full support for DirectAccess multisite deployments. Where Windows 7 clients had to be assigned to a single entry point, Windows 10 clients are aware of all entry points in the organization. They are able to automatically select the nearest entry point on startup, and transparently failover to another site if the current site becomes unavailable.
  3. Windows 10 Features an Enhanced Management Experience – From a troubleshooting and support perspective, Windows 10 makes things much easier. The DirectAccess connectivity assistant, an optional component for Windows 7, is now fully integrated with the Windows 10 UI. PowerShell is greatly improved and now includes many native DirectAccess configuration and troubleshooting commands.

As you can see, there are a number of significant advantages for using Windows 10 with DirectAccess. Windows 10 now supports all of the enterprise features of DirectAccess, including geographic redundancy and performance and scalability improvements. Windows 10 is also easier to troubleshoot and manage. If you’re still supporting Windows 7, DirectAccess in Windows Server 2012 R2 can certainly support them. However, without a doubt the best experience, both from an administrator’s and the end user’s perspective, is with Windows 10. Just one more reason to begin planning your migration to Windows 10 with DirectAccess today!

Need assistance with implementing  DirectAccess with Windows 10? I can help! More details here.

DirectAccess DNS Not Working Properly

Name resolution and proper DNS server configuration is vital to the functionality of DirectAccess. When performing initial configuration of DirectAccess, or making changes to the DNS server configuration after initial configuration, you may notice the operations status for DNS indicates Critical, and that the operations state shows Server responsiveness.

DirectAccess DNS Not Working Correctly

Highlighting the DNS server on the Operations Status page and viewing the details shows that DNS is not working properly with the following error message:

None of the enterprise DNS servers <IPv6_address> used by DirectAccess
clients for name resolution are responding. This might affect DirectAccess
client connectivity to corporate resources.

DirectAccess DNS Not Working Correctly

There are a number of things that can contribute to this problem, but a common cause is an error made when assigning a DNS server to a specific DNS suffix. An inexperienced DirectAccess administrator might specify the IPv4 address of an internal corporate DNS server, which is incorrect. The DNS server IPv4 address should be the address assigned to the DirectAccess server’s internal network interface.

The best way to ensure that the DNS server is configured correctly for DirectAccess is to delete the existing entry and then click Detect.

DirectAccess DNS Not Working Correctly

An IPv6 address will be added automatically. This is the IPv6 address of the DNS64 service running on the DirectAccess server, which is how the DNS server should be configured for proper DirectAccess operation.

DirectAccess DNS Not Working Correctly

Once the changes have been saved and applied, the DNS server should once again respond and the status should return to Working.

DirectAccess DNS Not Working Correctly

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.

Requirements

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.

Migration Process

Moving DirectAccess client computers from the old security group to the new one is all that’s required to migrate clients from one DirectAccess deployment to another. Client machines will need to be restarted to pick up the new security group membership, at which time they will also get the DirectAccess client settings for the new deployment. This works seamlessly when clients are on the internal network. It works well for clients that are outside the network too, for the most part. Because clients must be restarted to get the new settings, it can take some time before all clients finally moved over. To speed up this process it is recommended that DirectAccess client settings GPOs be targeted at a specific OUs created for the migration process. A staging OU is created for clients in the old deployment and a production OU is created for clients to be assigned to the new deployment. DirectAccess client settings GPOs are then targeted at those OUs accordingly. Migrating then only requires moving a DirectAccess client from the old OU to the new one. Since OU assignment does not require a reboot, clients can be migrated much more quickly using this method.

Summary

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.

DirectAccess Consulting Services Now Available

Microsoft Certified Solutions Associate (MCSA)For the last five years I’ve been helping organizations large and small deploy DirectAccess. During that time I have amassed a wealth of knowledge and experience with this unique technology. DirectAccess is not trivial to install, configure, or troubleshoot. Also, it’s easy to make mistakes in the planning and design phase that can turn in to serious issues later in the deployment. To make matters worse, many organizations are deploying DirectAccess for the first time, and without essential guidance they are prone to making common mistakes or choosing configuration options that are less than optimal both in terms of supportability and performance.

Having deployed DirectAccess for some of the largest companies in the world, there isn’t much I haven’t already encountered. If you are looking for the best chance of success for your DirectAccess deployment, consider a consulting engagement with me. I can provide assistance with all facets of DirectAccess implementation including planning and design, installation, configuration, and troubleshooting. Consulting services at reasonable rates are available for all types of DirectAccess work including:

  • New DirectAccess installations
  • Migration from previous versions of DirectAccess
  • Upgrade or expansion of existing DirectAccess deployment
  • Enterprise planning and design for large-scale, multisite DirectAccess deployments
  • DirectAccess high availability (local and geographic)
  • Manage-out for DirectAccess with external hardware load balancers and/or multisite configuration
  • Multisite DirectAccess with geographic redundancy for Windows 7 clients
  • Existing DirectAccess design review and security assessment
  • Windows Server 2012 R2 client-based VPN configuration
  • DirectAccess client connectivity troubleshooting
  • DirectAccess training

Additionally, consulting services are available for a variety of security solutions as well as on-premises and cloud networking technologies such as:

  • Azure networking and infrastructure
  • Cross-premises connectivity to Azure
  • Certificate services (PKI)
  • IP address management
  • ISA Server and Forefront Threat Management Gateway (TMG) migration

All services can be performed on-site or remotely. If you are interested in obtaining my services, drop me a note at rich@richardhicks.com for more details.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

For DirectAccess manage out scenarios, it is necessary to configure the Windows firewall on the DirectAccess client to allow any required inbound communication from the corporate network. For example, if management hosts on the internal network need to initiate Remote Desktop sessions with remote connected DirectAccess clients, the Remote Desktop – User Mode (TCP-In) Windows firewall rule will need to be enabled for the Public and Private profiles.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

While enabling this rule will allow remote desktop connections to be made from the corporate network, its default configuration will also accept remote desktop connections from any network. From a security perspective this is not desirable.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

A better solution is to restrict access to connections originating only from the corporate network. To do this it will be necessary to identify the ISATAP prefix used internally. To determine the corporate ISATAP prefix, run the ipconfig command on a management workstation that is configured for ISATAP. The ISATAP prefix will be the first 96 bits of the IPv6 address assigned to the ISATAP tunnel adapter (essentially everything with the exception of the embedded IPv4 address).

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

On the DirectAccess client, right-click the firewall rule and choose Properties. Choose the Scope tab and then select These IP addresses . Click Add and then enter the ISATAP prefix as shown here.

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

Once the firewall rule is configured to restrict access to the ISATAP prefix, only corporate management workstations on the internal network will have access to remote DirectAccess clients.

DirectAccess IPv6 Transition Protocols Explained

Introduction

From a client perspective, DirectAccess is an IPv6-only solution. The DirectAccess client communicates with the DirectAccess server exclusively using IPv6. However, IPv6 is not widely deployed, so the most common scenario will find your DirectAccess clients and servers on the IPv4 Internet.

To facilitate DirectAccess client to server communication with IPv6 when the client is on the IPv4 Internet, IPv6 transition protocols are employed. These protocols effectively tunnel IPv6 packets in IPv4 packets. DirectAccess makes use of three IPv6 transition protocols for client to server connections – 6to4, Teredo, and IP-HTTPS.

DirectAccess Transition Protocols

6to4 – The 6to4 IPv6 transition protocol works by encapsulating IPv6 packets in IPv4 packets using IP protocol 41. 6to4 does not work when the client or the server is behind a NAT, so this IPv6 transition protocol is only used when the client and server are assigned public IPv4 addresses. DirectAccess clients with public IPv4 addresses aren’t common though, and there are some challenges with the stability of 6to4. From experience I can tell you that 6to4 often fails when clients use a cellular Wi-Fi hotspot, for example. For this reason it is generally recommended that you proactively disable this transition protocol to avoid potential issues in the future.

TeredoTeredo is an IPv6 transition protocol that is designed to work when a DirectAccess client (but not the DirectAccess server) is behind a NAT. It works by encapsulating IPv6 packets in IPv4 packets using UDP on port 3544. Teredo will be used any time the DirectAccess client has a private IPv4 address, or when the client has a public IPv4 address and the 6to4 protocol is unavailable (e.g. 6to4 is disabled, or outbound access to IP protocol 41 is restricted by firewall policy). To support Teredo, the DirectAccess server must be configured with two consecutive public IPv4 addresses. In addition, Teredo uses ICMP for NAT detection (e.g. cone, restricted, symmetric), so ICMPv4 echo requests must be allowed inbound to any host with which the DirectAccess client communicates.

IP-HTTPSIP-HTTPS is an IPv6 transition protocol that works by encapsulating IPv6 packets in IPv4 packets using HTTP with SSL/TLS. It is the IPv6 transition protocol of last resort, and will be used any time that 6to4 or Teredo aren’t available. The advantage to using IP-HTTPS is ubiquitous firewall access. Any network with access to the public Internet should, at a minimum, allow outbound HTTP and HTTPS. In some deployment scenarios, IP-HTTPS can be disadvantageous. For example, when Windows 7 DirectAccess clients leverage this IPv6 transition protocol, IPsec-encrypted traffic is encrypted again using SSL/TLS. This double encryption results in high processing overhead and often translates to poor performance and limited scalability. Windows 8 and later clients do not suffer this limitation, as they support null encryption which eliminates the negative effects imposed by double encryption. For the best results using IP-HTTPS, use an application delivery controller to offload SSL, or deploy Windows 8 or later clients. In any case, do not collocate the client-based VPN role on the DirectAccess server, as doing so will remove support for null encryption completely and force even Windows 8 and later clients to perform double encryption for IP-HTTPS traffic.

DirectAccess Server Configuration

To support the 6to4 and Teredo IPv6 transition protocols, the DirectAccess server must be configured with two network interfaces; one internal and one external. The DirectAccess server must have public IPv4 addresses assigned to its external network interface. For Teredo in particular, the DirectAccess server requires two consecutive public IPv4 addresses. Beginning with Windows Server 2012, DirectAccess provides support for DMZ/perimeter network deployment behind a NAT device using RFC1918 private IPv4 addresses with either one or two network interfaces. In this deployment scenario, the DirectAccess server only supports the use of the IP-HTTPS IPv6 transition protocol. 6to4 and Teredo are not available when the DirectAccess server is located behind a NAT device and these IPv6 transition protocols should be disabled on all DirectAccess clients.

Unable to Generate DirectAccess Troubleshooting Logs in Windows 8.x Clients

When troubleshooting DirectAccess connectivity issues on Windows 8.x clients you may find the option to generate advanced troubleshooting logs missing. On Windows 8 clients, the Collect Logs button will be grayed out. On Windows 8.1 clients it will be missing altogether.

Windows 8

DirectAccess Client Troubleshooting Logs

Windows 8.1

DirectAccess Client Troubleshooting Logs

This issue is caused by not providing an e-mail address when configuring the DirectAccess server.

DirectAccess Client Troubleshooting Logs

To resolve this issue, supply an e-mail address and apply the configuration. The e-mail address does not necessarily have to be valid. It simply has to be present in order to have the option to generate DirectAccess advanced troubleshooting logs. After the clients have updated their group policy, the option to collect advanced troubleshooting logs will be available.

DirectAccess Client Troubleshooting Logs

DirectAccess Client Troubleshooting Logs

Microsoft DirectAccess Client Troubleshooting Tool

To aid in troubleshooting Windows DirectAccess client configuration and connectivity, Microsoft recently made available the Windows DirectAccess Client Troubleshooting Tool. The tool, which is a portable executable based on the .NET Framework and does not require installation, operates by performing a series of tests and health checks on a connected DirectAccess client. As of this release, the troubleshooting tool checks network interface configuration, Network Location Server (NLS) reachability, IP connectivity and the status of transition technologies, Windows Firewall with Advanced Security configuration, computer certificate status, as well as network connectivity over the infrastructure and user IPsec DirectAccess tunnels.

Microsoft Windows DirectAccess Client Troubleshooting Tool

The tool also features an optional debug mode that provides highly detailed information gathered from each of the tests executed.

Microsoft Windows DirectAccess Client Troubleshooting Tool

The tool is supported on both Windows 7 and Windows 8.x clients. If you implement or support DirectAccess, this utility will certainly speed up your troubleshooting by providing deep insight in to the configuration and current connectivity status for your DirectAccess clients. You can download the Microsoft DirectAccess client troubleshooting tool here.

Troubleshooting Name Resolution Issues on DirectAccess Clients

When troubleshooting name resolution issues on a Windows client, NSlookup is an essential tool. However, it is important to understand that using NSlookup on a DirectAccess client might not always work as you expect. Although using NSlookup on a DirectAccess client will work normally when the client is on the corporate network, it will not provide the correct results to queries for internal hostnames when the DirectAccess client is outside of the corporate network without taking additional steps. This is because when a DirectAccess client is outside the corporate network, the Name Resolution Policy Table (NRPT) is enabled. The NRPT provides policy-based name resolution routing for DirectAccess clients, sending name resolution requests for certain namespaces to specific DNS servers. You can view the NRPT on a Windows 8.x DirectAccess client by issuing the following PowerShell command:

Get-DnsClientNrptPolicy

Troubleshooting Name Resolution Issues on DirectAccess Clients

You can view the NRPT on a Windows 7 DirectAccess client by issuing the following netsh command:

netsh namespace show policy

Troubleshooting Name Resolution Issues on DirectAccess Clients

Here you’ll notice that the namespace .lab.richardhicks.net is configured to use the DNS64 service running on the DirectAccess server at 2002:62bd:d898:3333::1. Notice also that the host nls.lab.richardhicks.net is not configured to use a DNS server. This effectively exempts this host from the NRPT, forcing name resolution requests for this Fully-Qualified Domain Name (FQDN) to be delivered to the DNS servers configured on the network adapter.

A Working Example

With the NRPT enabled, which occurs whenever the DirectAccess client is outside of the corporate network, a name resolution request for app1.lab.richardhicks.net would be sent to the DNS64 service on the DirectAccess server. A name resolution request for technet.microsoft.com would be sent to the DNS servers assigned to the network adapter because the NRPT contains no entry for this namespace. And even though the host nls.lab.richardhicks.net is a part of the internal namespace, a name resolution request for this host would also be sent to the DNS servers assigned to the network adapter because it has been specifically exempted from the NRPT.

NSlookup

The NSlookup utility is unaware of the NRPT. Whenever you use NSlookup it will, by default, automatically send queries directly to the DNS servers configured on the network adapter, regardless of the NRPT. If you wish to use NSlookup to test name resolution for external hostnames, use it as you normally would. However, if you wish to use NSlookup to resolve internal hostnames over the DirectAccess connection, you will need to tell NSlookup to use the DNS64 service running on the DirectAccess server. You can do this by running NSlookup interactively and using the server command to point it to the IPv6 address of the DNS64 service, which you can find in the NRPT.

Troubleshooting Name Resolution Issues on DirectAccess Clients

This also applies to the PowerShell cmdlet Resolve-DNSname. Here you’ll use the -Server switch to specify the DNS64 server’s IPv6 address.

Resolve-DNSName –Server <DNS64_IPv6_Address> app1.lab.richardhicks.net

Troubleshooting Name Resolution Issues on DirectAccess Clients

How to Install and Configure KB2862152 for DirectAccess

Microsoft recently released security advisory 2862152 to address a vulnerability in IPsec that could allow DirectAccess security feature bypass. The associated update addresses an issue with how the DirectAccess client authenticates with a DirectAccess server. Without the update, it is possible for an attacker to launch a man-in-the-middle attack to intercept DirectAccess communication.

The update itself does not resolve the issue directly, however. The update simply allows administrators to configure DirectAccess clients using specific registry settings to enforce more stringent checks during IPsec negotiation after the update is installed. The challenge with this update is that the documentation contained within the knowledge base article is extremely detailed and includes information that pertains to many different remote access scenarios, not just DirectAccess. This has led to much confusion, and many administrators are unclear for which clients and deployment scenarios the registry changes are required.

For DirectAccess deployments, the update needs to be applied to all of your DirectAccess clients. The update does NOT need to be applied to the DirectAccess server. The registry settings required on the client will be dictated based on the configured authentication method for your DirectAccess deployment. If you have configured DirectAccess to use certificate-based authentication by checking selecting the Use computer certificates option as shown below, you’ll only need to make registry settings changes on your Windows 7 clients. Windows 8/8.1 clients DO NOT require any changes be made to the registry when DirectAccess is configured to use certificate-based authentication.

Microsoft Security Update KB2862152 for DirectAccess

If you are NOT using computer certificates for authentication, then you must make registry changes to all of your Windows 8/8.1 clients. For detailed, prescriptive guidance on implementing the client-side registry changes required to support this update and mitigate this vulnerability, Jason Jones has done a wonderful job documenting those steps specifically, so I’ll refer you to his post here.

You can find the update for KB2862152 for all supported clients here.

%d bloggers like this: