Kerberos RC4 Fallback in Active Directory: How to Detect It, Why It Still Happens, and How to Remove It

Kerberos RC4 fallback in Active Directory means a domain controller is still issuing Kerberos material with RC4 because the client, the service, the account keys, or the effective encryption-type configuration does not let the exchange stay on AES. That still matters in 2026 because RC4-backed service tickets keep the offline cracking side of Kerberoasting relevant even in domains that already look modern on paper.

This article is not a second Kerberoasting guide. It is a detection-and-remediation guide for proving where RC4 is still being used, why the KDC is still choosing it, and how to remove that dependency without breaking authentication.

What Kerberos RC4 Fallback Means in Active Directory

In practice, Kerberos RC4 fallback is not one setting. It is the outcome of the KDC choosing RC4 for a ticket or session key because AES is unavailable, not advertised, not generated for the account yet, or excluded by effective configuration.

Microsoft now states this plainly. In its current Kerberos guidance, Microsoft says RC4 is being phased out, that Windows updates released on or after November 8, 2022 changed the default Kerberos behavior to prefer AES-SHA1 for accounts where an encryption type was not explicitly set, and that RC4 still remains in use for accounts that do not support AES-SHA1. That is why this topic belongs in both an audit-first AD security review and a hardening-first AD cleanup plan.

Why RC4 Still Appears in Modern AD Environments

The most common mistake is to assume that seeing RC4 in a ticket always means one bad GPO. Microsoft's current documentation points to several different root causes, and they do not all remediate the same way.

Two Microsoft points matter here.

First, the November 8, 2022 Kerberos changes did not remove RC4 everywhere. Microsoft Support says those updates set AES as the default encryption type for session keys on accounts that were not already marked with a default encryption type, while Microsoft Learn says RC4 still appears for accounts that do not support AES-SHA1.

Second, computer accounts and user or service accounts do not behave the same way. Microsoft Support says Windows computers automatically set msDS-SupportedEncryptionTypes for their machine accounts based on local Kerberos policy, but user accounts, group Managed Service Accounts, and other AD accounts do not have that value set automatically. That difference is one of the main reasons service accounts keep showing up in RC4 investigations.

How to Detect Kerberos RC4 Fallback

For most environments, detection starts on domain controllers, not on the service host that eventually receives the ticket. Microsoft Learn says Kerberos RC4 usage details are recorded in Security logs on KDCs for Windows Server 2019 and later, and that Windows Server 2016 also gained RC4 usage visibility in these events after the January 2025 cumulative update.

Start with these data sources:

If you already centralize DC telemetry, this belongs next to the Kerberos events covered in Active Directory Monitoring: Security Event IDs That Matter, not in a separate ad hoc report.

What Event ID 4769 Actually Tells You

Event ID 4769 is the most practical place to prove Kerberos RC4 fallback because Microsoft documents both the ticket encryption value and the surrounding context fields.

Two details matter immediately:

1. Microsoft documents Ticket Encryption Type = 0x17 as RC4-HMAC, and 0x18 as RC4-HMAC-EXP.
2. Microsoft also says that, starting with Windows Vista and Windows Server 2008, the expected service ticket encryption values are 0x11 and 0x12, which are AES-family algorithms.

That makes 4769 one of the cleanest ways to prove that RC4 is still being issued.

Note: do not confuse Ticket Encryption Type = 0x17 in Event ID 4769 with msDS-SupportedEncryptionTypes = 0x18 or DefaultDomainSupportedEncTypes = 0x18. In Event 4769, 0x17 and 0x18 are RC4-family ticket values. In the AD and KDC bitmask context, 0x18 means AES128 plus AES256 only.

That distinction matters because it is easy to build the wrong remediation if you mix event values with AD bitmask values.

When you investigate 4769, use it with the surrounding account context:

• If Ticket Encryption Type is RC4-family and the service account has no AES keys, password history is often the real issue.
• If the client or target does not advertise AES, policy or platform compatibility is usually involved.
• If the event fields suggest an account supports only default behavior, review whether the account actually has a raw msDS-SupportedEncryptionTypes value in AD or whether the KDC is falling back to the domain default.

Common Root Causes Behind RC4 Ticket Issuance

Old accounts without regenerated AES keys

Microsoft Learn says that if a user account was created before AES-SHA1 support was added to Windows Kerberos and the password was never reset after support was added, the account can be missing AES-SHA1 keys. Microsoft ties this to the historical introduction of AES support in Windows Server 2003 and explicitly says that changing the account password generates the missing keys.

This is why RC4 cleanup is partly a password lifecycle problem and not just a protocol policy problem. It also explains why the issue often overlaps with the service-account hygiene problems described in Active Directory Password Security: Misconfigurations That Matter.

msDS-SupportedEncryptionTypes is absent, incomplete, or misread

Microsoft Support says that if an account does not have msDS-SupportedEncryptionTypes set, or it is set to 0, domain controllers assume a default value of 0x27 or use the DefaultDomainSupportedEncTypes registry setting. Microsoft Learn also says the KDC uses the domain default when the source or target machine has no defined value.

That means RC4 can still appear without an admin ever explicitly ticking an RC4 box on the account itself.

Use Microsoft's own commands to inspect what is actually configured.

Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x7 -and -not msDS-supportedEncryptionTypes -bor 0x18"

That query comes from Microsoft Support and is specifically meant to find accounts where DES or RC4 is explicitly enabled but AES is not.

For a single object review, Microsoft Learn shows this pattern:

$accountName = "<computer account name>"
$parameters = @{
     Filter     = "Name -eq '$($accountName)' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')"
     Properties = "msDS-SupportedEncryptionTypes"
}
Get-ADObject @parameters | FL "DistinguishedName","msDS-SupportedEncryptionTypes","Name","ObjectClass"

Legacy devices and services that still do not support AES

Microsoft's Kerberos policy documentation still warns that the Network security: Configure encryption types allowed for Kerberos setting can affect compatibility with client computers, services, and applications. The same Microsoft Learn guidance says the last Windows platform that did not support AES-SHA1 was Windows Server 2003 and recommends migration for devices that still depend on older behavior.

This is where RC4 fallback turns into an engineering problem instead of a checkbox. If you disable RC4 before you understand which clients and services still need it, you trade a security problem for an authentication outage.

Linux-integrated edge cases

Microsoft now documents a specific Linux-integrated scenario where AD DS still issues RC4-encrypted tickets. In that case, Event ID 4769 shows Ticket Encryption Type: 0x17, and Microsoft says forcing msDS-SupportedEncryptionTypes to 24 (0x18) or toggling the Kerberos encryption-type GPO does not solve the problem.

The documented reason is narrower than "Linux causes RC4." Microsoft says the issue occurs because the operatingSystemVersion attribute is interpreted in a way that makes the KDC treat the account as if supported encryption types are not populated, causing the KDC to use assumed supported encryption types instead.

That is an edge case worth knowing because it proves that some RC4 findings are caused by directory metadata semantics, not just by obvious policy drift.

How to Remediate RC4 Dependencies Safely

The safest remediation order is progressive.

1. Prove where RC4 is being issued before you change defaults

Do not start by disabling RC4 domain-wide. Start by proving where RC4 is still being issued in 4769 and which account or service each event maps to. If you updated domain controllers with the January 13, 2026 or later Windows updates, also monitor the Kdcsvc audit events introduced for the RC4 service-ticket hardening path.

2. Regenerate missing AES keys where that is the real cause

If an old user or service account is missing AES keys, Microsoft says changing the account password generates them. That should happen before you make broader KDC-side changes. For service accounts with SPNs, this is also the point where the risk overlaps with Kerberoasting: RC4-backed tickets are easier to turn into offline cracking work when weak or reused passwords are also present.

3. Separate raw AD configuration from effective KDC behavior

Check the raw msDS-SupportedEncryptionTypes attribute, then compare it with what the event shows. If the attribute is empty or 0, the KDC may be using DefaultDomainSupportedEncTypes instead. If a machine account is setting the value automatically based on local policy, fix the device policy. If a user or service account needs an explicit value, change that account deliberately rather than changing the whole domain default first.

4. Remove legacy dependencies before tightening Kerberos policy

If the client, service, appliance, or non-Windows stack does not actually support AES, Microsoft's own guidance is to migrate or replace it where possible. That is also why the Kerberos GPO documentation keeps warning about compatibility impact. RC4 cleanup should remove legacy dependencies first, not pretend they do not exist.

5. Use Protected Users only where it truly fits

Microsoft documents that Protected Users restrict members to AES for Kerberos, stop creating DES or RC4 keys, and prevent DES or RC4 in Kerberos preauthentication. That makes the group useful for selected human accounts that can already operate cleanly on AES.

It is not a universal RC4 remediation lever. Microsoft explicitly warns not to add service or computer accounts to Protected Users. In other words, Protected Users is a targeted control for the right user accounts, not a substitute for fixing service-account, device, or KDC configuration.

6. Prepare for the 2026 RC4 default changes with explicit dates

Microsoft's RC4 service-ticket guidance adds a second timeline that matters operationally:

• January 13, 2026: initial deployment phase begins and adds audit events for risky default RC4 behavior.
• April 14, 2026: enforcement phase changes the default DefaultDomainSupportedEncTypes value for KDC operations to 0x18, meaning AES-SHA1 only, for accounts that do not have an explicit msDS-SupportedEncryptionTypes value.
• July 2026: Microsoft says the temporary rollback control for this behavior is removed and enforcement becomes the standing mode.

That is the current Microsoft timeline. If you still need RC4 after April 14, 2026, Microsoft says to enable it explicitly in the service account's msDS-SupportedEncryptionTypes bitmask rather than depending on the old default behavior.

Validation After Moving to AES

You are done when the evidence changes, not when the GPO looks cleaner.

Validate the change in this order:

1. Confirm new Event ID 4769 entries for the remediated services no longer show RC4-family ticket values.
2. Confirm expected AES-family ticket values appear instead, typically 0x11 or 0x12.
3. Confirm the account now has AES keys if a password reset was the intended fix.
4. Confirm service authentication still works after password resets, service restarts, or account-setting changes.
5. On domain controllers updated for the 2026 hardening path, confirm there are no relevant Kdcsvc 201-209 warnings or errors for the remediated paths.
6. Test non-Windows interoperability explicitly. Microsoft says the absence of audit events does not guarantee that every non-Windows device will continue to work after the April 14, 2026 enforcement update.

If you want to track this over time instead of as a one-time cleanup, fold it into a recurring audit workflow and keep it in the same family of checks as the broader Active Directory security misconfigurations that drive identity drift.

How EtcSec Detects Kerberos RC4 Fallback

EtcSec detects Kerberos RC4 fallback by correlating the evidence that Microsoft now exposes operationally:

• RC4-family ticket issuance in Kerberos service ticket telemetry
• accounts that still depend on default or explicit RC4-capable encryption settings
• principals that lack usable AES keys after account age or password-history drift
• service-account paths where RC4 fallback and crackable ticket exposure overlap

That lets teams remeasure after password resets, account-setting changes, legacy service cleanup, and KDC hardening instead of treating RC4 as a one-time review item.

Primary References

• Detect and remediate RC4 usage in Kerberos
• Event 4769: A Kerberos service ticket was requested
• KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966
• How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833
• Protected Users security group
• Preventing Kerberos change password that uses RC4 secret keys
• Linux accounts can't get AES-encrypted tickets in AD DS
• Network security: Configure encryption types allowed for Kerberos