We recently upgraded to R9.2 to reenable RDP and whilst it may not be related, shortly afterwards we started getting reports from customers (as well as our own internal infrastructure) that RDP wasn't working correctly. A screenshot is below and this occurs when you directly RDP to a server (ie. not via Kaseya) without NLA turned on. You then have to hit "back" and choose other user to login.
The issue also affects RDS (Terminal Servers) so is affecting a good number of our customers. We've had a PSS case open with Microsoft but getting nowhere with it.
We can temporarily fix the issue client-side by removing registry keys from HKCU\SOFTWARE\Microsoft\Terminal Server Client\Servers but this is only a workaround and only client side.
The only common factor between all these servers is that they have our Kaseya agent installed. I suspect opening a support case with Kaseya will go nowhere fast as it's quite esoteric and doesn't affect all servers (we've identified maybe 50 or so out of our estate of 3000 so far, but obviously not tried them all).
When a Kaseya agent is deployed we have configured a policy to automatically run a script that enabled RDP and disables NLA to support RDP from Kaseya. Not sure if that is relevant.
It is seemingly affecting agents of both 9.1.0.x version and 9.2.0.x version so initially we thought it wasn't related.
Has anyone else seen this as it is driving us mad troubleshooting?
I can confirm that we have experienced the same issue and it appears that the new re-released Kaseya Remote Desktop enables NLA on the target terminal servers.
The issue appears to only affect 2012* Servers and older endpoints that do not support NLA. Kaseya's previous version of RDP did not support NLA and required you to turn it off to make RDP connections via Kaseya work
I'm conflicted about this one as NLA is an important security feature and updating the endpoints to a version that supports NLA should fix the issue but at the same time it would have been nice if this "feature" was advertised with the release of the new Kaseya RDP to allow us to prepare .
For clients where upgrading the endpoints is not currently an option our current workaround is to use VNC or KRC on the terminal servers only while we try to find ways to upgrade the endpoints.(* Not 100% sure about the server versions as I was not involved in the troubleshooting of the issue)
Thanks for that - helpful to know we are not alone!
We have done a lot more digging today actually and found the root problem. It is not so much to do with NLA but rather the RDP security layers setting.
The reg key is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SecurityLayer
When you initiate an RDP session to a server it forces the security layer back to 0 - i.e. Native RDP encryption. This has the effect of forcing NLA off, but we actually don't enforce NLA anyway so for us this is unnecessary.
The Microsoft default is Negotiate (registry key value 0) which should work fine for both Kaseya and non-Kaseya connections. I think Kaseya have just been lazy and coded this as a means of force-disabling NLA when in fact there are better ways of doing this.
It appears to be an issue regardless of agent versions - just the fact that our VSA is on 9.2 and hence reinstated RDP. We have agents affected that are still on 6.3 as well as 9.1 (we jumped from 6.3 to 9.1).
Raising a ticket now :-)