Tag: Kerberos

Using PowerPivot for SharePoint with SharePoint 2016

Published March 8, 2016

While the capabilities previously provided with Excel Services have been moved to Office Online Server (OOS) in the 2016 version of SharePoint, PowerPivot for SharePoint (PP4SP) has not. PP4SP remains a SharePoint service application in the 2016 edition of the product. This service application is responsible for providing the automatic data refresh capability for PowerPivot for SharePoint enabled workbooks. As an aside, it can also refresh connected workbooks, as I discuss here. Given that the rendering engine now exists on a separate server, there are a few additional steps to perform, and this article aims to walk through them.

Basic Installation

Prior to setting up PowerPivot for SharePoint, you’ll need a SharePoint farm that has been enabled for PowerPivot workbooks, as I have previously outlined here. The Add-In is available from Microsoft here.

Installing is a simple matter of downloading the add-in and running setup. You’ll be presented with a straightforward dialog box with 4 options.

This should be installed on every SharePoint server in the farm, whether or not it will run the Service application. Technically the first option is not required for front end web servers, but it is small, and I like to keep my options open. After clicking next, the bits will be installed.

Like SharePoint, once the bits are installed, they must be configured. This is done through the PowerPivot for SharePoint configuration tool, which the earlier setup installed. It should be available from the application list on the server. It works much the same as it did with earlier versions of PP4SP and SharePoint. Run it and you’ll be prompted for the installation type. Select “Configure or repair..” and click OK. Next, you’ll be presented with the configuration detail dialog. The dialog contains a number of configuration nodes, which drive a series of PowerShell scripts that are used to perform the configuration (tip – click on the Script tab to see the scripts in question). The exclamation point icon indicates that parameters need to be supplied.

The first node is mandatory – Configure or Repair.

Here, you enter the credentials of the user that can perform the configuration – I normally use the user that was used to configure SharePoint in the first place – spSetup in my demo environments. This is the only step that is critical. However, I find it to be good practice to change the name of the Service application and database.

The default values begin with “Default Power Pivot…” and the database contains a GUID as part of its name. When searching alphabetically for PowerPivot, I tend to look under P not D, so I remove the word default from both, the GUID from the database, and further change the database name to conform with naming conventions. Finally, it’s a good idea to check the Site Collection that will be activated.

The configuration tool will activate the PowerPivot solution in one site collection by default. It can be activated later in others, but it’s worth starting off on the right foot.

Click the “validate” button, and if all of the indicators are green, go ahead and complete the configuration. Once configured, no further Central Admin work should be necessary, at least not at this point.

PowerPivot Gallery

A PowerPivot gallery is not required. All of the PowerPivot for SharePoint features can be used in a regular document library, but the gallery centralizes things and makes these features more discoverable. It should be noted that just as with SharePoint 2013, the PowerPivot gallery is a customized document library that uses Silverlight to display its contents. This dependency on Silverlight means that in order to use it, workstations must have Silverlight installed, and neither Google Chrome, nor Microsoft Edge browsers will support it.

To create a new PowerPivot Gallery, navigate to the site contents of the target SharePoint site, and select “Add an app”. Select the PowerPivot gallery and give it a name. If you don’t see PowerPivot Gallery as an option, you may need to enable the PowerPivot Feature for Site collection in the Site Collection features list. Once added, upload a PowerPivot enabled workbook. This workbook should contain a data model where the data was imported directly into PowerPivot (not via Power Query). Once uploaded, after a few moments, the thumbnails from the workbook objects should show up in the gallery. It should be possible to interact with the workbook, as PP4SP is not required for that, but the two (or 3 depending on whether or not SSRS has been installed) icons on the right of the workbook provide access to PP4SP capability.

In order to set up scheduled refresh, click on the calendar icon (The Excel icon is for using Excel as a data source – see below). This opens up the data refresh history for this workbook. To configure it, click on the “Configure Schedule link”. On the configuration screen, select the enable check box, enter the desired schedule, and the credentials needed to connect to the source data. For testing purposes it is more deterministic to explicitly enter credentials here, but refresh supports a “refresh account” (configured via the Secure Store Service), or any Secure Store Service credentials. Also, selecting “Also refresh as soon as possible” will immediately force a refresh cycle, which will begin within 5 minutes of saving, and is useful for testing.

Once complete, open the refresh history for the workbook, and you should see either a stopwatch icon, indication a refresh is in progress, a green check mark, indicating successful completion, or a red x, indicating failure.

One thing should be noted – data models created by using Power Query in Excel will always fail – this is true as of March 2016. Power Query refresh has been stated as a feature for PowerPivot for SharePoint 2016, but as of this writing, it has not yet been included.

Workbook as a Data Source – Kerberos Enablement

The URL of a workbook that contains a data model can be used in a connection string in another workbook, and PowerPivot for SharePoint can intelligently route that connection to the backing SSAS PP Mode server. To the consuming workbook, it looks just like a regular SSAS server.

In prior versions of SharePoint and PP4SP, using a workbook as a data source “just worked”, because the service and the workbook were all on the same server. With OOS, the server is on a different server. OOS needs to connect to the source workbook (the one with the data model) with the credentials of the consuming user, which means that for this to work, Kerberos Constrained Delegation (KCD) must be configured between OOS and SharePoint.

To be sure, you only need to configure KCD if you wish to use Excel files as a data source. If not, this step can be safely skipped.

You need to allow the computer account for the OOS server to delegate credentials to the account running the HTTP service for the SharePoint application that contains the workbooks to be used as data sources. In the example below, the OOS Server is NAUTILUS2016OOS, the service account is NAUTILUS\spApps, and the application is http://home.nautilus.local. This PowerShell can be run on any Domain Controller server.

$allowedPrincipals = @()
$allowedPrincipals += Get-ADComputer -Identity NAUTILUS2016OOS

# Set the delegation property on the application pool identity.
Set-ADUser spApps -PrincipalsAllowedToDelegateToAccount $allowedPrincipals

# Set the Service Principal Names for the application pool identity.
SetSPN -S HTTP/home NAUTILUS\spApps
SetSPN -S HTTP/home.nautilus.local NAUTILUS\spApps

Once successfully configured, it should be possible to use Excel files that contain data models as a data source for other Excel files. To create a new one, click the Excel icon beside the data refresh history icon in the PowerPivot gallery.

Wrapping Up

One other feature requires further configuration to work, and that is the PowerPivot Administration dashboard. Security constraints now prevent the use of Central Administration as a container which means that the dashboard must be set up in a regular site collection. This requires Server to Server (S2S) trust to be configured. Given that this is not a user facing feature, it’s out of scope for this article, but details on how to do it can be found in the Deploying SQL Server 2016 PowerPivot and Power View in SharePoint 2016 document.

Setting up PowerPivot for SharePoint will still not give you the ability to render Power View reports in a browser whether they are created standalone, or in an Excel workbook. For that, it is necessary to set up SQL Server Reporting Services (SSRS) in SharePoint mode, as Power View rendering is part of SSRS. That will be the topic of an upcoming article.

6 Comments

Connecting Excel to Data with SharePoint 2016 and Office Online Server 2016

Published March 3, 2016

If you’re in the SharePoint community, and you’ve been living under a rock since August 2015, you may not have heard that Excel Services is no longer present in SharePoint 2016. This is not a as big a deal as it initially sounds, because all (OK.. most) of the features available to Excel Services have been moved over to Office Online server, streamlining the architecture. It does however lead to many changes, and this is certainly true for external data access and authentication. This article hopes to answer the question of how these changes impact data access and the Excel Services Authentication Settings.

My previous article “Adding Excel Services Capabilities to a SharePoint 2016 Farm” dealt with getting the farm enabled with Office Online Server and Excel Services capabilities. This article drills down into using Excel workbooks connected to back end data sources. It does not cover PowerPivot enabled workbooks, or workbooks with an embedded data model – that is the topic of the next article in this series.

The Excel Services authentication settings are use when an Excel workbook is opened in a browser, and the workbook connects directly to data on another server. Note that it does NOT pertain to PowerPivot enabled workbooks (at least that portion of those workbooks that uses the data model) as they utilize a different mechanism entirely.

The settings are accessed from the data tab in Excel. First, click on “Connections” to view the available connections in the workbook. Next select the connection and click “Properties”. Select the “Definition” tab, and at the bottom of the dialog box, click on “Authentication Settings”. It’s a well hidden option.

Before continuing, it should be mentioned that these settings affect Windows credentials only. If the data source uses SQL Authentication, or something proprietary, the credentials will be stored in the Secure Store Service, or embedded in the connection string, and they will be used as proxy accounts – fine grained permissions on the destination server will not be possible.

The issue with Windows credentials is the standard “double hop” problem encountered in Windows authentication. This problem existed in prior versions of Excel Services, with SharePoint being the middle tier server. Office Online Server (OOS) must now reside on a separate server, and this add an extra “hop”, exacerbating the problem. In a nutshell, the problem is how to allow the server (in this case, OOS) to provide an identity to the source server. These settings allow for a number of solutions to this problem.

The two major data sources that support Windows authentication are SQL Server, and SQL Server Analysis Services (SSAS), and they are unique enough to be considered separately. Any other data source that supports Windows authentication can be treated in the same manner as SQL Server.

1. Use the authenticated user’s account

This is the option that you’ll choose if you want the identity of the person opening the workbook to be passed back to the source server when the data is refreshed, or in the case off SSAS, interacted with. It’s also the default option. If you never knew about the Excel Services Option Authentication Options button, this would be the one that you’d use.

Before you go rushing to declare that this is the best option, keep in mind that it means that the user permissions will need to be maintained on the data source for all users accessing it. Sometimes proxy credentials are a better choice. In order to get either option working however, additional configuration will be required.

SQL Server Analysis Services Data Sources

If your data source is SSAS you have two options. You can set up Kerberos Constrained Delegation (KCD) between the OOS Server and the SSAS Server, or you can use EffectiveUserName. Given that Kerberos will be discussed in the SQL Server section, and that my recommendation is to use EffectiveUserName whenever possible, we will cover EffectiveUserName here.

To begin with, EffectiveUserName is turned off by default in OOS. In Excel Services this could be turned on through the user interface in the Excel Services Service Application, but with OOS, this is done through PowerShell. As with the other OOS parameters, it’s a single line on the OOS Server:

Set-OfficeWebAppsFarm -ExcelUseEffectiveUserName:$true

With EffectiveUserName, a connection is made between the OOS Server and the SSAS server using the machine account of the OOS Server itself. The OOS server has the identity, but not the password or token of the requesting user, and that is provided to the SSAS Server to use when executing queries. This impersonation process requires a high level of trust, and the machine account of the OOS server must be an administrator in the destination SSAS instance.

Adding this account requires the use of SQL Server Management Studio 2016 (SSMS), in prior versions it was not possible to add machine accounts to SSAS. To add it, connect SSMS to the destination SSAS instance, then right click on the server node and select “Properties”. Once the dialog options, select the “Security” node, and click the “Add” button.

Next (and order is important here), select the “Locations” button, and choose “Entire Directory” (or a container where your server accounts live). Click “Ok” and and then click the “Object Types” button. Computer accounts are excluded by default, and this is where you select them.

Once selected, you can enter the machine account in the form of DOMAIN\MachineName. After clicking OK, it should appear in the administrators list with a “$” appended to it. In our case, the machine name is NAUTILUS2016OOS and the domain is NAUTILUS. THis needs to be done for each OOS server in your farm.

At this point, any user interacting with the workbook in a browser will interact with the SSAS server using their own identity, which of course means that the SSAS server needs to know who they are. The end users will need to be granted access to the data sources in SSAS, in the same way they would if they were connecting to it in an Excel client.

SQL Server Data Sources

SQL Server has an equivalent feature to EffectiveUserName, the SetUser command. This feature has been supported for years in SQL Server Reporting Services, but unfortunately was never supported by Excel Services. Unfortunately, it’s still not supported by OOS. SharePoint and OOS both support claims based identities, but SQL server does not and this leaves us with only Kerberos Constrained Delegation to provide the user’s identity to the source system.

In order for this to work, Kerberos must be configured for the OOS Server(s) to trust the account running SQL Server on the destination server to delegate credentials. However, KCD delegates Windows credentials, and as mentioned above, both SharePoint 2016 and OOS use claims based authentication. It is necessary to first retrieve the user’s Windows token in order to delegate it, and this needs to happen on the OOS server, as it is now the final “hop” before connecting to the source system.

In the past, SharePoint provided this capability through the Claims to Windows Token Service (C2WTS). The was perfect for Excel Services, as it ran on top of SharePoint and could leverage this service. With OOS that is no longer an option because it runs on a separate machine, but C2WTS can be made available here as a part of the Windows Identity Foundation (WIF).

WIF is not a prerequisite for OOS, so it must be added first. In order to do so, launch the Add Roles and Features wizard on each OOS server, proceed to the features section, and select “Windows Identity Foundation”. Allow the wizard to complete.

(Note – if you will be supporting ADFS, you will also need to install the Microsoft Identity Extensions.)

Next, the C2WTS needs to be configured to allow access for the Network Service account. To do so, edit the file “C:\Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config” and remove the comments in the <allowedCallers> section for Network Service. When complete, it should appear as below:

Once edited, run the following Powershell to start the service and set it to automatic start:

Set-Service -Name C2WTS -startuptype “automatic”
Start-Service -Name C2WTS

At this point, we are ready to start delegating credentials.

The following Kerberos settings need to be performed on a directory server, or a server that can run the SetSPN command and the Active Directory Users And Computers tool.

The first step is to add the SQL Server service and its associated account as a Service Principal Name (SPN). We need to do this for both the machine name of the server and its Fully Qualified Domain Name(s). This can be done from either PowerShell or a command prompt.

SetSPN –S MSSQLSvc/NAUTILUS2016SQL.nautilus.local :1433 NAUTILUS\SQLService
SetSPN –S MSSQLSvc/NAUTILUS2016SQL :1433 NAUTILUS\SQLService

In this example, NAUTILUS2016SQL is the name of the SQL server, nautilus.local is its domain, and NAUTILUS\SQLService is the account that SQL service is running as.

Once the SPNs have been added, open the Active Directory Users and Computers tool. Navigate to the Computers node, select the OOS Server(s), right click and select properties. Click the delegation tab, Select “Trust this computer for delegation to specified servers only” (this is the constrained part…), and “Use any authentication protocol”. Next, click the “Add” button, and then “Users and computers”. Find the SQL service account (in our case, NAUTILUS\SQLService), and save it. You should see its corresponding service appear in the dialog box.

Click OK, save everything and that’s it. KCD should be set up to allow delegation from OOS to SQL server, and any direct connected Excel workbooks should work.

This process will need to be repeated for any data source that supports Windows Authentication.

2. Use a Stored Account

A stored account is a proxy account, which is to say that all users using the workbook in a browser will connect to the data using the same credential – the one that is stored. This option uses the Secure Store Service in SharePoint, which is therefore a requirement. Usage is relatively straightforward. To set up a new Stored Account, navigate to the Manage Service Applications section in Central Admin on the SharePoint farm, and select the Secure Store Service.

Once in the service, Select the “New” button in the ribbon to create a new “Target Application” (Stored Account). Enter an ID, Display Name, and contact email (it’s required for some reason). Then, ensure that the Target Application Type is “Group”.

Once complete, click the “Next” button.

The next screen prompts for the type of credentials, and the default is for Windows credentials, which is what we’re using. Click the “Next” button.

The administrators are those users that can modify the target application (stored account) and set the credentials for it. Add administrators as appropriate. The members are those users that can use the stored account, so this should be set to anyone that can access the workbook.

Now, in addition to any regular users, there is one or more accountsthat MUST be in the members list – the computer accounts for all of the OOS Servers. This makes sense as the Office Online service itself runs as the Network Account, and it needs to consume the credentials from the SSS – it needs permissions to do so. The account should be entered in the form DOMAIN\MachineName$ – so in our example it’s NAUTILUS\Nautilus2016OOS$.

Finally, click OK to save it. The last step is to set the credentials. Select the target application, and click on the “Set Credentials” button in the ribbon. Enter the account that will be used as the proxy here. This will be the stored account that gets used to access the source data, so it obviously should have access to that data.

If your network is http based, there is one further configuration task to perform on the OOS server. By default, OOS requires https to access the secure store service. The option for this is in a PowerShell parameter, and you can change it with the following PowerShell script:

Set-OfficeWebAppsFarm -AllowHttpSecureStoreConnections:$true

Now that this is complete, go to the Excel Services Authentication dialog in an Excel workbook, select “Use a Stored Account” and enter the name of the Secure Store Service Target application that was created (in the example above, this is SSSExcelTest). Save the workbook to SharePoint, open it in a browser and refresh data. All should work.

This procedure is the same for both Analysis Services and for SQL Server. This approach does not require Kerberos, EffectiveUserName, the C2WTS, or S2S trust for it to work. It is likely the easiest option to get up and running quickly.

As with any proxy account, these accounts should only have enough access to the source data to serve the worksheet(s) they are used for. These should always be least privilege accounts.

3. None

This option was always poorly named. None does not mean no credentials, or anonymous, it means default, or the Unattended Access Account. Both Excel Services and PerformancePoint had the concept of an Unattended Access Account. This account was really just a default entry in the Secure Store Service. It’s useful when the entire organization has access to a certain body of data. Giving the Unattended Access Account access to that data means that nobody needs to configure anything – it should “just work”.

One of the casualties of the move from Excel Services to OOS was the Unattended Access Account. There is no configuration area or PowerShell where it can be set. It would seem that the “None” option cannot be used at all. However, it can, in a very limited way.

Selecting this option will cause the OOS machine account(s) to be used when attempting to access the source data. Therefore, if we grant access in the source data to the machine account, we are treating it like an Unattended Access Account. If this is acceptable from a security standpoint, then it can be used in this manner.

We have already seen how to do this for SSAS, but there is no option in SSMS to add a machine account as a security user in SQL Server, even with SSMS 2016. It is however possible. The way to do this is to use SSMS to open a new query, and run the following T-SQL command:

create login [NAUTILUS\NAUTILUS2016OOS$] from windows

where NAUTILUS\NAUTILUS2016OOS$ is the machine account. The square brackets are required. This will add the machine account as a user in the security section in SQL Server Management Studio. Once that is done, the account can be added to individual databases in the same manner as any SQL account by navigating to the database Security\Users folder and adding a new user. From here, select “SQL User with login” as the User type, click the ellipsis beside Login name, enter the machine account and select “Check Names”. Once added click “OK”, and “OK”, and then that account can be used just like any other account.

SSAS cannot use the “None” parameter in this way due to the way that the EffectiveUserName option works. If EffectiveUserName is enabled in OOS, it will simply use the credentials of the logged in user and be indistinguishable from the “Use the authenticated user’s account” option. If it is not enabled, it will try to connect to SSAS as anonymous and fail. The alternative to failing would be to open up access to all data on the server – failure is the best option here. The bottom line is that the “None” should never be used with SSAS.

Summary

Below is a Summary of the various authentication options that can be used with Excel and OOS, and the requirements to make them work.

Use authenticated user’s account with EffectiveUserName (SSAS Only)

ExcelUseEffectiveUserName = true on OOS Server
OOS Computer account added to SSAS Server Administrator list

Use authenticated user’s account with Kerberos (SSAS or SQL Server)

CTWTS running on OOS Server
C2WTS configured to allow Network Service on OOS
KCD delegation from OOS Server to Source Server/account

Use a stored account (SSAS or SQL Server)

SSS Set up on SharePoint Farm
SSS Target account(s) created
OOS Computer account added to Members for Target account(s)
Target account configured for Least Privilege access to data

None

OOS Server account configured with Least privilege access to data (SQL Server Only)
ExcelUseEffectiveUserName = true on OOS Server (SSAS)

Acknowledgements

I wanted to acknowledge the help and guidance I received while putting this together and testing. Both Kay Unkroth and Jason Haak at Microsoft were quick to answer some of the thornier configuration questions, and fellow MVP Trevor Seward was instrumental in getting me over the Kerberos hump. Thanks guys.

13 Comments

Adding Excel Services Capabilities to a SharePoint 2016 Farm

Published January 5, 2016

Excel Services has been deprecated in SharePoint 2016, but the important features that it provided have been moved to Office Online Server 2016. This article describes the necessary steps.

It’s been fairly well documented that Excel Services will not be a part of SharePoint 2016, and that the bulk of its capabilities are being replaced by Office Online Server (OOS), which is the new name for the Office Web Apps server. The Excel Services features are not all available by default, and certainly not through the standard setup procedures of old. This post will walk through the process of restoring the bulk of the Excel Services capabilities to a SharePoint 2016 farm. SharePoint 2016 is currently in beta, and is scheduled to ship in Q2 2016, but the impact of these changes can be seen and tested now.

This is the first in a series of “how-to” articles that will outline how to get all of the SharePoint-based BI components up and running. The white paper, Deploying SQL Server 2016 PowerPivot and PowerView in SharePoint 2016, published by Microsoft in December 2015, goes into great detail on these topics, and my articles are meant to be a sort of “quick start” guide. In addition, these articles are based on pre-release versions of SharePoint 2016, OOS, and SQL Server 2016, so some of these steps may change, or will become unnecessary by final release time.

Configure the Office Online Server Farm

Starting with SharePoint 2013, it became necessary to run the Office Web Apps server independently from SharePoint. In fact, multiple Office Web Apps servers could be joined together to form a farm. This is also the case with OOS. Given that OOS is the only way for SharePoint to render Excel content in a browser, our first step is to set up a (single server) OOS farm.

The procedure for setting up OOS is fairly straightforward, and is outlined in the following TechNet article, so I won’t repeat it here:

https://technet.microsoft.com/en-ca/library/mt170644%28v=exchg.160%29.aspx?f=255&MSPPError=-2147217396

This article correctly lays out all of the prerequisites, and how to install them, but it’s not as complete as the Office Web Apps version of the same article for SharePoint 2013. In particular, it doesn’t discuss how to create a farm that uses http instead of https, which is important, and simpler for testing purposes. Luckily, you can use the same procedure for OOS 2016 as was used with Office Web Apps 2013, using the –AllowHTTP switch in the PowerShell creation commandlet.

Once completed, you can navigate to ServerAddress/hosting/discovery to determine if the procedure worked. In my case, the address was http://oos2016test/hosting/discovery.

Configure the SharePoint Farm

Once the OOS farm is in place, the SharePoint farm needs to be configured in order to use it. The procedure is well outlined in the aforementioned white paper, and is also identical to the procedure used for SharePoint 2013, so it is not worth repeating those steps here. Once connected, and an IISReset has been performed on the SharePoint front end server(s), all Office files should render successfully in a browser. The ability to work with Office files in a browser should now be the same as it was in SharePoint 2013 through Office Web Apps server. At this point, it will be necessary to enable or configure features previously available through Excel Services, and some additional setup is required.

The Excel web part in SharePoint is the most visible Excel Services feature, and is one of the most common ways that people interact with Excel Services in SharePoint. While Excel Services is gone from SharePoint 2016, the web part remains, and it will work with OOS, but using it does involve some configuration. It uses the SOAP-based Excel Services web services, and the new OOS server also exposes these web services. You’ll need to add the web services capability if you want to use the web part, or if you have any solutions that depend on Excel Services web services.

Again, you’ll need to use PowerShell to do the configuration, only this time, on a SharePoint server. In the following PowerShell script, you should replace OOSServer with the Fully Qualified Domain Name of the OOS farm or server.

$Farm = Get-SPFarm
$Farm.Properties.Add("WopiLegacySoapSupport", "http://OOSServer/x/_vti_bin/ExcelServiceInternal.asmx");
$Farm.Update()

within earlier setups of Excel Services, I advised my customers to immediately go to the Excel Services configuration in Central Admin and change some of the defaults because they weren’t terribly practical. Microsoft carried some of these defaults over to OOS, but there is no longer a user interface to configure them – so again, you need to do all of this with PowerShell. You can find all of the configurable settings by opening up a PowerShell prompt on the OOS server, and entering “Get-OfficeWebAppsFarm”. Figure 1 shows all of the Excel configuration parameters begin with “Excel”.

Figure 1: Excel Online configuration options

I think a few of these parameters are impractical, so I recommend changing them. The PowerShell to do this follows the same pattern in every case:

Set-OfficeWebAppsFarm –ParameterName ParameterValue

Here is a table with some of my recommended changes to OOS:

Increase the Maximum Workbook Size

By default, the maximum size of a workbook that can be opened in a browser is 10 MB. It’s pretty common to find larger workbooks, so I recommend increasing this limit. This increase will impact performance so keep that in mind, but by default, I like to set it to 250 MB.

Set-OfficeWebAppsFarm -ExcelWorkbookSizeMax 250

Turn Off Warning on Data Refresh

As with Excel Services, by default OOS will warn the user through a dialog box whenever it accesses external data. This gets to be particularly excessive because OOS considers PowerPivot content to be an external data source, and there is no way for users to say “stop warning me”. I recommend turning this option off.

Set-OfficeWebAppsFarm -ExcelWarnOnDataRefresh:$false

If You Aren’t Using Kerberos, Turn On EffectiveUserName

When the EffectiveUserName option is used, the server is able to pass the user’s identity to an Analysis Services server, allowing all queries to run under the permission of that user. It’s a way to delegate permissions without using Kerberos. If you’re not using Kerberos, you’ll likely want to turn this on.

Set-OfficeWebAppsFarm -ExcelUseEffectiveUserName:$true

Getting EffectiveUserName working properly requires another step. The EffectiveUserName feature requires the connecting service
(the one doing the impersonation) to have server admin-level access. In prior versions of SharePoint, this would be the service account that the Excel Services application used. With the move to OOS, there is no Excel Services, and the Excel Online service uses the Network Service account. The solution to this is to add the OOS server(s) to SSAS as administrators. To do this:

Open SQL Server Management Studio 2016 (SSMS).
Connect to the SSAS server.
Right-click on the server node and select properties.
In the resulting dialog box, select Security, and then press the add button (see figure 2).
Make sure that “Entire Directory” is selected in “From this location” – if it is not, select the Locations button and select it (see figure 2).

Figure 2: Selecting SSAS Administrators from Active Directory

Next, we need to add the name of the OOS server(s) to which we want to grant admin access. However, if we just enter the name in the object name box, it will fail, because the computer objects are not scanned by default. We must first select the “Object Types” button (figure 3) and select Computers and then click OK.

Figure 3: Adding Computer Accounts to the SSAS Administrator List

Now we can add our OOS server names to the administrators list, and the EffectiveUserName feature will work. Note that you must use SSMS 2016 to do this – prior versions do not allow computer accounts to be used.

Enabling Data Connections

The EffectiveUserName feature described above allows OOS to impersonate users to an SSAS server, but this isn’t available for other data sources. In past versions of SharePoint, Windows authentication could be provided through unattended access accounts, Secure Storage Service accounts, or Kerberos. The first two allow for proxy accounts, while Kerberos provides full identity delegation. With the move from Excel Services to OOS, the proxy account options are both gone, and we are left with Kerberos alone for Windows authentication. Therefore, in order to connect to SQL server data sources from a web-enabled workbook, it is necessary to either enable Kerberos Constrained Delegation (KCD), or switch connections to use SQL Server authentication. KCD is also required in order to use a SharePoint workbook as a data source in OOS (see below).

If you plan to use KCD, there is an additional step required. SharePoint uses Claims authentication, but Kerberos implies Windows authentication. In prior versions of SharePoint, the Claims to Windows
Token Service (C2WTS) on the Excel Services server(s) would be used to translate the Claims based identity into a Windows token. Now that the Excel engine lives in OOS, it’s necessary to configure the C2WTS on the OOS server as this is not done by default. The C2WTS is a part of the Windows Identity Foundation, and if it has not been installed, it can be added as a feature from the Add Roles and Features wizard on the server (figure 4). Also, make sure you install Microsoft Identity Extensions if you require ADFS support.

Figure 4: Installing Windows Identity Foundation in order to add C2WTS to the OOS server.

Once installed, you must configure C2WTS
to allow the Network Service account to use it, and you must configure C2WTS to start automatically. To do so, edit the C:\Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config file, and remove the comment tags (<!– and –>) from the NT AUTHORITY\Network Service line. Once you have done so and saved the file, run the following from a PowerShell prompt:

Set-Service -Name C2WTS -startuptype "automatic"

Start-Service -Name C2WTS

Configuring KCD itself is outside the scope of this article, but once enabled, it should be possible to delegate user identities from the OOS server back to SQL Server.

If you decide to not use Excel embedded connections and instead use data connections (ODC files) from a data connection library, you will need to configure a server to server trust relationship between the SharePoint WFE server(s) and the OOS server(s). You must also establish this relationship if you want to use the PowerPivot for SharePoint IT Management Dashboard.

You can find the procedure for establishing S2S trust in this TechNet article. Note that you also need to set up a User Profile service in the SharePoint farm before you perform this procedure.

Wrapping Up

The move to Office Online Server brings a consolidation of technology and a few new features, but it’s significantly more involved to set up. The good news is that you don’t have to enable anything that you don’t need. If you are an established SharePoint shop that currently leverages Excel Services to any degree, you will want to carefully plan and test any new environment before making the leap. Here there be dragons.

If your customers use PowerPivot enabled Excel workbooks, setting up OOS will allow them to open these workbooks in a browser, but not interact with them. For that, you need to introduce an Analysis Services PowerPivot mode server into the environment. I will discuss that topic in my next article.

28 Comments

Using Per-User Identity with Reporting Services and SharePoint

Published September 3, 2012

Almost anyone that has dealt with business intelligence in the Microsoft space is aware of the double hop problem. Simply put, when a user wants a server to execute a process on their behalf, that process will have a different identity, if any at all from the originating user, and therefore user focused operations such as per-user security trimming can’t be performed. The traditional solution to this problem in the Windows world has been to use Kerberos authentication, which allows server to pass on secure user tokens to other servers on behalf of originating users.

Unfortunately, Kerberos requires additional infrastructure, and is not adopted in all organizations. Smaller to mid sized organizations tend to stay away from adopting it, primarily due to its perceived complexity, which leaves them with the double hop problem. In the long term, claims based authentication promises to solve this problem, but it is still in its infancy, and is not adopted at all yet in the SQL Server suite of products, which is where double hop pain is felt most keenly.

The new BISM tabular model with Power View works around this problem by taking advantage of the EFFECTIVEUSERNAME property available in Analysis Services (I’ll be writing more about that later), as does Excel Services and PerformancePoint Services in SharePoint 2013. With EFFECTIVEUSERNAME, the server makes its connection with the data source using its service credentials, but then every query identifies the originating user, and those queries are executed in the context of that user. It’s a clever workaround, and takes care of much of the BI stack, but what about Reporting Services and relational data?

As it turns out, Reporting Services has been able to do this sort of thing for a long time. It’s just been rather cleverly concealed or misunderstood. SQL Server itself has a function, SetUser() that can be used by someone with sufficient privileges to impersonate another user. Originally implemented for testing purposes, Reporting Services takes advantage of it in much the same way that EFFECTIVEUSERNAME works in Analysis Services. The place to turn on this function is within a data source editor.

Using SharePoint Integrated mode, there are 3 main tools that can be used to define a data source. A data source can be created from any library that is configured to use the Report Data Source content type. In addition, SQL Server Report Builder can be used to edit a data source, or to create an embedded data source in a Report. Finally, Business Intelligence Development Studio (BIDS) or SQL Server Data Tools (depending on your version of SQL) can be used to create shared data sources. And the best news is, the interfaces are all different!

Setting Connection credentials in SQL Server Data Tools

Setting Connection credentials in SharePoint 2013

Setting Connection credentials in Report Builder

The option that we’re interested in, in all three cases is “Use this user name and password” (stored credentials). In the case of Data Tools or BIDS, the impersonation option isn’t available. Normally what would happen is that the connection would be deployed to the server, and then edited afterwards. We can therefore ignore this interface. However, examine the description of the impersonation option in both SharePoint and Report Builder. Although worded completely differently, they mean exactly the same thing. And in my opinion, Report Builder has it right. In fact it’s a stretch to say that the SharePoint screen isn’t dead wrong.

The SharePoint form can only be considered correct if the word “this” applies to the currently logged in user. To my mind, when I read that option, I am led to believe that it will be set to the account that is being used to make the connection (the stored credentials), when it is in fact the opposite. The setting in Report Builder is far clearer and more accurate.

When the option is checked, the SetUser() SQL function will be used in advance of any queries performed by the report, and the value will be set to the currently logged in user, NOT to the credentials specified under “Use this name and password”. The credentials specified here are used to make the connection to the SQL server, and because of the security restrictions of SetUser(), MUST have at least the dbOwner role on the queried database, or the SYSADMIN fixed role on the server. My recommendation is the latter if possible. This requirement also makes it very important to restrict the editing of the Data Source.

I imagine that most of the confusion around this feature comes from the fact that in most cases, when you are using impersonation, you are saying “I want to execute this function as this account”. However, in this case, with stored credentials, it’s always the stored credential executing the function, and what we’re asking it to do is to impersonate the currently logged in user. It’s sort of backwards to the way we normally think about impersonation. It’s not immediately intuitive as to why a logged in user would need to impersonate themselves, but that’s basically what’s happening.

Using this option therefore allows you to utilize per user permissions through Reporting Services on SharePoint without having to use Kerberos. This is a good thing, but you should be aware that in many cases, using a proxy account (by not selecting the impersonate option) may be a better option. There are several drawbacks to using per-user authentication. Impersonation should only be used when it is absolutely required.

If you open up the report processing screen for a report that uses a data source defined for impersonation, and select the “used cached data” option, you will receive the warning “This report can not be cached because one or more of the data sources credentials are not stored”.

The reality is that although the credentials are in fact stored, the report could be different for different users, and caching depends on a consistent result. Therefore, to prevent confusion, it’s not allowed. If the report is particularly large, this removes an important performance optimization technique.

From the same screen, it’s also made very clear that snapshotting is not an option when impersonation is being used, from the error “This report can not run from a snapshot because one or more of the data sources credentials are not stored”.

The reasons are the same as for caching, and the implication is that snapshots cannot be created, preventing us from storing a version history for the reports.

Finally, subscriptions are also rendered useless through the use of impersonation. An attempt to create a subscription to a report using an impersonated data connection results in the following error:

Per-user identities also require management on the SQL server side. Because we are impersonating the currently logged in user, that user must be managed from within SQL itself, whereas a proxy account only requires that account to have access to the data in question.

To summarize, Kerberos is not required to do per user queries in Reporting Services for relational data. The SetUser() function in SQL Server combined with the Execution Context option in data connections allow this to be performed quite effectively. However, just because it can be done, doesn’t mean that it should be. In many cases a simple proxy account can do the job, and should likely be allowed to, unless the requirements absolutely demand otherwise.

8 Comments

Connecting to Cubes and External Data with Excel in SharePoint

Published December 6, 2010

While many people are still unaware of it, Excel 2010 (and even previous versions) is a very powerful business intelligence client. That’s right, I said Excel. And I don’t mean the classic grab some data, do some charts and email it around sort of Excel, I mean connecting it to Analysis Services cubes and performing fast, useful data analytics on known sets of data. It can also go off and do some pretty amazing things with the Data Mining add-in, or PowerPivot, but for now I’m going to restrict myself to using core capabilities, and getting them published to SharePoint.

To start with, it’s important to understand how SharePoint interacts with Excel. Of course, at it’s core, you can store Excel files in a SharePoint document library,and open them in Excel. However,starting with SharePoint 2007,SharePoint included Excel Services, which allowed you to open a spreadsheet directly in the browser (without having Excel installed or using any ActiveX trickery). It also provided an Excel calculation engine, that was programmatically callable. Why would that matter? A power user could develop a complex model with Excel, store it in SharePoint, which could then be used as a calculation “black box” for other things. The model could also be tweaked by the power user as necessary with them needing to worry about coding. Finally, you could expose part of the spreadsheet (and named range or object) through the Excel Services web part, which would truly allow you to incorporate Excel content into a dashboard.

SharePoint 2010 brings more to the table, including not only the browser consumption of spreadsheet content, but editing through the Excel Web Application.

However, all of this power does not come without its risks, and when interacting with external data, risks abound. Microsoft has done an excellent job of providing us with a highly secure infrastructure that allows us to do what we want here, but the only trouble is that it’s not always clear which approach to take. My aim in this article is to navigate through the process of connecting to an external data source (an analysis services cube, but the principle applies to others) in a particular scenario in a simple fashion. Our scenario is a fairly common one:

One Front End SharePoint Server
One SQL back end Server hosting the SharePoint databases
One SQL server hosting the Data Warehouse and the Analysis Services cubes
Kerberos not installed in the environment

In this environment, we have an authentication problem, the famous double hop problem. If I as a user ask the server to process a spreadsheet that connects to external data, it can’t just take my authentication token and pass it along to the external data source. What we need to do is to set up a proxy account (this has its own set of implications that I won’t get into here) and we’ll do that via the secure store service. If you’re using Kerberos, then you don’t have the double hop problem and the Secure Store part of this won’t apply, but then you’re probably busy enough dealing with Kerberos issues anyway….

If you’ve ever connected to external data, and then sent the file to someone else, you’ll know that they get prompted to verify that they want to connect to the data source and that they trust the connection. In this case, the author has created an embedded data connection. Embedded data connections are not allowed (or at least are strongly discouraged) on the server, because it has no way of verifying the authenticity of the connection.

The way that we deal with this in SharePoint is by creating a connection file, and then publishing it to a trusted location in SharePoint. Administrators need to take heed, in that by default, Excel Services trusts all SharePoint locations, which makes life easy, but not necessarily secure. The library that the connections are stored in should also utilize approval features, but this is not required. This walkthrough isn’t concerning itself with the security aspects, but they need to be considered in any real world situation.

Most of the steps below only need to be performed once, and connection documents can be reused, etc. However, this walkthrough is aimed at getting everything all set up from scratch.

We also don’t want to store our credentials in our connection string, so we will utilize the Secure Store service in SharePoint which will allow us to use, without necessarily knowing, a set of credentials. This will allows us to work around the double hop problem in a secure way. We will start with the setup of the Secure Store Service.

1. Set up the Secure Store Service ID

From Central Administration, navigate to Manage Service Applications, and click on your Secure Store application. If you don’t have one already, you’ll need to create one. You should know that SharePoint Foundation does NOT come with the Secure Store service. However, Search Server Express 2010 does come with it (and a few other things). Given that it’s free, it provides a nice option.

The Secure Store Service Application relies on both the Secure Store Service (duh) and the Claims to Windows Token service. You’ll need to make sure that they’re both started in the “Services on Server” Section in Central Administration System Settings.

The secure Store application requires an encryption key. If one has not already been created, you’ll see a message indicating that you need to do so. The process is simple, just click the “Generate New Key” button in the ribbon.

Once a key has been created, we need to create a new target application, which is essentially a set of credentials. This is the application that our connection strings will reference when they need to connect to a back end data source. You create a new application by clicking the “New” button in the ribbon. The New application screen then appears.

There are a couple of things to note on this screen. Firstly, the Target Application ID is the ID that you will be using when you set up your connection below. You can name it what you like, but you’ll need to remember what it is. The Display Name and the Contact E-Mail need to be filled in, but the important thing to note is the Target Application Type field. If this is to be used by more than one person, you need to make sure that it is set to Group. By default, it is set to Individual, which doesn’t work so well in a shared environment. Take it from me – I found out the hard way. When this is filled in, click Next, and you’re presented with the following screen.

The Administrators are just that – the people who will set the properties of this set of credentials. The Members are the people that will be allowed to use this credential set in connections, External Lists etc. In the example above it’s set to anyone authenticated, which again, I wouldn’t recommend in production…..

When done, click OK, and we’re done right? Not so fast. We never actually set the credentials for this application, just everything around it. To do that, we select the application, and click the “Set (credentials)” button in the ribbon, or hover over the ID in the list and select “Set Credentials” from the dropdown.

In the subsequent screen you enter the account and the password (twice) of the credentials that are to be used as a proxy. Click OK and you’re done. A couple of things to note. If using a Windows account the name should be in DOMAINACCOUNT format. The proxy account is NOT a managed account, and if the password changes, you’ll need to come back here to update it. The proxy account should be a least privileges account, with access only to the things that are absolutely necessary to retrieve the appropriate data, or whatever its purpose is. Don’t add it to the Domain Administrators group.

OK, now step 1 is done. Whew.

2. Set up a Data Connection Library

The next thing we need to do is to set up a library to store our data connections. If you’ve set up a BI Site already (to use PerformancePoint), you can use the libraries there. Depending on your requirements, I find that it’s often a good idea to centralize this library and use it from different locations, but your requirements may vary. What we want to create is a Data Connection Library. This library will be used to store connections for both the Office Applications (ODC) and InfoPath UDC).

From the Site Actions menu on the site where it is to be located, select More Options, the, in the subsequent dialog box, Filter by Library, and select Data Connection Library. Give it a name (Don’t use spaces here, you can always come back and add them later, but we don’t want spaces in the internal name), and click Create

What makes this library special is that it uses the “Office Data Connection File” and the “Universal Data Connection File” content types. You could always add these content types to any old document library and achieve the same effect. You could also include Reporting Services connections if you’re using Reporting Services in integrated mode.

This library also needs to be registered as trusted in the Excel Services Application. This is done through the Manage Service Applications section of Central Administration. Simply click on your Excel Services application, click Trusted Data Connection Libraries, and add the URL of your library, if not already there.

3. Set up a Library to house the Excel Reports

You can store the Excel Report that we’ll be creating below into any document library in the Site Collection. If you have set up a BI Center, then you already have a “Reports” library, whose purpose is to do just that. Oddly, by default, this library isn’t set up to contain Reporting Services reports (.rdl files), but that isn’t relevant to my task here.

You simply need to create a new document library, and for the purposes of this example, I’ll call mine Excel Reports (original, huh?)

You’re now ready to create our connection. We’ll use Excel to do that.

4. Create And Store The Connection File

Open a new Spreadsheet in Excel. Click on the Data tab, then click the “From Other Sources” button and choose “From Analysis Services” (obviously, if you’re using something else, choose that).

Enter in the name of your server, and click Next, Select the Database and Cube that you want to connect to, and then click Next again. We’ll need to do a couple of things in the last screen that appears.

First, select “Always attempt to use this file to refresh data”. Then, click the “Authentication Settings” button. This is where it gets interesting.

Window
s Authentication is what you would use if the data resides on the same machine as the SharePoint front end, or your organization is using Kerberos. With this setting, the credentials of the user are used to connect to the data source.If you select None, then the credentials identified as the “Unattended Service Account” (if configured) in the Excel Services configuration will be used. You can only use one of these accounts, and when configuring it, it too will use the Secure Storage Service. We want to select our credential set and we do so by selecting SSS, and entering the ID of the credential set that we created in step 1 above.

Next, we need to save this connection into the SharePoint data connection library that we created in step 2. Click the Browse button, enter the URL of the library in the Address bar, choose a name and click save.

Finally, When you’re done, click finish, and fill out the metadata form that pops up with any comments or keywords that you might want to use later to fine the connection document. Now we have a connection document in the connection library.

5. Create The Excel Content

When you’re done creating the connection document, Excel will prompt you to insert a pivot table or chart. Choose the location, and Excel will insert it for you, and put you in pivot edit mode. You can select your dimensions and measures, and build your chart accordingly. When you’re ready, your worksheet should look something like this.

Later, we’ll want to show just the chart on a dashboard page, and to do that, we need to make sure that our chart has a logical name, so we need to do that, as highlighted above. Any named range can be published out to an Excel Services web part. When ready, it’s time to publish to SharePoint, but we also want to set some file properties first. These properties are very well hidden….

Click on the “File” tab to go to the backstage. Once in the backstage, click on the “Save and Send” tab on the left hand side. Then click on “Save to SharePoint”. Your screen will appear as follows:

Finally, we need to click on the Publish Options button. This allows you to control what gets used by Excel Services, and what appears when the spreadsheet is opened in the browser. It also lets us define parameters which can be used by the Excel Services web part, but I won’t be using parameters here. I will however choose to publish only my chart and my pivot table to Excel Services, so I click on the dropdown option in the Show tab, change it to “items in the workbook”, and check my two items.

Finally I can click OK, then click on “Save to SharePoint” and save the spreadsheet in the library created in step 3 above.

6. Test the File and Publish the Chart in a Dashboard

Navigate to the library that you stored the report and click on it. The file should open in a browser, and you should see the first item (alphabetically) that you set to publish above.

You can switch between published items, using the view dropdown highlighted above. Once you’ve gotten this far, everything is working, and we’re ready to put our chart into a dashboard page.

All that we’ll need to know is the name of the item, and the address of the spreadsheet. In our case, our item is “Chart 2” and the URL of the spreadsheet is http://uvspdev2010/ExcelReports/MySpreadsheet.xlsx. Navigate to anywhere in the site collection that you’d like to show the chart. I’m going to use a team site. From the destination, select Site Actions – Edit Page (or select Edit from the ribbon). Place your cursor where you want the chart to appear, click the Insert tab on the ribbon and click the Web Part button. Select the Business Data category, Choose the “Excel Web Access” part and click insert.

Once added, click on the “Click here to open the tool pane” link, and enter all desired parameters. The two crucial parameters are Workbook and Named Item. When adding content to a dashboard, I find that it is better to remove all of the buttons and web part chrome, but that’s totally dependent on the use case. When ready, my web part parameters look something like this:

At this point, you can click OK, and you should see your item on the page in context.

t=”773″>

Congratulations – you’re done!!

This was meant to be a “Hello World” walkthrough, and thus, I’ve left out quite a bit. You can add slicers and all kind of cool BI functions to your sheet, and they’re work in the browser. This is showing data in a cube, and therefore the chart will be updated when the cube is. You can also use parameters in Excel and drive them through filter web parts and connections on the display pages.

There ARE a lot of moving parts here, but once the infrastructure is set up, power users can do some pretty spectacular things using just Excel and SharePoint, and they can do so in a fully managed environment. Oddly enough, chances are that your power users probably already know both of these tools.

21 Comments