RDP Fails with Event ID 1058 & Event 36870 with Remote Desktop Session Host Certificate & SSL Communication

  • Article

Hello AskPerf!  Sanket here from the Windows Platforms team here to discuss an issue with Remote Desktop Services where RDP does not work when you try to connect from a remote machine.  With that, let’s get started!

I’m sure most of you have come across the following message when connecting to a machine via RDP:

Remote Desktop Connection

This computer can't connect to the remote computer. Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

This is a generic that can be caused by numerous varying reasons.  We have a fairly detailed troubleshooting KB article that talks about this error and what to do to fix it:

Remote Desktop disconnected or can’t connect to remote computer or to Remote Desktop server (Terminal Server) that is running Windows Server 2008 R2

Assumptions are that most of you have followed this KB and resolved your issue.  However, there could other reasons that could cause RDP to fail as well.

I recently worked an issue with same error where RDP from a remote machine was not connecting to a Windows 2012 Server.  NOTE the same error can occur on previous OS versions as well.

There was a mystery as to what was changed on the server that could have caused this start.  Possible assumptions were user intervention, or some application may have changed/removed certain permissions.

During the course of troubleshooting, we double-checked the KB article noted above, and noted the following Error events in the System Log:

Log Name: System
Source: Microsoft-Windows-TerminalServices-RemoteConnectionManager
Date: 7/27/2014 12:16:59 AM
Event ID: 1058
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: XXXXXXX
Description: The RD Session Host Server has failed to replace the expired self-signed certificate used for RD Session Host Server authentication on SSL connections.
The relevant status code was Access is denied.
 
This error indicates that there is already a Certificate in place, however there is no sufficient permissions, and/or the default permissions on “C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys” may have been modified.
 
&
 
Log Name: System
Source: Schannel
Date: --
Event ID: 36870
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: XXXXX
Description: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030D.
The internal error state is 10001.
 
There was a fatal error accessing the Private Key for secure communications.

At this point, I decided to capture a Process Monitor (Procmon) log on the destination server where the connection was going to.  As you may already know, Procmon allows us to monitor/record real-time file system, Registry and process/thread activity on Windows Workstations/Servers.

Per the Procmon log, we found an “Access Denied” error to the following path:

“C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\f686aace6942fb7f7ceb231212eef4a4_”

The above cert key f686aace6942fb7f7ceb231212eef4a4_xxx is associated with RDS, and this GUID like number is the pair key for both the computer and user.

If you use the certutil -key command, you would see this Cert key with TSSecKeySet1:

f686aace6942fb7f7ceb231212eef4a4_xxxxxxxxxx: AT_KEYEXCHANGE

From the Procmon Logs:
 
12:39:53.5364585 AM lsass.exe 588 CreateFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\f686aace6942fb7f7ceb231212eef4a4_xxxx ACCESS DENIED Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: N/A, Share Mode: Read, Allocation Size: N/A,
Impersonating: NT AUTHORITY\NETWORK SERVICE
 
12:40:24.3692803 AM lsass.exe 588 CreateFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\f686aace6942fb7f7ceb231212eef4a4_xxxx ACCESS DENIED
Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, Share Mode: Read, Allocation Size: n/a, Impersonating: NT AUTHORITY\SYSTEM
 
12:40:23.9265708 AM svchost.exe 1012 CreateFile C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\f686aace6942fb7f7ceb231212eef4a4_xxxx ACCESS DENIED
Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, Share Mode: Read, Allocation Size: n/a
 
So, what are the default permissions?  Well, you can use icacls to find this:
 
C:\>icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\
Everyone :(R,W)
BUILTIN\Administrators :(F)
 
c:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\f686aace6942fb7f7ceb231212eef4a4_xxxxx
NT AUTHORITY\NETWORK SERVICE :(R)
NT AUTHORITY\SYSTEM :(F)
BUILTIN\Administrators ::(R)

In case if you want to grant permission using icals you can provide the same using following command :
 
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\f686aace6942fb7f7ceb231212eef4a4_xxxxx /grant " NT AUTHORITY\NETWORK SERVICE :( R)
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\f686aace6942fb7f7ceb231212eef4a4_xxxxx /grant " NT AUTHORITY\SYSTEM :(F)
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\f686aace6942fb7f7ceb231212eef4a4_xxxxx /grant " NT AUTHORITY\NETWORK SERVICE :(R )

Fig 1.1 (Permission in Windows Explorer)

As you can see above, the SYSTEM accounts needs the proper permissions.  If these permissions have been changed, then they need put back to defaults.  The certs under this key should be inheriting the above permissions from the parent folder MachineKeys.

You can restore permissions, grant the permissions back using icacls, or use the Windows Explorer GUI.  Correcting the default permission on the cert should allow RDP to now work correctly.

Considering if this would have been easily reproducible, there is always an option to enable the Auditing on the cert key f686aace6942fb7f7ceb231212eef4a4_xxxxx under “C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys”.  This can be done using the Security Tab on Properties of the cert key as seen in the screenshot below:

NOTE Adding Auditing on this object will log Events to the Security Event Logs.  You will want to keep this enabled until you are able to reproduce the connection issue.

Hope you find this information helpful.

Additional Resources