How to find and retire Active Directory service accounts with SPNs: Shrink your Kerberoasting surface one account at a time

Every user account with a service principal name (SPN) lets any domain user request a Kerberos service ticket encrypted with that account's password, and old service accounts are where the weak, never-rotated passwords live. Removing the accounts and SPNs you no longer need is the cheapest Kerberoasting defence there is, and Microsoft's own guidance says SPNs should be removed from accounts where they are not needed. This guide is the procedure: find every user account with an SPN, prove which are still used, retire the rest through a staged disable, and harden what remains. It is for Active Directory administrators and identity security teams. The attack itself and its detection are covered in the Kerberoasting and AS-REP Roasting Defence Guide.

Key takeaways

• User accounts with SPNs are the target. Computer accounts and managed service accounts have long random passwords; user accounts configured by hand often do not.
• Prove use with ticket logs, not guesses. Event 4769 on domain controllers records each service ticket request with the service name, so you can see whether anything still asks for a ticket to the account.
• Retire in stages. Remove the SPN or disable the account, wait through a full business cycle, then delete. Deletion is the only step that is hard to undo.
• What stays should become managed. Microsoft recommends gMSA or dMSA wherever possible; gMSA passwords are 120 characters and rotated automatically.
• Fix encryption on survivors. Microsoft recommends AES for all service accounts and disabling RC4 on them, then changing the password so AES keys exist.

When you need this

• A penetration test or Defender for Identity alert reports Kerberoastable accounts. Microsoft lists Defender XDR alert external ID 2410 for suspected Kerberos SPN exposure.
• An Active Directory clean-up before a migration, a merger or a tiering project.
• After a domain compromise, as part of reducing what an attacker could reuse; see the Active Directory Domain Compromise Response Playbook.
• Any time nobody can say who owns an account. The Colonial Pipeline attack began with a legacy account that had fallen out of use but was never disabled; dormant service accounts carry the same risk with less scrutiny.

Before you start

1. Tools: the ActiveDirectory PowerShell module and setspn on an admin workstation, read access to the domain, and access to domain controller Security logs or your SIEM.
2. Audit policy: confirm Kerberos service ticket auditing is on so event 4769 is being generated on every domain controller. Without it you cannot prove an account is unused.
3. Change control: agree a staged retirement schedule and a named approver. Owners of line-of-business applications must be reachable during the disable window.
4. Baseline export: you will export every SPN account's attributes before changes, so rollback is a copy, not a memory.

Step-by-step

Steps 1 to 4 are read-only. Steps 5 to 7 change the directory: 5 and 6 are reversible, 7 is not without recycle bin or backup.

1. Find user accounts with SPNs. Use Get-ADUser -LDAPFilter '(servicePrincipalName=*)' -Properties servicePrincipalName,Description,LastLogonDate,PasswordLastSet,Enabled,msDS-SupportedEncryptionTypes and export the result to CSV. Exclude krbtgt, which carries an SPN by design. setspn -L <accountname> lists the SPNs on a single account, and setspn -T contoso -F -Q */MyServer searches the forest for SPNs on a given host.
2. Find duplicates. setspn -T * -T contoso -X reports duplicate SPNs. Microsoft notes duplicates cause authentication problems; they are also a sign that an SPN was copied to a new account and the old one forgotten.
3. Classify each account. Use the table below. Mark accounts that are disabled but still hold SPNs, accounts whose password has not changed in years, accounts allowing RC4, and accounts that are members of privileged groups. Privileged plus SPN plus old password is the top of the list.
4. Prove use from ticket logs. Search event 4769 across all domain controllers for 30 to 90 days, filtering on Service Name equal to each account. No requests means nothing has asked to authenticate to that service. Also check the account's own logons (the hosts where it runs as a service or scheduled task), because an account can be used to run something without anyone requesting a ticket to it. Record the Client Address values: they tell you which hosts depend on it.
5. Remove unneeded SPNs (reversible). Where the account is still used to run something but the SPN is not needed, remove only the SPN: Set-ADUser <account> -ServicePrincipalNames @{Remove="MSSQLSvc/host.contoso.com:1433"}, or setspn -D <SPN> <account>. Removing the SPN removes it from Kerberoasting scope.
6. Disable unused accounts (reversible). Set-ADUser <account> -Enabled $false -Description "Disabled <date> ticket CHG-1234, retire after <date>", and move it to a quarantine OU. Leave it disabled for at least one full business cycle, including month-end and any quarterly jobs.
7. Delete after the quiet period (destructive). If nothing broke and no 4769 events or logon failures referenced the account during the window, delete it. Confirm the AD Recycle Bin is enabled first.

Small and large estates: a single domain with a few dozen SPN accounts can be reviewed by hand in a week, account by account, with owners on a call. A multi-domain forest with hundreds of SPN accounts needs the work split by risk: first privileged SPN accounts and those allowing RC4, then accounts with no ticket requests in 90 days, then everything else. Feed the 4769 analysis from your SIEM rather than querying domain controller logs one at a time, and publish the disable schedule so application teams can object before the change rather than after it. In both cases, keep the baseline export from step 1 with the change record: it is your rollback and your audit evidence.

Verify it worked

• Re-run step 1: the count of enabled user accounts with SPNs falls, and no retired account remains.
• Watch 4769 and logon failures for the disabled accounts during the quiet period. A request to a disabled account's SPN means something still depends on it.
• Check encryption on survivors: 4769 events for remaining service accounts should show Ticket Encryption Type 0x11 or 0x12 (AES). Microsoft's monitoring guidance treats anything else on modern systems as unexpected, and 0x17 is RC4.

Rollback and common errors

• Rollback of a disable: Set-ADUser <account> -Enabled $true and move it back to its original OU. Because the password did not change, services resume.
• Rollback of an SPN removal: re-add from the baseline with setspn -S <SPN> <account>; Microsoft recommends -S over -A because it checks for duplicates first.
• Trusting LastLogonDate alone: it is replicated lazily and is only approximate; combine it with 4769 and service logon evidence.
• Looking only at the directory: an account can be configured as the logon identity for a Windows service, a scheduled task, an IIS application pool or a SQL Server agent on hosts nobody remembers. Before disabling, check the Client Address values from 4769 and the hosts where the account logs on, and ask those host owners directly. A disabled account that a service still uses fails at the next restart, which may be weeks later, so keep the quarantine description clear enough for an on-call engineer to find the change ticket.
• Deleting too early: if the AD Recycle Bin is not enabled, a deleted account and its group memberships can only be restored from backup. Enable it before step 7.
• Missing quarterly jobs: a 30-day window misses month-end and year-end processes. Use 90 days for anything finance-related.
• Breaking AES by setting it without a password change: Microsoft notes that after changing the encryption type the password must be changed so AES keys are generated. Set-ADUser -KerberosEncryptionType AES128,AES256 alone is not enough, and Microsoft warns that some systems, such as clustering, manage msDS-SupportedEncryptionTypes themselves.

Hardening afterwards

• Convert survivors to gMSA or dMSA; see How to convert AD service accounts to gMSA and the Group Managed Service Accounts (gMSA) Guide.
• For accounts that must stay manual: long, randomly generated passwords (Microsoft's floor is 14 characters, with longer random passwords recommended), AES only, no privileged group membership, and an owner and review date in the description or your inventory.
• Alert on new SPNs on user accounts and on bursts of 4769 requests from one client for many service accounts, a Kerberoasting pattern Microsoft calls out.
• Allow-list client addresses: Microsoft's 4769 guidance suggests alerting when a service account's tickets are requested from hosts outside a known list.

Where identity fits: SPN accounts are some of the oldest non-human identities in most estates. Put them in the same inventory as cloud workload identities, with owner, host, purpose and last-proven-use date, so retirement is a routine lifecycle step rather than a one-off clean-up. See the Windows Services and Service Account Security Guide.

Measure it: enabled user accounts with SPNs (trend down), SPN accounts in privileged groups (target zero), SPN accounts allowing RC4, SPN accounts with passwords older than one year, percentage converted to gMSA or dMSA, and accounts with a named owner.

Practitioner checklist

• Export every user account with an SPN and its key attributes as a baseline
• Check for duplicate SPNs with setspn -X
• Prove use from event 4769 and service logons over 30 to 90 days
• Remove SPNs that are not needed
• Disable unused accounts and leave them disabled for a full business cycle
• Delete only after the quiet period and with the AD Recycle Bin enabled
• Convert remaining accounts to gMSA or dMSA, or set long random passwords and AES only

Standards and references

• Microsoft Security Blog: Microsoft's guidance to help mitigate Kerberoasting
• Microsoft Learn: setspn
• Microsoft Learn: Get-ADUser
• Microsoft Learn: Set-ADUser
• Microsoft Learn: 4769 A Kerberos service ticket was requested
• MITRE ATT&CK: T1558.003 Kerberoasting
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Kerberoasting and AS-REP Roasting Defence Guide · Windows Services and Service Account Security Guide · How to convert AD service accounts to gMSA · Active Directory and Entra ID Hardening Guide