Configure Kerberos authentication

A few weeks ago I tried to set up a SharePoint farm that uses Kerberos authentication. I always thought it was just a setting in SharePoint but infect it is much more than that.

What is Kerberos

Kerberos is a computer network authentication protocol, which allows nodes to communicate over a non secure network to prove their identity to one another.

Kerberos makes use of a trusted third party for the authentication, termed a Key Distribution Center (KDC) which consists of two parts: an Authentication Server (AS) and a Ticket Granting Server (TGS). Kerberos works on the basis of tickets which serve to prove the identity.

For communication between two entities, the KDC generates a session key which they can use to secure their interaction. A KDC runs on every domain controller as a function of the Active Directory Domain Services (AD KS).

Why use Kerberos

There are many reasons why u should use Kerberos authentication rather than the default NTLM. The main reason is because it is more secure than NTML. Besides this reason you should also use it to get around the “double hop” (http://support.microsoft.com/kb/329986) authentication issue. The most common scenarios for the double hop issue with SharePoint are around Excel services and Data Connection.

Setting up Kerberos authentication

To make use of Kerberos nothing needs to be changed if the domain controller is set-up correctly. Kerberos clients are configured to request ticket-granting tickets (TGT’s) of the Kerberos Key Distribution Center automatically. If the ticket is received successfully the Kerberos client saves the ticket on the locale machine.

One of the first things you should consider when you want to use Kerberos authentication is which accounts you will be using for your services and web applications. Those accounts will have to get a Service Principal Name. The servers you will be using will have to allow delegation.

To trust a computer for delegation

  1. Click Start, point to Program Files, point to Administrative Tools, and then click Active Directory Users and Computers.
  2. Navigate to the computer account that needs to be set, for example, Active Directory Users and Computers/<domain name>/Computers/<computer name>.
  3. Double-click the computer name in the list on the right pane. On the Account tab, select the Account is trusted for delegation check box and then click OK.

If every server in the farm is trusted for delegation you can start creating SPN’s (Service Principal Names) for the accounts you will be going to use for SQL Server and the SharePoint farm.

Service Principal Names

Service principal names are associated with the security principal (user or groups) in whose security context the service executes. Service Principal Names are created with a specific Syntax.

Service Principal Name syntax:

The basic syntax of service principal name is as follows:

[service type]/[instance name]:[port number]/[service name]

The elements of the syntax have the following meaning:

  • service type: Type of service, such as “http” for the http protocol.
  • instance name: Name of the instance of the service. Depending upon the service type, it is either the name or IP address of the host running the service.
  • port number: Number of the port used by the service on the host, if it is different from the default for the service type.
  • service name: Name of the service. The name can be the DNS name of a host, of a replicated service, or of a domain; or it can be the distinguished name of a service connection point object or of an RPC service object.

Note: When you use Kerberos authentication with SharePoint you have to know that Internet Explorer does not send the port number with the service principal name. For example for this address https://intra.motion10.com:443 the SPN will be http/intra.motion10.com.

How to create a SPN in Active Directory

To create a SPN for an account you have to follow the following steps.

Create the SPNs for your SQL Server service account
  1. Log on to your Active Directory domain controller using the credentials of a user that has domain administrative permissions.
  2. In the Run dialog box, type ADSIEDIT.MSC.
  3. In the management console dialog box, expand the domain container folder.
  4. Expand the container folder containing user accounts, for example CN=Users.
  5. Locate the container for the SQL Server Service account, for example CN=mosssqlsvc.
  6. Right-click this account, and then click Properties.
  7. Scroll down the list of properties in the SQL Server Service account dialog box until you find servicePrincipalName.
  8. Select the servicePrincipalName property and click Edit.
  9. In the Value to Add field, in the Multi-Valued String Editor dialog box, type the SPN for example MSSQLSvc/sqlserver:1433 and click Add.
  10. Click OK on the Multi-Valued String Editor dialog box, and then click OK on the properties dialog box for the SQL Server service account.

Important: You cannot give two accounts the same Service Principal Name. This will cause the authentication to fail or fall back on NTLM if it is possible.

After you created the Service Principal Names you have to trust the accounts for delegation:

Trust accounts for Delegation

Windows server 2003 Active Directory

  1. On the Domain controller, click Start, point to Programs, point to Administrative Tools, and click Active Directory Users and Computers.
  2. Under your domain, click the Users folder.
  3. Under your user account, click Properties.
  4. Navigate to the “Delegation” tab.
  5. Choose “Trust this user/computer for delegation to any service (Kerberos)“.

Windows server 2000 Active Directory

  1. On the Domain controller, click Start, point to Programs, point to Administrative Tools, and click Active Directory Users and Computers.
  2. Under your domain, click the Users folder.
  3. Under your user account, click Properties.
  4. On the Account tab, select the Trusted for delegation check box.
  5. Under the account that you are trying to delegate, clear the Account is sensitive cannot be delegated check box.

Note: If you do not have the delegation tab in the user properties you will have to use the steps of the Windows server 2000 Active Directory. This is because Windows 2003 Active Directory can run a in a 2000 mode.

Configure Kerberos for SQL server

Kerberos for SQL server has to be configured before you can install SharePoint Server 2007. This means we have to create a SPN for the SQL service account:

  • Service type: MSSQLSvc
  • Instance name: SQLSERVER / SQLSERVER.mydomain.com
  • Port number: 1433 (default SQL communication port)

The SPN’s will be:

  • MSSQLSvc\SQLServer:1433
  • MSSQLSvc\SQLServer.mydomain.com:1433

Testing the Kerberos authentication for SQL Server

If you have configured the SPN’s for the SQL service account you can test if it works by following the following steps.

  1. Run SQL Server Management Studio in another server in the domain.
  2. Connect to you SQL Server.
  3. Check if Kerberos authentication is used by running the event viewer on your SQL host server and examine the Security log. In this log you should have a Success Audit that has used the Kerberos protocol.

If there isn’t a Success Audit that uses the Kerberos protocol you can check the following:

  • Is the SPN in active directory correct?
  • Do I have two accounts in Active Directory that have the same SPN?

Configure Kerberos for your Web Applications

If you want your web applications to make use of Kerberos you have to create Service Principal Names for the accounts that will used for running the web applications.

If have written down a few examples of SPN’s of several addresses of web applications.

Internet address Service Principal Name
http://intra.motion10.com http/intra.motion10.com
https://intra.motion10.com http/intra.motion10.com
http://mossadmin:43433 http/mossadmin
http://mysites.intranet.com http/mysites.intranet.com

Testing the Kerberos authentication for the web application authentications

If you have created SharePoint web applications that use Kerberos authentication, you are ready to test your configuration by following the following steps:

  1. Start internet explorer and navigate to the web application that has Kerberos authentication enables and login.
  2. On the SharePoint server open the event viewer and examine the Security log. In this log you should have a Success Audit that has used the Kerberos protocol.

Configure the SSP Infrastructure for Kerberos

For the SSP infrastructure to use Kerberos you have to follow the following steps:

  1. Register a new SPN for the SSP Service.
  2. Configure the SSP infrastructure to use Kerberos

Register a new SPN for the SSP Service

For the SSP infrastructure to use Kerberos a few new SPN’s need to be created. This is because the SSP infrastructure runs on every server in the SharePoint farm. It is also bound to the following ports TCP 56737 en TCP 56738 and the SPN also needs to include the name of the Shared Service Provider.

So you have to create a separate SPN for each server in the farm. In the following table you will see a few examples.

Computer Name:

MOSSQUERY

Name Shared Service Provider

SSP

MSSP/MOSSQUERY:56737/SSP

MSSP/MOSSQUERY:56738/SSP

Computer Name:

MOSSQUERY

Name Shared Service Provider

SharedServices4

MSSP/MOSSQUERY:56737/SharedServices4

MSSP/MOSSQUERY:56738/SharedServices4

Computer Name:

MOSSCRAWL

Name Shared Service Provider

SharedServices1

MSSP/ MOSSCRAWL:56737/ SharedServices1

MSSP/ MOSSCRAWL:56738/SharedServices1

 

Configure the SSP infrastructure to use Kerberos

After you created the Service Principal Names for the SSP Infrastructure you have to inform the SSP infrastructure to use Kerberos. You can inform the SSP infrastructure by using the stsadm tool.

To configure your SSP infrastructure to use Kerberos authentication, perform the following procedure:

  1. Log on to your Active Directory domain controller using the credentials of a user that has domain administrative permissions.
  2. On one of your servers running Office SharePoint Server 2007, open a command prompt.
  3. Change to the following directory: %COMMONPROGRAMFILES%\microsoft shared\web server extensions\12\bin.
  4. Type the following command: stsadm –o setsharedwebserviceauthn –negotiate, and then press ENTER.

After following all the steps you successfully configured your SharePoint farm to use Kerberos authentication.

Related Posts

SharePoint Rest API Handler SharePoint contains a lot of Rest API’s that can be used for many scenario’s. You could use them for example in desktop and windows phone applications...
User automatically removed from SharePoint Group During my current project we received an access request from a user. We did what we normally do, we checked the request and added the user in the appr...
Warm Up Form Based Web Application Normal warm up scripts for SharePoint open a site object or web object and make a request to that specific site. When you use form based authenticatio...
Load modules by default when opening PowerShell At the moment we are working a lot with PowerShell in combination with SharePoint. Over time we created a lot of usable functions that were not availi...
PowerShell Scripts During my current project we are using a lot of PowerShell scripts to administrate the environment and make development easier for us. In this post...
TFS and SharePoint Builds including Automatic deployments – Part 1 Part 1 of this series will instruct how to configure your build server for building SharePoint projects. In Part 2 we will discuss the automatic deplo...

Leave a Reply

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