Alta disponibilidad para los servicios de federación de Active Directory de Microsoft con NGINX Plus

Los Servicios de federación de Active Directory (AD FS) de Microsoft permiten a las organizaciones que alojan aplicações en Windows Server extender 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 socios comerciales se denomina federación .

En la práctica, el uso de AD FS significa que los empleados de las empresas de una federación solo tienen que iniciar sesión en su entorno local. Cuando acceden a una aplicação web que pertenece a un socio comercial de confianza, el servidor AD FS local pasa su información de identidad al servidor AD FS del socio en forma de token de seguridad. El token consta de múltiples reclamaciones , que son atributos individuales del empleado (nombre de usuario, rol comercial, ID de empleado, etc.) almacenados en el Active Directory local. El servidor AD FS del socio asigna las reclamaciones en el token a las reclamaciones que entienden las aplicações del socio y luego determina si el empleado está autorizado para el tipo de acceso solicitado.

Para AD FS 2.0 y versiones posteriores, puede habilitar alta disponibilidad (HA), agregando resiliencia y escala a los servicios de autenticación para sus aplicações. En un clúster de AD FS HA, también conocido como granja de AD FS, se implementan varios servidores de AD FS dentro de un solo centro de datos o se distribuyen entre centros de datos. Un clúster configurado para alta disponibilidad totalmente activa necesita un equilibrador de carga para distribuir el tráfico de manera uniforme entre los servidores de AD FS. En una implementación de alta disponibilidad activa-pasiva, el equilibrador de carga puede proporcionar conmutación por error al servidor AD FS de respaldo cuando falla el principal.

Esta publicación explica cómo configurar NGINX Plus para proporcionar HA en entornos que ejecutan AD FS 3.0 y AD FS 4.0 Server 2012 R2 y Windows Server 2016 respectivamente.

Topología HA estándar para AD FS

Esta publicación utiliza una topología de granja AD FS estándar con fines ilustrativos. No pretende ser una recomendación ni cubrir todos los posibles escenarios de implementación. Para las implementaciones locales, una granja estándar consta de uno o más servidores AD FS en la intranet corporativa, frente a uno o más servidores proxy de aplicação web (WAP) en una red DMZ. Los servidores WAP actúan como proxies inversos que permiten a los usuarios externos acceder a las aplicações web alojadas en la intranet corporativa.

Sin embargo, WAP no tiene una forma integrada de configurar un clúster de servidores o soportar HA, por lo que se debe implementar un balanceador 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 habilitar la alta disponibilidad para AD FS. En una granja de AD FS estándar, la característica Equilibrio de carga de red (NLB) de Windows Server 2012 y 2016 actúa como equilibrador de carga. Por último, los firewalls normalmente se implementan frente a la dirección IP externa del balanceador de carga y entre zonas de red.

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

Como se señaló, NLB puede realizar el equilibrio de carga para una granja de AD FS. Sin embargo, su conjunto de funciones es bastante básico (sólo controles de salud básicos y capacidades de monitoreo limitadas). NGINX Plus tiene muchas características críticas para HA en entornos de producción de AD FS y, sin embargo, es liviano.

En la implementación de la topología estándar descrita aquí, NGINX Plus reemplaza a NLB para equilibrar la carga de tráfico para todas las granjas WAP y AD FS. Sin embargo, tenga en cuenta que no hacemos que NGINX Plus finalice las conexiones SSL para los servidores AD FS, porque el funcionamiento correcto de AD FS requiere que vea el certificado SSL real del servidor WAP (para obtener más detalles, consulte este artículo de Microsoft TechNet ).

Recomendamos que en entornos de producción también implemente HA para NGINX Plus, pero no lo muestre aquí; para obtener instrucciones, consulte Compatibilidad de alta disponibilidad para NGINX Plus en implementaciones locales en la Guía de administración de NGINX Plus.

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

La configuración de NGINX Plus para equilibrar la carga de los servidores AD FS es sencilla. Como se mencionó anteriormente, un servidor AD FS debe ver el certificado SSL real de un servidor WAP, por lo que configuramos la instancia NGINX Plus en el borde DMZ-intranet para pasar tráfico cifrado con SSL a los servidores AD FS sin terminarlo ni procesarlo de otra manera.

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

• La zona asigna un área en la memoria compartida donde todos los procesos de trabajo de NGINX Plus pueden acceder a la información de configuración y estado de tiempo de ejecución de los servidores en el grupo ascendente.
• hash establece la persistencia de la sesión entre los clientes y los servidores de AD FS, según la dirección IP de origen (la del cliente). Esto es necesario incluso si los clientes establecen una única conexión TCP con un servidor AD FS, porque en determinadas condiciones algunas aplicações pueden sufrir múltiples redirecciones de inicio de sesión si la persistencia de la sesión no está habilitada.
• status_zone significa que la API NGINX Plus recopila métricas para este servidor, que pueden mostrarse en el panel de monitoreo de actividad en vivo integrado (la API y el panel se configuran por separado ).

stream { upstream adfs_ssl { zona adfs_ssl 64k ; servidor 10.11.0.5:443; # Servidor AD FS 1 servidor 10.11.0.6:443; # Servidor AD FS 2 hash $remote_addr ; } servidor { zona_estado adfs_ssl ; escuchar 10.0.5.15:443; contraseña_proxy adfs_ssl; } }

　
Para que el tráfico de los servidores WAP fluya a través de NGINX Plus hacia los servidores AD FS, también necesitamos asignar el nombre del servicio de federación ( fs.example.com en nuestro ejemplo) a la dirección IP que NGINX Plus está escuchando. Para implementaciones de producción, agregue un registro DNS Host A en la DMZ. Para implementaciones de prueba, es suficiente crear una entrada en el archivo de hosts en cada servidor WAP; eso es lo que estamos haciendo aquí, vinculando fs.example.com a 10.0.5.15 en un archivo de hosts :

Para probar que el tráfico de los servidores WAP llega a los servidores AD FS, ejecutamos el comando ipconfig /flushdns para vaciar el DNS y luego en nuestro navegador iniciamos sesión en AD FS en la página SSO, https://fs.example.com/adfs/ls/idpinitiatedsignon.htm :

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

Ahora configuramos NGINX Plus para equilibrar la carga de las conexiones HTTPS desde clientes externos a los servidores WAP. Las mejores prácticas indican que el tráfico aún está cifrado con SSL cuando llega a los servidores de AD FS, por lo que utilizamos uno de dos enfoques para configurar NGINX Plus para pasar tráfico HTTPS a los servidores WAP: Paso a través de SSL o recifrado SSL.

Configuración de paso a través de SSL

La configuración más sencilla es hacer que NGINX Plus reenvíe el tráfico TCP cifrado con SSL sin cambios a los servidores WAP. Para ello configuramos un servidor virtual en el contexto del 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. Para entornos de producción, el FQDN externo de la aplicação publicada debe apuntar a esta dirección en forma de un registro DNS Host A en la zona pública. Para realizar pruebas, es suficiente una entrada en el archivo de hosts de su máquina cliente.

Nota:  Si va a configurar servicios HTTPS adicionales en el contexto de transmisión para escuchar en la misma dirección IP que este servidor, debe habilitar la Indicación de nombre de servidor (SNI) usando la directiva ssl_preread con un mapa para enrutar el tráfico a diferentes upstreams correctamente. Esto está fuera del alcance de este blog, pero la documentación de referencia de NGINX incluye ejemplos .

stream { upstream wap {
zona wap 64k;
servidor 10.11.0.5:443; #Servidor WAP 1
servidor 10.11.0.6:443; #Servidor WAP 2
tiempo mínimo de conexión;
}

servidor {
zona_estado wap_adfs;
escucha 10.0.5.100:443;
contraseña_proxy wap;
}
}

Configuración del reencriptado HTTPS

Como alternativa al paso a través de SSL, podemos aprovechar las capacidades completas 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 a los servidores WAP.

Los archivos de certificado y clave secreta, example.com.crt y example.com.key , contienen el FQDN externo de la aplicação 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 de nombre de servidor (SNI) requerido, especificando un nombre de host remoto que se enviará en el mensaje de saludo de cliente SSL. El encabezado debe coincidir con el FQDN externo de la aplicação publicada, en este ejemplo fs.example.com .

Usamos directivas proxy_set_header para pasar información relevante a los servidores WAP, y también para que podamos capturarla en los registros:

• El encabezado X-Real-IP contiene la dirección IP de origen (cliente) tal como se captura en la variable $remote_addr .
• X-Forwarded-For transmite ese encabezado de la solicitud del cliente, con la dirección IP del cliente adjunta (o solo esa dirección si la solicitud del cliente no tiene el encabezado).
• El encabezado x-ms-proxy indica que el usuario fue enrutado a través de un servidor proxy e identifica la instancia NGINX Plus como ese servidor.

Además de las directivas que se muestran aquí, NGINX y NGINX Plus proporcionan una serie de características que pueden mejorar el rendimiento y la seguridad de SSL/TLS. Para más información, visita nuestro blog .

http { upstream wap { zona wap 64k; servidor 10.0.5.11:443; servidor 10.0.5.10:443; encabezado de tiempo mínimo; } servidor { escuchar 10.0.5.100:443 ssl; zona_de_estado fs.ejemplo.com; nombre_del_servidor fs.ejemplo.com; certificado_ssl /etc/ssl/ejemplo.com/ejemplo.com.crt; clave_del_certificado_ssl /etc/ssl/ejemplo.com/ejemplo.com.key; ubicación / { contraseña_proxy https://wap; # 'https' habilita el reencriptado de nombre_servidor_ssl_proxy en ; nombre_ssl_proxy $host ; encabezado_conjunto_proxy Host $host; encabezado_conjunto_proxy X-Real-IP $dirección_remota; proxy_set_header X-Reenviado-Para $proxy_add_x_reenviado_para; proxy_set_header x-ms-proxy $nombre_servidor; } } }

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

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

Los servidores WAP no son necesarios para algunos casos de uso; por ejemplo, cuando no se utilizan reglas de reclamo avanzadas, como red IP y niveles de confianza. En tales casos, puede eliminar los servidores WAP y colocar NGINX Plus en el límite entre la DMZ y la intranet para autenticar las solicitudes a los servidores internos de AD FS. Esto reduce sus costos de hardware, software y operativos.

Esta configuración reemplaza las de la topología HA estándar . Es casi idéntico a la configuración de reencriptación HTTPS para equilibrar la carga de servidores WAP, pero aquí NGINX Plus equilibra la carga de las solicitudes externas directamente a los servidores AD FS en la red interna.

upstream adfs { zona adfs 64k;
servidor 192.168.5.5:443; # Servidor AD FS 1
servidor 192.168.5.6:443; # Servidor AD FS 2
encabezado de tiempo mínimo;
}

servidor {
escuchar 10.0.5.110:443 ssl;
zona de estado adfs_proxy;
nombre_servidor fs.example.com;
certificado_ssl /etc/ssl/example.com/example.com.crt;
clave_certificado_ssl /etc/ssl/example.com/example.com.key;

ubicación / {
contraseña_proxy https://adfs;
nombre_servidor_ssl_proxy on;
nombre_proxy_ssl $host; Encabezado_proxy Host $host;
Encabezado_proxy X-Real-IP $dirección_remota;
Encabezado_proxy X-Reenviado-Para $add_proxy_x_reenviado_para;
Encabezado_proxy x-ms-proxy $nombre_servidor;
}
}

Pruebe NGINX Plus en su implementación de AD FS: comience hoy mismo una prueba gratuita de 30 días o contáctenos para analizar su caso de uso.