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
Hinweis zu Programm- und PowerShell 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
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:
| Wert | Bedeutung |
| 0 | SilentMode, keine Einträge |
| 1 | Nur Fehler und Warnungen |
| 2 | Verbose, alles wird Protokolliert |
EventIDs für den LAPS Client
Die folgende Tabelle ist dem LAPS_OperationsGuide entnommen (Version 6.2)
| ID | Severity | Description | Comment |
| 2 | Error | Could not get computer object from AD. Error %1 | This 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 Werbung
|
| 3 | Error | Could not get local Administrator account. Error %1 | This 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 |
| 4 | Error | Could 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 |
| 5 | Error | Validation failed for new local admin password against local password policy. Error %1. | This event is logged when password validation against local password policy fails. |
| 5 | Information | Validation passed for new local admin password. | This event is logged when password is successfully validated against local password policy |
| 6 | Error | Could not reset local Administrator’s password. Error %1 | This 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 |
| 7 | Error | Could 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 |
| 10 | Warning | Password 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 |
| 11 | Information | It 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 |
| 12 | Information | Local Administrator’s password has been changed. | This event is logged after CSE resets the password of managed local Administrator account |
| 13 | Information | Local Administrator’s password has been reported to AD. | This event is logged after CSE reports the password and timestamp to AD |
| 14 | Information | Finished successfully | This event is logged after CSE performed all required tasks and is about to finish |
| 15 | Information | Beginning processing | This event is logged when CSE starts processing |
| 16 | Information | Admin account management not enabled, exiting | This 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.
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.
Download der PowerShell Skripte
Die PowerShell Skripte sind mittlerweile auf GitHub gehostet.
Hinweis zu Programm- und PowerShell 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.
Schreibe einen Kommentar