Will kerberos work with CNAMEs if I have the SPN created for the A record as well?

At first I wanted badly to say no you can't do that, but on second thought, go for it.

"“You must register the Kerberos service principal names (SPNs), the host name, and the fully-qualified domain name (FQDN) for all the new DNS alias (CNAME) records. If you do not do this, a Kerberos ticket request for a DNS alias (CNAME) record may fail and return the error code KDC_ERR_S_SPRINCIPAL_UNKNOWN.”

http://blogs.msdn.com/b/karang/archive/2009/12/12/why-do-we-need-spn-for-file-server-nas-ras-file-share-system-dna-alias-cname.aspx

For follow up I can confirm that the kerberos connection is established correctly. Thanks for the link as it confirms that only a CNAME is needed as long as the SPN is created for the SQL Cluster Name.

http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/fa0a38ef-106a-4521-b4f3-a62c60f89a99

Technically, because SQL Server SPNs include an instance name (if you are using the second-named instance on the same computer), you can register the DNS host for the cluster as a CNAME alias and avoid the CNAME issue described in Appendix A, Kerberos configuration known issues (SharePoint Server 2010). However, if you choose to use CNAMEs, you have to register an SPN using the DNS (A) record host name for the CNAME aliases.

http://msdn.microsoft.com/en-us/library/gg502606.aspx

You can register an SPN for a CNAME. We do it where I work and it works.

Most of the links in the answers do not work any longer and none of the answers are entirely correct.

Here is one correct answer: Kerberos Error APP_MODIFIED when using a CNAME DNS record

And here is another one: https://argonsys.com/microsoft-cloud/library/using-computer-name-aliases-in-place-of-dns-cname-records/

Sum-up: you need to register SPNs for the machines behind your A-records, not your CNAME-records. For a Windows-box, aliasing is better done with this command instead of CNAME-DNS entries:

netdom computername <HOST> /Add:<ALIAS>

this keeps both DNS and SPNs automatically up-to-date.

A possible reason CNAMES may have "worked" for some is because they either did not notice the automatic fallback to NTLM or they had DisableStrictNameChecking enabled. Or they had the SPNs registered to both the CNAME and the A-record, which then of course works as well.

To prove my answer, here is a test done in my environment. The screenshot is obfuscated for privacy reasons.

we can observe

1. browser is opening testgrc.domain.local
2. DNS contains a CNAME entry pointing to grc.domain.local
3. DNS lookup is asking for testgrc.domain.local, DNS server responds with the target of the CNAME-record "grc.domain.local", and the IP of this host
4. browser initates a kerberos request to the domain controller for grc.domain.local (NOT grctest.domain.local)

i ran the same test with MS SQL Management studio, and the same result can be observed. Kerberos works correctly when the SPN is registered to the host that the CNAME is pointing to (the A-record), not the CNAME itself.