Group managed service accounts: ending service account passwords

A group managed service account (gMSA) is an Active Directory account whose password is generated and rotated by Windows, so nobody types, stores or shares it. For services that run on one or many servers, it replaces the old shared service account password that never gets changed.

The problem it solves

Classic service accounts have a human set password. It ends up in a wiki page or a script, gets reused across servers, and stays the same for years because changing it risks breaking a service. Anyone who obtains that password can use the account until someone notices.

Microsoft's documentation frames a gMSA as providing automatic password management, simplified service principal name management, and delegated administration, extended over multiple servers. When Windows handles the password, administrators no longer manage password synchronization between service instances.

How it works

The Microsoft Key Distribution Service lets hosts securely obtain the latest key, or a specific key, for an Active Directory account. The service shares a secret used to create keys that change periodically. For a gMSA, the domain controller computes the password from that key and other attributes of the account. Member hosts obtain the current and the preceding password values by contacting a domain controller.

You are not asked to pick a password, and the account does not need an interactive sign in. Hosts that are offline for a long time are supported, according to the documentation.

Where it fits

gMSAs suit a single identity for a service running on a server farm, or on systems behind a network load balancer. Microsoft describes this case because mutual authentication protocols need every instance of a service to use the same principal.

Failover clusters do not support gMSAs. Services running on the cluster service can still use a gMSA or a standalone managed service account if they are a Windows service, an app pool, a scheduled task, or natively support them.

Requirements and gotchas

• gMSAs are not applicable to Windows operating systems earlier than Windows Server 2012.
• The PowerShell tooling for administering them needs a 64-bit architecture.
• Managed service accounts depend on Kerberos supported encryption types. Microsoft says to always configure AES for them, and notes that if a host does not support RC4, authentication fails when the account has no encryption types set.
• The software on the server has to support running under a managed account. Many Windows services, app pools and scheduled tasks do. A command line tool that insists on a typed password does not.

A migration approach

1. Inventory service accounts, noting where each runs and who knows the password.
2. Pick the services that are well understood, such as an app pool or a scheduled task.
3. Create the gMSA, allow only the intended hosts to retrieve the password, and set AES.
4. Switch one service at a time and test the dependent connections.
5. Disable the old account, wait one full business cycle, then delete it.

Treat the security group that may retrieve the gMSA password as sensitive. Putting too many hosts in it widens who can run as the account.

Why this matters for attackers

Service accounts with human chosen passwords are a classic target for offline guessing. A password generated by the system is not something an attacker can realistically guess, which removes that route. It does not stop abuse of an account whose permissions are too wide, so keep the rights narrow as well.

Quick check

Sources

• Group Managed Service Accounts overview, Microsoft Learn

Last reviewed: 19 October 2026.