DirectAccess Troubleshooting with Nmap

DirectAccess IP-HTTPS Discovery Script for NmapDirectAccess troubleshooting can be made much easier using open source tools such as Nmap. Nmap can be used to perform many essential network connectivity and configuration checks, including validating network paths, confirming DirectAccess server response, and viewing SSL configuration. Nmap can also be used to ensure that the attack surface of the DirectAccess server is properly minimized. Some tests can be performed using only native Nmap functionality, while others require the use of specialized Nmap scripts that are included with the tool.

Installation

Nmap can be installed on a wide variety of operating systems, including Windows. If you plan to install Nmap on Windows, be sure to also install WinPcap and the Microsoft Visual C++ 2013 Redistributable. Both are included in the download.

Testing External Connectivity

Validating external connectivity is often one of the first DirectAccess troubleshooting steps I take. Confirm that the DirectAccess public hostname resolves to the correct IP address, then run the following Nmap command to validate network connectivity from the Internet to the DirectAccess server.

nmap -n -Pn -p443 <da_public_hostname>

DirectAccess Troubleshooting with Nmap

If the hostname resolves correctly and the network path is complete, the server should respond and Nmap will show the port as open. However, this doesn’t necessarily mean that the DirectAccess server is the device that replied! Due to misconfiguration, it is possible that another server or network device listening on TCP port 443 responded, so this is not a conclusive test.

DirectAccess Server Response

To confirm the DirectAccess server is responding to HTTPS requests and not some other server or device, run the following Nmap command with the ip-https-discover script.

nmap -n -Pn -p443 <da_public_hostname> –script ip-https-discover

If the DirectAccess server responds to the request, Nmap will return the following message:

IP-HTTPS is supported. This indicates that this host supports Microsoft DirectAccess.

DirectAccess Troubleshooting with Nmap

If the port is open but the script does not return this message, it is likely that another server or device is responding on TCP port 443, not the DirectAccess server.

Note: If an Application Delivery Controller (ADC) is configured to perform IP-HTTPS preauthentication, the Nmap IP-HTTPS discovery script will not return this result. This is expected and by design.

SSL Certificate Validation

It is not uncommon for DirectAccess clients to fail to connect via IP-HTTPS because of SSL certificate issues. Specifically, an SSL certificate that is not trusted, is expired, or its subject field does not match the public hostname will prevent DirectAccess clients from connecting. To view the SSL certificate configuration of a DirectAccess server, run the following Nmap command with the ssl-cert script.

nmap -n -Pn -p443 <da_public_hostname> –script ssl-cert

DirectAccess Troubleshooting with Nmap

SSL Cipher Suite Configuration

Occasionally there can be issues with the SSL configuration on the DirectAccess server that prevent some clients from connecting, or result in poor performance. This commonly occurs when administrators perform SSL hardening on the DirectAccess server and remove support for null cipher suites. Null cipher suites should never be disabled on the DirectAccess server. They are important to ensure the highest levels of performance for Windows 8.x and Windows 10 clients. Also, if an Application Delivery Controller (ADC) or load balancer is performing SSL offload, lack of support for null cipher suites will prevent Windows 8.x and Windows 10 clients from connecting. To determine if the DirectAccess server supports null cipher suites, run the following Nmap command with the ssl-enum-ciphers script.

nmap -n -Pn -p443 <da_public_hostname> –script ssl-enum-ciphers

DirectAccess Troubleshooting with Nmap

Attack Surface Audit

If DirectAccess implementation and security best practices are followed, the DirectAccess server will be behind an edge firewall. The only port required to be allowed inbound for DirectAccess is TCP port 443. It is recommended that a full port scan be performed against the DirectAccess server’s public IPv4 address to identify any unnecessary ports that may be open externally. To perform a full port scan, run the following Nmap command.

nmap -n -Pn -p- <da_public_hostname>

Ideally it should look like this.

DirectAccess Troubleshooting with Nmap

If it looks something like this, you’re in serious trouble!

DirectAccess Troubleshooting with Nmap

The DirectAccess server should never be listening for requests other that HTTPS on the public Internet. Exposing services such as SMB (TCP port 445), RDP (TCP port 3389), and others presents a significant security risk. It is recommended that edge firewalls be configured to allow inbound TCP port 443 only. If the DirectAccess server is connected directly to the public Internet (not recommended!) then the Windows Firewall should be configured to restrict access to inbound TCP port 443 only.

Additional Resources

DirectAccess IP-HTTPS Discovery Script for Nmap
Planning and Implementing DirectAccess with Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book
DirectAccess Troubleshooting and Consulting Services

Deploying DirectAccess in Microsoft Azure

Introduction

DirectAccess Now a Supported Workload in Microsoft AzureMany organizations are preparing to implement DirectAccess on Microsoft’s public cloud infrastructure. Deploying DirectAccess in Azure is fundamentally no different than implementing it on premises, with a few important exceptions (see below). This article provides essential guidance for administrators to configure this unique workload in Azure.

Important Note: There has been much confusion regarding the supportability of DirectAccess in Azure. Historically it has not been supported. Recently, it appeared briefly that Microsoft reversed their earlier decision and was in fact going to support it. However, the Microsoft Server Software Suport for Microsoft Azure Virtual Machines document has once again been revised to indicate that DirectAccess is indeed no longer formally supported on Azure. More details can be found here.

Azure Configuration

The following is guidance for configuring network interfaces, IP address assignments, public DNS, and network security groups for deploying DirectAccess in Azure.

Virtual Machine

Deploy a virtual machine in Azure with sufficient resources to meet expected demand. A minimum of two CPU cores should be provisioned. A VM with 4 cores is recommended. Premium storage on SSD is optional, as DirectAccess is not a disk intensive workload.

Network Interfaces

It is recommended that an Azure VM with a single network interface be provisioned for the DirectAccess role. This differs from on-premises deployments where two network interfaces are preferred because deploying VMs in Azure with two NICs is prohibitively difficult. At the time of this writing, Azure VMs with multiple network interfaces can only be provisioned using PowerShell, Azure CLI, or resource manager templates. In addition, Azure VMs with multiple NICs cannot belong to the same resource group as other VMs. Finally, and perhaps most importantly, not all Azure VMs support multiple NICs.

Internal IP Address

Static IP address assignment is recommended for the DirectAccess VM in Azure. By default, Azure VMs are initially provisioned using dynamic IP addresses, so this change must be made after the VM has been provisioned. To assign a static internal IP address to an Azure VM, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network Interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click IP configurations.
  6. Click Ipconfig1.
  7. In the Private IP address settings section choose Static for the assignment method.
  8. Enter an IP address for the VM.
  9. Click Save.

Deploying DirectAccess in Microsoft Azure

Public IP Address

The DirectAccess VM in Azure must have a public IP address assigned to it to allow remote client connectivity. To assign a public IP address to an Azure VM, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network Interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click IP configurations.
  6. Click Ipconfig1.
  7. In the Public IP address settings section click Enabled.
  8. Click Configure required settings.
  9. Click Create New and provide a descriptive name for the public IP address.
  10. Choose an address assignment method.
  11. Click Ok and Save.

Deploying DirectAccess in Microsoft Azure

Deploying DirectAccess in Microsoft Azure

Public DNS

If the static IP address assignment method was chosen for the public IP address, create an A resource record in public DNS that resolves to this address. If the dynamic IP address assignment method was chosen, create a CNAME record in public DNS that maps to the public hostname for the DirectAccess server. To assign a public hostname to the VM in Azure, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Overview.
  4. Click Public IP address/DNS name label.Deploying DirectAccess in Microsoft Azure
  5. Under Settings click Configuration.
  6. Choose an assignment method (static or dynamic).
  7. Enter a DNS name label.
  8. Click Save.

Deploying DirectAccess in Microsoft Azure

Note: The subject of the SSL certificate used for the DirectAccess IP-HTTPS listener must match the name of the public DNS record (A or CNAME) entered previously. The SSL certificate does not need to match the Azure DNS name label entered here.

Network Security Group

A network security group must be configured to allow IP-HTTPS traffic inbound to the DirectAccess server on the public IP address. To make the required changes to the network security group, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click Network security group.
  6. Click the network security group assigned to the network interface.
  7. Click Inbound security rules.
  8. Click Add and provide a descriptive name for the new rule.
  9. Click Any for Source.
  10. From the Service drop-down list choose HTTPS.
  11. Click Allow for Action.
  12. Click Ok.

Deploying DirectAccess in Microsoft Azure

Note: It is recommended that the default-allow-rdp rule be removed if it is not needed. At a minimum, scope the rule to allow RDP only from trusted hosts and/or networks.

DirectAccess Configuration

When performing the initial configuration of DirectAccess using the Remote Access Management console, the administrator will encounter the following warning message.

“One or more network adapters should be configured with a static IP address. Obtain a static address and assign it to the adapter.”

Deploying DirectAccess in Microsoft Azure

This message can safely be ignored because Azure infrastructure handles all IP address assignment for hosted VMs.

The public name of the DirectAccess server entered in the Remote Access Management console must resolve to the public IP address assigned to the Azure VM, as described previously.

Deploying DirectAccess in Microsoft Azure

Additional Considerations

When deploying DirectAccess in Azure, the following limitations should be considered.

Load Balancing

It is not possible to enable load balancing using Windows Network Load Balancing (NLB) or an external load balancer. Enabling load balancing for DirectAccess requires changing static IP address assignments in the Windows operating system directly, which is not supported in Azure. This is because IP addresses are assigned dynamically in Azure, even when the option to use static IP address assignment is chosen in the Azure management portal. Static IP address assignment for Azure virtual machines are functionally similar to using DHCP reservations on premises.

Deploying DirectAccess in Microsoft Azure

Note: Technically speaking, the DirectAccess server in Azure could be placed behind a third-party external load balancer for the purposes of performing SSL offload or IP-HTTPS preauthentication, as outlined here and here. However, load balancing cannot be enabled in the Remote Access Management console and only a single DirectAccess server per entry point can be deployed.

Manage Out

DirectAccess manage out using native IPv6 or ISATAP is not supported in Azure. At the time of this writing, Azure does not support IPv6 addressing for Azure VMs. In addition, ISATAP does not work due to limitations imposed by the underlying Azure network infrastructure.

Summary

For organizations moving infrastructure to Microsoft’s public cloud, formal support for the DirectAccess workload in Azure is welcome news. Implementing DirectAccess in Azure is similar to on-premises with a few crucial limitations. By following the guidelines outlined in this article, administrators can configure DirectAccess in Azure to meet their secure remote access needs with a minimum of trouble.

Additional Resources

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

DirectAccess IP-HTTPS Discovery Script for Nmap

DirectAccess IP-HTTPS Discovery Script for NmapWhen troubleshooting DirectAccess connectivity issues, the popular Nmap network mapping and discovery tool is an invaluable resource for verifying the communication path to the DirectAccess server from outside the network. However, just verifying that ports are open and listening often isn’t sufficient. In the case of IP-HTTPS, for example, the tried and true method of using telnet to verify that the port is open might be misleading. For instance, telnet might indicate that TCP port 443 is open and responding, but DirectAccess connectivity can still fail. This often happens as a result of a network configuration error that allows another network device other than the DirectAccess server to respond to HTTPS requests, which results in a false positive.

In an effort to conclusively determine that the DirectAccess server is responding, I’ve often relied on the SSL Labs Server Test site. Here I will enter the DirectAccess server’s public hostname and run the test, and from the results I can easily determine if indeed the DirectAccess server is responding by verifying that the HTTP server signature is Microsoft-HTTPAPI/2.0.

DirectAccess IP-HTTPS Discovery Script for NMAP

This usually works well, but it takes a few minutes to run the test, and there are a few scenarios in which it doesn’t work. For example, I might be working with a customer to perform some initial testing by using a local HOSTS file entry for the public name before the DNS record has been created. Also, if the SSL certificate on the DirectAccess server uses an IP address instead of a hostname (not recommended, but it is supported!) the SSL Labs server test won’t work.

Fortunately, the latest release Nmap (v7.00) now includes a script that enables the detection of Microsoft DirectAccess responding on TCP port 443. With the IP-HTTPS discovery script, it is now possible to determine not only if the port is open, but if the DirectAccess server is actually the service responding. The syntax for conducting a port scan using the IP-HTTPS discovery script for NMAP is as follows:

nmap.exe –n –Pn –p443 [directaccess_public_fqdn] –script [path_to_nmap_iphttps_discovery_script]

Here’s an example:

nmap.exe –n –Pn –p443 da.richardhicks.net –script c:\tools\nmap\scripts\ip-https-discover.nse

DirectAccess IP-HTTPS Discovery Script for NMAP

Now it is possible, using just Nmap, to not only determine if the IP-HTTPS communication path is functioning, but to definitively determine that the DirectAccess server is the device responding.

Happy troubleshooting!

%d bloggers like this: