Dienstkonten zu gMSA und dMSA migrieren

Ein statisches Dienstkonto ist eine langlebige Anmeldeinformation mit angehängtem SPN, einem Kennwort, das niemand zu ändern wagt, und Anmelderechten auf Servern über mehrere Tiers hinweg. Es ist das Lehrbuchziel für Kerberoasting, und landet sein Kennwort in einer Skriptfreigabe oder Konfigurationsdatei, wird es zu einem Lateral-Movement-Pfad, der jedes andere Härtungsprojekt überlebt. Der Grundlagenleitfaden zur Dienstkontenhärtung erklärt, warum verwaltete Konten das lösen; dieser Leitfaden ist das Migrations-Runbook: den Bestand inventarisieren, den KDS-Stammschlüssel korrekt einrichten, den Kennwortabruf eng begrenzen, gängige Workloads umstellen und dMSA unter Windows Server 2025 für die Konten nutzen, die sich nicht ohne Weiteres umstellen lassen.

Das Vorgehen folgt dem Rest dieser Website: den Bestand messen, die Abhängigkeiten jedes Kontos prüfen, die neue Identität pro Anwendung durchsetzen und dann überprüfen, dass nichts mehr das alte Konto nutzt, bevor Sie es deaktivieren.

Messen: jede Dienstidentität inventarisieren

Beginnen Sie mit Benutzerobjekten, die sich wie Dienste verhalten: SPNs, nicht ablaufende Kennwörter, alte Kennwörter und Anmeldeaktivität von Servern statt von Arbeitsstationen.

Get-ADUser -Filter 'ServicePrincipalName -like "*" -or PasswordNeverExpires -eq $true' `
    -Properties ServicePrincipalName, PasswordNeverExpires, PasswordLastSet, LastLogonTimestamp, Description, adminCount |
  Select-Object SamAccountName, adminCount, PasswordNeverExpires, PasswordLastSet,
    @{n='LastLogon';e={[datetime]::FromFileTime($_.LastLogonTimestamp)}},
    @{n='SPNs';e={$_.ServicePrincipalName -join ';'}}, Description |
  Export-Csv .\service-account-inventory.csv -NoTypeInformation

Ermitteln Sie dann, wo jedes Konto tatsächlich läuft. Auf Mitgliedsservern sind der Dienststeuerungs-Manager und die Aufgabenplanung die üblichen Nutzer:

# Gegen eine Serverliste von einem Admin-Host des passenden Tiers ausführen
$servers = Get-Content .\servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-CimInstance Win32_Service | Where-Object StartName -match '\\' |
        Select-Object @{n='Host';e={$env:COMPUTERNAME}}, Name, StartName
    Get-ScheduledTask | Where-Object { $_.Principal.UserId -match '\\' } |
        Select-Object @{n='Host';e={$env:COMPUTERNAME}}, TaskName, @{n='StartName';e={$_.Principal.UserId}}
}

Dabei entgehen Ihnen IIS-Anwendungspools, COM+-Anwendungen, SQL-Agent-Proxys und in Anwendungen gespeicherte Anmeldeinformationen. Ergänzen Sie daher um Anmeldeereignisse: Ereignis 4624 mit Anmeldetyp 5 (Dienst) und Typ 4 (Batch) auf Mitgliedsservern sowie Ereignis 4769 auf Domänencontrollern, das zeigt, welche SPNs von wem angefordert werden. Die Referenz der Ereignis-IDs listet die Felder auf, die sich zu extrahieren lohnen.

Auditieren: das Ziel pro Konto festlegen

Ordnen Sie jedes Konto einer von vier Kategorien zu:

1. Tot: seit 90+ Tagen keine Anmeldungen und kein Nutzer gefunden. Deaktivieren, einen Zyklus abwarten, löschen.
2. gMSA-kompatibel: Windows-Dienste, geplante Aufgaben, IIS-Anwendungspools, SQL-Server-Engine und -Agent, die meisten Microsoft-Serverprodukte. Zu gMSA migrieren.
3. Schwer umzustellen: Der Kontoname steckt in vielen Clients, einer Hersteller-Appliance oder in ACLs, die sich nicht ohne Weiteres übertragen lassen. Kandidat für dMSA, wenn Sie DCs mit Windows Server 2025 haben.
4. Inkompatibel: Die Anwendung braucht ein Kennwort, das sie eintippen kann, oder läuft auf einer Nicht-Windows-Plattform. Behalten Sie ein normales Konto mit einem zufälligen Kennwort von mindestens 30 Zeichen, nur AES und einer dedizierten fein abgestuften Kennwortrichtlinie.

Halten Sie außerdem fest, ob das Konto Delegierung benötigt. Ein gMSA unterstützt eingeschränkte Delegierung und ressourcenbasierte eingeschränkte Delegierung wie jedes andere Prinzipal; übernehmen Sie beim Umzug keine uneingeschränkte Delegierung.

Durchsetzen: das gMSA-Fundament einmal aufbauen

KDS-Stammschlüssel

gMSA-Kennwörter werden aus dem KDS-Stammschlüssel der Gesamtstruktur, der SID des gMSA und dem aktuellen Zeitintervall abgeleitet. Der Schlüssel muss existieren und repliziert sein, bevor ein DC ein Kennwort berechnet.

Get-KdsRootKey | Select-Object KeyId, EffectiveTime, CreationTime

# Produktion: einmal anlegen, dann die Replikation abwarten (standardmäßig nach 10 Stunden wirksam)
Add-KdsRootKey -EffectiveImmediately

Trotz seines Namens wartet -EffectiveImmediately in der Praxis das 10-stündige Sicherheitsfenster ab; das Rückdatieren von -EffectiveTime ist nur für Labore mit einem einzigen DC gedacht. Der KDS-Stammschlüssel liegt in der Partition Configuration, und wer ihn lesen kann (Domain Admins, Enterprise Admins, SYSTEM auf einem DC), kann jedes gMSA-Kennwort offline berechnen – der als Golden gMSA bekannte Angriff. Behandeln Sie ihn als Tier-0-Material und nehmen Sie ihn in Ihren Plan zur Gesamtstruktur-Wiederherstellung auf.

Abrufgruppen

Legen Sie pro gMSA eine Sicherheitsgruppe an, die nur die Computerkonten enthält, auf denen der Workload läuft. Diese Gruppe wird in msDS-GroupMSAMembership eingetragen, sichtbar als PrincipalsAllowedToRetrieveManagedPassword.

New-ADGroup -Name "gMSA-svc-sqlapp-Hosts" -GroupScope Global -GroupCategory Security `
    -Path "OU=gMSA Groups,OU=Tier1,DC=corp,DC=example,DC=com"
