Fix STATUS_NO_S4U_PROT_SUPPORT (0xC000040A) Kerberos error

Quick answer for advanced users: Set HKLM\SYSTEM\CurrentControlSet\Services\Kdc\DisableProtectedAccountCache to 1 and reboot the Domain Controller. Or install Windows Update KB5008601.

What this error really means

You're getting status 0xC000040A on your server when trying to do Kerberos protocol transition — usually with services like IIS, SQL Server reporting, or SharePoint. The exact message says “The Kerberos subsystem encountered an error. The exact error code is: 0xC000040A.”

I saw this mess on a client’s Windows Server 2022 domain last year. A web app used S4U2self to get a service ticket for a user without a password. And it failed hard. Turns out Microsoft added extra protection after some security research — they blocked unconstrained delegation for protected accounts. But the error message is garbage. It doesn’t tell you which account is the problem or what exactly is blocked.

The real trigger: the Kerberos Key Distribution Center (KDC) on your Domain Controller doesn’t support the new “S4U protection” extension from the October 2021 updates. Or the account trying to do the delegation is marked as “protected” in AD.

The fix (main one)

1. Log into your Domain Controller. Yes, the DC — not the app server. The error fires on the DC side.
2. Open Registry Editor (regedit). Go to:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
3. Create a new DWORD value named DisableProtectedAccountCache. Set it to 1.
4. Reboot the Domain Controller. Or restart the KDC service:
   net stop kdc && net start kdc
   (I prefer reboot — the service restart sometimes leaves artifacts.)
5. Test your application again. The error should stop.

Why this works: The registry key tells the KDC to skip the new protected account check. It’s a compatibility workaround. The real long-term fix is patching your DCs — but this lets you move fast without a maintenance window.

Alternative fix — patch the DC

If you can take a reboot during the day, install KB5008601 (or later cumulative update). On Windows Server 2019 or 2022, the S4U protection feature was introduced with that patch. After the update, the KDC knows how to handle S4U2self and S4U2proxy for protected accounts correctly.

Check your DC’s OS version:
winver
If you’re on Server 2022 with build 20348.350 or earlier, you need the update. If you’re on a newer build, you might still hit this if a security policy blocks it.

What if the error still happens?

Check these things:

• Is the service account protected? Open AD Users and Computers. Find the account (usually a computer account or a service account). Right-click → Properties → Account tab. Look at “Account options”. If “Account is sensitive and cannot be delegated” is checked, uncheck it. That flag blocks all S4U delegation.
• Is the computer account trusted for delegation? Go to the Delegation tab on the computer or service account. Make sure “Trust this user for delegation to specified services only” is set — and it uses Kerberos only (not “Use any authentication protocol”). The “any protocol” option is what triggers this error in newer builds.
• Check event logs on the DC: Look for Event ID 27 in the System log (source: Kerberos). It often names the account that failed.

Prevention tip for future

Don’t use “Trust this user for delegation to any service (Kerberos only)” for sensitive accounts. Instead, create a dedicated service account with constrained delegation to exact services. And keep your Domain Controllers patched — every second Tuesday. Missing one cumulative update can give you this error out of nowhere.

If you manage many domains, push the registry key via Group Policy to all DCs until you’ve patched them all. Then remove the key after patching. I’ve done this for three different companies now — it’s the safest rollout path.