Configurer la sécurité Reporting Services

1 ère étape :
Il faut d'abord configurer les comptes d'utilisation et répertoires virtuels de IIS.

Avec Internet, IIS ne peut pas connaître le nom de la machine (ou en tout cas le user connecté)
Car cela signifierait qu'il sait gérer les Macintosh, les machines Unix,…etc.
Il faut donc configurer un accès anonyme qui sera utilisé par ces connexions.

Dans le gestionnaire de l'ordinateur, gestion des utilisateurs locaux :
Modifier le compte anonyme de WINDOWS2003 :
IUSR_NomDeServeur (dans mon cas SERVEUR2005):

Mettre un mot de passe à cet utilisateur si ce n'est déjà fait.

Ensuite, nous passons au gestionnaire des services Internet pour configurer les répertoires virtuels et leur sécurité.

Dans le gestionnaire de services internet, donner les droits en accès anonyme à ce user :

et ceci, pour les deux répertoires virtuels Reports (si vous voulez administrer via le Web) et ReportServer (pour lancer vos états)

faire de même pour Reports

A ce stade, seul IIS connait vos droits d'accès au répertoire(s) virtuel(s) , un accès au répertoire ReportServer devait se solder par un échec du style :

En effet, nous allons maintenant passer à la sécurité intégrée à Reporting Services qui permet de définir les droits d'accès
aux éléments gérés par lui à savoir :
• Les sources de données
• Les répertoires virtuels
• Les rapports

Fonctionnement de la sécurité intégrée de Reporting Services :

Cela fonctionne, comme SQLServer avec deux niveaux :

1) Une sécurité au niveau du serveur qui permet de donner des droits d'administration au serveur d'états (en particulier celui de donner des droits)
2) Une sécurité au niveau des éléments pour protéger les répertoires, les états et les sources de données.

Voyons d'abord la sécurité au niveau du serveur :

Sécurité au niveau du serveur

On donne à une entité de sécurité Windows (Groupe ou User) des rôles , qui , eux-mêmes se dérivent en autorisations sur les droits du système.

Comme on le voit ci-dessus deux rôles sont prédéfinis, mais vous pouvez créer vos propres rôles, ce que je vous conseille.

Sécurité au niveau des éléments

On donne des rôles à des entités de sécurité (groupe/user) sur des éléments (état/répertoire/source de données)

Des rôles prédéfinis sont livrés avec le système (Editeur,...) mais je conseille de définir vos propres rôles pour deux raisons :
1) vous maitrisez mieux leur contenu
2) les versions ultérieures de RS pourraient ajouter des droits indésirables sur ces rôles par défaut

A partir de notre exemple d'accès via Internet, donnons le droit de parcourir (Browser) au niveau de la racine à l'utilisateur anonyme :

ATTENTION :
si, sur le même serveur, Visual Studio veut déployer un état , il utilise la connexion anonyme si elle
existe, d'où problème de droits ......

Conclusion :

Le modèle de sécurité de Reporting Services peut être utilisé simplement, mais aussi devenir une usine à gaz, en particulier à cause du non déterminisme des droits d'accès réels aux élements :
accès de plusieurs manières possibles.

Aussi je vous conseille de l'utiliser simplement :

. donner des accès aux groupes Windows plutôt qu'aux Users
. donner des accès aux répertoires RS plutôt qu'aux rapports
. utiliser l'héritage de droits si possible (hiérarchie de répertoires)
. travailler avec des sources de données partagées


Bon courage pour vos développements RS !