How to Install and Configure KB2862152 for a DirectAccess Scenario

Article
11/29/2013

Microsoft recently released a security advisory titled Vulnerability in DirectAccess could allow security feature bypass which can be found here. As part of the associated security update KB2862152 which can be found here, a DirectAccess client enforces more checks in IPsec negotiation when using either certificate-based or Kerberos Proxy authentication methods. During IPsec negotiation, the DirectAccess client now checks specific attributes against a set of registry-configured values. Consequently, it is important to realise that the security update is a client-side fix that strengthens how the identity of a DirectAccess server is validated, and aims to prevent a spoof, or rogue attacker-controlled system, from posing as a legitimate DirectAccess server.

Although the information provided in the KB article is very detailed, it has raised some questions from customers that I wanted to try clarify and explain in this blog post. I have written the blog post in FAQ style to try and provide a suitable reference guide for each consideration.

Please Note: Although the advisory references DirectAccess specifically in the title, and this blog post is focused on a DirectAccess deployment, the advisory also applies to other IPsec-related scenarios like client-to-site and site-to-site VPN deployments. Therefore, these scenarios will need to be considered slightly differently, and adapted as appropriate per the KB article.

On which computers do I need to deploy the update?

The key thing to realise is that the security update is a client-side fix and for the DirectAccess scenario, only needs to be deployed to DirectAccess client computers. This is likely to cause some confusion as the article talks about Window Server operating systems, but as DirectAccess is client-to-gateway configuration, the update only actually needs to be installed on the DirectAccess client computers. However, given that a Windows Server can also act as a DirectAccess client, the KB article includes references to Windows Server operating systems. This is not a common deployment model in my experience, but I have seen this configuration used for servers located in branch offices in order to communicate with a central data centre resource. So, in summary, the security update needs to be installed on the DirectAccess client computers which will [commonly] be Windows clients, but could also [less commonly] be Windows servers.

If you are using DirectAccess in Basic Remote Access mode using the Getting Started Wizard (also known as KerbProxy mode) you will need to:

You will need to deploy the update on all DirectAccess clients running Windows 8/8.1 and you DO NOT need to install the update on the DirectAccess servers. Once installed, you will then need to make the registry changes discussed in the upcoming section. KerbProxy mode only supports Windows 8/Windows Server 2012 and later operating system versions, so this deployment mode will not need to consider Windows 7 clients.

Please Note: If you are using Windows Server 2012 or 2012 R2 servers running as DirectAccess clients, then they will also require the security update to be installed.

If you are using DirectAccess in Advanced Remote Access mode (also known as certificate-based mode) you will need to:

You will need to deploy the update on all DirectAccess clients running Windows 7 and you DO NOT need to install the update on Windows 8/8.1 DirectAccess client computers or DirectAccess servers. Once installed, you will then need to make the registry changes discussed in the upcoming section.

Please Note: If you are using Windows Server 2008 or 2008 R2 servers running as DirectAccess clients, then they will also require the security update to be installed.

On which computers do I need to make the registry changes?

You will need to make the registry changes on all DirectAccess client computers where the update has been installed. By default, the update remains disabled after installation until specific registry changes are made on the client computer in order to manually enable the update. This will ensure that DirectAccess client computers include the new validation rules. As soon as these rules are set in the registry, the update will automatically start enforcing the new rules when it establishes a tunnel with the remote DirectAccess server. Any errors in the registry configuration will cause the IPsec tunnels connections to fail and consequently break DirectAccess connectivity from the client computer.

What registry changes do I need to make?

The registry changes are specific to the DirectAccess client computers operating systems as follows:

For DirectAccess client computers running Windows 7, Windows Server 2008 or Windows Server 2008 R2, you will need to edit the registry configuration to include an IP parameter combined with either a DNS parameter, or an EKU parameter. The following rules are then applied:

If only IP and EKU parameters are configured, the DirectAccess client checks that the DirectAccess server IPsec certificate for a matching EKU object identifier (also known as OID).
If only IP and DNS parameters are configured, the DirectAccess client checks that the DirectAccess servers IPsec certificate for a matching Common Name (CN) or Subject Alternate Name (SAN).
If IP, DNS, and EKU parameters are configured, the DirectAccess client only checks the DirectAccess server IPsec certificate for a matching EKU object identifier. If the DNS parameter is also defined, it is ignored.

For DirectAccess client computers running Windows 8, Windows Server 2012 or Windows Server 2012 R2, you will need to edit the registry configuration to include an IP parameter combined with a Service Principal Name (SPN) parameter. The following rules are then applied:

When the IP and SPN parameters are configured, the DirectAccess client checks that the DirectAccess server is using a matching SPN value.

For a DirectAccess scenario, note the following:

The <ipaddrv4/ipaddrv6> parameter should reference the Dynamic Tunnel Endpoints (DTEs) of the IPsec tunnels that enable DirectAccess. DTEs represent a collection of IPv6 addresses that each identify a DirectAccess server. In a certificate-based deployment of DirectAccess, there are typically two DTEs, one for the infrastructure tunnel, and one for the intranet tunnel. If using multiple DirectAccess servers, the DTEs will represent virtual IP addresses (VIPs) which are typically used with Windows Network Load Balancing (NLB) or hardware/external load balancer network topologies. An example DTE parameter might be: 2002:836b:1:: 836b:1
The <DNS> parameter should reference the DirectAccess server internal fully qualified domain name (FQDN) and the CN/SAN defined in the the DirectAccess server IPsec certificate. If using multiple DirectAccess servers, it is necessary to add each server FQDN to the registry key as denoted by the <DNS1> and <DNS2> references in the KB article. An example DNS parameter might be: daserver.corp.contoso.com
The <SPN> parameter should reference the DirectAccess server SPN which will typically be defined as host/FQDN. If using multiple DirectAccess servers, it is necessary to add each server SPN to the registry key as denoted by the <SPN1> and <SPN2> references in the KB article. An example SPN might be: host/daserver.corp.contoso.com

