We are currently setting up a SQL 2012 environment and it will be used for storing data that will be accessed by SSRS in sharepoint integrated mode. We will be using Kerberos for authentication.

Something we would like to be able to do is use cnames for the sql server. We are using the default instance and only require one instance per server.

What I am concerned about is the known issue with kerberos, IE/.NET, and CNAMEs. I was wondering if this configuration will work so long as I ensure that SPNs are properly setup for both the CNAME and the A-Record of the SQL server?


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.”


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.


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.



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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.