Introduction
Ce document décrit comment résoudre le problème lorsque l'authentification échoue par l'appareil de sécurité Web Cisco (WSA) lorsque le client utilise NEGOEXTS.
Informations générales
L'appareil de sécurité Web Cisco (WSA) peut authentifier les utilisateurs afin d'appliquer des stratégies basées sur l'utilisateur ou le groupe. L'une des méthodes disponibles est Kerberos. Lors de l'utilisation de Kerberos comme méthode d'authentification dans une identité, le WSA répond à la requête HTTP d'un client avec une réponse HTTP 401 (transparente) ou 407 (explicite) qui contient l'en-tête WWW-Authenticate : Negotiate. À ce stade, le client envoie une nouvelle requête HTTP avec l'en-tête Authorization : Negotiate, qui contient les protocoles Generic Security Service Application Program Interface (GSS-API) et Simple Protected Negotation (SPNEGO). Sous SPNEGO, l'utilisateur présente les mechTypes qu'il prend en charge. Voici les mechTypes pris en charge par WSA :
- KRB5 : méthode d'authentification Kerberos utilisée si Kerberos est pris en charge et configuré correctement sur le client et si un ticket Kerberos valide est présent pour le service auquel l'utilisateur accède.
- NTLMSSP : méthode du fournisseur de prise en charge de la sécurité Microsoft NTLM utilisée si aucun ticket Kerberos valide n'est disponible, mais que la méthode Negotiate auth est prise en charge
Problème : l'authentification échoue via WSA lorsque le client utilise NEGOEXTS
Dans les versions plus récentes de Microsoft Windows, une nouvelle méthode d'authentification est prise en charge, appelée NegoExts, qui est une extension du protocole d'authentification Negotiate. Ce mechType est considéré comme plus sécurisé que NTLMSSP et est préféré par le client lorsque les seules méthodes prises en charge sont NEGOEXTS et NTLMSSP. Pour plus d'informations, cliquez sur ce lien :
Présentation des extensions du package d'authentification Negotiate
Ce scénario se produit généralement lorsque la méthode Negotiate auth est sélectionnée et qu'il n'y a pas de mechType KRB5 (probablement parce qu'il manque un ticket Kerberos valide pour le service WSA). Si le client sélectionne NEGOEXTS (peut être considéré comme NEGOEX dans wireshark), alors le WSA est désactivé pour traiter la transaction d'authentification et l'authentification échoue pour le client. Dans ce cas, les journaux suivants apparaissent dans les journaux d'authentification :
14 Nov 2016 16:06:20 (GMT -0500) Warning: PROX_AUTH : 123858 : [DOMAIN]Failed to parse NTLMSSP packet, could not extract NTLMSSP command14 Nov 2016 16:06:20 (GMT -0500) Info: PROX_AUTH : 123858 : [DOMAIN][000] 4E 45 47 4F 45 58 54 53 00 00 00 00 00 00 00 00 NEGOEXTS ........
Lorsque l'authentification échoue, cela se produit :
Si les privilèges d'invité sont activés - le client est classé comme non authentifié et redirigé vers le site Web
Si les privilèges d'invité sont désactivés, le client reçoit un autre 401 ou 407 (selon la méthode proxy) avec les autres méthodes d'authentification présentées dans l'en-tête de réponse (Negotiate n'est pas présenté à nouveau). Une invite d'authentification est susceptible de se produire si l'authentification NTLMSSP et/ou Basic est configurée. S'il n'existe aucune autre méthode d'authentification (Identity est configuré uniquement pour Kerberos), l'authentification échoue tout simplement.
Solution
La solution à ce problème est de supprimer l'authentification Kerberos de l'identité ou de corriger le client afin qu'il obtienne un ticket Kerberos valide pour le service WSA.
Commentaires