Plan for Kerberos authentication (SharePoint Foundation 2010)

 

Applies to: SharePoint Foundation 2010

Microsoft SharePoint Foundation 2010 supports several methods of authentication. Deployments that require secure authentication, client identity delegation, and low network traffic can choose Kerberos authentication. For more information, see Plan authentication methods (SharePoint Foundation 2010).

In this article:

• Kerberos authentication and SharePoint 2010

• Kerberos authentication and claims-based authentication

Kerberos authentication and Microsoft SharePoint Foundation 2010

Why you should consider Kerberos authentication	Why Kerberos authentication might not be appropriate for a deployment scenario
Kerberos is the most secure Integrated Windows authentication protocol, and supports advanced security features including Advanced Encryption Standard (AES) encryption and mutual authentication.	Kerberos authentication requires additional configuration of infrastructure and environment to function properly. In many cases, domain administrator permission is required to configure Kerberos. Kerberos authentication can be difficult to set up and manage. Misconfiguring Kerberos can prevent successful authentication to your sites.
Kerberos enables delegation of client credentials.	Kerberos authentication requires client computer connectivity to a Key Distribution Center (KDC), and client computer connectivity to an Active Directory Domain Services (AD DS) domain controller. In a Windows deployment, the KDC is an AD DS domain controller. While this is a common network configuration in a corporate environment, Internet-facing deployments are typically not configured this way.
Kerberos supports mutual authentication of clients and servers.
Of the available secure authentication methods, Kerberos requires the least amount of network traffic to domain controllers. Kerberos can reduce page latency in certain scenarios, or increase the number of pages that a front-end Web server can serve in certain scenarios. Kerberos can also reduce the load on domain controllers.
Kerberos is an open protocol that is supported by many platforms and vendors.

Kerberos is a secure protocol that supports an authentication method that uses tickets provided by a trusted source. Kerberos tickets represent the network credentials of a user who is associated with a client computer. The Kerberos protocol defines the way in which users interact with a network authentication service to gain access to network resources. The Kerberos KDC issues a ticket to a client computer on behalf of a user. After a client computer establishes a network connection to a server, the client computer requests network access by presenting the Kerberos authentication ticket to the server. If the request contains acceptable user credentials, the KDC grants the request. For service applications, the authentication ticket must also contain an acceptable Service Principal Name (SPN). To enable Kerberos authentication, the client and server computers must already have a trusted connection to the KDC. The client and server computers must also be able to access Active Directory Domain Services (AD DS).

Kerberos delegation

Kerberos authentication supports the delegation of client identity. This means that a service can impersonate an authenticated client’s identity. Impersonation enables a service to pass the authenticated identity to other network services on behalf of the client. Claims-based authentication can also be used to delegate client credentials, but it requires the backend application to be claims-aware. Several important services are not currently claims-aware.

Used in conjunction with Microsoft SharePoint Foundation 2010, Kerberos delegation enables a front-end service to authenticate a client and then use the client’s identity to authenticate to a backend system. The backend system then performs its own authentication. When a client uses Kerberos authentication to authenticate with a front-end service, Kerberos delegation can be used to pass a client's identity to a backend system. The Kerberos protocol supports two types of delegation:

• Basic Kerberos delegation (unconstrained)

• Kerberos constrained delegation

Basic Kerberos delegation and Kerberos constrained delegation

Although basic Kerberos delegation can cross domain boundaries within the same forest, basic Kerberos delegation cannot cross a forest boundary. Kerberos constrained delegation cannot cross domain boundaries or forest boundaries. Depending on the service applications that are part of a SharePoint Foundation 2010 deployment, implementing Kerberos authentications with SharePoint Foundation 2010 can require the use of Kerberos constrained delegation. Therefore, to deploy Kerberos authentication with any of the following service applications, SharePoint Foundation 2010 and all external data sources must reside in the same Windows domain:

• Excel Services

• PerformancePoint Services

• InfoPath Forms Services

