LAPS - Local Admin Password Solution

Seit 2015 gibt es ein Add-on für Windows, mit dem die Verwaltung lokaler Kennworte auf Servern und Workstations deutlich vereinfacht werden kann. Ich weiß nicht mehr, warum ich ca. 2 Jahre später erst auf LAPS aufmerksam geworden bin und ich bin sicher, dass viele andere Administratoren LAPS noch nicht kennen. Das will ich mit dieser Seite abstellen.

Mit dem Windows Security Update April 2023 hat Microsoft "LAP2" ausgerollt. Hierbei kann es zu Konflikten mit einer bestehenden LAPS-Installation kommen. Siehe dazu auch
Legacy LAPS Interop issues with the April 11 2023 Update
https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview#legacy-laps-interop-issues-with-the-april-11-2023-update

Die Tätigkeiten in der IT ändern sich dauernd. Wenn Sie nicht stehen bleiben wollen, dann müssen Sie sich bewegen und Teams suchen, die sich gegenseitig voran bringen. LAPS ist nur eine Perle, die leider bei vielen Firmen unbekannt ist. Helfen Sie uns mit, die Welt etwas sicherer zu machen und diskutieren Sie mit meinen Kollegen und mir, wie wir das gemeinsam schaffen.
https://www.netatwork.de/unternehmen/karriere/

Achtung:
Das regelmäßig geänderte Kennwort sollten Sie vielleicht nicht im Active Directory stehen lassen, sondern exportieren und im AD löschen. Ansonsten hat ein erfolgreicher Angreifer die Schlüssel zu allen Systemen frei Haus. Siehe Abschnitt "Risiko" am Ende der Seite und War-Room.

Windows 11 Insider Preview Build 25145 - LAPS wird zur Standardfunktion
https://blogs.windows.com/windows-insider/2022/06/22/announcing-windows-11-insider-preview-build-25145/

Updates April 2023

Mit dem Security Updates April 2023 hat Microsoft LAPS umfangreich erweitert und die bisherige und hier beschriebene LAPS-Version durch eine neue Version abgelöst.

Legacy LAPS Interop issues with the April 11 2023 Update
https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview#legacy-laps-interop-issues-with-the-april-11-2023-update

Seit April 2023 ist einiges neu:

  • LAPS ist nun Bestandteil des Betriebssystems
    Sie müssen also keinen Dienst mehr installieren
  • LAPS und AzureAD
    Sie können nun das lokale Admin-Kennwort auch im AzureAD hinterlegen lassen
  • Kennwort sind verschlüsselt
    Die Kennworts im AD sind nicht mehr nur durch Berechtigungen (ACLS) gegen fremden Zugriff geschützt sondern nun auch verschlüsselt. Voraussetzung ist aber der Forest Functional Level 2016
    Um die Information mit dem DSRM-Kennwort zu schützen, brauchen Sie Windows 2019 Domaincontroller
  • Neues MMC Snapin
    Auch die Anzeige der Kennworte mit der MMC für AD Benutzer und Computer musste natürlich für die verschlüsselten Kennworte angepasst werden

Alleine wird LAPS aber auch nicht aktiv, d.h. auch die neue Version müssen Sie über Gruppenrichtlinien oder Intune CSPs entsprechend konfigurieren

Achtung:
Eine doppelte Konfiguration per "Legacy LAPS-Richtlinie " und "neue LAPS-CSE-Policy" blockiert beide Lösungen. Entfernen Sie entweder das CSP oder deaktivieren Sie den Legacy-Mode
Legacy LAPS Interop issues with the April 11 2023 Update
https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview#legacy-laps-interop-issues-with-the-april-11-2023-update

Managing local admin account passwords in AD and Azure AD
https://www.youtube.com/watch?v=jdEDIXm4JgU

Das Problem

In denke, dass es wohl in den meisten Firmen die Clients und Server Mitglied einer Domäne sind. LAPS funktionier nur für Mitglieder in einem Active Directory. Das macht nicht nur die Zugriffe und Verwaltung einfacher sondern erlaubt auch die Anmeldung mit einem Domänen-Account, so dass die lokalen Anmeldekonten quasi verkümmern oder gar nicht erst welche angelegt werden. Allerdings gibt es lokal immer das Konto eines Administrators und ich befürchte, dass bei den meisten Firmen ein oder mehrere Probleme damit verbunden sind.

  • Alle Systeme haben das gleiche Admin-Kennwort
    Oft wird das Kennwort anhand einer "Unattended"-Installation gesetzt und niemand ändert es danach. Man müsste das neue Kennwort ja irgendwo hinterlegen
  • Das Kennwort kennen zu viele Personen
    Das ist umso unangenehmer, wenn z.B. ausgeschiedene Administratoren oder Benutzer im Fehlerfall das Kennwort kennen.
  • Sie haben keinen Prozess zum Ändern
    Selbst wenn Sie das Kennwort ändern wollten, haben Sie keinen Prozess um auf vielen Systemen ausreichend sichere Kennworte zu vergeben und auch irgendwo sicher zu hinterlegen

Im Idealfall wird das lokale Konto natürlich nie benötigt und auch nicht durch Dienste oder Skripte verwendet. Daher wäre es doch pfiffig, das Kennwort immer mal wieder zu ändern und irgendwo zu hinterlegen. Ein per Softwareverteilung auf allen Client ausgeführtes Skript "New Admin password.cmd" könnte das Problem schon reduzieren. Nur besonders sicher ist das natürlich nicht. Man konnte sogar mit den "Group Policy Preferences" entsprechende Kennworte per Gruppenrichtlinien setzen lassen. Die waren aber schon länger nicht mehr "Sicher

Mit dem Update MS14-025 ( https://technet.microsoft.com/en-s/library/security/ms14-025.aspx ) hat Microsoft das Hinterlegen von Passwörtern in Group Policy Preferences dann auch unterbunden.

Funktionsweise von LAPS

Tools von Microsoft sind in der Regel kostenfrei und oft pfiffig angelegt. Und genau das ist auch LAPS und ich werde das Gefühl nicht los, das Microsoft intern das gleiche Tool einsetzt. Es ist sehr einfach aufgebaut und ich wüsste keinen Grund es nicht in jedem Netzwerkeinzusetzen. Es funktioniert wie folgt:

  • Die Funktion gibt es nur für Computer in einem Active Directory
    d.h. dies ist keine Lösung für Einzelplatzsysteme
  • Das Active Directory-Schema wird um Felder zur Hinterlegung des Kennworts erweitert
    Die Schema-Erweiterung erfolgt per PowerShell um zwei Felder. Im Feld "ms-Mcs-AdmPwd" wird das Kennwort gespeichert und im Feld "ms-Mcs-AdmPwdExpirationTime" das Ablaufdatum des Kennworts
  • Auf jedem PC und Server wird eine Group Policy Extension installiert
    Die Installation kann per Softwareverteilung oder als MSI-Pakete in der Gruppenrichtlinie erfolgen. Er sorgt dann dafür, dass das lokale Administrator-Kennwort geändert und im Active Directory hinterlegt wird.

Achtung
Das Kennwort wird im Klartext beim Computerobjekt gespeichert aber ist per Default nicht von normalen Anwendern zu lesen.

  • Die Steuerung der Einstellungen erfolgt über Gruppenrichtlinien
  • Ein Client erlaubt berechtigten Personen die Anzeige des Kennworts
  • Alle Aktionen werden in Eventlogs protokolliert
    So können Sie einfach Fehler und Änderungen erkennen

Klingt einfach und erspart mir das bislang genutzte VBScript oder andere Krücken, die auf dem PC gestartet wurden und das Kennwort verändert und irgendwie hinterlegt oder versendet haben. Aber etwas "Einrichtung" ist natürlich erforderlich.

Checklist Einrichtung

Für die Installation habe ich mir folgende Checkliste bereit gelegt:

Aktion Status

Download des Installationspakets

Local Administrator Password Solution (LAPS)
https://www.microsoft.com/en-us/download/details.aspx?id=46899

Folgende Dateien landen dann auf ihrem Computer:

Neben den zwei Installationsdateien, die neben der Group Policy Extension auch die ADMX-Vorlagen und den Admin Client enthalten, beschreiben die anderen drei Dokumente die Funktion, die Einrichtung und die technischen Details.

Installation der Client Management Tools

Ich habe die Tools einfach auf einem Verwaltungsserver installiert, auf dem Sie später auch das Kennwort von entsprechenden Systemen auslesen wollen. Das Setup installiert per Default aber nur die GPO Extensions (Siehe Bild). Für die Management Tools ist das .NET 4-Framework mindestens erforderlich.

Auf dem Verwaltungsserver müssen auch die anderen Komponenten installiert werden. Ca. 2,6 Megabyte landen so zusätzlich auf dem Server, die sich zum Teil in "C:\Program Files\LAPS" finden.

Schema erweitern

Für diesen Schritt muss der ausführende Benutzer in die Gruppe der Schema Administratoren addiert werden.

Die Kennworte für die Computer landen in eigens einzurichtenden Feldern am Active Directory Objekt. Dazu ist einmalig eine Schemaerweiterung erforderlich. Das geht per PowerShell:

#Import des erforderlichen Moduls
PS C:\> Import-Module admpwd.ps

# Anzeige der nun verfügbaren Befehle
PS C:\> get-command -Module admpwd.ps

CommandType     Name                                               ModuleName
-----------     ----                                               ----------
Cmdlet          Find-AdmPwdExtendedRights                          admpwd.ps
Cmdlet          Get-AdmPwdPassword                                 admpwd.ps
Cmdlet          Reset-AdmPwdPassword                               admpwd.ps
Cmdlet          Set-AdmPwdAuditing                                 admpwd.ps
Cmdlet          Set-AdmPwdComputerSelfPermission                   admpwd.ps
Cmdlet          Set-AdmPwdReadPasswordPermission                   admpwd.ps
Cmdlet          Set-AdmPwdResetPasswordPermission                  admpwd.ps
Cmdlet          Update-AdmPwdADSchema                              admpwd.ps

# Erweiterung des Schemas
PS C:\> Update-AdmPwdADSchema -Verbose

Operation            DistinguishedName                                                 Status
---------            -----------------                                                 ------
AddSchemaAttribute   cn=ms-Mcs-AdmPwdExpirationTime,CN=Schema,CN=Configuration,DC=m... Success
AddSchemaAttribute   cn=ms-Mcs-AdmPwd,CN=Schema,CN=Configuration,DC=msxfaq,DC=net      Success
ModifySchemaClass    cn=computer,CN=Schema,CN=Configuration,DC=msxfaq,DC=net           Success

# Zweiter Versuch bestätigt die bereits erfolgte Erweiterung
PS C:>> Update-AdmPwdADSchema

Operation            DistinguishedName                                                 Status
---------            -----------------                                                 ------
AddSchemaAttribute   cn=ms-Mcs-AdmPwdExpirationTime,CN=Schema,CN=Configuration,DC=m... EntryAlreadyExists
AddSchemaAttribute   cn=ms-Mcs-AdmPwd,CN=Schema,CN=Configuration,DC=msxfaq,DC=net      EntryAlreadyExists
ModifySchemaClass    cn=computer,CN=Schema,CN=Configuration,DC=msxfaq,DC=net           AttributeOrValueExists

Wenn Sie in ihrem Netzwerk auch "Read Only Domain Controller" betreiben, dann Feld "ms-Mcs-AdmPwd" aus dem Filterset entfernen und alle nicht berechtigten Accounts das Leserecht „All extended rights“ entziehen.

Vergessen Sie nicht, den Benutzer dann wieder aus der Gruppe der Schema Administratoren zu entfernen.

Schreibrechte auf die Felder geben

Der Dienst auf dem Computer muss natürlich das AD-Feld auch beschreiben dürften. Das erledigt der nächste Aufruf in der PowerShell:

Sie müssen diesen Befehl in einer Admin-Powershell durchführen, wenn User Account Control sie ansonsten blockiert.

PS C:\> Set-AdmPwdComputerSelfPermission -OrgUnit "dc=msxfaq,dc=net"

Name       DistinguishedName         Status
----       -----------------         ------
msxfaq     DC=msxfaq,DC=net          Delegated

Ich habe hier einfach die Rechte auf die Domäne gegeben, die dann Vererbung dann auch auf allen Objekten wirkt. Wenn Sie die Vererbung von Rechten auf OU- oder Objekt-Ebene unterbrochen haben, müssen Sie die Rechte dort wieder neu addieren. Die Berechtigung kann in den erweiterten Sicherheitseigenschaften auch betrachtet werden:

Auditing

Natürlich wollen wir wissen, wenn ein Administrator so ein Kennwort ausliest. Auch dies muss explizit auf die Domäne oder OU und die zu überwachende Gruppe oder den User aktiviert werden.

Vielleicht sollten Sie eine Berechtigungsgruppe "LAPSReader" anlegen und diese dann überwachen.

Set-AdmPwdAuditing `
   -OrgUnit "dc=msxfaq,dc=net" `
   -AuditedPrincipals LAPSReader `
   -AuditType Success,failure

Name        DistinguishedName     Status
----        -----------------     ------
msxfaq      DC=msxfaq,DC=net      Delegated

Analog zu den Berechtigungen zum Setzen der Kennwortfelder addiert dieser Befehl einen Eintrag im Auditing:

GPO-Vorlagen bereitstellen

Die Installation der "GPO Editor Templates" hat schon dafür gesorgt, dass die ADMX-Vorlagen im Verzeichnis %WINDIR%\PolicyDefinitions bzw. %WINDIR%\PolicyDefinitions\en-US landen.

Wenn Sie einen Ordner "PolicyDefinitions" im SYSVOL-Verzeichnis  zur zentralen Ablage von Vorlagen angelegt haben, sollten Sie die ADMX-Dateien wie gewohnt dort hin kopieren.

Gruppenrichtlinie einrichten

Wenn Sie keine eigenständige Softwareverteilung haben und sicher gehen wollen, dass alle Clients ihren Vorgaben folgen, dann bietet sich eine Gruppenrichtlinie an, die sowohl die Einstellungen bezüglich LAPS als auch die Verteilung der Client Extension übernimmt. Nach der Bereitstellung der ADMX/ADML-Vorlagen sollten Sie beim Erstellen oder Editieren einer Gruppenrichtlinie auch die LAPS-Einstellungen sehen. Per Default sind alle "Not configured". Hier habe ich drei Einstellungen schon aktiviert:


Windows 10


Windows 11: https://blogs.windows.com/windows-insider/2022/06/22/announcing-windows-11-insider-preview-build-25145/

Bei der Einstellung "Kennwort Settings" gibt es eine Einstellung zur Password Complexity als auch zur Länge und dem maximalen Alter.

Sie können die Einstellungen natürlich je nach OU abweichend einstellen, z.B. dass auch bestimmte Systeme ausgenommen werden.

Group Policy Extensions verteilen

Damit die Richtlinie auf den Client greifen kann, muss die Group Policy Extension installiert werden. Diese gibt es als 32bit und 64bit Version als MSI-Datei und kann entsprechend über die Gruppenrichtlinie oder eine andere Softwareverteilung auf die Clients installiert werden.

Hinweis:
Bei der Installation der MSI über Gruppenrichtlinien ist ein Neustart des Servers erforderlich, da die Installation mittels Computerrichtlinien nur beim Neustart durchgeführt wird.

Die Installation der CSE ist das Default Paket. Sie müssen aber die passende Plattform vorgeben.

msiexec /i <file location>\LAPS.x64.msi /quiet
msiexec /i <file location>\LAPS.x86.msi /quiet

Die Installation erscheint dann auch in der Systemsteuerung.

Alternativ können Sie die DLL "AdmPwd.DLL" auf die Zielsysteme bringen und mit "regsvr32.exe AdmPwd.dll" registrieren. Allerdings erscheint dann kein Eintrag unter den installierten Programmen.

C:\>dir AdmPwd.DLL /s
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: 1234-1234

 Verzeichnis von C:\Program Files\LAPS\CSE

22.09.2016  08:02           148.632 AdmPwd.dll
               1 Datei(en),        148.632 Bytes

     Anzahl der angezeigten Dateien:
               1 Datei(en),        148.632 Bytes
               0 Verzeichnis(se), 140.240.322.208 Bytes frei

Nachdem die Group Policy Extensions verteilt und die Richtlinien angewendet wurden, sollten mehr und mehr Computer das Kennwort des lokalen Administrators ändern und im AD hinterlegen.

Kennwort auslesen

Die Tatsache, dass das Kennwort im AD hinterlegt ist, eröffnet ihnen nun viele Möglichkeiten diese Daten wieder auszulesen. LAPS liefert eine Windows GUI mit, mit der Sie einfach das Kennwort eines Computers anzeigen können. Suchen Sie nach "LAPS UI".

Die Oberfläche ist wirklich minimalistisch:

Sie können natürlich auch ADSIEDIT, die MMC Für Benutzer und Computer im erweiterten Mode oder selbst CSVDE nutzen, um die Daten zu extrahieren. Ich ziehe hier die PowerShell vor:

Das Auslesen gelingt natürlich nur mit einer "Admin-PowerShell", da ansonsten UserAccountControl verhindert, dass Sie das Feld sehen.

PS C:\> Get-ADComputer -LdapFilter "(ms-Mcs-AdmPwd=*)" -Properties Name,ms-Mcs-AdmPwd | ft Name,ms-Mcs-AdmPwd -AutoSize

name      ms-Mcs-AdmPwd
----      -------------
DC01      3+X4HM#BY!nx0T
EX2016    387XFG+!ss2!02
SfB2015   afg63?"df!wSSx

Die Ausgabe können Sie natürlich auch noch mit Export-CSV in eine Liste exportieren und anderweitig weiter verarbeiten. Denken Sie aber daran, dass die Kennwort je nach Einstellung bald wieder geändert sind. Laut der folgenden Quelle bei Microsoft können Sie die Berechtigungen auch delegieren:

"Password is protected in AD by AD ACL, so granular security model can be easily implemented"
Quelle: https://docs.microsoft.com/en-us/previous-versions/mt227395(v=msdn.10)?redirectedfrom=MSDN

Wenn Sie ihre Computer in entsprechende OUs verteilen, können Sie dezentralen Administratoren auch die Berechtigungen auf "ihre" Clients delegieren. 

LAPS und Dienstkonten

LAPS ist eigentlich nur dazu gedacht, den lokalen Administrator zu verwalten. Nun ist es ja so, dass wir auch Dienstkonten haben, die auf viele Systeme viele Rechte haben. Ich denke da an den Backup-Job, der von vielen Servern über das Netzwerk die Dateien abzieht. Dann gibt es noch die Software-Verteilung, welche auch entweder mit einem privilegierten Domänenkonto auf jedem PC läuft oder sich mit dem PC verbindet. Für solche Dienste gibt es mittlerweile "Managed Service Accounts"

Aber nicht jede Lösung kann damit umgehen.

Anstatt nun aber ein hoch privilegiertes Domänenkonto zu nutzen, könnten Sie auch den lokalen Administrator nutzen, Ihre Software müsste dann nur für den Zugriff das aktuell gültige Kennwort aus dem Active Directory auslesen, ehe es über das Netzwerk z.B. auf C$, WMI, Registry o.ä. zugreift.

Das ist aber nur eine theoretische Überlegung, Ich habe dies bislang noch nicht eingesetzt und würde besser auf die gMSA-Konten setzen.

Logging, Debugging u.a.

Auf die einzelnen Eventlogs im Applicationlog und die Möglichkeit eines Debuggings über Logdateien gehe ich nicht weiter im Detail ein und verweise auf die von Microsoft mitgelieferten Dokumente. Der folgende Registrierungsschlüssel steuert z.B. was die CSE im Application Eventlog protokolliert:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}}\ExtensionDebugLevel

Alle Events und deren Bedeutung finden Sie z.B. in der Datei "LAPS_OperationsGuide.docx"

Local Administrator Password Solution (LAPS)
https://www.microsoft.com/en-us/download/details.aspx?id=46899

Risiko: PC-Owner

Ein Computerkonto im AD hat einen "Besitzer". In der Regel ist das ein Administrator oder ein Provisioning-Code, der den Computer in die Domäne gebracht hat. Aber es gibt auch die Option, dass ein Anwender per Default bis zu 10 Computer in eine Domäne aufnimmt. Maßgeblich ist dazu das Feld "ms-DS-MachineAccountQuota" auf der Domäne, welches ich natürlich auf "0" setze.

Wenn ein Benutzer einen Computer in die Domäne aufnimmt, dann ist er auch der Besitzer des AD-Objekts und kann immer wieder die Rechte anpassen. Er kann sich also auch selbst die Berechtigung einräumen das LAPS-Kennwort auszulesen. Das muss nicht schlimm sein, da der Benutzer ja auch zur Aufnahme in die Domain zumindest "lokaler Admin" auf dem Client ist. Aber wenn sie dies später per Richtlinie einschränken, dann kann der Benutzer sich so immer wieder eine Hintertür öffnen.

Mit folgendem Script bekommen Sie schnell heraus, welcher Computer welchen Besitzer hat.

Get-ADComputer -Filter * -Properties ms-DS-CreatorSID `
   | Where-Object -FilterScript { $_."ms-DS-CreatorSID" -ne $Null } `
   | Format-Table `
        -AutoSize `
        -Property Name,@{ `
                       Label='User'; `
                       Expression={(New-Object System.Security.Principal.SecurityIdentifier($_."mS-DS-CreatorSID".Value)).Translate([System.Security.Principal.NTAccount]).Value} `
           }

Das funktioniert auch als Domainuser!

Risiko: Speicherort

Es gibt natürlich schon ein Problem: Wenn ein Angreifer schon Domain Admin ist, z.B. mit einem Golden Ticket, dann kann er ebenfalls alle lokalen Admin Kennworte elegant auslesen. Vielleicht ist das AD doch nicht der besser Ablageplatz hierfür. Das Risiko könnte vielleicht reduziert werden, wenn der Zugriff auf dieses Admin-Konto auf den physikalischen Server selbst, d.h. vor Ort, per Management-Board oder VMConsole beschränkt und der Zugriff nicht über das Netzwerk möglich ist. Ein Angreifer hätte dann vielleicht das lokale Admin-Kennwort aber kann es nicht einfach ausnutzen.

Das lokale Admin-Kennwort könnte ja wirklich als "Notfall-Account" fungieren, welches nur genutzt werden kann, wenn eine Gegenstelle nicht erreichbar ist oder das CD-Laufwerk geöffnet ist oder ein USB-Stick verbunden ist. Selbst AVM hat das hinbekommen, dass bestimmte Aktionen durch einen physikalischen Druck auf eine Taste bestätigt werden müssen. Für VMs muss dann eine andere Lösung gefunden werden.

Einschätzung

Mein Artikel ist nun fast zwei Jahre nach dem Release der ersten LAPS-Version geschrieben worden. Er hat nicht direkt etwas mit Exchange oder Skype for Business zu tun aber er ist mir so wichtig, dass ich all die Administratoren erreichen möchte, die auch die MSXFAQ lesen und vielleicht von LAPS noch nichts gehört haben. Jetzt können Sie sich nicht mehr herausreden, wenn die Sicherheit durch nicht verwaltete lokale Administratorenkennworte gefährdet ist. Die Einrichtung von LAPS dauert meinst kürzer als ich zum Schreiben des Artikels gebraucht habe.

Weitere Links