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

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:

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.

“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.

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.

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.

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.

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.

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.

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

A common requirement, or ask, for many DirectAccess deployments is the need to remotely manage DirectAccess clients when they are away from the corporate network. This functionality is often termed ‘manage out’ and is one of the major benefits of a DirectAccess solution when compared to traditional VPN remote access solutions. The ability to reach a managed client, irrespective of their location, irrespective of whether they are logged in, is a power tool for IT administrators.

However, the need for corporate connected manage out clients to be IPv6 capable often presents a challenge when not running IPv6 within the intranet environment. This challenge is often met by configuring an intranet IPv6 transition technology called Intra-Site Automatic Tunnel Addressing Protocol, or ISATAP for short.

Unfortunately, the ISATAP mechanism uses a hard coded DNS lookup process that is automatically enabled on on Windows Vista and above operating systems. This DNS lookup requires the creation of a global ‘isatap.domain.com’ DNS host record, and this will ultimately enable ISATAP by way of an ISATAP router,. The router will automatically assign IPv6 addressing and prefix information, across the entire Windows Vista+ environment. In some scenarios, enabling IPv6 support globally using ISATAP is desirable, but for many deployments, adding IPv6 capabilities to all Windows systems is not desirable; especially when Windows will naturally favour IPv6 communications over IPv4. For many customers, the cultural change this IPv6 preference brings to a desktop and/or server administrator is more than a little confusing, and definitely not something that should be enabled globally without some thought.

So, how do we provide the IPv6 capabilities required for DirectAccess manage out clients, whilst still preserving a more traditional IPv4 experience for other Windows systems?

The main way to solve this problem is to move away from using the global ‘isatap.domain.com’ DNS host record that is hard coded into all Windows Vista+ systems, and use a custom ISATAP router name that is specific to your environment. With this DNS host record created, all we need to then do is enable specific clients to use this custom ISATAP router name and we have a mechanism of controlling ISATAP on our terms.

Please Note: An alternate approach using HOSTS files is feasible for very small deployments, but this has limited scalability and does not allow for the creation of an ISATAP DNS record that contains a VIP and multiple DIPs, as required when using a DirectAccess cluster. Therefore this approach is not recommended outside of a lab environment.

In my opinion, the best way to achieve this technically is by way of Group Policy and a dedicated Windows security group for manage out clients, as follows:

Step 1: Create a Custom ISATAP DNS Record

Create a new DNS record called [something]isatap.domain.com, or similar. Configure this DNS record to point to the internal IP address of the DA server. If using a cluster, you will need to defined the record multiple times; once for each DA cluster member internal IP address, and once for the internal cluster VIP.

Please Note: As the ISATAP router name is customised, it will not be necessary to remove this name from the default DNS block.

Step 2: Create a Windows Security Group

Create a new Windows security group called DirectAccess Manage Out Clients, or similar.

Step 3: Create a New Group Policy

Using GPMC, create a new group policy object called DirectAccess: Manage Out Clients (Enable ISATAP) or similar, with the following properties:

Under the Scope tab, remove Authentication Users from the Security Filtering section and add the Windows security group created above; DirectAccess Manage Out Clients in our example.

Under the Details tab, set the GPO Status to User configuration settings disabled

Edit the newly created GPO and define the following settings:

Computer Configuration | Policies | Administrative Templates | Network | TCPIP Settings | IPv6 Transition Technologies

ISATAP Router Name: Enabled

Enter a router or relay name: [something]isatap.domain.com

ISATAP State: Enabled

Select from the following states: Enabled State

Once completed, this should result in the following output in the Settings tab:

Step 4: Add Computer Accounts to Windows Security Group

All that now needs to be done is to add the computer accounts for machines that will be used for remote management of DirectAccess clients to the DirectAccess Manage Out Clients Windows security group.

Please Note: It will be necessary to reboot clients and servers after adding them to the DirectAccess Manage Out Clients windows security group before the new GPO will be applied.

Once this has been done, the specific manage out clients that you have defined by group membership should now receive ISATAP addressing and prefix information making them IPv6 capable.

Once configured correctly, you should receive a 2002:WWXX:YYZZ:8000:5efe:w.x.y.z format address (or similar) on the ISATAP adapter and will be able to remotely manage DirectAccess clients from this predetermined group of manage out machines.

Please Note: If the ISATAP adapter address assignment is not successful, it may also be necessary to use the following command to refresh the adapter state: sc control iphlpsvc paramchange

Hope this helps!

[This article has been adapted from a previous UAG DirectAccess blog post and hence screenshots may show UAG references which can be ignored]

Enjoy and great work Colin, I wish I had written it! :)

You can find the guide hosted on Tom’s ‘Building Clouds’ blog here: Troubleshooting DirectAccess Manage Out Connections

Please Note: The approach provided within this blog post is not suitable when using an External Load Balancer (ELB) or a multisite DirectAccess topology and you will need to use a more traditional native IPv6 deployment where you define your own IPv6 prefixes which are entered as part of the DirectAccess wizard configuration process.

I wrote a previous blog article titled Limiting ISATAP Services to UAG DirectAccess Manage Out Clients some time ago now which proved to be quite popular as a way to allow manage-out functionality for UAG DirectAccess solutions without effecting the entire network through the use of wide spread ISATAP enablement. That article originated as many people weren't aware that in order to manage DA clients from an intranet machine, it needed to be IPv6 capable (read native IPv6 or using a transition technology like ISATAP). Given the use of ISATAP you needed to be a little careful with how best to enable it for a subset of management clients, otherwise there was potential to impact the entire internal network and bad stuff can happen.

Given the advent of Windows Sever 2012 DirectAccess and the new Unified Remote Access role, Microsoft no longer recommends the use of ISATAP to facilitate manage out scenarios in favour of using native IPv6. This statement is discussed here and appears to be the general MS recommendation given the potential problems associated with ISATAP deployments that can, and often do, go wrong. The likely first reaction to that news is likely to be “…but I don’t understand IPv6 and our intranet doesn’t have it enabled or configured yet, so how do I do that?” or “…why can’t I just stick with ISATAP? It seems easier”. Both of these reactions are understandable, but I wanted to provide an example to show that it isn’t actually that scary and it is potentially even easier to implement than the old ISATAP method, especially for a small number of management clients. Nobody is saying that you can’t use ISATAP; in fact the ISATAP router functionality is still enabled by default on the DA server when using an IPv4 address on the internal network adapter. Although the DA Server is configured as an ISATAP router by default, it should be noted that it will not service clients until the necessary ISATAP DNS A record has been created and the entry removed from the DNS global query blocklist. However, maybe it is time to start thinking about that historic ‘ISATAP or native IPv6’ decision process and the primary reason that I am writing this blog post :)

Please Note: The obvious caveat, or limitation, here is that the communication path (read network infrastructure) between the management client and the DA server will need to support (be able to forward) native IPv6 traffic. This is likely to be very environment specific and may need to be tested, or involve discussions with your network guys to understand if this is a viable option. For example, an IPv4-only back firewall is a good example of something that may prevent the use of native IPv6 for manage out. For networks that cannot support native IPv6, some form of IPv6 encapsulation or transition technology will need to be used (using the method discussed in my previous blog post perhaps).

So, what does it mean to use native IPv6 for managing DA clients from the intranet then? Well, in it’s simplest form it means manually configuring your management clients with static IPv6 addresses from a suitable IPv6 prefix and then providing the appropriate IPv6 routing to reach DA clients by way of the DA server they are connected to. For this blog post, this is the example I am going to use to begin with and is based around the same premise as my last article; namely that the number of management clients involved is usually pretty small, or involves the use of ‘jump hosts’ that are shared by admin/support staff. Hence, the plan is to keep things simple for now and continue with the use of manual IPv6 configuration to describe the overall concept. At this juncture, it may also be useful to know that I wrote a basic overview of IPv6 addressing choices for DirectAccess in a previous blog post here which may also prove useful if you considering a more automated approach to IPv6 configuration.

When DirectAccess is installed, a 6to4-based organisation prefix is created automatically using the following IPv6 prefix format 2002:WWXX:YYZZ:3333::/64 where WWXX:YYZZ are the hexadecimal representations of the primary public IPv4 address octet pairs bound to the external network adapter of the DA server (with the IPv4 address formatted as WW.XX.YY.ZZ). So, using an example where the primary public IPv4 address is: 131.107.0.2 this would result in a 6to4 prefix of: 2002:836b:2:3333::/64 as 131 in hex is 83, 107 is 6b and 2 is 2.  

Please Note: If you are using your DirectAccess server behind a NAT device and consequently using private IPv4 addresses on the external network adapter, as opposed to public IPv4 addresses, the IPv6 prefix will be in the form of: FD##:####:####:7777::/96 as per RFC 6147. The DA client IPv6 prefixes for Teredo and IP-HTTPS will also follow a similar structure when using private IPv4 addresses.

Still with me? If so, let’s move on…

Given this IPv6 prefix, we can now use this to generate static IPv6 addresses for the management clients using the format 2002:836b:2:3333::# where # is a manually chosen unique number used by each management client. By default the DA server will automatically use the 2002:WWXX:YYZZ:3333::1 address, so anything above this value should be fine as long as though it is unique and not in use. Furthermore, when defining the static IPv6 address, the subnet prefix length will normally be 64.

So with the static IPv6 address defined, all we need to do now is consider how we ensure that IPv6 traffic can reach the DA clients that are connected to the DA server. This is achieved in two ways; by defining an IPv6 default gateway, or by defining specific individual IPv6 static routes. Focusing on the first option, as mentioned, for our example the DA Server will be assigned a static address of 2002:836b:2:3333::1 so we can simply define this as the IPv6 default gateway on management clients. The final result is shown below:

Making the DA server your default IPv6 gateway may not be desirable, or recommended in most cases. Therefore, as an alternative approach you may wish to be more specific and ensure that only IPv6 prefixes that are used by DirectAccess clients are routed to the DA server by way of specific IPv6 static routes. This provides much better control over IPv6 routing and allows for specific DA client management traffic to be considered without impacting on other IPv6 services. This is achieved by defining the static routes, on each management client, to cover necessary DA client IPv6 prefixes, as opposed to defining a global/single IPv6 default gateway. For our example, these include:

IP-HTTPS Clients Prefix: 2002:836b:2:1000::/64

Teredo Clients Prefix: 2001:0:836b:2::/64

Turning these IPv6 prefixes into IPv6 static routes, we get the following respective commands based upon our example above:

netsh int ipv6 add route 2002:836b:2:1000::/64 [Name of Intranet network adapter] 2002:836b:2:3333::1

netsh int ipv6 add route 2001:0:836b:2::/64 [Name of Intranet network adapter] 2002:836b:2:3333::1

Please Note: Sharp eyed readers may have noticed that I have not mentioned 6to4 clients. The reasoning behind this decision is that the 6to4 transition technology only works when the DA client has a public IPv4 address (which is a typically rare scenario nowadays) and issues often occur in networks where the DA client gets a public IPv4 address but cannot actually reach the 6to4 relay due to some form of in-path NAT. For these reasons, it is recommended practice to disable the 6to4 transition technology on DA clients and therefore it is not covered above.

At this point, those of you more familiar with IPv6 may be thinking “…is this guy mad? Why is he defining static IPv6 addresses??!!” Well, firstly, it makes things simple for the given example and in reality if you only have a small number of management clients (or ‘jump hosts’) it is actually quite feasible to use static addresses. This approach requires no additional network infrastructure, or network configuration for IPv6, and is actually pretty quick and easy to do. The obvious problem here is that this admin overhead doesn’t scale well and the IPv6 protocol was specifically designed to use a concept of automatic address selection and static addressing is therefore pretty much a thing of the past. However, as discussed, we are dealing with a very specific example, trying to keep things simple and we are not designing IPv6 for the entire intranet.

In the event that you have a larger number of management clients, or just feel that static configuration is not appropriate for your environment, it is better to use some form of IPv6 auto-configuration mechanism in order to provide management clients with addressing information and route assignment, without the need for human intervention. IPv6 auto-configuration can be performed by any capable Layer 3 network device (which includes a Windows Server) although as discussed, this is out of the scope of this blog post at this time. However, it may be interesting to note that the necessary steps for using a Windows Server to provide IPv6 auto-configuration have been covered in one of my previous blog posts here.

Now we have management clients with IPv6 addressing information and the appropriate IPv6 routing table entries, we can hopefully begin managing DA clients from the intranet. At this stage you should be able to ping a remotely connected DA client from a management machine and receive an IPv6 response, assuming there is a route to the destination and ICMP echo requests are enabled in the firewall.

Important: Ping is helpful to verify that basic connectivity is working and validate you management client IPv6 configuration parameters, however, should only ping work but not any other type of connection then it’s most likely to be an IPsec-related issue. This is because ICMP is exempted from the DirectAccess IPsec tunnels and therefore provides limited value when testing connectivity from management clients to DA clients. More discussion on this topic cab be found here.

Before we can have a fully working solution it may also be necessary to consider a few additional steps, which based upon my own experience, are not totally obvious and can easily be forgotten.

If you have defined new IPv6 addresses on System Center Configuration Manager servers, it will be necessary to use the Refresh Management Servers option in the Remote Access Management console, as shown below, in order for the new IPv6 address information to be added to the DirectAccess clients GPO:

The same thing is true for Domain Controllers, but I am guessing that you will not be defining these as specific management clients. Furthermore, implementing IPv6 addressing on Domain Controllers introduces additional considerations to Active Directory functionality and operation which are key to ensure services are not impacted.

For all other management clients, it will be necessary to manually add each of them to the Management servers list which can be found in the Step 3: Infrastructure Servers section of the Remote Access Management console as shown below:

Once entries have been added, the updated configuration can be committed using the Finish… button.

The final task is to run gpupdate /force on management clients and DA clients to ensure they get updated GPOs which have been modified by the changes described above. Alternatively, you can wait for the next Group Policy refresh cycle but I’m normally kinda impatient!

Please Note: Don’t forget that it will still be necessary to define Windows Firewall with Advanced Security (WFAS) inbound rules on the DA clients to allow for the necessary permitted network access as discussed here.

All being well, you should now be able to initiate outbound management requests to DA clients from management clients on the intranet without necessarily have to resort to ISATAP and hopefully you have a little more confidence that using native IPv6 is not quite so scary after all :)

Now, go manage out with native IPv6!

P.S. Special thanks to Philipp Kuhn for the article inspiration and technical review assistance!

PLEASE NOTE: Microsoft have now provided an official dynamic knowledgebase article which provides a summary of Windows 7, Windows 8 and Windows Server 2012 hotfixes which can be found here: https://support.microsoft.com/kb/2883952 and consequently supersedes the below information.

Last updated 14/08/13 with KB2849568.

Hotfixes: Windows 8 and Windows Server 2012

KB2859347: IPv6 address of a DirectAccess server binds to the wrong network interface in Windows Server 2012.

KB2855269: Error message when you use an account that contains a special character in its DN to connect to a Windows Server 2012-based Direct Access server.

KB2849568: Vulnerability in the Windows NAT driver could allow denial of service: August 13, 2013.

KB2845152: DirectAccess server cannot ping a DNS server or a domain controller when a DirectAccess client is pinging the same server in Windows Server 2012.

KB2844033: DirectAccess Setup Wizard fails on a Windows Server 2012-based server in a domain that has a disjoint namespace.

KB2836232: Subnet mask changes to an incorrect value and the server goes offline in DirectAccess in Windows Server 2012.

KB2796394: Error when you run the Get-RemoteAccess cmdlet during DirectAccess setup in Windows Server 2012 Essentials.

KB2795944: Windows 8 and Windows Server 2012 cumulative update: February 2013. This update includes fixes for DA that provide stability under heavy load.

KB2788525: You cannot enable external load balancing on a Windows Server 2012-based DirectAccess server.

KB2782560: DNS64 does not resolve computer names when you use DirectAccess and external load balancing in Windows Server 2012.

KB2769240: You cannot connect a DirectAccess client to a corporate network in Windows 8 or Windows Server 2012.

KB2748603: The process may fail when you try to enable Network Load Balancing in DirectAccess in Window Server 2012.

KB2666914: DirectAccess Connectivity Assistant 2.0 is available.

Hotfixes: Windows 7, Windows Server 2008 R2 and Forefront UAG 2010

KB2797301: A Forefront Unified Access Gateway 2010 DirectAccess client experiences repeated OTP prompts.

KB2796313: Long reconnection time after a DirectAccess server disconnects a Windows 7-based DirectAccess client.

KB2758949: You cannot build an IP-HTTPS protocol-based connection on a computer that is running Windows 7 or Windows Server 2008 R2.

KB2718654: You are prompted to enter credentials when you try to access a SharePoint server on a Windows 7 SP1-based or Windows Server 2008 R2 SP1-based computer.

KB2680464: Location detection feature in DirectAccess is disabled intermittently in Windows 7 or in Windows Server 2008 R2.

KB2663354: DirectAccess Manage Out fails for any non-ICMP traffic in Forefront Unified Access Gateway 2010.

KB2633127: DA client cannot reconnect to the UAG DA server when a Windows 7-based or Windows Server 2008 R2-based client computer is connected to the Internet.

KB2615847: "ERROR_IPSEC_IKE_CERT_CHAIN_POLICY_MISMATCH" error when you try to start an IPsec connection between two computers that are running Windows 7 or Windows Server 2008 R2

KB2535133: IP-HTTPS clients may disconnect from Windows Server 2008 R2-based web servers intermittently after two minutes of idle time.

KB2444558: You cannot access a host that is hosting the IPv4 file share by using SMB v1 from a Windows 7-based or Windows Server 2008 R2-based DirectAccess client.

KB2288297: You are unexpectedly prompted to enter your credentials when you try to access a WebDAV resource in a corporate network by using a DirectAccess connection in Windows 7 or in Windows Server 2008 R2.

KB979373: The DirectAccess connection is lost on a computer that is running Windows 7 or Windows Server 2008 R2 that has an IPv6 address.

KB978738: You cannot use DirectAccess to connect to a corporate network from a computer that is running Windows 7 or Windows Server 2008 R2.

KB974080: DirectAccess Workaround for reaching IPv4 address checking sites.

KB973982: The certificate for IP-HTTPS does not rebind if the certificate is changed after the configuration is applied one time in Windows Server 2008 R2.

KB972516: A DirectAccess access failure occurs after the DNS servers that are running Windows Server 2008 return empty responses for AAAA queries in a WINS zone.

Security Updates: Windows Server 2008 R2 and Windows Server 2012

KB2765809: Vulnerability in IP-HTTPS component could allow security feature bypass (MS12-083).

Hope the list is useful!

Notes and small print:

Items in red represent significant improvement or changes.

¹PKI is still mandatory for force tunnelling, Network Access Protection (NAP) integration or two-factor authentication deployment scenarios. A PKI-based solution is therefore still required for some enterprise-class deployments, dependent on the required features. 

²Hyper-V failover cluster is required.

³Smartcard only.

⁴IP-HTTPS is supported, but there is a performance overhead due to combined/double SSL and IPsec encryption. IP-HTTPS in Windows Server 2012 now support null SSL encryption and additional optimisations but requires Windows 8 clients.

⁵Complicated setup due to IPv6 requirements.

⁶Global Server Load Balancer (GSLB) is required.

⁷Automatic DirectAccess entry-point detection or user selected entry-point requires Windows 8 clients.

⁸Technically works, but the supportability status is currently unknown (full support provided in UAG SP3).

⁹Read-only PowerShell.

¹⁰Command line via PowerShell only.

As highlighted above, Windows Server 2012 offers the most feature-rich platform when compared to previous versions and can be considered as a superset of the functionality provided by the Forefront UAG SP1 offering. Many of the enhancements included in Windows Server 2012 DirectAccess are based upon direct feedback from customers and changes to facilitate easier adoption and deployment of the technology within both smaller organisations and enterprise environments alike. I am planning on creating two upcoming blog posts which will highlight the changes and benefits in Windows Server 2012 DirectAccess from the perspective of the smaller organisation and then also for the enterprise space. Given the improvements and changes, I think DirectAccess will be even more popular than ever…what do you think?