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 IP-HTTPS Error 0x2af9

When troubleshooting DirectAccess client connectivity issues, you may encounter a scenario where clients are unable to connect using the IP-HTTPS IPv6 transition technology. Running ipconfig shows that the tunnel adapter IPHTTPSInterface media state is Media disconnected.

DirectAccess IP-HTTPS Error 0x2af9

Running the Get-NetIpHttpsState PowerShell command shows that the LastErrorCode is 0x2af9 (WSAHOST_NOT_FOUND) and the InterfaceStatus is Failed to connect to the IPHTTPS server; waiting to reconnect.

DirectAccess IP-HTTPS Error 0x2af9

The 0x2af9 error differs slightly from the more common 0x274c IP-HTTPS connection time out error (WSAETIMEDOUT). In this scenario the DirectAccess client can successfully resolve the DirectAccess public hostname to an IPv4 address, and if ICMP echo requests are allowed on the DirectAccess server’s public IPv4 address it will respond to ping.

DirectAccess IP-HTTPS Error 0x2af9

The DirectAccess client is also able to establish a TCP connection to the DirectAccess server using the Test-NetConnection PowerShell command.

DirectAccess IP-HTTPS Error 0x2af9

So, why is the IP-HTTPS interface unable to establish a transition tunnel connection when the DirectAccess server’s public hostname resolves correctly via DNS and the client can establish a TCP connection on port 443? Commonly this is caused by proxy server settings configured in the web browser on the DirectAccess client computer. Disabling the proxy server in the client’s web browser should restore DirectAccess client connectivity over IP-HTTPS.

DirectAccess IP-HTTPS Error 0x2af9

If clearing the proxy server settings in the client machine’s web browser still does not restore IP-HTTPS connectivity, it may be that a proxy server is also configured for winhttp. You can confirm this by opening an elevated PowerShell command window and running the netsh winhttp show proxy command.

DirectAccess IP-HTTPS Error 0x2af9

To clear the winhttp proxy server settings run the netsh winhttp reset proxy command.

DirectAccess IP-HTTPS Error 0x2af9

Additional Resources

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

DirectAccess IP-HTTPS Preauthentication

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

DirectAccess SSL Offload using F5 BIG-IP

DirectAccess IP-HTTPS Preauthentication with F5 BIG-IP

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Implementing DirectAccess with Windows Server 2016 Book

 

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 Expired IP-HTTPS Certificate and Error 0x800b0101

Introduction

DirectAccess is an IPv6 only solution, at least from the perspective of the client. When the DirectAccess client is remote, it communicates with the DirectAccess server using IPv6 exclusively. IPv6 transition technologies are used to enable this connectivity when the DirectAccess server and/or client are on the pubic IPv4 Internet.

IP-HTTPS

One of the IPv6 transition technologies used by DirectAccess is IP-HTTPS. With IP-HTTPS, IPv6 traffic is encapsulated in HTTP and delivered to the DirectAccess server using IPv4. IP-HTTPS is used exclusively when the DirectAccess server is located behind an edge firewall performing network address translation.

SSL Certificate

To support IP-HTTPS, an SSL certificate is installed on each DirectAccess server. The SSL certificate is commonly issued by a public certification authority, but it can also be issued by an internal PKI. The SSL certificate used for IP-HTTPS can and does expire, and when it does it will prevent any DirectAccess connection from being established using this transition technology.

Troubleshooting

When troubleshooting DirectAccess connectivity via IP-HTTPS, the first thing the administrator will notice is that the media state for the DirectAccess client’s IP-HTTPS tunnel adapter interface is shown as disconnected.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

In addition, the Get-NetIPHttpsState PowerShell command returns an error code 0x800b0101 indicating Failed to connect to the IP-HTTPS server; waiting to reconnect.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Err.exe translates this error to CERT_E_EXPIRED, indicating that the SSL certificate is no longer valid.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Viewing the IP-HTTPS SSL certificate is not possible using a web browser. Instead, use Nmap and the ssl-cert script to view the certificate.

nmap.exe -n -Pn -p443 [FQDN] –script ssl-cert

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

In the Operations Status window of the Remote Access Management console on the DirectAccess server, the IP-HTTPS status is listed as Critical. Details show IP-HTTPS not working properly, with an error stating the IP-HTTPS certificate is not valid, and clearly indicating that the certificate is expired.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

The IP-HTTPS status can also be viewed at the command line by issuing the following command in an elevated PowerShell command window.

Get-RemoteAccessHealth | Where-Object Component -eq IP-Https | Format-List

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Updating the Certificate

Simply renewing the SSL certificate is not sufficient to restore IP-HTTPS connectivity for remote DirectAccess clients. The DirectAccess configuration must also be updated to use the new certificate. In the Remote Access Management console, highlight DirectAccess and VPN under Configuration and then click Edit on Step 2 (for load-balanced or multisite DirectAccess deployments, first highlight the individual server and then click Configure Server Settings). Click Network Adapters, click Browse, and then select the new SSL certificate.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Click Ok, Next, and then Finish twice and Apply. Repeat these steps for each server in the load-balanced cluster, and for all servers in all entry points in the enterprise.

Alternatively, the IP-HTTPS certificate can be updated in the DirectAccess configuration by opening an elevated PowerShell command window and entering the following commands.

$cert = Get-ChildItem -Path cert:\localmachine\my | Where-Object Thumbprint -eq [cert_thumbprint]
Set-RemoteAccess -SslCertificate $cert -Verbose

For example…

$cert = Get-ChildItem -Path cert:\localmachine\my | Where-Object Thumbprint -eq 2BFD1BC5805EBBF8ACB584DA025AD75B341A8B33
Set-RemoteAccess -SslCertificate $cert -Verbose


Important Note: Be sure to execute these commands on each DirectAccess server in the load-balanced cluster, and for all servers in all entry points in the enterprise.


Self-Signed Certificates

When DirectAccess is deployed using the Getting Started Wizard (GSW), also known as a “simplified deployment“, a self-signed certificate is used for IP-HTTPS. By default, this certificate expires 5 years after it is created. The expiration of a self-signed certificate presentsa unique challenge. Although the self-signed certificate can’t be renewed, it can be re-created or cloned using the New-SelfSignedCertificate PowerShell command. However, DirectAccess clients will not trust this new certificate until they receive the updated client settings via group policy. DirectAccess clients outside the network will not be able to establish IP-HTTPS connections until they receive these new policies. When they attempt to connect to the DirectAccess server without first updating group policy, the IP-HTTPS status will indicate an error code 0x800b0109 which translates to CERT_E_UNTRUSTEDROOT.

If the expired self-signed certificate is replaced with another self-signed certificate (not recommended), DirectAccess clients will have to come back to the internal network or connect remotely via client-based VPN to update group policy and receive the new DirectAccess client settings. A better alternative is to replace the expired self-signed certificate with a public SSL certificate that matches the existing public hostname. This will allow remote clients to reestablish DirectAccess connectivity without the need to udpate group policy first.

Summary

Certificate expiration must be monitored closely to ensure the highest level of availability for the DirectAccess remote access solution. Certificate auto enrollment can be leveraged to ensure that IPsec certificates are automatically renewed prior to expiration. However, the IP-HTTPS certificate must be renewed manually and requires additional configuration after it has been updated.

Additional Resources

DirectAccess Computer Certificate Auto Enrollment

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Implementing DirectAccess with Windows Server 2016 book

Deploying DirectAccess in Microsoft Azure

Introduction

DirectAccess Now a Supported Workload in Microsoft AzureMany organizations are preparing to implement DirectAccess on Microsoft’s public cloud infrastructure. Deploying DirectAccess in Azure is fundamentally no different than implementing it on premises, with a few important exceptions (see below). This article provides essential guidance for administrators to configure this unique workload in Azure.

Important Note: There has been much confusion regarding the supportability of DirectAccess in Azure. Historically it has not been supported. Recently, it appeared briefly that Microsoft reversed their earlier decision and was in fact going to support it. However, the Microsoft Server Software Suport for Microsoft Azure Virtual Machines document has once again been revised to indicate that DirectAccess is indeed no longer formally supported on Azure. More details can be found here.

Azure Configuration

The following is guidance for configuring network interfaces, IP address assignments, public DNS, and network security groups for deploying DirectAccess in Azure.

Virtual Machine

Deploy a virtual machine in Azure with sufficient resources to meet expected demand. A minimum of two CPU cores should be provisioned. A VM with 4 cores is recommended. Premium storage on SSD is optional, as DirectAccess is not a disk intensive workload.

Network Interfaces

It is recommended that an Azure VM with a single network interface be provisioned for the DirectAccess role. This differs from on-premises deployments where two network interfaces are preferred because deploying VMs in Azure with two NICs is prohibitively difficult. At the time of this writing, Azure VMs with multiple network interfaces can only be provisioned using PowerShell, Azure CLI, or resource manager templates. In addition, Azure VMs with multiple NICs cannot belong to the same resource group as other VMs. Finally, and perhaps most importantly, not all Azure VMs support multiple NICs.

Internal IP Address

Static IP address assignment is recommended for the DirectAccess VM in Azure. By default, Azure VMs are initially provisioned using dynamic IP addresses, so this change must be made after the VM has been provisioned. To assign a static internal IP address to an Azure VM, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network Interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click IP configurations.
  6. Click Ipconfig1.
  7. In the Private IP address settings section choose Static for the assignment method.
  8. Enter an IP address for the VM.
  9. Click Save.

Deploying DirectAccess in Microsoft Azure

Public IP Address

The DirectAccess VM in Azure must have a public IP address assigned to it to allow remote client connectivity. To assign a public IP address to an Azure VM, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network Interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click IP configurations.
  6. Click Ipconfig1.
  7. In the Public IP address settings section click Enabled.
  8. Click Configure required settings.
  9. Click Create New and provide a descriptive name for the public IP address.
  10. Choose an address assignment method.
  11. Click Ok and Save.

Deploying DirectAccess in Microsoft Azure

Deploying DirectAccess in Microsoft Azure

Public DNS

If the static IP address assignment method was chosen for the public IP address, create an A resource record in public DNS that resolves to this address. If the dynamic IP address assignment method was chosen, create a CNAME record in public DNS that maps to the public hostname for the DirectAccess server. To assign a public hostname to the VM in Azure, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Overview.
  4. Click Public IP address/DNS name label.Deploying DirectAccess in Microsoft Azure
  5. Under Settings click Configuration.
  6. Choose an assignment method (static or dynamic).
  7. Enter a DNS name label.
  8. Click Save.

Deploying DirectAccess in Microsoft Azure

Note: The subject of the SSL certificate used for the DirectAccess IP-HTTPS listener must match the name of the public DNS record (A or CNAME) entered previously. The SSL certificate does not need to match the Azure DNS name label entered here.

Network Security Group

A network security group must be configured to allow IP-HTTPS traffic inbound to the DirectAccess server on the public IP address. To make the required changes to the network security group, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click Network security group.
  6. Click the network security group assigned to the network interface.
  7. Click Inbound security rules.
  8. Click Add and provide a descriptive name for the new rule.
  9. Click Any for Source.
  10. From the Service drop-down list choose HTTPS.
  11. Click Allow for Action.
  12. Click Ok.

Deploying DirectAccess in Microsoft Azure

Note: It is recommended that the default-allow-rdp rule be removed if it is not needed. At a minimum, scope the rule to allow RDP only from trusted hosts and/or networks.

DirectAccess Configuration

When performing the initial configuration of DirectAccess using the Remote Access Management console, the administrator will encounter the following warning message.

“One or more network adapters should be configured with a static IP address. Obtain a static address and assign it to the adapter.”

Deploying DirectAccess in Microsoft Azure

This message can safely be ignored because Azure infrastructure handles all IP address assignment for hosted VMs.

The public name of the DirectAccess server entered in the Remote Access Management console must resolve to the public IP address assigned to the Azure VM, as described previously.

Deploying DirectAccess in Microsoft Azure

Additional Considerations

When deploying DirectAccess in Azure, the following limitations should be considered.

Load Balancing

It is not possible to enable load balancing using Windows Network Load Balancing (NLB) or an external load balancer. Enabling load balancing for DirectAccess requires changing static IP address assignments in the Windows operating system directly, which is not supported in Azure. This is because IP addresses are assigned dynamically in Azure, even when the option to use static IP address assignment is chosen in the Azure management portal. Static IP address assignment for Azure virtual machines are functionally similar to using DHCP reservations on premises.

Deploying DirectAccess in Microsoft Azure

Note: Technically speaking, the DirectAccess server in Azure could be placed behind a third-party external load balancer for the purposes of performing SSL offload or IP-HTTPS preauthentication, as outlined here and here. However, load balancing cannot be enabled in the Remote Access Management console and only a single DirectAccess server per entry point can be deployed.

Manage Out

DirectAccess manage out using native IPv6 or ISATAP is not supported in Azure. At the time of this writing, Azure does not support IPv6 addressing for Azure VMs. In addition, ISATAP does not work due to limitations imposed by the underlying Azure network infrastructure.

Summary

For organizations moving infrastructure to Microsoft’s public cloud, formal support for the DirectAccess workload in Azure is welcome news. Implementing DirectAccess in Azure is similar to on-premises with a few crucial limitations. By following the guidelines outlined in this article, administrators can configure DirectAccess in Azure to meet their secure remote access needs with a minimum of trouble.

Additional Resources

Implementing DirectAccess in Windows Server 2016
Fundamentals of Microsoft Azure 2nd Edition
Microsoft Azure Security Infrastructure
DirectAccess Multisite with Azure Traffic Manager
DirectAccess Consulting Services

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/

%d bloggers like this: