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:
Import-Module AdmPwd.ps Update-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:
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:
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:
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:
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:
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:
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.
Danke für den Artikel. Er hat mir sehr geholfen! :)
Wir haben viele Clients im Außendienst, die eher selten direkt am DC hängen und eher per VPN in die Firma connecten (wenn überhaupt). Wie verhalten sich die Clients, wenn die Gültigkeit des Passworts überschritten ist? Die Änderung wird ja offensichtlich vom AD getriggert. Wird das Kennwort im AD-Attribut erst geändert, wenn der Client diese auch empfange hat? Sonst sind die Passwörter im AD/Client ja asynchron. Und danach? Reicht dann eine Verbindung per VPN oder muss der Client sich direkt an den DC wenden? Muss oder kann man die Synchronisation irgendwie anschubsen?
Hallo Frank,
wäre es nicht sinnvoll noch einer Gruppe das Recht zum Passwort Reset über Set-AdmPwdResetPasswordPermission zu geben?
Damit ein Admin Passwort auch zwischendurch zurückgesetzt werden kann über LAPS.
Gruß Max
Hallo Franky,
super und danke für die tolle Anleitung bei mir klappt alles soweit jedoch das Audit „stresst“ mich ein wenig ich habe die Powershell Befehl ausgeführt
Set-AdmPwdAuditing –OrgUnit „meineDNOU“ -AuditedPrincipals „Meine ADGruppe die dasPasswort lesen darf“
leider bekomme ich es irgendwie nicht hin diesen 4662 EventId zu generieren – muss ich da noch andere Audits aktiveren wie z.b die DS Access Policy an der Default DC Policy? oder am Client direkt?
Gruss Danke
Thomas
Hallo Thomas,
bist du bei dem Thema weiter gekommen? Ich habe leider das gleiche Problem wie du… soweit funktioniert es, nur ich bekomme dieses Event 4662 nicht angezeigt.
VG
Andreas
Hallo Franky,
ich die Maßnahmen vollständig umgestzt. Nun stellt sich mir eine Frage. Wenn ich den Zugriff für LAPS nur dem Tier2Admin habe, wie kann ich mich als tier2admin via powershell anmelden um das password auszulesen
da tier2 admin sich ja nicht an tier 0 systemen anmelden kann
Hallo Franky,
ich bin gerade dabei die Maßnahmen umzusetzen. Nun stellt sich mir eine Frage. Wenn ich den Zugriff für LAPS nur dem Tier2Admin gebe, wo installiere ich dann die LAPS GUI? Auf dem Admin Host kann es nicht sein, weil der nicht in der Domäne hängt und der AHUser kein Mitglied der Domäne ist. Installiere ich die GUI dann auf meinem normalen Arbeitsplatzrechner und melde mich dort mit dem Tier2Admin an um an die Passwörter zu gelangen?
Vielen Dank für das super Tutorial. Hat mir damals sehr geholfen! Eine Frage: wie sehe ich nochmal welche User/Gruppe die Kennwörter auslesen dürfen? Per Find-AdmPwdExtendedRights -Identity „Beispiel-DN“ zeigt er mir auf den betreffenden OU’s „Domänen-Admins“ an was für mich ok ist.
Komischerweise kann ich mit meinem Daily User (nicht Domain-Admin!) auch die Kennwörter auslesen – der normale User nicht zum Glück, das hab ich gecheckt :-)
Bin mir nur nicht mehr sicher ob ich dortmals explizit die Admin einzeln berechtigt habe – kann ich das sehen?
Hallo Franky,
vielen Dank für die perfekte Anleitung. Du machst Dir wirklich viel Mühe – respekt!
Eine paar Fragen zu etwaigen Problemfällen sind bei mir noch offen:
Wie läuft die Absicherung der Passwortänderung ab. Beispiel: Der Client ändert sein Passwort und versucht es an die AD zurück zu melden, die AD ist aber just in diesem Moment ausgefallen (Switchausfall, Kabel gezogen, Stromausfall oder oder oder). Was passiert jetzt mit der Passwortänderung? Switcht der Client automatisch auf das alte Passwort zurück? Oder pollt er das neue, bis das AD wieder erreichbar ist? Kritisch wäre genau der Moment, wo durch die AD Störung im Nachgang z.B. am betreffenden Clienten eine Administratoraktion notwendig ist. Typisch auftretend bei Stromausfall, wenn der PC dann spontan nicht mehr startet und man sich als Administrator anmelden muss. Da hier u.U. das Passwort in der AD nicht mit dem neuen am Clienten übereinstimmt sehe ich arge Probleme.
Denkbar wäre dies auch bei Servern, wo evtl. dummerweise der LAPS Client gerade während einer Updateinstallation der Meinung ist ein neues Passwort zu genieren aber die Übertragung wegen gerade erfolgende Updateinstallation blockiert ist, dann die Updateinstallation fehlschlägt und man lokal eingreifen muss. Da wäre es der GAU, das lokale Administratorkennwort nicht zu wissen. Ist so ein Szenario ausgeschlossen oder real? Hast Du Erfahrungswerte dazu (generell zur Zuverlässigkeit das LAPS Konstruktes)?
Grundsätzlich ist es ja mit 3rd Party Tools (im Prinzip ja sogar mit Bordmitteln) möglich das Kennwort lokaler Konten zu löschen oder zu ändern. Das LAPS wird daran ja nichts ändern.
Gehen wir mal davon aus, das Endgerät ist mit Bitlocker verschlüsselt, müsste ja nur dort entschlüsselt werden um an die Windows Installation zu kommen. Die SAM könnte dann entsprechend manipuliert werden, so dass das Kennwort wieder bekannt ist.
LAPS aktualisiert erst die Passwort-Info im AD. Erst wenn die Änderung erfolgreich eingetragen wurden, wird das lokale Adminkennwort aktualisiert.
Quelle: „LAPS_TechnicalSpecification.docx“ (Abschnitt 5.1.1 „Implementation“) aus dem LAPS-Downloadpaket.
Das ist merkwürdig..
Wir haben es schon gehabt, dass VMWARE Tools Update am Donnerstag scheiter, der Rechner ewig ohne Netzwerk liegt.
Dann nachdem das behoben ist, ist die Vertrauensstellung weg.. und da gilt dann auch das LAPS Kennwort nicht mehr.
Als hätte er das zurückgesetzt ohne es im AD zu aktualisieren.