LAPS-Abdeckungsluecken: Audit und Behebung nach der Bereitstellung

Zusammenfassung: Was sind LAPS-Abdeckungsluecken nach der Bereitstellung?

LAPS-Abdeckungsluecken nach der Bereitstellung beschreiben eine Active-Directory-Umgebung, in der die Verwaltung lokaler Administratorkennwörter vorhanden ist, ihr Schutz aber nicht alle relevanten Computer oder Identitäten erreicht. Manche Computer erhalten die vorgesehene Richtlinie nie. Andere verwenden weiterhin die ältere Klartextspeicherung, vergeben Wiederherstellungsrechte zu großzügig oder lassen ein offengelegtes Kennwort bis zur erfolgreichen Rotation nutzbar.

Windows Local Administrator Password Solution verwaltet und sichert das Kennwort eines lokalen Administratorkontos. Zu ihren Zielen gehört es, laterale Bewegung durch wiederverwendete lokale Anmeldedaten einzuschränken. Microsofts Übersicht zu Windows LAPS beschreibt sowohl die Sicherung in Active Directory als auch die neuere native Implementierung. Ein Richtlinienobjekt, eine installierte Funktion oder ein befülltes Attribut sind Anhaltspunkte für die Untersuchung; jeder davon beantwortet eine andere Frage als die, ob jedes vorgesehene Gerät geschützt ist.

Dieser Artikel setzt voraus, dass AD-gestütztes LAPS bereits vorhanden ist. Unser Leitfaden zu nicht bereitgestelltem Windows LAPS erklärt den fehlenden Lebenszyklus der Anmeldedaten: unverwaltete, statische oder gemeinsam genutzte lokale Administratorkennwörter und die Einführung einer Rotation. Unser Artikel zur Hygiene von Computerobjekten und zum LAPS-Schema behandelt die grundlegendere Voraussetzung eines nicht erweiterten Schemas sowie die Hygiene von Computern und Domänencontrollern. Hier ist das Schema vorhanden und die Bereitstellung hat begonnen; nun gilt es, die Schwachstellen dieser Bereitstellung zu finden.

Funktionsweise: Vier Wege, auf denen bereitgestelltes LAPS seinen Schutz verliert

1. Unvollständige Domänenabdeckung

Eine Einführung kann in einer Pilot-OU erfolgreich sein und dennoch Mitgliedsserver, neu eingerichtete Arbeitsstationen oder in eine andere OU verschobene Geräte übergehen. Hinter derselben beruhigenden Aussage „Wir verwenden LAPS“ stehen dann zwei Populationen. Prüfen Sie den vorgesehenen Bestand und den tatsächlichen Gerätezustand getrennt für Arbeitsstationen und Mitgliedsserver, damit eine große Zahl von Arbeitsstationen einen unverwalteten Serverbestand nicht verdeckt.

Abdeckung ist außerdem etwas anderes als ein ordnungsgemäßer Betrieb. Ein Ablaufattribut kann befüllt bleiben, obwohl ein Gerät offline ist oder die Richtlinienverarbeitung fehlschlägt. Erfassen Sie, ob ein Computer Nachweise für natives Windows LAPS, für die ältere Version oder für keine der beiden aufweist, und prüfen Sie anschließend die jüngste Aktivität anhand der konfigurierten Rotationsrichtlinie. Führen Sie deaktivierte Computerobjekte und Domänencontroller ausdrücklich im Prüfumfang auf; die Verwaltung von DSRM-Kennwörtern ist ein eigener Anwendungsfall für DCs.

2. Das ältere Attribut bleibt der Wiederherstellungsweg

Die Generationen verwenden unterschiedliche Attribute. Microsofts Schemareferenz ordnet ms-Mcs-AdmPwdExpirationTime dem Attribut msLAPS-PasswordExpirationTime und ms-Mcs-AdmPwd dem Attribut msLAPS-Password zu. Der native Wert von msLAPS-Password enthält Kennwortdaten im Klartext als JSON; msLAPS-EncryptedPassword enthält verschlüsselte Daten. Das Präfix msLAPS- allein beweist daher keine Verschlüsselung.

Windows LAPS kann ältere Richtlinien über den Emulationsmodus für das ältere Microsoft LAPS berücksichtigen. Die Emulation speichert weiterhin im Klartext in AD und bietet keine native Kennwortverschlüsselung. Ein gefundenes älteres Attribut sollte eine Prüfung der aktiven Richtlinie und des Migrationsstands auslösen, statt zu der Annahme zu führen, dass zwangsläufig die alte Clienterweiterung ausgeführt wird. Native Windows-LAPS-Richtlinien haben Vorrang vor älteren Richtlinien. Die Emulation setzt außerdem voraus, dass die clientseitige Erweiterung des älteren Microsoft LAPS auf dem verwalteten Gerät nicht vorhanden ist.

3. Der Kennwortabruf ist zu großzügig delegiert

Rotation kann nicht ausgleichen, dass ein unberechtigter Sicherheitsprinzipal das aktuelle Kennwort abruft. Prüfen Sie sowohl das Recht zum Abrufen des gespeicherten Materials als auch, bei Verwendung von Verschlüsselung, den autorisierten Entschlüsseler. Dies sind getrennte Kontrollen. Eine Helpdesk-Gruppe mit genehmigter Wiederherstellungsaufgabe benötigt eine Prüfung ihrer Mitgliedschaften; allein „LAPS“ im Namen macht sie nicht sicher.

Weitreichende OU-Delegierung kann viele Computer betreffen. Explizite Computerberechtigungen können ebenfalls von der OU-Baseline abweichen. Prüfen Sie geerbte Berechtigungen, Ausnahmen, Gruppenmitgliedschaften und den genehmigten Personenkreis für die Wiederherstellung gemeinsam. Eine Berechtigung für eine Gruppe entspricht nicht der Zahl einzelner Personen, die sie ausüben können.

4. Die Kennwortoffenlegung wirkt über die Zugriffsprüfung hinaus

Eine ACL-Änderung beschränkt zukünftige Verzeichnislesevorgänge. Sie kann ein Kennwort, das bereits in ein Ticket, ein Transkript, eine Skriptausgabe oder die Sitzung einer anderen Person kopiert wurde, nicht zurückholen. Dies sind mögliche Untersuchungsansätze bei einem Vorfall, keine Belege dafür, dass in einer bestimmten Umgebung ein Kennwort abgeflossen ist.

Die Angriffskette: Von Wiederherstellungsrechten zu lokalem Zugriff

Eine plausible Fehlerkette beginnt mit der Kompromittierung einer Identität, die unbeabsichtigte Wiederherstellungsrechte besitzt. Kann dieser Sicherheitsprinzipal ein nutzbares lokales Administratorkennwort abrufen, erhält der Angreifer Anmeldedaten für den betroffenen Computer. Die daraus entstehende Reichweite hängt vom Kontostatus, Netzwerkzugriff und den lokalen Authentifizierungskontrollen ab; ein lesbares Attribut bedeutet keine automatische Übernahme der Domäne.

Ein nicht abgedecktes Gerät eröffnet einen anderen Weg: Sein lokales Kennwort bleibt außerhalb des vorgesehenen LAPS-Lebenszyklus. Ein ausschließlich mit der älteren Version verwaltetes Gerät kann korrekt rotieren und dennoch Wiederherstellungsmaterial im Klartext einem zu großen Kreis von Leseberechtigten zugänglich machen. Diese Bedingungen können gleichzeitig vorliegen, erfordern aber unterschiedliche Korrekturen. Eine Ausweitung des Richtlinienumfangs entfernt keine übermäßigen Leseberechtigungen, und das Aktivieren der Verschlüsselung nimmt ein ausgeschlossenes Gerät nicht in den Geltungsbereich auf.

Ermitteln Sie für die Vorfalltriage den Computer, die Generation des gespeicherten Kennworts, den autorisierten Personenkreis für die Wiederherstellung und die erfolgreiche Rotation nach der Eindämmung. Exportieren Sie keine echten Kennwörter allein zum Nachweis der Schwachstelle. Metadaten, ACL-Nachweise und Endpunktprotokolle ermöglichen in der Regel eine sicherere erste Bewertung.

Abdeckung und Leseberechtigungen messen

Computer mit nativen Ablaufnachweisen finden

