Bon allez, après un énième constat qu’il semble plus simple pour certains de mettre son login password dans les sources de donnée SSAS, voici personnellement mon approche du problème.
Car en effet problème il y a ! Lorsque vous allez configurer cette source de données, vous pourrez faire tester la connexion, et là tout fonctionne, forcément, vos droits sont utilisés.
Mais lors du processing, ce n’est forcément plus vos droits (vous imaginez bien que par défaut SSAS ne connait pas votre login password) c’est donc les droits du compte de service de SSAS qui est utilisé.
Et c’est trop cool depuis 2012 on a des Managed Service Account (MSA) par défaut et c’est bien pratique.
Alors pourquoi cette erreur de droit lorsque vous actualisez les données de votre cube ? Et bien parce que le compte NT Service\MSOLAP$BIDEVMD qui essaie de se connecter à votre source n’a pas les droits en lecture sur celle-ci. Deux solutions s’offrent alors à vous.
- La solution que je vous demande de ne pas utiliser (Parce-que votre mot de passe expire, qu’on peut vous retirer les droits sur la base, parce que vous allez vous faire virer et votre compte sera désactivé de l’AD)
Avec cette solution, vous demandez à SSAS d’accéder à la source de données avec votre login/password Windows.
En effet si vous avez les droits sur la base de données concernée, cela va fonctionner, en tout cas jusqu’à ce que votre mot de passe change, qu’un collègue à vous fasse une modification sur le cube ou que vous ayez quitté la société. - Donnez les droits à NT Service\MSOLAP$BIDEVMD en lecture sur votre base de données (Si celle-ci est sur le même serveur que votre serveur OLAP !)
Sur mon cube:
Sur ma base de données SQL :
J’en profite pour mettre uniquement les droits en lecture sur la base qui m’intéresse. Et hop cela fonctionne ! - C’est bien gentil tout cela mais sur ma prod mon serveur OLAP et SQL ne sont pas sur la même machine.Dans ce cas, vous demandez à un administrateur AD de créer un compte de service AD avec un password qui n’expire pas et que lui seul connait, il suffira de faire la même chose que pour le MSA en ayant préalablement changé le compte de service de SSAS.
En conclusion, privilégiez les comptes MSA ou de service AD, ne collez pas vos logins password partout, sinon … Prison !
4 Comments
Sur une grosse plate-forme mutualisée que j’ai pu implémenter, nous sommes obligés d’utiliser l’Impersonate Account. En effet, ce serait dommage qu’un compte de service « commun » accède à TOUTES les sources de données de TOUS les projets.
On utilise donc des comptes de service dédiés : DOMAIN\SSAS_ProjetA
Par contre, tout est scripté (en PowerShell) pour que ce soit transparent au provisionning et aux déploiements
Aucun problème de ce côté en effet, le mot clé étant « des comptes de service dédiés » et non pas un compte utilisateur 🙂
Instances de DEV et PROD sur le même serveur… ? 😉
Pour l’instant en effet, la machine est énorme et j’ai à terme pas besoin d’être admin du serveur donc cela ne posera pas de problème.