Windows LAPS in der Praxis — Schluss mit dem für alle PCs gleichen lokalen Administratorkennwort

Beim PC-Kitting hält sich seit Langem ein „bewährter Kniff, der eigentlich keiner sein sollte“: Man brennt ein gemeinsames lokales Administratorkennwort in das Master-Image und rollt es auf alle Geräte aus — beim Warten muss man sich dann nur mit diesem Kennwort anmelden, was als Vorgehen durchaus vernünftig wirkt. Doch genau diese Konstruktion ist inzwischen einer der ersten Punkte, auf die Angreifer zielen, weil sie einer massenhaften Vervielfältigung eines einzigen Generalschlüssels gleichkommt: Ist ein Gerät kompromittiert, sind es faktisch alle.

Dieser Artikel richtet sich an IT-Verantwortliche in kleinen und mittleren Unternehmen sowie an Entwickler, die PC-Kitting und Wartungsbetrieb übernehmen. Er ordnet zunächst ein, warum ein für alle PCs gemeinsames lokales Administratorkennwort gefährlich ist, und erklärt dann — gestützt auf Primärquellen mit Stand August 2026 — die Funktionsweise der ins Betriebssystem integrierten Lösung Windows LAPS (Local Administrator Password Solution), die Auswahl der passenden Konfiguration je nach Umgebung, das Vorgehen bei der Einführung sowie die Fallstricke im laufenden Betrieb. Er ist die Fortsetzung unserer Sicherheitsreihe für die IT-Abteilung, die bereits BitLocker, die Abschaffung von WSUS, Firewalls und den Zertifikatspeicher behandelt hat.

1. Das Wichtigste zuerst

• Ein für alle PCs gemeinsames lokales Administratorkennwort ist der Nährboden für laterale Bewegung (Lateral Movement), bei der sich die Kompromittierung eines Geräts auf alle anderen ausbreitet. Ist das Kennwort überall gleich, ist auch der NTLM-Hash überall gleich — wird der Hash auf einem Gerät entwendet, kann ein Angreifer sich per Pass-the-Hash auf alle übrigen Geräte einloggen.¹
• Windows LAPS ist eine im OS eingebaute Standardfunktion, die das lokale Administratorkennwort pro Gerät randomisiert und automatisch rotiert. Microsoft nennt den Schutz vor Pass-the-Hash- und Lateral-Movement-Angriffen als wichtigsten Vorteil.¹
• Es ist ab dem Update vom 11. April 2023 in Windows 10/11 sowie in Windows Server 2019/2022 und neuer eingebaut. Anders als beim alten LAPS (MSI-Verteilung) ist keine zusätzliche Installation nötig. Das alte LAPS wurde ab Windows 11 23H2 deprecated.¹
• Das Kennwort wird entweder in Active Directory oder in Microsoft Entra ID gespeichert — nur in einem von beiden. Rein domänenbeigetretene Geräte speichern in AD, rein Entra-beigetretene in Entra ID, hybrid beigetretene Geräte wählen eines von beidem. Auf Arbeitsgruppengeräten, die keinem von beiden beigetreten sind, lässt es sich nicht nutzen.¹
• Standardmäßig passiert nichts. BackupDirectory ist per Voreinstellung „deaktiviert“ — erst wenn eine Richtlinie (GPO oder Intune/CSP) den Speicherort explizit festlegt, beginnt Windows LAPS zu arbeiten.²
• Bei AD-Speicherung sind drei Vorbereitungsschritte nötig: Schemaerweiterung (Update-LapsADSchema), das Schreibrecht der Computer auf ihr eigenes Attribut (Set-LapsADComputerSelfPermission) und die Gestaltung der Leseberechtigung (Set-LapsADReadPasswordPermission).³
• Das Kennwort rufen Sie mit Get-LapsADPassword / Get-LapsAADPassword ab, sofortige Richtlinienwirkung erzwingen Sie mit Invoke-LapsPolicyProcessing, und die sofortige Rotation auf dem Gerät selbst lösen Sie mit Reset-LapsPassword aus.⁴
• Ein einmal verwendetes Kennwort wird automatisch zum Wegwerfartikel. Nach der Authentifizierung mit dem verwalteten Konto läuft standardmäßig nach 24 Stunden ein Zurücksetzen samt Abmeldung (PostAuthenticationActions).²

2. Warum ein für alle PCs gemeinsames lokales Administratorkennwort gefährlich ist

Zunächst zum genauen Bedrohungsbild. Was passiert, wenn das lokale Administratorkonto — sei es das eingebaute Administrator-Konto oder ein bei der Kitting-Phase angelegtes Wartungskonto — auf allen Geräten dasselbe Kennwort trägt?

Windows speichert das Kennwort eines lokalen Kontos nicht im Klartext, sondern als aus dem Kennwort berechneten NT-Hash. Und bei der NTLM-Authentifizierung dient genau dieser Hash selbst als Authentifizierungsmaterial. Das heißt: Ist das Kennwort gleich, ist auch der Hash auf allen Geräten gleich. Erlangt ein Angreifer per Malware oder gezieltem Angriff Administratorrechte auf einem Gerät, kann er den Hash aus dessen Arbeitsspeicher oder der lokalen Datenbank (SAM) extrahieren. Ab hier wird es ernst: Der extrahierte Hash lässt sich unmittelbar zur Authentifizierung verwenden, ohne ihn erst in ein Klartextkennwort zurückzuverwandeln. Das ist der Pass-the-Hash-Angriff. In einer Umgebung mit gemeinsamem Kennwort wird der von einem Gerät erbeutete Hash zum „Generalschlüssel“ für alle übrigen, und die Kompromittierung breitet sich in einem Schritt seitwärts aus. Wie NTLM-Authentifizierung funktioniert und warum allein der Hash zur Authentifizierung genügt, erklärt „NTLM und Kerberos anhand von Diagrammen erklärt“ im Detail.

flowchart TB
    subgraph BEFORE["Umgebung mit gemeinsamem Kennwort"]
        A1["PC-01 kompromittiert<br/>(Malware, gezielter Angriff)"] --> H["NT-Hash des Administrators erbeutet"]
        H -->|"Pass-the-Hash"| B1["PC-02"]
        H -->|"Pass-the-Hash"| B2["PC-03"]
        H -->|"Pass-the-Hash"| B3["…laterale Bewegung auf alle Geräte"]
    end
    subgraph AFTER["Nach Einführung von LAPS"]
        C1["PC-01 kompromittiert"] --> H2["Hash von PC-01 erbeutet"]
        H2 -->|"Da das Kennwort pro Gerät verschieden ist,"| STOP["funktioniert dieser Hash auf<br/>keinem anderen PC (unterbindet laterale<br/>Bewegung über lokale Admin-Konten)"]
    end

Abbildung 1: Ausbreitung per Pass-the-Hash vor und nach der Einführung von LAPS

Die Richtung der Lösung ist klar: jedem Gerät ein eigenes lokales Administratorkennwort geben und dieses regelmäßig ändern. Dann bleibt der Hash eines Geräts, selbst wenn er durchsickert, für die übrigen nutzlos, und der laterale Angriffsweg über die Wiederverwendung des lokalen Administratorkontos ist versperrt (beachten Sie dabei, dass damit nicht jeder laterale Angriffsweg geschlossen wird — etwa der Diebstahl von Domänenanmeldeinformationen auf einem kompromittierten PC bleibt ein separates Problem). Das von Hand zu erledigen, ist allerdings unrealistisch. Kennwörter für Dutzende Geräte einzeln zu erzeugen, in einem Verzeichnis zu führen und regelmäßig durchzuwechseln — genau dieser hohe Betriebsaufwand ist der Grund, warum der Kniff mit dem gemeinsamen Kennwort so lange überlebt hat. Windows LAPS ist die Antwort des Betriebssystems: Es übernimmt diese „Automatisierung von Individualisierung und regelmäßigem Wechsel“ zusammen mit der sicheren Speicherung im Verzeichnis. Microsoft selbst nennt „Schutz vor Pass-the-Hash- und Lateral-Traversal-Angriffen“ als wichtigsten Vorteil von Windows LAPS.¹

Zum grundlegenderen Prinzip der Rechteverwaltung — Alltagsarbeit von vornherein nicht unter einem Administratorkonto erledigen und den Einsatzbereich von Wartungskonten eng fassen — siehe auch „Wann werden unter Windows tatsächlich Administratorrechte benötigt?“.

3. Was ist Windows LAPS — der Unterschied zum alten LAPS

Der Name LAPS hat eine Geschichte, und in der Praxis geht ein Gespräch am Thema vorbei, wenn nicht klar ist, „von welchem LAPS“ gerade die Rede ist.

Das alte LAPS (Legacy Microsoft LAPS) ist ein 2016 von Microsoft veröffentlichtes, separat zu installierendes Tool.¹ Es verteilt ein MSI-Paket auf alle Geräte, installiert damit eine Group-Policy-Erweiterung (CSE) und speichert das Kennwort im Klartext im Attribut ms-Mcs-AdmPwd von Active Directory — lange Zeit der faktische Standard.

Windows LAPS ist der Nachfolger: eine separate, ins Betriebssystem eingebaute Implementierung. Es ist ab dem Update vom 11. April 2023 in Windows 10, Windows 11 21H2/22H2 sowie Windows Server 2019/2022 enthalten; Windows 11 23H2 und neuer sowie Windows Server 2025 und neuer bringen es von Anfang an mit.¹ Mit anderen Worten: Wenden Sie Updates normal an, steckt Windows LAPS in den PCs Ihres Unternehmens bereits drin. Es bleibt nur noch, eine Richtlinie zu konfigurieren.

Entscheidend ist: Windows LAPS ist kein überarbeitetes altes LAPS, sondern eine vollständig eigenständige Implementierung, deren AD-Schemaattribute (msLAPS-*) ebenfalls vom alten LAPS getrennt sind.⁴ Um die Migration vom alten LAPS zu erleichtern, gibt es zwar einen „Emulationsmodus“, in dem Windows LAPS die GPO-Einstellungen des alten LAPS interpretiert und danach arbeitet, dieser bringt aber viele Einschränkungen mit sich (Abschnitt 6), sodass es bei einer Neueinführung keinen Grund gibt, ihn eigens zu nutzen.

4. Wo das Kennwort gespeichert wird — eine Entscheidungstabelle nach Umgebung

Windows LAPS „sichert“ das generierte Kennwort in einem Verzeichnis. Der Speicherort richtet sich nach dem Beitrittsstatus des Geräts, und eine Speicherung sowohl in AD als auch in Entra ID ist nicht möglich.¹

Bei AD-Speicherung wird das Kennwort in ein Attribut des Computerobjekts geschrieben — im Klartext in msLAPS-Password, bei aktivierter Verschlüsselung in msLAPS-EncryptedPassword, das Ablaufdatum in msLAPS-PasswordExpirationTime.⁶ Von diesen sind die kennwortführenden Attribute (msLAPS-Password und die verschlüsselungsbezogenen msLAPS-Encrypted*) als vertraulich (confidential) markiert und mit gewöhnlicher Leseberechtigung nicht einsehbar. Das Ablaufattribut msLAPS-PasswordExpirationTime dagegen trägt keine Vertraulichkeitsmarkierung (SearchFlags: 0) und ist Metadaten, die mit der Standard-Leseberechtigung einsehbar sind.⁶ Für verschlüsselte Speicherung und Kennworthistorie ist Domänenfunktionsebene (DFL) 2016 oder höher erforderlich.³ Beachtenswert ist, dass die Verschlüsselungseinstellung (ADPasswordEncryptionEnabled) standardmäßig aktiviert ist.² In einer Domäne mit einer DFL älter als 2016 funktioniert Verschlüsselung nicht — verlassen Sie sich nicht darauf, dass sie stillschweigend auf Klartext umschaltet, sondern deaktivieren Sie die Verschlüsselung in der Richtlinie explizit und konfigurieren Sie stattdessen Klartext plus ACL-Schutz.³

Bei Speicherung in Entra ID ist die Standardkonfiguration, „die Verwaltung lokaler Administratorkennwörter“ auf Tenant-Seite zu aktivieren und die Richtlinie anschließend über Intune per LAPS-CSP zu verteilen. Lizenzseitig ist die Funktion von Windows LAPS selbst kostenlos, für AD-Speicherung bestehen keine zusätzlichen Anforderungen, und auch die Speicherung in Entra ID lässt sich bereits ab Microsoft Entra ID Free nutzen.¹

Dass es für Arbeitsgruppengeräte keine Alternative gibt, lässt sich nicht umgehen, solange kein Verzeichnis als Speicherort existiert. In der Praxis bedeutet das eine manuelle Vorgehensweise: bei der Kitting-Phase pro Gerät ein anderes Kennwort setzen und in einem Passwortmanager oder Ähnlichem verzeichnen. Ist das Kitting bereits skriptgesteuert, ist es am sichersten, die Erzeugung geräteindividueller Kennwörter direkt in dieses Skript einzubauen (siehe „PC-Kitting mit winget + PowerShell automatisieren“).

5. Die Einführung in der Praxis — mit Schwerpunkt auf AD+GPO

Dieser Abschnitt geht das eigentliche Vorgehen mit Schwerpunkt auf einer AD-Domäne + GPO-Konfiguration durch, da dies den mit Abstand häufigsten Fall abdeckt. Die Unterschiede bei einer Entra+Intune-Konfiguration sind am Ende zusammengefasst.

5.1. Vorbereitung (einmalige Arbeit)

Bei AD-Speicherung schließen Sie die forestweite Vorbereitung ab, bevor Sie irgendeine Richtlinie verteilen.³

# 1. Schemaerweiterung (einmal pro Forest; mit Schema-Admins-Rechten ausführen)
Update-LapsADSchema

# 2. Computern unter der Ziel-OU das Recht erteilen, ihr eigenes Kennwortattribut zu aktualisieren
Set-LapsADComputerSelfPermission -Identity "OU=Firmen-PCs,DC=example,DC=co,DC=jp"

# 3. Einer Gruppe das Leserecht für das Kennwort erteilen (Domain Admins können standardmäßig lesen)
Set-LapsADReadPasswordPermission -Identity "OU=Firmen-PCs,DC=example,DC=co,DC=jp" `
    -AllowedPrincipals @("EXAMPLE\HelpdeskAdmins")

# 4. Einer Gruppe das Recht erteilen, das Kennwortablaufdatum zu setzen (= sofortiges Zurücksetzen erzwingen)
#    (wird für Set-LapsADPasswordExpirationTime in 5.4 benötigt; Domain Admins besitzen es standardmäßig)
Set-LapsADResetPasswordPermission -Identity "OU=Firmen-PCs,DC=example,DC=co,DC=jp" `
    -AllowedPrincipals @("EXAMPLE\HelpdeskAdmins")

# 5. Prüfen, ob unerwartete Inhaber der Leseberechtigung vorhanden sind (Details in Abschnitt 6)
Find-LapsADExtendedRights -Identity "OU=Firmen-PCs,DC=example,DC=co,DC=jp"

Nutzen Sie verschlüsselte Speicherung (DFL 2016+, standardmäßig aktiviert), ist eine weitere Einstellung nötig. Leseberechtigung und Entschlüsselungsberechtigung sind zwei verschiedene Dinge, und standardmäßig können nur Domain Admins entschlüsseln.³ Soll die Helpdesk-Gruppe das Kennwort tatsächlich abrufen können, geben Sie dieselbe Gruppe (EXAMPLE\HelpdeskAdmins) auch bei ADPasswordEncryptionPrincipal in der Richtlinie an.² Vergessen Sie das, landen Sie trotz Leseberechtigung genau wie oben beschrieben in einem Zustand, in dem das Attribut zwar lesbar, aber nicht entschlüsselbar ist.

Update-LapsADSchema ist etwas anderes als das Update-AdmPwdADSchema des alten LAPS; hinzugefügt werden die msLAPS-*-Attribute. Auch in einer Umgebung mit bereits vorhandenem altem LAPS ist die Schemaerweiterung für Windows LAPS erneut erforderlich.⁴ Beachten Sie außerdem: Nutzen Sie einen zentralen GPO-Speicher (Central Store), kopiert Windows Update die Windows-LAPS-Vorlagen nicht automatisch in diesen Speicher — Sie müssen sie manuell kopieren.² Kopieren Sie dabei nicht nur %windir%\PolicyDefinitions\LAPS.admx, sondern auch die Sprachressource LAPS.adml (im Unterordner de-DE bei deutscher Benutzeroberfläche) in den passenden Sprachordner. Fehlt die ADML-Datei, zeigt die GPMC bei der LAPS-Richtlinie einen Ressourcenfehler an.

5.2. Richtlinie konfigurieren

Der Ort der GPO-Einstellung ist „Computerkonfiguration > Richtlinien > Administrative Vorlagen > System > LAPS“.² Die minimal erforderliche Einstellung ist die Angabe des Speicherorts — solange BackupDirectory nicht auf „Active Directory“ (Wert 2) gesetzt ist, tut Windows LAPS gar nichts (Standardwert: „deaktiviert“).² Die wichtigsten Einstellungen mit ihren Standardwerten:

Leicht übersehen wird hier, ob das verwaltete Konto aktiviert oder deaktiviert ist. Das eingebaute Administrator-Konto ist bereits ab der Windows-Einrichtung deaktiviert.⁷ Windows LAPS verwaltet das Kennwort auch für ein weiterhin deaktiviertes Konto, aktiviert das Konto aber nicht selbst.² Das heißt, unter der Standardkonfiguration kann der Zustand entstehen, dass zwar ein Kennwort im Verzeichnis liegt, sich damit aber niemand anmelden kann. Um es als Wiederherstellungsmittel zu nutzen, wählen Sie explizit eine der folgenden Optionen: das eingebaute Administrator-Konto aktivieren und betreiben, ein bereits aktiviertes benutzerdefiniertes Wartungskonto verwalten lassen, oder ab Windows 11 24H2 / Server 2025 den Aktivierungszustand selbst über die automatische Kontoverwaltung (Einstellungsfamilie AutomaticAccountManagement) mitverwalten.²

5.3. Funktionskontrolle und Kennwortabruf

Windows LAPS verarbeitet eine wirksame Richtlinie einmal pro Stunde. Wollen Sie nicht so lange warten, führen Sie auf dem Zielgerät eine sofortige Verarbeitung aus.³

# Auf dem Gerät: Richtlinie sofort verarbeiten (Standardvorgehen beim Testen)
Invoke-LapsPolicyProcessing

# Auf dem Gerät: Ergebnis im Ereignisprotokoll prüfen
# 10003 = Verarbeitung gestartet / 10004 = Erfolg / 10005 = Fehler / 10018 = erfolgreich in AD gespeichert
Get-WinEvent -LogName "Microsoft-Windows-LAPS/Operational" -MaxEvents 20

Das gespeicherte Kennwort rufen Sie von einem berechtigten Verwaltungsgerät ab.³

# Kennwort aus AD abrufen (ohne -AsPlainText bleibt der String maskiert)
Get-LapsADPassword -Identity PC-0123 -AsPlainText

# Beispielausgabe: liefert Account, Password, PasswordUpdateTime, ExpirationTimestamp,
#                  Source (bei EncryptedPassword verschlüsselte Speicherung), AuthorizedDecryptor u. a.

Für GUI-Freunde: In „Active Directory-Benutzer und -Computer“ wurde den Eigenschaften eines Computers ein LAPS-Reiter hinzugefügt, über den sich das Kennwort ebenfalls nachschlagen lässt.¹

5.4. Sofortige Rotation

Ist ein Kennwort nach Wartungsarbeiten aufgebraucht oder besteht Verdacht auf eine Kompromittierung, rotieren Sie es sofort, statt die nächste planmäßige Rotation abzuwarten.³

# Vom Verwaltungsgerät aus: Ablaufdatum auf „jetzt“ setzen, sodass die nächste Verarbeitung rotiert
Set-LapsADPasswordExpirationTime -Identity PC-0123
# Sofortige Verarbeitung auf dem Zielgerät anstoßen, dann wechselt es sofort auf ein neues Kennwort
Invoke-LapsPolicyProcessing

# Um direkt auf dem Zielgerät sofort zu rotieren
Reset-LapsPassword

5.5. Abweichungen bei einer Entra+Intune-Konfiguration

Bei Speicherung in Entra ID sind Schemaerweiterung und ACL-Konfiguration wie bei AD nicht nötig.³ Stattdessen müssen Sie unter [Geräteeinstellungen] des Microsoft-Entra-Tenants die Verwaltung lokaler Administratorkennwörter aktivieren — vergessen Sie das, können Geräte kein Kennwort speichern.⁵ Die Richtlinie verteilen Sie von Intune über das LAPS-CSP, und das Kennwort rufen Sie über die Bildschirme des Entra Admin Centers / Intune Admin Centers oder über Microsoft Graph mit Get-LapsAADPassword ab.⁵

# In Entra ID gespeichertes Kennwort per Graph abrufen (Beispiel: delegierter Zugriff)
# Bei der Verbindung explizit die benötigten Berechtigungen anfordern
Connect-MgGraph -Scopes "Device.Read.All","DeviceLocalCredential.Read.All"
Get-LapsAADPassword -DeviceIds PC-0123 -IncludePasswords -AsPlainText

Der Ereigniscode für eine erfolgreiche Speicherung ist bei AD 10018, bei Entra ID 10029.⁸

6. Fallstricke im laufenden Betrieb

Mit der Einführung ist es nicht getan. Hier, der Reihe nach, die Punkte, an denen man in der Praxis tatsächlich stolpert.

6.1. Die Leseberechtigung ist weiter gefasst, als man denkt

Da das Kennwortattribut als vertraulich (confidential) markiert ist, ist es mit gewöhnlicher Leseberechtigung nicht einsehbar — aber ein Prinzipal, der auf der Ziel-OU über das erweiterte Recht All Extended Rights verfügt, kann es lesen. In Umgebungen, in denen in der Vergangenheit weitreichende Berechtigungen an eine OU delegiert wurden, führt das dazu, dass unerwartete Gruppen das Kennwort lesen können. Ermitteln Sie bei der Einführung mit Find-LapsADExtendedRights die Inhaber erweiterter Rechte, und überprüfen Sie die Delegation, sobald jemand außer SYSTEM und Domain Admins auftaucht.³

Zusätzlich lässt sich mit aktivierter verschlüsselter Speicherung (ADPasswordEncryptionEnabled) die Leseberechtigung von der Entschlüsselungsberechtigung trennen. Allein die Leseberechtigung erlaubt keine Entschlüsselung des verschlüsselten Kennworts; standardmäßig können nur Domain Admins entschlüsseln, und zum Ändern legen Sie mit ADPasswordEncryptionPrincipal fest, welche Gruppe entschlüsseln darf.³ Feingranulare Einschränkungen wie „der Helpdesk kann nur Kennwörter für seine eigene OU entschlüsseln“ gestalten Sie über dieses zweistufige Konzept.

6.2. Das Prinzip „einmal benutzt, sofort verbraucht“ und seine Grenzen — PostAuthenticationActions

Ein vom Helpdesk abgerufenes Kennwort bringt nichts, wenn es einfach auf einem Notizzettel oder in einem Chat liegen bleibt. Windows LAPS erkennt die Authentifizierung mit dem verwalteten Konto und räumt automatisch auf, sobald eine Karenzzeit (PostAuthenticationResetDelay, standardmäßig 24 Stunden) verstrichen ist. Die Standardaktion ist „Kennwort zurücksetzen und abmelden“.²

Zwei Punkte sind zu beachten. Erstens deaktiviert eine Karenzzeit von 0 diese Funktion vollständig.² Zweitens: Der Auslöser ist „Authentifizierung“, nicht „Abrufen des Kennworts“. Wird das Kennwort nur aus dem Verzeichnis geholt, aber nie tatsächlich genutzt, greift dieses automatische Zurücksetzen nicht. Zuverlässig ist es, unabhängig davon, ob das abgerufene Kennwort tatsächlich verwendet wurde, es beim Abschluss der Arbeit fest im Ablauf mit Set-LapsADPasswordExpirationTime ablaufen zu lassen.

6.3. Koexistenz mit und Migration vom alten LAPS

Am gefährlichsten während der Migrationsphase ist der Zustand, in dem dasselbe Konto sowohl vom alten LAPS als auch von Windows LAPS verwaltet wird. Eine Konfiguration, in der zwei Mechanismen sich um das Kennwort desselben Kontos streiten, ist ein Sicherheitsrisiko und wird nicht unterstützt.⁹ Die Regeln zusammengefasst:

• Auf einem Gerät, auf dem auch nur eine Windows-LAPS-Richtlinie angewendet wird, ignoriert Windows LAPS selbst stets die Richtlinie des alten LAPS (Windows LAPS hat Vorrang).⁹ Das ist allerdings nur eine Aussage darüber, wie Windows LAPS die Lage interpretiert. Ist die CSE (Group-Policy-Erweiterung) des alten LAPS weiterhin installiert, verarbeitet die alte CSE das alte GPO unabhängig weiter. Belassen Sie das Gerät im Geltungsbereich des alten GPO und aktivieren gleichzeitig die Windows-LAPS-Richtlinie, entsteht eine Doppelverwaltung, bei der beide Seiten dasselbe Konto rotieren.
• Der „Emulationsmodus“, in dem Windows LAPS die GPO-Einstellungen des alten LAPS verarbeitet, funktioniert nur auf Geräten, auf denen die CSE des alten LAPS nicht installiert ist. Er übernimmt unverändert die Voraussetzungen der alten Umgebung (altes Schema, alte ACLs), neuere Funktionen wie Verschlüsselung oder Entra-Speicherung stehen aber nicht zur Verfügung.⁹
• Allein durch ein OS-Update kann ein Gerät, auf dem noch ein GPO des alten LAPS anliegt, unbeabsichtigt in den Emulationsmodus wechseln. Möchten Sie eine unerwartete Kennwortänderung direkt nach dem Kitting vermeiden, können Sie die Emulation stoppen, indem Sie im lokalen Konfigurationsschlüssel BackupDirectory=0 setzen.⁹

Die Migration erfolgt in der Reihenfolge „Ziel-OU aus dem Geltungsbereich des alten LAPS-GPO herausnehmen (oder die alte CSE deinstallieren) → Windows-LAPS-Richtlinie anwenden → Reste des alten GPO und der alten CSE entfernen“: erst die alte Verwaltung abschalten, dann die neue aktivieren, sodass geräteweise stets eindeutig ist, welchem Verwaltungsregime es untersteht. In umgekehrter Reihenfolge (zuerst die Windows-LAPS-Richtlinie anwenden) entsteht auf jedem Gerät mit verbliebener alter CSE die oben beschriebene Doppelverwaltung.

6.4. Auditing — festhalten, wer wann eingesehen hat

Wer lokale Administratorkennwörter zentral speichert, muss deren Einsichtshistorie auditieren. Auf Geräteseite wird alles in einem eigenen Ereignisprotokollkanal erfasst (Ereignisanzeige: „Anwendungs- und Dienstprotokolle > Microsoft > Windows > LAPS > Operational“), wo sich Verarbeitungsstart (10003), Erfolg (10004), Fehler (10005), erfolgreiche Speicherung (10018 bei AD / 10029 bei Entra) sowie Inhalte der angewendeten Richtlinie (10021–10023) unter anderem einsehen lassen.⁸ Auf AD-Seite konfiguriert Set-LapsADAuditing die Ziel-OU so, dass der Zugriff auf das Kennwortattribut im Sicherheitsprotokoll des Domänencontrollers erfasst wird.⁴ Bei Speicherung in Entra ID verfolgen Sie den Zugriff über die eigenen Überwachungsprotokoll- und Berichtsfunktionen von Entra.¹

7. Zusammenfassung

• Ein für alle PCs gemeinsames lokales Administratorkennwort schafft die Konstruktion, dass sich die Kompromittierung eines Geräts per Pass-the-Hash auf alle anderen ausbreitet. Individualisierung pro Gerät und automatische Rotation sind die Lösung, und Windows LAPS liefert genau das.
• Windows LAPS ist bereits ab dem Update vom April 2023 in Windows 10/11 sowie in Windows Server 2019/2022 und neuer eingebaut — eine zusätzliche Installation ist nicht nötig. Das alte LAPS (MSI-Verteilung) ist inzwischen deprecated, sodass bei Neueinführungen nur noch Windows LAPS infrage kommt.
• Der Speicherort ist entweder AD oder Entra ID, festgelegt durch den Beitrittsstatus des Geräts. Auf Arbeitsgruppengeräten lässt es sich nicht nutzen — hier braucht es entweder manuelle Einzelverwaltung oder ein Überdenken der Beitrittsform.
• Standardmäßig ist es deaktiviert. Bereiten Sie für eine AD-Konfiguration Schemaerweiterung, Selbstaktualisierungsrecht und Leseberechtigung vor — erst wenn Sie BackupDirectory per GPO setzen, beginnt es zu arbeiten.
• Der Tagesbetrieb dreht sich um PowerShell: Abrufen mit Get-LapsADPassword / Get-LapsAADPassword, sofortige Anwendung erzwingen mit Invoke-LapsPolicyProcessing, sofortige Rotation mit Reset-LapsPassword.
• Die Fallstricke sind unerwartete Einsicht über erweiterte Rechte, das Ausbleiben von PostAuthenticationActions bei bloßem Abrufen ohne Nutzung, Doppelverwaltung neben dem alten LAPS und fehlendes Auditing. Prüfen Sie bei der Einführung die Berechtigungen mit Find-LapsADExtendedRights, und legen Sie das Ablaufverfahren nach jedem Abruf fest verbindlich fest.

Verwandte Artikel

• BitLocker in der Praxis — Laufwerksverschlüsselung beginnend mit der Verwaltung des Wiederherstellungsschlüssels
• NTLM und Kerberos anhand von Diagrammen erklärt — Warum die Authentifizierung auf NTLM zurückfällt
• Wann werden unter Windows tatsächlich Administratorrechte benötigt? - UAC, geschützte Bereiche und wie man es am Design erkennt
• PC-Kitting mit winget + PowerShell automatisieren — Die Anleitung ausführbar machen
• Was ist das TPM in Windows? — Eine bebilderte Anleitung zum „Tresor, der Schlüssel niemals herausgibt“, und zum Measured Boot
• Was vor der Entsorgung eines Windows-PCs zu erledigen ist — Eine praktische Checkliste für Datenlöschung, Kontotrennung und Backups

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt das Erstellen von Automatisierungsskripten für das PC-Kitting, die Einrichtung von Endgerätesicherheitseinstellungen einschließlich der Einführung von Windows LAPS sowie die Ausarbeitung von Migrationsplänen weg von einem bestehenden Betrieb mit gemeinsamem Kennwort. Es ist kein Problem, von einem Stand wie „es gibt zwar eine Kitting-Anleitung, aber sie hängt an einer Person“ oder „wir wollen LAPS einführen, sind uns aber bei der AD-Berechtigungskonfiguration unsicher“ zu starten.

• Windows-Anwendungsentwicklung
• Technische Beratung und Design-Review
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wir betreiben bereits das alte LAPS (Microsoft LAPS, per MSI verteilt). Müssen wir etwas unternehmen?

Beginnen Sie mit der Migrationsplanung. Das alte LAPS ist ab Windows 11 23H2 deprecated, und auf neueren Betriebssystemversionen wird die MSI-Installation selbst blockiert. Aktuelle OS-Versionen (Windows 10/11 mit dem Update vom April 2023, Windows Server 2019/2022 und neuer) bringen Windows LAPS bereits eingebaut mit, sodass Sie ohne zusätzliche Installation migrieren können. Während der Übergangsphase können Sie Windows LAPS über den „Emulationsmodus für das alte LAPS“ auch weiterhin die alten Richtlinien verarbeiten lassen, das hat aber Einschränkungen: Es funktioniert nicht auf Geräten, auf denen die CSE des alten LAPS installiert ist, und neuere Funktionen wie Verschlüsselung oder die Speicherung in Entra ID stehen nicht zur Verfügung. Eine Konfiguration, in der dasselbe Konto sowohl vom alten als auch vom neuen System verwaltet wird, wird nicht unterstützt — wechseln Sie deshalb geräteweise mit einer klaren Vorstellung davon, welches System gerade zuständig ist.

Ist es unproblematisch, ein abgerufenes Kennwort nach Gebrauch einfach liegen zu lassen?

Bei der Standardkonfiguration wird es zwar automatisch aufgeräumt, aber nicht sofort. Windows LAPS besitzt PostAuthenticationActions: Es erkennt eine Authentifizierung (Anmeldung) mit dem verwalteten Konto und verarbeitet dann nach Ablauf einer Karenzzeit — standardmäßig werden Kennwort und Sitzung 24 Stunden nach der Authentifizierung zurückgesetzt beziehungsweise abgemeldet. Umgekehrt heißt das: Bis diese Karenzzeit verstrichen ist, bleibt dasselbe Kennwort gültig und verwendbar — es wird nicht im Moment der Nutzung ungültig. Außerdem greift dieser Mechanismus erst, „wenn mit dem Kennwort authentifiziert wurde“, nicht schon, „wenn es nur aus dem Verzeichnis gelesen wurde“. Zuverlässig ist nur, das Kennwort nach Abschluss der Arbeit explizit ablaufen zu lassen. Bei Speicherung in AD geschieht das mit Set-LapsADPasswordExpirationTime (dieses Cmdlet ist ausschließlich für AD-Speicherung). Bei Speicherung in Entra ID führen Sie entweder Reset-LapsPassword auf dem Zielgerät aus oder nutzen die Rotationsaktion für lokale Administratorkennwörter in Intune.

Lässt es sich auf PCs im Arbeitsgruppenbetrieb einsetzen, die weder einer Domäne noch Entra ID beigetreten sind?

Nein. Windows LAPS benötigt entweder Active Directory oder Microsoft Entra ID als Speicherort für das Kennwort, und ein Gerät, das keinem von beiden beigetreten ist, hat kein Ziel für die Sicherung. Wenn Sie beim Arbeitsgruppenbetrieb bleiben, ist die realistische Alternative der manuelle Weg: pro Gerät ein anderes lokales Administratorkennwort setzen und an einem sicheren Ort — etwa einem Passwortmanager — verzeichnen. Sobald die Gerätezahl wächst, ist es Zeit, einen Wechsel zu Entra-Beitritt (+ Intune) oder Domänenbeitritt zu erwägen, um von der zentralen Verwaltung — LAPS eingeschlossen — zu profitieren.

Wer kann das gespeicherte Kennwort einsehen?

Bei Speicherung in Active Directory können es standardmäßig nur Mitglieder von Domain Admins einsehen; anderen Benutzern oder Gruppen erteilen Sie die Berechtigung explizit mit Set-LapsADReadPasswordPermission. Auch wenn das Kennwortattribut als vertraulich (confidential) markiert ist, kann es dennoch von jedem Prinzipal gelesen werden, der auf der OU über das erweiterte Recht All Extended Rights verfügt — prüfen Sie deshalb bei der Einführung stets mit Find-LapsADExtendedRights, ob unerwartete Inhaber vorhanden sind. Aktivieren Sie zusätzlich die Verschlüsselung über ADPasswordEncryptionEnabled (erfordert Domänenfunktionsebene 2016 oder höher), können Sie den Kreis der Entschlüsselungsberechtigten über ADPasswordEncryptionPrincipal auf eine bestimmte Gruppe einschränken. Bei Speicherung in Entra ID können standardmäßig privilegierte Rollen wie der globale Administrator einsehen, und der Abruf über Microsoft Graph erfordert die Berechtigung DeviceLocalCredential.Read.All.

Ist für die Nutzung von Windows LAPS eine zusätzliche Lizenz erforderlich?

Die Funktion selbst ist kostenlos. Windows LAPS ist eine in unterstützte Windows-Versionen eingebaute Standardfunktion, und für die Speicherung von Kennwörtern in Active Directory bestehen keine zusätzlichen Lizenzanforderungen. Auch die Speicherung in Microsoft Entra ID lässt sich bereits ab einer Microsoft Entra ID Free-Lizenz nutzen. Prüfen Sie lediglich gesondert die umliegenden Entra-/Intune-bezogenen Funktionen — etwa eine Intune-Lizenz, falls Sie Richtlinien über Intune verteilen —, da diese eigene Lizenzanforderungen mit sich bringen können.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.