Resumen #

El servidor web de Microsoft, Internet Information Services (IIS), integra varios mecanismos de autenticación para validar a los usuarios frente a Active Directory o sistemas de autenticación independientes (basados ​​en LDAP). NTLM es el protocolo de autenticación de desafío/respuesta de Windows que se puede utilizar en redes y aplicaciones que operan en ambos entornos.

Se pueden considerar dos escenarios diferentes: la autenticación NTLM interactiva se compone de dos sistemas, un cliente y un controlador de dominio que se utiliza para almacenar los datos de los usuarios necesarios para autenticarse, y la autenticación NTLM no interactiva implica tres sistemas diferentes, un cliente, un servidor de aplicaciones y un dominio, para permitir que un usuario acceda a un recurso determinado en una aplicación.

La suplantación de identidad de ASP.NET permite que las aplicaciones web autentiquen y autoricen a los usuarios que dependen de Microsoft IIS.

En este artículo vamos a explicar cómo equilibrar la carga de aplicaciones que integran el protocolo NTLM para escenarios de autenticación de usuarios no interactivos.

¿Cómo funciona NTLM? #

El protocolo NTLM se basa en el protocolo HTTP/S donde un cliente determinado inicia un protocolo de enlace de un total de 6 pasos para establecer la sesión autenticada.

El protocolo de enlace de sesión autenticada requiere los siguientes pasos:

1. El cliente inicia una solicitud anónima de un determinado recurso a un servidor web.

OBTENER/HTTP

2. El servidor responde con un mensaje de no autorización y el método de autenticación que el cliente debe utilizar.

401 Autenticación WWW no autorizada: NTLM

3. El cliente reenvía la solicitud incluyendo un desafío de autenticación en formato NTLM.

OBTENER / Autorización HTTP: NTLM

4. El servidor responde con un mensaje de no autorización y solicita más información al cliente.

401 Autenticación WWW no autorizada: NTLM

5. El cliente reenvía la solicitud incluyendo el resto de la información de la sesión.

OBTENER / Autorización HTTP: NTLM

6. El servidor se conecta con el controlador de dominio para completar la solicitud de autenticación y luego confirma la autenticación al cliente.

HTTP 200 correcto

Tenga en cuenta que este protocolo de enlace es necesario en cada conexión nueva, no en solicitudes HTTP, y durante los pasos 3 a 6, es necesario mantener activa la conexión. Si la conexión está cerrada, esta parte del protocolo de enlace debe repetirse y no es válido repetir simplemente desde el paso 5. Por otro lado, una vez autenticada la conexión, no es necesario volver a enviar el encabezado de Autorización mientras el la conexión no se cierra independientemente del recurso al que se accede.

¿Cómo equilibrar la carga de aplicaciones web mediante autenticación NTLM? #

Con RELIANOID, existen dos formas principales de equilibrar la carga y crear una aplicación web basada en NTLM en alta disponibilidad, con un simple equilibrador de carga TCP de capa 2 o con un proxy de capa 4 para funciones avanzadas.

Equilibrio de carga NTLM simple en la capa 4 #

Para equilibrar la carga de aplicaciones web con soporte de autenticación NTLM con una configuración simple, podemos crear granjas basadas en LSLB con perfil L4xNAT. Podemos utilizar protocolos HTTP o HTTPS.

Luego, en la configuración global asegúrese de que el protocolo utilizado sea TCP , pero podemos seleccionar NAT o DNAT según la topología requerida.

En la sección Servicios , es necesario configurar la persistencia para garantizar que la autenticación de un cliente determinado siempre se dirija al mismo servidor backend; de lo contrario, no se podría realizar la autenticación de la conexión.

Finalmente, agregue su lista de backends y configure una verificación de estado como se indica en las secciones siguientes.

Equilibrio de carga NTLM en la capa 7 #

Esta opción permite gestionar los datos HTTP/S con soporte NTLM mediante el proxy de capa 7 configurado a través del módulo LSLB y la granja HTTP. Para ello, es necesario crear una granja para HTTP o HTTPS según los requisitos SSL del servicio virtual. La única diferencia radica en el Listener configurado en la configuración global de la granja creada.

En esta capa, dado que la aplicación aún no puede crear ninguna cookie de sesión para establecer una persistencia o fijación de conexión, podemos utilizar la opción de inserción de cookies , que permite al balanceador de carga crear una nueva cookie durante el protocolo de enlace inicial de la autenticación NTLM.

Finalmente, agregue su lista de backends y configure una verificación de estado como se indica en las secciones siguientes. Puede configurar opciones adicionales de la aplicación a nivel de proxy incluidas en este tipo de granja y el soporte NTLM no se verá afectado.

Comprobaciones de estado avanzadas para sitios web de autenticación NTLM #

Para crear nuestra comprobación de estado avanzada personalizada para aplicaciones autenticadas con NTLM, debemos crear un script en la ruta /usr/local/relianoid/app/libexec para verificar el backend, como se muestra a continuación. Por ejemplo, check_ntlm.sh con los permisos adecuados.

#!/bin/bash # obtener parámetros de entrada BACKEND=$1 PORT=$2 USER=$3 PASS=$4 URI=$5 STRING=$6 /usr/bin/curl http://${BACKEND}:${PORT}${URI } --ntlm -negotiate -u ${USUARIO}:${PASS} 2>/dev/null | grep "${STRING}" &>/dev/null si [$? == 0 ] entonces # si el comando curl no falla entonces notifica que el backend está activo echo "Server ${BACKEND}:${PORT} OK" exit 0 fi # si el comando curl falla entonces notifica que el backend está inactivo echo "El servidor ${BACKEND}:${PORT} no está bien" salida 1

En la sección Monitoreo >> Farmguardian , si corresponde, o agregándolo al comando para verificar en el servicio de granja.

Podemos probar el script de verificación de estado ejecutando:

/usr/local/relianoid/app/libexec/check_ntlm.sh 192.168.0.99 80 johndoe johnsecret "/my/uri" "DOCTYPE html"

Sabiendo que la IP del backend es 192.168.0.99 , el puerto es 80 HTTP, johndoe es un usuario ficticio en nuestro dominio, johnsecret es la contraseña ficticia, "/my/uri" es la URI a comprobar y "DOCTYPE html" es la cadena que se debe encontrar en los datos de respuesta cuando la solicitud sea exitosa.

Recomendamos crear un usuario ficticio que pueda iniciar sesión en el dominio, pero sin permisos, para incluirlo en la verificación de estado de nuestros servicios. Por eso utilizamos el usuario ficticio johndoe en nuestra verificación de estado personalizada.

Cuando nuestra verificación de estado se pruebe desde la línea de comandos y esté lista, podremos asignarla a las granjas configuradas con soporte NTLM.

¡Disfrute de sus aplicaciones web NTLM con carga equilibrada!