Share via

Kerberos Authentication for IIS 7 and later

  • Article

The Very Basics

1. If still using Windows Server 2008 R2, install this hotfix (http://support.microsoft.com/kb/2545850) which makes Kerberos more reliable. Machine account password changes occur every ~30 days by default, so if your uptime is more than a fortnight, this might cause authentication difficulties at some point.

  1. Get the SPNs right (!) - an SPN must be registered against only one account - whether a user or computer account. If you've registered an SPN against more than one account, that breaks Kerberos. It doesn't always break authentication because NTLM is the fallback method, but it does break delegation ('logon failed for user null or anonymous'-type errors).

Which SetSPN Should I Use?

You should always use the Windows 2008 or later version of SetSPN as:

  • it supports the -S switch, which doesn't let you create duplicate SPNs accidentally
  • it can be used to search for duplicate SPNs without resorting to LDIFDE queries and exports

Other tips:

  • Never use SetSPN -A (use -S instead), as incorrect use of this command will create duplicate SPNs. Duplicate SPNs are bad.
  • If you suspect you have broken Kerberos, use SETSPN -X to search the domain for groups of duplicate SPNs.
  • If you suspect your problem might be elsewhere in the forest, SETSPN -X -F will query the forest, not just the domain.

IIS 7 introduces the ApplicationPoolIdentity account type (seen also as IIS AppPool\AppPoolName). This is considered equivalent to the computer account, for who-owns-the-SPN purposes.

Web Farms

 If you need Kerberos and you have a load balanced web farm, you must use a domain user account as the application pool account.
(Note that if you're setting this up later than 2015, a Group Managed Service Account (Group Managed Service Accounts Overview | Microsoft Docs) is preferable rather than a user account).

  • The SPN(s) must be registered against this account
    • The SPNs must be registered against only this account

Things that may also cause Kerb to web servers to fail:

  • Membership in a large number of groups:
    • HTTP.SYS registry entries must be configured for large token sizes
    • Request Filtering settings may need to be configured to allow larger header sizes
    • ASP.Net security settings may also need to be configured