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/

ISP Address Field is Blank in DirectAccess Status and Reports

When viewing DirectAccess client status in the Remote Access Management console, you will notice that the ISP address field is blank for clients using the IP-HTTPS IPv6 transition protocol. However, the ISP Address information is displayed for clients using the 6to4 or Teredo IPv6 transition protocols.

ISP Address Field is Blank in DirectAccess Status and Reports

This is expected behavior and occurs as a result of the way in which the DirectAccess reports obtain the client’s public ISP address information. The ISP address is derived from the IPv6 address used to establish the DirectAccess client’s IPsec Security Associations (SAs) on the DirectAccess server. For clients using the 6to4 or Teredo IPv6 transition protocols, the client’s public IPv4 address is embedded in its IPv6 address. This information is displayed in the ISP Address field. However, the IP-HTTPS IPv6 transition protocol uses completely random IPv6 addresses. Without an embedded IPv4 address, the Remote Access Management console lacks the information to display in the ISP Address field.

Updated 3/22/2015: With a little extra work it is possible to find the IPv4 ISP address for DirectAccess clients using the IP-HTTPS IPv6 transition protocol. For more information, please refer to Microsoft PFE Martin Solis’ excellent blog post on the subject here.

DirectAccess IPv6 Transition Protocols Explained

Introduction

From a client perspective, DirectAccess is an IPv6-only solution. The DirectAccess client communicates with the DirectAccess server exclusively using IPv6. However, IPv6 is not widely deployed, so the most common scenario will find your DirectAccess clients and servers on the IPv4 Internet.

To facilitate DirectAccess client to server communication with IPv6 when the client is on the IPv4 Internet, IPv6 transition protocols are employed. These protocols effectively tunnel IPv6 packets in IPv4 packets. DirectAccess makes use of three IPv6 transition protocols for client to server connections – 6to4, Teredo, and IP-HTTPS.

DirectAccess Transition Protocols

6to4 – The 6to4 IPv6 transition protocol works by encapsulating IPv6 packets in IPv4 packets using IP protocol 41. 6to4 does not work when the client or the server is behind a NAT, so this IPv6 transition protocol is only used when the client and server are assigned public IPv4 addresses. DirectAccess clients with public IPv4 addresses aren’t common though, and there are some challenges with the stability of 6to4. From experience I can tell you that 6to4 often fails when clients use a cellular Wi-Fi hotspot, for example. For this reason it is generally recommended that you proactively disable this transition protocol to avoid potential issues in the future.

TeredoTeredo is an IPv6 transition protocol that is designed to work when a DirectAccess client (but not the DirectAccess server) is behind a NAT. It works by encapsulating IPv6 packets in IPv4 packets using UDP on port 3544. Teredo will be used any time the DirectAccess client has a private IPv4 address, or when the client has a public IPv4 address and the 6to4 protocol is unavailable (e.g. 6to4 is disabled, or outbound access to IP protocol 41 is restricted by firewall policy). To support Teredo, the DirectAccess server must be configured with two consecutive public IPv4 addresses. In addition, Teredo uses ICMP for NAT detection (e.g. cone, restricted, symmetric), so ICMPv4 echo requests must be allowed inbound to any host with which the DirectAccess client communicates.

IP-HTTPSIP-HTTPS is an IPv6 transition protocol that works by encapsulating IPv6 packets in IPv4 packets using HTTP with SSL/TLS. It is the IPv6 transition protocol of last resort, and will be used any time that 6to4 or Teredo aren’t available. The advantage to using IP-HTTPS is ubiquitous firewall access. Any network with access to the public Internet should, at a minimum, allow outbound HTTP and HTTPS. In some deployment scenarios, IP-HTTPS can be disadvantageous. For example, when Windows 7 DirectAccess clients leverage this IPv6 transition protocol, IPsec-encrypted traffic is encrypted again using SSL/TLS. This double encryption results in high processing overhead and often translates to poor performance and limited scalability. Windows 8 and later clients do not suffer this limitation, as they support null encryption which eliminates the negative effects imposed by double encryption. For the best results using IP-HTTPS, use an application delivery controller to offload SSL, or deploy Windows 8 or later clients. In any case, do not collocate the client-based VPN role on the DirectAccess server, as doing so will remove support for null encryption completely and force even Windows 8 and later clients to perform double encryption for IP-HTTPS traffic.

DirectAccess Server Configuration

To support the 6to4 and Teredo IPv6 transition protocols, the DirectAccess server must be configured with two network interfaces; one internal and one external. The DirectAccess server must have public IPv4 addresses assigned to its external network interface. For Teredo in particular, the DirectAccess server requires two consecutive public IPv4 addresses. Beginning with Windows Server 2012, DirectAccess provides support for DMZ/perimeter network deployment behind a NAT device using RFC1918 private IPv4 addresses with either one or two network interfaces. In this deployment scenario, the DirectAccess server only supports the use of the IP-HTTPS IPv6 transition protocol. 6to4 and Teredo are not available when the DirectAccess server is located behind a NAT device and these IPv6 transition protocols should be disabled on all DirectAccess clients.

Configuration Guidance for DirectAccess Security Advisory KB2862152

Introduction

Since Microsoft released security advisory KB2862152, there has been much confusion surrounding where the associated update should be installed, in what deployment scenarios it needs to be installed, and what the best way to configure it is. Recently my colleague and good friend Jason Jones and I worked together to research and answer these questions.

Overview

Microsoft security advisory KB2862152 addresses a vulnerability in IPsec that could allow an attacker to perform a man-in-the-middle attack by spoofing a DirectAccess server to intercept network traffic and potentially capture encrypted domain credentials. The associated update is designed to allow security administrators to configure DirectAccess clients to perform more rigorous validation checks when establishing the DirectAccess IPsec tunnels. It’s important to understand that without additional client-side configuration, this security update does nothing.

Windows 8 Clients

For DirectAccess deployments that use Kerberos authentication (Kerberos Proxy), the update needs to be installed on all Windows 8.x clients. No updates are required for Windows 7 clients as they are not supported using this deployment model. To enforce additional validation checks, configure the registry on the Windows 8.x DirectAccess clients with the IP addresses and Service Principal Name (SPN) of the DirectAccess server as outlined here.

Windows 7 Clients

For DirectAccess deployments that use certificate-based authentication, the update needs to be installed on all Windows 7 clients. No updates are required for Windows 8.x client using this deployment model. To enforce additional validation checks, configure the registry on the Windows 7 DirectAccess clients with the IP addresses and either the fully-qualified domain name (FQDN) of the DirectAccess server (not recommended) or the Object Identifier (OID) of the computer certificated used for IPsec authentication (recommended, with custom OID).

The choice between using FQDN or OID is a challenging one, however. Choosing to validate the DNS name is simple and straightforward, but this information may be known to an attacker, or perhaps discoverable, allowing them to spoof it. In addition, there is a limit of 10 DNS names supported using this method, which can be potentially limiting, especially in large, multi-site deployments. Using the certificate OID is even more problematic, because by default it uses a well-known Server Authentication EKU OID (1.3.6.1.5.5.7.3.1) common to many Microsoft Active Directory Certificate Services (AD CS) certificate templates which, of course, could be spoofed by an attacker even easier.

The most effective implementation of this security update for DirectAccess deployments that use certificate-based authentication is to use the OID option with a certificate configured with a custom OID. Custom OIDs are unique to your organization and will help prevent spoofing by using a unique value that is much harder to guess or determine. The remainder of this article will outline how to configure and deploy a certificate with a custom OID along with implementation details for configuring the appropriate client-side registry settings via group policy to enforce the additional validation checks.

Server Configuration

To implement this, it will require creating and deploying a new certificate template. In the Certificate Services management console, right-click Certificate Templates and choose Manage. Right-click the Computer certificate template and choose Duplicate Template. Select the General tab and give the template a descriptive name.

DirectAccess KB2862152 Implementation Guidance

Select the Extensions tab, highlight Application Policies and click Edit. Click Add and then New, and then provide a descriptive name. Leave the OID as is and click Ok to continue.

DirectAccess KB2862152 Implementation Guidance

Right-click once again on Certificate Templates and choose New and then Certificate Template to Issue. Select the certificate template you just created and click Ok.

DirectAccess KB2862152 Implementation Guidance

Once complete you can request a new certificate for each of your DirectAccess servers using this new template.

DirectAccess KB2862152 Implementation Guidance

After you have successfully installed the computer certificate using this new template, be sure to delete the old computer certificate on each DirectAccess server. No further changes are required on the DirectAccess server.

Note: If you are assigning a computer certificate to the DirectAccess server via group policy auto enrollment, the certificate will be reinstalled again after it is deleted, once group policy refreshes. To avoid this situation you will need to deny access to this GPO to ensure that only a single computer certificate with the custom OID is installed on the DirectAccess server.

Client Configuration

To instruct the client to validate the tunnel endpoint IPv6 address and the OID of the DirectAccess server certificate before initiating IPsec tunnels we’ll need to configure registry settings on our DirectAccess clients. Jason Jones’ article describes which settings need to be made and when, so I won’t duplicate his efforts here. However, it is recommended that you deploy these settings using group policy, which I will cover.

To create a Group Policy Object (GPO) to deploy these registry settings, open the Group Policy Management Console, expand the target domain, right-click Group Policy Objects and select New. Give the new GPO a descriptive name and click Ok. Right-click the newly created GPO and choose Edit. Expand Computer Configuration, Preferences, and Windows Settings. Right-click Registry and choose New and then Registry Item. Select Update for the action and HKEY_LOCAL_MACHINE for the hive. Enter

SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert

for the Key Path and enter DTE1 for the value. Select REG_MULTI_SZ for the Value Type and in the Value Data enter the IPv6 address of the first DTE. On the next line enter EKU:<OID> and click Ok.

DirectAccess KB2862152 Implementation Guidance

Repeat this procedure for each tunnel endpoint. Finally, highlight the GPO and change the Security Filtering from Authenticated Users to the security group for your DirectAccess clients and link the GPO to the domain.

DirectAccess KB2862152 Implementation Guidance

Exercise extreme caution when creating and implementing these GPOs to enforce additional validation checks. If there’s a typo somewhere or you forget a DTE, you could potentially orphan your DirectAccess clients. I recommend testing your changes by manually adding the registry entries required and then copying/pasting those settings to the GPO in Active Directory when you’re ready to deploy globally. Also, don’t forget that you’ll need to update GPOs each time you add a cluster node or multisite entry point.

How to Install and Configure KB2862152 for DirectAccess

Microsoft recently released security advisory 2862152 to address a vulnerability in IPsec that could allow DirectAccess security feature bypass. The associated update addresses an issue with how the DirectAccess client authenticates with a DirectAccess server. Without the update, it is possible for an attacker to launch a man-in-the-middle attack to intercept DirectAccess communication.

The update itself does not resolve the issue directly, however. The update simply allows administrators to configure DirectAccess clients using specific registry settings to enforce more stringent checks during IPsec negotiation after the update is installed. The challenge with this update is that the documentation contained within the knowledge base article is extremely detailed and includes information that pertains to many different remote access scenarios, not just DirectAccess. This has led to much confusion, and many administrators are unclear for which clients and deployment scenarios the registry changes are required.

For DirectAccess deployments, the update needs to be applied to all of your DirectAccess clients. The update does NOT need to be applied to the DirectAccess server. The registry settings required on the client will be dictated based on the configured authentication method for your DirectAccess deployment. If you have configured DirectAccess to use certificate-based authentication by checking selecting the Use computer certificates option as shown below, you’ll only need to make registry settings changes on your Windows 7 clients. Windows 8/8.1 clients DO NOT require any changes be made to the registry when DirectAccess is configured to use certificate-based authentication.

Microsoft Security Update KB2862152 for DirectAccess

If you are NOT using computer certificates for authentication, then you must make registry changes to all of your Windows 8/8.1 clients. For detailed, prescriptive guidance on implementing the client-side registry changes required to support this update and mitigate this vulnerability, Jason Jones has done a wonderful job documenting those steps specifically, so I’ll refer you to his post here.

You can find the update for KB2862152 for all supported clients here.

DirectAccess Computer Certificate Auto-enrollment

DirectAccess requires computer certificates to be installed on the DirectAccess server and DirectAccess clients. These certificates are used for IPsec, which provides a secure, encrypted communication channel between the DirectAccess client and the DirectAccess server. IPsec ensures the necessary integrity, confidentiality, and non-repudiation required for secure remote access. When using a Public Key Infrastructure (PKI) to issue computer certificates to DirectAccess clients, it can be helpful to automate this process by configuring certificate auto-enrollment using Active Directory group policy.

To begin, open the Group Policy Management Console and expand Domains. Next, expand your domain, right-click Group Policy Objects and choose New. Enter a descriptive name for the new GPO and click Ok. Right-click the GPO you just created and choose Edit. Expand Computer Configuration, Windows Settings, Security Settings, and Public Key Policies. Highlight Public Key Policies, and then double-click Certificate Services Client – Auto-Enrollment. For the Configuration Model choose Enabled. It is recommended that you also choose to Renew expired certificates, update pending certificates, and remove revoked certificates and Update certificates that use certificate templates.

DirectAccess Certificate Auto-enrollment

Close out of the Group Policy Editor and then link this computer certificate auto-enrollment GPO to your domain. Target only DirectAccess client and server security groups with this GPO instead of all domain computers by configuring Security Filtering to apply this GPO only to DirectAccess client and server machines.

DirectAccess Certificate Auto-enrollment

Finally, on your certificate server, right-click the DirectAccess certificate template, choose Properties, and then choose Security. Make certain the Enroll and Autoenroll permissions are set to Allow for all DirectAccess client and server security groups.

DirectAccess Certificate Auto-enrollment

 

Disconnecting DirectAccess Clients on Windows Server 2012

DirectAccess provides seamless and transparent, always-on remote network connectivity. It does this without requiring action from the user. While this is an important feature and benefit of a DirectAccess remote access solution, it can also present a challenge for security administrators when a DirectAccess client device is lost or stolen.

To prevent a DirectAccess device from establishing remote network connectivity, simply disable or delete the device’s computer account in Active Directory. This will prevent the establishment of the IPsec tunnels, which are authenticated in part using the computer account and Kerberos. The caveat here is that this will not terminate a session that is already established. In this scenario it will be necessary to also proactively disconnect the already established IPsec tunnels from the client in question. To accomplish this, open an elevated PowerShell prompt on the DirectAccess server and execute the following command:

Get-NetIPsecMainModeSA | where {$_.RemoteFirstId.Identity –like “*computer_name*”} | Remove-NetIPsecMainModeSA

For example, to terminate established IPsec tunnels for a computer name CLIENT1 the command would look like this:

Get-NetIPsecMainModeSA | where {$_.RemoteFirstId.Identity –like “*client1*”} | Remove-NetIPsecMainModeSA

When the client attempts to reestablish its connection it will fail to authenticate because its computer account is no longer valid in Active Directory. Now the trick is to get those users to tell us immediately when they’ve lost their laptops. That’s an entirely different problem, however. 😉

Special thanks for my good friend Jason Jones for his input on this solution. Thanks JJ!

DirectAccess and NAT

One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.

Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.

Windows Server 2012 DirectAccess Network Topology

Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.

So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.

Manage Out Fails for Non-ICMP Traffic with UAG DirectAccess

You may encounter a scenario in which the ability to manage out fails for DirectAccess clients using Forefront UAG 2010. You may also receive the following error:

4984 “An IPsec extended mode negotiation failed”

This can happen when custom security policies are applied to the DirectAccess client, specifically altering the settings for “Access this computer from the network“.

For more information regarding this error and how to resolve it, please refer to Microsoft Knowledge Base article 2663354.

%d bloggers like this: