Configurar Per-Connection AD SSO en Sophos Firewall para hosts multiusuario

Varios usuarios trabajan en el mismo Remote Desktop Session Host, pero Sophos Firewall solo ve una IP de servidor para todas las conexiones. Per-Connection AD SSO resuelve este caso específico para el tráfico web: Direct Web Proxy autentica cada conexión HTTP y HTTPS por separado mediante Kerberos o NTLM.

El límite es tan importante como la función. Solo reciben una identidad de usuario las conexiones que el navegador o la aplicación envían expresamente al proxy. DNS, RDP, SMB y el resto del tráfico sin proxy procedente de la misma IP de servidor permanecen sin autenticar. Si estos protocolos también requieren un control por usuario, SATC para Remote Desktop Services es la opción más adecuada.

⚠️ En cuanto se introduce una dirección IP en Multi-user hosts, deja de utilizar otros métodos de autenticación basados en IP. STAS, Captive Portal, Clientless User y AD SSO transparente dejan de aplicarse a esa IP. Por tanto, conviene empezar con un único servidor piloto y documentar antes la ruta de autenticación existente.

Per-Connection AD SSO en nueve pasos

1. Decidir si solo se deben procesar por usuario HTTP y HTTPS enviados a través de un proxy explícito.
2. Comprobar Active Directory, la importación de grupos, DNS, la hora y el Domain Join del firewall.
3. Preparar un FQDN resoluble para el firewall y un HTTP SPN correspondiente para Kerberos.
4. Permitir AD SSO y Web proxy solo para la zona de origen o el host piloto necesarios.
5. Crear el servidor RDS como un objeto IP host exacto.
6. Activar Per-Connection AD SSO para este host en Authentication > Web authentication.
7. Configurar los navegadores y las aplicaciones compatibles con proxy para que utilicen el FQDN del firewall y el puerto 3128.
8. Colocar una regla de host específica y con registro antes de reglas de usuario que puedan competir, y mantener Match known users desactivado.
9. Probar por separado dos sesiones RDS paralelas, resultados distintos de Web Policy y tráfico sin proxy.

¿Per-Connection AD SSO, STAS o SATC?

Los tres métodos proporcionan contexto de usuario, pero resuelven problemas distintos.

• STAS es adecuado para clientes Windows normales cuando una IP de cliente suele pertenecer exactamente a un usuario. El firewall recibe una asignación entre usuario e IP a partir de los eventos de inicio de sesión de Windows.
• Per-Connection AD SSO es adecuado para hosts multiusuario cuando solo es necesario distinguir conexiones HTTP y HTTPS enviadas expresamente a través del proxy. No se necesita un agente SATC en el servidor RDS, pero todas las aplicaciones deben utilizar Direct Web Proxy de forma fiable.
• SATC es adecuado para sistemas RDS o Citrix cuando otros tipos de conexión procedentes de las sesiones individuales también necesitan una identidad. Para ello se requiere Sophos Server Protection en el Session Host.

El STAS clásico en Sophos Firewall no puede distinguir varios usuarios detrás de la misma IP RDS. Por eso, Per-Connection AD SSO y SATC no son variantes más cómodas de STAS, sino modelos operativos independientes. Si una aplicación no admite un proxy explícito o es necesario aplicar reglas por usuario a protocolos que no son web, hay que detenerse aquí y evaluar SATC.

Ejemplo y valores sustituibles

La guía utiliza este ejemplo:

• Host multiusuario: RDS01
• Dirección IP: 10.20.30.40
• FQDN del firewall y destino del proxy: fw01.corp.example
• Puerto de Direct Web Proxy: 3128
• Grupos de AD: RDS-Web-Standard y RDS-Web-Restricted
• una cuenta piloto por grupo con resultados de Web Policy deliberadamente distintos

Se debe sustituir 10.20.30.40 por la IP fija del servidor piloto tal como la ve el firewall. No deben aparecer otros sistemas detrás de esta dirección mediante NAT. fw01.corp.example es un nombre de documentación y debe sustituirse por el FQDN real del firewall que se resuelva internamente. La parte correspondiente al host debería tener como máximo 15 caracteres y escribirse en minúsculas para que el hostname, el nombre NetBIOS, el objeto de equipo de AD y el SPN coincidan.

El puerto 3128 es el valor predeterminado de Direct Web Proxy. Si el entorno utiliza otro listening port, el firewall, el archivo PAC o la GPO, el navegador y las pruebas deben utilizar el mismo valor. Los grupos de ejemplo solo sirven para que la validación sea comprensible; los nombres de grupo y las Web Policies deben ajustarse a la estructura de permisos propia.

Preparar los requisitos

Comprobar Active Directory y el Domain Join

El firewall necesita un servidor de Active Directory operativo, grupos importados y un Domain Join correcto. Conectar Active Directory con Sophos Firewall explica LDAPS, la base de búsqueda, la importación de grupos y los requisitos generales de AD SSO.

Para una consulta LDAP normal es suficiente una cuenta con permisos de lectura. En cambio, el Domain Join y la creación del SPN requieren una cuenta Domain Admin o una cuenta con permisos correctamente delegados. La cuenta almacenada también debe permitir un rejoin posterior, ya que HA, otros servidores AD o las actualizaciones pueden volver a provocarlo. No conviene mantener innecesariamente una cuenta Domain Admin sin restricciones para este fin.

En Authentication > Services > Firewall authentication methods, se debe seleccionar el servidor AD previsto y colocarlo en el orden correcto. Si hay varios servidores, el firewall los comprueba de arriba abajo. Test connection en el servidor AD solo confirma las credenciales y la accesibilidad, no el posterior inicio de sesión Kerberos o NTLM en el navegador.

Comprobar FQDN, DNS, SPN y hora

Kerberos solo funciona si los clientes utilizan el FQDN del firewall como destino del proxy. Una dirección IP del proxy no es suficiente. En un cliente piloto Windows sirven estas comprobaciones de solo lectura:

Resolve-DnsName fw01.corp.example
setspn -Q HTTP/fw01.corp.example
w32tm /query /status

El HTTP SPN, o Service Principal Name, vincula el FQDN del proxy al objeto de equipo del firewall en AD. setspn -Q debería devolver exactamente una asignación coincidente. Antes del despliegue se debe aclarar tanto la ausencia de resultados como la existencia de varios.

La respuesta DNS debe corresponder al firewall previsto. El cliente, el controlador de dominio y el firewall también necesitan una hora compatible con Kerberos. Los comandos no modifican nada. No se debe corregir el SPN, el Domain Join o la configuración horaria por sospecha, sino demostrar primero el error real.

Inventariar la compatibilidad con proxy y las excepciones

Cada navegador y aplicación cuyo tráfico web deba recibir una identidad de usuario tiene que usar el proxy explícito y admitir la autenticación integrada de Windows. Antes del despliegue se debe comprobar al menos:

• los navegadores de cada sesión RDS compatible
• las aplicaciones con su propia pila HTTP
• las actualizaciones de Windows y del software
• los servicios que se ejecutan en el contexto del sistema en lugar de una sesión de usuario
• los destinos incluidos en el archivo PAC o en la lista de exclusión del proxy

El tráfico que evita el proxy permanece sin ID de usuario, tal como se espera. Para las conexiones de máquina necesarias se debe planificar una regla independiente y muy limitada sin referencia al usuario. Una regla amplia con Any diluiría el efecto de seguridad de las reglas de usuario y las Web Policies.

Configurar Per-Connection AD SSO

1. Preparar el FQDN del firewall y AD SSO

En Administration > Admin and user settings, se introduce el FQDN previsto para el firewall. A continuación, en Authentication > Web authentication, se selecciona Kerberos & NTLM en If Active Directory (AD) SSO is configured. NTLM es técnicamente compatible como fallback, pero en instalaciones grandes Kerberos debería funcionar de forma fiable porque Per-Connection AD SSO puede generar muchas solicitudes de autenticación adicionales.

Tras inicializar AD SSO, deben aparecer estos mensajes de éxito en Authentication dentro de Log Viewer:

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

El firewall solo ofrece los métodos cuando ambos canales funcionan. Cannot initialize Kerberos authentication o Cannot establish NTLM authentication channel son señales para detenerse, no una invitación a reiniciar servicios a ciegas.

2. Limitar Device Access

En Administration > Device access, AD SSO y Web proxy deben estar permitidos para la ruta de origen prevista. Para una IP piloto fija, una Local service ACL exception rule específica suele ser más limitada que una autorización para toda la zona LAN. Sin embargo, una excepción de aceptación adicional no restringe una autorización de zona ya activa; para un diseño realmente limitado, la autorización amplia debe permanecer desactivada. Device Access y Local Service ACL explica la configuración completa.

El acceso al Web Proxy tiene un efecto secundario importante: Un host autorizado puede alcanzar los servicios HTTP y HTTPS del firewall a través del proxy, aunque su zona no esté autorizada en la matriz normal de Local Service. Por eso se deben realizar pruebas negativas desde el host piloto contra WebAdmin, User Portal y otros destinos locales. Si esta exposición no es aceptable para el diseño de seguridad de la red, no se debe activar el diseño en producción.

En Web > General settings, se comprueban el Web proxy listening port real y los puertos de destino permitidos. Solo se debe cambiar el valor predeterminado 3128 si es posible adaptar de forma coherente el archivo PAC, la GPO y todas las aplicaciones administradas.

3. Crear el host multiusuario

Se crea un nuevo objeto de host en esta ruta:

Hosts and services > IP host > Add

Para el ejemplo se utilizan estos valores:

1. Name: RDS01
2. IP version: IPv4
3. Type: IP
4. IP address: 10.20.30.40

En la primera prueba no se debe introducir un rango completo ni una subred. De lo contrario, muchos sistemas podrían perder al mismo tiempo su autenticación anterior basada en IP. Después de validar cada host por separado, varios hosts aprobados pueden agruparse de forma controlada en un host group.

4. Activar Per-Connection AD SSO

Se accede a:

Authentication > Web authentication > Authentication settings for direct web proxy

A continuación:

1. Activar Use per-connection AD SSO authentication for multi-user hosts.
2. Añadir el objeto RDS01 en Multi-user hosts.
3. Guardar con Apply.

A partir de este momento, STAS, Captive Portal, Clientless User y AD SSO transparente dejan de estar disponibles para 10.20.30.40. Por tanto, el cambio debe realizarse en una ventana de mantenimiento y no debe utilizarse una sesión RDS existente como única prueba.

5. Distribuir Direct Web Proxy

El proxy del navegador o del sistema se configura mediante GPO, archivo PAC o aplicación administrada con este valor:

fw01.corp.example:3128

Kerberos requiere exactamente el FQDN que coincide con el SPN. Utilizar una dirección IP como destino del proxy, una forma abreviada que no se puede resolver u otro alias suele provocar un fallback a NTLM o una solicitud de credenciales. Las entradas de bypass deben mantenerse deliberadamente reducidas y documentarse, ya que cada conexión omitida no recibe una identidad Per-Connection.

La configuración general de listener, PAC, regla y reversión se explica en Configurar Direct Web Proxy con un archivo PAC. Este artículo añade únicamente la autenticación multiusuario.

6. Colocar una regla de firewall específica

En Rules and policies > Firewall rules, se crea una regla de salida independiente y con un nombre claro para RDS01. Debe situarse antes de las reglas que incluyan el mismo host con Match known users.

El marco seguro es el siguiente:

• Source zones: zona RDS real, por ejemplo LAN
• Source networks and devices: solo RDS01
• Destination zones: WAN
• Destination networks: solo los destinos necesarios o, de forma consciente, Any
• Services: un servicio TCP propio para 3128 o para el proxy listening port configurado realmente; Any solo de forma consciente
• Log firewall traffic: activado
• Match known users: desactivado
• Web filtering > Web policy: seleccionar la política preparada dependiente del usuario o grupo

Las Web Policies pueden distinguir usuarios y grupos dentro del tráfico proxy, pero solo tienen efecto cuando se asignan a la regla de firewall. Esta diferenciación debe configurarse en la Web Policy, no en Match known users de esta regla de host. Después de seleccionar o modificar la Web Policy, se debe volver a comprobar el interruptor, ya que una dependencia de usuario puede volver a activarlo.

Para DNS, actualizaciones y otras conexiones necesarias sin proxy, se crea una regla de máquina independiente. No se debe añadir una regla general de WAN a LAN; el ejemplo inbound mostrado por Sophos no es necesario para el acceso web RDS normal y, sin una finalidad de publicación propia, supondría una superficie de ataque innecesaria. Crear correctamente reglas de firewall explica la estructura, el orden y el registro.

Validar con dos usuarios RDS

Una única solicitud correcta del navegador solo demuestra que funciona algún tráfico proxy. La validación real requiere dos sesiones paralelas.

1. Asignar dos cuentas piloto de AD a grupos de Web Policy diferentes.
2. Abrir dos nuevas sesiones RDS en RDS01.
3. Comprobar la configuración efectiva del proxy en ambas sesiones.
4. Generar una solicitud permitida y otra solicitud HTTP o HTTPS que se evalúe deliberadamente de forma distinta.
5. En Current activities > Live users, comprobar ambos usuarios con Client Type Multi-host client.
6. En Log viewer > Authentication, comprobar el usuario y Log Comp para Kerberos o NTLM.
7. Comparar en los registros web y de firewall el usuario, la policy, el Rule ID, la acción y la hora.
8. Generar una prueba necesaria sin proxy y confirmar que no recibe por error una identidad de usuario.
9. Desde el host piloto, registrar qué servicios HTTP y HTTPS locales del firewall son accesibles a través del proxy. Si se puede acceder a un servicio no permitido por el diseño de seguridad, se debe detener el despliegue y continuar solo después de demostrar una medida de protección adicional.

Solo se deben añadir más hosts RDS cuando ambos usuarios se distingan correctamente al mismo tiempo, se obtengan los resultados previstos de Web Policy y se comprenda la ruta sin proxy. Probar de forma controlada las reglas de Sophos Firewall ayuda con la validación general de reglas.

Solución de problemas

No se puede acceder al proxy

Se comprueban la resolución del FQDN, el puerto, el resultado del archivo PAC o de la GPO, la zona de origen y las autorizaciones Web proxy y AD SSO. Una prueba correcta del servidor AD no demuestra el acceso al proxy. Con rutas SD-WAN, el puerto del proxy o Any debe coincidir con el servicio; el firewall crea por sí mismo la conexión proxy externa, por lo que no se aplican todas las características del cliente como en el tráfico enrutado normal.

El navegador solicita credenciales o utiliza NTLM

Se comprueban el destino del proxy, DNS, el HTTP SPN, la zona del navegador y la autenticación integrada. Kerberos necesita el FQDN correspondiente, no la IP del firewall. El fallback a NTLM es un síntoma que debe explicarse primero, no un motivo para desplegar preventivamente solo NTLM.

Ambas sesiones aparecen como el mismo usuario

Se debe comprobar si ambos navegadores utilizan realmente el proxy explícito y si alguna aplicación crea conexiones fuera de la sesión de usuario correspondiente. Un proxy anterior o NAT también puede modificar el modelo de conexión previsto. En Live Users debe aparecer el tipo Multi-host client; una asignación normal basada en IP es la ruta equivocada para este host.

El usuario aparece, pero no se aplica la Web Policy

Se comprueban conjuntamente el grupo AD, Main Group, el orden de la Web Policy, la regla de firewall y la entrada de registro. Match known users debe permanecer desactivado en la regla de host específica. Una autenticación visible no demuestra que la solicitud utilice la Web Policy o el Firewall Rule ID esperados.

El tráfico que no es web no muestra ningún usuario

Es el comportamiento esperado. Per-Connection AD SSO solo identifica HTTP y HTTPS a través de Direct Web Proxy. El tráfico de máquina necesario utiliza una regla sin referencia al usuario. Si RDP, SMB, bases de datos u otro tráfico sin proxy debe distinguirse por sesión, se debe cambiar a SATC.

SSO deja de funcionar después de una actualización o un failover de HA

AD SSO puede requerir un nuevo Domain Join después de una actualización, al utilizar varios servidores AD o en HA. Por eso, la cuenta de join delegada debe seguir siendo válida. Después de un failover controlado se prueba con una nueva conexión proxy y con ambas cuentas piloto; no se debe presuponer que las conexiones proxy o los tickets Kerberos existentes continúan sin interrupción. En cualquier modo HA, cada nodo solo guarda los registros del tráfico que ha procesado. Por tanto, hay que comprobar el nodo que estaba activo o procesaba el tráfico en el momento del evento.

Leer los registros relevantes

En Advanced Shell son relevantes estos archivos:

cd /log
tail -n 200 nasm.log
tail -n 200 access_server.log
tail -n 200 awarrenhttp.log

nasm.log muestra problemas de NTLM, Kerberos y posibles errores de KVNO. access_server.log ayuda con la autenticación y autorización, y awarrenhttp.log con Web Proxy. awarrenhttp_access.log solo se crea con el debug activado temporalmente y no forma parte del primer paso normal. Antes de reiniciar servicios o ampliar el debug, se deben guardar primero el intervalo temporal, el usuario, el destino, la regla y los registros existentes.

Rollback

Un rollback limpio restablece no solo el proxy, sino también el modelo de autenticación anterior.

1. Documentar la lista multiusuario actual, las excepciones de Device Access, las reglas, la Web Policy y la distribución del proxy.
2. Eliminar RDS01 de Multi-user hosts y guardar con Apply.
3. Revertir de forma controlada la GPO del proxy, el archivo PAC o la configuración de la aplicación.
4. Restablecer la asignación anterior de STAS, Clientless o Captive Portal solo si se documentó previamente y es adecuada para esta IP.
5. Después de comprobar otras dependencias, eliminar la excepción ACL piloto o los permisos temporales de zona de AD SSO y Web Proxy, o devolverlos exactamente al estado anterior.
6. Desactivar o eliminar las reglas específicas de host y máquina en cuanto se confirme la ruta de sustitución.
7. Volver a probar con nuevas sesiones de navegador y RDS y, en HA, en ambos roles operativos.

Lista de comprobación

• Per-Connection AD SSO solo está previsto para tráfico HTTP y HTTPS enviado a través de un proxy explícito.
• El host piloto tiene una IP fija y única, sin otros sistemas detrás.
• Se han comprobado AD, los grupos, Domain Join, FQDN, DNS, SPN y la hora.
• AD SSO y Web Proxy solo están permitidos para la ruta de origen necesaria.
• Los navegadores y las aplicaciones utilizan fw01.corp.example:3128 o los valores equivalentes del entorno.
• La regla de host específica tiene el registro activado y Match known users desactivado.
• El tráfico sin proxy se ha planificado como tráfico de máquina o se ha cambiado el diseño a SATC.
• Se han realizado pruebas positivas y negativas con dos usuarios paralelos, políticas distintas y el acceso de administración.
• El failover de HA y las actualizaciones disponen de un proceso documentado de rejoin y nuevas pruebas.
• Se ha documentado el rollback de la lista multiusuario, la distribución del proxy, Device Access, las reglas y la autenticación anterior.

Preguntas frecuentes