Microsofts Migrationsleitfaden nennt ein neues oder aktualisiertes msLAPS-PasswordExpirationTime als eine Möglichkeit, den Übergang zu nativem Windows LAPS zu überwachen. Der folgende Befehl ist eine für Audits angepasste Variante der dokumentierten LDAP-Filter- und Eigenschaftsparameter von Get-ADComputer und verwendet das dokumentierte Attribut. Ersetzen Sie die Beispiel-OU durch Ihren genehmigten Prüfumfang. Dieser Befehl wird für Leser bereitgestellt; er wurde für diesen Artikel nicht gegen eine Produktionsdomäne ausgeführt.

Get-ADComputer -SearchBase 'OU=Workstations,DC=corp,DC=example' -LDAPFilter '(msLAPS-PasswordExpirationTime=*)' -Properties 'msLAPS-PasswordExpirationTime',OperatingSystem,Enabled

Das Ergebnis ist eine Liste von Computern mit nativen Ablaufnachweisen, weder ein Prozentsatz noch ein Beleg dafür, dass jeder aufgeführte Computer ordnungsgemäß funktioniert. Vergleichen Sie die Liste mit dem erwarteten Gerätebestand, um fehlende Computer zu ermitteln. Ein älterer Ablaufwert auf einem fehlenden Computer kann auf eine frühere Bereitstellung hinweisen. Prüfen Sie den Deaktivierungsstatus, das vorgesehene Sicherungsverzeichnis und die tatsächliche Endpunktkonfiguration, bevor Sie eine Abdeckungslücke zuweisen. Ein in Entra gesichertes Gerät sollte nicht anhand des fehlenden AD-Sicherungsattributs beurteilt werden.

Gleichen Sie für eine belastbare Abdeckungsberechnung denselben Bestand aktivierter Arbeitsstationen und Mitgliedsserver im Geltungsbereich mit nativen oder älteren Bereitstellungsnachweisen ab. Geben Sie an, welche Generationen als abgedeckt zählen. Trennen Sie die Sicht auf die Migration zur nativen Version von der Sicht auf die Bereitstellung über alle Generationen hinweg. Prüfen Sie anschließend die Aktualität der Ablaufwerte und die erfolgreiche Rotation; die bloße Attributpräsenz kann beides nicht belegen.

Sicherheitsprinzipale mit Wiederherstellungsrechten auflisten

Die Referenz zu Find-LapsADExtendedRights dokumentiert die OU-Abfrage und die Option -IncludeComputers. Dieses Beispiel setzt eine Audit-OU ein und schließt Berechtigungen auf Computerebene ein:

Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=example' -IncludeComputers

Vergleichen Sie die zurückgegebenen Sicherheitsprinzipale mit einer genehmigten Wiederherstellungsliste und prüfen Sie die relevanten Mitgliedschaften sowie geerbte oder explizite Berechtigungen. Behandeln Sie dies als Auflistung von Berechtigungen, nicht als Beleg für einen erfolgten Kennwortlesevorgang oder als vollständige Rekonstruktion des effektiven Zugriffs. Bewahren Sie Objekt- und Berechtigtenkennungen in den Auditnachweisen auf, ohne Kennwortwerte zu speichern.

Für eine autorisierte Wiederherstellungsprüfung an einem Computer dokumentiert Microsofts Referenz zu Get-LapsADPassword das folgende Muster mit einem ersetzten Beispielcomputernamen. Es ruft Anmeldedaten ab; es ist keine reine Metadatenabfrage und wurde für diesen Artikel nicht gegen eine Produktionsdomäne ausgeführt.

Get-LapsADPassword -Identity 'WS-001'

Ohne -AsPlainText werden zurückgegebene Kennwörter in SecureString gekapselt. Prüfen Sie Source, DecryptionStatus und AuthorizedDecryptor, um Speicherungs- und Entschlüsselungsergebnisse zu unterscheiden. Das Cmdlet ruft auch ältere ms-Mcs-AdmPwd-Kennwörter ab, aber bei älteren Ergebnissen fehlen Account und PasswordUpdateTime; eine dort leere Aktualisierungszeit ist kein Beleg für eine fehlgeschlagene Rotation.

Erkennung: Das LAPS-Betriebsprotokoll des Clients lesen

Microsoft dokumentiert diese Signale in der Referenz zum Windows-LAPS-Ereignisprotokoll:

Erfassen Sie diese Ereignisse aus Microsoft-Windows-LAPS/Operational auf den verwalteten Clients. Der entsprechende Kanal auf einem Domänencontroller betrifft dessen eigene DSRM-Verwaltung, nicht die Aktivität domänengebundener Clients. Ein erfolgreicher Verarbeitungszyklus muss keine Rotation enthalten, wenn keine Kennwortaktualisierung fällig war.

Korrelieren Sie die Ereignisse je Gerät und Verarbeitungszyklus. Ermitteln Sie anhand der konfigurierten Richtlinie, wann eine Aktualisierung hätte erfolgen sollen. Diese Betriebsereignisse belegen Verarbeitungs- und Aktualisierungsergebnisse; sie belegen nicht, wer das gespeicherte Kennwort abgerufen hat. Fehlende Ereignisse erfordern außerdem eine Prüfung der Funktionsfähigkeit der Erfassung, bevor sie als fehlende LAPS-Aktivität gewertet werden.

Behebung: Jede Schwachstelle einzeln schließen (Remediation)

1. Richtlinienumfang und Schreibberechtigungen korrigieren

Weisen Sie jedem nicht abgedeckten Computer einen Verantwortlichen zu. Prüfen Sie sein vorgesehenes Sicherungsverzeichnis und die Richtlinienzuweisung und beheben Sie dann die tatsächliche Ursache: OU-Platzierung, Filterung, Richtlinienvorrang oder Schreibdelegierung. Microsofts AD-Bereitstellungsverfahren dokumentiert den folgenden Befehl mit einer ersetzten Beispiel-OU:

Set-LapsADComputerSelfPermission -Identity 'OU=Workstations,DC=corp,DC=example'

Dies gewährt Selbstaktualisierungsrechte für native Windows-LAPS-Attribute; es konfiguriert keine Richtlinie und beweist keine erfolgreiche Sicherung. Verwenden Sie bei älteren Bereitstellungen oder Emulationsbereitstellungen die im Microsoft-Emulationsleitfaden beschriebenen älteren ACL-Werkzeuge, statt anzunehmen, dass dieses native Cmdlet ältere Berechtigungen korrigiert. Prüfen Sie die Kandidatenliste und die Nachweise der Endpunktaktualisierung nach der Korrektur erneut.

2. Abruf und Entschlüsselung beschränken

Entfernen Sie unbeabsichtigte Berechtigungen an ihrer tatsächlichen Quelle, einschließlich geerbter Berechtigungen, und delegieren Sie die Wiederherstellung anschließend an den genehmigten Personenkreis. Das Hinzufügen einer eng begrenzten Berechtigung widerruft keine bestehende weitreichende Berechtigung. Wiederholen Sie die Rechteabfrage nach der ACL-Prüfung und testen Sie die genehmigte Wiederherstellung, ohne Anmeldedaten in allgemeine Auditausgaben aufzunehmen.

Für native AD-Verschlüsselung setzt Microsofts Referenz zu Richtlinieneinstellungen die Domänenfunktionsebene 2016 oder höher voraus. Prüfen Sie ADPasswordEncryptionEnabled und ADPasswordEncryptionPrincipal; letzteres bezeichnet den autorisierten Entschlüsseler und muss auf dem Gerät auflösbar sein. Setzen Sie Verzeichnisabrufrechte nicht mit der Befugnis zur Entschlüsselung gleich.

3. Die Migration von der älteren Version abschließen

Folgen Sie Microsofts Migrationsverfahren für den unmittelbaren Übergang oder die vorübergehende Koexistenz. Während der Koexistenz müssen die beiden Implementierungen unterschiedliche lokale Konten verwalten. Prüfen Sie die native Richtlinie, aktualisierte native Attribute und erfolgreiche Endpunktaktivität, bevor Sie ältere Software entfernen. Prüfen Sie auch den Zugriff auf verbliebenes älteres Kennwortmaterial; eine erfolgreiche native Einführung belegt nicht, dass jeder alte Wiederherstellungsweg bereinigt wurde.

4. Nach glaubhafter Offenlegung rotieren

Koordinieren Sie nach der Eindämmung unberechtigten Zugriffs die Rotation auf dem betroffenen Endpunkt. Microsoft dokumentiert Reset-LapsPassword für außergewöhnliche Situationen, die eine sofortige Änderung erfordern, darunter eine Sicherheitsverletzung auf einem Computer:

Reset-LapsPassword

Führen Sie es lokal auf dem betroffenen verwalteten Gerät mit den erforderlichen Berechtigungen aus. Das Cmdlet gibt keine detaillierten Ergebnisinformationen zurück; prüfen Sie die daraus entstehenden Ereignisse. Ein übermittelter Zurücksetzungsauftrag reicht nicht als Beleg dafür, dass die offengelegten Anmeldedaten nicht mehr funktionieren. Prüfen Sie neben der Rotation die betroffenen Identitäten und Endpunkte des Vorfalls, statt ihn allein wegen einer geänderten Leser-ACL abzuschließen.

Wie EtcSec dies erkennt

Der Katalog akzeptiert diese vier Kennungen. Die folgenden Beschreibungen geben die für diesen Artikel geprüften Detect()-Implementierungen wieder und behaupten nicht, dass ein Audit gegen Ihre Domäne ausgeführt wurde:

• LAPS_DOMAIN_COVERAGE_LOW bewertet die Abdeckung aktivierter Computer, die keine DCs sind, und zählt das Vorhandensein von älterem oder nativem LAPS. Der Kontrollmechanismus trennt Arbeitsstations- und Serverzahlen und meldet eine Kennzahl auf Domänenebene. In der geprüften Detect()-Implementierung erzeugt eine Abdeckung unter 95% einen Befund: High unter 80%, andernfalls Medium unter 95%. Dies sind EtcSec-Kontrollschwellen, keine Microsoft-Empfehlungen. Quelle: etc-collector public/internal/audit/detectors/ad/advanced/laps/laps-domain-coverage.go, Zeilen 78–86, Commit f51fad0b69c0c7fbda2fcc3c43bd6f6b4da4bee4, geprüft am 3. Oktober 2026. Die Kontrolle misst Bereitstellungsnachweise, weder die Aktualität der Rotation noch die Qualität der Verschlüsselung.
• LAPS_LEGACY_ATTRIBUTE identifiziert Computer mit Nachweisen für älteres LAPS und ohne Nachweise für natives Windows LAPS. Der Kontrollmechanismus identifiziert weder die ausgeführte Clientimplementierung noch belegt er einen unberechtigten Lesevorgang.
• LAPS_PASSWORD_READABLE untersucht gewährende ACEs mit CONTROL_ACCESS, die auf die im aktiven Forest aufgelöste Schema-GUID von ms-Mcs-AdmPwd zielen. Erkannte integrierte Administrator-Berechtigte und die eigene SID des Computers werden ausgeschlossen. Der Umfang beschränkt sich auf dieses ältere Berechtigungssignal, nicht auf eine allgemeine Bewertung nativer Rechte zur Entschlüsselung verschlüsselter Kennwörter.
• LAPS_PASSWORD_LEAKED verwendet dasselbe ältere Signal gewährender CONTROL_ACCESS-ACEs und meldet mehr als einen unterschiedlichen leseberechtigten Trustee auf einem Computer nach denselben Ausschlüssen für integrierte Administratoren und die eigene SID. „Non-admin“ bedeutet hier, dass der Trustee von diesem Filter nicht erkannt wurde; der Detektor ermittelt nicht die effektive administrative Rolle jedes Trustees. Er meldet potenzielle Offenlegung durch übermäßige Berechtigungen, keine beobachtete Exfiltration, und löst Gruppen nicht in eine Personenanzahl auf. Validieren Sie den effektiven Zugriff gesondert: Dieses Prädikat zählt passende gewährende Berechtigungen, statt verweigernde ACEs dagegen aufzulösen.

Verwenden Sie etc-collector-Befunde, um Untersuchungen zu priorisieren, und validieren Sie anschließend Abdeckung, effektive Rechte, Richtliniengeneration und Endpunktrotation getrennt. Ein Bereitstellungsbefund kann behoben sein, während ein Berechtigungsproblem fortbesteht. Schließen Sie die Prüfung erst ab, wenn sowohl der vorgesehene Bestand als auch der genehmigte Wiederherstellungsweg mit den Nachweisen übereinstimmen.