Autor: Fabian Niesen

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.

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.

Das Skript

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

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

Und so sieht es im Event Log aus:

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:

EventIDs für den LAPS Client

Die folgende Tabelle ist dem LAPS_OperationsGuide entnommen (Version 6.2)

Quelle: Microsoft LAPS Operation Guide

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

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.