Introduction
Mitigation
The best way to mitigate these security risks is to implement an Application Delivery Controller (ADC) such as the F5 BIG-IP Local Traffic Manager or the Citrix NetScaler. I’ve documented how to configure those platforms here and here.
No ADC?
For those organizations that do not have a capable ADC deployed, it is possible to configure the IP-HTTPS listener on the Windows Server 2012 R2 server itself to perform preauthentication.
Important Note: Making the following changes on the DirectAccess server is not formally supported. Also, this change is incompatible with one-time passwords (OTP) and should not be performed if strong user authentication is enabled. In addition, null cipher suites will be disabled, resulting in reduced scalability and degraded performance for Windows 8.x and Windows 10 clients. Making this change should only be done if a suitable ADC is not available.
Configure IP-HTTPS Preauthentication
To configure the DirectAccess server to perform preauthentication for IP-HTTPS connections, open an elevated PowerShell command window and enter the following command.
ls Cert:\LocalMachine\My
Copy the thumbprint that belongs to the SSL certificate assigned to the IP-HTTPS listener. Open an elevated command prompt window (not a PowerShell window!) and enter the following commands.
netsh http delete sslcert ipport=0.0.0.0:443 netsh http add sslcert ipport=0.0.0.0:443 certhash=[thumbprint] appid={5d8e2743-ef20-4d38-8751-7e400f200e65} dsmapperusage=enable clientcertnegotiation=enable
For load-balanced clusters and multisite deployments, repeat these steps on each DirectAccess server in the cluster and/or enterprise.
Summary
Once these changes have been made, only DirectAccess clients that have a computer certificate with a subject name that matches the name of its computer account in Active Directory will be allowed to establish an IP-HTTPS transition tunnel connection.