Dienstkonten härten: gMSA, SPNs und LAPS

Normale Dienstkonten gehören zu den hartnäckigsten Schwachstellen in Active Directory: statische Kennwörter, die selten gewechselt werden, Anmeldeinformationen in Skripten und Konfigurationsdateien und Service Principal Names, die gewöhnliche Benutzerkonten zu Zielen für Offline-Kennwortknacken machen. Für den Großteil dieses Risikos gibt es in modernen Windows-Server-Versionen eine direkte, unterstützte Lösung – das Hindernis ist meist der Migrationsaufwand, nicht fehlende Werkzeuge. Dieser Leitfaden beschreibt den praktischen Weg von normalen zu verwalteten Dienstkonten sowie die Kennwortrichtlinien und Kontrollen für lokale Admins, die das Bild abrunden.

Warum normale Dienstkonten ein Risiko sind

Ein typisches Legacy-Dienstkonto ist ein normales Benutzerobjekt mit gesetztem Kennwort läuft nie ab, einem Kennwort, das einmal bei der Bereitstellung gewählt und selten geändert wurde, und häufig über mehrere Anwendungen hinweg wiederverwendet, weil ein Wechsel eine abgestimmte Ausfallzeit mit jedem Nutzer erfordert. Ist für dieses Konto zusätzlich ein Service Principal Name (SPN) registriert, wird es zum Ziel für Kerberoasting: Jeder authentifizierte Domänenbenutzer kann ein Kerberos-Dienstticket dafür anfordern und versuchen, den verschlüsselten Teil offline zu knacken – ohne Anmeldeversuch und ohne Auslösen einer Kontosperre.

Gruppenverwaltete Dienstkonten (gMSA) und in Windows Server 2025 delegierte verwaltete Dienstkonten (dMSA) lösen das Grundproblem: AD erzeugt und wechselt automatisch ein zufälliges Kennwort mit 240 Byte (120 Zeichen), kein Mensch kennt es, und es kann nirgends wiederverwendet werden, weil es nie von einer Person gewählt wurde.

Migration zu gMSA

Voraussetzungen

• gMSA benötigt das Schema von Windows Server 2012 (oder neuer) und mindestens einen DC mit Windows Server 2012 oder neuer; eine bestimmte Funktionsebene ist nicht erforderlich. dMSA erfordert Domänencontroller mit Windows Server 2025.
• Der KDS-Stammschlüssel (KDS root key) muss existieren, bevor das erste gMSA angelegt werden kann.

# Einmalige Einrichtung pro Gesamtstruktur – prüfen, ob bereits ein KDS-Stammschlüssel existiert
Get-KdsRootKey

# Falls keiner existiert, einen anlegen. In Produktion das 10-stündige
# Sicherheitsfenster für die Replikation abwarten, statt rückzudatieren:
Add-KdsRootKey -EffectiveImmediately
# Nur im Labor (ein einziger DC): Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Ein gMSA anlegen und bereitstellen

# Ein gMSA anlegen, beschränkt auf die Hosts, die es nutzen dürfen
New-ADServiceAccount -Name "svc-sqlapp" `
    -DNSHostName "svc-sqlapp.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "SQLAppServers" `
    -Enabled $true

# Auf jedem berechtigten Host das gMSA installieren
Install-ADServiceAccount -Identity "svc-sqlapp"

# Prüfen, ob der Host das verwaltete Kennwort abrufen kann
Test-ADServiceAccount -Identity "svc-sqlapp"

Konfigurieren Sie den nutzenden Dienst (z. B. einen Windows-Dienst, einen IIS-Anwendungspool oder eine geplante Aufgabe) so, dass er als CORP\svc-sqlapp$ ohne Kennwort läuft – das Betriebssystem ruft das Kennwort transparent ab und wechselt es.

# Einen bestehenden Windows-Dienst auf das gMSA umstellen
sc.exe config "MyAppService" obj= "CORP\svc-sqlapp$"

dMSA für schwer migrierbare Konten (Server 2025)

dMSA ist speziell für Konten gedacht, die sich nicht sauber auf eine neue Identität umstellen lassen – Windows kann ein dMSA mit dem ursprünglichen normalen Dienstkonto verknüpfen und die Kerberos-Authentifizierung transparent umleiten. Das erleichtert die Migration von Diensten, die einen Kontonamen fest codiert haben.

# Ein dMSA anlegen, das für die Migration mit einem bestehenden normalen Dienstkonto verknüpft wird
New-ADServiceAccount -Name "svc-sqlapp-dmsa" -DNSHostName "svc-sqlapp-dmsa.corp.example.com" `
    -CreateDelegatedServiceAccount -KerberosEncryptionType AES256

# Mit dem Legacy-Konto verknüpfen und die Migration starten
Start-ADServiceAccountMigration -Identity "svc-sqlapp-dmsa" `
    -SupersededAccount "CN=svc-sqlapp,OU=Service Accounts,DC=corp,DC=example,DC=com"

Der vollständige Migrationsablauf (starten, die Hosts das dMSA übernehmen lassen, dann abschließen) wird in Dienstkonten zu gMSA und dMSA migrieren behandelt. Testen Sie ihn im Labor, bevor Sie produktive Dienstkonten anfassen.

SPN-Hygiene

Prüfen Sie jeden SPN, der auf einem Benutzerobjekt (nicht auf einem Computer- oder gMSA-Objekt) registriert ist – das ist die Menge der für Kerberoasting anfälligen Konten:

Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName |
    Select-Object SamAccountName, ServicePrincipalName

Für jedes Ergebnis:

1. Ermitteln Sie den Dienst und das verantwortliche Team.
2. Migrieren Sie den Dienst auf ein gMSA/dMSA, sofern die Anwendung gruppenverwaltete Dienstkonten unterstützt (die meisten modernen Szenarien mit SQL Server, IIS und Windows-Diensten tun das).
3. Wo eine Migration noch nicht möglich ist, erzwingen Sie über eine dedizierte fein abgestufte Kennwortrichtlinie (siehe unten) ein langes (25+ Zeichen), zufälliges Kennwort und wechseln Sie es.
4. Entfernen Sie den SPN vollständig von jedem Konto, dessen zugehöriger Dienst nicht mehr existiert – veraltete SPNs sind nach der Stilllegung von Anwendungen häufig.

# Einen veralteten SPN entfernen
Set-ADUser -Identity "svc_oldapp" -ServicePrincipalNames @{Remove="MSSQLSvc/oldapp.corp.example.com:1433"}

Fein abgestufte Kennwortrichtlinien (PSOs)

Die einzige Standard-Kennwortrichtlinie der Domäne ist für privilegierte und Dienstkonten meist zu schwach, aber zu streng, um sie jedem Benutzer aufzuerlegen. Mit fein abgestuften Kennwortrichtlinien können Sie strengere Anforderungen auf bestimmte Gruppen legen, ohne den Domänenstandard zu ändern.

New-ADFineGrainedPasswordPolicy -Name "PSO-ServiceAccounts" `
    -Precedence 10 `
    -MinPasswordLength 32 `
    -PasswordHistoryCount 24 `
    -MaxPasswordAge "180.00:00:00" `
    -MinPasswordAge "1.00:00:00" `
    -ComplexityEnabled $true `
    -ReversibleEncryptionEnabled $false

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-ServiceAccounts" -Subjects "SVC-Accounts-NonMigrated"

New-ADFineGrainedPasswordPolicy -Name "PSO-Tier0Admins" `
    -Precedence 5 `
    -MinPasswordLength 20 `
    -MaxPasswordAge "60.00:00:00" `
    -ComplexityEnabled $true

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Tier0Admins" -Subjects "Tier 0 Admins"

Niedrigere Precedence-Werte gewinnen, wenn für ein Konto mehrere PSOs gelten. Prüfen Sie die wirksame Richtlinie pro Konto:

Get-ADUserResultantPasswordPolicy -Identity "svc_oldapp"

Ziehen Sie außerdem einen Ansatz mit verbotenen Kennwörtern in Betracht – entweder eine Kennwortfilter-DLL eines Drittanbieters oder den lokalen Agenten von Entra Password Protection –, damit sowohl Kennwörter von Menschen als auch noch verbliebene, von Menschen gesetzte Dienstkontokennwörter beim Setzen gegen eine Liste kompromittierter bzw. gängiger Kennwörter geprüft werden, nicht nur gegen einen Komplexitäts-Regex.

Windows LAPS für lokale Admin-Kennwörter

Lokale Administratorkennwörter, die sich eine ganze Rechnerflotte teilt, vervielfachen Lateral Movement – ein einziges geleaktes lokales Admin-Kennwort kann jeden Rechner öffnen, der es teilt. Windows LAPS (in Windows Server 2019+ und Windows 10/11 mit dem entsprechenden Update integriert, ersetzt die Legacy-LAPS-CSE) randomisiert und wechselt das lokale Administratorkennwort pro Rechner und speichert es verschlüsselt in AD.

# Schema erweitern (einmalig, auf einem Schemamaster ausführen)
Update-LapsADSchema

# Per GPO konfigurieren: Computer Configuration → Policies → Administrative Templates → System → LAPS
# „Configure password backup directory“ auf Active Directory setzen (ohne diese Einstellung passiert nichts),
# dann „Password Settings“ und bei Bedarf auf DCs „Enable password backup for DSRM accounts“

# OU-Berechtigungen setzen, damit nur berechtigte Admins das verschlüsselte Kennwort lesen können
Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=corp,DC=example,DC=com" -AllowedPrincipals "Tier2-Helpdesk-Admins"

# Prüfen, ob ein Rechner sein LAPS-Kennwort meldet
Get-LapsADPassword -Identity "WKS-01" -AsPlainText

Hinweis: Der Umgang mit DSRM- und lokalen DC-Admin-Anmeldeinformationen ist ein eigenes Thema. Windows LAPS kann das DSRM-Kennwort auf Domänencontrollern verwalten, wie unter Windows LAPS bereitstellen beschrieben; halten Sie sich außerdem an die DC-spezifischen Empfehlungen, statt die Annahmen zum LAPS-Geltungsbereich für Arbeitsstationen auf Domänencontroller zu übertragen.

Checkliste zur Überprüfung

# Bestätigen, dass außerhalb einer genehmigten Ausnahmeliste keine Benutzerkonten SPNs besitzen
Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName

# Bestätigen, dass die vorgesehenen Hosts die gMSA-Konten abrufen können
Test-ADServiceAccount -Identity "svc-sqlapp"

# Bestätigen, dass die PSO auf die vorgesehene Gruppe angewendet wird
Get-ADFineGrainedPasswordPolicySubject -Identity "PSO-ServiceAccounts"

# Bestätigen, dass LAPS auf einer Stichprobe von Rechnern aktiv rotiert
Get-LapsADPassword -Identity "WKS-01" | Select-Object PasswordUpdateTime, ExpirationTimestamp

Was dabei kaputtgeht

• Anwendungen ohne gMSA-Unterstützung. Manche Legacy- oder Drittanbietersoftware besteht auf einem Konto im interaktiven Stil mit setzbarem Kennwort und kann keine Identität nach Art eines Computerkontos nutzen. Diese Anwendungen bleiben bei normalen Konten, abgeschottet hinter der strengsten PSO, die Sie anwenden können, bis der Hersteller Unterstützung nachliefert.
• Gesamtstruktur- oder domänenübergreifende Dienstnutzung kann die gMSA-Bereitstellung erschweren, da der Abruf von der Replikation des KDS-Stammschlüssels und der Auflösung der Gruppenmitgliedschaft innerhalb des Geltungsbereichs abhängt.
• Fest codierte Anmeldeinformationen in Skripten oder Konfigurationsdateien, die auf das Kennwort des alten Kontos verweisen, funktionieren nach der Umstellung auf ein gMSA ohne statisches Kennwort schlicht nicht mehr – suchen Sie danach vor der Umstellung, nicht danach.
• Helpdesk-Abläufe, die auf gemeinsamen lokalen Admin-Kennwörtern beruhen, müssen sich ändern, sobald Windows LAPS eindeutige Kennwörter pro Rechner erzwingt; dokumentieren Sie den neuen Abrufprozess (Get-LapsADPassword) für das Supportpersonal.

Dieser Leitfaden behandelt bewusst nicht die Rotation des krbtgt-Kennworts – sie hat ihren eigenen Rhythmus und eigene Überlegungen zum Wirkungsradius und wird in einem eigenen Leitfaden behandelt. Siehe auch Kerberos-Härtung für die übergreifende Kerberos-Konfiguration, in deren Kontext diese Maßnahmen stehen.