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.

DirectAccess IP-HTTPS Null Encryption and SSTP VPN

An important scalability improvement introduced in Windows Server 2012 DirectAccess is the support for null encryption for Windows 8.x DirectAccess clients using the IP-HTTPS IPv6 transition protocol. Using null encryption eliminates the overhead imposed by the needless encryption of DirectAccess IPsec communication, which itself is already encrypted. This double encryption significantly increases resource consumption on both the client and server, and can have a negative impact on scalability and performance. When a Windows 8.x client establishes an IP-HTTPS connection to a Windows Server 2012 or 2012 R2 DirectAccess server, it will negotiate only cipher suites that use null encryption. Windows 7 clients cannot take advantage of null encryption and continue to use encrypted cipher suites.

Note: It is possible to replicate some of the benefits of null encryption for Windows 7 clients using an Application Delivery Controller (ADC) such as the F5 Networks Local Traffic manager (LTM) to perform SSL offloading. See SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP for more information.

For both performance and scalability, the best deployment results are achieved when using a Windows Server 2012 or 2012 R2 DirectAccess server and Windows 8.x clients. However, null encryption for IP-HTTPS is no longer available in the scenario where client-based remote access VPN is configured on the same server as DirectAccess. As you can see below, when DirectAccess is deployed by itself, the server offers null encryption cipher suites which Windows 8.x clients can take advantage of.

DirectAccess IP-HTTPS Null Encryption and SSTP VPN

Figure 1 – Cipher Suites for DirectAccess Only

However, when the client-based remote access VPN role is enabled on the same DirectAccess server, null encryption cipher suites are no longer available for use by DirectAccess clients.

DirectAccess IP-HTTPS Null Encryption and SSTP VPN

Figure 2- Cipher Suites for DirectAccess and VPN

This occurs because the Secure Sockets Tunneling Protocol (SSTP) client-based remote access VPN protocol requires SSL/TLS encryption to provide confidentiality for tunneled network communication. Unfortunately, disabling support for SSTP alone does not return null encryption cipher suites for DirectAccess clients unless the VPN role is removed completely. Of course none of this is readily apparent to the administrator, who may be completely unaware that they’ve sacrificed the efficiency of IP-HTTPS null encryption for Windows 8.x clients in order to support SSTP for client-based remote access VPN clients.

Note: There are additional scenarios in which null encryption for Windows 8.x DirectAccess clients is not supported. For example, if you enable the Web Application Proxy (WAP) role on the DirectAccess server, or if you configure DirectAccess to use one-time password (OTP) authentication, null encryption support is lost for Windows 8.x clients.

If you plan to support Windows 8.x clients using IP-HTTPS and want to take full advantage of the scalability and performance benefits associated with IP-HTTPS null encryption in Windows Server 2012/R2 DirectAccess, it is recommend that you deploy client-based remote access on a separate system.

Hotfix for Windows 7 DirectAccess Clients

This month Microsoft released an important hotfix to address a DirectAccess connectivity issue for Windows 7 clients connecting to a Windows Server 2012 DirectAccess Server. The hotfix specifically resolves an issue where Windows 7 clients face a very long delay reestablishing a DirectAccess session using the IP-HTTPS IPv6 transition protocol after recently disconnecting from a VPN session. In this scenario, Windows 7 DirectAccess clients may take as long as 15 minutes to automatically reestablish a DirectAccess session using IP-HTTPS. During this time the IP-HTTPS adapter state is displayed as disconnected. Refer to Microsoft KB 2796313 more information and to download the hotfix.

Windows Server 2012 DirectAccess IP-HTTPS and Windows 7 Clients

With Windows Server 2008 R2, IP-HTTPS used standard SSL cipher suites to encrypt sessions. However, those sessions are already encrypted using IPsec, which is needlessly redundant. The protocol overhead for this double encryption placed an extreme burden on the DirectAccess server in terms of CPU utilization and memory consumption. Throughput and performance suffered greatly in large deployments. To address this issue, Microsoft included two new SSL cipher suites in Windows Server 2012 and Windows 8 that use NULL encryption. IP-HTTPS sessions are fully authenticated, but encrypted only once using IPsec. This significantly reduced resource demand on the DirectAccess gateway and improves performance greatly. Unfortunately, only Windows 8 clients can take advantage of this new IP-HTTPS functionality in Windows Server 2012 DirectAccess. When Windows 7 clients establish an IP-HTTPS session with a Windows Server 2012 DirectAccess gateway they will still request the use of fully encrypted cipher suites, as shown here:

Windows 7 IP-HTTPS Client Hello

Windows 7 DirectAccess IPHTTPS Cipher Suites

Windows 8 IP-HTTPS Client Hello

Windows 8 DirectAccess IPHTTPS Cipher Suites

Windows 8.1 IP-HTTPS Client Hello

Windows 8.1 DirectAccess SSL Cipher Suites

So, if you want to take advantage of the IP-HTTPS performance improvements in Windows Server 2012 DirectAccess, be sure to use Windows 8 clients!

Update: Recently with the help of the folks at F5, I developed a solution to emulate Windows 8 client behavior for Windows 7 DirectAccess clients using the F5 BIG-IP Local Traffic Manager (LTM). Using this technique allows you to *effectively* offload SSL for Windows 7 DirectAccess clients. Fore more details click here.

December 2012 Windows Updates and DirectAccess Connectivity Issues

The December 2012 collection of Windows updates included a number of changes that may adversely affect connectivity for DirectAccess clients. The December updates included changes to the Windows Root Certificate store and a hotfix for the IP Helper Service. Either or both of these updates could potentially prevent DirectAccess clients from connecting via the IPHTTPS IPv6 transition protocol. For more information read this post from the Forefront UAG Product Team.

%d bloggers like this: