LAPS - Local Admin Password Solution

Seit 2015 gibt es ein AddON 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.

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

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:\Users\adm-fcarius> 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.

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.

PS C:\> Set-AdmPwdAuditing -OrgUnit "dc=msxfaq,dc=net" -AuditedPrincipals helpdesk -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:

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 Dfault 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.

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.

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"

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