Logins, SIDs, and Kerberos from First Principles, Part 7: Is Your Kerberos Still Using RC4?
Part 6 got your connections onto Kerberos. This part asks an uncomfortable follow-up: encrypted with what? You probably have not thought about Kerberos encryption types recently. That is fair; the protocol mostly just works and has for decades. But CVE-2026-20833 changed the calculus. Microsoft disclosed a Kerberos information disclosure vulnerability in January 2026 that affects every supported version of Windows Server from 2008 SP2 through 2025. The root cause is RC4-HMAC, an encryption type that has been present in Kerberos configurations since the Windows 2000 era.
The uncomfortable truth: most SQL Server environments still have RC4-HMAC somewhere in the negotiation chain. Not because anyone chose it deliberately, but because it is the default when nobody configures msDS-SupportedEncryptionTypes on the service account. The domain controller picks encryption types based on domain functional level defaults, and those defaults have historically included RC4.
What Is the Actual Risk?
RC4-HMAC (etype 23) is a weak cipher by modern standards. CVE-2026-20833 classifies it as an information disclosure vector.[1] In practical terms, a Kerberos ticket encrypted with RC4 is significantly easier to attack offline than one encrypted with AES-256. If an attacker captures Kerberos traffic (which is trivial on a shared network), RC4-encrypted tickets are the low-hanging fruit.
The good news: Windows Server 2025 domain controllers no longer issue TGTs using RC4-HMAC at all. The bad news: most of us are not running 2025 DCs yet, and the migration path requires deliberate configuration on every service account.
How Do You Check Your SQL Server Instances?
I added RC4 detection to sql-cert-inspector (the TLS certificate inspection tool I wrote about previously). The tool now does two things related to RC4:
1. AD attribute inspection (runs automatically with Kerberos diagnostics): queries msDS-SupportedEncryptionTypes on the service account that owns the SQL Server SPN (part 6 covered which account that should be). This tells you what encryption types the account is configured to accept.
2. Live authentication test (opt-in with --test-kerberos): performs an actual SSPI/Negotiate handshake against the server, extracts the Kerberos ticket’s encryption type from the SPNEGO token, and cross-references it with both the client machine’s configuration and the service account’s AD attribute.
Here is what the output looks like when RC4 is negotiable but AES was chosen:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
=== Kerberos SPN Registration === FQDN + Port MSSQLSvc/sqlprod01.corp.example.com:22136 REGISTERED -> svc-sql-prod (User) FQDN + Instance MSSQLSvc/sqlprod01.corp.example.com:MSSQLSERVER REGISTERED -> svc-sql-prod (User) Encryption Types (msDS-SupportedEncryptionTypes not configured) REVIEW === Kerberos Health Checks === [WARN] Service account 'svc-sql-prod' does not have msDS-SupportedEncryptionTypes configured. The domain controller will select encryption types based on domain functional level defaults, which may include RC4-HMAC. === Kerberos Authentication Test === Target SPN MSSQLSvc/sqlprod01.corp.example.com:MSSQLSERVER Protocol Kerberos Ticket Etype 18 (AES256-CTS-HMAC-SHA1-96) RC4 Status Not in use OK Client Etypes RC4-HMAC, AES128, AES256 [default (0x1C)] Service Acct Etypes (not configured in AD) Negotiable Etypes RC4-HMAC, AES128, AES256 RC4-HMAC is negotiable Advisory https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20833 https://nvd.nist.gov/vuln/detail/CVE-2026-20833 Mitigation https://support.microsoft.com/en-us/topic/kb5021131-how-to-manage-the-kerberos-protocol-changes-related-to-cve-2022-37966-fd837ac3-cdec-4e76-a6ec-86e67501407d |
Notice the key finding: the KDC chose AES-256 for this particular ticket, but RC4-HMAC is still in the negotiable set. That means a downgrade attack could force RC4 in the right circumstances.
How to Run It
Download the latest release from GitHub and run:
|
1 |
sql-cert-inspector --server myserver.corp.example.com\SQLPROD --test-kerberos |
The --test-kerberos flag opens a separate connection and performs a full TDS LOGIN7 + SSPI handshake. It determines whether Kerberos or NTLM was actually used (the same question part 6 answered with sys.dm_exec_connections, but from outside the server and without credentials), extracts the ticket etype from the SPNEGO token via ASN.1 parsing, and reads your machine’s Kerberos registry configuration to compute the full picture.
Without --test-kerberos, the tool still queries the service account’s msDS-SupportedEncryptionTypes from AD during normal SPN diagnostics. That alone will tell you if RC4 is explicitly enabled on the account.
How to Fix It
SQL Server itself has no configuration for Kerberos encryption types. It delegates entirely to Windows SSPI, which means the fix is at the AD and OS level.
Step 1: Set msDS-SupportedEncryptionTypes on the service account. This is the single most important change. In Active Directory Users and Computers (or PowerShell), configure the SQL Server service account to support only AES:
|
1 |
Set-ADUser "svc-sql-prod" -KerberosEncryptionType AES128,AES256 |
This sets the attribute to 0x18 (AES128 + AES256, no RC4). After changing this, the service account’s password must cycle (or be manually reset) so the KDC generates new AES keytab entries.
Step 2: Configure Group Policy to remove RC4 from the allowed encryption types on both the SQL Server machines and the domain controllers:
|
1 2 3 4 5 |
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> "Network security: Configure encryption types allowed for Kerberos" [X] AES128_HMAC_SHA1 [X] AES256_HMAC_SHA1 [ ] RC4_HMAC_MD5 -> uncheck this |
Step 3: Set the KDC fallback on domain controllers so accounts without msDS-SupportedEncryptionTypes default to AES-only:
|
1 2 |
Registry: HKLM\System\CurrentControlSet\services\KDC DefaultDomainSupportedEncTypes (REG_DWORD) = 0x38 (AES128 + AES256 + AES Session Keys) |
See KB5021131 for the complete migration guidance from Microsoft.[2]
What If You Are on Windows Server 2025 DCs?
You are already protected for TGTs. Windows Server 2025 domain controllers no longer issue TGTs using RC4-HMAC, regardless of configuration.[3] However, you should still configure msDS-SupportedEncryptionTypes on service accounts for defense in depth, and be aware that the legacy client-side registry key (HKLM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\SupportedEncryptionTypes) is no longer honored on Server 2025. Use Group Policy instead.
The Bottom Line
Run sql-cert-inspector --test-kerberos against your SQL Server fleet. If you see “RC4-HMAC is negotiable” or “msDS-SupportedEncryptionTypes not configured” in the output, you have work to do. The fix is straightforward (one PowerShell command per service account), but you need to know which accounts to fix first.
The tool is free, open source, and does not require credentials. Grab it from GitHub.
Next up: part 8 closes the series with continuous login auditing, capturing every connection with Service Broker and event notifications, no trace or Extended Events session required.
Found RC4 lurking in your domain? I would love to hear about it in the comments, or find me on Bluesky or LinkedIn.
References
- CVE-2026-20833 – Microsoft Security Response Center. The Kerberos information disclosure advisory motivating RC4 removal. ↩
- KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966 – Microsoft Support. Migration guidance for msDS-SupportedEncryptionTypes and the KDC default encryption types. ↩
- Kerberos authentication overview – Microsoft Learn. Protocol behavior, encryption type negotiation, and Windows Server 2025 changes. ↩