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.

GMSA1

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.

GMSA2

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.

GMSA3

Als nächsten Schritt verknüpfe ich meinen Server mit der Gruppe, damit er entsprechend berechtigt ist, den gMSA zu verwenden.

GMSA4

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.

GMSA5

Wir erstellen nun den gMSA und geben dabei einige Parameter mit.

GSMA14

Parameter

Beschreibung

-name

Definiert den Namen des Service-Accounts (SA darf nicht länger als 15 Zeichen sein, das kennen wir ja von Netbios)

-DNSHostName

Name des ADs

-PrincipalsAllowedToRetrie-veManagedPassword

Gruppe, in welcher der Account zugewiesen werden soll

-ManagedPasswordInter-valInDays 30

Definiert die Zeit in Tagen, nachdem das Kennwort automatisch wieder geändert wird

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.

GMSA7

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.

Name (max. 15 Zeichen)

Dienst oder Task

Beschreibung

SA_T_B_SRV-XY

Scheduled Task

Backup Skript auf dem Server SRV-XY

SA_D_SQL_SRV_YX

Dienst

Dienst für SQL_Server auf SRV-YX

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.

GMSA8

Anschliessend können wir den gMSA auf dem Host installieren und testen, ob die Installation erfolgreich war.

GMSA9

GMSA10

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.

GMSA11

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.

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

GMSA12

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

Weitere Quellen

https://blogs.technet.microsoft.com/askpfeplat/2012/12/16/windows-server-2012-group-managed-service-accounts/

https://www.dsinternals.com/en/retrieving-cleartext-gmsa-passwords-from-active-directory/

https://www.powershellgallery.com/packages/DSInternals/2.22

Informationen zum Autor
Antonio Kulhanek
Autor: Antonio Kulhanek
Nach meinem Studium an der STFW erhielt ich die Möglichkeit bei goSecurity als Junior Security Consultant einzusteigen. Das war im Jahre 2013. Manchmal staune ich selbst über den Wissens- und Erfahrungsschatz, den ich bis heute aufbauen konnte. Neben meiner heutigen Funktion als Security Consultant bin ich als CIO für unsere interne IT-Infrastruktur verantwortlich. Genau deshalb kann ich unsere Kunden optimal und praxisnah beraten. Ich weiss was es bedeutet, eine IT-Infrastruktur sicher, kostenoptimiert und auf die Business-Prozesse ausgerichtet zu betreiben. Gebündelt kann ich mein Fachwissen und meine Erfahrung als Referent unseres Kurses goTraining Information Security for CIO (IS4CIO) weitergeben. Die Sicherheit Ihrer IT optimal auf Ihre Businessanforderungen auszurichten, ist nicht nur mein Beruf, es ist meine Leidenschaft.