Ein Klick in der Benutzerverwaltung — und vier Abende Fehlersuche
Warum ein zurückgesetztes Windows-Kennwort ein Benutzerprofil unwiederbringlich zerstören kann.
Es beginnt harmlos. Ein Arbeitsplatzrechner meldet beim Start von Outlook einen Fehler:
TPM-Problem des Geräts
Es gibt ein Problem mit dem Trusted Platform Module (TPM) Ihres Geräts.
Fehlercode:
-2146893813
Ein TPM-Problem also. Der Sicherheitschip. Klingt nach Hardware, klingt überschaubar.
Es war weder das eine noch das andere.
Was wir zuerst geprüft haben
Der naheliegende Weg zuerst. Das TPM meldete sich in bester Verfassung: initialisiert, speicherbereit, kein Lockout, kein Fehler im Ereignisprotokoll. Ein Modul mit aktueller Firmware, technisch tadellos.
Also weiter. Die Token-Caches von Office wurden umbenannt — Windows legte sie neu an, der Fehler blieb. Im Benutzerzweig der Registry fand sich eine verwaiste Workplace-Join-Registrierung, die auf ein Zertifikat verwies, das im Zertifikatspeicher gar nicht mehr existierte. Ein Fund, der überzeugend aussah. Wir räumten ihn ab. Der Fehler blieb.
Dann ein Blick auf die Krypto-Ordner des Systems: 1.794 Schlüsselblobs, sämtlich innerhalb von zwei Tagen im Juni entstanden. Etwas hatte über 48 Stunden hinweg im Sekundentakt versucht, einen Schlüssel anzulegen, war jedes Mal gescheitert und hatte den Rest liegen lassen. Ein eindrucksvolles Symptom — aber eben nur ein Symptom.
Das BIOS war zwei Jahre alt. Wir aktualisierten es. Der Fehler blieb.
An diesem Punkt stand als nächste Maßnahme das Löschen des TPM im Raum. Es wäre die falsche Entscheidung gewesen.
Der Satz, der alles änderte
„Der Account hat funktioniert, bis wir per MMC das Benutzerpasswort entfernt haben."
Ein Nebensatz. Und die vollständige Erklärung.
Was dabei tatsächlich passiert
Windows schützt lokale Geheimnisse über die Data Protection API, kurz DPAPI. Gespeicherte Kennwörter, Zertifikat-Privatschlüssel, Anmeldetokens von Office und Microsoft 365 — sie alle hängen an einem sogenannten Masterkey. Und dieser Masterkey ist mit dem Kennwort des Benutzers verschlüsselt.
Hier liegt der entscheidende Unterschied, den die Oberfläche nicht erklärt:
Ändert der Anwender sein Kennwort selbst über Strg + Alt + Entf, hängt sich DPAPI in den Vorgang ein. Das alte Kennwort ist in diesem Moment bekannt, der Masterkey wird entschlüsselt und mit dem neuen Kennwort wieder verschlossen. Die Kette bleibt geschlossen, alles bleibt lesbar.
Setzt ein Administrator das Kennwort zurück — über die Computerverwaltung, über net user, über jedes andere administrative Werkzeug —, dann fehlt genau diese Information. Der Administrator kennt das alte Kennwort nicht. Der Masterkey kann nicht entschlüsselt und nicht neu verschlüsselt werden.
Er wird dabei nicht gelöscht. Er bleibt liegen. Nur eben für immer unlesbar.
Und mit ihm alles, was darunter hing.
Der Fehlercode 0x8009000B heißt übersetzt: Schlüssel ist im angegebenen Status nicht gültig. Kein TPM-Fehler. Ein DPAPI-Fehler, den Microsoft in diesem Dialog schlicht falsch beschriftet.
Windows warnt beim Zurücksetzen übrigens durchaus — mit einem Hinweis auf möglichen Datenverlust. In einer Domäne fängt ein serverseitiges Backup des Masterkeys den Fall ab. Auf einem eigenständigen Rechner gibt es dieses Netz nicht.
Warum die Reparatur trotzdem scheiterte
Die Diagnose stand. Die Behandlung war klar: Masterkeys entfernen, damit Windows eine frische Kette aufbaut.
Das funktionierte auch. Ein Test bestätigte anschließend, dass die lokale Verschlüsselung wieder einwandfrei arbeitete.
Nur meldete Outlook weiterhin denselben Fehler.
Es folgte eine Woche des Schichtenabtragens. Bei jedem Schritt fand sich eine weitere Ablage mit totem Schlüsselmaterial:
| Fundstelle | Ältester Stand |
|---|---|
| Token-Caches von Office | 2019 |
| DPAPI-Masterkeys | 2019 |
| Schlüsselcontainer, zwei getrennte Zweige | 2025 |
| Verwaiste Geräteregistrierung eines früheren Mandanten | — |
| Hinterlegte Konten im Windows-Kontospeicher | 44 Stück, ältestes von 2021 |
| Zwischengespeicherte Postfächer | vier verwaist, seit zehn Monaten unberührt |
Nach jeder einzelnen Bereinigung kam derselbe Fehler zurück.
Der eigentliche Befund
Irgendwann wurde deutlich, dass wir nicht ein Problem behandelten, sondern ein Symptom von etwas Grundsätzlicherem.
Dieses Benutzerprofil war über sieben Jahre und mehrere Rechnerwechsel hinweg mitgewandert. Es trug Schlüsselmaterial aus einer Zeit, in der die heutige Hardware noch nicht existierte. Es enthielt Kontoreste aus zwei verschiedenen Microsoft-365-Mandanten, das zwischengespeicherte Postfach eines längst ausgeschiedenen Kollegen und Zwischenspeicher, die niemand mehr zuordnen konnte.
Von 237 Gigabyte Systemplatte waren 12 übrig. Davon entfielen allein 76 Gigabyte auf Outlook-Zwischenspeicher, gut 10 weitere auf temporäre Dateien. Die tatsächlichen Arbeitsdaten des Anwenders: 1,44 Gigabyte.
Ein Profil in diesem Zustand ist nicht reparabel im Sinne von „noch ein Handgriff". Jeder gefundene Rest führt zum nächsten.
Die ehrliche Konsequenz
Wir haben die Reparatur eingestellt und ein neues Benutzerprofil aufgesetzt.
Übernommen wurden die tatsächlichen Nutzdaten und die Browser-Lesezeichen — beides unverschlüsselte Dateien, die problemlos mitwandern. Bewusst nicht übernommen wurde alles, was DPAPI-verschlüsselt war: gespeicherte Kennwörter, Anmeldeinformationen, sämtliche Anwendungsdaten von Microsoft. Genau dieses Material hätte das Problem ins neue Profil importiert.
Die gespeicherten Kennwörter waren ohnehin verloren. Sie standen seit dem Reset nur noch als tote Einträge in Listen, die niemand mehr entschlüsseln konnte.
Zeitaufwand für das neue Profil: rund zwei Stunden. Zeitaufwand für die vorangegangene Fehlersuche: ein Vielfaches davon.
Nicht jedes Problem ist ein Reparaturfall. Manchmal ist die ehrlichste Diagnose, dass die Substanz nicht mehr trägt.
Was wir daraus mitnehmen
Lokale Kennwörter niemals administrativ zurücksetzen. Auf einem Rechner ohne Domänenanbindung gibt es keine Rettungsleine. Der Anwender ändert sein Kennwort selbst über Strg + Alt + Entf — nur dieser Weg erhält die Schlüsselkette. Ist das Kennwort wirklich unbekannt, muss man wissen, dass man dabei alle lokal geschützten Geheimnisse aufgibt.
Ein zurückgesetztes Kennwort lässt sich noch retten. Solange der alte Wert bekannt ist, stellt das Zurücksetzen auf genau dieses Kennwort den Zugriff wieder her. Die Masterkeys werden nie gelöscht — sie warten. Diese Chance besteht allerdings nur, solange jemand den alten Wert noch kennt.
Fehlermeldungen lügen nicht, aber sie zeigen manchmal in die falsche Richtung. „TPM-Problem des Geräts" hat uns Tage gekostet. Der eigentliche Hinweis stand im Fehlercode, nicht in der Überschrift.
Benutzerprofile haben eine Lebensdauer. Ein Profil, das über Jahre und mehrere Geräte mitwandert, sammelt Zustand an, den niemand mehr auseinandersortiert. Bei einem Gerätewechsel ist ein frisches Profil mit gezielter Datenübernahme oft die günstigere Rechnung — auch wenn sie im Moment teurer aussieht.
Ein Nebensatz kann mehr wert sein als jede Diagnose. Die entscheidende Information kam nicht aus einem Werkzeug. Sie kam aus einer beiläufigen Bemerkung darüber, was vorher geändert worden war. Danach zu fragen, gehört an den Anfang jeder Fehlersuche — nicht in die Mitte.
Alle Angaben in diesem Beitrag sind anonymisiert. Namen, Adressen, Kennungen und Systembezeichnungen wurden entfernt oder verallgemeinert.