Autenticación NTLM mediante FSSO

Descripción:

Este artículo describe cómo Fortinet Single-Sign on admite la autenticación NTLM.

Alcance

FSSO

Solución

En una red de Windows AD, FSSO también puede proporcionar un servicio de autenticación NTLM a la unidad FortiGate.

Cuando el usuario realiza una solicitud que requiere autenticación, la unidad FortiGate inicia la negociación NTLM con el navegador del cliente.

FortiGate no procesa los paquetes NTLM por sí mismo. En su lugar, reenvía todos los paquetes NTLM al servicio FSSO para que los procese.

NTLM tiene la ventaja de no requerir un agente FSSO, pero no es transparente para los usuarios y el navegador web del usuario debe ser compatible con NTLM.

El protocolo NTLM protege la contraseña del usuario al no enviarla a través de la red.

En su lugar, el servidor envía al cliente un número aleatorio que el cliente debe cifrar con el valor hash de la contraseña del usuario.

El servidor compara el resultado del cifrado del cliente con el resultado de su propio cifrado. Los dos coincidirán solo si ambas partes usaron la misma contraseña.

Autenticación NTLM

Si la autenticación NTLM con la red de Windows AD es exitosa y el usuario pertenece a uno de los grupos permitidos en la política de seguridad aplicable, FortiGate permite la conexión pero requerirá autenticación nuevamente en el futuro cuando caduque la autenticación actual.

Fortinet ha probado la autenticación NTLM con los navegadores Internet Explorer y Firefox.

NTLM en un entorno de múltiples dominios

En un entorno de múltiples dominios para NTLM, el factor importante es que exista una relación de confianza entre los dominios.

En un bosque, esta relación se crea automáticamente. Por lo tanto, es posible instalar el agente FSSO en uno de los controladores de dominio sin preocupaciones.

Pero en el caso de varios dominios que no están en un bosque, es necesario crear una relación de confianza entre los dominios.

Para no tener una relación de confianza entre los múltiples dominios, es necesario utilizar FSAE 4.0 MR1 y el agente DC debe instalarse una vez en cada dominio.

Entonces es posible usar políticas de seguridad para configurar el acceso al servidor.

En la figura a continuación, se muestran tres dominios conectados al servidor del agente FSSO Collector. El cliente inicia sesión en su controlador de dominio local, que luego envía la información del evento de inicio de sesión del usuario al agente recopilador.

Cuando el cliente intenta acceder a Internet, la unidad FortiGate se pone en contacto con el agente recopilador para obtener la información de inicio de sesión, ve que el cliente está autenticado y permite el acceso a Internet.

Hay varios dominios, cada uno con un agente de controlador de dominio (DCagent) que envía información de inicio de sesión al agente de recopilación.

Si varios dominios tienen una relación de confianza, solo se requiere un DCagent en lugar de uno por dominio.

FSSO NTLM con varios dominios que no están en un bosque

Comprender el proceso de autenticación NTLM.

1) El usuario intenta conectarse a un recurso HTTP externo (internet).

La aplicación cliente (navegador) en la computadora del usuario emite una solicitud no autenticada a través de la unidad FortiGate.

2) FortiGate es consciente de que este cliente no se ha autenticado previamente, por lo que responde con un código de estado 401 No autenticado y le dice al cliente con qué método de autenticación responder en el encabezado: Proxy autenticado: NTLM. Luego se desmantela la sesión inicial.

3) La aplicación cliente se conecta nuevamente a FortiGate y emite una solicitud GET, con una autorización de proxy: encabezado NTLM <negociar cadena>. <cadena de negociación> es un paquete de negociación NTLM Tipo 1 codificado en base64.

4) La unidad FortiGate responde con un código de estado 401 ‘autorización de proxy requerida’ y un Proxy-Autenticación: NTLM <cadena de desafío> (un paquete de desafío NTLM Tipo 2 codificado en base 64).

En este paquete está el desafío nonce, un número aleatorio elegido para esta negociación que se usa una vez y evita ataques de repetición.

Nota:

La conexión TCP debe mantenerse activa, ya que toda la información posterior relacionada con la autenticación está vinculada a la conexión TCP. Si se descarta, el proceso de autenticación debe comenzar de nuevo desde el principio.

5) El cliente envía una nueva solicitud GET con una cabecera Proxy-Autenticación: NTLM <cadena de autenticación>, donde <cadena de autenticación> es un paquete de autenticación NTLM Tipo 3 que contiene:

• Nombre de usuario y dominio
• El desafío una vez codificado con la contraseña del cliente (puede contener el nonce del desafío dos veces utilizando diferentes algoritmos).

6) Si la negociación es exitosa y el usuario pertenece a uno de los grupos permitidos en la política de seguridad, la conexión es permitida, de lo contrario, el FortiGate niega la autenticación emitiendo un código de retorno 401 y solicita un nombre de usuario y contraseña.

A menos que se rompa la conexión TCP, no se envían más credenciales del cliente al proxy.

Nota:

Si la política de autenticación alcanza el periodo de tiempo de espera de autenticación, se produce un nuevo handshake NTLM.

Compatibilidad de NTLM sin agente

La autenticación NTLM sin agente se puede configurar directamente desde FortiGate al controlador de dominio a través del protocolo SMB (no se requiere agente).

Tenga en cuenta que este método de autenticación solo es compatible con las políticas de proxy.

Sintaxis.

Tenga en cuenta que el controlador de dominio solo está disponible cuando el método está configurado en NTLM y/o negociación-ntlm está configurado para habilitar.

# config authentication scheme

edit <name>

set method ntlm
set domain-controller <dc-setting>

next

end

# config user domain-controller

edit <name>

set ip-address <dc-ip>
set port <port> – default = 445
set domain-name <dns-name>
set ldap-server <name>

next

end