Impersonation de sources de données dans SSRS–Login Failed

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

image

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.

image

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 Sourire.

On a donc donné le privilège aux concepteurs de rapports sur le serveur SSRS. Affaire classée.

2 réflexions sur “Impersonation de sources de données dans SSRS–Login Failed

  1. Bonjour;
    Je débute avec ssrs,je trvaille avec SSDT 2015 et SSMS 2014 , j’ai créé des rapports que j’ai hébergé sur le serveur local, mais je n’est aucune idée sur comment créer des utilisateurs (distants) pour leurs attribuer les différents roles qui existent, j’accède avec l’utilisateur windows actuel de mon PC, mais je veux par exemple qu’un autre utilisateur se connecte à mon serveur …
    Votre aide s’il vous plais.

  2. Difficile de faire une explication complète à travers un commentaire de blog. Toutefois les éléments à considérer sont :
    -Etre dans un domaine Active Directory
    -Utiliser le Report Manager pour configurer les droits sur les dossiers/rapports

    Rassurez-moi, quand vous parlez de « serveur local », vous ne parlez pas de votre PC ?

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s