OMFG how many times must this happen in one project?! SharePoint (actually .NET Framework) does not work properly for Kerberos security resolution if you try and use CName records. Also they are a bad idea for a site anyway… because you cannot load-balance a Cname (a Cname just says “This Name maps to this server name” – gah!). I’m not sure why there’s such a high preference for Sysadmins to use Cnames. I suppose there must be an architecture reason, but it causes soooooo many problems! Here’s the info from someone at Microsoft…
When given the choice between using an A DNS record or a CNAME DNS record for your SharePoint web applications, favor an A record particularly if you are using Kerberos authentication. Reference the following TechNet article:
Of particular interest in this article is the following passage:
Kerberos authentication and DNS CNAMEs
There is a known issue with some Kerberos clients (Internet Explorer 7 and 8 included) that attempt to authenticate with Kerberos enabled services that are configured to resolve using DNS CNAMEs instead of A Records. The root of the problem is the client does not correctly form the SPN in the TGS request by creating it using the host name (A Record) instead of the alias name (CNAME).
A Record: wfe01.contoso.com
CNAME: intranet.contoso.com (aliases wfe01.contoso.com)
If the client attempts to authenticate with http://intranet.contoso.com, the client does not correctly form the SPN and requests a Kerberos ticket for http/wfe01.contoso.com instead of http/intranet.contoso.com
Details regarding the issue can be found in the following articles:
To work around this issue, configure Kerberos enabled services using DNS A records instead of CNAME aliases. The hotfix mentioned in KB article will correct this issue for Internet Explorer but will not correct the issue for the .NET framework (which is used by Microsoft Office SharePoint Server for web service communication).
What me and my team experienced is that a customer had a customization which interfaced with Exchange. The browser authentication to the web application appeared to be working fine, but the double-hop to Exchange was failing with a 401 error. All SPNs appeared to be correct. We changed the DNS records from CNAME records to A records and the authentication began to work as expected.