You know the CVE-2019-0708 is around and everyone is looking for a PoC, and I followed this article to do some workaround to harden my old windows server. Yes, I enabled NLA. The NLA is working. But after a reboot, the NLA is not working properly, I was disconnected from server immediately after enter the password and click ok. There is no message pop up I just got disconnected. Weird.
I can give you a Wireshark capture packets if needed.
You can take a glimpse of what is going on. With password auto fill. Wireshark Captured Packets
So what is going on? I am not familiar with windows and really don't know why... And the worst thing is that I can't connect to it now because it is really a remote server...T_T...
I got following error log, too:
[I] RDP ClientActiveX is trying to connect to the server (srv1.domain.com) [I] Server supports SSL = supported [I]Base64(SHA256(UserName)) is = - [W] RDPClient_SSL: An error was encountered when transitioning from TsSslStateHandshakeInProgress to TsSslStateDisconnecting in response to TsSslEventHandshakeContinueFailed (error code 0x80004005) [I] The multi-transport connection has been disconnected. [I] RDP ClientActiveX has been disconnected (Reason = xx) [I] The multi-transport connection has been disconnected.
It may be the update process at fault.
Go to RDP settings, Advanced Tab.
Choose "Connect and don't warn" instead of "Do not connect" under the "If server authentication fails" area.
If that didn't work try uninstalling KB2984972.
Considering your updated question, you should also make sure that in Computer - > Properties -> Remote Settings -> Remote tab -> 'Allow Connections from Computers Using Any Version of RDP' is selected. Also make that on 'Select Users' the local admin account is added there.
It is typical for the Remote Desktop client to disconnect immediately with no error message if you attempt to connect to a computer that is in the process of shutting down. This most often happens if the remote computer is installing updates, because this drags out the shutdown process.
I get a slightly different error code than you did (
0x8000FFFF rather than
0x80004005) but this probably just depends on the exact version of the client and server and perhaps other factors like the quality of the connection that was (briefly) established.
pslist command (available from the MS web site) with the
-s option can be useful in determining what a remote computer is doing, and in particular in distinguishing between a computer that is actually installing updates from one that has hung while attempting to install updates. You may also wish to check the Component Based Servicing log, which can be found at
c:\windows\logs\cbs\cbs.log, for activity.
User contributions licensed under CC BY-SA 3.0