Partager via

Authentification dans un serveur de rapports

  • Article

SQL Server Reporting Services (SSRS) offre plusieurs options configurables pour authentifier les utilisateurs et les applications clientes sur un serveur de rapports. Par défaut, un 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. Dans le cas contraire, vous pouvez 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.

Types d’authentification

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

Nom du type d’authentification Valeur de la couche d'authentification HTTP Utilisé par défaut Description
RSWindowsNegotiate Negotiate Oui Ce type d’authentification tente d’abord d’utiliser Kerberos pour l’authentification intégrée de Windows, mais revient à NTLM (NT LAN Manager) si Active Directory ne peut pas octroyer de ticket pour la requête 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 Ce type d’authentification 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é de votre 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 Ce type d’authentification utilise Kerberos pour l’authentification intégrée de Windows. Configurez Kerberos en utilisant des noms de principal du service (SPN) pour vos comptes de service. L’installation nécessite des privilèges d’administrateur de domaine. 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é sur une autre connexion. Cette connexion doit être établie avec les 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 Utiliser SSL pour chiffrer des données confidentielles.
Personnalisée (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 fait appel à une authentification ASP.NET Forms 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 le message d’erreur « 401 Access Denied » 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. Si vous souhaitez utiliser une technologie d’authentification unique, créez une extension d’authentification personnalisée.

L’environnement d’hébergement du serveur de rapports ne prend pas en charge les filtres ISAPI (interface ISAPI (Internet Server Application Programming Interface)). Si la technologie SSO que vous utilisez est mise en œuvre sous la forme d’un filtre ISAPI, envisagez d’utiliser le support intégré du serveur ISA (Internet Security and Acceleration 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 (RSWindowsBasic, RSWindowsNTLM, RSWindowsKerberos et 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 informatique. Il est possible que la sécurité par défaut ne fonctionne pas pour votre installation ou que vous spécifiiez des paramètres de configuration qui ne sont pas valables pour votre infrastructure de sécurité. 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, mais 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 connexe

D’autres questions ? Posez une question dans le forum Reporting Services.