Configuring Kerberos authentication: Step-by-step configuration (SharePoint Server 2010)

Applies to: SharePoint Server 2010

In the scenario articles that follow, we build out a SharePoint Server 2010 environment to demonstrate how to configure delegation in a number of common scenarios you might encounter in the enterprise. The walkthroughs assume you are building out a scaled-out SharePoint farm similar to what is described in the following section.

Environment and farm topology

The following diagram illustrates the farm topology used when configuring the scenarios in the sections below. The farm topology is load balanced and scaled out between multiple tiers to demonstrate how identity delegation would work in multi-server, multi hop scenarios.

Environment specification

All computers in the demonstration environment are virtualized running on Windows Server 2008 R2 Hyper-V. The computers are joined to a single Windows domain, vmlab.local, running in Windows Server 2008 Forest and Domain function levels.

• Client Computer

  • Windows 7 Professional, 64 bit

• SharePoint Server front-end Webs

  • Windows Server 2008 R2 Enterprise, 64 bit

  • Services:

    • Web Application Service

  • Load balanced with Windows NLB

• SharePoint Server Application Server

  • Windows Server 2008 R2 Enterprise, 64 bit

  • Microsoft SharePoint Server 2010 (RTM)

  • Services:

    • WIF Claims to Windows Token Service

    • Managed Metadata Service

    • SharePoint Index

    • SharePoint Query

    • Excel Services

    • Visio Graphics Service

    • Business Connectivity Services

    • Performance Point Services

• SQL Services

  • Windows Sever 2008 R2 Enterprise, 64 bit

  • Microsoft SQL Server 2008 R2 Enterprise, 64 bit

  • Active/Passive Configuration

  • SQL Server Services:

    • SQL Data Engine

    • SQL Server Analysis Services

    • SQL Agent

    • SQL Browser

• SQL Reporting Server

  • Windows Server 2008 R2 Enterprise, 64 bit (RTM)

  • Microsoft SQL 2008 R2 Enterprise, 64 bit (RTM)

  • Microsoft SharePoint Server 2010 (RTM)

  • Windows NLB, Load balanced

  • Reporting Services SharePoint integration mode

  • Reporting Services, scaled-out mode

Web Application specification

The scenarios in the walkthrough reference a set of SharePoint Server 2010 web applications you will configure in Scenario 1. The following web applications are load balanced using Windows NLB across the two SharePoint Server web front ends in the demonstration environment:

• http://sp10CA   The Central Administration web application for the farm. Scenario 1 will not walk through the configuration of this web application.

• http://portal and https://portal   Web application with demonstration publishing portal. It is used to demonstrate how to configure delegation for web applications running on standard ports (HTTP 80, HTTPS 443)

• http://teams:5555   Web application with demonstration team site. It is used to demonstrate how to configure delegation for web applications running on non-standard ports, in this example port 5555.

SSL configuration

Some of the walkthrough scenarios will use SSL to demonstrate how to configure delegation with HTTPS. It is assumed that the certificates being used come from a trusted root certificate authority, either internal or public, or you have configured all computers to trust the certificates being used. The document will not cover how to properly configure certificate trust nor will it provide guidance about debugging issues related to SSL certificate installation. It is highly recommended to review these topics and test your SSL configuration before configuring Kerberos constrained delegation with SSL protected services. For more information see:

• Active Directory Certificate Services Overview (https://go.microsoft.com/fwlink/p/?LinkId=196660)

• Active Directory Certificate Services Step-by-Step Guide (https://go.microsoft.com/fwlink/p/?LinkId=196661)

• Configuring Server Certificates in IIS 7 (https://go.microsoft.com/fwlink/p/?LinkId=196662)

• How to Set Up SSL on IIS 7: Configuring Security : Installing and Configuring IIS 7 : The Official Microsoft IIS Site (https://go.microsoft.com/fwlink/p/?LinkID=193447)

• Add a Binding to a Site (IIS 7) (https://go.microsoft.com/fwlink/p/?LinkId=196663)

• Configure a Host Header for a Web Site (IIS 7) (https://go.microsoft.com/fwlink/p/?LinkId=196664) — (How to use SSL with host headers)

• Create a Self-Signed Server Certificate in IIS 7 (https://go.microsoft.com/fwlink/p/?LinkId=196665)

Load balancing

Load balancing on the SharePoint Server front-end Webs and SQL Server Reporting Services servers was implemented by using Windows Server 2008 Network Load Balancing (NLB). How to configure NLB and NLB best practices are not covered in this document. For more information on NLB, refer to Overview of Network Load Balancing.

SQL aliasing

The farm was built using a SQL client alias to connect to the SQL cluster. This is typically a best practice and was done to demonstrate how Kerberos authentication is configured when SQL aliasing is used. Scenario 2 assumes the environment is configured in this manner, but it is not required to use SQL aliases to complete any of the scenarios below. For more information on how to configure SQL aliases, see How to: Create a Server Alias for Use by a Client (SQL Server Configuration Manager).

SharePoint Server services and service accounts

The scenarios below implement a least-privilege model where each service in the SharePoint farm leverages a separate, distinct Active Directory account for its service identity. Using a least-privilege model has advantages and disadvantages:

Advantages:

• The administrator can control the permissions of each service in a fine-grained way   This includes domain permissions, local permissions and privileges, delegation rights and other settings.

• Better auditing and traceability   By ensuring each service leverages its own identity, an administrator can track network and system activity back to the specific service based on the identity captured in audit files. For example, if a server audit log shows logon activity for a particular account, the account could be used to trace the activity to a particular service.

• Better security   By leveraging separate accounts for each service, an administrator assures that if one account is compromised it potentially limits the damage due to the security issue because only the service that is using the compromised account is affected. Note that if any account becomes compromised, a holistic security assessment of the entire environment should be performed to determine the most appropriate action to address the security issue.

Disadvantages:

• Increased account management complexity   Having more service accounts translates to more Active Directory configuration and more password management policies to enforce.

• Additional configuration   As seen in the step-by-step guides that follow, once a SharePoint Server administrator makes the decision to leverage a least-privilege model, there are additional steps she or he must perform to configure the environment correctly.

• Increased administration complexity   The probability of misconfiguration increases as the complexity of the environment increases. When you leverage multiple accounts, there is a chance that certain services will be misconfigured, which can lead to functionality issues and triage needed to correct the issues.

Be aware that using separate service accounts is not a requirement of SharePoint Server but a general recommendation for production environments. The steps in the articles that follow outline how to configure SharePoint Server when you are using separate accounts; some of these steps may not apply when you are using shared accounts.

C2WTS Service Identity

The steps in the articles that follow assume a least-privilege security model and leverage discrete service accounts for each SharePoint Server service. The C2WTS is configured to use a separate Active Directory account instead of the default local system account to follow this design tenant. When you use a distinct account, the individual delegation rights granted to the C2WTS can be managed separately from other services on the server that are also using the local system account. Note that this is not a product requirement, but a recommended practice.

Tips for working through the scenarios

The scenarios below walk through various activities needed to configure Kerberos delegation across different functions of the SharePoint Server platform. As you go through each section:

All the scenarios assume you have your web applications configured for incoming classic authentication (Kerberos). Some scenarios below require classic authentication and will not function as documented with incoming claims authentication.

• Get the SharePoint Server services working first without delegation to ensure the service applications are configured correctly before moving on to more challenging configurations with delegation.

• Try to pay special attention to each step and avoid skipping any steps

• Work through scenario 1 and spend time using the debugging tools mentioned in the scenario as they can be used in other scenarios to triage configuration issues.

• Remember to work through scenario 2. You will need a computer running SQL Server that is configured to accept Kerberos authentication and will require the test database that you setup in this scenario for some of the later scenarios.

• Always double-check SPN configuration in each scenario by using SetSPN -X and SetSPN -Q. See the appendix for more information.

• Always be sure to check the server event logs and ULS logs when attempting to debug a configuration issue. There are typically good pointers in these logs which can quickly point out the issues you are encountering.

• Turn up diagnostic logging for SharePoint Foundation->Claims Authentication and any service applications that you are attempting to triage if issues occur.

• Remember that each scenario may be affected by service application caching. If you make configuration changes but do not see changes in platform behavior, try restarting the service’s application pool or windows service. If this has no effect, sometimes a system reboot will help.

• Remember that Kerberos tickets are cached once requested. If you are using a tool like NetMon to view TGT and TGS requests, you may need to empty the ticket cache if you don’t see the request traffic you expect. Scenario 1, Configuring Kerberos authentication: Core configuration (SharePoint Server 2010) explains how to do this with the KLIST and KerbTray utilities.

• Remember to run NetMon with Administrative privileges to capture Kerberos traffic.

• For advanced debugging scenarios you may want to turn on WIF tracing for the Claims to Windows Token Service and WCF tracing for the SharePoint Service Applications (WCF services). See:

  • WIF Tracing

  • How to: Enable Tracing

  • Configuring Tracing