RDP suddenty stopped working

[Sheridan]

On one of our 2022 servers RDP has suddenly stopped working with the clients now seeing the 'an internal error has occurred 0x4' immediately when we try to connect, not even getting as far as the user/password section - and its immediate as if the server doesn't exist or the port is blocked

 

Nothing changed on the server, and its working as normal in all ways (it hosts SQL and some file shares and they're working)

 

I can ping it, traceroute is correct and port 3389 is open and tested using powershell (tnc server -port 3389) and I've tried to RDP using the IP as well

 

Its been restarted several times, and I've tried disabling NLA temporarily but nothing has worked! All the other servers in the hosted environment are working normally - the only thing that I can think of that changed is we had a power outage and our core switch stack restarted (and using the saved/correct config so we haven't lost anything), but we have full connectivity for everything - just not RDP on this one server!

 

Anyone seen this before? Its got me going around in circles!

Edited June 4, 2024 by Sheridan

[r0cketbev]

This is going to sound silly, but have you checked that the firewall is allowing RDP?

[Sheridan]

This is going to sound silly, but have you checked that the firewall is allowing RDP?

 

Yes - not a daft suggestion at all, but 3389 is open for the domain, and it was there previously. Its also the same on other servers which are still working!

 

Oddly, I can RDP out from this server to desktops, and also to other servers in the same environment

Edited June 4, 2024 by Sheridan

[3s-gtech]

Yes - not a daft suggestion at all, but 3389 is open for the domain, and it was there previously. Its also the same on other servers which are still working!

 

Oddly, I can RDP out from this server to desktops, and also to other servers in the same environment

 

Has it got a static IP set, and has it changed or been deleted, or lost its subnet mask/gateway?

 

Would normally affect the other services, but I have seen this happen before.

[jthompson]

Is the server's network connection identified as a domain connection? If it's sitting there identifying as a 'Public' connection, that would explain it.

[mikes]

Can you RDP in via IP rather than the server's DNS name? Had an issue where trying to RDP in via the DNS name doesn't work (ping resolves the right IP address) but RDPing in via the IP worked fine

[r0cketbev]

Give this a try. Taken from Reddit.

 

 

It turns out that the issue is indeed related to the TPM version and model. The older TPM's have an issue with RSA-PSS signature algorithms.Although not advisable from a security standpoint it's possible to remove RSA-PSS signature algorithms from the registry (or upgrade the endpoints to a v2 TPM with at least sub-version of 1.17 or higher).Remove the following entries from the "Functions" REG_SZHKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003\Double-click the Functions entry and remove the following algorithms from the Value data section.RSAE-PSS/SHA256RSAE-PSS/SHA384RSAE-PSS/SHA512Then reboot.

[Sheridan]

Hmm doesn't work using IP or the web account login -and its just this one server. Its a VM but based on the same hosting platform as many others that work. I'm just wary of why it suddenly stopped when no changes were made to it or the hosts!

[Sheridan]

Finally found the solution - although not sure why the problem occurred

 

I had to add SYSTEM permissions to the folder C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, and then after restarting the RDS service it worked fine!

[StephenPink]

Finally found the solution - although not sure why the problem occurred

 

I had to add SYSTEM permissions to the folder C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, and then after restarting the RDS service it worked fine!

 

Interesting - in case useful to anyone else, I have seen the same change (I knew it rang a bell!) being required for a different issue (SIMS - Solus3) and according to my notes from the time, was a Windows Update that broke it:

 

Windows Updates can reset the below folder permissions, which causes SOLUS to have issues reading database etc

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

Permissions need re-adding on this folder;

 

• Everyone > Full Control
  

Then restart SOLUS3 Agent Service, before relaunching the SOLUS3 Deployment Application