Configurez l’authentification Windows sur le serveur de rapports

Par défaut, Reporting Services accepte les requêtes spécifiant l’authentification Negotiate ou NTLM. Si votre déploiement inclut des applications clients et des navigateurs utilisant ces fournisseurs de sécurité, vous pouvez utiliser les valeurs par défaut sans autre configuration. Disons que vous souhaitez utiliser un autre fournisseur de sécurité pour la sécurité intégrée Windows, ou si vous modifiez les valeurs par défaut et souhaitez restaurer les paramètres d'origine. Vous pouvez utiliser les informations de cet article pour spécifier les paramètres d’authentification sur le serveur de rapports.

Pour utiliser la sécurité intégrée Windows, chaque utilisateur ayant besoin d’accéder à un serveur de rapports doit posséder un compte utilisateur local ou de domaine Windows valide. Ou bien, ils doivent être membres d’un compte local ou de groupe de domaine Windows. Vous pouvez inclure des comptes provenant d’autres domaines tant que ces domaines sont dignes de confiance. Les comptes doivent avoir accès à l’ordinateur serveur de rapports, puis être assignés à des rôles afin d’accéder à des opérations spécifiques du serveur de rapports.

Les exigences suivantes doivent également être remplies :

  • Les fichiers RSReportServer.config doivent avoir AuthenticationType défini sur RSWindowsNegotiate, RSWindowsKerberos ou RSWindowsNTLM. Par défaut, le fichier RSReportServer.config inclut le RSWindowsNegotiate paramètre si le compte de service du serveur de rapports est soit NetworkService, soit LocalSystem ; sinon, ce RSWindowsNTLM paramètre est utilisé. Vous pouvez ajouter RSWindowsKerberos si vous avez des applications qui n’utilisent que l’authentification Kerberos.

    Important

    Lorsque vous utilisez RSWindowsNegotiate, une erreur d’authentification Kerberos survient si vous configurez le service Report Server pour qu’il fonctionne sous un compte utilisateur de domaine et que vous n’avez pas enregistré de nom principal de service (SPN) pour le compte. Pour plus d’informations, voir Résoudre les erreurs d’authentification Kerberos lors de la connexion à un serveur de rapports dans ce sujet.

  • ASP.NET doit être configuré pour l’authentification Windows. Par défaut, les fichiers Web.config du service Web Report Server incluent ce <authentication mode="Windows"> paramètre. Si vous le changez en <authentication mode="Forms">, l’authentification Windows pour les Reporting Services échoue.

  • Les fichiers Web.config du service Web Report Server doivent contenir <identity impersonate= "true" />.

  • L’application cliente ou le navigateur doit prendre en charge la sécurité intégrée Windows.

  • Le portail web n’a pas besoin de plus de configuration.

Pour modifier les paramètres d’authentification du serveur de rapport, modifiez les éléments XML et les valeurs dans le fichier RSReportServer.config. Vous pouvez copier-coller les exemples de cet article pour mettre en œuvre des combinaisons spécifiques.

Les paramètres par défaut fonctionnent mieux si tous les ordinateurs client et serveur sont dans le même domaine ou dans un domaine de confiance. De plus, le serveur de rapports est déployé pour l’accès à l’intranet derrière un pare-feu d’entreprise. Les domaines de confiance et les domaines uniques sont indispensables pour transmettre les identifiants Windows. Les identifiants peuvent être transmis plusieurs fois si vous activez le protocole Kerberos version 5 pour vos serveurs. Sinon, les accréditations ne peuvent être délivrées qu’une seule fois avant leur expiration. Pour plus d’informations sur la configuration des identifiants pour plusieurs connexions informatiques, voir Spécifier les informations sur les identifiants et les connexions pour les sources de données du 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 de l’extension par défaut d’authentification Windows pour prendre en charge les serveurs de rapports en mode intégré SharePoint.

Protection étendue pour l’authentification

À compter de SQL Server 2008 R2 (10.50.x), la prise en charge de la protection étendue de 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 Reporting Services doivent être utilisées avec un système d’exploitation qui prend en charge la protection étendue. Vous pouvez déterminer Reporting Services configuration pour une protection étendue grâce à des réglages spécifiques dans le fichier RSReportServer.config. Vous pouvez mettre à jour le fichier soit en le modifiant, soit en utilisant des API WMI. Pour plus d’informations, voir Protection étendue pour l’authentification avec Reporting Services.

Configurez un serveur de rapports pour utiliser la sécurité intégrée de Windows

  1. Ouvrez RSReportServer.config dans un éditeur de texte.

  2. Recherchez <Authentication>.

  3. Copiez l’une des structures XML suivantes qui correspond le mieux à vos besoins. Vous pouvez spécifier RSWindowsNegotiate, RSWindowsNTLM, et RSWindowsKerberos dans n’importe quel ordre. Vous devriez activer la persistance de l’authentification si vous souhaitez authentifier la connexion plutôt que chaque requête individuelle. Sous persistance d’authentification, toutes les requêtes nécessitant une authentification sont autorisées pendant la connexion.

    La première structure XML est la configuration par défaut lorsque le compte du service Report Server est soit NetworkService, soit LocalSystem :

    <Authentication>
    <AuthenticationTypes>
        <RSWindowsNegotiate />
    </AuthenticationTypes>
    <EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>

    La seconde structure XML est la configuration par défaut lorsque le compte de service Report Server n’est ni NetworkService ni LocalSystem :

    <Authentication>
    <AuthenticationTypes>
            <RSWindowsNTLM />
    </AuthenticationTypes>
    <EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>

    La troisième structure XML spécifie tous les paquets 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>

  4. Collez-le par-dessus les entrées existantes pour <Authentication>.

    On ne peut pas utiliser Custom avec les RSWindows types.

  5. Modifiez les réglages selon les besoins pour une protection prolongée. La protection étendue est désactivée par défaut. Si ces entrées ne sont pas présentes, l'ordinateur actuel pourrait ne pas exécuter une version de Reporting Services qui supporte une protection étendue. Pour plus d’informations, voir Protection étendue pour l’authentification avec Reporting Services

    <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>

  6. Enregistrez le fichier.

  7. Si vous avez configuré un déploiement en échelle, répétez ces étapes pour d’autres serveurs de rapports dans le déploiement.

  8. Redémarrez le serveur de rapports pour effacer toutes les sessions actuellement ouvertes.

Résoudre les 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 client au serveur de rapports échoue s’il y a une erreur d’authentification Kerberos. Des erreurs d’authentification Kerberos sont connues pour survenir lorsque :

  • Le service Report Server fonctionne comme un compte utilisateur du domaine Windows et vous n'avez pas enregistré de Nom Principal de Service (SPN) pour le compte.

  • Le serveur de rapports est configuré avec ce RSWindowsNegotiate paramètre.

  • Le navigateur choisit Kerberos plutôt que NTLM dans l’en-tête d’authentification de la requête qu’il envoie au serveur de rapport.

Vous pouvez détecter l’erreur si vous activez la journalisation de Kerberos. Un autre symptôme de l’erreur est qu’on vous demande plusieurs fois des identifiants puis une fenêtre de navigateur vide.

Vous pouvez confirmer que vous rencontrez une erreur d’authentification Kerberos en la retirant <RSWindowsNegotiate> de votre fichier de configuration et en réessayant la connexion.

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

  • Enregistrez un SPN pour le service Report Server sous le compte utilisateur du domaine. Pour plus d'informations, consultez Inscrire un nom de principal du service (SPN) pour un serveur de rapports.

  • Changez le compte service pour qu’il fonctionne sous un compte intégré tel que Network Service. Les comptes intégrés associent le SPN HTTP au SPN de l’hôte, qui est défini lorsque vous connectez un ordinateur à votre réseau. Pour plus d’informations, consultez Configurer un compte de service (Report Server Configuration Manager).

  • Utilise NTLM. Le NTLM fonctionne généralement dans les cas où l’authentification Kerberos échoue. Pour utiliser NTLM, retirez RSWindowsNegotiate du fichier RSReportServer.config et vérifiez que seul RSWindowsNTLM cela est spécifié. Si vous choisissez cette approche, vous pouvez continuer à utiliser un compte utilisateur de domaine pour le service Serveur de Rapports même si vous ne définissez pas de SPN pour celui-ci.

Pour résumer, vous devriez exécuter des commandes similaires à l’exemple suivant. Remplacez les valeurs selon les besoins.

setspn -S HTTP/<SSRS Server FDQN> <SSRS Service Account>
setspn -S HTTP/<host header for Report server web site> <SSRS Service Account>
setspn -S HTTP/<SharePoint Server FDQN> <SharePoint Application Pool Account>
setspn -S HTTP/<host header for SharePoint site>  <SharePoint Application Pool Account>
setspn -S HTTP/Dummy <Claims to Windows Taken Service Account>

Enregistrement d’informations

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

Attribut Contrôle de compte d’utilisateur

Déterminez si le compte de service Reporting Services possède un attribut suffisant défini dans Active Directory. Consultez le fichier journal de trace du service Reporting Services pour trouver la valeur enregistrée pour l’attribut UserAccountControl. La valeur enregistrée est en décimale. Vous devez convertir la valeur décimale en forme hexadécimale, puis trouver cette valeur dans l’article MSDN décrivant l’attribut User-Account-Control.

  • L’entrée du journal de trace du service Reporting Services ressemble à l’exemple suivant :

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

  • Une option pour convertir la valeur décimale en hexadécimale est pour nous le calculateur Microsoft Windows. Windows Calculator prend en charge plusieurs modes qui affichent les options Hex et Dec. Sélectionnez l’option Dec , collez ou tapez la valeur décimale que vous avez trouvée dans le fichier journal, puis sélectionnez l’option « Hex ».

  • Consultez ensuite l’article User-Account-Control Attribute afin de déterminer l’attribut du compte de service.

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

Pour enregistrer les SPN dans le fichier journal de trace du service Reporting Services, vous pouvez activer temporairement la fonction de protection étendue de Reporting Services.

  • Modifiez le fichier de configurationrsreportserver.config en définissant ce qui suit :

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

  • Redémarrez le service Reporting Services.

Si vous ne souhaitez pas continuer à utiliser la Protection Étendue, alors remettez les valeurs de configuration par défaut et redémarrez le compte Reporting Services Service.

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

Pour plus d’informations, voir 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 rapport, il spécifie soit Négociated Kerberos, soit NTLM sur l’en-tête d’authentification. NTLM est utilisé à la place de Kerberos lorsque :

  • La requête est envoyée à un serveur de rapports local.

  • La requête est envoyée à une adresse IP de l’ordinateur serveur de rapport plutôt qu’à un en-tête hôte ou un nom de serveur.

  • Le logiciel du pare-feu bloque les ports utilisés pour l’authentification Kerberos.

  • Le système d’exploitation d’un serveur particulier n’a pas activé Kerberos.

  • Le domaine inclut les anciennes versions des systèmes d'exploitation clients et serveurs Windows qui ne supportent pas la fonction d'authentification Kerberos intégrée aux versions plus récentes du système d'exploitation.

De plus, Internet Explorer peut choisir soit Kerberos négocié, soit NTLM selon la configuration des paramètres d’URL, de LAN et de proxy.

URL du serveur de rapports

Si l’URL inclut un nom de domaine entièrement qualifié, Internet Explorer sélectionne NTLM. Si l’URL indique localhost, Internet Explorer sélectionne NTLM. Si l’URL spécifie le nom réseau de l’ordinateur, Internet Explorer sélectionne Négocier, qui réussit ou échoue, selon l’existence d’un SPN pour le compte de service Report Server.

Paramètres LAN et proxy sur le client

Les paramètres LAN et proxy que vous configurez dans Internet Explorer peuvent déterminer si NTLM est choisi plutôt que Kerberos. Cependant, comme les paramètres LAN et proxy varient selon les organisations, il n’est pas possible de déterminer précisément quels paramètres exacts contribuent aux erreurs d’authentification Kerberos. Par exemple, votre organisation peut appliquer des paramètres de proxy qui transforment les URL intranet en URL de noms de domaine complets résolues via des connexions Internet. Si différents fournisseurs d’authentification sont utilisés pour différents types d’URL, vous pourriez constater que certaines connexions réussissent lorsque vous vous attendez à ce qu’elles échouent.

Vous pourriez rencontrer des erreurs de connexion que vous pensez être dues à des échecs d’authentification. Si oui, vous pouvez essayer différentes combinaisons de réglages LAN et proxy pour isoler le problème. Dans Internet Explorer, les paramètres LAN et proxy se trouvent dans la boîte de dialogue Paramètres du réseau local (LAN), que vous ouvrez en sélectionnant les paramètres LAN dans l’onglet Connexion des options Internet.

Informations supplémentaires pour Kerberos et les serveurs de rapports

Contenu connexe

  • Last updated on