Group Managed Service Accounts (gMSA): putting an end to static service passwords
In almost every audit we find service accounts whose password has not changed in years, sometimes known to several successive contractors. Group Managed Service Accounts have existed since Windows Server 2012 and solve most of the problem. Their security, however, rests on two often overlooked elements: the KDS root key and the list of principals allowed to read the password.
Why traditional service accounts are a problem
A traditional service account is an ordinary user account with a human-chosen password, often set to never expire. That password gets typed into the services console, into scheduled tasks, sometimes into scripts or configuration files. It is rarely changed, because nobody knows exactly where it is used and everyone fears breaking an application.
These accounts pile up weaknesses: they often carry a service principal name (SPN), which exposes them to Kerberoasting; they frequently hold excessive rights, sometimes Domain Admins membership "to make it work"; and their weak or old password can be cracked offline or found on a file share.
How a gMSA works
A Group Managed Service Account is an object of type msDS-GroupManagedServiceAccount. Its password is computed by domain controllers from the Key Distribution Service (KDS) root key. It is long, random and rotated automatically at an interval defined at creation (30 days by default, and not changeable afterwards). No human needs to know it: authorised servers retrieve it from a domain controller and the Windows service uses it directly.
A gMSA can be used by several servers at once, which suits web farms, clusters and distributed applications. It works for Windows services, IIS application pools, scheduled tasks and many Microsoft products; for third-party software, check compatibility with the vendor.
The KDS root key is a Tier 0 secret
Creating the KDS root key is a one-time prerequisite per forest. It is stored in the configuration partition and must have replicated to domain controllers before it can be used; Microsoft documents an effective-time delay to respect in production.
The crucial point: anyone who can read this key's attributes, plus a few public details about a gMSA, can compute its past and future passwords offline. This scenario, sometimes called "Golden gMSA", means the KDS key must be protected at the same level as the directory database itself. By default only highly privileged groups can access it; an audit checks that no delegation has widened that scope.
Controlling PrincipalsAllowedToRetrieveManagedPassword
The list of principals allowed to retrieve the password is stored in the msDS-GroupMSAMembership attribute, exposed in PowerShell as PrincipalsAllowedToRetrieveManagedPassword. Any principal in that list can read the secret and therefore act as the gMSA.
- Authorise a security group containing only the computer accounts of the relevant servers, never users or broad groups.
- Treat membership of that group as sensitive: adding a computer means handing it the service identity.
- Also monitor who can modify the attribute itself: write access to the gMSA object lets someone add themselves to the list.
If the gMSA holds high privileges, the servers using it effectively inherit that level. An administrative gMSA should therefore only be used from servers of the same tier.
A gMSA does not fix permissions. Moving a service account to a gMSA removes the password problem, not the privilege problem. Use the migration as an opportunity to cut rights down to what is strictly required.
Delegated Managed Service Accounts (dMSA)
Windows Server 2025 introduces dMSAs, designed to ease migrating an existing service account to a managed account while taking over its rights. Research published in 2025 showed that a user allowed to create objects in an organisational unit could, under certain conditions, abuse this mechanism to inherit other accounts' privileges. Microsoft has released fixes; before any deployment, apply the latest updates, read the current Microsoft documentation and review who can create objects in your OUs, even if you do not use dMSAs.
What an audit checks
- the presence of the KDS root key and the list of principals able to read it;
- remaining traditional service accounts, their SPNs and password age;
- for each gMSA, the content of
PrincipalsAllowedToRetrieveManagedPasswordand write permissions on the object; - privileges granted to gMSAs and the tier of the servers using them;
- object creation rights on OUs, particularly with dMSAs in mind.