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

Topic

New Reply

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.

Elly, zeuswoz, GeekDiver, WildBill

Reply | Quote

Replies

& 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!

Bought a refurbished Windows 10 64-bit, currently updated to 22H2. Have broke the AC adapter cord going to the 8.1 machine, but before that, coaxed it into charging. Need to buy new adapter if wish to continue using it.
Wild Bill Rides Again...

2 users thanked author for this post.

GoneToPlaid, GeekDiver

Reply | Quote

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.

MXMasterNL, b, woody, abbodi86, AlexEiffel, justasysadamin, Microfix

Reply | Quote

https://www.askwoody.com/forums/topic/kb4103727-rdp-issues/

1 user thanked author for this post.

mcbsys

Reply | Quote

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.

Reply | Quote

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.

Reply | Quote

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.

Reply | Quote

Wish I had suggestions other than opening a support case.

Reply | Quote

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…

Reply | Quote

“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?

Reply | Quote

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.

columbia2011

Reply | Quote

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.

mcbsys

Reply | Quote

RDP = Remote Desktop Protocol. Are you remoting into other computers?

1 user thanked author for this post.

DrBonzo

Reply | Quote

Short answer is that consumers can probably ignore it unless you need to connect to unpatched servers. The patch was included in a slew of updates in March:  see the CVE article to locate your OS and the corresponding patch number:

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886

2 users thanked author for this post.

SueW, DrBonzo

Reply | Quote

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

Reply | Quote

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/Prudent patcher

5 users thanked author for this post.

SueW, dononline, Bill C., DrBonzo, woody

Reply | Quote

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

Reply | Quote

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.

 

Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

Reply | Quote

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/Prudent patcher

Reply | Quote

Thank you, Patch Lady.

Your answer clears things up for me.

 

Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

Reply | Quote

mcbsys wrote:

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.

Reply | Quote

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.

 

Reply | Quote

…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.

GeekDiver

Reply | Quote

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.

Reply | Quote

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.

Reply | Quote

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.

woody

Reply | Quote

They did gave 2 months notice about the change

1 user thanked author for this post.

woody

Reply | Quote

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/Prudent patcher

4 users thanked author for this post.

Jan K., GeekDiver, woody, columbia2011

Reply | Quote

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. https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018 …

Susan Bradley Patch Lady/Prudent patcher

4 users thanked author for this post.

Jan K., GeekDiver, abbodi86, woody

Reply | Quote

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

Reply | Quote

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

Reply | Quote

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

Reply | Quote

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

 

regards

Joseph

Reply | Quote

anonymous wrote:

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.

Reply | Quote

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/Prudent patcher

Reply | Quote

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*

Reply | Quote

What’s a rebooting bug on your Win2008R2 servers? After which month update rollup did it happen?

Reply | Quote

There was quite a bit of chatter regarding 2K8R2 having reboot issues and phantom NIC’s.

https://www.computerworld.com/article/3268607/microsoft-windows/patch-tuesday-brings-some-surprises-some-early-crashes-and-a-surreal-solution.html
The old Win7/Server 2008R2 SMB server memory leak is still there — that’s a showstopper for many folks running 2008R2 servers.

1 user thanked author for this post.

columbia2011

Reply | Quote

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.

Reply | Quote

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.

Reply | Quote

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/Prudent patcher

Reply | Quote

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.

Reply | Quote

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 10 running in a remote session on my file server

4 users thanked author for this post.

RangerVic, Elly, RetiredGeek, columbia2011

Reply | Quote

Except everyone would go on as normal and never patch.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

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 10 running in a remote session on my file server

2 users thanked author for this post.

RangerVic, Elly

Reply | Quote

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

Reply | Quote

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.

Non-techy Win 10 Pro and Linux Mint experimenter

2 users thanked author for this post.

windows7wasthebest, columbia2011

Reply | Quote

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.

columbia2011, PKCano, woody

Reply | Quote

WildBill wrote:

& 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.

Reply | Quote

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

Reply | Quote

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?

Reply | Quote

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

Reply | Quote

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

Reply | Quote

“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.

Reply | Quote

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

Reply | Quote

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

Reply | Quote

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.

Reply | Quote

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?

Reply | Quote

“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.

Reply | Quote

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.

Reply | Quote

mcbsys wrote:

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.

mcbsys, Elly

Reply | Quote

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.

Reply | Quote

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.

Reply | Quote

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

 

Reply | Quote

Yes, I can confirm that.

Reply | Quote

anonymous wrote:

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.”

Reply | Quote

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

Reply | Quote

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.

columbia2011

Reply | Quote

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…

Reply | Quote

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.

columbia2011

Reply | Quote

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.

Reply | Quote

mcbsys wrote:

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.

Edit to insert attachment

1 user thanked author for this post.

columbia2011

Reply | Quote

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

only KB4103715 for Windows 2012 R2 ?

Reply | Quote

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?

Reply | Quote

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)

Reply | Quote

anonymous wrote:

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.

Reply | Quote

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.

Reply | Quote