Identity delegation for PerformancePoint Services (SharePoint Server 2010)

Applies to: SharePoint Server 2010, PerformancePoint Services

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.

Scenario dependencies

To complete this scenario you will need to have completed:

• Scenario 1: Core Configuration

• Scenario 2: Kerberos Authentication for SQL OLTP (optional)

• Scenario 3: Kerberos Authentication for SQL Server Analysis Services

Configuration checklist

Scenario environment details

Kerberos constrained delegation paths

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

SharePoint Server logical authentication

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.

Step-by-step Configuration instructions

Active Directory configuration

Create PerformancePoint Services service account

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:

Create an SPN for the Service Account running the PerformancePoint Service on the Application Server

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:

SETSPN -S SP/PPS vmlab\svcPPS

Verify Analysis Services SPN on SQL Server Analysis Services service account, vmlab\svcSQLAS (performed in Scenario 3) AND (Optional) Verify the SQL Server database engine service account, vmlab\svcSQL (performed in Scenario 2)

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:

MSOLAPSvc.3/MySqlCluster

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:

MSSQLSVC/MySqlCluster

Configure Kerberos constrained delegation from the PerformancePoint Services Service account to the SSAS Service and optionally for SQL Server service

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:

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.

   Note

   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).

   Note

   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.

SharePoint Server configuration

Configure and Start the Claims to Windows Token Service on PerformancePoint Services Servers

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.

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.

    Note

    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.

Add startup dependencies to the WIF C2WTS service

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.

Start the PerformancePoint Services service instance on the PerformancePoint Services server

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.

Create the PerformancePoint Services service application and proxy

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.

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.

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

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

$w.GrantAccessToProcessIdentity("vmlab\svcPPS")

Configure PerformancePoint services trusted file location and authentication settings

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.

Verify PerformancePoint Service Constrained Delegation

Create test PerformancePoint dashboard with a SQL Server AS data connection

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.

8.  

Publish the dashboard to SharePoint Server

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.