Microsoft DirectAccess is an extremely secure method for connecting your domain-joined workstations back to the corporate network whenever those machines have Internet access. Whether at home, a hotel, or a coffee shop – the beauty of DA is that it automatically connects from anywhere, without users needing to launch any kind of manual connection.
Since these remote connections are coming in from the public Internet, it makes sense that your DirectAccess server needs to sit at or near the edge of your network. There are a few different ways that DA servers can be linked back to the Internet, but in any installation you will at the very minimum be allowing TCP port 443 to flow inbound to your DA server, in order to allow DirectAccess connections to work.
With the DA servers listening on port 443, that automatically makes security scanners (and humans) believe that they are hosting website traffic. This means that when pen testers are hired to help companies discover their vulnerabilities, DirectAccess servers are always identified and scanned as if they were web servers. Qualys is an extremely common scanning tool used to gain a quick health status of web servers, and so your DA servers are bound to come back in a report from Qualys. That report will likely show an “F” rating, which is usually a very bad thing. Let’s take a minute and discuss the reasons why this rating really means nothing in the DirectAccess world, and that it can be safely ignored. In fact, from a DirectAccess best practices and efficiency standpoint, the F rating probably means your DA server is running well!
All DirectAccess traffic rides inside heavily encrypted IPsec tunnels. Let me say that again – ALL DirectAccess traffic always flows inside IPsec. These IPsec tunnels are based upon IPv6, however, and so they won’t flow naturally over the IPv4 Internet. In order to get our IPsec tunnels connecting between client and server, DirectAccess utilizes IPv6 transition tunneling technologies to encapsulate the IPsec flow and get it connected over the Internet. This encapsulation is the role of the three transition tunneling technologies that work with DirectAccess.
These tunneling technologies are called 6to4, Teredo, and IP-HTTPS. In many DirectAccess installation scenarios, IP-HTTPS is the only protocol that is used. IP-HTTPS is essentially HTTPS traffic, negotiated between the DirectAccess client and the DirectAccess server. What is IP-HTTPS’s purpose? Once again, it is simply to carry the already-encrypted IPsec tunnels to the server.
Since all DA traffic is already IPsec encrypted, requiring encryption on the IP-HTTPS tunneled stream is redundant and inefficient. This was the case with Windows 7 clients, who would always double-encrypt all traffic when they were connected via IP-HTTPS. This slowed down the DirectAccess connections, and increased load on the DA server because it was doing double-duty when decrypting all of those packets. Starting with Windows 8, Microsoft enabled IP-HTTPS to be able to negotiate its own tunnel via NULL. This effectively brought it on par with Teredo and 6to4 in terms of performance, since those transition technologies are also responsible for transporting the DA IPsec tunnels, but do so in a way that is non-encrypted.
The only reason that DirectAccess servers show up on security scanners like Qualys is because IP-HTTPS looks like it is an HTTPS website (listening on port 443), and those scanners effectively peg it as a web server. A DirectAccess server is not a web server. There are no websites hosted on here, and no credentials or sensitive information passes within IP-HTTPS, except for those DirectAccess tunnels which are already IPsec protected.
Ultimately, any other poor results that show up on the scanner are also inconsequential for this same reason. There will never be a website connection to this DA server that could result in confidential information being passed over that HTTPS stream, and so the scanner can tell you all day long that it’s unhappy about RSA RC4, TLS1.0, etc – but in the end none of this matters. I mean think about it – if you’re already allowing NULL to be negotiated between client and server, why in the world would you care about TLS1.0??
While it is possible to disable the NULL ciphers (and others) on a DirectAccess server, it is not recommended. This would make the vulnerability scanners happier, but without any actual enhancement of security on the traffic stream. What it would do, however, is slow down DirectAccess connections and increase the load on the DA servers, lowering their capacity and creating a lesser user experience for the connection.
Most commonly when companies receive these F rating results (after the initial shock and then learning the correct information about why this happens), they set the DA servers as exclusions to future scanning processes. Allowing IP-HTTPS to negotiate the insecure cipher suites is what it is designed to do, allowing DA to run most efficiently, and still very securely.
Microsoft MVP | Enterprise Security