The svc_sql account was created together with the database server and has kept the same password ever since. Two administrators know it, and changing it means manually updating three application servers and a maintenance window nobody has time for. The account has a registered SPN, so any logged-in domain user can ask the controller for a ticket to that service and crack the password on their own machine, without leaving a single failed logon in the log.
A Group Managed Service Account (gMSA) removes this problem at the source: the domain controller computes the password, it is long and random, and it changes by itself. It is not a switch, though: gMSA moves the secret to the list of computers that may retrieve the password, does not support every service and needs a few prerequisites on the domain side. Those limits decide whether migrating service accounts improves the domain’s cybersecurity or only moves the risk.
What is gMSA and how does it differ from a regular service account?
A gMSA is a domain account that runs services on multiple servers, and its password is managed by the operating system, not by an administrator. The Microsoft Learn documentation describes it as an extension of the standalone Managed Service Account (sMSA), an account type introduced in Windows Server 2008 R2 and Windows 7: an sMSA works on a single server, a gMSA across a whole farm.
A user account acting as a service account has a password set by hand that someone must know, enter in the configuration of every service instance and change everywhere at once. A gMSA has no password known to a person: the service gets it from the domain controller, and the password field in its configuration stays blank. gMSA does not support systems older than Windows Server 2012.
For server farms, for example behind a load balancer, a gMSA gives every service instance one identity. Protocols with mutual authentication, such as Kerberos, only work when all instances of the service use the same principal.
Why do service accounts with static passwords attract attackers?
Because the password of a service account with an SPN can be cracked offline, and a static password gives the attacker as much time as they need. MITRE ATT&CK describes the technique as T1558.003 and calls it Kerberoasting: anyone holding a valid TGT can ask a domain controller for service tickets for any SPN, and part of such a ticket may be encrypted with the RC4 algorithm using a key derived from the service account’s password.
For the defender, the trouble is that requesting a service ticket is an ordinary protocol operation. The attacker triggers no account lockout: they retrieve the ticket and crack it on their own hardware, and the domain is left with only a ticket request event. MITRE points to anomalous TGS ticket requests (event 4769) with RC4 encryption and an unusual number of requests in a short time as detection signals.
How well the attack works depends on the password. In its description of the technique (version 19 of the ATT&CK knowledge base), MITRE recommends long service account passwords, ideally 25 or more characters, that are complex and expire periodically, and suggests considering Group Managed Service Accounts or password vaulting, as well as AES encryption instead of RC4. A password set by hand when the server was installed and unchanged for years meets none of these conditions.
The article on Active Directory hardening also lists migrating service accounts to gMSA among the high-priority actions.
How does gMSA manage the password without an administrator?
The domain controller computes the gMSA password from a key supplied by the Microsoft Key Distribution Service (KDS) and from the account’s attributes, and the servers allowed to use the account retrieve it from the controller. According to Microsoft’s documentation, member hosts can obtain both the current and the preceding password, so the moment of change does not have to interrupt the service.
Microsoft’s guide Secure group managed service accounts gives the parameters: passwords are 240 bytes long and randomly generated, and Windows changes them every 30 days. According to Microsoft, the length and complexity of these passwords minimize the likelihood of compromise by brute-force or dictionary attacks.
The change interval is set once. The -ManagedPasswordIntervalInDays parameter of the New-ADServiceAccount cmdlet can only be given when the account is created, and without a value it defaults to 30 days. Anyone who wants a different interval after creation has to set up a new gMSA, so this decision is worth making before the migration.
The whole mechanism rests on the KDS root key stored in Active Directory, in the forest configuration container. Microsoft warns that deleting and re-creating the root key can leave the old key in use from cache, and after re-creating it the KDC must be restarted on all domain controllers.
What prerequisites do you need before deploying gMSA?
The domain and forest functional levels must be at least Windows Server 2012, a KDS root key must exist in the domain, and the person creating accounts must be a member of Domain Admins or Enterprise Admins or hold delegated permission to create msDS-GroupManagedServiceAccount objects. That is how the Manage group Managed Service Accounts page on Microsoft Learn describes the requirements.
The KDS root key causes the most surprises. After it is created, domain controllers wait up to 10 hours before allowing a gMSA to be created, so that the key can replicate to all controllers. The -EffectiveImmediately parameter adds a key that is used at once, but only on the controller where it was created; the others can use it only after replication. Microsoft reserves backdating the key’s effective time by 10 hours for test environments with a single controller.
The second prerequisite concerns Kerberos encryption. Managed accounts depend on supported encryption types, and Microsoft recommends always configuring AES for MSAs. Every system that logs on as a gMSA or installs one must support the encryption types gMSA requires, otherwise the logon fails.
Before the migration window, also check the remaining items on Microsoft’s list: a 64-bit architecture for the PowerShell cmdlets, registered SPNs, DNS records and synchronized clocks on the systems taking part in authentication.
How do you create and install a gMSA step by step?
Deployment takes four steps: the KDS root key (a one-time operation), a gMSA with a list of permitted computers, installing the account on every server running the service, and switching the service to the new identity.
# 1. KDS root key — once, on a domain controller
Add-KdsRootKey -EffectiveImmediately
# 2. The gMSA; the group of service servers may retrieve the password
New-ADServiceAccount -Name svc-sql -DNSHostName svc-sql.company.local -PrincipalsAllowedToRetrieveManagedPassword "SQL-Servers"
# 3. On every server running the service
Install-ADServiceAccount -Identity svc-sql
Test-ADServiceAccount -Identity svc-sqlKeep the list of permitted computers in a security group: Microsoft advises adding the computer accounts that host the service to a designated group and granting permissions to that group. A new server in the farm then gets access by being added to the group.
A gMSA name must be unique across the whole forest, not just the domain, and an attempt to create an account with a duplicate name fails even in a different domain. Test-ADServiceAccount checks whether a given server can retrieve the password, and its output is worth keeping as evidence of completion.
The last step happens in the service configuration. According to Microsoft’s guide, you change the service identity to the gMSA, leave the password blank, validate that the service works under the new identity and only then delete the old service account. This order keeps a way back if the service does not start.
Which services can’t you move to gMSA?
You cannot move services that do not support managed accounts, nor failover clusters themselves. Microsoft states plainly that failover clusters do not support gMSA, but services running on top of a cluster can use a gMSA or sMSA if they are a Windows service, an application pool, a scheduled task or natively support managed accounts.
On the host side, gMSA works with services configured through the Service Control Manager, IIS application pools, Task Scheduler tasks and products that support sMSA, because gMSA uses the same APIs. An application that stores credentials in its own configuration or requires a password in a setup wizard has to be checked in the vendor’s documentation before it goes on the migration list.
Microsoft recommends testing the service with a gMSA in a test environment before production. When the service does not support gMSA, the next choice is an sMSA, the same functionality on a single server. When that is not an option either, what remains is a standard user account that needs a strong password management process, for example a password vault with rotation.
Key takeaways:
- A gMSA is a domain account for services on multiple servers, and its password is computed by the domain controller, not by a person.
- The password is 240 bytes long, random and changes automatically; the interval is set only when the account is created.
- The first gMSA can be created only after the KDS root key replicates, and controllers wait up to 10 hours for that.
- Failover clusters do not support gMSA, and services without managed account support need a different solution.
Does gMSA fully protect against Kerberoasting?
Not fully. A long, random password makes cracking a ticket offline harder, but the account can be taken over another way: through a computer that is allowed to retrieve the password.
The PrincipalsAllowedToRetrieveManagedPassword list becomes the new secret. Every computer on that list, and therefore anyone who gains administrator rights on it, can obtain the account’s password. Microsoft admits this openly in its dMSA overview: gMSA passwords are machine-generated and rotated automatically, but they are not machine-bound and can be stolen.
The second trap is permissions. gMSA manages the password more safely, but it does not limit what the account can do. Microsoft names two risks: a gMSA in privileged groups and a gMSA with read or write access to sensitive resources. The recommendations are: remove the account from privileged groups, grant it only the rights the service needs, audit access to sensitive resources and remove unnecessary permissions.
Migrating to gMSA while keeping Domain Admins membership swaps a weak password for a strong one but leaves an account whose takeover gives away the whole domain, which is why the permission review goes together with the migration.
What is dMSA in Windows Server 2025 and when should you consider it?
dMSA (delegated Managed Service Account) is an account type introduced in Windows Server 2025 that replaces a traditional service account with a machine-bound account and disables the original account’s password. According to Microsoft’s documentation, dMSA authentication is linked to the device identity, so only specified machines can use the account, which is meant to prevent credential harvesting through Kerberoasting.
The key difference from gMSA is where the secret lives. The dMSA secret, derived from the machine account credential, is held on the domain controller and, according to Microsoft, cannot be retrieved or found anywhere else; it can be further protected with Credential Guard. With gMSA, the password reaches every permitted server.
dMSA is not, however, the next step after gMSA. Microsoft notes that you cannot migrate from a managed service account or a gMSA to a dMSA, because dMSA replaces standard service accounts. It also takes patience: after modifying the security descriptor you must wait at least two ticket lifetimes (14 days) before completing the migration, and every machine using the account must support dMSA, otherwise it loses authentication once the old account is disabled.
The account type itself also had a flaw. In August 2025 Microsoft patched CVE-2025-53779 in Kerberos: according to the vendor’s description, an attacker with write access to attributes of a dMSA object, including msDS-ManagedAccountPrecededByLink, could gain domain administrator privileges. Akamai researchers, who described the technique as BadSuccessor, recommend updating Windows Server 2025 domain controllers first and then reviewing permissions on organizational units, containers and dMSA objects. Treat the right to create dMSA accounts as a privileged permission.
How do you find service accounts that need migrating?
Start with two lists: the managed accounts that already exist and the user accounts with a registered SPN. The first comes from Get-ADServiceAccount -Filter *, and Microsoft notes that a gMSA is identified by the object class msDS-GroupManagedServiceAccount, while an sMSA uses msDS-ManagedServiceAccount.
# Managed accounts (gMSA and sMSA)
Get-ADServiceAccount -Filter * | Select-Object Name, ObjectClass
# User accounts with an SPN — migration candidates
Get-ADUser -Filter "ServicePrincipalName -like '*'" -Properties ServicePrincipalName, PasswordLastSet |
Select-Object SamAccountName, PasswordLastSet, ServicePrincipalNameThe second list matters more. A user account with an SPN is exactly the target whose ticket an attacker requests in Kerberoasting, and the PasswordLastSet column shows how long the password has gone unchanged. Accounts with passwords set years ago and membership in privileged groups go to the front of the queue.
The third source is the 4769 events described in the Kerberoasting section.
How do you plan the migration of service accounts to gMSA?
Plan the migration per account, not per server: every service account gets a target type, a transition condition and evidence that the service runs under the new identity. The table organizes the decisions that come back with every account.
| Account situation | Target type | Transition condition | Typical trap | Evidence of completion |
|---|---|---|---|---|
| Windows service on several servers (farm, load balancing) | gMSA | server group in PrincipalsAllowedToRetrieveManagedPassword, AES on the hosts | the account stays in a privileged group | Test-ADServiceAccount output on each host, the account’s group list |
| Service on a single server | gMSA or sMSA | the service supports managed accounts | password interval set without a decision | the account’s msDS-ManagedPasswordInterval value |
| IIS application pool or scheduled task | gMSA | identity set with a blank password | old account deleted before testing | log of the service running under the new identity |
| Failover cluster (the cluster itself) | no gMSA | not applicable | attempting migration against the documentation | decision in the account register with a justification |
| Application without managed account support | user account in a password vault | long random password, rotation, a named owner | password known to several people | rotation and access history in the vault |
| Standard service account in an environment with Windows Server 2025 | dMSA | all machines support dMSA, at least 14 days for the migration | migrating while replication is broken | msDS-DelegatedMSAState = 2 (migration completed) |
The migration order follows risk: first user accounts with an SPN and privileged rights, then the remaining accounts with an SPN, and finally accounts without an SPN.
How can nFlo help secure service accounts?
nFlo runs an Active Directory Security Audit whose scope covers service accounts, Kerberos configuration and attack paths, including Kerberoasting. The audit uses BloodHound, PingCastle and Purple Knight in read-only mode, and its output is an attack path map and a prioritized hardening plan in which migrating service accounts gets its place in the queue.
For accounts that cannot be moved to gMSA, nFlo deploys One Identity Safeguard for Privileged Passwords: a vault for privileged account passwords with rotation, access requests with approval and automatic discovery of privileged accounts on the network. The account’s password then stops passing from person to person, and every access leaves an audit trail.
If you want to check how many service accounts in your domain have an SPN and a password set years ago, talk to us.
What else is worth knowing about gMSA?
Does an administrator have to change the gMSA password?
No. The domain controller computes the password and Windows changes it on its own, at the interval set when the account is created. The password field in the service configuration stays blank, and the servers allowed to use the account retrieve the current password from the controller.
Does gMSA work in a failover cluster?
The failover cluster itself does not support gMSA. Services running on top of the cluster can still use a gMSA or sMSA if they are a Windows service, an application pool, a scheduled task or natively support managed accounts.
How long do you have to wait for the first gMSA after creating the KDS key?
Up to 10 hours. Domain controllers wait that long after the KDS root key is created so that the key can replicate. Microsoft allows shortening this wait only in test environments with a single domain controller.
Can you change the password interval of an existing gMSA?
No. The -ManagedPasswordIntervalInDays parameter sets the interval only when the account is created, and without a value it defaults to 30 days. A different interval requires creating a new gMSA and switching the service to it.
Can a gMSA be migrated to dMSA?
No. Microsoft states that you cannot migrate from a managed service account or a gMSA to a dMSA. dMSA, introduced in Windows Server 2025, replaces standard service accounts, not accounts that the system already manages.
