How to convert AD service accounts to gMSA: Step-by-step commands, checks and rollback

Most Active Directory estates still run services under domain user accounts whose passwords were set once and never changed, and every server running those services holds a recoverable copy of the password. A group managed service account (gMSA) replaces that static secret with a 240-byte password that domain controllers compute and Windows changes every 30 days by default. This page is the hands-on procedure: the read-only discovery you run first, the exact PowerShell and command-line steps from Microsoft documentation, how to prove the cut-over worked, and how to roll back cleanly. It is written for Windows server engineers and AD administrators doing the work. For the concepts, the KDS root key threat model and dMSA, read the Group Managed Service Accounts (gMSA) Guide first.

Key takeaways

• Discover before you touch anything. Every read-only step (finding SPN accounts, where they run and what they access) comes before the first change, and the old account stays enabled until the new identity has run cleanly for a full cycle.
• The KDS root key is a one-time, forest-wide prerequisite. Create it with Add-KdsRootKey and allow up to 10 hours for replication in production; the back-dated shortcut is for single-DC labs only.
• The retrieval group is the real security boundary. Whoever is in PrincipalsAllowedToRetrieveManagedPassword can read the password, so put only the hosts that run the service in that group.
• Cut-over is a blank password and a trailing dollar sign. The service logs on as DOMAIN\name$ with no password; the commonest failures are a missing $, a host that was never added to the group, or an SPN still sitting on the old account.
• Rollback is cheap only if you plan it. Record the old logon account and SPNs before cut-over, keep the old account disabled rather than deleted for an agreed period, and you can revert a service in minutes.

When you need this

Convert a service account to gMSA when a Windows service, IIS application pool or scheduled task runs as a domain user with a password, and the software supports managed service accounts. Typical triggers:

• Kerberoasting exposure: any user account with a servicePrincipalName can have a service ticket requested and cracked offline (MITRE ATT&CK T1558.003 Kerberoasting). A gMSA password is long and random, which makes offline cracking impractical. See the Kerberoasting and AS-REP Roasting Defence Guide.
• Credential reuse across servers: a user-based service password is stored in LSA secrets on each host (T1003.004 LSA Secrets), so one compromised server exposes the account everywhere it runs.
• A directory dump or breach: static service account passwords outlive incidents. In the Cisco Active Directory credentials leak, hashes from a 2022 intrusion, reportedly including service accounts, were republished in 2025, which is only harmless if those passwords have since changed.
• Audit findings: service accounts with passwords older than policy, or "password never expires" set on accounts nobody owns.

Do not use this procedure when the service runs on a failover cluster as a clustered resource (Microsoft states failover clusters do not support gMSAs, although Windows services, application pools and scheduled tasks running on cluster nodes can), when the vendor explicitly does not support managed accounts, or when the service only needs local rights (use a virtual account instead). For the full choice between account types, see the Windows Services and Service Account Security Guide.

Before you start

Prerequisites (from Microsoft documentation)

Read-only discovery

1. Find candidate accounts. List user accounts that carry SPNs: Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName,PasswordLastSet,MemberOf. Sort by PasswordLastSet; the oldest are your first wave.
2. Record each account's SPNs. setspn -L <account>. Save the output: you will need it to move the SPNs and to roll back.
3. Find where it runs. On each candidate host, list services by logon account: Get-CimInstance Win32_Service | Where-Object StartName -like "*<account>*" | Select Name,StartName,State. Check IIS application pools and scheduled tasks too. Successful logons with logon type 5 (service) in event 4624 on the domain controllers show hosts you did not know about.
4. Record what it accesses. File share ACLs, SQL logins, local group memberships, "Log on as a service" rights and any group the account belongs to. The gMSA needs the same rights, and no more.
5. List existing managed accounts. Get-ADServiceAccount -Filter * | Where-Object {$_.ObjectClass -eq "msDS-GroupManagedServiceAccount"} shows gMSAs already in the forest, so you do not create duplicates. gMSA names must be unique in the forest, not just the domain.
6. Agree an owner, a change window and a rollback deadline for each service. Record them in the Service Account Inventory Template.

Step-by-step

Steps 1 and 2 change the directory but not any running service. Steps 5 to 7 are the disruptive part: run them in a change window, one service at a time.

1. Create the KDS root key (once per forest, change). On a domain controller, as Domain Admin or Enterprise Admin: Add-KdsRootKey -EffectiveImmediately. Domain controllers wait up to 10 hours after creation before allowing gMSA creation so that the key can replicate, and Microsoft warns that using a gMSA before replication completes can fail. In a single-DC lab only, Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) skips the wait. Confirm event 4004 in the KdsSvc Operational log. Skip this step if Get-KdsRootKey already returns a key.
2. Create a host group for retrieval (change). Create a security group such as gmsa-<service>-hosts and add only the computer accounts that run the service, using Add-ADGroupMember -Identity gmsa-<service>-hosts -Members <HOST1>$,<HOST2>$. Computers pick up new group membership on their next Kerberos ticket, which in practice means a reboot (or purging the computer's tickets) before Install-ADServiceAccount will succeed.
3. Create the gMSA (change). New-ADServiceAccount -Name <gMSAName> -DNSHostName <gMSAName>.<domain> -PrincipalsAllowedToRetrieveManagedPassword gmsa-<service>-hosts. Add -ManagedPasswordIntervalInDays <Days> only if you need something other than the 30-day default: Microsoft states the interval can only be set at creation. For accounts that never accept inbound Kerberos, Microsoft documents -RestrictToOutboundAuthenticationOnly.
4. Install and test on each host (low risk). In an elevated PowerShell session on every host: Install-ADServiceAccount -Identity <gMSAName>, then Test-ADServiceAccount -Identity <gMSAName>. True means the host can authenticate as the account with its current credentials. Do not continue on a host that returns anything else.
5. Move the SPNs (disruptive, flag in the change). An SPN can only sit on one account, so remove it from the old account and add it to the gMSA in the same window: setspn -D <SPN> <oldaccount> then setspn -S <SPN> <gMSAName>$. The -S switch checks for duplicates before adding, which is why Microsoft prefers it over -A. Skip this step for services with no SPN.
6. Grant the gMSA the old account's rights (change). Add DOMAIN\<gMSAName>$ to the same share ACLs, SQL logins, local groups and user rights you recorded in discovery. Do not add it to privileged groups: Microsoft's guidance is to remove gMSAs from privileged groups and grant only what the vendor documents.
7. Switch the service identity (disruptive). In services.msc, set Log On to DOMAIN\<gMSAName>$ and leave both password boxes empty, or from an elevated prompt: sc.exe config <ServiceName> obj= "DOMAIN\<gMSAName>$" password= "". Note the space after each equals sign, which sc.exe requires. For an IIS application pool, set the pool identity to the same account with a blank password. Restart the service.
8. Repeat per host for farms and load-balanced services, draining each node from the load balancer before step 7.

Verify it worked

Leave the service running through at least one full password change (30 days by default) before you retire the old account. That is the only real proof that the hosts retrieve each new password correctly.

Rollback and common errors

Rollback

1. Set the service back to the old account and its password (services.msc, or sc.exe config <ServiceName> obj= "DOMAIN\<oldaccount>" password= "<password>", typing the password interactively rather than storing it in a script).
2. Move the SPNs back: setspn -D <SPN> <gMSAName>$ then setspn -S <SPN> <oldaccount>.
3. Restart the service and repeat the functional test.
4. Leave the gMSA installed while you diagnose. If you abandon it, run Uninstall-ADServiceAccount -Identity <gMSAName> on each host before deleting it: Microsoft notes that deleting the object by hand does not perform the same clean-up.

This only works if the old account still exists and you still know its password. Disable it after cut-over, do not delete it, and keep the password in your vault until the rollback deadline passes. If you rotated it, treat rollback as a new credential.

Common errors

Hardening afterwards

• Retire the old account: after the observation period and one password change, remove its remaining group memberships, then delete it. Until then it is a live credential that can still be Kerberoasted. See the planned How to find and retire Active Directory service accounts with SPNs.
• Lock down the retrieval group: treat membership of gmsa-*-hosts groups as privileged. Monitor event 4728/4732/4756 (member added to a security group) for those groups, and never add user accounts to them.
• Tier the gMSA with its hosts: a gMSA used on a Tier 0 system is Tier 0. See the Tiered Administration and Enterprise Access Model Guide.
• Restrict interactive use: deny interactive and Remote Desktop logon for service identities through Group Policy, and alert on 4624 logon types 2 or 10 for any gMSA.
• Protect the KDS root key: anyone who can read the root key and the gMSA's attributes can compute its passwords offline. Restrict and audit read access to the key's container, and keep domain controller backups under Tier 0 controls.
• Measure progress: track the percentage of SPN-bearing accounts that are gMSA, the number of user-based service accounts with passwords older than one year, the count of gMSAs whose retrieval principals include anything other than a host group, and mean time from discovery to cut-over per service.

Framework mapping

Practitioner checklist

• Run SPN account discovery and record SPNs, hosts and rights for each account before changing anything.
• Confirm functional levels, the KDS root key (event 4004) and Kerberos health.
• Create one host-only retrieval group per gMSA and reboot hosts after adding them.
• Create the gMSA with the right password interval the first time.
• Install and get True from Test-ADServiceAccount on every host before cut-over.
• Move SPNs and switch identity in the same change window, one service at a time.
• Verify with logs and an owner sign-off, then run through one full password change.
• Disable, then delete, the old account after the rollback deadline.
• Monitor retrieval group changes and interactive logons by gMSAs.

Standards and references

• Microsoft Learn: Get started with group managed service accounts
• Microsoft Learn: Create the Key Distribution Services KDS Root Key
• Microsoft Learn: Secure group managed service accounts
• Microsoft Learn: Test-ADServiceAccount
• Microsoft Learn: sc.exe config
• Microsoft Learn: Setspn
• MITRE ATT&CK: Kerberoasting
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Group Managed Service Accounts (gMSA) Guide · Windows Services and Service Account Security Guide · Service Account Security Guide · Active Directory Security Monitoring and Event IDs Guide