Kerberos is an authentication method developed at MIT. The idea behind it is that a third party that is trusted will grant a “ticket” that is utilized to prove the identity of users. Kerberos is the default authentication method used by Windows Servers since Windows 2000. The purpose behind Kerberos is to ensure that the identity of users is secured as well as to protect the network resources that will be accessed by these users. The use of the keys and tickets provides additional security to interactions across the network. The key is used to secure the interactions while the ticket is used to prove the identity.
Why do we need Kerberos with SharePoint? SharePoint is a server technology, however, not all data that is utilized in SharePoint lives in SharePoint. By that, I mean that you have the capabilities, especially with SharePoint 2010 to access data that is stored in other applications and databases. Accessing this data often requires credentials to be passed across from one server to another server. This is known as a “double-hop.” Another time you see this out of the box is with RSS. Because the RSS feeds within SharePoint can be used to aggregate data from other SharePoint sites, you may want to make use of these, however, often in load balanced situations, you may see the same double-hop issue. There are also some third party tools that may be used to access this data that will also require Kerberos to be implemented.
The good news? You can implement Kerberos when you set up SharePoint. It is best if this is done from the initial deployment. However, if you already have your SharePoint farm in production, you can still go back and change the authentication methods for your web applications to Kerberos and set the SPNs appropriately and your sites will still be accessible, and more than likely, your users will never know the difference. The username and password will still be collected from the user the same way. One thing it is important to note here is that the users may have to ensure that the sites are in the trusted or local intranet zones in order for the authentication to work correctly. This can easily be set via group policy and pushed out to your users, or you can send instructions on how to manually add the sites to these zones.
I am working on a series of articles around Kerberos and will include the technical details of moving an existing SharePoint 2010 implementation from NTLM to Kerberos. Keep an eye out for the next posting!
This article is cross-posted here.