Local Administrator Password Solution (LAPS)

Früher wurden für die lokalen Administrator Passwörter meistens immer ein Unternehmensspezifischer Standard verwendet. Doch was macht man wenn ein Mitarbeiter der das Standardkennwort kennt, das Unternehmen verlässt?

Richtig, man sollte es ändern. Früher wurden dafür gerne mal Gruppenrichtlinien (GPO) verwendet, auch wenn das Kennwort im Klartext im SysVol lag. Dem hat Microsoft zum Glück einen Riegel vorgeschoben. Was gibt es noch für andere Lösungen? In der Praxis habe ich auch schon VBS oder PowerShell Skripte gesehen, die guten haben Random Passwörter, die schlechten nur ein Standard.

Aber gibt es da nicht eine Durchdachte Lösung von Microsoft? Doch, die gibt es, Local Administrator Password Solution (LAPS).

Warum den Aufwand?

Einige Kunden bei denen ich schon mal gewesen bin nutzten Standard-Kennwörter für lokale Admin-Konten weil es einfach ist. Einmal im Image hinterlegt, fertig. Doch wann kann das zu einem Problem werden? Hier meine persönliche Top-3 warum das eine schlechte Idee ist:

  • Mitarbeiter verlassen das Unternehmen und kennen diese Kennwörter…
  • Wenn alle Kennwörter gleich sind, wird im Falle einer Infektion oder eines Angriffes eine seitliche Pass-to-Hash Attacke vereinfacht.
  • Wenn man mal ein Kennwort dem Anwender geben muss (ja, sollte nicht passieren, kann aber mal vorkommen), dann kennt er nur das für seinen Computer (Und das ändern kann über die PowerShell vorzeitig angestoßen werden.)

Weitere Gründe und Anforderungen (Zum Beispiel IT-Grundschutz) gibt es zu genüge. Meistens werden Lokale Administratorkennwörter nicht geändert, weil es zu viel Arbeit ist. Auch dies ändert sich hierdurch.

Wie funktioniert das Ganze?

LAPS ist ein Dienst der auf den entsprechenden Computern installiert wird. Dieser Dienst schreibt seine Informationen in 2 Attribute des Computer-Objektes. Diese Attribute müssen mit einer Schemaerweiterung installiert werden, und werden durch ADDS-ACL automatisch geschützt. Die Erweiterung erfolgt durch ein mitgeliefertes PowerShell Script.

Der Client / Dienst wird als MSI-Paket geliefert und kann über Kommando-Zeile oder mit einer Softwareverteilung erfolgen.

Die Administration erfolgt mit einem eigenen PowerShell Modul oder einer installierbaren GUI. Die Steuerung für die Clients erfolgt über Gruppenrichtlinien. Über die GPO können dann auch die Richtlinien für Lokale Admin-Passwörter eingestellt werden, zum Beispiel Länge der Kennwörter oder maximales Alter.

Um das Ganze auch zu überwachen, kann das Log-Verhalten und die Audit Funktion angepasst werden. Die entsprechenden Ereignisse werden im Event Log protokolliert.

Welche Systeme werden unterstützt?

Immer rede ich von einem Client, aber für welche Systeme kann der LAPS-Client genutzt werden? Ganz einfach, mehr als gedacht, jedes aktuell von Microsoft unterstützte x86 oder x64 Windows das Mitglied einer Windows Domäne ist. Die Anforderung an das Active Directory ist ähnlich niedrig, die Domänen Kontroller müssen aus Windows Server 2003 SP1 oder höher laufen. Die Funktionsebene der Domäne sollte auch mit 2003 sein.

Wie installiere ich das jetzt?

Bei einer normalen Installation des MSI können die Management Tools ausgewählt werden. Normalerweise werden die nicht mitinstalliert. Darin enthalten sind die PowerShell Scripte für die Verbreitung des AD.

Die Installation der Management Tools ist denkbar einfach.

Nach der Installation muss über die PowerShell das AD Vorbereitet werden, starten Sie dazu die PowerShell mit einem Benutzer der in der Gruppe Schema-Admins enthalten ist und führen die folgenden Befehle aus:


Import-Module AdmPwd.PS

Update-AdmPwdADSchema

Wenn Bedarf besteht, kann auch manuell die Berechtigung auf die Attribute angepasst werden, zum Beispiel um dem Help-Desk lediglich Zugriff auf die Kennwörter der Client Computer zu gewähren. Näheres dazu steht in der LAPS Dokumentation.

Damit die LAPS Client jetzt auch beim Anwenden der GPO die neuen Passwörter eintragen können, müssen diese auch berechtigt werden. Ohne diese Rechte werden die Kennwörter nicht geändert. Führen Sie dazu den Befehl:

Set-AdmPwdComputerSelfPermission <OU>

aus, ersetzten Sie <OU> durch den entsprechenden OU-Namen.

Damit das ganze nun auch noch per Gruppenrichtlinie gesteuert werden kann, muss die ADMX und die ADML-Datei noch kopiert werden, am besten in den Zentralspeicher für die Gruppen Richtlinien. Sollten Sie noch keinen Central Store für GPO’s haben, wird es höchste Zeit. Die Dateien die Sie kopieren müssen finden Sie nach der Installation unter “%SystemRoot%\PolicyDefinitions” der Dateiname ist “AdmPwd.admx” bzw. “en-US\AdmPwd.adml”.

Im Anschluss können Sie LAPS über Gruppenrichtlinie konfigurieren.

Installation des LAPS-Client

Damit LAPS auch funktionier muss neben der Policy das passende MSI-Packet installiert werden. Wer keine Softwareverteilung hat, kann das auch über einen geplanten Task mittels Gruppenrichtlinen machen. Oder klassisch über einen Kommandozeilenbefehl, z.B.:

msiexec /i \\server\Freigabe\LAPS.x64.msi /quiet

Wer gerne möchte das LAPS nicht unter “Programme und Funktionen” gelistet wird, kann auch die DLL verteilen und registrieren. Näheres dazu in der LAPS Dokumentation.

Nach dem nächsten GPUpdate wird das Admin Password entsprechend geändert.

Wie kann ich das Kennwort sehen?

Einfach die GUI starten und den Rechnernamen auswählen.

Alternativ kann auch der PowerShell Befehl

Get-AdmPwdPassword -ComputerName Win10Ent

genutzt werden, hier funktioniert auch ein Platzhalter.

Please wait...

Autor: Fabian Niesen

Fabian Niesen ist seit Jahren beruflich als IT-Consultant unterwegs und arbeitet bei der steep GmbH in Bonn. Unter anderem ist er Zertifiziert als MCSA Windows Server 2008 / 2012, MCSA Office 365, MCSE Messaging, MCT und Novell Certified Linux Administrator. Seine Hobby’s sind Social Media, Bloggen, Mittelaltermärkte und Historische Lieder.

Schreibe einen Kommentar

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