Dans l’article précédent, je présentais un scénario de Self-Service BI : faire des rapports Reporting Services sur des modèles Power Pivot.
Techniquement, c’est un peu comme ouvrir un classeur Power Pivot dans SharePoint dont vous avez le schéma d’exécution ci-dessous. En requêtant le fichier XLSX, ce sont d’abord les services Excel qui répondent puis passent le relai au service Power Pivot.
source MSDN
Dans le cadre d’un appel via EWA (Excel Web Access), la sécurité est gérée par SharePoint lui-même. En effet, la sécurité est au niveau du classeur et dès que EWA l’a vérifié, c’est lui qui fait le boulot et s’arrange avec l’instance SSAS de PowerPivot (je l’ai fait courte).
Avec SSRS en tête de chaine, c’est un peu différent puisque que SSRS se présente avec l’identité de l’utilisateur directement au service Power Pivot (après avoir que EWA ait fait le forwarde vers les Web Services Power Pivot). Le problème c’est que le service Power Pivot est configuré pour fonctionner en NTLM et là, on est confronté au problème du double-hop si SSAS et la ServiceApp sont sur des machines différentes de la ferme.
Kerberos ?
Oui, la réponse est Kerberos, comme j’ai déjà pu en parler lors de différentes conférences.
Les étapes (en résumé) :
- Configurer le service Power Pivot pour supporter Kerberos
- Créer les SPN et les délégations entre la ServiceApp Power Pivot et l’instance SSAS
Le point noir, c’est que la première étape nécessite la modification de fichier Web.config dans la ferme, chose que les administrateurs SharePoint autorisent rarement…
Sources :
http://blogs.msdn.com/b/johndesch/archive/2012/04/23/using-powerpivot-workbooks-from-a-mid-tier-server-configured-for-kerberos-authentication.aspx
http://sharepointalldocs.blogspot.fr/2011/12/ssrs-reports-or-excel-services.html
Business Geek 