Starting point: the ticket is normal; the weak service secret is the risk

Kerberoasting uses a normal property of Kerberos. An authenticated domain user can request a service ticket for a service that has a registered Service Principal Name, or SPN. Part of that ticket is protected with key material belonging to the service account. The request itself is therefore neither an administrative operation nor proof of an attack.

The risk appears offline. If the service account password is short, predictable, reused or unchanged for years, the ticket provides verifiable material for password guesses. Domain Controllers cannot see this offline verification. An ordinary user account with network connectivity can therefore be enough to make a weak service account a target.

Several unfavorable properties commonly converge in established AD environments:

  • standard user objects are used as service identities,
  • Password never expires substitutes for a real rotation process,
  • one account runs several applications or environments,
  • SPNs remain on the old account after migrations,
  • service accounts have excessive local or domain privileges,
  • interactive and RDP logon remain permitted,
  • RC4 was explicitly allowed for individual accounts or the KDC,
  • nobody can name the owner, target systems or outage impact.

Since the July 2026 Windows security updates, fully updated Domain Controllers no longer evaluate the former rollback switch for service-ticket issuance. If the target account has no explicit msDS-SupportedEncryptionTypes value and the DC has no explicit DefaultDomainSupportedEncTypes value, the KDC uses AES-SHA1 by default. If suitable AES keys are missing or the client does not offer AES, the request is blocked. Explicit account and DC configurations remain effective. This removes an important legacy weakness, but it does not eliminate Kerberoasting. Mixed DC patch levels can produce different results, and an AES-protected ticket can still be tested offline when the password is weak.

Kerberoasting is therefore not merely a cryptography problem. It is primarily a service-account, privilege and operating-model problem.

Target state: every service has a managed, constrained identity

A defensible target state can be tested concretely:

  1. Every production SPN has an owner. The application, service, hosts, environment, accountable people and recovery procedure are documented.
  2. One service purpose uses one identity. Accounts are not shared between production, test, scheduled tasks and unrelated applications.
  3. gMSA is the preferred standard. Supported Windows services and server farms use automatically managed, high-entropy secrets.
  4. Legacy accounts have long random secrets and a real rotation process. Secret storage, change, distribution, testing and recovery are automated or at least documented reliably.
  5. SPNs are unique and current. Orphaned and duplicate entries are removed after dependency validation; rights to write SPNs are tightly delegated.
  6. Service identities are no more privileged than their function requires. There are no blanket administrator groups, unnecessary directory rights or uncontrolled delegation.
  7. Logon is constrained by purpose and host. Only required service or batch rights exist on intended systems; local and RDP logon are denied where compatible.
  8. AES is evidenced and RC4 is a time-boxed exception. Actual ticket issuance and current KDC events matter, not only an account attribute.
  9. Kerberos tickets are monitored centrally. Event 4769 and current KDC service events are evaluated against a dependable normal baseline.
  10. New service accounts pass an approval process. Ownership, gMSA suitability, SPNs, privileges, target hosts, rotation, monitoring and retirement are resolved before production use.

The objective is not to prevent service tickets. Kerberos requires them. The objective is to ensure that a requested ticket is not an economically useful target for offline password attacks and that a compromised service account can cause only tightly bounded damage.

Implementation: move from an SPN inventory to controlled service operations

1) Inventory user accounts with SPNs read-only

Start with accounts that are represented as normal AD user objects and carry at least one SPN. This is where manually managed service passwords are often found. The following query makes no changes:

Set-StrictMode -Version Latest
Import-Module ActiveDirectory -ErrorAction Stop

$properties = @(
  'Description'
  'Enabled'
  'LastLogonDate'
  'MemberOf'
  'msDS-SupportedEncryptionTypes'
  'PasswordLastSet'
  'PasswordNeverExpires'
  'ServicePrincipalName'
)

Get-ADUser `
  -LDAPFilter '(&(objectCategory=person)(objectClass=user)(servicePrincipalName=*))' `
  -Properties $properties |
  Select-Object `
    SamAccountName,
    Enabled,
    PasswordLastSet,
    PasswordNeverExpires,
    LastLogonDate,
    @{Name = 'SpnCount'; Expression = { @($_.ServicePrincipalName).Count }},
    @{Name = 'Spns'; Expression = { $_.ServicePrincipalName -join '; ' }},
    @{Name = 'SupportedEncryptionTypes'; Expression = {
      $_.'msDS-SupportedEncryptionTypes'
    }},
    @{Name = 'DirectGroupCount'; Expression = { @($_.MemberOf).Count }},
    Description,
    DistinguishedName |
  Sort-Object PasswordLastSet, SamAccountName

The output is a starting point, not a complete risk assessment. LastLogonDate is delayed and proves neither active service use nor inactivity. MemberOf contains only direct memberships; nested groups, delegated ACLs and local rights must be resolved separately. An empty msDS-SupportedEncryptionTypes value does not automatically mean that RC4 is currently used. The decisive evidence is what the KDC actually issues under the applicable patch and policy state.

Extend the user inventory to include gMSAs, sMSAs, computer objects with application-specific SPNs and non-Windows Kerberos principals. Assess these classes separately. gMSA and computer passwords normally have different entropy and rotation properties from manually maintained user passwords. For gMSAs, overly broad managed-password retrieval rights are a separate risk. Incorrect SPNs and excessive privileges can make either account class unsafe.

2) Join ownership, services and dependencies

An SPN alone does not show whether an account is still required. Link directory data with actual operations:

  • Windows services, IIS application pools and scheduled tasks,
  • databases, backup, monitoring and middleware components,
  • cluster and farm nodes,
  • non-Windows applications and appliances,
  • secret-vault or deployment entries,
  • service tickets issued by Domain Controllers,
  • change, CMDB and ownership data.

For every account, record at least the service name, business and technical owner, production hosts, SPNs, required privileges, start type, restart order, maintenance window and recovery procedure. If nobody can provide these facts, the account is not automatically orphaned. It is first an uncontrolled operational risk.

Check duplicate SPNs across the forest and resolve every result before changing it. An SPN must map to only one security principal. Blind deletion or movement can cause Kerberos failures and KRB_AP_ERR_MODIFIED. Remove apparently orphaned SPNs only when telemetry, ownership and application testing agree.

3) Prioritize by impact, not password age alone

Not every SPN account carries the same risk. A defensible prioritization includes at least:

  • privileged and nested group memberships,
  • direct rights over OUs, GPOs, servers, databases, backup or virtualization platforms,
  • Password never expires, high password age or an unknown password source,
  • multiple SPNs, applications or environments on one identity,
  • explicit RC4 support or observed RC4 tickets,
  • unconstrained delegation or another broad delegation setting,
  • allowed local, RDP, batch and service logon,
  • access to Tier 0 systems or particularly sensitive data,
  • missing ownership, unclear use or inadequate telemetry.

A weak account without special privileges matters. A weak account with an SPN, backup rights and access to Domain Controllers is a different project case. Address accounts where secret quality and potential impact are both poor first.

4) Migrate suitable services to gMSA

Group Managed Service Accounts are the cleanest target state for many Windows services. Active Directory creates a long random secret and rotates it automatically by default. The service no longer needs a static password from a configuration file, script or manual handoff.

The migration still needs planning:

  1. Confirm that the product and service type support gMSA and that the vendor supports its use in the intended cluster or farm model.
  2. Ensure that the KDS root key is correctly available and replicated in the forest.
  3. Use a separate gMSA for each clearly bounded service purpose.
  4. Plan only the required SPNs for the new account and prove uniqueness before cutover.
  5. Permit managed-password retrieval only to a dedicated group containing the computer objects that actually require it.
  6. Run Test-ADServiceAccount on every intended node.
  7. Switch the service and required SPNs in a pilot window and test startup, failover, Kerberos, access and password rollover.
  8. After a defined observation period, remove remaining legacy privileges and disable the predecessor account.

Using a broad group such as Domain Computers in PrincipalsAllowedToRetrieveManagedPassword undermines host binding. The principals that can retrieve the gMSA secret are part of the trust boundary and need the same scrutiny as the account privileges.

gMSA is not a privilege filter either. An automatically rotated account in a highly privileged group remains highly privileged. Rotation protects the secret; least privilege limits the impact.

5) Operate non-migratable accounts with long random secrets

Legacy products, non-Windows services or vendor constraints can prevent gMSA use. In that case, each service account needs a unique, cryptographically random secret at the longest reliably supported length. In practice, 32 or 64 or more random characters are a reasonable starting point if the application, protocol and deployment path preserve the entire value.

The password process must do more than store a value in a vault:

  • generation through a cryptographically secure random-number generator,
  • no reuse between services, environments or emergency accounts,
  • access only by the automated distribution path and tightly limited operators,
  • atomic or coordinated update of all service nodes,
  • functional validation with a newly issued ticket,
  • controlled restart and documented rollback,
  • rotation on a fixed, technically proven interval and immediately after suspected disclosure,
  • monitoring for outdated deployments and failed logons.

Password never expires can prevent an uncoordinated expiration from stopping an application. It must not mean that the password is never changed. If AD expiration is not used, a separate, evidenced rotation process must take over.

6) Evidence AES and retire RC4 exceptions

Since the July 2026 updates, RC4DefaultDisablementPhase is no longer evaluated on updated Domain Controllers. If the target account has no explicit msDS-SupportedEncryptionTypes value and the DC has no explicit DefaultDomainSupportedEncTypes value, the KDC uses AES-SHA1, bitmask 0x18, by default for service-ticket selection. If suitable AES keys are missing or the client does not offer AES, the request is blocked. Explicit account and DC configurations remain effective.

Three checks are still required:

  • Are all Domain Controllers actually on a July 2026 or later update and restarted?
  • Does a service account still allow RC4 explicitly through msDS-SupportedEncryptionTypes?
  • Was DefaultDomainSupportedEncTypes overridden unsafely on a DC?

When AES is newly enabled for an old account, rotate the password afterwards. This creates the required AES key material if the password predates AES support. Then test the application with fresh tickets and examine KDC events. Setting checkboxes or attributes alone is not evidence of effective use.

Do not confuse two different values. In the account attribute, 0x18 means AES128 plus AES256. In the Ticket Encryption Type field of event 4769, 0x11 means AES128, 0x12 means AES256 and 0x17 means RC4-HMAC. In that event field, 0x18 identifies RC4-HMAC-EXP and is not evidence of AES.

AES increases the cost of offline password testing, but it does not make a human-chosen service password strong. The order remains: a managed or long random secret, least privilege, AES and monitoring.

7) Constrain privileges and logon paths per service

For every account, make the consequences of compromise visible. Remove blanket membership in local Administrators, Server Operators, Backup Operators, Domain Admins and similar groups unless a documented technical requirement exists. Replace broad group privileges with explicit file, database, service or API permissions.

Grant Log on as a service or Log on as a batch job only on intended hosts and only when the workload needs it. Deny interactive and RDP logon for pure service identities after application testing. Do not deny network logon indiscriminately; many services need it for back-end access. User-right assignments have broad effects and belong in role-specific GPOs, not a global list without a dependency model.

Do not add service or computer accounts to Protected Users: all incoming authentication to a service account can fail. For supported managed service accounts, use piloted Authentication Policies and silos instead when stronger host binding is required.

8) Monitor ticket use and account changes centrally

Enable the advanced audit policy Audit Kerberos Service Ticket Operations for at least successful operations on Domain Controllers and collect event 4769 centrally. The volume is high; forwarding it without capacity planning and a detection model creates cost but little protection.

A useful baseline connects the requester, Client Address, target SPN, service account, ticket encryption, time and frequency. Relevant deviations include:

  • one client requests tickets for many different SPNs in a short period,
  • an ordinary user or unusual source host requests a ticket for a particularly valuable service,
  • a long-unused SPN receives tickets again,
  • tickets for the old account continue after migration,
  • Ticket Encryption Type remains 0x17 despite the target state,
  • service-ticket failures rise after an AES or account migration,
  • SPNs or relevant encryption attributes change outside an approved change.

Do not filter only for RC4. Kerberoasting remains possible with AES, and after the July 2026 hardening an RC4-only rule would be blind to most of the estate. Parse XML field names instead of fixed property positions because newer updates extended the 4769 schema.

Monitor SPNs and msDS-SupportedEncryptionTypes separately through directory-change auditing or the change feed of the identity-management platform. Event 5136 can record the changed attribute on Domain Controllers when Audit Directory Service Changes is enabled and an appropriate SACL applies to the affected objects. Pilot the SACL and data volume first; without those prerequisites, the absence of 5136 does not prove that the configuration remained unchanged.

On updated Domain Controllers, also collect KDC service system events in the 201 through 209 range. Enforcement events 203 and 208 identify RC4-only clients; 204 and 209 identify missing AES keys on the service account. Event 205 identifies an explicitly unsafe domain default. Continue collecting the full range where patch levels are mixed. Their absence does not prove that every non-Windows integration is compatible. Real application testing remains necessary.

Defender for Identity or a comparable identity threat-detection system can add detection for unusual SPN discovery and ticket patterns. It replaces neither the service-account inventory nor central KDC telemetry.

9) Pilot per service and retire the legacy path deliberately

Do not make a forest-wide password rotation the first action. Build rollout rings by application criticality and technical similarity:

  1. a documented, noncritical Windows service,
  2. a representative multinode application,
  3. scheduled tasks and batch processing,
  4. database, backup and middleware services,
  5. business-critical and Tier-0-adjacent identities.

Every change validates service startup, authentication, back-end access, failover, ticket type, logs, monitoring and recovery. Ticket caches can temporarily conceal the old state, so test with newly issued tickets and after the intended restart.

Keep the predecessor account documented and recoverable only during the defined rollback window; do not continue using it for normal operations in parallel. Then remove remaining SPNs and privileges, keep the account disabled and delete it after the retention period. A predecessor account left permanently active is not rollback; it is a second attack path.

Advantages

  • Offline password attacks become economically unattractive: gMSAs and long random secrets remove the basis for dictionary and pattern attacks.
  • Potential impact falls: unique identities and least privilege contain an incident to one service purpose.
  • Password changes become operationally manageable: automatic or tested rotation replaces static secrets that persist for years.
  • SPN hygiene improves Kerberos overall: unique mapping reduces misconfiguration and opaque authentication failures.
  • AES dependencies become measurable: actual ticket types and KDC events show the state rather than only desired configuration.
  • Operations gain ownership: applications, accounts, hosts, privileges and recovery are joined consistently.
  • Detection becomes more targeted: a known ticket baseline reveals unusual sources and mass requests.
  • Retirement becomes possible: orphaned accounts and SPNs can be removed with evidence rather than assumptions.

Disadvantages and limits

  • Inventory work is substantial: AD attributes alone provide neither ownership nor complete application dependencies.
  • Not every application supports gMSA: legacy products, appliances and certain deployment models need a different secure secret process.
  • Rotation can cause outages: nodes, tasks, pools or configuration files that were not updated continue using the old secret.
  • AES does not eliminate Kerberoasting: weak passwords remain testable offline; the cost rises, but the mechanism remains.
  • Event 4769 has very high volume: storage, normalization and detection logic require planning.
  • Least privilege can uncover hidden dependencies: broad historical rights often enabled undocumented secondary functions.
  • SPN changes are operationally sensitive: incorrect removal or movement can immediately disrupt Kerberos.
  • gMSA has its own trust boundary: overly broad managed-password retrieval rights substantially weaken the benefit.
  • Mixed DC patch levels complicate evidence: service tickets can be treated differently depending on the KDC contacted.
  • Detection is not prevention: an alert for suspicious ticket patterns does not retroactively protect a weak service password.

Typical pitfalls

  • Searching only for Password never expires: accounts without the flag can still have stale or weak secrets.
  • Automatically deleting every user with an SPN: an apparently inactive account can run a critical service.
  • Treating LastLogonDate as proof of use: the value is delayed and does not reliably represent service tickets by itself.
  • Reviewing only direct group memberships: nested groups and delegated ACLs often determine the real impact.
  • Allowing Domain Computers to retrieve a gMSA password: this makes the intended host binding unnecessarily broad.
  • Leaving the old account enabled after migration: its SPNs, privileges and static secret remain a second path.
  • Selecting AES checkboxes without rotating the password: the account may still lack the required AES key material.
  • Confusing the attribute bitmask with the ticket etype: 0x18 has a different meaning in the two contexts.
  • Treating July 2026 as a complete RC4 ban: explicit exceptions, unsafe defaults and unpatched DCs still require review.
  • Alerting only on RC4 tickets: AES tickets can also matter when passwords are weak.
  • Parsing event fields by position: updates extended the schema, and fixed indexes can fail silently.
  • Moving service or computer accounts into Protected Users: all incoming authentication to a service account can fail.
  • Denying network logon globally: back-end, file or database access can fail as a result.
  • Changing passwords without restart and cache validation: old tickets or running processes can conceal an incomplete migration.
  • Using a global RC4 rollback as recovery: the old rollback path is removed on updated DCs after July 2026 and was never a secure target state.
  • Maintaining ownership only as free text: without mandatory review after personnel, product or system changes, the mapping quickly becomes stale.

Project checklist

  • [ ] Inventory all user accounts with SPNs read-only.
  • [ ] Record gMSAs, sMSAs, computer objects and non-Windows principals separately.
  • [ ] Check duplicate SPNs forest-wide and assign an owner.
  • [ ] Resolve duplicate SPNs after ownership and dependency validation, then prove uniqueness.
  • [ ] Document application, hosts, environment, start type and recovery for every service identity.
  • [ ] Assign business and technical owners with a review date.
  • [ ] Evaluate nested groups, direct ACLs and local rights.
  • [ ] Review delegation configuration and Tier 0 access.
  • [ ] Prioritize accounts by secret quality and potential impact.
  • [ ] Verify gMSA support with the vendor and the actual service type.
  • [ ] Check KDS root key and replication before gMSA rollout.
  • [ ] Restrict PrincipalsAllowedToRetrieveManagedPassword to a dedicated target-host group.
  • [ ] Register SPNs uniquely on the target account.
  • [ ] Test the gMSA on every intended node.
  • [ ] Generate long random secrets in a vault for accounts that cannot be migrated.
  • [ ] Prove rotation, distribution, restart, testing and rollback technically.
  • [ ] Separate secrets between services and environments.
  • [ ] Remove unnecessary privileged groups and directory rights.
  • [ ] Limit service and batch logon to required hosts.
  • [ ] Deny interactive and RDP logon after compatibility testing.
  • [ ] Update all Domain Controllers to July 2026 or later and restart them.
  • [ ] Review explicit RC4 bits on service accounts and unsafe KDC defaults.
  • [ ] Rotate old account passwords after enabling AES.
  • [ ] Collect event 4769 centrally and normalize it by XML field name.
  • [ ] Build a baseline for requester, source host, target SPN, ticket type and frequency.
  • [ ] Add KDC service events 201 through 209 to monitoring.
  • [ ] Ensure alerting is not limited to RC4.
  • [ ] Monitor SPN and encryption changes outside approved changes.
  • [ ] Test each service migration with fresh tickets, failover and back-end access.
  • [ ] Remove old SPNs and privileges after the observation period.
  • [ ] Disable predecessor accounts and schedule controlled deletion.
  • [ ] Document time-boxed exceptions with owner, compensating controls, expiry and migration plan.
  • [ ] Schedule a quarterly service-account and SPN review.