¿Cómo debería ser la autenticación NTLM en el nivel de paquete?

Introducción

Este documento describe la autenticación NT LAN Manager (NTLM) en el nivel de paquete. 

¿Cómo debería ser la autenticación NTLM en el nivel de paquete?

Puede descargar una captura de paquetes a continuación de este artículo aquí: https://supportforums.cisco.com/sites/default/files/attachments/document/ntlm_auth.zip

IP del cliente: 10.122.142.190

IP WSA: 10.122.144.182

Número y detalles del paquete

#4 El cliente envía una solicitud GET al proxy.

#7 El proxy devuelve un 407. Esto significa que el proxy no permite el tráfico debido a una falta de autenticación adecuada. Si observa los encabezados HTTP en esta respuesta, verá un "Proxy-authenticate: NTLM". Esto indica al cliente que un método de autenticación aceptable es NTLM. Del mismo modo, si el encabezado "Proxy-authenticate: Basic" está presente, el proxy le dice al cliente que las credenciales básicas son aceptables. Si ambos encabezados están presentes (común), el cliente decide qué método de autenticación utilizará.

Una cosa a tener en cuenta es que el encabezado de autenticación es "Proxy-authenticate:". Esto se debe a que la conexión en la captura utiliza proxy de reenvío explícito. Si se tratara de una implementación de proxy transparente, el código de respuesta sería 401 en lugar de 407 y los encabezados serían "www-authenticate:" en lugar de "proxy-authenticate:".

#8 El proxy FIN conecta este socket TCP. Esto es correcto y normal.

#15 En un nuevo socket TCP, el cliente realiza otra solicitud GET. Esta vez observe que GET contiene el encabezado HTTP "proxy-authorization:". Contiene una cadena codificada que contiene detalles relativos al usuario/dominio.

Si expande Proxy-authorization > NTLMSSP, verá la información descodificada enviada en los datos NTLM. En "NTLM Message Type" (Tipo de mensaje NTLM), observará que es "NTLMSSP_NEGOTIATE". Este es el primer paso del protocolo de enlace NTLM de tres vías.

#17 El proxy responde con otros 407. Hay otro encabezado "proxy-authenticate" presente. Esta vez contiene una cadena de desafío NTLM. Si lo expande aún más, verá que el tipo de mensaje NTLM es "NTLMSSP_CHALLENGE". Este es el segundo paso del protocolo de enlace NTLM de tres vías.

En la autenticación NTLM, el controlador de dominio de Windows envía una cadena de desafío al cliente. A continuación, el cliente aplica un algoritmo al desafío NTLM que determina la contraseña del usuario en el proceso. Esto permite al controlador de dominio verificar que el cliente conoce la contraseña correcta sin enviar nunca la contraseña a través de la línea. Esto es mucho más seguro que las credenciales básicas, en las que la contraseña se envía en texto sin formato para que todos los dispositivos de rastreo la vean.

#18 El cliente envía un GET final. Tenga en cuenta que este GET está en el MISMO socket TCP en el que se produjeron el NTLM Negotiate y el NTLM Challenge. Esto es vital para el proceso NTLM. El protocolo de enlace completo debe encontrarse en el mismo socket TCP; de lo contrario, la autenticación no será válida.

En esta solicitud, el cliente envía el desafío NTLM modificado (respuesta NTLM) al proxy. Este es el último paso del protocolo de enlace NTLM de tres vías.

#21 El proxy devuelve una respuesta HTTP. Esto significa que el proxy aceptó las credenciales y decidió entregar el contenido.