Kerberos auth to SQL or an internal web app fails, I suspect SPN issues.
Service Principal Names (SPNs) link a service to an AD account. With duplicate or missing SPNs Kerberos auth fails and you fall back to NTLM, or it stops working entirely.
Try this first
- 1Find duplicate SPNs: setspn -X (across the whole forest). An SPN may exist only once.
- 2For SQL: SPNs go on the service account if SQL runs under a domain account, not on the computer account. Format: MSSQLSvc/server.fqdn:1433 and MSSQLSvc/server.fqdn:instance.
- 3For IIS: SPN on the app pool identity. Format: HTTP/siteurl and HTTP/siteurl.fqdn. 'HTTP' uppercase.
- 4Wrong or duplicate SPN: setspn -D to remove, setspn -A on the correct account. Document what you change.
- 5Test: klist purge on the client, reconnect, klist shows a ticket for the right service. On failure: Event 4 on the client (KDC_ERR_S_PRINCIPAL_UNKNOWN or KRB_AP_ERR_MODIFIED).
When to bring us in
For gMSA (group Managed Service Accounts) SPNs are managed automatically. Recommended for modern SQL installs, saves manual SPN upkeep.
See also
- One DC or two DCs for an SMB office?Two is almost always the right answer; one DC is a single point of failure for logon, DNS and GPOs.
- Should I split FSMO roles across two DCs?For a small domain all on one DC is fine; with two DCs splitting is tidier but not required.
- How do I know my AD replication is healthy?Replication errors creep in silently; they only surface when logins or GPOs misbehave.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.