gMSA – Die Lösung für das Service Account Dilemma
In einer sicheren Infrastruktur muss für jeden Dienst (Service) und jede Aufgabe (Scheduled Task) ein Service Account eingesetzt werden. Da sind auch unsere Auditoren, wenn sie bei Kunden die Infrastruktur durchleuchten, sehr gründlich. Wichtig ist, dass ein Service Account nicht für weitere Dienste eingesetzt wird. Ansonsten können bei einer allfälligen Kompromittierung die anderen Dienste in Mitleidenschaft gezogen werden. Ein Dienst oder eine Aufgabe darf auch niemals als LocalSystem (dabei handelt es ich um einen speziellen Account mit lokalen Administratorenrechten) ausgeführt werden.
Das ein Service Account nur über die geringstmöglichen Berechtigungen verfügt, ist inzwischen selbstverständlich. Die Verwaltung dieser Service Accounts kann entweder lokal auf dem jeweiligen System erfolgen oder über das Active Directory. Meist ist die Verwaltung über Active Directory die bessere Wahl, da ein Account oft auch auf andere Ressourcen im Netzwerk Zugriff haben muss (beispielsweise ein Backup-Task). Zudem ist es einfacher, die Übersicht über vorhandene Accounts zu bewahren.
Standard Service Account
Nach unserer Erfahrung ist vielen Administratoren nicht bewusst, dass die Berechtigungen eines lokalen Administrators auf einem Server ausreichen, um die Passwörter der angemeldeten Accounts (und somit auch von Service Accounts) auszulesen. Mit dem Windows-Tool reg.exe, lässt sich die Registry, inklusive der lokal gespeicherten Passwörter, exportieren. Die Kennwörter für die Dienste sind im Security-Zweig abgelegt und erfordern für den Zugriff SYSTEM-Berechtigungen. Diese können beispielsweise vom lokalen Administrator mit dem Tool psexec.exe, welches in der Sysinternals Suite enthalten ist, gefolgt von den Parametern (-i -s cmd.exe) erlangt werden.
Das Tool impacket-secretsdump hilft uns dabei, die Dateien in einem lesbaren und entschlüsselten Format anzuzeigen. Hier ist nun das Passwort des Service Accounts im Klartext zu sehen.
Gehen wir also davon aus, dass der Angreifer den Server bereits kompromittiert hat und lokaler Administrator ist. Nun kann er den Service Account und die damit verbunden Berechtigungen übernehmen. Dies kann natürlich unangenehme Folgen haben, da der Account vielleicht auf andere Ressourcen in der Domäne berechtigt ist.
Wie kann dieses Dilemma nun mit verhältnismässig wenig Aufwand gelöst werden? Die allererste und wichtigste Massnahme ist, keine lokalen Administratorenrechte zu verwenden. Leider ist dies jedoch nicht immer möglich. Oft benötigen Mitarbeiter oder externe IT-Dienstleister administrative Rechte auf Servern, damit sie diese Warten können. Mit Windows Server 2008 R2 wurden Managed Service Accounts eingeführt. Diese wurden jedoch von Applikationen wie Exchange und SQL nicht unterstützt, Scheduled Tasks liessen sich damit nicht starten und sie konnten nicht auf verschiedenen Hosts verwendet werden – somit war das unbrauchbar. Mit Windows Server 2012 wurden Group Managed Service Accounts (gMSA) eingeführt. Damit können nun einzelne Accounts auf mehreren Hosts verwendet werden. Auch der Einsatz von Scheduled Tasks ist nun möglich. Dies macht die Sache interessant für uns. Ein weiterer Vorteil ist die Verwaltung der Kennwörter. Diese werden automatisch mit dem Key Distribution Service (KDS) auf dem Domain Controller generiert und je nach Einstellung automatisch gewechselt. Hört sich doch interessant an? Mit folgenden Schritten haben sie gMSA in Ihrer Domäne eingerichtet.
Setup
Standardmässig existiert bereits die Organisation Unit (OU) «Managed Service Accounts». Hier werden die gMSA abgelegt. Als ersten Schritt lege ich hier eine Gruppe an, womit ich die Berechtigungen meines Service Accounts steuere.
Als nächsten Schritt verknüpfe ich meinen Server mit der Gruppe, damit er entsprechend berechtigt ist, den gMSA zu verwenden.
Mit folgendem PowerShell-Befehl veranlasse ich den Key Distribution Service, einen Root-Schlüssel für den Microsoft Group Key Distribution Service im AD zu generieren. Der Parameter -EffectiveImmediately bedeutet «as soon as possible». Es dauert aber trotzdem 10 Stunden. Wir fahren also am nächsten Tag mit der Einrichtung fort, oder behelfen uns mit folgendem Workaround, welcher gemäss Microsoft nur in einer Testumgebung empfohlen wird. Die 10 Stunden Wartezeit ist keine Schikane, sondern sollte sicherstellen, dass der Key auf allen DCs repliziert wurde.
Wir erstellen nun den gMSA und geben dabei einige Parameter mit.
Das Ergebnis sollte wie folgt ausschauen. Falls eine beim PowerShell-Befehl eine Fehlermeldung erscheint und alle Eingaben korrekt sind, weise ich gerne nochmal auf die 10 Stunden Wartezeit hin.
Sie können nun mit diesem Befehl beliebig viele Service Accounts erstellen. Wir empfehlen Ihnen sich dabei an ein zuvor definiertes Namenskonzept zu halten, wie folgendes Beispiel zeigt.
Unser gMSA ist nun bereit und kann auf dem Host eingerichtet werden. Zuerst müssen wir aber noch die Remote Server Administration Tools (RSAT) auf dem Host installieren. Diese werden benötigt, da ansonsten die PowerShell-Befehle unbekannt sind.
Anschliessend können wir den gMSA auf dem Host installieren und testen, ob die Installation erfolgreich war.
Scheduled Task
In der lokalen Policy des Servers berechtige ich den gMSA mit der Ausführung von Batch-Jobs. Dies ist für meine Demonstration notwendig, da ich mit einem Scheduled Task eine Batch-Datei starten möchte.
Den Task erstelle ich mit PowerShell. Leider sehe ich momentan keinen anderen Weg, denn über die GUI lässt sich der gMSA einem Scheduled Task nicht zuweisen (siehe Update vom 7. Dezember).
$action = New-ScheduledTaskAction “c:\script\backup.cmd”
$trigger = New-ScheduledTaskTrigger -At 22:00 -Daily
$principal = New-ScheduledTaskPrincipal -UserID blog\SA_Task_1$ -LogonType Password
Register-ScheduledTask BackupTask1 –Action $action –Trigger $trigger –Principal $principal
Der Scheduled Task wird nun im Kontext des gMSA, SA_Task_1 ausgeführt.
Dienst
Einen Dienst kann man nun ebenfalls mit dem gMSA starten. Der Account kann im AD gesucht und hinzugefügt werden. Das Passwortfeld wird leer gelassen, da es im AD gespeichert ist und verschlüsselt vom Distribution Service auf den Server übertragen wird.
Fazit
Verfügt man im Active Directory die Berechtigung, den gMSA zu verwenden, kann auch das Passwort ausgelesen werden. Dies ist normal und lässt ich nicht verhindern. Wichtig ist, dass ein anderer, nicht berechtigter Account (z.B. ein lokaler Administrator), das Passwort nicht auslesen kann. Dies ist gemäss meinen Recherchen und Versuchen nicht möglich. Ausserdem bietet der gMSA diverse Vorteile:
- Mit PowerShell können relativ einfach Accounts erstellt werden
- Die Berechtigung wird anschliessend über die Gruppe gesteuert
- Passwortmanagement entfällt
- Mit einem gMSA kann keine Anmeldung am System erfolgen
Weitere Empfehlungen:
- Geringstmögliche Berechtigungen pro Account (d.h. keine lokalen Administratorenrechte)
- Keine aktiven Sessions auf dem Server geöffnet lassen
Update 7. Dezember 2018
Der Scheduled Task kann doch wie gewohnt via GUI (Windows Aufgabenplanung) eingerichtet werden. Als Service Account irgendeinen Benutzer auswählen.
Anschliessend kann in der CMD mit folgendem Befehl der gMSA gewechselt werden:
schtasks /Change /TN ScheduledTaskName /RU „SA_Task_1$“ /RP „“
Herzlichen Dank an Herr Nikolay Vodenicharov von der Schubiger Möbel AG für den Hinweis.
Weitere Quellen
https://www.dsinternals.com/en/retrieving-cleartext-gmsa-passwords-from-active-directory/