MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Cached Profile als Risiko

Normalerweise meldet sich ein Anwender auf einem Windows Client an, wobei der Anmelddienst den dahinterliegenden Verzeichnisdienst konsultiert, z.B.: ein Active Directory oder Entra ID. Ist keine Verbindung zu diesem Verzeichnis vorhanden, können sich Benutzer aber immer noch anmelden, wenn Sie früher schon einmal angemeldet waren. Windows kennt dazu "Cached Credentials". Das kann ein Risiko sein, wenn ein Benutzer ausscheidet und sie erwarten, dass er nun sich nicht mehr anmelden kann.

Testserie

Ich habe dazu eine kleine Testserie gestartet, indem ich einen Domain Benutzer im AD angelegt und dann verschiedene Aktionen auf einen Windows 11 24H2-Client im August 2025 durchgespielt habe.

Verbindnug

Aktion

Status

Ergebnis

 

Online

 

Ungültiger User

 
"Benutzer oder Kennwort falsch"

Wie nicht anders zu erwarten, konnte ich mich nicht anmelden.

 

Off

 

Ohne lokales Profil

 
"Domain nicht verfügbar"

Wie nicht anders zu erwarten, konnte ich mich nicht anmelden.

 

Offline

 

Keine Änderung

Erfolgreiche Anmeldung

Wie nicht anders zu erwarten, konnte ich mich mit dem Benutzer auch anmelden, wenn keine Verbindung zum Domain Controller möglich ist

 

Online

 

Kennwort aktiv

Erfolgreiche Anmeldung

Wie nicht anders zu erwarten, konnte ich mich mit dem Benutzer anmelden.

 

Online

 

Kennwort geändert

Anmeldung mit neuem Kennwort möglich

Wird das Kennwort in der Domain geändert, wird bei der nächsten Anmeldung das neue Kennwort erzwungen. Eine Anmeldung mit dem bisherigen Kennwort ist nicht möglich. Der Windows Client

 

Offline

 

Kennwort geändert

Danach habe ich das Kennwort in der Domain von einem anderen Client aus geändert. Da der Clients des Benutzers nicht im Netzwerk war, konnte er das nicht mitbekommen. Eine Anmeldung des Anwenders am Client konnte weiter mit dem alten Kennwort erfolgen. Das Verhalten ist aber erwartet und auch erwünscht, damit Anwender z.B. unterwegs oder im Home Office ohne Verbindung zur Firma sich anmelden können.

Hinweis: Auch wenn der Client "online" war, hat er die Kennwortänderung nicht mitbekommen. Erst beim Anmelden prüft der Client die Verbindung zum DC.

 

Online

Konto deaktiviert

 

"Das Konto ist deaktiviert"

Da der Anmeldedienst während des Login die Daten des Benutzers im Verzeichnis prüft, fällt auch ein gesperrtes Konto direkt auf.

Hinweis: Ein fehlerhafter Anmeldeversucht aufgrund einer Kontosperrung führt dazu, dass auch das lokale Profil gesperrt wird und eine Anmeldung am DC erforderlich ist.

 

Offline

Konto deaktiviert

Ist der Client aber Offline und gab es vorher noch keinen abgebrochenen Anmeldeversucht, dann kann der Client nicht wissen, ob ein Konto gesperrt ist. Der Anwender kann sich weiterhin "offline" mit dem Kennwort anmelden, welches bei der letzten Anmeldung noch gültig war.

 

Online

Konto gelöscht

 

"Benutzer oder Kennwort falsch"

Wurde das Konto im lokalen AD gelöscht, dann kann sich der Benutzer nicht mehr Anmelden. Die Fehlermeldung unterscheidet sich nicht vom ersten Fall, dass es den Benutzer noch nie gegeben hat. Dass es noch ein lokales Profil gibt, interessiert nicht.

 

Offline

Konto gelöscht

Anmeldung erfolgreich

Hier könne man nun behaupten, dass dies ja zu erwarten ist, denn der Client kann ja nicht den DC fragen. Das stimmt aber ich habe den Test auch noch mal wiederholt, nachdem der Client online war und da eine Anmeldung nicht mehr möglich war.

Der Anmeldedienst sperrt/löscht keine lokalen Konten oder Profile, obwohl das Konto nachweislich im Verzeichnisdienst nicht mehr vorhanden war.

 

Offline

Neuer Benutzer

Ohne Verbindung zum Verzeichnisdienst kann sich ein neuer Anwender nie auf dem PC anmelden. Das überrascht aber auch nicht, denn woher sollte der Windows Client auch die Information haben. Er repliziert ja nicht auf Vorrat alle möglichen Benutzer mit ihren Zugangsinformationen.

 

Der Client wurde zwischen den Tests nicht durchgestartet.

Zwischenstand - bedingt sicher

Mit dem Wissen können wir festhalten, dass eine Anmeldung an einem Windows 11 24H2-Client bei einer aktiven Verbindung zum Verzeichnisdienst je nach Konfiguration (aktive, neues Kennwort, gesperrt, deaktiviert, gelöscht) durch das Verzeichnis gesteuert wird. Wenn der Client aber keine Verbindung zum Verzeichnis hat, dann kann der Client nicht erkennen, welchen Status das Konto gerade hat. Es ist für den Anwender weiterhin möglich, eine Anmeldung mit dem damals gültigen Anmeldedaten anhand der "Cached Logon Information" durchzuführen. Er bekommt dann natürlich erst einmal auch kein Kerberos-TGT und weitere TGS-Tickets für den Zugriff auf andere Systeme. Auch eine Anmeldung per NTLM nach wiederherstellen der Verbindung ist erst wieder möglich, wenn das Kennwort weiterhin identisch ist oder aktuelle Kennwort neu eingegeben wurde. Der Zugriff auf Server selbst ist damit unterbunden.

Im Risiko sind natürlich alle lokalen Daten auf dem Client, an welche der Anwender noch herankommt. Wenn er sogar lokaler Administrator ist, dann kann er den Client auch verändern. Eine Konto-Sperrung wird auf dem Client gespeichert, wenn eine Anmeldung fehlgeschlagen ist. Anders sieht es bei gelöschten Konten aus. Hier scheint der Windows Anmeldedienst nicht intelligent genug zu sein, so ein Konto zu beseitigen. Wenn ich mich einmal korrekt angemeldet habe, dann kann ich mich auch zukünftig weiter "offline" anmelden, selbst wenn das Konto im Verzeichnisdienst gelöscht wurde und eine Anmeldung am Client fehlgeschlagen ist.

Es gibt keinen Hintergrundprozess im Anmeldedienst, der bei einer Verbindung zum Verzeichnisdienst die Konten überwacht, für die es lokale Profile gibt und ggfls. sperrt oder aufräumt.

Ich hätte mir schon gewünscht, dass ein Client z.B. alle 60 Minuten die Liste der lokalen Profile mit Domain-Benutzern gegen das AD abgleicht und ggfls. die Profile bereinigt oder die Anmeldung entsprechend sperrt oder zumindest bei jeder neuer interaktiven Anmeldung mit Verbindung zum DC die bestehenden Profile kurz checkt.

Überrascht hat mich aber, dass ein gelöschter Benutzer sich an einem Computer mit Verbindung zum DC sich zwar nicht mehr anmelden kann, aber der Clients dies nicht zum Anlass nimmt, die "Offline"-Anmeldung zu unterbinden.

Übrigens war genau das auch der Auslöser für diesen Artikel. Ein Mitarbeiter hatte neben seinem regulären Anmeldekonto auch noch ein Admin-Konto, welches auf dem lokalen Computer erweiterte Rechte hatte. Da er dieses Konto aber einige Zeit nicht mehr verwendet hat, wurde es in der Domain gelöscht. Monate später hat sich der Anwender aber wieder an sein privilegiertes Konto erinnert und konnte sich damit "offline" sogar auf dem Client anmelden. Das war so nicht von der Firma gewünscht.

Abhilfe: Gruppenrichtlinien

Microsoft hat keinen eingebauten Prozess, um die lokalen und Profile und Konten zu bereinigen oder einen Status abzugleichen. Es gibt aber verschiedene Möglichkeit die Sicherheit zu verbessern. Über Gruppenrichtlinien lassen sich zwei Einstellungen recht einfach anpassen:

  • "Interactive logon: Number of previous logons to cache (in case domain controller is not available) "
    In der Standardeinstellung cached Windows bis zu 10 Benutzeranmeldeinformationen. Diesen Wert können reduziere, wenn ein Computer nur von einer Person genutzt wird. Ein Wert von "0" verhindert dies und ist für ortsfeste Desktops eine geeignete Einstellung. Der Maximalwerte ist 50". Für Laptops und andere mobile und nicht permanent verbundene Geräte ist dies natürlich keine Lösung und denken Sie daran, dass einige Anmeldeverfahren , z.B. Smartcard zwei Einträge belegen.
  • "Interactive logon: Require Domain Controller authentication to unlock"
    Diese Einstellung erzwingt auch beim Entsperren eines clients eine Verbindung zum Domain Controller. Damit bringen Sie ihre mobilen Arbeiter sehr schnell zur Weißglut.

Neben den lokalen Richtlinien gibt es auch ADMX-Vorlagen zu Profilen. 

Hier ist eine Einstellung interessant:

  • "Delete user profiles older than a specified number of days on system restart"
    Diese Einstellung sollte eigentlich die Forderung erfüllen, dass länger nicht mehr genutzte Profile von Windows beim nächsten Neustart bereinigt werden.

Manchmal scheint das aber nicht zu funktionieren oder sie möchten die Löschvorgänge gerne selbst kontrollieren.

Abhilfe: Intune

Wer kein lokales AD hat, sondern z.B. die Endgeräte mit Intune verwaltet, kann über die "Settings" für Windows Clients ebenfalls eine entsprechende Vorgabe machen:

Technisch setzen sowohl Gruppenrichtlinien als auch Intune einen Schlüssel in der Registrierung

Hintergrund: Profilalter

Ehe man Profile per Gruppenrichtlinie, WMI oder PowerShell löscht, müssen wir natürlich das Alter auf diesem Client ermitteln. Hierzu gibt es zwei Möglichkeiten:

  • NTFS- Dateidatum  z.B. NTUSER.DAT
    Ein Windows Profil besteht aus einem Verzeichnisbaum, in dem Windows auch die Registrierungsschlüssel wie "HKEY_CURRENT_USER" als Datei (ntuser.dat) ablegen und bei der Abmeldung werden dort Änderungen geschrieben und damit das "LastWrite"-Datum der Datei verändert. Sie können natürlich theoretisch auch nach der letzten Änderung von Verzeichnissen, Temp-Dateien etc. suchen und so einen Rückschluss auf die letzte Nutzung erhalten.
  • ProfileList
    Eleganter ist aber vermutlich die Abfrage der Einstellung in der Windows Registrierung, welche die Informationen über alle Profile zusammenhält. Hier gibt es zwei Felder "LocalProfileUnloadTimeHigh" und "LocalProfileUnloadTimeLow", die entsprechend zusammengerechnet einen Zeitstempel ergeben.

Eine Analyse des Windows Eventlogs nach "Login/Logout"-Events ist theoretisch auch noch denkbar, wenn die Events denn lange genug vorgehalten werden

Löschen per Script

Ein Profil auf einem Windows Client besteht aus dem Verzeichnis mit all den Dateien und dem Eintrag in der Registrierung, die per WMI erreichbar ist. Auf meinem Client sehe ich dazu:

Get-WmiObject -Class Win32_UserProfile| ft sid,LastUseTime

Das WMI-Objekt liefert auch noch die anderen Felder:

LastAttemptedProfileDownloadTime :
LastAttemptedProfileUploadTime   :
LastBackgroundRegistryUploadTime :
LastDownloadTime                 :
LastUploadTime                   :

Allerdings waren diese Felder bei mir immer leer und per WMI habe ich nur "LastUseTime" gefunden. Die Informationen aus der Registrierung kann ich relativ einfach ermitteln. Ich muss nur den "High"- und "Low"-Wert kombinieren und in ein Datum konvertieren lassen:

foreach ($entry in (Get-childitem "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\")) {
   [pscustomobject][ordered]@{
      SID = $entry.PSChildName
      Profilpfad = $entry.ProfileImagePath
      LastUnloadTime = [datetime]::FromFileTime(([UInt64]$entry.GetValue("LocalProfileUnloadTimeHigh") -shl 32) -bor $entry.GetValue("LocalProfileUnloadTimeLow"))
   }
}

Achtung KI!
Ich habe natürlich auch einmal Copilot befragt und die Ergebnisse waren auf der Tonspur OK, aber das Skript hätte mit alle Profile gelöscht,

Das von Copilot erzeugte Skript hat den Wert der WMI-Abfrage zu "LastUseTime" als INT64-Filedate interpretiert hat und nicht als "String". Bei der Umrechnung kam dann immer 1.1.1601 als "LastUseTime heraus.

Jeder "Mensch" interpretiert die Zahl als rückwärts geschriebenes Datum in der Form "ÝYYYMMDDhhmmss.hhhhh+zone". Testen sie daher ihre Skripte ausführlich und beim Löschen selbst müssten sie daran denken, dass sie beide Stellen bearbeiten:

  • Löschen des Profileintrags per WMI
    Damit wird der Schlüssel in der Registrierung entfernt
  • Löschen des Profilverzeichnisses
    Das betrifft dann die Dateien.

Dabei sollten Sie darauf achten, dass sie nur Profile löschen, die nicht gerade in Benutzung sind. Denken Sie dabei auch an Profile, die nach der Abmeldung nicht sofort von Windows wieder freigegeben werden. Nicht umsonst wird Microsoft eine richtlinienbasierte Löschung immer beim Neustart des Computer machen, während noch niemand angemeldet ist. Zudem sollten Sie die Systemprofile "LocalSystem", "LocalService", "NetworkService" etc. ausschließen. Entsprechende Beispiele gibt es von Microsoft und anderen Autoren.

Windows Credential Cache

Aber genaugenommen will ich das Profil gar nicht sofort löschen, sondern einfach nur sicherstellen, das gesperrter und insbesondere gelöschte Konten keinen Zugriff mehr haben. Leider hat Windows keinen Hintergrundprozess, der regelmäßig prüft, welche Profile noch zu aktiven Konten gehören und welche wirklich bereinigt werden könnten. Ich kann mir ja schon vorstellen, dass Benutzer mit mehreren Arbeitsplätzen auch nach Wochen wieder einmal zurückkommen und dann nicht unbedingt bei "Null" wieder anfangen wollten. Ich denke an Clients, die Daten in eine OST-Datei replizieren oder OneDrive nutzen etc.

Mir hätte es ja schon gereicht, Profile von im AD gelöschten Benutzern zu entfernen und den "Deaktiviert"-Status von Konten proaktiv zu übertragen. So eine Funktion gibt es in Windows allerdings nicht und wenn ich diese erzwingen müsste, dann würde ich vermutlich einen geplanten Task aufsetzen, der z.B. jede Stunde die Liste der lokalen Profile ermittelt und die Existenz der Benutzer prüft.

Leider habe ich keinen Weg gefunden, wie ich die Profile bestehen lassen könnte aber die "Cached Credentials" gezielt löschen kann
Der Speicher ist "pro Computer" und ist nicht der "Credential Manager", in dem jeder Benutzer innerhalb seiner Session weitere Anmeldeinformationen ablegen kann.

Weitere Links