Orchestrating Kerberos Authentication .... SPN Cheat Sheet

Orchestrating Kerberos Authentication .... SPN Cheat Sheet

Rate This
  • Comments 7

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 : http://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 : http://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 : http://alpha/

setspn -A HTTP/alpha CustomDomainIdentity

setspn -A HTTP/alpha.example.com CustomDomainIdentity


Scenario IV

Website Application Pool Identity : CustomDomainIdentity

Website accessed with URL : http://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 : http://www.example.com

setspn -A HTTP/www.example.com CustomDomainIdentity

If the website is accessed with individual netbios names : http://alpha/ http://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
Leave a Comment
  • Please add 6 and 5 and type the answer here:
  • Post
  • OK - quick question

    >Scenario II

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

    >Website accessed with URL : http://www.example.com

    >

    >setspn HTTP/www.example.com alpha

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

    WHY???  I'm having an issue with this, and don't understand the issue between using a A record vs. a CNAME record.

    This KB http://support.microsoft.com/kb/870911 seems to indicate that SPN's and CNAMES are perfectly acceptible.

    >Scenario IV

    >Website Application Pool Identity : CustomDomainIdentity

    >

    >Website accessed with URL : http://www.example.com

    >

    >setspn HTTP/www.example.com CustomDomainIdentity

    Dose this have the same requirements with A vs. CNAME as Scenario II?

    We're in the process of configuring a lot more of our internal web sites to Kerberos Authentication rather then NTLM and are using CNAME alias and Host headers for our shared IIS.  Some sites are using CustomDomainIdentity (SharePoint installs, CRM), some Network Service.  

    We register both HTTP/<host> and HTTP/<host>.BankOfSomewhere.com to either the machine or account, but we are consistently seeing TGS-REP/TGS-REQ for HTTP/<MachineName> or HTTP/<MachineName>.BankOfSomewhere.com rather then for the URL.

  • 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.

  • Please clarify your comment regarding KB 870911:

    > To change this behavior and make IE request for a ticket with

    > SPN HTTP/www.example.com we have to make the changes

    > suggested in (KB870911). But this is a client side fix so it is

    > better to avoid :).

    I don't see anything in that article about client-side changes (except for ensuring they use DNS, of course).

    Is there a client-side change that will make IE request tickets for the SPN of the URL (the alias) rather than the SPN of the underlying host (to which the alias resolves)?

  • In scenario III, using a host name instead of a Cname (Alias) just fixed my Kerberos problem.

    Thanks!

  • 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.

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

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

Page 1 of 1 (7 items)