Delegated Managed Service Account
Neuer Kontotyp in Windows Server 2025, der bestehende Service Accounts ohne Unterbrechung ablösen kann — mit automatischer Credential-Rotation und maschinengebundener Authentifizierung.
Delegated Managed Service Accounts (dMSA) sind ein mit Windows Server 2025 eingeführter Kontotyp in Active Directory, der die automatische Ablösung klassischer Service Accounts ermöglicht. Im Gegensatz zu gMSA, bei denen ein komplett neues Konto erstellt und der Dienst manuell umkonfiguriert werden muss, kann ein dMSA einen bestehenden Service Account in-place übernehmen — einschließlich aller Berechtigungen und SPNs. Das Passwort des ursprünglichen Kontos wird dabei deaktiviert und die Authentifizierung automatisch auf den dMSA umgeleitet.
Funktionsweise und Maschinenidentität
Die Authentifizierung eines dMSA ist an eine konkrete Maschinenidentität gebunden: Nur der in Active Directory zugeordnete Computer kann die Credentials vom Domain Controller abrufen. Das Passwort wird vollständig vom DC verwaltet, regelmäßig rotiert und ist — anders als bei gMSA — ausschließlich auf dem Domain Controller gespeichert. Kein Administrator und kein anderes System kennt oder besitzt das aktuelle Passwort. In Kombination mit Credential Guard werden die dMSA-Credentials zusätzlich in einer virtualisierten Sicherheitsumgebung (VBS) geschützt und Service-Account-Tickets automatisch an die Maschinenidentität gebunden.
Migration bestehender Service Accounts
Der zentrale Vorteil gegenüber gMSA liegt im Migrationspfad. Ein dMSA kann als Nachfolger eines bestehenden Service Accounts konfiguriert werden. Während einer Lernphase ermittelt das System automatisch, auf welchen Maschinen der ursprüngliche Account verwendet wird. Nach Abschluss dieser Phase — Microsoft empfiehlt mindestens zwei Ticket-Lebenszeiten (entspricht 14 Tagen) — wird die Authentifizierung vollständig auf den dMSA umgestellt. Der ursprüngliche Account bleibt als Objekt erhalten, kann sich aber nicht mehr mit seinem alten Passwort anmelden. Anfragen werden über die Local Security Authority (LSA) transparent auf den dMSA umgeleitet.
dMSA vs. gMSA
| Merkmal | gMSA | dMSA |
|---|---|---|
| Verfügbar ab | Windows Server 2012 | Windows Server 2025 |
| Migration bestehender Accounts | Nein — neues Konto erforderlich | Ja — In-Place-Ablösung mit Lernphase |
| Passwortspeicherung | Abrufbar von berechtigten Hosts | Ausschließlich auf dem DC |
| Maschinengebundene Authentifizierung | Nein | Ja — an spezifische Computeridentität gebunden |
| Credential Guard Integration | Begrenzt | Vollständig — VBS-Schutz und Ticket-Binding |
| Multi-Server-Betrieb | Ja — mehrere Hosts gleichzeitig | Ein Host pro dMSA |
Schutz gegen Kerberoasting
Klassische Service Accounts mit statischen Passwörtern sind das primäre Ziel für Kerberoasting: Ein normaler Domänenbenutzer fordert ein Service Ticket an und versucht, den Passwort-Hash offline zu knacken. dMSAs entschärfen diesen Angriffsvektor durch die Kombination aus automatischer Rotation und maschinengebundener Authentifizierung. Da das Passwort regelmäßig gewechselt wird und nie außerhalb des DC existiert, ist ein Offline-Angriff auf den Hash praktisch wirkungslos.
Sicherheitshinweis: BadSuccessor
Die dMSA-Migrationsfunktion brachte auch einen neuen Angriffsvektor mit sich. Sicherheitsforscher von Akamai entdeckten 2025 die als „BadSuccessor" (CVE-2025-53779) bekannte Schwachstelle: Ein Angreifer mit Schreibrechten auf einer beliebigen Organisationseinheit konnte einen dMSA als Nachfolger eines privilegierten Kontos konfigurieren und dessen Berechtigungen übernehmen — selbst wenn im Unternehmen keine dMSAs im Einsatz waren. Microsoft hat die Schwachstelle gepatcht. Dennoch unterstreicht BadSuccessor, dass neue Sicherheitsfeatures stets mit sorgfältigem Berechtigungsmanagement nach dem Least-Privilege-Prinzip und einem sauberen Tiering-Modell einhergehen müssen.
Relevanz für KMUs
dMSA löst das häufigste Problem im Service-Account-Management: statische Passwörter, die seit Jahren nicht rotiert wurden. Für Unternehmen, die den Schritt zu gMSA bisher gescheut haben — etwa weil die Umstellung eine koordinierte Neukonfiguration aller betroffenen Dienste erfordert — bietet dMSA einen deutlich einfacheren Migrationspfad. Voraussetzung ist allerdings ein Domain Functional Level von Windows Server 2025, was für viele Mittelstandsumgebungen erst mittelfristig realistisch ist. Der pragmatische Ansatz: Bereits heute alle kompatiblen Dienste auf gMSA migrieren und dMSA als Zielbild für die verbleibenden, schwer migrierbaren Service Accounts einplanen. In jedem Fall sollte die OU-Berechtigungsstruktur überprüft werden, um das BadSuccessor-Risiko auch ohne Patch proaktiv zu minimieren.