Windows & Server

Delegated Managed Service Account (dMSA)

Overview

Ein Delegated Managed Service Account (dMSA) ist ein Kontotyp in Active Directory, den Microsoft mit Windows Server 2025 eingeführt hat. Er ersetzt klassische Dienstkonten mit statischem Kennwort durch ein verwaltetes Konto mit vollständig zufälligen Schlüsseln. Das Kennwort des alten Kontos wird deaktiviert, die Authentifizierung ist an die Identität der in AD hinterlegten Computer gebunden. Microsoft zielt damit auf Kerberoasting, bei dem Angreifer Diensttickets offline knacken.

Unterschied zum Group Managed Service Account (gMSA, eigener Eintrag): Auch beim gMSA rotiert Windows das Kennwort automatisch, es ist aber nicht an eine Maschine gebunden und kann gestohlen werden. Beim dMSA leitet sich das Geheimnis aus dem Computerkonto ab und ist nur auf dem Domain Controller abrufbar, Credential Guard sichert die Bindung zusätzlich ab. Eine Migration von gMSA oder sMSA zu dMSA ist nicht vorgesehen, dMSA löst klassische Benutzerkonten ab, unter denen Dienste laufen.

Sicherheitslage: Am 21. Mai 2025 veröffentlichte Akamai den Angriff „BadSuccessor“. Wer in einer beliebigen OU dMSA-Objekte anlegen durfte, konnte über das Attribut msDS-ManagedAccountPrecededByLink die Rechte jedes Kontos übernehmen, bis hin zu Domänen-Admins. Betroffen war jede Domäne mit mindestens einem Domain Controller unter Windows Server 2025, auch wenn dMSA gar nicht genutzt wurde. Microsoft hat die Lücke als CVE-2025-53779 am Patchday im August 2025 geschlossen: Der KDC stellt seither nur noch Tickets aus, wenn die Verknüpfung wie bei einer echten Migration in beide Richtungen besteht.

Abgrenzung: Active Directory und Domain Controller haben eigene Einträge, Kerberos beschreibt das Ticketverfahren, auf dem dMSA aufsetzt. Windows LAPS verwaltet lokale Administratorkennwörter, keine Dienstkonten.

How it works

Die Migration eines bestehenden Dienstkontos läuft in Phasen:

  1. Voraussetzungen: mindestens ein erreichbarer, beschreibbarer Domain Controller mit Windows Server 2025, ein KDS-Root-Key (Get-KdsRootKey, sonst Add-KdsRootKey) und auf den Clients der Registry-Wert DelegatedMSAEnabled = 1 unter HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters.
  2. dMSA anlegen mit New-ADServiceAccount -CreateDelegatedServiceAccount, sinnvollerweise mit -KerberosEncryptionType AES256.
  3. Migration starten mit Start-ADServiceAccountMigration -Identity <dMSA> -SupersededAccount <DN des Dienstkontos>. In dieser Phase lernt der dMSA, welche Computer das Konto nutzen, und nimmt sie als berechtigte Prinzipale auf.
  4. Nach mindestens zwei Ticket-Lebensdauern (14 Tage), empfohlen sind vier (28 Tage), schließt Complete-ADServiceAccountMigration ab: SPNs, Delegierungseinstellungen und Authentifizierungsrichtlinien wandern zum dMSA, das alte Konto wird deaktiviert und verliert seine SPNs.
  5. Anmeldungen am alten Konto leitet die LSA auf den dMSA um, der Dienst muss nicht umkonfiguriert werden.

Fehlgriffe lassen sich mit Undo-ADServiceAccountMigration oder Reset-ADServiceAccountMigration zurücknehmen. Den Stand zeigt das Attribut msDS-DelegatedMSAState (1 = Migration gestartet, 2 = abgeschlossen, 3 = eigenständiger dMSA). Die Ereignisse 307 (Migration), 308 (Berechtigung hinzugefügt) und 309 (Schlüsselabruf) erscheinen im Log Security-Kerberos/Operational, das standardmäßig deaktiviert ist.

Benefits

  • Kerberoasting läuft ins Leere, weil das Dienstkonto kein statisches, von Menschen gewähltes Kennwort mehr hat.
  • Migration ohne Anwendungsumbau: Der Dienst bleibt auf das alte Konto konfiguriert, die Umleitung übernimmt Windows.
  • Nur zugeordnete Computer können das Konto nutzen, ein abgegriffenes Geheimnis hilft auf einem fremden Rechner nicht weiter.
  • Rechte, SPNs und Delegierungen werden automatisch übernommen, das erspart die fehleranfällige Neuvergabe.
  • Kein Kennwort im Passwort-Safe mehr, da Windows die Schlüssel periodisch erneuert.

Practical example

Ein Lebensmittelhersteller mit 600 Mitarbeitenden betreibt eine Warenwirtschaft, deren Dienst seit Jahren unter einem Benutzerkonto mit nie geändertem Kennwort und weitreichenden Rechten läuft. Nach Einführung der ersten Domain Controller mit Windows Server 2025 legt die IT einen dMSA an, startet die Migration und lässt sie vier Wochen im Startzustand, damit alle Anwendungsserver erfasst werden. Danach schließt sie die Migration ab, das alte Konto wird deaktiviert, bleibt aber als Verknüpfung erhalten. Parallel entzieht sie Helpdesk-Gruppen das Recht, in OUs beliebige Objekte anzulegen, weil genau das die Voraussetzung für BadSuccessor war.

Things to keep in mind

  • Installiere auf allen Domain Controllern mit Windows Server 2025 die Updates ab August 2025 (CVE-2025-53779), auch wenn Du dMSA nicht nutzt.
  • Beschränke das Anlegen von dMSA-Objekten und das Schreiben der Migrationsattribute auf Tier-0-Admins; Akamai fand in 91 Prozent der untersuchten Umgebungen Nicht-Admins mit den nötigen OU-Rechten.
  • Überwache per SACL das Anlegen von dMSA-Objekten (Event 5137) und Änderungen an msDS-ManagedAccountPrecededByLink (Event 5136).
  • Lösche das ursprüngliche Dienstkonto nach der Migration nicht, weil der Dienst weiterhin darauf konfiguriert ist und sonst stoppt.
  • Migriere nicht bei gestörter AD-Replikation, und stelle sicher, dass alle Computer, die das Konto nutzen, dMSA unterstützen; sonst scheitert die Anmeldung, sobald das alte Konto deaktiviert ist.

Licensing & availability

dMSA ist Bestandteil von Active Directory Domain Services in Windows Server 2025 und verursacht keine Zusatzkosten. Voraussetzung ist mindestens ein erreichbarer Domain Controller mit Windows Server 2025, eine reine Schemaerweiterung auf 2025 reicht nicht. Lizenziert wird wie bei Windows Server üblich pro Kern plus CALs. Stand: Oktober 2026.

Conclusion

dMSA ist der sinnvolle Weg, alte Dienstkonten mit statischen Kennwörtern loszuwerden, ohne Anwendungen umzubauen. Patche zuerst Deine Domain Controller mit Windows Server 2025 und räume die OU-Berechtigungen auf, denn die Funktion steht mit dem ersten solchen DC in der Domäne bereit, ob Du sie nutzt oder nicht.

Further reading

Related articles