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.'
- Remote Desktop Gateway Server 2019
- Remote Desktop Gateway Pre-authentication Servers List
- Securing Rd Gateway With Web Application Proxy
More about Windows
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: HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters
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.
Microsoft Weekly Newsletter
Be your company's Microsoft insider with the help of these Windows and Office tutorials and our experts' analyses of Microsoft's enterprise products. Delivered Mondays and Wednesdays
Sign up today Sign up today Also see:
- How to resolve network problems caused by the Windows 10 April 2018 update (TechRepublic)
- Windows 10 users should wait to install the latest update-it's bricking some PCs (TechRepublic)
- Windows 10 April 2018 Update could break a ton of critical features on your PC (TechRepublic)
- Hundreds of IoT smart locks bricked by bad update, leaving customers stranded (TechRepublic)
- New Windows Server 2019 test build adds more clustering features (ZDNet)
- Windows Server 2019 LTSC Build 17623, First Take: Key scenarios await detail (ZDNet)
I had exactly the same error message however it was working the day I setup but next day it just died. However, my setup wasn't as like your external and internal - mine is purely internal.
I tried everything deleting certificate from IIS, RDP server, and client. Re-creating and assigning but none worked.
one thing I remembered as I was going thru the whole suite of RDP components: RDP Manager, RDP Session Host, RDP Remote App etc etc..
Remote Desktop Gateway Server 2019
I found: RemoteApp Manager > RD Host Session Server Setting (click Change) > RD Gateway tab and ticked Automatically detect RD Gateway Server Settings. Then I restarted the Remote Desktop Gateway service and what do you know..DAMN THING ACTUALLY WORKED!!!
Wooohoooo..
So you might want to check in your environment this might help..
Cheers,
IT
Hello,
After update my Windows 10 to creators update (1703), it's not possible to connect a server in RDP with Remote Desktop Gateway (RDG).
Before we used Windows 10 1607 and all works good.
Apparently, in this new version, Windows 10 force to use Kerberos authentification to authenticate in RDG.
But RDG doesn't support Kerberos auth, only NTLM.
It's possible to enable NTLM auth with RDG ?
Apparently, it's a change appear in the new version of Windows 10 (1703) with functionnality 'Remote Credential Guard'
So it's support only Kerberos Auth and doesn't support Remote Desktop Gateway.
https://technet.microsoft.com/en-us/itpro/windows/keep-secure/remote-credential-guard
'Remote Desktop Gateway is not compatible with Remote Credential Guard.'
But apparently, with RDP client and when I try to connect to the Remote Desktop Gateway, it's not the process mstsc it's connect to RDG but it's LSASS with try to Kerberos authentification.
So it's support only Kerberos Auth and doesn't support Remote Desktop Gateway.
https://technet.microsoft.com/en-us/itpro/windows/keep-secure/remote-credential-guard
'Remote Desktop Gateway is not compatible with Remote Credential Guard.'
But apparently, with RDP client and when I try to connect to the Remote Desktop Gateway, it's not the process mstsc it's connect to RDG but it's LSASS with try to Kerberos authentification.
Like it's explain in this article :
Remote Desktop Gateway Pre-authentication Servers List
http://www.thewindowsclub.com/credential-guard-windows-10
Securing Rd Gateway With Web Application Proxy
For example, this is a connexion from Windows 8.1 :
RDG_OUT_DATA /remoteDesktopGateway/
HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
User-Agent: MS-RDGateway/1.0
RDG-Connection-Id: {B96140B7-3D9A-4DC0-88BC-7B40C49C1A4D}
RDG-Correlation-Id: {0CC5ACC4-323D-4D50-9A9C-D0FFD9430000}
RDG-User-Id: xxxxxxxxxxxxxxxxxxxx
Host: rdg.mondomaine.fr
Authorization: NTLM xxxxxxxxxxxxxxxxxxxxxxxxxxx
clientless-mode: 1
X-F5-Client: rdg-http
This is a connexion from Windows 10 creators update (1703) :
First connect to KDC Proxy :
And after to RDG but with auth scheme Negotiate and not NTLM :
RDG_OUT_DATA /remoteDesktopGateway/
HTTP/1.1
Cache-Control: no-cache
Connection: Upgrade
Pragma: no-cache
Upgrade: websocket
Accept: */*
User-Agent: MS-RDGateway/1.0
RDG-Connection-Id: {2FE597B6-00AE-42BC-A47D-A67BE884237D}
RDG-Correlation-Id: {1F76CE0F-C75D-462E-9F15-FFA5951F0000}
RDG-User-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxx
RDG-Client-Generation: Win32#6.2=5
Sec-WebSocket-Key: 6ekVx9V3iMEKWPlNVsbZ5g
Sec-WebSocket-Version: 13
Host: rdg.mondomaine.fr
Authorization: Negotiate xxxxxxxxxxxxxxxxxxxxxxxxxxx
clientless-mode: 1
X-F5-Client: rdg-http
RDG_OUT_DATA /remoteDesktopGateway/
HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
User-Agent: MS-RDGateway/1.0
RDG-Connection-Id: {B96140B7-3D9A-4DC0-88BC-7B40C49C1A4D}
RDG-Correlation-Id: {0CC5ACC4-323D-4D50-9A9C-D0FFD9430000}
RDG-User-Id: xxxxxxxxxxxxxxxxxxxx
Host: rdg.mondomaine.fr
Authorization: NTLM xxxxxxxxxxxxxxxxxxxxxxxxxxx
clientless-mode: 1
X-F5-Client: rdg-http
This is a connexion from Windows 10 creators update (1703) :
First connect to KDC Proxy :
And after to RDG but with auth scheme Negotiate and not NTLM :
RDG_OUT_DATA /remoteDesktopGateway/
HTTP/1.1
Cache-Control: no-cache
Connection: Upgrade
Pragma: no-cache
Upgrade: websocket
Accept: */*
User-Agent: MS-RDGateway/1.0
RDG-Connection-Id: {2FE597B6-00AE-42BC-A47D-A67BE884237D}
RDG-Correlation-Id: {1F76CE0F-C75D-462E-9F15-FFA5951F0000}
RDG-User-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxx
RDG-Client-Generation: Win32#6.2=5
Sec-WebSocket-Key: 6ekVx9V3iMEKWPlNVsbZ5g
Sec-WebSocket-Version: 13
Host: rdg.mondomaine.fr
Authorization: Negotiate xxxxxxxxxxxxxxxxxxxxxxxxxxx
clientless-mode: 1
X-F5-Client: rdg-http
Best regards