Domaenenanmeldung im Cache pruefen: REG_SZ und Offlinezugriff

Was bedeutet es, die Domaenenanmeldung im Cache zu pruefen?

Domaenenanmeldung im Cache pruefen bedeutet, drei Belege auf derselben Pilotarbeitsstation miteinander abzugleichen: die angewendete Computerrichtlinie, den lokalen Registrierungswert samt Typ und eine beobachtete Offlineanmeldung. Ein Befund auf Richtlinienebene stößt diese Untersuchung an. Er identifiziert weder ein privilegiertes Konto im Cache noch beweist er, dass die Arbeitsstation kompromittiert wurde.

Microsoft dokumentiert CachedLogonsCount unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon als REG_SZ. Die Referenz zu zwischengespeicherten Domänenanmeldungen erklärt, dass null die Zwischenspeicherung deaktiviert und direkte Änderungen an diesem Registrierungsschlüssel einen Neustart erfordern. Die gesonderte Neustartvorgabe für die Security Option wird im Abschnitt zur Behebung behandelt. Diese Details sind relevant, wenn ein Audit-Collector einen anderen Registrierungstyp erwartet oder den Bereitstellungsweg der Richtlinie nicht erfasst.

Das praktische Ergebnis ist ein Entscheidungsprotokoll: welches Gerät geprüft wurde, was es erlauben soll, was tatsächlich beobachtet wurde und wer eine verbleibende Ausnahme akzeptiert hat. Das folgende Verfahren ist ein vorgeschlagener Prüfablauf, kein Bericht über Tests in einer produktiven Domäne. Quellen und Detektorverhalten wurden am 6. Oktober 2026 geprüft; für diesen Artikel wurde weder eine Windows-Anmeldung durchgeführt noch ein Behebungsbefehl ausgeführt.

Funktionsweise: Richtlinie, Typ und Verfügbarkeit getrennt betrachten

Verwenden Sie drei Belegebenen mit jeweils eigenen Schlussfolgerungen:

Die ersten beiden Ebenen sind Konfigurationsbeobachtungen. Die dritte ist eine Verhaltensbeobachtung mit einer bestimmten Identität, einem bestimmten Rechner und Zeitpunkt. Behalten Sie diese Einschränkungen in der abschließenden Aussage bei. Ein erfolgreicher Test auf einem Laptop deckt nicht jeden Laptop in dessen OU ab. Ein fehlgeschlagener Test benötigt eine Erklärung, bevor er eine Änderungsentscheidung stützen kann.

Unser Leitfaden zur RDP-Härtung trennt Entscheidungen zu NLA, Sicherheitsschicht und Anmeldeinformationsdelegierung. Er behandelt bereits Einstellungen für zwischengespeicherte Anmeldungen neben diesen Kontrollen. Dieser Ablauf ergänzt die Belege, die benötigt werden, wenn der Befund zu zwischengespeicherten Anmeldungen von der Endpunktkonfiguration abweicht; er wiederholt nicht den umfassenderen RDP-Konfigurationsleitfaden.

Betrachten Sie auch die Isolation von Anmeldeinformationen separat. Der Leitfaden zu Credential Guard nach einem Upgrade prüft übernommene Ausnahmen und den laufenden Dienst. Nutzen Sie diese Untersuchung für die zugehörige Frage zum Schutzstatus. Weder das Auslesen des Registrierungswerts für zwischengespeicherte Anmeldungen noch der unten beschriebene Detektor misst den Laufzeitstatus von Credential Guard.

Zuerst den Piloten und das erforderliche Verhalten festlegen

Benennen Sie vor der Belegerfassung den Verantwortlichen des Piloten und den Benutzerablauf, der Offlinezugriff erfordert. Beschreiben Sie das erwartete Ergebnis in betrieblichen Begriffen: etwa ob ein benannter, nicht privilegierter Testbenutzer bei einer geplanten Unterbrechung der Domänenverbindung den lokalen Desktop erreichen muss. Das ist ein organisationsspezifisches Abnahmekriterium, keine allgemeine Cache-Quote von Microsoft oder ANSSI.

Dokumentieren Sie die Änderungsbefugnis, das Wartungsfenster, den Ansprechpartner für die Wiederherstellung und das Prüfdatum. Wenn keine Offlineanforderung vereinbart wurde, darf die Meldung des Detektors nicht stillschweigend zur Anforderung werden. Lassen Sie den zuständigen Verantwortlichen das gewünschte Verhalten festlegen, bevor Sie einen Wert vorschlagen.

Überprüfung: Angewendete GPO und lokale REG_SZ abgleichen

Schritt 1: Den Bericht zu den resultierenden Computerrichtlinien erfassen

Verwenden Sie auf dem Piloten die dokumentierte gpresult-Syntax und ihre Ausgabeoptionen. Diese lokalen Befehle passen die Syntax an den Computerbereich an; führen Sie jeden einzeln in einer autorisierten Windows-Eingabeaufforderung aus:

gpresult /scope computer /r

gpresult /scope computer /h cached-logon-computer-policy.html

Der erste Befehl liefert zusammengefasste Daten; der zweite speichert einen HTML-Bericht. Für ARM64 Windows gibt Microsoft an, dass die Option /h die ausführbare Datei gpresult in SysWow64 benötigt. Der relative Dateiname ist ein Beispiel: Wählen Sie für die tatsächliche Prüfung das freigegebene Belegverzeichnis. Bewahren Sie die Computeridentität und den Erfassungszeitpunkt des Berichts auf und prüfen Sie anschließend die verfügbaren einstellungsspezifischen Belege. Eine Liste angewendeter GPO-Namen ist hilfreicher Kontext, identifiziert für sich genommen jedoch nicht den wirksamen Wert dieser Security Option.

Bewahren Sie für die relevante GPO den Namen, die GUID, die Version und die genaue Einstellung für zwischengespeicherte Anmeldungen aus den Verwaltungsbelegen auf. Vergleichen Sie diese mit den Informationen zu den resultierenden Richtlinien des Piloten. Wenn der Bericht die Herkunft der Einstellung nicht belegt, dokumentieren Sie diese als ungeklärt und beschaffen Sie einstellungsspezifische Belege, bevor Sie entscheiden, welche Richtlinie geändert werden soll.

Prüfen Sie in der relevanten GPO Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf und, falls vorhanden, den Eintrag unter [Registry Values]. Bewahren Sie nur den einstellungsspezifischen Auszug und die für diese Prüfung benötigte Richtlinienidentität auf. Anlass für diese Prüfung ist die unten erläuterte, dokumentierte Erfassungslücke des Collectors beim Standardweg. Eine SYSVOL-Deklaration muss weiterhin mit dem Piloten abgeglichen werden; ersetzen Sie Belege zur angewendeten Richtlinie nicht durch die Deklaration einer unbeteiligten GPO.

Schritt 2: Den lokalen Wert auslesen, ohne seinen Typ zu verbergen

Verwenden Sie die Referenz zu reg query mit dem dokumentierten Winlogon-Pfad und Wertnamen:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount

Dies ist eine Anpassung der Syntax für einen ausschließlich lesenden Zugriff, kein aus einem ausgearbeiteten Microsoft-Beispiel übernommener Befehl. Prüfen Sie den zurückgegebenen Wertnamen, Typ und die Daten. Für die dokumentierte Konfiguration sind die Typbezeichnung REG_SZ und der konfigurierte numerische Text zu erwarten. Filtern Sie die Abfrage nicht auf DWORD: Das würde genau die untersuchte Typabweichung verbergen.

Speichern Sie die tatsächliche Ausgabe zusammen mit dem Richtlinienbericht. Wenn der Wert fehlt, der Typ abweicht, der Zugriff scheitert oder die Ausgabe von einem anderen Host stammt, kennzeichnen Sie diese Beobachtung ausdrücklich. Keines dieser Ergebnisse erlaubt es, aus einer Auditmeldung einen lokalen Wert von zehn zu konstruieren.

Erstellen Sie für den Piloten eine Abgleichszeile mit der gemeldeten Richtlinienquelle, den GptTmpl.inf-Belegen, dem lokalen Typ und den Daten, dem Erfassungszeitpunkt und dem Neustartkontext. Weisen Sie Abweichungen einen Verantwortlichen und eine nächste Maßnahme zu. Beispielsweise deutet eine dokumentierte REG_SZ mit dem Wert null bei fortbestehendem Befund auf die Einschränkung des Collectors hin; sie ist kein Grund, den Arbeitsstationswert als DWORD neu zu schreiben, damit das Audit verstummt.

Erkennung: LsaSrv 45058 bewahren und Offlineanmeldung testen

Microsofts Artikel zur Fehlerbehebung bei LsaSrv 45058 beschreibt ein informatives Ereignis im System-Protokoll, das die Verdrängung des ältesten zwischengespeicherten Benutzereintrags bei Erreichen der Quote erfasst. Das Ereignis identifiziert den entfernten Benutzer und den Zeitstempel des Eintrags. Es liefert hilfreichen Kontext für eine fehlgeschlagene Offlineanmeldung; es belegt keinen Diebstahl von Anmeldeinformationen.

Wenn das Ereignis im relevanten Zeitraum vorhanden ist, bewahren Sie Ereigniszeit, Computer, Quelle, Ereignis-ID, entfernte Testidentität und Eintragszeitstempel auf. Korrelieren Sie es mit der Anmeldezeitleiste des Piloten. Wenn Erfassung oder Aufbewahrung unvollständig sind, dokumentieren Sie diese Lücke. Behandeln Sie das Fehlen eines beobachteten Ereignisses als Beleggrenze, nicht als vollständiges Inventar zwischengespeicherter Identitäten.

Schritt 3: Eine nicht privilegierte Identität verwenden und Bedingungen dokumentieren

Wählen Sie eine dedizierte, nicht privilegierte Domänentestidentität, deren Verantwortlicher die Übung autorisiert. Dokumentieren Sie, wie das Fehlen privilegierter Zugriffsrechte im Kontenprüfprozess der Organisation überprüft wurde. Verwenden Sie keinen privilegierten Administrator, nur weil der Titel des Detektors privilegierte Konten erwähnt.

Planen Sie einen Anmeldetest an der lokalen Konsole mit einem freigegebenen Wiederherstellungsweg. Dokumentieren Sie den Online-Ausgangszustand, die kontrollierte Netzwerkbedingung, wie die Erreichbarkeit von Domänencontrollern ausgeschlossen wurde, die Anmeldemethode und das genaue beobachtete Ergebnis. Stellen Sie die Verbindung nach der Übung wieder her. Wenn sich die Netzwerkbedingung des Tests nicht belegen lässt, melden Sie das Ergebnis als nicht schlüssig.

Die Ergebnisaussage sollte eng gefasst sein: Die benannte Testidentität hat unter den angegebenen Bedingungen auf dem benannten Piloten den Desktop erreicht oder nicht erreicht. Microsoft weist gesondert darauf hin, dass Offlinezugriff auf den Desktop keinen Zugriff auf Ressourcen ermöglicht, die eine Domänenvalidierung erfordern. Melden Sie den Desktop-Erfolg nicht als erfolgreichen Zugriff auf Domänendienste.

Wenn eine Verdrängung untersucht werden muss, verwenden Sie ein beobachtetes 45058-Ereignis für die Testidentität oder eine separat freigegebene Laborübung. Wechseln Sie nicht gezielt zwischen Produktionskonten, nur um ein Ereignis zu erzwingen. Dokumentieren Sie „Verdrängung nicht beobachtet“, wenn dies der verfügbaren Beleglage entspricht. Dieses Protokoll benötigt weder einen Cache-Dump noch einen Verifier-Export, eine Extraktion von Registry-Hives oder eine Passwortwiederherstellung.

Schritt 4: Die Entscheidung vor der Änderung der Einstellung dokumentieren

Ein hilfreiches Prüfprotokoll kann diese Vorlage verwenden:

Stellen Sie am Prüfgate drei ausdrückliche Fragen: Welcher Pilot und welche Offlineeinschränkung rechtfertigen eine Ausnahme? Welche GptTmpl.inf/REG_SZ-Belege und resultierende GPO sind aufzubewahren, wenn der Befund vom lokalen Zustand abweicht? Welche nicht privilegierte Identität kann das relevante Verhalten demonstrieren, ohne Geheimnisse zu verarbeiten? Benennen Sie den Entscheidungsverantwortlichen, statt diese Fragen unausgesprochen zu lassen.

Behebung: Entscheidung umsetzen und Pilotprüfung wiederholen (Remediation)

Wenn die freigegebene Entscheidung eine Änderung der Zwischenspeicherung vorsieht, verwenden Sie die im Microsoft-Artikel zu 45058 genannte Security Option: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options, anschließend Interactive logon: Number of previous logons to cache (in case domain controller is not available). Begrenzen Sie die Änderung auf die vorgesehenen Geräte.

Für die Entscheidung, die Zwischenspeicherung zu deaktivieren, dokumentiert Microsoft null als deaktivierenden Wert. Eine Ausnahme, bei der die Zwischenspeicherung erhalten bleibt, benötigt eine eigene Begründung durch den Arbeitsablauf, einen Verantwortlichen und ein Prüfdatum. Machen Sie weder das globale Maximum des Detektors noch seine Meldung zum Standardwert zehn oder eine informative Verdrängung zu einer allgemein akzeptablen Quote.

Microsofts Referenz zur Security Option erklärt, dass Richtlinienänderungen ohne Neustart wirksam werden, wenn sie lokal gespeichert oder über Group Policy verteilt werden. Der Artikel zur Fehlerbehebung in der Registrierung verlangt separat einen Neustart bei direkten Änderungen am Registrierungsschlüssel. Dokumentieren Sie den verwendeten Konfigurationsweg und befolgen Sie dessen dokumentierte Neustartvorgabe. Wiederholen Sie nach dem Wirksamwerden der Änderung denselben Richtlinienbericht, dieselbe lokale Typ- und Wertabfrage sowie den kontrollierten Pilottest. Vergleichen Sie Gleiches mit Gleichem: dieselben Belegebenen und dasselbe Abnahmekriterium. Bewahren Sie ungeklärte Unterschiede auf, statt das Protokoll allein deshalb zu schließen, weil das Audit keine Meldung mehr ausgibt.

Bei einem von Verdrängung betroffenen Benutzer besteht Microsofts dokumentierte Wiederherstellung darin, die Verbindung zu Domänencontrollern und die Namensauflösung wiederherzustellen und eine authentifizierte Domänenanmeldung abzuschließen; die erneute Zwischenspeicherung setzt voraus, dass die Zwischenspeicherung aktiviert ist. Trennen Sie die Wiederherstellung von einer Richtlinienentscheidung zur Erhöhung der Quote. Eine wiederhergestellte Benutzersitzung rechtfertigt für sich genommen keine Konfigurationsänderung für den gesamten Gerätebestand.

Wie EtcSec dies erkennt

Die etc-collector-Prüfung BP039_PRIV_ACCOUNTS_CACHED von EtcSec, gelesen am Commit bcd03c54, untersucht erfasste GPO-Registrierungseinstellungen. Jeder beobachtete CachedLogonsCount-Wert null in einer beliebigen GPO unterdrückt den Befund. Andernfalls liefert sie einen Befund mittleren Schweregrads mit Count=1, auch wenn kein GPO-Wert erfasst wurde. Ihr Wert worstSeen ist das Maximum über die erfassten GPOs, nicht die resultierende Richtlinie jeder Arbeitsstation.

Der Provider befüllt dieses Feld aus Registry.pol mithilfe von getDWORDValue, das REG_DWORD akzeptiert. Microsoft dokumentiert die tatsächliche Einstellung als REG_SZ. Der GptTmpl.inf-Parser befüllt CachedLogonsCount nicht aus [Registry Values]. Der Code des Detektors selbst erklärt, dass der Standardweg der Security Option deshalb unsichtbar bleiben und einen Fehlalarm erzeugen kann.

Zwei Folgen gehören ins Prüfprotokoll. Ein Wert null über den Standardweg kann mit einem Befund einhergehen; umgekehrt kann ein in einer anderen GPO beobachteter Wert null den Befund unterdrücken, ohne die Abdeckung des Piloten zu belegen. Der Verweis der Meldung bei fehlendem Wert auf den Windows-Standardwert zehn ist eine Schlussfolgerung dieser Meldung, keine gemessene lokale Einstellung.

Diese Prüfung beobachtet weder ein bestimmtes zwischengespeichertes Konto noch dessen wirksame Privilegien, eine Kompromittierung, LsaSrv-Ereignisse, Offlineanmeldeverhalten oder den Laufzeitstatus von Credential Guard. Behandeln Sie sie als Aufforderung, die Konfiguration über den richtigen Weg zu prüfen. Schließen Sie die Pilotprüfung mit den Richtlinienbelegen, der lokalen REG_SZ-Beobachtung, dem Verhaltensergebnis und der autorisierten Entscheidung ab; halten Sie jede nicht gemessene Abdeckung des Gerätebestands sichtbar.