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 

SSL Certificate Considerations for DirectAccess IP-HTTPS 

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