Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

Organizations are rapidly deploying Windows server infrastructure with public cloud providers such as Amazon Web Services (AWS) and Microsoft Azure. With traditional on-premises infrastructure now hosted in the cloud, DirectAccess is also being deployed there more commonly.

Supportability

Interestingly, Microsoft has expressly stated that DirectAccess is not formally supported on their own public cloud platform, Azure. However, there is no formal statement of non-support for DirectAccess hosted on other non-Microsoft public cloud platforms. With supportability for DirectAccess on AWS unclear, many companies are taking the approach that if it isn’t unsupported, then it must be supported. I’d suggest proceeding with caution, as Microsoft could issue formal guidance to the contrary in the future.

DirectAccess on AWS

Deploying DirectAccess on AWS is similar to deploying on premises, with a few notable exceptions, outlined below.

IP Addressing

It is recommended that an IP address be exclusively assigned to the DirectAccess server in AWS, as shown here.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

Prerequisites Check

When first configuring DirectAccess, the administrator will encounter the following warning message.

“The server does not comply with some DirectAccess prerequisites. Resolve all issues before proceed with DirectAccess deployment.”

The warning message itself states that “One or more network adapters should be configured with a static IP address. Obtain a static address and assign it to the adapter.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

IP addressing for virtual machines are managed entirely by AWS. This means the DirectAccess server will have a DHCP-assigned address, even when an IP address is specified in AWS. Assigning static IP addresses in the guest virtual machine itself is also not supported. However, this warning message can safely be ignored.

No Support for Load Balancing

It is not possible to create load-balanced clusters of DirectAccess servers for redundancy or scalability on AWS. This is because enabling load balancing for DirectAccess requires the IP address of the DirectAccess server be changed in the operating system, which is not supported on AWS. To eliminate single points of failure in the DirectAccess architecture or to add additional capacity, multisite must be enabled. Each additional DirectAccess server must be provisioned as an individual entry point.

Network Topology

DirectAccess servers on AWS can be provisioned with one or two network interfaces. Using two network interfaces is recommended, with the external network interface of the DirectAccess server residing in a dedicated perimeter/DMZ network. The external network interface must use either the Public or Private Windows firewall profile. DirectAccess will not work if the external interface uses the Domain profile. For the Public and Private profile to be enabled, domain controllers must not be reachable from the perimeter/DMZ network. Ensure the perimeter/DMZ network cannot access the internal network by restricting network access in EC2 using a Security Group, or on the VPC using a Network Access Control List (ACL) or custom route table settings.

External Connectivity

A public IPv4 address must be associated with the DirectAccess server in AWS. There are several ways to accomplish this. The simplest way is to assign a public IPv4 address to the virtual machine (VM). However, a public IP address can only be assigned to the VM when it is deployed initially and cannot be added later. Alternatively, an Elastic IP can be provisioned and assigned to the DirectAccess server at any time.

An ACL must also be configured for the public IP that restricts access from the Internet to only inbound TCP port 443. To provide additional protection, consider deploying an Application Delivery Controller (ADC) appliance like the Citrix NetScaler or F5 BIG-IP to enforce client certificate authentication for DirectAccess clients.

Network Location Server (NLS)

If an organization is hosting all of its Windows infrastructure in AWS and all clients will be remote, Network Location Server (NLS) availability becomes much less critical than with traditional on-premises deployments. For cloud-only deployments, hosting the NLS on the DirectAccess server is a viable option. It eliminates the need for dedicated NLS, reducing costs and administrative overhead. If multisite is configured, ensure that the NLS is not using a self-signed certificate, as this is unsupported.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

However, for hybrid cloud deployments where on-premises DirectAccess clients share the same internal network with cloud-hosted DirectAccess servers, it is recommended that the NLS be deployed on dedicated, highly available servers following the guidance outlined here and here.

Client Provisioning

All supported DirectAccess clients will work with DirectAccess on AWS. If the domain infrastructure is hosted exclusively in AWS, provisioning clients can be performed using Offline Domain Join (ODJ). Provisioning DirectAccess clients using ODJ is only supported in Windows 8.x/10. Windows 7 clients cannot be provisioned using ODJ and must be joined to the domain using another form of remote network connectivity such as VPN.

Additional Resources

DirectAccess No Longer Supported in Microsoft Azure

Microsoft Server Software Support for Azure Virtual Machines

DirectAccess Network Location Server (NLS) Guidance

DirectAccess Network Location Server (NLS) Deployment Considerations for Large Enterprises

Provisioning DirectAccess Clients using Offline Domain Join (ODJ)

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

DirectAccess SSL Offload and IP-HTTPS Preauthentication with F5 BIG-IP

Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course

Implementing DirectAccess with Windows Server 2016 Book

DirectAccess Troubleshooting with Nmap

DirectAccess IP-HTTPS Discovery Script for NmapDirectAccess troubleshooting can be made much easier using open source tools such as Nmap. Nmap can be used to perform many essential network connectivity and configuration checks, including validating network paths, confirming DirectAccess server response, and viewing SSL configuration. Nmap can also be used to ensure that the attack surface of the DirectAccess server is properly minimized. Some tests can be performed using only native Nmap functionality, while others require the use of specialized Nmap scripts that are included with the tool.

Installation

Nmap can be installed on a wide variety of operating systems, including Windows. If you plan to install Nmap on Windows, be sure to also install WinPcap and the Microsoft Visual C++ 2013 Redistributable. Both are included in the download.

Testing External Connectivity

Validating external connectivity is often one of the first DirectAccess troubleshooting steps I take. Confirm that the DirectAccess public hostname resolves to the correct IP address, then run the following Nmap command to validate network connectivity from the Internet to the DirectAccess server.

nmap -n -Pn -p443 <da_public_hostname>

DirectAccess Troubleshooting with Nmap

If the hostname resolves correctly and the network path is complete, the server should respond and Nmap will show the port as open. However, this doesn’t necessarily mean that the DirectAccess server is the device that replied! Due to misconfiguration, it is possible that another server or network device listening on TCP port 443 responded, so this is not a conclusive test.

DirectAccess Server Response

To confirm the DirectAccess server is responding to HTTPS requests and not some other server or device, run the following Nmap command with the ip-https-discover script.

nmap -n -Pn -p443 <da_public_hostname> –script ip-https-discover

If the DirectAccess server responds to the request, Nmap will return the following message:

IP-HTTPS is supported. This indicates that this host supports Microsoft DirectAccess.

DirectAccess Troubleshooting with Nmap

If the port is open but the script does not return this message, it is likely that another server or device is responding on TCP port 443, not the DirectAccess server.

Note: If an Application Delivery Controller (ADC) is configured to perform IP-HTTPS preauthentication, the Nmap IP-HTTPS discovery script will not return this result. This is expected and by design.

SSL Certificate Validation

It is not uncommon for DirectAccess clients to fail to connect via IP-HTTPS because of SSL certificate issues. Specifically, an SSL certificate that is not trusted, is expired, or its subject field does not match the public hostname will prevent DirectAccess clients from connecting. To view the SSL certificate configuration of a DirectAccess server, run the following Nmap command with the ssl-cert script.

nmap -n -Pn -p443 <da_public_hostname> –script ssl-cert

DirectAccess Troubleshooting with Nmap

SSL Cipher Suite Configuration

Occasionally there can be issues with the SSL configuration on the DirectAccess server that prevent some clients from connecting, or result in poor performance. This commonly occurs when administrators perform SSL hardening on the DirectAccess server and remove support for null cipher suites. Null cipher suites should never be disabled on the DirectAccess server. They are important to ensure the highest levels of performance for Windows 8.x and Windows 10 clients. Also, if an Application Delivery Controller (ADC) or load balancer is performing SSL offload, lack of support for null cipher suites will prevent Windows 8.x and Windows 10 clients from connecting. To determine if the DirectAccess server supports null cipher suites, run the following Nmap command with the ssl-enum-ciphers script.

nmap -n -Pn -p443 <da_public_hostname> –script ssl-enum-ciphers

DirectAccess Troubleshooting with Nmap

Attack Surface Audit

If DirectAccess implementation and security best practices are followed, the DirectAccess server will be behind an edge firewall. The only port required to be allowed inbound for DirectAccess is TCP port 443. It is recommended that a full port scan be performed against the DirectAccess server’s public IPv4 address to identify any unnecessary ports that may be open externally. To perform a full port scan, run the following Nmap command.

nmap -n -Pn -p- <da_public_hostname>

Ideally it should look like this.

DirectAccess Troubleshooting with Nmap

If it looks something like this, you’re in serious trouble!

DirectAccess Troubleshooting with Nmap

The DirectAccess server should never be listening for requests other that HTTPS on the public Internet. Exposing services such as SMB (TCP port 445), RDP (TCP port 3389), and others presents a significant security risk. It is recommended that edge firewalls be configured to allow inbound TCP port 443 only. If the DirectAccess server is connected directly to the public Internet (not recommended!) then the Windows Firewall should be configured to restrict access to inbound TCP port 443 only.

Additional Resources

DirectAccess IP-HTTPS Discovery Script for Nmap
Planning and Implementing DirectAccess with Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book
DirectAccess Troubleshooting and Consulting Services

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 WinRM Conflicts and Errors

Introduction

When installing DirectAccess for the first time, an administrator may encounter the following error message while running the Remote Access Setup wizard.

Error. The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: “winrm quickconfig”.

DirectAccess WinRM Conflicts and Errors

Troubleshooting

Running winrm quickconfig in an elevated PowerShell command window returns the following message.

WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.

DirectAccess WinRM Conflicts and Errors

Clicking Check prerequisites again does not resolve the error message.

Post-Installation Errors

If DirectAccess is already installed and working properly, an administrator may encounter a scenario in which the operations status page displays nothing, yet remote DirectAccess clients are connected and able to access corporate resources without issue.

DirectAccess WinRM Conflicts and Errors

In addition, clicking Edit on Step 2 in the Remote Access Management console and choosing Network Adapters produces an error message stating “An error occurred when validating interfaces”. You can select a network adapter from the drop-down list, but the Next and Finish buttons are grayed out.

DirectAccess WinRM Conflicts and Errors

Conflicts with WinRM

These errors are commonly caused by a conflict with WinRM Service settings enforced via Active Directory group policy. To confirm this, open an elevated PowerShell command window run the winrm enumerate winrm/config/listener command. The listener configuration source will be listed as GPO.

DirectAccess WinRM Conflicts and Errors

The administrator will also find the presence of the following registry keys on the DirectAccess server.

HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\AllowAutoConfig
HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\IPv4Filter
HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\IPv6Filter

Resolution

To resolve this conflict, prevent the GPO with this setting from being applied to the DirectAccess server(s). You will find this GPO setting in the Group Policy Management console (GPMC) by navigating to Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows Remote Management (WinRM) -> WinRM Service and setting the state of Allow remote server management through WinRM to Not configured.

DirectAccess WinRM Conflicts and Errors

Additional Resources

DirectAccess and Windows 10 Better Together

DirectAccess and Windows 10 in Education

VIDEO – DirectAccess and Windows 10 in Action 

BOOK – Implementing DirectAccess with Windows Server 2016

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/

Implementing DirectAccess with Windows Server 2016 Book Now Available

I am very excited to announce that my new DirectAccess book, Implementing DirectAccess with Windows Server 2016 from Apress media, is now shipping! The book is available on popular online sites like Amazon.com, Barnes & Noble, Springer.com, Apress.com, and others. The book is also available in electronic formats such as Amazon Kindle and Barnes & Noble Nook, as well as a variety of subscription formats including Safari, Books24x7, and SpringerLink.

Implementing DirectAccess with Windows Server 2016

This book contains detailed and prescriptive guidance for the planning, design, implementation, and support of a DirectAccess remote access solution on Windows Server 2016. It also includes valuable insight, tips, tricks, and best practice recommendations gained from my many years of deploying DirectAccess for some of the largest organizations in the world.

Current DirectAccess administrators will also find this book helpful, as the majority of content is still applicable to DirectAccess in Windows Server 2012 and Windows Server 2012 R2. In addition, the book also includes essential information on the design and deployment of highly available and geographically redundant DirectAccess deployments.

Troubleshooting DirectAccess can be a daunting task, so I’ve dedicated an entire chapter in the book to this topic. For those responsible for the maintenance and support of DirectAccess in their organization, this chapter alone will be worth the investment.

Be sure to order your copy today!

%d bloggers like this: