Woody Leonhard's no-bull news, tips and help for Windows, Office and more… Please disable your ad blocker – our (polite!) ads help keep AskWoody going!
Home icon Home icon Home icon Email icon RSS icon
  • Problems with CredSSP updates CVE-2018-0886 breaking RDP connections

    Posted on May 9th, 2018 at 11:48 woody Comment on the AskWoody Lounge

    Yet another mess.

    @GeekDiver reports:

    Looks like CVE-2018-0886  was included in the cumulative update and is breaking RDP connections and App feeds.   No backward compatibility in CredSSP right now we are dealing with 100 Windows 10 PCs that are affected.   Anyone else seeing this?

    The CVE-2018-0886 article lists every current version of Windows as falling under this patch’s spell.

    Microsoft has an extensive list of errors generated by this update in KB 4093492, which mentions this error and offers a link to https://go.microsoft.com/fwlink/?linkid=866660 — which, in turn, links back to the same article.

    Kinda like chasing your tail. Windows is the productivity OS, right?

    Susan aka Patch Lady note as of 5/9/2018:  Please note the problem is NOT with the update.  Rather the issue is that there’s a mismatch of patching levels.  In March Microsoft released an update that began the process of rolling out an update to CredSSP used in Remote Desktop connection.  In May the updates mandate that a patched machine can’t remote into an unpatched machine.  If you dig into the KB there is a registry workaround to [TEMPORARILY] disable the mandate, but the better and wiser move is to update the server or workstation you are remoting into.  Make sure the “thing” you are remoting into has an update.  Also note that for consumers and home computers you probably won’t see this issue.  This only has impact if you use Remote Desktop connection to remote into another computer.

    If that helped, take a second to support AskWoody on Patreon

    Home Forums Problems with CredSSP updates CVE-2018-0886 breaking RDP connections

    This topic contains 76 replies, has 17 voices, and was last updated by  anonymous 2 months, 3 weeks ago.

    • Author
      Posts
    • #191198 Reply

      woody
      Da Boss

      Yet another mess. @geekdiver reports: Looks like CVE-2018-0886  was included in the cumulative update and is breaking RDP connections and App feeds. 
      [See the full post at: Problems with CredSSP updates CVE-2018-0886 breaking RDP connections]

      4 users thanked author for this post.
    • #191205 Reply

      WildBill
      AskWoody Lounger

      & THIS is why consumers are losing faith in Windows (already too late for Microsoft). Not the last straw to send me to Mac or Linux… yet. Somebody’s not paying attention when a bug like this goes out to ALL flavors of Windows… even RT!

      Windows 8.1, 64-bit, now in Group B!
      Wild Bill Rides Again...

      2 users thanked author for this post.
    • #191212 Reply

      mcbsys
      AskWoody Lounger

      I don’t know where the original @geekdiver post is so don’t know the context. I suspect unpatched servers and/or clients.

      This is a planned tightening of security over three months. As promised, the May update changed the default to Mitigated. You can use group policy or registry to change it back to Vulnerable until you get your systems patched. Susan gave a heads-up on this in March:  https://www.askwoody.com/2018/patch-lady-tracking-some-post-release-issues/:

      “Initially in March, they are rolling out the new protocol. Later in April they will make it so that an error message will occur when you attempt to remote from a patched machine to an unpatched machine, and then later in May (tentative at this time) the default will be to enforce that remoting from a patched machine to an unpatched machine will not work.”

      I hate it when Microsoft releases bugs that affect millions. In this case, I think Microsoft deserves credit for FIXING a security bug with a careful, documented, multi-month rollout of a mitigation.

      7 users thanked author for this post.
      • #191214 Reply

        PKCano
        AskWoody MVP
      • #192702 Reply

        MXMasterNL
        AskWoody Lounger

        I agree with you that Microsoft has provided ample warning of this and in my personal opinion there indeed isn’t a lot wrong with the way they have been securing this protocol in the “careful, documented, multi-month rollout of a mitigation” way as you have described it.

        One small caveat though: I can confirm this problem also affects May rollup patched Windows 10 machines RDP-ing into April rollup patched servers. According to the KB that shouldn’t happen. It also presented me (And a lot of other people and Administrators alike I am sure.) with a predictable problem:

        -Generally workstations/desktops/notebooks are set to automatically download and install updates. Because of this, they generally have the rollup installed on, or shortly after, patch tuesday.
        -Generally server administrators tend to have the Microsoft Update setting set to “Download but let me decide when to install”. This will provide them with a (hopefully short) windows of time to evaluate any major problem with the updates during the days that follow patch tuesday. We, for example, tend to patch our clients servers the first week-end after patch tuesday. This, as proven by a few troublesome updates we have seen over the past few years, isn’t an unwise approach while still not affecting security a whole lot.

        And there you have it: Administrators like myself who have to patch a lot of client servers monthly from a remote location patched to a patch level “only one patch tuesday behind” suddenly are unable to RDP into said servers. So the general feeling that seems to be around that this problem only affects “Those naughty administrators that are laggin way behind in their updates” is a little unjustified in my humble opinion. 😉

        • #192707 Reply

          mcbsys
          AskWoody Lounger

          Allowing May-patched clients to connect to April-patched servers should have addressed the patching scenario you described, but if that doesn’t work as documented, yeah that’s a problem.

          • #192722 Reply

            MXMasterNL
            AskWoody Lounger

            I can truly confirm that behaviour, as we have experienced and tested said problem from 3 different Windows 10 Pro workgroup machines fully patched to may rollup level RDP-ing into 6 different physical and virtual servers fully patched to april rollup level, both locally and offsite via VPN. Affected servers where on two different geographical locations. Site-2-Site “VPN-ing” from two different geographical locations. Said testing was only out of curiousity though as on the first workstation I encountered the problem I was able to circumvent the problem after less then 15 minutes of “googling” applying the “Encryption Oracle Remediation” setting in GPO Computer Configuration -> Administrative Templates -> System -> Credentials Delegation to value 3 (vulnerable) on said desktop. We have external access to a lot of servers and workstations though, so out of curiousity (After all, this shouldn’t happen.) I made sure to test a lot of different combinations before I patched all servers only hours later.

            One caveat: All mentioned servers are non-english versions (dutch) as are all mentioned Windows 10 Pro clients. Furthermore, all servers had NLA enabled, be it through RDP settings on non domain joined machines or by GPO and RDP settings (We like to tick them both) on domain joined machines.

            • #192723 Reply

              mcbsys
              AskWoody Lounger

              Wish I had suggestions other than opening a support case.

            • #192727 Reply

              MXMasterNL
              AskWoody Lounger

              Why would I? All servers where patched with only a few hours of delay. And losing hours instead of minutes was more because I tested a lot because I wanted to know the specifics of the problem.

              Summarizing I think I can safely state the May Rollup does contain some errors affecting clients trying to rdp into machines patched to April Rollup level, and I van only hope the information I provide here will help others with the same problem.

              Now if only somebody could confirm that this behaviour also occurs RDP-ing into english versions of Servers (and workstations) patched up to April Rollup level… 😉

            • #192779 Reply

              mcbsys
              AskWoody Lounger

              “Why would I?”

              Maybe you would like to know that your RDP communications are secure.

              Maybe you would like to report the problem to the vendor who can fix it, not just in a user-to-user community.

              Maybe they could either confirm that it’s a bug or perhaps identify what is different in your environment that is causing the issue. Seems like if this were a common issue even on non-English versions, we would be hearing more about it. Have you found others who are reporting this?

            • #192790 Reply

              MXMasterNL
              AskWoody Lounger

              Maybe you would like to know that your RDP communications are secure.

              Nope, I have no doubts at all they are.

              Maybe you would like to report the problem to the vendor who can fix it, not just in a user-to-user community.

              I’d rather spend my scarce time posting on forums like this one where it might actually do some good then trying to pull the dead blue whale that I personally see as a fitting synonym for Microsoft of the accossiated similitudous beach all by myself. I have been there, and have done that. Having created a few (Well, make that a lot.) of my own I have reluctantly come to believe that in order for Microsoft to even state a “known issue” in any of their KBs either a gazillion of little computer people like myself have to sumbit a support ticket or it has to be one posted by a person who signs of with a company name like Dell, in which case miraculously the giant will awake. At the moment a google search for “this could be due to credssp encryption oracle remediation” (Yes, that’s a search within quotation marks.) yields 117.000 results, but sure enough on the kb4103725 page Microsoft still states “Microsoft is not currently aware of any issues with this update.” They must be using Bing, I guess. I have created support cases about demonstrable faults in Office 365, Open License Activation, Onedrive and have seen desired features and improvements by users on the Windows Phone platform reach 400.000 points, still not netting any results sometimes even years later. If one as an individual user or even huge group of individual users want to see a big company do anything with their feedback one should contact companies like Google, not Microsoft. But if you feel the urge to do so, please go ahead, and make sure to also throw in total meltdown and the dissappearing nic issue while your at it, because it seems they still haven’t been completely resolved by these months updates, too.

              Maybe they could either confirm that it’s a bug or perhaps identify what is different in your environment that is causing the issue. Seems like if this were a common issue even on non-English versions, we would be hearing more about it. Have you found others who are reporting this?

              Stating the caveat that this behaviour (may patched clients rdp-ing into april patched hosts) happens on non-english language systems is because I haven’t yet seen other users experiencing that exact behaviour on the diverse other forums I have visited looking in to this specific problem. That’s actually trying to find a possible explanation why I don’t see a whole lot of other users with exactly that problem. So as far as my gut instincts go, this might be a problem only on non-english systems, not “even on non-English versions” as you seem to conclude. If such is the case, and therefore only a relatively small group of users is affected (We are rare in running non-English servers, only doing so because we used to be big proponents of Terminal Server which users seem to more enjoy in their native language.) submitting a support ticket would prove to be even more futile.

              1 user thanked author for this post.
    • #191217 Reply

      DrBonzo
      AskWoody Lounger

      Well, this is certainly confusing , to me at least. I don’t recall any update ever addressing this on my Win 7 machines and it doesn’t seem as though anything is being offered through Windows Update.

      Or is this something that gets addressed through a Rollup or security only update?

      Or, better yet, is this something that I, as a typical home user, don’t need to worry about?

      1 user thanked author for this post.
    • #191215 Reply

      anonymous

      Does anyone know if this is also a problem this month with the Windows 7 x64 Security Only patch?

      • #191255 Reply

        Susan Bradley
        AskWoody MVP

        Do you use RDP?  If you don’t even know what RDP/remote desktop protocol is you won’t even care or see this issue.

        Susan Bradley Patch Lady

        5 users thanked author for this post.
        • #191341 Reply

          anonymous

          (smile)  Ignorance is bliss ?   just asking.  Thanks Susan Patch Lady. !

        • #191355 Reply

          OscarCP
          AskWoody Lounger

          Patch Lady,

          I use, alternatively, RSA (pin+token) or VPN to login remotely from home to some government computers. I do not know if RDP or PowerShell is used with either of them.

          Could that be the case?

          My machine OS is Win 7 Pro x64 SP1.

           

          • #191370 Reply

            Susan Bradley
            AskWoody MVP

            If you don’t launch remote desktop connection and merely use VPN then no you won’t be impacted.  If you do use remote desktop connection (as is often used to launch access into a desktop) then check with your government IT department and ask if they have updated.

            Susan Bradley Patch Lady

            • #191507 Reply

              OscarCP
              AskWoody Lounger

              Thank you, Patch Lady.

              Your answer clears things up for me.

               

    • #191223 Reply

      GeekDiver
      AskWoody Lounger

      I don’t know where the original @geekdiver post is so don’t know the context. I suspect unpatched servers and/or clients. This is a planned tightening of security over three months. As promised, the May update changed the default to Mitigated. You can use group policy or registry to change it back to Vulnerable until you get your systems patched. Susan gave a heads-up on this in March: https://www.askwoody.com/2018/patch-lady-tracking-some-post-release-issues/: “Initially in March, they are rolling out the new protocol. Later in April they will make it so that an error message will occur when you attempt to remote from a patched machine to an unpatched machine, and then later in May (tentative at this time) the default will be to enforce that remoting from a patched machine to an unpatched machine will not work.” I hate it when Microsoft releases bugs that affect millions. In this case, I think Microsoft deserves credit for FIXING a security bug with a careful, documented, multi-month rollout of a mitigation.

      Definitely, agree they deserve some kudos for fixing the security hole but with how messy patches have been this first quarter of the year it does add to issues.

      • #191233 Reply

        woody
        Da Boss

        Got a question from @rpodric on Twitter:

        Do you know how he has the server set relative to the Encryption Oracle Remediation Group Policy? What he’s seeing would be expected in some cases.

         

      • #191287 Reply

        mcbsys
        AskWoody Lounger

        …but with how messy patches have been this first quarter of the year it does add to issues.”

        Fair enough. What used to be a few minutes a month (checking for Patch Tuesday issues before installing on Friday) has this year become a non-trivial part of my work most weeks.

        @geekdiver, did patching your server(s) fix your issue?

        1 user thanked author for this post.
    • #191229 Reply

      anonymous

      Most end users and consumers will never run into this and will not be affected by this. It only affects users that are using RDP (or remote PowerShell). Additionally, most people will just get this patch and nobody will know any different. In managed environments it’s a little different and you will need to patch both the client and server for this to be effective.

      The original fix came out in March’s security patch release and we waited 2 months for people to be ready and plan accordingly before turning it on so it wouldn’t break everyone. All up, this has been a very minor inconvenience to end users and IT departments.

      The vulnerability itself is an old and obscure architectural defect (10+ years), hence why it affects most versions of Windows. So why didn’t we find it then? Because we ain’t perfect.

      • #191236 Reply

        woody
        Da Boss

        Fair enough.

        The angst I’ve seen is with admins using RDP who aren’t familiar with the problem – all they know is RDP broke overnight.

        • #191250 Reply

          anonymous

          Unfortunately there’s not a lot we can do about that. If you choose not to patch immediately (which is reasonable) then you at least need to track the impact of doing so. If you patch some things on a schedule, and some things indiscriminately, you’re going to have a bad time.  If you do neither, well…

          1 user thanked author for this post.
    • #191238 Reply

      abbodi86
      AskWoody MVP

      They did gave 2 months notice about the change

      1 user thanked author for this post.
    • #191251 Reply

      Susan Bradley
      AskWoody MVP

      It’s only a mess because people aren’t patching their servers.  March is when these updates came out.  If you patched, you are fine.  Okay so you want to wait and not patch right away…. but still…. all this is showcasing is that we’re not patching consistently.

      Susan Bradley Patch Lady

      4 users thanked author for this post.
    • #191256 Reply

      Susan Bradley
      AskWoody MVP

      https://twitter.com/SteveSyfuhs/status/994247758415413248?s=20

      For those affected by the latest Windows Update for CredSSP: Update your servers — please don’t set your clients to vulnerable.

      Susan Bradley Patch Lady

      4 users thanked author for this post.
      • #191652 Reply

        anonymous

        There’s no need to updated servers if users the RDP cant save credentials all you need to do is to delete the saved connections and add it again,if shared printing is also affected all you need to is to clear your credentials manaager and re add  the profiles

    • #191300 Reply

      anonymous

      Is there a fix for this? I connect via RDC to one of my servers and now I can’t.

      • #191312 Reply

        mcbsys
        AskWoody Lounger

        anonymous, like Susan says, patch your server. Any cumulative server udpate from March onward should get you back in business.

      • #192083 Reply

        anonymous

        uninstall KB4103727  this update and restart your pc. you will be able to connect

         

        regards

        Joseph

    • #191311 Reply

      GeekDiver
      AskWoody Lounger

      Is there a fix for this? I connect via RDC to one of my servers and now I can’t.

      Have to update the server.

      • #191371 Reply

        Susan Bradley
        AskWoody MVP

        You can put in a registry key to lower the security on the workstation, but it’s really wiser to install the updates on the server.

        Susan Bradley Patch Lady

    • #191398 Reply

      anonymous

      Ran into this problem and applied the temp fix. I am extremely skeptical of applying updates to my Win2k8R2 servers due to that rebooting bug and I am still not sure if it has been fixed. For those who will give me grief running old server OS, same old story, no budget to upgrade.
      Will be seeking approval to upgrade next year but highly unlikely to happen… *sigh*

    • #191422 Reply

      columbia2011
      AskWoody Lounger

      According to article https://support.microsoft.com/en-us/help/4103718 – Microsoft has fixed problem with memory leak on SMB servers. Phantom NIC’s were solved in April CU.

      • #191425 Reply

        anonymous

        I really should just log in but I am bouncing around doing other things so sorry for posting Anon.

        They say they fixed it but then this:
        Symptom
        A stop error occurs on computers that don’t support Streaming Single Instructions Multiple Data (SIMD) Extensions 2 (SSE2).
        Workaround
        Microsoft is working on a resolution and will provide an update in an upcoming release.

        Edit to remove HTML.
        Please use the “Text” tab in the entry box when you copy/paste.

        • #191498 Reply

          Susan Bradley
          AskWoody MVP

          Not all side effects are going to be seen by everyone.  As was pointed out by Columbia, those are older chips and anything recent won’t be impacted.

          Susan Bradley Patch Lady

    • #191431 Reply

      columbia2011
      AskWoody Lounger

      SSE2 is enabled and supported on any CPU from Intel Pentium 4, AMD Athlon 64 or later.
      Intel Pentium 3s, AMD Athlon XPs (K7 Semprons) and older do not have SSE2.
      Those using Win7 on these ancient CPUs like Pentium 3 or Athlon XP should avoid installing any 2018 cumulative update as none of them work on non-SSE2 processors.

    • #191445 Reply

      MrJimPhelps
      AskWoody MVP

      the better and wiser move is to update the server or workstation you are remoting into

      It would be helpful if, when this situation is encountered, the popup error message would clearly explain that you are trying to remote into an unpatched server, and then give you a choice:
      * Do you want to connect to the unpatched machine as is?
      * Do you want to connect to the unpatched machine and then patch it?
      * Do you want to cancel?

      Windows would then do all of the work behind the scenes to complete the choice you make. You wouldn’t have to manually edit the registry, change the group policy, nothing.

      It wouldn’t have taken much to add the above code to the patch; and it would have allowed people to very easily make an informed choice on this issue.

      I’ll bet there are other similar situations where, if Microsoft had just coded the patch to handle things for the user and give a clear, simple explanation of the issue, there would be a lot fewer problems and a lot less ill will directed at Microsoft.

      Group "L" (Linux Mint)
      with Windows 8.1 running in a VM
      4 users thanked author for this post.
      • #191497 Reply

        Susan Bradley
        AskWoody MVP

        Except everyone would go on as normal and never patch.

        Susan Bradley Patch Lady

        • #191520 Reply

          MrJimPhelps
          AskWoody MVP

          I think this would encourage people to patch, because people would have more confidence that patching wouldn’t break their systems.

          My suggested improvement wouldn’t kick in unless you were trying to remote into an unpatched system. Instead of the process failing with an unintelligible geek error message, the person trying to remote into an unpatched system would be given the opportunity to proceed — either unprotected or fix the problem — or cancel. Wouldn’t that be better than the current unintelligible situation?

          In my opinion, adding improvements like this would engender confidence rather than stress when it is time to patch.

          Group "L" (Linux Mint)
          with Windows 8.1 running in a VM
          2 users thanked author for this post.
          • #191566 Reply

            RangerVic
            AskWoody Lounger

            MrPhelps,
            My exact thoughts on both your points.
            The machines that are exposed to the Internet are patched.
            The ones behind my firewall are configured to only accept RDP connections from specific sources. Those machines are slow to patch because I lost a lot of confidence in Microsoft this first quarter with the Windows 10 problem patches which hit me hard.
            Thanks,
            Victor

            • This reply was modified 7 months, 1 week ago by  RangerVic. Reason: Post had HTML in it that I did not add
        • #191555 Reply

          Elly
          AskWoody MVP

          There was a time (pre- KB KB2952664) that I was an avid advocate of patching. I made sure that all my family and friends were updating, or using auto updating. First came unwanted telemetry… then forced GWX… and this year has been a complete patching disaster. No one has mal-ware filled computers… but Microsoft has moved itself from trusted to actively adopting mal-ware as an OS. Microsoft is making it important to avoid patching and OS and feature updates in order to have a stable OS… when allowed to run unimpeded through auto-updating, over two dozen low budget computers were rendered unusable (not all at once, but bit by bit)… since then those computers have been restored to usability… and patching is strictly controlled, and not at all how Microsoft recommends… and every single one continues to function well, because it isn’t receiving patches. Microsoft is their own worst enemy when it comes to patching!

          @The Patch Lady- I highly value your knowledge and advice… but take what you share and apply it carefully. But I must respectfully disagree with anyone that recommends following Microsoft’s mandates and changes, because they aren’t in the best interests of us, the Home personal computer users.

          Win 7 Home, 64 bit, Group B

          2 users thanked author for this post.
      • #191562 Reply

        anonymous

        The vulnerability occurs because the client let’s an attacker do something they shouldn’t do before the client has an opportunity to know the server its talking to. This means the client doesn’t know if it’s a patched or unpatched server before it’s too late. So to just prompt and ask if they want to connect to an unpatched server is impossible without revealing the keys to kingdom.

        Additionally, presenting this sort of warning and prompt-to-continue to users is a bit silly because the majority of people will ignore it and do whatever they need to do to connect regardless of the security impact.

        And I can tell you, even if it was possible at the protocol level, it’s not trivial making such a change. This involves the RDP client, RDP server, CredSSP protocol, PowerShell, Group Policy, and a number of internal bits to coordinate an annoying UI prompt that weakens the user’s security. And then patch it to every currently supported version of Windows.

        3 users thanked author for this post.
    • #191464 Reply

      ComTruise
      AskWoody Lounger

      & THIS is why consumers are losing faith in Windows (already too late for Microsoft). Not the last straw to send me to Mac or Linux… yet. Somebody’s not paying attention when a bug like this goes out to ALL flavors of Windows… even RT!

      Not sure i would call MS out on this.. we all knew it was coming.

    • #191479 Reply

      anonymous

      resuelto!!!! solo actualice mi server y listo…

    • #191499 Reply

      Coises
      AskWoody Lounger

      Am I correct in guessing that a machine running 32-bit Windows XP Pro will fail the new requirements, and that there is not and never will be any way to patch it?

      Security for data on the XP machine is not a concern; what is a concern is the cost of replacing it with new hardware and software when it serves our needs perfectly well now… assuming something like this doesn’t break it.

      That all-caps “TEMPORARILY” makes me nervous. Is the implication that the registry change will one day cease to work, and it will be impossible to connect to an XP machine from an up-to-date Windows 7 (or later) machine?

      • #191530 Reply

        columbia2011
        AskWoody Lounger

        Then the solution is only to set on up-to date machine policy (registry) setting “Vulnerable”.

    • #191638 Reply

      anonymous

      I’ve seen a few mentions here of a temporary registry fix but cant see what the fix actually is.
      I know i have remote machines that need some recent updates to be run but we tend to do these during main school holidays. Meanwhile I need to be able to connect to my remote VMs. Some of which i can only connect to through RDS/Cluster Manager console which is currently not working.
      Would someone please point me to specific instructions for the [temporary] reg fix.

      Cheers

      • #191739 Reply

        anonymous

        “I’ve seen a few mentions here of a temporary registry fix but cant see what the fix actually is.
        I know i have remote machines that need some recent updates to be run but we tend to do these during main school holidays. Meanwhile I need to be able to connect to my remote VMs. Some of which i can only connect to through RDS/Cluster Manager console which is currently not working.
        Would someone please point me to specific instructions for the [temporary] reg fix.

        Cheers”

        Regfix:

        -Open Regedit (press windows key + R simultaniously, type “regedit” and press enter)
        -navigate to HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters and doubleclick on value “AllowEncryptionOracle”
        -adjust  to “2” and close regedit
        -No reboot required
        -Make sure to revert to original value after you have patched all servers.

        It seems that this registry key is missing on Windows 10 systems though. GPEdit is the method we have therefore used on Windows 10 Pro:

        -GPedit (press windows key + R simultaniously, type “gpedit.msc” and press enter)
        -Navigate to Computer Configuration->Administrative Templates->System->Credentials Delegation and open the object “Encryption Oracle Remediation”
        -Change it to Enabled and in Protection level, change back to Vulnerable. Close GPedit.
        -Reboot the system.
        -Make sure to revert to original value after you have patched all servers.

        • #192058 Reply

          anonymous

          Using GPEdit I could connect my Win 10 Pro to the server of my work that has Win Server 2016. Thanks to who offered that option to solve the problem.

          Moderator’s Note: translation from Spanish, per Google

          • #192694 Reply

            MXMasterNL
            AskWoody Lounger

            de nada..I mean “you’re welcome” 😉

    • #191688 Reply

      anonymous

      We are are experiencing this problem also from W10 Pro 180410-1804 and kb4103721 installed RDP-ing into Server 2012 and 2012 R2 servers patched with KB4093123 (April monthly Rollup)

      We patch all our own and our clients servers monthly during the week-end after patch tuesday , therefore waiting only a few days.

      Therfore this problem doesn’t only affect servers that haven’t been updated for months.

      • #191766 Reply

        mcbsys
        AskWoody Lounger

        Are the clients also patched? Does the Interoperability Matrix in KB4093942 shed any light on which combination of servers, clients, and settings are giving you the Blocked behavior?

        • #191944 Reply

          anonymous

          “Are the clients also patched? Does the Interoperability Matrix in KB4093942 shed any light on which combination of servers, clients, and settings are giving you the Blocked behavior?”

          The answer to your first question  is already in my text: “W10 Pro 180410-1804 and kb4103721” So yes, these clients are “patched”.

          To answer your second question: No it doesn’t. As these servers have KB4093123 (April monthly Rollup) installed according to the information provided in KB4093942 the problem shouldn’t occur since the CredSSP update for CVE-2018-0886 was already included in KB4088877 (March monthly Rollup) which the affected servers have installed.

          Edit to remove HTML. Please use the “Test” tab in the entry box when you copy/paste.

          • #191995 Reply

            mcbsys
            AskWoody Lounger

            anonymous, I’d be curious whether the registry entry described in the KB article exists on servers and/or clients and if so, what is its value? But really I’m out of ideas. Please post back on your progress and solution to benefit the community.

            • #192687 Reply

              MXMasterNL
              AskWoody Lounger

              anonymous, I’d be curious whether the registry entry described in the KB article exists on servers and/or clients and if so, what is its value? But really I’m out of ideas. Please post back on your progress and solution to benefit the community.

              I decided to create an account, that should clear some of the confusion as a multitude of messages in this post are of my writing 😉

              Registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters

              W10 Pro Patched with May Rollup: Not present
              W10 Pro Patched with May Rollup: Haven’t been able to tell as all our workstations and the workstation at our clients already have the rollup installed . If I do encounter one I will post back here or, if I find the time, I will revert the update on one to check if the key is present.
              Server 2012 Standard without May Rollup: Not present
              Server 2012 Standard with May Rollup: Not present

              2 users thanked author for this post.
            • #192704 Reply

              mcbsys
              AskWoody Lounger

              Thanks for creating an account.

              AFAIK, the registry entry will never be created by applying a patch. It’s only created manually or by group policy for overriding default behavior.

              Since you were reporting that RDP does not work between patched machines, i.e. the default behavior is not working properly, I was just checking whether somehow the registry entries had been created and were interfering. Apparently not.

              What message do you get when you try an RDP connection? Does it specifically refer to CredSSP? In my domain, for example, RDP fails when Network Level Authentication (NLA)  is enabled but the server does not properly detect that it is on a domain (instead the network shows as Public or Private). This is a  network location awareness issue not directly related to CredSSP.

    • #191699 Reply

      anonymous

      Registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters as described in kb4093492 is not present on our diverse W10 Pro 180410-1804 desktops.

      Setting Encryption Oracle Remediation in GPO Computer Configuration -> Administrative Templates -> System -> Credentials Delegation to value 3 (vulnerable) on the desktops and rebooting did the trick though. Will revert this to default after we have patched all servers.

      Edit to remove HTML. Please use the “Text” tab in the entry box when you copy/paste.

    • #191736 Reply

      anonymous

      Do you know if unpatched client/workstions will be able to connect patched RDS servers?

       

    • #191759 Reply

      mcbsys
      AskWoody Lounger

      Do you know if unpatched client/workstions will be able to connect patched RDS servers?

      I think yes. See the Interoperability Matrix in KB4093942, Unpatched client to Mitigated server shows “Allowed.”

    • #191880 Reply

      anonymous

      Windows server 2012 are updated and windows 10 are updated, but still not working…

    • #192394 Reply

      anonymous

      This is laughable approach, Microsoft keeps getting worse and worse. Gradually they have been removing user control over their OS for the last years and enforcing such c***. Why not to release the client update with override switch or just warning that keeps on nagging but at least lets the person work and then sort out the patching at their convenience? And why this is so important anyways? Nobody uses RDP open to public because nobody trusts RDP anyway, it is always behind a VPN or is ran over additional layer like SSL. So why disrupt the workflow like incredibly insecure RDP security would somehow matter? Keep driving nails in your coffin, Microsoft.

      1 user thanked author for this post.
    • #192497 Reply

      anonymous

      Question:  Isn’t CredSSP used when NLA is enabled in the Remote Desktop Settings?  Couldn’t one just untick NLA in the Remote Desktop Settings on the server?

      Our organization opted out of using NLA because of various issues we were experiencing.  We have fully patched workstations RDP’ing to not-so-up-to-date servers.  Because we don’t use NLA, we haven’t seen this issue.

      Just a thought…

      • #192572 Reply

        anonymous

        Confirmed.  Disabling NLA in Remote Desktop Settings resolves this.

        For those that need to set this on a global level, the GPO for this is:

        Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security

        Disable “Require user authentication for remote connections by using Network Level Authentication”

        1 user thanked author for this post.
      • #192692 Reply

        MXMasterNL
        AskWoody Lounger

        I can confirm this too. Disabling NLA on the unpatched host will allow patched workstations to connect. Tested with both Server 2008 R2 and Server 2012 hosts and Windows 10 Pro clients. Of course you do need to have physical access to the host in question or an unpatched client or a patched client with GPO Computer Configuration -> Administrative Templates -> System -> Credentials Delegation enabled and set to the setting “vulnerable” as mentioned by me elsewhere in this post to be able to adjust this setting.

    • #192712 Reply

      MXMasterNL
      AskWoody Lounger

      Thanks for creating an account.

      AFAIK, the registry entry will never be created by applying a patch. It’s only created manually or by group policy for overriding default behavior.

      Since you were reporting that RDP does not work between patched machines, i.e. the default behavior is not working properly, I was just checking whether somehow the registry entries had been created and were interfering. Apparently not.

      What message do you get when you try an RDP connection? Does it specifically refer to CredSSP? In my domain, for example, RDP fails when Network Level Authentication (NLA) is enabled but the server does not properly detect that it is on a domain (instead the network shows as Public or Private). This is a network location awareness issue not directly related to CredSSP.

      We received the exact message as in the picture, both RDP-ing into domain machines and/or non domain/workgroup machines (For instance, our Hyper-V hypervisors generally are workgroup members.)

      Disabling NLA though via RDP settings on a Server 2012 non domain machine patched to april rollup level gave instant RDP access from may rollup patched windows 10 clients though, as did disabling NLA on Server 2012 domain member servers patched to april rollup patch level.

      CVE-2018-0886-1

      Edit to insert attachment

      • This reply was modified 7 months ago by  MXMasterNL.
      • This reply was modified 7 months ago by  PKCano.
      • This reply was modified 7 months ago by  PKCano.
      Attachments:
      You must be logged in to view attached files.
      1 user thanked author for this post.
    • #196013 Reply

      anonymous

      which update needs to be installed on server side to fix this problem ?

      only KB4103715 for Windows 2012 R2 ?

    • #197385 Reply

      anonymous

      would someone please roll discussion this up and post the patch KB with a link for what needs to be installed on both the server and client side to properly fix this?

      • #197571 Reply

        MXMasterNL

        would someone please roll discussion this up and post the patch KB with a link for what needs to be installed on both the server and client side to properly fix this?

        Please elaborate what you mean by: maybe it is because I am a non-native speaker of English, but I don’t exactly understand what you mean by this.

        I do realize you seem to be interested in what KBs need to be installed on both client- and server side.

        As for the client side:
        Nothing (Installing the May Rollup on the client side is the reason one can’t RDP into servers lacking certain updates after all.)

        As for the server side:
        Windows 7 Service Pack 1, Windows Server 2008 R2 Service Pack 1: KB4103718
        Windows Server 2012: KB4103730
        Windows 8.1, Windows Server 2012 R2: KB4103725
        Windows 10 version 1709: KB4103727
        Windows 10 version 1803: KB4103721

        These links to KBs represent the May Update Rollups for most current Windows versions. While it is in theory possible to only patch up to April Rollup level on the server side (The RDP protocol should be fixed in the April 18 Rollup on the server side) it is adviseable to patch to May Rollup level unless there are strong reasons not to do so.

        Why is this adviseable? Well, apart from the obvious (There will be eternal debate about this subject but most good administrators feel that the risk of experiencing problems because of bugs as a consequence of patching their machines is outweighed by the benefit of not patching said machines.) some users (myself included) have reported also experiencing this exact problem RDP-ing into servers with the April Rollup installed on the server side.

        EDIT html to text (formatting used was not BBCode)

    • #197573 Reply

      MXMasterNL
      AskWoody Lounger

      which update needs to be installed on server side to fix this problem ?

      only KB4103715 for Windows 2012 R2 ?

      Correct, but it might be adviseable to install KB4103725, the may rollup for Server 2012 R2 which also contains KB4103715.

    • #219056 Reply

      anonymous

      open cmd &Run as administrator : solution : C:\Users\velukris> reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 1

      Edit to remove HTMH. Please use the “Text” tab in the entry box when you copy/paste.

    Please follow the -Lounge Rules- no personal attacks, no swearing, and politics/religion are relegated to the Rants forum.

    Reply To: Problems with CredSSP updates CVE-2018-0886 breaking RDP connections

    You can use BBCodes to format your content.
    Your account can't use Advanced BBCodes, they will be stripped before saving.

    Your information: