Kerberos RC4 Hardening Phase 2 (April 2026) Breaking Authentication — Service Accounts and Legacy Applications
Microsoft's April 2026 Kerberos RC4 hardening Phase 2 enforces AES-only Kerberos ticket encryption on domain-joined Windows clients and Server Domain Controllers, rejecting RC4-HMAC by default. Service accounts, computer accounts, and legacy applications whose msDS-SupportedEncryptionTypes attribute does not include AES128 (value 8) or AES256 (value 16) — or which hard-code RC4-HMAC negotiation — will fail Kerberos authentication after the April 2026 cumulative updates are applied. Resolution requires auditing all account encryption type attributes in AD and updating them to include AES, updating GPO Kerberos encryption policy, and coordinating with application vendors for any hard-coded RC4 dependencies. Environments that have not proactively reviewed account encryption settings ahead of the enforcement date are at highest risk.
Indicators
- Authentication failures for domain users or services on domain-joined Windows clients after April 2026 Windows updates are applied — onset correlates directly with update installation date
- Service accounts fail to obtain Kerberos tickets, resulting in application login errors or service startup failures immediately after April 2026 update rollout
- Legacy applications that previously authenticated successfully begin failing with Kerberos-related errors after the April 2026 update phase
- Domain Controller Security event log: Event ID 4769 (Kerberos Service Ticket Operations) with failure codes indicating unsupported or rejected encryption types
- Domain Controller Kerberos operational log entries referencing RC4 or unsupported encryption type rejections
Likely causes
- Service accounts or computer accounts have msDS-SupportedEncryptionTypes set to RC4-HMAC only (decimal value 4 / 0x4) and do not advertise AES128 (8) or AES256 (16) support — these accounts cannot obtain Kerberos tickets under Phase 2 enforcement
- Legacy applications hard-coded to negotiate RC4-HMAC Kerberos encryption are incompatible with the enforced AES-only policy and cannot fall back gracefully
- Account encryption settings across the estate were not reviewed or updated prior to the April 2026 enforcement deadline
- Kerberos encryption GPO under 'Network security: Configure encryption types allowed for Kerberos' is either not set, or explicitly includes only RC4-HMAC, conflicting with Phase 2 hardening behaviour
Diagnostic steps
-
On each Domain Controller, open Event Viewer and review the Security log filtered to Event ID 4769. Look for Kerberos service ticket failures with error code 0x27 (KDC_ERR_ETYPE_NOSUPP) or other encryption-type-related codes. Also check Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational log for RC4 rejection events. Note which accounts and services appear in failing events.Confirms that Kerberos RC4 hardening Phase 2 enforcement is actively causing authentication failures and identifies which specific accounts and services are affected.
-
Enumerate all service accounts and computer accounts and check their msDS-SupportedEncryptionTypes attribute. Run in PowerShell: Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes,ServicePrincipalName | Where-Object {$_.ServicePrincipalName -ne $null} | Select-Object Name,msDS-SupportedEncryptionTypes,ServicePrincipalName | Export-Csv C:\Temp\ServiceAccountEnc.csv -NoTypeInformation — then review for accounts showing value 4 (RC4 only) or 0 (not set, which may default to RC4). Run the equivalent against computer accounts: Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes | Select-Object Name,msDS-SupportedEncryptionTypes | Export-Csv C:\Temp\ComputerAccountEnc.csv -NoTypeInformationIdentifies all accounts that will fail Kerberos authentication under Phase 2 enforcement because they do not advertise AES encryption support.
-
For each legacy application identified in the inventory, confirm whether it supports AES128 or AES256 Kerberos encryption by reviewing vendor documentation or testing in a non-production environment. Check application-level configuration files or Kerberos configuration (e.g., krb5.conf equivalents, Java security settings, or GSSAPI configs) for hard-coded RC4 (arcfour, rc4-hmac) cipher references.Determines whether authentication failures stem from application-level RC4 hard-coding rather than account attribute misconfiguration — the two require different remediation paths (vendor update vs. attribute change).
-
Open Group Policy Management Console (gpmc.msc). Review GPOs applied to DCs and clients under: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > 'Network security: Configure encryption types allowed for Kerberos'. Note which encryption types are currently permitted or blocked. If RC4-HMAC is the only type permitted, or if the setting is 'Not Configured' (which in Phase 2 may default to AES-only), this is a contributing factor.Confirms whether Group Policy is enforcing or restricting Kerberos encryption types in a way that conflicts with Phase 2 hardening, and identifies whether policy needs to be updated.
-
Correlate the April 2026 cumulative update installation timestamps on DCs and clients (Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10) against the first observed authentication failure timestamps from the event logs and help desk tickets.Confirms causation between the Microsoft April 2026 Kerberos RC4 hardening Phase 2 update deployment and the observed authentication failures, ruling out other concurrent changes as root cause.
Resolution path
- 1. For all service accounts identified as RC4-only (msDS-SupportedEncryptionTypes = 4 or 0): update to include AES — Set-ADUser -Identity <ServiceAccountName> -KerberosEncryptionType AES128,AES256. If legacy applications cannot yet support AES, use AES128,AES256,RC4 (value 28 / 0x1C) as a strictly interim measure to restore service while the vendor remediation is underway.
- 2. For all computer accounts identified as RC4-only: Set-ADComputer -Identity <ComputerName> -KerberosEncryptionType AES128,AES256. Allow AD replication to propagate changes to all DCs before testing.
- 3. Update the Kerberos encryption types Group Policy on Domain Controllers: in gpmc.msc go to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > 'Network security: Configure encryption types allowed for Kerberos'. Explicitly enable AES128-HMAC-SHA1 and AES256-HMAC-SHA1. Remove RC4-HMAC from this policy only after confirming all RC4 legacy dependencies have been resolved. Run 'gpupdate /force' on DCs after updating.
- 4. For any legacy applications confirmed to hard-code RC4-HMAC: engage vendors for updated versions supporting AES. As a temporary measure only, the application's service account can retain RC4 in its msDS-SupportedEncryptionTypes (value 28) pending vendor remediation — document the exception with a defined remediation deadline.
- 5. After updating account attributes and GPO, purge Kerberos ticket caches on affected client machines: run 'klist purge' from an elevated command prompt, then test application authentication to confirm AES tickets are now issued.
- 6. Monitor DC Security event logs (Event ID 4769) for 24 hours post-remediation to confirm no further RC4 encryption type rejection failures are occurring. Refer to Microsoft Learn Kerberos RC4 hardening documentation for the full phase schedule and any additional Microsoft-recommended steps specific to the April 2026 Phase 2 rollout.
- 7. After updating msDS-SupportedEncryptionTypes on service accounts, reset the service account password to force the KDC to generate new AES Kerberos keys: Set-ADAccountPassword -Identity <AccountName> followed by a full password reset cycle. Without this step the KDC may not issue AES tickets even after the attribute update.
Prevention
- Proactively audit all service account and computer account msDS-SupportedEncryptionTypes attributes before each Microsoft Kerberos hardening phase enforcement date — ensure AES128 and AES256 are included well ahead of enforcement, not reactively after failures begin.
- Maintain an up-to-date inventory of all applications using Kerberos authentication and validate AES encryption support with vendors as part of the standard patch/update review cycle — do not wait for Microsoft enforcement phases to identify legacy RC4 dependencies.
- Subscribe to Microsoft Security Update Guide and Microsoft Learn Kerberos hardening release notes to obtain lead time for remediation of legacy encryption dependencies before each phase's enforcement date.
- Enforce AES-only Kerberos encryption via Group Policy ('Network security: Configure encryption types allowed for Kerberos') on all new environments from initial deployment, preventing RC4 dependencies from being introduced into the estate.
Tools
- Event Viewer (review DC Security and Kerberos operational logs — Event ID 4769)
- PowerShell / ActiveDirectory module — Get-ADUser, Get-ADComputer, Set-ADUser (enumerate and update msDS-SupportedEncryptionTypes)
- Active Directory Users and Computers — Attribute Editor tab (inspect and manually edit msDS-SupportedEncryptionTypes)
- klist (view and purge Kerberos ticket cache on Windows clients — confirm encryption type of issued tickets)
- Group Policy Management Console / gpmc.msc (review and update Kerberos encryption type policy on DCs and clients)
- Get-HotFix (confirm April 2026 update installation dates across DCs and clients)
- Microsoft Learn (official phase schedule and remediation guidance)