Credential Guard und LSA-Schutz lassen sich per Intune prüfen und erzwingen

Credential Guard hat sich in vielen Enterprise-Umgebungen mit Windows 11 22H2 und neuer still und leise durchgesetzt. Auf modernen Geräten läuft der Schutz häufig ab Werk mit, ohne dass es jemand groß bemerkt. Beim LSA-Schutz (Local Security Authority Protection, RunAsPPL) sieht die Lage anders aus. Hier erlebe ich in Projekten immer wieder, dass man sich auf „sichere Standardwerte“ nicht verlassen kann. Wer Credential Guard und LSA-Schutz ernst nimmt, muss den Zustand prüfen, fehlende Einstellungen nachziehen und bei drohenden Kompatibilitätsproblemen auch einmal auf die Bremse treten.

Credential Guard läuft oft schon, der LSA-Schutz längst nicht überall

In vielen Tenants, die ich mir ansehe, ist Credential Guard auf halbwegs aktuellen Geräten mit Windows 11 Enterprise von selbst aktiv, sofern Secure Boot und VBS-fähige Hardware vorhanden sind. Für eine schnelle Kontrolle reicht meist msinfo32, dort der Eintrag „Virtualisierungsbasierte Sicherheit“. Anders beim LSA-Schutz: Er führt die sensiblen LSASS-Prozesse als geschützte Prozesse (RunAsPPL) aus und macht Credential-Dumping, etwa mit mimikatz, deutlich schwerer. Aktiv ist er aber keineswegs auf jedem Gerät. Vor allem ältere Installationen und Rechner nach einem In-place-Upgrade weichen häufig ab. Genaueres zum Credential-Guard-Status steht in der Ereignisanzeige unter Anwendungen und Diensteprotokolle → Microsoft → Windows → DeviceGuard → Operational. Für den LSA-Schutz sollte man außerdem im Sicherheitsprotokoll nach den Ereignissen 3065 und 3066 suchen.

flowchart TD
    Userlogin["Benutzer meldet sich an"] --> LSASS["LSASS-Prozess"]
    LSASS --> CredentialGuard["Credential Guard (VBS)"]
    LSASS --> LSAProtection["LSA-Schutz (RunAsPPL)"]
    LSASS -.-> OldPlugin["Altes LSA-Plugin"]
    LSAProtection -.-> PluginBlock["Plugin wird blockiert"]
    CredentialGuard --> Attacker["Angreifer (Dumping)"]
    LSAProtection --> Attacker
    Attacker -->|"Angriff erschwert/abgewehrt"| Stop["Schutz aktiv"]

Abbildung: So greifen Credential Guard, LSA-Schutz und mögliche Plugins ineinander

Intune aktiviert den LSA-Schutz am besten zunächst im Audit-Modus

Im Unternehmen setzt man den LSA-Schutz heute am saubersten über Intune durch. Eingerichtet wird er pro Gerät unter Endpoint security → Kontoschutz oder direkt im Einstellungs-Katalog, wo die Device-Guard- und Local-Security-Authority-Einstellungen zu finden sind. Für den LSA-Schutz selbst gibt es dort die Einstellung „LSA als geschützten Prozess ausführen“, die in aktuellen Richtlinien auch einen Audit-Modus kennt. Bei gemischten Geräteflotten oder älteren Clients rate ich dazu, genau damit anzufangen. Probleme mit alten VPN-Clients, mit WLAN-Stacks, die noch auf MSCHAPv2 setzen, oder mit unsignierten LSA-Plugins tauchen dann zunächst nur im Ereignisprotokoll auf. Auf diese Weise findet man die kritischen Geräte, bevor man den Schutz scharf schaltet, und sperrt niemanden versehentlich aus.

Praxis-Tipp: Für einen gut beobachtbaren Rollout lohnt sich eine dynamische Entra-ID-Gruppe mit allen Geräten, auf denen der LSA-Schutz (noch) nicht läuft. Damit lässt sich gezielt nachsteuern, und Fehler sind schneller eingegrenzt.

In der Praxis stolpert man immer wieder über dieselben Dinge. Ältere Plugins von Drittanbietern für Smartcards, VPN oder WLAN-Hardware sind oft nicht signiert, und der LSA-Schutz blockiert sie. Die Folge sind fehlgeschlagene Anmeldungen oder Verbindungen, die plötzlich nicht mehr zustande kommen. Bekannte Einschränkungen und Abhilfen beschreibt Microsoft in der offiziellen Dokumentation zu Credential Guard und zum LSA-Schutz.

Berichte und Defender for Endpoint zeigen den Status flächendeckend an

msinfo32 und die Ereignisanzeige reichen für einzelne Rechner, in größeren Umgebungen braucht es ein richtiges Monitoring. Bei Geräten, die Intune verwaltet, lässt sich der Status von Credential Guard und LSA-Schutz über Berichte abrufen. Mehr Überblick verschafft Microsoft Defender for Endpoint. In der Defender-Konsole zeigt Geräteinventar → Gerätesicherheitskonfiguration auf einen Blick, auf welchen Geräten VBS und LSA-Schutz laufen. Wer es lokal genauer wissen will, führt die folgende PowerShell-Abfrage aus, zum Beispiel als Device Query über Intune. Lokale Adminrechte sind dafür nötig:

Get-CimInstance -ClassName Win32_DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning

Ein Wert von „1“ bedeutet Credential Guard, „2“ steht für HVCI. Ob der LSA-Schutz greift, verrät der Registry-Schlüssel HKLM\SYSTEM\CurrentControlSet\Control\Lsa mit dem Wert RunAsPPL (1 = aktiv).

Nicht jedes Gerät verträgt den LSA-Schutz auf Anhieb

Manche Umgebungen erwischt es kalt. Kaum ist der LSA-Schutz aktiv, starten alte VPN-Clients nicht mehr oder die Anmeldung an bestimmten WLAN-Netzen scheitert. Dahinter steckt fast immer ein veraltetes LSA-Plugin oder ein Treiber, der nie aktualisiert wurde. Der Audit-Modus sollte dann so lange eingeschaltet bleiben, bis feststeht, wie viele Systeme betroffen sind und welche. Dazu kommen Sonderfälle mit eigenen Security- oder Management-Tools, die tief in die LSA-Prozesse eingreifen.

Lässt es sich nicht anders lösen, kann und sollte man die Durchsetzung bewusst auf kompatible Gerätegruppen beschränken. Intune bietet dafür gute Möglichkeiten, etwa über Geräteeigenschaften oder Compliance-Richtlinien. Wer bereits Passkeys einführen will, sollte sich auch mit den neuen Anforderungen an Authentifizierung und Gerätesicherheit beschäftigen.

Der LSA-Schutz gehört auf jeden Rechner, braucht aber Augenmaß

Neben Credential Guard ist der LSA-Schutz heute keine Option mehr, er gehört auf jeden modernen Windows-Rechner. Tatsächlich gibt es aber noch immer zu viele Ausnahmen, in denen technische Schulden oder proprietäre Altsoftware einen flächendeckenden Rollout aufhalten. Wer überlegt vorgeht, das Monitoring nicht aus den Augen verliert, im Zweifel mit dem Audit-Modus beginnt und Kompatibilitätsprobleme gegenüber dem Management offen anspricht, bringt den Schutz auch in heterogenen Flotten nach und nach auf die Geräte. Bei den derzeitigen Angriffswellen auf Windows-Anmeldeinformationen ist dieser Aufwand gut investiert.