Kerberos in a Sharepoint Environment

Microsoft Windows Sharepoint Services (WSS) 3.0 and Microsoft Office Sharepoint Server (MOSS) 2007 are designed to centralize company information and help team members collaborate more efficiently. Users can access all the information that their individual user accounts are allowed to see from the Sharepoint websites. Because of this design you need to make sure that authentication is swift, secure and fits company policies.

In this article I will go through the basics of using Kerberos in a Sharepoint environment. You will find many configuration guides for different scenarios on the internet and I have put together some tips for you. I hope this can give you an overview to work from in your own environment.

Using Kerberos in Sharepoint?

Kerberos is a secure protocol that grants authentication tickets if the client’s request to the Key Distribution Center (KDC) contains valid user credentials and a valid Service Principal Name (SPN). Kerberos is the preferred authentication type for Sharepoint because it is faster, more secure, and reduces the number of errors you can get with username and passwords than NTLM. If the Sharepoint website uses external data (located on different servers than your Sharepoint server itself) ex. to SQL databases through webparts the Sharepoint server needs Kerberos to delegate the client credentials (the credentials are never sent over the wire, only tickets which the KDC keeps track of).

So what is happening between the client and the servers when you try to access a Kerberos enabled website? I have made a little visual overview to show what is going on “behind the scenes”. This scenario shown in Figure 1 is made up of Windows Sharepoint Services 3.0 which also is the base for MOSS. The Kerberos technology is the same – we just have more services and roles in MOSS.

Figure 1: Kerberos in Sharepoint flow

  1. Client accesses http://intranet.domain.local using anonymous credentials.
  2. The WSS Server returns IIS error 401.2
but also returns a WWWAuthenticate header.
  3. Client requests a ticket for the SPN created by the local internet browser: HTTP/intranet.domain.local
  4. The KDC returns the ticket if the SPN is found. This is encrypted using the registered account master key for the SPN (domain\spcontentpool).
  5. Client authenticates with the ticket for the web application.
  6. The Web App account decrypts the ticket and validates it.
  7. Web App account requests ticket for the SPN created by the SQL Client: MSSqlSvc/sql1.domain.local:1433.
  8. The KDC returns the ticket if the SPN is found. This is encrypted using the registered account master key for the SPN (domain\sqlsvsacct).
  9. The web application service authenticates with the SQL database using the Web App account ticket and impersonates the user using delegation rights.
  10. The SQL service account decrypts the ticket and validates it.
  11. The SQL Server returns the request data to the WSS Server.
  12. The WSS Server returns the webpage.

If Kerberos is not configured for SQL communications step 6 jumps to step 12. And remember the ticket granting only happens at first logon and lasts until timeout. Check out the links section for a flowchart in larger scale with built-in text on the arrows.

Configuring Kerberos for Sharepoint

First of all let me encourage you to create a test setup before reconfiguring your production environment. I know it is a pain but if you use virtual servers you can build test servers very quickly. This also allows you to compare the final configuration to if something is not working as expected.

So we need to retire the NTLM on our web applications and configure these to use Kerberos. First you enable this protocol for communication between the frontend and backend servers. Then you enable Kerberos between clients and individual web applications to handle the authentication through the Sharepoint server (some call it dual- or double-hop authentication).

Let’s take a look at the to-do list for setting this up.

  • Gather the required information and create Sharepoint users

  • Enable Kerberos for SQL communications

  • Configure Service Principal Names (SPNs) in Active Directory

  • Configure “Trust for delegations” on the computer/user accounts

  • Configure Component Services on the Sharepoint servers

  • Enable Kerberos for web applications and Shared Service Provider (SSP)

  • Test the Sharepoint environment=

Gather the required information

To make our implementation as painless as possible we need to have all the building blocks ready. I presume your environment is running Active Directory and every server has a unique IP address. This must be registered in your DNS server and no duplicates of this must exist in the forward or reverse lookup zone for Kerberos to work. Also all clients and servers must have the correct date and time as Kerberos uses this too for validation of the tickets and access to an internal DNS Server.

Before you install Sharepoint create appropriate users in Active Directory (see link-section for link to the official guidelines). If you already have created the accounts needed please continue reading.

Here is a list of information needed for setting up Kerberos in a Sharepoint environment.

  • The Service Class of the SPN
    (HTTP for WSS/MOSS web applications. MSSQLSvc for a default instance of SQL Server)

  • The host names of your SPNs (only hostname. Usually FQDN without the domain-part)
  • The Fully Qualified Domain Name (FQDN) of all web applications and servers
  • The port numbers or your SPNs (no port for WSS and MOSS web applications. 1433 for SQL)
  • The Active Directory accounts for your SPNs (Service and application pool accounts)

Enable Kerberos for SQL communications

Microsoft highly recommends doing this before installing Microsoft Sharepoint to ensure that your SQL communication is working. The configuration database is located on your SQL Server and if the connection is broken you need to fix it before the Sharepoint sites are up and running again. If you change the authentication after the initial installation at least shut down the Sharepoint services first to avoid data loss.

You enable Kerberos between the Sharepoint frontend server(s) to your SQL Server by:

  • Configuring the SPNs for it
  • Configuring Trust for delegation if you need to impersonate users for other services.

It is not necessary to enable Kerberos for SQL communications if you only need to authenticate clients to the Sharepoint frontend and not other data connections/Excel Services/SQL Reporting Services.

Configure Service Principal Names (SPNs) in Active Directory

The Service Principal Name mappings are used by Kerberos to allow a delegation of a service to impersonate a specific user account. An SPN contains a Service Class, hostname and sometimes a port number. Some examples are HTTP/intranet.domain.local and MSSqlSvc/sql1.domain.local:1433. It is good practice to register both the hostname and FQDN of your web applications even though you intend to use only one of them.

To configure Service Principal Names you can use several tools. I prefer the SetSPN-tool that is installed in Windows Server 2008 by default. For Windows Server 2003 it can be found in the Support tools on the installation CD-ROM or in the resource kit downloadable from Microsoft. You can also use ADSIedit to configure SPNs, but it takes a little more work navigating through your Active Directory and editing the items and changing their ServicePrincipalName.

Command for registering a SPN: setspn.exe -A HTTP/intranet.domain.local DOMAIN\Account
Command for listing SPN for an account: setspn.exe -L DOMAIN\Account
Command for deleting a SPN: setspn.exe -D HTTP/intranet.domain.local DOMAIN\Account

Use the tables in Figure 2 or 3 to see the needed registrations for your SQL in the MOSS/WSS scenario.

Figure 2: Delegation and SPNs for MOSS

Figure 3: Delegation and SPNs for WSS

Configure “Trust for delegations” on the computer/user accounts

Now we need to handle the delegation rights in Active Directory. This is done for the computer and user accounts you can see in the table above. In Active Directory Users and Computers right-click on the account, choose properties and check the delegation trust (see screenshots figure 4 and 5 below). The text/procedure can differ in different versions of Windows Server.

Figure 4: Delegation for computer account

Figure 5: Delegation for user accounts

See Figure 2 or 3 for which accounts to configure delegation in the scenario.

Configure Component Services on the Sharepoint servers

The web application pool accounts need to have certain rights or you will get a DCOM error with event id 10017 in your event log and described in Microsoft KB920783:

“The application-specific permissions settings do not grant Local Activation permission for the COM Server application with CLSID {CLSID} to the user DomainName\UserName SID {SID}. This security permission can be modified using the Component Services administration tool.”

For setting the correct security for the accounts simply go into the Control Panel, Component Services, Computers, My Computer, DCOM Config and edit the properties of the “IIS WAMReg Admin Service”. Edit “Launch and Activate” in the Security tab and give “Local Activation” rights for all the application pool accounts (see Figure 2 or 3).

While you are in Component Services set the “Default Impersonation Level” to “Delegate” by editing the properties of “My Computer”. Check the Microsoft KB917409 for more information.

Enable Kerberos for web applications and Shared Service Provider (SSP)

Okay, your base configuration should be almost done now. To use Kerberos you must enable this through the Central Administration for your web applications. We can choose between NTLM and Kerberos for the individual web applications on the Authentication Providers page which you will find in the Application Management pane. Follow this path for the configuration:

  • Central Administration, Application Management, Authentication providers

  • Choose your web application to the one you need to use Kerberos for, e.g. :


  • Click “Default”

  • Choose/check the Kerberos option:


Remember to restart your IIS with iisreset /noforce in a command prompt on your web front end servers.

In MOSS your Shared Service Provider must also be configured and you do this in a command prompt. The SetSharedWebServiceAuthn-command does not exist in WSS. Navigate to the 12-hive bin directory (usually placed in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin) and run the command: stsadm.exe -o SetSharedWebServiceAuthn -negotiate

Test the Sharepoint environment

Now comes the exciting part of the operation: making sure everything is working as we expect it to do. As any other person I check the configuration changes while I go through the procedures. It is a good thing to know if your SQL communication uses Kerberos before continuing with other steps. But how do we check the individual parts of the setup?

You simply check your security event log for Kerberos logon events. Check that the domain account used is succeeding. If the account is getting a log on failure, please check the following:

  • Date and time is set correctly on all servers
  • That the account is not locked in the domain
  • The service or application pool is running with the correct account
  • Delegation is configured correctly on the computer- and user accounts
  • The SPNs are configured correctly in Active Directory
  • No duplicates on the servers must exist in the DNS forward and reverse zones
  • DNS servers are specified correctly on all servers

Known Internet Explorer issue

If you are using non-default ports on your IIS Virtual servers please make sure your version of Internet Explorer 6 or earlier is patched and configured to include port numbers in SPNs. The Central Administration will contain a non-default port number. You do not get an error message saying this is the error if using an old or unconfigured version of Internet Explorer. Read the Microsoft article I have mentioned in the links section of this article regarding this issue. I have been told that Internet Explorer 7 had the same issue but has been fixed.


Microsoft Windows Sharepoint can be used in complex environments where secure authentication with Kerberos is needed. With this article I hope to have explained the “big picture” of Kerberos in a Sharepoint setup. The tools and base configurations are available so you can start using the great features of Sharepoint dual-hop authentication yourself.


Microsoft TechNet: Plan for administrative and service accounts

Microsoft TechNet: Configure Kerberos authentication  

Microsoft TechNet SetSPN-Tool documentation: SetSPN Overview

Microsoft Download SetSPN-Tool: Windows 2000 Server and Windows Server 2003 SP2 32-bit

Microsoft TechNet: Troubleshooting Kerberos Delegation

Microsoft Support: How to troubleshoot the “Cannot generate SSPI context” error message

Microsoft Support: Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port in Windows XP and in Windows Server 2003

Jesper M. Christensen blog: Kerberos in Sharepoint flow with build-in text

Jesper M. Christensen blog: Troubleshooting the Kerberos error KRP_AP_ERR_MODIFIED

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top