Titelbild: Windows LAPS in der Praxis – lokale Admin-Passwörter unter Kontrolle

Es ist der Klassiker, der in fast jeder Umgebung noch herumliegt: ein lokales Administratorkonto, dessen Passwort auf allen Rechnern identisch ist – aus dem Goldbild übernommen und nie geändert. Ein Angreifer muss nur einmal ein Kennwort-Hash auslesen und kann sich anschließend im gesamten Netz seitwärts bewegen. Genau diese Lücke schließt Windows LAPS (Local Administrator Password Solution).

In diesem Beitrag geht es nicht um die Theorie, sondern um das, was Admins in der Praxis brauchen: Was Windows LAPS heute ist, welche Voraussetzungen im Active Directory zu schaffen sind, welche Einstellungen sinnvoll sind – und wo typische Stolperfallen lauern.

Was Windows LAPS ist – und was sich geändert hat

Windows LAPS verwaltet und sichert automatisch das Kennwort eines lokalen Administratorkontos – auf Entra-joined oder Active-Directory-gejointen Geräten, auf Wunsch auch das DSRM-Konto von Domaincontrollern. Das Kennwort wird regelmäßig rotiert, sicher abgelegt und kann von berechtigten Administratoren abgerufen werden.

Die wichtigste Änderung: Windows LAPS ist seit den Windows-Updates vom 11. April 2023 fest im Betriebssystem enthalten. Es muss kein MSI mehr installiert werden. Damit ist die alte „Microsoft LAPS“-Lösung aus dem Download Center abgelöst:

  • Das Legacy-LAPS-Produkt ist ab Windows 11 23H2 und neuer deprecated; neuere Systeme blockieren die Installation des MSI-Pakets sogar.
  • Windows LAPS kann komplette Features nutzen, die Legacy-LAPS nicht hatte: Kennwortverschlüsselung im AD, Kennwort-Historie und Sicherung nach Entra ID.
  • Für die Migration bestehender Installationen gibt es einen Legacy-Emulationsmodus, in dem Windows LAPS die vorhandenen alten Gruppenrichtlinien weiter beachtet.

Ein Hinweis zum Lebenszyklus: Windows 10 hat den Support am 14. Oktober 2025 beendet. Windows LAPS ist auf Windows 10 nur noch auf Geräten verfügbar, die weiterhin Updates erhalten – etwa über das ESU-Programm. Für Neuinstallationen ist Windows 11 die richtige Basis.

Sichern nach Entra ID oder ins AD – nicht beides

Wohin das Kennwort gesichert wird, hängt von der Join-Art ab:

  • Nur Entra ID gejoint → Sicherung nur nach Entra ID.
  • Nur AD gejoint → Sicherung nur in den Windows Server Active Directory.
  • Hybrid gejoint → entweder Entra ID oder AD – aber niemals in beide Ziele gleichzeitig.

Workplace-joined Geräte werden nicht unterstützt. Für rein cloudbasierte Umgebungen braucht es also keine Schema-Erweiterung – der Aufwand beginnt erst, wenn Sie ins AD sichern wollen.

Voraussetzungen im Active Directory

Der klassische On-Premises-Weg erfordert drei Schritte. Der erste ist eine einmalige Aktion für die gesamte Gesamtstruktur:

PS C:\> Update-LapsADSchema

Das Schema-Update lässt sich auf einem Domaincontroller ab Windows Server 2019 ausführen – oder auf einem beliebigen Server, der das Windows-LAPS-PowerShell-Modul unterstützt.

Danach braucht jedes verwaltete Gerät das Recht, sein eigenes Kennwort zu schreiben. Das wird als vererbbare Berechtigung auf der OU gesetzt, in der die Geräte liegen:

PS C:\> Set-LapsADComputerSelfPermission -Identity NewLaps

Für die Lese- und Zurücksetzrechte gibt es eigene Cmdlets:

PS C:\> Set-LapsADReadPasswordPermission -Identity NewLAPS -AllowedPrincipals @("laps\LapsPasswordReadersGroup")
PS C:\> Set-LapsADResetPasswordPermission -Identity NewLAPS -AllowedPrincipals @("laps\Helpdesk")

Die unsichtbare Falle: Extended Rights

Wenn Benutzer oder Gruppen auf der OU eines verwalteten Geräts das Recht Extended Rights besitzen, ist das ein Problem. Denn alle LAPS-Kennwortattribute sind als vertraulich (confidential) markiert – wer dieses Recht hat, kann sie lesen. Prüfen Sie das vor dem Rollout:

PS C:\> Find-LapsADExtendedRights -Identity NewLAPS

Domain Functional Level

Ein Punkt, der viele Planungen kippt: Ist der Domain Functional Level (DFL) älter als 2016, lässt sich die Kennwortverschlüsselung im AD nicht aktivieren. Dann gilt:

  • Kennwörter liegen nur im Klartext im AD, geschützt allein durch ACLs.
  • Domaincontroller können ihr DSRM-Konto nicht verwalten.

Ab DFL 2016 ist die Verschlüsselung möglich – allerdings unterstützen Domaincontroller mit Windows Server 2016 und älter Windows LAPS nicht und können daher kein DSRM-Konto pflegen. Kurz: Vor dem Rollout das DFL und den DC-Bestand prüfen.

Die Gruppenrichtlinie richtig konfigurieren

Für AD-gesicherte Kennwörter ist eine Einstellung Pflicht: BackupDirectory muss auf den Wert 2 gesetzt sein. Alle weiteren Werte haben dokumentierte Standardeinstellungen, die man kennen sollte:

  • AdministratorAccountName – ohne Angabe wird das eingebaute lokale Administratorkonto verwaltet, identifiziert über seine RID (nicht über den Namen). Ein eigenes Konto muss vorher existieren; Windows LAPS legt es nicht an.
  • PasswordAgeDays – Standard 30 Tage.
  • PasswordLength – Standard 14 Zeichen.
  • PasswordComplexity – Standard 4.
  • PostAuthenticationActions – Standard 3 (Kennwort zurücksetzen und abmelden).

Zwei Warnungen zu den Werten: Konfigurieren Sie PasswordLength oder PasswordComplexity niemals so, dass sie mit der lokalen Kennwortrichtlinie des Geräts kollidieren – Windows LAPS kann sonst kein gültiges Kennwort erzeugen (Ereignis 10027 im LAPS-Log). Und: Wird die Verschlüsselung aktiviert, aber ADPasswordEncryptionPrincipal nicht gesetzt, können standardmäßig nur Domänen-Admins entschlüsseln. Wer den Helpdesk mit einbeziehen will, muss das explizit konfigurieren. Zu beachten ist außerdem, dass Windows LAPS alle bekannten Registry-Wurzeln von oben nach unten durchsucht und die erste Wurzel mit mindestens einer expliziten Einstellung als aktive Richtlinie verwendet wird – fehlende Werte darin werden auf ihre Standardwerte gesetzt.

Betrieb: Abrufen, Rotieren, Prüfen

Windows LAPS verarbeitet die aktive Richtlinie stündlich; auf Richtlinien-Änderungsbenachrichtigungen reagiert es zusätzlich. Für Tests lohnt sich die sofortige Verarbeitung:

PS C:\> Invoke-LapsPolicyProcessing

Kennwörter abrufen, Rotation erzwingen und Ablaufzeiten setzen:

PS C:\> Get-LapsADPassword -Identity lapsAD2 -AsPlainText
PS C:\> Reset-LapsPassword
PS C:\> Set-LapsADPasswordExpirationTime -Identity lapsAD2

Für den Notfall gibt es eine wichtige Ergänzung: Normalerweise braucht der Abruf einen erreichbaren Domaincontroller. Sind alle DCs down, lassen sich Kennwörter aus einem gemounteten Backup der AD-Datenbank auslesen – mit Get-LapsADPassword und dem Parameter -Port. Das ist ein starkes Argument dafür, Domaincontroller-Backups wirklich regelmäßig zu machen und zu testen.

Checkliste für den Rollout

  1. DFL und DC-Bestand prüfen (Verschlüsselung erst ab DFL 2016, DSRM ab Windows Server 2019).
  2. Schema erweitern (einmalig pro Gesamtstruktur).
  3. OU-Berechtigungen setzen: Self-Permission, Read-, Reset-Rechte.
  4. Find-LapsADExtendedRights prüfen und unnötige Rechte entfernen.
  5. GPO: BackupDirectory setzen, Länge und Komplexität zur lokalen Richtlinie passend wählen.
  6. Klassisches Legacy-LAPS deinstallieren, wenn migriert wird – sonst greift der Emulationsmodus nicht.
  7. Testgerät: Ereignis-Log-Kanal für Windows LAPS beobachten, Abruf testen.
  8. Kennwort-Historie und Verschlüsselung bewusst entscheiden, inklusive ADPasswordEncryptionPrincipal.

Fazit

Windows LAPS ist kein Projekt, sondern eine Grundeinstellung, die man einmal sauber aufsetzt. Der Aufwand ist überschaubar: Schema-Update, drei Berechtigungs-Cmdlets, eine GPO. Der Gewinn ist groß – jedes Gerät hat sein eigenes, regelmäßig gewechseltes lokales Adminkennwort, und laterale Bewegung über ein identisches Hash ist deutlich erschwert.

Der häufigste Fehler ist nicht die Technik, sondern die Reihenfolge: erst das DFL und die Berechtigungen klären, dann die Richtlinie ausrollen. Wer in dieser Reihenfolge vorgeht, hat selten Ärger.

Quellen

Stand: September 2026. Die Angaben zu Standardwerten und Cmdlets folgen der offiziellen Microsoft-Dokumentation.

Tags

No responses yet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert