Ein Satz, den ich in Beratungsgesprächen regelmäßig höre: „Wir haben doch LAPS aktiviert, also sind unsere Clients jetzt geschützt.“ Das stimmt – aber eben nur für ein sehr spezifisches Problem. Und genau da entsteht die Verwirrung, mit der ich in diesem Artikel aufräumen möchte: Was Windows LAPS tatsächlich tut, wovor es wirklich schützt, und wo Administratoren fälschlicherweise glauben, damit sei das Thema „lokale Admin-Rechte“ erledigt.
Windows LAPS ist die moderne, direkt in Windows integrierte Nachfolge des klassischen Microsoft LAPS (Local Administrator Password Solution). Es verwaltet das Passwort eines lokalen Administrator-Kontos pro Gerät. also genau auf Client-/Workstation-Ebene.
Was Windows LAPS eigentlich ist
Die Kernfunktion ist unspektakulär, aber wirkungsvoll: Es rotiert automatisch und regelmäßig ein zufälliges, komplexes Passwort, damit nicht auf allen Rechnern im Unternehmen dasselbe, oft nie geänderte lokale Admin-Passwort liegt. Genau dieses Muster, ein Passwort, gültig auf hunderten Maschinen gleichzeitig, ist der klassische Lateral-Movement-Vektor, den Angreifer nach einer ersten Kompromittierung ausnutzen.
Konfiguriert wird Windows LAPS über Intune, genauer unter „Endpunktsicherheit → Kontoschutz → Windows LAPS-Richtlinie“, technisch ein CSP (Configuration Service Provider). Dort legen Sie fest, welches Konto verwaltet wird, wie oft rotiert wird, wie komplex das Passwort sein muss und was bei Ablauf passieren soll. Wichtig für das Verständnis: LAPS kümmert sich pro Gerät ausschließlich um ein benanntes lokales Konto, nicht um alle lokalen Admin-Konten, die auf einer Maschine existieren könnten.
Zwei Betriebsmodi – und ein wichtiger Unterschied bei der Kontoerstellung
Hier lohnt sich ein genauer Blick, weil sich hier in der Praxis die meisten Missverständnisse einschleichen. Windows LAPS kennt zwei Modi:
| Merkmal | Manual Account Management | Automatic Account Management |
|---|---|---|
| Verfügbarkeit | Alle unterstützten Windows-Versionen | Erst ab Windows 11 24H2, muss explizit aktiviert werden |
| Kontoerstellung | Das Konto muss bereits existieren – LAPS legt nichts neu an | LAPS kann ein benanntes Konto (z. B.„LapsAdmin“) bei Bedarf selbst als lokales Admin-Konto anlegen |
| Passwort-Rotation | Ja | Ja |
| Aktivierung/Deaktivierung des Kontos | Nicht durch LAPS gesteuert | LAPS kann das Konto selbst aktivieren/deaktivieren, optional inklusive Namensrandomisierung |
Im Standardmodus, dem Manual Account Management, verwaltet LAPS also wirklich nur das Passwort eines bereits vorhandenen Kontos. Wenn Sie in der Intune-Richtlinie einen Kontonamen wie „LapsAdmin“ eintragen und dieses Konto auf dem Gerät noch nicht existiert, passiert schlicht nichts – keine Rotation, kein Fehler, der Sie sofort anspringt. Erst mit dem Automatic-Account-Management-Modus, verfügbar ab Windows 11 24H2, kann LAPS ein solches Konto bei Bedarf selbst neu anlegen und zusätzlich dessen Aktiv-/Inaktiv-Status steuern.
„Aber das Administrator-Konto ist doch sowieso deaktiviert?“
Diese Frage bekomme ich oft, und sie trifft einen echten Punkt. Auf modernen Windows-Clients ist das eingebaute, klassische Konto „Administrator“ (mit der bekannten RID 500) tatsächlich ab Werk deaktiviert. Das ist allerdings eine allgemeine Windows-Sicherheitseinstellung und hat mit LAPS nichts zu tun. Wenn Sie LAPS auf genau dieses Konto ansetzen, bleibt es in der Regel weiterhin deaktiviert und wird nur bei Bedarf aktiviert.
In der Praxis verwalten die meisten Organisationen mit LAPS aber gar nicht das eingebaute Administrator-Konto, sondern ein separates, eigens dafür angelegtes lokales Admin-Konto oder – häufiger als man denkt – den bei der Geräteeinrichtung erstellten Erstbenutzer, der selbst Mitglied der lokalen Administratoren-Gruppe ist. Genau dieses Konto ist es typischerweise, dessen Passwort LAPS rotiert. Und dessen Aktiv-/Inaktiv-Status müssen Sie im Manual-Modus selbst im Blick behalten; LAPS rotiert das Passwort im Hintergrund brav weiter, unabhängig davon, ob das Konto gerade aktiviert ist oder nicht.
Wovor LAPS wirklich schützt
Der eigentliche Zweck von LAPS ist größer als nur „UAC-Abfragen beantworten können“, auch wenn das ein legitimer und in der Praxis häufiger Anwendungsfall ist: Sind Endnutzer als Standard-User ohne lokale Adminrechte eingerichtet – was eigentlich Best Practice ist –, kann der Helpdesk bei einer UAC-Elevation das für genau diese eine Maschine gültige, aktuelle LAPS-Passwort telefonisch durchgeben, ohne dass ein für alle Rechner gültiges Passwort im Umlauf ist.
Der größere Zweck liegt aber woanders:
- Lateral Movement verhindern: Ohne LAPS haben viele Organisationen ein einziges lokales Admin-Konto mit demselben Passwort auf allen Rechnern, häufig aus demselben Image oder derselben GPO stammend. Wird das Passwort auf einem einzigen Gerät kompromittiert – etwa per Mimikatz aus dem SAM ausgelesen –, kann sich ein Angreifer damit auf jedem anderen Rechner im Unternehmen anmelden. LAPS macht jedes dieser Passwörter pro Gerät individuell und rotiert es regelmäßig, sodass ein geknacktes Passwort nur auf genau diesem einen Gerät nutzbar ist.
- Break-Glass-Zugriff für die IT: Ist ein Gerät offline, das Domain-Trust-Verhältnis defekt, ein Nutzerkonto gesperrt oder man muss im Recovery- bzw. Autopilot-Reset-Fall lokal auf die Maschine, braucht die IT einen zuverlässigen lokalen Adminzugang. LAPS liefert dafür ein aktuelles, sicheres Passwort statt eines irgendwo fest dokumentierten.
- Wissen verjährt: Ein einmal bekanntes, statisches lokales Passwort bleibt ohne Rotation potenziell für immer gültig – und sei es nur, weil es noch in einem alten Wiki-Eintrag oder einer Chat-Historie eines längst ausgeschiedenen IT-Mitarbeiters steht. LAPS sorgt dafür, dass dieses Wissen irgendwann wertlos wird.
Der Punkt, der am häufigsten missverstanden wird: Domain Admins
Eine Frage, die mir Teilnehmer in Schulungen fast jedes Mal stellen, sobald sie einmal verstanden haben, was LAPS macht: Was hindert einen Domain Admin eigentlich daran, trotzdem auf die Maschine zu gehen? Die ehrliche Antwort: nichts – und das ist auch nicht der Zweck von LAPS.
Bei einem domänengebundenen Client haben Domain Admins (bzw. Enterprise Admins) bereits auf AD-Ebene volle Kontrolle über die Maschine, völlig unabhängig vom lokalen Admin-Passwort. Der Grund: Die Gruppe „Domain Admins“ wird bei jedem domänengebundenen Rechner standardmäßig automatisch in die lokale Administratoren-Gruppe aufgenommen. Das passiert über die Default Domain Policy beim Domain-Join. Ein Domain-Admin-Konto kann sich also mit seinen eigenen Domänen-Credentials interaktiv, per RDP, PsExec oder WinRM/PowerShell Remoting anmelden. Das lokale, LAPS-verwaltete Passwort wird dafür überhaupt nicht gebraucht. Selbst wenn diese Gruppenmitgliedschaft irgendwo entfernt wurde, bleiben genügend andere Wege offen: Gruppenrichtlinien, Softwareverteilung über SCCM oder Intune, oder Scheduled Tasks, die als SYSTEM laufen.
LAPS schützt also gezielt gegen ein einziges, überall gleiches, nie geändertes lokales Passwort. LAPS schützt nicht gegen legitime oder kompromittierte Domain-Admin-Konten. Wer diese Ebene absichern will, braucht eine zusätzliche, andere Kontrollebene, typischerweise ein Tiering-Modell nach Microsofts Enterprise Access Model (Tier 0/1/2), bei dem Domain-Admin-Konten sich technisch gar nicht an normalen Workstations anmelden dürfen, dazu Privileged Access Workstations (PAWs) für administrative Tätigkeiten, getrennte Alltagskonten ohne Domain-Admin-Rechte und Session-Auditing für privilegierte Anmeldungen. LAPS und diese Maßnahmen ergänzen sich, ersetzen sich aber nicht gegenseitig.
Wo das Passwort tatsächlich landet
Ein Punkt, der ebenfalls oft für Verwirrung sorgt: Wo wird das rotierte Passwort eigentlich gespeichert? Die Antwort lautet Microsoft Entra ID oder Active Directory, je nach Join-Typ des Geräts. Ein Gerät kann dabei immer nur eines von beiden nutzen, nicht beides parallel. Der offizielle Begriff „Backup Directory“ ist dabei etwas irreführend: Es handelt sich nicht um eine zusätzliche Sicherungskopie neben Intune, sondern um den tatsächlichen, einzigen zentralen Passwortspeicher.
Intune selbst speichert das Passwort nicht dauerhaft. Das Intune Admin Center ist lediglich die Oberfläche, die bei Abruf per Graph-API auf Entra ID zugreift, beziehungsweise bei AD als Ziel entsprechende On-Prem-Tools und PowerShell-Module nutzt. Eine praktische Konsequenz daraus: Löschen Sie ein Entra-Geräteobjekt, ist das zugehörige LAPS-Passwort damit unwiderruflich weg.
Und wer darf das Passwort im Ernstfall überhaupt abrufen? Global Administrator und Intune Administrator können es standardmäßig sehen. Für abgestuften Zugriff, etwa für den Helpdesk, legt man eine custom Entra-Rolle mit der Berechtigung microsoft.directory/deviceLocalCredentials/password/read an. Eine separate, schwächere Berechtigung (.../standard/read) zeigt nur Metadaten wie den Zeitpunkt der letzten Rotation, aber nicht das Passwort selbst. Für das Rotieren aus der Ferne braucht es zusätzlich die Intune-RBAC-Berechtigung „Rotate Local Admin Password“.
Ein Muster, das sich in der Praxis bewährt hat: Weisen Sie die custom Entra-Rolle nicht dauerhaft einzelnen Personen zu, sondern einer Gruppe, die per „Entra PIM eligible“ statt aktiv zugewiesen ist. Der Helpdesk-Mitarbeiter aktiviert dann bei Bedarf seine PIM-Gruppenmitgliedschaft, bekommt dadurch temporär die Leserechte auf das LAPS-Passwort, und der Zugriff läuft protokolliert und zeitlich begrenzt ab – das bekannte Just-in-Time-Prinzip aus PIM, hier kombiniert mit normalem Entra-RBAC statt eines eigenen LAPS-spezifischen Workflows.
Fazit
Windows LAPS löst ein sehr konkretes, sehr reales Problem: ein und dasselbe, nie geändertes lokale Admin-Passwort quer über die gesamte Geräteflotte. Es ersetzt kein lokales Admin-Konto. Das bleibt in den meisten Umgebungen aus guten Gründen bestehen. LAPS sorgt lediglich dafür, dass dieses Konto nicht überall gleich heißt beziehungsweise gleich lautet und dauerhaft unverändert bleibt. Es ist ausdrücklich kein Werkzeug, um Domain-Admin-Rechte einzuschränken.Dafür braucht es Tiering, PAWs und getrennte Konten als zusätzliche Kontrollebene.
Der Einrichtungsaufwand ist überschaubar:
- Eine Intune-Richtlinie, gegebenenfalls Entra-LAPS im Entra Admin Center aktivieren,
- RBAC und PIM einmalig aufsetzen
und seit LAPS fest in Windows und Intune integriert ist, entstehen dafür auch keine zusätzlichen Lizenzkosten mehr.
Für praktisch jede Umgebung mit mehr als einer Handvoll Windows-Clients, in der irgendwo ein lokales Admin-Konto existiert – und das ist in der Praxis fast immer der Fall, und sei es nur für Recovery-Zwecke –, lohnt sich der Einsatz.
Wenn Sie Windows LAPS, Intune-Richtlinien oder das Zusammenspiel mit Entra PIM in Ihrer Umgebung praktisch umsetzen möchten: In meinen Microsoft-365- und Azure-Schulungen bei cloudtrain.de gehen wir solche Szenarien direkt in der Praxis durch.