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!

DirectAccess and NAT

One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.

Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.

Windows Server 2012 DirectAccess Network Topology

Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.

So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.

Manage Out Fails for Non-ICMP Traffic with UAG DirectAccess

You may encounter a scenario in which the ability to manage out fails for DirectAccess clients using Forefront UAG 2010. You may also receive the following error:

4984 “An IPsec extended mode negotiation failed”

This can happen when custom security policies are applied to the DirectAccess client, specifically altering the settings for “Access this computer from the network“.

For more information regarding this error and how to resolve it, please refer to Microsoft Knowledge Base article 2663354.