Identity delegation for PerformancePoint Services (SharePoint Server 2010)

SharePoint 2010

Applies to: SharePoint Server 2010, PerformancePoint Services

Topic Last Modified: 2012-04-11

In this scenario, you will add the PerformancePoint Services service application to the SharePoint Server environment and configure Kerberos constrained delegation to allow the service to pull data from an external Analysis Services cube and have the option to pull data from SQL Server.

If you are installing on Windows Server 2008, you may need to install the following hotfix for Kerberos authentication:
A Kerberos authentication fails together with the error code 0X80090302 or 0x8009030f on a computer that is running Windows Server 2008 or Windows Vista when the AES algorithm is used (

To complete this scenario you will need to have completed:


Area of configuration Description

Active Directory configuration

Create PerformancePoint Services service account

Create an SPN for the service account running the PerformancePoint Service on the Application Server

Verify Analysis Services SPN on SQL Server Analysis Services service account, vmlab\svcSQLAS (performed in Scenario 3)


(Optional) verify the SQL Server database engine service account, vmlab\svcSQL(performed in Scenario 2).

Configure Kerberos constrained delegation for Claims to Windows Token Services service account to Analysis Services

Configure Kerberos constrained delegation for the PerformancePoint

Services service account to Analysis Services

SharePoint Server configuration

Start Claims to Windows Token Service on PerformancePoint Services Servers

Start the PerformancePoint Services service instance on the PerformancePoint Services server

Create the PerformancePoint Services service application and proxy

Check the identity on PerformancePoint application

Grant the PerformancePoint Services service account permissions on the web application content database

Configure PerformancePoint services trusted file location and authentication settings

Verify PerformancePoint Service constrained delegation

Create document library to host a test dashboard

Create a data source that reference an existing SQL Server Analysis Services cube

Create a trusted PerformancePoint content list

Create test PerformancePoint dashboard

Publish dashboard to SharePoint Server

Diagram of authentication process

In this scenario we will configure the PerformancePoint Services service account for Kerberos constrained delegation to the SQL Server service.

Diagram of authentication flow

Authentication in this scenario begins with the client authenticating with Kerberos authentication at the web front end. SharePoint Server 2010 will convert the Windows authentication token into a claims token using the local Security Token Service (STS). The PerformancePoint service application will accept the claims token and convert it into a Windows token (Kerberos) using the local Claims to Windows Token Service (C2WTS) that is a part of Windows Identity Framework (WIF). The PerformancePoint service application will then use the client’s Kerberos ticket to authenticate with the backend DataSource.

As a best practice PerformancePoint Services should run under its own domain identity. To configure the PerformancePoint Service Application, an Active Directory account must be created and registered as a managed account in SharePoint Server 2010. For more information see Managed Accounts in SharePoint 2010. In this example the following account is created and registered later in this scenario:


SharePoint Server service IIS App Pool Identity

PerformancePoint Services


You can optionally reuse a single domain account for multiple services. This configuration is not covered in the following sections.

The Active Directory Users and Computers MMC snap-in is typically used to configure Kerberos delegation. To configure the delegation settings within the snap-in, the Active Directory object being configured must have a service principal name applied; otherwise the delegation tab for the object will not be visible in the object’s properties dialog. Although PerformancePoint Services does not require a SPN to function, we will configure one for this purpose. Note that if the service account already has an SPN applied (in the case of sharing accounts across services) this step is not required.

On the command line, run the following command:

The SPN is not a valid SPN. It is applied to the specified service account to reveal the delegation options in the AD users and computers add-in. There are other supported ways of specifying the delegation settings (specifically the msDS-AllowedToDelegateTo AD attribute) but this topic will not be covered in this document.

Verify that the SPN for the SQL Server Analysis Services account (vmlab\svcSQLAS) exists with the following SetSPN command:

SetSPN -L vmlab\svcSQLAS

You should see the following:


Verify the SPN for the SQL Server service account (vmlab\svcSQL) exists with the following SetSPN command:

SetSPN -L vmlab\svcSQL

You should see the following:


To allow PerformancePoint services to delegate the client's identity, Kerberos constrained delegation must be configured. You must also configure constrained delegation with protocol transition for the conversion of claims token to Windows token via the WIF C2WTS.

Each server running PerformancePoint services must be trusted to delegate credentials to each back-end service with which PerformancePoint will authenticate. In addition, the PerformancePoint services service account must also be configured to allow delegation to the same back-end services. Notice also that HTTP/Portal and HTTP/Portal.vmlab.local are configured to delegate in order to include a SharePoint list as an optional data source for your PerformancePoint dashboard.

In our example the following delegation paths are defined:


Principal Type Principal Name





To configure constrained delegation
  1. Open the Active Directory Object’s properties in Active Directory Users and Computers.

  2. Navigate to the Delegation tab.

  3. Select Trust this user for delegation to specified services only.

    Constrained delegation on computer account, VMSP10APP01, is optional and only required when you are running the C2WTS as Local System. If you configure the computer account, select Trust this computer for delegation to specified services only.
  4. Select Use any authentication protocol.

  5. Click the add button to select the service principal.

  6. Select User and Computers.

  7. Select the service account running the service you wish to delegate to (SQL Server, SQL Server Analysis Services, or both).

    The service account selected must have an SPN applied to it. In our example, the SPN for this account was configured in a previous scenario. See Kerberos authentication for SQL OLTP (SharePoint Server 2010) and Kerberos authentication for SQL Server Analysis Services (SharePoint Server 2010).
  8. Click OK.

  9. Select the SPNs you would like to delegate to, and then click OK.

  10. You should now see the selected SPNS in the services to which this account can presented delegated credentials list.

  11. Repeat these steps for each delegation path defined in the beginning of this section.

The Claims to Windows Token Service (C2WTS) is a component of the Windows Identity Foundation (WIF) which is responsible for converting user claim tokens to Windows tokens. Performance Point services uses the C2WTS to convert the user’s claims token into a windows token when the services needs to delegate credentials to a back-end system which uses Windows authentication. WIF is deployed with SharePoint Server 2010 and the C2WTS can be started from Central Administration.

Each PerformancePoint Services Application server must run the C2WTS locally. The C2WTS does not open any ports and cannot be accessed by a remote caller. Further, the C2WTS service configuration file must be configured to specifically trust the local calling client identity.

As a recommended practice you should run the C2WTS using a dedicated service account and not as Local System (the default configuration). The C2WTS service account requires special local permissions on each server that the service runs on. Be sure to configure these permissions when you choose to run the C2WTS with a domain account. To ensure the C2WTS account picks up the needed privileges, reboot the server after you have configured the C2WTS.

If you choose to configure the C2WTS as Local System, you do not need to configure any additional local privileges.
To start the C2WTS
  1. Create a service account in Active Directory to run the service under. In this example we created vmlab\svcC2WTS.

  2. Add an arbitrary Service Principal Name (SPN) to the service account to expose the delegation options for this account in Active Directory Users and Computers. The SPN can be any format because we do not authenticate to the C2WTS using Kerberos authentication. It is recommended to not use an HTTP SPN to avoid potentially creating duplicate SPNs in your environment. In our example we registered SP/C2WTS to the vmlab\svcC2WTS using the following command:

    SetSPN -S SP/C2WTS vmlab\svcC2WTS
  3. Configure Kerberos constrained delegation on the C2WTS services account. In this scenario we delegate credentials to the SQL Server service that is running with the MSOLAPsvc.3/MySqlCluster.vmlab.local service principal name.

  4. Next, configure the required local server permissions the C2WTS requires. You have to configure these permissions on each server the C2WTS runs on. In our example this is VMSP10APP01. Log onto the server and give the C2WTS the following permissions:

    1. Add the service account to the local Administrators Groups.

    2. In local security policy (secpol.msc) under user rights assignment give the service account the following permissions:

      1. Act as part of the operating system

      2. Impersonate a client after authentication

      3. Log on as a service

  5. Open Central Administration.

  6. In the Security section, under Configure Managed Service Accounts, register the C2WTS service account as a managed account.

  7. Under services, select Manage services on server.

  8. In the server selection box in the upper right hand corner select the server(s) running PerformancePoint services. In this example it is VMSP10APP01.

  9. Find the Claims to Windows Token Service and start it.

  10. Go to Manage Service Accounts in the Security section. Change the identity of the C2WTS to the new managed account.

    If the C2WTS was already running before configuring the dedicated service account, or if you need to changes the permissions of the service account after the C2WTS is running you must restart the C2WTS from the services console.

    In addition, if you experience issues with the C2WTS after restarting the service it may also be required to reset the IIS application pools that communicate with the C2WTS.

There is a known issue with the C2WTS where it may not automatically startup successfully on system reboot. A workaround to the issue is to configure a service dependency on the Cryptographic Services service:

  1. Open the command-prompt window.

  2. Type: sc config c2wts depend= CryptSvc

  3. Find the Claims to Windows Token Service in the services console.

  4. Open the properties for the service.

  5. Check the Dependencies tab. Make sure Cryptographic Services is listed:

  6. Click OK.

  7. Reboot the server. Make sure that the C2WTS has started once the computer reboots.

Before creating a PerformancePoint Services service application, start the PerformancePoint services serve service on the designated Farm servers. To learn more about PerformancePoint Services configuration, see PerformancePoint Services administration (SharePoint Server 2010).

  1. Open Central Administration.

  2. Under services, select Manage services on server.

  3. In the server selection box in the upper right hand corner select the server(s) running PerformancePoint services. In this example it is VMSP10APP01.

  4. Start the PerformancePoint Service service.

Next configure a new PerformancePoint Services service application and application proxy to allow web applications to consume PerformancePoint Services:

  1. Open Central Administration.

  2. Select Manage Service Applications under Application Management.

  3. Select New, and then click PerformancePoint Services Application.

  4. Configure the new service application. Be sure to select the correct service account or create a new managed account if you did not perform this step previously.

Configuring the Unattended Services Account is optional in this scenario and only used if you want to also test NTLM authentication.

You can create and register a new service account for an existing application pool dedicated for PerformancePoint Services before this step or when you create the new PerformancePoint Service. To associate the service account with an existing application pool dedicated to PerformancePoint or verify an existing account, do the following.

  1. Navigate to SharePoint Central Administration. Find Configure managed accounts in the Security section.

  2. Select the drop-down box and select the application pool.

  3. Select the Active Directory account.

A required step in configuring SharePoint Server 2010 Office Web Applications is allowing the web application’s service account access to the content databases for a given web application. In this example, we will grant the PerformancePoint Services account access to the "portal" web application’s content database by using Windows PowerShell.

Run the following command from the SharePoint 2010 Management Shell:

$w = Get-SPWebApplication -Identity http://portal


Once the PerformancePoint Services application is created, you must configure the properties on the new service application to specify a trusted host location and authentication settings.

  1. Open Central Administration.

  2. Select Manage Service Applications under Application Management.

  3. Click the link for the new Service Application, PerformancePoint Services and click the Manage button in the ribbon.

  4. In the PerformancePoint services management screen, click Trusted Data Source Locations.

  5. Select the Only specific locations option and click Add Trusted Data Source Location.

  6. Type the URL of the location, select the Site Collection (and subtree) option, and then click OK.

  7. Select the Only specific locations option and click Add Trusted Data Source Location.

  8. Type the URL of the location, select the Site (and subtree) option, and then click OK.

In larger environments with multiple Active Directory servers, you may need to wait for Active Directory replication to finish before you verify your configuration.

Next, open PerformancePoint Dashboard Designer and create an Analysis Services data connection.

  1. Open PerformancePoint Dashboard Designer and right-click data source to create a connection.

  2. Select Analysis Services.

  3. Specify the server, database, and cube and select Per-user Identity.

  4. Click Test Data Source to test the connection.

  5. Create a report and dashboard.

  6. Make sure you have a data connection by dragging measures and dimensions from the details pain into the report designer.

  7. Your report can be included in the dashboard.

    Select Reports and then drag My Report onto the Dashboard Content page.


The last step to validate the PerformancePoint Services application is to publish the dashboard and test refreshing and viewing the Analysis Services data. To do this:

  1. Select the bright file button icon.

  2. Click Deploy in the file selection.

  3. Select a Master Page to which you want to publish.

  4. Click the refresh button in your browser.

    If the data connection refreshes, you have successfully configured Kerberos delegation for PerformancePoint Services.