Installing and Configuring DirectAccess Connectivity Assistant 2.0 on Windows 7 Clients

When DirectAccess first appeared as a feature in Windows Server 2008 R2, one of the challenges was determining quickly and easily if a DirectAccess client had successfully established remote network connectivity, and more importantly if that connection was unsuccessful or had dropped for any reason. To address this issue, Microsoft released the DirectAccess Connectivity Assistant (DCA) version 1.0, first introduced in February of 2010 as part of the Windows Optimized Desktop Toolkit. It has been updated a number of times since its initial release, and in Windows 8 the DCA functionality is now part of the base operating system. The DCA is helpful from a diagnostic and troubleshooting perspective, as it provides an intuitive visual indicator for DirectAccess connectivity status. More importantly, the DCA is required to support One-Time Passwords (OTP).

As of this writing, the latest version of the DCA is version 2.0, which can be downloaded here. DCA 1.0 and 1.5 are both supported with Windows Server 2012 DirectAccess, unless you need to provide support for OTP, which of course will require DCA 2.0. It is possible to perform an in-place upgrade from DCA 1.5, but if you’ve deployed DCA 1.0 you’ll have to uninstall prior to installing DCA 2.0. It’s important to understand that DCA 2.0 is explicitly NOT supported with Windows Server 2008 R2 DirectAccess or Server 2008R2/Forefront UAG DirectAccess. In addition, the DCA 2.0 MSI installation package can be deployed automatically using Active Directory Group Policy, System Center Configuration Manager, or any other third-party software distribution tool.

To install and configure DCA 2.0 on your Windows 7 DirectAccess clients, download DCA 2.0 and extract all of the files, then run the either the 32 bit or 64 bit version of the MSI on the client, depending on your operating system. The settings for the DCA are managed exclusively with group policy, so once you’ve installed DCA 2.0 on the client, log on to a domain controller and copy the file DirectAccess_Connectivity_Assistant_2_0_GP.admx to the C:\Windows\PolicyDefinitions folder. In addition, copy the file DirectAccess_Connectivity_Assistant_2_0_GP.adml to the C:\Windows\PolicyDefinitions\en-US folder. Next open the Group Policy Management Console and create a new Group Policy Object (GPO) for your Windows 7 DCA settings. Right-click the GPO and choose Edit.

directaccess_dca2_windows7_001

In the Group Policy Management Editor expand Computer Configuration, Policies, and Administrative Templates and then highlight DirectAccess Connectivity Assistant. Double-click Support Email, select the option to enable the setting and enter an e-mail address. This setting is optional, but is required if you want to allow your remote DirectAccess users to e-mail client logs to a helpdesk administrator.

directaccess_dca2_windows7_02

Click Next Setting to configure the DirectAccess Dynamic Tunnel Endpoints (DTEs). Select the option to enable the setting, then click the Show button. To ensure that you are using the correct DTEs, I suggest collecting this information from the registry of the DirectAccess server by opening an elevated PowerShell prompt on the DirectAccess server and issuing the following command…

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

…and note the entries for DTE1 and DTE2. Copy these addresses to the GPO setting using the syntax PING:<DTE_IPv6_Address>.

directaccess_dca2_windows7_03

directaccess_dca2_windows7_04

Click Next Setting to configure LocalNamesOn. This setting is optional, and when enabled will allow the DirectAccess client to use local name resolution, which effectively disables DirectAccess connectivity on the client side.

directaccess_dca2_windows7_05

Click Next Setting to configure Corporate Resources. Select the option to enable the setting and click Show. This setting enables a health check from the DirectAccess client to this resource to determine if the DirectAccess tunnels are up and that corporate network access connectivity is indeed working correctly. You can use ping, UNC file path, or an HTTP URL. I prefer to use the HTTP method as it seems to be the most reliable. Any internal web server will work, but keep in mind that if it is unavailable for any reason the DCA will indicate that network connectivity is not available when in fact it is working correctly. For that reason I’d suggest selecting a highly available (load balanced) internal web server if possible. DO NOT use the network location server (NLS) for this connectivity check. The syntax for this setting is HTTP:<internal_webserver_URL>. It is also recommended that you use the server’s FQDN when configuring this setting. You can also specify an IPv6 address, but an IPv4 address will not work.

directaccess_dca2_windows7_06

Click Next Setting to configure the Admin Script Location. This setting is optional and used only if you want to run a custom script on the Windows 7 DirectAccess client to gather additional information used for troubleshooting.

directaccess_dca2_windows7_07

Once complete, right-click WMI Filters in the Group Policy Management Console and choose New.

directaccess_dca2_windows7_002

Provide a descriptive name for the new WMI filter and click Add. Enter the following WMI query and click Ok.

select * from Win32_OperatingSystem where Version like "6.1%"

directaccess_dca2_windows7_003

Finally, edit the Security Filtering for this GPO by removing Authenticated Users and adding the DirectAccess client security group. In addition, link the GPO to the WMI filter for Windows 7 clients. Once complete, link the GPO to the domain.

directaccess_dca2_windows7_004

After you’ve completed the DCA group policy settings, refresh group policy configuration on the client by issuing a gpupdate /force command from an elevated command prompt. The DCA should now indicate that corporate network connectivity is working correctly.

directaccess_dca2_windows7_08

SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP

From a client perspective, DirectAccess is an IPv6 only solution. It requires IPv6 connectivity from end-to-end to provide seamless, transparent, always-on remote access. DirectAccess clients are most commonly connected to the IPv4 Internet, so to overcome the limitations imposed by the exclusive use of IPv6 for transport, DirectAccess leverages IPv6 transition technologies such as 6to4, Teredo, or IP-HTTPS to tunnel IPv6 DirectAccess client communication over the IPv4 Internet. These transition protocols are favored by the operating system in the order in which I have listed them here. 6to4 uses IP protocol 41 for transport and requires that the client have a public IPv4 address, so if the DirectAccess client is behind a firewall that does not allow outbound IP protocol 41, or is located behind a NAT and has a private IPv4 address, it will fall back to Teredo. Teredo uses UDP for transport on port 3544, and if this communication is blocked by a firewall the DirectAccess client will then fall back to IP-HTTPS. IP-HTTPS, as its name implies, tunnels DirectAccess IPv6 traffic in HTTP, which is authenticated and encrypted using SSL or TLS.

Historically the challenge with the IP-HTTPS IPv6 transition protocol is that it encrypts DirectAccess communication which is already encrypted using IPsec. This double encryption places significant demands on CPU and memory resources on the DirectAccess server, resulting in poor throughput and performance and limiting the overall scalability of the solution. To address these shortcomings, Windows Server 2012 DirectAccess introduced support for IP-HTTPS NULL encryption. SSL/TLS is still used for authentication, but the IPsec traffic is no longer double encrypted. This dramatically reduces resource consumption on the DirectAccess server, resulting in improved performance and allowing many more DirectAccess clients to be handled by a single server. The only drawback is that IP-HTTPS NULL encryption is only supported with Windows 8 clients. When Windows 7 clients connect to a Windows Server 2012 DirectAccess server using IP-HTTPS, they will continue to use encrypted IP-HTTPS.

An ideal solution would be to terminate SSL off box using a dedicated hardware appliance like the F5 BIG-IP Local Traffic Manager (LTM). Unfortunately there is no provision in Windows Server 2012 DirectAccess to enable SSL termination for IP-HTTPS traffic. However, using some of the advanced features of the LTM, we can effectively offload SSL on the F5 by configuring LTM to emulate Windows 8 DirectAccess client behavior. This is accomplished by having the F5 LTM exclusively negotiate the use of a NULL encryption cipher suite with the Windows Server 2012 DirectAccess server on behalf of Windows 7 DirectAccess clients.

Note: This post assumes that you are familiar with the configuration and management of the F5 BIG-IP LTM solution, and that you’ve already imported your SSL certificates and configured nodes, pools, and virtual servers for your Windows Server 2012 DirectAccess server.