• Visio Services

To deploy Kerberos authentication with any of the following service applications, SharePoint Foundation 2010 can use either basic Kerberos delegation or Kerberos constrained delegation:

• Business Data Connectivity service and Microsoft Business Connectivity Services

• Access Services

• Microsoft SQL Server Reporting Services (SSRS)

• Microsoft Project Server 2010

Services that are enabled for Kerberos authentication can delegate identity multiple times. As an identity travels from service to service, the delegation method can change from basic Kerberos to Kerberos constrained. However, the reverse is not possible. The delegation method cannot change from Kerberos constrained to basic Kerberos. Therefore, it is important to anticipate and plan for whether or not a backend service will require basic Kerberos delegation. This can impact the planning and design of domain boundaries.

A Kerberos enabled service can use protocol transition to convert a non-Kerberos identity to a Kerberos identity that can be delegated to other Kerberos enabled services. This capability can be used, for example, to delegate a non-Kerberos identity from a front-end service to a Kerberos identity on a backend service.

Important

Protocol transition requires Kerberos constrained delegation. Therefore, protocol transitioned identities cannot cross domain boundaries.

Claims-based authentication can be used as an alternative to Kerberos delegation. Claims-based authentication enables a client’s authentication claim to be passed between two different services if the services meet all of the following criteria:

• There must be a trust relationship between the services.

• Both services must be claims-aware.

For more information about Kerberos authentication, see the following resources:

• How the Kerberos Version 5 Authentication Protocol Works (https://go.microsoft.com/fwlink/p/?LinkID=196644)

• Microsoft Kerberos (https://go.microsoft.com/fwlink/p/?LinkID=125740)

• Kerberos Explained

Kerberos authentication and claims-based authentication

SharePoint Foundation 2010 supports claims-based authentication. Claims-based authentication is built on Windows Identity Foundation (WIF), which is a set of .NET Framework classes that are used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation and WS-Trust. For more information about claims-based authentication, see the following resources:

• Claims-based Identity for Windows: An Introduction to Active Directory Federation Services 2.0, Windows CardSpace 2.0, and Windows Identity Foundation (white paper) (https://go.microsoft.com/fwlink/p/?LinkId=198942)

• Windows Identity Foundation home page (https://go.microsoft.com/fwlink/p/?LinkId=198943)

• An Introduction to Claims (https://go.microsoft.com/fwlink/p/?LinkId=217399)

• SharePoint Claims-Based Identity (https://go.microsoft.com/fwlink/p/?LinkID=196647)

When you create a SharePoint Foundation 2010 Web application, you have the option of selecting either of two authentication modes: claims-based or classic-mode. For new implementations of SharePoint Foundation 2010, you should consider using claims-based authentication. By using claims-based authentication, all supported authentication types are available for your Web applications.

The following service applications require the translation of claims-based credentials to Windows credentials. This process of translation uses the Claims to Windows Token Service (C2WTS):

• Excel Services

• PerformancePoint Services

• InfoPath Forms Services

• Visio Services

The service applications that require the C2WTS must use Kerberos constrained delegation. This is because the C2WTS requires protocol transition, and protocol transition is only supported by Kerberos constrained delegation. For the service applications in the preceding list, the C2WTS translates claims within the farm to Windows credentials for outbound authentication. It is important to understand that these service applications can leverage the C2WTS only if the incoming authentication method is either claims-based or classic-mode. Service applications that are accessed through Web applications and that use SAML claims or forms-based authentication claims do not use the C2WTS, and, therefore, cannot translate claims to Windows credentials.

For comprehensive guidance for configuring Kerberos in nine specific scenarios, including core deployment, three Microsoft SQL Server solutions, and scenarios that use Excel Services, PowerPivot for SharePoint, Visio Services, PerformancePoint Services, and Business Connectivity Services, see Configuring Kerberos authentication for SharePoint 2010 Products (https://go.microsoft.com/fwlink/p/?LinkId=197178).