Protection étendue de l'authentification avec Reporting Services
La protection étendue est un ensemble d’améliorations apportées aux dernières versions du système d’exploitation Microsoft Windows. La protection étendue améliore la manière dont les applications protègent les informations d'identification et l'authentification. La fonctionnalité ne fournit pas directement de protection contre des attaques spécifiques telles que le transfert d’informations d’identification, mais offre une infrastructure aux applications telles que Reporting Services afin d’appliquer la protection étendue de l’authentification.
La liaison de service et la liaison de canal figurent parmi les améliorations d'authentification les plus importantes de la protection étendue. La liaison de canal utilise un jeton de liaison de canal (FAO) afin de vérifier que le canal établi entre deux points d'arrêt n'a pas été compromis. La liaison de service utilise les noms de principaux du service (SPN) pour valider la destination prévue de jetons d'authentification. Pour plus d’informations générales sur la protection étendue, consultez Integrated Windows Authentication with Extended Protection(Authentification Windows intégrée avec protection étendue).
SQL Server 2019 (15.x) Reporting Services prend en charge et applique la protection étendue activée dans le système d’exploitation et configurée dans Reporting Services. Par défaut, Reporting Services accepte les demandes qui spécifient l’authentification Negotiate ou NTLM, et peut donc tirer parti de la prise en charge de la protection étendue dans le système d’exploitation et des fonctionnalités de la protection étendue de Reporting Services.
Important
Par défaut, Windows n'active pas la protection étendue. Pour plus d'informations sur l'activation de la protection étendue dans Windows, consultez Protection étendue de l'authentification. Le système d'exploitation et la pile d'authentification du client doivent tous les deux prendre en charge la protection étendue pour que l'authentification aboutisse. Vous devrez peut-être installer plusieurs mises à jour sur les systèmes d'exploitation plus anciens pour bénéficier d'une protection étendue à jour et prête à l'emploi sur l'ordinateur. Pour plus d’informations sur les développements les plus récents de la protection étendue, consultez les informations mises à jour relatives à la protection étendue.
Vue d'ensemble de la protection étendue Reporting Services
SQL Server 2019 (15.x) Reporting Services prend en charge et applique une protection étendue activée dans le système d’exploitation. Si le système d’exploitation ne prend pas en charge la protection étendue ou si la fonctionnalité n’a pas été activée dans le système d’exploitation, la fonctionnalité de protection étendue de Reporting Services ne parviendra pas à effectuer l’authentification. Reporting Services protection étendue nécessite également un certificat SSL. Pour plus d’informations, consultez Configurer des connexions SSL sur un serveur de rapports en mode natif.
Important
Par défaut, Reporting Services n’active pas la protection étendue. La fonctionnalité peut être activée en modifiant le fichier de configuration rsreportserver.config ou en utilisant les API WMI pour mettre le fichier de configuration à jour. SQL Server 2019 (15.x)Reporting Services ne fournit pas d’interface utilisateur permettant de modifier ou d’afficher les paramètres de protection étendue. Pour plus d'informations, consultez la section des paramètres de configuration dans cette rubrique.
Les problèmes courants qui se produisent à cause des modifications des paramètres de protection étendue ou de paramètres mal configurés ne décrivent pas les messages d'erreur ou les boîtes de dialogue habituelles. Les problèmes sur la configuration et la compatibilité de la protection étendue aboutissent à des échecs et des erreurs d’authentification dans les journaux de trace Reporting Services.
Important
Certaines technologies d'accès aux données peuvent ne pas prendre en charge la protection étendue. Une technologie d’accès aux données est utilisée pour se connecter aux sources de données SQL Server et à la base de données du catalogue Reporting Services. L’échec d’une technologie d’accès aux données à prendre en charge la protection étendue a les conséquences suivantes sur Reporting Services :
- La protection étendue ne peut pas être activée sur le serveur SQL Server qui exécute la base de données du catalogue Reporting Services, ou le serveur de rapports ne parvient pas à se connecter à la base de données de catalogue et retourne des erreurs d’authentification.
- Les instances SQL Server utilisées comme sources de données de rapport Reporting Services ne peuvent pas bénéficier de la protection étendue, ou les tentatives du serveur de rapports de se connecter à la source de données de rapport échouent et retournent des erreurs d’authentification.
La documentation pour une technologie d'accès aux données doit disposer d'informations sur la prise en charge de la protection étendue.
Mettre à niveau
La mise à niveau d’un serveur Reporting Services vers SQL Server 2019 (15.x) ajoute des paramètres de configuration avec des valeurs par défaut au
rsreportserver.configfichier. Si les paramètres étaient déjà présents, l’installation SQL Server 2019 (15.x) les conservera dans lersreportserver.configfichier.Lorsque les paramètres de configuration sont ajoutés au fichier de configuration, le comportement par défaut consiste à
rsreportserver.configdésactiver la fonctionnalité de protection étendue Reporting Services et vous devez activer la fonctionnalité comme décrit dans cette rubrique. Pour plus d'informations, consultez la section des paramètres de configuration dans cette rubrique.La valeur par défaut du paramètre
RSWindowsExtendedProtectionLevelestOff.La valeur par défaut du paramètre
RSWindowsExtendedProtectionScenarioestProxy.SQL Server 2019 (15.x) Upgrade Advisor ne vérifie pas que la prise en charge du système d’exploitation ou de l’installation actuelle de Reporting Services est activée.
Champs non couverts par la protection étendue de Reporting Services
Les fonctionnalités et scénarios suivants ne sont pas pris en charge par la fonctionnalité de protection étendue Reporting Services :
Les auteurs des extensions de sécurité personnalisées Reporting Services doivent insérer la prise en charge de la protection étendue à leur extension de sécurité personnalisée.
Les composants tiers ajoutés ou utilisés durant une installation de Reporting Services doivent être mis à jour par le fournisseur tiers en vue de la prise en charge de la protection étendue. Pour plus d'informations, contactez le fournisseur tiers.
Recommandations et scénarios de déploiement
Les scénarios suivants illustrent plusieurs déploiements et topologies ainsi que la configuration recommandée afin de les sécuriser par la protection étendue Reporting Services.
Direct
Ce scénario décrit la connexion directe à un serveur de rapports, par exemple, un environnement d'intranet.
| Scénario | Schéma du scénario | Procédure de sécurisation |
|---|---|---|
| Communication SSL directe. Le serveur de rapports applique la liaison du canal entre le client et le serveur de rapports. |
 1) Application cliente 2) Serveur de rapports |
La liaison de service n'est pas nécessaire, car le canal SSL est utilisé pour la liaison de canal. Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require.Définissez RSWindowsExtendedProtectionScenario sur Direct. |
| Communication HTTP directe. Le serveur de rapports applique la liaison de service entre le client et le serveur de rapports. |  1) Application cliente 2) Serveur de rapports |
Il n'existe aucun canal SSL et, par conséquent, toute application de la liaison de canal est impossible. La liaison de service peut être validée, mais ne constitue pas une ligne de défense parfaite sans la liaison de canal ; la liaison de service à elle seule se contente de bloquer les menaces de base. Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require.Définissez RSWindowsExtendedProtectionScenario sur Any. |
Équilibrage de la charge réseau et proxy
Les applications clientes se connectent à un périphérique ou un logiciel qui effectue une connexion SSL et transmet les informations d'identification au serveur en vue de l'authentification, par exemple, Internet, un réseau extranet ou intranet sécurisé. Le client se connecte à un serveur proxy ou à tous les clients utilisant un proxy.
La situation est la même lorsque vous utilisez un périphérique d'équilibrage de la charge réseau.
| Scénario | Schéma du scénario | Procédure de sécurisation |
|---|---|---|
| Communications HTTP. Le serveur de rapports applique la liaison de service entre le client et le serveur de rapports. |  1) Application cliente 2) Serveur de rapports 3) Proxy |
Il n'existe aucun canal SSL et, par conséquent, toute application de la liaison de canal est impossible. Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require.Définissez RSWindowsExtendedProtectionScenario sur Any.Notez que le serveur de rapports doit être configuré pour connaître le nom du serveur proxy afin de s’assurer que la liaison de service est correctement appliquée. |
| Communications HTTP. Le serveur de rapports applique la liaison de canal entre le client et le proxy et la liaison de service entre le client et le serveur de rapports. |
 1) Application cliente 2) Serveur de rapports 3) Proxy |
Le canal SSL vers le proxy est disponible ; par conséquent, la liaison de canal au proxy peut être appliquée. La liaison de service peut également être appliquée. Le nom de proxy doit être connu du serveur de rapports et l'administrateur du serveur de rapports doit lui créer une réservation d'URL, avec un en-tête d'hôte ou encore configurer le nom de proxy dans l'entrée BackConnectionHostNames du Registre Windows.RSWindowsExtendedProtectionLevel sur Allow ou Require.Définissez RSWindowsExtendedProtectionScenario sur Proxy. |
| Communications HTTPS indirectes avec un proxy sécurisé. Le serveur de rapports applique la liaison de canal entre le client et le proxy et la liaison de service entre le client et le serveur de rapports. |  1) Application cliente 2) Serveur de rapports 3) Proxy |
Le canal SSL vers le proxy est disponible ; par conséquent, la liaison de canal au proxy peut être appliquée. La liaison de service peut également être appliquée. Le nom de proxy doit être connu du serveur de rapports et l'administrateur du serveur de rapports doit lui créer une réservation d'URL, avec un en-tête d'hôte ou encore configurer le nom de proxy dans l'entrée BackConnectionHostNames du Registre Windows.RSWindowsExtendedProtectionLevel sur Allow ou Require.Définissez RSWindowsExtendedProtectionScenario sur Proxy. |
Passerelle
Ce scénario décrit des applications clientes qui se connectent à un dispositif ou à un logiciel qui effectue la connexion SSL et authentifie l'utilisateur. Le périphérique ou le logiciel emprunte l'identité du contexte de l'utilisateur ou d'un utilisateur différent avant que ce dernier n'émette une demande au serveur de rapports.
| Scénario | Schéma du scénario | Procédure de sécurisation |
|---|---|---|
| Communications HTTP indirectes. La passerelle applique la liaison de canal entre le client et la passerelle. Il existe une passerelle menant à la liaison de service du serveur de rapports. |
1) Application cliente 2) Serveur de rapports 3) Périphérique de passerelle |
La liaison de canal entre le client et le serveur de rapports est impossible, car la passerelle emprunte l'identité d'un contexte, créant ainsi un autre NTLM. Il n'y a aucune connexion SSL ente la passerelle et le serveur de rapports ; la liaison de canal ne peut pas être appliquée. La liaison de service peut prendre effet. Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require.Définissez RSWindowsExtendedProtectionScenario sur Any.Le périphérique de passerelle doit être configuré par votre administrateur pour l'application de la liaison de canal. |
| Communications HTTPS indirectes avec une passerelle sécurisée. La passerelle applique la liaison de canal entre le client et la passerelle et le serveur de rapports applique la liaison de canal entre la passerelle et le serveur de rapports. | 1) Application cliente 2) Serveur de rapports 3) Périphérique de passerelle |
La liaison de canal entre le client et le serveur de rapports est impossible, car la passerelle emprunte l'identité d'un contexte, créant ainsi un autre NTLM. SSL de la passerelle vers le serveur de rapports signifie que la liaison de canal peut être appliquée. La liaison de service n'est pas obligatoire. Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require.Définissez RSWindowsExtendedProtectionScenario sur Direct.Le périphérique de passerelle doit être configuré par votre administrateur pour l'application de la liaison de canal. |
Combinaison
Ce scénario décrit des environnements Internet ou Extranet dans lesquels le client se connecte à un proxy. Il fait intervenir un intranet dans lequel un client se connecte au serveur de rapports.
| Scénario | Schéma du scénario | Procédure de sécurisation |
|---|---|---|
| Les accès indirects et directs du client au serveur de rapports fonctionnent sans SSL pour les connexions entre le client et le proxy ou le client et le serveur de rapports. | 1) Application cliente 2) Serveur de rapports 3) Proxy 4) Application cliente |
La liaison de service entre le client et le serveur de rapports est applicable. Le nom de proxy doit être connu du serveur de rapports et l'administrateur du serveur de rapports doit lui créer une réservation d'URL, avec un en-tête d'hôte ou encore configurer le nom de proxy dans l'entrée BackConnectionHostNames du Registre Windows.Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require.Définissez RSWindowsExtendedProtectionScenario sur Any. |
| Accès indirects et directs du client au serveur de rapports sur lequel le client établit une connexion SSL vers le proxy ou le serveur de rapports. |  1) Application cliente 2) Serveur de rapports 3) Proxy 4) Application cliente |
La liaison de canal peut être utilisée. Le nom de proxy doit être connu du serveur de rapports et l'administrateur du serveur de rapports doit lui créer une réservation d'URL, avec un en-tête d'hôte ou encore configurer le nom de proxy dans une entrée BackConnectionHostNames du Registre Windows.Définissez RSWindowsExtendedProtectionLevel sur Allow ou Require.Définissez RSWindowsExtendedProtectionScenario sur Proxy. |
Configuration de la protection étendue de Reporting Services
Le rsreportserver.config fichier contient les valeurs de configuration qui contrôlent le comportement de Reporting Services protection étendue.
Pour plus d’informations sur l’utilisation et la modification du rsreportserver.config fichier, consultez Fichier de configuration RSReportServer. Les paramètres de protection étendue peuvent également être modifiés et examinés à l'aide d'API WMI. Pour plus d’informations, consultez Méthode SetExtendedProtectionSettings (WMI MSReportServer_ConfigurationSetting).
Si la validation des paramètres de configuration échoue, les types d'authentification RSWindowsNTLM, RSWindowsKerberos et RSWindowsNegotiate sont désactivés sur le serveur de rapports.
Paramètres de configuration pour la protection étendue de Reporting Services
Le tableau suivant donne des informations sur les paramètres de configuration qui figurent dans le fichier rsreportserver.config de protection étendue.
| Paramètre | Description |
|---|---|
RSWindowsExtendedProtectionLevel |
Indique le niveau d'application de la protection étendue. Les valeurs correctes sont Off, Allow et Require.La valeur par défaut est Off.La valeur Off indique l'absence de vérification de la liaison de canal ou de service.La valeur Allow prend en charge la protection étendue, mais ne l'impose pas. La valeur Autoriser indique les éléments suivants :La protection étendue est appliquée aux applications clientes qui s'exécutent sur les systèmes d'exploitation prenant en charge la protection étendue. La manière dont la protection s'applique dépend de la définition du RsWindowsExtendedProtectionScenario.L'authentification est autorisée pour les applications fonctionnant sur des systèmes d'exploitation qui ne prennent pas en charge la protection étendue. La valeur Require indique les éléments suivants :La protection étendue est appliquée aux applications clientes qui s'exécutent sur les systèmes d'exploitation prenant en charge la protection étendue. L’authentification n’est pas autorisée pour les applications qui s’exécutent sur des systèmes d’exploitation qui ne prennent pas en charge la protection étendue. |
RsWindowsExtendedProtectionScenario |
Spécifie quelles formes de protection étendue sont validées : Liaison de canal, liaison de service ou les deux. Les valeurs correctes sont Any, Proxy et Direct.La valeur par défaut est Proxy.La valeur Any indique les éléments suivants :-L’authentification Windows NTLM, Kerberos et Negotiate, ainsi qu’une liaison de canal, ne sont pas obligatoires. -La liaison de service est appliquée. La valeur Proxy indique les éléments suivants :-L’authentification Windows NTLM, Kerberos et Negotiate a lieu lorsqu’un jeton de liaison de canal est présent. -La liaison de service est appliquée. La valeur Direct indique les éléments suivants :-L’authentification Windows NTLM, Kerberos et Negotiate a lieu lorsqu’il existe un jeton de liaison de canal et une connexion SSL au service actuel, et lorsque le jeton de liaison de canal pour la connexion SSL correspond à celui du jeton NTLM, Kerberos ou Negotiate. -La liaison de service n’est pas appliquée. Remarque : ce paramètre est ignoré si RsWindowsExtendedProtectionLevel a la valeur OFF. |
Exemples d'entrées dans le fichier de configuration rsreportserver.config :
<Authentication>
<RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionLevel>
</Authentication>
Liaison de service et SPN inclus
La liaison de service utilise les noms principaux du service (SPN) pour valider la destination prévue des jetons d'authentification. Reporting Services utilise les informations de réservation d’URL existantes pour générer la liste des SPN considérés comme valides. L'utilisation des informations de réservation d'URL pour la validation des réservations SPN et URL permet aux administrateurs système de gérer les deux à la fois à partir d'un seul emplacement.
La liste des SPN valides est mise à jour au démarrage du serveur de rapports démarre, à la modification des paramètres de configuration de la protection étendue ou au recyclage du domaine d'application.
La liste valide des SPN est spécifique à chaque application. Par exemple, le Gestionnaire de rapports et le serveur de rapports auront chacun leur propre liste de SPN.
La liste de SPN valides générée pour une application est déterminée par les facteurs suivants :
Réservations d'URL.
Ensemble des SPN extraits du contrôleur de domaine pour le compte de service Reporting Services.
Si une réservation d'URL inclut des caractères génériques (« * » ou « + »), le serveur de rapports ajoutera chaque entrée de la collection d'hôtes.
Sources de collection d'hôtes.
Le tableau suivant répertorie les sources potentielles de la collection d'hôtes.
| Type de la source | Description |
|---|---|
| ComputerNameDnsDomain | Nom du domaine DNS affecté à l'ordinateur local. Si l'ordinateur local est un nœud dans un cluster, le nom de domaine DNS du serveur virtuel de cluster est utilisé. |
| ComputerNameDnsFullyQualified | Nom DNS complet qui identifie de manière unique l'ordinateur local. Ce nom est une combinaison du nom d'hôte DNS et du nom de domaine DNS présentée sous la forme Nom d'hôte.Nom de domaine. Si l'ordinateur local est un nœud dans un cluster, le nom DNS complet du serveur virtuel de cluster est utilisé. |
| ComputerNameDnsHostname | Nom d'hôte DNS de l'ordinateur local. Si l'ordinateur local est un nœud dans un cluster, le nom d'hôte DNS du serveur virtuel de cluster est utilisé. |
| ComputerNameNetBIOS | Nom NetBIOS de l'ordinateur local. Si l'ordinateur local est un nœud dans un cluster, le nom NetBIOS du serveur virtuel de cluster est utilisé. |
| ComputerNamePhysicalDnsDomain | Nom du domaine DNS affecté à l'ordinateur local. Si l'ordinateur local est un nœud dans un cluster, le nom de domaine DNS de l'ordinateur local est utilisé, mais pas le nom du serveur virtuel de cluster. |
| ComputerNamePhysicalDnsFullyQualified | Nom DNS complet qui identifie de manière unique l'ordinateur. Si l'ordinateur local est un nœud dans un cluster, le nom DNS complet de l'ordinateur local est utilisé, mais pas le nom du serveur virtuel de cluster. Le nom DNS complet est une combinaison du nom d'hôte DNS et du nom de domaine DNS présentée sous la forme Nom d'hôte.Nom de domaine. |
| ComputerNamePhysicalDnsHostname | Nom d'hôte DNS de l'ordinateur local. Si l'ordinateur local est un nœud dans un cluster, le nom d'hôte DNS de l'ordinateur local est utilisé, mais pas le nom du serveur virtuel de cluster. |
| ComputerNamePhysicalNetBIOS | Nom NetBIOS de l'ordinateur local. Si l'ordinateur local est un nœud dans un cluster, le nom NetBIOS de l'ordinateur local est utilisé, mais pas le nom du serveur virtuel de cluster. |
Pour plus d’informations, consultez Inscrire un nom de principal de service (SPN) pour un serveur de rapports et À propos des réservations et inscriptions d’URL (SSRS Configuration Manager).
Voir aussi
Se connecter au moteur de base de données à l’aide d’une protectionétendue pour l’authentification Vue d’ensembleDe l’authentification Authentification Windows intégrée à la protection étendueAvis de sécurité Microsoft : Protection étendue pour l’authentification du journal de trace du serviceReport Server RSReportServerSetExtendedProtectionSettings, méthode (WMI MSReportServer_ConfigurationSetting)