DirectAccess IP-HTTPS Preauthentication


Introduction

DirectAccess IP-HTTPS PreauthenticationRecently 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

DirectAccess IP-HTTPS Preauthentication

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

DirectAccess IP-HTTPS Preauthentication

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.

Leave a comment

24 Comments

  1. Thorsten Frohberg

     /  June 23, 2016

    Hello Richard, works the IP-HTTPS Preauthentikation directly one the DA Server (without ADC) also together with the OTP-Authentication Feature from DirectAccess ?

    Reply
  2. Joimel D

     /  July 18, 2016

    Hello,
    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

    Reply
    • I 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.

      Reply
      • Joimel D

         /  July 19, 2016

        I 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” .

      • Yes, you would substitute your domain name in those commands. I’ve used my domain name purely as an example.

  3. Thorsten Frohberg

     /  August 8, 2016

    Hello,
    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.

    Reply
  4. Thorsten Frohberg

     /  August 8, 2016

    when 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.

    Reply
    • Thanks 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!

      Reply
  5. Gus

     /  October 21, 2016

    Do you have any information/articles on how to setup IP-HTTPS Pre-authentication using a Kemp Load Balancer?

    Reply
    • No, 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!

      Reply
  6. Stefaan Pouseele

     /  December 23, 2016

    In 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?

    Reply
    • Hi 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. 🙂

      Reply
  7. Don Young

     /  February 24, 2017

    I 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?

    Reply
    • Don Young

       /  February 24, 2017

      Whoops: Commands:
      netsh http add sslcert ipport=0.0.0.0:443 certhash=[ my hash] appid=”{5d8e2743-ef20-4d38-8751-7e400f200e65}” dsmapperusage=enable clientcertnegotiation=enable

      Reply
  8. Don Young

     /  February 24, 2017

    Oh, crap. I was using PowerShell – that explained needing the quotes, but I still get the IP-HTTPS listener error.

    Reply
  9. Don Young

     /  February 27, 2017

    More 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.

    Reply
    • Unusual. 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.

      Reply
  1. DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP | Richard Hicks' DirectAccess Blog
  2. DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler | Richard Hicks' DirectAccess Blog
  3. DirectAccess IP-HTTPS Error 0x2af9 | Richard Hicks' DirectAccess Blog
  4. Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320 | Richard Hicks' DirectAccess Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: