Compartilhar via

Orchestrating Kerberos Authentication .... SPN Cheat Sheet

  • Artigo

When it comes to orchestrating Kerberos authentication on IIS websites most people get it wrong when the question of Service Principal Names (SPN) comes up. Microsoft PSS gets a huge number of such issues.

When you set a SPN you are telling the Key Distribution Centre (KDC) that a service of this type and this name is being provided by this account and you can issue Kerberos tickets for it.

Here I have put together a table of the most common configuration scenarios and the SPNs that are required. I am assuming the netbios name of your server is alpha and its FQDN is alpha.example.com. I am also assuming that you will use the setspn tool to set a particular spn.

Scenario I

Website Application Pool Identity : Preconfigured Identity (Network Service/Local Service/Local System)

Website accessed with URL : https://alpha/

Theoritically you will need the two spns below. But you do not have to set them as the netbiosname account will already have the HOST/ SPN which is  a superset.

setspn -A HTTP/alpha alpha

setspn -A HTTP/alpha.example.com alpha

You do not have to explicitly set these as the alpha account already has a SPN HOST/alpha by default.

Scenario II

Website Application Pool Identity : Preconfigured Identity (Network Service/Local Service/Local System)

Website accessed with URL : https://www.example.com

setspn -A HTTP/www.example.com alpha

Note : This URL entry has to be an Host (A) Record in the DNS and not a CNAME.

Scenario III

Website Application Pool Identity : CustomDomainIdentity

Website accessed with URL : https://alpha/

setspn -A HTTP/alpha CustomDomainIdentity

setspn -A HTTP/alpha.example.com CustomDomainIdentity

Scenario IV

Website Application Pool Identity : CustomDomainIdentity

Website accessed with URL : https://www.example.com

setspn -A HTTP/www.example.com CustomDomainIdentity

Scenario V

Load Balanced Website on servers alpha and beta

Website Application Pool Identity : CustomDomainIdentity(Mandatory)

Website accessed with URL : https://www.example.com

setspn -A HTTP/www.example.com CustomDomainIdentity

If the website is accessed with individual netbios names : https://alpha/ https://beta

setspn -A HTTP/alpha CustomDomainIdentity

setspn -A HTTP/alpha.example.com CustomDomainIdentity

setspn -A HTTP/beta CustomDomainIdentity

setspn - A HTTP/beta.example.com CustomDomainIdentity

Note : The custom domain identity running the application pool has to be added to the IIS_WPG group.

Remember : Internet Explorer treats URLs with a dot in it as an Internet Address. You have to explicitly tell IE to treat it as a Local Intranet website by adding it to the Local Intranet Zone.

 

Bookmark and Share

Comments

  • Anonymous
    October 23, 2007
    The comment has been removed

  • Anonymous
    November 15, 2007
    Chris,    The reason I suggested using an (A) record was to avoid confusion. When you have a CNAME record IE in the backgroud asks for a kerberos ticket with SPN as the host name(KB870911).  So say you have a machine named abc.example.com and you have a CNAME record saying www.example.com that points to the same machine.  While using Kerberos to browse www.example.com IE will request for a ticket with the SPN HTTP/abc.example.com   You can easily identify this with a network trace on the client machine.   To change this behavior and make IE request for a ticket with SPN HTTP/www.example.com we have to make the chagnes suggested in (KB870911). But this is a client side fix so it is better to avoid :).   Many users are not aware of this behavior so to be on the safe side I suggest using a A record. Note :Since IE is requesting for SPNS with HTTP/abc.example.com you can get away by settings that SPN for the custom domain account :) Also the behavior of IE has not changed with IE 7.

  • Anonymous
    January 02, 2008
    The comment has been removed

  • Anonymous
    January 10, 2008
    In scenario III, using a host name instead of a Cname (Alias) just fixed my Kerberos problem. Thanks!

  • Anonymous
    May 01, 2008
    I'd like to just say, Thank You.  I've been working with Windows Authenticated web apps running under custom identities for ages.  Getting the SPN entry correct for these has always been kindof a pain because none of the documentation is nearly as clear as this one single post. Your examples are clear and concise and are going to be bookmarked for me for the forseeable future.

  • Anonymous
    October 13, 2008
    Thanks for this article - I was doing the same thing as scenario III, and changing a CNAME to an A record fixed the problem.

  • Anonymous
    January 06, 2009
    On IIS 6.0 if your web application ran under a custom user account you would have to setup Service Principal