Ein identisches lokales Administrator-Passwort auf vielen Windows-Clients ist ein Klassiker: Sobald ein Gerät fällt, kann ein Angreifer per Credential-Reuse (Wiederverwendung von Zugangsdaten) seitlich durchs Netz wandern. Genau hier setzt LAPS (Local Administrator Password Solution) an: Pro Gerät wird ein individuelles, regelmäßig rotierendes Passwort für ein lokales Admin-Konto in Active Directory hinterlegt – inklusive kontrollierter Leserechte und Protokollierung. Damit wird aus einem „ein Passwort regiert alles“-Problem ein beherrschbarer Prozess.
Der Beitrag fokussiert die sichere Einführung und den Betrieb, inklusive typischer Stolperfallen in Berechtigungen, Gruppenrichtlinien und Helpdesk-Abläufen. Für angrenzende Schutzmaßnahmen lohnt außerdem der Blick auf sicheres Onboarding und UAC-Härtung, weil saubere Admin-Prozesse immer zusammenspielen.
Warum lokale Admin-Passwörter ein Hochrisiko-Thema sind
Typische Angriffswege in der Praxis
Lokale Adminrechte sind nicht automatisch „Domänen-Admin“, aber sie öffnen oft die Tür: Mit lokalen Rechten lassen sich Security-Tools deaktivieren, Persistenz einrichten, Token abgreifen, lokale Anmeldedaten auslesen oder Pass-the-Hash-Techniken vorbereiten. In vielen Umgebungen liegt das größte Risiko in der Standardisierung: gleiche Images, gleiche lokalen Konten, gleiche Passwörter.
Besonders kritisch wird es, wenn ein Angreifer nach der Erstinfektion (z. B. über Phishing, Drive-by-Download oder ein unsicheres Makro) auf einem Client lokale Adminrechte erlangt und dann „seitlich“ weitergeht. Wird dasselbe lokale Admin-Passwort auf weiteren Geräten akzeptiert, ist die Ausbreitung oft nur noch eine Frage von Minuten.
Was LAPS konkret entschärft – und was nicht
Lokale Administrator-Passwortrotation verhindert Credential-Reuse für das verwaltete lokale Konto, weil jedes Gerät ein anderes Passwort besitzt. LAPS ist jedoch kein Ersatz für Patch-Management, EDR oder Netzwerksegmentierung. Außerdem schützt es nicht vor Angriffen, die ohne Kenntnis des Passworts lokale Privilegien eskalieren, und auch nicht vor kompromittierten Domänenkonten mit zu hohen Rechten.
Microsoft LAPS vs. Legacy LAPS: worauf bei der Planung zu achten ist
Funktionsumfang und Umgebungs-Fit
Es existieren zwei Linien: das ältere „Legacy LAPS“ (separat verteilt) und das in Windows integrierte „Microsoft LAPS“. In modernen Windows-Umgebungen ist Microsoft LAPS typischerweise der naheliegende Weg, weil es besser integriert ist (u. a. Richtlinien, Ereignisprotokolle, zusätzliche Optionen). In gemischten Umgebungen kann Legacy LAPS als Übergang dienen, sollte aber mit Blick auf Wartbarkeit und Zukunftssicherheit bewusst bewertet werden.
Wichtig ist weniger das Branding als die saubere Designentscheidung: Welches lokale Konto wird verwaltet, wie erfolgt der Zugriff für den Support, und wie werden Leserechte sowie Audits umgesetzt?
Technische Grundidee (ohne Magie)
LAPS speichert das jeweils aktuelle Passwort (und Metadaten wie Ablaufzeit) in einem Attribut des Computerobjekts in Active Directory. Der Zugriff wird über Berechtigungen gesteuert. Genau dort entscheidet sich die Sicherheit: Wenn zu viele Personen/Services Leserechte erhalten, wird aus einem Schutzmechanismus eine bequeme Passwortdatenbank.
Voraussetzungen prüfen: AD, Clients, GPOs und Rollout-Strategie
Saubere Zielgruppen: OU-Design und Pilotphase
Ein stabiler Rollout beginnt mit klar abgegrenzten OUs: erst Pilot, dann Wellen (z. B. IT, einzelne Fachbereiche, Außenstellen). Das vermeidet, dass falsche GPOs oder Berechtigungen flächig ausgerollt werden. Parallel sollte festgelegt werden, welche Geräte ausgenommen sind (z. B. Sonderkioske, isolierte Systeme) und wie dort alternativ vorgegangen wird.
Namens- und Kontenstrategie für lokale Administratoren
Ein häufiger Fehler ist, das eingebaute lokale „Administrator“-Konto unangetastet zu lassen und zusätzlich ein zweites lokales Admin-Konto zu schaffen – ohne klare Regel, welches Konto wofür genutzt wird. Besser ist eine konsistente Strategie: Entweder ein dediziertes verwaltetes lokales Konto oder – wenn das eingebaute Konto genutzt werden muss – konsequente Richtlinien dazu (aktiviert/deaktiviert, Benennung, Zugriff).
Berechtigungen in Active Directory: klein halten, hart prüfen
Wer darf Passwörter lesen – und wer darf sie zurücksetzen?
Das zentrale Sicherheitsziel lautet: Nur Rollen, die das Passwort wirklich brauchen, erhalten Leserechte. In der Regel sind das wenige Helpdesk- oder Client-Engineering-Gruppen. Noch besser ist eine Trennung: Ein Teil darf Passwörter lesen (Break-Glass/Support), ein anderer Teil darf Passwörter rotieren bzw. Abläufe triggern, aber nicht lesen. Das reduziert Missbrauchsrisiken bei kompromittierten Support-Konten.
Praktisch bedeutet das: Berechtigungen nicht auf Domain- oder „IT-All“-Gruppen geben, sondern dedizierte Gruppen mit überprüfbarer Mitgliedschaft nutzen. Mitgliedschaften sollten regelmäßig rezertifiziert werden (z. B. quartalsweise), insbesondere bei externem Support.
Warum „Alle dürfen lesen“ oft unbemerkt passiert
Fehlkonfigurationen entstehen häufig durch vererbte Rechte in OUs, pauschale Delegationen oder automatisierte AD-Templates. Deshalb sollten die effektiven Rechte auf das relevante Attribut stichprobenartig geprüft werden, nicht nur die beabsichtigten Gruppenrichtlinien. Sobald LAPS im Einsatz ist, ist das Attribut ein hochsensibles Ziel: Ein Angreifer mit Leserechten erhält sofort lokale Adminzugriffe auf viele Systeme.
GPO/Policy sicher setzen: Rotation, Passwortqualität, Protokollierung
Passwortlänge, Rotation und Ablauf: sinnvolle Leitplanken
Für die Passwortparameter zählt vor allem: lang genug, zufällig, regelmäßige Rotation, und kein unnötig langer Gültigkeitszeitraum. Kurze Rotationszyklen verringern das Zeitfenster bei einem Leak, erhöhen aber Support-Aufwand. Ein pragmatischer Ansatz ist: Standardrotation (z. B. Wochenbereich) plus sofortige Rotation nach Support-Nutzung oder Incident.
Bei der Komplexität ist weniger „Sonderzeichenakrobatik“ entscheidend, sondern Länge und Zufälligkeit. Der Generator von LAPS liefert genau das; wichtig ist, dass keine internen Prozesse das Passwort ausdrucken, in Tickets kopieren oder in ungeschützten Systemen dokumentieren.
Logs und Nachvollziehbarkeit im Betrieb
Ein wirksamer Betrieb braucht Nachvollziehbarkeit: Wer hat wann ein Passwort ausgelesen? Wurde es anschließend rotiert? Ohne Log-Review bleibt Missbrauch oft unsichtbar. In vielen Umgebungen hilft ein zentrales Log- und Alarm-Konzept, etwa über vorhandene Windows-Event-Forwarding/Log-Collecting-Mechanismen. Wer bereits zentral auswertet, kann die LAPS-relevanten Events in bestehende Use-Cases integrieren; ergänzend ist Windows-Log-Auswertung eine solide Basis.
Support-Prozesse robust machen: Zugriff ohne Datenleck
So bleibt das Passwort nicht im Ticket-System kleben
Ein häufiger Realwelt-Schaden entsteht nicht durch Kryptographie, sondern durch Copy&Paste: Das Passwort landet im Ticket, im Chat oder im Screenshot. Ein belastbarer Prozess minimiert diese Leckpfade: Zugriff nur durch autorisierte Rollen, dokumentierte Begründung, kurze Nutzungsdauer, anschließende Rotation und strikte Regeln zur Dokumentation (z. B. „Passwort niemals im Klartext in Tickets“).
Break-Glass sauber definieren
Für Notfälle braucht es einen Break-Glass-Mechanismus: Was passiert, wenn der LAPS-Zugriff selbst gestört ist (z. B. AD nicht erreichbar, Client offline, Support-Konto gesperrt)? Break-Glass sollte selten sein, technisch und organisatorisch begrenzt und nach Nutzung zwingend nachbearbeitet werden (Passwortwechsel, Review der Ursache, Log-Kontrolle).
Konkrete Umsetzung in kleinen Schritten
Praxisnahe Schritte für einen sicheren Start
- Pilot-OU anlegen und nur wenige Testgeräte aufnehmen; GPO/Policy ausschließlich dort verlinken.
- Dedizierte AD-Gruppen für Lesezugriff erstellen; Mitgliedschaften minimal halten und dokumentieren.
- Passwortparameter festlegen (Länge, Rotation, Sonderregeln) und mit Support-Aufwand abgleichen.
- Festlegen, ob ein eigenes lokales Admin-Konto verwaltet wird; lokale Standardkonten konsistent behandeln.
- Prozess definieren: Passwortabruf nur mit Ticket-Referenz; keine Klartextablage; Rotation nach Nutzung.
- Event-Logging aktivieren und einen Review-Mechanismus etablieren (z. B. stichprobenartig wöchentlich).
- Nach dem Piloten schrittweise Rollout-Wellen pro OU/Standort, jeweils mit kurzer Kontrollphase.
Härtung rund um LAPS: häufig übersehene Angriffsflächen
LAPS schützt nicht, wenn lokale Adminrechte zu leicht erreichbar sind
Wenn Anwenderkonten lokale Adminrechte besitzen, helfen auch rotierende Passwörter nur begrenzt. Ebenso kritisch sind Software-Deployments, die lokale Adminrechte „für Bequemlichkeit“ vergeben, oder Anwendungen, die mit lokalen Adminrechten laufen, obwohl es nicht nötig ist. Hier lohnt ein Abgleich mit einem Whitelisting-Ansatz wie AppLocker/WDAC, um ungewollte Ausführungen zu reduzieren.
Schützen, was LAPS ermöglicht: administrative Workstations und MFA
Der Zugriff auf LAPS-Passwörter ist ein privilegierter Vorgang. Deshalb sollte er möglichst von gehärteten Admin-Endgeräten erfolgen (separater Admin-Workspace, keine alltägliche Browser-/Mail-Nutzung) und durch starke Authentifizierung abgesichert sein. Least Privilege (Prinzip der minimalen Rechte) ist dabei der Leitstern: nur die Rechte, die für den konkreten Job erforderlich sind.
Kontrollpunkte: so lässt sich die Wirksamkeit nachweisen
Stichproben, Rechte-Review, Incident-Readiness
Einführung ist erst der Anfang. Im Betrieb zählen wiederkehrende Kontrollen: Stimmen die effektiven Leserechte auf den relevanten Attributen? Werden Passwörter tatsächlich rotiert? Gibt es Ausreißer (Geräte ohne aktuelle Werte, verwaiste Computerobjekte, Support-Konten mit zu breiten Rechten)?
Eine pragmatische Methode ist ein monatlicher Mini-Audit: wenige OUs auswählen, Rechte und Logs prüfen, auffällige Fälle direkt beheben. Ergänzend sollte der Incident-Prozess klar sein: Wenn ein Support-Konto kompromittiert wurde, muss schnell klar sein, welche Geräte betroffen sind und wie eine flächige Rotation ausgelöst wird. Für die ersten Schritte im Ernstfall passt ein schlankes Sicherheitsvorfall-Runbook.
Kurzer Vergleich typischer Administrationsmodelle
| Modell | Risiko bei Kompromittierung eines Clients | Operativer Aufwand | Typische Schwachstelle |
|---|---|---|---|
| Gleiches lokales Admin-Passwort überall | Sehr hoch (Credential-Reuse) | Niedrig | Seitwärtsbewegung trivial |
| LAPS für lokales Admin-Konto | Deutlich reduziert | Mittel | Zu breite Leserechte |
| Nur Domänen-Admin für Client-Support | Extrem hoch (Kronjuwelen im Feld) | Niedrig bis mittel | Admin-Creds auf Clients exponiert |
| Just-in-Time/Just-Enough Admin (rollenbasiert) | Niedrig bis mittel | Hoch | Komplexität, Prozessdisziplin |
In vielen mittelgroßen Umgebungen ist LAPS ein praktikabler Schritt, der schnell messbar Risiko senkt, ohne die IT mit einem komplexen Privileged-Access-Programm zu überfordern. Entscheidend bleibt die saubere Zugriffskontrolle und die Vermeidung von Klartext-Leaks.
Privileged Access Management (Verwaltung privilegierter Zugriffe) ist dabei der übergeordnete Rahmen: LAPS kann ein Baustein sein, aber nicht der gesamte Ansatz. Sobald mehrere Admin-Rollen, Dienstkonten und Remote-Zugänge zusammenkommen, lohnt eine klare Privileged-Strategie, damit einzelne Maßnahmen nicht gegeneinander arbeiten.
Audit-Logging (Nachvollziehbarkeit von Zugriffen) sollte im LAPS-Kontext nicht als „nice to have“ behandelt werden. Es ist das Sicherheitsnetz, das bei Verdacht oder Incident die entscheidenden Antworten liefern kann: Wer hat gelesen? Von wo? Für welches Gerät? Und was wurde danach getan?
Mit klaren OUs, minimalen Rechten, soliden Support-Regeln und wiederkehrenden Kontrollen lässt sich LAPS so betreiben, dass es realistisch angreifbare Wege schließt, statt nur eine weitere Konfiguration im AD zu sein.
