Windows LAPS bleibt ohne Rollenmodell und Rückholpfad nur ein besseres Passwort

Lokale Administrator-Konten gelten in vielen Windows-Umgebungen noch immer als technischer Altbestand, den man mit etwas Passwortrotation schon irgendwie einfangen wird. Genau das ist der Denkfehler. Das eigentliche Risiko entsteht heute seltener durch eine zu kurze Zeichenkette, sondern durch unsaubere Betriebswege: Wer darf ein Passwort sehen, wer darf eine Sofortrotation auslösen, was passiert nach einem Helpdesk-Einsatz und was bleibt übrig, wenn ein Gerät aus Microsoft Entra gelöscht wird? An diesen Punkten entscheidet sich, ob Windows LAPS echte Risikoreduktion bringt oder nur ein besser verwaltetes Ausnahmekonto bleibt.

Die offiziellen Microsoft-Dokumente machen die Lage inzwischen klar genug, um daraus belastbare Betriebsregeln abzuleiten. Windows LAPS kann lokale Administrator-Passwörter automatisch verwalten, sichern und rotieren. Es nimmt Teams aber nicht die Führungsarbeit ab, die rund um Rollen, Policy-Konflikte, Incident-Reaktion und Device-Lifecycle entsteht. Wer nur das Feature einschaltet, bekommt noch kein belastbares Modell. Wer die Betriebslogik sauber aufsetzt, entzieht einem alten Angriffs- und Support-Sonderfall endlich die Improvisation.

Für Nicht-Spezialisten: Windows LAPS ist eine eingebaute Microsoft-Funktion für lokale Administrator-Konten auf Windows-Geräten. Sie speichert das Kennwort nicht einfach dauerhaft gleich, sondern kann es automatisch ändern und in Microsoft Entra oder Active Directory sichern. Das ist wichtig, weil lokale Admin-Konten im Notfall sehr mächtig sind und ohne saubere Kontrolle schnell zu einem stillen Seiteneingang für Supportfehler, Missbrauch oder laterale Bewegungen werden.

Das Sicherheitsproblem beginnt nicht bei der Passwortlänge, sondern beim Betriebsmodell

Microsoft beschreibt sehr deutlich, warum Windows LAPS überhaupt relevant ist: Jedes Windows-Gerät besitzt ein eingebautes lokales Administratorkonto mit umfassenden Rechten. Genau deshalb soll Windows LAPS diese Kennwörter regelmäßig verwalten und sichern. Der erste operative Punkt ist dabei die Verzeichnisentscheidung. Laut Microsoft hängt der zulässige Sicherungspfad am Join-Zustand des Geräts. Rein Entra-verbundene Geräte können Kennwörter nur nach Microsoft Entra sichern, rein Active-Directory-verbundene Geräte nur nach Active Directory, hybride Geräte in genau eines der beiden Ziele. Beides parallel geht nicht.

Das klingt nach einer Randnotiz, ist aber für den Betrieb zentral. Ein Team kann LAPS nicht sinnvoll führen, wenn es den Backup-Pfad losgelöst von der Geräteklasse plant. Genau an dieser Stelle scheitern Mischumgebungen schnell: Endpoint-Betrieb denkt in Intune-Richtlinien, klassische Administration in Active Directory, Helpdesk in dem Weg, der „irgendwie schon funktioniert“. Windows LAPS zwingt diese Pfade auf eine klare Entscheidung zurück. Wer sie nicht trifft, baut keine verlässliche Wiederherstellung, sondern nur neue Unklarheit.

Dazu kommt die Migrationsfrage. Microsoft stuft das frühere MSI-basierte Legacy-LAPS auf neueren Windows-Versionen als veraltet ein und empfiehlt den Umstieg auf Windows LAPS. Auch das ist kein kosmetischer Versionswechsel. Wer noch Altpfade, alte GPO-Gewohnheiten und neue Intune-Policies nebeneinander betreibt, erhöht die Wahrscheinlichkeit, dass Teams zwar „LAPS nutzen“, aber nicht mehr sicher sagen können, welche Quelle im Alltag wirklich gewinnt.

Die häufigste Fehlannahme: Eine strengere Policy dreht das laufende Passwort schon irgendwie mit

Besonders aufschlussreich ist Microsofts Beschreibung der Policy-Einstellungen. Der Wert PasswordAgeDays steuert zwar das maximale Kennwortalter, eine spätere Änderung an dieser Einstellung verändert laut Microsoft aber weder die aktuelle Ablaufzeit des bereits gespeicherten Kennworts noch löst sie automatisch eine sofortige Rotation aus. Genau hier liegt ein praktischer Stolperstein. Nach einem Vorfall, einem internen Rechtewechsel oder einer unsauberen Support-Nutzung reicht es eben nicht, die Richtlinie von 30 auf 7 Tage zu verschärfen und auf schnelle Wirkung zu hoffen. Wer sofortige Wirkung braucht, muss eine echte manuelle Rotation auslösen.

Microsoft nennt dafür zwei Wege: lokal per Reset-LapsPassword oder im Intune-Kontext über die Geräteaktion zur Rotation des lokalen Administrator-Kennworts. Das ist operativ wichtig, weil sich daraus zwei getrennte Disziplinen ergeben. Geplante Rotation ist eine Policy-Frage. Sofortige Rotation nach Support, Incident oder Verdacht ist ein definierter Betriebsprozess. Wer beides vermischt, lässt genau die Zeitfenster offen, die LAPS eigentlich verkleinern soll.

Ebenso relevant sind die Post-Authentication-Actions. Microsoft dokumentiert, dass Windows LAPS nach einer konfigurierbaren Wartezeit nicht nur das Kennwort zurücksetzen, sondern auch interaktive Sitzungen beenden und SMB-Sitzungen löschen kann. Standardmäßig ist genau diese Kombination vorgesehen. Für viele Helpdesk- und Außendienst-Szenarien ist das der eigentliche Reifegewinn: Ein lokales Admin-Kennwort darf für einen echten Ausnahmezugriff nutzbar sein, bleibt aber nicht länger als nötig im Feld wirksam. Ohne diese Regel wird aus einem Notfallwerkzeug schnell wieder ein halb informeller Dauerzugang.

Rollen, Konflikte und Sichtbarkeit entscheiden über die Alltagstauglichkeit

Microsoft trennt auch beim Zugriff deutlich zwischen Sehen, Rotieren und Auswerten. Für Entra-basierte Abrufe verweist die Dokumentation auf Microsoft Graph beziehungsweise den PowerShell-Befehl Get-LapsAADPassword. Das ist kein Zufall. Der Rückholpfad ist bewusst ein kontrollierter Administrationsvorgang und keine beiläufige Komfortfunktion auf dem Client. Wer LAPS ernst nimmt, sollte deshalb nicht nur „Admins dürfen das schon“ notieren, sondern Rollen sauber staffeln: Wer darf Metadaten wie letzte und nächste Rotation sehen, wer darf das Klartextkennwort abrufen und wer darf unabhängig davon eine Sofortrotation anstoßen?

Gerade im Intune-Betrieb wird sichtbar, warum diese Trennung wichtig ist. Microsoft schreibt ausdrücklich, dass die Geräteaktion Rotate Local Admin Password in keiner Intune-Standardrolle und auch nicht in der Entra-Rolle Intune Administrator enthalten ist. Für diesen Schritt braucht es also bewusst eine eigene benutzerdefinierte Intune-Rolle. Das ist kein Lizenzdetail, sondern ein Governance-Signal. Wer Support und Security dieselben breiten Adminrechte gibt, verschenkt die Chance, genau diese Funktion kontrolliert zu delegieren.

Hinzu kommt die Konfliktkontrolle. Die Intune-Berichte für Windows LAPS zeigen laut Microsoft, wenn Einstellungen wie PasswordAgeDays durch mehrere Profile kollidieren und aus welchen Profilen der Konflikt stammt. Außerdem werden automatische Rotationen, manuelle Rotationen und Kennwortabrufe in Microsoft Entra protokolliert. Genau diese Sichtbarkeit macht aus LAPS einen steuerbaren Betriebsgegenstand. Ohne sie bleibt nur die Behauptung, das Feature sei aktiv. Mit ihr lässt sich prüfen, welche Policy tatsächlich greift, welche Aktionen ausgeführt wurden und welche Personen sich reale Kennwortzugriffe geholt haben.

Der unterschätzte Punkt ist der Geräte-Lebenszyklus

Ein Detail aus der Intune-Dokumentation wird leicht übersehen, ist aber praktisch heikel: Wenn ein Gerät in Microsoft Entra gelöscht wird, geht die dort gespeicherte LAPS-Credential laut Microsoft verloren. Ohne eigene begleitende Recovery-Logik gibt es dann keinen Weg, dieses Kennwort aus Entra zurückzuholen. Das ist kein Argument gegen LAPS, sondern für saubere Offboarding- und Decommissioning-Prozesse. Bevor ein Gerätobjekt gelöscht oder bereinigt wird, muss klar sein, ob noch ein lokaler Wiederherstellungsbedarf besteht und wer diesen Schritt freigeben darf.

Damit schließt sich der Kreis zum Betriebsmodell. Windows LAPS ist stark, wenn Teams es nicht als isolierte Passwortfunktion behandeln, sondern als Kette aus Geräteklassifizierung, Backup-Ziel, Rollenmodell, Sofortrotation, Post-Auth-Verhalten, Monitoring und Lifecycle-Kontrolle. Fehlt eine dieser Schichten, wird das Risiko kleiner, aber nicht beherrschbar. Dann liegt das Kennwort zwar nicht mehr überall gleich herum, doch der Ausnahmezugriff bleibt organisatorisch unscharf.

Für Endpoint-Teams, Workplace-IT, Security und Service-Verantwortliche lautet die nüchterne Konsequenz: Windows LAPS erst dann als „fertig“ betrachten, wenn drei Dinge sauber entschieden sind. Erstens der verbindliche Rückholpfad pro Geräteklasse. Zweitens die Trennung zwischen Leserechten, Rotationsrechten und Audit-Sichtbarkeit. Drittens der konkrete Ablauf nach Nutzung des lokalen Admin-Kontos, inklusive Sofortrotation oder automatischer Nachwirkung. Erst dann wird aus dem Feature ein belastbarer Sicherheits- und Betriebsstandard.