Authentification auprès du 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 réseau et les besoins de votre organisation, vous pouvez personnaliser le protocole d'authentification utilisé pour l'authentification intégrée de Windows. Vous pouvez également utiliser l'authentification de base ou une extension d'authentification personnalisée basée sur des 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.

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. La fonction 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 identifiants ne sont pas délégués ou utilisés pour 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 identifiants. Par ailleurs, la demande d'authentification est éventuellement 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 de principal du service (SPN, Service Principal Name) de vos comptes de service, pour laquelle des privilèges d’administrateur de domaine sont nécessaire. Vous pouvez configurer la délégation d'identité avec Kerberos. Dans ce cas, le jeton de l'utilisateur qui demande un rapport peut également être utilisé lors d'une autre connexion 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 Microsoft Edge ou Internet Explorer, l'authentification Kerberos est prise en charge uniquement par l'intermédiaire de Negotiate. Microsoft Edge ou 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 TLS (Transport Layer Security), précédemment appelé SSL (Secure Sockets Layer) pour chiffrer les informations sur le compte de l'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 Personnaliser 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 comme un filtre ISAPI, envisagez d'utiliser la prise en charge intégrée ISA Server pour RSASecueID ou le protocole RADIUS. Sinon, vous pouvez créer une ISAPI pour ISA Server ou un HTTPModule pour RS. Toutefois, il est préférable d'utiliser ISA Server directement.
Passport Non pris en charge dans SQL Server Reporting Services.
Digest Non pris en charge dans SQL Server Reporting Services.

Configurer les 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 demandes 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 (à savoir, RSWindowsBasic, RSWindowsNTLM, RSWindowsKerberoset RSWindowsNegotiate) s’excluent mutuellement avec Personnalisé.

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 portail web utilisent toujours le même type d’authentification. Vous ne pouvez pas configurer d'autres types d'authentification pour les fonctionnalités du service de serveur de rapports. 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 scale-out 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 de serveur de rapports ou du compte d'exécution sans surveillance si l'authentification est configurée.

Contenu de 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 portail web. Configurer le portail Web pour transférer des cookies d'authentification personnalisée

Contenu connexe

Octroi d’autorisations sur un serveur de rapports en mode natif
Fichier de configuration RsReportServer.config
Créer et gérer des attributions de rôle
Spécifier des informations d'identification et de connexion pour les sources de données de rapports
Implémenter une extension de sécurité
Configurer des connexions TLS sur un serveur de rapports en mode natif
Vue d'ensemble des extensions de sécurité
Authentification dans Reporting Services
Autorisation dans Reporting Services

D’autres questions ? Essayez de poser une question dans le forum Reporting Services