Troubleshooting Kerberos issues is one of the least fun things to do. Mostly, because when it fails, there will be no error message. It will silently revert to NTLM, and you won’t know why.

I’ve been having a bit of fun getting our new Sharepoint 2010 install to work. I’ve set the SPNs correctly by using “setspn -a HTTP/thesharepoint.domain.co applicationPoolAccount”. This worked fine for one site, however the second one was still reverting to NLTM. Why?? I enabled kerberos tracking on the servers as per this KB – 262177. No errors that were relevant were recorded. I even started packet tracing the kerberos tickets. It was then that I noticed this error “KRB_ERR_S_PRINCIPAL_UNKNOWN” . Strange.. I re-checked, and the SPN (service principle name) was added so why is it unknown? After several hours of fiddling, I realised it was a duplicate SPN. Now, why the error message can’t say that, I don’t know. Infuriating. I found the duplicate SPN by running the following command:
ldifde -f check_SPN.txt -t 3268 -d “” -l servicePrincipalName -r “(servicePrincipalName=HOST/mycomputer*)” -p subtree
Obviously change “HOST\mycomputer” to the SPN you are checking. Delete the SPN with “setspn -d”. Having done this, kerberos now works well…