Nach Update auf 24H2 kann keine RDP-Verbindung zu einzelnen Systemen aufgebaut werden

[passt 10]

Hallo allerseits,

ich habe Mitte Januar mein Windows 11 auf 24H2 upgedatet. (Inziwschen sind noch zwei Kulmutative Updates für win11 24h2 dazu installiert.) Seit der Installation von 24H2 kann ich mich nicht mehr per RDP auf unterschiedliche unserer Windows Server oder Clients anmelden. Es erscheint die Fehlermeldung:

Authentifizierungsfehler.
Der angeforderte Verschlüsselungstyp wird vom Kerberos-Domänencontroller nicht unterstützt. 

Die Meldung erscheint bei einigen Maschonen bevor ich Zugangsdaten eingeben soll und bei anderen nachdem ich diese eingegeben habe.

 

Umgehen kann ich diese Meldung nur, indem ich in dem Windows, auf das ich zugreifen will, in den Remote-Einstellungen diese Option deaktiviere:

Verbindungen nur von Computern zulassen, auf denen Remotedesktop mit Authentifizierung auf Netzwerkeben ausgeführt wird

 

Was ist mit dem Update Win11 24H2 installiert worden, das diese Verbindungsschwierigkeiten verursacht?

Kann ich das auch clientseitig beheben?

 

Gruß,

Peter

bearbeitet 13. Februar von passt

[Nobbyaushb 1.506]

Moin,

gesehen habe ich das noch nicht - aber wie wird denn auf die RDP Hosts zugegriffen?

FQDN oder IP-Adresse?

Gleiches LAN oder VPN / Remote?

[NorbertFe 2.155]

vor 32 Minuten schrieb passt:

s, auf das ich zugreifen will, in den Remote-Einstellungen diese Option deaktiviere:

Verbindungen nur von Computern zulassen, auf denen Remotedesktop mit Authentifizierung auf Netzwerkeben ausgeführt wird

Soweit ich weiß erfordert die NLA NTLM Authentifizierung :)

[MurdocX 965]

Hallo,

 

wurden die Kerberos Encryption Types msDS-SupportedEncryptionTypes verändert? Das deutet in die Richtung.

Wurden GPOs zur Härtung auf die Clients, Server oder DCs angewendet?

Wann wurde zuletzt das Passwort des KRBTGT-Kontos geändert? (Jahr reicht)

VG,

Jan

bearbeitet 15. Februar von MurdocX

[NorbertFe 2.155]

vor 19 Minuten schrieb MurdocX:

wurden die Kerberos Encryption Types msDS-SupportedEncryptionTypes verändert? Das deutet in die Richtung.

 

Wenn es ohne NLA funktioniert deutet es meiner Meinung nach eben nicht auf Kerberos hin, da die NLA NTLM verwendet.

[MurdocX 965]

Ob hier ein Fallback passiert, wenn Kerberos fehlschlägt weiß ich nicht. Könnte ich mir aber vorstellen. Geht ja von Extern zum RDGW auch so. 

 

Ist der Benutzer vielleicht in den Protected-Users?

[NorbertFe 2.155]

vor 18 Minuten schrieb MurdocX:

Ob hier ein Fallback passiert, wenn Kerberos fehlschlägt weiß ich nicht

Nein, die NLA funktioniert _nur_ mit NTLM. Da kommt kein Fallback _auf_ NTLM.

https://www.gruppenrichtlinien.de/artikel/rdp-ohne-ntlm-richtlinien-und-verhaltensweisen-zur-reduktion-von-ntlm

bearbeitet Samstag um 17:19 von NorbertFe

[cj_berlin 1.393]

vor 14 Minuten schrieb NorbertFe:

Nein, die NLA funktioniert _nur_ mit NTLM. Da kommt kein Fallback _auf_ NTLM.

https://www.gruppenrichtlinien.de/artikel/rdp-ohne-ntlm-richtlinien-und-verhaltensweisen-zur-reduktion-von-ntlm

Also der Mann, der dafür verantwortlich ist, ist nicht der Meinung, dass das Verhalten hartkodiert ist, und ich meine auch, dass NLA durchaus für User funktioniert, die in Protected Users Mitglied sind:
https://syfuhs.net/how-authentication-works-when-you-use-remote-desktop. Auch Artikel über Remote Credential Guard sagen nichts dazu, dass man dafür NLA abschalten muss.

*wenn* man natürlich IP-Adressen für die RDP-Verbindung verwendet *und* keine IP-basierten SPNs ausgerollt hat, *dann* wird NTLM zwingend verwendet werden.

[NorbertFe 2.155]

OK, muss ich bei Gelegenheit mal testen. Hab mich jetzt auf Mark verlassen.

[passt 10]

Am 13.2.2025 um 17:27 schrieb Nobbyaushb:

Moin,

gesehen habe ich das noch nicht - aber wie wird denn auf die RDP Hosts zugegriffen?

FQDN oder IP-Adresse?

Gleiches LAN oder VPN / Remote?

Die Hostnamen der Rechner können problemlos aufgelöst werden und sie stehen im selben LAN.

 

Ich muss gestehen, ich bin mit den Begriffen NLA und NTLM nicht vertraut. Wenn ich NLA richtig verstehe, geht es um die Anmeldung an einen Windows Server/Workstation bevor die RDP-Sitzung aufgebaut wird. Diese Anmeldung schlägt bei mir seit dem Update auf 24H2 fehl.

Windows Rechner ohne aktiviertem NLA, siehe meinen obersten Beitrag, bauen die RDP-Sitzung auf und lassen mich dort erfolgreich meine Anmeldung durchführen.

 

Zitat

Ist der Benutzer vielleicht in den Protected-Users?

Nein, zB auf Win10 PCs gibt es diese Gruppe nicht.

 

Btw, wir verwenden RDP nur zur Verwaltung von Windows Rechnern und nicht als Terminal Server.

bearbeitet Montag um 09:05 von passt

[zahni 566]

Entweder ist am Client Kerberos mit AES256 nicht erlaubt oder am DC deaktiviert?

[passt 10]

Zur Info, wir haben kein Active Directory mit Windows Server als DC sondern eine Samba 4 "Domäne" auf einem Linux Server.

Die Windows Server (und auch Windows Clients), zu denen ich mich nicht mehr per RDP verbinden kann, sind nur Domänenmitglieder aber keine DCs.

 

Am 17.2.2025 um 10:30 schrieb zahni:

Entweder ist am Client Kerberos mit AES256 nicht erlaubt oder am DC deaktiviert?

D.h. entweder wird AES256 auf meinem Win11 verboten oder es wird erzwungen und durch Deaktivierung am DC kommt die RDP-Verbindung nicht zustande?

 

 

Btw, es gibt zahlreiche andere Meldung über RDP-Probleme unter Windows 11 nach dem Update auf 24H2. Außerdem habe ich den Fehler gerade auf einem anderen Rechner nachstellen können. 
 

[zahni 566]

 Da kann ich Dir nicht weiterhelfen. Ob und wie Kerberos mit Samba funktioniert: keine Ahnung. Es kann hier aber sein, dass durch unterschiedliche Windows-Versionen am Client und Server unterschiedliche Encryption Types konfiguriert sind. Ob überhaupt Kerberos benutzt wird, muss Du selber herausfinden.

 

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos

[daabm 1.384]

Man könnte am Client ja mal gucken, was für Tickets man bekommt klist get HOST/<FQDN>
Und man könnte gucken welche ETypes die Zielkonten unterstützen powershell get-adcomputer <hostname> -properties msds-supportedencryptiontypes (Spoiler: Da sollte 24 oder 28 drinstehen)