Many of you have already seen the announcement covering PerformancePoint rolling into SharePoint, with the next release already dubbed "PerformancePoint Services".
Big deal right? Monitoring and Analytics will still be there and the least used and often forgotten Planning will move off to pasture. So what does Kerberos have to do with this change to PerformancePoint?
Probably more than you think.
In a typical small farm, PerformancePoint will be deployed in one of several manners, either scaling out with the web front ends or on separate app servers. This works well even in the current deployment model, however, more and more, company security policies are pushing for data to be locked down at the source level, even for analytics.
PerformancePoint Services will be just one piece to the new SharePoint for BI capability stack – Project Gemini is coming along nicely with a lot of extreme Excel enhancements - -thick client analytics for the power user at the desktop level.
With the new version of Office, we are looking at an expansion of the toolset used to hit the data, but what we do not know, and what I do not expect to happen, is whether security will continue to be fully maintained by the user roles in the Monitoring database. In such a future environment, without Kerberos, you would essentially have a set of roles and access configured via the Monitoring web services, and then the normal groups and roles on something like your SSAS databases. On large environments, this will be incredibly cumbersome.
Enter Kerberos – by using NT groups and authentication throughout, data sources can remain, at the data source level, locked down by individual logins and allowing the Monitoring service to pass the user credentials when accessing PerformancePoint web parts. With this implementation in the security architecture, despite the end user tool used, users can now have a more centralized security mechanism and data managers can feel better and have less work than trying to keep up with all the separate app user accounts and what access rights they map to.
Kerberos, while not entirely straight forward in implementation, solves the double hop issue and allows you to scale out your farm with the PerformancePoint services able to communicate freely to data sources on disparate servers and maintain security using AD.
Mike Plumley of Microsoft has made an instruction video posted here on implementing Kerberos.
I have also downloaded it and saved it to my site in case it goes missing ( this actually happened with the Business Intelligence Metadata Whitepaper Microsoft posted – popular, but it kept disappearing on the site, so it is another one I have saved to my site ) – but I will only activate the link if someone lets me know it has disappeared. The file is 72 MB and too many downloads will cripple my meager little hosted blog.
Other references for Kerberos directly related to PerformancePoint:
As you have probably guessed by now – this is a current deployment consideration as well. Scaling PerformancePoint to use multiple SSAS servers where NT authentication pass through is a must will require this type of delegation in order for deployment to be successful, so luckily, these instructions do exist.
One of the extras in going through the pain in implementing Kerberos? Reporting Services works wonderfully in SharePoint integrated mode, but Kerberos is also a requirement for a proper deployment – so, do the infrastructure work one, and reap the benefits twice over!
Tags:
Categories: Performance Point