Working at a client site the other day, I discovered that remote desktop connectivity from a set of Windows 2008 R2 servers to several Windows 7 virtual systems had abruptly stopped working. The error produced upon attempting to log in was simple: “The user name or password is incorrect.”

Except I was positive this wasn’t true. Googling the issue turned up a plethora of red herrings and dead ends which provided no insight into the problem. So, I had to roll up my sleeves and get out my system administrator’s detective toolkit, so to speak.

Triangulating the problem

The first and most obvious assumption was that the password was somehow changed by someone, but this seemed highly unlikely as the password in question had existed for several years and was shared by many people. However, stranger things have happened.

I ruled this possibility out right away by logging into these virtual machines directly via the VMWare console. The ID and password worked just fine, so I knew something had to be wrong with the remote desktop communication itself.

My next step was to try to connect to these machines from a different system; another Windows 7 machine on the network to which I could log in via remote desktop from this server. That worked fine, so I knew the problem had to be with the source servers themselves from which I was trying to access the problem Windows 7 systems.

Fortunately there were four servers involved so I systematically tested remote desktop connectivity from all of them – and found that this access worked on one out of the four.

Aha! I then sought to determine what was different about that one working system and what changed on the three non-working servers.

SEE: Working in IT: Why we love it, why we hate it (free PDF) (TechRepublic)

Determining what changed

The first thing I checked was recent Windows updates on the problem servers. I saw that several updates had been installed just a few days prior:

The working server had NOT received the May updates listed above so that was a very strong suggestion in my mind that one of these updates broke remote desktop connectivity.

I then made a list of the recently installed updates and researched their purpose:

Update Title Description
Update for Microsoft .NET Framework 4.7.1 (KB4096418) .NET update
Security Update for Microsoft .NET Framework 4.7.1 (KB4096237) .NET update
Security Update for Microsoft Windows (KB4103718) Monthly patch rollup
Security Update for Microsoft Windows (KB4103768) Cumulative IE Update
Security Update for Microsoft Windows (KB4103712) Addresses an issue that may cause an error when connecting to a Remote Desktop server
Update for Microsoft Windows (KB4095874) Security and Quality Rollup for .NET Framework 3.5.1
Security Update for Microsoft Windows (KB4095514) Security Only update for .NET Framework 3.5.1 for Windows 7 SP1 and Server 2008 R2 SP1
Update for Microsoft Windows (KB4099950) Fixes network settings and IP address issues
Update for Microsoft Windows (KB4093753) Time zone and DST changes in Windows for Brazil, Morocco, and São Tomé and Príncipe

Isolating the fix step-by-step

While I could have just uninstalled all the updates to see if the problem was resolved, I wanted to take the extra time to try to figure out which one specifically caused the issue, otherwise the problem would just likely return at the next round of patching. I opted to uninstall the updates one-by-one then reboot and test the remote desktop connection each time.

But how to proceed? After reviewing the list above it was clear some of these updates had nothing to do with the problem – the .NET and time zone patches weren’t worthy of my interest. I felt the likely source of the problem was KB4103712, since it specifically referenced a remote desktop connectivity issue. Ironically, it was intended to fix problems, not cause them, but the topsy-turvy world of patching can often lead to reverse outcomes.

I uninstalled KB4103712, rebooted the server, then attempted a remote desktop connection and it worked!

SEE: How to manage IT during mergers and acquisitions (free PDF) (TechRepublic)

Applying a long-term fix

The job wasn’t finished yet; just the opposite. Now that I knew which update produced the issue I had to figure out how to apply it and retain remote desktop connectivity to these Windows 7 systems.

I spoke to a friend of mine, Mike Catalano, Senior Technology Engineer at Worldpay, who provided more information on what happened here. He pointed me to a Microsoft support article which explains that this issue involves a March update to the Credential Security Support Provider Protocol (CredSSP) which handles authentication requests. Another symptom of this problem is the error: “An authentication error has occurred. The function requested is not supported.”

Specifically, connectivity problems occur when a patched client attempts to connect to an unpatched system which was exactly the case here. The connection worked from an unpatched client connecting to the unpatched systems, so it’s clear the remote desktop patch KB4103712 needed to be present on both systems. The short-term fix on a per-server basis is to apply this registry setting:

Registry path: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters

Value: AllowEncryptionOracle (DWORD): 2

The Microsoft support article referenced above explains the full settings available and states that a setting of “2” represents the “vulnerable” policy setting whereby insecure connectivity is permitted:

This article explains how to achieve the same result in Group Policy.

It’s important to keep in mind this setting is considered a bad idea since it bypasses a security control. Apply this setting as a short-term solution, but ensure all systems involved receive all available updates (obviously the next thing I did was to determine why the target systems weren’t patched as of late and remediate that) and undo this setting – or change the value to “0” to “Force updated clients” after the next patching round then check remote desktop functionality. Hopefully all should be working as expected at that point.

Also see: