In many of the Active Directory environments I work with, Kerberos RC4 deprecation has been a background worry for years. Now Microsoft has officially announced that domain controllers will disable RC4 by default starting in 2026, so it's time to deal with it properly. Any legacy dependency that's still around will simply stop authenticating once RC4 is gone, with no warning. The usual suspects are service accounts, appliances, old NAS devices and some Linux hosts, and that's exactly where unprepared tenants get caught out.

RC4 has no place left in Kerberos

RC4 has been considered weak for years, and in Kerberos it's an actual liability. The key is derived directly from the password, which makes attacks like Kerberoasting or Pass-the-Ticket much easier. The Microsoft Kerberos authentication overview covers the technical background. Most environments have moved to AES over time, but not all of them, and RC4 often stayed enabled "just in case." With its removal now scheduled, you need to know who or what still relies on it.

Domain controller logs show where RC4 is still in use

Tracking down leftover RC4 use is often a surprise, even in environments everyone considered "modernized". Your main source is the Security event log on the domain controllers. Event IDs 4768 (TGT issuance) and 4769 (service ticket) contain a "Ticket Encryption Type" field, and 0x17 means RC4. If you want a view that scales and keeps running, stream these logs into a Log Analytics Workspace (via Azure Monitor or Sentinel) and run a KQL query like this one:

SecurityEvent
| where EventID in (4768, 4769)
| extend EncryptionType = tostring(parse_xml(EventData).EventData.Data[5]['#text'])
| where EncryptionType == '0x17'
| summarize Count = count() by Account = tostring(parse_xml(EventData).EventData.Data[0]['#text'])

Where: Log Analytics Workspace with SecurityEvent ingestion from DCs, and reader permissions on the workspace.

The results show you fairly quickly which accounts and systems are still receiving RC4 tickets. In smaller setups you can search the DC event logs directly with PowerShell (Get-WinEvent), but that approach doesn't scale. If you run Microsoft Defender for Identity, I'd strongly recommend the weak cipher security assessment. It flags machines and apps that still request RC4, and in my experience it often leads straight to NAS devices, legacy appliances or outdated Linux/Unix hosts.

Old service accounts and keytabs cause most of the breakage

When Kerberos RC4 deprecation is enforced, the thing I've seen break most often is old service accounts. That's particularly true for accounts with very old passwords, or where msDS-SupportedEncryptionTypes is missing or set to RC4 only. Without a new password set, which is what generates the AES keys, these accounts just stop authenticating. More than once during a migration I've found that the service account passwords (for SQL, IIS or backup services) had been rotated, but nobody had updated the supported encryption types or regenerated the keytabs. Storage systems and firewalls are harder still, because they often use hardcoded keytabs and need a vendor update before AES works properly.

Pro tip: Find the service accounts with very old passwords and reset them on purpose. That makes AD create AES keys, which modern Kerberos needs. For non-Windows systems, always generate new keytabs that include the current encryption types.

To find problem accounts, I use this PowerShell command (run it with the Active Directory module, for example on a management server with RSAT):

Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { !$_.msDS-SupportedEncryptionTypes -or $_.msDS-SupportedEncryptionTypes -band 4 }

It lists every user account where the attribute is missing or set to RC4 only. You can do the same for computer objects.

A pilot OU with its own GPO tests the switch safely

Before the actual switch, you have to find out whether RC4 can be turned off everywhere without taking down important services. I usually set up a pilot OU containing representative systems and service accounts, plus a dedicated GPO on the DCs in scope that disables RC4. Hidden dependencies show up quickly this way, and you can fix them with little risk to the business. For the most thorough check, simulate the planned group policy in a test environment, write down what fails, and make sure every new system is built without RC4 from day one.

The diagram below shows the process I recommend:

flowchart TD
    Discovery["Find RC4 usage"] --> Accounts["Check service accounts & reset passwords"]
    Discovery --> Devices["Check device keytabs"]
    Accounts --> Pilot["Pilot OU: Disable RC4"]
    Devices --> Pilot
    Pilot --> Testing["Run function tests"]
    Testing --> Rollout["Disable RC4 on all DCs"]

Figure: Typical workflow for safe Kerberos RC4 deprecation.

Microsoft plans the default change for 2026

According to the current announcement, Microsoft will disable RC4 by default in 2026. The Windows release health page is the place to check when the change reaches the Windows versions you support. I'd put this on the list now rather than later. Over the past few months I've watched more tenants switch RC4 off completely, and they end up with a much tidier AD as a result: updated service accounts, regular password hygiene and better lifecycle management for appliances. The sooner you start, the calmer things will be when the deprecation actually arrives.