Update vom 22.05.2025:
Aufgrund des gestern, Mittwoch, 21.05.2025, von Yuval Gordon beschriebenen Angriffsvektors „BadSuccessor“ ist von der Verwendung von dMSA derzeit abzuraten, sofern nicht sichergestellt ist, dass nur höchst privilegierte User und Systeme (Tier0-User und -Systeme) schreibrechte auf die dMSAs haben! Dieses kann verifiziert werden, in dem man ein von Yuval Gordon bereit gestelltes PowerShell-Skript verwendet.
Einen sehr ausführlichen Artikel hierzu kann man bei Günter Born / borncity.com einsehen.
Update vom 28.08.2025
Der Patchday vom 12.08.2025 hat Microsoft durch den KB 5063878 das Problem mit dem „badSuccessor“ adressiert.
Active Directory 2025: delegated managed service accounts (dMSA)
Delegated managed service account (dMSA) schließen final die Lücke zwischen einem Dienstkonto mit statischen, nicht ablaufenden Kennwort und dem group managed service account (gMSA), welches ein rotierendes, langes und komplexes Kennwort aufweist.
Beide Dienstkontenarten (statisches Dienstkonto und gMSA) können auf mehreren Servern gleichzeitig für die gleichen und / oder unterschiedliche Dienste verwendet werden.
Die Besonderheit beim dMSA ist jedoch folgendes:
During migration, dMSA automatically learns the devices on which the service account to be used which is then used to move from all existing service accounts.
dMSA uses a randomized secret (derived from the machine account credential) that is held by the Domain Controller (DC) to encrypt tickets. The secret can be further protected by enabling CG. While the secrets used by dMSA are updated periodically on an epoch like a gMSA, the key difference is that dMSA’s secret can’t be retrieved or found anywhere other than on the DC.
Timeline Dienstkonten
- statische Dienstkonten: seit anbeginn der Zeit, zumindest aber seit Windows NT4.0: das war am 31.07.1996
- Managed service account (MSA): seit dem 22.10.2009 mit Server 2008 R2
- Virtual accounts: seit dem 22.10.2009 mit Server 2008 R2
- Group managed service accounts (gMSA): seit dem 04.09.2012 mit Server 2012
- delegated managed service accounts (dMSA): seit dem 02.11.2024 mit Server 2025
Identitäten von Diensten
Ein Dienst bei einem Windows-Rechner kann mehrere Identäten aufweisen.
- Local System: die höchsten lokalen Berechtigungen und Privilegien, arbeitet im Netzwerk authentifiziert mit dem Computerkonto, auf dem der Service läuft
- Network Service: minimale lokale Berechtigungen und Privilegien, arbeitet im Netzwerk authentifiziert mit dem Computerkonto, auf dem der Service läuft
- Local Service: minimale lokale Berechtigungen und Privilegien, arbeitet im Netzwerk anonym bzw. nicht authentifiziert
- Virtual Account: minimale lokale Berechtigungen und Privilegien, arbeitet im Netzwerk authentifiziert mit dem Computerkonto, auf dem der Service läuft, Kennwort wird lokal verwaltet
- Service account: Berechtigungen gem. der Einrichtung für das Dienstkonto, arbeitet im Netzwerk mit seiner eigenen Identität.
Virtual Account
Local Service
Network Service
Local System
Managed Service Account
- Verfügbar mit Server 2008 R2
- für manche, wenige Services geeignet
- kann nur jeweils von einem Server verwendet werden
Eine schnelle Übersicht findet sich hier: *klick*
Group Managed Service Account
- verfügbar mit Server 2012
- für die meisten Services geeignet
- kann auf mehreren Servern eingesetzt werden
Eine schnelle Übersicht findet sich hier: *klick*
Delegated Managed Service Account
- verfügbar mit Server 2025
- geeignet für alle Services, die kein MSA oder gMSA verwenden können
- kann auf mehreren Servern eingesetzt werden
Eine schnelle Übersicht findet sich hier: *klick*
So typisch für einen Dienst…
Den Diensten wohnt in Summe ein Privileg inne: „Impersonate a client after authentication„.
Impersonation is the ability of a thread to run in a security context that is different from the context of the process that owns the thread. Impersonation is designed to meet the security requirements of client/server applications. When running in a client’s security context, a service „is“ the client, to some degree. One of the service’s threads uses an access token representing the client’s credentials to obtain access to the objects to which the client has access. The primary reason for impersonation is to cause access checks to be performed against the client’s identity. Using the client’s identity for access checks can cause access to be either restricted or expanded, depending on what the client has permission to do.
Ganz nebenbei, die SID mit S-1-99 sind die restricted services auf diesem Rechner.
„Restriced Services“ haben Einschränkungen bei Berechtigungen in den Bereichen Systemdateien, Registry und Dienstkonfigurationen.
Diese Zuordnung von Diensten wurde mit Windows Vista und Server 2008 (04.02.2008) verfügbar gemacht.
Shitty static service accounts
Statische Dienstkonten, also Benutzerobjekte, welche für Services verwendet werden, müssen im Active Directory aktiviert sein, damit der Dienst sich gegenüber dem AD beim Starten erfolgreich authentifzieren kann. Das aktuelle Kennwort des Dienstkontos wird dann beim jeweiligen Dienst zusammen mit dem Anmeldenamen hinterlegt.
Im Rahmen der Dienstkontengenerierung werden, fast immer, grundsätzlich, zwei Haken gesetzt:
- Kennwort läuft nicht ab (ok, kann ich nachvollziehen) und
- Kennwort kann nicht geändert werden (kann ich nicht nachvollziehen)
Unabhängig vom Grad der Privilegierung eines Dienstkontos sollte dessen Kennwort
- sehr lang sein (größer 30 Zeichen) und
- komplex sein (Großbuchstaben, Kleinbuchstaben, Zahlen und Sonderzeichen)
Die Kennwortänderung kann ich der Tat ein Problem sein, jedoch muss man das Problem ja nicht noch verstärken, in dem man die Kennwortänderung unterbindet.
Wünsch‘ Dir was!
Was ich mir also wünsche, sind folgende Punkte:
- Dienstkonten sind grundsätzlich gMSAs.
- Kennwörter von gMSAs sind immer 120 Zeichen lang.
- Kennwörter von gMSAs sind immer komplex.
- Kennwörter von gMSAs werden durch den PDC-Emulator gem. Konfiguration roliert.
- gMSAs können auf mehreren Server, sogar für unterschiedliche Dienste, gemeinsam verwendet werden.
- Dienstkonten, die keine gMSAs sein können, sind dMSAs.
- Kennwörter von dMSAs sind immer 120 Zeichen lang.
- Kennwörter von dMSAs sind immer komplex.
- Kennwörter von dMSAs werden durch den PDC-Emulator gem. Konfiguration roliert.
- dMSAs können auf mehreren Server, sogar für unterschiedliche Dienste, gemeinsam verwendet werden.
Häh? Die Wünsche sind doch vom Ergebnis identisch?
Jaja, die Ergebnisse sind gleich, der Knackpunkt ist „Dienstkonten, die keine gMSAs sein können, sind dMSAs“. Nicht jeder Dienst kann ein gMSA nutzen, was schade ist. Um ein zwei Beispiele aufzuzeigen, ohne das jetzt in einem negativen Kontext zu sehen:
Dein Wunsch sei gewährt!
Sofern der Server ein Server 2025 ist kann jedes bisherige (shitty) static serivce account (vulgo Dienstkonto (Kennwort läuft nicht ab + Kennwort kann nicht geändert werden)) in dein dMSA überführt werden.
Überführung eines (shitty) static service account zu einem dMSA
Um einen dMSA zu erzeugen benötigt man in der Ausgangssituation mehrere Server mit Server 2025 mit einem (shitty) static service account.
Bei der Überführung zu einem dMSA gibt es drei Zustände / Phasen:
- Unlinked (ein dMSA wurde erzeugt, hat aber keinen Bezug zum (shitty) static service account)
- Linked (dMSA und (shitty) static service account pflegen eine attributbezogene Beziehung)
- Delegated (das dMSA übernimmt die Authentifizierung am Dienst)
Das Setup
Drei Server unter Server 2025 betreiben eine Webseite mit dem IIS und integrierter Windows Authentifizierung. Die Webseite läuft in einem AppPool unter der Useridentität „CH\WSJH01“.
Wichtig: die Voraussetzung per GPO schaffen
Wenn das dMSA auf mehreren Servern eingesetzt wird, wie hier auf drei verschiedenen Servern, muss per GPO die Policy „Enable Delegated Managed Service Account logons“ aktiviert werden.
Diese findet sich unter „Computer Configuration“ ⇒ „Policies“ ⇒ „Administrative Templates“ ⇒ „System“ ⇒ „Kerberos“
1. Unlinked
Unlinked bedeutet, es existiert paralell zu (shitty) static service account ein dMSA. Dieses dMSA wird wie ein gMSA angelegt. Das wiederum bedeutet man benötigt einen KdsRootKey. Ist der KdsRootKey nicht vorhanden, ein Get-KdsRootKey liefert nichts zurück, bitte mit Add-KdsRootKey und der Windows PowerShell anlegen.
Mit einem weiteren PowerShell-Befehl wird das dMSA-Objekt erzeugt.
New-ADServiceAccount -Name dWSJH01 -DNSHostName dWSJH01.cloud-hybrid.de -CreateDelegatedServiceAccount -KerberosEncryptionType AES256 Es können noch mehr Parameter beim Anlegen angegeben werden, so zum Beispiel:
-ManagedPasswordIntervalInDaysum festzulegen, wie oft das Kennwort iteriert wird.
2. Linked
Die zweite Phase, linked, bedeutet man konnotiert das dMSA mit dem eigentlichen (shitty) static service account. Über drei Attribute wird am (shitty) static service account gekennzeichnet, dass hier eine Verinbundung zu dMSA besteht:
- msDS-ManagedAccountPrecededByLinkBL; verweist auf das dMSA
- msDS-SupersededManagedAccountLink; verweist auf das dMSA
- msDS-SupersededServiceAccountState; gibt mit „1“ den Modus „linked“ an
Der Status „linked“ wird wieder mit der Windows PowerShell herbeigeführt.
Start-ADServiceAccountMigration –Identity dWSJH01 –SupersededAccount "CN=WebService Jumphosts,OU=Users,OU=JumpHosts,OU=Tier1,OU=ESAE,DC=CLOUD-HYBRID,DC=DE"
3. Delegated
Mit Delegated, der dritten Phase, übernimmt nun das dMSA die Authentifizierung als Service.
Complete-ADServiceAccountMigration –Identity dWSJH01 –SupersededAccount "CN=WebService Jumphosts,OU=Users,OU=JumpHosts,OU=Tier1,OU=ESAE,DC=CLOUD-HYBRID,DC=DE"Hierzu werden die SPNs vom (shitty) static service account zum dMSA übertragen.
Und am Schluss?
Am Schluss ist der Prozess in meinen Augen realtiv überschaubar:
- KdsRootKey muss vorhanden sein,
- Der Dienst mit dem (shitty) static service account muss auf einem Server 2025 laufen,
- es muss sichergestellt sein, dass nur hoch privilegierte Konten Schreibrechte auf das dMSA haben,
- eine neue Einstellung per GPO verteilen,
- drei PowerShell-Befehle ausführen und
- es wird am Dienst auf den Servern nichts verändert!
So, jetzt mache ich erst mal nichts, dann habe ich das schon weg.
ComputerLogbuch der IQunit, Sternzeit -297672.4105783867, Captian Handl
Der Vertrieb geht mir auf die Nüsse, im dem er die „call to action“ in meine Artikeln vermisst.
Kenne ich nicht. Ich kenne „call of duty“ oder „ports of call„.
Ich soll Werbung für den Kurs machen, in dem man die obige Angelgenheit vermittelt bekommt.
Bitteschön: Essential Active Directory 2025 – Kapitel PowerShell
