Windows Server Kerberos and SPN Troubleshooting Checklist

Confirm the expected authentication path

First identify the client, service endpoint, service account and expected SPN. A Kerberos failure can be caused by infrastructure problems or an incorrect or duplicate service principal name.

Check DNS before SPNs

Kerberos depends on correct naming. Verify forward and reverse resolution where relevant and confirm that clients resolve the service name to the intended host. Do not troubleshoot SPNs while DNS is still wrong.

Inspect SPNs

Use setspn -Q to search for an SPN and setspn -L to inspect the account associated with a service. Duplicate SPNs can cause the KDC to issue tickets for the wrong account.

Inspect the client's tickets

Use klist to view cached Kerberos tickets. After correcting an account or SPN, purge stale tickets with klist purge and reproduce the issue.

Check time and identity

Kerberos is sensitive to time skew. Confirm the client, server and domain controllers have a healthy time hierarchy. Also verify that the service is actually running under the account you are inspecting.

Resolution order

DNS → service identity → SPN uniqueness → ticket cache → time → application configuration. Avoid deleting SPNs until you know which account should own the service identity.

Useful commands

setspn -Q HTTP/server.example.com
setspn -L DOMAIN\svcWeb
klist
klist purge
w32tm /query /status

Production checklist: capture the original state, test one dependency at a time, make the smallest controlled change and validate the original symptom before closing the incident.

What good troubleshooting looks like

Use evidence before configuration changes. Record the symptom, test result, change made and validation result so another engineer can repeat the procedure.

Workflow
Symptom → hypothesis → direct test → controlled change → validation → documentation

Frequently asked questions

What should I check first?

Start with the exact failed path or dependency and test it directly before changing configuration.

Should I change production configuration immediately?

No. Capture the current state first and make one controlled change at a time.

How should I document the fix?

Record the symptom, commands, result, configuration change and validation result.

Related TechRunbook guides

Primary reference

This guide was independently written for TechRunbook. Technical details were checked against current Microsoft documentation. Microsoft Learn reference →

Need more infrastructure runbooks?

Explore the TechRunbook article library for Windows Server, VMware, Hyper-V, Azure, PowerShell and MABS troubleshooting.

Browse all articles →