Top 5 DirectAccess Troubleshooting Tips

Top 5 DirectAccess Troubleshooting TipsDirectAccess is a thing of beauty when everything is working as it should. When it isn’t, troubleshooting can be quite challenging. DirectAccess relies on many Windows platform technologies such as Active Directory for authentication, PKI for certificate management, group policy for settings deployment, IPsec for encryption, and IPv6 for transport. With so many dependencies, locating the source of the problem can be a difficult and daunting task.

I’m frequently called upon to help organizations of all sizes with DirectAccess troubleshooting. While this post is not intended to be a detailed, prescriptive guide for DirectAccess troubleshooting, I did want to share some common troubleshooting tips based on many years of troubleshooting DirectAccess.

Here are my top 5 DirectAccess troubleshooting tips:

  1. Check Prerequisites – Before diving in and collecting network traces and scouring event logs for clues as to why DirectAccess isn’t working, it’s essential to start at the beginning. Often the source of trouble is missing or misconfigured prerequisites. For example, is the DirectAccess client running a supported operating system? Remember, clients must be running Windows 10 Enterprise or Education, Windows 8.x Enterprise, or Windows 7 Enterprise or Ultimate. Also, ensure that the Windows firewall is enabled on DirectAccess servers and clients, that certificates are installed and valid (trusted, correct EKU, etc.), and that the DirectAccess settings GPO has been applied to servers and clients.
  2. Validate External Connectivity – If you are following implementation and security best practices for DirectAccess, the DirectAccess server will be in a perimeter/DMZ network behind an edge firewall. The firewall must be configured to allow inbound TCP port 443 only. If the firewall is also performing Network Address Translation (NAT), the NAT rule must be configured to forward traffic to the DirectAccess server’s dedicated or virtual IP address (VIP), or the VIP of the load balancer. Watch for routing issues when using load balancers too. It’s a good idea to confirm external connectivity using the Test-NetConnection PowerShell command. Even better, use the open source tool Nmap for more thorough testing.
  3. Remove Third Party Software – I can’t tell you how many times I’ve resolved DirectAccess connectivity issues by removing (not just disabling!) third party software on the client and/or server. It’s not uncommon for third-party security software to interfere with IPsec and/or IPv6 communication, both of which are vital to DirectAccess. If your DirectAccess troubleshooting efforts reveal no underlying issues with prerequisites or external connectivity, I’d suggest removing (at least temporarily) any third-party software and testing again.
  4. Isolate Environmental Issues – Occasionally other settings applied manually or via Active Directory group policy will interfere with DirectAccess. Examples include IPv6 being disabled in the registry, IPv6 transition technologies required to support DirectAccess are turned off, essential firewall rules for DirectAccess are disabled, or manipulating local security settings such as Access this computer from the network. To assist with troubleshooting it might be necessary to temporarily place DirectAccess clients and servers in their own dedicated Organizational Units (OUs) and block inheritance to isolate the configuration as much as possible. In addition, if DirectAccess clients are servers are provisioned using images or templates, testing with a clean build straight from the installation source (ISO or DVD) can be helpful.
  5. Check for Unsupported Configurations – If DirectAccess isn’t working, it might be possible the configuration you are trying to use is not supported. Examples including strong user authentication with OTP when force tunneling is enabled, provisioning Windows 7 clients when using Kerberos Proxy authentication, or provisioning Windows 10 clients when Network Access Protection (NAP) integration is enabled. These configurations won’t work and are formally documented here.

This is by no means a comprehensive or exhaustive troubleshooting guide. For more information and additional DirectAccess troubleshooting guidance I would encourage you to purchase my book Implementing DirectAccess with Windows Server 2016, which has an entire chapter devoted just to troubleshooting. In addition, watch my DirectAccess video training courses on Pluralsight for details and information about DirectAccess installation, configuration, management, support, and troubleshooting. And if you’re still struggling to resolve a DirectAccess problem, use the form at the bottom of this page to contact me to inquire about additional troubleshooting help.

Additional Resources

Microsoft Windows DirectAccess Client Troubleshooting Tool
DirectAccess and Windows 10 Professional
DirectAccess Troubleshooting with Nmap
DirectAccess Unsupported Configurations
Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book

Need assistance with DirectAccess troubleshooting? Complete the form below and I’ll get in touch with you.

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

A Windows 7 or Windows 8.x/10 client may fail to establish a DirectAccess connection using the IP-HTTPS IPv6 transition technology. When troubleshooting this issue, running ipconfig.exe shows that the media state for the tunnel adapter iphttpsinterface is Media disconnected.

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Running the Get-NetIPHttpsState PowerShell command on Windows 8.x/10 clients or the netsh interface httpstunnel show interface command on Windows 7 clients returns an error code of 0x90320, with an interface status Failed to connect to the IPHTTPS server; waiting to reconnect.

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Error code 0x90320 translates to SEC_I_INCOMPLETE_CREDENTIALS, indicating the client was unable to authenticate to the DirectAccess server during the TLS handshake when establishing the IP-HTTPS IPv6 transition tunnel. This occurs when the DirectAccess server or an Application Delivery Controller (ADC) is configured to perform client certificate authentication for IP-HTTPS connections. The client may fail to authenticate if it does not have a valid certificate issued by the organization’s internal certification authority (CA) or if the DirectAccess server or ADC is configured to perform IP-HTTPS client authentication incorrectly.

To resolve this issue, ensure that a valid certificate is installed on the DirectAccess client. In addition, ensure that the DirectAccess server or ADC is configured to use the correct CA when authenticating clients establishing IP-HTTPS connections.

Additional Information

DirectAccess IP-HTTPS Preauthentication 

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

DirectAccess SSL Offload and IP-HTTPS preauthentication using Citrix NetScaler 

DirectAccess IP-HTTPS preauthentication using F5 BIG-IP 

DirectAccess Now a Supported Workload in Microsoft Azure

DirectAccess Now a Supported Workload in Microsoft Azure

Important Update! Microsoft has recently reversed their decision to support DirectAccess in Microsoft Azure. The Microsoft Server Software Support for Microsoft Azure Vitual Machines document has once again been revised to indicate that DirectAccess is formally unsuported in Azure.

Update: Detailed guidance for deploying DirectAccess in Azure can be found here.

This is great news for organizations moving their infrastructure to the Microsoft Azure public cloud! Microsoft recently made some important changes to their published support statement for server software running on Azure virtual machines. Although no formal announcement was made, they quietly removed DirectAccess from the list of unsupported roles for Windows Server 2012 R2.

DirectAccess Now a Supported Workload in Microsoft Azure

I’ve performed some limited testing with DirectAccess using Resource Manager VMs in Microsoft Azure and it appears to be stable. In addition, some of the challenges I encountered previously when implementing DirectAccess in Azure using Classic VMs have now been resolved. I’ll be publishing some guidance for deploying DirectAccess in Azure soon.

Additional Resources

Deploying DirectAccess in Microsoft Azure
Implementing DirectAccess in Windows Server 2016
Fundamentals of Microsoft Azure 2nd Edition
Microsoft Azure Security Infrastructure
DirectAccess Multisite with Azure Traffic Manager

SSH Administration over a DirectAccess Connection

SSH Administration over a DirectAccess ConnectionFrom a client perspective, DirectAccess is an IPv6 only solution. All communication between the DirectAccess client and server takes place exclusively over IPv6. This can make things challenging for network engineers tasked with administering network devices using SSH over a DirectAccess connection. Often network devices don’t have corresponding hostname entries in DNS, and attempting to connect directly to an IPv4 address over a DirectAccess connection will fail.

To resolve this issue, it is necessary to create internal DNS records that resolve to IPv4 addresses for each network device. With that, the DNS64 service on the DirectAccess server will create an IPv6 address for the DirectAccess client to use. The NAT64 service will then translate this IPv6 address to IPv4 and connectivity will be established.

