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 erden

    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