Configurar STAS en Sophos Firewall

STAS significa Sophos Transparent Authentication Suite. La funcion asigna inicios de sesion de Windows desde Active Directory a una IP de cliente, de modo que Sophos Firewall pueda usar usuarios y grupos en reglas de firewall sin que el usuario tenga que iniciar sesion por separado en el navegador o en un portal.

Esto sigue siendo util en dominios Windows clasicos. Al mismo tiempo, STAS no es una solucion SSO universal. La asignacion solo funciona de forma fiable si el firewall ve la IP real del cliente, los Domain Controllers escriben los eventos de inicio de sesion adecuados y las cuentas tecnicas se excluyen correctamente. Para entornos RDS, terminal server o Citrix, normalmente hace falta otro diseno, por ejemplo SATC.

Cuando tiene sentido STAS

STAS encaja sobre todo en entornos con clientes Windows normales dentro de un dominio Active Directory. Objetivos tipicos:

• reglas de firewall con usuarios o grupos de AD
• reporting con referencia a usuarios en lugar de solo direcciones IP
• asignacion transparente de usuarios sin Captive Portal
• reglas de Internet para redes internas de clientes
• autenticacion complementaria en entornos sin diseno Entra ID SSO

STAS es menos adecuado cuando varios usuarios comparten la misma IP de origen. Esto afecta, por ejemplo, a Remote Desktop Server, terminal server, Citrix Server o sistemas con NAT entre el cliente y el firewall. En estos casos conviene comprobar pronto si Sophos Authentication for Thin Client (SATC) u otro modelo de autenticacion encaja mejor.

Video tutorial

Los siguientes Sophos Techvids muestran visualmente la arquitectura STAS. Los videos se crearon con SFOS v21, pero siguen siendo utiles para entender el principio, la arquitectura y los pasos principales de configuracion. Algunas pantallas pueden verse ligeramente distintas en SFOS 22.

Funcionamiento

STAS consta de dos componentes:

El flujo tipico:

1. Un usuario inicia sesion en un cliente Windows.
2. Active Directory escribe un Security Event adecuado.
3. El STA Agent lee este evento.
4. El STA Collector recibe usuario, IP de cliente e informacion de dominio.
5. Sophos Firewall actualiza los Live Users.
6. Las reglas de firewall pueden evaluar usuarios o grupos.

Ademas, el Collector puede comprobar clientes mediante WMI o Registry Read Access. Este Workstation Polling ayuda a asignar una direccion IP a un usuario o a corregir entradas antiguas. Para ello deben encajar Windows Firewall, servicios, permisos y rutas de red.

Requisitos

Antes de la instalacion deben estar claros estos puntos:

• Sophos Firewall funciona en modo gateway.
• Active Directory ya esta conectado al firewall.
• Los Domain Controllers escriben los eventos de inicio de sesion necesarios.
• Los clientes Windows son miembros del dominio.
• No hay NAT entre clientes, Collector y Sophos Firewall.
• Client Authentication esta permitido en Device Access para las zonas afectadas.
• DNS, hora, routing y reglas de firewall entre los sistemas implicados son correctos.
• Se ha definido una cuenta de servicio y un proceso de cambio de contrasena.
• Las cuentas tecnicas para Exclusions son conocidas.

STAS 2.5 y versiones posteriores admiten, segun la documentacion oficial, Windows Server 2008 R2, 2012 R2, 2016, 2019, 2022 y 2025. Para instalaciones nuevas, aun asi no conviene planificar con generaciones de servidor antiguas. Lo importante es que STAS puede ejecutarse directamente en un Domain Controller o, a partir de STAS 2.5, tambien en un Member Server. En disenos con Member Server hay que comprobar con especial cuidado que el acceso a Event Log, WMI/Registry y las rutas de red funcionen realmente.

La conexion AD esta descrita en Conectar Active Directory con Sophos Firewall. STAS no debe entenderse como sustituto de una configuracion limpia del servidor AD.

Si con los anos se acumulan muchos usuarios y grupos en el firewall, tambien debe vigilarse el limite de User-ID de Sophos Firewall. Esto es especialmente relevante si funciones de portal o VPN fallan solo para usuarios concretos.

Planificar la arquitectura

En entornos pequenos, Agent y Collector pueden ejecutarse en el mismo Domain Controller. Es sencillo, pero no siempre es la mejor variante operativa.

El Collector genera sus propias rutas de comunicación y comprobación hacia la firewall, los Agents y, según el método de polling, también hacia los clientes. Por eso no debería instalarse automáticamente en un Domain Controller solo porque allí ya se ejecuta el Agent. Sophos también advierte que instalar el Collector en un Domain Controller no siempre es recomendable por el tráfico que genera. En entornos productivos, un servidor Windows separado suele ser más limpio de monitorizar, actualizar y reiniciar en caso de problemas.

En entornos mas grandes suele ser mas limpio:

• STA Agent en cada Domain Controller relevante
• uno o dos STA Collectors en sistemas Windows separados
• Collector Groups por dominio AD
• Exclusion List clara para cuentas tecnicas
• reglas de firewall y permisos de Device Access definidos
• monitorizacion de servicios, Event Logs y asignacion de Live Users

La vista de IP es decisiva. STAS asigna usuarios a direcciones IP. Si un proxy, NAT, terminal server o VPN gateway oculta la IP real del cliente, el firewall no puede usar la asignacion de forma fiable.

Preparar Active Directory

STAS depende mucho de que existan los eventos de inicio de sesion correctos en el Security Event Log. Los siguientes ajustes deben comprobarse en cada Domain Controller en el que se vaya a usar el STA Agent.

Ademas, antes de instalar conviene anotar el nombre NetBIOS, el FQDN y el Search DN del dominio. Estos valores se necesitan mas tarde en Sophos Firewall y en la configuracion STAS.

Activar Audit account logon events

En el Domain Controller, abrir Local Security Policy. Se puede hacer, por ejemplo, con secpol.msc.

Despues abrir la ruta:

Security Settings > Local Policies > Audit Policy

Alli abrir Audit account logon events.

A continuacion, activar Success y Failure y guardar el cambio.

Preparar la cuenta STAS

El servicio STAS debe ejecutarse con una cuenta documentada. En entornos de prueba sencillos se usa a menudo una cuenta de administrador. Para entornos productivos es mejor una cuenta STAS dedicada, siempre que los permisos necesarios se definan y prueben correctamente.

Segun el diseno, la cuenta debe poder:

• iniciar el servicio
• leer los Event Logs relevantes
• acceder a clientes mediante WMI o Registry Read Access
• sobrevivir de forma planificada a cambios de contrasena
• ser identificable claramente en monitorizacion y documentacion

La cuenta no tiene que ser necesariamente Domain Admin. Para el Domain Controller son importantes, como minimo, los permisos de grupo y de archivos adecuados. En la practica conviene comprobar:

• pertenencia a Domain Users
• pertenencia a Event Log Readers
• permisos de lectura y escritura en C:\Program Files (x86)\Sophos\Sophos Transparent Authentication Suite\
• para WMI Polling, permisos adecuados en los endpoints, por ejemplo Remote Desktop Users, Distributed COM Users y permisos WMI en Root\CIMV2 con Execute Methods y Remote Enable

En entornos grandes, estos permisos de endpoint se distribuyen mejor mediante Group Policies. Si no se usa Workstation Polling, no se deben conceder permisos innecesariamente amplios.

Si el servicio se ejecuta con una cuenta propia, esta cuenta necesita Log on as a service.

Ruta en Local Security Policy:

Security Settings > Local Policies > User Rights Assignment

Despues anadir la cuenta.

Comprobar puertos y servicios

Entre Sophos Firewall, STA Collector, STA Agent, Domain Controller y clientes deben ser posibles las conexiones necesarias. Como base se aplican:

Los puertos adicionales dependen de los metodos activados:

Si Windows Firewall esta activo en clientes o servidores, las reglas deben limitarse estrictamente al Collector. Plantilla de ejemplo para WMI:

New-NetFirewallRule -DisplayName "Sophos STAS Collector WMI" -Direction Inbound -RemoteAddress 10.10.10.10 -Action Allow -Profile Domain

Este comando es solo una plantilla. En entornos productivos, IP de origen, puertos de destino, perfiles y Group Policies deben ajustarse al metodo de polling elegido.

Registrar Active Directory en el firewall

Antes de activar STAS, Sophos Firewall debe conocer el servidor Active Directory.

En WebAdmin:

Authentication > Servers

Alli anadir un servidor Active Directory o comprobar la configuracion existente.

Los campos individuales se explican en Conectar Active Directory con Sophos Firewall. Para STAS son especialmente importantes el dominio NetBIOS, el nombre de dominio, la base de busqueda y la resolucion de grupos.

Descargar e instalar STAS

La instalacion STAS se proporciona desde Sophos Firewall.

En WebAdmin:

Authentication > Client downloads

En Single Sign-on se encuentra Sophos Transparent Authentication Suite (STAS).

Iniciar el archivo STAS.exe descargado como administrador en el sistema Windows previsto.

Variantes tipicas de instalacion:

Con varios Domain Controllers, normalmente se necesita un STA Agent en cada Domain Controller relevante. Un Collector puede recopilar informacion de varios Agents.

Configurar STAS

Tras la instalacion se configura la STA Suite. Las areas mas importantes son General, STA Agent, STA Collector y Exclusion List.

General

En la pestana General se revisan sobre todo la cuenta de servicio, los datos del dominio, el nombre NetBIOS y el FQDN.

Si aqui hay valores de dominio incorrectos, la instalacion puede parecer sana mas tarde, pero los usuarios o grupos no se asignan correctamente. El nombre NetBIOS debe introducirse en STAS en mayusculas.

STA Agent

En la pestana STA Agent estos puntos son decisivos:

• STA Agent Mode: para deteccion local mediante Event Log, EVENTLOG es el punto de partida habitual.
• Specify the networks to be monitored: introducir las redes de clientes en las que STAS debe detectar usuarios.
• Domain Controller IP: solo se configura si el Agent no se ejecuta directamente en el Domain Controller. Si la SSO Suite esta instalada en un Domain Controller, este campo normalmente queda vacio.
• Collector List: introducir las direcciones IP de los sistemas Collector.

Las redes monitorizadas deben elegirse conscientemente. Redes de servidores, redes de gestion o redes sin estaciones de trabajo de usuarios normales generan errores innecesarios o expectativas equivocadas.

STA Collector

En la pestana STA Collector se registra Sophos Firewall y se planifica el Client Polling.

Puntos importantes:

• Sophos Appliance: introducir la direccion IP de Sophos Firewall.
• Workstation Polling Method: elegir conscientemente WMI o Registry Read Access.
• Enable Logoff Detection: activar solo si ping y timeouts encajan con la red de clientes.
• Dead entry timeout: probar el valor con la version STAS y el modelo operativo.

En clusters HA se debe usar la direccion interna alcanzable del firewall que encaja con el trafico STAS. Las direcciones administrativas separadas del peer casi nunca son el destino correcto.

Exclusion List

La Exclusion List evita que cuentas tecnicas sobrescriban asignaciones de usuarios normales. Es una de las areas operativas mas importantes de STAS.

Entradas tipicas:

• cuentas de servicio para backup, monitorizacion, distribucion de software o Endpoint tools
• cuentas de administracion e instalacion
• cuentas que inician sesion en segundo plano en muchos clientes
• servidores o sistemas en los que no se esperan usuarios de estaciones de trabajo

Sin Exclusion List, un usuario real puede desaparecer de los Live Users porque poco despues se ha detectado una cuenta de servicio en el mismo cliente. Mas tarde esto parece un problema de regla de firewall, aunque la causa este en la asignacion de autenticacion.

Collector Groups y redundancia

En entornos pequenos suele bastar un Collector. En entornos mas grandes, los Collector Groups deben planificarse conscientemente.

Reglas probadas:

• Usar un Collector Group adecuado por dominio AD.
• Planificar al menos dos Collectors si las reglas de usuario son criticas.
• Configurar los STA Agents con todos los Collectors previstos.
• Probar firewall y Collectors en ambas direcciones.
• No colocar Collectors en sistemas que se reinician con frecuencia.

Un STA Agent puede atender varios Collectors. Un STA Collector tambien puede atender varios Sophos Firewalls. Aun asi, la asignacion debe documentarse; de lo contrario, el troubleshooting se complica innecesariamente.

En el firewall se registra un Collector con Collector IP, Collector port y Collector group. Por Collector Group son posibles como maximo cinco Collectors. El orden dentro del grupo es importante: el primer Collector es primario, los demas sirven como backup. Los Collectors del mismo dominio pertenecen al mismo Collector Group. Para subdominios o dominios AD separados conviene usar Collector Groups propios.

Activar STAS en Sophos Firewall

Cuando Agent, Collector, AD y red estan preparados, STAS se activa en el firewall.

En WebAdmin:

Authentication > STAS

Activar STAS e introducir el Collector o el Collector Group.

Si la configuracion funciona, los usuarios aparecen en el dashboard y en el area Live Users.

Si alli no aparecen usuarios, primero deben comprobarse AD Events, Agent, Collector, Device Access y puertos. Las reglas de firewall son el siguiente paso, no el primero.

Opciones STAS importantes en el firewall

En Authentication > STAS hay algunas opciones que conviene configurar conscientemente.

• STAS quarantine: Con tráfico entrante, la firewall pregunta al Collector por la asignación de usuario e IP de destino. Sin coincidencia, el tráfico se descarta. Es útil para reglas de usuario estrictas, pero con detección STAS inestable puede parecer un problema de red.
• Identity probe time-out: Tiempo durante el cual la firewall espera la respuesta del Collector. El valor predeterminado es 120 segundos. No debe aumentarse a ciegas; primero hay que comprobar por qué el Collector no responde o responde tarde.
• Restrict client traffic during identity probe: Con Yes, el tráfico puede quedar bloqueado durante la comprobación de identidad hasta que el firewall reciba una respuesta de STAS. Con No, el tráfico se reenvía durante la comprobación. El valor de fábrica es Yes, por lo que también pueden verse afectados entornos STAS antiguos que no se han cambiado durante años. Conviene revisarlo antes de upgrades a SFOS 22, porque en SFOS 22.0 MR1 es relevante para un problema documentado de upgrade y funcionamiento de STAS.
• Enable user inactivity: Elimina usuarios inactivos de Live Users. Ayuda a mantener limpios los Live Users, pero debe encajar con clientes, polling y timeout.
• Inactivity timer: Minutos hasta el sign-out de usuarios inactivos. El valor predeterminado es 3. Valores demasiado cortos pueden provocar cierres de sesión irritantes en clientes con poco tráfico.
• Data transfer threshold: Cantidad mínima de datos en bytes para que un usuario se considere activo. El valor predeterminado es 100. Umbrales bajos suelen ser más adecuados para clientes Office que valores muy agresivos.

Crear regla de firewall con referencia a usuarios

Cuando STAS detecta usuarios de forma estable, se pueden usar reglas de firewall con usuarios o grupos de Active Directory.

Importante:

• Probar la regla con un grupo de prueba real.
• Activar Log firewall traffic si la regla se debe analizar mas tarde.
• Comprobar la posicion de la regla.
• Evitar reglas fallback que oculten errores de autenticacion.
• Revisar Live Users y Log Viewer conjuntamente.

Para analizar reglas encaja Probar reglas de firewall con Log Viewer, Policy Test y Packet Capture.

Validacion tras la configuracion

Un estado de servicio verde no basta. Tras la configuracion conviene probar toda la cadena.

Procedimiento practico:

1. Iniciar sesion con un usuario de prueba en un cliente del dominio.
2. Comprobar el Security Event en el Domain Controller.
3. Comprobar el estado del STA Agent.
4. Comprobar el estado del STA Collector y los usuarios detectados.
5. Comprobar Live Users en Sophos Firewall.
6. Probar una regla de firewall basada en usuarios con logging.
7. Probar logoff o cambio de usuario.
8. Comprobar cuentas tecnicas contra la Exclusion List.

En STAS se puede comprobar en Advanced > Show live users que usuarios conoce actualmente el Collector. En el firewall, el lugar correspondiente es Current activities > Live users. Ambas vistas deben ser logicas en el momento de la prueba.

Si STAS controla reglas criticas para el negocio, esta prueba debe repetirse despues de Windows Updates, cambios en Domain Controllers, upgrades del firewall y cambios de contrasena de la cuenta de servicio.

Pruebas, logs y backup

STAS ofrece varias herramientas locales de comprobacion. A menudo son mas rapidas que mirar solo el Firewall Log Viewer.

• Probar conexión con la firewall: Advanced > Troubleshooting > Test Connectivity > Sophos comprueba si Agent o Collector alcanzan la firewall.
• Probar STA Agent: Advanced > Troubleshooting > Test Connectivity > STAS Agent comprueba si el Collector alcanza un Agent.
• Probar STA Collector: Advanced > Troubleshooting > Test Connectivity > STAS Collector comprueba si un Agent alcanza un Collector.
• WMI Verification: Advanced > Troubleshooting > STAS Polling Utilities > WMI Verification comprueba Workstation Polling mediante WMI contra una IP de cliente.
• Registry Read Verification: Advanced > Troubleshooting > STAS Polling Utilities > Registry Read Verification comprueba Workstation Polling mediante Registry Read Access contra una IP de cliente.

El log de STAS se ve directamente en la aplicacion STAS en Advanced > View Log. Ademas, el archivo de log esta en el sistema Windows en:

C:\Program Files (x86)\Sophos\Sophos Transparent Authentication Suite\stas.log

Antes de cambios importantes se debe guardar la configuracion STAS. Esto se hace en la aplicacion STAS en Advanced > Backup / Restore > Backup Now. La copia se crea como archivo con el formato STAS_ConfigBackup_DD_MM_YYYY_THH_MM_SS.bkp. Para restaurar, se selecciona el archivo .bkp en Backup / Restore y se aplica mediante Upload and Restore.

Revisar STAS antes de SFOS 22 MR1

STAS es una de las funciones que deben revisarse conscientemente antes de un Major Upgrade. En la lista actual de Known Issues hay un problema relacionado con SFOS 22.0 MR1, STAS y la opcion Restrict client traffic during identity probe. Si esta opcion esta en Yes, puede impedir un upgrade a SFOS 22.0 MR1 o provocar tras el upgrade Identity Probes repetidos y, por tanto, interrupciones temporales de trafico. Como Yes es el valor predeterminado, no conviene asumir que solo estan afectados disenos especiales endurecidos conscientemente.

Para administradores es importante: no es un problema normal de configuracion STAS. Un entorno puede funcionar durante anos y aun asi llamar la atencion durante el upgrade porque una configuracion antes aceptada se vuelve critica en combinacion con SFOS 22.0 MR1. Por eso STAS debe incluirse en el SFOS 22 Upgrade Check.

Antes de un upgrade a SFOS 22.0 MR1 o posterior, comprobar:

• Esta STAS activo?
• Se usan reglas basadas en usuarios en produccion?
• Esta activado Restrict client traffic during identity probe?
• Hay mensajes sobre Identity Probes repetidos o interrupciones breves de trafico sin explicacion?
• Existe un usuario de prueba para comprobar STAS especificamente tras el upgrade?

Si la opcion afectada esta activa, no debe evaluarse por primera vez durante la ventana de mantenimiento de firmware. Es mejor hacer una prueba breve antes: documentar el cambio, iniciar sesion con el usuario de prueba, comprobar Live Users, probar una regla basada en usuarios y revisar Log Viewer. Si STAS controla reglas criticas de seguridad, tambien debe aclararse si hace falta una regla fallback temporal para que los usuarios no queden bloqueados de forma incontrolada.

Para el camino de upgrade a SFOS 22.0 MR1, la regla practica es: si STAS esta activo y Restrict client traffic during identity probe esta en Yes, conviene cambiar la opcion a No antes del upgrade y validarla despues con usuarios de prueba reales. Si este cambio no puede probarse antes, aplazar el upgrade suele ser mas limpio que una ventana de mantenimiento arriesgada. En sistemas SFOS 22.0 MR1 ya afectados, No tambien es la mitigacion documentada hasta que haya una release corregida.

Tras el upgrade, comprobar especificamente:

1. Revisar el estado STAS en Authentication > STAS.
2. Comprobar Live Users con un login de dominio nuevo.
3. Probar una regla de firewall basada en usuarios con logging.
4. En Log Viewer, comprobar si se ve el nombre de usuario y no solo la IP.
5. Vigilar efectos de Identity Probe repetidos o breves interrupciones.

Si el upgrade se bloquea con un mensaje STAS o si tras el upgrade aparecen interrupciones reproducibles, conviene preparar un Sophos Support Case. Seran utiles una captura del mensaje de upgrade, la configuracion STAS actual, la version de firmware, la regla de usuario afectada y una breve secuencia de prueba.

Troubleshooting

No aparecen usuarios en Live Users

Primero comprobar si el Domain Controller escribe los Security Events adecuados. Despues revisar STA Agent, STA Collector, puertos y Device Access.

Causas tipicas:

• Audit Policy no activa
• STA Agent no se ejecuta o lee el Domain Controller equivocado
• Collector no alcanzable
• UDP 6060 o 6677 bloqueado
• Client Authentication no permitido en Device Access
• NAT oculta la IP real del cliente

El usuario se asigna de forma incorrecta

Con frecuencia intervienen Exclusions, Workstation Polling o cuentas tecnicas. Comprobar si cuentas de servicio, cuentas de monitorizacion o cuentas de instalacion sobrescriben el mismo cliente.

El usuario desaparece demasiado rapido

Comprobar Logoff Detection, Dead Entry Timeout, alcanzabilidad del cliente y metodo de polling. Si los clientes no responden a ping, WMI o Registry Access, las entradas pueden desaparecer inesperadamente o quedar obsoletas.

Errores DCOM o STAS consulta redes equivocadas

Si despues de instalar STAS aparecen errores DCOM como Event ID 10009 o 10028 en Windows Event Viewer, la causa no es automaticamente la regla de firewall. A menudo el Collector intenta comprobar mediante WMI o Registry Read Access clientes que no son accesibles o que no pertenecen a las redes monitorizadas.

En ese caso, se deben limitar las redes monitorizadas en STAS:

1. En la aplicacion STAS, abrir la pestaña STA Collector.
2. En Sophos appliances, seleccionar la Sophos Firewall afectada y abrir Edit.
3. Activar Enable subnet based filter.
4. Introducir solo las redes que realmente deben monitorizarse.
5. En la pestaña STA Agent, comprobar las mismas redes cliente en Specify the networks to be monitored.
6. Aplicar los cambios y reiniciar STAS.

Esto reduce consultas WMI innecesarias y evita que usuarios de redes no adecuadas aparezcan como LogonType: 1. Despues del cambio, revisar conjuntamente stas.log, Windows Event Viewer y Current activities > Live users.

La regla de firewall no aplica

No mirar solo la regla. Comprobar:

• Esta el usuario visible en Live Users?
• Se detecta el grupo AD correcto?
• Aplica una regla de firewall anterior?
• Esta activo el logging en la regla?
• Log Viewer ve el usuario o solo la direccion IP?

Tiempo de transicion para trafico no autenticado

Para fases de transicion, el firewall permite por defecto trafico no autenticado durante un breve tiempo. Este valor puede comprobarse o ajustarse desde Device Console:

system auth cta unauth-traffic drop-period

Esta configuracion no debe cambiarse a ciegas. Primero debe quedar claro si el problema es realmente el tiempo de transicion o una asignacion STAS defectuosa.

Cuando el firewall ve trafico de una direccion IP para la que STAS aun no conoce ningun usuario, esta IP se comprueba primero en modo de aprendizaje. Durante esta fase se puede descartar trafico. Si el Collector no responde, el firewall trata la IP como no autenticada durante un tiempo. Para dispositivos fuera del dominio no se debe esperar que STAS los cubra automaticamente de forma limpia. Para estos sistemas, Clientless Users o reglas propias pueden ser mas adecuados.

STAS a traves de VPN

STAS tambien puede usarse en un escenario IPsec VPN si usuarios de una sede remota se autentican contra un Domain Controller en la sede principal. Pero esto debe planificarse conscientemente, porque routing, IP de origen, STAS Monitored Networks y zonas de firewall deben encajar.

Requisitos para un diseno asi:

• La conexion IPsec esta activa y estable.
• El trafico de la branch se enruta por el tunel.
• STAS y Active Directory estan configurados correctamente en la sede principal.
• La red branch esta registrada en STAS como red monitorizada.
• El firewall branch esta registrado en la configuracion del STA Collector como Sophos Appliance.
• Client Authentication esta permitido para la zona VPN en Device Access.

En el firewall de la sede principal, la red remota debe anadirse para STAS mediante Device Console. Ejemplo:

system auth cta vpnzonenetwork add source-network 172.50.50.0 netmask 255.255.255.0

El ejemplo debe sustituirse por la red branch real. En muchos entornos, aun asi es mas sencillo y robusto usar STAS solo para redes locales de clientes y disenar las sedes remotas por separado.

STAS, SATC y Remote Desktop Server

El STAS clasico funciona bien cuando una IP de cliente pertenece normalmente a un usuario. En Remote Desktop Server, terminal server o sistemas Citrix, varios usuarios comparten la misma direccion IP. Entonces STAS clasico no puede distinguir limpiamente los usuarios.

En estos entornos debe comprobarse Sophos Authentication for Thin Client (SATC). SATC no es una simple casilla dentro de STAS, sino un tema de diseno propio:

• Que servidores estan afectados?
• Que usuarios trabajan a traves de estos servidores?
• Que reglas de firewall deben ser realmente basadas en usuarios?
• Hay trafico mixto de servicios del servidor y sesiones de usuario?
• Como se prueba y documenta el comportamiento?

Si los terminal servers se usan solo ocasionalmente, puede ser mas sensato segmentar estas conexiones de otra forma o usar reglas propias sin referencia a usuarios. Lo decisivo es que la autenticacion encaje con la arquitectura de red real.

Checklist operativa

Antes de la instalacion:

• El servidor AD funciona en Sophos Firewall.
• Redes de clientes y Domain Controllers estan documentados.
• Ningun NAT oculta las IPs de cliente.
• La cuenta de servicio y los permisos estan definidos.
• Audit Policy esta activa en los Domain Controllers relevantes.
• Exclusion List esta preparada.

Despues de la instalacion:

• Agent y Collector se ejecutan.
• Los puertos entre Agent, Collector, firewall y clientes estan abiertos.
• Live Users muestra usuarios de prueba.
• La regla de firewall basada en usuario coincide en Log Viewer.
• Logoff, cambio de usuario y cuentas tecnicas se han probado.
• La redundancia de Collector esta documentada si es necesaria.

En operacion:

• Monitorizar la cuenta de servicio.
• Mantener regularmente la Exclusion List.
• Coordinar cambios de Windows Firewall y GPO con STAS.
• Coordinar regularmente los subnet-based filters y las redes monitorizadas con la estructura real de clientes.
• Probar STAS despues de upgrades de firewall y Domain Controllers.
• Antes de SFOS 22.0 MR1 o posterior, comprobar Restrict client traffic during identity probe.
• En RDS/Citrix, no improvisar con STAS; comprobar SATC u otro diseno.

FAQ