gMSA and dMSA Guide: Group and Delegated Managed Service Accounts

Static Active Directory service accounts with human-set passwords are one of the most reliable routes to domain compromise, and managed service accounts only fix that if the accounts around them are governed too. Group managed service accounts (gMSAs) replace those passwords with long, random, automatically rotated secrets, and delegated managed service accounts (dMSAs) in Windows Server 2025 go further by binding the secret to specific machines. Both introduce their own attack surface: who may retrieve the password, the KDS root key every password is derived from, and the dMSA migration attributes abused by BadSuccessor. This guide goes deeper than the Service Account Security Guide on Windows managed service accounts: how they work, how to migrate to them, and how to protect and monitor them. It is for directory engineers, Windows server teams and identity security teams responsible for non-human identities.

Key takeaways

• A gMSA removes the human-chosen password. Domain controllers generate a 240-byte random password and rotate it every 30 days by default, which defeats Kerberoasting and password reuse.
• The retrieval list is the new password. Every principal in PrincipalsAllowedToRetrieveManagedPassword can read the cleartext password, so that list must be as tightly controlled as the account's privileges.
• The KDS root key is a forest-wide secret that cannot be rotated. Whoever reads it can compute gMSA and dMSA passwords offline (Golden gMSA and Golden dMSA), and recovery means a new root key and new accounts.
• dMSA is machine-bound, but migration is powerful. It supersedes a legacy account and inherits its access, which is exactly what BadSuccessor abused through create rights on an organisational unit.
• Migration needs a plan, not a script. Inventory dependencies, test each application, keep a rollback path and audit the new accounts' group memberships and retrieval rights.

Managed service account types compared

Windows has three kinds of managed service account plus the traditional user account used as a service account. The standalone managed service account (sMSA) arrived with Windows Server 2008 R2; the group managed service account needs Windows Server 2012 or later; the delegated managed service account needs at least one Windows Server 2025 domain controller.

Microsoft's order of preference for on-premises services is a gMSA, then an sMSA if the service runs on one server and cannot use a gMSA, then a standard user account with strong password management as a last resort. Failover clusters themselves do not support gMSAs, although Windows services, IIS application pools and scheduled tasks running on cluster nodes can use them.

How gMSA passwords work

• Derivation: the Microsoft Key Distribution Service (kdssvc.dll) on each domain controller derives the gMSA password from the forest's KDS root key, the account's SID and a time-based password identifier (msDS-ManagedPasswordId). No DC stores the password; any DC can compute it.
• gMSA password retrieval: an authorised host asks a DC for the constructed attribute msDS-ManagedPassword. The returned structure (MSDS-MANAGEDPASSWORD_BLOB) contains the current password in cleartext, the previous password if there is one, and intervals telling the host when to query again. Services sharing one gMSA therefore never need password synchronisation.
• Who may retrieve: the principals named in PrincipalsAllowedToRetrieveManagedPassword, stored as a security descriptor in msDS-GroupMSAMembership. Microsoft recommends a security group of host computer accounts.
• Rotation: ManagedPasswordIntervalInDays defaults to 30 and can only be set when the account is created; changing it means creating a new gMSA.
• Encryption: gMSAs rely on the Kerberos encryption types in msDS-SupportedEncryptionTypes. Microsoft recommends always configuring AES, which matters more now that domain controllers default to AES only for accounts without the attribute set.
• Naming: gMSA names must be unique across the forest, not just the domain.

The joint ASD, CISA, NSA and Five Eyes guidance on Active Directory compromises recommends creating service accounts with SPNs as gMSAs specifically because the 120-character, automatically rotated password defeats Kerberoasting and silver tickets.

Password retrieval rights: the real attack surface

A gMSA does not remove the secret; it moves control of it into Active Directory. Anyone who controls a principal in the retrieval list can read the password and act as the gMSA anywhere it has rights. Typical exposure paths are a retrieval group that contains users or broad groups, administrators added "temporarily" for troubleshooting, write access to msDS-GroupMSAMembership held by a non-tier zero group, and local admin on a host in the retrieval group (the host's own identity can read the password).

• Keep the list to host accounts: a dedicated group per gMSA containing only the computer accounts that run the service. No human users, no nested groups.
• Tier the hosts: a gMSA that is privileged in tier zero must only be retrievable by tier zero hosts, otherwise a member server compromise becomes domain compromise.
• Protect the attribute: review who can write msDS-GroupMSAMembership and the membership of retrieval groups; alert on changes through 5136 and group change events 4728, 4732 and 4756.
• Audit reads: add a SACL for reads of msDS-ManagedPassword on sensitive gMSAs and enable "Audit Directory Service Access", so event 4662 shows which principal read it. Reads from anything other than the expected hosts are high-fidelity alerts.
• Least privilege for the account itself: Microsoft's own risk table lists gMSAs in privileged groups and gMSAs with read or write access to sensitive resources as the two issues to review first.
• Deny interactive use: grant "Log on as a service" or "Log on as a batch job" only where needed, and deny interactive and Remote Desktop logon rights through Group Policy.

Protecting the KDS root key

The KDS root key (Key Distribution Service root key) is created once per forest and stored under CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration. Creating it requires Domain Admins or Enterprise Admins rights, and domain controllers wait up to 10 hours before using a new key so that it replicates everywhere. Microsoft documents a shortcut that backdates the key, but only for single-DC test labs: in production it causes password retrieval failures on DCs that have not received the key. Creation is confirmed by event 4004 in the KdsSvc Operational log.

Golden gMSA attack and offline gMSA password generation

The golden gMSA attack follows directly from the derivation. An attacker who can read the root key's attributes (by default, root domain Domain Admins, Enterprise Admins and SYSTEM on domain controllers) can copy them and later compute the password of any gMSA in the forest offline, using values such as the account's SID and msDS-ManagedPasswordId that ordinary users can read. No further access to a DC is needed, the 30-day rotation does not help because the root key does not change, and researchers report no supported way to rotate the root key secret.

• Prevent: treat the root key as tier zero material alongside the KRBTGT key. Limit who has Domain Admin, Enterprise Admin or SYSTEM-level access on DCs, and protect DC backups.
• Detect: native auditing logs nothing by default. Add a SACL on the root key objects (class msKds-ProvRootKey) for reads of msKds-RootKeyData, so event 4662 records any read by an account that is not a domain controller. Alert on ACL changes to those objects too.
• Respond: after a suspected root key compromise, create a new KDS root key, create new gMSAs and dMSAs derived from it, move services across and delete the old accounts. Microsoft notes that re-created root keys can be cached, so restart the KDC service on all DCs.

Microsoft's position, quoted by the researchers who published Golden dMSA, is that these features "have never been intended to protect against a compromise of a domain controller". The KDS root key is therefore a recovery consideration in any domain compromise; see the Identity Recovery Guide.

Delegated managed service accounts (dMSA)

A delegated managed service account is a Windows Server 2025 account type built to replace legacy service accounts without changing every application. Its secret is held by the DC and derived from the machine account credential, only the machines mapped to it in Active Directory can use it, and Credential Guard can bind its tickets to those machines. Microsoft describes gMSA passwords by contrast as "still not machine bound and can be stolen".

dMSA migration

A dMSA migration supersedes an existing user-based service account. When the administrator starts migration, the dMSA's msDS-ManagedAccountPrecededByLink points to the old account, msDS-DelegatedMSAState becomes 1 and the old account is linked forward to the dMSA. The service keeps running while it learns the new identity. On completion the state becomes 2, SPNs, delegation settings and authentication policy membership move to the dMSA, the original account is disabled, and logons that try its password are redirected to the dMSA, which has all the access the old account had.

• Timing: Microsoft says to wait at least two ticket lifetimes after the security descriptor changes before completing, and recommends staying in the start state for about 28 days; delay if replication is unhealthy.
• Prerequisites: a discoverable Windows Server 2025 DC (schema extension alone is not enough), a writable DC for the migration, and every machine using the account running a dMSA-capable OS, or it fails once the original is disabled.
• Limits: one dMSA per service account; no migration from an sMSA or gMSA; no forced password reset; unconstrained delegation stops working after migration.
• Rollback: Microsoft provides undo and reset migration cmdlets. Keep the disabled original account, because the links between the two objects depend on it.
• Mixed estates: the Group Policy setting "Enable Delegated Managed Service Account logons" (Computer Configuration, Administrative Templates, System, Kerberos) defines realms so older child domains can authenticate to dMSAs.

BadSuccessor and Golden dMSA

BadSuccessor showed that the migration link is effectively a privilege grant. Researchers found in 2025 that a user who could create objects in any organisational unit (the "Create all child objects" right or the right to create msDS-DelegatedManagedServiceAccount objects) could create a dMSA, point msDS-ManagedAccountPrecededByLink at any account, including a Domain Admin, mark the migration complete, and then authenticate with that account's privileges. Microsoft fixed CVE-2025-53779, described as a relative path traversal flaw in Windows Kerberos that could give domain administrator privileges, in the August 2025 updates. The researchers' follow-up said the patch mitigates a significant part of the risk but that the technique "remains relevant in certain scenarios", so the permissions themselves still need fixing.

• Patch every DC with updates from August 2025 or later, especially once any Windows Server 2025 DC exists.
• Audit OU create rights: find every principal outside tier zero holding create-child rights on OUs and remove or narrow them. Such rights are commonly delegated to help desks and provisioning tools.
• Treat migration links as privileged: legitimate migrations are rare, run by administrators and pass through state 1 before 2. Anything else is suspicious.

Golden dMSA extends the Golden gMSA idea to dMSAs: with the KDS root key, the time component of the password identifier leaves only 1,024 possible combinations, so passwords for dMSAs, gMSAs and their associated accounts can be computed offline across domains. The defence is the same as for Golden gMSA: protect and audit the root key, and watch for bursts of Kerberos pre-authentication failures against $ service accounts and dMSA tickets requested by user accounts.

gMSA migration from static service accounts

Managed service account migration works best service by service: choose the target for each, then migrate in waves, starting with Kerberoastable accounts that hold privileged access.

1. Inventory: list user accounts with SPNs, accounts in the "Log on as a service" right, scheduled task identities and IIS pool identities; record owner, hosts and privileges. See the NHI Ownership Guide.
2. Prepare the forest: confirm a KDS root key exists (event 4004) or create one and wait the full 10 hours; set the root key SACL; check domain and forest functional level is Windows Server 2012 or later.
3. Create per service: one gMSA per service, AES set in msDS-SupportedEncryptionTypes, a dedicated retrieval group of host accounts, and only the rights the service needs (never inherit Domain Admin because the old account had it).
4. Test in a pilot: install the account on a test host, change the service identity with a blank password, and validate access to every resource, including SQL logins, file shares and SPN-based Kerberos clients.
5. Cut over in waves: production hosts one group at a time, keeping the old account enabled but unused for a defined period. Rollback is pointing the service back at the old account.
6. Retire the old account: disable, watch for failed logons for two to four weeks, then delete it and remove its SPNs.

The Cisco Active Directory credentials leak shows why the retirement step matters: hashes for service and machine accounts from a 2022 intrusion were republished in 2025, and our analysis recommends moving to managed service accounts and confirming every exposed credential was actually changed.

Detection and monitoring

Metrics:

• Share of SPN-bearing service accounts that are gMSAs, sMSAs or dMSAs, tracked monthly.
• Number of gMSAs whose retrieval list contains users or nested groups (target: zero).
• Number of managed service accounts in privileged groups (target: zero outside documented tier zero services).
• Non-tier zero principals with create-child rights on OUs (target: zero after review).
• Root key and msDS-ManagedPassword read alerts triaged within the agreed time.

Decision guidance

• gMSA or dMSA: use a gMSA for new services today; it works from Windows Server 2012 onwards and on server farms. Use dMSA migration where a legacy account cannot easily be replaced in every configuration and all hosts can run Windows Server 2025 capable systems.
• Small organisations: a handful of gMSAs with clean retrieval groups, AES and the root key SACL delivers most of the value. Large estates need an inventory with owners, per-tier retrieval groups and automated checks for drift in retrieval lists and OU permissions.
• Hybrid and cloud: where a workload moves to Azure, Microsoft recommends managed identities or service principals instead of carrying an on-premises account across; see the Cloud Workload Identity Guide.

Framework mapping

Common failure patterns

• Retrieval granted to "Domain Computers" or an admin group: every member can read the cleartext password.
• Copying the old account's privileges: a gMSA in Domain Admins is still a Domain Admin credential, just a longer one.
• Old accounts left enabled after migration: the static password remains crackable and usable.
• Delegated OU create rights never reviewed: the BadSuccessor precondition, frequently held by help desk or provisioning groups.
• KDS root key ignored in compromise recovery: KRBTGT is reset twice but every gMSA password remains computable by the attacker.
• Backdating the root key in production: intermittent retrieval failures that push teams back to user accounts.

Practitioner checklist

• Inventory user accounts used as services and rank them by privilege and Kerberoastability.
• Confirm the KDS root key exists, was created with the normal replication wait, and has a SACL auditing reads of msKds-RootKeyData.
• Create one gMSA per service with AES set and a dedicated retrieval group of host computer accounts only.
• Remove managed service accounts from privileged groups and grant only the rights each service needs.
• Deny interactive and Remote Desktop logon to all managed service accounts.
• Audit reads of msDS-ManagedPassword on tier zero gMSAs and alert on unexpected readers.
• Patch DCs for CVE-2025-53779 and remove create-child rights on OUs from non-tier zero principals.
• Alert on 5136 changes to dMSA migration attributes and retrieval group membership.
• Disable and then delete legacy accounts after migration, removing their SPNs.
• Add "new KDS root key and new managed accounts" to the domain compromise recovery plan.

Standards and references

• Microsoft Learn: Group Managed Service Accounts overview
• Microsoft Learn: Manage group Managed Service Accounts
• Microsoft Learn: Create the Key Distribution Services KDS root key
• Microsoft Learn: Delegated Managed Service Accounts overview
• Microsoft Learn: Secure group managed service accounts
• Microsoft Open Specifications: MS-ADTS MSDS-MANAGEDPASSWORD_BLOB
• ASD, CISA, NSA et al.: Detecting and Mitigating Active Directory Compromises
• Help Net Security: Microsoft fixes BadSuccessor Kerberos vulnerability (CVE-2025-53779)

Related NHI Mgmt Group resources: Service Account Security Guide · Active Directory and Entra ID Hardening Guide · Privileged Access Management Guide · NHI Ownership Guide · Identity Recovery Guide