When opening the SharePoint site from another machine, Internet Explorer logs on with NTLM anyway. When opening the site from the server, a logon prompt appears which won't accept any credentials. After three times, an Unauthorized message is shown.
I had all Service Principal Names configured as described in Configure Kerberos authentication (Office SharePoint Server). To get more information I enabled Kerberos logging (How to enable Kerberos event logging), which resulted in a lot of events in the System log:
Message: "A Kerberos Error Message was received:
on logon session <user>
Server Time: 12:5:19.0000 10/30/2008 Z
Error Code: 0x34 KRB_ERR_RESPONSE_TOO_BIG
Server Realm: <domain>
Server Name: krbtgt/<domain>
Target Name: krbtgt/<domain>@<domain>
Error Data is in record data.
After using Network Monitor v3.2, I found that the Kerberos traffic from the server was requesting a different Service Principal Name than the url of the SharePoint site. The error which was also listed in the eventlog was returned by AD. The SPN that was send, contained the CNAME value instead of the original URL. Using Google, I found the following article:
The Problem with Kerberos Delegation (Section: "Confused Yet?")
This article states the following:
- Computer running IIS: ws.identitychaos.com (WS)
- Service Account hosting the Central Admin app pool: idchaos\svc.wss.farm
- Host Header for Central Admin: spca.identitychaos.com
- SPN's registered to idchaos\svc.wss.farm
Using a CNAME, when IE requests the SPN, spca.identitychaos.com resolves to ws.identitychaos.com (the alias resolves to the host) so IE asks AD, "tell me which account has an SPN registration of HTTP/ws.identitychaos.com" and it gets the WS computer account, not the service account. How do you fix it? You use A records instead of CNAME's.
After changing our CNAME records to A records, all Kerberos issues were resolved.
In other words:
Do not use CNAMEs when using Kerberos authentication!!!