[German]I have received reports of problems with remote desktop connections under Windows when they are made via FQDN (Fully Qualified Domain Name). The connections can then no longer be established. The problem has been occurring since October 2022 and a connection to the difficulties in connection with Remote Desktop problems seems to be given.
Advertising
Issues with Remote Desktop connections
According to my observations, there have been problems with Remote Desktop connections under various Windows versions for months. I had already reported about the problem in October 2022 in the blog post Windows 11 22H2: Microsoft investigates RDP issues. Then, as of November 22, 2022, Microsoft has confirmed that there may be connection issues with Remote Desktop connections in Windows 11 version 22H2. Details can be found in the blog post Windows 11 22H2: Connection issues with remote desktop confirmed.
Issues with FQDN Remote Desktop connections
To my German blog post Windows 11 22H2: Probleme mit Remote Desktop-Verbindungen bestätigt Nicki got in touch and reported problems with Remote Desktop Connections on FQDN (Fully Qualified Domain Name). In this comment the problem is described like this (I've translated the comment):
Hi Günter,
since the October updates we have the problem that more and more users cannot connect via FQDN. The password is rejected. A connection via the IP address works fine.
Have you heard about this? It goes here only in the PC-PC connections without gateway or broker.
I myself have not had any user reports and have not yet read anything in this regard, but blog reader Christian Braun confirms the problem in this comment (translated):
Same problem already had with 2 customers today. The connection was refused via FQDN. In the event log of the terminal server it was logged that the access data is not correct. IP address directly entered in the RDP connection solved the problem.
In the comment there is already a hint to a workaround: Instead of using a Fully Qualified Domain Name (FQDN) as connection target, Christian directly entered the IP address and the RDP connection works again.
October 11, 2022 updates to blame?
Nicki then linked in a follow-up comment to a post in the PatchDay MegaThread where the October 2022 updates for Windows 10 (KB5018410) and Windows 11 (KB5018418) could be to blame for the connectivity issues. It says there:
Advertising
Security Update KB5018410 (Windows 10) and KB5018418 (Windows 11) break RDP SSO Delegated Credentials.
We use the RDP desktop shortcut with single sign-on to allow logged-in users to simply log in to the remote server without entering the password again. It worked like a charm for years.
I've been scratching my head all morning and found that some users are greeted with a "The user name or password is incorrect. Try Again." as soon as the remote session window opens. Followed by weird logs in the event viewer.
Apparently, it's been happening since last week, but not many users complained. When we investigated this issue today, we found several other users have the same issue, and they all had KB5018410 installed, and those that didn't have this issue didn't have the update installed. We uninstalled this update from the affected machines, and everything started working again!
We do use RDS Farm(s) running WS 2022 with UPD (User Profile Disks).
We tried the following, but the issue is not fixed, unless we remove the update.
- disabled UDP
- replaced mstsc.exe and .dll
I can't seem to find any specific info about this and how to avoid this from happening again when future updates are installed…
There, too, connection problems are confirmed and someone writes that he had to replace his FQDN connection target with the IP address. There is evidence there that it only occurred with users if they had saved the credentials for the RDP connection. There is a suggestion for this scenario to edit the content of the .RDP file and make sure that the line:
use redirection server name:i:1
has the parameter 1 (instead of 0). However, I am unsure if this would do any good in the above case. Nikki writes that the above updates are not installed yet. But possibly the bug has been creeping in for a while – after all, the October 2022 updates were supposed to better secure TLS/SSL and have resulted in collateral damage (see the following articles). Anyone who has these problems – and maybe knows a solution (aside from using an IP address as destination)?
Addendum: Got now several confirmation from German blog readers. Another feedback from a German Facebook Windows Server group (here is the translated text): "The problem only affects RDP connections. Just received a call from a colleague – Hyper-V management tools do not work via FQDN, but via IP input". In an addendum, this administrator wrote:
First I checked the defaults, domain trust and network profile. Everything was perfect. Then I tried to connect via IP and everything worked. The error message was:
Error during operation on computer xxxxxx unknown security error….
Event log then showed a Kerberos error.
I reported it to Microsoft via Twitter. On reddit.com someone worte:
I have spoken with Microsoft Enterprise Support. Microsoft confirmed to me that there is an issue still existing with the OOB patch and they plan to make an announcement in the coming days.
Similar articles
Patchday: Windows 10-Updates (October 11, 2022)
Patchday: Windows 11/Server 2022-Updates (October 11, 2022
RDS issues after Windows update KB5015808
Windows Server 2016: Fix for RDP issues in KB5015808 and later
Windows 11 22H2: Microsoft investigates RDP issues
Windows 10 (20H2-22H2): October Update KB5018410 causes OneDrive crashes/issues
Issues with OneDrive for Business Sync Client caused by update KB5018410 (Oct. 22, 2022)
Citrix connections broken after Windows update KB5018410 (October 2022) (TLS problem)
DirectAccess fails after Windows Updates from November 2022
SSL/TLS connection issue fix: out-of-band update status and affected applications (Oct. 21, 2022)
Out-of-band updates for Windows fixes SSL-/TLS connection issues (also with Citrix) – October 17, 2022
We opened a case with Microsoft Premier support but battling to get through 1st line, we're on day 3 of an opened case were we're still receiving feedback such as 'please clear your DNS resolver cache'.
What is interesting, is that we reviewed a packet capture from a Windows 11 22H2 domain joined workstation attempting to establish a RDP host-to-host connection to either Windows Server 2019 or Windows Server 2022 systems where the target systems are *not* joined to a domain (aka stand alone workgroup).
We did this to demonstrate that DNS resolution is in fact working and that RDP transmits packets towards the wanted destination when we run 'mstsc /admin /v FQDN' instead of 'mstsc /admin /v IP'.
When connecting to FQDN packets to start to flow but only about 4 packets leave the workstation and Wireshark does not detail 'TLS 1.2' anywhere and the packet lengths are at most 73 bytes big (definitely no TLS certificate exchanges going on anywhere).
PS: It's almost as if the client is refusing to start TLS but this can't be based on the TLS presented by the server as the client doesn't send an initiation of this.
PPS: We're running Windows 11 22H2 fully patched (December CU) together with Windows Server 2019 or 2022, also fully patched with December CUs. We have hardening in effect in the domain and were effected by the November Kerberos snafu…
Regards
David Herselman
I believe this to be bug in that mstsc doesn't fall back to NTLM authentication when Kerberos authentication fails. This is when the following GPO is set:
Computer Configuration \ Policies \ Administrative Templates \ System \ Kerberos
Fail authentication requests when Kerberos armoring is not available
With this disabled RDP falls back from non-armoured Kerberos towards the non-domain joined destination hosts and allows NTLM fallback.
We have the same issue since about Oct 2022 in our network consisting of a 2008R2 PDC and a 2008R2 BDC and two additional domain controllers (Server 2019 and 2022). The two 2008R2 servers shall be phased out in a couple of months. Various users can't RDT into a Windows 2019 Terminal server from their Windows 10 PC and also into the 2008R2 PDC. A workaround is to use the IP address instead of either the FQDN or server name w/o domain part. Before we found the workaround, we advised users to reboot, which sometimes helped. Recently, we found another solution which involves adding "enablecredsspsupport:i:0" to Default.rdp in the user's Documents folder. However, this requires "Network Level Authentication" to be disabled in Control Panel – Remote Desktop settings on the server. We introduced the 2019 and 2022 servers some time in Oct, so we are not sure if the problems are related to the Oct 2022 KB5018410 cumulative update. We're advising our users to use the server IP address.
Hi Klaas-Pieter,
We have a similar environment (2008R2 PDC) and experiencing the same problems occasionally. Did phasing your 2008R2 system out resolve this? We're about to do the same, but would be good to know if it is the cause.
Also, we found that logging on with the UPN (user@domain.com) worked with the FQDN, whereas using the pre-2000 name (domain\user) did not. Changing to IP both, both username formats work. Very strange.
Thanks.
Hi Joe,
I'm finding myself in a similar situation (mostly 2016, but with a SBS 2011 system (which is 2008r2 based) still kicking around) and I was wondering if decomissioning your 2008r2 system resolved the issue for you.
We changed the alternate full adresse that work in our inviroment.
Set-RDSessionCollectionConfiguration -CollectionName -CustomRdpProperty "use redirection server name:i:1 `n alternate full address:S:"