DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

Occasionally I will get a call from a customer that has deployed DirectAccess and is complaining about a security audit finding indicating that the DirectAccess server supports insecure SSL/TLS cipher suites. For example, when using the popular Tenable Nessus vulnerability scanner, a vulnerability report indicates a finding with a Medium severity level in the plug-in “SSL Null Cipher Suites Supported”. The description states that “The remote host supports the use of SSL ciphers that offer no encryption at all.”

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

You can confirm this finding by using the Qualys SSL Labs SSL Server Test site. You’ll notice that the test results for a Windows Server 2016 DirectAccess server indicate an overall rating of “F” and a score of “0” for the cipher strength.

DirectAccess IP-HTTPS Insecure SSL and TLS Cipher Suites

Reviewing the details of the test results shows that the following two NULL cipher suites are indeed supported, highlighted below in red.

TLS_WITH_RSA_NULL_SHA256
TLS_WITH_RSA_NULL_SHA

DirectAccess IP-HTTPS Insecure SSL and TLS Cipher Suites

Note: This doesn’t apply when the client-based VPN or Web Application Proxy (WAP) roles are also installed on the DirectAccess server, or if one-time password (OTP) authentication is enabled.  More details here.

Typically this would be remedied by disabling support for NULL cipher suites using the common SSL and TLS hardening techniques. However, DirectAccess IP-HTTPS is unique in this scenario and the support for NULL cipher suites is by design, so employing traditional SSL and TLS security hardening techniques doesn’t apply here.

This is because DirectAccess IP-HTTPS is only used for IPv6 tunneling purposes, enabling the DirectAccess client that communicates exclusively using IPv6 to connect to the DirectAccess server over the public IPv4 Internet. IPv6 DirectAccess traffic from the client to the server is encrypted with IPsec, so the need for SSL/TLS encryption is not required, and in fact is not desirable for scalability and performance reasons. No unencrypted traffic (with the exception of ICMP) is sent over this SSL/TLS connection.

If a security audit flags support for insecure cipher suites on your Windows Server 2012/R2 DirectAccess server, you can safely ignore it.

Remote Assistance to Windows 7 SP1 DirectAccess Client Fails

Microsoft recently made available a hotfix to address an issue where Remote Assistance connections to remote DirectAccess clients fails. The issue occurs specifically when Windows 7 clients connect to a Windows Server 2012 DirectAccess server using the IP-HTTPS IPv6 transition protocol. In this scenario, DirectAccess clients are assigned a Unique Local IPv6 Address (ULA) using the prefix FD00::/8 for which Remote Assistance service would not listen on. If you are planning to support Windows 7 clients on your Windows Server 2012/R2 DirectAccess server and you need Remote Assistance functionality, you’ll definitely want to ensure that this hotfix is applied to all of your Windows 7 DirectAccess clients.

For more information and to download the hotfix, please refer to Microsoft Knowledge Base article KB2912883.

Troubleshooting Name Resolution Issues on DirectAccess Clients

When troubleshooting name resolution issues on a Windows client, NSlookup is an essential tool. However, it is important to understand that using NSlookup on a DirectAccess client might not always work as you expect. Although using NSlookup on a DirectAccess client will work normally when the client is on the corporate network, it will not provide the correct results to queries for internal hostnames when the DirectAccess client is outside of the corporate network without taking additional steps. This is because when a DirectAccess client is outside the corporate network, the Name Resolution Policy Table (NRPT) is enabled. The NRPT provides policy-based name resolution routing for DirectAccess clients, sending name resolution requests for certain namespaces to specific DNS servers. You can view the NRPT on a Windows 8.x DirectAccess client by issuing the following PowerShell command:

Get-DnsClientNrptPolicy

Troubleshooting Name Resolution Issues on DirectAccess Clients

You can view the NRPT on a Windows 7 DirectAccess client by issuing the following netsh command:

netsh namespace show policy

Troubleshooting Name Resolution Issues on DirectAccess Clients

Here you’ll notice that the namespace .lab.richardhicks.net is configured to use the DNS64 service running on the DirectAccess server at 2002:62bd:d898:3333::1. Notice also that the host nls.lab.richardhicks.net is not configured to use a DNS server. This effectively exempts this host from the NRPT, forcing name resolution requests for this Fully-Qualified Domain Name (FQDN) to be delivered to the DNS servers configured on the network adapter.

A Working Example

With the NRPT enabled, which occurs whenever the DirectAccess client is outside of the corporate network, a name resolution request for app1.lab.richardhicks.net would be sent to the DNS64 service on the DirectAccess server. A name resolution request for technet.microsoft.com would be sent to the DNS servers assigned to the network adapter because the NRPT contains no entry for this namespace. And even though the host nls.lab.richardhicks.net is a part of the internal namespace, a name resolution request for this host would also be sent to the DNS servers assigned to the network adapter because it has been specifically exempted from the NRPT.

NSlookup

The NSlookup utility is unaware of the NRPT. Whenever you use NSlookup it will, by default, automatically send queries directly to the DNS servers configured on the network adapter, regardless of the NRPT. If you wish to use NSlookup to test name resolution for external hostnames, use it as you normally would. However, if you wish to use NSlookup to resolve internal hostnames over the DirectAccess connection, you will need to tell NSlookup to use the DNS64 service running on the DirectAccess server. You can do this by running NSlookup interactively and using the server command to point it to the IPv6 address of the DNS64 service, which you can find in the NRPT.

Troubleshooting Name Resolution Issues on DirectAccess Clients

This also applies to the PowerShell cmdlet Resolve-DNSname. Here you’ll use the -Server switch to specify the DNS64 server’s IPv6 address.

Resolve-DNSName –Server <DNS64_IPv6_Address> app1.lab.richardhicks.net

Troubleshooting Name Resolution Issues on DirectAccess Clients