Kerberos and SharePoint

Keeping a SharePoint environment secure is one of the biggest challenges for an IT-Professional. Kerberos is the strongest Integrated Windows authentication protocol available so far. That is why it should always be used in a SharePoint Farm instead of NTLM.

Inferno, Canto VI, 12-35, Cerberus – From William Blake
https://commons.wikimedia.org/wiki/File:Cerberus-Blake.jpeg

Kerberos supports advanced security features including Advanced Encryption Standard (AES) encryption and mutual authentication of clients and servers. The protocol allows delegation of client credentials and from all the available secure authentication methods. It also requires the least amount of network traffic to the Active Directory controllers. Kerberos can reduce webpage loading latency in certain scenarios as well.

This post is

So why shouldn’t you implement Kerberos in your SharePoint environment after all? First of all, Kerberos authentication requires additional infrastructure and environment configuration to function correctly. In most cases, domain administrator permission is required to configure Kerberos authentication. If you misconfigure Kerberos, it can prevent successful authentication to your sites. Authentication with Kerberos requires client computer connectivity to a Kerberos Key Distribution Center (KDC) and to an AD DS domain controller. In a Windows environment, the KDC is also an AD DS domain controller. While this is a common network configuration on an organization intranet, Internet-facing deployments are typically not configured in this manner. For this Internet-facing SharePoint sites Claims is typically the better approach.

A simple SharePoint setup

Before we dive into the depths of the underworld, we’ll take a look of a rather simple SharePoint server installation.

In the Greek and Roman mythology Kerberos (Cerberus) is a multi-headed dog, or hellhound with a serpent tail and lions claws. He guards the entrance to the underworld to prevent the dead from escaping and the living from entering. Compared to your environment this definition makes your network the underworld, intruders from outside the living and your coworkers to walking dead.

How Kerberos works

The authentication process in a Kerberos environment begins at logon to the client computer. When a user enters his user name and password, the client computer sends the user name to the Kerberos Key Distribution Center (KDC). The KDC looks up the user’s master key (KA) in the database, which is based on the user’s password. The KDC creates then two items, a session key (SA) and a Ticket-Granting Ticket (TGT). The TGT includes a copy of the session key, the user name, and an expiration time. The KDC encrypts this ticket by using its own master key (KKDC), which only the KDC knows.

The client receives the TGT from the KDC and authenticates the user's password through a one-way hashing function, which converts the password into the user's master key. The client computer now has a session key and a TGT so that it can securely communicate with the KDC. The client computer is now authenticated to the domain and is ready to access other resources in the domain by using the Kerberos protocol.

In the following diagram you can see how the authentication via Kerberos and a SharePoint server works:

1. The User opens the website in his browser (http://host.domain.tld) and the web browser normally requests the page from the web server using anonymous credentials. Some browsers can use the session key provided by the KDC from the logon process instead. However we’ll assume here the user’s authentication must be redone.
2. The SharePoint Web Application is hosted by an IIS Application Pool, where the process is running under the credentials of the account “domain\WebAppSvc”. Unless the SharePoint Web Application is configured to support anonymous access, the IIS returns an error 401.2 and offers an authentication header as well.
3. The browser requests a Kerberos authentication for the Service Principal Name (SPN) http://host.domain.tld from the Kerberos Key Distribution Center (KDC).
4. The KDC creates a Ticket-Granting Ticket (TGT) for the SPN found. The ticket is then encrypted with the master key of the registered SPN account “domain\WebAppSvc”.
5. The browser uses the ticket returned from the KDC to authentication itself against the SharePoint Server. This is done by the Web Application process, which uses the master key to decrypt the ticket and validates the signature.
6. The Web Application tries to receive the data for the web site the browser is requesting from the SQL server. Therefor it must request a new Kerberos ticket to authenticate at the KDC for the SQL server SPN “MSSqlSvc/sql.domain.tld:1433”.
7. If a matching SPN is found, the new Kerberos ticket for the the Web Application Process is created. The ticket is encrypted with the master key of the registered SPN account “domain\SQLsvc”.
8. The Web Application then authenticates at the SQL server using the new Kerberos ticket and impersonates the user account using delegation rights.
9. If all validations are correct, the SQL returns the requested data to the Web Application Process. Together with the SQL data the web site is processed by the SharePoint server and then returned back to the user’s web browser.

If you are interested in how Kerberos works under the hood, you should go to techtarget.com and read the article on Kerberos there first. It gives you the full picture with every detail.

Preparing a SharePoint environment for Kerberos authentication

We’ll assume here you are working with Windows Active Directory on a local network and a SharePoint Intranet. But before you begin, you should use a testing environment to get all the moving bits and pieces together and write them down. I know a lot of IT-Pros love to jump right into action. However, if you goof up on Kerberos you might be spending more time on fixing your production environment, than you would have used to you setup a test stage in the first place.

We want to configure our Web applications to use Kerberos instead of NTLM. Therefore the communication for the protocol between the frontend and backend servers must be enabled. Then Kerberos communication between clients and the web applications is enabled. This is also called Double Hop authentication. If you like to learn more about Kerberos Double Hop, go visit this blog article at Technet.

Prerequisites

Before we implement Kerberos, we should have all the information needed ready. First of all your servers must have a unique IP-Address and these must be registered in your DNS servers with no duplicates in the forward or reverse lookup zones. Because Kerberos relies on DNS this is a must have and can cause some strange behavior if not properly configured. Particular in large organizations where identity management and networks are configured in different departments this should be taken in account.

Even though Windows servers sharing the same domain space and time is synced by default, you should check this point as well. The Kerberos Ticket-Granting Tickets rely heavily on timestamps generated by the system. Without all servers in sync, authentication will fail. Although it doesn’t really matter if the time is correct, the time on the servers just need to be in sync.

I’ll skip all SharePoint installation related topic and assume you have already created every necessary user account in Active Directory. For this tutorial I’ll use the following accounts. These can (and probably will) be named differently in your environment:

• domain\WebAppSvc – Account used by the Application Pool in IIS, that is hosting the Web Application
• domain\SQLsvc – Account used by the SQL server process to run the DB instance
• http://host.domain.tld – The URL of the Web Application hosting the SharePoint Site Collections
• sql.domain.tld – The URL of the SQL server instance hosting the SharePoint databases

These definitions are the same I used in the diagram, this way you should be able to track the different steps more easy. Beside the names of the servers and the user accounts, we’ll need the Kerberos Service Classes as well.

• HTTP – Service Class for all Web Applications in SharePoint
• MsSqlSvc – Service Class for the SQL server

The Service Class is needed when creating the SPN for the user accounts.

SQL server

Before you install or configure your SharePoint Farm, you need the SQL server. It is highly recommended you setup the Kerberos SQL configuration before you continue with SharePoint. Because all SharePoint data and even the configuration of the farm are stored inside of SQL, you risk data lost if your SQL setup isn’t working properly.

First you’ll need to create a SPN for the SQL server. I use the user account that was used to run the SQL instance. However the SQL server can be operated under the network service account, it would however then be a dead end. Because the network service account is restricted to the local server, Kerberos communication over the network must fail. In this case you should have a SQL instance running with the credentials of an active directory user account first.

To create a SPN you need administrative rights to access your active directory. Open a command shell and type:

setspn.exe -L domain\SQLsvc

Unless you have configured the SQL server user account already, this command should not return any information.

We will create two new SPN entries here. One for the full qualified hostname (FQDN) and one for the host name only. It's good practice to register both for your web application even though you use only one of them. To set the SPN use the following command:

setspn.exe -S MsSqlSvc/sql:1433 domain\SQLsvc
setspn.exe -S MsSqlSvc/sql.domain.tld:1433 domain\SQLsvc

The switch –S does the same as –A only with the difference it checks for duplicate entries in the active directory. This should be your primary choice when adding a SPN. Duplicate entries in your AD can lead to errors in Kerberos and should always be avoided.

Next the Kerberos service class. In this case we define a SQL Service why we use the MsSqlSvc service class followed by the hostname or the FQDN. The port number 1433 for the SQL service is attached and separated by a colon. If your SQL service is configured for a different port, you must change the port number for the SPN here as well.

If you run the command setspn.exe –L domain\SQLsvc again, you’ll find that this time the SPN has been added to the user account. To finish the configuration for the SQL, we need to configure the Trust for delegation for the user account as well. But before that, we’ll configure the SPN for the Web Application of the SharePoint server farm first.

SharePoint Server

The SPN mappings for the SharePoint Web application are the same as for the SQL service, except you use a different Kerberos service class. To register the SPN for the Web application uses the following command:

setspn.exe -S HTTP/host domain\WebAppSvc
setspn.exe -S HTTP/host.domain.tld domain\WebAppSvc

Instead of the URI of the SQL we use the URI of the Web Application after the –S switch. The HTTP service class is used for any kind of http traffic. This also applies to SSL encrypted traffic, even though one might think to use HTTPS instead. This however isn’t the case. If you encrypt your http communication you simple need to define HTTP as your service class.

In some documentation it’s suggested to use the SharePoint Farm account to map the SPN. I however prefer to use the account used to host the Web Application. If you are using Host Named Site Collections (HNSC) in your SharePoint environment, you must register the FQDN of the particular Site Collection to the corresponding Web Application account as well.

If you need to delete a SPN you have created, simply use the –D switch together with the service class, hostname and user account as parameter:

setspn.exe -D HTTP/host domain\WebAppSvc
setspn.exe -D HTTP/host.domain.tld domain\WebAppSvc

Trust for delegations

For everything to work correctly, the user accounts and the server machine accounts must be trusted for delegation. This is handled by the Active Directory Users and Computers Management Tool.

You must trust the following accounts for delegation:

Account	SPN	Delegation
Web Application IIS Application Pool Account All user accounts used to host Web Applications in a SharePoint Farm	HTTP/host.domain.tld domain\WebAppSvc	Yes
Service Application IIS Application Pool Account All user accounts used to host Service Applications in a SharePoint Farm	HTTP/service.domain.tld domain\ServiceAppSvc	Yes
SQL Service Account The user accounts used to host the SQL server instances	MsSqlSvc/sql.domain.tld:1433 domain\SQLsvc	Yes
SharePoint Server Computer Account All computer accounts of the servers in the SharePoint Farm	domain\host	Yes

Now that we know which accounts must be configured, let’s see how it’s done. If you haven’t done so far, open the Actice Directory Users and computers Management Tool and select the account you with to configure.

Open the settings of the AD object. You should find a register called Delegation.

If you cannot find the register you must check your SPN first. The setting for Delegation doesn’t appear in the management tool unless a SPN for the account was configured first.

Change the setting to “Trust this user for delegation to any service (Kerberos only)” to activate delegation for this account. If your environment is stricter on security, you can choose “Trust this user for delegation to specified services only” and “Use Kerberos only”. However in this chase, you will need to configure the endpoints and the services as well.

Problems with the Internet Explorer

There is a known problem with IE and how hostname resolution on the DNS Servers works. To keep it short, just make sure your hostnames are always declared as A-Records and never as CNAME.

For more information on this topic read one of my other blog articles “Why should you prefer A-records over CName in SharePoint”.

Done

There are two good documents about Kerberos debugging available from Microsoft. You should download these to your computer in case you'l need them.

Troubleshooting Kerberos Delegation
Troubleshooting Kerberos Errors


That’s all. I hope you’ll find this post informative and it can help you with the task to configure SharePoint and Kerberos. If you liked it, please don’t forget to write your friends at Facebook or Twitter and leave a comment below.