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.
Some of the configuration steps may change, or may not work in certain farm topologies. For instance, a single server install does not support the Windows Identity Foundation C2WTS services so claims to windows token delegation scenarios are not possible with this farm configuration.
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.
The farm configuration in the demonstrations is not meant to be a reference architecture or an example of how to design a topology for production environments. For example, the demo topology runs all SharePoint Server 2010 service applications on a single server which creates a single point of failure for these services. For more information on how to design and build a production SharePoint Server environment, see SharePoint Server 2010 – Physical and Logical Architecture and Topologies for SharePoint Server 2010.
The scenario walkthroughs assume that all computers that are running SharePoint Server and the data sources used in the scenario below reside in a single domain. An explanation and walkthrough of multi-domain/multi-forest configuration is not covered in this document.
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.
- Windows 7 Professional, 64 bit
SharePoint Server front-end Webs
Windows Server 2008 R2 Enterprise, 64 bit
- Web Application Service
Load balanced with Windows NLB
SharePoint Server Application Server
Windows Server 2008 R2 Enterprise, 64 bit
Microsoft SharePoint Server 2010 (RTM)
WIF Claims to Windows Token Service
Managed Metadata Service
Visio Graphics Service
Business Connectivity Services
Performance Point Services
Windows Sever 2008 R2 Enterprise, 64 bit
Microsoft SQL Server 2008 R2 Enterprise, 64 bit
SQL Server Services:
SQL Data Engine
SQL Server Analysis Services
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.
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:
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.
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:
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.
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: