Friday, 29 November 2013

How to Install and Configure KB2862152 for a DirectAccess Scenario

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:

 

 

image

 

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:

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Infrastructure
Type: REG_MULTI_SZ
Data: 2002:836b:1::836b:1 EKU:1.3.6.1.5.5.7.3.1

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
Registry name: Intranet
Type: REG_MULTI_SZ
Data: 2002:836b:2::836b:2 EKU:1.3.6.1.5.5.7.3.1

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:

image

For the EKU approach:

image

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.

Wednesday, 13 November 2013

The Evolution of Collecting DirectAccess Client Diagnostic Log Information

A common administrator question when learning to troubleshoot DirectAccess client connectivity problems is:

“How can you create a client-side diagnostic log which provides specific detail about the DirectAccess configuration, connectivity state and other relevant system information which can be used to isolate the exact problem/issue?” 

Depending on how far along the Windows evolutionary journey you are, the user experience in order to initiate the log capture process is different for specific versions of Windows. In my experience, customers often have a mixed Windows estate and therefore need to be aware of how to collect these diagnostic logs for Windows 7, Windows 8 and potentially even Windows 8.1 DirectAccess clients. Given this need, the following sections define the steps involved to collect/gather the logs for each respective version and associated considerations to be aware of.

 

Windows 7 and the DirectAccess Connectivity Assistant

First introduced as part of the Solution Accelerators series, the DirectAccess Connectivity Assistant (DCA) soon became a common component that was an essential part of any DirectAccess deployment. One of the key benefits of DCA to the administrator was that it would allow the user to create a diagnostic log, with minimal effort, which would collect relevant data and system information. This could then be sent to the administrator for offline review, or used during interactive troubleshooting assistance.

Instructions: Right-click the DCA icon in the System Tray and then select the Advanced Diagnostics option.

 

image

 

Note: If the Advanced Diagnostics option is not available, it may have been disabled by the administrator, or a support/helpdesk email address has not been defined.

Log files will be generated automatically and saved to the following location: %SystemDrive%\Users\%Username%\AppData\Local\Microsoft\DCA\

 

Windows 8 and the DirectAccess Properties Window

With the advent of Windows 8, the DCA was no longer needed as the operating system had been specifically designed to incorporate DirectAccess connectivity status and other key networking information within the View Available Networks (VAN) user interface. This negates the need to install a separate component and provides a consistent user interface where DirectAccess connectivity status can be viewed alongside all other network-related connectivity information. This was a welcome change.

Instructions: Left-click the Network icon in the System Tray to show the View Available Networks (VAN) window. Right-click the DirectAccess network entry from the list of available networks and select the View connection properties option. From the DirectAccess Properties window, click the Collect Logs button.

 

image

 

image

 

Note: If the Collect Logs button is greyed out or not available, it may have been disabled by the administrator, or a support/helpdesk email address has not been defined.

Log files will be saved to the following location: %SystemDrive%\Users\%Username%\AppData\Local\Temp\Microsoft DirectAccess Logs\

 

Windows 8.1 and the DirectAccess Modern UI

With the increased need to provide a touch-friendly interface and adhering to Modern UI design specifications, the user experience of DirectAccess connectivity status provided in Windows 8.1 has been moved to the Networks Modern UI page. This avoids unnecessary switching to desktop and maintains uniformity with the rest of the networking connections like VPN, Wi-Fi etc. The existing DirectAccess Properties windows used in Windows 8 also required the user to switch to the desktop, which could be confusing when using Modern UI applications.

Instructions: Place the mouse pointer into the bottom-right corner of the desktop, select the Settings charm and then select the Change PC settings option. From the list of available PC Settings choose the Network option and then select the DirectAccess icon from the right-hand pane of the Connections window. Finally, click the Collect button under the Logs section.

 

image

 

image

 

image

 

image

 

Note: If the Collect button is greyed out or not available, it may have been disabled by the administrator, or a support/helpdesk email address has not been defined.

Once the logs have been collected, a new email message window titled DirectAccess logs from %COMPUTERNAME%\\%DOMAIN%\%Username% - %Date% should appear. This will be rendered based upon the default email application that is defined on the Windows 8.1 DirectAccess client, and is shown below for Outlook 2013.

 

image

 

The log collection process in Windows 8.1 requires that an email program has been installed and/or a default email association has been defined, otherwise you will receive the error shown below. If the log collection process appears to be taking a long time (spinning circle) it may be necessary to switch to the desktop to actually see any errors related to the log collection process.

 

image

 

An email program and/or email association is required as the collected logs files are attached directly into a new email message window. Log files will not be saved to an obvious file location and will need to be either emailed to an administrator by clicking Send, or copied directly from the new email message window to an appropriate file location of choice. However, a copy of the collected log file can also be found in the following location: %SystemDrive%\Users\%Username%\AppData\Local\Temp with a default filename of %COMPUTERNAME%-%Date% %Time%-DirectAccess Logs.html

Tip: An alternate (easiest) way to access the DirectAccess Options screen in Windows 8.1 is to use the Search charm, typing direct into the search field and then selecting the Change DirectAccess settings option from the displayed search results.

 

image

 

So, there we have it; three different versions of Windows, three different ways to collect DirectAccess diagnostic log information. Happy log collecting DirectAccess troubleshooters!