MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

dMSA - Delegated Managed Service Accounts

Mit Windows 2025 Active Directory hat Microsoft einen weiteren Benutzertyp eingeführt, um speziell Dienstkonten noch weiter abzusichern.

Dienstkonten, gMSA und dMSA

Zugriff auf nicht öffentliche Informationen sollten immer nur authentifiziert erfolgen und dazu gibt es schon seit Jahrzehnten die Anlage von Benutzerkonten mit Kennwort. Seit Microsoft mit "Domänen" gearbeitet hat, gibt es daher "normale Benutzer", Computerkonten und zur Berechtigungsvergabe sollten Sicherheitsgruppen genutzt werden. Über spezielle Gruppen wie Domain-Administratoren, Schema-Administratoren etc. können Benutzer auch privilegiert werden. Wenn Programme ohne Mithilfe eines Benutzers ablaufen sollen, dann könnten diese lokal auf einem Computer als "Local System"  oder "Network System" laufen. Später kam dann noch "Local Service" dazu.

Allerdings sind diese Konten auf den lokalen Computer beschränkt. Wenn ein Programm aber auf andere Computer über Windows Authentifizierung zugreifen möchte, muss es mit einem "Domain Konto" arbeiten oder sich an jedem entfernten Computer explizit anmelden, was aber unsicherer ist. Aber ein "Domain Konto" für einen Dienst ist auch einfach nur wie ein "Benutzer" zu sehen und wenn das Kennwort des Dienstkontos jemandem bekannt ist, kann er sich damit auch interaktiv anmelden. Das ist ein Sicherheitsrisiko, insbesondere wenn die Dienste sehr umfangreiche Berechtigungen haben.

Daher hat Microsoft zusätzliche Konten eingeführt.

Konto Betriebssystem/AD Beschreibung

sMSA

Windows 2008R2

Standalone Managed Service Accounts waren der ersten Schritt, auf einem einzelnen Server ein besonderes Dienstkonto zu nutzen, welches sich nur auf diesem Server anmelden konnte. Windows sorgte für regelmäßige Kennwortänderungen

gMSA

Windows 2012

Die Group Managed Service Accounts erlaubten dann den Einsatz auf mehreren Server im Active Directory. Automatische Kennwortänderungen haben alle Systeme umgesetzt. Das Kennwort ist aber nicht auf die Maschine gebunden. Die gMSA wird in der Regel durch die Software bei der Installation eingerichtet.

dMSA

Windows 2025

Mit Windows 2025 wurde die neuen "Delegated Managed Service Accounts" eingeführt. Sie sollen nun die beste Variante zur Migration von klassischen "Dienstkonten" sein, denn neben den Vorteilen des gMSA wird nun der Zugriff auch noch auf die Maschine beschränkt und eine Migration vereinfacht. Er wird vom Administrator verwaltet.

Die dMSA-Konten sind damit ideal für den Einsatz als Dienstkonten, da sie auf mehreren Systemen genutzt werden können, Windows das Kennwort regelmäßig ändert, eine Migration vereinfacht wird und die Beschränkung der Nutzung auf ausgewählte Domain-Computer die Sicherheit erhöht

Migration

Die Beschränkung auf das Computerkonto bedeutet natürlich, dass im Benutzerkonto eine Liste der "zugelassenen Computer" hinterlegt wird und zudem die Berechtigungen des abgelösten alten Dienstkontos mitgeführt werden müssen. Darum kümmert sich Windows, denn für die Migration von einem bestehenden Konto in ein neues dMSA-Konto müssen Sie folgende Schritte nutzen, nachdem Sie das Konto angelegt haben:

  1. Standalone dMSA anlegen
    Zuerst legen Sie einen neues Dienstkonto mit New-ADServiceAccount an.
  2. Migration starten
    Mit dem Befehl "Start-ADServiceAccountMigration" weisen Sie das Active Directory an, alle Zugriffe mit dem Dienstkonto mit dem Computer zu ermitteln und den Computer automatisch in "msDS-groupMSAMembership" aufzunehmen.
  3. Migration abschließen
    Wenn Sie sicher sind, dass alle Computer mindestens einmal sich neu angemeldet haben und damit die Liste in "msDS-groupMSAMembership" komplett ist, dann können Sie dieses "Selbsteintragen" mit dem PowerShell-Befehl "Complete-ADServiceAccountMigration" wieder abschalten. Das alte Dienstkonto bleibt als deaktiviertes Konto erhalten.

Beachten Sie aber, dass nicht nur ihre DCs mit Windows 2025 laufen müssen, sondern auch Member-Server und Clients (Ab Windows 11 24h2) für die Nutzung von dMSA vorbereitet werden müssen.

Konfiguration und Nutzung

Eine Beschreibung, wie ich z.B. ein PowerShell-Script oder einen kommerziellen Dienst auf dMSA umgestellt habe, reiche ich später nach.

BadSuccessor

Es bleibt natürlich nicht aus, dass Security-Spezialisten sich neue Funktionen oder Updates von Microsoft genau anschauen. Diesmal hat das Security Research Team von Akamai herausgefunden, dass bei der Einrichtung von dMSA-Konten eine Lücke bestehen kann. Ein bösartiger Admin, der neue Konten anlegen kann, kann Auch ein dMSA-Konto anlegen und über die Logik einer Migration dieses so einrichten, dass der damit jedes beliebige andere Konto per Impersonation übernehmen kann.

Wer also heute schon mit entsprechenden Berechtigungen ein Benutzerkonto in einer beliebigen OU anlegen kann, kann in das Objekte auch das Feld "msDS-ManagedAccountPrecededByLink" den DN eines Kontos schreiben, welches irgendwann in der Zukunft einmal ersetzt werden soll. Ein Angreifer wird dort dann z.B. ein DomainAdmin-Konto eintragen und den Status auf "Migration completed" (Feld "msDS-DelegatedMSAState = 2) setzen.

Danach fordert der Angreifer ein Kerberos-Ticket für das dMSA-Konto an, dessen Kennwort er ja kennt und das Kerberos TGT-Ticket enthält auch die Gruppenmitgliedschaften des angeblich migrierten Kontos. Wenn das Quellkonto, welches immer noch da ist, dann Mitglied in der DomainAdmin-Gruppe ist, dann ist dies auch im TGT des dMSDA-Kontos enthalten.

BadSuccessor: Abusing dMSA to Escalate Privileges in Active Directory
https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory

Akamai hat zugleich ein PowerShell-Skript veröffentlicht, welches ihr Active Directory auf solche riskanten Berechtigungen prüft

Github BadSuccessor
https://github.com/akamai/BadSuccessor/blob/main/Get-BadSuccessorOUPermissions.ps1 

Der Sachverhalt wurde von Akamai am 1. April 2025 an Microsoft gemeldet aber erst einmal nicht als "kritisch" angesehen.

Man kann hier geteilter Meinung sein. Aus meiner Sicht ist es "überraschend" und ein Risiko, wenn jeder, der einen AD-Benutzer irgendwo anlegen kann, sich so Privilegien beschaffen kann und sollte umgehend unterbunden werden, z.B. indem die Anlage von dMSA-Konten und die Migration auf Domain Admins beschränkt sein sollte und nur über explizite Berechtigungen oder Freigaben z.B. auf spezielle OUs delegiert werden.

Das Risiko ist für den Firmen groß, die im guten Glauben mit Bordmittel die Neuanlage und Verwaltung von Benutzerkonten z.B.: auf bestimmte OUs an ausgewählte Benutzer delegiert haben und damit eine Hintertür erlauben. Ganz kleine Firmen, die sowieso alles mit dem Domain Admin verwalten, sind eh leichter direkt zu hacken. Größere Firmen, die über ein Provisioning die Neuanlage an bestimmte Dienstkonten delegiert haben, sollte nur prüfen, ob wirklich nur die Provisioningkonten diese Berechtigungen haben und ggfls. den Nutzerkreis einschränken.

BadSuccessor - Gegenmaßnahmen

Zuerst: Das Problem betrifft sie nur wenn sie:

  1. Mindestens einen Windows 2025 DC haben
    Die Funktion dMSA gibt es erst ab Windows 2025 DCs. Wer noch Windows 2022 oder früher als Domain Controller nutzt, hat noch kein Problem.
  2. Anlage von Benutzern durch "Nicht Domain Admin"
    Zudem müssen Sie die Aufgabe "Neuanlage von Benutzern" an andere Anwenderkonten delegiert haben, die nicht eh schon Domain Admin sind. Nur diese User-Administratoren könnten mit Windows 2025 dann einen dMSA anlegen und so umstellen, dass Sie z.B. Domain Admin werden könnten.

Die erste Gegenmaßnahme besteht darin, das Neuanlegen und Verwalten von Benutzerkonten und insbesondere die Schreibvorgänge auf das Feld "msDS-ManagedAccountPrecededByLink" auf wirklich vertrauenswürdige Personen zu beschränken. Wer ein einen entsprechenden "Provisioning-Prozess" etabliert hat, bei dem kein Benutzer sondern nur ein Service die neuen Konten anlegt und verwaltet, ist damit auch gut abgesichert.

Dennoch sollten Sie prüfen, auf welche Benutzer jemand das Recht hätte, die Felder zu bearbeiten. Dazu gibt es ein fertiges PowerShell Script

Github BadSuccessor
https://github.com/akamai/BadSuccessor/blob/main/Get-BadSuccessorOUPermissions.ps1 

Auch über das Windows Eventlog können Sie die Ablage von dMSA-Konten protokollieren.

Microsoft-Windows-Security-Auditing Event ID 5137 : Neuanlage eines dMSA-Kontos
Microsoft-Windows-Security-Auditing Event ID 5136 : Änderung eines bestehenden dMSA-Kontos
Directory Services                  Event ID 2946 : Das Kennwort eines gMSA/dMSA-Kontos wurde abgerufen

Damit können Sie überwachen, ob und wie diese Konten verwendet werden. Allerdings hilft das nur, wenn die Angreifer nach dem Erhalt der Privilegien nicht sofort aktiv werden. Insofern helfen diese Logs ehe, wenn interne Mitarbeiter so nur temporär einen Zugriff durchführen aber ansonsten noch unbemerkt bleiben wollen.

Weitere Links