Configurar Sophos Firewall SATC para Remote Desktop Services
Sophos Authentication for Thin Client, abreviado SATC, ayuda con las reglas de usuario en Remote Desktop Services. Esto es importante cuando varios usuarios acceden a la red o a Internet a través del mismo Windows Remote Desktop Session Host. En estos casos, el STAS clásico suele ver solo la dirección IP del servidor de terminales. SATC, en cambio, entrega a Sophos Firewall información de usuario de las distintas sesiones RDS.
Este artículo explica cuándo SATC tiene sentido, qué límites existen, cómo activarlo mediante Sophos Server Protection y cómo comprobar después si los usuarios aparecen correctamente en Sophos Firewall.
Para clientes Windows normales, primero es relevante configurar STAS en Sophos Firewall. SATC no sustituye a STAS en todos los entornos, sino que es el componente adecuado para Remote Desktop Services.
Cuándo SATC tiene sentido
SATC encaja cuando los usuarios no pasan por la firewall directamente desde su propio cliente, sino que usan aplicaciones o navegadores en un Remote Desktop Session Host.
Escenarios típicos:
- Remote Desktop Services con varios usuarios simultáneos
- servidores de terminales en los que los usuarios necesitan acceso web o acceso a aplicaciones
- reglas de firewall basadas en usuarios para usuarios RDS
- reporting en el que no debe verse solo la dirección IP del servidor RDS
- entornos en los que STAS no basta correctamente por una IP de origen compartida
SATC no es el punto de partida correcto para clientes de dominio normales, usuarios VPN o escenarios puros de Captive Portal. Ahí conviene elegir primero el modelo de autenticación adecuado: STAS, Captive Portal, autenticación VPN, RADIUS o Microsoft Entra ID SSO.
Separar claramente STAS y SATC
La diferencia más importante es la asignación de IP.
| Escenario | Enfoque adecuado |
|---|---|
| Un cliente Windows suele pertenecer a un usuario | STAS |
| Muchos usuarios comparten la misma IP de servidor RDS | SATC |
| Los usuarios inician sesión en el navegador para que apliquen reglas | Captive Portal |
| Los usuarios entran por Remote Access VPN | autenticación VPN o Entra ID SSO |
| El tráfico pasa por servidores técnicos sin referencia de usuario | reglas de firewall normales sin usuario |
Si un servidor de terminales se representa erróneamente mediante STAS o Clientless User, surgen rápidamente expectativas equivocadas. Una regla parece estar basada en usuarios, pero en realidad la firewall solo ve una IP de servidor compartida. SATC resuelve exactamente este problema, pero necesita una configuración propia en el Windows Server y en la firewall.
Requisitos
Antes de la configuración deberían aclararse estos puntos:
- Sophos Server Protection puede usarse en el Remote Desktop Session Host.
- El Windows Server funciona como Remote Desktop Session Host.
- Se usa Windows Server 2016 o posterior.
- La Sophos Firewall es accesible.
- Active Directory está conectado en Sophos Firewall.
- Los grupos AD necesarios están importados en la firewall.
Client Authenticationestá permitido en Device Access para la zona del servidor RDS.- Las reglas de firewall podrán trabajar después con Match known users.
- Existe una ventana de mantenimiento para el cambio de Registry y el reinicio del servidor RDS.
La conexión AD en sí no debería crearse de paso. Si AD todavía no está configurado limpiamente, primero conviene revisar conectar Active Directory con Sophos Firewall.
Límites importantes
SATC tiene algunos límites que conviene conocer antes del rollout:
| Punto | Significado |
|---|---|
| SATC standalone | Ya no está soportado por Sophos Firewall. |
| Despliegue | SATC funciona mediante Sophos Server Protection o el Sophos Central Server Core Agent. |
| Plataforma | SATC con Sophos Server Protection está pensado para Windows Remote Desktop Services. |
| Límite de servidores | Sophos menciona hasta 192 Thin Client Servers en la firewall. |
| Autenticación por IP de servidor | Si una IP de servidor RDS está registrada en la firewall como Thin Client, SATC funciona como método de autenticación para esa IP. Otros métodos como Clientless User no aplican para esa IP. |
El último punto es especialmente importante. No conviene registrar IPs productivas de servidores de terminales solo para probar, sin entender las reglas y la ruta de retorno. En cuanto la IP se trata como fuente SATC, cambian las expectativas sobre asignación de usuarios y rule matching.
Resumen del procedimiento
El proceso técnico consta de cinco partes:
- Instalar Sophos Server Protection en el servidor RDS.
- Activar SATC mediante Registry en el servidor RDS.
- Registrar la IP del servidor RDS en la Device Console de Sophos Firewall.
- Revisar servidor AD, grupos y orden de autenticación en la firewall.
- Validar Device Access, regla de firewall y Live Users.
SATC no solo debe instalarse, sino también probarse. Una instalación correcta en el servidor no demuestra todavía que la firewall vaya a ver después el usuario correcto en la regla correcta.
Instalar Sophos Server Protection
La instalación se realiza mediante Sophos Central.
Procedimiento:
- Iniciar sesión en Sophos Central.
- Abrir Protect Devices.
- Descargar el Windows Server Installer bajo Server Protection.
- Instalar el installer en el Remote Desktop Session Host.
- Comprobar si el servidor aparece correctamente en Sophos Central.
- Definir una ventana de mantenimiento para la activación de SATC.
Los installers visibles dependen de las licencias Sophos disponibles. Si Sophos Server Protection ya se ejecuta en el servidor, aun así conviene comprobar si el agente está actualizado y si Tamper Protection puede desactivarse de forma controlada y volver a activarse después.
Activar SATC mediante Registry
SATC se controla en el servidor RDS mediante valores de Registry bajo esta ruta:
HKLM\Software\Sophos\Sophos Network Threat Protection\Application
Antes del cambio conviene documentar los ajustes actuales. Si Tamper Protection está activa en el servidor, debe desactivarse de forma controlada para el cambio y volver a activarse después.
La configuración básica puede definirse en un símbolo del sistema administrativo:
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SendSatcEvents /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationAddr /t REG_SZ /d FIREWALL-IP /f
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcDestinationPort /t REG_DWORD /d 6060 /f
FIREWALL-IP se sustituye por la dirección IP de Sophos Firewall a la que el servidor RDS debe enviar la información SATC. El puerto estándar es 6060.
Después:
- Volver a activar Tamper Protection.
- Reiniciar el servidor RDS.
- Tras el reinicio, comprobar si el servicio Sophos se está ejecutando.
- Solo después continuar con la configuración de firewall y las pruebas.
Excluir cuentas locales y destinos
Por defecto, cuentas locales como SYSTEM o Administrator también pueden generar eventos SATC. Esto normalmente no ayuda a las reglas de usuario y puede ensuciar los logs innecesariamente.
Con SatcExcludedUsers se pueden excluir usuarios. Las entradas son case-sensitive.
Ejemplo:
reg add "HKLM\Software\Sophos\Sophos Network Threat Protection\Application" /v SatcExcludedUsers /t REG_MULTI_SZ /d "SYSTEM\0Administrator" /f
Con SatcExcludedAddresses se pueden excluir destinos para los que no se deben enviar datos SATC a la firewall. Esto puede tener sentido para destinos locales de gestión, update o infraestructura, pero debería documentarse conscientemente.
Formatos posibles:
192.0.2.10
192.0.2.10:443
*:443
Las excepciones deberían mantenerse estrechas. Si se excluyen destinos demasiado amplios, la firewall verá después menos contexto de usuario del esperado.
Registrar el servidor RDS en la firewall
La firewall debe saber qué servidores entregan información SATC. Esto se hace en la Device Console, no en la Advanced Shell.
Procedimiento:
- Iniciar sesión en Sophos Firewall por consola o SSH.
- Abrir la opción
4. Device Console. - Añadir la IP del servidor RDS:
system auth thin-client add citrix-ip <RDS-SERVER-IP>
<RDS-SERVER-IP> se sustituye por la dirección IP del Remote Desktop Session Host.
Si existen varios servidores RDS, registrar cada servidor por separado y documentarlo. Después debería quedar claro:
- qué servidores cuentan como fuentes SATC
- qué zona usan estos servidores
- qué reglas de firewall evalúan usuarios de estos servidores
- quién aprueba cambios en la lista de servidores RDS
Revisar Active Directory y grupos
SATC entrega información de usuario. Para que la firewall pueda usar esta información en reglas, la conexión AD y los grupos deben ser correctos.
Revisar:
- Abrir Authentication > Servers.
- Comprobar el servidor AD con Test connection.
- Controlar la importación de grupos.
- Abrir Authentication > Groups.
- Buscar los grupos relevantes.
- Abrir Authentication > Services.
- Revisar el servidor AD en el orden correcto de los firewall authentication methods.
Si los usuarios aparecen en el área Live Users, pero las reglas no aplican, la causa a menudo no está en SATC, sino en la importación de grupos, el grupo predeterminado, el criterio de regla o la posición de la regla.
Configurar Device Access y regla de firewall
Para que la firewall acepte Client Authentication desde la zona del servidor, Client Authentication debe estar permitido para esa zona.
Ruta:
Administration > Device access
Bajo Client Authentication, activar la zona del servidor RDS. No se debería abrir a ciegas WAN ni una zona amplia e insegura. Device Access controla servicios locales de la firewall y forma parte del hardening de gestión.
Después, el tráfico real necesita una regla de firewall.
Procedimiento típico:
- Abrir Rules and policies > Firewall rules.
- Crear una regla adecuada para tráfico desde el servidor RDS o desde la zona de servidor.
- Definir Source zone y Destination zone correctamente.
- Activar Match known users.
- Seleccionar los usuarios AD o grupos AD necesarios.
- Activar logging para que la prueba sea trazable después.
- Guardar la regla.
- Generar tráfico de prueba desde una sesión RDS.
Para la resolución de problemas posterior, logging es importante. Si se crea una regla de usuario sin logging, resulta más difícil reconocer si el problema está en SATC, group matching, el orden de reglas u otra ruta.
Validación después de la configuración
Después de la configuración no conviene comprobar solo si un usuario tiene acceso a Internet. Lo decisivo es si la firewall ve el usuario correcto y hace match con la regla correcta.
Prueba práctica:
- Iniciar sesión con un usuario en una sesión RDS.
- Generar tráfico de prueba definido, por ejemplo una conexión HTTPS permitida.
- En Sophos Firewall, abrir Current activities > Live users.
- Comprobar si el usuario aparece con Client type
Thin client. - Controlar la dirección IP del servidor RDS y la asignación de sesión.
- Abrir Log Viewer.
- Filtrar por Source IP del servidor RDS, usuario y regla.
- Comprobar si aplica la regla esperada basada en usuario.
Si el tráfico no funciona como se espera, ayuda además probar una regla de firewall con Log Viewer, Policy Test y Packet Capture. Si los usuarios son visibles, pero los grupos o usuarios individuales no hacen match, la regla de Sophos Firewall no hace match encaja como siguiente ruta de revisión.
Troubleshooting
No aparece ningún usuario Thin Client
Revisar:
- el servidor RDS se reinició después del cambio de Registry.
SendSatcEventsestá definido y es distinto de0.SatcDestinationAddrapunta a la IP correcta de la firewall.SatcDestinationPortcoincide con el puerto esperado.- la ruta de red del servidor RDS a la firewall está abierta.
- la IP del servidor RDS se registró en la firewall mediante
system auth thin-client add citrix-ip. - la zona del servidor RDS permite Client Authentication bajo Device Access.
El usuario aparece, pero la regla no hace match
Revisar:
- el usuario o grupo está importado en la firewall.
- la regla usa Match known users.
- el grupo AD correcto está seleccionado en la regla.
- la posición de la regla es adecuada.
- no existe una regla anterior que haga match con el mismo tráfico sin referencia de usuario.
- Log Viewer muestra el mismo usuario, la misma Source IP y el mismo servicio.
Cuentas locales aparecen en los logs
Revisar SatcExcludedUsers y añadir cuentas técnicas. Candidatos habituales son administradores locales, servicios y cuentas de sistema. Pero la lista no debería hacerse tan amplia que se excluyan usuarios reales por error.
Algunos destinos no reciben contexto de usuario
Revisar SatcExcludedAddresses. Si se ha excluido un destino o puerto, SATC no envía información de autenticación a la firewall para ello. Esto puede ser intencionado, pero en reglas de usuario genera confusión fácilmente.
Tras registrar la IP del servidor, un Clientless User antiguo ya no aplica
Esto es esperable. Si la IP del servidor RDS se registró en la firewall como Thin Client Server, SATC debería ser el modelo de autenticación para esa IP. Los workarounds antiguos con Clientless Users deberían eliminarse o sustituirse conscientemente.
Operación y documentación
SATC debería operarse como un componente productivo de autenticación, no como un hack de Registry de una sola vez.
Documentar:
- servidores RDS y direcciones IP
- IP de firewall utilizada y puerto SATC
- valores de Registry definidos
- usuarios y destinos excluidos
- reglas de firewall afectadas
- grupos AD y owner
- usuario de prueba y rule match esperado
- ventana de mantenimiento y momento del reinicio
Después de updates de Sophos Server Protection, Windows Server, Sophos Firewall o AD, conviene probar SATC de forma dirigida con un usuario de prueba. La autenticación suele llamar la atención solo cuando las reglas de usuario de repente aplican demasiado ampliamente o ya no aplican.
Checklist
- El escenario RDS realmente corresponde a SATC y no a STAS normal.
- Sophos Server Protection está instalado en el Remote Desktop Session Host.
- Se han revisado la versión de Windows Server y el rol RDS.
- Tamper Protection se desactivó solo de forma controlada y después se volvió a activar.
SendSatcEvents,SatcDestinationAddrySatcDestinationPortestán definidos.- El servidor RDS se reinició.
- La IP del servidor RDS se registró en la Device Console de la firewall.
- El servidor AD y los grupos AD están revisados en la firewall.
Client Authenticationestá permitido para la zona correcta bajo Device Access.- La regla de firewall usa Match known users y tiene logging activo.
- El usuario aparece bajo Current activities > Live users con Client type
Thin client. - Log Viewer muestra el usuario esperado y la regla esperada.
FAQ
¿Cuándo se necesita SATC en lugar de STAS?
¿Se sigue soportando el SATC standalone antiguo?
¿Qué versión de Windows Server necesita SATC?
¿Por qué ya no funciona un Clientless User para la IP del servidor RDS?
¿Cómo se comprueba si SATC funciona?
Thin client. Además, Log Viewer debería mostrar qué regla de usuario hace match con el tráfico.