What changed in practice since April 2026

Kerberos RC4 hardening is no longer an abstract cryptography topic. Since the April 2026 Windows security updates, Domain Controllers changed default behavior for accounts where no explicit msDS-SupportedEncryptionTypes value is configured: the KDC no longer treats RC4 as a silent compatibility fallback and moves toward AES-SHA1 for default ticket behavior.

In clean environments, this is uneventful. In mature AD estates, it can hit exactly the systems nobody has looked at for years: old service accounts with SPNs, technical accounts for third-party applications, appliances, Java/Linux stacks, old IIS/SQL/middleware integrations, or domains with inherited GPO and registry exceptions.

The risk has two sides:

  • Security risk: RC4-based Kerberos service tickets are an unnecessarily weak target for offline attacks against service account passwords.
  • Operational risk: if an application effectively only supports RC4, moving to AES can cause authentication failures.

The right response is not “set a registry key and move on”. The right response is controlled removal of RC4 dependencies.

Systems that should be on the list first

Prioritize by Kerberos relevance, not gut feeling:

  1. Service accounts with SPNs: the primary candidates for Kerberos service tickets and therefore RC4 exposure.
  2. Accounts without msDS-SupportedEncryptionTypes: this is where the new defaults become especially visible.
  3. Accounts configured as RC4-only or DES/RC4-heavy: usually technical and organizational legacy.
  4. Legacy applications and appliances: often not obvious from normal Windows operations.
  5. Domains with manually set DefaultDomainSupportedEncTypes: the intent, safety, and documentation need to be clear.

A configured value is not automatically a good value. What matters is whether AES128/AES256 are supported and whether RC4 is still genuinely required.

Read-only checks you can run now

Start with an inventory of service accounts with SPNs and their encryption type configuration:

Get-ADUser -LDAPFilter '(servicePrincipalName=*)' `
  -Properties servicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet |
  Select-Object SamAccountName, Enabled, PasswordLastSet, msDS-SupportedEncryptionTypes, servicePrincipalName

For computer- or gMSA-based services:

Get-ADServiceAccount -Filter * -Properties msDS-SupportedEncryptionTypes, PrincipalsAllowedToRetrieveManagedPassword |
  Select-Object Name, Enabled, msDS-SupportedEncryptionTypes, PrincipalsAllowedToRetrieveManagedPassword

On Domain Controllers, review Kerberos/KDC events in parallel. The output you want is not a log screenshot, but a working list with:

  • account / SPN
  • client system
  • requested encryption type
  • warning or failure pattern
  • responsible application owner
  • planned remediation

If you already have a SIEM, this is a good temporary dashboard: top accounts with RC4 usage, top clients with Kerberos errors, daily trend after DC patching.

Target state for remediation

A clean target state looks like this:

  • Service accounts support AES128 and AES256.
  • RC4 is no longer an implicit fallback for “unknown” accounts.
  • Service account passwords were rotated after encryption type changes where required.
  • gMSA is preferred for suitable Windows services.
  • Exceptions are time-bound, owned, and risk-accepted.

The key project detail: encryption types and password material are connected. If an account historically only used RC4, changing an attribute may not be enough in every case. Plan password rotation, service restarts, and application testing.

Rollout without surprises

A defensible sequence:

  1. Confirm DC patch state: which Domain Controllers have January/April 2026 updates? Are any sites lagging?
  2. Collect audit data: cover multiple business cycles, not just one quiet hour.
  3. Classify SPN accounts: business-critical, technically unclear, clearly modern, clearly legacy.
  4. Pick a pilot group: a few well-owned applications with reachable owners.
  5. Enable and test AES: start controlled, then expand.
  6. Rotate passwords: especially for privileged or long-lived service accounts.
  7. Monitor after change: correlate Kerberos errors, helpdesk tickets, and application logs.

In larger environments, use a change window per application cluster rather than one global “Kerberos day”. Kerberos issues often look like application, DNS, time sync, or SPN problems at first glance. Without owners and tests, troubleshooting becomes unnecessarily expensive.

What should not become the permanent plan

Temporary compatibility controls can help stabilize a rollout, but they are not remediation. Be careful with:

  • allowing RC4 broadly again as the default
  • mass-setting msDS-SupportedEncryptionTypes without account context
  • leaving service accounts running without password rotation
  • documenting exceptions without expiry dates
  • judging non-Windows systems only from AD attributes without real authentication tests

The absence of warning events is not a full guarantee either. Some non-Windows and appliance scenarios only fail during the actual ticket flow.

Benefits of the change

  • Reduces Kerberoasting exposure by removing RC4-based service tickets from the environment.
  • Forces service account hygiene, including SPN inventory and password rotation.
  • Improves operational ownership, because applications, SPNs, and technical accounts get mapped again.
  • Prepares for the July 2026 phase, where temporary audit/rollback behavior becomes less relevant.

Downsides and limits

  • Legacy breakpoints are real: old appliances, middleware, or third-party products may not handle AES cleanly.
  • Attribute changes are not enough: without testing, password rotation, and service restarts, the real state can stay unclear.
  • Monitoring is distributed: DC events, application logs, SIEM, and helpdesk data need to be reviewed together.
  • Exceptions remain attack surface: every RC4-dependent account is an explicitly accepted risk.

Project checklist

  • [ ] All Domain Controllers checked for patch state and Kerberos hardening phase.
  • [ ] SPN accounts, gMSAs, and technical users inventoried.
  • [ ] msDS-SupportedEncryptionTypes grouped as “missing”, “AES-capable”, “RC4-only”, and “unclear”.
  • [ ] Kerberos/KDC events collected centrally and reviewed by account, client, and SPN.
  • [ ] Application owners assigned for critical service accounts.
  • [ ] Pilot cutover completed with rollback plan and monitoring.
  • [ ] Password rotation for affected service accounts planned or completed.
  • [ ] Temporary RC4 exceptions documented with expiry dates.
  • [ ] July 2026 readiness tracked as its own AD-hardening backlog milestone.