SharePoint (and Project Server) Shenanigans

I was recently involved in getting PerfomancePoint and the “Per User Identity” configuration working for a client running SharePoint 2010. The same configuration still holds true for SharePoint 2013, but for 2013 both PerformancePoint and Excel Services now introduce the new “EffectiveUserName” feature, which should make life a load easier.

In the world of SharePoint /PerformancePoint 2010 if you want to build an MI dashboard that shows user specific information in the reports the only way to do this effectively is to use the “Per-User Identity” option in the Data Source Connection setting, which in turn involves setting up Kerberos and specifically constrained delegation, in this article I will cover the broad steps needed.

Kerberos on Web App.

Firstly make sure that Kerberos is running on the Web App that will be hosting your PerformancePoint content, the best way to check this is in the Windows Security log, filter on 4624 events and find a logon event, make sure its a type 3 (Network) and the Process is Kerberos.

Kerberos on Target.

Make sure you have the correct SPNs registered against your target, typically with PerformancePoint this will be an SSAS cube, use SetSPN –S MSOLAPSvc.3/ServerName DomainName\SSASDomainAccount to create the SPNs, these will be key, so take your time and make sure you get them right.

Claims to Windows Token Service

PerformancePoint (along with Excel and Visio Services) relies on the C2WTS for Protocol Transition, so this must be running and configured correctly.

I would recommend running the C2WTS as a separate managed account, this account needs some specific requirements (local administrator, Logon as a service, Act as part of the operating system and Impersonate a client after authentication, set the last 3 in local security policy.)

If the C2WTS is not happy you will probably see something like the error below logged in the Windows Application log when trying to connect.

You also need to register a manual SPN for the C2TWS, something like SetSPN –S SP/C2WTS DomainName\C2WTSDomainAccount, this will allow the “delegation” tab on the user account domain object to become available.

Constrained Delegation.

This is the tricky part to get working, basically we are saying that “object A” is allowed to delegate to “service A” only in, our case it will be “object A & object B and object C”, are allowed to delegate to “Service A” in fact all the objects in the delegation chain, so to allow delegation we open our user object in AD, go to the “Delegation” tab, select “Trust this user for delegation to the specified services only” (This is setting constrained delegation)–> “Use any authentication protocol” (This is allowing protocol transition).

Use the  Add… button to find the service account for the SSAS Domain account mentioned above and select the Service Type you setup earlier.

You will probably have to perform this for your Web Application account, C2WTS account, PerformancePoint account and any other managed service account that is involved, once finished each account should have a setting like this

Remember that if the Delegation tab is not available on the user object you have to create a manual SPN.

If your data connection still refuses to connect with the “Per-User Identity setting”, have another look at the eventlog again and look for this error.

This probably means you still have an SPN missing or not configured correctly, the best way to deal with this is to install Network Monitor then run a trace while trying to connect and filter on the ‘KerberosV5’ events, and you are looking for any Kerberos error codes most likely you will see some kind of PRINCIPLE_UNKNOWN error being reported, normally associated with a user name or service account that has been missed in the constrained delegation settings.

Good luck and Happy SharePointing