Dépannage de la protection étendue (Reporting Services)

• Les paramètres RSWindowsExtendedProtectionLevel et RSWindowsExtendedProtectionScenario sont enregistrés dans le fichier rsreportserver.config. Pour plus d'informations sur les paramètres de configuration, consultez Protection étendue de l'authentification avec Reporting Services.

• Utilisez les API WMI. Pour plus d'informations, consultez Méthode SetExtendedProtectionSettings (WMI MSReportServer_ConfigurationSetting).

• Le fichier journal des traces reportserverservice contient des entrées indiquant le paramètre actuel. Les entrées de journal des traces sont écrites au démarrage du service de serveur de rapports. Les entrées ressemblent à l'exemple suivant :

library!DefaultDomain!698!12/29/2009-10:14:49:: i INFO: Initializing RSWindowsExtendedProtectionLevel to 'Off' as specified in Configuration file.

library!DefaultDomain!698!12/29/2009-10:14:49:: i INFO: Initializing RSWindowsExtendedProtectionScenario to 'Proxy' as specified in Configuration file.

Le fichier de journal des traces de service du serveur de rapports contient des entrées similaires aux suivantes :

http!rshost!ec0!12/29/2009-11:01:37:: i INFO: Authentication failed with error state: 46

Recherchez le numéro de l'erreur et des informations supplémentaires dans la liste d'error states à la fin de cette rubrique.

Activez l'option de journalisation détaillée en mettant à jour le fichier de configuration reportingservicesservice.exe.config. Dans la section <RStrace>, définissez :

<add name=”Components” value=”all:4” /> 

• Redémarrez le service.

• Si l'option de journalisation détaillée est activée, l'authentification écrit des lignes similaires aux lignes suivantes, en indiquant si la vérification de la liaison de canal, la liaison de service ou les deux vérifications ont été effectuées :

http!rshost!ec0!12/29/2009-11:01:37:: v VERBOSE : vérification de la liaison de canal en tant que proxy.

http!rshost!7b0!12/29/2009-11:26:23:: v VERBOSE : vérification de la liaison de service.

Pour plus d'informations, consultez Fichier de configuration ReportingServicesService.

Microsoft SQL Client n'a pas été mis à jour pour prendre en charge la protection étendue au moment de la publication de la version finale de SQL Server 2008 R2. SQL Client est utilisé pour se connecter aux sources de données SQL Server et à la base de données du catalogue Reporting Services. Cette limitation du client SQL affecte Reporting Services des façons suivantes :

• La protection étendue ne peut être activée sur le serveur SQL Server qui exécute la base de données du catalogue Reporting Services et le serveur de rapports ne parvient pas à se connecter à la base de données de catalogue et renvoie des erreurs d'authentification.

• Tous les serveurs SQL Server utilisés comme sources de données de rapport Reporting Services ne peuvent bénéficier de la protection étendue ou tentant, par le biais du serveur de rapports, de se connecter à la source de données de rapport échouent et retournent des erreurs d'authentification. Une manière de contourner ce problème consiste à modifier les sources de données Reporting Services pour utiliser des fournisseurs natifs au lieu du client SQL. Par exemple, configurez les sources de données pour le pilote ODBC ; le client SQL natif est alors utilisé, car il prend en charge la protection étendue.

Le comportement dépend du paramètre du RSWindowsExtendedProtectionScenario dans le fichier de configuration rsreportserver.config.

Si RSWindowsExtendedProtectionScenario est configuré sur Direct et que la connexion SSL est absente

Si RSWindowsExtendedProtectionScenario est configuré sur Proxy et que la connexion SSL est absente

Ce scénario s'applique seulement aux systèmes d'exploitation antérieurs à Windows 7 et Windows 2008 R2. Les versions antérieures de Windows n'ont pas été mises sur le marché avec la fonctionnalité de protection étendue. Par conséquent, un ordinateur équipé d'un ancien système d'exploitation risque de ne pas disposer de toutes les mises à jour liées à la protection étendue, notamment la mise à jour de protection étendue concernant .NET Framework.

Lorsque RSWindowsExtendedProtectionLevel est Allow ou Require, une application cliente qui fonctionne sur un système d'exploitation prenant en charge la protection étendue doit fournir la liaison de canal et parfois la liaison de service. Exemple :

• Internet Explorer a été mis à jour dans le cadre de la mise à jour de protection étendue Windows.

• Cependant, .NET Framework n'a pas été corrigé. L'infrastructure .NET Framework est obligatoire pour les clients .NET tels que le Générateur de rapports et Management Studio.

Pour diagnostiquer ce problème, désactivez la protection étendue et vérifiez que l'application cliente .NET peut se connecter. Pour désactiver la protection étendue :

1. Définissez RSWindowsExtendedProtectionLevel sur Off dans le fichier RSReportServer.config.

2. Redémarrez le service Report Server.

La solution consiste à télécharger toutes les mises à jour concernant .NET Framework.

En cas d'authentification par bouclage, le système d'exploitation ignore le mécanisme d'authentification et n'applique pas la liaison de canal.

Par conséquent, avec une connexion HTTP et les paramètres de configuration suivants :

• RSWindowsExtendedProtectionLevel a pour valeur Require

  AND

• RSWindowsExtendedProtectionScenario a pour valeur Proxy

La connexion locale réussit, mais les connexions distantes échouent.

Selon l'URL utilisée pour établir la connexion locale et les réservations d'URL configurées sur le serveur de rapports, il est encore possible que la connexion locale échoue en cas d'échec de liaison de service si le SPN créé à partir de la réservation d'URL ne correspond pas à un SPN figurant dans la liste des SPN valides.

La connexion distante continue d'échouer si vous établissez une connexion HTTP alors qu'aucune passerelle ne réside entre le client et le serveur de rapports configurés pour établir la connexion SSL.

Ce scénario est spécifique à un déploiement avec montée en puissance parallèle de Reporting Services et se produit si le Gestionnaire de rapports et le serveur de rapports figurent sur le même ordinateur et utilisent l'un comme l'autre les en-têtes d'hôtes et l'authentification Windows. Ainsi, si vous essayez d'accéder au Gestionnaire de rapports à l'adresse http://<lenom>/reports, la liste de rapports ou de dossiers attendue n'apparaît pas. À sa place, vous obtenez le message d'erreur de « HTTP 401 (non autorisé) ».

Le <nom> de référence ne désigne pas le nom physique de l'ordinateur et est considéré comme un « en-tête d'hôte». Il s'agit d'un nom de remplacement pour l'ordinateur sur lequel Reporting Services est installé. Les en-têtes d'hôtes sont également utilisés comme source des SPN valides lorsque Reporting Services compile la liste des SPN valides dans le cadre de la protection étendue.

Pour empêcher l'erreur 401 non autorisée, vous devrez insérer le nom NetBIOS et le FQDN (nom de domaine complet) du <nom> dans la liste des noms BackConnectionHostNames stockée dans le Registre Windows. Redémarrez l'ordinateur après avoir apporté la modification dans le Registre.

Pour plus d'informations sur la façon de modifier le Registre, consultez la section « Méthode 2 : Spécification des noms d'hôte » dans l'article  896861 de la Base de connaissances Microsoft, Vous recevez une erreur 401.1 lorsque vous visitez un site Web qui utilise l'authentification intégrée et qui est hébergé sur IIS 5.1 ou une version ultérieure.