PowerShell Skripte mit Local Administrator Password Solution (LAPS) nutzen und auditieren

A screenshot of a social media post

Sie kennen die Administrator Password Solution (LAPS) noch nicht, dann lesen Sie meinen ersten Artikel zu LAPS und wie das einzurichten ist. In diesem Beitrag geht es um die Verwendung mit der PowerShell und wie man das auch auditieren kann.

Warum die remote PowerShell mit LAPS geschützten Administratorkennwörtern verwenden

Da LAPS gerne genutzt wird, um vertikale Angriffe nach der Erbeutung des Passwort Hashes zu verhindern, warum nicht noch weiter gehen? Oft gibt es PowerShell Skripte die lokal auf Systemen von Remote ausgeführt werden. Diese können Administrativer Art sein, oder einfach auch Daten aus dem Ereignisanzeige auslesen. Aber dafür immer einen Domänen-Basierten Dienstkonto nehmen, der einen Hash hinterlässt? Warum nicht den Lokalen Administrator nutzen? Da die Kennwörter alle verschieden sind, besteht hier kein Risiko. Auch wird das Passwort regelmäßig geändert, so dass der Hash an Wert verliert.

Aber, das Passwort wechselt sich ja immer, aber man kann es mit der PowerShell abfragen. Was liegt also näher als ein PowerShell Skript zu schreiben, dass den lokalen Administrator mit dem LAPS Passwort für den Zugriff verwendet? So mal ja auch das Kennwort direkt zum zurücksetzten nach der Benutzung vermerkt werden kann. Somit ist der Hash oder das vielleicht angefangene Password wertlos.

Der große Vorteil, durch das Auditing, was ich später im Artikel beschreibe, kann man direkt auch sehen wer das Skript ausgeführt hat.

Die Voraussetzungen

Auf den Computer, der das Skript startet, muss das LAPS PowerShell Modul aus dem LAPS Installer installiert sein. Auch müssen dazu die Systeme, die LAPS zum Verbinden benutzen möchten, als Trusted Host eingetragen werden. Da Kerberos für Lokale Kennwörter nicht genutzt werden kann, muss entweder Unverschlüsselte WinRM Benutzung erlaubt werden, oder SSL für WinRM genutzt werden. Wie das geht können Sie in dem Artikel „Windows WinRM über HTTPs“ nachlesen.

Sinnvoll ist hier eine Begrenzung auf die notwendigen Systeme. Wenn es einfach sein soll, funktioniert auch ein „*“.

Setzen der TrustedHosts per Gruppenrichtlinie

Um das per Gruppenrichtlinie zu aktivieren gehen Sie unter Administrative Vorlagen/Windows-Komponenten/Windows-Remoteverwaltung (Windows Remote Management, WinRM)/WinRM-Dienst und wählen „Remoteverwaltung über WinRM zulassen“. Als Wert für die Trusted Hosts werden hier die IP-Adressen oder Subnetze eingetragen.

Screenshot Windows RM GPO Einstellung "Remoteverwaltung über WinRM zulassen" unter  Administrative Vorlagen/Windows-Komponenten/Windows-Remoteverwaltung (Windows Remote Management, WinRM)/WinRM-Dienst
Screenshot Windows RM GPO Einstellung „Remoteverwaltung über WinRM zulassen“ unter Administrative Vorlagen/Windows-Komponenten/Windows-Remoteverwaltung (Windows Remote Management, WinRM)/WinRM-Dienst

Setzen der TrustedHosts per PowerShell

Um die TrustedHosts per PowerShell zu definieren kann der Befehl

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <ComputerName>,[<ComputerName>]

genutzt werden. Dieser Überschreibt existierende Einträge. Wer mehr zu der PowerShell Variante lesen möchte, dem empfehle ich den Artikel „Add computers to TrustedHosts list using PowerShell“ von Dimitris Tonias.

De Gruppenrichtlinie aber gewinnt wenn beides aktiv ist. Da die GPO auch einfacher angepasst werden kann, empfehle ich das darüber zu setzen. Dies macht auch eine eventuelle Fehleranalyse einfacher.

Screenshot Power Shell Set-Item WSMan:\localhost\Client\TrustedHosts
Screenshot Power Shell Set-Item WSMan:\localhost\Client\TrustedHosts

Das Skript

Hinweis zu Programm und Power Shell Code

Der hier enthaltene Code dient als Beispiel. Ich übernehme keine Garantie, Gewährleistung oder Support für den Code oder Bestandteile. Verwendung des Codes erfolgt auf eigene Gefahr.
Ich empfehle immer sich die Skripte vor der Verwendung genau anzuschauen, was sie wirklich tun.

Jetzt zu dem Skript automatisch den LAPS geschützten Administrator verwendet. Auf dem System, auf dem das Skript ausgeführt wird, muss das LAPS-PowerShell Modul installiert sein. Das folgende Skript soll nur als Beispiel dienen, wie man das machen kann. Für den Produktiven Einsatz sollte man es noch entsprechend „hübsch“ machen. Die einzelnen Schritte sind im Code kommentiert.

Import-Module AdmPwd.PS 
#Importiert das benötigte Modul 
$computer = "Win10-1809" 
#Computer zu dem die Verbindung aufgebaut wird
$username = "$computer\Administrator" 
#Benutzerkonto das mit LAPS geschützt wird
#Das Auslesen funktioniert nur aus einer Shell mit Administrativen rechten!
$password = (Get-AdmPwdPassword -ComputerName $computer).Password 
#Auslesen des Password
Write-Output "Found Password: $password" 
#Damit man prüfen kann ob das Password ausgelesen werden konnte
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $username,$($password | ConvertTo-SecureString -asPlainText -Force)
#Erstellen der Credentials
$FQDN= $computer + ".adg.local" 
#Um einen Zertifikatsfehler zu vermeiden muss der FQDN zum Verbindungsaufbau genutzt werden
Invoke-Command -ComputerName $FQDN -ScriptBlock { Get-ChildItem C:\ } -credential $cred -UseSSL
Screenshot ISE mit Code Beispiel und Ergebnis der Remote Ausführung mit LAPS Kennwort
Screenshot ISE mit Code Beispiel und Ergebnis der Remote Ausführung mit LAPS Kennwort

Jetzt könnte man argumentieren das das Passwort ja bekannt ist, oder der gespeicherte Hash auf dem Ziel missbraucht werden könnte. Also ändern wir es.

Das geht im dem wir unser Skript um die folgenden Befehle erweitern:

Reset-AdmPwdPassword -ComputerName $computer
#Zurücksetzten des LAPS Passwort
Start-Sleep -Seconds 30
#Etwas Gedult für die lokale AD Replikation
Invoke-GPUpdate -Computer $computer -Target Computer -Force
#GPUdate ausführen um neues Kennwort setzten zu lassen. Dies dauert dann einige Minuten.

Es kann nach dem Invoke-GPUpdate durchaus 5-10 Minuten dauern bis das neue Passwort gesetzt ist.

Somit wird nach dem Skript das Passwort neu gesetzt. Als Ergänzung könnte man das Skript auch um eigene Ereignisprotokoll Einträge erweitern.

Auditieren der Passwort Abfrage

Natürlich ist die Gefahr, das Lokale Administratorkennwort genutzt werden, um keine Spuren zu hinterlassen. Da der lokale Administrator nicht personalisiert ist, könnte es ja jeder gewesen sein, der das Kennwort auslesen kann. Zum Glück hat das Active Directory hier die Möglichkeit zu Auditierung. LAPS bringt dafür direkt den Befehl „Set-AdmPwdAuditing“ mit. Mit dieser Befehl erleichtert die Einrichtung der Audit-Funktion. Es kann eine Gruppe die Auditiert werden soll, sowie die OU angegeben werden. Sinnvoll ist hier dieselben Gruppen zu nutzen, die auch zur Berechtigung zum Auslesen verwendet werden. Alternativ kann auch die Gruppe „Jeder“ für das Audit verwendet werden. Die OU sollte entsprechend gewählt werden. Nach der Aktivierung erscheint im Sicherheits-Log der Domänen Kontroller ein Eintrag mit der EventID 4662. Darin ist der Benutzer enthalten.

Hier ein Beispiel für das PowerShell Kommando:

Set-AdmPwdAuditing -Identity Clients -AuditedPrincipals Jeder
Screenshot Aktivieren des LAPS Audit mit  Set-AdmPwdAuditing in der Power Shell
Screenshot Aktivieren des LAPS Audit mit Set-AdmPwdAuditing in der Power Shell

Und so sieht es im Event Log aus:

Screenshot des EventLog mit Audit Eintrag für Zugriff auf ein LAPS Kennwort
Screenshot des EventLog mit Audit Eintrag für Zugriff auf ein LAPS Kennwort

Anpassen des Client Loging bei LAPS

Normalerweise trägt LAPS auf dem System, das es verwaltet nichts in das Ereignisprotokoll ein. Das Erstellen von Einträgen ins EventLog kann aber zur Fehleranalyse oder zur besseren Überwachung aktiviert werden. Um das Protokollieren zu aktivieren muss unter HKLM:SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA} ein Registry-Schlüssel mit dem Namen „ExtensionDebugLevel“ angelegt werden. Der Wert ist vom Typ Reg_Dword und hat die folgenden Werte:

