[English]Im Rahmen der Oktober 2021 Patchday-Nachlese möchte ich neben dem Beitrag Microsoft bestätigt Windows-Netzwerkdruckproblem nach Oktober 2021-Updates noch ein zweites Thema hochholen. Microsoft hat verkündigt, dass das Problem der Smartcard-Authentifizierung bei Remote Desktop-Verbindungen mit den Oktober 2021-Updates durch ein Rollback gefixt sei. Gleichzeitig sind mir hier im Blog Berichtet untergekommen, dass das Oktober 2021-Sicherheitsupdate für Windows 10 die Authentifizierung per YubiKey aushebelt.
Anzeige
YubiKey-Authentifizierung gestört
Nach Veröffentlichung der Oktober 2021-Sicherheitsupdates (siehe Patchday: Windows 10-Updates (12. Oktober 2021)) haben sich hier im Blog verschiedene Administratoren in Kommentaren gemeldet und beschreiben, dass die YubiKey-Authentifizierung nicht mehr funktioniert. IT-Guy schreibt:
Leider hat das Update bei uns die RDP-Anmeldung via Yubikey zerschossen.
Nach Deinstallation von KB5006670 ist die Anmeldung wieder möglich.
Und der Benutzer mit dem Alias CloudKasper ergänzt:
dito hier, so ein Mist. Prüfen die eigentlich ihre eigene Suppe?
vor allem hier Yubikey mit MS AD Enterprise CA, keine Drittanbietersoftware.
Laut diesem Benutzer betrifft das Problem auch Windows Hello. In einem zweiten Kommentar schreibt er:
eine Lösung habe ich bisher nicht gefunden. Es betrifft wohl auch Windows Hello.
Ein schneller Test gestern hat bei uns ergeben, dass es RDP-Clients in der selben Domäne nicht betrifft, nur RDP-Clients die keine Domänen-Zugehörigkeit haben (bei uns ein Surface, welches nicht in der Domäne angemeldet ist). Für eine Reproduzierbarkeit ist die Stichprobe bisher zu klein.Aber es muss da draussen ne Menge Admins geben, die die Konstellation Yubikey Smartcard-Zertifikat mit MS CA verwenden.
In einem aktuelleren Kommentar merkt CloudKasper an (danke dafür), dass Microsoft dies bestätigt habe und verlinkt auf den Beitrag Smartcard authentication might fail when attempting to connect using Remote Desktop im Windows 10 Statusbereich für die Version 21H1.
Anzeige
Smartcard-Authentifizierung bei Remote Desktop
Der von Microsoft im Windows 10 Statusbereich für die Version 21H1 veröffentlichte Beitrag Smartcard authentication might fail when attempting to connect using Remote Desktop adressiert das Adressierungsproblem bei Verwendung von Smartcards, dort bezogen auf den Remote Desktop (sollte aber auch Windows Hello, wie oben erwähnt betreffen). Microsoft schreibt dazu:
After installing KB5005611 or later updates, when connecting to devices in an untrusted domain using Remote Desktop, connections might fail to authenticate when using smart card authentication. You might receive the prompt, "Your credentials did not work. The credentials that were used to connect to [device name] did not work. Please enter new credentials." and "The login attempt failed" in red.
Update KB5005611 ist das Vorschau-Update vom 30. September 2021. Nach der Installation von KB5005611 oder neueren Updates kann die Smartcard-Authentifizierung bei Verbindungen zu Geräten in einer nicht vertrauenswürdigen Domäne mit Remotedesktop fehlschlagen. Die Nutzer erhalten eine Meldung "Ihre Anmeldeinformationen haben nicht funktioniert. Die Anmeldeinformationen, die für die Verbindung mit [Gerätename] verwendet wurden, haben nicht funktioniert. Bitte geben Sie neue Anmeldeinformationen ein." und "Der Anmeldeversuch ist fehlgeschlagen" in roter Schrift. Betroffen sind folgende Systeme, wenn die Updates installiert wurden:
- Client: Windows 10, Version 21H1; Windows 10, Version 20H2; Windows 10, Version 2004
- Server: Windows Server 2022; Windows Server, Version 20H2; Windows Server, Version 2004
Microsoft hat eine profunde Lösung für dieses Problem gezogen und einfach die betreffenden Patches durch die KIR-Funktion (Know Issues Rollback) aus den betroffenen Maschinen entfernt. Damit sollte auch die Authentifizierung per YubiKey wieder funktionieren. Bei nicht verwalteten Systemen erfolgt das am 15. Oktober gestartete Rollback automatisch. Bei verwalteten Systemen (Enterprise) muss eine Gruppenrichtlinie ausgerollt werden, die das Rollback triggert. Details finden sich im oben verlinkten Beitrag.
Ähnliche Artikel:
Patchday: Windows 10-Updates (12. Oktober 2021)
Microsoft bestätigt Windows-Netzwerkdruckproblem nach Oktober 2021-Updates
Windows 11: AMD-Probleme, weitere Leistungseinbußen durch Update KB5006674, Patch durch Update KB5006746
Windows 11: App-Probleme und Brother USB-Drucker drucken nicht
Windows 11: Drucker-Probleme betreffen mehr Hersteller, und Scan-/Dokumentsoftware-Kompatibilität
Windows 11: Memory-Leak im Explorer
Anzeige
Ich schrieb drüben im Thread gerade:
—
Seid so gut und schreibt genauer, was Ihr da nutzt.
Ich nutze:
Yubikey 5 NfC mit Domänenanmeldung (PIV), also Zertifikate, ausgestellt von der internen Domänen-CA auf Win10 20H2 und alles läuft nach dem Patchday problemlos lokal und per RDP.
Tragt doch nach, was Ihr nutzt.
Was MS bestätigt hat, ist doch ein Logon bei einer unvertrauten Domäne, ist das denn überhaupt der Fall bei Euch?
genau um die Clients geht es: nicht Mitglied der Domäne.
Beispiel externer Softwareentwickler, der für mehrere Kunden arbeitet.
Anruf kam prompt am Mittwoch morgen nach dem Patchday. Löblich, dass er die Updates zeitnah einspielt ;-)
Für alle trusted clients lief es zum Glück normal nach dem Update.
Yubikey 4 & 5 mit Domänenanmeldung (certificates) ausgestellt von der internen Domänen-CA auf Windows 20H2 und 21H1. Ich denke, diese Konstellation ist die übliche, um an Drittanbietersoftware vorbei zukommen.
Es geht aber Computer Login nicht mehr.
Also überhaupt keinen Zugriff auf eigenen Computer ,Meldung Benutzername oder Kennwort falsch.
Damit auch kein Update möglich oder Löschung. Muss Windows 10 auf neuer Fest Platte installieren weil USB Rettung auch nicht geht. Login werde ich dann nicht mehr machen
Für alle, die es betrifft:
Ich hatte gerade die Gelegenheit den MS Fix (oder besser workaround) zu testen, es klappt (dieser muß händisch angelegt werden auf dem NICHT-Domänenmitglieds-Client; die RDP-Gegenseite benötigt diesen Registry-key NICHT!):
registry-key:
DWORD-Wert (32Bit): 2925853837
Wert: 0x00000000
Damit schaltet er den oben genannten einzelnen Patch innerhalb des Pakets wieder ab ohne das komplette KB5006670 deinstallieren zu müssen.
Danke für die Ergänzungen. Habe ich es falsch einsortiert, aber Microsoft veröffentlicht doch Gruppenrichtlinien zum Download, die genau den benötigten Key auf verwalteten Systemen setzen. Oder musstest Du wirklich manuell den Key setzen?
absolut korrekt auf verwalteten Systemen.
Dort könnte ich die GPO auch einsetzen und auf disable mit value 0 stellen. Aber die hatten als Domänenmitglieder ja zum Glück keine Probleme mit dem Patch.
Da das Surface aber nicht verwaltet und auch kein Mitglied der Domäne ist, musste dieser Eintrag tatsächlich händisch gesetzt werden auf unserem speziellen Client.
Ok, danke für die Ergänzung.
GPO bei Leuten im Homeoffice eingespielt und konfiguriert. Nach Neustart ist eine Anmeldung mit dem Yubikey wieder möglich.
Hat bei Nicht-Mitglieder der Domäne problemlos funktioniert.
Ich habe seit diesem Update bei einem Kunden wieder massiv Probleme mit RDP Sitzungen unter UDP. Windows 10 Client, Terminalserver Windows 2019, alles aktuelle Patch-stände. Das äußert sich dann so, das die RDP Session hängt und es so aussieht als sei der Server abgestürzt. Das passiert meist sehr schnell nach dem Login auf den Server und starten einer Anwendung wie Chrome, Outlook oder Datev. Oftmals ist die Grafik in der Sitzung dann plötzlich 'zerstört'.
Ein Umstellen auf TCP für die RDP Sitzung löst in der Regel das Problem. Das erledigt man über den Regedit unter HKLM\software\policies\microsoft\windows nt\terminal services\client durch einfügen eines 32bit dword Schlüssels Names fClientDisableUDP mit dem Wert 1
Danach gibt es keine RDP Probleme mehr bei dem Kunden.
Die eigentliche Ursache ist nach wie vor unklar. Ich ärgere mich schon seit Monaten damit rum, da das Problem immer wieder mal auftaucht. Ich habe den Eindruck, das nur PCs mit Intel CPU und dort integrierter Grafikeinheit betroffen sind. Bei PCs mit zusätzlicher Grafikkarte (idr Nvidia) ist mir das in der Form noch nicht aufgefallen aber das kann täuschen.