Stand: 30. September 2026
Klassische Service Accounts gehören zu den hartnäckigsten Sicherheitsproblemen in Active-Directory-Umgebungen. Sie besitzen oft langlebige Passwörter, weitreichende Rechte und werden von Anwendungen verwendet, die niemand anfassen möchte. Windows Server 2025 führt mit delegated Managed Service Accounts, kurz dMSA, einen neuen Weg ein, solche Konten schrittweise abzulösen.
dMSA verbindet die Authentifizierung stärker mit der Identität des Computers, auf dem der Dienst tatsächlich laufen darf. Das alte Service-Account-Passwort kann nach der Migration deaktiviert werden. Damit wird es deutlich schwieriger, gestohlene Zugangsdaten einfach auf einem anderen System zu verwenden.
Was dMSA von klassischen Service Accounts unterscheidet
Ein klassisches Domänenkonto für einen Windows-Dienst funktioniert technisch wie ein Benutzerkonto. Das Passwort muss gesetzt, geschützt, rotiert und in der Anwendung aktualisiert werden. In der Praxis entstehen deshalb häufig sehr lange Passwortlaufzeiten oder Ausnahmen von normalen Policies.
dMSA nutzt dagegen von Active Directory verwaltete, zufällige Schlüssel und bindet die Nutzung an definierte Maschinenidentitäten. Microsoft beschreibt dMSA ausdrücklich als Migrationspfad weg von traditionellen Service Accounts.
dMSA, gMSA und klassische Konten
gMSA hat bereits viele Probleme klassischer Service Accounts gelöst, insbesondere die automatische Passwortverwaltung. dMSA geht einen Schritt weiter, weil die Authentifizierung stärker an die berechtigte Maschine gebunden wird. Dadurch sinkt das Risiko, dass ein kompromittiertes Service-Konto auf beliebigen Hosts weiterverwendet werden kann.
Für neue Anwendungen bleibt gMSA in vielen Szenarien weiterhin sinnvoll. dMSA ist besonders interessant, wenn bestehende klassische Service Accounts migriert werden sollen.
Schutz gegen Credential Harvesting
Service Accounts sind attraktive Ziele für Kerberoasting und andere Credential-Angriffe. Ein Angreifer versucht dabei, verwertbare Authentifizierungsdaten zu erhalten und offline zu knacken oder in anderen Systemen wiederzuverwenden. dMSA reduziert genau diese Angriffsfläche, weil das alte Passwort nach erfolgreicher Migration blockiert wird und die neuen Secrets nicht wie klassische Passwörter verfügbar sind.
Wer seine Umgebung parallel von NTLM-Abhängigkeiten befreit, sollte auch die NTLM-Nutzung inventarisieren und Service Accounts gezielt in Kerberos-Tests aufnehmen.
Voraussetzungen und typische Stolpersteine
Microsoft verlangt für dMSA mindestens einen Windows-Server-2025-Domänencontroller, der für die beteiligten Systeme erreichbar ist. Außerdem muss die AD-Umgebung entsprechend vorbereitet sein. In Szenarien über mehrere Forests spielt auch die Vertrauensstellung eine Rolle.
Vor einer Migration muss genau bekannt sein, auf welchen Servern ein Service Account verwendet wird. Wird das alte Konto deaktiviert, obwohl einzelne Systeme dMSA noch nicht unterstützen oder nicht korrekt zugeordnet wurden, scheitert dort die Authentifizierung.
Ein sicherer Migrationsablauf
1. Discovery: Service Account identifizieren, SPNs, Gruppenmitgliedschaften, Rechte und verwendende Server dokumentieren.
2. Abhängigkeiten prüfen: Dienste, Tasks, IIS Application Pools, SQL-Verbindungen und geplante Jobs erfassen.
3. dMSA vorbereiten: Zielkonto erstellen und berechtigte Maschinen festlegen.
4. Migration starten: Den Microsoft-Migrationspfad verwenden und Eventlogs beobachten.
5. Funktionstests: Kerberos-Tickets, SPNs, Netzwerkzugriffe und Applikationsfunktionen prüfen.
6. Legacy-Konto abschalten: Erst wenn alle beteiligten Systeme erfolgreich migriert sind.
Warum SPNs und Kerberos weiterhin wichtig sind
dMSA löst nicht automatisch jede Authentifizierungsfrage. Dienste, die Kerberos verwenden, hängen weiterhin von korrekten SPNs, DNS und Zeit-Synchronisation ab. Gerade in SQL-, IIS- oder SFTP-Szenarien sollte geprüft werden, welche Identität den Dienst startet und welche SPNs auf welchem Objekt registriert sind.
Der Artikel Active Directory Pentest: typische Risiken im Unternehmensnetzwerk zeigt, warum Service- und Berechtigungskonten bei AD-Sicherheitsprüfungen besondere Aufmerksamkeit verdienen.
dMSA und Credential Guard
Microsoft verbindet dMSA mit Mechanismen wie Credential Guard, um Secrets zusätzlich zu isolieren. Auf modernen Windows-Server-2025-Systemen entsteht damit eine deutlich stärkere Identitätsgrenze zwischen Dienst und Host.
Fazit
dMSA ist kein einfacher Ersatzknopf für alle Service Accounts, aber ein wichtiger Baustein für moderne Active-Directory-Sicherheit. Unternehmen erhalten einen realistischen Migrationspfad weg von statischen Dienstkonten, reduzieren Passwortmanagement und binden Service-Identitäten stärker an autorisierte Systeme. Wer Windows Server 2025 einführt, sollte deshalb nicht nur Betriebssystem-Features betrachten, sondern auch die Service-Account-Architektur neu bewerten.
Weiterführende Quellen
Microsoft Learn: Delegated Managed Service Accounts
Microsoft Learn: dMSA einrichten
Titelbild: Zulfugar Karimov / Unsplash
Autor: Salman Dolatpanah Gortlar