Configurar Client Authentication Agent en Sophos Firewall

El Client Authentication Agent, o CAA, es adecuado para endpoints individuales Windows, macOS o Linux en los que el usuario inicia sesión conscientemente en el firewall. Tras un login correcto, la identidad aparece como Authentication agent en Current activities > Live users. Las reglas de firewall y web basadas en usuarios o grupos pueden asociar después el tráfico a esta identidad.

El agente no sustituye a todas las arquitecturas SSO. Un servidor de terminales con varios usuarios simultáneos necesita SATC, mientras que STAS puede realizar la autenticación sin agente de endpoint en un dominio Windows. CAA está pensado sobre todo para un conjunto controlable de equipos individuales donde el inicio de sesión manual sea aceptable.

Importante: El agente debe alcanzar la ruta de autenticación documentada por Sophos. Los clientes Windows y macOS se comunican mediante 1.2.3.4 y TCP 9922; una VPN, otra ruta predeterminada o un router previo pueden desviar esta ruta del firewall. Antes de un despliegue amplio, se prueban la ruta, la CA TLS, el login piloto y la coincidencia real de regla en un equipo.

CAA en diez pasos

1. Confirmar que el endpoint representa a un solo usuario activo; para RDS, Citrix u otros hosts multiusuario se utiliza SATC.
2. Documentar el servidor de autenticación, el grupo de usuarios, la política de firewall y un método local de recuperación.
3. Desde el equipo piloto, verificar la ruta a 1.2.3.4 a través de Sophos Firewall y TCP 9922.
4. Descargar el agente adecuado y su Server CA en Authentication > Client downloads.
5. Para una distribución masiva en Windows, planificar juntos Download MSI y Download CA for MSI; los instaladores individuales incluyen agente y CA.
6. Instalar el agente en un equipo piloto, sin distribuirlo todavía de forma general.
7. En Authentication > Services > Firewall authentication methods, comprobar el servidor de autenticación previsto y su orden.
8. Iniciar sesión con un usuario piloto y confirmar el tipo de cliente Authentication agent en Current activities > Live users.
9. Ejecutar un flujo permitido y otro bloqueado y comprobar usuario, política y Firewall Rule ID en Log Viewer.
10. Solo entonces documentar el despliegue, el comportamiento de MFA, la prueba HA, el proceso de soporte y el rollback.

Cuándo es adecuado Client Authentication Agent

CAA envía al firewall el inicio de sesión del usuario desde el endpoint. Es especialmente adecuado para:

• equipos individuales administrados que no pertenecen a un dominio;
• entornos pequeños sin infraestructura STAS;
• equipos donde un cambio de usuario debe provocar deliberadamente un nuevo login del agente;
• políticas que necesitan un nombre de usuario real y no solo una IP de origen.

El agente no es una solución general para varios usuarios simultáneos detrás de la misma IP de host. SATC en sistemas de Remote Desktop explica el enfoque por sesión para Citrix, RDS y servidores de terminales. En un entorno AD, STAS en Sophos Firewall es la alternativa sin cliente.

CAA autentica al usuario, pero no crea una autorización de red. Las reglas de firewall, Web Policies, grupos, cuotas y Access-Time-Policies siguen siendo niveles independientes. Un Live User visible no demuestra que el tráfico deseado coincida con la regla correcta.

Ejemplo y requisitos

El piloto utiliza:

• IP LAN del firewall: 10.20.30.1
• Equipo piloto: 10.20.30.50
• Usuario piloto: fw-user-pilot
• Grupo de usuarios: CAA-Pilot
• Destino del agente: 1.2.3.4
• Puerto TCP: 9922

10.20.30.1 y 10.20.30.50 son valores privados de documentación que se sustituyen por las direcciones reales. En cambio, 1.2.3.4 y TCP 9922 son la ruta del agente documentada por Sophos para Windows y macOS y no se cambian allí como valores normales del entorno. Para Linux, las instrucciones actuales del User Portal utilizan un archivo de configuración propio y exigen la IP real del firewall.

Antes de la instalación deben aclararse estos puntos:

• El equipo piloto utiliza Sophos Firewall como gateway o dispone de una ruta comprobada al destino del agente.
• Ninguna VPN full-tunnel ni ruta ajena desvía 1.2.3.4 del gateway SFOS previsto.
• El usuario existe localmente o en un servidor seleccionado en Firewall authentication methods.
• El grupo y las políticas están preparados; el piloto no recibe permisos más amplios por precaución.
• La Authentication Server CA correspondiente al instalador se obtiene solo del firewall propio.
• Durante el piloto permanece disponible otro método de autenticación funcional.
• Si MFA está activado, se registra el token y se prueba por separado el comportamiento del agente.

La ayuda actual de SFOS 22 indica como sistemas compatibles Windows 10 y posterior, Ubuntu 16.4 y posterior y macOS Catalina 10.15 y posterior. Es un límite de la documentación actual del producto, no una garantía para cualquier versión futura del sistema operativo. Antes del despliegue se prueba como piloto la combinación concreta de compilación SFOS, paquete del agente y versión del endpoint.

Preparar la autenticación en el firewall

En Authentication > Services > Firewall authentication methods se selecciona al menos un servidor adecuado o la base de datos local. Con varios servidores, SFOS reenvía la solicitud en el orden mostrado. Por tanto, Default Group, grupo importado y estado del usuario deben estar definidos antes de probar el agente.

Para cuentas piloto locales, consulte crear y probar usuarios locales de forma segura. En AD, LDAP o RADIUS se prueba primero el servidor correspondiente con su diálogo normal de servicio. Sin embargo, un Test connection correcto no demuestra la posterior ruta CAA desde el endpoint.

Si MFA está activado para el User portal, Sophos indica que este requisito también se aplica a Client Authentication Agents. El registro y la introducción del token se prueban con el mismo usuario piloto. MFA no se activa inesperadamente después del despliegue.

Descargar el agente y la Server CA

Los administradores descargan los paquetes aquí:

Authentication > Client downloads

Sophos ofrece estas variantes:

• Download MSI: agente Windows para distribución automatizada;
• Download CA for MSI: Authentication Server CA separada para el despliegue MSI;
• Download for Windows: instalador individual con agente y CA;
• Download for macOS: instalador individual con agente y CA;
• Download for Linux 32 o Download for Linux 64: archivo con agente, configuración y CA.

Como alternativa, los usuarios autorizados pueden descargar los paquetes desde Download client > Authentication clients en el User Portal. El acceso al User Portal solo se permite desde las redes previstas. No es necesaria una autorización WAN amplia solo para la descarga.

Tras un factory reset, el firewall genera de nuevo la CA. Los usuarios deben reinstalar entonces la Authentication Server CA. Un agente antiguo con una CA antigua no se repara desactivando la validación de certificados o añadiendo una CA ajena; se descarga de nuevo el paquete actual desde el firewall correcto.

Instalar el agente en el equipo piloto

Windows y macOS

En Windows se ejecuta client_auth_agent.exe desde el User Portal. En un despliegue MSI administrado deben distribuirse juntos el agente y Download CA for MSI. El agente sin su CA correspondiente no implementa la ruta TLS documentada.

En macOS se abre Client+Authentication+Agent.dmg y se mueve el agente a la carpeta de aplicaciones prevista. También aquí la CA integrada debe proceder del firewall en el que el usuario iniciará sesión posteriormente.

Primero se instala el piloto de forma interactiva. La distribución del paquete, el inicio automático y el comportamiento de actualización solo se automatizan tras una prueba end-to-end correcta. No se reutiliza un agente antiguo de otro backup o appliance.

Linux

Para Linux, Sophos indica esta ruta de extracción, sustituyendo <FILENAME> por el archivo descargado:

sudo tar -xzvf <FILENAME> -p -C $HOME
sudo mv ~/bin/caa /usr/local/bin

Después se comprueba la configuración incluida en $HOME/.caa/caa.conf. La ayuda actual del User Portal exige en Linux sustituir el valor tras Copernicus host por la IP real del firewall e introducir usuario y contraseña. Una contraseña real no se incluye en un script de distribución, ticket o ejemplo público. Sophos indica que el agente cifra la contraseña inicialmente guardada en texto claro durante la primera ejecución.

Antes de iniciar se comprueban permisos, propietario y el contenido de $HOME/.caa/README. Después se ejecuta caa como piloto. Como las instrucciones de Linux utilizan otro valor de destino que la ruta general de Windows y macOS, no se mezclan los procedimientos de las plataformas.

Autenticar el piloto y probar las políticas

El piloto inicia sesión en el agente con el nombre de usuario y la contraseña previstos para el firewall. Con autenticación externa, el formato exacto debe coincidir con la configuración del servidor. Una indicación correcta en el agente solo es la primera prueba.

Después se comprueba en el firewall:

1. fw-user-pilot aparece en Current activities > Live users.
2. El tipo de cliente es Authentication agent.
3. La IP de origen y el grupo corresponden al equipo piloto y al mapeo previsto.
4. Un flujo permitido coincide con la regla esperada basada en usuario o grupo.
5. Un destino deliberadamente no autorizado sigue bloqueado.
6. El log del firewall muestra usuario, regla, acción y Firewall Rule ID.
7. Tras Disconnect en Live users, el agente recibe la notificación documentada y el tráfico vuelve a evaluarse.

No se crea una política Any amplia para la regla de prueba. Las reglas existentes solo se amplían de forma controlada con el usuario o grupo piloto. El proceso general se explica en probar sistemáticamente reglas de Sophos Firewall.

Comprobar logs y HA

En Log viewer, se filtra Authentication por usuario, IP de origen y hora de prueba. El campo de cliente debe mostrar Authentication Agent. También se comprueba el tráfico real del firewall y su Firewall Rule ID.

Para una correlación más profunda son relevantes access_server.log para autenticación y autorización, además de Log Viewer o el destino Syslog configurado. Un solo estado del cliente sin la entrada correspondiente del firewall no es una prueba completa de éxito.

En HA no se presupone que un login existente del agente continúe sin interrupción. Después de un failover controlado se vuelven a probar un login nuevo, Live User, la coincidencia de política y el tráfico real. Los logs se encuentran en el node que procesó el evento; si la hora no está clara, se comprueban ambos nodes o una vista consolidada.

Delimitar errores por síntoma

El agente no alcanza el firewall

Primero se comprueba la ruta al destino documentado del agente y TCP 9922. Una captura controlada con host 1.2.3.4 and port 9922 puede mostrar si el tráfico Windows o macOS llega a Sophos Firewall. En Linux se comprueba en su lugar la IP del firewall configurada en caa.conf.

Si el problema comienza solo después de conectar otro cliente VPN, se comprueba si su ruta full-tunnel se apropia del destino del agente. La solución no consiste en aplicar a ciegas un comando de host route: primero se evalúan split tunnel, routing y efecto de seguridad en el diseño real. Si la ruta de autenticación sigue sin estar clara, se detiene el despliegue.

Aparece un error TLS o de CA

El instalador y la CA deben proceder del mismo firewall activo. Tras un factory reset, la CA antigua deja de ser válida y se sustituye por el paquete actual. No se desactivan la validación de certificados, la protección del endpoint ni TLS como solución rápida.

La contraseña funciona en el portal, pero no en el agente

En Firewall authentication methods, se comprueban el orden de servidores, Default Group y el estado del usuario. Después se revisan el requisito MFA, el formato del nombre de usuario, una vinculación a IP de origen o MAC y el mensaje del log Authentication. Un login correcto en el portal no demuestra automáticamente el mismo método ni la ruta del agente.

El usuario está live, pero se aplica la regla equivocada

Se comprueban el orden de reglas, Match known users, el usuario o grupo seleccionado, el servicio, el destino y Firewall Rule ID. Primero se identifica la regla realmente coincidente; una autorización amplia no sustituye al diagnóstico.

En un servidor de terminales solo aparece una identidad

CAA no es el enfoque correcto para esta ruta multiusuario. Varias instancias paralelas del agente no convierten el host en un sistema sensible a sesiones. Para RDS o Citrix se utiliza SATC y se valida por separado.

Para el diagnóstico entre métodos, consulte resolver sistemáticamente errores de autenticación de Sophos Firewall.

Rollback y operación

Si el piloto falla, se detiene o elimina el agente en el equipo piloto. Los cambios temporales de usuario, grupo, portal y reglas se devuelven al estado anterior documentado. Después se vuelve a probar el método de autenticación previo con un login nuevo y tráfico real.

La Authentication Server CA no se elimina globalmente mientras otras instalaciones CAA la utilicen. Antes de un factory reset, reimage o sustitución del appliance se planifica actualizar la CA recién generada en todos los endpoints afectados.

Como mínimo se documentan estos puntos operativos:

• responsable del paquete del agente y del despliegue;
• versiones de sistema operativo autorizadas;
• origen y renovación de la Authentication Server CA;
• ruta esperada al destino del agente y TCP 9922;
• proceso de MFA y contraseña;
• prueba piloto y negativa tras cambios de SFOS, endpoint o VPN;
• desactivación de acceso y eliminación de Live Sessions existentes.

Lista de comprobación

• endpoint de un solo usuario confirmado, no host multiusuario
• servidor de autenticación y orden documentados
• ruta del agente a través de Sophos Firewall verificada
• agente y Authentication Server CA descargados del mismo firewall
• MSI y CA separada planificados conjuntamente
• límites de plataforma y ruta específica de Linux considerados
• usuario piloto preparado con grupo y política mínimos
• comportamiento MFA probado
• Live User muestra Authentication agent
• tráfico real permitido y bloqueado probado
• usuario, acción y Firewall Rule ID confirmados en el log
• comportamiento de VPN y HA probado con un login nuevo
• efecto de factory reset sobre la CA y rollback documentados

Preguntas frecuentes