Partager via

Authentification Windows intégrée avec protection étendue

Des améliorations ont été apportées qui affectent la gestion de l’authentification Windows intégrée par les HttpWebRequest, HttpListener, SmtpClient, SslStream, NegotiateStream et les classes associées dans les System.Net et les espaces de noms associés. La prise en charge de la protection étendue a été ajoutée pour renforcer la sécurité.

Ces modifications peuvent affecter les applications qui utilisent ces classes pour effectuer des requêtes web et recevoir des réponses où l’authentification Windows intégrée est utilisée. Cette modification peut également avoir un impact sur les serveurs web et les applications clientes configurées pour utiliser l’authentification Windows intégrée.

Ces modifications peuvent également affecter les applications qui utilisent ces classes pour effectuer d’autres types de requêtes et recevoir des réponses où l’authentification Windows intégrée est utilisée.

Les modifications apportées à la prise en charge de la protection étendue sont disponibles uniquement pour les applications sur Windows 7 et Windows Server 2008 R2. Les fonctionnalités de protection étendue ne sont pas disponibles sur les versions antérieures de Windows.

Aperçu

La conception de l’authentification Windows intégrée permet à certaines réponses de défi d’informations d’identification d’être universelles, ce qui signifie qu’elles peuvent être réutilisées ou transférées. Les réponses aux défis doivent être construites au minimum avec des informations spécifiques cibles et de préférence avec des informations spécifiques au canal. Les services peuvent ensuite fournir une protection étendue pour s’assurer que les réponses aux demandes d’informations d’identification contiennent des informations spécifiques au service telles qu’un nom de principal de service (SPN). Avec ces informations dans les échanges d’informations d’identification, les services sont en mesure de mieux se protéger contre l’utilisation malveillante des réponses de défi d’informations d’identification qui auraient pu être utilisées de manière incorrecte.

La conception étendue de la protection est une amélioration des protocoles d’authentification conçus pour atténuer les attaques de relais d’authentification. Elle repose sur le concept d’informations de liaison de service et de canal.

Les objectifs globaux sont les suivants :

  1. Si le client est mis à jour pour prendre en charge la protection étendue, les applications doivent fournir des informations de liaison de canal et de liaison de service à tous les protocoles d’authentification pris en charge. Les informations de liaison de canal ne peuvent être fournies que lorsqu’il existe un canal (TLS) à lier. Les informations de liaison de service doivent toujours être fournies.

  2. Les serveurs mis à jour correctement configurés peuvent vérifier les informations de liaison de canal et de service lorsqu’ils sont présents dans le jeton d’authentification du client et rejeter la tentative d’authentification si les liaisons de canal ne correspondent pas. Selon le scénario de déploiement, les serveurs peuvent vérifier la liaison de canal, la liaison de service ou les deux.

  3. Les serveurs mis à jour ont la possibilité d’accepter ou de rejeter des demandes clientes de bas niveau qui ne contiennent pas les informations de liaison de canal en fonction de la stratégie.

Les informations utilisées par la protection étendue se composent d’une ou des deux parties suivantes :

  1. Un jeton de liaison de canal.

  2. Des informations de liaison de service sous la forme d’un nom de principal du service (SPN).

Les informations de liaison de service sont une indication de l’intention d’un client de s’authentifier auprès d’un point de terminaison de service particulier. Il est communiqué du client au serveur avec les propriétés suivantes :

  • La valeur SPN doit être disponible pour le serveur effectuant l’authentification du client sous forme de texte clair.

  • La valeur du SPN est publique.

  • Le SPN doit être protégé par chiffrement en transit afin qu’une attaque man-in-the-middle ne puisse pas insérer, supprimer ou modifier sa valeur.

Un CBT est une propriété du canal sécurisé externe (tel que TLS) utilisé pour lier ce canal à une conversation sur un canal interne authentifié par le client. Le jeton de liaison de canal doit avoir les propriétés suivantes (qui sont également définies dans la norme RFC 5056 publiée par l’IETF) :

  • Lorsqu’un canal externe existe, la valeur du cbT doit être une propriété identifiant le canal externe ou le point de terminaison du serveur, arrivée indépendamment à la fois par les côtés client et serveur d’une conversation.

  • La valeur du jeton de liaison de canal envoyé par le client ne doit pas être une valeur falsifiable par un attaquant.

  • Aucune garantie n’est faite quant à la confidentialité de la valeur CBT. Cela ne signifie toutefois pas que la valeur de la liaison de service ainsi que les informations de liaison de canal peuvent toujours être examinées par n’importe quel autre serveur qui effectue l’authentification, car le protocole qui transporte le CBT peut le chiffrer.

  • Le CBT doit être protégé par le chiffrement en transit afin qu’un attaquant ne puisse pas insérer, supprimer ou modifier sa valeur.

La liaison de canal est effectuée par le client qui transfère le SPN et le CBT au serveur de manière infalsifiable. Le serveur valide les informations de liaison de canal conformément à sa stratégie et rejette les tentatives d’authentification pour lesquelles il ne pense pas être la cible prévue. De cette façon, les deux canaux deviennent liés par chiffrement ensemble.

Pour préserver la compatibilité avec les clients et les applications existants, un serveur peut être configuré pour autoriser les tentatives d’authentification par les clients qui ne prennent pas encore en charge la protection étendue. Il s’agit d’une configuration « partiellement renforcée », contrairement à une configuration « entièrement renforcée ».

Plusieurs composants dans les espaces de noms System.Net et System.Net.Security effectuent l'authentification Windows intégrée pour le compte d'une application appelante. Cette section décrit les modifications apportées aux composants System.Net pour ajouter une protection étendue à leur utilisation de l’authentification Windows intégrée.

La protection étendue est actuellement prise en charge sur Windows 7. Un mécanisme est fourni afin qu’une application puisse déterminer si le système d’exploitation prend en charge la protection étendue.

Modifications apportées à la prise en charge de la protection étendue

Le processus d’authentification utilisé avec l’authentification Windows intégrée, selon le protocole d’authentification utilisé, inclut souvent un défi émis par l’ordinateur de destination et renvoyé à l’ordinateur client. La protection étendue ajoute de nouvelles fonctionnalités à ce processus d’authentification

L’espace de noms System.Security.Authentication.ExtendedProtection fournit la prise en charge de l’authentification avec protection étendue pour les applications. La ChannelBinding classe de cet espace de noms représente une liaison de canal. La ExtendedProtectionPolicy classe de cet espace de noms représente la stratégie de protection étendue utilisée par le serveur pour valider les connexions clientes entrantes. D’autres membres de classe sont utilisés avec la protection étendue.

Pour les applications serveur, ces classes sont les suivantes :

Un ExtendedProtectionPolicy qui a les éléments suivants :

  • Propriété OSSupportsExtendedProtection qui indique si le système d’exploitation prend en charge l’authentification Windows intégrée avec une protection étendue.

  • Valeur PolicyEnforcement qui indique quand la stratégie de protection étendue doit être appliquée.

  • Valeur ProtectionScenario qui indique le scénario de déploiement. Cela influence la façon dont la protection étendue est vérifiée.

  • Un élément facultatif ServiceNameCollection qui contient la liste SPN personnalisée utilisée pour correspondre au SPN fourni par le client en tant que cible prévue de l'authentification.

  • Un élément facultatif ChannelBinding qui contient une liaison de canal personnalisée à utiliser pour la validation. Ce scénario n’est pas un cas courant

L’espace System.Security.Authentication.ExtendedProtection.Configuration de noms prend en charge la configuration de l’authentification à l’aide de la protection étendue pour les applications.

Plusieurs modifications de fonctionnalité ont été apportées pour prendre en charge la protection étendue dans l’espace de noms existant System.Net . Ces modifications sont les suivantes :

Une modification de fonctionnalité a été apportée pour prendre en charge la protection étendue pour les applications clientes SMTP dans l’espace de noms existant System.Net.Mail :

  • Propriété TargetName de la SmtpClient classe qui représente le SPN à utiliser pour l’authentification lors de l’utilisation de la protection étendue pour les applications clientes SMTP.

Plusieurs modifications de fonctionnalité ont été apportées pour prendre en charge la protection étendue dans l’espace de noms existant System.Net.Security . Ces modifications sont les suivantes :

Une SmtpNetworkElement propriété a été ajoutée pour prendre en charge la configuration de la protection étendue pour les clients SMTP dans l’espace System.Net.Security de noms.

Protection étendue pour les applications clientes

La prise en charge de la protection étendue pour la plupart des applications clientes se produit automatiquement. Les classes HttpWebRequest et SmtpClient prennent en charge la protection étendue chaque fois que la version sous-jacente de Windows prend en charge cette protection. Une HttpWebRequest instance envoie un SPN construit à partir du Uri. Par défaut, une SmtpClient instance envoie un SPN construit à partir du nom d’hôte du serveur de messagerie SMTP.

Pour l’authentification personnalisée, les applications clientes peuvent utiliser les méthodes HttpWebRequest.EndGetRequestStream(IAsyncResult, TransportContext) ou HttpWebRequest.GetRequestStream(TransportContext) de la classe HttpWebRequest qui permettent de récupérer le TransportContext et le CBT à l’aide de la méthode GetChannelBinding.

Le SPN à utiliser pour l’authentification Windows intégrée envoyée par une HttpWebRequest instance à un service donné peut être substitué en définissant la CustomTargetNameDictionary propriété.

La TargetName propriété peut être utilisée pour définir un SPN personnalisé à utiliser pour l’authentification Windows intégrée pour la connexion SMTP.

Protection étendue pour les applications serveur

HttpListener fournit automatiquement des mécanismes pour valider les liaisons de service lors de l’authentification HTTP.

Le scénario le plus sécurisé consiste à activer la protection étendue pour HTTPS:// les préfixes. Dans ce cas, définissez HttpListener.ExtendedProtectionPolicy sur un ExtendedProtectionPolicy avec PolicyEnforcement défini sur WhenSupported ou Always, et ProtectionScenario défini sur TransportSelected. Une valeur de WhenSupported met HttpListener en mode partiellement renforcé, tandis que Always correspond au mode entièrement renforcé.

Dans cette configuration lorsqu’une requête est envoyée au serveur via un canal sécurisé externe, le canal externe est interrogé pour une liaison de canal. Cette liaison de canal est transmise aux appels SSPI d’authentification, qui valident que la liaison de canal dans le blob d’authentification corresponde. Il existe trois résultats possibles :

  1. Le système d’exploitation sous-jacent du serveur ne prend pas en charge la protection étendue. La demande ne sera pas exposée à l’application et une réponse non autorisée (401) sera retournée au client. Un message est consigné dans la HttpListener source de trace en spécifiant la raison de l’échec.

  2. L’appel SSPI échoue indiquant que le client a spécifié une liaison de canal qui ne correspondait pas à la valeur attendue récupérée à partir du canal externe ou que le client n’a pas pu fournir une liaison de canal lorsque la stratégie de protection étendue sur le serveur a été configurée pour Always. Dans les deux cas, la demande ne sera pas exposée à l’application et une réponse non autorisée (401) sera retournée au client. Un message est consigné dans la HttpListener source de trace en spécifiant la raison de l’échec.

  3. Le client spécifie la liaison de canal correcte ou est autorisé à se connecter sans spécifier de liaison de canal, car la stratégie de protection étendue sur le serveur est configurée avec WhenSupported la requête est retournée à l’application pour traitement. Aucune vérification du nom de service n’est effectuée automatiquement. Une application peut choisir d’effectuer sa propre validation de nom de service à l’aide de la ServiceName propriété, mais dans ces circonstances, elle est redondante.

Si une application effectue ses propres appels SSPI pour authentifier en fonction des blobs échangés dans le corps d'une requête HTTP et qu'elle souhaite prendre en charge la liaison de canal, elle doit récupérer la liaison de canal attendue à partir du canal sécurisé externe en utilisant HttpListener pour la transmettre à la fonction native Win32 AcceptSecurityContext. Pour cela, utilisez la propriété TransportContext et appelez la méthode GetChannelBinding qui permet de récupérer le jeton de liaison de canal. Seules les liaisons de point de terminaison sont prises en charge. Si une autre liaison que la liaison Endpoint est spécifiée, une NotSupportedException est levée. Si le système d’exploitation sous-jacent prend en charge la liaison de canal, la méthode GetChannelBinding retournera un ChannelBindingSafeHandle enveloppant un pointeur vers une liaison de canal convenable à passer à la fonction AcceptSecurityContext en tant que membre pvBuffer d’une structure SecBuffer passée dans le paramètre pInput. La Size propriété contient la longueur, en octets, de la liaison de canal. Si le système d’exploitation sous-jacent ne prend pas en charge les liaisons de canal, la fonction retourne null.

Un autre scénario possible consiste à activer la protection étendue pour HTTP:// les préfixes lorsque les proxys ne sont pas utilisés. Dans ce cas, définissez HttpListener.ExtendedProtectionPolicy sur un ExtendedProtectionPolicy avec PolicyEnforcement défini sur WhenSupported ou Always, et ProtectionScenario défini sur TransportSelected. Une valeur de WhenSupported met HttpListener en mode partiellement renforcé, tandis que Always correspond au mode entièrement renforcé.

Une liste par défaut des noms de service autorisés est créée en fonction des préfixes qui ont été inscrits auprès du HttpListener. Cette liste par défaut peut être examinée par le biais de la DefaultServiceNames propriété. Si cette liste n’est pas complète, une application peut spécifier une collection de noms de service personnalisée dans le constructeur pour la ExtendedProtectionPolicy classe qui sera utilisée au lieu de la liste de noms de service par défaut.

Dans cette configuration, lorsqu'une requête est envoyée au serveur sans canal sécurisé externe, l'authentification se déroule normalement sans vérification de l'association des canaux. Si l’authentification réussit, le contexte est interrogé pour le nom du service que le client a fourni et validé par rapport à la liste des noms de service acceptables. Il existe quatre résultats possibles :

  1. Le système d’exploitation sous-jacent du serveur ne prend pas en charge la protection étendue. La demande ne sera pas exposée à l’application et une réponse non autorisée (401) sera retournée au client. Un message est consigné dans la HttpListener source de trace en spécifiant la raison de l’échec.

  2. Le système d’exploitation sous-jacent du client ne prend pas en charge la protection étendue. Dans la WhenSupported configuration, la tentative d’authentification réussit et la demande est retournée à l’application. Dans la Always configuration, la tentative d’authentification échoue. La demande ne sera pas exposée à l’application et une réponse non autorisée (401) sera retournée au client. Un message est consigné dans la HttpListener source de trace en spécifiant la raison de l’échec.

  3. Le système d’exploitation sous-jacent du client prend en charge la protection étendue, mais l’application n’a pas spécifié de liaison de service. La demande ne sera pas exposée à l’application et une réponse non autorisée (401) sera retournée au client. Un message est consigné dans la HttpListener source de trace en spécifiant la raison de l’échec.

  4. Le client a spécifié une liaison de service. La liaison de service est comparée à la liste des liaisons de service autorisées. Si elle correspond, la requête est retournée à l’application. Sinon, la demande ne sera pas exposée à l’application et une réponse non autorisée (401) sera automatiquement retournée au client. Un message est consigné dans la HttpListener source de trace en spécifiant la raison de l’échec.

Si cette approche simple utilisant une liste autorisée de noms de service acceptables est insuffisante, une application peut fournir sa propre validation de nom de service en interrogeant la ServiceName propriété. Dans les cas 1 et 2 ci-dessus, la propriété retourne null. Dans le cas 3, elle retourne une chaîne vide. Dans le cas 4, le nom du service spécifié par le client est retourné.

Ces fonctionnalités de protection étendue peuvent également être utilisées par les applications serveur pour l’authentification avec d’autres types de requêtes et lorsque des proxys approuvés sont utilisés.

Voir aussi

  • Last updated on