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
Client accesses http://intranet.domain.local using anonymous credentials.
The WSS Server returns IIS error 401.2
but also returns a WWWAuthenticate header.
Client requests a ticket for the SPN created by the local internet browser: HTTP/intranet.domain.local
The KDC returns the ticket if the SPN is found. This is encrypted using the registered account master key for the SPN (domain\spcontentpool).
Client authenticates with the ticket for the web application.
The Web App account decrypts the ticket and validates it.
Web App account requests ticket for the SPN created by the SQL Client: MSSqlSvc/sql1.domain.local:1433.
The KDC returns the ticket if the SPN is found. This is encrypted using the registered account master key for the SPN (domain\sqlsvsacct).
The web application service authenticates with the SQL database using the Web App account ticket and impersonates the user using delegation rights.
The SQL service account decrypts the ticket and validates it.
The SQL Server returns the request data to the WSS Server.
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