In order to determine the DTE parameters for a Windows Server 2012 DirectAccess deployment, you can use the following PowerShell command:

Get-Item –Path “HKLM:\\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters”

and look for the DTE1 and DTE2 references in the results. These are the DTE values (IPv6 addresses) that will need to be used in the registry keys. For the DirectAccess scenario, it is only necessary to define the IPv6 addresses in the registry keys as DirectAccess is a pure IPv6 technology when considering the IPsec configuration (connection security rules). Consequently, IPv4 addresses are not relevant for this scenario.

The DNS and SPN parameters should be quite easy to determine based upon the computer name and FQDN of the DirectAccess server(s). The IPsec certificate should also be checked to ensure the DNS name of the certificate will match that defined on the DirectAccess client computer registry entries.

Do I need to do anything else?

The security update has a dependency on the DirectAccess server certificate in order to meet the new client-side validation rules. Therefore, if you have used an IPsec certificate on the DirectAccess server that DOES NOT contain an Enhanced Key Usage (EKU) field/property, then you will need to replace the certificate with one that does, before making the registry changes on DirectAccess client computers. The DirectAccess server hosting this certificate can be running Windows Server 2008 R2, 2012, or 2012 R2. In general, if you are using a Microsoft CA and follow the guidance of creating a certificate template that has been duplicated from the default Computer certificate template in order to issue a suitable certificate, then the IPsec certificate should contain the correct EKU values to meet the client-side validation process. More information on these aspects can be found here and here.

How do I know if the registry changes have worked?

If after making the registry changes, you can still connect to corporate resources from a DirectAccess client that is located outside your internal network then you should be good to go. This can be confirmed several ways; by looking at the DirectAccess connection status of ‘Corporate Connectivity is Available’ in DCA (Windows 7), a ‘Connected’ state in NCA (Windows 8) or from looking at the client connections view in the Remote Access management console. If you can no longer connect, then something went wrong with the registry changes, or the IPsec server certificate is not configured correctly to match the registry values. The troubleshooting section provided in the KB article can be used to look for errors in IPsec logging information and also the general guidance provided here.

Can I see a working example?

So, the best way to understand the configuration is to see how it would be applied to a real-world scenario. So, let’s assume we have the following DirectAccess deployment:

This deployment is using the more common Advanced Remote Access model (certificate-based) with the DTE, DNS and EKU values as shown in the diagram. Note that the DNS parameter is NOT the IP-HTTPS FQDN, it is the internal FQDN of the DirectAccess server computer object within Active Directory. The EKU used in this example is the standard EKU OID for Server Authentication (1.3.6.1.5.5.7.3.1) but could in theory be a custom OID that is defined in the DirectAccess IPsec certificate.

This DirectAccess deployment would result in the following registry changes on the DirectAccess client computers:

For DNS approach:

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Infrastructure
Type: REG_MULTI_SZ
Data: 2002:836b:1::836b:1 daserver.corp.contoso.com

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Intranet
Type: REG_MULTI_SZ
Data: 2002:836b:2::836b:2 daserver.corp.contoso.com

For EKU approach:

Please Note: The data separators can be "space" or "tab" or a "new line" but I would personally use a new line for each entry.

Graphically these registry changes can be seen as shown below.

For the DNS approach:

For the EKU approach:

A similar approach can be used for Basic Remote Access mode deployments (KerbProxy) by simply using the SPN parameter instead of the DNS parameter in the above example. As a Basic Remote Access deployment only uses a single IPsec tunnel, it will only be necessary to define a single registry key value and the registry subkey will defined as Kerberos and not Cert e.g. HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Kerberos

I hope the above information clarifies and compliments the original KB article and provides some exemplar guidance on configuration of the registry keys based upon an actual working scenario.

Props: Thanks to Ioan Corcodel and Nithin Jose (Microsoft guys) for their assistance with providing a lot of the above information.

Comments

Anonymous
January 01, 2003
The client simply needs a certificate with Client Authentication EKU which is a standard requirement. Assuming you have that, you then just need the reg keys. Are you using the standard Server Auth EKU or a custom one? The latter is preferred as per the article Rich and I did.
Anonymous
January 01, 2003
You only need the custom EKU in the DirectAccess server IPsec certificates, not the client certificates. It is only the client which does the EKU validation check. The risk here is that of a spoof DirectAccess server, not client. The client simply needs a certificate with the Client Authentication EKU to validate its own identity.
Anonymous
January 01, 2003
I'm using a custom one... however looking at the local certificates installed in one of my clients, I noticed that there 2 Client Authentication certificates, one of them is used by ConfigMgr Client, and the other one is the one for DirectAccess, with the customized EKU. If I remove the one for DirectAccess, it looks like IPSec is still validating the Client with the one used by ConfigMgr Client... even after changing the registry keys. Does it make sense?
Anonymous
January 01, 2003
Hi Jason, I have updated the certificate in the Server in order to use EKU, however does the client (in a Windows7 deployment) require any certificate, or just the new registry keys are enough?
Anonymous
December 02, 2013
The comment has been removed
Anonymous
December 02, 2013
The comment has been removed
Anonymous
December 03, 2013
The comment has been removed
Anonymous
December 03, 2013
The comment has been removed
Anonymous
January 07, 2014
The comment has been removed

Share via