Das Problem der zwischengespeicherten Anmeldeinformationen

Die Ausgangssituation zu diesem Problem war, dass bei einer Benutzerin in der Personalabteilung sich das Benutzerkonto permanent sperrte. Ein aktiviertes Server-Auditing zeigte eindeutig, dass es ihr primärer Rechner war, von dem die Sperrung kam. Mittels der ALTools.exe (aus den Account Lockout and Management Tool Suite von Microsoft) konnten der Zeitpunkt der Sperrung und der Auslöser eingegrenzt werden. Ein Passwort-Raten durch Dritte war damit ausgeschlossen.

Der Auslöser war die Personalsoftware. Jedes Mal, wenn über den Link auf dem Desktop die Anwendung am Server aufgerufen wurde, wurde dreimal ein falsches Passwort gesendet. Bei weiteren unvermeidlichen Arbeiten mit der Software wurde irgendwann der Schwellenwert zur Sperrung erreicht. Die erste Vermutung: ein gespeichertes Passwort, dass nach der letzten Passwortänderung tapfer weiter das alte Passwort sendet. Also wurde in der Anmeldeinformationsverwaltung der Systemsteuerung der Windows-Tresor überprüft. Doch dieser war leer und unbenutzt.

Als nächstes hat sich diese Benutzerin an einem anderen Rechner angemeldet. Die Software lief problemlos, und das Konto wurde nicht gesperrt. Dann hat sich ein anderer Benutzer am ersten Rechner angemeldet. Die Software lief problemlos und auch hier wurde das Konto nicht gesperrt.

Aus Erfahrung war jetzt das Benutzerprofil der Hauptverdächtige. Das alte Profil wurde ordnungsgemäß gesichert, entfernt und ein neues Profil angelegt. Das Problem blieb jedoch bestehen.

Mark Russinovich proklamiert an dieser Stelle stets: „when in doubt, run process monitor!“ Der nächste Schritt war folglich, den Process Monitor aus der Sysinternals Suite anzuwerfen und einen tieferen Blick auf das Problem zu werfen. An dieser Stelle machte ich allerdings den Fehler, dass ich bereits vor Beginn des Monitorings schon einen Filter auf die Personalsoftware setzte. Diese verursachte schließlich den Fehler, also wollte ich auch nur diese im Logfile haben.

Ergebnis: nichts Ungewöhnliches. Die wirkliche Ursache blieb vorerst ungelöst. Das Problem war nach einer Neuinstallation des Rechners auch verschwunden. Weitere Energie sollte ich dafür nicht aufwenden.

Vor zwei Monaten tauchte das Problem dann bei zwei anderen Kolleginnen auf. Dieses Mal wurde gleich der Rechner getauscht und der alte stand für Tests dauerhaft zur Verfügung. Das Problem sollte nun ein für alle Mal gelöst werden. ALTool.exe, Prozess Monitor und Prozess Explorer scharrten mit den Füßen. Die Größe der Log-Dateien hielt sich in Grenzen, denn ich startet die Anwendungen und stoppte sofort nach Aufruf der Verknüpfung.

Ich wandte mich dem Process Monitor zu und da dieses Mal kein Filter gesetzt war, fanden sich auch außergewöhnliche Einträge unter den Ergebnissen. (Wer bisher wenig mit dem Process Monitor gearbeitet hat oder noch nie eine der „the case of“-Videos von Mark Russinovich gesehen hat: das fertige Log kann man schnell über „Tools – Count Occurrences…“ auf Anzahl der Ergebnisbegriffe filtern. Einfach die Spalte auf „Results“ umstellen und auf die Schaltfläche „Count“ klicken.)

In diesem Fall waren es elf „Access Denied“ und ein „Logon failure“. Letzterer zeigte allerdings nicht auf die HR-Software, sondern auf den Dienst „btservice.exe“. Dieser Dienst gehört zur Software „Powerbroker for Windows“ von Beyond Trust. (Powerbroker ermöglicht es dem Administrator einer definierten Anwendung über eine Gruppenrichtlinie erhöhte Benutzerrechte zuzuweisen.)

Der Dienst wurde angehalten. Das Problem war weg. Der Dienst wurde gestartet. Das Problem war wieder da.

Standardmäßig lief der Dienst unter dem Systemkonto. Also habe ich einen neuen lokalen Benutzer angelegt, diesen in die Gruppe der lokalen Administratoren aufgenommen und als Konto für den Dienst hinterlegt. Das Problem war weg. Das Systemkonto wieder eintragen. Das Problem war wieder da.

An dieser Stelle war ich erst einmal ratlos, wie sich das Systemkonto die Anmeldeinformationen merken konnte, wenn der Windows-Tresor leer ist. Bis zu diesem Zeitpunkt habe ich davon noch nie was gehört. (Was vermutlich bei vielen Dingen so ist, wenn man nicht mit der Nase draufgestoßen wird :-))

Somit stellte sich die Frage, wo man sieht, dass es ein gespeichertes Passwort für ein Domänenkonto gibt und wie man das abstellt. Der Eintrag auf http://serverfault.com/questions/375036/how-can-i-clear-cached-domain-credentials brachte schließlich die Lösung.

Wieder benötigt man ein Tool aus der Sysinternals Suite: psexec.exe. Mit den Parametern „psexec.exe -i -s regedit.exe“ startet man die Registry als „System“ und hat hier Zugriff auf den HKLM\System-Zweig. Unter „Cache“ stehen die zwischengespeicherten Passwörter in verschlüsselter Form.

Bitte SO nicht nachmachen! Da es ein Test-Rechner war, habe ich direkt ohne mit der Wimper zu zucken alle Einträge gelöscht, die folgendes Format aufwiesen „NL$<Zahl>. Nach einen Rechner-Neustart wurde für den Dienst wieder das Systemkonto gesetzt und das Problem trat nicht mehr auf.

Für einen Rechner, der einem erhalten bleiben soll, empfiehlt sich allerdings es so zu lösen, wie es auf der o.a. Seite beschrieben ist: über die secpol.msc unter den Security Settings – Local Policies – Security Options kurzzeitig den Cache-Wert auf Null und danach wieder auf den Ausgangswert „10“ zu setzen. Der Eintrag heißt auf Englisch: „Number of previous logons to cache (in case domain controller is not available)“. Auf deutsch: „Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorherige Anmeldungen (für den Fall, dass der Domänencontroller nicht verfügbar ist)“.

Die HR-Kollegin hat dann noch als abschließenden Test ihre Arbeiten mit dem alten System durchgeführt und die Sperrung war „Geschichte“.