La autenticación falla a través de WSA cuando el cliente utiliza NEGOEXTS

Introducción

Este documento describe cómo superar el problema cuando la autenticación falla a través del dispositivo de seguridad Cisco Web Security Appliance (WSA) cuando el cliente utiliza NEGOEXTS.

Antecedentes

El dispositivo de seguridad Cisco Web Security Appliance (WSA) puede autenticar a los usuarios para aplicar políticas basadas en usuarios o grupos. Uno de los métodos disponibles es Kerberos. Cuando se utiliza Kerberos como método de autenticación en una identidad, WSA responde a la solicitud HTTP de un cliente con una respuesta HTTP 401 (transparente) o 407 (explícita) que contiene el encabezado WWW-Authenticate: Negotiate. En este momento, el cliente envía una nueva solicitud HTTP con el encabezado Authorization: Negotiate, que contiene los protocolos Generic Security Service Application Program Interface (GSS-API) y Simple Protected Negotation (SPNEGO). Bajo SPNEGO, el usuario presenta los mechTypes que soporta. Estos son los mechTypes que admite WSA:

• KRB5: método de autenticación Kerberos que se utiliza si Kerberos es compatible y está configurado correctamente en el cliente y si hay un vale Kerberos válido para el servicio al que se está accediendo
• NTLMSSP: método del proveedor de soporte de seguridad NTLM de Microsoft que se utiliza si no hay vales Kerberos válidos disponibles pero se admite el método Negotiate auth

Problema: la autenticación falla a través de WSA cuando el cliente utiliza NEGOEXTS

En las versiones más recientes de Microsoft Windows, se admite un nuevo método de autenticación denominado NegoExts, que es una extensión del protocolo de autenticación Negotiate. Este mechType se considera más seguro que NTLMSSP, y es preferido por el cliente cuando los únicos métodos soportados son NEGOEXTS y NTLMSSP. Puede encontrar más información en este enlace:

Introducción de Extensiones al Paquete de Negociación de Autenticación

Este escenario suele ocurrir cuando se selecciona el método Negotiate auth y no hay mechType KRB5 (probablemente debido a que falta un vale Kerberos válido para el servicio WSA). Si el cliente selecciona NEGOEXTS (puede verse como NEGOEX en wireshark), el WSA no puede procesar la transacción de autenticación y la autenticación falla para el cliente. Cuando esto ocurre, estos registros se ven en los registros de autenticación:

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

Cuando falla la autenticación, ocurre lo siguiente:

Si los privilegios de invitado están habilitados, el cliente se clasifica como no autenticado y se redirige al sitio web

Si los privilegios de invitado están inhabilitados - al cliente se le presenta otro 401 o 407 (dependiendo del método de proxy) con los métodos de autenticación restantes presentados en el encabezado de respuesta (Negotiate no se presenta nuevamente). Es probable que se produzca un mensaje de autenticación si se configura NTLMSSP y/o la autenticación básica. Si no hay otros métodos de autenticación (la identidad se configura sólo para Kerberos), la autenticación simplemente falla.

Solución

La solución a este problema consiste en quitar la autenticación Kerberos de la identidad o corregir el cliente para que obtenga un vale Kerberos válido para el servicio WSA.