Windows LAPS nicht bereitgestellt: Warum gemeinsam genutzte lokale Admin-Passwörter riskant bleiben

Was ist Windows LAPS nicht bereitgestellt?

Windows LAPS nicht bereitgestellt bedeutet, dass die Umgebung noch keinen verwalteten Prozess für Setzen, Rotieren, Sichern und Wiederherstellen des lokalen Administratorpassworts auf Windows-Clients und Servern hat. Windows Local Administrator Password Solution soll genau ein praktisches Problem lösen: Das lokale Admin-Konto bleibt aus Support-, Build- oder Break-Glass-Gründen oft vorhanden. Wenn das Passwort aber statisch oder auf mehreren Systemen identisch ist, kann ein kompromittierter Host denselben Zugang auf viele weitere Geräte öffnen.

Microsoft empfiehlt heute klar den Einsatz von Windows LAPS statt manueller Rotation. Windows LAPS kann das Passwort entweder in Windows Server Active Directory oder in Microsoft Entra ID sichern und bringt native Richtlinien, PowerShell-Cmdlets und Auditing mit. Wenn die Funktion fehlt, falsch gescoped ist oder nie sauber per GPO, Intune oder CSP ausgerollt wurde, bleibt das Risiko real, auch wenn Teams lokalen Admin-Zugriff für „selten genutzt" halten.

Darum taucht Windows LAPS nicht bereitgestellt oft zusammen mit GPO-Fehlkonfigurationen als Angriffsvektor und Veralteten und überprivilegierten Konten in AD auf. In allen Fällen geht es nicht nur darum, wer Adminrechte besitzt, sondern ob der Lebenszyklus des Geheimnisses nach einer Kompromittierung kontrollierbar bleibt.

Wie es funktioniert

Windows LAPS ist in aktuellen Windows-Versionen integriert und kann genau ein konfiguriertes lokales Administratorkonto pro Gerät verwalten. Microsoft dokumentiert zwei unterstützte Sicherungsziele:

• Windows Server Active Directory
• Microsoft Entra ID

Auf dem Client konfigurieren Sie Kontoname, Passwortkomplexität, Passwortalter, Post-Authentication-Actions und das Sicherungsziel. Auf der Verwaltungsseite legen Sie fest, wer Passwörter lesen darf, wer eine Rotation anstoßen kann und wie Wiederherstellung auditiert wird.

Für Entra ID nennt Microsoft klare Voraussetzungen:

• das Gerät muss Entra-joined oder hybrid-joined sein
• rein Entra-registered Geräte werden nicht unterstützt
• LAPS muss tenantseitig aktiviert sein und die Clientrichtlinie muss BackupDirectory auf Entra ID setzen

Für Active Directory setzt Windows LAPS auf Schema-Erweiterungen und Delegationsrechte, damit das Passwortmaterial sicher im Verzeichnis gespeichert werden kann. Microsoft liefert eigene Cmdlets, um das Schema zu erweitern, Passwörter abzufragen, Leserechte zu ermitteln und Rotationen zurückzusetzen.

Microsoft dokumentiert außerdem einen Migrationspfad vom älteren Microsoft LAPS. Das ist relevant, weil viele Umgebungen glauben, „LAPS sei schon da", obwohl in Wirklichkeit nur ein veralteter, unvollständiger oder nie fertig migrierter Ansatz existiert.

Die Angriffskette

Schritt 1 - Einen Host kompromittieren, der noch ein wiederverwendbares lokales Admin-Passwort hat

Angreifer brauchen keinen Domain Admin, um von schlechter lokaler Passwort-Hygiene zu profitieren. Sie benötigen nur einen Host, auf dem das lokale Admin-Konto erreichbar ist und dessen Passwort erraten, ausgelesen oder anderweitig erlangt werden kann. Wenn dieses Passwort auf mehreren Systemen funktioniert, bleibt die Kompromittierung nicht lokal.

Deshalb taucht das Thema oft in derselben Review wie Active Directory-Passwortsicherheit: Fehlkonfigurationen mit echtem Risiko auf. Der Kernfehler ist identisch: Ein Geheimnis, das eigentlich eindeutig und kontrolliert sein sollte, lässt sich in Wirklichkeit leicht wiederverwenden.

Schritt 2 - Das Passwort für Lateralmovement wiederverwenden

Sobald Passwort oder NT-Hash auf mehreren Geräten gültig sind, werden Remote-Admin-Kanäle für den Angreifer deutlich wertvoller. Der genaue Pfad hängt von der Umgebung ab, aber die Logik bleibt gleich: Das Passwort wurde nie pro Gerät randomisiert und nach einer Offenlegung nicht schnell genug rotiert.

# Prüfen, ob ein Gerät aktuelle Windows-LAPS-Aktivität protokolliert
Get-WinEvent -LogName 'Microsoft-Windows-LAPS/Operational' -MaxEvents 20 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Wenn dieses Log auf eigentlich verwalteten Geräten leer bleibt, oder weder Rotation noch Wiederherstellung im erwarteten Verwaltungspfad auftauchen, ist der Rollout unvollständig.

Schritt 3 - Zugang schneller ausweiten als manuell rotiert werden kann

Manuelle Passwortwechsel skalieren im Incident-Fall schlecht. Eine Umgebung ohne Windows LAPS landet meist bei Notfallskripten, Endpoint-Tickets oder Ad-hoc-Resets. Das verlangsamt die Eindämmung und lässt ein größeres Zeitfenster, in dem der Angreifer denselben lokalen Admin-Pfad auf weiteren Systemen wiederverwenden kann.

Darum passt das Thema auch direkt zu Active Directory-Angriffspfaden zu Domain Admin. LAPS allein löst keine Privilege Escalation, aber sein Fehlen liefert Angreifern einen verlässlichen Lateralmovement-Baustein, der sich oft mit breiterem AD-Missbrauch verbindet.

Erkennung

Die beste Erkennung kombiniert Richtlinienabdeckung, Backup-Validierung und Rechte-Review.

# Prüfen, wer in AD LAPS-Passwörter lesen kann
Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=local'

# Wiederherstellung eines in AD gespeicherten Passworts validieren
Get-LapsADPassword -Identity WS-001 -AsPlainText

Für Entra-ID-gestützte Bereitstellungen dokumentiert Microsoft außerdem Get-LapsAADPassword und rollenbasierte Wiederherstellung. Ein guter Review prüft also beide Seiten: Ist das Passwort wirklich vorhanden, und dürfen nur die vorgesehenen Rollen es abrufen?

Es lohnt sich außerdem, den LAPS-Rollout mit AD-Sicherheitsüberwachung: relevante Event IDs und SIEM zu korrelieren. Fehlt die Kontrolle über das lokale Admin-Passwort, fehlt dem Monitoring-Team meist auch eine saubere Sicht darauf, welche Systeme noch außerhalb der vorgesehenen Baseline liegen.

Remediation

Ein pragmatischer Remediationspfad sieht so aus:

1. Sicherungsautorität festlegen. Nutzen Sie Active Directory oder Microsoft Entra ID abhängig von Join- und Management-Modell.
2. Verzeichnis und Rechte vorbereiten. Für AD das Schema aktualisieren und Lese-/Reset-Rechte prüfen. Für Entra tenantseitig LAPS aktivieren und Recovery-Rollen festlegen.
3. Clientrichtlinie konfigurieren. Definieren Sie verwaltetes Konto, Passwortkomplexität, Passwortalter, Sicherungsziel und Post-Authentication-Actions.
4. Erfolgreiche Verarbeitung validieren. Prüfen Sie über das Windows-LAPS-Log und die Retrieval-Cmdlets, dass Passwörter wirklich rotiert und gespeichert werden.
5. Drift beseitigen. Entfernen Sie alte Skripte, geteilte lokale Admin-Passwörter und Reste des älteren Microsoft LAPS.
6. Recovery-Rechte auditieren. Stellen Sie sicher, dass nur die richtigen Teams Passwörter lesen oder zurücksetzen können.

# Beispiel für Rollout und Validierung bei AD-gestütztem Windows LAPS
Update-LapsADSchema
Get-LapsADPassword -Identity WS-001
Reset-LapsPassword

Für Entra-gestützte Bereitstellungen empfiehlt Microsoft außerdem, die Passwortwiederherstellung mit Conditional Access für die Rollen zu schützen, die lokale Admin-Zugangsdaten abrufen können. Das ist ein nützlicher Hinweis, dass ein LAPS-Rollout nicht nur eine Endpoint-Hygiene-Aufgabe ist, sondern auch ein Zugriffskontrollproblem.

Rollout validieren, bevor Sie den Befund schließen

Ein Rollout ist nicht abgeschlossen, weil eine Richtlinie existiert. Er ist abgeschlossen, wenn repräsentative Geräte ihre Passwörter wirklich rotieren, das Sicherungsziel aktuelle Secrets enthält und der Recovery-Pfad Ende-zu-Ende von der vorgesehenen Rolle getestet wurde. Ein sinnvoller Minimaltest deckt einen Standard-Client, einen privilegierten Admin-Arbeitsplatz (falls vorhanden), eine relevante Serverklasse und einen echten Recovery-Test ab.

Diese Validierung sollte außerdem dokumentieren, wer Passwörter lesen und wer Rotationen anstoßen darf. Andernfalls ersetzt die Umgebung nur ein geteiltes lokales Passwort durch eine zu breite Wiederherstellungsfläche. Deshalb sollten Windows LAPS nicht bereitgestellt und eine zu weit gefasste Delegation oft im selben Audit gemeinsam geprüft werden.

Wie EtcSec das erkennt

EtcSec verknüpft dieses Thema mit LAPS_NOT_DEPLOYED und GPO_LAPS_NOT_DEPLOYED. Die relevante Unterscheidung ist, ob Windows LAPS komplett fehlt oder ob das Unternehmen glaubt, es sei ausgerollt, obwohl keine dauerhafte Richtlinie die richtigen Endgeräte erreicht.

Offizielle Quellen

• Microsoft Learn: Windows LAPS Overview
• Microsoft Learn: Windows LAPS PowerShell Cmdlets Overview
• Microsoft Learn: Use Windows Local Administrator Password Solution with Microsoft Entra ID
• Microsoft Learn: Prepare for Windows LAPS deployment and migration

Weiterführende Artikel

Zur Priorisierung dieses Themas sollten Sie auch GPO-Fehlkonfigurationen als Angriffsvektor, Veraltete und überprivilegierte Konten in AD, Active Directory-Passwortsicherheit: Fehlkonfigurationen mit echtem Risiko, Active Directory-Sicherheitsaudit-Checkliste für interne Teams und AD-Sicherheitsüberwachung: relevante Event IDs und SIEM lesen. Diese angrenzenden Themen zeigen, warum lokale Passwortrotation nur dann trägt, wenn Scope, Rechte und Auditierbarkeit zusammenpassen.