In diesem dritten Teil der Artikelreihe “Einfache Maßnahmen für mehr Sicherheit im AD” geht es um die Passwörter der lokalen Administrator Konten. In vielen Umgebungen sind die lokalen Administrator Passwörter immer gleich, dies öffnet Malware mitunter aber Tür und Tor und macht das Lateral Movement erst möglich oder vereinfacht es zumindest.
Unterschiedliche Passwörter für den lokalen Administrator für jeden Client und Server manuell zu vergeben, ist aber meist auch nicht praktikabel. Auch eine zyklische Passwortänderung auf Servern und Clients lässt sich manuell kaum bewerkstelligen. Genau für diesen Zweck hat Microsoft das Tool LAPS (Local Administrator Password Solution) veröffentlicht. Mittels LAPS erzeugt ein kleiner Agent auf jedem Client und Server ein individuelles Passwort und ändert dies auch zyklisch, das lokale Admin Kennwort wird im Active Directory gespeichert und lässt sich von berechtigten Personen mittels einer kleinen GUI auslesen. Gesteuert wird LAPS bequem per Gruppenrichtlinie.
In diesem HowTo geht es nun um die Installation und Konfiguration von LAPS, idealerweise auch bereits in einem Active Directory welches das Admin Tier Model verwendet.
Installation
Für die Installation von LAPS müssen zunächst die erforderlichen Komponenten runtergeladen werden:
LAPS erfordert ein Update des Active Directory Schemas und das Erstellen von Gruppenrichtlinien, die Installation führe ich daher direkt auf einem Domain Controller durch, somit sind auf einem DC alle erforderlichen Komponenten verfügbar um die Einrichtung von LAPS vorzunehmen.
Die Installation selbst ist mit wenigen Klicks erledigt, daher gibt es nur Kommentare zu relevanten Einstellungen:
Die Installation von LAPS fügt keine weiteren Dienste auf einem DC hinzu, sondern installiert nur Verwaltungstools, wie beispielsweise ein PowerShell Modul und GPO Erweiterungen. Die “Fat Client UI” wird auf dem Domain Controller nicht benötigt und sollte daher auch nicht installiert werden:
Nach der Installation muss das AD Schema für LAPS erweitert werden.
Active Directory Schema erweitern und Berechtigungen vorbereiten
Nachdem auf dem Domain Controller das LAPS Paket installiert wurde, muss das Active Directory Schema erweitert werden. Dies ist einer der seltenen Fälle in denen Schema-Admin Rechte benötigt werden. Wenn bereits ein Admin Tier Konzept umgesetzt wurde, muss an dieser Stelle ein Tier 0 Admin zur Gruppe “Schema-Admins” hinzugefügt werden:
Nachdem der Benutzer in die Gruppe aufgenommen wurde, muss sich einmal von Windows abgemeldet und wieder angemeldet werden.
Nun kann das AD Schema erweitert werden. Innerhalb einer administrativen PowerShell können dafür die folgenden Befehle verwendet werden:
| 12 | Import-Module AdmPwd.psUpdate-AdmPwdADSchema |
Die Schema Admin Rechte sind jetzt nicht mehr erforderlich, daher kann der Benutzer wieder aus der Gruppe “Schema-Admins” entfernt werden.
Damit Computer das lokale Administrator Kennwort im Active Directory speichern können, müssen entsprechende Berechtigungen konfiguriert werden. Die Computerkonten benötigen das Recht in die AD-Attribute “ms-Mcs-AdmPwd” und “ms-Mcs-AdmPwdExpirationTime” zu schreiben. Innerhalb des ADs lasen sich diese Rechte auf OU-Ebene vergeben.
Damit zukünftig alle Clients ihr Administrator Kennwort zyklisch ändern und im AD speichern, können die entsprechenden Berechtigungen zunächst auf einer Client OU konfiguriert werden.
Die Konfiguration der Berechtigungen kann anhand des “distinguishedName” einer OU erfolgen. Die Schreibrechte für “ms-Mcs-AdmPwd” und “ms-Mcs-AdmPwdExpirationTime” werden dabei an untergeordnete OUs vererbt:
Mit dem folgenden Befehl erhalten die Computerkonten das Recht ihr Administrator Passwort im Active Directory zu speichern:
| 1 | Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Clients,DC=frankysweblab,DC=de" |
Wenn es weitere OUs im AD gibt, welche Computerkonten enthalten und via LAPS das Passwort ändern sollen, muss der Befehl auch entsprechend für weitere OUs ausgeführt werden.
Ein weiterer wichtiger Punkt ist die Konfiguration der Berechtigungen für Administratoren, welche sich das Passwort aus dem Active Directory anzeigen lassen können. LAPS enthält für das Anzeigen der Passwörter die “LAPS UI”, welche sich Admins installieren können.
Da in diesem Beispiel zunächst die Clients (Admin Tier 2) mit LAPS versorgt werden, sollten auch die Tier 2 Administratoren die Berechtigung erhalten das lokale Administrator Passwort aus dem AD auszulesen. Mit dem folgenden Befehl erhält die Gruppe “Tier2Admins” die Berechtigung die Passwörter der Computerkonten innerhalb der OU “Clients” aus dem AD auszulesen:
| 1 | Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Clients,DC=frankysweblab,DC=de" -AllowedPrincipals "Tier2Admins" |
Die Vorbereitung des Active Directory ist somit abgeschlossen. Jetzt können die Gruppenrichtlinien zur Steuerung von LAPS erstellt werden.
Gruppenrichtlinie für LAPS erstellen
Um die Passwörter mittels LAPS zu verwalten, muss eine neue Gruppenrichtlinie erstellt werden. Zunächst wird dazu eine neue leere GPO angelegt, die Benutzerkonfigurationseinstellungen für die neue GPO kann deaktiviert werden:
Im Ordner LAPS finden sich nun die Einstellungen zu den Eigenschaften des Passworts und dessen maximales Alter. Diese Einstellungen müssen entsprechend aktiviert werden:
Damit das Passwort durch den LAPS Client zyklisch geändert wird, muss noch die Einstellung “Enable local admin password management” aktiviert werden:
Die Gruppenrichtinie ist nun soweit fertig und kann mit einer OU verknüpft werden. In diesem Fall gilt die GPO zunächst für Clients (Tier 2):
Hinweis: Am Ende des Artikel finden sich auch Hinweise für die Aktivierung von LAPS auf Tier 0 und Tier 1.
LAPS Client Installation per Gruppenrichtlinie
LAPS erfordert auf den Rechnern einen kleinen Client damit das Ändern des Passworts automatisch funktioniert. Damit der Client nicht manuell installiert werden muss, kann der LAPS Client per GPO automatisch installiert werden. Alternativ kann der LAPS Client natürlich auch beispielsweise per SCCM oder auch manuell auf den Rechnern installiert werden.
Für die automatische Installation via Gruppenrichtlinie ist zunächst eine Freigabe erforderlich. Innerhalb der Freigabe werden die beiden LAPS Pakete bereitgestellt (x86 und x64):
Damit der Client erfolgreich installiert werden kann, werden Lese-Berechtigungen auf der Freigabe benötigt:
Bevor eine entsprechende Gruppenrichtlinie zur Installation erstellt wird, sollte einmal überprüft werden, ob die Freigabe erreichbar ist:
Jetzt kann eine neue leere Gruppenrichtlinie angelegt werden. Für die GPO können die Benutzerkonfigurationseinstellungen deaktiviert werden:
Innerhalb der GPO kann nun der LAPS Client alles neues Paket angelegt werden:
Als Softwarepaket wird zunächst der x64 Client ausgewählt:
Das Paket erhält die Bereitstellungsmethode “Zugewiesen”:
Die x64-Version des Clients kann jetzt mit der GPO verteilt werden:
Damit auch x86 Clients das entsprechende Paket erhalten kann auf dem gleichen Weg die x86-Version importiert werden:
In den Eigenschaften des x86-Pakets muss nun noch die Einstellung “Diese 32-Bit-X86-Anwendung für Win64-Computer bereitstellen” deaktiviert werden:
Damit der LAPS Client auf den Rechner installiert wird, muss die GPO noch mit der entsprechenden OU verknüpft werden. In diesem Fall also die OU “Clients”:
Hinweis: Alternativ können hier auch zwei GPOs erzeugt werden, welche mittels WMI Filter auf x64 und x86 Betriebssysteme filtern. Hier ein Beispiel für entsprechende WMI Filter:
| 12 | SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth =’32’SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth =’64’ |
Testen von LAPS
Um die Funktionsweise von LAPS zu prüfen, kann sich zunächst auf einem Client angemeldet und kontrolliert werden, ob der LAPS Client installiert wurde. Der Client sollte sich unter “Apps und Features” als Programm “Local Administrator Password Solution” zu erkennen geben:
Wenn das Passwort bereits geändert und im AD gespeichert wurde, kann es mittels LAPS UI ausgelesen werden (Entsprechende Berechtigung vorausgesetzt):
Wenn das Passwort noch nicht im AD hinterlegt wurde, oder der Benutzer keinen Zugriff auf das Passwort des jeweiligen Computerkontos hat, wird auch kein Passwort angezeigt:
Hier gibt es übrigens einen kleinen Nachteil von LAPS, dass Passwort wird innerhalb des ADs unverschlüsselt gespeichert und ist für alle Konten einsehbar, welche im AD das Recht “Vollzugriff” haben:
Benutzer mit Domain-Admin Rechten können also via ADSI Edit oder “Active Directory Benutzer und Computer MMC” das Kennwort direkt im Klartext anzeigen lassen. Das Klartextpasswort wird zwar über eine verschlüsselte Verbindung zum AD übertragen, jedoch wird es im AD im Klartext abgespeichert. Normale Benutzer mit Leserechten können das Passwort nicht auslesen.
Benutzer mit Domain Admin Rechen, können den Wert für “ms-Mcs-AdmPwd” im AD auch verändern, das neue Passwort wird dadurch aber nicht am Client gesetzt. Nur der LAPS Client überträgt das Passwort zum AD, das Zurücksetzen eines Passworts indem das Attribut im AD geändert wird ist also nicht möglich.
Nachdem das Passwort mittels LAPS UI oder direkt aus dem AD ausgelesen wurde, kann sich mit dem Passwort am Client angemeldet werden. Ist die Anmeldung möglich, funktioniert LAPS korrekt.
LAPS auch für Server einsetzen
Es macht natürlich Sinn auch die lokalen Administrator Passwörter der Server mittels LAPS zyklisch zu ändern. Wer bereits das Admin Tier Konzept umgesetzt hat, kann nun auch mit wenig Aufwand LAPS für Server des Tier 1 und Tier 0 einsetzen.
Hier noch einmal ein Screenshot der Admin Tiers aus dem vorherigen Artikel:
Wer dies ähnlich konfiguriert hat, muss nur noch ein oder zwei weitere GPOs erstellen (wenn unterschiedliche Zyklen oder Passwortrichtlinien für die jeweiligen Tiers gelten sollen) und die Berechtigungen entsprechend setzen. Hier einmal der Schnelldurchlauf für Tier 1 und Tier 0 Server.
Setzen der Berechtigung für die Computerkonten um das Passwort im AD zu speichern:
| 12 | Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Tier 0,OU=Server,DC=frankysweblab,DC=de"Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Tier 1,OU=Server,DC=frankysweblab,DC=de" |
Konfiguration für die Admin Tier Gruppen um die Passwörter aus dem AD zu lesen:
| 12 | Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Tier 0,OU=Server,DC=frankysweblab,DC=de" -AllowedPrincipals "Tier0Admins"Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Tier 1,OU=Server,DC=frankysweblab,DC=de" -AllowedPrincipals "Tier1Admins" |
Gruppenrichtlinien für Tier 0 und Tier 1 erstellen (Beispiel für unterschiedliche Passwortrichtlinien):
GPOs für Installation und Verwaltung mit OUs verknüpfen:
Hinweis: Wenn das lokale Administrator Konto deaktiviert wurde und ein neuer Admin Account angelegt wurde, kann auch dieser mittels LAPS verwaltet werden. In diesem Fall muss in der GPO der Name des neuen Accounts angegeben werden:
Wenn das lokale Administrator Konto nur umbenannt wurde, muss diese Richtlinie nicht konfiguriert werden. Für die Domain Controller in der OU “Domain Controllers” sollte LAPS nicht eingesetzt werden, da hier im Prinzip kein lokales Administrator Konto existiert.
LAPS Audit
Bei Servern (ggf. auch bei Clients) kann es sinnvoll sein ein Auge darauf zu haben, welche Benutzer die lokalen Admin Passwörter aus dem AD abrufen. Hierfür kann das Audit eingeschaltet werden, hier mal ein Beispiel wie das Audit für das Abrufen von Passwörtern für die Server OUs und Server Admins eingeschaltet wird:
| 12 | Set-AdmPwdAuditing –OrgUnit "OU=Tier 1,OU=Server,DC=frankysweblab,DC=de" -AuditedPrincipals "Tier1Admins"Set-AdmPwdAuditing –OrgUnit "OU=Tier 0,OU=Server,DC=frankysweblab,DC=de" -AuditedPrincipals "Tier0Admins" |
Sobald ein Admin nun das Passwort via LAPS UI aus dem AD abruft, wird das Event 4662 auf Domain Controller protokolliert welcher die Anfrage beantwortet. In Screenshot ist zu erkennen, dass der Benutzer “Tier1Admin” das Passwort für den Rechner “FS1” abgerufen hat:
Leider ist das Event 4662 recht generisch, um hieraus einen sinnvollen Zugriffbericht zu den Passwörtern zu generieren, muss man schon etwas tiefer einsteigen und entsprechend auf die Eigenschalten filtern:
Hier könnte man beispielsweise ein PowerShell Script erstellen welches die Daten entsprechend aufbereitet oder die Events zur Auswertung an ein SIEM-System weiterleiten.
Was this helpful?
0 / 0