Le problème en 2 mots
En utilisant l’Impersonation d’une Data Source dans SSRS, on reçoit l’erreur Login Failed / Echec d’ouverture de session alors que l’utilisateur et le mot de passe sont corrects
Pourquoi définir les information d’identification ?
Il est possible de définir des Credentials (utilisateur / mot de passe) pour le requetage des sources de données dans un rapport (ou dans une source de données partagée). Ceci indépendamment du type de source de données évidemment.
Personnellement, je conseille d’utiliser la sécurité Windows par défaut afin d’utiliser l’identité de la personne qui consulte le rapport.
D’ailleurs, c’est même obligatoire si vous souhaitez bénéficier de la sécurité d’un cube Analysis Services par exemple.
Il y a un cas où l’utilisation de l’Impersonation de la source de données avec un compte est incontournable, c’est quand on ne peut pas (ou on ne veut pas) configurer la délégation Kerberos dans un environnement multi-serveur.
Le problème du double-hop
Un rappel du problème quand on n’a pas Kerberos : NTLM (la gestion de login par défaut sous Windows) ne permet pas de transférer une identité 2 fois de suite.
Par exemple, votre identité passe de IE au serveur SSRS mais SSRS ne peut pas la transférer au serveur SSAS.
Kerberos permet la délégation sur une chaine multi-serveur mais reste compliqué à mettre en œuvre. C’est pourquoi on choisit quelquefois de stocker le login dans la source de données.
Dans ce cas, SSRS effectue un login local (il a le compte et le mot de passe) et c’est comme-ci la chaine démarrait de zéro.
Alors pourquoi j’ai un Login Failed ?
Dans les logs de Reporting Services (par défaut ici : C:\Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\LogFiles), on voit ceci :
ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.LogonFailedException: Logon attempt for user 'XXXX' failed., Microsoft.ReportingServices.Diagnostics.Utilities.LogonFailedException: Échec de l'ouverture de session. Vérifiez que le nom d'utilisateur et le mot de passe sont corrects. ---> System.ComponentModel.Win32Exception: Échec d’ouverture de session : l’utilisateur ne bénéficie pas du type d’ouverture de session demandé sur cet ordinateur à Microsoft.ReportingServices.Diagnostics.ImpersonationContext.Login(String userName, String userPwd, String domain)
Comme je viens de l’expliquer, SSRS se logue au nom du compte fournit pour appeler la source de données avec cette identité.
Pour cela, il faut donc un privilège local sur ce compte. Ce privilège, c’est une ouverture de session de type tâche (type 4 = BATCH LOGON).
Pour attribuer les droits, vous pouvez passer par une GPO ou par une stratégie locale. Dans le second cas, un coup de secpol.msc sur le serveur SSRS et vous n’avez qu’à ajouter les comptes ayant le droits de figurer dans les sources de données.
Attention, une GPO peut annuler vos stratégies locales donc synchronisez vous avec vos administrateurs système.
Pour finir ?
Le cas où j’ai rencontré cette problématique est chez un client qui respecte le principe de moindre privilège (Least-Privilege – LA règle principale d’une bonne sécurité). Par conséquent, ils n’autorisent pas aux “simples” utilisateurs cette permission.
Sur la ferme SharePoint sur laquelle se trouve SSRS, nous n’avons pas (encore) mis Kerberos et donc les utilisateurs doivent saisir leur compte dans la chaine de connexion, ce qui n’est pas prévu par les règles de sécurité de l’entreprise 
.
On a donc donné le privilège aux concepteurs de rapports sur le serveur SSRS. Affaire classée.
Tags: Kerberos, Reporting Services, SSRS