To configure the F5 LTM to provide SSL offload for Windows 7 DirectAccess clients, we’ll need to create SSL profiles to allow the use of specific cipher suites for our IP-HTTPS traffic. In its default configuration, the BIG-IP LTM does not support the use of NULL encryption cipher suites. Since Windows 8 DirectAccess clients use NULL cipher suites exclusively, we need to explicitly enable these on the LTM to support our Windows 8 clients. Since our Windows 7 clients will use only encrypted cipher suites, we’ll be sure to include those as well. To do this, open the F5 management console, expand Local Traffic, Profiles, SSL, and then click the green icon next to Client.

f5_directaccess_iphttps_offload_01

Provide a name for the new Client SSL Profile, select Advanced configuration, check the Custom box and specify DEFAULT:NULL for Ciphers. Be sure to select the appropriate SSL certificate and key. Click Finished at the bottom of the screen to save these settings. This change allows NULL cipher suites in addition to encrypted cipher suites, allowing us to support both Windows 8 and Windows 7 DirectAccess clients.

f5_directaccess_iphttps_offload_02

Next we need to configure the LTM to use only NULL cipher suites when communicating with the Windows Server 2012 DirectAccess server. To do this, expand Profiles, SSL, and then click the green icon next to Server.

f5_directaccess_iphttps_offload_03

Provide a name for the new Server SSL Profile, select Advanced configuration, check the Custom box and specify NULL-SHA for Ciphers. Click Finished at the bottom of the screen to save these settings. The end result here will be to force the exclusive use NULL encryption cipher suites for all IP-HTTPS traffic, regardless if it is a Windows 8 or Windows 7 client.

f5_directaccess_iphttps_offload_04

Once you’ve completed the client and server SSL profiles, it will be necessary to assign these profiles to the virtual servers that represent your Windows Server 2012 DirectAccess server. Navigate to Virtual Servers and click on Virtual Server List. Click the virtual server that corresponds to your DirectAccess server, and then scroll down to the bottom of the page. For SSL Profile (Client), select DA_IPHTTPS_CLIENT and add that to the list. Repeat this step for the SSL Profile (Server), this time selecting DA_IPHTTPS_SERVER. Click Update to apply these changes.

f5_directaccess_iphttps_offload_05

Once complete, the F5 BIG-IP LTM will now effectively be offloading SSL traffic on behalf of Windows 7 DirectAccess clients by emulating the Windows 8 DirectAccess client behavior and using only NULL encryption for IP-HTTPS sessions established with the Windows Server 2012 DirectAccess server. Although I can see no issues with this deployment model, be advised that this configuration may not be supported by Microsoft, so make these changes at your own risk. I’ll be working with Microsoft and F5 to get this solution reviewed and tested and I will provide clarification on supportability here once I have that information.

Special thanks to Jeff Bellamy, Ryan Korock, and John Wagnon at F5 for their assistance with this developing solution.

DirectAccess Session at Microsoft TechEd 2013

This month I had the honor and privilege to present a Windows Server 2012 DirectAccess session at Microsoft TechEd North America and Europe 2013. For those of you who attended in person, thank you very much! I certainly hope that you found the session informative and worthwhile. For those of you who were not able to attend in person, you can watch a recording of the session for free at Microsoft’s MSDN Channel 9 web site here. Enjoy!

Windows Server 2012 DirectAccess TechEd 2013 Session

ISATAP Recommendations for DirectAccess Deployments

ISATAP Recommendations for DirectAccess DeploymentsFrom a client perspective, DirectAccess is an IPv6 only solution. The client communicates with the DirectAccess server and intranet resources using IPv6 exclusively. To enable communication between DirectAccess clients and IPv4 only resources on the internal network, the DirectAccess servers uses two important protocol translatorsDNS64 and NAT64. Unfortunately DNS64 and NAT64 provide only inbound protocol translation, so another measure is required for communication initiated outbound to connected DirectAccess clients.

ISATAP

To support outbound communication originating from the Intranet to connect DirectAccess clients, the DirectAccess server is configured as an Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) router. ISATAP is an IPv6 transition technology that allows hosts on the intranet to initiate outbound communication to DirectAccess clients on the Internet by tunneling IPv6 communication over the internal IPv4 network.

ISATAP can be enabled by populating internal DNS with a host record called ISATAP that resolves to the IPv4 address assigned to the Internal network adapter on the ISATAP router, in this case the DirectAccess server (don’t forget to remove ISATAP from the DNS global query block list!). When a client resolves ISATAP to an IP address successfully, it enables an ISATAP tunnel adapter and assigns itself an ISATAP IPv6 address. Once enabled, any host with an ISATAP tunnel adapter configured can initiate outbound communication to DirectAccess clients on the Internet.

Important note: It is not recommended to deploy ISATAP globally via DNS. See below for more details.

When configured and enabled, ISATAP opens up new and interesting network communication scenarios. For example, a helpdesk administrator can proactively initiate a remote desktop session to a remote client connected via DirectAccess to troubleshoot an application. Systems management engineers can push software out to DirectAccess clients without requiring an agent on the remote client to “phone home” to receive software updates. This model is often referred to as “manage out”.

Limitations

In the early days of DirectAccess with Windows Server 2008 R2 and Forefront UAG, configuring and enabling ISATAP as described above was standard operating procedure. However, we soon learned that there are some serious drawbacks to deploying ISATAP. While the DirectAccess manage out scenario is an important and frequently requested feature of a DirectAccess implementation, it often causes more trouble than it solves. In its default configuration, ISATAP is a global change that affects all hosts that can resolve the hostname ISATAP to an IP address. The challenge here is that this change can break or impair normal network communication for some hosts on the Intranet. For example, if an internal host is able to resolve a public hostname to an IPv6 address, it may attempt to connect to the site via ISATAP.

Unfortunately, in this scenario ISATAP does not lead to the public Internet. Rather, ISATAP is used to provide network connectivity exclusively for our DirectAccess clients. Since IPv6 is preferred in most modern operating system’s networking stacks, it can lead to failed or seriously delayed communication to Internet resources. In addition, once ISATAP is enabled globally there will be a lot of IPv6 communication taking place on the network, which in large enterprise networks can be a source of confusion for those individuals with the responsibility for monitoring the network.

ISATAP also suffers from a lack of robust monitoring tools for this very essential service. Additionally, ISATAP turns the OSI model upside down. ISATAP relies on upper-layer protocols (DNS) to provide its service. If there are issues with DNS that prevent proper name resolution, ISATAP routing will cease to function, which is fundamentally backward.

Targeted Deployment

ISATAP Recommendations for DirectAccess DeploymentsAs I mentioned earlier, ISATAP is a global setting by default. However, in most environments there will only be a few systems that will require the ability to initiate outbound communication from the internal network to remote DirectAccess clients. Typically these will be helpdesk administrators’ workstations or management systems. Today we are recommending that you deploy IPv6 on any internal systems that will participate in any DirectAccess manage out scenarios. Unfortunately this will not be possible in many cases, as additional network changes are often required to support IPv6 on the Intranet. In these cases we recommend that instead of configuring ISATAP in DNS globally, you target individual systems for ISATAP configuration as required. This can be accomplished in a number of ways.

Group Policy

This is recommended way to deploy ISATAP settings to systems that require DirectAccess manage out functionality. It is the easiest to manage and the most scalable as well. A unique ISATAP hostname (for example, DirectAccess-ISATAP) is created in the internal DNS that resolves to the internal IPv4 address of the DirectAccess server. Create a new GPO in Active Directory to assign it to management workstations using security group filtering or OU targeting. Edit the GPO setting Computer Configuration > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies > Set ISATAP State (Enabled and set to Enabled State) and > Set ISATAP Router Name (Enabled and enter the ISATAP hostname created previously).

ISATAP Recommendations for DirectAccess Deployments

PowerShell

Using PowerShell is an alternative method of configuring an individual system to use ISATAP. Although not as scalable as the group policy method, it is still very effective. On the system that requires network connectivity to DirectAccess clients, open an elevated PowerShell command window and run the following command:

Set-NetISATAPConfiguration -Router <NameOrIPAddress>

Netsh

Another command line method for configuring the ISATAP is to use netsh.exe. In an elevated command prompt window run the following command:

netsh interface isatap set router <NameOrIPAddress>

HOSTS File

This is the least desirable way to configure ISATAP, but I’ll mention it here because it is quick and simple and does work. On any system that requires ISATAP for DirectAccess manage out, simply edit the HOSTS file in C:\Windows\System32\Drivers\Etc and add a host record for ISATAP that resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. Obviously this is the least scalable alternative and should only be used in test environments or very small production networks.

Supportability

ISATAP is only supported for single server DirectAccess deployments. ISATAP will work when Network Load Balancing (NLB) is enabled, but it requires some additional configuration. ISATAP does not work when an external load balancer is in use and/or multisite is enabled. To restore manage out functionality for DirectAccess for load-balanced and multisite deployments, additional infrastructure and configuration is required. Fill out the form below to request more information.

Summary

As you can see there are numerous drawbacks to configuring ISATAP on a global scale. Fortunately there are simple and effective workarounds that allow you to target specific systems for ISATAP configuration. Choose the one that works best for you and have fun managing your DirectAccess clients!

Additional Information

DirectAccess Manage Out and Microsoft System Center Configuration Manager (SCCM)

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016

Contact Me!

Want to enable DirectAccess manage out for System Center Configuration Manager (SCCM) remote control or Remote Desktop Connection (RDC) in load-balanced and multisite deployments? Fill out the form below for more information.

Network Interface Configuration for Multihomed Windows Server 2012 DirectAccess Servers

When preparing a Windows Server 2012 DirectAccess server with two network interfaces, proper configuration of the network interfaces is vital to the operation and security of the remote access solution, especially in edge-facing scenarios. Preparing a server with two network interfaces might seem trivial, but there are some important and often overlooked settings that may lead to trouble. In this post I’d like to outline the proper network interface configuration for a Windows Server 2012 DirectAccess server in an edge-facing deployment scenario. It is important to note that you should configure your network interfaces prior to installing and configuring DirectAccess.

The first step is to rename the network interfaces with intuitive names that identify their role. Typically I use Internal and External. This will make DirectAccess configuration much easier, as you will see when you are configuring DirectAccess using the deployment wizards. To rename the network interfaces, open the Networking and Sharing Center from the Control Panel and choose the option to Change adapter settings. Optionally you can simply highlight the network interface you wish to rename and hit F2. Assign new names to the network interfaces as appropriate.

direct_access_multihome_01

Next, right-click the Internal network interface and choose Properties. Enter an IPv4 address, subnet mask, and DNS servers as required. Notice that I have not entered a default gateway here. This is absolutely critical and one of the most common mistakes made when configuring a multihomed DirectAccess server. On a server with multilple network interfaces there can be only one default gateway, and the gateway must reside on the External network interface.

direct_access_multihome_02

In the absence of a default gateway on the Internal network interface, static routes will be required to reach any remote internal subnets. To add a static route, open an elevated PowerShell command prompt and add any necessary routes using the following syntax:

New-NetRoute -InterfaceAlias <Interface_Name> -DestinationPrefix <SubnetID/Mask> -NextHop <Gateway_Address>

For example, my lab network has a remote subnet of 172.16.2.0/24 that is reachable through a router interface of 172.16.1.254.

New-NetRoute -InterfaceAlias Internal -DestinationPrefix 172.16.2.0/24 -NextHop 172.16.1.254

It’s also a good idea to unbind any protocols that are not required. For example, in my implementation I will not be leveraging QoS or NIC teaming, nor will I require the Link-Layer Topology Discovery services so I’ve unchecked those boxes accordingly.

direct_access_multihome_03

Perform this same exercise for the External network interface. Enter an IPv4 address and subnet mask, and this time be sure to include the default gateway for the External network. Notice that I have not entered any DNS servers here. Resist the urge to enter the DNS servers provided by your ISP. They are not required here.

direct_access_multihome_04

Since this DirectAccess server will be edge-facing and connected directly to the public Internet, it is a good idea to unbind all protocols from the network interface with the exception of IPv4 and IPv6.

direct_access_multihome_05

In addition, uncheck the option to Enable LMHOSTS lookup and also chooseDisable NetBIOS over TCP/IP.

direct_access_multihome_08

One last change that needs to be made, and perhaps the most critical and often overlooked setting, is the network interface binding order. This change can be made by pressing the Alt key on the keyboard to display the drop-down menu and choosing Advanced Settings.

Important Note:  Beginning with Windows Server 2016, making changes to the network interface binding order is no longer required, and this option has been removed from the UI.

direct_access_multihome_06

Make certain that the Internal network interface is listed first in the list of connections.

direct_access_multihome_07

So that’s it! You can now proceed with installing and configuring DirectAccess in full confidence that your network interfaces are configured properly!

Additional Resources

Always On VPN and the Future of DirectAccess

5 Things DirectAccess Administrators Should Know about Always On VPN

3 Important Advantages of Always On VPN over DirectAccess

Always On VPN Hands-On Training Classes

DirectAccess on the Microsoft Surface Pro

At Microsoft TechEd North America 2013 I had the privilege of (finally!) acquiring both a Microsoft Surface RT and a Surface Pro. I’d been wavering back and forth on which one to purchase for many months. As it turned out, my indecision (and admittedly some procrastination!) paid off. As you are probably aware, Microsoft was offering the Surface RT 64GB for $99.00 USD and the Surface Pro 128GB for $399.00 USD to TechEd attendees and third-party speakers. Needless to say I purchased both! I love the Surface RT for general Internet use like web browsing, e-mail, etc. The battery life is great and having Office apps is tremendously productive. However, as a technology geek I really like the power and flexibility that the Surface Pro offers. Since it is a full-fledged PC, I can install whatever software I like on it.

Being able to join a domain and enable DirectAccess would, of course, be the icing on the cake. The Surface Pro comes pre-installed with Windows 8 Professional, which means I can join a domain but unfortunately it doesn’t support DirectAccess. My plan was to wipe the device and reload Windows 8 Enterprise when I returned from the conference. As luck would have it, I ran in to my good friend and fellow Microsoft MVP Jordan Krause, and I was surprised to find that he had already upgraded his Surface Pro to Windows 8 Enterprise, joined it to his domain, and had enabled DirectAccess right there at TechEd! How did he do this so quickly? It turns out that it is as simple as mounting the Windows 8 Enterprise ISO and performing an in-place upgrade by launching setup.exe. And no, contrary to what some have said, you can’t simply input your Windows 8 Enterprise license key and magically turn Windows 8 Professional in to Windows 8 Enterprise. It will of course activate, but it will still be Windows 8 Professional unless and until you perform the actual upgrade to Windows 8 Enterprise using the installation media.

So, upon returning home from TechEd I promptly upgraded my Surface Pro to Windows 8 Enterprise using the steps Jordan outlined here. Worked like a charm! I was able to join my lab domain and successfully establish DirectAccess connectivity on the Surface Pro. I did encounter a few issues when I attempted to refresh the device, however. To reset the device, I clicked Settings on the charms menu (swipe-in on the right or Window Key+C) and clicked Change PC Settings. Next I selected General and chose the option to Refresh your PC without affecting your files and received the following error message:

Insert media. Some files are missing. Your Windows installation or
recovery media will provide these files.

Insert Media on the Surface Pro

Selecting the option to Remove everything and reinstall Windows yielded the same error. Fortunately it was easy enough to resolve. To begin, I created a folder on the C: drive called WinRec. Next, I mounted the Windows 8 Enterprise ISO, navigated to the \Sources folder and copied install.wim to C:\WinRec. Finally, I opened an elevated command prompt and executed the following command to register this file as a recovery image:

reagentc.exe /setosimage /path C:\WinRec /target C:\Windows /index 1

Now when I select the option to Refresh your PC without affecting your files or Remove everything and reinstall Windows the process continues normally. Once the process is complete, there will be a few drivers missing which you can download here. After that everything was good to go! Obviously the solution I’ve described here is only really effective for one-off deployments of Windows 8 Enterprise on the Surface Pro. If you’re considering an enterprise-wide deployment, have a look at the Surface Pro Enterprise Deployment Guide [PDF], which includes detailed, prescriptive guidance for deploying Windows 8 Enterprise on the Surface Pro.

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!

The Drawbacks of Supporting Windows 7 Clients with Windows Server 2012 DirectAccess

Windows Server 2012 DirectAccess includes many new features to enhance scalability and performance. To take full advantage of many of these capabilities you must use Windows 8 Enterprise edition for your DirectAccess clients. Windows 7 Enterprise and Ultimate clients are supported, but there are a few important features that can’t be leveraged. Here are some examples:

IP-HTTPS Improvements – Windows Server 2012 supports NULL encryption for the IP-HTTPS IPv6 transition protocol. This eliminates the performance penalty and negative scalability caused by needlessly redundant encryption of DirectAccess client communication (IPsec encrypted traffic encrypted again with SSL/TLS). Windows 8 clients only request these NULL encryption cipher suites when establishing DirectAccess connectivity. However, Windows 7 clients do not support NULL encryption and will instead request an encrypted cipher suite when performing SSL/TLS negotiations.

Automatic Site Selection for Multi-Site – With Windows Server 2012 the administrator can configure multiple DirectAccess gateways to provide geographic redundancy for DirectAccess clients. Windows 8 clients are configured to intelligently select the nearest entry point and automatically reconnect to another gateway if the connection to the originally selected entry point fails. In contrast, Windows 7 clients can be configured for only a single entry point. The Windows 7 client is unaware of any other entry points and if the original connection becomes unavailable for any reason it will not have corporate network access until that entry point is back online.

Public Key Infrastructure (PKI) – The removal of the requirement to have an internal PKI to support DirectAccess clients is a popular feature for many organizations wanting to deploy DirectAccess (I don’t necessarily agree with this, but that’s the subject of another post!). Although Windows Server 2012 DirectAccess can be configured to use self-signed certificates, this deployment model is only supported for Windows 8 clients. If you plan to provide support for Windows 7 clients you will need a working internal PKI.

DirectAccess Connectivity Assistant – The Windows 8 client includes native functionality to indicate the status of DirectAccess connectivity and also includes a facility with which to quickly gather detailed log data for troubleshooting. Windows 8 clients can also establish DirectAccess connectivity when they are located behind an authenticating web proxy. For Windows 7 clients, the DirectAccess Connectivity Assistant (DCA) provides some of this functionality, but it is an optional component that must be deployed separately. Even with the DCA installed, Windows 7 clients cannot establish DirectAccess connections when a web proxy server requires authentication.

Although Windows 7 Enterprise and Ultimate editions are supported for DirectAccess when connecting to a Windows Server 2012 DirectAccess server, Windows 8 Enterprise clients should be deployed whenever possible to ensure the best and most complete experience.

Win a Copy of Windows Server 2012 Security from End to Edge and Beyond

As many of you know, I recently joined the team at Iron Networks to work more closely with DirectAccess and to be involved with some of their exciting new solutions for enabling the Microsoft private cloud. I was noticing that they don’t have much of a following on Twitter yet, so in an effort to change that I’m announcing a Twitter contest! This Friday, May 31, I will select one individual who is following both me and Iron Networks on Twitter and send you a free copy of Tom and Deb Shinder and Yuri Diogenes’ latest book entitled “Windows Server 2012 Security from End to Edge and Beyond”. I had the privilege of serving as the book’s technical reviewer and I can tell you it is an excellent reference that you’ll want to have in your library. So go out and follow me and Iron Networks for a chance to win!

Iron Networks

Windows Server 2012 Security from End to Edge and Beyond

Windows Server 2012 DirectAccess Session at TechEd 2013

Are you planning to attend Microsoft TechEd this year? If so, I’m happy to announce that I’ll be delivering a session entitled “The Future Is Now! Next Generation Remote Access Today with Windows Server 2012 DirectAccess”. I’ll be presenting at both TechEd North America in New Orleans, LA, and at TechEd Europe in Madrid, Spain. Looking forward to seeing you there!

Microsoft TechEd North America 2013

Microsoft TechEd Europe 2013

%d bloggers like this: