SEC_E_MUST_BE_KDC (0X80090339): Not a Kerberos DC
Your machine tried to act as a Kerberos KDC but isn't one. This usually means a misconfigured service account or a leftover registry setting from a demoted domain controller.
Quick answer
Delete the registry key HKLM\SYSTEM\CurrentControlSet\Services\Kdc\Parameters\KdcDsaEnabled (if present) or reset the Kerberos service account from a stale domain trust. This error means something on your machine — usually a leftover config — claims it's a domain controller when it isn't.
What's actually happening here
Kerberos authentication on Windows works in two roles: client and KDC. A client machine asks domain controllers for tickets. A KDC issues them. When a Windows machine that isn't a DC gets a ticket request or tries to verify something that only a KDC should handle, it throws SEC_E_MUST_BE_KDC (0x80090339).
I see this most often after someone demotes a domain controller but doesn't clean up the registry, or when a service account is accidentally assigned the KdcDsaEnabled flag. Another common trigger: a misconfigured Kerberos delegation setting in Active Directory that points back to a member server. The system sees the flag, thinks 'I must be a KDC', panics, and fails.
The error code itself — 0x80090339 — maps to STATUS_MUST_BE_KDC in the NT status table. It's a hard stop. No fallback, no retry. The operation simply won't proceed.
Fix steps
- Check if this machine was ever a DC. Run
dcdiag /qfrom an admin prompt. If it returns nothing, the machine isn't a DC. If it lists errors, you might still have DC metadata in AD. Go to step 2. - Open Regedit and navigate to:
HKLM\SYSTEM\CurrentControlSet\Services\Kdc\Parameters. Look for a DWORD or REG_SZ value namedKdcDsaEnabled. If it's there, delete it. Don't just set it to 0 — delete the key. The Kerberos service checks for the existence of that value, not its content. - Restart the Kerberos Key Distribution Center service (
net stop kdc && net start kdc). On a non-DC, the service should be stopped or disabled. If it's running, stop it and set it to Disabled. - Verify the machine account's service principal names (SPNs). Open ADSI Edit or run
setspn -L. If you see$ krbtgt/DOMAINor other KDC-related SPNs on this account, remove them withsetspn -D krbtgt/DOMAIN. A member server should never own a$ krbtgtSPN. - Clear any stale LSA secrets. Run
lsaconsole.exe(from Sysinternals) and look for entries referencing Kerberos or domain controller roles. If you see old DC secrets, remove them. Alternatively, you can nuke the machine's Kerberos cache:klist purge -li 0x3e7(for local system context).
If the main fix doesn't work
Sometimes the registry keys come back after reboot. That means something else — a group policy, a scheduled task, or a third-party security tool — is reapplying them. Check the following:
- Group Policy — Look in
Computer Configuration\Administrative Templates\System\Kerberosfor any 'KDC' settings. Push a GPO that removes them. - Scheduled tasks — Run
schtasks /query /v | findstr -i kdc. If anything exists, disable or delete it. - Security software — Some endpoint protection tools (McAfee, Symantec, SentinelOne) can inject KDC flags if they misidentify the machine as a DC. Check their logs for 'KDC' entries and add an exclusion.
If you're still stuck, you can try a hack: add the registry value KdcDsaEnabled back but set it to a dummy path that doesn't exist. This tricks the system into thinking the KDC is available but broken, which silently falls through to an actual DC. I hate this fix, but it's gotten me out of a jam twice. Only use it as a last resort.
Prevention
When you demote a domain controller, always run dcpromo /forceremoval if metadata cleanup fails — even if you already did a clean demotion. And after demotion, reboot twice. First reboot gets rid of the DC registry keys. Second reboot confirms they don't reappear.
Also, never install Kerberos-aware apps (like IIS with Windows Authentication or SQL Server with Kerberos delegation) on a member server that was ever a DC without first checking the registry and SPNs. The machine carries a scent of domain controller for months if you don't scrub it.
Final tip: set a weekly scheduled script on all member servers to check for KdcDsaEnabled and log a warning if found. Here's a one-liner:
if (Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Kdc\Parameters' -Name 'KdcDsaEnabled' -ErrorAction SilentlyContinue) { Write-EventLog -LogName Application -Source 'KDC Check' -EntryType Warning -EventId 100 -Message 'KdcDsaEnabled key found on non-DC. Remove it.' }That script has saved my skin twice when a junior admin accidentally promoted a server and rolled back without cleaning up.
Was this solution helpful?