UPDATE: Spence posted a great comment pointing out some issues with this post. Richard then restored our Community Server DB to a point in time before the post, so it’s been wiped. Post again, Spence, please, as I didn’t get chance to copy the text of the comment, I’m afraid.
I’ve not been doing so well with blog posts lately. I have more than one currently in process but unposted, and I just can’t seem to get the time to finish them – so apologies, CSW, for not getting the article I promised up yet, but I am working on it.
However, I needed to write up the work I did on our SharePoint at the end of last week, which I thought warranted being made available to a wider audience, so this a quick but hopefully helpful post.
Kerberos, Service Principal Names and Application Pool Identities
I’ve been migrating our SharePoint farm from Server 2003 to Server 2008, and because we now also use Microsoft CRM and a few other systems that require it, I’ve been configuring kerberos.
In theory, this should be simple: We always create service accounts in the AD for each web application to run as, so each of those accounts needs the correct SPN’s creating to match the web site.
For example, if our internal domain is mycorp.com and our SharePoint site is Portal running as the portalapp account, then I would register the SPNs of http/portal.mycorp.com and http/portal against the portalapp account using either adsiedit or setspn. I then make sure that the account is trusted for delegation, which I can do through the delegation tab in the account properties dialog in Active Directory Users and Computers. I also make sure that the servers running SharePoint are trusted for delegation to any service in the same way. UPDATE: Spence pointed out that this is completely unnecessary, see the comments, below.
Once I’ve done all that, I can enable Kerberos on the SharePoint web application through Central Administration. If you’ve never done that, the Authentication Providers option is in the Application Security section (usually the right hand column) in Application Management. Make sure you have the correct web application selected and choose the zone you want to configure (if you haven’t extended your web application, that’ll be default). In the Edit Authentication page, simply tick Integrated Windows Authentication and toggle the radio button beneath to Negotiate (Kerberos). Apply the changes, and we’re done.
Or so you’d think…
To be fair, with Server 2003, that should be it. With Server 2008, however, things just didn’t seem to be working properly for me. So I consulted the Oracle (on a side note, I’m trying a new Oracle lately…).
Kernel-mode authentication. Great idea, shame about the configuration
It turns out the IIS 7 has changed the way it deals with authentication, in that it now executes authentication-related processes in kernel mode for security and performance. That’s all well and good, but it also transpires that because of that, it uses the Local System account for this, and that’s where we hit a snag: I’ve created the SPN’s on the wrong account – I would need to create them on the machine account for the hosting server. Except that won’t work if we’re using more than one server in our farm to host the web applications, because I can only set the SPN against a single account.
It turns out that there is a solution to this. Frustratingly, however, it can’t be done through IIS Manager (or at least, I couldn’t see a way – perhaps Andy Westgarth and the IIS boys can help me here?). Once again we need to edit the applicationHost.config file, just like we did for the bindings, previously:
- Finding the right section for this can be tricky. You’re looking for the
<location>section for your site, which then has a<system.webServer>section within it. I search on the site name (for example, our web site in IIS is SharePoint – Portal) because the line should look something like:
<location path=”SharePoint – Portal”> - Scroll down until you find the section. In there you should see an section and beneath that,
<windowsAuthentication>. It will probably say:
<windowsAuthentication enabled="true"> - Edit that line to read:
<windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true">
You’ll need to do an IISReset after that, or at least I did.
Am I the only person that thinks this should be a setting in the GUI somewhere – it’s such a fundamental issue if you’re using any kind of farm-based system (such as SharePoint or CRM) that I can’t believe it’s so hidden.
UPDATE: Spence also pointed out that appcmd lets you configure this. I’ll post more when I’ve learned how to do it myself.
Appcmd syntax and a hotfix
After Spence posted his comments I did more digging. The syntax for appcmd to make the change I describe above is:
appcmd set config “SharePoint – Portal” /section:windowsAuthentication /useAppPoolCredentials:true /commmit:MACHINE/WEBROOT/APPHOST
where you need to replace the stuff in quotes with the name of your site. You can get a list using appcmd:
appcmd list site
I also found a note about a hotfix related to this issue. If you see your server suffering from blue screens after configuring kerberos (I haven’t… yet) then this might help.
Finally, Spence posted a link to a set of useful slides covering just this topic – thanks Spence, I bet those were three great sessions. Hopefully I’ve now corrected the errors you pointed out and this post is back to being helpful!