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!
Stephen Frost
/ March 2, 2014Hi 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
Richard Hicks
/ March 3, 2014I 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.).
Mark Harford
/ November 11, 2015Hi 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
Richard M. Hicks
/ November 11, 2015Does this work for you? (Get-NetIPsecMainModeSA).RemoteFirstID.Identity
Phil
/ June 23, 2016I’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?
Richard M. Hicks
/ June 23, 2016Expected behavior. ICMP is exempted from IPsec policy processing. You can prevent this behavior by disallowing ICMP through the DirectAccess server or enforcing client certificate authentication on the IP-HTTPS listener. It’s also possible to require IPsec for ICMP, but that’s not generally recommended.
John
/ November 7, 2016Well, 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.
Richard M. Hicks
/ November 8, 2016You 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.
John
/ November 17, 2016I 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.
John
/ November 18, 2016I 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
DeBlackman
/ August 17, 2021Hi all,
A bit late to the party but just thought i’d re-ignite this topic. Our company has been using DA for 5-6 yrs now and its been great. With WFH during this pandemic, security is being tightened up so management is looking for a way to make sure if a corporate device is stolen we are able to disconnect any DA connection.
Been trying the steps outlined here (disable computer account and run CMDlet to disconnect) but the client keeps getting reconnected with no issues.
Has there been any progress on this to find out how to make sure the workstation is not allowed to reconnect?
Richard M. Hicks
/ August 24, 2021This is an old topic for sure, but still relevant! If the guidance in this post isn’t working, I would suggest adding the computer’s certificate to the “Untrusted Certificates” certificate store on each DirectAccess server. That should prevent your DirectAccess devices from connecting immediately.
I don’t have any published guidance for DirectAccess specifically, but the procedure would be the same as it is for the Always On VPN device tunnel. Details here:
https://directaccess.richardhicks.com/2019/04/22/denying-access-to-always-on-vpn-users-or-computers/
John
/ April 16, 2017Was 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?
Richard M. Hicks
/ April 18, 2017I’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.
Lee
/ June 13, 2017Assuming 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
Richard M. Hicks
/ June 15, 2017That 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.
Jorge
/ September 14, 2017Hi 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.
Richard M. Hicks
/ September 14, 2017That’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.
Jorge
/ September 16, 2017Hi 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.
Richard M. Hicks
/ September 16, 2017If 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.