4

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.
gacopu
  • 161
  • 1
  • 2
  • 7
Yuri Leaves
  • 43
  • 1
  • 4
  • Are you connecting from a Windows client using Remote Desktop Connection? Was the server fully patched as of April? Is the client fully patched? – Harry Johnston May 20 '19 at 23:05
  • ... some people with similar problems have reported that connecting via the server's IP address (as opposed to providing a DNS name) works, have you tried that? – Harry Johnston May 20 '19 at 23:06
  • @HarryJohnston thanks a lot, finally solved by hard reboot from remote, it seems that machine was hanging on update process like Overmind says. Any way thanks for your rely maybe it can help others. – Yuri Leaves May 21 '19 at 01:01
  • D'oh! Yeah, now that you point it out, being disconnected instantly with no error message is typical of a server that is in the process of shutting down, usually encountered when the shutdown is delayed (or in this case hung) due to updates installing. I didn't know that made error `0x80004005` appeared in the error log on the client end though. Since you solved your own problem, you can post (and accept) your own answer if you like. – Harry Johnston May 21 '19 at 03:31
  • Haha, thanks, your suggestion is great, I even don't know that I can do that, but I don't want to do that because it's not fair for others I think hahaha, you can do it and I will accept it for you. – Yuri Leaves May 24 '19 at 09:34

2 Answers2

4

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.

Overmind
  • 3,076
  • 2
  • 16
  • 25
2

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.

The 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.

Harry Johnston
  • 6,005
  • 4
  • 35
  • 52