LSA-Protection (RunAsPPL) führt zu SSO-Anmeldefehlern – Vorab-Auditierung unsignierter SSP/AP-Module erforderlich

Question

LSA-Protection (RunAsPPL) führt zu SSO-Anmeldefehlern – Vorab-Auditierung unsignierter SSP/AP-Module erforderlich

Ciao Lukas 40

Incident-Zusammenfassung & Problemstellung:

Nach der Test-Aktivierung der LSA Protection (RunAsPPL) schlägt der Ladevorgang benutzerdefinierter Drittanbieter-Authentifizierungsmodule (SSP/AP für Single Sign-On) in der lsass.exe fehl. Die Folge sind fehlerhafte Anmeldeversuche (Logon Failures) bei betroffenen User-Clients.

Technischer Hintergrund (Root Cause):

Da die lsass.exe unter PPL nur noch Binärdateien mit valider Microsoft-PPL-Signatur akzeptiert, verweigert die Code-Integrität unsignierten oder eigen-signierten DLLs von Drittanbietern das Laden im Prozessraum der LSA.

Benötigte Freigabe-Kriterien & Anfragen an das Security-Team:

Um den Rollout im Rahmen des Hardening-Projekts ohne Betriebsunterbrechung fortzusetzen, müssen wir die Infrastruktur vorab im Audit-Modus betreiben:

Audit-Trigger & Telemetrie: Welche spezifischen Event-IDs (z. B. im Channel CodeIntegrity oder LSA-Audit) müssen im SIEM (z. B. Splunk / Microsoft Sentinel) aggregiert werden, um alle unkompatiblen SSP/AP-Treiber vor der harten Durchsetzung lückenlos zu erfassen?
Whitelisting / Vendor-Check: Wie ist die genaue Vorgehensweise zur Evaluierung der Dritthersteller-DLLs (Signatur-Upgrade durch den Hersteller vs. Ausnahmeregelungen/Bypass), damit die Logins nach dem Enforcen stabil bleiben?

Soll ich ein PowerShell-Skript zum Auslesen der LSA-Audit-Event-Logs schreiben?

0 Kommentare

2 Antworten

Ihre Antwort

Answer 1

Jason Nguyen Tran 27,210 Unabhängiger Berater

Ich möchte kurz nachfragen, ob das Problem inzwischen gelöst wurde. Falls Sie weitere Informationen benötigen, können Sie jederzeit auf diese Nachricht antworten. Wenn die bereitgestellten Informationen hilfreich waren, klicken Sie bitte auf „Accept Answer“, um anderen Mitgliedern der Community zu helfen. Vielen Dank!

0 Kommentare

Answer 2

Hallo Ciao Lukas,

LSA Protection (RunAsPPL) kann durchaus unerwartete SSO-Fehler verursachen, wenn benutzerdefinierte SSP/AP-Module nicht entsprechend den Anforderungen für Protected Process Light (PPL) signiert sind. Sobald lsass.exe unter PPL ausgeführt wird, werden nur Binärdateien mit einer gültigen, von Microsoft ausgestellten PPL-Signatur geladen. Nicht signierte oder selbst signierte Authentifizierungs-DLLs werden daher von Code Integrity blockiert. Aus diesem Grund bricht Ihre SSO-Kette unmittelbar nach der Aktivierung von RunAsPPL ab.

Bevor Sie PPL in der Produktionsumgebung erzwingen, ist es sinnvoll, zunächst den Audit-Modus zu verwenden. Die wichtigsten Ereignisse, die Sie in Ihrem SIEM aggregieren sollten, sind CodeIntegrity Operational (Event ID 3076, 3089) für blockierte LSA-Plug-ins sowie LSA Operational (Event ID 3001, 3002) für Fehler beim Laden von Authentifizierungspaketen. Damit erhalten Sie einen vollständigen Überblick darüber, welche SSP/AP-Module nicht kompatibel sind.

Für die Bewertung durch den Hersteller empfiehlt es sich, beim jeweiligen Anbieter eine ordnungsgemäße PPL-konforme Signatur anzufordern. Ausnahmen oder Umgehungslösungen sollten nur vorübergehend eingesetzt und sorgfältig dokumentiert werden, um eine Schwächung der bestehenden Hardening-Baseline zu vermeiden.

Ein PowerShell-Skript kann dabei ebenfalls sehr hilfreich sein. Mit Get-WinEvent können Sie die CodeIntegrity- und LSA-Audit-Kanäle abfragen und so vorab auf allen betroffenen Hosts eine Prüfung durchführen. Viele Teams automatisieren diesen Prozess, um eine Liste der DLLs zu erstellen, die vor der Durchsetzung von PPL angepasst werden müssen.

Ich hoffe, diese Antwort konnte Ihnen weiterhelfen. Wenn Sie die Antwort hilfreich finden, klicken Sie bitte auf „Antwort akzeptieren“, damit ich weiß, dass Ihre Frage damit beantwortet wurde.

Jason.