If you've been through the install, you're probably ready to get Kerberos authentication working.

One time, I had a guy tell me "it's easy" and now I don't trust him.  It's not easy.

But, our new best friend Martin has a great explanation here and there's another explanation from James here.

So, I'm deploying a three server farm, WFE, DB and SSP, and I want to use Kerberos.  As I see it, there's three steps.

1. Add the SPN's to the user accounts.
2. Configure the accounts for delegation.
3. Configure the servers to support delegation.

Step 1.  Add the SPN's to the user accounts.

Which accounts?  Well that's a good question.  Microsoft suggests a number of accounts to support your multi-server farm.  I think I count 11 plus one for each web app pool and one for each search crawler other than the default.  Here's my list:

1. MyDomain\SQLServerSvc
2. MyDomain\MOSSSetup
3. MyDomain\MOSSDBAccess
4. MyDomain\MOSSSSPSvc
5. MyDomain\MOSSSearchSvc
6. MyDomain\MOSSCrawl_Default
7. MyDomain\MOSSProfileImport
8. MyDomain\MOSSExcelSvcs
9. MyDomain\MOSSWSSSearchSvc
10. MyDomain\MOSSWSSSearchContent
11. MyDomain\MOSSAppPool_01
12. MyDomain\MOSSAppPool_MySite
13. MyDomain\MOSSAppPool_SSP

You can see I'm going to use one App Pool for my portal content and then I'll have one each for SSP and MySites.

So the immediate question is "which accounts"? 

Well, Kerberos is used to support cases where the application has to connect to other applications to gather information on behalf of the current user.  In his article, James says to create SPNs for the App Pool accounts and the SSP Service account.  Martin says to create the SPNs for the DBAccess account and the App Pools. That would be:

1. MyDomain\MOSSDBAccess
2. MyDomain\MOSSAppPool_01
3. MyDomain\MOSSAppPool_MySite
4. MyDomain\MOSSAppPool_SSP

Then, my farm will route user requests to my various applications using host headers.  I'll have three and then, the machine name as follows:

1. MyPortal
2. MySite
3. MySSP
4. MyServer - this is the web front end host.

And, since users may fully qualify these host headers when they browse, that turns my four into eight like this:

1. MyPortal
2. MyPortal.MyDomain.com
3. MySite
4. MySite.MyDomain.com
5. MySSP
6. MySSP.MyDomain.com
7. MyServer
8. MyServer.MyDomain.com

In Martin's article, he says to map the two lists together like this to make seven SetSPN calls:

1. MyServer.MyDomain.com >> MOSSDBAccess
2. MyPortal >> MOSSAppPool_01
3. MyPortal.MyDomain.com >>MOSSAppPool_01
4. MySite >> MOSSAppPool_MySite
5. MySite.MyDomain.com >> MOSSAppPool_MySite
6. MySSP >> MOSSAppPool_SSP
7. MySSP.MyDomain.Com >> MOSSAppPool_SSP

So the two disagree regarding the SSP service account.

There's two things going on here.  First, the SPN is the HTTP/MyPortal part and it's assigned to the user account.  James reminds us that no two accounts can have the same SPN.  So the SPN is really the web app are we're creating four.

Second, when you try to trust a user for delegation, they must have an SPN installed first or you won't see the delegation tab.  So, documents say the "trust account for delegation" is on the Account tab.  It must have been at one point because I've seen screen shots.  In my DC, the user properties has an Account tab but it does not have the noted check box.  After running the SetSPN command on the username, the user properties will have a "delegation tab" where you tell it you're using Kerebos.

When I ran the install with my setup account, I was able to install both servers using the MOSSDBAccess account.  A peculiar step is required after you tell it, yes, I want to join an existing farm.  It wants to go to the  db server and find a config database for you.  Mine worked fine returning the SharePoint_config database as my only option.

 Martin follows up with instructions to enable Kerberos on exisitng CA and SSP apps.  Since mine are not installed yes, i can't imagine that's pertinent.

Then he says configure some windows components.  I'll get right on that.

 -robot