none
Remote Desktop Suddenly Broken due(?) to CredSSP encryption oracle remediation

    Question

  • I have a couple of Azure VMs which others and I remote into regularly.  We stopped & restarted this morning but get the following error trying to remote in.  I gather from the reference we probably should have updated some group policy setting before May 8? Is there a way to get these VMs back on their feet, RDP-wise?  

    Wednesday, May 09, 2018 2:40 PM

Answers

  • You're getting that error because your RDP client (local machine) has been patched with a Windows Update and the server you're connecting to has not had the patch for the CredSSP issue. If both systems were patched then you would not be receiving this error. You have 2 options:

    1 - Update the server with the patch for the CredSSP issue (preferable)

    2 - Change the Group Policy on your local client to use the Vulnerable setting in

    Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation

    Hope that helps

    • Marked as answer by T.A.Schultz Wednesday, May 09, 2018 9:57 PM
    Wednesday, May 09, 2018 9:49 PM
  • Having a similar issue with one of my users.

    The VM server in Azure had recently been turned back on after a month hiatus or so (to reduce cost, obvs) and I can log in to it just fine from my workstation (a VDI itself).  Not sure why this would affect one and not the others...

    • Marked as answer by T.A.Schultz Wednesday, May 09, 2018 5:58 PM
    Wednesday, May 09, 2018 5:12 PM

All replies

  • The error is due to a combination of three factors:

    ·         You activated NLA on your target computer

    ·         The target computer is not patched for CVE-2018-0886

    ·         You enforced the Force updated clients or Mitigated parameters on the source computer

    NLA uses CredSPP (for pre-authentication) which is impacted by CVE-2018-0886.

    The most common scenario could be the following one:

    ·         You enforced NLA on your servers since a long time

    ·         You recently patched your workstations for CVE-2018-0886 and enforced the Force updated clients or Mitigated parameters on your workstations

    ·         However,you didn’t patch your servers for CVE-2018-0886

    ·         And now you are stuck with this error message when you try to open an RDP session on a non-patched server.

    Refer the link which discusses about the same issue and let us know.

    Wednesday, May 09, 2018 3:32 PM
    Moderator
  • I have seen this error when the first two issues alone are in play.

    ·         You activated NLA on your target computer

    ·         The target computer is not patched for CVE-2018-0886

    You enforced the Force updated clients or Mitigated parameters on the source compute

    The last issue is not in play in our environment.  There is no GPO policy with the settings you are talking about.

    Good info though, thanks!


    -=Chris



    • Edited by Progent.CT Wednesday, May 09, 2018 4:14 PM
    Wednesday, May 09, 2018 4:13 PM
  • I guess the factors you described happen by default or through automatic updates because we certainly did not take those actions (except for non-patching).  But benign neglect can lead to bad results though this outcome is very disappointing and the punishment (dead remote VMs which nearly 100 people used regularly) well beyond the 'crime'.

    Without being able to log in locally to an Azure VM to tickle its innards as you suggest, I take it the VM is hosed in Azure?  My only thought is to download the VHD, build a local VM based on it, fix the local VM, re-upload the VHD, and rebuild the VM in Azure; can you think of anything easier to preserve the VM?  

    An addendum:  A web search suggested that the mobile version of RDP is not crippled by this issue.  My trusty Win 8.1 phone remoted in just great.  So there has to be something that can be done on the client side in general.  Any quick (and I don't mind dirty) advice welcomed.
    • Edited by T.A.Schultz Wednesday, May 09, 2018 4:49 PM Some extra thoughts
    Wednesday, May 09, 2018 4:26 PM
  • Having a similar issue with one of my users.

    The VM server in Azure had recently been turned back on after a month hiatus or so (to reduce cost, obvs) and I can log in to it just fine from my workstation (a VDI itself).  Not sure why this would affect one and not the others...

    • Marked as answer by T.A.Schultz Wednesday, May 09, 2018 5:58 PM
    Wednesday, May 09, 2018 5:12 PM
  • Based on what you suggested I started up a local VM on my laptop and successfully remoted in from there even though the laptop cannot; very nice because doing the policy bits on the phone was making me crazy. But as you say kind of odd that this (being in a VM) should matter. I am guessing some detritus on my laptop from earlier remote access caused the clamp down whereas my VM was a little purer.

    Thanks for the quick and not so dirty workaround!

    Wednesday, May 09, 2018 5:58 PM
  • If this comes up with someone else keep in mind that your advice may be far more intricate than needed.  In my case NLA was never touched and no group policies related to Credentials Delegation were ever configured.  The remote server (an Azure VM running Windows Server 2016) had updates last applied in Jan 2018 and not since until today (I have about 100 students using the resource and I hesitate to break things with updates during the term).  Before updates today I noticed the Encryption Oracle Remediation group policy didn't exist at all in the Credentials Delegation; after updates it was there but Not configured.  Perhaps some other magic occurred when installing updates in the server but the authentication issue using remote desktop has gone (at least from the one client computer I tried).

    So after applying rule 1 of system administration (turn it off & back on again), always try rule 2 (apply updates).

    I get it about a potential vulnerability and will look into it when I can thoroughly test. Thanks for the help.

    Wednesday, May 09, 2018 8:29 PM
  • You're getting that error because your RDP client (local machine) has been patched with a Windows Update and the server you're connecting to has not had the patch for the CredSSP issue. If both systems were patched then you would not be receiving this error. You have 2 options:

    1 - Update the server with the patch for the CredSSP issue (preferable)

    2 - Change the Group Policy on your local client to use the Vulnerable setting in

    Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation

    Hope that helps

    • Marked as answer by T.A.Schultz Wednesday, May 09, 2018 9:57 PM
    Wednesday, May 09, 2018 9:49 PM
  • Thanks ... this clears things up.  My initial reaction on Group Policy was fiddling with the Remote Server, not the client.
    Wednesday, May 09, 2018 9:59 PM
  • Thank you for this post, took care of the issue choosing option 2 for me.
    Thursday, May 10, 2018 12:22 AM
  • Another way is to remove latest Security Update for Microsoft Windows (KB4103721) — https://youtu.be/UoXaTx05INI
    Thursday, May 10, 2018 6:49 AM
  • "2 - Change the Group Policy on your local client to use the Vulnerable setting in"

    Changing this setting didn't work for me, it was originally set to "Not configured" and I tried changing it to Enabled and it didn't work, also tried Disabled and it didn't work either.

    • Proposed as answer by samuelver Tuesday, May 29, 2018 1:44 PM
    • Unproposed as answer by samuelver Tuesday, May 29, 2018 1:44 PM
    • Proposed as answer by samuelver Tuesday, May 29, 2018 1:45 PM
    • Unproposed as answer by samuelver Tuesday, May 29, 2018 1:45 PM
    Thursday, May 10, 2018 8:23 AM
  • Any solution for this? i also tried point 2. and it didn't work. I badly need to access my Azure VM via rdp.
    Thursday, May 10, 2018 9:03 AM
  • Try adding or changing the following key in the registry on the client running the remote desktop:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters]
    "AllowEncryptionOracle"=dword:00000002

    Than reboot and try
    • Edited by roberto cereda Thursday, May 10, 2018 9:20 AM
    • Proposed as answer by menu1a Thursday, May 10, 2018 11:27 AM
    Thursday, May 10, 2018 9:06 AM
  • Just briefly what helped me:

    I used a local VM (or maybe a different Azure VM?) or phone to remote into my Azure VM, applied updates (which apparently included this patch), and remoting to the server in general worked.  If you're not admin of the remote VM then this won't work, natch.  As far as I can tell this solves the issues for others trying to remote as well; working with Group Policy or the registry on the client is one-off per client.  In my case the remote server did not have NLA configured at all.  And not sure why remoting from a phone or a hyper-v VM on my laptop worked where plain ol' RDP didn't.

    Thursday, May 10, 2018 1:06 PM
  • I login successfully. 

    thank you !!

    Thursday, May 10, 2018 2:51 PM
  • this reg key works for me. thx
    Thursday, May 10, 2018 4:35 PM
  • no need to reboot
    Thursday, May 10, 2018 4:36 PM
  • thanks.. this worked for me .. had to add everything  from CredSSP onward
    Friday, May 11, 2018 12:29 AM
  • Hi,

    Can you please share the link for installing the below patch in Windows2012R2 TS?

    1 - Update the server with the patch for the CredSSP issue (preferable)

    Thanks-Vinod

    Friday, May 11, 2018 5:24 AM
  • Great, awesome.

    Thank you very much.

    Friday, May 11, 2018 7:44 AM
  • We're seeing similar problems not just with Azure VMs but many machines that people are trying to remote into. This also impacts VPN connections. It's not clear why Remote Desktop Connections that have worked for years all of a sudden fail.

    I think it has something to do with the host computer not allowing Windows Updates. This security patch increased requirements, but the Windows Update must be allowed to implement a security change so that remote connections continue to work. Unfortunately, for many environments, especially development, build, testing, staging and production platforms, can't have Automatic Updates without creating other problems. 

    I can't imagine telling all general users to manually edit their registry settings or assume they have the right to do so. What a mess.

    I wrote a blog post describing our findings so far with a workaround: Remote Desktop Authentication Error Has Occurred. The function requested is not supported. CredSSP

    Our suggested workaround is interactive, doesn't require touching the registry, and seems to work by setting the Remote Desktop setting to Less Secure.

    Hope this helps. Looking forward to a real solution. A Microsoft employee told me this yesterday:

    "I double checked the Windows bug database and they are aware of the problem. No ETA on a fix yet unfortunately. Your workaround is what’s suggested to temporarily get around the error, although it is not suggested as a long term fix."


    Luke Chung
    Microsoft MVP
    President of FMS, Inc.
    Blog Facebook Twitter



    Friday, May 11, 2018 12:33 PM
  • Hi Schultz, 

    I changed the settings through the registry. 

    Can you tell me how to undo this on Win 10 Home edition?

    Sunday, May 13, 2018 3:45 PM
  • @ParthTyagi:  My suggestions above side-stepped changing the registry or group policy (I wanted to avoid doing anything with my client RDP machine unless I had to). I am not sure what you are trying to undo ... did your registry change allow you to remote in (e.g., from your Win 10 Home Edition)? If you can't fix the remote access machine then you don't want to undo your change. Maybe clear up what it is you are trying do?

    Sunday, May 13, 2018 10:44 PM
  • Yes Schultz, My registry change allowed me to remotely access my VM and I updated the server with the patch for CredSSP issue. 

    Now, since my VM is updated and working fine, Can I undo the changes I made in the registry of my Win 10 machine?

    If Yes, How?

    Monday, May 14, 2018 6:30 AM
  • I don't think keeping your registry key on your client does any harm and I guess it inoculates you against un-updated remote servers but to be sure your computer behaves like others which have not added this key (that was one of my goals) I am pretty sure you can just delete it (again, I never added this key but my computers are doing fine without it now that the remote server is updated).  To delete a registry key, navigate to the key using RegEdit, right-click on it, and choose delete.

    Monday, May 14, 2018 8:32 AM
  • The 2nd choice worked out best for me.
    Monday, May 14, 2018 9:04 AM
  • Got it. Thanks a lot 
    Monday, May 14, 2018 9:27 AM
  • Hi all 

    :Enter CMD as an administrator and paste the following command

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



    • Edited by Roi - up Monday, May 14, 2018 10:06 AM
    Monday, May 14, 2018 10:03 AM
  • If you can't access Group Policy console, please run the below command in your client machine.

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

    Monday, May 14, 2018 3:16 PM
  • You're getting that error because your RDP client (local machine) has been patched with a Windows Update and the server you're connecting to has not had the patch for the CredSSP issue. If both systems were patched then you would not be receiving this error. You have 2 options:

    1 - Update the server with the patch for the CredSSP issue (preferable)

    2 - Change the Group Policy on your local client to use the Vulnerable setting in

    Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation

    Hope that helps


    This is the only answer that worked in my environment. Windows 10 Pro. Server 2016 essential
    • Proposed as answer by NCCU Admin Monday, May 14, 2018 5:39 PM
    Monday, May 14, 2018 5:38 PM
  • https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886
    Wednesday, May 16, 2018 2:47 PM
  • Try this, It would help.

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

    • Edited by Tamil M Friday, May 18, 2018 10:36 AM
    Friday, May 18, 2018 10:36 AM
  • you need to enable, then select Vulnerable from the other drop down (the one that is grey before you enable)
    • Proposed as answer by samuelver Tuesday, May 29, 2018 1:45 PM
    Tuesday, May 29, 2018 1:45 PM
  • I have a Windows 7 PC that HOSTS the Remote Desktop session that cannot be connected to because of this error. Would someone kindly tell me the KB number of the update that needs to be applied for Windows 7? Thanks!

    Corey Ames

    Thursday, May 31, 2018 7:43 PM