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!
Stuart Hawkins
/ February 6, 2016Hi Richard,
I can’t get my DirectAccess working. I’ve just followed through this and when running the NMAP script I get;
Starting Nmap 7.01 ( https://nmap.org ) at 2016-02-06 19:06 GMT Standard Time
Nmap scan report for da.debenhamhighschool.suffolk.sch.uk (85.12.76.8)
Host is up (0.031s latency).
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 9.04 seconds
DirectAccess never connects. I also ran the DAClientTroubleshooter and that gives me red crosses for Certificate Tests (No usable machine certificate found), Infrastructure Tunnel Tests (Failed to connect to domain sysvol share) and User Tunnel Tests (Failed to connect to HTTP probe at http://directaccess-WebProbeHost.*internaldomain*)
Where do I go from here please?
Very helpful site.
Thank you
Stuart Hawkins
Richard M. Hicks
/ February 6, 2016I’ll need more information from your environment to provide assistance. Can you send me an email and I’ll let you know what I need?
Andriy Kotnyuk
/ February 15, 2016Hi Richard,
I have number of examples when the HTTPS service has been identified by SSL Labs as:
HTTP server signature Microsoft-IIS/8.5
And this was actually a DirectAccess IPHTTPS service.
So the requirement to have Microsoft-HTTPAPI/2.0 there might not be very correct.
Andriy
Richard M. Hicks
/ February 15, 2016I’ve come across a few occasions where the tool would incorrectly report the existence of IP-HTTPS too. I’m still investigating and will update this post if I find out what that is happening. Until then, the output of the script shouldn’t be taken as gospel. 🙂
Steve
/ April 27, 2021Hey Richard
Is there an update to this article?
I get as a result like Stuart Hawkins. The DAClientTroubleshooter seems to stop working on Windows 10. Maybe you have an update for this too.
Richard M. Hicks
/ May 3, 2021Nmap has been updated, certainly, but that’s about it. When you use the syntax in this post you should see that Nmap connects and that it reports DirectAccess is supported. Do you get both of those?