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 and Multi-SAN SSL Certificates for IP-HTTPS

Introduction

When preparing a DirectAccess server, an SSL certificate is required for the IP-HTTPS IPv6 transition technology. This certificate is often issued by a public Certification Authority (CA), but it can also be issued an organization’s internal Public Key Infrastructure (PKI).

SSL Certificate

Commonly an SSL certificate is issued for a single hostname, or subject. As long as the hostname matches the subject, everything works fine.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Multi-SAN SSL Certificate

To ease the management burden of using multiple certificates, or reduce the expense associated with using a wildcard certificate, organizations can request a multi-SAN (Subject Alternative Name) certificate, which matches more than one subject. The additional subjects are included in the Subject Alternative Name field on the SSL certificate.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS
A single multi-SAN certificate can be installed on multiple hosts and will work without issue as long as the hostname matches one of the SAN entries.

DirectAccess and Multi-SAN Certificates

When implementing DirectAccess in a multisite configuration, each entry point in the organization will have a unique public hostname. Instinctively, using a multi-SAN SSL certificate in this scenario would seem ideal.

Unfortunately, support for multi-SAN SSL certificates with DirectAccess is limited. To use a multi-SAN certificate for DirectAccess IP-HTTPS, the public hostname must match the name listed in the Subject field. In the example above, the subject is da.richardhicks.net, with SAN entries for da-west.richardhicks.net and da-east.richardhicks.net.

In this scenario, only the public name da.richardhicks.net is supported for use with DirectAccess. It will not work for any of the SAN entries. For example, attempting to configure DirectAccess to use this certificate with the public hostname da-west.richardhicks.net will fail with the following error message.

The subject name of certificate CN=[certificate subject name] is invalid.
Select a certificate with a valid subject name.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Attempting to work around this issue by using the Set-DAServer PowerShell cmdlet also fails to recognize the SSL certificate correctly.

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Summary

Using a multi-SAN SSL certificate for the DirectAccess IP-HTTPS IPv6 transition technology is only supported when the public hostname matches the subject name of the certificate. Configuring DirectAccess with a public hostname listed in the SAN list is not supported. For multisite DirectAccess deployments, individual certificates must be issued for each entry point. Alternatively, a wildcard certificate can be used.

DirectAccess IP-HTTPS Discovery Script for Nmap

DirectAccess IP-HTTPS Discovery Script for NmapWhen troubleshooting DirectAccess connectivity issues, the popular Nmap network mapping and discovery tool is an invaluable resource for verifying the communication path to the DirectAccess server from outside the network. However, just verifying that ports are open and listening often isn’t sufficient. In the case of IP-HTTPS, for example, the tried and true method of using telnet to verify that the port is open might be misleading. For instance, telnet might indicate that TCP port 443 is open and responding, but DirectAccess connectivity can still fail. This often happens as a result of a network configuration error that allows another network device other than the DirectAccess server to respond to HTTPS requests, which results in a false positive.

In an effort to conclusively determine that the DirectAccess server is responding, I’ve often relied on the SSL Labs Server Test site. Here I will enter the DirectAccess server’s public hostname and run the test, and from the results I can easily determine if indeed the DirectAccess server is responding by verifying that the HTTP server signature is Microsoft-HTTPAPI/2.0.

DirectAccess IP-HTTPS Discovery Script for NMAP

This usually works well, but it takes a few minutes to run the test, and there are a few scenarios in which it doesn’t work. For example, I might be working with a customer to perform some initial testing by using a local HOSTS file entry for the public name before the DNS record has been created. Also, if the SSL certificate on the DirectAccess server uses an IP address instead of a hostname (not recommended, but it is supported!) the SSL Labs server test won’t work.

Fortunately, the latest release Nmap (v7.00) now includes a script that enables the detection of Microsoft DirectAccess responding on TCP port 443. With the IP-HTTPS discovery script, it is now possible to determine not only if the port is open, but if the DirectAccess server is actually the service responding. The syntax for conducting a port scan using the IP-HTTPS discovery script for NMAP is as follows:

nmap.exe –n –Pn –p443 [directaccess_public_fqdn] –script [path_to_nmap_iphttps_discovery_script]

Here’s an example:

nmap.exe –n –Pn –p443 da.richardhicks.net –script c:\tools\nmap\scripts\ip-https-discover.nse

DirectAccess IP-HTTPS Discovery Script for NMAP

Now it is possible, using just Nmap, to not only determine if the IP-HTTPS communication path is functioning, but to definitively determine that the DirectAccess server is the device responding.

Happy troubleshooting!

3 Important Things You Need to Know about Windows 10 and DirectAccess

DirectAccess and Windows 10 - Better TogetherDirectAccess has been with us for quite some time know, having been originally introduced with Windows Server 2008 R2, later enhanced with Forefront Unified Access Gateway (UAG) 2010, and finally integrated in to the base operating system in Windows Server 2012 R2. Client support for DirectAccess begins with Windows 7 (Enterprise or Ultimate), and also includes Windows 8.x (Enterprise) and Windows 10 (Enterprise or Education).

Although Windows 7 clients are supported for DirectAccess, Windows 10 is highly preferred. Here are three important things you need to know about using Windows 10 with DirectAccess.

  1. Windows 10 Provides Improved Performance and Scalability – Windows 10 includes support for null encryption when using the IP-HTTPS IPv6 transition protocol. This eliminates the needless double-encryption performed by Windows 7 clients, and dramatically reduces the protocol overhead for clients connecting behind port-restricted firewalls. DirectAccess servers can support many more concurrent IP-HTTPS sessions with Windows 10, and it has the added benefit of making the more secure perimeter/DMZ deployment behind an edge security device performing NAT much more attractive.
  2. Windows 10 Supports Geographic Redundancy – Windows 10 includes full support for DirectAccess multisite deployments. Where Windows 7 clients had to be assigned to a single entry point, Windows 10 clients are aware of all entry points in the organization. They are able to automatically select the nearest entry point on startup, and transparently failover to another site if the current site becomes unavailable.
  3. Windows 10 Features an Enhanced Management Experience – From a troubleshooting and support perspective, Windows 10 makes things much easier. The DirectAccess connectivity assistant, an optional component for Windows 7, is now fully integrated with the Windows 10 UI. PowerShell is greatly improved and now includes many native DirectAccess configuration and troubleshooting commands.

As you can see, there are a number of significant advantages for using Windows 10 with DirectAccess. Windows 10 now supports all of the enterprise features of DirectAccess, including geographic redundancy and performance and scalability improvements. Windows 10 is also easier to troubleshoot and manage. If you’re still supporting Windows 7, DirectAccess in Windows Server 2012 R2 can certainly support them. However, without a doubt the best experience, both from an administrator’s and the end user’s perspective, is with Windows 10. Just one more reason to begin planning your migration to Windows 10 with DirectAccess today!

Need assistance with implementing  DirectAccess with Windows 10? I can help! More details here.

DirectAccess Manage Out from Windows 10 Does Not Work

For DirectAccess manage out deployments using ISATAP, you may encounter a scenario in which you are unable to initiate outbound connections to connected DirectAccess clients from a Windows 10 computer. Outbound connections using ISATAP from Windows 7, Windows 8, Windows Server 2008/R2, or Windows Server 2012/R2 systems work without issue.

DirectAccess Manage Out from Windows 10 Does Not Work

As it turns out, there is a bug in the Windows 10 DNS client code that prevents manage out using ISATAP from a Windows 10 client from working correctly. Thanks to the diligent effort of DirectAccess administrators Mike Piron and Jason Kuhns, a workaround has been identified. To deploy the workaround, it will be necessary to implement registry changes to alter the default behavior of the DNS resolver in Windows 10. You can implement these changes on a Windows 10 DirectAccess manage out machine by using the following PowerShell commands:

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableParallelAandAAAA -PropertyType dword -Value 1 -Force

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableServerUnreachability -PropertyType dword -Value 1 –Force

Once these registry changes have been made, you should now be able to use ISATAP for DirectAccess manage out connections from a Windows 10 machine.

DirectAccess and Windows 10 Better Together

With last week’s release of Windows 10, many organizations who chose to skip Windows 8 are now beginning to deploy Windows 10. To maximize investment in Windows 10, DirectAccess can be leveraged to provide employees with seamless and transparent, always on, secure remote corporate network connectivity. DirectAccess has been around for many years, and today the most popular DirectAccess client is Windows 7. However, Windows 10 provides better support for DirectAccess features that enhance performance and availability, while at the same making it easier to implement and support. Windows 10 opens up many new and compelling deployment scenarios for small businesses to large scale enterprises.

Full Support for Geographic Redundancy

Without a doubt the most important DirectAccess feature Windows 10 supports is automatic entry point selection and transparent failover for multisite deployments. DirectAccess multisite deployment provides essential geographic redundancy for organizations with multiple physical locations. Windows 7 has only minimal support for multisite deployment, with clients required to be assigned to a single entry point. Windows 10 clients are aware of all entry points and will intelligently select the closest entry point when establishing a DirectAccess connection. If the entry point becomes unavailable during the connection, Windows 10 clients will transparently connect to another entry point automatically.

Better Scalability and Performance

Windows 10, like Windows 8 before it, includes support for IP-HTTPS null encryption. This feature greatly improves scalability on the DirectAccess server by eliminating the needless double encryption that Windows 7 clients perform. This reduces resource consumption on the server and enables the server to support many more DirectAccess client connections.

DirectAccess and Windows 10 Better Together

Enhanced Supportability

Many will also appreciate Windows 10’s built-in DirectAccess connectivity status indicator. No longer will administrators have to deploy, manage, and maintain additional software to provide this essential functionality.

To access DirectAccess information in Windows 10, press Window Key + I, click Network & Internet, and then click the DirectAccess tab. Here you will find vital details about DirectAccess configuration and status such as connection state, currently connected entry point, and a site selection drop down box (if manual site selection is enabled by an administrator). In addition you can generate and collect log information for troubleshooting purposes.

DirectAccess and Windows 10 Better Together

Native PowerShell Support

Anyone tasked with troubleshooting DirectAccess configuration and connectivity issues will appreciate the native PowerShell integration with DirectAccess in Windows 10. With just a few commands a wealth of information about DirectAccess configuration and connectivity status can be obtained.

Need to quickly determine if a Windows 10 client has been provisioned for DirectAccess successfully?

Get-DAClientExperienceConfiguration

DirectAccess and Windows 10 Better Together

Has the Windows 10 client connected successfully? If not, why?

Get-DAConnectionStatus

DirectAccess and Windows 10 Better Together

Need to identify the Network Location Server (NLS) the client is configured to use?

Get-NCSIPolicyConfiguration

DirectAccess and Windows 10 Better Together

Looking for DirectAccess multisite entry point details and connection status?

Get-DAEntryPointTableItem

DirectAccess and Windows 10 Better Together

PKI Optional (But Recommended)

Finally, when Windows 10 (and Windows 8.x) clients are supported exclusively a Public Key Infrastructure (PKI) is optional. Here instead the Kerberos Proxy is leveraged to perform DirectAccess client authentication, which reduces infrastructure requirements by eliminating the need for a PKI. However, this configuration offers only limited support for DirectAccess features. For example, a PKI is still required if any Windows 7 clients are deployed. Also, PKI is required to support features such as one-time password (OTP) authentication, Microsoft Network Access Protection (NAP) integration, load balancing (integrated or external), force tunneling, and multisite configuration.

DirectAccess and Windows 10 Better Together

For optimum security and maximum deployment flexibility it is recommended that PKI be used to manage certificates for all DirectAccess deployments including those supporting only Windows 8.x and Windows 10 clients.

Summary

DirectAccess and Windows 10 are much better together. Windows 10 provides full support for the geographic load balancing features of DirectAccess and at the same time offers improved scalability and performance. Windows 10 also makes supporting and troubleshooting DirectAccess clients much easier. And for smaller deployments, Windows 10 can lower the barrier to entry for organizations considering DirectAccess by eliminating the need for a full PKI deployment.

Additional Resources

Video: DirectAccess and Windows 10 in Action
DirectAccess and Windows 10 in Education
Implementing DirectAccess with Windows Server 2016 Book
Implementing DirectAccess with Windows Server 2012 R2 Video Training Course
DirectAccess Consulting Services

%d bloggers like this: