Configurer l’authentification Windows sur le serveur de rapports

Par défaut, Reporting Services accepte les demandes qui spécifient l’authentification Negotiate ou NTLM. Si votre déploiement inclut des applications clientes et des navigateurs qui utilisent ces fournisseurs de sécurité, vous pouvez utiliser les valeurs par défaut sans configuration supplémentaire. Si vous souhaitez utiliser un autre fournisseur de sécurité pour la sécurité intégrée Windows (par exemple, si vous souhaitez utiliser Kerberos directement) ou si vous avez modifié les valeurs par défaut et que vous souhaitez restaurer les paramètres d’origine, vous pouvez utiliser les informations de cette rubrique pour spécifier les paramètres d’authentification sur le serveur de rapports.

Pour utiliser la sécurité intégrée de Windows, chaque utilisateur qui a besoin d’accéder à un serveur de rapports doit avoir un compte d’utilisateur windows local ou de domaine valide ou être membre d’un compte de groupe de domaine ou local Windows. Vous pouvez inclure des comptes à partir d’autres domaines tant que ces domaines sont approuvés. Les comptes doivent avoir accès à l’ordinateur du serveur de rapports et doivent être affectés par la suite aux rôles afin d’accéder à des opérations spécifiques du serveur de rapports.

Les exigences supplémentaires suivantes doivent également être remplies :

Les fichiers RSeportServer.config doivent être configurés sur AuthenticationType, RSWindowsNegotiate, RSWindowsKerberos, ou RSWindowsNTLM. Par défaut, le fichier RSReportServer.config inclut le RSWindowsNegotiate paramètre si le compte de service Report Server est NetworkService ou LocalSystem ; sinon, le RSWindowsNTLM paramètre est utilisé. Vous pouvez ajouter RSWindowsKerberos si vous avez des applications qui utilisent uniquement l’authentification Kerberos.

Important

L’utilisation RSWindowsNegotiate entraîne une erreur d’authentification Kerberos si vous avez configuré le service Report Server pour qu’il s’exécute sous un compte d’utilisateur de domaine et que vous n’avez pas inscrit de nom de principal de service (SPN) pour le compte. Pour plus d’informations, consultez Résolution des erreurs d’authentification Kerberos lors de la connexion à un serveur de rapports dans cette rubrique.
ASP.NET devez être configuré pour l’authentification Windows. Par défaut, les fichiers Web.config pour le service web Report Server et le Gestionnaire de rapports incluent le <paramètre mode d’authentification=« Windows ».> Si vous la remplacez en <mode d’authentification ="Forms »>, l’authentification Windows pour Reporting Services échoue.
Les fichiers Web.config pour le service web Report Server et le Gestionnaire de rapports doivent avoir <l’identité impersonate= « true » />.
L’application cliente ou le navigateur doit prendre en charge la sécurité intégrée de Windows.

Pour modifier les paramètres d’authentification du serveur de rapports, modifiez les éléments et valeurs XML dans le fichier RSReportServer.config. Vous pouvez copier et coller les exemples de cette rubrique pour implémenter des combinaisons spécifiques.

Les paramètres par défaut fonctionnent mieux si tous les ordinateurs clients et serveurs se trouvent dans le même domaine ou dans un domaine approuvé et que le serveur de rapports est déployé pour l’accès intranet derrière un pare-feu d’entreprise. Les domaines approuvés et uniques sont requis pour transmettre des informations d’identification Windows. Les informations d’identification peuvent être passées plusieurs fois si vous activez le protocole Kerberos version 5 pour vos serveurs. Sinon, les informations d’identification ne peuvent être passées qu’une seule fois avant leur expiration. Pour plus d’informations sur la configuration des informations d’identification pour plusieurs connexions ordinateurs, consultez Spécifier les informations d’identification et de connexion pour les sources de données de rapport.

Les instructions suivantes sont destinées à un serveur de rapports en mode natif. Si le serveur de rapports est déployé en mode intégré SharePoint, vous devez utiliser les paramètres d’authentification par défaut qui spécifient la sécurité intégrée De Windows. Le serveur de rapports utilise des fonctionnalités internes dans l’extension d’authentification Windows par défaut pour prendre en charge les serveurs de rapports en mode intégré SharePoint.

Protection étendue pour l’authentification

À compter de SQL Server 2008 R2, la prise en charge de la protection étendue pour l’authentification est disponible. La fonctionnalité de SQL Server prend en charge l’utilisation de la liaison de canal et la liaison de service pour améliorer la protection de l’authentification. Les fonctionnalités de Reporting Services doivent être utilisées avec un système d’exploitation prenant en charge la protection étendue. La configuration de Reporting Services pour la protection étendue est déterminée par les paramètres du fichier RSReportServer.config. Le fichier peut être mis à jour en modifiant le fichier ou en utilisant des API WMI. Pour plus d’informations, consultez Protection étendue pour l’authentification avec Reporting Services.

Pour configurer un serveur de rapports afin d’utiliser la sécurité intégrée windows

Ouvrez RSReportServer.config dans un éditeur de texte.
Rechercher <Authentication>.
Copiez l’une des structures XML suivantes qui répondent le mieux à vos besoins. Vous pouvez spécifier RSWindowsNegotiate, RSWindowsNTLMet RSWindowsKerberos dans n’importe quel ordre. Vous devez activer la persistance de l’authentification si vous souhaitez authentifier la connexion plutôt que chaque demande individuelle. Sous persistance de l’authentification, toutes les demandes qui nécessitent une authentification seront autorisées pendant la durée de la connexion.

La première structure XML est la configuration par défaut lorsque le compte de service Report Server est NetworkService ou LocalSystem :
```
<Authentication>  
      <AuthenticationTypes>  
             <RSWindowsNegotiate />  
      </AuthenticationTypes>  
      <EnableAuthPersistence>true</EnableAuthPersistence>  
</Authentication>  
```
La deuxième structure XML est la configuration par défaut lorsque le compte de service Report Server n’est pas NetworkService ou LocalSystem :
```
<Authentication>  
      <AuthenticationTypes>  
             <RSWindowsNTLM />  
      </AuthenticationTypes>  
      <EnableAuthPersistence>true</EnableAuthPersistence>  
```
</Authentification>

La troisième structure XML spécifie tous les packages de sécurité utilisés dans la sécurité intégrée Windows :
```
      <AuthenticationTypes>  
             <RSWindowsNegotiate />  
             <RSWindowsKerberos />  
             <RSWindowsNTLM />  
      </AuthenticationTypes>  
```
La quatrième structure XML spécifie NTLM uniquement pour les déploiements qui ne prennent pas en charge Kerberos ou pour contourner les erreurs d’authentification Kerberos :
```
      <AuthenticationTypes>  
             <RSWindowsNTLM />  
      </AuthenticationTypes>  
```
Collez-le sur les entrées existantes pour <Authentication>.

Notez que vous ne pouvez pas utiliser Custom avec les RSWindows types.
Modifiez les paramètres appropriés pour la protection étendue. La protection étendue est désactivée par défaut. Si ces entrées ne sont pas présentes, l’ordinateur actuel peut ne pas exécuter une version de Reporting Services qui prend en charge la protection étendue. Pour plus d'informations, consultez Extended Protection for Authentication with Reporting Services
```
      <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>  
      <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>  
```
Enregistrez le fichier.
Si vous avez configuré un déploiement avec montée en puissance parallèle, répétez ces étapes pour d’autres serveurs de rapports dans le déploiement.
Redémarrez le serveur de rapports pour effacer toutes les sessions qui sont actuellement ouvertes.

Résolution des erreurs d’authentification Kerberos lors de la connexion à un serveur de rapports

Sur un serveur de rapports configuré pour l’authentification Negotiate ou Kerberos, une connexion cliente au serveur de rapports échoue en cas d’erreur d’authentification Kerberos. Les erreurs d’authentification Kerberos sont connues quand :

Le service Report Server s’exécute en tant que compte d’utilisateur de domaine Windows et vous n’avez pas inscrit de nom de principal de service (SPN) pour le compte.
Le serveur de rapports est configuré avec le RSWindowsNegotiate paramètre.
Le navigateur choisit Kerberos sur NTLM dans l’en-tête d’authentification dans la demande qu’il envoie au serveur de rapports.

Vous pouvez détecter l’erreur si vous avez activé la journalisation Kerberos. Un autre symptôme de l’erreur est que vous êtes invité à entrer des informations d’identification plusieurs fois, puis à voir une fenêtre de navigateur vide.

Vous pouvez confirmer que vous rencontrez une erreur d’authentification Kerberos en supprimant <RSWindowsNegotiate /> à partir de votre fichier de configuration et en réacheminant la connexion.

Après avoir confirmé le problème, vous pouvez le résoudre de la manière suivante :

Inscrivez un SPN pour le service Report Server sous le compte d’utilisateur de domaine. Pour plus d’informations, consultez Inscrire un nom de principal de service (SPN) pour un serveur de rapports.
Modifiez le compte de service pour qu’il s’exécute sous un compte intégré tel que le service réseau. Les comptes intégrés mappent le SPN HTTP au SPN hôte, qui est défini lorsque vous joignez un ordinateur à votre réseau. Pour plus d’informations, consultez Configurer un compte de service (Gestionnaire de configuration SSRS).
Utilisez NTLM. NTLM fonctionne généralement dans les cas où l’authentification Kerberos échoue. Pour utiliser NTLM, supprimez RSWindowsNegotiate le fichier RSReportServer.config et vérifiez que seul RSWindowsNTLM est spécifié. Si vous choisissez cette approche, vous pouvez continuer à utiliser un compte d’utilisateur de domaine pour le service Report Server, même si vous ne définissez pas de SPN pour celui-ci.

Informations de journalisation

Il existe plusieurs sources d’informations de journalisation qui peuvent aider à résoudre les problèmes liés à Kerberos.

Attribut utilisateur-Account-Control

Déterminez si le compte de service Reporting Services a l’attribut suffisant défini dans Active Directory. Passez en revue le fichier journal de trace du service Reporting Services pour rechercher la valeur enregistrée pour l’attribut UserAccountControl. La valeur journalisée est sous forme décimale. Vous devez convertir la valeur décimale en forme hexadécimale, puis rechercher cette valeur dans la rubrique MSDN décrivant l’attribut User-Account-Control.

L’entrée du journal de suivi du service Reporting Services ressemble à ce qui suit :

appdomainmanager!DefaultDomain!8f8!01/14/2010-14:42:28:: i INFO: The UserAccountControl value for the service account is 590336

Une option permettant de convertir la valeur décimale en forme hexadécimale est de nous la calculatrice Microsoft Windows. La calculatrice Windows prend en charge plusieurs modes qui affichent l’option « Déc » et les options « Hex ». Sélectionnez l’option « Déc », collez ou tapez la valeur décimale que vous avez trouvée dans le fichier journal, puis sélectionnez l’option « Hex ».
Reportez-vous ensuite à la rubrique User-Account-Control Attribute pour dériver l’attribut du compte de service.

SPNs configurés dans Active Directory pour le compte de service de Reporting Services.

Pour journaliser les SPN dans le fichier journal de suivi du service Reporting Services, vous pouvez activer temporairement la fonctionnalité de protection étendue de Reporting Services.

Modifiez le fichier rsreportserver.config de configuration en définissant les éléments suivants :

<RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>   
<RSWindowsExtendedProtectionScenario>Any</RSWindowsExtendedProtectionScenario>

Redémarrez le service Reporting Services .

Si vous ne souhaitez pas continuer à utiliser la protection étendue, définissez les valeurs de configuration sur les valeurs par défaut et redémarrez le compte de service Reporting Services.

<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>  
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>

Pour plus d’informations, consultez La protection étendue pour l’authentification avec Reporting Services

Comment le navigateur choisit Kerberos négocié ou NTLM négocié

Lorsque vous utilisez Internet Explorer pour vous connecter au serveur de rapports, il spécifie Kerberos négocié ou NTLM sur l’en-tête d’authentification. NTLM est utilisé au lieu de Kerberos lorsque :

La demande est envoyée à un serveur de rapports local.
La requête est envoyée à une adresse IP de l’ordinateur du serveur de rapports plutôt qu’à un en-tête d’hôte ou un nom de serveur.
Le logiciel de pare-feu bloque les ports utilisés pour l’authentification Kerberos.
Le système d’exploitation d’un serveur particulier n’a pas Kerberos activé.
Le domaine inclut des versions antérieures des systèmes d’exploitation client et serveur Windows qui ne prennent pas en charge la fonctionnalité d’authentification Kerberos intégrée à des versions plus récentes du système d’exploitation.

En outre, Internet Explorer peut choisir Kerberos ou NTLM négocié en fonction de la façon dont vous avez configuré les paramètres d’URL, de réseau local et de proxy.

URL du serveur de rapports

Si l’URL inclut un nom de domaine complet, Internet Explorer sélectionne NTLM. Si l’URL spécifie localhost, Internet Explorer sélectionne NTLM. Si l’URL spécifie le nom réseau de l’ordinateur, Internet Explorer sélectionne Negotiate, qui réussit ou échoue selon qu’un SPN existe pour le compte de service Report Server.

Paramètres réseau local et proxy sur le client

Les paramètres réseau local et proxy que vous définissez dans Internet Explorer peuvent déterminer si NTLM est choisi sur Kerberos. Toutefois, étant donné que les paramètres réseau local et proxy varient entre les organisations, il n’est pas possible de déterminer précisément les paramètres exacts qui contribuent aux erreurs d’authentification Kerberos. Par exemple, votre organisation peut appliquer des paramètres de proxy qui transforment les URL de l'intranet en URLs de noms de domaines pleinement qualifiés qui sont accessibles via des connexions Internet. Si différents fournisseurs d’authentification sont utilisés pour différents types d’URL, vous pouvez constater que certaines connexions réussissent quand vous les attendez à échouer.

Si vous rencontrez des erreurs de connexion que vous pensez en raison d’échecs d’authentification, vous pouvez essayer différentes combinaisons de paramètres LAN et proxy pour isoler le problème. Dans Internet Explorer, les paramètres réseau local et proxy se trouvent dans la boîte de dialogue Paramètres réseau local (LAN), que vous ouvrez en cliquant sur les paramètres RÉSEAU local sous l’onglet Connexion des options Internet.

Ressources externes

Pour plus d’informations sur Kerberos et les serveurs de rapports, consultez Déploiement d’une solution Business Intelligence à l’aide de SharePoint, de Reporting Services et du serveur de surveillance PerformancePoint avec Kerberos.

Voir aussi

Authentification avec le serveur de rapports
Octroi d'autorisations sur un serveur de rapports en mode natif
Fichier de configuration RSReportServer
Configurer l’authentification de base sur le serveur de rapports
Configurer l'authentification personnalisée ou par formulaire sur le serveur de rapports
Protection étendue de l'authentification avec Reporting Services

Last updated on 2017-06-13

Partager via