[English]Mir liegen inzwischen Berichte über Probleme mit Remote Desktop-Verbindungen unter Windows vor, wenn diese über FQDN (Fully Qualified Domain Name) erfolgen. Die Verbindungen können dann nicht mehr aufgebaut werden. Das Problem tritt seit Oktober 2022 auf und ein Zusammenhang mit den Schwierigkeiten in Verbindung mit Remote Desktop-Problemen scheint gegeben.
Anzeige
Problem mit Remote Desktop-Verbindungen
Meinen Beobachtungen nach gibt es seit Monaten Probleme mit Remote Desktop-Verbindungen unter diversen Windows-Versionen. Ich hatte bereits im Oktober 2022 im Blog-Beitrag Windows 11 22H2: Microsoft untersucht RDP-Probleme über das Problem berichtet. Dann hat Microsoft zum 22. November 2022 bestätigt, dass es zu Verbindungsproblemen mit Remote Desktop-Verbindungen in Windows 11 Version 22H2 kommen kann. Details finden sich im Blog-Beitrag Windows 11 22H2: Probleme mit Remote Desktop-Verbindungen bestätigt.
Problem FQDN Remote Desktop-Verbindungen
Zum Blog-Beitrag Windows 11 22H2: Probleme mit Remote Desktop-Verbindungen bestätigt hat sich dann Nicki gemeldet und berichtet Probleme mit Remote Desktop-Verbindungen auf FQDN (Fully Qualified Domain Name). In diesem Kommentar wird das Problem so beschrieben:
Hi Günter,
wir haben seit den Oktober Updates das Problem, dass sich immer mehr Benutzer nicht mehr über den FQDN verbinden können. Das Passwort wird zurückgewiesen. Eine Verbindung über die IP Adresse geht tadellos.
Hast Du davon auch schon gehört? Es geht hier nur im PC-PC Verbindungen ohne Gateway oder Broker.
Ich selbst hatte noch keine Nutzerberichte und noch nichts diesbezüglich gelesen, aber Blog-Leser Christian Braun bestätigt das Problem in diesem Kommentar:
Selbes Problem schon bei 2 Kunden heute gehabt. Über FQDN wurde die Verbindung abgelehnt. Im Ereignislog des Terminalservers wurde protokolliert das die Zugangsdaten nicht stimmen. IP Adresse direkt eingetragen in der RDP Verbindung löste das Problem.
Im Kommentar gibt es ja bereits einen Hinweis auf einen Workaround: Statt einen Fully Qualified Domain Name (FQDN) als Verbindungsziel zu verwenden, hat Christian direkt die IP-Adresse angegeben und die RDP-Verbindung funktioniert wieder.
Anzeige
Updates vom 11. Oktober 2022 schuld?
Nicki hat dann in einem Folgekommentar auf einen Post im PatchDay MegaThread verlinkt, wo die Oktober 2022-Updates für Windows 10 (KB5018410) und Windows 11 (KB5018418) Schuld an den Verbindungsproblemen sein könnten. Dort heißt es:
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…
Auch dort werden Verbindungsprobleme bestätigt und jemand schreibt, dass er sein FQDN-Verbindungsziel durch die IP-Adresse ersetzen musste. Dort gibt es Hinweise, dass es nur bei Benutzern auftrete, wenn diese die Zugangsdaten (Credentials) für die RDP-Verbindung gespeichert hätte. Es gibt für dieses Szenario einen Vorschlag, den Inhalt der .RDP-Datei zu editieren und sicherzustellen, dass die Zeile:
use redirection server name:i:1
den Parameter 1 (statt 0) aufweist. Ich bin aber unsicher, ob das in obigem Fall etwas nützt. Nikki schreibt, dass die oben genannten Updates bisher nicht installiert seien. Aber möglicherweise hat sich der Bug schon länger eingeschlichen – die Oktober 2022-Updates sollten ja TLS/SSL besser absichern und haben zu Kollateralschäden geführt (siehe folgende Artikel). Irgend jemand, der diese Probleme hat – und vielleicht eine Lösung (abseits der Verwendung einer IP-Adresse als Ziel) kennt?
Ergänzung: Noch eine Rückmeldung aus einere Facebook-Gruppe der Art "Das Problem betrifft nur RDP-Verbindungen. Eben von nem Kollegen eien Anruf erhalten – Hyper-V Management-Tools gehen nicht über FQDN, aber über IP Eingabe". In einem Nachtrag kam dann noch folgende Information.
Erst mal Standard, Domaintrust und Netzwerkprofil gecheckt. Hat alles gepasst, dann über IP versucht und läuft. Meldung war:
Fehler beim Vorgang auf Computer xxxxxx unbekannter Sicherheitsfehler…
Ereignis-log hat dann einen Kerberos Fehler angezeigt.
Ich habe es mal über Twitter an Microsoft gemeldet. Auf reddit.com schreibt jemand:
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.
Bisher habe ich aber noch nichts dazu gesehen.
Ähnliche Artikel:
Patchday: Windows 10-Updates (11. Oktober 2022)
Patchday: Windows 11/Server 2022-Updates (11. Oktober 2022)
Windows 10 (20H2-22H2): Oktober Update KB5018410 lässt OneDrive abstürzen – Korrektur-Update KB5020953 verfügbar
Probleme mit OneDrive for Business Sync Client durch Update KB5018410 (22.10.2022)
Citrix-Verbindungen nach Windows-Update KB5018410 (Oktober 2022) gestört (TLS-Problem)
DirectAccess funktioniert nach November 2022 Windows Updates nicht mehr
Windows Oktober 2022-Patchday: Fix für Domain Join Hardening (CVE-2022-38042) verhindert ggf. Domain-Join
Fix des SSL-/TLS-Verbindungsproblems: Stand der Sonderupdates und betroffene Anwendungen (21.10.2022)
Sonderupdates für Windows fixen SSL-/TLS-Verbindungsproblem (auch bei Citrix) – 17. Oktober 2022
Anzeige
Darunter Ledende sollten auf den DCs das Out of band update einspielen. Jenes beseitigt Probleme mit Kerberos, welches by Fqdn versucht wird. Trat bei uns dann auf, wenn auf den Rechnern nicht alle Verschlüsselungen für Kerberos erlaubt waren, speziell rc4.
Hallo, seit ich von dem RDP-Problem im Zusammenhang mit FQDNs gelesen habe, dachte ich mir "Ach guck mal, vielleicht hat das mit Kerberos zu tun und wenn man die IP adressiert wird vermutlich NTLM benutzt – das passt ja prima zu den ganzen Kerberos-Änderungen in letzter zeit."
Du hast jetzt aber nicht gesagt, dass das RDP-Problem damit weggeht.
Tut es?
(Frage für nen Freund. Ich mache RDP mit SSL, richtigen Zertifikaten, enablecredsspsupport:i:0 und ohne NLA/Gateway.)
Welches Updates für den DC ist es genau? Wir betreiben ein 2016 Server und sind betroffen. Können sie die KB Nr nennen?
https://support.microsoft.com/en-us/topic/november-17-2022-kb5021654-os-build-14393-5502-out-of-band-3bccb4df-bfa1-4c70-9ce3-d5842e3af467
RDP-Zugangsdaten sollte man eh nicht in der Verbindung speichern, sonst erleichtert man einem Angreifer das Lateral Movement.
Und ich gehe bezüglich RDP Authentifizierung noch einen Schritt weiter, nachdem ich die Tage mal wieder ein bischen mit Mimikatz rumgespielt habe, frage ich mich, ob das mit der überall seit Jahren üblichen Network Preauthentication bei RDP die beste Lösung ist, oder ob es nicht doch sicherer ist, sich erst auf dem Loginscreen des Zielsystems anzumelden. Noch bin ich da nicht zu einem abschließenden Ergebnis gekommen, jedenfalls konnte ich mit Mimikatz lokal die Zugangsdaten so einer gerade aktiven RDP-Preauthentication problemlos auslesen. Dagegen hilft nur, den für die Remoteanmeldung benutzten User in die "Protected User" Gruppe aufzunehmen, dann wirds aber für den Benutzer sehr ungemütlich.
Sitze ich da einem Irrtum auf oder kann man >>90% der Angriffsvektoren simpel dadurch ausschalten, dass RDP _ausschliesslich_ über VPN (also von wenigen ausgewählten Adress(bereich)en aus) erreichbar ist?
Halb-halb, wenn ein CS-Beacon einen PC infiziert hat und Daten von Außen über ein anderes Protokoll tunneln, so kann der Angreifer in deinem LAN sich trotzdem lateral bewegen. VPNs haben eher die Funktion sich vom Homeoffice ins Firmen-LAN zu verbinden.
Ein Angreifer wird aber jeden weg, jedes Protokoll und jede Anwendung versuchen zu kompromittieren.
https://en.wikipedia.org/wiki/Privilege_escalation
…ich hatte bewusst tief gestapelt, als ich nur von ">>90%" sprach. Die von Ihnen beschriebenen Szenarien sind dann in den <<10% drin und das ist mMn realistisch, weil sie nicht wenig Vorarbeit erfordern.
In meinem Beispiel hat VPN primär den Zweck, die Anzahl der zugriffsberechtigten IPs (und damit die Anzahl der Angreifer/Angriffe) drastisch zu reduzieren.
VPN ist nicht gleich zu setzen mit einer Liste von zugelassenen IP-Adressen, denn sowas kann man fälschen.
VPN ist VPN, das setzt man entweder mit einer VPN-Software auf dem Client oder einem VPN-Router z.B. im Homeoffice und einem passenden VPN-Gateway (am besten keine Windows-Kiste!) auf Firmenseite ein.
Man kann natürlich auch noch ein Geoblocking vor das VPN-Gateway setzen und z.B. die zugriffsberechtigten IPs auf Deutschland/Europa beschränken, je nachdem wo die Mitarbeiter usw. daheim sind.
"VPN ist nicht gleich zu setzen mit einer Liste von zugelassenen IP-Adressen, denn sowas kann man fälschen."
Ach so?
Wie fälscht man denn als entfernter Angreifer (ausserhalb des ARP-Bereiches) die Quell-IP bei TCP so, dass sie für mehr als eine SYN-Attacke taugt?
…mal davon ab:
Haben Sie gerade ernsthaft geschrieben "Firewalls sind Schlangenöl"?
Denn deren Hauptaufgabe ist die (Nicht-)Gewährung von Zugriff basierend auf IP-Adressen (und Ports).
RDP macht man grundsätzlich NICHT einfach über ein Portforwarding auf dem Router der Firma. Wer das macht, ist ja des Wahnsinns fette Beute! Ja, VPN davor, und zwar auch nicht diese Varianten, die Windows selbst mitliefert. Sondern was von was weiß ich Symantec, Sophos, Checkpoint, Cisco, OpenVPN (bei der freien Community-Version muss man aber sehr genau wissen was man tut!!!), Citrix, …
Den Nutzen der RDP-Preauthentication sehe ich schon seit deren Einführung nicht ein. Das einzugebende Passwort ist das Gleiche; ob dieses früher oder später eingetragen/übermittelt wird, ist letztlich irrelevant. Das Logging wird damit auch nicht verbessert – zumindest serverseitig nicht.
Zudem habe ich die Erfahrung gemacht, dass die Preauthentication bei den Benutzern teilweise Unklarheiten und Missverständnisse verursacht. Nicht zuletzt gibt es häufig Schwierigkeiten, weil die Domäne fehlt oder eine falsche Domäne automatisch vorgeschlagen wird. Letzteres kann nicht passieren, wenn die Credentials erst auf dem Login-Screen des Zielservers eingetragen werden müssen.
Wir haben seit der Umstellung der Terminalserver auf Server 2022 das Problem, dass manchmal keine zweite Remoteapp geöffnet werden kann. Kappt man die Verbindung zum gesamten Broker über das Symbol der Taskleiste öffnet sich die zweite Remoteapp. Wir finden einfach keine Lösung… vielleicht kann jemand etwas ähnliches beobachten?
Wir haben dieses Problem auch auf gewissen Clients und Servern. Die Anzahl ist überschaubar. Wir haben noch keinen Zusammenhang gefunden. Client A kann mit Server A, Client B nicht, dafür kann Client B auf Server B,C,…
Selber Patchstand, selbe GPOs, selbe DC´s –
Wir haben festgestellt, dass der SPN beim Request des TGT nicht übermittelt wird und leer ist. Das ist mit Sicherheit ein Bug in einer gewissen Konstellation.
Wir verwenden CredSSP für Kerberos (enforced). Betrifft Server 2016, Windows 10, 11
Den Fehler gab/gibt es bei uns ebenfalls.
Die Oktober-Updates hatten wir am 2. November auf den Kundenservern installiert. Bei einem Server – bzw. einem Kunden – gab es danach Probleme, bei zwei anderen nicht.
Die Benutzer verbinden sich von extern über einen Remotedesktopgateway oder von intern mit Umgehung dessen. Die Fehlersuche wurde erschwert, weil es bei vermutlich allen Benutzern zeitweise funktionierte, zeitweise aber nicht. Wenn ich zuerst mit einem Administrator-Account eine Verbindung aufbaute, klappte gleich darauf die Anmeldung als Normalbenutzer ebenfalls.
Wir haben schliesslich beim Konfigurationsfile (welches per Logonscript verteilt wird) auf Verbindung per IP umgestellt. Ergänzend musste in den Gateway-Richtlinien die Verbindung per IP erlaubt werden.
Auf das Out of band update waren wir zwar gestossen, haben dieses aber nicht installiert.
Die Möglichkeit, den Inhalt der .RDP-Datei zu editieren, kannte ich gar nicht. Bei einem Test von soeben mit "use redirection server name:i:1" hat die Anmeldung funktioniert.
Kleine Korrektur:
Die Oktober-Updates hatten wir nicht nur für drei Kunden installiert. Die drei haben aber die gleiche Serverversion und eine vergleichbare Konfiguration. Darum hatte ich "zwei andere" erwähnt.
Bitte Client-Uhrzeiten (da vlt. MS-(?) Kerberos im Spiel ;-) beobachten(!), siehe bitte unten (30. November 2022 um 19:21). Ich vermute aber, das Microsoft-Windows 1X mit "seinen Übermittlungsoptimierungen/~bemühungen" an die Grenzen unserer Kupfer-/Glasfaser-Leitungssysteme stößt und es deswegen zu…, sagen wir mal Latenzen >= 3-5 Minuten kommt? Also lt. Verursacherprinzip sollte sich Microsoft mit an den (fuer sie?) passenden Leitungs-Ausbau (finanziell) beteiligen :-)
Moinsen,
ein Kollege bei uns hatte Probleme mit MSRA nach der Installation der Updates.
Die Installation von November 15, 2022—KB5020030 (OS Builds 19042.2311, 19043.2311, 19044.2311, and 19045.2311) Preview hat in diesem Fall zur Fehlerbehebung geführt, vlt könnten dass ja auch mal betroffene mit mstsc und FQDN problemen probieren
Da Microsoft (zunehmend?) auf Kerberos setzt, sei es nur "Handshaking" oder etwa "Authentication", ("trust" via FQDN, intern), vlt. Folgendes: Windows 11 hat m.M.n. Probleme mit der Zeit?!? Da aber Kerberos-Vorgänge (extrem) ZeitSensitiv sind (\delta T max. 3-5 Minuten zwischen Quellhost/Zielhost) vielleicht mit "psping -accepteula Zielhost-IP:3389" mal die Zeit "messen"*. Interessanterweise geht auch einfach nur die (System-)Uhrzeit des Windows 1x-Clienten nach dem Mond! Warum? Denn Batterien, BIOS-T etc. alles OK! Wir haben aber noch was anderes entdeckt: Frisch aufgesetzt: Windows 1x Clienten mit psping Zielhost-IP:Port angepingt: "Zeitüberschreitung" => Client => 2+ eingehende Firewall-Regeln fuer MS-RDP geprueft und siehe da: Stehen zwar drin, sind aber nicht aktiviert, ergo "geblockt" bei (Win1x-)Client. *Danke fuer den Tip! Siehe Link: https://learn.microsoft.com/de-de/windows-server/remote/remote-desktop-services/troubleshoot/rdp-error-general-troubleshooting#check-whether-a-group-policy-object-gpo-is-blocking-rdp-on-a-local-computer
(Firewall-blocking, Gaaaaanz weit unten :-). PS.: Meine Frage: Es gibt gegenteilige Aussagen zu RDP UDP/TCP. Unter dem Link von Microsoft wird ja vorgeschlagen: via GPO RDP auf "nur TCP" zu stellen. Aber "UDP waere besser fuer einfaches "Handshaking"", laut einem anderen MS-Artikel. Also UDP trotzdem erstmal komplett (siehe GPO) rausnehmen??? Herzlichen Dank fuer Ihre Zeit/Bemuehungen! Freundlichst O.E., Potsdam.
Ich bring hier mal den aktuellen Status ein:
MS hat das Problem bestätigt und ein Out-of-Band Update für DCs bereitgestellt:
Windows Server 2022: KB5021656
Windows Server 2019: KB5021655
Windows Server 2016: KB5021654
Windows Server 2012 R2: KB5021653
Windows Server 2012: KB5021652
Windows Server 2008 R2 SP1: Dieses Update ist noch nicht verfügbar. Weitere Informationen finden Sie hier in der kommenden Woche.
Windows Server 2008 SP2: KB5021657
(keine autom. Installation über Windows Update oder WSUS)
Quelle: 8. November 2022 – KB5019964 (Betriebssystembuild 14393.5501)