Protection étendue de l'authentification avec Reporting Services

Article
09/25/2024

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 façon dont les applications peuvent protéger les informations d'identification et l'authentification. La fonctionnalité ne fournit pas directement de protection contre des attaques spécifiques comme le transfert d'informations d'identification. Cependant, elle offre une infrastructure aux applications comme 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 intégrée de Windows avec protection étendue).

SQL Server Reporting Services (SSRS) 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

SSRS prend en charge et applique la 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 parvient pas à effectuer l'authentification. Reporting Services nécessite également un certificat TLS/SSL. Pour plus d'informations, consultez Configurer des connexions TLS 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. SSRS ne propose pas d’interface utilisateur pour modifier ou visualiser les paramètres de protection étendus. 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 2016 ajoute des paramètres de configuration avec les valeurs par défaut au fichier rsreportserver.config. Si les paramètres étaient déjà présents, l'installation de SQL Server 2016 les conserve dans le fichier rsreportserver.config.
Quand les paramètres de configuration sont ajoutés au fichier de configuration rsreportserver.config, la fonctionnalité de protection étendue de Reporting Services est désactivée par défaut. Vous devez donc activer la fonctionnalité comme indiqué dans cet article. Pour plus d'informations, consultez la section des paramètres de configuration dans cet article.
La valeur par défaut du paramètre RSWindowsExtendedProtectionLevel est Off.
La valeur par défaut du paramètre RSWindowsExtendedProtectionScenario est Proxy.
Le conseiller de mise à niveau ne vérifie pas que le système d'exploitation ou l'installation actuelle de Reporting Services avec prise en charge de la protection étendue est activée.

Champs non couverts par la protection étendue de Reporting Services

La fonctionnalité de protection étendue de Reporting Services ne prend pas en charge les domaines de fonctionnalités et les scénarios suivants :

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.
Le fournisseur tiers doit mettre à jour les composants tiers ajoutés ou utilisés par une installation de Reporting Services pour prendre en charge 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 TLS 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	Définissez `RSWindowsExtendedProtectionLevel` sur `Allow` ou `Require`. Affectez la valeur `RSWindowsExtendedProtectionScenario` à `Direct`. – La liaison de service n'est pas nécessaire, car le canal TLS est utilisé pour la liaison de canal.
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	Définissez `RSWindowsExtendedProtectionLevel` sur `Allow` ou `Require`. Affectez la valeur `RSWindowsExtendedProtectionScenario` à `Any`. -Il n’existe aucun canal TLS 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.

Équilibrage de la charge réseau et proxy

Les applications clientes se connectent à un périphérique ou un logiciel qui effectue une connexion TLS 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	Définissez `RSWindowsExtendedProtectionLevel` sur `Allow` ou `Require`. Affectez la valeur `RSWindowsExtendedProtectionScenario` à `Any`. -Il n’existe aucun canal TLS et, par conséquent, toute application de la liaison de canal est impossible. -Le serveur de rapports doit être configuré de façon à identifier le serveur proxy pour 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	Définir `RSWindowsExtendedProtectionLevel` sur `Allow` ou `Require`. Affectez la valeur `RSWindowsExtendedProtectionScenario` à `Proxy`. -Le canal TLS vers le proxy est disponible ; par conséquent, la liaison de canal au proxy peut être appliquée. -La liaison de service est également 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.
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	Définir `RSWindowsExtendedProtectionLevel` sur `Allow` ou `Require`. Affectez la valeur `RSWindowsExtendedProtectionScenario` à `Proxy`. -Le canal TLS vers le proxy est disponible ; par conséquent, la liaison de canal au proxy peut être appliquée. -La liaison de service est également 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.

Passerelle

Ce scénario décrit des applications clientes qui se connectent à un dispositif ou à un logiciel qui effectue la connexion TLS 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	Définissez `RSWindowsExtendedProtectionLevel` sur `Allow` ou `Require`. Affectez la valeur `RSWindowsExtendedProtectionScenario` à `Any`. – 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 jeton NTLM. – Il n'existe aucune connexion TLS entre la passerelle et le serveur de rapports ; la liaison de canal ne peut donc pas être appliquée. -La liaison de service est applicable. – 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	Définissez `RSWindowsExtendedProtectionLevel` sur `Allow` ou `Require`. Affectez la valeur `RSWindowsExtendedProtectionScenario` à `Direct`. – 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 jeton NTLM. -La connexion TLS entre la passerelle et le serveur de rapports signifie qu’une liaison de canal est possible. – La liaison de service n'est pas obligatoire. – 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 les environnements Extranet ou Internet où le client connecte un proxy en combinaison avec un environnement intranet où 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 TLS 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	Définissez `RSWindowsExtendedProtectionLevel` sur `Allow` ou `Require`. Affectez la valeur `RSWindowsExtendedProtectionScenario` à `Any`. -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.
Accès indirects et directs du client au serveur de rapports sur lequel le client établit une connexion TLS vers le proxy ou le serveur de rapports.	1) Application cliente 2) Serveur de rapports 3) Proxy 4) Application cliente	Définissez `RSWindowsExtendedProtectionLevel` sur `Allow` ou `Require`. Affectez la valeur `RSWindowsExtendedProtectionScenario` à `Proxy`. -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.

Configuration de la protection étendue de Reporting Services

Le fichier rsreportserver.config contient les valeurs de configuration qui contrôlent le comportement de la protection étendue de Reporting Services.

Pour plus d'informations sur l'utilisation et la modification du fichier rsreportserver.config, consultez le fichier de configuration RsReportServer.config. 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.

Setting Description

RSWindowsExtendedProtectionLevel Indique le niveau d'application de la protection étendue. Les valeurs autorisées sont :

Off : valeur par défaut. Indique l’absence de vérification de la liaison de canal ou de service.

Allow prend en charge la protection étendue, mais ne l'exige pas. Spécifie les points 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.

Require spécifie :

– 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 fonctionnant 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 autorisées sont :

Proxy : valeur par défaut. Spécifie les points 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.

Any spécifie :

– L'authentification Windows NTLM, Kerberos et Negotiate, ainsi qu'une liaison de canal, ne sont pas obligatoires.

-La liaison de service est appliquée.

Direct spécifie :

-L’authentification Windows NTLM, Kerberos et Negotiate a lieu lorsqu’il existe un jeton de liaison de canal et une connexion TLS au service actuel, et lorsque le jeton de liaison de canal pour la connexion TLS correspond à celui du jeton NTLM, Kerberos ou Negotiate.

– La liaison de service n'est pas appliquée.

Notes : le paramètre RsWindowsExtendedProtectionScenario est ignoré si RsWindowsExtendedProtectionLevel est défini sur OFF.

Setting	Description
`RSWindowsExtendedProtectionLevel`	Indique le niveau d'application de la protection étendue. Les valeurs autorisées sont : `Off` : valeur par défaut. Indique l’absence de vérification de la liaison de canal ou de service. `Allow` prend en charge la protection étendue, mais ne l'exige pas. Spécifie les points 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. `Require` spécifie : – 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 fonctionnant 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 autorisées sont : `Proxy` : valeur par défaut. Spécifie les points 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. `Any` spécifie : – L'authentification Windows NTLM, Kerberos et Negotiate, ainsi qu'une liaison de canal, ne sont pas obligatoires. -La liaison de service est appliquée. `Direct` spécifie : -L’authentification Windows NTLM, Kerberos et Negotiate a lieu lorsqu’il existe un jeton de liaison de canal et une connexion TLS au service actuel, et lorsque le jeton de liaison de canal pour la connexion TLS correspond à celui du jeton NTLM, Kerberos ou Negotiate. – La liaison de service n'est pas appliquée. Notes : le paramètre `RsWindowsExtendedProtectionScenario` est ignoré si `RsWindowsExtendedProtectionLevel` est défini sur `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. Les informations de réservation d'URL pour la validation des réservations SPN et URL permettent aux administrateurs système de gérer les deux à la fois à partir d'un seul emplacement.

La liste des SPN valides est mise à jour lorsque l'une des actions suivantes se produit :

le serveur de rapports démarre.
Les paramètres de configuration de la protection étendue sont modifiés.
Le domaine d'application est recyclé.

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.

Les facteurs suivants déterminent les SPN valides calculés pour une application :

Réservations d'URL.
Chaque SPN récupéré auprès du contrôleur de domaine pour le compte de service de Reporting Services.
Si une réservation d'URL inclut des caractères génériques (« * » ou « + »), le serveur de rapports ajoute 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, qui utilise 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, qui utilise 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 d'un cluster, cette source est le nom NetBIOS de l'ordinateur local, et non le nom du serveur virtuel du cluster.

Pour plus d'informations, consultez Inscrire un nom de principal du service (SPN) pour un serveur de rapports et À propos des réservations et de l'inscription d'URL (Gestionnaire de configuration du serveur de rapports).

Partager via

Protection étendue de l'authentification avec Reporting Services