Print | posted on Wednesday, March 31, 2010 8:53 AM
This is the first in a series of posts about using Kerberos with SharePoint 2010. This one is an easy introduction to using Kerberos for authentication in Classic Mode. My good buddy Ted Pattison likes to joke around with me that Kerberos is dead, thanks to the “new” world of claims based identity. But it is a joke! :) Kerberos is far from dead, and in many scenarios it is still the best choice for Authentication, if not Authorization within SharePoint 2010. For those of you who are fellow security geeks, you will know of course, that Kerberos is indeed a “claims based” system in and of itself.
Classic Mode is basically the same as in SharePoint 2007. It’s all about Windows Authentication – that is using domain credentials to sign in. However there are a couple of changes in the implementation to be aware of. Detailing those is the purpose of this post. I assume you already know how to implement Kerberos for SharePoint 2007. Properly mind, not the way the legion of dubious posts and articles out there describe :)
This example has a Web Application using Classic Mode Authentication (NTLM). By default SharePoint 2010 sets up a web application with this configuration. The web application hosts a Team Site with a couple of RSS Viewer Web Parts.
The first web part displays an RSS feed from another site in a different application pool on the same server. The second web part displays an RSS feed from another site on a different server (which is obviously in a separate application pool). Both of these sites are also configured with Classic Mode Authentication (NTLM).
As you can see the behaviour is the same as with SharePoint 2007. Neither web part can be displayed. Note we are viewing the page from a client machine, NOT the web server! Never test from a domain controller or the web servers! That’s really, really stupid! :)
On Windows Server 2008, if we go ahead and configure the web application to use Negotiate (Kerberos) using Central Administration, STSADM or PowerShell, the first web part will then work. We don’t need to actually implement Kerberos (an SPN) to enable the RSS Viewer for a feed on the same server, we just need to change the Authentication settings back to the IIS default (Negotiate, NTLM).
However on Windows Server 2008 R2, we will be prompted for authentication three times and the page will fail to load. This is because R2 uses the new SPNEGO2 implementation:
Therefore an SPN is required for the web application that consumes the RSS. Once we configure the SPN the first web part can be displayed:
Note that we do not need to configure Kernel-mode Authentication. There is a known compatibility issue with kernel-mode authentication and Internet Explorer 8. Therefore SharePoint 2010 disables kernel-mode authentication when creating web applications:
I do not recommend you configure kernel-mode authentication to use Application Pool Credentials with SharePoint 2010 at this point. If you are running on R2, then you must keep this disabled as this feature is not compatible with SPNEGO2.
Of course, the second web part still isn’t working, because for this we need to implement an SPN for the web application that hosts the feed, configure Kerberos for the application, and configure delegation from the application pool account to the new SPN. Once that is all done, both web parts display:
In summary, things are much the same. There are however a couple of key differences:
- SharePoint 2010 disables Kernel-mode authentication
- Windows Server 2008 R2 uses SPNEGO and therefore SPNs are required for the web application which consumes content on the same server. This is a good thing, it’s a more secure implementation.
In the next post I will talk about “advanced” delegation scenarios with Classic Mode Authentication.