DirectAccess IPv6 Support for WorkSite and iManage Work

DirectAccess IPv6 Support for WorkSite and iManage WorkiManage Work (formerly WorkSite) is a popular document management system commonly used in the legal, accounting, and financial services industries. Historically, there have been issues getting WorkSite to function over DirectAccess, because WorkSite used IPv4 addresses and DirectAccess clients use IPv6. When a DirectAccess client is outside of the office, it communicates with the DirectAccess server using IPv6 exclusively, so applications that make calls directly to IPv4 addresses won’t work.

One way DirectAccess administrators could make WorkSite function was to use portproxy to create v4tov6 address and port mappings on the client. However, this method is error prone, difficult to troubleshoot and support, and doesn’t scale effectively.

The good news is that beginning with release 9, the iManage Work client application has been upgraded to support IPv6. However, it is not enabled by default. To enable IPv6 support for iManage Work, add the following registry key on the client side (not the server!). No other changes are required.

HKLM\Software\Wow6432Node\Interwoven\WorkSite\Server Common\

Type: REG_SZ
String: IP Address Family
Value: IPv6

DirectAccess IPv6 Support for WorkSite and iManage Work

You can also use the following PowerShell command to add this registry entry.

New-Item -Path “HKLM:\Software\Wow6432Node\Interwoven\WorkSite\Server Common\” -Force
New-ItemProperty -Path “HKLM:\Software\Wow6432Node\Interwoven\WorkSite\Server Common\”-Name “IP Address Family” -PropertyType String -Value IPv6 -Force

After validation testing is complete, deploy the registry setting via Active Directory group policy preferences to all DirectAccess clients and iManage Work will function perfectly over DirectAccess!

Additional Resources

Active Directory Group Policy Preferences on Microsoft TechNet

iManage Web Site

Implementing DirectAccess with Windows Server 2016

Troubleshooting DirectAccess IP-HTTPS Error Code 0x800b0109

A Windows 7 or Windows 8.x/10 client may fail to establish a DirectAccess connection using the IP-HTTPS IPv6transition technology. When troubleshooting this issue, running ipconfig.exe show that the media state for the tunnel adapter iphttpsinterface is Media disconnected.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

Running the Get-NetIPHttpsState PowerShell command on Windows 8.x/10 clients or the netsh interface httpstunnel show interface command on Windows 7 clients returns an error code of 0x800b0109 with an interface status Failed to connect to the IPHTTPS server; waiting to reconnect.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

Error code 0x800b0109 translates to CERT_E_UNTRUSTEDROOT, indicating the client was unable to establish an IP-HTTPS connection because the certificate presented during the SSL handshake was issued by a certification authority that was not trusted. This commonly occurs when the DirectAccess server is configured with an SSL certificate issued by the internal PKI and DirectAccess clients are provisioned using offline domain join without using the /rootcacerts switch.

Troubleshooting DirectAccess IP-HTTPS Error 0x800b0109

To resolve IP-HTTPS error code 0x800b0109, obtain the root certificate for the certificate authority that issued the SSL certificate used for IP-HTTPS and import it in to the DirectAccess client’s Trusted Root Certification Authorities local computer certificate store. Once complete, restart the IP helper service to reinitiate an IP-HTTPS connection.

Additional Information

Provisioning DirectAccess Clients using Windows Offline Domain Join

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Troubleshooting DirectAccess IP-HTTPS Error 0x2af9

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Implementing DirectAccess with Windows Server 2016

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

A Windows 7 or Windows 8.x/10 client may fail to establish a DirectAccess connection using the IP-HTTPS IPv6 transition technology. When troubleshooting this issue, running ipconfig.exe shows that the media state for the tunnel adapter iphttpsinterface is Media disconnected.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

Running the Get-NetIPHttpsState PowerShell command on Windows 8.x/10 clients or the netsh interface httpstunnel show interface command on Windows 7 clients returns and error code of 0x80090326, with an interface status Failed to connect to the IPHTTPS server; waiting to reconnect.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

Error code 0x80090326 translates to SEC_E_ILLEGAL_MESSAGE, indicating the client encountered a fatal error during the SSL handshake.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

