IE HTTP Kerberos issues authenticating to site on FQDN not matching AD Domain

Question

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.

score 1 · Answer 1 · answered Jul 18 '14 at 18:16

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

I'll check the links. I see the browser go to the GC and get a ticket, then give the ticket to the webserver in the Negotiate header. The webserver refuses it as if it was an SPN issue. — TheSoftwareJedi, Jul 18 '14 at 18:48

score 0 · Answer 2 · answered Jul 19 '14 at 13:34

The problem had nothing at all to do with the domain being different. You can use any domain at all and as long as IE is configured correctly to pass the ticket, and the SPN is configured correctly in AD. Greg's answer provided me with several links which I encourage you to explore if you are coming here to solve an SPN issue.

I discovered that I needed to disable Kernel mode authentication, which also required that I unlock that configuration section. I also found that if the DNS entry for the site is a CNAME, Internet Explorer (but not Chrome) will use the name of the host that the CNAME is pointing to when creating the SPN ticket.

I had to configure the server to use the app pool credentials as such

<system.webServer>
   <security>
      <authentication>
         <windowsAuthentication enabled="true" useAppPoolCredentials="true" />
      </authentication>
   </security>
</system.webServer>

Understanding and configuring kernel mode

But in order to change that configuration block the following was required:

A colleague pointed me to the “Feature Delegation” icon at the root (computer) level of IIS Manager (Thanks, Ryan). Clicking into the Feature Delegation page shows a listing of features and their current override setting. With few exceptions each of the features can be changed to Read/Write, Read Only, or Not Delegated

Unlocking configuration sections

IE HTTP Kerberos issues authenticating to site on FQDN not matching AD Domain

2 Answers2