KDC reply has too many principals (0xC00002F7) fix
This error means Windows got multiple user names from the KDC when it expected exactly one. Here's how to fix it in under 30 minutes.
What makes this error pop up
You're logging into a domain-joined machine, or maybe you're running an app that talks to SQL Server or an Exchange server, and boom — you get the STATUS_TOO_MANY_PRINCIPALS (0xC00002F7) error. The Windows security log will show the KDC reply contained more than one principal name. This tripped me up the first time I saw it on a Windows Server 2019 box last year.
What's happening: your machine asked the Domain Controller (KDC) for a Kerberos ticket, but the DC found more than one account with the same user principal name (UPN) or Service Principal Name (SPN). So it sent back a bundle of candidates, and Windows doesn't know which one to use. This usually means a duplicate computer account or a stale SPN sitting in AD. Let's fix it.
Quick check (30 seconds): flush DNS and renew the ticket
Sometimes it's a caching problem. The KDC might have stale DNS records pointing to a wrong DC or duplicate entries. Clear the local DNS cache and Kerberos tickets before you do anything else.
- Open Command Prompt as administrator. Click Start, type
cmd, right-click and choose Run as administrator. - Run these commands one at a time:
ipconfig /flushdns
klist purge
Wait a few seconds, then try your login or application again. If it works, you're done. This fixes maybe 20% of cases — usually after a DC failover or network change.
Moderate fix (5 minutes): find and remove duplicate SPNs
If the flush didn't help, the real culprit is almost always a duplicate Service Principal Name. SPNs are like addresses for services — each one must be unique across the entire domain. When two accounts claim the same SPN, the KDC gets confused.
Open PowerShell as administrator on any domain-joined machine or DC, and run:
setspn -X
This scans for duplicate SPNs. If it finds any, it'll list the conflicting accounts. For example, you might see HOST/SERVER01 registered on both COMPUTER-OLD$ and COMPUTER-NEW$. That old computer account shouldn't have that SPN anymore.
To remove the duplicate from the wrong account, use:
setspn -D HOST/SERVER01 COMPUTER-OLD$
Replace HOST/SERVER01 with the actual SPN and COMPUTER-OLD$ with the incorrect account name. Run setspn -X again to confirm it's clean.
Advanced fix (15+ minutes): check for duplicate user or computer accounts
If SPNs are clean and you're still getting 0xC00002F7, there's a deeper AD issue — likely a duplicate user or computer account. This happens when someone re-joins a machine to the domain without removing the old computer object, or when a user is migrated with a duplicate UPN.
Open Active Directory Users and Computers (dsa.msc) on a DC. Go to the Users or Computers container. Look for any account that matches the one throwing the error. But the fastest way is using PowerShell on the DC:
Get-ADObject -Filter 'ObjectClass -eq "computer"' -Properties SamAccountName | Group-Object SamAccountName | Where-Object { $_.Count -gt 1 }
Same query for users:
Get-ADObject -Filter 'ObjectClass -eq "user"' -Properties SamAccountName | Group-Object SamAccountName | Where-Object { $_.Count -gt 1 }
If you see duplicates, you need to disable and then delete the stale one. Do not delete the current active account. Verify the last logon timestamp on each. On a domain controller, run:
Get-ADComputer COMPUTER-NEW -Properties LastLogonDate
Stale accounts usually show a logon date months or years ago. Disable that duplicate, then delete it after a few days if nothing breaks.
Last resort: clear the Kerberos ticket cache on the KDC
I've seen one case where the KDC itself held a cached ticket with multiple principal entries. This is rare, but if the above steps didn't work, restart the Kerberos Key Distribution Center service on the DC handling authentication. On the DC, open Services.msc, find Kerberos Key Distribution Center, right-click and choose Restart. This flushes the KDC's internal cache.
After the restart, run klist purge again on the client machine and test. If it still fails, check the DC's System log for Event ID 11 or 24 — those point to database corruption, which needs a full AD restore. Hopefully you won't get there.
One more thing: if you're using a third-party Kerberos realm (like MIT or Heimdal), the KDC there might also have duplicate entries. But in 99% of Windows-only environments, it's one of the fixes above. Start with the flush, check SPNs, then hunt for duplicate AD accounts. You'll beat this error.
Was this solution helpful?