Unable to RDP to Virtual Machine: CredSSP Encryption Oracle Remediation


We have published an official KB on this issue. Please see the following: https://support.microsoft.com/en-us/help/4295591



With the release of the March 2018 Security bulletin, there was a fix that addressed a CredSSP, “Remote Code Execution” vulnerability (CVE-2018-0886) which could impact RDP connections. The vulnerability was discovered to which the exploits observed were:

  • Targets receive a malicious RTF Microsoft Office document
  • After being opened, the malicious document causes the second stage of the exploit to be downloaded in the form of an HTML page with malicious code
  • The malicious code triggers the use-after-free memory-corruption bug
  • Accompanying shellcode then downloads and executes a malicious payload


1.       The VM screenshot shows the OS fully loaded and waiting for the credentials

2.       If you try to RDP the VM either internally or externally, you'll get the message:

An authentication error has occurred.

The function requested is not supported.


This could be due to CredSSP encryption oracle remediation.

For more information, see https://go.microsoft.com/fwlink/?linkid=866660

To discuss further regarding this update please see: General Discussion - Unable to RDP: CredSSP

If the below steps do you help you in resolving your issue please open a new forum post to Azure Virtual Machines

Root Cause Analysis

To resolve a vulnerability issue with Credential Security Support Provider protocol (CredSSP), a monthly Windows update in May was applied which does two things:

1.       Correct how Credential Security Support Provider protocol (CredSSP) validates requests during the authentication process

2.       Change the group policy Encryption Oracle Remediation default setting from Vulnerable to Mitigated.

This RDP authentication issue can occur if the local client and the remote host have differing Encryption Oracle Remediation settings that define how to build an RDP session with CredSSP. If the server or client have different expectations on the establishment of a secure RDP session the connection could be blocked. There is the possibility that the current default setting could change from the tentative update and therefore impact the expected secure session requirement.

Below is the matrix for each possible situation for RDP result:



1.       If the client is updated and you try to RDP to an Azure VM that was not updated, then it will be blocked and see the error message.

2.       If the client is not patched while server is updated, RDP can still work. But the session will be exposed to the attack.

3.       If both client & server are patched with default setting (Mitigated), RDP will work in a secure way.


Resolution/ Fix

Ensure both client & server side have latest patch installed so that RDP can be established in a secure way.

You can find the list of the corresponding KB number for each operating system here: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886


 Alternative Work-arounds

Mitigation 1

If you cannot RDP to  VMs from your patched client, we can consider changing the policy settings on the client to temporarily gain RDP access to the servers. You can change the settings in Local Group Policy Editor. Execute gpedit.msc and browse to Computer Configuration / Administrative Templates / System / Credentials Delegation in the left pane:

Change the Encryption Oracle Remediation policy to Enabled, and Protection Level to Vulnerable:


 Mitigation 2

If it is not possible to access to Local Group Policy Editor on the client (i.e. Windows Home versions), same change can be done through the registry:

REG  ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2

After that, whether the established RDP session is secure or not depends on whether server is patched. Remember to un-do this when all the servers are patched.


Comments (20)

Cancel reply

  1. Ryan S says:

    Just to state the obvious, this can affect a physical server as well! This doesn’t only affect a Virtual Machine (Yes, I understand this Azure VM blog). But this also was top hit on the good ole “Bing/Googlizer” searching for CredSSP RDP error.

  2. No tengo esa opción en Windows 10 HOME (I don’t have that Option In windwos 10m home to fix the problema) Not available gpedit.msc

  3. fatih says:

    hello managed to connect with your help
    could you please tell how to reverse last mitigation

  4. Ahmed Mihoub says:

    thanks for this post, it’s very helpful.

  5. LukeChung says:

    We’ve seen lots of people running into this problem where they can’t remote to their office computer or VM from home.

    We’ve found an easier workaround that doesn’t require touching the registry or setting group policies. Simply adjust the Remote Desktop settings.

    Wrote about it here: http://blog.fmsinc.com/remote-desktop-authentication-error-function-requested-is-not-supported-credssp/

    1. kiamoyman says:

      LukeChung suggestion worked for me! :) Thanks sir!

  6. ECarbone says:

    In my scenario, users are getting this message when they attempt to remote into their office workstations from home. So in this case there is no ‘server’. Does this same solution apply to home workstation to office workstation remote sessions? Does this mean the issue will be resolved if both ends (the home pc and the office pc) install the update?

  7. Siva1979 says:

    Thanks for the article. It helped me.

  8. UniMatrix says:

    Also the VM connections from Hyper-V manager are disabled. Luckily the Group Policy / registry key workaround is client based, otherwise an updated client would lose all console acces to our yet unpatched servers… Bit unnerving if you ask me.

  9. UniMatrix says:

    After some more testing it is becoming clear that when a server VM is patched, it IS possible to RDP to the server, but the VM connection from hyper-v manager is still NOT working.

  10. Devil-AP says:

    This happened to me where I work (a school) and as my Network Manager brought this problem to my attention – it seems as if the registry fix helps us remote back into the servers we couldn’t access.

    Download this batch script I made – it uses Mitigation 2 but people may find a use for the script.


  11. \ /v AllowEncryptionOracle /t REG_DWORD /d 2

    Means: Add new REG_DWORD; then Modify it to set the type from Hexadecimal to Decimal with the value from 0 to 2

  12. very helpful. thank you very much

  13. Naeem Jamil says:

    thanks Mitigation 1 works for me

  14. BolvuaM says:

    In gpedit Editor change on Encryption Oracle Remediation > Vulnerable didn’t nothing.. Even it is accessible.
    But REG ADD helped… Thank you a lot!!!! :)))

  15. Nop Siri says:

    Solved. Mitigation 2 works with my Windows 10 Home 64 bit. Thanks.

  16. iru17 says:

    Thanks for this post, it’s very helpful.
    It helped me fixing the issue.

  17. MaxPax80 says:

    Mitigation 2 solved the problem for me. Thanks for sharing the trick!

  18. It works, thank you


Skip to main content