Starting with the May cumulative Windows 10/Server 2016 update, you may have run into a CredSSP error when trying to connect via Remote Desktop Protocol (RDP) to another computer.  Specifically, you get the following error:

An authentication error has occurred. The function requested is not supported. Remote computer: <computer name or IP>. This could be due to CredSSP encryption oracle remediation…

It’s not just you, it surprised a bunch of people.  So what’s happening and how do we resolve this issue and get you connected again?  Well, the short answer is both computers need to be updated, the long answer is there’s a workaround…

What is this whole CredSSP?

The Credential Security Support Provider (CredSSP) protocol is basically one of the ways credentials are passed between computers during an RDP connection.  There’s an identified vulnerability that allows remote code execution during this credential hand-over (see CVE-2018-0886 entry in the NVD for technical details).  So, it’s important that your Windows systems, both client and server, are patched.  The RDP connection problem occurs when one system is patched and the other system is not.  By default, patched systems will not connect/permit connections from unpatched systems… that’s the issue.

Workaround for temporary connections

First off, let’s remember this is a WORKAROUND.  You really really really need to get all your systems patched ASAP.  But, you might need to connect remotely to a system in order to patch it… I hear ya…

Remote system is patched, local system is unpatched

This one is easy.  PATCH YOUR SYSTEM!  Once the patch is installed and your system is rebooted, you’ll be able to connect.  The patch is available via your regular Windows Update.

Local system is patched, remote system is unpatched

The actual patching of the CredSSP happened in a March update, the error messages were updated in April but, in May, the Registry was changed to disallow connections between patched and unpatched systems.  You can bypass this security setting via Local Group Policy or via the Registry.  Pick your poison, you only have to use one method OR the other:

  1. Open the Local Group Policy Editor by going to your Start Menu and typing “gpedit.msc“, right-click on the search result and choose “Run as administrator“. (SCREENSHOT)
  2. Browse to Computer Configuration >> Administrative Templates >> System >> Credentials Delegation. (SCREENSHOT)
  3. Select Encryption Oracle Remediation policy and set it to Enabled.
  4. Change the Protection Level to Vulnerable. (SCREENSHOT)


Be super-careful here!

Editing your Registry incorrectly can cause all kinds of screwy system problems or even prevent your computer from starting altogether. Follow these instructions EXACTLY and take backups of your Registry before proceeding. If you do not know how to backup and restore your Registry, you should not be editing it in the first place and should NOT proceed! (Okay, obligatory warning out of the way... back to the good stuff)

  1. Open an Administrative Command Prompt.  Go to your Start Menu and type “cmd“.  Right-click on the Command Prompt and select Run as Administrator (or -key + x and select “Command Prompt (Admin)”)
  2. Type the following to add a key to the Registry (note: type this all on one line):
REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2
  1. Giv’er a reboot and you’re in business.  You should be able to connect to an unpatched system.

Resetting your system to a secure state

After you’ve connected to whatever unpatched systems you need to work with, it’s important to reset your system to refuse unsecured connections by default.  In other words, we need to reverse exactly what we just did in the previous step. Here are your options again… remember, chose one method OR the other:

  1. Open the Local Group Policy Editor by going to your Start Menu and typing “gpedit.msc“, right-click on the search result and choose “Run as administrator“. (SCREENSHOT)
  2. Browse to Computer Configuration >> Administrative Templates >> System >> Credentials Delegation. (SCREENSHOT)
  3. Select Encryption Oracle Remediation policy and set it to Not Configured. (SCREENSHOT)


Be super-careful here!

Editing your Registry incorrectly can cause all kinds of screwy system problems or even prevent your computer from starting altogether. Follow these instructions EXACTLY and take backups of your Registry before proceeding. If you do not know how to backup and restore your Registry, you should not be editing it in the first place and should NOT proceed! (Okay, obligatory warning out of the way... back to the good stuff)

  1. Open an Administrative Command Prompt.  Go to your Start Menu and type “cmd“.  Right-click on the Command Prompt and select Run as Administrator (or -key + x and select “Command Prompt (Admin)”)
  2. Type the following to delete the key added earlier from the Registry (note: type this all on one line):
REG DELETE HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle
  1. Reboot and you’re in business.  Your system will revert to default (patched) behaviour and you’ll only connect to other patched systems.

Q&A for the curious-minded

Why is the default set to require all systems be patched before connecting?

When connecting, credentials have to be passed from one system to another.  Therefore, any system that is not patched is vulnerable to having code executed during this transfer… that’s the problem.  To avoid this, the systems check whether or not the other one is patched and if not, the credential transfer doesn’t even occur thereby mitigating the risk of remote code being executed.

What do the numbers in the Registry setting mean?

They correspond to the order of the Group Policy settings (actually vice-versa, but go with me here).  Here’s a table to summarize:

Property
Value
Force updated clients
0
Mitigated
1
Vulnerable
2

 

Why am I deleting everything to re-secure my system?

It may seem that you need to set the Oracle Remediation policy to ‘Force updated clients’ (or 0 in the Registry) to undo the changes in this article… you’d be right.  However, that also means Windows has to check and apply that policy.  On the other hand, on a patched system, those are the default settings.  So by simply deleting any contrary policies/settings, Windows will use its defaults which is faster.

Well, that’s it from me on this topic.  I hope this helps you get connected and update all your systems.  Thanks for reading my techie-thoughts on this issue. Have any comments? Suggestions? Want to add your tips? Things you want me to cover in a future article? Comment below!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Menu