However, for many large organizations this might not be feasible. You may have hundreds or thousands of devices on your network to administer, and creating records in DNS for all these devices will take some time. As a temporary workaround, it is possible to determine the NAT64 IPv6 address for any network device and use that for remote network administration.

The process is simple. On a client that is connected remotely via DirectAccess, resolve the name of a known internal server to an IP address. The quickest and easiest way to do that is simply to ping an internal server by its hostname and note the IPv6 address it resolves to.

SSH Administration over a DirectAccess Connection

Now copy the first 96 bits of that address (everything up to and including the 7777::) and then append the IPv4 address of the network device you wish to manage in familiar dotted-decimal notation. The IPv6 address you create should look something like this:

fd74:45f9:4fae:7777::172.16.1.254

Enter this IPv6 address in whichever tool you use to manage your network devices and it should work. Here’s an example using the popular Putty tool connecting via SSH to a network device in my lab.

SSH Administration over a DirectAccess Connection

Figure 1 – DirectAccess Client IPv6 Prefix w/Appended IPv4 Address

SSH Administration over a DirectAccess Connection

Figure 2 – Successful connection over DirectAccess with Putty.

Going forward I would strongly recommend that you make it part of your normal production implementation process and procedures to create DNS records for all network devices. In the future you’ll absolutely have to do this for IPv6, so now is a good time to get in the habit of doing this. It will make your life a lot easier, trust me!

Please note that adding entries to the local HOSTS file of a DirectAccess client does not work! The name must be resolved by the DNS64 service on the DirectAccess server in order to work properly. Although you could populate the local HOSTS file with names and IPv6 addresses using the method I described above, it would cause problems when the client was on the internal network or connected remotely using traditional client-based VPN, so it is best to avoid using the HOSTS file altogether.

DirectAccess and Windows Server 2012 R2 Core

Important Note: The ability to switch back and forth between the full GUI and core versions of Windows was removed from Windows Server 2016. If you are deploying DirectAccess on Windows Server 2016, you must install server core initially. More details here.

DirectAccess and Windows Server 2012 R2 Core

Windows Server Core is an operating system configuration option that does not include a Graphical User Interface (GUI). Server Core was first introduced with Windows Server 2008 and originally included only a limited number of supported roles. With each subsequent release, Microsoft continues to add support for additional roles on Server Core. Beginning with Windows Server 2012, the Routing and Remote Access (RRAS) role, which includes DirectAccess, is a supported workload on Server Core.

Advantages of Server Core

There are a number of important advantages that come with running DirectAccess on Server Core. Server Core has a greatly reduced attack surface compared to the full GUI version, which is positive from a security perspective. Server Core also features a dramatically reduced footprint, consuming less RAM and disk space. System startup times are faster, and this refactored installation option also reduces servicing requirements (patching), eliminating many reboots and increasing availability and overall system uptime.

DirectAccess and Windows Server 2012 R2 Core

Figure 1 – Windows Server 2012 R2 Core Desktop (Yes, that’s it!)

Server Core Configuration

DirectAccess is a workload that lends itself well to running on Server Core, and I highly recommend leveraging this configuration whenever possible. Based on my experience, I suggest performing initial configuration and testing of the DirectAccess solution with the GUI installed, and then removing the GUI just before placing the DirectAccess server in to production. Removing the GUI can be accomplished by executing the following PowerShell command:

Remove-WindowsFeature Server-Gui-Mgmt-Infra –Restart

Once the server has been converted to Server Core, all administration must be performed at the command line on the server, or remotely from a management server or workstation using the command line or GUI administration tools. You can install the Remote Access Management console on any Windows Server 2012 R2 server using the following PowerShell command:

Install-WindowsFeature RSAT-RemoteAccess

Optionally you can download and install the Windows Server Remote Administrations Tools (RSAT) on a Windows client workstation, if desired.

Minimal Server Interface Configuration

If you prefer to be able to manage the DirectAccess server locally using the GUI, consider enabling the Minimal Server Interface. Minimal Server Interface is a configuration option that lies between Server Core and the full GUI interface. It features some of the benefits of Server Core, while at the same time providing local access to GUI management tools such as the Remote Access Management console. You can configure Minimal Server Interface using the following PowerShell command:

Remove-WindowsFeature Server-Gui-Shell -Restart

You can access the Remote Access Management console by entering RaMgmtUI.exe from the command line.

Revert to Full GUI

If at any point in the future you require the GUI for some reason, re-installing it can be accomplished using the following PowerShell command:

Install-WindowsFeature Server-Gui-Shell –Restart

Summary

With the Unified Remote Access role supported on Windows Server Core, consider implementing DirectAccess using this option to improve the security and increase the availability of your remote access solution. You’ll find that almost all ongoing server maintenance and support can be accomplished remotely using GUI tools, or locally using PowerShell. And if you ever need the GUI again, you can always add it back if necessary!

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 Manage Out from Windows 10 Does Not Work

Note: The issue described in this article has been resolved in Windows 10 version 1703 (Creators Update). Making these changes is no longer required after installing the Creators Update release of Windows 10.

For DirectAccess manage out deployments using ISATAP, you may encounter a scenario in which you are unable to initiate outbound connections to connected DirectAccess clients from a Windows 10 computer. Outbound connections using ISATAP from Windows 7, Windows 8, Windows Server 2008/R2, or Windows Server 2012/R2 systems work without issue.

DirectAccess Manage Out from Windows 10 Does Not Work

As it turns out, there is a bug in the Windows 10 DNS client code that prevents manage out using ISATAP from a Windows 10 client from working correctly. Thanks to the diligent effort of DirectAccess administrators Mike Piron and Jason Kuhns, a workaround has been identified. To deploy the workaround, it will be necessary to implement registry changes to alter the default behavior of the DNS resolver in Windows 10. You can implement these changes on a Windows 10 DirectAccess manage out machine by using the following PowerShell commands:

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableParallelAandAAAA -PropertyType dword -Value 1 -Force

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableServerUnreachability -PropertyType dword -Value 1 –Force

Once these registry changes have been made, you should now be able to use ISATAP for DirectAccess manage out connections from a Windows 10 machine.

Enterprise Nirvana with Surface Pro 4, Windows 10, and DirectAccess

Introduction

DirectAccess and Windows 10 - Better Together

The Microsoft Surface Pro 4 was made available for sale to the public on October 26, 2015. The latest in a line of powerful and flexible tablets from Microsoft, the Surface Pro 4 features a full version of the Windows 10 desktop client operating system and includes more available power, memory, and storage than previous editions. Significant improvements were also made to the keyboard and pen. The Surface Pro 4 is designed to be an all-in-one laptop replacement, enabling users to carry a single device for all of their needs.

Surface Pro 4 and the Enterprise

Microsoft is pushing the Surface Pro 4 heavily to large enterprise organizations by expanding the resale business channel and offering the device through companies like Dell and HP. In fact, Microsoft has made the Surface Pro 4 available through more than 5000 business resellers in 30 global markets. This new enterprise sales initiative strives to deliver world class service and support for enterprise customers adopting the new Surface Pro 4, and includes a new warranty offer and a business device trade-in program designed to promote the adoption of Surface and Windows 10 in the enterprise.

Enterprise Nirvana with Surface Pro 4, Windows 10, and DirectAccess

In addition, Microsoft will have a training program for IT management and support professionals as well as new Windows users that will help streamline the deployment of the Surface Pro 4 and Windows 10. Organizations are rapidly adopting the Surface Pro 4 and Windows 10, as Microsoft has already signed on a number of high-profile companies in the retail, financial services, education, and public sector verticals. Today, Microsoft has deployed Windows 10 to over 110 million devices since it was released in late October 2015, making it the most rapidly adopted operating system in their history.

Enterprise Requirements

One of the primary motivating factors for enterprise organizations migrating to the Surface Pro 4 is cost reduction. The Surface Pro 4 functions as both a full PC and a tablet, eliminating the need for users to carry two devices. More importantly, it eliminates the need for IT to procure, manage, and support two different hardware and software platforms (for example a Windows-based laptop and an iPad). Additionally, IT organizations can leverage their existing Windows systems management infrastructure and expertise to deploy and maintain their Surface devices.

DirectAccess and the Surface Pro 4

For organizations seeking to maximize their investment in the Surface Pro 4 with Windows 10, implementing a secure remote access solution using Windows Server 2012 R2 DirectAccess is essential. DirectAccess provides seamless and transparent, always on secure remote corporate network connectivity for managed (domain-joined) Windows clients. DirectAccess enables streamlined access to on-premises application and data, improving end user productivity and reducing help desk costs. DirectAccess connectivity is bi-directional, making possible new and compelling management scenarios for field-based assets. DirectAccess clients can be managed the same way, regardless if they are inside or outside of the corporate network. DirectAccess ensures that clients are better managed, consistently maintained, and fully monitored.

Enterprise Nirvana with Surface Pro 4, Windows 10, and DirectAccess

Windows 10 and DirectAccess

The Surface Pro 4 with Windows 10 provides full support for all enterprise features of DirectAccess in Windows Server 2012 R2, including automatic site selection and transparent fail over for multisite deployments, as well as scalability and performance improvements. In addition, supportability for Windows 10 clients is much improved with DirectAccess GUI integration and full PowerShell support. Additional information about how DirectAccess and Windows 10 are better together, click here.

Additional Cost Savings

Enterprise Nirvana with Surface Pro 4, Windows 10, and DirectAccess

DirectAccess does not require any additional software to be installed on the client, and does not incur per user licensing to implement. Another benefit is that DirectAccess can easily be deployed on most popular hypervisors such as Hyper-V and VMware, eliminating the need for expensive proprietary hardware-based remote access solutions and taking full advantage of current investments in virtual infrastructure. Additionally, existing Windows systems management skill sets can be leveraged to support a DirectAccess implementation, eliminating the need for expensive dedicated administrators.

Note: Windows 10 Enterprise edition is required to support DirectAccess, and it is assumed that large organizations will be deploying Surface Pro 4 with Windows 10 Enterprise.

Summary

The Surface Pro 4 is the thinnest, lightest, and most powerful Surface tablet ever. It features Windows 10, and it can run the full version of Office and any other applications you need. The Surface Pro 4 is aimed squarely at large enterprises, governments, and schools. Not coincidentally, these verticals are also excellent uses cases for DirectAccess. DirectAccess is the perfect complement to the Surface Pro 4 and Windows 10 in the enterprise, as it helps organizations address the unique pain points of large scale enterprise adoption of Windows devices. DirectAccess allows the Surface Pro 4 to be much more effectively managed, while at the same time significantly improving the end user experience.

To realize the full potential of your Windows 10 and Surface Pro 4 deployment, consider a DirectAccess consulting engagement. By leveraging our experience you’ll have the peace of mind knowing that you have deployed DirectAccess in the most optimal, flexible, secure, and highly available manner possible. For more information about a DirectAccess consulting engagement, click 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

DirectAccess and VPN on RunAs Radio

DirectAccess and Windows Server 2012 R2 on RunAs RadioRecently I had the opportunity to once again join Richard Campbell on his popular RunAs Radio podcast to chat about all things remote access in Windows Server 2012 R2. The conversation starts out with DirectAccess, but we also touch upon important topics like client-based VPN and BYOD access. We also talk a little bit about DirectAccess in Windows Server 2016 and what the future might look like for DirectAccess in Windows.RunAs Radio

You can listen to the podcast here.

Enjoy!

%d bloggers like this: