Wednesday, January 18, 2012

Authentication setting: where are you?

When you are planning to consume data from all kinds of data sources you need to understand why, where and what to specify for authentication settings. The authentication landscape is fairly complex even from an end user perspective. There are many places where you can specify or create connections and finding them is not always easy: rich office clients, authoring tools, browser, service applications, secure store, BCS, external content types and web applications all play a part in the outcome of the mapped set of credentials which is accessing the data source.

Why is this important?

Users do not care what you have specified on the SharePoint side. They already have this nice Excel sheet connected to a SQL database and they have heard that you can render it on a SharePoint site as well. But somehow it doesn’t seem to work. What will you tell your end users? How are you going to educate them?
To get a better understanding of authentication settings we need to make a difference between getting data from within client applications and from within a browser on a SharePoint site or through a SharePoint Service.
Let us focus on the client side.

End user tools

The end user has a number of client tools available which are capable of fetching data from data sources:
  • Rich office clients
    • Word
    • Outlook
    • SharePoint Workspace
    • Excel
    • InfoPath
  • BI Authoring tools
    • Excel with or without PowerPivot for Excel
    • Report Builder 3
    • PerformancePoint Dashboard Designer
    • SharePoint Designer 2010
    • Visio 2010
    • Business Intelligence Developer Studio

Data connections

Secondly, there are various ways of defining external sources:
  • Embedded data connections
    • Like in Excel you create them through the Ribbon
  • External data connections
    • .odc or .udc files you have saved to a SharePoint data connection library
  • External content types
    • Running on the client through the BDC runtime

Data sources

Finally, there are various data sources to fetch data from. To name a few:
  • Databases
  • WCF services
  • Web services
  • Custom data sources
  • .Net Connectivity Assemblies

External content types

Let us focus a bit on External Content types. If you need to get data from an external source you may want to use External content types in case you would like to reuse the data in various places or need basic CRUD actions on the data itself. A tool like SharePoint Designer 2010 may be used to define these External Content Types. I will not describe the various steps you need to perform but instead focus on the different authentication settings.
When configuring External content types the authentication mode is selected. Each authentication mode represents a different way of processing incoming user credentials and mapping them to a set of credentials for the external content type.
To simplify matters the following list shows you how the various settings map to what:
  • Mapped to Impersonated Identity
    • Digest credentials
    • External Credentials
    • RDBCredentials
    • Windows credentials
  • Mapped to Users Identity
    • Pass through
  • Mapped to BDC Identity
    • Revert to self

Impersonated Identity

The first four settings all map to the impersonated identity. It basically means that the user credentials will be replaced by another credential set. And that is where the Secure Store plays its part. The Secure Store allows you to define so called target applications.
A target application defines a mapping between a (group of) member(s) to a credential set. The credential set can be a Windows Identity or an External Identity. A member can be the user account or for instance an active directory group or in some cases the application pool account of a SharePoint service.

Pass through

Meaning that the users identity will be used to access the data source. In case the data source is more than one server hop away from the user, this will fail as the user identity cannot be delegated to the data source. Another option would be for instance to use Kerberos authentication.

Revert to self

It means that the user identity will be replaced by the BDC identity which is the identity the BDC runtime is running on the client side. In browser based scenarios this would often result in the application pool id of the BCS service application.
What we just described are the client side authentication settings for External content types. These content types may surface in for instance Outlook.
In most BI authoring scenarios however, you are not using External Content Types. Instead you are connecting your client tools to data sources like SQL Server Analysis cubes, SQL databases or Web Services.
It greatly depends which tool you are using, which service and if you are doing this client side only or are planning to use it on SharePoint sites as well.

Embedded vs. external connection files

In all those cases your data connection can be defined as embedded or as an external file. What does that mean? Embedded means that you are using the various client applications to define data sources which are saved as part of your file. The file could be Excel or perhaps Visio etc. External means that the file pulls the data connection info from another file, called the ODC or UDC file. Often there are various ways of “externalizing” existing embedded connections to external ones. Obviously, the benefit of external ones are reusability amongst others.

Classified Intel: Excel Services

Take for instance Excel. If you connect your Excel sheet to an external data source you can do so through the Ribbon -> Data -> Get External Data
image
If you connect to a SQL database for instance, a wizard will guide you through the configuration steps. Generally it means specifying a server name, a database name, a table and that’s it. The most common mistake: although this works for you in the client tool, it most likely won’t work in the browser.
image
If you render the same sheet with Excel services you would need to specific the settings through the button you can see in the Screenshot: Authentication settings. I will describe how that works later on, but keep in mind that this is the easiest example!
It already becomes different when using for instance Excel with PowerPivot. And if you would be using InfoPath than specifying these settings will keep you looking as there is no such button and you need to export the connection file, modify the XML and so forth.
For now we are talking client side only and it is important to remember that this kind of setting is called embedded.
Now, it may be that you are consolidating connection settings into a SharePoint connection library. In that case you can export the connection we just made in Excel by again using the Ribbon -> Data -> Connections -> select your connection -> Properties -> Select Definition Tab -> Choose button Export Connection File.
You can store the connection file in a SharePoint library for use. Later on you will see that you need to trust connection libraries to be used by SharePoint. But for now, we are ok with that.

Prepare for lift off: PowerPivot for Excel

If you have installed PowerPivot for Excel than you will notice that the PowerPivot window has its own Get External Data part in the Ribbon:
image
If you would like to pull info from Analysis Services for instance you will be prompted for authentication settings again. Keep in mind that this is authentication against the cube not the database.
image
Now this is information that will be used when rendering it on the client. If you would like to publish it to SharePoint and would like to use PowerPivot for SharePoint to render the pivottable, then this information may or may not be used. Instead you would need to define authentication settings through the browser:
image

Data refresh for PowerPivot

Credentials
image
Data sources
image

Refresh on behalf of the user

As you can see in the screenshots it basically tells SharePoint that whenever the user clicks on the refresh button in the browser, which authentication setting should be used: the account which has been specified as part of the PowerPivot for SharePoint Service Application. Or a predefined Windows user credential or the credentials specified by a target application ID. As I have explained earlier the target application ID (SSS ID) is a mapping between members and a set of credentials. If you are using an SSS ID here, PowerPivot for SharePoint will look up that application in the Secure Store and next will look for a member which matches the current user. If it finds that current user as a member it will map it to a different set of credentials.

Refresh on behalf of SharePoint

The other section is quite similar to the previous one and will be used by SharePoint to refresh data according to a schedule. The difference is that the first setting is referring to the credentials contained in the workbook. Meaning that in this case the settings you have defined as a user in the Excel workbook – PowerPivot window, will be used.

On the server side it is different

If you have made it this far you are probably interested in how things are configured on the SharePoint site. The answer is: it depends on the Service Application you are using. Still, most authentication settings and service applications share a similar model:

Connection settings

  • NONE: If a server side connection setting specifies none then this means that SharePoint will use the identity of the SA. In most cases this is the Application pool identity the Service App is running in.  The important thing here is that you can specify which SA’s use which target application of the Secure Store in those cases where none is specified. The general idea is to map the application pool account to an unattended service account which will have access on the data source. You don’t want to add the application pool identities to the data sources. Instead you create a target application for each Service Application where the application pool identity is the member and the set credentials are the so called unattended service account. You will add the unattended service account (read account) access to your data source. This is a very useful scenario and often used for BI solutions. In most BI solutions you don’t want to query complex cubes on a per user identity. It would definitely require large amounts of memory on the SharePoint server as each query result will be cached for each user. In those cases you are using the unattended service account which will greatly reduce the cache and improve performance.
  • Windows credentials: again, if you have Kerberos enabled this may be useful for you but otherwise you might find yourself facing a double hop scenario and windows cannot pass your credentials a second time.
  • SSS ID: a scenario where you actually know who has access to the data source, for instance if you have a special BI group of readers defined. In that case you create a target application at the Secure Store and add the AD group as a member and a set of credentials as the account which actually has access to the data source. Very useful for all kinds of locked down situations.

Complex?

Do you get it? There are many places to define authentication and you have to carefully plan those when rolling out advanced features. Below you will find an example. You will be surprised!
Summarized example for Excel and PowerPivot:
The example below will show you where you can specific authentication settings. Together with the explanation I have given you in this blog article you should be able to understand which authentication setting is applicable when. The example also shows you Excel and PowerPivot only. For other client tools and service applications it is different but at the same time similar patterns are applicable.
  • Excel:
    • Data tab in the Ribbon
      • Client side settings
        • Windows credentials
        • Database account
        • Excel services settings
          • None: no authentication (meaning that the Excel Services unattended target application ID will be used)
          • Windows authentication (useful when using Kerberos)
          • SSS ID (use the mapping as defined by the target application within the Secure Store)
    • PowerPivot for Excel
      • Data tab in the Ribbon
        • Client side settings
          • Windows credentials
          • Database account
    • SharePoint
      • Excel services Service App
        • Unattended target application ID
      • PowerPivot for SharePoint Service App
        • Unattended target application ID (so called, as specified by administrator)
      • Excel sheet
        • PowerPivot refresh schedule
          • On user behalf
            • As specified by admin
            • Specific windows credentials
            • SSS ID
          • Automatic according to schedule
            • As specified by workbook
            • Specific user account
            • SSS ID

Mini debriefing

What about the other Service Applications?The pattern for most other Service Applications is the same:
  • Either you are directly connecting to the data source: for instance from the client tools like Excel
  • Or you are connecting through an External Content Type
  • Or a SharePoint service is connecting for you either by passing the credentials, using a specific target application or by falling back to a so called unattended target application. In those cases the Secure Store determines the target credentials which will be used to access the data source.
What about the other Client applications?Keep in mind that Client applications like Excel and InfoPath may offer the same functionality for specifying the authentication settings but in different places. Or sometimes completely hidden for the end user. Take for instance InfoPath. You are able to define a data connection but no SSS ID. In that case you need to export the connection to an external file, edit it with notepad, uncomment the lines about authentication and voila you are able to enter a SSS ID.
It is almost impossible to completely cover all differences at once but patterns are similar and MSDN will help as well.

Thursday, December 01, 2011

Could not load file from input library: Word Automation

Today I was struggling a little bit with Word Automation Services. I am trying to test Word Automation services and see how it affects memory and cpu utilization. For that purpose I have created a shared documents library on a team site and pulled a few lines of C# code to create a conversionjob from the Web like you can see below. I extended the script to output all Errorcodes and Errormessage from the so called FailedItems which is a collection you can access through the Status object.

image


image

The error
During testing I received an ErrorCode 6 and the ErrorMessage:

Could not load file from the input library
.

According to this link: http://technet.microsoft.com/en-us/library/ff808318.aspx#FailedConversion there are various ways of troubleshooting issues but the one I just mentioned is not described.
After some more web searches I discovered an article which states that Word automation uses one core for each active conversion job. The default setting is 1 and you need to make sure that you have at least one free core available. Well, that didn’t seem the issue. More interesting is the fact that the article states that if Word Automation Services is not able to complete your request like in situations where your server is too busy, it will yield the same error message but with a different Error code (3).

The root cause
In the end I discovered by using the ULS viewer and by running the Word automation services on just one server that the application pool account which is running the Word Automation services, did not have access rights.

The Solution
Run SharePoint Management Shell with the following:

$w = Get-SPWebApplication –Identity http://yourwebapplicationurl
$w.GrantAccessToProcessIdentity(“domain\yourapppoolaccountrunnigWordAutomation”)


If you are not sure which account is running Word automation then I would suggest to go to:
  • Central Admin –> Application Management –> Manage Service Applications
  • Manage Service Applications –> Select Word Automation Services and click Properties in the Ribbon
  • Write down the Application pool
  • Browse to Security –> Configure Service Accounts
  • Select from the drop down the Service Application pool you have written down previously
  • Write down the Account that shows beneath the drop down

Friday, November 25, 2011

AlternateCSSUrl + Save site to template = AlternateHeader issue

Last week I was experiencing broken foundation pages or malformed top navigation bars. In my case this was related to having a custom (aka Saved) site template and the AlternateCSSUrl setting.

The AlternateCSSUrl setting

Most companies have a specific corporate identity and as a SharePoint designer they ask you to change the look and feel of the teamsites to adhere to that identity. In some cases people use themes to implement the color scheme and main font family. Something which is very useful as it also creates the gradients for you. In other cases this might not be enough and additional CSS is required to change for instance the position, background images, line spacing etcetera.

There are various ways to attach your custom CSS to the page. Some people are activating the Publishing Infrastructure and Publishing features. This results in a Masterpage link on the Site settings page. On that page you are able to enter an Alternate CSS link. That link will be automatically added to every page by the CSS link control which is part of the default master page. It will be added after your (themed) Core css files.

But what if you are not using the publishing features? In those cases I would definitely not recommend editing the master page. There are two options:

- Build a FeatureActivated event receiver which will set the AlternateCSSUrl property and apply the theme. Do not forget to implement the FeatureDeactivating feature as well.

- Build a custom action which is a scriptlink and add a scriptblock which will include the CSS in the header using javascript for instance.

Personally I like the first option most and use the second one for including for instance CSS that is required by JQueryUI. The disadvantage of the second one is that it will be injected, which might be noticeable.

If you are implementing the first method then you will need an event receiver. The Event Receiver would look like:

image

Save Site as template
Assume that you have created a new site using an out of the box Teamsite template and the solution that applies a new theme and sets an alternateCSSUrl using a feature event receiver and feature stapling. Everything looks fine and you start configuring your site. At some point you would like to save the current site as a template in order to create subsites using that template.

You browse to site settings and select the option Save Site to template. This link will be hidden as soon as you are using the publishing features and it is not recommended to save templates of publishing sites.

The saved template will be stored in the Solutions gallery of the site.

Now create a subsite using the newly saved site template. Browse to Site Actions -> New site -> select your custom site template, enter a subsite name, URL name and press OK. The subsite will be created and once that process finishes you will be redirected to the homepage of the newly created subsite.

The issue
If you have followed the steps as described above you have a newly created subsite. Try to browse to the Site settings page. You may experience one of the following symptoms:

- the header shows but nothing beneath the top navigation

- you see a site settings page but there CSS code is displayed in the top navigation bar

- you encounter an unexpected error (most likely)

What has happened?
If you try to render for instance the Site Settings page, the page will try to render the top navigation. As the Site Settings page is a foundation page, the top navigation is different than other pages from the _layouts directory which are related to the publishing features like Masterpage or Welcome page links.

The Settings.aspx page uses the v4.master unless you have specified otherwise.

The v4.master page defines a contentplaceholder for the top navigation. Inside the placeholder you will see a ASP:Menu control for rendering the top navigation. However, the contents of the placeholder control will be overridden by the settings.aspx page.
In the settings.aspx page you will see that instead of the ASP:Menu control an user control will be used called LinkSection.ascx. This control you can find in the ControlTemplates folder on each SharePoint server.

The LinkSection control checks a web property called AlternateHeader. According to MSDN the AlternateHeader can be used to define an ASPX page to render an alternative top navigation.

When we check the AlternateHeader property of our newly, malformed subsite, we will notice that it has been provisioned with our AlternateCSSUrl value!

Well, that is certainly NOT what we want and it seems to be a bug.

The solution
Try to set the AlternateHeader back to the null value using PowerShell and you will discover that the subsite works perfectly, including the custom CSS and theme like on the root site:

$w = Get-SPWeb -Identity http://urltoyour/subsite
$w.AlternateHeader = $null


Note:
It seems that the issue has been solved by a hotfix but as most companies only apply Service Packs and no CU’s unless business critical, I would definitely recommend to clear the AlternateHeader yourself.