Partager via

Configurer une authentification Windows sur le serveur de rapports

  • Article

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 clients qui utilisent ces fournisseurs de sécurité, vous pouvez utiliser les valeurs par défaut sans configuration supplémentaire. Imaginons que vous souhaitez utiliser un autre fournisseur de sécurité pour la sécurité intégrée de Windows, ou que vous modifiez les valeurs par défaut et souhaitez rétablir 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 de Windows, chaque utilisateur qui a besoin d'un accès à un serveur de rapports doit avoir un compte local ou d'utilisateur de domaine Windows valide. Par ailleurs, ils doivent être membres d'un compte de groupe de domaine ou local Windows. Vous pouvez inclure des comptes d'autres domaines tant que ces domaines sont approuvés. Les comptes doivent avoir accès à l'ordinateur serveur de rapports. Ils doivent ensuite être attribués à des rôles pour pouvoir accéder à des opérations du serveur de rapports spécifiques.

Les besoins suivants doivent également être respectés :

  • Les fichiers RSReportServer.config doivent avoir la valeur AuthenticationType défini sur RSWindowsNegotiate, RSWindowsKerberosou RSWindowsNTLM. Par défaut, le fichier RSReportServer.config inclut le paramètre RSWindowsNegotiate si le compte de service Report Server est NetworkService ou LocalSystem ; sinon, le paramètre RSWindowsNTLM est utilisé. Vous pouvez ajouter RSWindowsKerberos si vous possédez des applications qui utilisent uniquement l'authentification Kerberos.

    Important

    Lorsque vous utilisez RSWindowsNegotiate, une erreur d'authentification Kerberos se produit si vous avez configuré le service de serveur de rapports pour qu'il s'exécute sous un compte d'utilisateur de domaine et que vous n'avez pas enregistré de nom de principal du 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 doit être configuré pour l'authentification Windows. Par défaut, les fichiers Web.config du service web Report Server incluent le paramètre <authentication mode="Windows">. Si vous le remplacez par <authentication mode="Forms">, l'authentification Windows pour Reporting Services échoue.

  • Les fichiers Web.config du service web Report Server doivent avoir le paramètre <identity impersonate= "true" />.

  • L'application cliente ou le navigateur client doivent prendre en charge la sécurité intégrée de Windows.

  • Le portail web ne nécessite pas de configuration supplémentaire.

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 cet article pour implémenter des combinaisons spécifiques.

Les paramètres par défaut sont satisfaisants si tous les ordinateurs clients et serveurs se trouvent dans le même domaine ou dans un domaine approuvé. De plus, le serveur de rapports est déployé pour l'accès intranet derrière un pare-feu d'entreprise. Des domaines approuvés et uniques sont indispensables pour la transmission d'informations d'identification Windows. Les informations d'identification peuvent être transmises plusieurs fois si vous activez le protocole Kerberos version 5 pour vos serveurs. Dans le cas contraire, elles peuvent être passées une seule fois avant d'expirer. Pour plus d'informations sur la configuration des identifiants pour plusieurs connexions d'ordinateurs, consultez Spécifier les identifiants et les informations 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 de 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 la configuration de Reporting Services pour la protection étendue par des paramètres spécifiques dans le fichier RSReportServer.config. Vous pouvez mettre à jour le fichier en le modifiant ou en utilisant les API WMI. Pour plus d'informations, consultez Protection étendue de 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, parmi les structures XML suivantes, celle qui répond le mieux à vos besoins. Vous pouvez spécifier RSWindowsNegotiate, RSWindowsNTLM et RSWindowsKerberos dans n'importe quel ordre. Vous devez activer la permanence de l'authentification si vous voulez authentifier la connexion plutôt que chaque demande individuelle. En cas de persistance de l’authentification, toutes les demandes qui requièrent une authentification seront autorisées pendant 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 quand le compte de service Serveur de rapport n’est ni NetworkService ni LocalSystem :

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

    La troisième structure XML spécifie tous les packages de sécurité qui sont utilisés dans la sécurité intégrée de 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 éviter les erreurs d’authentification Kerberos :

    <AuthenticationTypes>
    <RSWindowsNTLM />
</AuthenticationTypes>

  4. Collez-la sur les entrées existantes de <Authentication>.

    Vous ne pouvez pas utiliser Custom avec les types RSWindows.

  5. Modifiez comme il convient les paramètres de 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 Protection étendue de l'authentification avec Reporting Services

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

  6. Enregistrez le fichier .

  7. 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 du déploiement.

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

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

Sur un serveur de rapports qui est configuré pour l'authentification Negotiate ou Kerberos, une connexion client au serveur de rapports échoue en cas d'erreur d'authentification Kerberos. Les erreurs d'authentification Kerberos sont connues pour se produire dans les cas suivants :

  • Le service Serveu de rapport s’exécute en tant que compte d’utilisateur de domaine Windows et vous n’avez pas inscrit de nom de principal du service (SPN) pour le compte.

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

  • Le navigateur choisit Kerberos via NTLM dans l'en-tête d'authentification de la demande qu'il envoie au serveur de rapports.

Vous pouvez détecter l'erreur si vous avez activé l'enregistrement Kerberos. Le fait que vous soyez invité plusieurs fois à saisir les informations d'identification, puis qu'une fenêtre du navigateur vide s'affiche, constitue un autre symptôme de l'erreur.

Vous pouvez vérifier que vous rencontrez une erreur d'authentification Kerberos en supprimant <RSWindowsNegotiate> de votre fichier de configuration, puis en tentant une nouvelle connexion.

Après avoir confirmé le problème, vous pouvez le résoudre de l'une des manières suivantes :

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

  • Changez de compte de service pour qu'il s'exécute sous un compte intégré tel que le compte de service réseau. Les comptes intégrés mappent le nom de principal du service (SPN) HTTP au nom de principal du service (SPN) hôte, lequel est défini lorsque vous joignez un ordinateur à votre réseau. Pour plus d'informations, consultez Configurer un compte de service (Gestionnaire de configuration du serveur de rapports).

  • Utilisez NTLM. NTLM fonctionnera généralement dans les cas où l’authentification Kerberos échoue. Pour utiliser NTLM, supprimez RSWindowsNegotiate du 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 Serveur de rapport même si vous ne définissez pas de nom de principal du service (SPN) pour ce compte.

Pour résumer, vous devez exécuter des commandes similaires à l’exemple suivant. Remplacez les valeurs comme il convient.

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 de Contôle de compte d’utilisateur

Déterminez si l’attribut défini du compte de service Reporting Services est suffisant dans Active Directory. Examinez le fichier journal de trace des services de création de rapports pour rechercher la valeur enregistrée pour l’attribut Contôle de compte d’utilisateur. La valeur enregistrée se présente au format décimal. Vous devez convertir la valeur décimale au format hexadécimal, puis rechercher cette valeur dans l’article MSDN qui décrit l’attribut Contôle de compte d’utilisateur.

  • L'entrée du journal de suivi 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 de conversion de la valeur décimale au format hexadécimal est pour nous la Calculatrice de Microsoft Windows. La calculatrice Windows prend en charge plusieurs modes qui affichent les options Dec etHex. Sélectionnez l'option Dec, collez ou entrez la valeur décimale trouvée dans le fichier d'historique, puis sélectionnez l'option « hexadécimale ».

  • Reportez-vous ensuite à l’article Attribut Contôle de compte d’utilisateur pour dériver l’attribut pour le compte de service.

Noms de principaux du service configurés dans Active Directory pour le compte de service Reporting Services

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

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

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

  • Redémarrez le service Reporting Services .

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

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

Pour plus d'informations, consultez Protection étendue de l'authentification avec Reporting Services.

Comment le navigateur choisit l’authentification Kerberos par négociation ou l’authentification NTLM par négociation

Lorsque vous utilisez Internet Explorer pour vous connecter au serveur de rapports, il spécifie l'authentification Kerberos par négociation ou l'authentification NTLM par négociation sur l'en-tête d'authentification. NTLM est utilisé à la place de Kerberos dans les cas suivants :

  • La demande est envoyée à un serveur de rapports local.

  • La demande est envoyée à une adresse IP 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.

  • Kerberos n’est pas activé pour le système d’exploitation d’un serveur particulier.

  • 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 aux versions plus récentes du système d’exploitation.

En outre, Internet Explorer peut choisir l'authentification Kerberos par négociation ou l'authentification NTLM par négociation en fonction de la configuration des 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 l'hôte local (localhost), Internet Explorer sélectionne NTLM. Si l’URL spécifie le nom réseau de l’ordinateur, Internet Explorer sélectionne l’authentification Negotiate, qui réussira ou échouera suivant qu’il existe, ou non, un nom de principal du service (SPN) pour le compte de service Report Server.

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

Les paramètres de réseau local et de proxy que vous définissez dans Internet Explorer peuvent déterminer si l'authentification NTLM est préférée à Kerberos. Toutefois, étant donné que les paramètres de réseau local et de proxy varient entre 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 des URL d’intranet en URL de noms de domaine complets qui se résolvent via des connexions Internet. Si différents fournisseurs d'authentification sont utilisés pour différents types d'URL, il se peut que certaines connexions aboutissent alors que vous vous attendiez à ce qu'elles échouent.

Vous pouvez rencontrer des erreurs de connexion que vous pensez être dues à des échecs d'authentification. Si c'est le cas, vous pouvez essayer différentes combinaisons de paramètres LAN et proxy pour isoler le problème. Dans Internet Explorer, les paramètres de réseau local et de proxy se trouvent dans la boîte de dialogue Paramètres du réseau local, que vous ouvrez en cliquant sur Paramètres réseau local sous l’onglet Connexion d’Options Internet.

Informations supplémentaires pour les serveurs Kerberos et les serveurs de rapports

Contenu connexe