Overview of Kerberos authentication for Microsoft SharePoint 2010 Products

Applies to: SharePoint Server 2010

Microsoft SharePoint 2010 Products introduce significant improvements in how identity is managed in the platform. It is very import to understand how these changes affect solution design and platform configuration to enable scenarios that require user identity to be delegated to integrated systems. The Kerberos version 5 protocol plays a key role in enabling delegation and sometimes may be required in these scenarios.

This set of articles gives you information that helps you do the following:

• Understand the concepts of identity in SharePoint 2010 Products

• Learn how Kerberos authentication plays a very important role in authentication and delegation scenarios

• Identify the situations where Kerberos authentication should be leveraged or may be required in solution designs

• Configure Kerberos authentication end-to-end within your environment, including scenarios that use various service applications in SharePoint Server

• Test and validate that Kerberos authentication is configured correctly and working as expected

• Find additional tools and resources to help you configure Kerberos authentication in your environment

This set of articles is divided in two major sections:

• This overview of Kerberos authentication in SharePoint 2010 Products

  This article contains conceptual information about how to manage identity in SharePoint 2010 Products, the Kerberos protocol, and how Kerberos authentication plays a key role in SharePoint 2010 solutions.

• Step-by-step configuration

  This group of articles discusses the steps that are required to configure Kerberos authentication and delegation in various SharePoint solution scenarios.

Who should read these articles about Kerberos authentication?

Identity and delegation in SharePoint 2010 Products is a broad topic, with many facets and depths of understanding. This set of articles addresses the topic from both conceptual and technical levels and is written to address the needs of various audiences:

Beginning to end

"Tell me everything there is to know about Identity and Kerberos authentication in SharePoint 2010 Products"

If you are only starting out and learning about SharePoint 2010 Products, Kerberos authentication, and claims authentication, you will want to the read the first section of this document. It covers the basic concepts of identity and delegation and offers primers about Claims and Kerberos authentication. Be sure to follow the links to external articles and additional information to build a solid foundation of knowledge before continuing on to the step-by-step configuration articles.

Upgrading from Office SharePoint Server 2007

"Tell me what is changed from 2007 and what I should prepare for in upgrading to 2010"

If you have an existing Microsoft Office SharePoint Server 2007 environment already configured to use Kerberos authentication and Kerberos delegation, you should read the following articles:

• Identity scenarios in SharePoint 2010 Products

• Claims Primer

• Kerberos authentication changes in Windows 2008 R2 and Windows 7

• Kerberos configuration changes in SharePoint 2010 Products

• Considerations when upgrading from SharePoint Server 2007

If you have additional questions about how to configuration delegation for a particular feature or scenario, read the step-by-step configuration articles, especially the configuration checklists. This will help you ensure that your environment is configured correctly after upgrade.

Step-by-step walkthrough

"I want detailed step-by-step instructions on how to configure Kerberos delegation in SharePoint Server and applicable SharePoint Server service applications"

The step-by-step configuration articles cover several SharePoint 2010 Products scenarios which can be configured to use Kerberos delegation. Each scenario is covered in detail, including a configuration checklist and step-by-step instructions to help you successfully configure Kerberos authentication in your environment. The scenarios covered include the following:

• Scenario 1: Core Configuration

• Scenario 2: Kerberos Authentication for SQL OLTP

• Scenario 3: Kerberos Authentication for SQL Analysis Services

• Scenario 4: Identity Delegation for SQL Reporting Services

• Scenario 5: Identity Delegation for Excel Services

• Scenario 6: Identity Delegation for PowerPivot for SharePoint 2010

• Scenario 7: Identity Delegation for Visio Services

• Scenario 8: Identity Delegation for Performance Point Services

• Scenario 9: Identity Delegation for Business Connectivity Services

Be sure to thoroughly review the first core configuration scenario, because it is a prerequisite for all the scenarios that follow.

Existing SharePoint 2010 Product environments

"I have an existing SharePoint 2010 Product environment and I cannot seem to get Kerberos authentication working. How do I validate and debug my configuration?"

The Step-by-step configuration articles contain several checklists to help triage your environment in various scenarios. Pay special attentions to Scenario 1, Core configuration, which covers basic tools and techniques to triage Kerberos configuration.

Identity scenarios in SharePoint 2010 Products

When learning about identity in the context of authentication in SharePoint 2010 Products, you can conceptually look at how the platform handles identity in three key scenarios: Incoming authentication, inter/intra-farm authentication and outgoing authentication.

Incoming Identity

The incoming authentication scenario represents the means in which a client presents its identity to the platform, or in other words authenticates with the web application or web service. SharePoint Server will use the client's identity to authorize the client to access SharePoint Server secured resources such as web pages, documents, and so on.

SharePoint 2010 Products support two modes in which a client can authenticate with the platform: Classic mode and Claims mode.

Classic mode

Classic mode allows the typical Internet Information Services (IIS) authentication methods that you may already be familiar with from previous versions of SharePoint Server. When a SharePoint Server 2010 Web Application is configured to use classic mode, you have the option of using the following IIS authentication methods:

Integrated Windows authentication

Integrated Windows authentication enables Windows clients to seamlessly authenticate with SharePoint Server without having to manually provide credentials (user name/password). Users accessing SharePoint Server from Internet Explorer will authenticate by using the credentials that the Internet Explorer process is running under — by default the credentials that the user used to log on to the desktop. Services or applications that access SharePoint Server in Windows integrated mode attempt to authenticate by using the credentials of the running thread, which, by default, is the identity of the process.

NTLM

NT LAN Manager (NTLM) is be the default protocol type when Integrated Windows authentication is selected. This protocol takes advantage of a three-part challenge-response sequence to authenticate clients. For more information about NTLM, see Microsoft NTLM (https://go.microsoft.com/fwlink/p/?LinkId=196643).

Pros:

• It is easy to configure and typically requires no additional infrastructure/environment configuration to function

• It works when the client is not part of the domain, or is not in a domain trusted by the domain that SharePoint Server resides in

Cons:

• It requires SharePoint Server to contact the domain controller every time that a client authentication response needs validation, increasing traffic to the domain controllers.

• It does not allow delegation of client credentials to back-end systems, otherwise known as the double-hop rule.

• It is a proprietary protocol.

• It does not support server authentication.

• It is considered less secure than Kerberos authentication

Kerberos protocol

The Kerberos protocol is a more secure protocol that supports ticketing authentication. A Kerberos authentication server grants a ticket in response to a client computer authentication request, if the request contains valid user credentials and a valid Service Principal Name (SPN). The client computer then uses the ticket to access network resources. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). The KDC distributes shared secret keys to enable encryption. The client and server computers must also be able to access Active Directory directory services. For Active Directory, the forest root domain is the center of Kerberos authentication referrals. For more information about the Kerberos protocol, see How the Kerberos Version 5 Authentication Protocol Works (https://go.microsoft.com/fwlink/p/?LinkId=196644) and Microsoft Kerberos. (https://go.microsoft.com/fwlink/p/?LinkId=196645)

Pros:

• Most secure Integrated Windows authentication protocol

• Allows delegation of client credentials

• Supports mutual authentication of clients and servers

• Produces less traffic to domain controllers

• Open protocol supported by many platforms and vendors

Cons:

• Requires additional configuration of infrastructure and environment to function correctly

• Requires clients have connectivity to the KDC (Active Directory domain controller in Windows environments) over TCP/UDP port 88 (Kerberos), and TCP/UDP port 464 (Kerberos Change Password – Windows)

Other methods

In addition to NTLM and Kerberos authentication, SharePoint Server supports other kinds of IIS authentication such as basic, digest, and certificate-based authentication, which are not covered in this document. For more information about how these protocols function, see Authentication Methods Supported in IIS 6.0 (IIS 6.0) (https://go.microsoft.com/fwlink/p/?LinkId=196646).

Claims-based authentication

Support for claims authentication is a new feature in SharePoint 2010 Products and is built on Windows Identity Foundation (WIF). In a claims model, SharePoint Server accepts one or more claims about an authenticating client to identify and authorize the client. The claims come in the form of SAML tokens and are facts about the client stated by a trusted authority. For example, a claim could state, ”Bob is a member of the Enterprise Admins group for the domain Contoso.com."If this claim came from a provider trusted by SharePoint Server, the platform could use this information to authenticate Bob and to authorize him to access SharePoint Server resources. For more information about claims authentication, see A Guide to Claims-based Identity and Access Control (https://go.microsoft.com/fwlink/p/?LinkID=187911).

The kind of claims that SharePoint 2010 Products support for incoming authentication are Windows-Claims, forms-based authentication-Claims, and SAML-Claims.

Windows-Claims

In the Windows-claims mode sign in, SharePoint Server authenticates the client using standard Integrated Windows authentication (NTLM/Kerberos), and then translates the resulting Windows Identity into a Claims Identity.

Forms-based authentication Claims

In Forms-based authentication claims mode, SharePoint Server redirects the client to a logon page that hosts the standard ASP.NET logon controls. The page authenticates the client by using ASP.NET membership and role providers, similar to how forms-based authentication functioned in Office SharePoint Server 2007. After the identity object that represents the user is created, SharePoint Server then translates this identity into a claims identity object.

SAML-Claims

In SAML-Claims mode, SharePoint Server accepts SAML tokens from a trusted external Security Token Provider (STS). When the user attempts to log on, see comment is directed to an external claims provider (for example, Windows Live ID claims provider) which authenticates the user and produces a SAML token. SharePoint Server accepts and processes this token, augmenting the claims and creating a claims identity object for the user.

For more information about claims-based authentication in SharePoint 2010 Products, see SharePoint Claims-Based Identity.

Note about incoming claims authentication and the Claims to Windows Token Service (C2WTS)

Some service applications require that you use the Windows Identity Foundation (WIF) Claims to Windows Token Service (C2WTS) to translate claims within the farm to Windows credentials for outbound authentication. It is important to understand that C2WTS only functions if the incoming authentication method is either classic mode or Windows claims. If claims is configured, the C2WTS requires only Windows claims; the web application cannot use multiple forms of claims on the web application, otherwise the C2WTS will not function.

Identity within a SharePoint 2010 Products environment

SharePoint 2010 Products environments use claims authentication for intra- and inter-farm communications with most SharePoint service applications and SharePoint integrated products regardless of the incoming authentication mechanism used. This means that even where classic authentication is used to authenticate with a particular web application, SharePoint Products convert the incoming identity into a claims identity to authenticate with SharePoint Service Applications and products that are claims-aware. By standardizing on the claims model for intra/inter farm communications, the platform can abstract itself from the incoming protocols that are used.

Outbound identity

Outbound identity in SharePoint 2010 Products represents the scenarios where services within the farm have to authenticate with external line-of-business systems and services. Depending on the scenario, authentication can be performed in one of two basic conceptual models:

Trusted subsystem

In the trusted subsystem, the front-end service authenticates and authorizes the client, and then authenticates with additional back-end services without passing the client identity to the back-end system. The back-end system trusts the front-end service to do authentication and authorization on its behalf. The most common way to implement this model is to use shared service account to authenticate with the external system:

In SharePoint Server, this model can be implemented in various ways:

• Using the IIS application pool identity — usually achieved by running code in the web application that elevates permissions while making a call to an external system. Other methods such as using RevertToSelf can also use the application pool's identity to authenticate with external systems.

• Using a service account — typically achieved by storing application credentials in the Secure Store then using those credentials to authenticate with an external system. Other methods include storing the service account credentials in other ways such as embedded connection strings.

• Anonymous Authentication — this is where the external system requires no authentication. Therefore the front-end SharePoint Server service does not have to pass any identity to the back-end system.

Delegation

In the Delegation model, the front-end service first authenticates the client, and then uses the client's identity to authenticate with another back-end system that performs its own authentication and authorization:

In SharePoint 2010 Products, this model can be implemented in various ways:

• Kerberos delegation — If the client authenticates with the front-end service by using Kerberos authentication, Kerberos delegation can be used to pass the client's identity to the back-end system.

• Claims — claims authentication allows the client's claims to be passed between services as long as there is trust between the two services and both are claims-aware.

Delegation across domain and forest boundaries

The scenarios in this set of articles about Kerberos authentication require that the SharePoint Server service and external data sources reside in the same Windows domain, which is required for Kerberos constrained delegation. The Kerberos protocol supports two kinds of delegation, basic (unconstrained) and constrained. Basic Kerberos delegation can cross domain boundaries in a single forest, but cannot cross a forest boundary regardless of trust relationship. Kerberos constrained delegation cannot cross domain or forest boundaries in any scenario.

Some SharePoint Server services can be configured to use basic Kerberos delegation, but other services require that you use constrained delegation. Any service that relies on the Claims to Windows token service (C2WTS) must use Kerberos constrained delegation to allow the C2WTS to use Kerberos protocol transition to translate claims into Windows credentials.

The following service applications and products require the C2WTS and Kerberos constrained delegation:

• Excel Services

• PerformancePoint Services

• Visio Services

The following service applications and products are not affected by these requirements, and therefore can use basic delegation, if it is required:

• Business Data Connectivity service and Microsoft Business Connectivity Services

• InfoPath Forms Services

• Access Services

• Microsoft SQL Server Reporting Services (SSRS)

• Microsoft Project Server 2010

The following service application does not allow delegation of client credentials and therefore is not affected by these requirements:

• Microsoft SQL Server PowerPivot for Microsoft SharePoint

Claims primer

For an introduction to Claims concepts and Claims base authentication, see An Introduction to Claims (https://go.microsoft.com/fwlink/p/?LinkId=196648) and SharePoint Claims-Based Identity (https://go.microsoft.com/fwlink/p/?LinkID=196647).

Kerberos protocol primer

For a conceptual overview of the Kerberos protocol, see Microsoft Kerberos (Windows) (https://go.microsoft.com/fwlink/p/?LinkID=196645), Kerberos Explained (https://go.microsoft.com/fwlink/p/?LinkId=196649), and Ask the Directory Services Team: Kerberos for the Busy Admin (https://go.microsoft.com/fwlink/p/?LinkId=196650).

Benefits of the Kerberos protocol

Before examining the details of how one configures SharePoint Server (or any web application) to use the Kerberos protocol, let's talk about the Kerberos protocol generally and why you might want to use it.

Typically there are three main reasons to use the Kerberos protocol:

1. Delegation of client credentials — The Kerberos protocol allows a client's identity to be impersonated by a service to allow the impersonating service to pass that identity to other network services on the client's behalf. NTLM does not allow this delegation. (This limitation NTLM is called the "double-hop rule"). Claims authentication, like Kerberos authentication, can be used to delegate client credentials but requires the back-end application to be claims-aware.

2. Security — Features such as AES encryption, mutual authentication, support for data integrity and data privacy, just to name a few, make the Kerberos protocol more secure than its NTLM counterpart.

3. Potentially better performance — Kerberos authentication requires less traffic to the domain controllers compared with NTLM (depending on PAC verification, see Microsoft Open Specification Support Team Blog: Understanding Microsoft Kerberos PAC Validation). If PAC verification is disabled or not needed, the service that authenticates the client does not have to make an RPC call to the DC (see: You experience a delay in the user-authentication process when you run a high-volume server program on a domain member in Windows 2000 or Windows Server 2003). Kerberos authentication also requires less traffic between client and server compared with NTLM. Clients can authenticate with web servers in two request/responses vs. the typical three-leg handshake with NTLM. However, this improvement is typically not noticed on low latency networks on a per-transaction basis, but can typically be noticed in overall system throughput. Remember that many environmental factors can affect authentication performance; therefore Kerberos authentication and NTLM should be performance-tested in your own environment before you determine whether one method performs better than the other.

This is an incomplete list of the advantages of using the Kerberos protocol. There are other reasons like mutual authentication, cross platform interoperability, and transitive cross domain trust, to name a few. However, in most cases one typically finds delegation and security to be the primary drivers in adoption of the Kerberos protocol.

Kerberos delegation, constrained delegation, and protocol transition

The Kerberos version 5 protocol on the Windows platform supports two kinds of identity delegation: basic (unconstrained) delegation and constrained delegation:

Kerberos enabled services can delegate identity multiple times across multiple services and multiple hops. As an identity travels from service to service, the delegation method can change from Basic to Constrained but not in reverse. This is an important design detail to understand: if a back-end service requires Basic delegation (for example to delegate across a domain boundary), all services in front of the back-end service must use basic delegation. If any front-end service uses constrained delegation, the back-end service cannot change the constrained token into an unconstrained token to cross a domain boundary.

Protocol transition allows a Kerberos enabled authenticating service (front-end service) to convert a non-Kerberos identity into a Kerberos identity that can be delegated to other Kerberos enabled services (back-end service). Protocol transition requires Kerberos constrained delegation and therefore protocol-transitioned identities cannot cross domain boundaries. Depending on the user rights of the front-end service, the Kerberos ticket returned by protocol transition can be an identification token or an impersonation token. For more information about constrained delegation and protocol transition, see the following articles:

• Kerberos Protocol Transition and Constrained Delegation (https://technet.microsoft.com/en-us/library/cc739587(WS.10).aspx)

• Protocol Transition with Constrained Delegation Technical Supplement (https://msdn.microsoft.com/en-us/library/ff650469.aspx)

• Kerberos Constrained Delegation May Require Protocol Transition in Multi-hop Scenarios (https://support.microsoft.com/kb/2005838)

As a general best practice, if Kerberos delegation is required, one should use constrained delegation, if it is possible. If delegation across domain boundaries is required, then all services in the delegation path must use basic delegation.

Kerberos authentication changes in Windows 2008 R2 and Windows 7

Windows Server 2008 R2 and Windows 7 introduce new features to Kerberos authentication. For an overview of the changes, see Changes in Kerberos Authentication (https://go.microsoft.com/fwlink/p/?LinkId=196655) and Kerberos Enhancements (https://go.microsoft.com/fwlink/p/?LinkId=196656). In addition, you should make yourself familiar with IIS 7.0 Kernel Mode authentication (Internet Information Services (IIS) 7.0 Kernel Mode Authentication Settings, (https://go.microsoft.com/fwlink/p/?LinkId=196657)) even though it is not supported in SharePoint Server farms.

Kerberos configuration changes in SharePoint 2010 Products

Most of the basic concepts of configuring Kerberos authentication in SharePoint 2010 Products have not changed. You still have to configure service principal names and you still have to configure delegation settings on computer and service accounts. However there are several changes that you should be aware of:

• Constrained Delegation — required for services which use the Claims to Windows Token Service. Constrained delegation is required to allow protocol transition to convert claims to Windows tokens.

• Service Applications — In Office SharePoint Server 2007, the SSP services required special SPNs and server registry changes to enable delegation. In SharePoint 2010 Products, service applications use claims authentication and the Claims to Windows Token service, so these changes are no longer needed.

• Windows Identity Foundation (WIF) — the WIF Claims to Windows Token Service (C2WTS) is a new service leveraged by SharePoint 2010 Products to convert claims to Windows tokens for delegation scenarios.

Considerations when you are upgrading from Office SharePoint Server 2007

If you are upgrading an Office SharePoint Server 2007 farm to SharePoint Server 2010, there are several things you should consider as you complete the upgrade:

• If web applications are changing URLs, make sure that you update the Service Principle Names to reflect the DNS names.

• Delete the SSP service principal names, because they are no longer needed in SharePoint Server 2010.

• Start the Claims to Windows Token Service on the servers that are running service applications that require delegation (for example, Excel Services, Visio Graphics Service).

• Configure Kerberos constrained delegation with "use any authentication protocol" to allow Kerberos constrained delegation with the C2WTS.

• Ensure Kernel mode authentication is disabled in IIS.