Introduction
Recently I’ve written about the security challenges with DirectAccess, specifically around the use of the IP-HTTPS IPv6 transition technology. In its default configuration, the DirectAccess server does not authenticate the client when an IP-HTTPS transition tunnel is established. This opens up the possibility of an unauthorized user launching Denial-of-Service (DoS) attacks and potentially performing network reconnaissance using ICMPv6. More details on this can be found here.
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.
Thorsten Frohberg
/ June 23, 2016Hello Richard, works the IP-HTTPS Preauthentikation directly one the DA Server (without ADC) also together with the OTP-Authentication Feature from DirectAccess ?
Richard M. Hicks
/ June 23, 2016Yes, it does. 🙂
Joimel D
/ July 18, 2016Hello,
After test your configuration of preauthentication IP-HTTPS, the listener IP-HTTPS failed in the console access direct.
“The listening service was stopped or is not configured”. What can i do to configure the listener ?
Thanks
Sorry for my poor english
Richard M. Hicks
/ July 18, 2016I can only assume that one of the commands you typed was incorrect. Double-check the commands you ran are exactly as mine in this article. It should work without issue.
Joimel D
/ July 19, 2016I can’t see any error in my commands. It’s important the subject in certificate corresponding to *.richardhicks.net ? Or da.richardnicks.net ? My command “ls Cert:\LocalMachine\My” display “da.domain.com” .
Richard M. Hicks
/ July 20, 2016Yes, you would substitute your domain name in those commands. I’ve used my domain name purely as an example.
Thorsten Frohberg
/ August 8, 2016Hello,
i have the same issue like Joimel (“The listening service was stopped or is not configured”), and after reboot the server the old listener settings are active again.
Thorsten Frohberg
/ August 8, 2016when i use “netsh http show sslcert” before i activate pre-authentication from your guide, then i see ssl certificate binding on ipport 0.0.0.0:443 is the root certificate in the DAOTPtrustedIssuers CtlStore with appid .{4dc3e181-e14b-4a21-b022-59fc669b0914}. When i delete this with “netsh http delete sslcert ipport=0.0.0.0:443” then its break the IP-HTTPS Listener and OTP.
Richard M. Hicks
/ August 8, 2016Thanks for bringing this to my attention. In my initial testing, this appear to work without issue when OTP is enabled. However, upon further investigation it appears that it does not work. As it turns out, when OTP is enabled the Remote Access Management services (ramgmtsvc) overwrites the IP-HTTPS listener configuration which ultimately breaks OTP authentication and potentially the listener itself. I’ll update the post to reflect this information now. Apologies for the inconvenience!
Gus
/ October 21, 2016Do you have any information/articles on how to setup IP-HTTPS Pre-authentication using a Kemp Load Balancer?
Richard M. Hicks
/ October 24, 2016No, not at this time. As of now, the KEMP LoadMaster does not support this configuration. I’ve asked the team at KEMP to make some changes to their solution to do this, but I don’t know when those changes will be implemented in the product. If/when it does support it, I will publish documentation for it.
Thanks!
Stefaan Pouseele
/ December 23, 2016In your book “Implementing DirectAccess with Windows Server 2016, Appendix C – DirectAccess Security Hardening” you talk also about IP-HTTPS preauthentication. However you don’t mention that the null cipher suites will be disabled. Is that a change in behavior with the 2016 DirectAccess implementation?
Richard M. Hicks
/ December 23, 2016Hi Stefaan. Thanks for bringing that to my attention. That was an oversight on my part. The behavior does not change in Windows Server 2016. Enabling IP-HTTPS preauthentication on the DirectAccess server itself will remove support for null cipher suites. Because of that it is recommended that this only be performed when supporting Windows 7 clients exclusively. Of course the best way to perform IP-HTTPS preauthentication is to use a proper application delivery controller (ADC) such as the F5 Big IP or Citrix NetScaler. 🙂
Don Young
/ February 24, 2017I too am having issues enabling IP-HTTPS pre-auth. My commands have been verified, (copied and pasted from here, since I can’t do that from my book) – First I get an error id I don’t put the AppID in quotes (no biggie), and then I get an IP-HTTPS Listener state error, until I turn both
clientcertnegotiation and dsmapperusage.
My commands:
netsh http add sslcert ipport=0.0.0.0:443 certhash=[ my hash] “appid={5d8e2743-ef20-4d38-8751-7e400f200e65}” dsmapperusage=enable clientcertnegotiation=enable
Any ideas?
Don Young
/ February 24, 2017Whoops: Commands:
netsh http add sslcert ipport=0.0.0.0:443 certhash=[ my hash] appid=”{5d8e2743-ef20-4d38-8751-7e400f200e65}” dsmapperusage=enable clientcertnegotiation=enable
Don Young
/ February 24, 2017Oh, crap. I was using PowerShell – that explained needing the quotes, but I still get the IP-HTTPS listener error.
Richard M. Hicks
/ February 27, 2017I was just going to suggest using the command prompt instead of PowerShell. 😉 What is the IP-HTTPS listener error?
Don Young
/ February 27, 2017The Listener service has been stopped, or is not configured.
Don Young
/ February 27, 2017More info: Event ID 10038 – IPHTTPS monitor has gone from HEALTHY state to UNHEALTHY state on 2/27/2017 at 6:00 PM on (server name). The failure heuristic IDs for the state change of IPHTTPS are 80080004.
Richard M. Hicks
/ March 10, 2017Unusual. In my testing I never encountered any issues at all. That doesn’t mean that something isn’t unique in your environment that might be causing a problem though. Reach out to me via email and I’ll try to provide more guidance.
Robin T
/ March 6, 2018Hi Richard,
I’ve just tested this in a development and production environment and yes, client certificate authentication is enabled, but any client certificate will authenticate, trusted or not. Only when there is no certificate is the connection refused. Server 2012R2 and Windows10 clients
Richard M. Hicks
/ March 10, 2018Most interesting. To be honest, I did not conduct a lot of testing with this configuration, mostly because this isn’t the recommended method for performing DirectAccess IP-HTTPS preauthentication. Doing this with an ADC is preferred because they provide much more granularity with regard to client certificate authentication. Thanks for bringing this to my attention though! Definitely good to know. 🙂