FOCUS AND CONTEXT
This article is focused on SharePoint 2013 but the same rules can be applied to SharePoint 2010 with some restrictions.
This is not a why or what is Kerberos article as that is well documented already in http://download.microsoft.com/download/B/B/F/BBF0C6F3-6E36-4979-8C43-DE165AD7AE34/SP2010%20Kerberos%20Guide.docx
The focus of this article is that you would like to configure Kerberos for all the BI functionality in SharePoint. It is a step by step checklist to ensure your Kerberos configuration is correct. It also focuses on configuring as few items as possible so that you do not have to set 100's of Service principle names as that leads to lower security, duplication and misconfiguration.
I have highlighted in orange where I show examples of my account names and URL's which must be replaced by your account names and URL's
The highlights in blue are important points to note.
IF YOU WOULD LIKE A STEP BY STEP PRESENTATION THIS IS AVAILABLE ON CHANNEL9.MSDN.COM (http://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC422)
SQL 2012 IMPACT
There are some fundamental changes in SQL 2012 that affect SharePoint and as such the Kerberos configuration requirements are simpler.
Reporting services has always been the caveat as it has never actually been managed by SharePoint. With SQL 2012, Reporting services is now a Service Application in SharePoint and is therefore managed by SharePoint. This means that it is load balanced by SharePoint, requires constrained delegation and as such does not have a separate Reporting Services Config file to update.
The new reporting Services mode is called SQL Reporting Services SharePoint Mode (previously known as Integrated Mode).
I will therefore detail the configuration using Constrained Delegation for all components as I do not see the point of using mixed delegation i.e. Constrained and Basic together as most BI components in SharePoint 2013 require Constrained.
The details below make a few assumptions:
Identify all data sources i.e. where will you be getting your data from? (SQL, SQL Analysis Services, etc.) While this seems obvious, every customer I have ever been to fails to declare all sources You will need Server Name + Instance, Port (SQL only) and Service Account used that is physically running the service (If it is Local System then it is not configured correctly and must be changed to an AD Service Account) e.g. SQL01\SP_Instance port 40000 Service Account svc_SQLService
Create a friendly URL and register it in DNS e.g. BI.BLUE.COM (replace with your URL on your Domain). This should be registered in DNS as a Host A record (Not a CNAME) and the IP should be the Web Front End or if using a Load Balancer then your load Balancer IP.
Configure Claims to Windows Token Service Account.
Create an AD account to be used by the Claims to Windows Token Service Account e.g. SP_C2WTSOpen a SharePoint PowerShell prompt as Administrator and run the following command:$w = Get-SPWebApplication -Identity http://bi.blue.com (Put the URL of your web application)$w.GrantAccessToProcessIdentity("blue\sp_c2wts") (Put your service account name)
DUPLICATE SPN CHECK SIDE NOTEI have attached a duplicate SPN check script that also assists in listing what you have set against each account.It will list the Constrained delegation, delegation and duplicate SPN's (If duplicates are detected this means that the service in question will fail to generate a Kerberos context).