I have a site on a corporate domain that authenticates using Kerberos auto-login from IE and Chrome just fine, as long as the DNS being used to access it falls under the AD FQDN
The AD domain is not a public domain, for this example, lets call it company.internal.corp.net. Standard SPN is configured with the IIS domain user account such as HTTP/somesite.company.internal.corp.net mycompany\svc_iis, and IE is configured to see this site as an intranet site (allowing auto-login)
FQ AD Domain: company.internal.corp.net
NETBIOS domain name: MYCOMPANY
DNS for my website: somesite.company.internal.corp.net
IIS App Pool account: MYCOMPANY\svc_iis
SPN: HTTP/somesite.company.internal.corp.net MYCOMPANY\svc_iis
I've decided to change the DNS for this site to another name somesite.mycompanypublic.com in order to take advantage of the SSL certification chain on my public cert. I do not plan on making the site externally accessible. The DNS record will point to the same server for internal resolution and access only, and IE is configured to see this site as an intranet site (allowing auto-login). So now I have this setup:
FQ AD Domain: company.internal.corp.net
NETBIOS domain name: MYCOMPANY
DNS for my website: somesite.mycompanypublic.com <-- new DNS name, not same as AD domain
IIS App Pool account: MYCOMPANY\svc_iis
SPN: HTTP/somesite.mycompanypublic.com MYCOMPANY\svc_iis <-- new DNS name, not same as AD domain
With this new configuration, the DNS service name no longer matched the AD domain name, but I'm unclear if that should even matter
After configuring like above, Kerberos no longer works. IE prompts for a username/password for NTLM, chrome sometimes prompts and often times just gets a failure page. Fiddler traces show Kerberos tickets passing but the server rejecting everytime with another 401 every time. IE is configured to see this site as an intranet site (allowing auto-login), so that's not the issue – I see the tickets passing.
Is this configuration supported?
Troubleshooting ideas?
It behaves as if the SPN is not properly configured. I can provide fiddler traces or wireshark caps if desired.
Best Answer
The SPN does not need to match the AD domain. You do need to have an SPN that matches the name that is used to connect. I'm not sure what you mean by "Kerberos tickets passing". The HTTP Authorization header should begin with a "Negotiate Y" if Kerberos credentials are passed to the server.
Probably the quickest thing to do is setup the DelegConfig tool and use the report/wizard to test your configuration.
http://blogs.msdn.com/b/chaun/archive/2013/09/15/some-tips-on-setting-up-the-delegconfig-tool.aspx
http://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx
Troubleshooting ASP.NET
http://support.microsoft.com/kb/891032