IIS - Do I need to use a SPN?

A SPN, or Service Principal Name, is something that is often encountered when deploying web applications.  It can be used in corporate LANs with Active Directory/Kerberos to assist silent single-sign-on.

I am no expert on the subject of Kerberos, nor SPNs, but encounter them from time to time and have to wrack my brain for the how-to.  A new scenario recently was using a trusted domain for hosting a web-site and authentication wasn't working.  Was a SPN the thing we needed?

No.  Simple as that, although it took some messing around to realise that.  Most of the documentation out there I see, suggests that a SPN is required if you're using a service-account on your application pool (which we were), or not using the NetBIOS name of the server to connect to (which we weren't).  But this doesn't seem to be the case.

The setup we're looking at is this:

• 'SVCS' Active Directory domain, running shared services.
• 'USRS' Active Directory domain, where users logon to.
• 'site.acme.com', the URL for the site we want to serve.

We running our application pool under the identity of 'USRS\oursite' to provide authentication to other resources, such as databases.  There is no impersonation being performed by the site.

When users connect to 'site.acme.com', they need to silently authenticate as their logged in user.  By default, a login box is displayed.  Adding a SPN can help here, but what we were finding with this was, that any referral security groups in the SVCS domain were not being discovered, and the site did not know what security groups in SVCS, users from USRS were members of.  When there was no SPN, the site could view all the memberships, but the user was prompted for credentials.

Negotiate

But to achieve silent single-sign-on didn't need the SPN, it can be done well enough just by telling the client browser to try it.  For IE/Edge, this is done through Internet settings and adding the site to the Local Intranet zone.  The browser will then try to use Negotiate to login transparently.

DNS

There was one other gotcha, DNS.  In my initial testing, I was using a HOSTS file entry and everything was working swimmingly.  Once I shifted to using a DNS record, I started to see the logon prompt again for the site.  This it seemed to be done to the DNS record type, for convenience we were using CNAME (aliases) to point to the web-server, it makes things slightly easier if you suddenly need to shift all your sites to a new box and for some reason can't reuse the name (obscure, I know).  It was this though that was causing a problem.  When we switched these DNS records to use full A records (direct resolution to an IP) the prompt went away.

Checklist

So my new check-list for transparent SSO before pulling out setspn.

1. Is the site setup in DNS with an A record?
2. Is the FQDN bound to the site in IIS?
3. Is Windows Authentication enabled in the IIS Authentication options for the site, and all other methods disabled?
4. Is the FQDN listed in the "Intranet Zone" in Windows?

Other things to ignore

These settings are involved with the authentication process, and may be required in some scenarios, just not a simple (ish) one like this.

• useAppPoolCredentials (system.webServer/security/authentication/windowsAuthentication)
• useKernelMode

Neither of these options had any impact whichever way they were set.