This post is the first one in a series about using SharePoint BI features together with Kerberos, hereby enabling you to delegate the user credentials all the way to the data source, enabling role based security.
When I think about it seems like people love to fear Kerberos. Often, the developers and the infrastructure people I meet at customers are afraid of trying to enable Kerberos delegation or at least fear that it will take a considerable amount of time debugging, tracing and fixing. At least when working on SharePoint to SQL Server or SSAS delegation.
To be honest, there is not much work related to enable Kerberos delegation in a domain. The problem is that it is tedious and it requires changes to some Active Directory objects, which often in turn requires the involvement of other IT specialists in the organization (AD administrators).
Kerberos and SharePoint is nothing new, the picture below is taken from a SharePoint 2003 installation from 2002 with several millions documents that I’ve been administrating for a customer since 2005 and still going strong.
About the setup.
I want to keep it very simple. And the simplest way of doing it is to keep the number of SPNs and the number of users trusted for delegation. To achieve I can have all the SharePoint service application that I want to run with Kerberos authentication running in the same application pool (under the same user identity), so there is only one user to trus for delegation.
The downside of it being that you need to register a SPN for HTTP/<servername> and that user and that you will not later on be able to register another user for the HTTP/<servername>. This could happen in situations where you want to change the authentication to your SharePoint website to Kerberos.
Information Gathering and Configuration
These are the two main activities needed for making it work. You need to gather the information about the users running different services and then you need to script some modifications for allowing identity delegation.
- All the servers need to be in the same Windows domain
- Permission to modify certain AD objects (You must be a member of the Domain Administrators group to run the SetSpn command)
- Enable following SharePoint feature by running the following:
Install-SPFeature –path "DataConnectionLibrary" Enable-SPFeature –url <yourSiteName> -identity "DataConnectionLibrary"
- Ensure that the Claim to Windows Token Service is started and set to automatic on the SharePoint servers
- By default no callers are allowed to use the Windows Identity Foundation Claims To NT Token Service so you need to modify c2wtshost.exe.config generally found in : C:Program FilesWindows Identity Foundationv3.5 You need to add WSS_WPG to the allowed callers:
- Create a dependency from C2WTS service to ensure it starts at reboot – in command prompt type:
sc config c2wts depend= CryptSvc
IF C2WTS is running under a domain user you will need to add some rights to this user:
- Act as part of the operating system
- Impersonate a client after authentication
- Log on as a service
The following diagrams shows how to setup Kerberos delegation between Excel Services, PowerPivot, PerformancePoint Services, Power View and Reporting Services to SQL Server engine and SQL Server Analysis Services. The diagram spans across several pages. The first page is the base and each following page is a component from the SharePoint BI stack.
Click on the drawing to get the visio file.
If you have followed the instructions from the diagram you should be ready to check the configuration. This will be the subject of my next post.