[English]Die Anmeldeinformationsverwaltung ('Credentials Manager') ist beim Windows 10 Mai 2020 Update (Version 2004) sowie bei Windows 10 20H2 unbrauchbar, weil sie Zugangsdaten, von Anwendungen, die auf dieser Funktion aufsetzen, vergisst. In Teil 1 hatte ich das Thema ja bereits angesprochen. In Teil 2 trage ich einige zusätzliche Informationen zu einer möglichen Ursache nach.
Anzeige
Im Beitrag Windows 10 2004/20H2 und der kaputte 'Credentials Manager': Ursache und Workaround – Teil 1 habe ich das Problem der vergessenen Anmeldeinformationen in Windows 10 2004/20H2 aufbereitet. Dort findet sich auch der Hinweis, dass die Informationen zwar noch in der Anmeldeinformationsverwaltung ('Credentials Manager') gespeichert sind. Ein kaputtes Manifest, verursacht durch eines der letzten Windows 10-Updates, soll dazu führen, dass die Verschlüsselung mittels der Data Protection-API mit einem Benutzer-Key nicht mehr funktionieren. Es muss der System-Key verwendet werden – was ich im Beitrag als Workaround skizziert habe.
Eine mögliche, tiefere Ursache
Blog-Leser Bernhard Diener wies in diesem Kommentar darauf hin, dass Tavis Ormandy vom Google Project Zero diesen Fehler schon vor einiger Zeit analysiert habe. Ormandi hat Ende September 2020 in einer Reihe von Tweets seine Erkenntnisse offen gelegt.
Zeitgleich bin ich bei den Kollegen von Bleeping Computer auf diesen Artikel gestoßen, der das ebenfalls anspricht. Im Microsoft Answers-Forum gibt es diesen umfangreichen Thread, wo sich jemand initial über den systemweiten Passwort-Verlust beklagt. Viele Nutzer bestätigen den Bug. Ormandy hat bei seiner Analyse herausgefunden, dass ein bestimmter geplanter Task die CryptUnprotectData() unterbrechen kann. Führt man in einer administrativen PowerShell-Konsole folgenden Befehl aus:
Anzeige
Get-ScheduledTask | foreach { If ($_.Principal.LogonType -eq 'S4U') { $_ } }
und tauchen dort Aufgaben auf, gibt es ein Problem. Sobald die Aufgaben ausgeführt werden, funktioniert die DPAPI solange nicht mehr, bis eine Neuauthentifizierung erfolgt ist. Schuld sind geplante Aufgaben, die mit der Option S4U (Services For User) des Taskplaners erstellt wurden.
Ursache ist ein Fehler im RPC UBPM (Unified Background Process Manager), der dazu führt, dass gespeicherte Anmeldedaten im Local Security Authority Subsystem Service (LSASS) entfernt werden. Dadurch verlieren Anwendungen entweder den Anmeldestatus oder melden Benutzer von ihren Konten ab. In der Ereignisanzeige sollte dann die Eventid 8198 oder NTE_BAD_KEY_STATE als Ereignis eingetragen werden.
Ein vorgeschlagener Workaround
Ormadis schlägt vor, alle geplanten Aufgaben, die von S4U ausgeführt werden, zu deaktivieren. Hierzu ist in einer administrativen PowerShell-Konsole folgender Befehl auszuführen:
Get-ScheduledTask | foreach { If (([xml](Export-ScheduledTask -TaskName $_.TaskName -TaskPath $_.TaskPath)).GetElementsByTagName("LogonType").'#text' -eq "S4U") { $_.TaskName } }
Der Befehl listet die Aufgaben, die durch S4U geplant werden, auf. Notieren Sie alle geplanten Aufgaben, die als Ausgabe des Befehls aufgelistet werden, und deaktivieren Sie sie mit Hilfe des Windows-Taskplaners. Dieser lässt sich als Administrator über das Suchfeld der Taskleiste öffnen. Nachdem alle Aufgaben deaktiviert wurden, soll Windows neu gestartet werden. Solange die Aufgaben nicht ausgeführt werden, sollten die Anmeldeinformationen wieder erhalten bleiben.
Microsoft untersucht, Fix noch nicht verfügbar
Eric Law von Microsoft hat sich Ende September 2020 bei Ormandi in diesem Chromium-Bug-Tracker-Thread gemeldet und angekündigt, dass man den Bug untersuche. Bis zum 9. November 2020 gab es aber von Microsoft noch keine Rückmeldung, ob und wann dieser Bug beseitigt wird (lediglich dieser Artikel zu Outlook wurde zum 6.11.2020 publiziert, siehe auch folgende Kommentare). Aktuell empfiehlt es sich, auf Windows 10 Version 1909 zurück zu gehen, oder den in Teil 1 erwähnten Ansatz zu versuchen.
Ergänzung: Es sieht so aus, als ob Microsoft mit den Windows 10 November 2020 Updates das Problem behoben hat, siehe Patchday: Windows 10-Updates (10. November 2020).
Artikelreihe:
Windows 10 2004/20H2 und der kaputte 'Credentials Manager': Ursache und Workaround – Teil 1
Windows 10 2004/20H2 und der kaputte 'Credentials Manager': Ursache und Workaround – Teil 2
Ähnliche Artikel:
Windows 10 2004: 'Credentials Manager' kaputt [Workaround]
Windows 10 vergisst Zertifikate beim Upgrade
Microsoft bestätigt Zertifikatsverlust bei Windows 10-Upgrades
Office 365: Download scheitert nach Oktober 2020 Updates
Windows 10 20H2: Abstürze von lsass.exe (Okt. 2020)
Windows 10 2004/20H2 lsass.exe-Absturzproblem (Okt. 2020) bestätigt
Windows 10: Ist der Defender GUI-Bug zu definierten Ausschlüssen gefixt?
Windows 10 2004: Ist der Black-Sceen-Bug bei externen Display gefixt?
Anzeige
update bei microsoft dazu: https://support.microsoft.com/en-us/office/outlook-and-other-apps-won-t-remember-password-after-windows-updates-1e5a8a80-7112-440a-a18c-be2e50047a75
Danke, war an mir vorbei gegangen. Aber windige Geschichten, die MS den Nutzern aufbürdet.
Das ist gut zu Wissen. Ich plane den Umstieg von derzeit 1909 auf 20H2 aber eh erst ende Januar 2021 / Anfang Februar 2021. Hab beschlossen nur noch zu den H2 Updates Windows 10 zu Aktualisieren (Also nur 1x Pro Jahr), aufgrund der Fehleranfälligkeit der größeren H1 Updates.
Der Workaround hat bei mir geholfen. Danach habe ich das November Update gemacht. Empfehlen Sie den Reg Eintrag aus dem Workaround wieder zu löschen?
Vielen Dank nochmals für den Workaround – es war einer der Probleme die Stunden bei Usern erspart hat – gerade in Kleinunternehmen – wo ist der Donate-Button? Die Werbung klicke ich teilweise eh schon an, weil es mich interessiert.
Sobald ein Fix von Microsoft verfügbar ist, würde ich persönlich den Key aus Teil 1 wieder löschen.
Zum Donate-Button: In der Seitenleiste gibt es eine Spenden-Schaltfläche für Paypal.
Bin u.a. auf Windows 10 21H2 unterwegs und habe das Thema noch immer. Da sollte der o.g. Fix ja enthalten sein.
Es scheint also verschiedene Ursachen für den besagten NTE_BAD_KEY_STATE-Fehler zu geben. Aber die Beobachtung von dem Autoren des DPAPI-Testtools kann ich auf meinem lokalen System bestätigen: es gibt Unmengen von Dateien unter %APPDATA%\Roaming\Microsoft\Protect\%SID% … bei anderen Rechnern nicht.
Habe das mittlerweile auch auf anderen Rechnern nachvollziehen können, bspw. von Kunden meiner Firma die sich über die Vergeßlichkeit unserer Software beschweren. Habe deswegen auch mit Tavis Ormandy Kontakt aufgenommen und er verdächtigt trotz des von Microsoft ausgelieferten Hotfix für das S4U-Problem nach wie vor irgendwelche geplanten Tasks als Ursache.
Habe mich mittlerweile durch die halbe DPAPI reverse-engineert und habe sowohl "Aufnahmen" mit PerfView und ProcMon von dem Verhalten gemacht (manchmal konnte man es forcieren indem man den Rechner sperrte und wieder entsperrte). Bisher ist die eigentliche Ursache aber noch nicht gefunden. Im Moment geht es ran an lsass.exe, was bei einem kritischen Systemprozeß natürlich immer etwas haarig ist.
Mit Microsoft habe ich mittlerweile auch ein Supportticket eröffnet und erhoffe mir davon weitere Fortschritte.
Ansonsten habe ich mittlerweile die Logs unter Microsoft-Windows-Crypto-DPAPI/Operational und Microsoft-Windows-Crypto-DPAPI/Debug aktiviert. In ersterem sieht man passend zu den Dateien unter %APPDATA%\Roaming\Microsoft\Protect\%SID% immer einen passenden Eintrag mit Event ID 1 "DPAPI created Master key." und dann der neue Name in Form einer GUID.
Auch ist mir aufgefallen daß die CREDHIST-Datei niemals aktualisiert wurde. Diese Datei sollte laut dem DPAPI-Artikel von Passcape die jeweiligen Master-Keys in %APPDATA%\Roaming\Microsoft\Protect\%SID% referenzieren und ermöglichen mit alten Schlüsseln DPAPI-geschützte Geheimnisse auch nach Paßwortwechsel (_nicht_ Reset!) weiter entschlüsseln zu können. Gelesen wird die Datei lt. ProcMon und PerfView-Daten schon, aber nie aktualisiert, trotz Neuerstellung eines Master-Keys.
Das Log (ein ETW-Provider) Microsoft-Windows-Crypto-NCrypt/Operational habe ich ebenfalls aktiviert, genau wie Microsoft-Windows-CAPI2/Operational. Dabei sollte man tunlichst auch die Größe der jeweiligen Logs nach oben anpassen, damit sie nicht ständig überlaufen und alte Einträge überschreiben. Ich hab mich auf 20 MiB festgelegt. Das scheint bislang ausreichend für mehrere Tage.
Ich habe mittlerweile auch einen konkreten Verdacht in Zusammenhang mit einem USB-basierten "Security Key" (vulgo Smartcard aus Sicht von Windows), aber dieser Verdachtsmoment ergab sich erst heute, weswegen ich ihn noch nicht bestätigen oder ausschließen konnte. Es würde insofern passen, weil unter der Haube CAPI2/CNG ja erweiterbar gedacht sind.
Halte mich auf dem Laufenden – wenn es konkrete Erkenntnisse gibt, könnte ich das in einen Blog-Beitrag gießen. Danke für den Hinweis.