DirectAccess IP-HTTPS Discovery Script for Nmap

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:

5 Comments

Stuart Hawkins

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

Andriy Kotnyuk

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.

I’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. 🙂