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.

La función no se limita a Windows RDS: un servidor Linux multiusuario también puede utilizar este modelo de conexión, siempre que sus clientes admitan Direct Web Proxy y Kerberos o NTLM. Este ejemplo explica una prueba piloto con Windows RDS; los comandos de Windows y la distribución mediante GPO no constituyen una guía para Linux. Los hosts que no figuran en la lista Multi-user hosts conservan la autenticación basada en IP que ya tenían configurada.

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 realmente solo se necesita procesar por usuario HTTP y HTTPS a través de un proxy explícito.
2. Comprobar Active Directory, la importación de grupos, DNS, la hora y la unión de la firewall al dominio.
3. Preparar un FQDN de la firewall que se pueda resolver y un HTTP-SPN adecuado para Kerberos.
4. Evaluar primero el alcance y el impacto de seguridad; después activar AD SSO para la zona LAN necesaria en Administration > Device access y pulsar Apply. Limitar por separado Web proxy al host piloto con una excepción ACL específica, si se admite; una excepción de aceptación no restringe permisos de zona. Si el permiso necesario no es aceptable, detener el despliegue y obtener un diseño compatible de alcance limitado.
5. Crear el servidor RDS como un objeto de host con su IP exacta.
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 de la firewall y el puerto 3128.
8. Colocar una regla específica del host, con registro activado, antes de las reglas de usuario que puedan entrar en conflicto y mantener Match known users desactivado.
9. Comprobar por separado dos sesiones RDS simultáneas, resultados diferentes 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 necesidades distintas.

• STAS es adecuado para clientes Windows convencionales cuando una IP de cliente suele corresponder a un solo usuario. La firewall recibe una asociació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 las conexiones HTTP y HTTPS que pasan por un proxy explícito. 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 Windows RDS compatibles cuando otros tipos de conexión de las sesiones de usuario también necesitan una identidad. Para ello, se requiere Sophos Server Protection en el Session Host. La documentación actual de Sophos no respalda un nuevo despliegue de Citrix; antes de modificar instalaciones de Citrix existentes, conviene consultarlo con Sophos Support.

El STAS clásico en Sophos Firewall no puede distinguir varios usuarios detrás de la misma IP RDS. Por tanto, Per-Connection AD SSO y SATC no son variantes más cómodas de STAS, sino modelos de funcionamiento propios. SATC también asigna identidades únicamente a procesos de usuario; las conexiones generadas por servicios del sistema siguen necesitando una regla específica sin Match known users. Si una aplicación no admite un proxy explícito o es necesario regular protocolos no web por usuario, detenerse aquí y evaluar SATC.

Ejemplo y valores que deben sustituirse

El procedimiento utiliza este ejemplo:

• Host multiusuario: RDS01
• Dirección IP: 10.20.30.40
• FQDN de la 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

10.20.30.40 debe sustituirse por la IP fija del servidor piloto que ve la 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 de la firewall, resoluble internamente. La parte correspondiente al host debe tener como máximo 15 caracteres y estar en minúsculas, para que coincidan el nombre de host, el nombre NetBIOS, el objeto de equipo de AD y el SPN.

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

Preparar los requisitos previos

Comprobar Active Directory y la unión al dominio

La firewall necesita un servidor de Active Directory operativo, grupos importados y una unión al dominio completada correctamente. 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.

Si el servidor de AD aún no está configurado, seleccionar el tipo Active Directory en Authentication > Servers > Add. Introducir el nombre del servidor, la IP o el FQDN accesible del DC, el dominio NetBIOS, el dominio de AD y la base de búsqueda del entorno. Para corp.example, la base de búsqueda es dc=corp,dc=example. Cifrar la conexión mediante SSL/TLS en el puerto 636 o STARTTLS en el puerto 389 y preparar la comprobación del certificado según el procedimiento de AD enlazado. Configurar la cuenta de lectura/unión con los permisos descritos más abajo, ejecutar Test connection y guardar con Save. No sustituir un servidor de AD ya utilizado solo para la prueba piloto ni cambiar sus credenciales sin comprobarlas. Si el dominio exige enlace de canal LDAP estricto o firma LDAP, aclarar la compatibilidad en el procedimiento de AD antes del despliegue; la ayuda de Sophos para servidores de AD indica una limitación al respecto. No desactivar un requisito de protección de todo el dominio para solucionar un problema.

Al importar grupos, seleccionar una unidad organizativa (OU) selecciona automáticamente todos los grupos que contiene. Attach to all the Groups asigna las políticas comunes seleccionadas a cada grupo importado por el asistente. Por tanto, antes de finalizar, revisar la lista de grupos ampliada por la selección de la OU y el ámbito de esas políticas; aceptar únicamente los grupos realmente necesarios y las asignaciones de políticas previstas.

Para la prueba piloto, abrir Import en el servidor de AD bajo Authentication > Servers > Manage, iniciar el Import group wizard con Start y seleccionar la Base DN adecuada. Para el dominio de ejemplo corp.example, es dc=corp,dc=example; se sustituyen los componentes del dominio, no la sintaxis LDAP. Seleccionar RDS-Web-Standard y RDS-Web-Restricted, revisar la asignación de políticas comunes y el resumen, finalizar el asistente y cerrarlo con Close. Después, comprobar en Authentication > Groups que ambos grupos estén realmente presentes. Una unión al dominio correcta, por sí sola, no importa los grupos necesarios para las políticas.

Para las consultas LDAP habituales basta con una cuenta con permisos de lectura. En cambio, la unión al dominio y la creación del SPN requieren una cuenta de administrador de dominio o una cuenta con permisos correctamente delegados. La cuenta configurada también debe permitir una futura nueva unión al dominio, ya que HA, servidores de AD adicionales o actualizaciones pueden volver a desencadenarla. No conviene utilizar permanentemente una cuenta de administrador de dominio sin restricciones si no es necesario.

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

En la misma sección, seleccionar conscientemente la Default group y guardar con Apply. Si el grupo de AD necesario no está importado, un usuario autenticado correctamente puede terminar en el grupo predeterminado en lugar de recibir la política del grupo deseado. Los usuarios de una OU que no pertenecen a ningún grupo del directorio pueden aparecer en la Open group. Si un usuario pertenece a varios grupos, el primer grupo coincidente puede determinar la política; por ello, comprobar no solo la importación, sino también el orden y la asignación real. Para la prueba piloto, no utilizar un grupo predeterminado con permisos amplios como sustituto de una importación pendiente. En el primer inicio de sesión nuevo, comprobar la asignación real de grupo en Authentication > Users; no es necesario que el objeto de usuario sea visible antes de ese inicio de sesión.

Comprobar FQDN, DNS, SPN y hora

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

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

El HTTP-SPN, cuyo nombre completo es Service Principal Name, vincula el FQDN del proxy al objeto de equipo de AD de la firewall. setspn -Q debe devolver exactamente una asociación coincidente. Si no hay resultados o hay varios, debe aclararse antes del despliegue.

El sufijo DNS configurado en el campo de nombre de host no es automáticamente el sufijo de AD: al unirse al dominio, la firewall forma el nombre de equipo de AD y el SPN a partir de su nombre NetBIOS y del dominio de AD. Si el dominio DNS y el dominio de AD son distintos, comparar el FQDN registrado en el objeto de equipo de AD con el destino de proxy previsto. El ejemplo presupone un SPN adecuado para fw01.corp.example; introducir ese nombre en Admin and user settings no lo demuestra por sí solo. Primero comprobar conjuntamente DNS y SPN para el destino real del proxy y después distribuir la configuración del proxy. No crear SPN adicionales por simple suposición.

La respuesta DNS debe corresponder a la firewall prevista. Además, el cliente, el controlador de dominio y la firewall necesitan una hora compatible con el funcionamiento de Kerberos. Los comandos no modifican nada. No corregir el SPN, la unión al dominio ni la configuración horaria por simple suposición; primero demostrar cuál es el error real.

Identificar la compatibilidad con proxy y las excepciones

Cada navegador y aplicación cuyo tráfico web deba recibir una identidad de usuario debe utilizar el proxy explícito y admitir Kerberos o NTLM; en el ejemplo de Windows RDS, esto se realiza mediante autenticación integrada de Windows. Antes del despliegue, comprobar como mínimo:

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

El tráfico que evita el proxy permanece sin ID de usuario, como cabe esperar. Para las conexiones de máquina necesarias, planificar una regla específica, estrictamente limitada y sin asociación a usuarios. Una regla amplia con Any debilitaría el efecto de seguridad de las políticas de usuario y web.

Configurar Per-Connection AD SSO

1. Preparar el FQDN de la firewall y AD SSO

En Administration > Admin and user settings, introducir el FQDN previsto de la firewall y guardar con Apply. Después, en Authentication > Web authentication, seleccionar Kerberos & NTLM bajo If Active Directory (AD) SSO is configured y guardar también con Apply. NTLM está técnicamente admitido como alternativa; Kerberos es más rápido y seguro y debe funcionar de forma fiable durante la prueba piloto. Como cada conexión al proxy puede desencadenar una autenticación, antes de un despliegue más amplio también conviene observar los errores de inicio de sesión, los tiempos de respuesta y la carga de la firewall y de AD con tráfico representativo. No deducir de ello un multiplicador fijo de carga ni una capacidad de usuarios garantizada.

Si los dispositivos no están correctamente configurados para Kerberos o el navegador no admite autenticación Kerberos, se utiliza automáticamente NTLMv2 como alternativa. A diferencia de Kerberos, NTLMv2 no necesita un FQDN como destino del proxy. Sin embargo, esta alternativa de compatibilidad no garantiza que el inicio de sesión funcione: los canales de autenticación descritos a continuación deben estar inicializados y la ruta real de inicio de sesión debe comprobarse con las cuentas piloto.

En Log Viewer, bajo Authentication, deben aparecer estos mensajes de éxito después de la inicialización de AD SSO:

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

La firewall solo ofrece estos 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 los permisos de Device Access

Sophos exige activar AD SSO para la zona LAN necesaria en Administration > Device access y pulsar Apply como requisito para Kerberos/NTLM. Antes, evaluar el alcance del permiso de zona y su impacto de seguridad; no abrir toda la LAN sin esa revisión. Desactivar AD SSO en todas las zonas impide Kerberos/NTLM, y una excepción ACL de AD SSO limitada a un host no sustituye este requisito. Añadir una excepción de aceptación tampoco restringe un permiso de zona existente. Si el permiso necesario no es aceptable, detener el despliegue y obtener del responsable de las ACL o de Sophos Support un diseño compatible y de alcance limitado para la compilación instalada. Por separado, limitar la accesibilidad de Web proxy desde el origen al host piloto mediante una Local service ACL exception rule específica, si se admite. Una excepción de aceptación no restringe un permiso de Web proxy ya activo para toda la zona; ese permiso amplio no debe mantenerse para un acceso realmente limitado al host. No habilitar otras zonas ni servicios innecesarios. Device Access y Local Service ACL explica la configuración completa.

El acceso al proxy web tiene un efecto secundario importante: un host autorizado puede acceder a los servicios HTTP y HTTPS de la firewall a través del proxy, aunque su zona no esté autorizada en la matriz habitual de servicios locales. Por tanto, realizar pruebas negativas de acceso a WebAdmin, User Portal y otros destinos locales desde el host piloto. Si esta exposición no es aceptable en la red, no activar el diseño en producción.

En Web > General settings, comprobar el Web proxy listening port real y los puertos de destino permitidos. Cambiar el valor predeterminado 3128 solo si es posible ajustar de forma coherente el archivo PAC, la GPO y todas las aplicaciones administradas.

3. Crear el host multiusuario

Crear un nuevo objeto de host en la siguiente 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

Guardar con Save y comprobar que el objeto contiene la IP exacta del piloto antes de seleccionarlo en la lista de hosts multiusuario.

Para la primera prueba, no introducir un rango completo ni una subred. De lo contrario, muchos sistemas podrían perder simultáneamente su autenticación basada en IP anterior. Una vez validado cada host individualmente, los hosts adicionales autorizados pueden agruparse de forma controlada en un grupo de hosts.

4. Activar Per-Connection AD SSO

Ir a esta sección:

Authentication > Web authentication > Authentication settings for direct web proxy

Después:

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

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

Correspondencia opcional con la API para la automatización

Quien desee automatizar este paso de la interfaz gráfica encontrará la entidad DirectWebProxyAuthentication en la referencia de la API para SFOS 22.0 y 23.0. Esta entidad establece la siguiente correspondencia con el interruptor y la lista de hosts multiusuario; esta correspondencia no constituye una solicitud completa y ejecutable.

• DirectWebProxyAuthentication > PerConnectionAuth corresponde al interruptor de activación y desactivación de Per-Connection AD SSO. El parámetro está documentado como un SCALAR no obligatorio y solo admite Enable o Disable. La notación con barra del ejemplo de la referencia indica alternativas, no un tercer valor permitido.
• DirectWebProxyAuthentication > MultiUserHosts > Host describe la lista de nombres de hosts multiusuario, es decir, en el ejemplo, el nombre del objeto de host RDS01 creado anteriormente, no su dirección IP. Host no es obligatorio y está documentado como un ARRAY con el tipo de datos STRING. Se permiten varios valores y, según la referencia, se ignoran los valores duplicados. La referencia indica un máximo de 1500 caracteres, pero no aclara si este límite se aplica a cada valor o a la lista completa.

Las columnas de valores predeterminados están vacías: de ello no se deriva ningún valor predeterminado documentado ni ninguna indicación sobre el efecto de omitir campos. La sección de la operación tampoco describe si una lista enviada añade entradas a las existentes o las sustituye, ni cómo se eliminan las entradas. Por tanto, no interpretar ni la omisión ni una lista vacía como una vía segura de reversión; antes de automatizar, deben aclararse los comportamientos concretos de actualización y eliminación para la compilación utilizada.

La tabla de estados contiene 200 y 500. Estos valores de referencia no garantizan un estado HTTP concreto ni confirman que usuarios y políticas se hayan procesado correctamente. Los campos de mensajes remiten a JavaScript; la sección de la operación disponible no proporciona mensajes de respuesta literales.

Los requisitos previos indicados arriba y la prueba piloto de alcance limitado a un único host también se aplican a cualquier cambio posterior autorizado mediante la API. Antes del cambio, guardar de forma segura los ajustes reales y disponer de un acceso de administración independiente. Después, volver a consultar el interruptor y la lista completa de hosts multiusuario en la firewall exacta que se haya modificado y compararlos con el estado previsto; a continuación, realizar las pruebas positivas y negativas de proxy, usuarios, políticas, tráfico sin proxy y servicios locales descritas más abajo. Una respuesta de aceptación de la configuración no sustituye esta validación. Para la reversión, restaurar el estado anterior guardado, sin deducir de ello una sintaxis de eliminación mediante la API que no esté respaldada.

5. Distribuir Direct Web Proxy

Configurar el proxy del navegador o del sistema mediante GPO, archivo PAC o aplicación administrada con este valor:

fw01.corp.example:3128

Para Kerberos debe utilizarse exactamente el FQDN que coincida con el SPN. Una dirección IP como destino del proxy, un nombre corto que no se pueda resolver u otro alias suelen provocar el uso de NTLM como alternativa o una solicitud de credenciales. Mantener deliberadamente reducida la lista de exclusiones y documentarla, ya que cada conexión que evita el proxy no recibe una identidad Per-Connection.

La configuración general del listener, PAC, reglas y reversión se encuentra en Configurar Direct Web Proxy con un archivo PAC. Este artículo solo complementa esa configuración con la autenticación multiusuario.

6. Colocar una regla de firewall específica

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

Para este ejemplo de IPv4, seleccionar IPv4 > Add firewall rule > New firewall rule. Establecer, por ejemplo, RDS01_DirectProxy_Outbound como Rule name y Accept como Action. El nombre es de libre elección; debe permitir identificar el host y la finalidad. Comprobar su posición antes de las reglas de usuario que puedan entrar en conflicto consultando la lista completa de reglas, no solo el nombre.

El marco seguro:

• Source zones: la zona real de RDS, por ejemplo LAN
• Source networks and devices: solo RDS01
• Destination zones: WAN
• Destination networks: solo los destinos necesarios o, de forma deliberada, Any
• Services: HTTP, HTTPS y un servicio TCP específico para 3128 o para el puerto de escucha del proxy realmente configurado; utilizar Any solo de forma deliberada. Seleccionar únicamente el puerto de escucha no constituye una selección completa de servicios para Direct Web Proxy.
• Log firewall traffic: activado
• Match known users: desactivado
• Web filtering > Web policy: seleccionar la política preparada que depende de usuarios o grupos

Las Web Policies pueden distinguir usuarios y grupos dentro del tráfico del proxy, pero solo surten efecto cuando están asignadas a la regla de firewall. Esta distinció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, volver a comprobar el interruptor, ya que una dependencia de usuarios puede activarlo de nuevo.

Guardar con Save, volver a abrir la regla y comprobar Match known users, el registro, la Web Policy y la posición. La regla de host permite la ruta de tráfico prevista; la Web Policy decide sobre usuarios y grupos dentro de esa ruta. Por tanto, una identidad reconocida correctamente no implica automáticamente los permisos correctos.

La guía general de AD SSO también describe reglas de usuario con Match known users activado. Ese no es el modelo de reglas para la IP multiusuario registrada aquí: la guía específica de Per-Connection exige expresamente una regla propia con este interruptor desactivado. Tampoco copiar la selección de servicios de una regla HTTP/HTTPS transparente: el puerto de escucha del proxy describe la ruta del cliente al proxy, mientras que una conexión separada del proxy al destino utiliza servicios de destino como HTTP o HTTPS. Confirmar la Rule ID real y el puerto correspondiente durante la prueba piloto mediante los registros. Un cliente IPv6 con un destino IPv4 puede necesitar dos reglas; este ejemplo de IPv4 no constituye una guía completa de doble pila.

Para DNS, actualizaciones y otras conexiones necesarias sin proxy, crear una regla de máquina separada. No añadir una regla general de WAN a LAN; el ejemplo de entrada mostrado por Sophos no es necesario para el acceso web habitual de RDS y supondría una superficie de ataque innecesaria si no existe un propósito específico de publicación. Crear correctamente reglas de firewall explica la configuración, el orden y el registro.

Si existe una necesidad justificada de acceso entrante al host multiusuario, independiente del proxy, Match known users también debe permanecer desactivado en su regla específica. Definir de forma restrictiva la zona de origen y los hosts de origen autorizados, la zona de destino y RDS01, así como los servicios realmente necesarios; activar el registro y comprobar la posición antes de las reglas de usuario que puedan entrar en conflicto. Esto no es una invitación a exponer RDP públicamente; para el acceso web habitual no se crea ninguna regla de entrada nueva.

Validar con dos usuarios RDS

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

1. Asignar dos cuentas piloto de AD a grupos con Web Policies diferentes.
2. Abrir dos sesiones RDS nuevas en RDS01.
3. Comprobar la configuración efectiva del proxy en ambas sesiones.
4. Realizar en cada una una solicitud HTTP o HTTPS permitida y otra con un resultado deliberadamente distinto.
5. Comprobar ambos usuarios en Current activities > Live users con Client Type Multi-host client.
6. Comprobar el usuario y Log Comp para Kerberos o NTLM en Log viewer > Authentication.
7. Comparar usuario, política, Rule ID, acción y hora en los registros web y de firewall.
8. Realizar una prueba necesaria sin proxy y confirmar que no recibe erróneamente una identidad de usuario.
9. Identificar desde el host piloto qué servicios locales HTTP y HTTPS de la firewall son accesibles a través del proxy. Si se puede acceder a un servicio no permitido por el diseño de seguridad, detener el despliegue y continuar solo cuando se haya demostrado una medida de protección adicional.

Una comparación significativa utiliza el mismo destino de prueba autorizado en ambas sesiones: una cuenta de RDS-Web-Standard puede abrirlo, mientras que otra de RDS-Web-Restricted queda bloqueada por la Web Policy preparada. Registrar fecha, hora, usuario, IP de origen, Rule ID, política y resultado. Después, acceder a un destino de control que ambos grupos puedan utilizar. Así se distingue una restricción de grupo intencionada de un fallo general del proxy o de DNS. Los destinos de prueba deben proceder de la lista de pruebas autorizada del entorno; no bloquear una página de negocio en producción solo para realizar la validación.

Añadir más hosts RDS únicamente cuando ambos usuarios se distingan correctamente al mismo tiempo, se obtengan los resultados previstos de Web Policy y se comprenda la ruta sin proxy. Para la validación general de las reglas, resulta útil Probar de forma controlada las reglas de Sophos Firewall.

Solución de problemas

No se puede acceder al proxy

Comprobar la resolución del FQDN, el puerto, el resultado de PAC/GPO, la zona de origen y los permisos Web proxy y AD SSO. Una prueba correcta del servidor de AD no demuestra que se pueda acceder al proxy. En las rutas SD-WAN, el puerto del proxy o Any debe coincidir con la selección de servicios; la propia firewall genera la conexión externa del proxy, 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

Comprobar el destino del proxy, DNS, el HTTP-SPN, la zona del navegador y la autenticación integrada. Kerberos necesita el FQDN adecuado, no la IP de la firewall. El uso de NTLM como alternativa es un síntoma cuya causa debe aclararse primero, no un motivo para realizar preventivamente un despliegue solo con NTLM.

Ambas sesiones aparecen como el mismo usuario

Comprobar si ambos navegadores utilizan realmente el proxy explícito y si alguna aplicación genera conexiones fuera de la sesión de usuario correspondiente. Un proxy intermedio o NAT también puede alterar el modelo de conexión deseado. En Live Users debe aparecer el tipo Multi-host client; una asociación normal basada en IP es una ruta incorrecta para este host.

El usuario es visible, pero la Web Policy no se aplica

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

Si el usuario piloto aparece en la Default group en lugar de en el grupo de AD importado esperado, comprobar primero Authentication > Groups, la base de búsqueda y la importación de grupos. No asignar una política más amplia al grupo predeterminado para ocultar el error. Después de una corrección controlada, comprobar con un nuevo inicio de sesión que la asignación y ambas pruebas de políticas sean correctas.

El tráfico no 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 asociación a usuarios. Si es necesario distinguir por sesión RDP, SMB, conexiones de base de datos u otro tráfico sin proxy, cambiar a SATC.

SSO deja de funcionar después de una actualización o una conmutación por error de HA

AD SSO puede necesitar una nueva unión al dominio después de una actualización, al utilizar varios servidores de AD o en HA. Por tanto, la cuenta con permisos delegados para la unión debe seguir siendo válida. Después de una conmutación por error controlada, realizar pruebas con una nueva conexión al proxy y ambas cuentas piloto; no asumir que las conexiones de proxy existentes o los tickets Kerberos continúan sin interrupciones. En cualquier modo de HA, cada nodo almacena únicamente los registros del tráfico que ha procesado. Por ello, para un evento hay que comprobar el nodo que estaba activo o que procesaba el tráfico en ese momento.

Si se actualiza directamente desde SFOS 21.5 o una versión anterior a SFOS 22.0 GA Build 411, también puede ser relevante el problema conocido NC-176853: AD SSO con NTLM y Kerberos puede fallar inmediatamente después de la actualización, de modo que las políticas basadas en identidad no coincidan. Sophos indica SFOS 22.0 MR1 Build 490 como versión que corrige el problema. El procedimiento interno para KBA-000048429 describe el diagnóstico y la solución temporal. La Known Issues List no menciona Per-Connection AD SSO por separado; por tanto, este hallazgo solo es relevante si la ruta de AD SSO subyacente falla después de esa actualización concreta. Conservar la compilación de firmware, la hora y los registros, consultar la KBA para la compilación afectada y no eludir el problema con reglas amplias ni cambiando el método de autenticación.

Consultar los registros relevantes

En Advanced Shell, estos archivos son relevantes:

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 problemas de KVNO. access_server.log ayuda con la autenticación y la autorización, y awarrenhttp.log con el proxy web. awarrenhttp_access.log solo se genera con la depuración activada temporalmente y no forma parte del primer paso habitual. Antes de reiniciar servicios o ampliar la depuración, conservar primero el intervalo temporal, el usuario, el destino, la regla y los registros existentes.

Reversión

Una reversión correcta no solo restablece el proxy, sino también el modelo de autenticación anterior.

1. Documentar la lista actual de hosts multiusuario, 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 asociación anterior de STAS, Clientless o Captive Portal únicamente si estaba documentada y era adecuada para esta IP.
5. Tras comprobar otras dependencias, eliminar la excepción ACL del piloto o los permisos temporales de zona para AD SSO y Web Proxy, o restablecerlos exactamente a su estado anterior.
6. Desactivar o eliminar las reglas específicas de host y de máquina en cuanto se confirme la ruta alternativa.
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 está previsto únicamente para tráfico HTTP/HTTPS 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, la unión al dominio, FQDN, DNS, SPN y la hora.
• Requisito de zona de AD SSO e impacto de seguridad revisados; zona LAN necesaria activada y Apply aplicado, con acceso a Web proxy limitado por separado al host piloto y sin permiso amplio del proxy. Si el permiso de zona no es aceptable, detener el despliegue y obtener un diseño compatible de alcance limitado.
• Los navegadores y las aplicaciones utilizan fw01.corp.example:3128 o los valores que lo sustituyen en el entorno.
• La regla específica del host tiene el registro activado y Match known users desactivado.
• El tráfico sin proxy se ha planificado como tráfico de máquina o el diseño se ha cambiado a SATC.
• Se han realizado pruebas positivas y negativas con dos usuarios simultáneos, políticas diferentes y acceso de administración.
• La conmutación por error de HA y las actualizaciones cuentan con un procedimiento documentado de nueva unión al dominio y repetición de pruebas.
• Está documentada la reversión de la lista de hosts multiusuario, la distribución del proxy, Device Access, las reglas y la autenticación anterior.

Preguntas frecuentes