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.

Leave a comment

8 Comments

  1. Anthony

     /  January 7, 2014

    If we are only using Windows 8 and 8.1 clients then all we need to do is install the KB on the clients if we are using certificate authentication? This post is more for Windows 7 clients. Right?

    Reply
    • That’s correct. This post is focused on the best configuration for certificate-based authentication and would only affect Windows 7 clients. The update would not be required on Windows 8.x clients when certificate authentication is used.

      Reply
  2. The Cuq!

     /  January 10, 2014

    Hi Richard!, great post! just a quick one for you… does the client (in a Win7 deployment) need to get the new certificate as well in order to validate the EKU? or is it just the server that needs the new cert? Thanks!

    Reply
    • No changes required on the client’s machine certificate. Just make sure that your computer certificate installed on the DirectAccess server has the EKU property.

      Reply
  3. TK

     /  January 10, 2014

    Do I understand it correctly that the safety of directacess against man-in-the-middle attack is based on the attacker does not know the custom OID used in certificate on the server? OID that are freely readable by all users on all machines configured with directacess.

    Reply
    • It’s important to understand that there is no *absolute* protection against a man-in-the-middle attack by implementing this feature. To be clear, I’m stating that using a custom OID makes it *more difficult* for an attacker to mount this type of attack blindly. Yes, a custom OID could still be discovered by an attacker with access to the DirectAccess server or from a client with an established DirectAccess connection, but at that point they already have access to your network so what’s the point of a MITM attack?

      Reply
  4. Lennarth B

     /  March 4, 2016

    Hi Richard

    Is this for Windows 10 as well or is this included in Windows 10?

    Best Regards,

    Lennarth B

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: