Alta disponibilidad para Microsoft Active Directory Federation Services con NGINX Plus

NGINX | 16 de octubre de 2018

Microsoft Servicios de federación de Active Directory (AD FS) permite a las organizaciones que alojan aplicaciones en Windows Server ampliar el acceso de inicio de sesión único (SSO) a los empleados de socios comerciales de confianza a través de una extranet. El intercambio de información de identidad entre los socios comerciales se denomina federación.

En la práctica, el uso de AD FS implica que los empleados de las empresas que forman parte de una federación solo tienen que iniciar sesión en su entorno local. Cuando acceden a una aplicación web de un socio comercial de confianza, el servidor de AD FS local transmite su información de identidad al servidor de AD FS del socio en forma de token de seguridad. El token consta de varias notificaciones, que son atributos individuales del empleado (nombre de usuario, función empresarial, identificador de empleado, etc.) almacenados en la instancia local de Active Directory. El servidor de AD FS del socio asigna las notificaciones del token a otras que las aplicaciones del socio puedan interpretar y, a continuación, determina si el empleado está autorizado para el tipo de acceso solicitado.

En AD FS 2.0 y versiones posteriores, puede habilitar la alta disponibilidad (HA), lo que aporta resiliencia y escalabilidad a los servicios de autenticación de sus aplicaciones. En un clúster de alta disponibilidad de AD FS, también conocido como granja, se implementan varios servidores AD FS en un único centro de datos o se distribuyen entre varios centros de datos. Un clúster configurado con alta disponibilidad en modo activo-activo requiere un equilibrador de carga para distribuir el tráfico de manera uniforme entre los servidores AD FS. En una implementación de alta disponibilidad en modo activo-pasivo, el equilibrador de carga puede conmutar al servidor AD FS de respaldo cuando falla el servidor principal.

Este artículo explica cómo configurar NGINX Plus para proporcionar alta disponibilidad en entornos que ejecutan AD FS 3.0 y AD FS 4.0 en Windows Server 2012 R2 y Windows Server 2016, respectivamente.

Topología estándar de alta disponibilidad para AD FS

Esta publicación utiliza una topología estándar de granja de AD FS con fines ilustrativos. No pretende servir como recomendación ni abarcar todos los escenarios de implementación posibles. En las implementaciones locales, una granja estándar consta de uno o varios servidores de AD FS en la intranet corporativa, precedidos por uno o varios servidores de Proxy de aplicación web (WAP) en una red DMZ. Los servidores WAP actúan como proxies inversos que permiten a los usuarios externos acceder a las aplicaciones web alojadas en la intranet corporativa.

Sin embargo, WAP no dispone de una forma integrada de configurar un clúster de servidores ni de ofrecer alta disponibilidad, por lo que debe implementarse un equilibrador de carga delante de los servidores WAP. También se coloca un equilibrador de carga en el límite entre la DMZ y la intranet para proporcionar alta disponibilidad a AD FS. En una granja estándar de AD FS, la característica Equilibrio de carga de red (NLB) de Windows Server 2012 y 2016 actúa como equilibrador de carga. Por último, normalmente se implementan firewalls delante de la dirección IP externa del equilibrador de carga y entre las distintas zonas de red.

Figura 1. Granja estándar de AD FS local con NLB

Uso de NGINX Plus en la topología de alta disponibilidad estándar

Como se ha indicado, NLB puede realizar el balanceo de carga de una granja de AD FS. Sin embargo, su conjunto de funciones es bastante básico (solo comprobaciones de estado básicas y capacidades de supervisión limitadas). NGINX Plus ofrece muchas funciones esenciales para garantizar la alta disponibilidad en entornos de producción de AD FS y, aun así, es ligero.

En la implementación de la topología estándar descrita aquí, NGINX Plus sustituye a NLB para equilibrar el tráfico de todas las granjas de WAP y AD FS. Sin embargo, tenga en cuenta que no hacemos que NGINX Plus finalice las conexiones SSL de los servidores de AD FS, ya que, para funcionar correctamente, AD FS debe poder ver el certificado SSL real del servidor WAP (para obtener más información, consulte este artículo de Microsoft TechNet).

Recomendamos que, en los entornos de producción, también implemente alta disponibilidad para el propio NGINX Plus, aunque no se muestra aquí. Para obtener instrucciones, consulte Compatibilidad con alta disponibilidad para NGINX Plus en implementaciones locales en la Guía de administración de NGINX Plus.

Figura 2. Granja estándar de AD FS local con NGINX Plus

Configuración de NGINX Plus para equilibrar la carga de los servidores de AD FS

La configuración de NGINX Plus para equilibrar la carga de los servidores de AD FS es sencilla. Como se ha mencionado anteriormente, un servidor de AD FS debe ver el certificado SSL real de un servidor WAP, por lo que configuramos la instancia de NGINX Plus situada en el límite entre la DMZ y la intranet para que reenvíe el tráfico cifrado mediante SSL a los servidores de AD FS sin finalizarlo ni procesarlo de ningún otro modo.

Además de las directivas obligatorias, incluimos las siguientes directivas en la configuración:

zone asigna un área en la memoria compartida donde todos los procesos de trabajo de NGINX Plus pueden acceder a la configuración y a la información sobre el estado en tiempo de ejecución de los servidores del grupo de servidores upstream.
hash establece la persistencia de sesión entre los clientes y los servidores de AD FS en función de la dirección IP de origen (la del cliente). Esto es necesario aunque los clientes establezcan una única conexión TCP con un servidor de AD FS, ya que, en determinadas condiciones, algunas aplicaciones pueden sufrir varias redirecciones de inicio de sesión si no se habilita la persistencia de sesión.
status_zone indica que la API de NGINX Plus recopila métricas de este servidor, que pueden mostrarse en el panel integrado de supervisión de la actividad en tiempo real (la API y el panel se configuran por separado).

stream {    upstream adfs_ssl {
        zone adfs_ssl 64k;
        server 10.11.0.5:443; # AD FS server 1
        server 10.11.0.6:443; # AD FS server 2
        hash $remote_addr;
    }

    server {
        status_zone adfs_ssl;
        listen 10.0.5.15:443;
        proxy_pass adfs_ssl;
    }
}

Para que el tráfico de los servidores WAP fluya a través de NGINX Plus hasta los servidores de AD FS, también debemos asociar el nombre del servicio de federación (fs.example.com en nuestro ejemplo) a la dirección IP en la que escucha NGINX Plus. Para implementaciones de producción, añada un registro A de host DNS en la DMZ. Para implementaciones de prueba, basta con crear una entrada en el archivo hosts de cada servidor WAP; eso es lo que hacemos aquí, asociando fs.example.com a 10.0.5.15 en un archivo hosts:

Figura 3. Asignación del servidor NGINX Plus en el archivo hosts file

Para comprobar que el tráfico de los servidores WAP llega a los servidores de AD FS, ejecutamos el comando ipconfig /flushdns para vaciar la caché de DNS y, a continuación, iniciamos sesión en AD FS desde el navegador, en la página de inicio de sesión único (SSO): https://fs.example.com/adfs/ls/idpinitiatedsignon.htm:

Figura 4. Inicio de sesión en AD FS

Configuración de NGINX Plus para equilibrar la carga de los servidores WAP

Ahora configuramos NGINX Plus para equilibrar la carga de las conexiones HTTPS de los clientes externos a los servidores WAP. Las prácticas recomendadas establecen que el tráfico debe seguir cifrado mediante SSL cuando llegue a los servidores AD FS, por lo que utilizamos uno de estos dos métodos para configurar NGINX Plus a fin de que transfiera el tráfico HTTPS a los servidores WAP: paso directo de SSL o recifrado SSL.

Configuración del paso directo de SSL

La configuración más sencilla consiste en hacer que NGINX Plus reenvíe el tráfico TCP cifrado mediante SSL sin modificarlo a los servidores WAP. Para ello, configuramos un servidor virtual en el contexto stream similar al anterior para equilibrar la carga de los servidores AD FS.

Aquí, NGINX Plus escucha el tráfico externo en una dirección IP única diferente, 10.0.5.100. En entornos de producción, el FQDN externo de la aplicación publicada debe apuntar a esta dirección mediante un registro de host DNS de tipo A en la zona pública. Para realizar pruebas, basta con añadir una entrada en el archivo hosts del equipo cliente.

Nota: Si va a configurar servicios HTTPS adicionales en el contexto stream para que escuchen en la misma dirección IP que este servidor, debe habilitar la indicación del nombre del servidor (SNI) mediante la directiva ssl_preread con un map para enrutar correctamente el tráfico a distintos servidores upstream. Esto queda fuera del alcance de este blog, pero la documentación de referencia de NGINX incluye ejemplos.

stream {    upstream wap {
        zone wap 64k;
        server 10.11.0.5:443; #WAP server 1
        server 10.11.0.6:443; #WAP server 2
        least_time connect;
    }
  
    server {
        status_zone wap_adfs;
        listen 10.0.5.100:443;
        proxy_pass wap;
    }
}

Configuración del recifrado HTTPS

Como alternativa al paso directo de SSL, podemos aprovechar todas las capacidades de capa 7 de NGINX Plus configurando un servidor virtual en el contexto http para aceptar tráfico HTTPS. NGINX Plus finaliza las conexiones HTTPS de los clientes y crea nuevas conexiones HTTPS con los servidores WAP.

Los archivos de certificado y clave secreta, example.com.crt y example.com.key, contienen el FQDN externo de la aplicación publicada en la propiedad Nombre común (CN) o Nombre alternativo del sujeto (SAN); en este ejemplo, el FQDN es fs.example.com.

Las directivas proxy_ssl_server_name y proxy_ssl_name habilitan el encabezado de indicación del nombre del servidor (SNI) necesario, que especifica el nombre de host remoto que se enviará en el mensaje Client Hello de SSL. El encabezado debe coincidir con el FQDN externo de la aplicación publicada, en este ejemplo, fs.example.com.

Usamos las directivas proxy_set_header para transmitir información relevante a los servidores WAP y poder registrarla también en los logs:

La cabecera X-Real-IP contiene la dirección IP de origen (del cliente), tal como se registra en la variable $remote_addr.
El encabezado X-Forwarded-For transmite dicho encabezado de la solicitud del cliente, añadiéndole la dirección IP del cliente (o únicamente esa dirección si la solicitud del cliente no incluye el encabezado).
El encabezado x-ms-proxy indica que el usuario fue redirigido a través de un servidor proxy e identifica la instancia de NGINX Plus como dicho servidor.

Además de las directivas que se muestran aquí, NGINX y NGINX Plus ofrecen diversas funciones que pueden mejorar el rendimiento y la seguridad de SSL/TLS. Para obtener más información, consulte nuestro blog.

http {    upstream wap {
        zone wap 64k;
        server 10.0.5.11:443;
        server 10.0.5.10:443;
        least_time header;
    }

    server {
        listen 10.0.5.100:443 ssl;
        status_zone fs.example.com;
        server_name fs.example.com;
        ssl_certificate     	/etc/ssl/example.com/example.com.crt;
        ssl_certificate_key 	/etc/ssl/example.com/example.com.key;

        location / {
            proxy_pass https://wap; # 'https' enables reencrypt 
            proxy_ssl_server_name on;
            proxy_ssl_name $host;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header x-ms-proxy $server_name;
        }
    }
}

Configuración de NGINX Plus en una topología sin servidores WAP

Al permitir que clientes externos accedan a sus servidores de AD FS, se recomienda finalizar el tráfico externo en el límite entre la DMZ y la intranet corporativa, así como identificar los intentos de autenticación externos insertando la cabecera «x-ms-proxy». Los servidores WAP realizan ambas funciones, pero NGINX Plus, configurado como se indica en la sección anterior, también las realiza.

Los servidores WAP no son necesarios en algunos casos de uso; por ejemplo, cuando no se utilizan reglas de notificaciones avanzadas, como las de red IP y niveles de confianza. En esos casos, puede prescindir de los servidores WAP y situar NGINX Plus en el límite entre la DMZ y la intranet para autenticar las solicitudes dirigidas a los servidores AD FS internos. Esto reduce los costes de hardware, software y operaciones.

Figura 5. Granja de AD FS sin servidores WAP

Esta configuración sustituye a las de la topología de alta disponibilidad estándar. Es prácticamente idéntica a la configuración de recifrado HTTPS para equilibrar la carga de los servidores WAP, pero en este caso NGINX Plus equilibra las solicitudes externas directamente entre los servidores de AD FS de la red interna.

upstream adfs {    zone adfs 64k;
    server 192.168.5.5:443; # AD FS Server 1
    server 192.168.5.6:443; # AD FS Server 2
    least_time header;
 }

server {
    listen 10.0.5.110:443 ssl;
    status_zone adfs_proxy;
    server_name fs.example.com;
    ssl_certificate         /etc/ssl/example.com/example.com.crt;
    ssl_certificate_key     /etc/ssl/example.com/example.com.key;
  
    location / {
        proxy_pass https://adfs;
        proxy_ssl_server_name on;
        proxy_ssl_name $host;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header x-ms-proxy $server_name;
    }
 }

Pruebe NGINX Plus en su implementación de AD FS: comience hoy mismo una prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre su caso de uso.