Credential Guard nach Upgrade deaktiviert: Prüfen und beheben

Credential Guard nach Upgrade deaktiviert: Was bedeutet das?

Wenn Credential Guard nach einem Upgrade deaktiviert ist, kann dies auf einer geerbten Konfiguration beruhen, selbst bei einer Windows-Version, die die Funktion standardmäßig aktiviert. Ein Upgrade auf einem berechtigten Gerät hebt eine frühere ausdrückliche Entscheidung zur Deaktivierung nicht auf. Bevor Sie ein aktuelles Betriebssystem als Nachweis für den Schutz von Anmeldeinformationen betrachten, prüfen Sie Edition, Bereitstellungsverlauf, Richtlinien und laufende Dienste des Computers. Microsoft dokumentiert diese fortbestehende Ausnahme in seiner Konfigurationsanleitung.

Credential Guard isoliert ausgewählte Domänengeheimnisse mithilfe virtualisierungsbasierter Sicherheit (VBS). In der Praxis müssen Sie feststellen, ob diese Isolation auf den Geräten läuft, an denen sich Domänenbenutzer anmelden. Eine Bereitstellungsrichtlinie und ein erfolgreiches Betriebssystem-Upgrade beantworten andere Fragen als eine Laufzeitprüfung.

Diese Anleitung gibt die Microsoft-Learn-Seiten wieder, die am 3. Oktober 2026 geprüft wurden. Sie behandelt berechtigte Windows-11-Geräte ab Version 22H2 und berechtigte Windows-Server-2025-Domänenmitglieder. Die folgenden Befehle stammen aus der Dokumentation; sie wurden für diesen Artikel nicht in einer Windows-Umgebung ausgeführt. Es wird keine Aussage über die Verbreitung geerbter Ausnahmen getroffen.

Wie die standardmäßige Aktivierung funktioniert

Microsofts Übersicht zu Credential Guard beschreibt die standardmäßige Aktivierung ab Windows 11 22H2 und Windows Server 2025. Die Einleitung bezieht sie auf berechtigte, einer Domäne beigetretene Systeme, die keine Domänencontroller sind; die Windows-spezifischen Bedingungen nennen Lizenzierung, Hardware-/Softwarevoraussetzungen und das Fehlen einer ausdrücklichen Deaktivierung. Behalten Sie diese Einschränkungen bei der Überprüfung einer AD-Geräteflotte bei.

Für den historischen Pro-Fall nennt Microsoft HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\IsolatedCredentialsRootSecret als zu prüfenden Registrierungsindikator. Er kennzeichnet diesen Verlauf; er misst die Isolation nicht im laufenden Betrieb. Die Lizenzierungstabelle gewährt Pro, Pro Education oder SE nicht dieselbe Berechtigung wie Enterprise und Education. Microsoft-Übersicht

Auch die Hardwarevoraussetzungen müssen geprüft werden. Die Übersicht nennt VBS und Secure Boot für den Schutz und empfiehlt TPM, ohne TPM zu einer pauschalen Voraussetzung für Credential Guard zu machen. Sie weist gesondert darauf hin, dass VBS auch ohne Secure Boot einen laufenden Zustand erreichen kann. Bewahren Sie diese Unterscheidung: Ein laufender VBS-Dienst allein bestätigt nicht die vorgesehenen Plattformschutzmaßnahmen. Die VBS-Plattformdokumentation erläutert Virtualisierungserweiterungen, SLAT sowie Firmware-/DMA-Anforderungen.

Warum eine ausdrückliche Deaktivierung das Upgrade übersteht

Microsoft erklärt, dass ausdrücklich konfigurierte Werte die standardmäßige Aktivierung nach einem Neustart übersteuern. Ein vor einem Upgrade ausdrücklich deaktiviertes Gerät bleibt danach deaktiviert. Das Upgrade ist deshalb ein sinnvoller Prüfzeitpunkt, aber keine Behebung einer alten Ausnahme. Credential Guard konfigurieren

Prüfen Sie LsaCfgFlags sowohl unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa als auch unter HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard. Microsoft dokumentiert 0 für die ausdrückliche Deaktivierung, 1 für die Aktivierung mit UEFI-Sperre und 2 für die Aktivierung ohne Sperre. Prüfen Sie in der GPO Computerkonfiguration → Administrative Vorlagen → System → Device Guard → Virtualisierungsbasierte Sicherheit aktivieren, einschließlich der darin enthaltenen Credential-Guard-Konfiguration. Microsoft-Verfahren für Konfiguration und Deaktivierung

Eine Ausnahme kann wegen einer tatsächlichen Anwendungsabhängigkeit eingeführt worden sein. Microsofts bekannte Probleme behandeln Single Sign-on mit MS-CHAPv2/NTLMv1, gespeicherte CredSSP-Anmeldeinformationen und CredSSP-basierte Hyper-V-Livemigration. Ermitteln Sie, welcher Ablauf die Ausnahme ursprünglich erforderte, ob sie weiterhin nötig ist und wer die Entscheidung verantwortet. Gehen Sie weder davon aus, dass die Ausnahme weiterhin erforderlich ist, noch davon, dass sie ohne Tests entfernt werden kann.

Die Angriffskette: Was fehlende Isolation verändert

Ohne die Isolation von Credential Guard kann eine lokale Kompromittierung mit ausreichenden Berechtigungen die auf dem Host vorhandenen Domänengeheimnisse für den Diebstahl aus LSASS leichter zugänglich machen. Wenn Credential Guard läuft, werden geschützte Geheimnisse stattdessen über eine isolierte LSA-Komponente verarbeitet. Diebstahl und Wiederverwendung hängen weiterhin von den vorhandenen Geheimnissen, den Berechtigungen des Angreifers und einem verfügbaren Authentifizierungspfad ab; eine deaktivierte Schutzmaßnahme bedeutet nicht automatisch eine kompromittierte Domäne. Funktionsweise von Credential Guard

Unser Artikel zu Pass-the-Hash in Active Directory erklärt, wie gestohlenes NTLM-Material laterale Bewegungen unterstützen kann, wenn das Ziel NTLM akzeptiert und das Konto über nutzbare Rechte verfügt. Er behandelt Credential Guard bereits als Gegenmaßnahme. Diese Anleitung ergänzt die Untersuchung geerbter Deaktivierungen und die Laufzeitprüfung, mit der festgestellt wird, ob diese Gegenmaßnahme tatsächlich greift.

Credential Guard hat auch im aktiven Zustand Grenzen: Lokale/Microsoft-Konten, Kerberos-Diensttickets, manuell eingegebene NTLM-Anmeldeinformationen, Keylogger und der Missbrauch der Berechtigungen einer bestehenden Sitzung bleiben relevante Risiken. Zwischengespeicherte Prüfwerte für Domänenanmeldungen sind außerdem keine NTLM-Hashes, die einfach einem anderen Computer vorgelegt werden können. Microsoft: Schutzgrenzen

Erkennung: Den laufenden Dienst messen

Verwenden Sie auf dem Windows-Zielgerät eine PowerShell-Sitzung mit erhöhten Rechten und den exakten Befehl, den Microsoft unter Prüfen, ob Credential Guard aktiviert ist angibt:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Interpretieren Sie das Ergebnis als Menge von Dienstkennungen. Ist 1 enthalten, läuft Credential Guard; 2 steht für Speicherintegrität. Ein Ergebnis mit 1 und 2 enthält Credential Guard. SecurityServicesConfigured beschreibt die Konfiguration, während SecurityServicesRunning die Ausführung beschreibt; VirtualizationBasedSecurityStatus beschreibt VBS. Dies sind getrennte Beobachtungen. Microsoft-Referenz der Win32_DeviceGuard-Eigenschaften

Öffnen Sie alternativ msinfo32.exe, wählen Sie Systemübersicht und suchen Sie nach Credential Guard unter Ausgeführte Dienste für virtualisierungsbasierte Sicherheit. Microsoft rät davon ab, das Vorhandensein von LsaIso.exe im Task-Manager als Prüfmethode zu verwenden. Microsoft-Prüfanleitung

Wenn Konfiguration und Laufzeit voneinander abweichen, prüfen Sie Windows-Protokolle → System, Quelle WinInit. Microsoft dokumentiert diese Startsignale auf derselben Konfigurationsseite:

Diese Ereignisse beschreiben den Schutzstatus und beweisen keinen Diebstahl von Anmeldeinformationen. Eine fehlgeschlagene Erfassung bedeutet unbekannt, nicht deaktiviert. Erfassen Sie Host, Erfassungszeitpunkt und Neustartkontext, damit ein altes Ereignis oder ein unerreichbarer Endpunkt nicht mit aktueller Abdeckung verwechselt wird.

Behebung (Remediation): Die Ausnahme ersetzen und nach dem Neustart prüfen

1. Ein Ausnahmeninventar erstellen

Erfassen Sie für jeden Kandidaten Version, Edition/Lizenzierung, Plattformvoraussetzungen, Domänen-/DC-Rolle, ausdrückliche lokale und verwaltete Einstellungen sowie das Laufzeitergebnis. Trennen Sie Geräte, auf denen der Dienst nachweislich nicht läuft, von Hosts, die nicht gemessen werden konnten. Priorisieren Sie die Untersuchung dort, wo Domänenanmeldeinformationen verwendet werden, und beachten Sie dabei die oben dokumentierten Ausschlüsse.

2. Die Abhängigkeit testen, die die Deaktivierung begründet hat

Verwenden Sie repräsentative Geräte und die tatsächlichen Authentifizierungsabläufe. Microsoft empfiehlt zertifikatbasierte WLAN-/VPN-Authentifizierung anstelle von MS-CHAPv2 sowie Kerberos Constrained Delegation oder Resource-Based Kerberos Constrained Delegation für betroffene Hyper-V-Migrationsabläufe. Diese Änderungen beheben die Abhängigkeit, statt die Deaktivierung fortzuschreiben. Dokumentieren Sie einen Verantwortlichen und ein Überprüfungsdatum für Ausnahmen, die bestehen bleiben müssen. Microsoft-Kompatibilitätsanleitung

3. Eine ausdrückliche unterstützte Konfiguration festlegen

Folgen Sie für domänenverwaltete Geräte Microsofts GPO-Verfahren: Aktivieren Sie Virtualisierungsbasierte Sicherheit aktivieren unter Computerkonfiguration → Administrative Vorlagen → System → Device Guard und wählen Sie dann Aktiviert mit UEFI-Sperre oder Aktiviert ohne Sperre unter Credential Guard-Konfiguration. Begrenzen und testen Sie die Bereitstellung vor einem breiten Rollout. Starten Sie nach der Richtlinienanwendung neu. Intune stellt diese Credential-Guard-Optionen ebenfalls bereit. Microsoft-Bereitstellungsanleitung

Die dokumentierte Registrierungsalternative verwendet EnableVirtualizationBasedSecurity=1 unter HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard und LsaCfgFlags=1 oder 2 unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa. RequirePlatformSecurityFeatures unter dem DeviceGuard-Pfad wählt Secure Boot (1) oder Secure Boot plus DMA-Schutz (3). Befolgen Sie das vollständige dokumentierte Verfahren und lösen Sie widersprüchliche verwaltete Konfigurationen auf. Microsoft-Registrierungseinstellungen

Wählen Sie die Sperre bewusst. Die standardmäßige Aktivierung erfolgt ohne UEFI-Sperre; das Entfernen einer Konfiguration mit UEFI-Sperre erfordert Microsofts Firmware-Verfahren und eine physische Bestätigung. Eine Registrierungsänderung allein entfernt diesen Firmware-Zustand nicht. Dokumentieren Sie die Wiederherstellungsmöglichkeiten, bevor Sie die Sperre wählen. Microsoft-Verfahren für die UEFI-Sperre

4. Prüfen und Nachweise aufbewahren

Wiederholen Sie nach dem Neustart den dokumentierten CIM-Befehl oder die Prüfung mit msinfo32.exe und untersuchen Sie WinInit-Fehler. Schließen Sie die Behebung ab, wenn der vorgesehene Dienst läuft und die erforderlichen Abläufe erfolgreich getestet wurden, nicht schon dann, wenn eine GPO existiert. Belassen Sie ungeklärte Geräte mit ihren tatsächlichen Nachweisen und dem nächsten Schritt im Inventar.

Diese Laufzeitprüfung stellt nicht fest, ob Anmeldeinformationen vor dem Beginn des Schutzes offengelegt wurden. Microsoft empfiehlt, Credential Guard vor dem Domänenbeitritt oder der ersten Anmeldung eines Domänenbenutzers zu aktivieren, weil zuvor verwendete Geheimnisse bereits kompromittiert worden sein können. Microsoft-Bereitstellungsanleitung

Prüfen Sie auch angrenzende Risiken für Anmeldeinformationen. Unser Artikel zu aktiviertem WDigest erklärt, wie UseLogonCredential und veraltete Ausnahmen die in LSASS offengelegten Anmeldeinformationen erweitern können. Dies ergänzt die Prüfung der Speicherung von Anmeldeinformationen, ersetzt aber nicht die Messung der Credential-Guard-Isolation.

Wie EtcSec dies erkennt

Der etc-collector von EtcSec enthält CREDENTIAL_GUARD_DISABLED, eine GPO-Konfigurationsprüfung mit mittlerem Schweregrad. Ihre Methode Detect() liest erfasste GPO-Richtlinien und sucht nach einem VBS-Wert von 1 und einem Credential-Guard-Wert LsaCfgFlags von 1 oder 2. Fehlt eine der beiden Bedingungen, erfasst sie einen Konfigurationsbefund.

Die Suche verwendet die erste gefundene Einstellung aus Default DC Policy, Default Domain Policy und anschließend anderen GPOs; die beiden Werte können aus unterschiedlichen Richtlinien stammen. Sie berechnet nicht die resultierende Richtlinie jedes Endpunkts, fragt nicht den CIM-Zustand jedes Hosts ab und ermittelt nicht die automatische Aktivierung auf jedem Computer. Eine GPO-Konfiguration ist kein effektiver Laufzeitzustand. Ein fehlender GPO-Wert kann mit einem laufenden, standardmäßig aktivierten Dienst zusammenfallen; eine vorhandene Einstellung beweist nicht die Ausführung in der gesamten Geräteflotte.

Nutzen Sie den Befund, um die Konfigurationsuntersuchung zu eröffnen, und fügen Sie dann Messungen auf Hostebene dem Behebungsnachweis hinzu. Die aussagekräftige Nachweiskette besteht aus Voraussetzungen, ausdrücklichen Einstellungen, angewandter Konfiguration, Neustart und Laufzeitprüfung. Halten Sie unbekannte Ergebnisse sichtbar, damit Konfigurationsabdeckung nicht als gemessener Schutz ausgewiesen wird.