How to Setup Kerberos SPNs for SharePoint

This is a fairly short post about how to setup kerberos for SharePoint 2007 and 2010 written because it is a subject that frequently continues to baffle SharePoint consultants.


Kerberos authentication has been available since SharePoint 2003 yet most people are still using NTLM authentication. Why? NTLM is ancient and we all know that it works out of the box where Kerberos comes with a huge number of knowledge base articles and instruction to create Service Principal Names (SPNs) in your AD.

The reason for making the effort is that it enables you to solve the old double hop issue.

Ehh? When you are authenticated on a SharePoint server the server side code runs in “your name” with the privileges of your account. If however that server side code calls a second system, e.g. a web service, that second (the double hop) call is not authenticated and run with anonymous privileges. This is a limitation (or a security feature in your AD).

Now there are a number of ways around this problem, hardcoding some credentials in the server side, escalating privileges in the code, messing with the host file, etc. but the only good way is to use Kerberos.

Now when does this apply to SharePoint, where does it benefit from Kerberos? Then non-complete list is (additional suggestions welcome in the comments)

  • RSS viewer webpart
  • Page viewer webpart
  • Mail, calendar and task webparts (often used in MySites)
  • Excel services
  • Forms services
  • (and your custom code)

How to setup Kerberos

Now this is very far from a complete guide on Kerberos as it’s by far too long and too complicated for most people to read it. I’ll describe the simple bits needed to make SharePoint spin with Kerberos.

SharePoint setup

When you create a new web application you get the choice of using NTLM or Kerberos authentication. After creation you can always go into the authentication provider settings within the Central Administration and change it. Note: That a faulty Kerberos setup is virtually the same as bare NTLM 😉

SPN setup

The hardest part is to setup Service Principal Names in your AD to enable SharePoint to use Kerberos properly. Basically a SPN is an entry into the AD allowing a specific service account for a service (e.g. HTTP) to re-authenticate a user.

The trick is of course what exactly should go into these SPNs and how many you need. The answer is:

  • One for each URL you are serving
  • One for each combination of server and app pool service account (if you are like me you’ll have multiple)

You use the “SetSPN.exe” program to do this and you need very high privileges to do so. Domain Admin or equivalent is sufficient 😉 though it could have been delegated to lower ranks. Note that this can be executed on any server in your domain not only the SharePoint servers.

The major point of this post is that I’ve created a small PowerShell script to generate a bat file that will create the SPNs required.

Given a config file (CreateSPNBatFile_config.xml) like this:

 <?xml version="1.0" ?> <Config> <Servers> <Server name="moss1" domain="" /> <Server name="moss2" domain="" /> <Server name="moss3" domain="" /> </Servers> <Urls> <Url hostheader="intranet" serviceaccount="contoso\sa_intranet" /> <Url hostheader="" serviceaccount="contoso\sa_extranet" /> </Urls> </Config> 

The script (CreateSPNBatFile.ps1) (download here if quotes and stuff are messed up):

# Create a bat file for SPN creation based on config file # # 2010 Søren L. Nielsen function CreateSPNBatFile( $configFile, $outputFile ){ $config = [xml] (Get-Content $configFile) $output = "" #Gather all the service accounts $serviceAccounts = @{} foreach( $url in $config.Config.Urls.Url ){ $output += "Setspn.exe -A HTTP/" + $url.hostheader + " " + $url.serviceaccount + "`r`n" $serviceAccounts[ $url.serviceaccount.ToLower() ] = 1 } foreach( $server in $config.Config.Servers.Server ){ foreach( $serviceAccount in $serviceAccounts.Keys ){ #every combination of server and service account $output += "Setspn.exe -A HTTP/" + $ + "." + $server.domain + " " + $serviceAccount + "`r`n" } } $output += "pause`r`n" Set-Content -LiteralPath $outputFile -Value $output Write "Batch file $outputFile created" } CreateSPNBatFile "./CreateSPNBatFile_config.xml" "./CreateSPN.bat" 

Will generate the following bat file (CreateSPN.bat):

Setspn.exe -A HTTP/intranet contoso\sa_intranet Setspn.exe -A HTTP/ contoso\sa_extranet Setspn.exe -A HTTP/ contoso\sa_extranet Setspn.exe -A HTTP/ contoso\sa_intranet Setspn.exe -A HTTP/ contoso\sa_extranet Setspn.exe -A HTTP/ contoso\sa_intranet Setspn.exe -A HTTP/ contoso\sa_extranet Setspn.exe -A HTTP/ contoso\sa_intranet pause 

Ready to ship off to your domain administrator.

Trust for Delegation (Updated)

You need to configure the servers to be trusted for delegation in the AD (sorry I don’t know the command line). The procedure is:

  1. On any computer in the domain start Active Directory Users and Computers (“dsa.msc”)
  2. In the left pane, click Computers.
  3. In the right pane, right-click the name of your SharePoint server, and then click Properties.
  4. Click the Delegation tab (or General for WinSrv2000), click to select the Trust computer for delegation check box.
  5. Repeat step 3 and 4 for every SharePoint server in your farm including the SQL server

And you also need to configure the service accounts the same way (provided that they are domain accounts):

  1. On any computer in the domain start Active Directory Users and Computers (“dsa.msc”)
  2. Locate your service account in your AD (I generally prefer to search for the samAccountName)
  3. click Properties on the service account
  4. Click the Delegation tab (or General for WinSrv2000), click to select the Trust this user/computer for delegation to any service (Kerberos)  check box.
  5. Repeat step 3 and 4 for every service account in your farm including SQL account


Kerberos uses port 88 to communicate with the AD server therefore that port need to be open between the AD and your servers. There likely are a bunch of additional ports – ask google not me.


There are of course a number of ways to test this – look at the list above.

I generally start by enabling fiddler and check that the authentication part looks like a Kerberos ticket – fiddler will tell you this on the “Auth” tab.

The easiest test is to go to a list and get the RSS feed url. Then add a RSS viewer webpart to a page with that URL. If Kerberos works (for that site! You need to test all) you should see the list feed with the same elements as you would browsing directly to the RSS url.

If it does not work you’ll see the RSS feed as an anonymous user (note: Pick a list without anonymous access).

There are a large number of potential problems that would make this fail. Kerberos is very hard to debug – I can’t help you all but do try some of Microsofts tools.

I hope this help some of you with Kerberos. I had to hunt down a surprising number of post, documents and trial runs to compile this. Sorry for not sharing them all I simply don’t recall all of them as I did the installation over a year ago.

Note: If some users cannot authenticate but others get a “400 bad request” have a look here.


About Søren Nielsen
Long time SharePoint Consultant.

One Response to How to Setup Kerberos SPNs for SharePoint

  1. Carlos says:

    Good post, it helped me to clarify the different parts. The delegation in the users were my issue, so thanks!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: