Kerberos error when using a DNS name that doesn't match the Active Directory domain name

Question

I am running into a weird issue with a new SQL Reporting Services server I built. I installed SQL Reporting 2014 on Windows Server 2012 R2 and configured Kerberos, but the site is extremely slow. After some reconfiguration and log captures I have determined
the issue has to do with the Kerberos setup but it is an exact replica of a Windows Server 2008 R2 server we currently have and it does not have these issues.
The error I see while using Wireshark is KRB Error: KRB5KDC_ERR_BADOPTION NT Status: STATUS_NO_MATCH.
When I drill down the into the error I can see the kerberos string is testprjmnmtreports14.company.com, which is the URL we are using to access the site. I made sure to add that name as an SPN for the service account that is running SQL Reporting Services,
however I still receive the error.
Then I tried configuring the site to run without a hostheader, so I accessed the site with the server name ECTSTSQLRS5 and the site works perfectly fine, no errors are reported either. So it seems I have isolated the issue down to Kerberos but I am not sure
how to resolve it. Here is some more information about my environment:
DNS/URL used: testprjmnmtreports14.company.com
Server Name (FQDN): ECTSTSQLRS5.company.int
AD Domain Name: company.int
Server Version: Windows Server 2012 R2
AD Functional Level: 2008 R2
I also have the following SPNs set for my SQL service account:
http/testprjmngmtreports14.company.com
http/testprjmngmtreports14
http/ECTSTSQLRS5.COMPANY.INT
http/ECTSTSQLRS5
As you can see I am trying to use a .com address but my AD domain is .int which I think is the issue, but I do not have the same problem on my other server that is running Windows Server 2008 R2. 
Has anyone see this issue before? What do I need to do to allow my new site on 2012 R2 to work with this DNS Alias?
Thanks,
Brandon

Answer 1

Hi
Quote from there; Kerberos errors in network captures
The most common scenario is a request for a delegated ticket (unconstrained or constrained delegation). You will typically see this on the middle-tier server trying to access a back-end server. There are several reasons for rejection:
1. The service account is not trusted for delegation
2. The service account is not trusted for delegation to the SPN requested
3. The user’s account is marked as sensitive
4. The request was for a constrained delegation ticket to itself (constrained delegation is designed to allow a middle tier service to request a ticket to a back end service on behalf on another user,
not on behalf of itself).
Regards, Philippe
Don't forget to mark as answer or vote as helpful to help identify good information. ( linkedin endorsement never hurt too :o) )
Answer an interesting question ? Create a
wiki article about it!