Friday, August 4, 2017

Remote Desktop Connection"An internal error has occurred"


Yeah, try googling that.

  

You will find a gazillion posts with a gazillion different solutions.  None of which fit my case….well at least first half gazillion didn’t.

So I’ll add some keywords here to help this pop out to anyone else who has the same problem as me.

Event 5061 audit failure
TsSecKeySet1

The symptoms we were seeing were happening when attempting to access a Windows Server 2012 Enterprise server via RDP from a Windows 10 Professional workstation.  The error was “An internal error has occurred” which based on my Internet research directly translates to the OS sayin, “huh….that’s weird.”
Nothing particularly useful found in the workstation’s Application or System event logs.  Not much in the server’s either.  But, the criminal’s fingerprint was clearly found in the Security event log, with a one to one correlation of attempts and the following events.
Event Id 5061 audit failure.

Cryptographic operation:
Subject:
                Security ID: NETWORK SERVICE
…blah blah blah…

Cryptographic Parameters:
                Provider Name: Microsoft Software Key Storage Provider
                Algorithm Name: UNKNOWN
                Key Name: TSSecKeySet1
                Key Type: Machine key.

Cryptographic Operation:
                Operation: Open Key.
                Return Code: 0x80090016

Everything you need is in that audit failure.
You see, it turns out the real problem here is that the NETWORK SERVICE account on the server does not have access to the key needed to establish a secure terminal services session.  But where the hell do you set those permissions?  In the file system of course  

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

In my case, I turned to a server that was working and just changed the security settings on my bad server to match the good one.  Those were:

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
·         (local)SYSTEM – Full Control
·         (local)NETWORK SERVICE – Read
·         (local)Administrators – Read

Now, since this was very much an exploration versus a procedure, I also modified rights on the 
following file within the MachineKeys folder as well.

                f686aace6942fb7f7ceb231212eef4a4_xxxxx
·         (local)SYSTEM – Full Control
·         (local)NETWORK SERVICE – Read
·         (local)Administrators – Read

Followed this up with a reboot and like magic, all was well.  I suspect there was a single service that could have been restarted to achieve the same affect, but again this was an exploration, not a procedure.
Hope this helps someone else out.

Peace

d.Stutt