Share via

BI Service Applications in SharePoint 2010 – Authentication (Classic vs. Claims) and Identity Delegation (Kerberos) – Part 5

  • Article

Author: Chris Bailiss
Technical Reviewers (Kerberos/Claims): James Noyce, Paul Williams

Introduction

This post is part of a series of posts describing the authentication methods supported by the SharePoint 2010 Business Intelligence service applications. Please see Part 1 for an overview of this series of posts.

This post describes how to test that user identity is being delegated through the BI service applications in a web application utilising Windows-Claims. It also covers some differences in the functionality that is supported by Windows-Claims (vs Classic-authentication).

BI Service Application Tests in the Claims Web App – Windows-Claims

I’ll now walk through each of the BI Service Applications tested previously – this time accessing them in the claims web app as a Windows User (i.e. using a Windows-Claim).

Excel Services

Uploading the test workbook created earlier into the Claims site allows the same test to be repeated:

This shows that we are able to delegate the user identity back to the SQL Server instances. Behind the scenes, the C2WTS has successfully performed a protocol transition from a Windows-Claim to a Windows Kerberos Ticket (two in fact, one for the Relational Engine and another for Analysis Services).

PerformancePoint Services

The first challenge in working with PerformancePoint on a Claims-enabled site is opening Dashboard Designer. Dashboard Designer (a Click-Once application) is not Claims-aware. Attempting to open it on a Claims-enabled site (even using a Windows-Claims as here) results in:

This can be worked around by extending the web application (see Technet), to enable access via Classic-mode authentication. In my lab environment, I extended the claims web app, to https://claimsext, from where Dashboard Designer can be successfully opened:

The same test dashboard as shown previously can then be built and published. This can be viewed via either the https://claimsext URL (not shown) or https://claims URL (shown below):

Again, the highlighted cells show that the current connection from PPS has been authenticated using Kerberos and that the user identity has been delegated through to Analysis Services correctly.

Reporting Services

When opening Report Builder from a Claims-mode site, it is not possible to retrieve / save reports, data sources, etc from / into the SharePoint site. Instead, the following prompt is thrown up:

It is impossible to enter a credential into this dialog – it simply won’t go away.

A similar prompt is thrown up when attempting to deploy into a Claims-mode site from Visual Studio.

As with PPS Designer, extending the web application to provider a Classic mode URL will enable both tools to access content in the site.

Uploading a copy of the report created earlier allows us to test running a report in Reporting Services. However, attempting to pass the user identity to the back-end now results in an error, e.g. attempting to test the Data Source:

Windows authentication / per-user identity delegation is not supported in SQL Server Reporting Services 2008 R2 when the web application is in Claims Mode. Instead, a shared account must be used (see MSDN). That account will either be the default trusted execution account for the server (in which case the fall back will be transparent) or the account can be configured explicitly on the data source:

Of course, the disadvantage of using a shared trusted account is that the user identity is no longer passed through to the back-end:

This restriction is due to the fact SQL Server Reporting Services 2008 R2 is not claims-aware. It runs as a separate web-server outside of SharePoint. In SQL Server 2012 Reporting Services becomes a SharePoint service application and is better suited to supporting this type of scenario.

PowerPivot for SharePoint

Attempting to open a PowerPivot workbook from the Claims-enabled site initially appears successful – just after opening the workbook it appears as:

However, at this point, no PowerPivot functionality has been invoked, only Excel Services has been used, which is showing data that was cached in the worksheet. The PowerPivot service application only comes into play when Data >> Refresh… is selected from the toolbar, or the slicer selection is changed. Trying either of those actions results in:

At the current time, PowerPivot does not support Claims-enabled sites of any kind. Only web applications running Classic-mode authentication are supported.

Visio Services

Uploading the test web drawing created earlier into the Claims site allows the same test to be repeated:

Again, this shows we have successfully delegated the user identity back to SQL Server.

Continued...

Continue reading in Part 6.