There are a number of things that can cause this to happen. The most common scenario occurs when an Application Delivery Controller (ADC) is improperly configured to perform client certificate authentication for IP-HTTPS connections. Common examples are an incorrect or missing root CA certificate, or null SSL/TLS cipher suites not enabled when supporting Windows 8.x/10 clients.

To troubleshoot DirectAccess IP-HTTPS error 0x80090326, perform a network trace on the DirectAccess client and observe the TLS handshake for clues as to which configuration error is the culprit. If the TLS handshake failure occurs immediately after the client sends a Client Hello, it is likely that the ADC does not have null cipher suites enabled.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

If the TLS handshake failure occurs after the Server Hello, it is likely that the ADC is configured to perform client certificate authentication incorrectly, or the client does not have a valid certificate.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

IP-HTTPS error 0x80090326 can also occur if an intermediary device is performing SSL/TLS inspection or otherwise tampering with the TLS request. It can also happen if the edge firewall and/or NAT device is forwarding IP-HTTPS connections to the wrong internal server, or if the firewall itself is responding to the HTTPS connection request. Remember, just because the server is responding on TCP port 443 doesn’t necessarily mean that it is the DirectAccess server responding!

Additional Information

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Troubleshooting DirectAccess IP-HTTPS Error 0x2af9

DirectAccess Troubleshooting Consulting Services

Implementing DirectAccess with Windows Server 2016

DirectAccess and Azure Multifactor Authentication

Introduction

DirectAccess and Azure Multifactor AuthenticationDirectAccess can be configured to enforce strong user authentication using smart cards or one-time passwords (OTP). This provides the highest level of assurance for remote users connecting to the internal network via DirectAccess. OTP solutions are commonly used because they require less administration and are more cost effective than typical smart card implementations. Most OTP solutions will integrate with DirectAccess as long as they support Remote Access Dial-In User Service (RADIUS).

DirectAccess and Azure Multifactor Authentication

Azure Authentication-as-a-Service

Azure Multifactor Authentication (MFA) is a popular OTP provider used to enable strong user authentication for a variety of platforms, including web sites and client-based VPN. Unfortunately, it doesn’t work with DirectAccess. This is because Azure MFA uses a challenge/response method for which DirectAccess does not support. To use OTP with DirectAccess, the user must be able to enter their PIN and OTP immediately when prompted. There is no provision to begin the authentication process and wait for a response from the OTP provider.

PointSharp ID Multifactor Authentication

An excellent alternative to Azure MFA is PointSharp ID. PointSharp is a powerful OTP platform that integrates easily with DirectAccess. It is also very flexible, allowing for more complex authentication schemes for those workloads that support it, such as Exchange and Skype for Business.

DirectAccess and Azure Multifactor AuthenticationEvaluate PointSharp

You can download a fully-functional trial version of PointSharp ID here (registration required). The PointSharp ID and DirectAccess integration guide with detailed step-by-step instructions for configuring DirectAccess and PointSharp ID can be downloaded here. Consulting services are also available to assist with integrating PointSharp ID with DirectAccess, VPN, Exchange, Skype for Business, Remote Desktop Services, or any other solution that requires strong user authentication. More information about consulting services can be found here.

Additional Information

PointSharp Multifactor Authentication
Configure DirectAccess with OTP Authentication
DirectAccess Consulting Services
Implementing DirectAccess with Windows Server 2016

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

A Windows 7 or Windows 8.x/10 client may fail to establish a DirectAccess connection using the IP-HTTPS IPv6 transition technology. When troubleshooting this issue, running ipconfig.exe shows that the media state for the tunnel adapter iphttpsinterface is Media disconnected.

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Running the Get-NetIPHttpsState PowerShell command on Windows 8.x/10 clients or the netsh interface httpstunnel show interface command on Windows 7 clients returns an error code of 0x90320, with an interface status Failed to connect to the IPHTTPS server; waiting to reconnect.

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Error code 0x90320 translates to SEC_I_INCOMPLETE_CREDENTIALS, indicating the client was unable to authenticate to the DirectAccess server during the TLS handshake when establishing the IP-HTTPS IPv6 transition tunnel. This occurs when the DirectAccess server or an Application Delivery Controller (ADC) is configured to perform client certificate authentication for IP-HTTPS connections. The client may fail to authenticate if it does not have a valid certificate issued by the organization’s internal certification authority (CA) or if the DirectAccess server or ADC is configured to perform IP-HTTPS client authentication incorrectly.

To resolve this issue, ensure that a valid certificate is installed on the DirectAccess client. In addition, ensure that the DirectAccess server or ADC is configured to use the correct CA when authenticating clients establishing IP-HTTPS connections.

Additional Information

DirectAccess IP-HTTPS Preauthentication 

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

DirectAccess SSL Offload and IP-HTTPS preauthentication using Citrix NetScaler 

DirectAccess IP-HTTPS preauthentication using F5 BIG-IP 

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Introduction

Communication between the DirectAccess client and server takes place exclusively over IPv6. When DirectAccess servers and/or clients are on the IPv4 Internet, an IPv6 transition technology must be employed to allow those clients to connect to the DirectAccess server. DirectAccess deployment best practices dictate that only the IP-HTTPS IPv6 transition technology be used. IP-HTTPS uses SSL/TLS for server authentication and optionally encryption. To improve security and performance for IP-HTTPS, an Application Delivery Controller (ADC) like the Citrix NetScaler can be configured to perform SSL offloading and client preauthentication for DirectAccess IP-HTTPS connections.

Please note that the following caveats apply when enabling SSL offload for DirectAccess clients:

  • Enabling SSL offload and IP-HTTPS preauthentication on an ADC for DirectAccess is formally unsupported by Microsoft.
  • SSL offload should not be enabled with DirectAccess is configured to use one-time password (OTP) authentication. Offloading SSL will break OTP functionality.

IP-HTTPS Challenges

The IP-HTTPS IPv6 transition technology is a simple and effective way to allow DirectAccess clients and servers to communicate by encapsulating IPv6 traffic in HTTP and routing it over the public IPv4 Internet. However, there are two critical issues with the default implementation of IP-HTTPS in DirectAccess. One is a security issue, the other affects performance.

Security

The DirectAccess server does not authenticate clients establishing IP-HTTPS connections. This could allow an unauthorized client to obtain an IPv6 address from the DirectAccess server using the IPv6 Neighbor Discovery (ND) process. With a valid IPv6 address, the unauthorized user could perform internal network reconnaissance or launch a variety of Denial of Service (DoS) attacks on the DirectAccess infrastructure and connected clients. More details here.

Performance

Windows 7 DirectAccess clients use encrypted cipher suites when establishing IP-HTTPS connections. However, the payload being transported is already encrypted using IPsec. This double encryption increases resource utilization on the DirectAccess server, reducing performance and limiting scalability. More details here.


Note: Beginning with Windows Server 2012 and Windows 8, Microsoft introduced support for null encryption for IP-HTTPS connections. This eliminates the needless double encryption, greatly improving scalability and performance for DirectAccess clients using IP-HTTPS.


SSL Offload for DirectAccess IP-HTTPS

The Citrix NetScaler can be configured to perform SSL offload to improve performance for Windows 7 DirectAccess clients using IP-HTTPS. Since DirectAccess does not natively support SSL offload, the NetScaler must be configured in a non-traditional way. While the NetScaler will be configured to terminate incoming IP-HTTPS SSL connections, it must also use SSL for the back-end connection to the DirectAccess server. However, the NetScaler will be configured only to use null cipher suites when connecting to the DirectAccess server. Even though Windows 7 clients will still perform double encryption to the NetScaler, this configuration effectively offloads from the server the heavy burden of double encrypting every IP-HTTPS connection for all connected DirectAccess clients. This results in reduced CPU utilization on the DirectAccess server, yielding better scalability and performance.

SSL Offload and Windows 8.x/10 Clients

Offloading SSL for Windows 8.x/10 clients will not improve performance because they already use null cipher suites for IP-HTTPS when connecting to a Windows Server 2012 or later DirectAccess server. However, terminating SSL on the NetScaler is still required to perform IP-HTTPS preauthentication.

Supported NetScaler Platforms for DirectAccess SSL Offloading

The following configuration for Citrix NetScaler can be performed on any release of the VPX virtual ADC platform. However, be advised that there is a known issue with older releases on the MDX and SDX hardware platforms that will prevent this from working. For MDX and SDX deployments, upgrading to release 11.1 build 50.10 or later will be required.

Configure Citrix NetScaler for IP-HTTPS SSL Offload

To enable SSL offloading for DirectAccess IP-HTTPS on the Citrix NetScaler, open the NetScaler management console, expand Traffic Management and Load Balancing, and then perform the following procedures in order.

Add Servers

  1. Click Servers.
  2. Click Add.
  3. In the Name field enter a descriptive name for the first DirectAccess server.
  4. Select IP Address.
  5. In the IP Address field enter the IP address of the first DirectAccess server.
  6. Click Create.
  7. Repeat these steps for any additional servers in the load-balanced cluster.

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Add Services

  1. Click Services.
  2. Click Add.
  3. In the Service Name field enter a descriptive name for the service.
  4. Select Existing Server from the Server drop-down list.
  5. Choose the first DirectAccess server in the cluster.
  6. Choose SSL from the Protocol drop-down list.
  7. Click Ok.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler
  8. Edit SSL Parameters.
    1. In the Protocol section uncheck SSLv3.
    2. Click Ok.
  9. Edit SSL Ciphers.
    1. Click Remove All.
    2. Click Add.
    3. Type NULL in the Search Ciphers box.
    4. Check the box next to the first entry for SSL3-NULL-SHA.
    5.  Click the right arrow to add the cipher to the list.
    6. Click Ok.
    7. Click Done.
    8. Repeat these steps for any additional servers in the load-balanced cluster.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

A warning message may be displayed indicating that no usable ciphers are configured on the SSL vserver/service. This message can be safely ignored.

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Add Virtual Server

  1. Click Virtual Servers.
    1. Click Add.
    2. In the Name field enter a descriptive name for the virtual server.
    3. Choose SSL from the Protocol drop-down list.
    4. In the IP Address field enter the IP address for the virtual server.
    5. Click Ok.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

      Note: When enabling load balancing in DirectAccess, the IP address assigned to the first DirectAccess server is reallocated for use as the load balancing Virtual IP Address (VIP). Ideally this IP address will be assigned to the load balancing virtual server on the NetScaler. However, this is not a hard requirement. It is possible to configure the VIP on the NetScaler to reside on any subnet that the load balancer has an interface to. More details here.


  2. In the Services and Groups section click No Load Balancing Virtual Server Service Binding.
    1. Click on the Select Service field.
    2. Check all DirectAccess server services and click Select.
    3. Click Bind.
    4. Click Continue.
  3. In the Certificate section click No Server Certificate.
    1. Click on the Select Server Certificate field.
    2. Choose the certificate to be used for DirectAccess IP-HTTPS.
    3. Click Select.
    4. Click Bind.
    5. Click Continue.
  4. Edit SSL Ciphers.
    1. Click Remove All.
    2. Click Add.
    3. Type ECDHE in to the Search Ciphers box.
    4. Check the box next to TLS1-ECDHE-RSA-AES128-SHA.
    5. Click the right arrow to add the cipher to the list.
    6. Type NULL in to the Search Ciphers box.
    7. Check the box next to SSL3-NULL-SHA.
    8. Click the right arrow to add the cipher to the list.
    9. Click Ok.
    10. Click Done.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

      Note: If Windows 8.x/10 clients are supported exclusively, SSL3-NULL-SHA is the only cipher suite required to be configured on the virtual server. If Windows 7 client support is required, the TLS1-ECDHE-RSA-AES128-SHA cipher suite should also be configured on the virtual server.


  5. Edit SSL Parameters.
    1. Uncheck SSLv3.
    2. Click Ok.

      Note: If Windows 8.x/10 clients are supported exclusively, TLSv1 can also be unchecked on the virtual server. If Windows 7 client support is required, TLSv1 must be enabled.


  6. In the Advanced Settings section click Persistence.
    1. Choose SSLSESSION.
    2. Enter 10 minutes for the Time-out (mins) value.
    3. Click Ok.
    4. Click Done.

Optional IP-HTTPS Preauthentication

To enable IP-HTTPS preauthentication to prevent unauthorized network access, perform the following procedures on the Citrix NetScaler appliance.

  1. Expand Traffic Management, Load Balancing, and then click Virtual Servers.
  2. Select the DirectAccess virtual server and click Edit.
    1. In the Certificate section click No CA Certificate.
    2. Click the Select CA Certificate field.
    3. Choose the certificate for the CA that issues certificates to DirectAccess clients and servers.

      Note: The CA certificate used for DirectAccess can be found by opening the Remote Access Management console, clicking Edit on Step 2, and then clicking Authentication. Alternatively, the CA certificate can be found by running the following PowerShell command.

      (Get-RemoteAccess).IPsecRootCertificate | Format-Table Thumbprint


    4. Click Select.
    5. Choose CRL Optional from the CRL and OCSP Check drop-down list.
    6. Click Bind.
  3. Edit SSL Parameters.
    1. Check the box next to Client Authentication.
    2. Choose Mandatory from the Client Certificate drop-down list.
    3. Click Ok.
    4. Click Done.
      DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Summary

Leveraging the advanced capabilities of the Citrix NetScaler ADC can improve performance when supporting Windows 7 clients and enhance security for all DirectAccess clients using IP-HTTPS. In terms of supportability, all of the changes described in this article are completely transparent and do not alter the native DirectAccess client or server configuration. If a Microsoft support engineer declines support due to this configuration, switching from SSL offload to SSL bridge is all that’s required to restore full supportability.

Additional Resources

NetScaler release 11.1 build 50.10 (requires login) – https://www.citrix.com/downloads/netscaler-adc/firmware/release-111-build-5010

Release notes for build 50.10 of NetScaler 11.1 release – https://www.citrix.com/content/dam/citrix/en_us/documents/downloads/netscaler-adc/NS_11_1_50_10.html

VIDEO: Enable Load Balancing for DirectAccess – https://www.youtube.com/watch?v=3tdqgY9Y-uo

DirectAccess IP-HTTPS preauthentication using F5 BIG-IP – https://directaccess.richardhicks.com/2016/05/23/directaccess-ip-https-preauthentication-using-f5-big-ip/

DirectAccess SSL offload for IP-HTTPS using F5 BIG-IP – https://directaccess.richardhicks.com/2013/07/10/ssl-offload-for-ip-https-directaccess-traffic-from-windows-7-clients-using-f5-big-ip/

Implementing DirectAccess with Windows Server 2016 book – http://directaccessbook.com/

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 Preauthentication using F5 BIG-IP

Note: For information about configuring the Citrix NetScaler to perform IP-HTTPS preauthentication, click here. For information about configuring Windows Server 2012 R2 to perform IP-HTTPS preauthentication natively, click here.

Introduction

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IPRecently I wrote about security challenges with DirectAccess and the IP-HTTPS IPv6 transition technology. Specifically, IP-HTTPS transition tunnel connections are not authenticated by the DirectAccess server, only the client. This allows an unauthorized device to obtain an IPv6 address on the DirectAccess client network. With it, an attacker can perform network reconnaissance using ICMPv6 and potentially launch a variety of Denial-of-Service (DoS) attacks. For more details, click here.

Note: DirectAccess IPsec data connections not at risk. Data is never exposed at any time with the default configuration.

Mitigation

To mitigate these issues, it is recommended that an Application Delivery Controller (ADC) be used to terminate SSL connections and enforce client certificate authentication. Doing this will ensure that only authorized connections will be accepted by the DirectAccess server. In addition, there are some scalability and performance benefits to implementing this configuration when supporting Windows 7 clients.

Important Considerations

Performing IP-HTTPS preauthentication on the F5 BIG-IP is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the F5 appliance breaks OTP authentication.

F5 BIG-IP Configuration

To configure the F5 BIG-IP to perform SSL offload for DirectAccess IP-HTTPS, follow the guidance documented here. In addition, to configure the F5 BIG-IP to perform preauthentication for DirectAccess clients, when creating the client SSL profile, click Custom above the Client Authentication section and choose Require from the Client Certificate drop-down list and Always from the Frequency drop-down list. In addition, choose your internal PKI’s root Certification Authority (CA) certificate from the Trusted Certificate Authorities drop-down list and from the Advertised Certificate Authorities drop-down list.

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

Summary

Enabling client certificate authentication for IP-HTTPS connections ensures that only authorized DirectAccess clients can establish a connection to the DirectAccess server and obtain an IPv6 address. It also prevents an unauthorized user from performing network reconnaissance or launching IPv6 Denial-of-Service (DoS) attacks.

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

Note: For information about configuring the F5 BIG-IP to perform IP-HTTPS preauthentication, click hereFor information about configuring Windows Server 2012 R2 or Windows Server 2016 to perform IP-HTTPS preauthentication natively, click here.

Introduction

DirectAccess IP-HTTPS Preauthentication using Citrix NetScalerIP-HTTPS is an IPv6 transition technology used by DirectAccess. It enables DirectAccess clients to communicate with the DirectAccess server using IPv6 over the public IPv4 Internet by encapsulating IPv6 packets in HTTP and authenticating (and optionally encrypting) them using SSL/TLS. IP-HTTPS is supported for all DirectAccess network deployment configurations and is enabled by default.

When a DirectAccess client connection is established, only the server is authenticated by the client. The client is not authenticated by the server. The DirectAccess server will thus accept IP-HTTPS connections from any client, valid or not.

IP-HTTPS Connection

Once a client has established an IP-HTTPS transition tunnel, it will go through the standard IPv6 neighbor discovery process to identify routers and obtain an IPv6 prefix for the link. It will use this information to build its own IPv6 address, which it uses to communicate with the DirectAccess server and begin establishing IPsec security associations for DirectAccess.

ICMP and IPsec

By design, ICMP is exempt from DirectAccess IPsec policy processing. If an unauthorized client were to establish an IP-HTTPS transition tunnel, even without authentication (Kerberos Proxy or certificate) it would be able to ping the DirectAccess server tunnel endpoint IPv6 addresses, the DNS64 IPv6 address, and any intranet hosts (assuming host firewalls allow this access).

Security Risk

This default posture opens up the DirectAccess server and intranet to unauthorized remote network reconnaissance and some IPv6-related Denial-of-Service (DoS) attacks. These were demonstrated by security researcher Ali Hardudi at the recent Troopers16 security conference. You can view his very informative session here.

Note: DirectAccess IPsec data connections are unaffected and are completely secure. Data is never exposed at any time with the default configuration.

IP-HTTPS Preauthentication

DirectAccess IP-HTTPS Preauthentication using Citrix NetScalerTo mitigate these risks, it is recommended that an Application Delivery Controller (ADC) such as the Citrix NetScaler be configured to preauthenticate DirectAccess clients prior to establishing the IP-HTTPS transition tunnel.

Note: To configure the F5 BIG-IP to perform IP-HTTPS preauthentication, click here.

Citrix NetScaler Configuration

To perform DirectAccess preauthentication, it will be necessary to configure the Citrix NetScaler to perform SSL termination for IP-HTTPS. The virtual server on the NetScaler must use the SSL protocol. In addition, a CA certificate must be bound to the virtual server. Also, Client Authentication must be enabled under SSL Parameters and be set to Mandatory.

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

Once configured, the NetScaler appliance will ensure that the DirectAccess IPsec certificate is present on the client before establishing the IP-HTTPS IPv6 transition tunnel. This will prevent unauthorized connections to the DirectAccess server.

Important Considerations

Performing IP-HTTPS preauthentication on the Citrix NetScaler is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the NetScaler appliance breaks OTP authentication.

Summary

The default security posture of DirectAccess leaves the internal network open to unauthorized network reconnaissance, and exposes the DirectAccess infrastructure to potential denial-of-service (DoS) attacks. To mitigate these security risks, implement the Citrix NetScaler ADC and enable client certificate authentication.

References

Security Assessment of Microsoft DirectAccess [Overview] – https://www.insinuator.net/2016/04/security-assessment-of-microsoft-directaccess/

Security Assessment of Microsoft DirectAccess [Full Document] – https://www.ernw.de/newsfeed/newsletter-53-may-2016-security-assessment-of-microsoft-directaccess/index.html

Security Assessment of Microsoft DirectAccess Troopers16 Presentation by Ali Hardudi [Video] – https://www.youtube.com/watch?v=wW1x7ow0V9w

Chiron IPv6 Penetration Testing Framework – https://www.insinuator.net/2014/10/chiron-an-all-in-one-ipv6-penetration-testing-framework/

IP-HTTPS specification on MSDN – https://msdn.microsoft.com/en-us/library/dd358571.aspx

Configure F5 BIG-IP to Perform IP-HTTPS Preauthentication – https://directaccess.richardhicks.com/2016/05/23/directaccess-ip-https-preauthentication-using-f5-big-ip/

Configure Windows Server 2012 R2  and Windows Server 2016 to Perform IP-HTTPS Preauthentication – https://directaccess.richardhicks.com/2016/06/13/directaccess-ip-https-preauthentication/

DirectAccess and Windows Server 2012 R2 Core

Important Note: The ability to switch back and forth between the full GUI and core versions of Windows was removed from Windows Server 2016. If you are deploying DirectAccess on Windows Server 2016, you must install server core initially. More details here.

DirectAccess and Windows Server 2012 R2 Core

Windows Server Core is an operating system configuration option that does not include a Graphical User Interface (GUI). Server Core was first introduced with Windows Server 2008 and originally included only a limited number of supported roles. With each subsequent release, Microsoft continues to add support for additional roles on Server Core. Beginning with Windows Server 2012, the Routing and Remote Access (RRAS) role, which includes DirectAccess, is a supported workload on Server Core.

Advantages of Server Core

There are a number of important advantages that come with running DirectAccess on Server Core. Server Core has a greatly reduced attack surface compared to the full GUI version, which is positive from a security perspective. Server Core also features a dramatically reduced footprint, consuming less RAM and disk space. System startup times are faster, and this refactored installation option also reduces servicing requirements (patching), eliminating many reboots and increasing availability and overall system uptime.

DirectAccess and Windows Server 2012 R2 Core

Figure 1 – Windows Server 2012 R2 Core Desktop (Yes, that’s it!)

Server Core Configuration

DirectAccess is a workload that lends itself well to running on Server Core, and I highly recommend leveraging this configuration whenever possible. Based on my experience, I suggest performing initial configuration and testing of the DirectAccess solution with the GUI installed, and then removing the GUI just before placing the DirectAccess server in to production. Removing the GUI can be accomplished by executing the following PowerShell command:

Remove-WindowsFeature Server-Gui-Mgmt-Infra –Restart

Once the server has been converted to Server Core, all administration must be performed at the command line on the server, or remotely from a management server or workstation using the command line or GUI administration tools. You can install the Remote Access Management console on any Windows Server 2012 R2 server using the following PowerShell command:

Install-WindowsFeature RSAT-RemoteAccess

Optionally you can download and install the Windows Server Remote Administrations Tools (RSAT) on a Windows client workstation, if desired.

Minimal Server Interface Configuration

If you prefer to be able to manage the DirectAccess server locally using the GUI, consider enabling the Minimal Server Interface. Minimal Server Interface is a configuration option that lies between Server Core and the full GUI interface. It features some of the benefits of Server Core, while at the same time providing local access to GUI management tools such as the Remote Access Management console. You can configure Minimal Server Interface using the following PowerShell command:

Remove-WindowsFeature Server-Gui-Shell -Restart

You can access the Remote Access Management console by entering RaMgmtUI.exe from the command line.

Revert to Full GUI

If at any point in the future you require the GUI for some reason, re-installing it can be accomplished using the following PowerShell command:

Install-WindowsFeature Server-Gui-Shell –Restart

Summary

With the Unified Remote Access role supported on Windows Server Core, consider implementing DirectAccess using this option to improve the security and increase the availability of your remote access solution. You’ll find that almost all ongoing server maintenance and support can be accomplished remotely using GUI tools, or locally using PowerShell. And if you ever need the GUI again, you can always add it back if necessary!

%d bloggers like this: