When 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.
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
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!
DirectAccess 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).