WertBedeutung
0SilentMode, keine Einträge
1Nur Fehler und Warnungen
2Verbose, alles wird Protokolliert

EventIDs für den LAPS Client

Die folgende Tabelle ist dem LAPS_OperationsGuide entnommen (Version 6.2)

IDSeverityDescriptionComment
2ErrorCould not get computer object from AD. Error %1This event is logged in case that CSE is not able to connect to computer account for local computer in AD.

%1 is a placeholder for error code returned by function that retrieves local computer name, converts it to DN and connects to object, specified by the DN

3ErrorCould not get local Administrator account. Error %1This event is logged in case that CSE is not able to connect to managed local Administrator account.

%1 is a placeholder to error code returned by function that detects the name of local administrator’s account and connects to the account

4ErrorCould not get password expiration timestamp from computer account in AD. Error %1.This event is logged in case that CSE is not able to read the value of ms-Mcs-AdmPwdExpirationTime of computer account in AD

%1 is a placeholder for error code returned by function that reads the value of the attribute and converts the value to unsigned __int64 type

5ErrorValidation failed for new local admin password against local password policy. Error %1.This event is logged when password validation against local password policy fails.
5InformationValidation passed for new local admin password.This event is logged when password is successfully validated against local password policy
6ErrorCould not reset local Administrator’s password. Error %1This event is logged in case that CSE is not able to reset the password of managed local Administrator account.

%1 is a placeholder for error returned by NetUserSetInfo() API

7ErrorCould not write changed password to AD. Error %1.This event is logged in case that CSE is not able to report new password and timestamp to AD.

%1 is a placeholder for error code returned by ldap_mod_s call

10WarningPassword expiration too long for computer (%1 days). Resetting password now.This event is logged in case that CSE detects that password expiration for computer is longer than allowed by policy in place while protection against excessive password age is turned on
11InformationIt is not necessary to change password yet. Days to change: %1.This event is logged after CSE detects that it is not yet the time to reset the password

%1 is a placeholder for number of 24-hour’s intervals that remain till the password will be reset

12InformationLocal Administrator’s password has been changed.This event is logged after CSE resets the password of managed local Administrator account
13InformationLocal Administrator’s password has been reported to AD.This event is logged after CSE reports the password and timestamp to AD
14InformationFinished successfullyThis event is logged after CSE performed all required tasks and is about to finish
15InformationBeginning processingThis event is logged when CSE starts processing
16InformationAdmin account management not enabled, exitingThis event is logged when admin account management is not enabled

Quelle: Microsoft LAPS Operation Guide

Wenn das Client-Logging auf 2 (Verbose) eingestellt wird, sieht so die Änderung des Passwords durch das Skript aus.

Screenshot des Client Eventlog nach der Aktivierung des Client LAPS Logging im Modus Verbose
Screenshot des Client Eventlog nach der Aktivierung des Client LAPS Logging im Modus Verbose

Windows Admin Center mit LAPS

Ich hatte schon vor im April 2018 über das Windows Admin Center, aka Projekt Honolulu, berichtet.

Mittlerweile kann auch das Windows Admin Center LAPS benutzen um die Verbindungen zu den verwalteten Systemen automatisch aufzubauen. Dadurch benötigt nicht mehr jeder einen Persönlichen Admin der überall lokaler Administrator ist. So verbleiben auch wesentlich weniger Password Hashes und Cached Credentials auf den Systemen. Dies ist auch schon ein Sicherheitsgewinn. So mal bei vielen Firmen die persönlichen Administrativen Kennwörter entweder nicht gewechselt werden, oder aber die Administrativen Konten mehr Rechte haben, als für die eigentliche Aufgabe erforderlich.

In Kombination mit dem oben genannten Auditing, kann auch kontrolliert werden, wer Zugriff hatte.

Ob diese Funktion Sinnvoll ist und wie viel Sicherheit das bringt, hängt von Ihren Prozessen ab.

Autor: Fabian Niesen

Fabian Niesen ist seit Jahren beruflich als IT-Consultant unterwegs. Hier schreibt er privat und unabhängig von seinem Arbeitgeber. Unter anderem ist er Zertifiziert als MCSA Windows Server 2008 / 2012, MCSA Office 365, MCSA Windows 10, MCSE Messaging, MCT und Novell Certified Linux Administrator. Seit 2016 ist er auch MCT Regional Lead für Deutschland. Seine Hobby’s sind Social Media, Bloggen, Mittelaltermärkte, Historische Lieder und der Hausbau. Zu finden ist er auch auf folgenden Plattformen: -

Ein Gedanke zu „PowerShell Skripte mit Local Administrator Password Solution (LAPS) nutzen und auditieren“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.