About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Services need accounts to run under, and those accounts need passwords. For years, that meant a service account whose password was set once, written down somewhere, and rarely changed, because changing it meant updating every server that used it.
Group managed service accounts were designed to end that. Microsoft's Group Managed Service Accounts overview explains that such an account minimizes the administrative overhead of a service account by allowing Windows to handle password management for these accounts.
That is a real security improvement. It also changes what backup and recovery must think about. This article explains, from Microsoft's documentation, where these passwords come from, why that makes domain controller backups especially sensitive, and what Microsoft advises after a serious incident.
Where the passwords come from
Nobody types a password for a group managed service account. The overview explains how it is produced: For a gMSA, the domain controller computes the password on the key that the Key Distribution Services provides, along with other attributes of the gMSA. Servers allowed to use the account ask a domain controller for it: Member hosts can obtain the current and preceding password values by contacting a domain controller.
The key at the base of this is called the root key. Microsoft's guide to Create a Key Distribution Service (KDS) root key states that Domain controllers (DC) require a root key to begin generating gMSA passwords. The guide explains that the root key is stored in Active Directory itself, in the part of the directory shared across the whole forest.
Domain controllers derive the password from KDS key material and account attributes. Those directory objects must replicate, and authorised hosts can retrieve and cache password material. It is therefore inaccurate to say that nothing is synchronised or that a password never exists outside the calculation. Recovery must restore both directory consistency and the intended hosts’ ability to use the account.
Why that matters for backups
In our understanding, that design has a direct consequence. A backup of a domain controller contains the directory, and the directory contains the root key and the account details. Whoever holds such a backup holds, in principle, what is needed to calculate the passwords of the organisation's group managed service accounts.
Microsoft treats this seriously. Its support article How to recover from a Golden gMSA attack describes an approach to repairing the credentials of a group Managed Service Account (gMSA) that are affected by a domain controller database exposure incident. Microsoft names the linked research Introducing the Golden GMSA Attack; this article does not describe the attack itself.
In our view, the lesson for backup is straightforward. A domain controller backup is not just a recovery asset. It is one of the most sensitive files an organisation holds, and it should be protected as carefully as the domain controllers themselves: restricted access, encrypted storage, a record of who can reach it, and no copies left on general-purpose shares or laptops.
What Microsoft advises after an exposure
If a domain controller's database, or a backup of it, may have been exposed, the support article's approach is clear: The approach for resolving the problem is to replace the Microsoft Key Distribution Service (kdssvc.dll, also known as KDS) root key object and all gMSAs that use the compromised KDS Root Key object.
In our reading, the important point is that changing the accounts' passwords alone does not help while the root key that calculates them is still the same. Microsoft distinguishes two recovery scenarios. Where exposure details and timing are reliable and meet its conditions, existing accounts can move to a new root key without all being recreated. Where the exposure is unknown or password rollover cannot be awaited, its broader recovery procedure recreates accounts. The incident owner must select the applicable documented scenario.
The article also addresses how widely to apply it. It explains that a domain controller's database mainly exposes the accounts of its own domain, but that an attacker may be able to reach further. It then adds a realistic note: Usually, you don't know the details of what was exposed. Its suggestion follows: Therefore, it's suggested to apply the resolution to all domains of the forest.
The article's resolution section notes that its approaches involve creating a new root key and restarting the Key Distribution Service on every domain controller of the domain. This article does not reproduce those steps; Microsoft's article is the authority.
The restored backup sets part of the scope
The support article includes a worked example that ties this directly to backup. It explains that a setting chosen when each account is created, how often its password changes, affects how many accounts must be recreated after an exposure and a restore. It notes that the setting becomes fixed once the account is created. Microsoft offers 15 days or another appropriate interval as a design choice, not a universal recovery target. In its reliable-exposure scenario, it also says accounts created after exposure ended do not need manual repair, because their passwords regenerate from the new root key; that exception depends on establishing the exposure boundary.
Microsoft’s example ties the required replacement scope to the exposure, backup point and account password interval. It should not be reduced to “replace accounts created after the backup”. Assess all accounts that may use compromised root-key material and follow the documented incident procedure across the affected forest. A shorter interval is a design choice, not a substitute for replacing compromised key material.
In a forest recovery
Microsoft's Active Directory Forest Recovery - Perform the initial recovery guide brings these accounts into the recovery steps themselves. Where the recovery follows an intrusion, it advises resetting administrative account passwords and adds: work on replacing all GMSA passwords as if an administrative account was taken over, the attacker may have retrieved information that allows them to authenticate as GMSA.
It repeats the point later in the same guide: If you're using gMSA accounts, you may need to re-create them as the password generation details may be exposed to an attacker, pointing to the support article above.
In our reading, this means that after a security incident, restoring the directory brings back the same root key that may have been exposed. The restore returns the forest to a working state; it does not, on its own, return it to a trusted one. Replacing the root key and the accounts is part of finishing the recovery.
Recreating accounts means reconfiguring services
In our understanding, a new group managed service account is a new account, not the old one with a new password. Every service, scheduled task or application pool that ran under the old one has to be pointed at the new one, and the new one has to be granted whatever access the old one had: file permissions, database logins, application roles.
In our view, this is where recovery plans are most often thin. The accounts are convenient precisely because nobody has to think about them day to day, so nobody has a list of where they are used. A recovery plan should include, for each group managed service account, which servers use it, which services run under it, and what it has been given access to.
Don't treat the root key casually
The root key guide includes a caution about deleting and recreating the key outside a planned procedure: Deleting and re-creating the root key can lead to issues where the old key continues to be used after deletion due to caching of the key. The root-key guide separately says the KDC should be restarted on all domain controllers when a root key is re-created. Service names and scope must be taken from the applicable recovery procedure, not treated as interchangeable. It also describes a deliberate wait after a new key is created, explaining that Waiting up to 10 hours is a safety measure to prevent password generation from occurring before all DCs in the environment are capable of answering gMSA requests.
In our reading, both points belong in the recovery timeline. Replacing the root key is not instant, and doing it carelessly can leave domain controllers disagreeing. In our view, it should be done once, by the documented procedure, as a planned step of the incident response.
Watching the key
The support article suggests auditing reads of the root key as a proactive measure, while noting its limit: Auditing only helps to detect an online attack on the KDS Root Key data.
In our reading, that limit points back to backups. Auditing can show someone reading the key from a live domain controller. It cannot show someone reading it from a stolen backup file. Protecting the backups is the control for that case.
Where these accounts tend to be used
Knowing where group managed service accounts sit helps scope a recovery. The overview describes their main use: gMSAs provide a single identity solution for services running on a server farm or on systems behind Network Load Balancer. It also notes that The gMSA supports hosts kept offline for an extended time period and manages member hosts for all instances of a service.
In our reading, that describes exactly the systems that matter most in a recovery: web farms, application tiers and services spread across several servers. In our view, a recovery runbook should name them, because a missed account surfaces as a service that will not start, long after the directory itself looks healthy.
Restoring after an ordinary mistake
Not every recovery is a security incident. For an accidentally deleted gMSA, assess the supported Active Directory object-recovery path and confirm the required KDS key, allowed password-retrieval principals and host configuration remain available. The sources here do not establish a complete gMSA object-restore procedure, so this article does not promise that restoring the object alone returns every service to operation. Root-key replacement is an exposure-response decision, not a routine response to a deleted object.
In our view, the distinction to draw early in any recovery is therefore simple: was something deleted or broken, or might something have been seen? The first is a restore. The second is a restore followed by replacing the keys and accounts.
Not a reason to go back to ordinary service accounts
None of this, in our view, argues against group managed service accounts. A traditional service account with a fixed password has the same exposure in a stolen directory backup, and a password that may not have changed in years. Group managed service accounts change their passwords automatically and can be replaced in a planned way. The point is to plan for that replacement, not to avoid the feature.
What we recommend
- Treat domain controller backups as highly sensitive: restricted, encrypted, and recorded.
- List every group managed service account, the servers and services that use it, and what it can access.
- Include root key and account replacement in the incident response plan for any suspected directory exposure.
- Follow Microsoft's documented procedure for replacing the root key, and allow for its waiting period.
- Choose a password change interval for new accounts deliberately.
- Consider auditing root key reads, knowing it does not cover stolen backups.
- Rehearse replacing one account end to end in a test environment.
Check the service identity after the directory returns
A rebuilt application host needs more than a healthy domain controller. Record which host or group is authorised to retrieve the managed password, which service uses the account, its service principal names and the resources that grant it access. A newly created replacement account has a different identity, so existing permissions and database mappings require deliberate review. Keep that inventory as configuration evidence without exporting password material into the runbook.
In an isolated rehearsal, confirm the intended service starts under its expected identity and reaches a controlled resource. A password-retrieval check alone does not establish that the application can perform its work. After a compromise, coordinate the order in which keys, accounts, permissions and services are replaced so that an old exposed dependency is not silently reintroduced from backup. Record the service-level outcome separately from completion of the directory recovery steps.
Risks and limits of this article
- Based on Microsoft documentation as read on 11 November 2026.
- The attack itself is deliberately not described; readers are referred to Microsoft's article.
- That a backup contains what is needed to calculate passwords is our understanding of Microsoft's description.
- No accounts or keys were created, replaced or restored for this article, and no commands, attribute names or directory paths are given.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: Group Managed Service Accounts overview
- Microsoft Learn: Create a Key Distribution Service (KDS) root key
- Microsoft Learn: How to recover from a Golden gMSA attack
- Microsoft Learn: Active Directory Forest Recovery - Perform the initial recovery
This article was originally published on .