Partager via

Authentification avec le serveur de rapports

  • Article

SQL Server Reporting Services (SSRS) offre plusieurs options configurables pour authentifier les utilisateurs et les applications clientes sur le serveur de rapports. Par défaut, le serveur de rapports utilise l'authentification intégrée Windows et suppose des relations approuvées dans lesquelles le client et les ressources réseau sont dans le même domaine ou dans un domaine approuvé. Selon la topologie de votre réseau et les besoins de votre organisation, vous pouvez personnaliser le protocole d’authentification utilisé pour l’authentification intégrée de Windows, utiliser l’authentification de base ou une extension personnalisée d’authentification basée sur les formulaires que vous fournissez. Chacun de ces types d'authentification peut être activé ou désactivé individuellement. Vous pouvez activer plusieurs types d’authentification si vous voulez que le serveur de rapports accepte des demandes de plusieurs types.

Notes

Dans les versions précédentes de Reporting Services, toute la prise en charge de l’authentification était fournie par IIS. À compter de la version SQL Server 2008, IIS n’est plus utilisé. Reporting Services gère toutes les demandes d’authentification en interne.

Tous les utilisateurs ou applications qui demandent l'accès au contenu et aux opérations du serveur de rapports doivent être authentifiés avant que l'accès ne soit autorisé.

Types d'authentification

Tous les utilisateurs ou applications qui demandent l'accès au contenu et aux opérations du serveur de rapports doivent être authentifiés à l'aide du type d'authentification configuré sur le serveur de rapports avant que l'accès ne soit autorisé. Le tableau suivant décrit les types d’authentification pris en charge par Reporting Services.

Nom de type d'authentification Valeur de la couche d'authentification HTTP Utilisé par défaut Description
RSWindowsNegotiate Negotiate Oui Tente d'utiliser Kerberos en premier pour l'authentification intégrée de Windows, mais revient à NTLM si Active Directory ne peut pas accorder de ticket pour la demande du client au serveur de rapports. Negotiate revient à NTLM uniquement si le ticket n'est pas disponible. Si les premières tentatives entraînent une erreur plutôt qu'un ticket manquant, le serveur de rapports n'effectue pas de deuxième tentative.
RSWindowsNTLM NTLM Oui Utilise NTLM pour l'authentification intégrée de Windows.

Les informations d'identification ne seront pas déléguées ou empruntées sur d'autres demandes. Les demandes suivantes suivent une nouvelle séquence de stimulation/réponse. Selon les paramètres de sécurité du réseau, le système peut demander à un utilisateur des informations d'identification ou la demande d'authentification est gérée de façon transparente.
RSWindowsKerberos Kerberos Non Utilise Kerberos pour l'authentification intégrée de Windows. La configuration de Kerberos passe par celle des noms des principes du service (SPN) pour vos comptes de service, lequel requiert des privilèges d'administrateur de domaine. Si vous configurez la délégation d'identité à l'aide de Kerberos, le jeton de l'utilisateur qui demande un rapport peut également être utilisé sur une connexion supplémentaire aux sources de données externes qui fournissent des données aux rapports.

Avant de spécifier RSWindowsKerberos, vérifiez que le type de navigateur que vous utilisez prend bien en charge ce dernier. Si vous utilisez Internet Explorer, l'authentification Kerberos est prise en charge uniquement par l'intermédiaire de Negotiate. Internet Explorer ne formule pas de demande d'authentification qui spécifie Kerberos directement.
RSWindowsBasic De base Non L'authentification de base est définie dans le protocole HTTP et peut être utilisée uniquement pour authentifier des requêtes HTTP au serveur de rapports.

Les informations d'identification sont passées dans la requête HTTP à l'aide de l'encodage en base 64. Si vous avez recours à l'authentification de base, utilisez le protocole SSL (Secure Sockets Layer) pour chiffrer les informations du compte d'utilisateur avant de les envoyer sur le réseau. Le protocole SSL fournit un canal chiffré pour l'envoi d'une demande de connexion du client au serveur de rapports via une connexion HTTP TCP/IP. Pour plus d’informations, consultez Utilisation de SSL pour chiffrer les données confidentielles sur le site web Microsoft TechNet.
Custom (Anonyme) Non L'authentification anonyme dirige le serveur de rapports pour ignorer l'en-tête d'authentification dans une requête HTTP. Le serveur de rapports accepte toutes les demandes, mais appelle une authentification par formulaire ASP.NET personnalisée que vous fournissez pour authentifier l’utilisateur.

Spécifiez Custom uniquement si vous déployez un module d'authentification personnalisé qui gère toutes les demandes d'authentification sur le serveur de rapports. Vous ne pouvez pas utiliser le type d'authentification Personnalisé avec l'extension d'authentification Windows par défaut.

