Is Your SQL Server Using RC4 for Kerberos? Here’s How to Find Out
You probably haven’t thought about Kerberos encryption types recently. That’s 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’s been lurking in Kerberos configurations since the Windows 2000 era.
Hat tip to Mike Walsh for raising awareness of this issue on LinkedIn. His post pointed me at this CVE, which led to building the detection tooling described below.
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’s 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’s the actual risk?
RC4-HMAC (etype 23) is a weak cipher by modern standards. CVE-2026-20833 classifies it as an information disclosure vector. 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 aren’t 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. 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’s 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/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2026-20833-1ebcda33-720a-4da8-93c1-b0496e1910dc |
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, 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" ☑ AES128_HMAC_SHA1 ☑ 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 KB5073381 for the complete migration guidance from Microsoft.
What if you’re on Windows Server 2025 DCs?
You’re already protected for TGTs. Windows Server 2025 domain controllers no longer issue TGTs using RC4-HMAC, regardless of configuration. 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 silent breaking change: AES flag without AES keys
There’s a scenario that’s easy to miss, and I just ran into it myself. Suppose you (or a predecessor, or a hardening script) set msDS-SupportedEncryptionTypes = 0x18 (AES128 + AES256) on the SQL Server service account months or years ago. Everything kept working. Then a Windows Update lands on your domain controllers, and suddenly every client connecting to SQL Server falls back to NTLM. No errors in the SQL Server error log. No Kerberos events on the client. Just silent degradation.
Here’s what happened: setting the attribute told AD “this account prefers AES,” but it did not regenerate the account’s actual Kerberos keys. The stored key material remained RC4-HMAC (etype 23). The old KDC was lenient; it issued service tickets using the RC4 key despite the AES preference. The patched KDC (post-CVE-2026-20833) now strictly refuses to use a key type that doesn’t match the declared supported encryption types.
The dcdiag output on the domain controller makes it clear:
|
1 2 3 4 5 |
While processing a TGS request for the target server MSSQLSvc/sqlserver01.corp.example.com:1433, the account SQLSvc@CORP.EXAMPLE.COM did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 9). The requested etypes were 18 17. The accounts available etypes were 23. Changing or resetting the password of SQLSvc will generate a proper key. |
Translation: the client asked for AES256 (18) or AES128 (17), but the only key the KDC has on file for the service account is RC4 (23). The KDC refuses to issue the ticket, and the client silently falls back to NTLM.
The fix
Reset the service account password. This forces AD to generate AES key material:
|
1 |
Set-ADAccountPassword -Identity SQLSvc -Reset -NewPassword (Read-Host -AsSecureString "New password") |
Then update the password in SQL Server Configuration Manager and restart the SQL Server service. After the restart, klist on a client should show an MSSQLSvc/* service ticket with etype 18 (AES256).
The critical takeaway: setting msDS-SupportedEncryptionTypes is not enough. You must also reset the password afterward so AD generates the matching keys. If you set it years ago and never re-keyed, the January 2026 KDC patch just broke Kerberos for every client connecting to that service, with zero warning.
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 doesn’t require credentials. Grab it from GitHub.