Configuring Kerberos for SharePoint 2007: Part 1 – Base Configuration for SharePoint


(UPDATED on 04/06/07 as per feedback from two different subscribers (thank-you). Updates in Italic)


(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 dubious 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:



  • SQL Server Service Account: Account used by SQL to run all SQL services

  • Server Farm Account

  • SSP Service Account

  • Office SharePoint Server Search Account

  • Default Content Access Account

  • User Profile and Properties Content Access Account

  • Excel Services Unattended Account

  • One account per application pool: This is typically three accounts; SSPAdministration, MySite and your main ‘Portal’ or ‘Intranet’.

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:



  • Some services require the fully qualified domain name (FQDN) even if your users only use the host name. For example if user type http://portal to get to you main portal and you Active Directory is called Domain.local then the FQDN is Portal.Domain.Local

  • Some SPNs require the host name which is the FQDN without the .domain.local bit on the end. In the example above, this would simply be portal

  • For all user accounts you must include the domain prefix.

  • To make the table easier to understand, I have included an example for a single server farm in a domain called ‘Domain.local’ where the MOSS server is called ‘Server’ and I have three host headers for web applications which are called ‘My Site’, ‘Portal’ and ‘SSPAdmin’. The ‘least privilege account principle’ has been used in this example and the accounts are fairly descriptively named.































Command


Notes


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




  • Repeat the process for each of the following


    • MOSS Server (Computer Account)

    • SQL Server (Computer Account)

    • FarmService (User Account)

    • MySiteAppPool (User Account)

    • SSPAdminAppPool (User Account)

    • PortalAppPool (User Account)

  • Locate the account and click ‘properties’

  • Navigate to the ‘Delegation’ tab

  • Choose ‘Trust this user/computer for delegation to any service (Kerberos)’

Step 3: Enable Kerberos on your web applications


In MOSS 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:



  • Open Central Administration

  • Navigation to Application Management > Authentication Providers

  • Choose the web application you wish to configure from the drop-down in the top right corner (this includes the Central Administration web application)

  • Click on ‘Default’

  • Set the authentication to Negotiate (Kerberos)

  • IISRESET

Step 4: Enable Kerberos on your SSP


In this step you enable Kerberos on your SSP. Follow these steps:



  • Open a Command Prompt and navigate to your ’12\Bin’ directory (normally c:\program files\common files\microsoft shared\web server extensions\12\bin) 

  • Run ‘STSADM.exe -o SetSharedWebServiceAuthn -negotiate’

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:



  • Open Component Services on the MOSS server

  • Navigation to Component Services > Computers > My Computer

  • Click on Properties (for My Computer) > Default Properties > Default Impersonation Level = Delegate (see http://support.microsoft.com/kb/917409)

  • Navigate to Component Services > Computers > My Computer > DCOM Config > IIS WAMREG Admin Service

  • Click on Properties (for IIS WAMREG Admin Service) and navigate to the Security tab

  • Edit Launch and Activate Permissions

  • Grant all three of your application pool account ‘Local Activation’ permissions (see http://support.microsoft.com/kb/920783). In our example, these accounts would be domain\MySiteAppPool, domain\SSPAdminAppPool, domain\PortalAppPool

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:



  • Do your web applications work from a client computer? If they do, then this is a good sign

  • Keep an eye on your System event log on both your MOSS and SQL servers. Kerberos related errors are logged here.

  • Make sure all the servers in the loop (MOSS, SQL and Domain Controllers) have the same time set. Inconsistent time settings are one of the primary causes of Kerberos related issues.

If you have further difficulties, try these articles:


Comments (31)

  1. jam110480 says:

    What are the odds the part of this series is how to configure it to work with Reporting Services?  It seems like not what we try we cannot get reporting services configured unless we are using a trusted account.  We keep searching the newsgroups, but are finding nothing.

  2. This is the second of my several-part series on how to configure Kerberos for MOSS 2007. In the first

  3. gavinadams says:

    Hi Martin.

    Thanks for both of these posts on kerberos and excel services. This has been a life saver.

    I think there is a typo in step4.

    the 2nd url for the KB article doesn’t work.

    I think its meant to be KB# 920783?

    Thanks once again,

    Gavin

  4. Thanks for the note on the URL mistake – I have updated the article now.

  5. Your tutorials are incredibly helpful. Thank you so much!

  6. Welcome to a new site, I see alot of people are having problems with the SSL Kerberos or maybe its just

  7. During a recent POC, I was reminded (again) that the double-hop problem is a thorn in the side. For those

  8. I have had numerous problems getting SSL, Kerberos working throughout the SharePoint project I’m on,

  9. Siguiendo con la recopilación periódica de recursos sobre WSS 3.0 & MOSS, esta semana en el número

  10. James World says:

    Hi, This definitely isn’t the first blog post on this topic, and it certainly won’t be the last – but

  11. christian science monitor magazine free daily news

  12. What about Kerberos in SharePoint 2007… From Steve Carvajal's Blog , some links to Martin Kearn's

  13. If you've been through the install, you're probably ready to get Kerberos authentication. Now

  14. If you've been through the install, you're probably ready to get Kerberos authentication. Now

  15. You may recall we discussed Kerberos authentication here . And we linkd to two great posts, one, here

  16. You may recall we discussed Kerberos authentication here . And we linkd to two great posts, one, here

  17. After successfully implemented SCOM Reporting Server (with some help of course!) I get my hands dirty

  18. chrisg says:

    I sent out a collection of links that I have book marked on Kerberos and thought I would share them with

  19. If you want your credentials to pass throughout all your servers for PPS to work correctly, you really

  20. Coraz częściej w pracy stykam się z koniecznością ustawienia autentykacji poprzez protokół Kerberos ,

  21. Coraz częściej w pracy stykam się z koniecznością ustawienia autentykacji poprzez protokół Kerberos ,

  22. This is obviously one of the trickiest tools in the MOSS box. Previously, I referenced this industry

  23. Microsoft SharePoint Team Blog : MS Filter Pack released ! Usability of the SharePoint Wiki « Providing

  24. All about Martin Kearn …. I am a Senior Consultant within the UK SharePoint team in Microsoft Consulting

  25. I get asked a lot about what I put into a MOSS virtual machine, so the last time I built one, I actually

  26. I’m not sure why but Kerberos has the ability to send shivers down SharePoint Consultants spines….

  27. I’m not sure why but Kerberos has the ability to send shivers down SharePoint Consultants spines….