Monday, 23 April 2007
How to configure kerberos for SharePoint 2007
This article was published at GitHub. It is open source and you can make edits, comments etc.
(UPDATED on 20/08/07: My colleauge James World has just published an excellent article which is a kind of follow-up to this one. It goes a bit deeper on Kerberos basics and covers some real-world tips that relate specifically to SharePoint. Check it out here: http://blogs.msdn.com/james_world/archive/2007/08/20/essential-guide-to-kerberos-in-sharepoint.aspx )
At some point during a career working with SharePoint, everyone will be given the task of configuring Kerberos authentication. I've done this a few times with SPS 2003 in the past, but despite my previous experience, it is a complex and difficult task to undertake if you don't know how. As with most things, if you have the right info, it is really quite easy. This is the first of a several-part series that outlines what you need to do to enable Kerberos in a MOSS 2007 environment. This article (part 1) will focus on how to get Kerberos working for just MOSS; the later articles will then expand on that to include Excel Services, Data Connections and SQL Server 2005 Analysis Services.
Why Kerberos? There are many reasons why Kerberos authentication can be used rather than the default NTLM, the main reason should be because it is faster and more secure than NTLM. It should really be the default choice for any SharePoint deployment on this basis, however in the SharePoint world the main reason is normally to get around the 'double hop' authentication issue. I am no security expert and I am sure there are better explanations out on the web somewhere (try here) but my simple understanding of a 'double hop' is where a user authenticates to a web server and that web server then needs to impersonate the user against another service. When this happens, the user's authentication ticket is 'hopping' across two services; this is not allowed in NTLM and you will have to user Kerberos to do this. In SharePoint, 'double hops' are most commonly seen when webparts need to access other web services or databases. In MOSS 2007, the most common scenarios are around Excel Services, Data Connections and connecting to SQL Server Analysis Services cubes. (I.e. 'hopping' from the Excel services webpart to the SQL analysis cube).
Step 1: SPNs The first thing you need to do in order to enable Kerberos for SharePoint is configure Service Principle Names (SPNs) for your SharePoint service accounts in Active Directory. Here lies the first stumbling block... depending on your configuration it is very hard to figure out which SPNs need to be applied to which accounts. If you are installing SharePoint properly, you'll use the 'least privilege account principle'; this basically means that each distinct service inside the SharePoint farm will have its own domain user account. These accounts should have the minimum privileges that they need to perform their jobs. There is a great document which goes into detail on each different account (8+ accounts) here, however in summary, you should have the following accounts:
SPNs are used by Kerberos to ensure that only certain accounts have permission to delegate a specific service on a user's behalf. An SPN needs to be configured for each service and address that the account needs to delegate for. SPNs are configured by using SetSPN.exe (download here) which is a command line provided as part of the Windows 2003 resource kit. This table outlines the commands that are required to create the right SPNs for each of the relevant SharePoint service accounts, however please bear the following points in mind:
|Setspn.exe -A HTTP/%SHAREPOINTSERVERFQDN% %SERVERFARMACCOUNT%||%SHAREPOINTSERVERFQDN% = the FQDN of your SharePoint server's NetBIOS name (local machine name) %SERVERFARMACCOUNT% = Server Farm Account Example: Setspn.exe -A HTTP/server.domain.local domain\serverfarm|
|Setspn.exe -A HTTP/%MYSITEURLFQDN% %MYSITEAPPPOOLACCOUNT%||%MYSITEURLFQDN% = the FQDN of the host header for the My Site Web Application %MYSITEAPPPOOLACCOUNT% = The application pool account that the My Site web application uses Example: Setspn.exe -A HTTP/mysite.domain.local domain\mysiteapppool or Setspn.exe -A HTTP/server.domain.local domain\mysiteapppool|
|Setspn.exe -A HTTP/%MYSITEURLHOST% %MYSITEAPPPOOLACCOUNT%||%MYSITEURLHOST% = the host name (i.e. without the .domain.local bit) for the My Site web application %MYSITEAPPPOOLACCOUNT% = The application pool account that the My Site web application uses Example: Setspn.exe -A HTTP/mysite domain\mysiteapppool or Setspn.exe -A HTTP/server domain\mysiteapppool|
|Setspn.exe -A HTTP/%PORTALURLFQDN% %PORTALAPPPOOLACCOUNT%||%PORTALURLFQDN% = the FQDN of the host header for the main portal or intranet Web Application %MYSITEAPPPOOLACCOUNT% = The application pool account that the Portal web application uses Example: Setspn.exe -A HTTP/portal.domain.local domain\portalapppool|
|Setspn.exe -A HTTP/%PORTALURLHOST% %PORTALAPPPOOLACCOUNT%||% PORTALURLHOST % = the host name (i.e. without the .domain.local bit) for the Portal web application %MYSITEAPPPOOLACCOUNT% = The application pool account that the Portal web application uses Example: Setspn.exe -A HTTP/portal domain\portalapppool|
|Setspn.exe -A HTTP/%SSPADMINURLFQDN% %SSPADMINAPPPOOLACCOUNT%||% SSPADMINURLFQDN % = the FQDN of the host header for the SSP Administration Web Application % SSPADMINAPPPOOLACCOUNT % = The application pool account that the SSP Administration web application uses Example: Setspn.exe -A HTTP/sspadmin.domain.local domain\sspadminapppool|
|Setspn.exe -A HTTP/%SSPADMINURLHOST% %SSPADMINAPPPOOLACCOUNT%||% SSPADMINURLHOST % = the host name (i.e. without the .domain.local bit) for the SSP Administration web application % SSPADMINAPPPOOLACCOUNT % = The application pool account that the SSP Administration web application uses Example: Setspn.exe -A HTTP/sspadmin domain\sspadminapppool|
Step 2: Trust for Delegation In addition to setting the SPNs for each of your service accounts, you also need to trust each of the computer accounts and some of the service accounts for delegation. Trusting for delegation means that the accounts are allowed to delegate on a user's behalf. In order to trust for delegation you need to open Active Directory Users and Computers as a user with domain administration rights and follow these instructions
Step 3: Enable Kerberos on your web applications In SharePoint 2007, the switch between Kerberos and NTLM is very simple and is undertaken via Central Administration. If you are creating your farm from scratch, be sure to set Central Administration itself to use Kerberos which you can set as part of the 'SharePoint Products and Technologies Configuration Wizard', however if the farm is pre-created you can easily enable Kerberos by following these steps:
Step 4: Enable Kerberos on your SSP In this step you enable Kerberos on your SSP. Follow these steps:
Step 5: Component Services Configuration This is one of the lesser documented steps. You need to set various permissions in Component Services. Follow these steps:
How do you know it has worked? The thing with Kerberos is that it can be difficult to see if it is working properly. There are several things you can do to check:
If you have further issues, try these articles:
Got a comment?
All my articles are written and managed as Markdown files on GitHub.
Please add an issue or submit a pull request if something is not right on this article or you have a comment.
If you'd like to simply say "thanks", then please send me a .