VPN - Configurar un servidor Active Directory [AD] a través de un túnel VPN

Este artículo proporciona una visión detallada de cómo configurar un servidor Active Directory (AD) a través de un túnel VPN L2TP utilizando el método de autenticación USG FLEX/ATP VPN. Además, la guía que aquí se presenta es aplicable a las configuraciones de VPN IPsec IKEv2 e IKEv1.

Los túneles VPN son un componente crítico cuando se establecen redes que son inherentemente expansivas, tales como redes corporativas globales o sitios principales interconectados con ubicaciones subsidiarias.

Una característica fundamental de las redes corporativas es el proceso de autenticación de los usuarios ante un servidor, demostrando así su confiabilidad y obteniendo acceso a los recursos internos. Este tutorial pretende dotarle de las herramientas necesarias para configurar la autenticación ante un servidor de autenticación a través de un túnel VPN.

Dos cortafuegos están conectados a través de una VPN de sitio a sitio, y en el sitio principal A, hay un servidor RADIUS dentro de la LAN. En el Sitio B, puede haber varios clientes que quieran autenticarse en el servidor RADIUS del Sitio A. En el Sitio B, podemos encontrar clientes locales que necesiten conectarse al Servidor RADIUS del Sitio A, o Clientes VPN L2TP que necesiten autenticarse en el RADIUS del Sitio A.

Aquí, tenemos que hacer una importante diferenciación entre el Cliente VPN y el Cliente LAN en el Sitio B - mientras que es muy probable, que el Cliente del Sitio B pueda autenticarse sin ningún problema hacia el RADIUS del Sitio A, los clientes VPN L2TP muy probablemente no podrán hacerlo. ¿Por qué?

Las VPN de sitio a sitio se configuran con una política local y una política remota. Estas políticas determinan qué rutas de red se crean al crear el túnel, es decir, qué redes pueden "hablar entre sí". En este caso, estamos asumiendo que el enrutamiento entre 192.168.10.0/24 y 192.168.20.0/24 está bien. La VPN L2TP, que inherentemente tiene que ser una subred diferente a las subredes locales del Sitio B, no tiene permitido comunicarse hacia el Sitio A porque no está incluida dentro de la Política Local o Remota.

Es decir, si no añadimos rutas de política adicionales. Con la ayuda de este tipo de rutas, podemos forzar cualquier intento de autenticación proveniente de la VPN L2TP hacia un destino en el Sitio A. Primero, necesitamos definir que las autenticaciones en el Sitio B sean dirigidas al RADIUS del Sitio A.

Configurar el servidor AAA

Configuración > Objeto > Servidor AAA

y configure un objeto de autenticación hacia la IP 192.168.10.100:

Pruebe la autenticación AD

Configuración -> Objeto -> Servidor AAA

Asegúrese de guardar su configuración antes de probar la validación de la configuración.

Buen resultado	Mal resultado

Configure el Auth. Method

Este objeto-servidor AAA debe combinarse ahora con un método de autenticación, que a su vez se establecerá como la autenticación principal para nuestra VPN. En primer lugar, vaya al menú

Configuración > Objeto > Método de autenticación Method

y añade el Servidor AAA recién creado al método de autenticación predeterminado Auth. predeterminado:

Hacer que el cortafuegos se una al servidor AD

A continuación, el USG debe unirse al dominio AD con el nombre de dominio del servidor AD

Vaya a Configuración -> Sistema -> Nombre de host

El dominio es el nombre de dominio del servidor de anuncios y el nombre NetBIOS es el dominio.

Para apuntar el cortafuegos al servidor AD, necesitamos crear un registro DNS para encontrar correctamente el servidor AD a través de la dirección IP del servidor AD:

Configurar la VPN

A través de IKEv2

Configuración -> VPN -> VPN IPSec -> Puerta de enlace VPN - Añadir/Editar

Haga clic en "Show Advanced Settings" y active "Extended Authentication Protocol" y seleccione Server mode.

A continuación, seleccione el método AAA (Auth. Method) y el usuario permitido (Allowed user).

Vía L2TP

Después de eso, seleccionamos este Auth. que se utilizará a través de la VPN L2TP mediante

Configuración > VPN > VPN L2TP sobre IPSec

(Tenga en cuenta que el grupo de direcciones IP no se corresponde con la topología dibujada anteriormente, ya que esto es sólo un ejemplo de cómo configurar el túnel L2TP).

Ahora que la VPN L2TP está configurada con una autenticación que debe reenviarse hacia el RADIUS en el Sitio A, tenemos que crear rutas de política:

La primera ruta de política empujará cualquier cosa que venga de cualquier fuente, que quiera moverse hacia la IP 192.168.10.100, dentro del túnel hacia el Sitio A - lo que significa también el intento de autenticación desde nuestra VPN L2TP. La segunda ruta de política empujará cualquier cosa destinada a la subred VPN L2TP de vuelta a la VPN L2TP.

En el otro sitio, ahora simplemente tenemos que complementar esto a través de una regla correspondiente, que empujará cualquier cosa de subredes diferentes de la LAN del Sitio B (como el intento de nuestra subred VPN L2TP) de vuelta al túnel hacia el Sitio B, activando nuestra ruta de política que hemos establecido en ese sitio.

Siguiendo esta sencilla guía, ahora debería ser capaz de autenticar a sus clientes hacia un RADIUS en otra ubicación VPN remota.

Configurar el reenvío DNS para el dominio AD (recomendado)

Para garantizar una resolución de nombres AD adecuada, configure el reenvío DNS además de la entrada DNS local:

• Vaya a Configuración → Sistema → DNS → Reenvío de zona de dominio, añada su dominio AD (por ejemplo, empresa.local) y configure el servidor DNS AD como reenviador.

• En Conexión VPN → Configuración del cliente, asigne el servidor AD DNS (o la IP LAN del cortafuegos si el reenvío está activado) como Primer servidor DNS.

• (Opcional) Añada una ruta de política si las consultas DNS deben forzarse a través de la VPN.

Compruébelo con: nslookup dc1.company.local.

Solución de problemas y comprobación del resultado

Vaya a

Monitor -> Estado de la red -> Usuarios conectados

Vaya a

Monitor -> VPN Monitor -> IPSec

Solución de problemas

Vaya a la consola web del cortafuegos o conéctese al cortafuegos a través de SSH y ejecute este comando

debug domain-auth test profile-name [nombre del perfil del anuncio] username [nombre de usuario] password [contraseña]

Sustituya ad profile name por el nombre "AD Server Summary" de Active Directory y utilice el nombre de usuario y la contraseña de la autenticación de dominio a través de MSCHAP.

Más artículos encontrados aquí:

AD (active directory) usuario autenticar verificación

Cómo unirse a un dominio de Active Directory con USG/ATP/VPN

Cómo hacer autenticación de dos factores con usuarios de Active Directory