What Is 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.
How Windows LAPS nicht bereitgestellt Works
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
BackupDirectoryauf 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.
| LAPS-Bereich | Microsoft-Funktion | Warum das wichtig ist |
|---|---|---|
| Clientrichtlinie | Integrierte Windows-LAPS-Settings | Erzwingt Alter, Länge, Komplexität und das verwaltete Konto |
| Sicherungsziel | AD oder Entra ID | Macht das Passwort ohne Tabellen oder Notizen wiederherstellbar |
| Zugriffssteuerung | Rollen oder Delegationsrechte | Verhindert, dass Helpdesk-Bequemlichkeit zu breiter Offenlegung wird |
| PowerShell-Tooling | Get-LapsADPassword, Get-LapsAADPassword, Find-LapsADExtendedRights, Reset-LapsPassword | Macht Rollout und Prüfung messbar |
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.
The Attack Chain
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.
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. Das Kernproblem ist also nicht nur die Existenz eines lokalen Admin-Kontos, sondern dass sein Geheimnis nicht pro Gerät eindeutig und nicht schnell genug rotierend ist.
# 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
Ohne Windows LAPS landen viele Umgebungen im Incident-Fall bei Notfallskripten, Ticket-Serien oder manuellen Passwortwechseln. Das verlangsamt die Eindämmung und verlängert das Zeitfenster, in dem derselbe lokale Admin-Zugang weiterverwendbar ist. Darum passt das Thema auch direkt zu Active Directory-Angriffspfaden zu Domain Admin: LAPS verhindert nicht jede Privileg-Eskalation, aber sein Fehlen liefert einen starken Lateralmovement-Baustein.
Warum ein teilweiser Rollout nicht genügt
Die gefährlichste Situation ist oft nicht „LAPS fehlt überall“, sondern „LAPS ist irgendwie vorhanden“. Wenn Standard-Clients abgedeckt sind, Jump Hosts, ältere Server oder Admin-Arbeitsplätze aber außen vor bleiben, verliert der Control viel von seinem Wert. Angreifer suchen gerade die Systeme, auf denen lokale Secrets noch statisch oder geteilt sind. Ein teilweiser Rollout erzeugt deshalb oft nur Scheinsicherheit.
Ein belastbarer Review prüft daher nicht nur das Vorhandensein einer Richtlinie, sondern auch die Zielgruppen, Rechte, Ausnahmen und die tatsächlich geschützten Systeme. Eine GPO in der Konsole ist nicht dasselbe wie ein real rotierendes und sauber wiederherstellbares lokales Passwort.
Detection
Die beste Erkennung kombiniert Richtlinienabdeckung, Backup-Validierung und Rechte-Review.
| Indikator | Quelle | Was geprüft werden sollte |
|---|---|---|
| Keine wirksame Windows-LAPS-Richtlinie | GPO, Intune, CSP oder lokale Policy | Bekommen verwaltete Geräte tatsächlich eine LAPS-Konfiguration? |
| Kein aktuelles Backup in AD oder Entra ID | Get-LapsADPassword oder Get-LapsAADPassword | Werden Passwörter wirklich gespeichert und rotiert? |
| Keine erfolgreiche LAPS-Aktivität auf dem Endgerät | Microsoft-Windows-LAPS/Operational | Verarbeitet der Client die Richtlinie korrekt? |
| Zu breite Leserechte | Find-LapsADExtendedRights oder Entra-Rollenreview | Können zu viele Identitäten lokale Admin-Passwörter lesen? |
# 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?
Remediation
💡 Quick Win: Legen Sie zuerst ein unterstütztes Sicherungsmodell fest. Eine halb migrierte Mischung aus manueller Verwaltung, altem Microsoft LAPS und Windows LAPS erzeugt meist mehr Risiko als Schutz.
Ein pragmatischer Remediationspfad sieht so aus:
- Sicherungsautorität festlegen. Nutzen Sie Active Directory oder Microsoft Entra ID abhängig von Join- und Management-Modell.
- 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.
- Clientrichtlinie konfigurieren. Definieren Sie verwaltetes Konto, Passwortkomplexität, Passwortalter, Sicherungsziel und Post-Authentication-Actions.
- Erfolgreiche Verarbeitung validieren. Prüfen Sie über das Windows-LAPS-Log und die Retrieval-Cmdlets, dass Passwörter wirklich rotiert und gespeichert werden.
- Drift beseitigen. Entfernen Sie alte Skripte, geteilte lokale Admin-Passwörter und Reste des älteren Microsoft LAPS.
- 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
Validate Before You Close the Finding
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, 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.
AD- und Entra-Bereitstellungen getrennt validieren
Viele LAPS-Projekte scheitern nicht an fehlender Technik, sondern an vermischten Betriebsmodellen. Microsoft trennt Windows LAPS für Active Directory und Microsoft Entra ID bewusst. Bei AD-gestützten Deployments muss nicht nur das Schema erweitert werden. Sie sollten auch prüfen, ob die delegierten Leserechte sauber auf die richtige OU oder Gerätegruppe begrenzt sind, ob Get-LapsADPassword auf repräsentativen Clients aktuelle Werte liefert und ob Reset-LapsPassword tatsächlich eine neue Rotation auslöst. Erst dann ist sichtbar, ob der Recovery-Pfad im Incident wirklich funktioniert und nicht nur als theoretische Option in der Dokumentation steht.
Bei Entra-gestützten Deployments sind andere Kontrollen kritisch. Microsoft unterstützt nur Entra-joined und hybrid-joined Geräte; rein registrierte Geräte sind nicht unterstützt. Zusätzlich muss LAPS tenantseitig aktiviert sein und die Clientrichtlinie BackupDirectory auf Entra ID setzen. Auch die Wiederherstellungsrechte sollten separat geprüft werden, weil Microsoft zwischen dem Lesen des Passworts und dem Lesen von Passwort-Metadaten unterscheidet. Ein Rollout gilt daher erst als belastbar, wenn das vorgesehene Team beide Pfade testet: erfolgreiche Sicherung des Passworts und sauber auditierbare Wiederherstellung.
Ein weiterer häufiger Fehler ist die Annahme, dass „irgendwie vorhandenes LAPS“ bereits genügt. Microsoft dokumentiert einen expliziten Migrationspfad vom älteren Microsoft LAPS. Deshalb sollte die Abnahme auch klären, ob alte GPOs, Login-Skripte oder Dokumentationsreste noch parallel existieren. Solange mehrere Verwaltungsmodelle nebeneinander laufen, entstehen Ausnahmen, Doppelzuständigkeiten und Recovery-Lücken. Ein sauberer Pilot bestätigt daher getrennt für AD und Entra, welche Geräte wirklich verwaltet sind, welches Team Passwörter abrufen darf und wie schnell nach Nutzung oder Reset eine neue Rotation nachweisbar ist.
Besonders auf Admin-Workstations, Jump Hosts und privilegierten Servern lohnt sich zusätzlich ein Test der Post-Authentication-Actions. Wenn das verwaltete Konto nach erfolgreicher Nutzung oder nach Ablauf der zulässigen Frist automatisch neu gesetzt wird, schrumpft das Zeitfenster für Lateralmovement deutlich. Ebenso wichtig ist die Frage, ob Windows LAPS pro Gerät wirklich nur das vorgesehene lokale Administratorkonto verwaltet und ältere Konten nach einem Kontenwechsel nicht versehentlich unverwaltet zurückbleiben.
How EtcSec Detects This
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.
ℹ️ Note: EtcSec prüft fehlende oder inkonsistente LAPS-Abdeckung automatisch in Active-Directory-Audits und trennt so „Feature vorhanden“ von „Feature schützt tatsächlich die Endgeräte“.
Official References
- Microsoft Learn: What is Windows LAPS?
- 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
Related Reading
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.