Add-ADGroupMember "gMSA-svc-sqlapp-Hosts" -Members "SQL01$","SQL02$"

New-ADServiceAccount -Name "gmsa-sqlapp" `
    -DNSHostName "gmsa-sqlapp.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "gMSA-svc-sqlapp-Hosts" `
    -KerberosEncryptionType AES128,AES256 `
    -ManagedPasswordIntervalInDays 30 `
    -Path "OU=Service Accounts,OU=Tier1,DC=corp,DC=example,DC=com"

ManagedPasswordIntervalInDays lässt sich nur beim Anlegen setzen. KerberosEncryptionType hält RC4 vom Konto fern, was wichtig ist, wenn Sie gerade RC4 deaktivieren. Verschieben Sie SPNs vom alten Konto mit Set-ADServiceAccount -ServicePrincipalNames @{Add=...} auf das gMSA, nachdem Sie sie vom alten Konto entfernt haben, denn doppelte SPNs legen Kerberos lahm.

Aktualisieren Sie auf jedem Host die Gruppenmitgliedschaft und testen Sie:

klist -li 0x3e7 purge
Test-ADServiceAccount -Identity "gmsa-sqlapp"

Install-ADServiceAccount ist für gMSA auf aktuellen Windows-Versionen optional; entscheidend ist, dass Test-ADServiceAccount True zurückgibt.

Das gMSA selbst schützen

Ein gMSA ist nur so stark wie die Liste der Prinzipale, die sein Kennwort lesen dürfen. Der DC gibt das aktuelle und das vorherige Kennwort im konstruierten Attribut msDS-ManagedPassword an jedes Prinzipal in msDS-GroupMSAMembership aus; diese Liste ist also faktisch die ACL eines Anmeldeinformationsspeichers. Drei Regeln halten sie sauber:

• Ordnen Sie das gMSA dem Tier seiner Hosts zu. Ein gMSA eines Tier-1-Anwendungsservers darf nicht von einem Tier-2-Rechner abrufbar sein, und ein gMSA mit Rechten auf DCs oder Backup-Infrastruktur ist Tier 0 – ebenso wie die Gruppen und OUs, die es kontrollieren.
• Kontrollieren Sie, wer die Abrufliste ändern darf. Wer Schreibzugriff auf msDS-GroupMSAMembership des gMSA oder auf die Mitgliedschaft der Abrufgruppe hat, kann einen eigenen Rechner hinzufügen und das Kennwort lesen. Prüfen Sie diese ACLs mit denselben Werkzeugen, die Sie für das Angriffspfadmanagement verwenden.
• Überwachen Sie den Abruf. Eine SACL auf den gMSA-Objekten für Lesezugriffe auf msDS-ManagedPassword erzeugt Ereignis 4662 auf den DCs. Legitime Lesezugriffe kommen von den Hosts der Abrufgruppe, etwa pro Kennwortintervall und beim Dienststart; Lesezugriffe von jedem anderen Konto verdienen einen Alarm.

Hinweise je Anwendung

Windows-Dienste und geplante Aufgaben

Dienste erhalten das Konto mit angehängtem $ und leerem Kennwort. Das Konto benötigt Log on as a service (Anmelden als Dienst), das sc.exe und die Dienstekonsole auf dem lokalen Host automatisch gewähren; wird das Zuweisen von Benutzerrechten per GPO verwaltet, nehmen Sie das gMSA in diese GPO auf, sonst entfernt die nächste Aktualisierung das Recht wieder.

sc.exe config "AppService" obj= "CORP\gmsa-sqlapp$" password= ""

$principal = New-ScheduledTaskPrincipal -UserId "CORP\gmsa-report$" -LogonType Password
Set-ScheduledTask -TaskName "NightlyReport" -Principal $principal

Geplante Aufgaben benötigen statt des Dienstrechts Log on as a batch job (Anmelden als Batchauftrag).

IIS-Anwendungspools

Setzen Sie im IIS-Manager die Pool-Identität auf CORP\gmsa-web$ mit leerem Kennwort. Für Kerberos-Authentifizierung an der Site registrieren Sie den HTTP-SPN auf dem gMSA und aktivieren die Kernelmodus-Authentifizierung mit useAppPoolCredentials, damit Tickets mit den Schlüsseln des gMSA entschlüsselt werden. Webfarmen funktionieren gut, weil jeder Knoten in der Abrufgruppe ist.

SQL Server

Ändern Sie die Konten für Engine und Agent über den SQL Server-Konfigurations-Manager, nicht über die Dienstekonsole, damit Dateisystem-, Registrierungs- und SPN-Berechtigungen aktualisiert werden. Prüfen Sie für Failovercluster-Instanzen und Verfügbarkeitsgruppen die Dokumentation Ihrer SQL-Server-Version: Die Unterstützung wurde über die Versionen ausgeweitet, und alle Replikate müssen in der Abrufgruppe sein. Verschieben Sie die MSSQLSvc/-SPNs auf das gMSA.

Was gMSA nicht gut abdeckt

Anwendungen, die das Dienstkennwort in ihrer eigenen Datenbank speichern, gesamtstrukturübergreifende Szenarien, in denen der nutzende Host in einer anderen Gesamtstruktur liegt, und die meisten Nicht-Windows-Plattformen. Diese bleiben in Kategorie 4.

dMSA unter Windows Server 2025

Delegierte verwaltete Dienstkonten (dMSA) erfordern mindestens einen Domänencontroller mit Windows Server 2025 und den KDS-Stammschlüssel. Die Migration verknüpft ein neues dMSA mit einem bestehenden normalen Konto; während der Migration wird die Kerberos-Authentifizierung für das alte Konto auf das dMSA umgeleitet, und nach Abschluss wird das Kennwort des ursprünglichen Kontos nicht mehr verwendet.

New-ADServiceAccount -Name "dmsa-legacyapp" -DNSHostName "dmsa-legacyapp.corp.example.com" `
    -CreateDelegatedServiceAccount -KerberosEncryptionType AES256 `
    -Path "OU=Service Accounts,OU=Tier1,DC=corp,DC=example,DC=com"

Start-ADServiceAccountMigration -Identity "dmsa-legacyapp" `
    -SupersededAccount "CN=svc_legacyapp,OU=Service Accounts,DC=corp,DC=example,DC=com"

# Nachdem der Host das dMSA übernommen hat und die Anwendung validiert ist
Complete-ADServiceAccountMigration -Identity "dmsa-legacyapp" `
    -SupersededAccount "CN=svc_legacyapp,OU=Service Accounts,DC=corp,DC=example,DC=com"

Für ein Rollback gibt es Undo-ADServiceAccountMigration und Reset-ADServiceAccountMigration. Parameternamen wurden seit der Veröffentlichung angepasst; prüfen Sie daher Get-Help auf Ihren DCs, bevor Sie Skripte schreiben. Die Verknüpfung wird in msDS-ManagedAccountPrecededByLink am dMSA und in msDS-SupersededManagedAccountLink am alten Konto gespeichert.

Sicherheitshinweis: 2025 veröffentlichten Forscher „BadSuccessor“ und zeigten, dass ein Prinzipal, das in irgendeiner OU ein dMSA anlegen kann, diese Verknüpfung auf ein privilegiertes Konto richten und dessen Berechtigungen erben konnte. Microsoft hat das mit einem Sicherheitsupdate behoben (CVE-2025-53779), die zugrunde liegende Lehre bleibt aber bestehen: Prüfen Sie, wer Create msDS-DelegatedManagedServiceAccount oder allgemeine Create-Child-Rechte auf OUs besitzt – genau wie bei jeder anderen gefährlichen ACL.

Überprüfen

Bestätigen Sie vor dem Deaktivieren eines alten Kontos, dass die neue Identität funktioniert und das alte Konto stumm ist.

# Zustand und Abrufbereich der gMSAs
Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword, msDS-SupportedEncryptionTypes, PasswordLastSet |
  Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes,
    @{n='Retrievers';e={$_.PrincipalsAllowedToRetrieveManagedPassword -join ';'}}

# Altes Konto: keine aktuelle Authentifizierung
Get-ADUser svc_legacyapp -Properties LastLogonTimestamp, ServicePrincipalName |
  Select-Object Name, @{n='LastLogon';e={[datetime]::FromFileTime($_.LastLogonTimestamp)}}, ServicePrincipalName

Markieren Sie jedes gMSA, zu dessen Abrufberechtigten Benutzerkonten, Domain Computers oder verschachtelte Gruppen gehören, die Ihnen nicht gehören. Beobachten Sie mindestens einen vollständigen Geschäftszyklus lang (Monatsabschlussjobs) 4769-Anforderungen für die alten SPNs und 4625-Fehler mit dem alten Konto; deaktivieren Sie es dann, lassen Sie es 30 Tage deaktiviert und löschen Sie es. Führen Sie das Inventar aus Abwehr von Kerberoasting erneut aus, um zu bestätigen, dass der SPN von den Benutzerobjekten verschwunden ist.

Was dabei kaputtgeht

• Dienste starten, bevor der Host ein frisches TGT hat. Ein neu hinzugefügter Host scheitert mit einem Anmeldefehler, bis er neu startet oder Sie seine Tickets löschen. Planen Sie diesen Schritt in den Change ein.
• Per GPO verwaltete Benutzerrechte entziehen dem gMSA bei der nächsten Aktualisierung das Recht zum Anmelden als Dienst oder Batchauftrag, wenn das gMSA nicht in der Richtlinie steht.
• Fest codierte Anmeldeinformationen in Verbindungszeichenfolgen, Skripten und Herstellerkonsolen funktionieren nicht mehr, weil es kein Kennwort zum Eintippen gibt. Finden Sie sie während des Audits, nicht nach der Umstellung.
• Doppelte SPNs während des Umzugs verursachen Kerberos-Fehler und einen stillen Rückfall auf NTLM. Erst entfernen, dann hinzufügen.
• Gesamtstrukturübergreifende Nutzer und Nicht-Windows-Clients können gMSA-Kennwörter nicht abrufen; sie bleiben bei normalen Konten.
• dMSA erfordert DCs mit Windows Server 2025 und Hosts mit Windows Server 2025, auf denen der Dienst läuft; ältere Hosts können es nicht nutzen.

Weiterführende Lektüre: Das Thema Kennwörter & Dienstkonten fasst dies mit der Bereitstellung von Windows LAPS zusammen, und der Glossareintrag zu gMSA fasst das Attributmodell zusammen.