Kerberos for MOSS

I wanted to set our new MOSS Farm up to use Kerberos because, once setup, Kerberos provides many benefits over the default NTLM method.

Heck, even during the initial install, the installer recommends using negotiate over NTLM (although this contradicts this article: http://support.microsoft.com/kb/832769 which says more than once that NTLM is preferred - in my opinion, simply because it is "easier" to implement - next, next, next, okay, anyone?)

So, I did some research before starting. I read Martin Kearn's excellent post about it. I read all 2 official articles I could find specifically on the topic. I read the blurb's in the books we've acquired for MOSS. I spoke to our in-house Kerberos expert.

So, once I gathered up all of this information, which pretty much echoed Martin's post - I set to work, and ran into problems immediately.

We're running a small (3 server) farm, so all of the Web Applications (main portal, mysite application, spp admin application, central admin application, records center application) are all on the same physical machine, differentiated by either port numbers, or host headers.

Despite the farm's current small size, I wanted to 'do things the right way' and follow the least-privaledged account model, so each of the applications has its very own account in AD.

Our SPS 2003 instance was setup with a CNAME record for the desired portal name (aka host header) pointing back to the A record for the actual physical machine, so when I created the DNS records for the new MOSS environment, I followed my predecessor's lead and created CNAME records for mysite, records and portal, all pointing back to the A record for the physical machine.

I configured IIS WAMREG admin Service in DCOM config to allow all of the application pool accounts both 'Local Activation' and 'Local Launch' (by granting those permission to the WSS_WPG local group, so I wouldn't have to do it again later, when we created more new applications)

I set all of the accounts to be allowed to delegate Kerberos in AD, including the machine accounts.
I changed the default impersonation level for the machine to 'Delegate' from the default 'Identify'

Lastly, I created SPN's for everything.

using the following convention:

SETSPN -A HTTP/MOSSHOST DOMAIN\MOSS.Farm
SETSPN -A HTTP/mosshost.domain.local DOMAIN\MOSS.Farm
SETSPN -A HTTP/RECORDS DOMAIN\MOSS.Records
SETSPN -A HTTP/records.domain.local DOMAIN\MOSS.Records

I rebooted every machine in the farm (for good ol' Microsoft measure)
After all of the configuration, Kerberos simply would not authenticate.
When attempting to connect to the records application, for example, I was prompted 3 times for credentials, and errors were logged in the event logs on the MOSS server.
On the domain controller however, I saw 'Success' audits logged at the same time, for my account, coming from the MOSS server.

I noticed, during the aforementioned 3 login prompts that the source of the prompts was stated to be the FQDN of the actual machine - not the FQDN of my application record ( I was getting prompted by mosshost.domain.local, instead of records.domain.local.)

So, I created another SPN, as a test (fully knowing that I SHOULDN'T being doing this, because it would create a duplicate SPN)

SETSPN -A mosshost.domain.local DOMAIN\MOSS.Records

Suddenly, it worked - for about 15 minutes, until AD 'realized' there was a duplicate SPN in place. I had already created an SPN for mosshost.domain.local, linked to the Farm account (per Martin's post) Regardless of the farm account, duplicate SPN's would have been inevitable, considering 'records' was only 1 of 4 named applications.

So, going back to what I knew all along - that SPN's can't be duplicated, or you'll encounter problems - I deleted the newly created SPN, thus removing the duplicate.
For grins, I tried connecting to the records application again - and not surprisingly, was again prompted thrice, to eventually end up seeing the 401 - access denied page, just as before.

As a test, I tried avoiding the duplicate SPN's by appending the specific port number to a record, starting with the SSP Admin application, since it uses a non-default port in my environment.

SETSPN -A HTTP/mosshost.domain.local:12345 DOMAIN\MOSS.SSPAdmin

Still, it didn't work - I later found this article explaining why ports didn't work, despite the fact that MS recommends specifying a port in all of their articles about Kerberos and SQL (which are in much greater supply than articles about Kerberos and MOSS)

SQL and Kerberos article that inspired the attempted use of port numbers: http://support.microsoft.com/kb/319723/en-us
Despite not working for this problem - really good info, especially if one of your goals in using Kerberos with MOSS relates to SQL Reporting, etc.

Article that explains why ports wouldn't work for THIS problem: http://support.microsoft.com/kb/899900/en-us
Basically, you can't append a port number to an SPN, if the SPN is for the HTTP service...arggg.

So, frustrated, I decided to change my CNAME records into A records. Instead of pointing records.domain.local, mysite.domain.local etc back to mosshost.domain.local, I created a new A record for each desired host header and pointed it to the IP address for mosshost.domain.local and deleted the CNAME record.

It started working just fine. All of the SPN's were configured properly, IIS WAMREG was setup correctly. Everything had the correct delegation option in AD and had been all along.

I called Microsoft to get some help, since this seemed odd to me.
They confirmed my latest observation, but the explanation was a bit surprising, and a bit ironic.

Apparently, XP, running IE6 or IE7 has a bug with using CNAME records and Kerberos.
There's a hotfix, but, it's one of those have-to-ask-for-it hotfixes, and regardless, I'd much rather change a few DNS records than deploy not-quite-official-hotfixes to all of my clients.

Also, rather annoyingly, there is a published article which seems to indicate that CNAME records are fine with Kerberos.

The irony is that it seems Firefox can probably handle the CNAME references, but probably won't render everything in MOSS like IE6 and IE7 will...

Lesson Learned: Use A records for host headers in MOSS if you also want to use Kerberos for authentication.

This article mentions the XP bug (which I personally think is really an IE bug, because I'm running Vista on my client, and ran into the exact same behavior, but it's listed as an XP problem) http://support.microsoft.com/kb/911149/en-us

The article which seems to state that CNAME's and Kerberos play well together: http://support.microsoft.com/kb/870911/en-us - it's targeted at printers, but mentions using SPN's in tandem with Alias records.

Hopefully, this helps someone.

Jing

Tech-Smith has always been one of my favorite companies.
A coworker pointed me to their new project - Jing

not directly sharepoint related, but very cool - especially for the training and troubleshooting I'm sure I'm going to have to do.

http://www.screencast.com/t/jgovPgbA8KZ

The link above is an insanely easy screencast created with Jing demonstrating how to find Audiences within MOSS.

Jing itself (with all of their info) can be found here:
http://www.jingproject.com/

So good to be used

I'm just using this blog to throw notes and ideas about a SharePoint upgrade I'm working on. Since I end up at 18 different computers while I'm working through scenarios and testing options, I figured a spot out here on blogger would serve my needs until I get the SharePoint instance up and running (at which point I'll probably just use it instead)