Ausgangslage: Offline-Verfügbarkeit hinterlässt einen lokalen Prüfwert

Domänenmitglieder sollen auch dann benutzbar bleiben, wenn beim Anmelden kein Domain Controller erreichbar ist. Windows speichert deshalb nach erfolgreichen Online-Anmeldungen Informationen für eine begrenzte Zahl von Domänenbenutzern lokal. Meldet sich einer dieser Benutzer später ohne DC-Verbindung an, kann das Gerät das eingegebene Kennwort gegen den lokalen Prüfwert validieren und eine Offline-Sitzung öffnen.

Das ist kein im Klartext gespeichertes Domänenkennwort und auch kein normal verwendbares Netzwerk-Credential. Der Prüfwert kann nicht einfach bei einem anderen System zur Anmeldung vorgelegt werden. Er bleibt dennoch sicherheitsrelevant: Wer ein Gerät und dessen geschützte Systemdaten vollständig unter Kontrolle bringt, kann Passwortkandidaten außerhalb des AD gegen den lokalen Bestand prüfen. Kontosperren und Online-Erkennung begrenzen diesen Offline-Vorgang nicht.

Credential Guard ändert diese Bewertung nicht. Cached-Domain-Verifier gehören gerade nicht zu den wiederverwendbaren Anmeldeinformationen, die Credential Guard isoliert. BitLocker, Secure Boot, physischer Schutz und eine belastbare Gerätekonfiguration erschweren den Zugriff auf die lokalen Systemdaten, ersetzen aber keine bewusste Entscheidung über die Zahl der gespeicherten Benutzer.

Ohne explizite Richtlinie halten Member Server und Windows-Clients typischerweise Informationen für bis zu zehn unterschiedliche Domänenbenutzer vor. Der Wert beschreibt Benutzer-Slots, nicht Fehlversuche, Tage oder Passwortversionen. Wird ein weiterer Benutzer online authentifiziert und sind alle Slots belegt, wird der älteste Eintrag verdrängt. Die Einträge besitzen kein eigenes Zeitlimit.

Die Verfügbarkeitsseite ist ebenso wichtig. Ein mobiles Gerät ohne Cache und ohne Verbindung zu einem Domain Controller lässt keine Domänenanmeldung zu. Ein VPN, das erst nach der Benutzeranmeldung startet, hilft an dieser Stelle nicht. Umgekehrt kann ein vorhandener Offline-Prüfwert noch zum zuletzt auf diesem Gerät bekannten Kennwort passen, obwohl das Konto inzwischen an anderer Stelle gesperrt, deaktiviert oder das Kennwort geändert wurde. Solange das Gerät keinen DC erreicht, kennt es diesen neuen Zustand nicht.

Cached Domain Logons sind deshalb weder pauschal schlecht noch ein Komfortschalter, der überall auf dem Default bleiben sollte. Sie sind eine Abwägung zwischen lokaler Angriffsfläche, Offline-Arbeitsfähigkeit und Wiederherstellbarkeit.

Zielbild: Jeder Gerätetyp erhält nur die notwendige Offline-Reserve

Ein belastbarer Zielzustand setzt nicht denselben Wert auf die gesamte Domäne. Er ordnet die Richtlinie dem Betriebsmodell der Geräte zu:

  1. Member Server authentifizieren grundsätzlich online. Wenn DC-, DNS- und Netzwerkkonnektivität redundant ausgelegt sind, ist 0 der sinnvolle Ausgangswert. Eine Ausnahme braucht einen konkreten Recovery-Fall.
  2. Privileged Access Workstations und Tier-0-Administrationssysteme vermeiden Offline-Domänenanmeldungen. Auch hier ist 0 das Ziel, sofern ein getrennter, getesteter Wiederherstellungsweg existiert.
  3. Feste Büro-Clients erhalten 0 oder einen sehr kleinen Wert. Die Entscheidung hängt von Standortredundanz, Pre-Logon-VPN und Supportmodell ab.
  4. Mobile und echte Offline-Clients behalten eine kleine Reserve. 1 oder 2 ist häufig ein praktikabler Pilotwert. Zwei Slots verhindern beispielsweise, dass eine Wartungsanmeldung den einzigen Benutzer sofort aus dem Cache verdrängt.
  5. Geteilte, Kiosk-, VDI- und RDS-Systeme werden separat bewertet. Ein dauerhaft erreichbarer oder nicht persistenter Workload braucht meist keinen lokalen Cache; ein geteilter Offline-Laptop kann dagegen mit zwei Slots bereits zu knapp bemessen sein.
  6. Domain Controller werden nicht über diese Einstellung abgesichert. Sie halten die maßgebliche Domänendatenbank und benötigen eine eigene Tier-0-Anmelde- und Recovery-Architektur.
  7. Die Richtlinie wird per Computer-GPO und Geräteklasse verwaltet. Ein dokumentierter Owner verantwortet Zielwert, Ausnahmen, Pilot und Review.
  8. Offline-Anmeldung und Recovery werden praktisch getestet. Pre-Logon-Netzwerk, Windows LAPS für ein lokales Notfallkonto, BitLocker-Recovery und Supportverfahren sind vor der Verschärfung funktionsfähig.

Das Ziel ist nicht der niedrigste theoretisch mögliche Wert. Es ist der kleinste Wert, mit dem der jeweilige Gerätetyp auch in seinen realen Ausfallszenarien sicher betrieben und wiederhergestellt werden kann.

Umsetzung: Richtlinie, Konnektivität und Recovery gemeinsam planen

1) Wirksamen Wert und Gerätegruppen inventarisieren

Beginne mit dem effektiven Zustand auf repräsentativen Clients und Member Servern. Der Richtlinienwert landet unter Winlogon als Zeichenfolge. Die folgende Abfrage ist read-only:

Set-StrictMode -Version Latest

$winlogonPath = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon'

$policyItem = Get-ItemProperty -LiteralPath $winlogonPath -ErrorAction Stop
$cachedLogonsCount = if ($policyItem.PSObject.Properties.Name -contains 'CachedLogonsCount') {
  [string]$policyItem.CachedLogonsCount
} else {
  'Not configured'
}

[pscustomobject]@{
  ComputerName      = [Environment]::MachineName
  CachedLogonsCount = $cachedLogonsCount
}

Ein fehlender Registry-Wert bedeutet nicht automatisch 0. Er zeigt zunächst nur, dass die Einstellung an dieser Stelle nicht explizit geschrieben wurde; das Betriebssystem kann dann mit seinem Default arbeiten. Ergänze die Abfrage deshalb um Resultant Set of Policy, GPO-Verknüpfungen und die tatsächlich verwaltende Plattform. Registry Preferences, lokale Security Policy und Security-Baselines können mit einer vermeintlich eindeutigen Domänen-GPO kollidieren.

Erfasse pro Geräteklasse mindestens:

  • aktuelle und vorgesehene Zahl der Slots,
  • primäre Benutzerzahl je Gerät,
  • Standort-, LAN-, WLAN- und VPN-Verhalten vor der Anmeldung,
  • Abhängigkeit von Benutzer-VPN oder Device Tunnel,
  • lokale Recovery-Konten und deren Verwaltung,
  • BitLocker-, Secure-Boot- und Gerätezustand,
  • Support- und Wartungsanmeldungen,
  • Windows Hello for Business, Smartcard- oder andere Anmeldeverfahren,
  • maximale reale Dauer ohne DC-Verbindung.

Die konfigurierte Slotzahl verrät nicht, welche Benutzer aktuell gespeichert sind. Versuche nicht, LSA-Secrets oder Registry-Hives für ein Inventar auszulesen. Für das Projekt reichen Policy-Zustand, Geräteklasse, bekannte Anmeldeabläufe und Ereignisdaten.

2) Zielwerte anhand echter Ausfallszenarien festlegen

Für Member Server lautet die erste Frage: Warum sollte sich ein Domänenbenutzer anmelden können, wenn kein Domain Controller erreichbar ist? Ist die Antwort lediglich „für den Notfall“, fehlt meist ein belastbares Recovery-Design. Ein lokales, per Windows LAPS verwaltetes Notfallkonto oder Out-of-Band-Zugriff ist klarer als eine unbekannte Menge alter Domänen-Prüfwerte.

Bei PAWs ist die Offline-Verfügbarkeit ebenfalls nicht automatisch wichtiger als die Reduktion hochwertiger lokaler Prüfdaten. 0 passt nur, wenn die Systeme vor der Anmeldung zuverlässig einen DC erreichen und ein Ausfall nicht durch ein unsicheres Shared-Admin-Konto überbrückt wird.

Für stationäre Benutzergeräte kann 0 angemessen sein, wenn der Standort mehrere DC-/DNS-Pfade oder einen funktionierenden Pre-Logon-Tunnel besitzt. Fehlt diese Resilienz, ist 1 oder 2 oft die ehrlichere Übergangslösung. Der Wert sollte nicht aus einer allgemeinen Benchmark kopiert, sondern gegen Standortstörungen, Notebook-Docks, WLAN-Anmeldung und den tatsächlichen Helpdesk-Prozess getestet werden.

Mobile Geräte benötigen regelmäßig Offline-Anmeldung. Ein Wert von 2 ist ein brauchbarer Startpunkt, aber kein Naturgesetz. Geräte mit wechselnden Benutzern, Schichtbetrieb oder Vor-Ort-Support brauchen eventuell mehr Slots oder ein anderes Gerätemodell. Ein persönlich zugewiesener Laptop benötigt dagegen selten zehn gespeicherte Domänenidentitäten.

Behandle Authentifizierungsverfahren getrennt. CachedLogonsCount steuert zwischengespeicherte Domänenkontoinformationen für die Offline-Anmeldung. Die Einstellung löscht keine lokalen Konten, Windows-Vault-Einträge, Browser-Passwörter, Service-Credentials oder bereits aktive Sitzungen. Auch Windows Hello for Business hat ein eigenes Schlüssel- und Vertrauensmodell; sein Online- und Offline-Verhalten muss im eingesetzten Trust-Modell getestet werden.

3) Separate Computer-GPOs statt globaler Default-Änderung einsetzen

Die Einstellung liegt unter:

Computerkonfiguration
  Richtlinien
    Windows-Einstellungen
      Sicherheitseinstellungen
        Lokale Richtlinien
          Sicherheitsoptionen
            Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen
            (für den Fall, dass kein Domänencontroller verfügbar ist)

Zulässig sind Werte von 0 bis 50; 0 deaktiviert die Offline-Anmeldung über diesen Cache. Für den unterstützten Security-Policy-/GPO-Pfad ist kein Neustart vorgeschrieben. Direkte Registry-Änderungen werden in Microsofts Betriebsdokumentation abweichend behandelt und sollten nicht der Produktionsweg sein. Validiere den effektiven Zustand nach GPO-Verarbeitung trotzdem mit einem vollständigen Neustart sowie einer frischen Online- und Offline-Anmeldesequenz.

Lege dedizierte GPOs für klar getrennte Gerätepopulationen an, zum Beispiel:

  • Member Server und PAWs: Zielwert 0,
  • feste Standard-Clients: Pilotwert 0, 1 oder 2 nach Standortdesign,
  • mobile Standard-Clients: Pilotwert 2,
  • begründete Spezialgeräte: dokumentierter eigener Wert.

Verändere dafür nicht die Default Domain Policy. Nutze stabile OUs oder kontrollierte Sicherheitsfilterung und halte pro Gerät nur eine führende Einstellung. Eine zusätzliche Registry Preference für CachedLogonsCount macht das Ergebnis schwerer nachvollziehbar und sollte entfernt werden, sobald die Security Policy führend ist.

4) Anmelde- und Recovery-Pfade vor dem Rollout herstellen

Ein Zielwert von 0 verlangt DC-Erreichbarkeit vor der Domänenanmeldung. Prüfe deshalb DNS, Zeit, Zertifikate, Netzwerkzugang und Authentifizierung als durchgehenden Pfad. Bei entfernten Geräten braucht es je nach Architektur einen Always-On-VPN-Device-Tunnel, eine unterstützte Pre-Logon-VPN-Lösung oder eine andere Verbindung, die nicht erst von der Benutzersitzung abhängt.

Ein Benutzer-VPN, das nach dem Desktopstart aufgebaut wird, kann keine Anmeldung ermöglichen, die bereits am fehlenden Cache scheitert. Ebenso kann ein frisch bereitgestelltes Gerät einen Benutzer nicht offline anmelden, bevor dessen Domänenidentität mindestens einmal erfolgreich online validiert wurde.

Plane einen getrennten lokalen Wiederherstellungsweg. Ein per Windows LAPS verwaltetes lokales Administratorkonto ist für viele Clients und Member Server geeigneter als dauerhaft zwischengespeicherte privilegierte Domänenkonten. Sein Kennwort bleibt geschützt, wird nach Nutzung rotiert und seine Verwendung überwacht. Das Konto ist kein täglicher Supportzugang und ersetzt keine Netzwerkwiederherstellung.

Der Rollback-Pfad muss offline funktionieren. Eine korrigierende GPO hilft einem ausgesperrten Gerät erst, nachdem es wieder einen Domain Controller erreicht. Halte deshalb für Pilotgeräte eine praktisch getestete Methode für lokalen Zugriff, Netzwerk-Recovery oder Out-of-Band-Verwaltung bereit.

5) Offline-Anmeldung mit einer festen Testmatrix prüfen

Teste nicht nur, ob sich der Hauptbenutzer nach dem Change noch anmelden kann. Eine belastbare Matrix enthält mindestens:

  1. bekannte Benutzeranmeldung mit erreichbarem DC,
  2. erneute Anmeldung desselben Benutzers ohne Netzwerk,
  3. Anmeldung eines Benutzers ohne vorhandenen Cache,
  4. Wartungsanmeldung und anschließende Offline-Anmeldung des Gerätebesitzers,
  5. Kennwortänderung auf einem anderen System und Offline-Anmeldung mit altem sowie neuem Kennwort im isolierten Test,
  6. gesperrtes oder deaktiviertes Testkonto ohne DC-Verbindung,
  7. erster Benutzer-Logon auf einem neu bereitgestellten Gerät,
  8. Pre-Logon-VPN bei Ausfall eines Gateways oder Domain Controllers,
  9. lokaler LAPS-Recovery und Rückkehr zur normalen Domänenanmeldung,
  10. Windows Hello-, Smartcard- und Passwortpfad, soweit sie eingesetzt werden.

Diese Tests gehören in ein Lab oder einen eng begrenzten Pilot. Insbesondere Konto-Deaktivierung und Passwortwechsel dürfen nicht mit produktiven Identitäten improvisiert werden.

Security Event 4624 mit Logon Type 11 kennzeichnet eine erfolgreiche CachedInteractive-Anmeldung. Das Ereignis ist ein gutes Signal für Offline-Nutzung, aber kein vollständiger Echtzeitnachweis: Ein getrenntes Gerät kann seine Logs erst später an die zentrale Sammlung liefern. LsaSrv Event 45058 kann zusätzlich melden, dass beim Belegen eines Slots ein älterer Eintrag verdrängt wurde, sollte aber nicht als Benutzerinventar missverstanden werden.

Baseliniere, welche Geräteklassen Type 11 tatsächlich erzeugen. CachedInteractive auf einem mobilen Laptop kann erwartet sein; auf einem Tier-0-Adminsystem oder Member Server ist es ein Prüfgrund. Alarmiere risikobasiert nach Gerätetyp, Konto und Häufigkeit, nicht pauschal auf jedes einzelne Ereignis.

6) In Ringen ausrollen und Drift dauerhaft kontrollieren

Starte mit IT- und Security-Geräten, die das Zielmodell repräsentieren, aber schnell lokal wiederhergestellt werden können. Der Pilot muss mindestens einen realen Remote-, Standort- oder VPN-Ausfall abdecken. Erst danach folgen repräsentative Fachbereiche, Außenstellen und mobile Populationen.

Ändere nicht gleichzeitig VPN-Client, Anmeldeverfahren, Gerätezertifikate und Cache-Policy. Sonst ist bei einem Fehler weder Ursache noch Rückfallweg klar. Halte die zuletzt funktionierende GPO gesichert und dokumentiere, wie ein Offline-Gerät wieder Verbindung erhält.

Überwache nach dem Rollout:

  • effektiven CachedLogonsCount gegen den Sollwert der Geräteklasse,
  • Type-11-Anmeldungen auf Servern, PAWs und festen Clients,
  • Geräte ohne aktuellen GPO- oder MDM-Check-in,
  • Ausnahmen ohne Owner oder Ablaufdatum,
  • Helpdesk-Fälle nach Kennwortänderungen und längerer Offline-Zeit,
  • Änderungen am VPN-, Provisioning- oder Recovery-Verfahren.

Die Richtlinie ist Teil des Geräte-Lebenszyklus. Neue Laptop-Klassen, Shared Devices, Standortschließungen oder ein Wechsel des VPN-Produkts können die richtige Slotzahl verändern. Ein jährlicher Review reicht nur, wenn solche Architekturänderungen in den Security-Change-Prozess einfließen.

Vorteile

  • Weniger lokale Passwort-Prüfwerte: Eine kleine Slotzahl reduziert die Menge an Domänenidentitäten, die auf einem verlorenen oder vollständig kompromittierten Gerät offline geprüft werden könnten.
  • Kein Offline-Domänenlogon auf Always-on-Systemen: Mit 0 akzeptieren Server, PAWs und feste Clients keine zwischengespeicherte Domänenanmeldung, wenn der DC-Pfad fehlt.
  • Kleinere Wirkung veralteter Kontozustände: Weniger gespeicherte Benutzer bedeuten weniger Fälle, in denen ein Gerät ohne DC noch einen alten lokalen Kenntnisstand verwendet.
  • Explizite Verfügbarkeitsarchitektur: VPN, DC-Erreichbarkeit und lokaler Recovery werden zu geplanten Abhängigkeiten statt stillen Annahmen.
  • Messbarer Zustand: Policy-Wert, Geräteklasse, Type-11-Nutzung und Ausnahmen lassen sich als Compliance-Daten auswerten.
  • Erhält mobile Arbeitsfähigkeit: Ein kleiner, bewusst gewählter Cache kann Offline-Arbeit ermöglichen, ohne den Default von zehn Benutzern überall beizubehalten.

Nachteile und Grenzen

  • Aussperrungen sind möglich: Ein zu kleiner oder auf 0 gesetzter Wert blockiert Domänenbenutzer, wenn kein DC vor der Anmeldung erreichbar ist.
  • Remote-Recovery ist anspruchsvoll: Eine nachgelagerte Benutzer-VPN-Verbindung oder Notfall-GPO hilft nicht, wenn die Anmeldung bereits vorher scheitert.
  • Der verbleibende Cache bleibt angreifbar: 1 oder 2 reduziert die Menge, macht schwache Domänenkennwörter aber nicht sicher.
  • Keine sofortige Offline-Sperrwirkung: Ein Gerät ohne DC kennt eine spätere Kontosperre, Deaktivierung oder Kennwortänderung zunächst nicht.
  • Kein allgemeiner Credential-Schutz: Die Einstellung erfasst weder aktive Sessions noch lokale Konten, Service-Secrets, Vault-Inhalte oder Browser-Credentials.
  • Credential Guard deckt diesen Prüfwert nicht ab: Der lokale Verifier ist kein wiederverwendbares Netzwerk-Credential und bleibt eine separate Schutzentscheidung.
  • Andere Anmeldeverfahren brauchen eigene Tests: Windows Hello, Smartcard und hybride Trust-Modelle lassen sich nicht allein aus CachedLogonsCount ableiten.
  • Telemetrie kommt verzögert: Offline-Geräte liefern ihre Anmeldeereignisse erst nach erneuter Verbindung.
  • Slots haben kein Ablaufdatum: Die Policy begrenzt die Zahl eindeutiger Benutzer, nicht die Lebensdauer eines Eintrags.

Typische Stolperfallen

  • Domänenweit blind 0 setzen: Mobile Benutzer und Außenstellen werden ausgesperrt, bevor ein Pre-Logon-Pfad bereitsteht.
  • Den Default von zehn als Sicherheitsentscheidung behandeln: Ein Betriebssystem-Default ist kein begründeter Zielwert für jede Geräteklasse.
  • Slots mit Fehlversuchen oder Tagen verwechseln: Der Wert zählt unterschiedliche Benutzer und definiert keine Sperre oder Ablaufzeit.
  • Kennwortänderungen sofort offline erwarten: Der lokale Prüfwert wird erst bei einer erfolgreichen Online-Authentifizierung dieses Benutzers auf dem Gerät aktualisiert.
  • Deaktivierte Konten als sofort blockiert betrachten: Ohne DC-Verbindung kann das Gerät den neuen Kontostatus nicht validieren.
  • Auf ein Post-Logon-VPN vertrauen: Es startet zu spät, um eine durch 0 verhinderte Anmeldung zu retten.
  • Keinen lokalen Recovery-Pfad testen: Die korrigierende GPO ist für ein vollständig offline ausgesperrtes Gerät nicht erreichbar.
  • Privilegierte Domänenkonten als Recovery nutzen: Dadurch werden gerade die hochwertigen Identitäten lokal vorgehalten, die das Hardening reduzieren soll.
  • Security Policy und Registry Preference parallel setzen: Zwei Quellen erzeugen Drift und erschweren die Ursachenanalyse.
  • Nur den Hauptbenutzer testen: Support-, Shared-Device-, Provisioning- und Kennwortwechsel-Szenarien bleiben unentdeckt.
  • Credential Guard als vollständige Abdeckung annehmen: Cached-Domain-Verifier gehören nicht zu seinen geschützten, wiederverwendbaren Credentials.
  • Aktuelle Cache-Benutzer aus Secrets auslesen wollen: Das schafft unnötigen Zugriff auf sensitive Systemdaten und ist für die Policy-Steuerung nicht erforderlich.
  • Rollback nur als GPO-Link dokumentieren: Ein Gerät ohne DC kann diese Änderung nicht abrufen.

Projekt-Checkliste

  • [ ] Clients, PAWs, Member Server, Shared Devices, VDI/RDS, Kiosks und mobile Geräte getrennt klassifizieren.
  • [ ] Effektiven CachedLogonsCount, GPO-Quelle und lokale Abweichungen je Geräteklasse erfassen.
  • [ ] Fehlende Registry-Werte nicht automatisch als 0 bewerten.
  • [ ] Primäre Benutzerzahl, Wartungsanmeldungen und echte Offline-Dauer dokumentieren.
  • [ ] DC-, DNS-, Zeit- und Netzwerkpfad vor der Anmeldung prüfen.
  • [ ] Benutzer-VPN von Device-Tunnel oder Pre-Logon-VPN klar unterscheiden.
  • [ ] Member Server und PAWs mit Zielwert 0 bewerten.
  • [ ] Feste Clients je Standort auf 0, 1 oder 2 pilotieren.
  • [ ] Mobile persönliche Geräte mit kleinem Wert, typischerweise 1 oder 2, testen.
  • [ ] Shared Devices anhand ihrer realen Benutzerzahl separat dimensionieren.
  • [ ] Separate Computer-GPOs anlegen; Default Domain Policy unverändert lassen.
  • [ ] Registry Preferences oder lokale Policies mit konkurrierendem Wert bereinigen.
  • [ ] BitLocker, Secure Boot und Gerätezustand als ergänzende Kontrollen verifizieren.
  • [ ] Lokales Recovery-Konto mit Windows LAPS absichern und Nutzung überwachen.
  • [ ] Pre-Logon-Netzwerk und Recovery bei DC-/VPN-Ausfall praktisch testen.
  • [ ] Ersten Online-Logon neu bereitgestellter Geräte berücksichtigen.
  • [ ] Passwortwechsel, Kontosperre und Deaktivierung mit Testkonten im Offline-Fall prüfen.
  • [ ] Windows Hello-, Smartcard- und Passwortanmeldung im eingesetzten Trust-Modell testen.
  • [ ] Event 4624 / Logon Type 11 zentral erfassen und nach Geräteklasse baselinen.
  • [ ] Server- und PAW-Nutzung von CachedInteractive als Prüfgrund behandeln.
  • [ ] Rollout in kleinen Ringen mit lokal wiederherstellbaren Piloten durchführen.
  • [ ] VPN-, Zertifikats- und Cache-Änderungen nicht im selben ersten Change bündeln.
  • [ ] Last-known-good-GPO sowie Offline-Recovery-Verfahren dokumentieren und testen.
  • [ ] Ausnahmen mit Owner, Begründung, Zielwert und Ablaufdatum führen.
  • [ ] Policy-Drift, Offline-Clients und Helpdesk-Fälle nach dem Rollout überwachen.
  • [ ] Zielwerte bei Änderungen an Gerätetyp, Standort, VPN oder Provisioning erneut bewerten.