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!

Leave a comment

19 Comments

  1. Stephen Frost

     /  March 2, 2014

    Hi Richard,
    We are in a situation where we need to Disable access for certain DA clients for a period of time and then only Enable it again when they are scheduled to travel. I have not found a satisfactory solution for this scenario. I’ve experimented with disabling the computer account in AD, replicating AD, then killing the IPsec connections via your Powershell commands. This works as a stop-gap measure if we want to kill DA on the client when they are out of the office, but isn’t suitable when the client is back IN the office again.
    I’m quite staggered that MSFT have not provided any mechanism in the DA Server to selectively Block/Disable a client. It seems that the Server is not doing any validation at all, other than checking that the Computer account is active. Surely they could provide a “Block List” of some description fairly easily?
    Any thoughts you could offer on this would be most welcome.
    Regards,
    Steve

    Reply
    • I can assure you that the DirectAccess server is doing plenty of validation. 🙂 To establish DirectAccess connectivity the client is authenticated using it’s Active Directory computer account (NTLM) along with its machine certificate for the first tunnel. The second tunnel is authenticated using the computer account (NTLM) along with the user account (Kerberos). As for “block list” functionality, you are right, there isn’t any. To be fair, however, I don’t recall seeing this feature on another other remote access solution either (Cisco, Checkpoint, Juniper, etc.).

      Reply
  2. Hi Richard,
    Out of curiosity I was trying to format-table the output of Get-NetIPsecMainModeSA however I can’t seem to get anything useful e.g.
    Get-NetIPsecMainModeSA |ft RemoteFirstid.Identity
    returns empty rows
    Get-NetIPsecMainModeSA | ft RemoteFirstid
    just returns the following:
    PS C:\Windows\system32> get-netipsecmainmodesa | ft RemoteFirstId

    RemoteFirstId
    ————-
    MSFT_NetIPsecIdentity
    MSFT_NetIPsecIdentity

    Do you have any suggestions as to how I’d get an output more like this?
    RemoteFirstId
    ————-
    client1.domain.local
    client2.domain.local

    Thanks

    Mark

    Reply
  3. Phil

     /  June 23, 2016

    I’m testing this out and not understanding some of the behavior I’m seeing. I have a laptop that is connect to my DirectAccess server and I’m running a continuous ping to a file server that is only accessible through a DirectAccess connection. I disabled the laptop account in Active Directory and replicated the changes to all domain controllers. I followed the instructions above, in a slightly more heavy-handed manner that just kills all MainModeSAs, but the connection is immediately recreated. It’s not even dropping a single ICMPv6 packet!

    Get-NetIPsecMainModeSA | Remove-NetIPsecMainModeSA

    It’s not until the machine actually locks (after a paranoid 3 minute timeout) that it’s apparent I’ve done anything at all. At that point, I can’t log back into the machine, which is great, but it seems that new connections are still created by already-running applications (in my case, ping).

    Is this what you would expect to happen? If so, would a certificate revocation be required to stop this behavior?

    Reply
  4. John

     /  November 7, 2016

    Well, this kind of works.
    While it does seem to stop most of the connection, I notice a similar issue as Phil. But it went beyond that.
    I was actually RDP’d into a DC when doing the testing so I could easily disable my PC & kill my connection.
    I would lose the RDP connection to the DA server, but the connection to the DC would stay active, which to me, seemed odd.
    My computer account was disabled & replication has occurred.
    Did some more testing, determined that name resolution would stop, but if I had trapped the IPv6 addresses ahead of time, I could RDP into any server, DC, file server, etc. I could SSH into firewall & router. Just not access resources by name.
    Apparently disabling the computer account isn’t sufficient enough to keep the tunnel from being functional, which is kind of troubling.
    Not necessarily a issue for you since it’d be a MS issue, but wondering if you can duplicate the issue as well.

    Thanks.

    Reply
    • You are right, it is technically possible to continue to access corporate resources after performing these steps, assuming you know the correct IPv6 address of the internal resource. For the record, no connectivity is possible after the client reboots, so I suspect this might have something to do with Kerberos ticket or some other type of credential caching somewhere. I’ll continue looking in to this and post more details if I find a suitable workaround.

      Reply
      • John

         /  November 17, 2016

        I let the boys @ MS know as well. Got a personal reply, so at least I have a false sense of hope it’ll be addressed in a future enhancement….
        Thanks.

  5. John

     /  November 18, 2016

    I was playing around a bit, was thinking might need to kill both the MainMode & QuickMode SA’s.
    Able to build the lists that need to be mopped up.
    $MainModeSAList = Get-NetIPsecMainModeSA | where {$_.RemoteFirstId.Identity –like “*testlaptop*”}
    $QuickModeSAList = Get-NetIPsecQuickModeSA | where {$MainModeSAList.RemoteEndpoint -contains $_.RemoteEndpoint}

    And obviously can kill the MainModeSA as noted above. But I can’t seem to kill the QuickMode SA (or at least, target the individuals without doing “-all” or something.

    Not sure if that is chasing the right issue or not, but thought I’d toss it out there in case you were playing with things as well.

    Thanks

    Reply
  6. John

     /  April 16, 2017

    Was this ever solved?
    Is there now any way to disconnect a stolen laptop using a process that cannot be bypassed by a determined and savvy person who knows how to connect via IPv6 address?

    Reply
    • I’ve not done any more testing with this, but I’ll add it to my list of things to do and report back with any results. It is mostly effective though. Of course another option would be to use an ADC to perform IP-HTTPS preauthentication and enable CRL checking. That way if the client’s certificate is revoked, the ADC will prevent the IP-HTTPS connection from being established in the first place, which would eliminate any chance of a terminated user accessing internal resources.

      Reply
  7. Lee

     /  June 13, 2017

    Assuming you have Manage Out connectivity to the DA Client, we do the following:

    1) Issue Remote Shutdown of the DA Client from an Admin Command Prompt: “Shutdown -m \\CLIENTNAME -f -s -t 00”. This forces an immediate shutdown of the remote client.

    2) Disable the Computer Account in AD.

    Cuts off access to all resources, and even if the device is restarted, being Disabled will prevent establishing a new connection.

    Lee

    Reply
    • That should work. You could also use the Stop-Computer PowerShell command. The important point is disabling the Active Directory computer account, which prevents the client from authenticating in the future.

      Reply
  8. Jorge

     /  September 14, 2017

    Hi Richard,

    If I want to disconnect all the users on DirectAccess server but without disabling their machine accounts in AD. Can I use the cmdlet like shown below ?
    Get-NetIPsecMainModeSA | Remove-NetIPsecMainModeSA

    Or there is another way for it

    Thanks in advance.
    Kind regards.

    Reply
    • That’s it! Running that command will immediately terminate all DirectAccess IPsec connections. Since you’ve not disabled any computer accounts, the clients will then automatically try to reestablish the connection.

      Reply
  9. Jorge

     /  September 16, 2017

    Hi Richard,

    Many thanks for your quick reply. I was looking for a way to terminate all DA clients sessions in order to force them to jump to another balanced DA server to perform a hardware upgrade. And like you’ve said, clients automatically attempt to establish the connection. So I stopped the Remote access management service on first DA server and then I shutted down it to do the upgrade. Is there any other way terminating DA clients session other than stopping the service ? I’m not sure if it is a proper best practice for this sort of situation.

    Thanks in advance.
    Kind regards.

    Reply
    • If you are using an external load balancer, my suggestion is to first remove the first node from the load-balanced pool and then terminate any open IPsec connections. This will force any connected clients to reconnect to the remaining server. If you are using NLB, you can do the same thing using the NLB manager. Just perform a drain/stop or simply a stop and run the script. Should work fine.

      Reply
  1. Disconnecting DirectAccess Clients on Windows Server 2012 – PKM-Technology

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: