Group Managed Service Accounts (gMSA) für Tasks und Dienste

Häufig werden Service Accounts für den Start von Windows Diensten oder geplanten Aufgaben mit dem Attribut „Passwort läuft nie ab“ konfiguriert und dann jahrelang genutzt. Oft werden solche Service Accounts auch zweck entfremdet und auf vielen Servern für verschiedenste Aufgaben eingesetzt. Service Accounts mit weit reichenden Berechtigungen und nie ablaufenden Passwörtern erleichtern es dann den Angreifern. Eine Alternative sind Group Managed Service Accounts (gMSA-Konten).

Group Managed Service Accounts (gMSA-Konten) eignen sich besser für den Start von geplanten Aufgaben und Diensten als normale Active Directory Benutzerkonten mit nie ablaufenden Passwort. Der Hauptvorteil der gMSA-Konten ist, dass für dieses Konto kein Passwort verwaltet werden muss. gMSA-Konten werden auf den Servern konfiguriert und Windows übernimmt die Passwortverwaltung für das Konto.

Dies erleichtert die Verwaltung von Service Accounts, da keine manuelle Benutzerinteraktion erforderlich ist, um das Kennwort regelmäßig zu ändern. Zusätzlich werden diese Konten auf bestimmte Server eingeschränkt, so lassen sich die gMSA-Konten nicht so leicht zweckentfremden und auf vielen Servern für unterschiedliche Aufgaben nutzen.

Vorbereitung für gMSA-Konten (KDS Root Key)

Damit gMSA-Konten erstellt und genutzt werden können, wird zunächst ein KDS Root Key für das Erzeugen der Passwörter benötigt. Der KDS Root Key lässt sich mit folgendem Befehl erzeugen:

Add-KdsRootKey -EffectiveImmediately
Group Managed Service Accounts (gMSA) für Tasks und Dienste

Jetzt müssen 10 Stunden gewartet werden, bevor die ersten Konten erstellt werden können. Hierbei handelt sich um eine Funktion um sicherzustellen, dass alle Domänencontroller die Replikation abgeschlossen haben, bevor die ersten gMSA Konten erstellt werden. Dadurch wird verhindert, dass Passwörter generiert werden, bevor alle Domänencontroller in der Lage sind, die Passwortanfragen / Passwortwechsel zu beantworten. Auch wenn es nur ein Domaincontroller geben sollte, muss hier trotzdem 10 Stunden gewartet werden.

Tipp: Wer keine 10 Stunden warten will, kann den folgenden Befehl benutzen, dies funktioniert aber nur, wenn es noch keinen KDS Root Key gibt:

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

Der sichere Weg ist aber die 10 Stunden abzuwarten und die erfolgreiche Replikation zu prüfen, damit es nicht zu Problemen kommt.

gMSA-Konten erstellen

Nachdem die 10 Stunden vergangen sind, können neue gMSA-Konten mit dem folgenden Befehl erzeugt werden:

New-ADServiceAccount -Name msa_ex19ex1 -DNSHostName msa_ex19ex1.frankysweblab.de -PrincipalsAllowedToRetrieveManagedPassword EX19EX1$

Der Parameter „Name“ legt den Names des neuen Kontos fest, für den Parameter „DNSHostName“ sollte der Name des Kontos gefolgt von dem FQDN der Domain gewählt werden. Im DNS muss dieser Eintrag nicht angelegt werden. Der Parameter „PrincipalsAllowedToRetrieveManagedPassword“ gibt an, welche Server das Konto verwenden dürfen (mehrere Server lassen sich durch Komma getrennt angeben).

gMSA Konto erstellen

Das neue Konto findet sich jetzt in der OU „Managed Service Accounts“ im Active Directory:

gMSA Konto im AD

Das Konto kann nun mit den entsprechenden Berechtigungen ausgestattet werden, damit Scripte oder Dienste ausgeführt werden können. Beispielsweise lässt sich das gMSA-Konto nun zur Exchange Gruppe „View-Only Organization Management“ hinzufügen, somit könnte man mit diesem Konto Scripte starten, welche lesenden Zugriff auf die Exchange Organisation benötigen:

gMSA Exchange Berechtigungen

Sollte es nötig sein, dass lokale Administrator Rechte auf dem Server benötigt werden, kann das Konto auch zur lokalen Admin Gruppe des Servers hinzugefügt werden:

gMSA Berechtigungen

Das gMSA-Konto wechselt in der Standardeinstellung alle 30 Tage das Passwort. Der Passwort Wechsel erfolgt automatisch und es nicht manuell eingegriffen werden. Mit dem folgenden Befehl lässt sich lässt sich ein Konto mit 60 Tage Passwortwechsel Intervall erstellen:

New-ADServiceAccount -Name msa_ex19ex1 -DNSHostName msa_ex19ex1.frankysweblab.de -PrincipalsAllowedToRetrieveManagedPassword EX19EX1$ -ManagedPasswordIntervalInDays 60

Um sich alle Attribute eines des Kontos anzuschauen, kann der folgende Befehl verwendet werden:

Get-ADServiceAccount msa_ex19ex1 -Properties *
Alle Attribute

gMSA-Konten nutzen

Um einen Dienst mit einem gMSA-Konto zu starten muss nur das entsprechende Konto ausgewählt werden, dass Passwort Feld bleibt leer:

Nachdem der Dienst neu gestartet wurde, wird das gMSA-Konto benutzt. Der Abruf und das Wechseln des Passworts nach der festgelegten Zeit, passiert nun automatisch.

Bei einem geplanten Task funktioniert das Zuweisen des Kontos über die Shell mit folgendem Befehl:

schtasks /Change /TN "FrankysWeb Demo" /RU "frankysweblab\msa_ex19ex1$" /RP ""
Geplanter Task

Einschränkungen

Leider gibt es für gMSA-Konten auch Einschränkungen, für geplante Tasks und Windows Dienste eignen sich diese Konten sehr gut, jedoch können diese Konten nicht in Anwendungen eingetragen und genutzt werden. Beispielsweise benötigen viele Anwendungen einen Service Account um Informationen aus dem Active Directory abrufen zu können, diese Accounts werden dann meistens statisch in der Anwendung eingetragen. Hier funktioniert dann der automatische Passwortwechsel nicht. In diesem Fall helfen nur spezielle, meistens recht aufwendige, PAM-Lösungen oder eine gute Dokumentation verbunden mit sehr viel Disziplin und einem guten Auditprozess.

9 thoughts on “Group Managed Service Accounts (gMSA) für Tasks und Dienste”

  1. Ich bin neu in dem Thema und habe eine Frage. Wir hatten bisher keine gMSA. Also habe ich wie oben beschrieben den KDSRootkey erzeugt. Eine Abfrage mit Get-KdsRootKey | fl liefert mir 2 Einträge. Einer davon ist der neu erzeugte. Es gibt aber noch einen von 2018 mit folgendem DC:
    DomainController : CN=namedesdc\0ADEL:domainid,CN=Deleted Objects,DC=unsere_domäne,DC=de

    Dieser DC wurde vor einigen Wochen herabgestuft und durch einen neuen mit dem selben Namen ersetzt.
    Test-KdsRootkey gibt für beide KeyIDs den Wert True zurück.

    Frage: kann ich diesen alten Key löschen ?

    Danke und Grüße,

    MG

    Reply
  2. Ich möchte gMSA verwenden um die WsusDBMaintenance Aufgabe auszuführen.
    Mit dem Administratorkonto läuft es.
    Nach Umstellung auf gMSA kommt die Fehlermeldung: Es konnte keine Anmeldung gefunden werden, die mit dem angegebenen Namen übereinstimmt. [Client:]
    Es ist ein neu installierter Windows Server 2022 mit der Windows internen Datenbank für den WSUS.
    Kann mir jemand helfen?

    Reply
  3. Hallo miteinander,

    bei mir (Server 2019) besteht das Problem, dass ein Task nicht unter Verwendung der Option „-LogonType Password“ mit Powershell angelegt werden kann. Dann läuft der Task nur, wenn der Service Account angemeldet ist (macht ja wenig Sinn). Die Fehlermeldung sagt falscher User oder Passwort.
    Der Fehler bleibt, auch wenn ich erst in der Gui einen Task anlege und ihn später mit

    $pric = New-ScheduledTaskPrincipal -UserId domain\service$ -LogonType Password
    Set-ScheduledTask -TaskName Name -Principal $pric

    ändern will.

    Danke
    Beste Grüße
    Thomas

    Reply
  4. Hallo Zusammen,

    hat jemand RBAC und gMSA aktiv am laufen?
    einige Befehle wie Get-Mailbox funktionieren, andere Befehle wie Get-AcceptedDomain, oder Get-MailboxStatistics funktionieren nicht.
    Fehler ist wahlweise „Zugriff verweigert“, oder „Objekt nicht gefunden“, je nach Befehl. Der gMSA ist dabei Mitglied von „View-Only Organization Management“ (normaler User darin geht). Sobald der gMSA zur Gruppe Exchange Trusted Subsystem geht auch alles. Ist aber natürlich maximal unschön.

    Gruß
    Basti

    Reply
  5. Servus Frank

    Das Installieren des MSA auf einem System mit Install-ADServiceAccount ist nicht mehr nötig, oder nicht mehr nötig mit einem gMSA?

    LG
    Michael

    Reply
    • Hallo zusammen,

      was macht man wenn man die gMSA nicht einem Task zuordnen kann?

      PS C:\Users\XXXXXX> schtasks /Change /TN „Specops Breached Password List Update“ /RU „mydomain\msa.specops$“ /RP „“
      ERROR: The user name or password is incorrect.

      Den User habe ich wie folgt angelegt:
      PS C:\Users\XXXXXX> New-ADServiceAccount -Name msa.specops -DNSHostName msa.specops.mydomain.org -PrincipalsAllowedToRetrieveManagedPassword DC01$,DC02$

      Reply
      • Mhhh ggf. liegt ja hier das Problem :/

        PS C:\Users\XXXXXX> Test-ADServiceAccount -Identity $MsaIdentity.sAMAccountName
        False
        WARNING: Test failed for Managed Service Account msa.specops. If standalone Managed Service Account, the account is linked to another computer object in the Active Directory. If group Managed Service Account, either this computer does not have permission to use the group MSA or this computer does not support all the Kerberos encryption types required for the gMSA. See the MSA operational log for more information.

        Reply
  6. Die vermutlich häufigste Verwendung wird man beim AADC, ADFS und SQL Servern finden. Da gibts dann auch gute Wizards und Anleitungen von Microsoft.

    Reply

Leave a Comment