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

13 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
  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: