Ran a quick audit this week looking for Kerberoastable accounts at one of our clients and (as always) found several. One had a last password change date of June 2012.

The service was still running but nobody touched it in over a decade.

This is more common than it should be. Service accounts get set up once, given a password someone typed in a hurry, and then forgotten completely. They're not in any rotation policy and nobody thinks about them until something breaks.

The problem isn't just weak passwords either. Any authenticated domain user can request a Kerberos service ticket for an account with a SPN. That ticket is encrypted with the account's password hash. If the password is weak and hasn't changed since 2019, an attacker pulls the ticket offline and cracks it with Hashcat in under an hour. Especially if it's encrypted with RC4. No lockout, no logs on the account and zero noise.

Once it's cracked, they own whatever that service account has access to. In a lot of environments that's SQL, backup agents! (this one's huge) and Exchange. Sometimes it's Domain Admin because someone thought it was easier at the time.

gMSA fixes this.

The password becomes 240 bytes of random data, so 120 chars, rotated every 30 days, and no human ever sees it in plaintext. There's nothing to crack because the entropy is completely unrealistic to brute force.

Setup is actually straightforward:

One-time per domain:

Add-KdsRootKey -EffectiveImmediately

Wait 10 hours for replication. (-EffectiveImmediately doesn't do what you think it might do.)

Create the account:

New-ADServiceAccount -Name "svc_yourservice" `
  -DNSHostName "svc_yourservice.yourdomain.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "SERVER01$"

Install on the target server:

Install-ADServiceAccount -Identity "svc_yourservice"
Test-ADServiceAccount "svc_yourservice"

If Test-ADServiceAccount returns "True", you're done. If it returns "False", the computer account probably isn't in PrincipalsAllowedToRetrieveManagedPassword. Fix that, run klist purge, gpupdate /force, test again.

Assign it in services.msc by entering YOURDOMAIN\svc_yourservice$ on the Log On tab. Leave the password field empty.

Limitations worth knowing before you start:

• Only works for Windows services, IIS app pools, and Scheduled Tasks
• Anything that requires a password typed into a config file won't work
• SQL Server 2014+ supports it. Exchange on-prem has limited support so check before migrating
• Scheduled tasks need to be configured via schtasks from the command line, not the GUI

For detection while you're still migrating: enable Audit Kerberos Service Ticket Operations on your DCs and watch for Event ID 4769 with Ticket Encryption Type 0x17. In a modern environment almost everything should be AES. RC4 requests against accounts with SPNs are Kerberoast traffic.

auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable

If you're on Defender for Identity, alert ID 2410 covers this.

Thirty minutes per service to migrate. Free and no reboot required :)

Worth doing before someone else finds your service accounts first.