Fix SEC_E_TOO_MANY_PRINCIPALS 0x8009033B error

What's going on with this error?

You're trying to log into a Windows machine, access a network share, run an application—and you get hit with SEC_E_TOO_MANY_PRINCIPALS (0x8009033B). The full message says something like: 'The KDC reply contained more than one principal name.'

Here's what that means in plain English: When your computer asked the Kerberos Key Distribution Center (KDC—usually your domain controller) for a ticket, the KDC got confused and sent back a response that listed multiple user or computer principal names instead of just one. Kerberos can't handle that. It doesn't know which one you really are, so it bails with this error.

This usually happens because of one of three things: a DNS misconfiguration, duplicate SPNs (Service Principal Names), or a time sync problem. I'll show you fixes for each, starting with the easiest.

Fix 1: Clear your Kerberos ticket cache (30 seconds)

This is the lazy fix that works about 30% of the time. Your local ticket cache might have a stale or corrupted ticket from an earlier KDC reply. Clearing it forces your machine to ask for a fresh ticket.

Open Command Prompt as an administrator. Press Windows key, type cmd, right-click 'Command Prompt', choose 'Run as administrator'.
Type or paste this command and press Enter:
```
klist purge
```
You should see a message like 'Current LogonId is 0:0x... Purged.' That means your cached tickets are gone.
Now try whatever you were doing that triggered the error. If it works, you're done. If not, move to the next fix.

Why this sometimes works: If the original ticket request went to a misbehaving domain controller that sent back bad data, clearing the cache and retrying may hit a different DC that gets it right. It's a shot in the dark, but it's fast.

Fix 2: Check for duplicate SPNs (5 minutes)

This is the real fix for most cases. Duplicate Service Principal Names (SPNs) are the #1 cause of this error. An SPN is a unique identifier that Kerberos uses to associate a service (like SQL Server, IIS, or even a file share) with a specific machine account. If two different accounts claim the same SPN, the KDC doesn't know which one to send the ticket to—so it sends both, and that's your error.

Log into a domain controller or any machine with the Active Directory Administrative Center or ADSI Edit tools installed.
Open Command Prompt as an administrator.
Run this command to list all SPNs in the domain and find duplicates:
```
setspn -Q */*
```
This dumps every SPN. Wait—it could be hundreds or thousands. Piping it through find is smarter. Use this instead to directly search for duplicates:
```
setspn -X
```
After running setspn -X, you'll see a list of duplicate SPNs. They look something like:
```
HOST/SERVER01.CONTOSO.COM SERVER01$ CONTOSO\DUPLICATE_USER
```
For each duplicate, you need to decide which account should have it. Usually the computer account—like SERVER01$—is the correct owner. If a user account has it wrongly, run this command to remove it:
```
setspn -D HOST/SERVER01.CONTOSO.COM CONTOSO\DUPLICATE_USER
```
After cleaning up duplicates, run this to verify:
```
setspn -X
```
It should return no duplicates.

Real-world trigger: You just migrated a service from one server to another. The old server's account still holds the SPN, and the new server's account also got one added. Boom—duplicate. Clean the old one.

Fix 3: Fix DNS and time sync (15 minutes)

If the SPN check came back clean, the problem is likely DNS or clock skew. Kerberos is picky about both.

Step 1 - Check time sync: Kerberos tickets are timestamped. If your client clock is off by more than 5 minutes from the domain controller, authentication fails. This can also trigger the 'too many principals' error because the KDC's ticket response includes both a forward and reverse lookup that might mismatch due to time issues.

On the machine with the error, open Control Panel > Date and Time.
Click Change date and time settings if you see it, then Internet Time tab, then Change settings. Make sure it's set to sync with time.windows.com or your internal NTP server.
Better yet, run this in Command Prompt (admin) to force a sync:
```
w32tm /resync
```
If you get a 'The computer did not resync because no time data was available' error, check your time service:
```
w32tm /query /status
```
Look for 'Source'—it should be your domain controller.

Step 2 - Check DNS for stale records: The KDC does a reverse DNS lookup on your IP to get your hostname. If that reverse lookup returns multiple names, Kerberos sees multiple principals. This is common in DHCP environments where old PTR records aren't cleaned up.

On a domain controller, open DNS Manager (from Server Manager > Tools).
Expand your server name, then Reverse Lookup Zones.
Find the zone that matches the IP range of the affected machine. Look for the specific host record for the machine's IP.
If you see more than one record pointing to different hostnames for the same IP, delete all except the correct one. Right-click the extra record and choose 'Delete'. Confirm.
Also check forward lookup zones for the affected hostname—make sure it points to the correct IP. No aliases or duplicates.

Step 3 - Flush DNS on the client: Back on the affected machine, run these commands in an admin Command Prompt:

ipconfig /flushdns
ipconfig /registerdns

Then reboot. After the reboot, test your original action.

When none of these work

If you've done all three fixes and still get the error, you're looking at a deeper issue. Possibly a misconfigured domain controller that's running a stale version of the Kerberos service, or a trust relationship problem between domains. In that case, check the System and Security event logs on both the client and the DC for event ID 4 (Kerberos) or 5719 (netlogon). That'll point you to the real culprit.

One last quick thing—if you're running a legacy app that uses Kerberos delegation (like some old SharePoint or SQL Server setups), you might need to limit the SPNs in the app's configuration. That's rare, but it happens. Check the app's connection string or config file for multiple SPN entries.