Vue d'ensemble de la sécurité pour Reporting Services en mode intégré SharePoint
Lorsque vous configurez un serveur de rapports pour qu'il s'exécute en mode intégré SharePoint, le serveur de rapports utilise le fournisseur d'authentification et les autorisations définis dans l'application Web SharePoint pour contrôler l'accès aux éléments et opérations du serveur de rapports.
L'autorisation d'accès à des éléments et des opérations est accordée par le biais de stratégies de sécurité SharePoint qui mappent un compte d'utilisateur ou de groupe sur un niveau d'autorisation pour un élément. Conceptuellement, cela est identique à la manière dont les attributions de rôle sont utilisées dans un déploiement de serveur de rapports en mode natif, où une attribution de rôle mappe un compte d'utilisateur ou de groupe sur un ensemble de tâches autorisées pour un élément. D'une manière commune à la plupart des modèles d'autorisation utilisant des rôles, la sécurité SharePoint prend en charge l'héritage des autorisations pour réduire la complexité et la charge liées à l'entretien d'un grand nombre de stratégies.
Si vous déployez des types de contenu de serveur de rapports sur un site SharePoint, vous devez connaître les éléments suivants :
Comment les connexions et les demandes sont effectuées entre les deux serveurs. Le fournisseur d'authentification utilisé dans l'application Web SharePoint détermine si vous pouvez utiliser ultérieurement l'option de sécurité intégrée Windows pour accéder aux sources de données externes utilisées par un rapport.
Comment utiliser la sécurité par défaut pour ajouter, gérer et accéder à des éléments et des opérations du serveur de rapports. Pour plus d'informations, consultez Accord d'autorisations sur des éléments de serveur de rapports sur un site SharePoint et Utilisation de la sécurité intégrée dans Windows SharePoint Services pour les éléments de serveur de rapports dans la documentation en ligne de SQL Server.
Comment remplacer la sécurité par défaut en définissant des autorisations sur des rapports ou des opérations spécifiques. Pour plus d'informations, consultez Procédure : définir les autorisations sur les éléments de serveur de rapports sur un site SharePoint (Reporting Services en mode intégré SharePoint) dans la documentation en ligne de SQL Server.
Avant de pouvoir définir des autorisations, vous devez configurer chaque serveur pour l'intégration. Pour plus d'informations, consultez Configuration de Reporting Services pour l'intégration de SharePoint 2010.
Fournisseurs d'authentification dans les technologies SharePoint
Une application Web SharePoint peut utiliser l'authentification Windows ou l'authentification par formulaires. Un serveur de rapports traite les demandes provenant de ces deux types d'authentification. Vous pouvez configurer l'authentification avec les associations suivantes :
Authentification Windows avec Kerberos
Authentification Windows avec NT LAN Manager (NTLM)
Authentification par formulaires
Notes
Reporting Services et les produits et technologies SharePoint prennent en charge l'authentification par formulaires. L'implémentation est différente pour chaque groupe de produits et les différents groupes ne sont pas compatibles. Les extensions d'authentification personnalisée Reporting Services ne sont pas prises en charge pour les serveurs de rapports qui s'exécutent en mode d'intégration SharePoint.
Le tableau suivant résume les avantages et les inconvénients de chaque fournisseur d'authentification :
Avantages |
Inconvénients |
|
---|---|---|
Authentification Windows avec Kerberos |
Fonctionne dans les scénarios de déploiement à serveur unique et multiserveurs. Prend en charge l'utilisation des informations d'identification intégrées de Windows pour les sources de données externes. |
Ne fonctionne pas avec l'authentification NTLM dans les déploiements multiserveurs. Requiert une configuration serveur de configuration et de domaine complexe. |
Authentification Windows avec NTLM ou authentification par formulaires |
Fonctionne avec les scénarios d'authentification Kerberos et non Kerberos. |
Ne prend pas en charge l'utilisation des informations d'identification intégrées de Windows pour les sources de données externes. |
Authentification par revendications SharePoint
Les produits SharePoint 2010 prennent en charge l'authentification par revendications. SQL Server 2008 R2 Reporting Servicesen mode intégré SharePoint fonctionnera avec les applications Web compatibles avec les revendications SharePoint grâce à l'authentification Compte approuvé et aux jetons d'utilisateur SharePoint. Pour plus d'informations sur la prise en charge par Reporting Services de l'authentification de réclamations, consultez Authentification par revendications et Reporting Services. Pour plus d'informations sur l'authentification basée sur les revendications, consultez Vue d'ensemble de l'identité basée sur les revendications (page éventuellement en anglais).
Envoi de demandes à un serveur de rapports
Toutes les demandes concernant un élément ou une opération de serveur de rapports doivent être des demandes authentifiées valides. Le fournisseur d'authentification que vous utilisez détermine la manière dont cette demande est traitée.
Sécurité intégrée Windows avec Kerberos
Si l'application Web SharePoint est configurée pour l'authentification Windows avec Kerberos, la connexion entre l'application Web SharePoint et le serveur de rapports peut utiliser les informations d'identification déléguées ou l'identité empruntée de l'utilisateur Windows en cours. La sécurité intégrée de Windows avec Kerberos et la délégation d'identité vous permet d'éliminer le problème standard de « double saut » qui provoque l'expiration des informations d'identification Windows après une connexion unique. Elle permet également d'étendre l'ensemble des options disponibles lorsque vous configurez des connexions à des sources de données pour des rapports et des modèles. Le diagramme ci-dessous montre les connexions lorsqu'un serveur de rapports est configuré pour l'intégration SharePoint et que l'application Web SharePoint utilise l'authentification Windows avec l'option Kerberos activée et la délégation d'identité.
Connexion 1
Un utilisateur accède à un site SharePoint au moyen du jeton utilisateur créé lorsque l'utilisateur a ouvert une session sur le réseau. Ce jeton contient l'identité et l'appartenance aux groupes de l'utilisateur. L'application Web SharePoint authentifie l'utilisateur. L'utilisateur demande un élément ou une opération du serveur de rapports.Connexion 2
L'application Web SharePoint envoie le jeton et la demande au serveur de rapports. La demande de connexion est envoyée sous l'identité Windows déléguée de l'utilisateur. Le serveur de rapports authentifie l'utilisateur pour savoir s'il est autorisé à accéder au serveur de rapports.Connexion 3
Si l'authentification réussit, le serveur de rapports utilisera le compte d'utilisateur de l'instance Reporting Services pour une connexion aux bases de données de contenu SharePoint afin de vérifier que l'utilisateur est autorisé à accéder à l'élément ou l'opération. Si l'autorisation réussit, le serveur de rapports traite la demande.Connexion 4
Si l'utilisateur visualise un rapport, le serveur de rapports peut déléguer l'identité Windows de l'utilisateur lors du traitement du rapport pour extraire des données des sources de données externes. Cela signifie que lorsque vous définissez les propriétés d'une source de données sur un rapport, vous pouvez sélectionner l'option Sécurité intégrée de Windows pour la connexion à la source de données. Pour plus d'informations, consultez Spécification des informations d'identification et de connexion pour les sources de données de rapport et Procédure : créer et gérer des sources de données partagées (Reporting Services en mode intégré SharePoint) dans la documentation en ligne de SQL Server.
Authentification Windows ou par formulaires et comptes approuvés
Si l'application Web SharePoint est configurée pour l'authentification par formulaires ou l'authentification Windows avec NTLM, la connexion au serveur de rapports est envoyée sur le réseau au moyen d'un compte approuvé prédéfini qui a l'autorisation d'emprunter l'identité d'un utilisateur SharePoint sur le serveur de rapports. Le diagramme ci-dessous montre les connexions lorsque des comptes approuvés et des identités d'utilisateurs SharePoint sont utilisés.
Connexion 1
Un utilisateur ouvre une session sur un site SharePoint. L'application Web SharePoint authentifie l'utilisateur. L'application Web SharePoint convertit l'identité de l'utilisateur en une identité d'utilisateur SharePoint (SPUser). Un nouveau jeton utilisateur est créé pour cet utilisateur dans le contexte de SPUser. Il contient l'identité et l'appartenance aux groupes de l'utilisateur. L'utilisateur demande un élément ou une opération du serveur de rapports.Connexion 2
L'application Web SharePoint se connecte au serveur de rapports à l'aide d'un compte approuvé, qui est l'identité du processus de l'application Web SharePoint. L'application Web SharePoint emprunte l'identité de l'utilisateur SharePoint dans la demande d'un élément ou d'une opération.Le serveur de rapports valide le fait que la demande de connexion provient d'un compte approuvé en la comparant aux informations de compte que le serveur de rapports a extraites à partir des bases de données de configuration SharePoint au démarrage du serveur de rapports. Sur un serveur de rapports, le compte approuvé correspond à un utilisateur Windows doté de l'autorisation d'emprunter l'identité de l'application Web SharePoint. Il est également utilisé pour emprunter l'identité de SPUser, mais il n'est pas autorisé à accéder aux éléments et opérations du serveur de rapports.
Connexion 3
Si l'authentification réussit, le serveur de rapports utilisera le compte d'utilisateur de l'instance Reporting Services pour une connexion aux bases de données de contenu SharePoint afin de vérifier que SPUser est autorisé à accéder à l'élément ou l'opération. Si l'autorisation réussit, le serveur de rapports traite la demande.Connexion 4
Si l'utilisateur visualise un rapport, le serveur de rapports ne peut pas utiliser SPUser pour extraire des données des sources de données externes en raison du problème de « double-saut ». Cela signifie que lorsque vous définissez les propriétés d'une source de données sur un rapport, vous ne pouvez pas sélectionner l'option Sécurité intégrée de Windows pour la connexion à la source de données. Vous pouvez, cependant, configurer le rapport pour qu'il utilise d'autres options de connexion, telles que les informations d'identification stockées ou demandées. Pour plus d'informations, consultez Spécification des informations d'identification et de connexion pour les sources de données de rapport et Procédure : créer et gérer des sources de données partagées (Reporting Services en mode intégré SharePoint) dans la documentation en ligne de SQL Server.
Expiration des comptes et traitement des abonnements
Lorsque vous créez un abonnement à un rapport, le serveur de rapports stocke les informations du compte SPUser afin de pouvoir vérifier que l'utilisateur est habilité à afficher le rapport au moment de la remise. Si le compte SPUser a expiré, l'abonnement échoue et retourne une erreur rsSharePointError. Une propriété nommée TokenTimeout au niveau de la batterie de serveurs détermine la durée de validité du compte SPUser.
Configuration de comptes administratifs et de service pour l'utilisation de comptes d'utilisateur de domaine uniques
Le déploiement d'un produit ou d'une technologie SharePoint utilise tout un ensemble de comptes pour exécuter les services et accéder aux serveurs frontaux et principaux. Si vous spécifiez des comptes de domaine dans votre déploiement, suivez bien les meilleures pratiques recommandées et spécifiez des comptes exclusivement utilisés par l'application Web SharePoint. Ne configurez pas de compte de service à exécuter sous le compte d'utilisateur de domaine d'une personne qui doit accéder au site SharePoint. Si vous accédez à un site SharePoint avec les informations d'identification d'un service, vous risquez de rencontrer des erreurs.
Meilleures pratiques pour la configuration des fournisseurs d'authentification dans un déploiement avec montée en puissance parallèle
Si vous avez un déploiement avec montée en puissance parallèle de Reporting Services et un produit SharePoint, et que vous avez configuré différents fournisseurs d'authentification pour votre environnement, vous risquez de rencontrer des problèmes avec l'authentification des utilisateurs. Par exemple, si votre environnement de création de rapports utilise l'authentification par formulaires pour les connexions Internet et l'authentification Windows pour les connexions intranet, la demande peut être routée vers un ordinateur Web frontal avec un fournisseur d'authentification qui ne correspond pas au type d'authentification de la demande. Reporting Services risque alors de refuser l'accès pour la demande ou celle-ci peut être exécutée sous l'identité du pool d'applications plutôt que sous l'utilisateur ayant fait la demande.
Il est recommandé aux utilisateurs d'utiliser différentes URL pour accéder au contenu à partir d'Internet et d'un intranet. Vous pouvez également configurer le fichier d'hôtes sur les ordinateurs Web frontaux de façon à substituer la recherche DNS (Domain Name System) en mappant l'adresse IP (Internet Protocol) du site qui fait face à Internet à l'URL Internet de sorte que les demandes portant sur l'URL Internet ne soient pas routées vers l'URL intranet par le service DNS.
Accès du serveur de rapports aux bases de données de contenu SharePoint
L'application Web SharePoint et le serveur de rapports se connectent à leurs bases de données respectives pour stocker l'état d'application et d'autres données, mais le serveur de rapports doit également se connecter aux bases de données SharePoint pour stocker et extraire les éléments, les propriétés et les paramètres de configuration. Le diagramme ci-dessous montre les connexions du serveur aux différentes bases de données.
Une application Web SharePoint peut utiliser une base de données locale ou distante pour le stockage interne. Si les bases de données SharePoint se trouvent sur des ordinateurs distants, un compte de domaine doit être utilisé pour la connexion.
Un serveur de rapports peut utiliser une base de données locale ou distante pour le stockage interne. Pour chacun de ces types, la connexion à la base de données peut être établie à l'aide d'un compte de domaine, d'une connexion SQL Server ou d'un compte intégré tel que Network Service ou Local System.
Connexion du serveur de rapports aux bases de données SharePoint
Dans Reporting Services, le service Web et le service Windows requièrent l'accès aux bases de données SharePoint. Les comptes de service de ces deux services s'exécutent en tant qu'utilisateurs approuvés dans une application Web SharePoint et obtiennent automatiquement l'autorisation d'accéder aux bases de données SharePoint.
La connexion est gérée de manière interne ; elle est configurée lorsque vous utilisez l'administration centrale de SharePoint pour pointer une application Web SharePoint sur un serveur de rapports et définir les comptes approuvés. Contrairement à la connexion du serveur de rapports à ses propres bases de données, que vous pouvez définir ou modifier à l'aide de l'outil de configuration de Reporting Services, vous ne pouvez pas configurer ni gérer explicitement la connexion du serveur de rapports aux bases de données SharePoint.
L'exécution d'un serveur de rapports en mode intégré SharePoint introduit des contraintes quant à la configuration des comptes de service dans Reporting Services. Utilisez les instructions ci-dessous pour configurer des comptes de service :
Choisissez des comptes qui possèdent des autorisations d'ouverture de session sur le réseau si les comptes de service Report Server doivent se connecter aux bases de données SharePoint sur un ordinateur distant.
Évitez les comptes intégrés (tels que Système local ou Service réseau) si le serveur de rapports et les bases de données SharePoint se trouvent sur un même ordinateur, alors que l'application Web SharePoint est sur un ordinateur distant. Lorsque les bases de données SharePoint s'exécutent sur un ordinateur distant, l'application Web SharePoint refuse explicitement l'accès aux bases de données des comptes intégrés définis sur cet ordinateur distant. Cela signifie que si le serveur de rapports s'exécute sous un compte intégré, il ne peut pas se connecter aux bases de données SharePoint, car il s'exécute sur le même ordinateur que les bases de données SharePoint.
Pour toutes les autres topologies où les serveurs et les bases de données sont placés sur le même ordinateur ou sur des ordinateurs différents, les comptes de service Reporting Services peuvent être configurés comme comptes de domaine ou comptes intégrés.
Erreurs lors de la connexion aux bases de données SharePoint
Si le serveur de rapports ne peut pas accéder aux bases de données SharePoint et qu'il existe une erreur de configuration (par exemple, si les comptes de service ou les mots de passe ne sont pas valides ou si aucune instance locale du modèle objet Windows SharePoint n'est installée), une erreur rsServerConfigurationError se produit. Pour toutes les autres erreurs de connexion, l'erreur rsSharePointError est retournée avec des informations d'erreur supplémentaires provenant de l'instance SharePoint locale.
Topologies de l'authentification SharePoint et SSRS
Le tableau ci-dessous répertorie les combinaisons prises en charge des méthodes et de l'utilisation de l'authentification SharePoint et SSRS.
SharePoint et SSRS sur un même ordinateur |
Authentification SharePoint |
Mode intégré SSRS |
Authentification SSRS |
Accès d'un compte à SSRS |
Informations d'identification de la source de données |
---|---|---|---|---|---|
Oui |
Kerberos |
Intégré |
Negotiate |
Utilisateur, peut déléguer le contexte de sécurité de l'utilisateur. |
Intégrées, stockées, saisies |
Oui |
Kerberos |
Intégré |
NTLM |
Non pris en charge |
|
Oui |
Kerberos |
Fiable |
Negotiate ou NTLM |
Compte de service de site |
Stockées, saisies, intégrées (+) |
Oui |
NTLM |
Intégré |
Negotiate |
Non pris en charge |
|
Oui |
NTLM |
Intégré |
NTLM |
Utilisateur, NE peut PAS déléguer le contexte de sécurité de l'utilisateur. |
Stockées, saisies, intégrées, locales |
Oui |
NTLM |
Fiable |
Negotiate ou NTLM |
Compte de service de site |
Stockées, saisies, intégrées (+) |
Oui |
Formulaires |
Intégré |
IUSR |
Non pris en charge |
|
Oui |
Formulaires |
Fiable |
Negotiate ou NTLM |
Compte de service de site |
Stockées, saisies, intégrées (+) |
Non |
Kerberos |
Intégré |
Negotiate |
Utilisateur délégable |
Intégrées, stockées, saisies |
Non |
Kerberos |
Intégré |
NTLM |
Non pris en charge |
|
Non |
Kerberos |
Fiable (*) |
Negotiate |
Compte de service de site |
Stockées, saisies, intégrées (+) |
Non |
Kerberos |
Fiable (*) |
Negotiate |
Compte de service de site |
Stockées, saisies, intégrées, uniquement si locales sur SSRS |
Non |
NTLM |
Intégré |
Anonyme |
Non pris en charge |
|
Non |
NTLM |
Fiable (*) |
Negotiate |
Compte de service de site |
Stockées, saisies, intégrées (+) |
Non |
NTLM |
Fiable (*) |
NTLM |
Compte de service de site |
Stockées, saisies, intégrées, uniquement si locales |
Non |
Formulaires |
Intégré |
Anonyme |
Non pris en charge |
|
Non |
Formulaires |
Fiable (*) |
Negotiate |
Compte de service de site |
Stockées, saisies, intégrées (+) |
Non |
Formulaires |
Fiable |
NTLM |
Compte de service de site |
Stockées, saisies, intégrées, uniquement si locales |
(+) Si le compte de service de site SharePoint est un compte local, la source de données doit être locale sur l'ordinateur serveur de rapports. (+) Si le compte de service de site est un compte de domaine, la source de données peut se trouver sur un autre ordinateur.
(*) Le compte de service de site SharePoint doit être un compte de domaine.
Voir aussi
Tâches
Concepts
Historique des modifications
Mise à jour du contenu |
---|
Ajout des tableaux des topologies d'authentification. |