Méthodes d'authentification non prises en charge

Les méthodes et demandes d'authentification suivantes ne sont pas prises en charge.

Méthode d'authentification Explication
Anonyme Le serveur de rapports n'accepte pas de demandes non authentifiées d'un utilisateur anonyme, à l'exception des déploiements qui incluent une extension d'authentification personnalisée.

Le Générateur de rapports accepte des demandes non authentifiées si vous activez l'accès au Générateur de rapports sur un serveur de rapports configuré pour l'authentification de base.

Pour tous les autres cas, les demandes anonymes sont rejetées avec une erreur État HTTP 401 Accès Refusé avant que la demande ne parvienne à ASP.NET. Les clients qui reçoivent cette erreur doivent reformuler la demande avec un type d'authentification valide.
Technologies d'authentification uniques (SSO) Il n’existe pas de prise en charge native pour les technologies d’authentification unique dans Reporting Services. Pour utiliser cette technologie, vous devez créer une extension d'authentification personnalisée.

L'environnement d'hébergement du serveur de rapports ne prend pas en charge les filtres ISAPI. Si la technologie SSO que vous utilisez est implémentée sous la forme d'un filtre ISAPI, vous pouvez envisager d'utiliser la prise en charge intégrée ISA Server pour RSASecueID ou le protocole RADIUS. Sinon, vous pouvez créer un ISA Server ISAPI ou un HTTPModule pour RS, mais il est recommandé d'utiliser ISA Server directement.
Passport Non pris en charge dans SQL Server 2014.
Digest Non pris en charge dans SQL Server 2014.

Configuration des paramètres d'authentification

Les paramètres d'authentification sont configurés pour la sécurité par défaut lorsque l'URL du serveur de rapports est réservée. Si vous modifiez ces paramètres de manière incorrecte, le serveur de rapports retourne des erreurs HTTP 401 Accès Refusé pour les requêtes HTTP qui ne peuvent pas être authentifiées. Le choix d'un type d'authentification nécessite de savoir comment l'authentification Windows est prise en charge sur votre réseau. Vous devez spécifier au moins un type d'authentification. Plusieurs types d'authentification peuvent être spécifiés pour RSWindows. Les types d’authentification RSWindows (c’est-à-dire , RSWindowsBasicRSWindowsNTLM, RSWindowsKerberoset RSWindowsNegotiate) s’excluent mutuellement avec Custom.

Important

Reporting Services ne valide pas les paramètres que vous spécifiez pour déterminer s'ils sont corrects pour votre environnement d'informatique. La sécurité par défaut peut ne pas fonctionner pour votre installation, ou et vous pouvez spécifier des paramètres de configuration qui ne sont pas valides pour votre infrastructure de sécurité. Pour cette raison, il est important de tester prudemment votre déploiement de serveur de rapports dans un environnement de test contrôlé avant de le déployer à plus grande échelle dans votre organisation.

Le service Web Report Server et le Gestionnaire de rapports font toujours appel au même type d'authentification. Vous ne pouvez pas configurer d'autres types d'authentification pour les fonctionnalités du service Report Server. Si vous disposez d'un déploiement par montée en puissance parallèle, veillez à dupliquer toutes vos modifications sur tous les nœuds dans le déploiement. Vous ne pouvez pas configurer d'autres nœuds dans le même déploiement pour utiliser des types d'authentification différents.

Le traitement en arrière-plan n'accepte pas de demandes d'utilisateurs finaux, cependant il authentifie toutes les demandes à des fins d'exécution sans assistance. Il utilise toujours l'authentification Windows et authentifie des demandes à l'aide du service Report Server ou du compte d'exécution sans assistance s'il est configuré.

Dans cette section

Descriptions de tâche Liens
Configurez le type d'authentification intégrée de Windows. Configurer une authentification Windows sur le serveur de rapports
Configurez le type d'authentification de base. Configurer une authentification de base sur le serveur de rapports
Configurez soit l'authentification par formulaire, soit un type d'authentification personnalisé. Configurer l'authentification personnalisée ou par formulaire sur le serveur de rapports
Pour gérer le scénario d'authentification personnalisé, activez le gestionnaire de rapports. Configurer le Gestionnaire de rapports pour passer des cookies d’authentification personnalisée

Voir aussi

Octroi d'autorisations sur un serveur de rapports en mode natif
Fichier de configuration RSReportServer
(create-and-manage-role-assignments.md)
Spécifier des informations d'identification et de connexion pour les sources de données de rapports
Implémentation d'une extension de sécurité
Configurer des connexions SSL sur un serveur de rapports en mode natif
Configurer l'accès au Générateur de rapports
Présentation des extensions de sécurité
Authentification dans Reporting Services
Autorisation dans Reporting Services