Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

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 (en anglais)

SQL Server 2014 Reporting Services prend en charge et applique la protection étendue qui a été 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 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

SQL Server 2014 Reporting Services prend en charge et applique une protection étendue dans le système d'exploitation. Si le système d'exploitation ne prend pas en charge la protection étendue ou la fonctionnalité dans le système d'exploitation n'a pas été activée, cette fonctionnalité Reporting Services ne sera pas authentifiée. La protection étendue Reporting Services requiert également un certificat SSL. Pour plus d'informations, consultez Configurer des connexions SSL sur un serveur de rapports en mode natif.

Important Important

Reporting Services n'active pas la protection étendue par défaut. 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 2014 Reporting Services ne propose pas d'interface utilisateur pour modifier ou afficher 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 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 dans la prise en charge de la protection étendue a les conséquences suivantes sur Reporting Services :

  • 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.

  • 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 essayant, par le biais 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.

Mise à niveau

  • La mise à niveau d'un serveur Reporting Services vers SQL Server 2014 ajoute des paramètres de configuration avec les valeurs par défaut au fichier rsreportserver.config. Si les paramètres y figurent déjà, l'installation de SQL Server 2014 les laisse dans le fichier rsreportserver.config.

  • Lorsque les paramètres de configuration sont ajoutés au fichier de configuration rsreportserver.config, le comportement par défaut de la fonctionnalité de protection étendue de Reporting Services est désactivé et vous devez activer la fonction comme indiqué dans cette rubrique. Popur plus d'informations, consultez la section Paramètres de configuration de cette rubrique.

  • 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 SQL Server 2014 ne vérifie pas que la protection étendue est activée sur le système d'exploitation ou l'installation actuelle de Reporting Services.

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 lors d'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.

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.

RS_ExtendedProtection_DirectSSL

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.

RS_ExtendedProtection_Direct

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.

RS_ExtendedProtection_Indirect

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.

  • 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.

RS_ExtendedProtection_Indirect_SSL

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.

RS_ExtendedProtection_IndirectSSLandHTTPS

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.

RS_ExtendedProtection_Indirect_SSL

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.

RS_ExtendedProtection_IndirectSSLandHTTPS

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.

  • La connexion SSL entre la passerelle et le serveur de rapports signifie qu'une liaison de canal est possible.

  • 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.

RS_ExtendedProtection_CombinationSSL

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.

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 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 fonctionnant sur des systèmes d'exploitation qui ne prennent pas en charge la protection étendue.

RsWindowsExtendedProtectionScenario

Indique les formes de protection étendue validées : liaison de canal, liaison de service ou les deux à la fois. 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 que la 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 en présence d'un FAO, d'une connexion SSL au service actuel et lorsque le FAO pour la connexion SSL correspond au FAO du jeton NTLM, Kerberos ou Negotiate.

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

Remarque Remarque

Ce paramètre 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>

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 HostName.DomainName. 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 HostName.DomainName.

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.

Lorsque les SPN sont ajoutés, une entrée est ajoutée au journal de suivi semblable au suivant :

rshost!rshost!10a8!01/07/2010-19:29:38:: i INFO: SPN Whitelist Added <ComputerNamePhysicalNetBIOS> - <theservername>.

rshost!rshost!10a8!01/07/2010-19:29:38:: i INFO: SPN Whitelist Added <ComputerNamePhysicalDnsHostname> - <theservername>.

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 de SSRS).

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft