Activar MFA para Sophos Firewall WebAdmin, VPN Portal y Remote Access

Los portales de acceso administrativo y acceso remoto no solo deben estar protegidos con usuario y contraseña. Con la autenticación multifactor, MFA para abreviar, el Sophos Firewall también requiere un segundo factor, por ejemplo, un código OTP basado en tiempo de una aplicación Authenticator.

Para el contexto general de hardening, sirve el hub Sophos Firewall Hardening: buenas prácticas para una configuración segura.

El artículo explica cómo planificar, activar y probar el MFA con sensatez. La atención se centra en WebAdmin, VPN Portal y el acceso remoto.

Clasificación y protección de acceso

MFA es una protección importante para los inicios de sesión, pero solo un componente básico. En primer lugar, debe quedar claro qué acceso está protegido, qué fuente de identidad se esconde detrás y si el servicio debe ser accesible incluso desde la red respectiva.

¿Qué artículo de autenticación encaja?

MFA es sólo una parte de la seguridad de acceso. Dependiendo del objetivo, lo primero a considerar es la accesibilidad, la fuente de identidad, el portal, el cliente VPN o la aplicación web publicada:

• MFA para WebAdmin, VPN Portal o programar acceso remoto: Este artículo.
• WebAdmin, SSH, User Portal, VPN Portal, Restringir DNS o Ping accesible: Sophos Firewall Acceso seguro: configurar Device Access correctamente
• Utilice el SSO de Microsoft Entra ID para Sophos Connect o VPN Portal: Configurar el SSO de Microsoft Entra ID para Sophos Connect y VPN Portal
• Compare Sophos Connect, SSL VPN, IPsec o ZTNA como modelo de acceso remoto: Sophos Connect o SSL VPN: ¿Qué solución de acceso remoto es la adecuada?
• Verifique la versión del cliente de Sophos Connect, las reconexiones de OTP o el aprovisionamiento de SSO: Compruebe la versión del cliente Sophos Connect y actualícela de forma segura
• Protección de la aplicación web publicada WAF con MFA: WAF Sophos Firewall seguro con MFA
• Conecte el Active Directory clásico como fuente de usuarios: Agregar Active Directory en Sophos Firewall
• Preparar acceso de soporte controlado para Avanet o Sophos: Configuración del acceso de soporte de Avanet a Sophos Firewall
• Priorizar los resultados de la verificación de estado para MFA o el acceso al portal: Utilice Sophos Firewall Health Check correctamente

Esta separación es importante: MFA protege los inicios de sesión, pero no limita automáticamente desde qué redes o portales se puede acceder a WebAdmin, SSH. Por el contrario, una regla estricta de acceso al dispositivo no reemplaza un segundo factor. Una buena seguridad de acceso combina accesibilidad, fuente de identidad, MFA, registro y acceso alternativo probado.

Cuando MFA tiene sentido

MFA debe habilitarse al menos para todas las cuentas a las que se les permite acceder a interfaces administrativas o funciones de acceso remoto.

Áreas de aplicación típicas:

• Registro en WebAdmin.
• Registro en VPN Portal.
• SSL VPN o acceso remoto a Sophos Connect.
• Acceso para proveedores de servicios externos.
• Acceso para administradores privilegiados.

MFA reduce el riesgo de robo de contraseñas, pero no reemplaza las restricciones de acceso adecuadas. SSH, WebAdmin y los portales solo deberían ser accesibles desde redes confiables o mediante un acceso de administración claramente definido.

MFA no reemplaza a Device Access

MFA protege el proceso de inicio de sesión. Sin embargo, no reduce la superficie de ataque de un servicio. Si se puede acceder a WebAdmin, User Portal, VPN Portal o SSL VPN desde Internet, estos servicios seguirán viéndose afectados por bots, escáneres e intentos de fuerza bruta. Esto crea entradas de registro innecesarias, esfuerzo de soporte y riesgos.

Por eso siempre debes combinar MFA con controles de disponibilidad:

• Device access: Básicamente determinar qué servicios son accesibles en qué zona.
• Regla de excepción de ACL de servicio local: WebAdmin, SSH o portales específicamente solo permiten desde redes de administración, redes VPN o direcciones de origen conocidas.
• MFA: Además, asegure los registros si los datos de acceso válidos se han visto comprometidos.
• Registro y Syslog: Haga comprensibles los intentos fallidos, los problemas de implementación y los ataques.

Si es necesario que un portal sea accesible en todo el mundo, al menos debe combinar MFA, certificados válidos, registros, grupos de usuarios restrictivos y procesos de revisión regulares. Para los servicios de firewall de acceso público, la cuestión no es sólo si un atacante puede iniciar sesión, sino si el servicio necesita ser ampliamente accesible.

Restringir adicionalmente el acceso con reglas ACL

Antes de activar MFA, debe verificar desde dónde se puede llegar a WebAdmin, SSH, User Portal y VPN Portal.

La ruta del menú es Sistema > Administration > Device access.

Hay dos áreas relevantes:

• ACL de servicio local: Acceso básico por zona, por ejemplo LAN, VPN o WAN.
• Regla de excepción de ACL de servicio local: excepciones específicas para redes de origen individuales, hosts o acceso de soporte.

Para entornos de producción, generalmente no se deben habilitar WebAdmin y SSH para la zona WAN. Es mejor limitarlo a:

• una IP de gestión,
• una red de administración,
• una red VPN,
• un servidor de soporte dedicado,
• o una excepción de host/FQDN claramente definida.

Si se requiere SSH, el acceso debe restringirse adicionalmente e idealmente usarse con una clave pública. Esto se adapta a Conectar Sophos Firewall a través de SSH.

⚠️ MFA protege contra credenciales robadas, pero no contra servicios innecesariamente expuestos. WebAdmin, SSH y los portales nunca deberían ser más accesibles de lo necesario.

Seleccione la variante MFA y planifique la implementación

Antes de la activación, debe decidir si la función local de Sophos OTP es suficiente o si se debe integrar una plataforma MFA existente a través de RADIUS, NPS o SSO. Luego se planifica la implementación para que los administradores y usuarios no se bloqueen.

Requisitos

Antes de la activación debes comprobar:

• La hora del sistema firewall es correcta.
• Se configura un servidor NTP en funcionamiento.
• Los usuarios existen localmente, a través de AD, LDAP, RADIUS u otro servicio de autenticación compatible.
• Los usuarios afectados pueden iniciar sesión en el User Portal o en el servicio respectivo.
• Hay al menos un acceso administrativo alternativo disponible.> ⚠️ Hay que tener especial cuidado con Admin-MFA. MFA no debe habilitarse directamente para todos los administradores sin verificar primero un usuario de prueba, un segundo administrador y un acceso alternativo. La configuración incorrecta del MFA puede provocar que usted se quede fuera del WebAdmin o VPN Portal.

¿Sophos MFA o MFA externo?

Básicamente, hay dos formas de usar MFA en Sophos Firewall: usar la función OTP local del firewall o conectar una solución MFA externa a través de RADIUS o SSO. Ambas variantes son legítimas, pero resuelven problemas diferentes.

El MFA local del Sophos Firewall administra los tokens OTP directamente en el firewall. Esta suele ser la forma más rápida de proteger WebAdmin, portales y acceso remoto con un segundo factor. No se requiere infraestructura RADIUS adicional ni proveedor de identidad.

Ventajas del MFA de Sophos:

• No se requiere RADIUS adicional ni integración de proveedor de identidad.
• Implementación rápida para usuarios locales y entornos pequeños.
• Los tokens se pueden generar y administrar directamente en el firewall.
• Adecuado para acceso remoto WebAdmin, User Portal, VPN Portal, SSL VPN y acceso remoto IPsec.

Desventajas:

• Es posible que los usuarios necesiten mantener una aplicación o token Authenticator adicional.
• El token es independiente de Microsoft 365, Entra ID u otros procesos MFA existentes.
• Dependiendo de la máscara de inicio de sesión, no hay un campo OTP separado.
• Los usuarios deben ingresar la contraseña y el token directamente uno tras otro en ciertos portales.

En entornos más grandes, una solución MFA externa puede tener más sentido. Las variantes típicas son RADIUS con un backend compatible con MFA, Microsoft NPS con extensión Entra-MFA u otro sistema MFA compatible con RADIUS. Dependiendo de la versión de SFOS y el modelo de acceso remoto, también puede ser compatible Microsoft Entra ID SSO para WebAdmin, VPN Portal, así como Sophos Connect con SSL VPN o IPsec VPN.

La distinción importante es: Entra ID no es simplemente el mismo mecanismo que la función local de Sophos OTP. Entra MFA se integra indirectamente en el flujo de autenticación a través de RADIUS/NPS o se utiliza un modelo SSO si el servicio y el cliente utilizados lo admiten.

Los usuarios suelen encontrar más conveniente un MFA externo porque utilizan el mismo MFA que para Microsoft 365 u otros servicios empresariales. Esto no crea un segundo mundo MFA con una aplicación adicional, un token adicional y un comportamiento de inicio de sesión diferente.

La desventaja de una solución externa es su mayor complejidad. RADIUS, los grupos, los tiempos de espera, el comportamiento de desafío y las alternativas deben planificarse y probarse cuidadosamente.| Variante | Ventaja | Desventaja | Uso típico |

• MFA externo vía RADIUS: Se puede utilizar la plataforma MFA existente, se conservan los procesos de usuario centrales RADIUS, NPS, tiempos de espera, grupos y comportamiento del cliente deben probarse limpiamente Entornos AD/Microsoft 365 con muchos usuarios de VPN.
• Entra ID SSO: Inicio de sesión familiar de Microsoft, mejor experiencia de usuario, procesos de identidad centrales No se puede utilizar de forma idéntica en todos los escenarios, según la versión, el servicio y el cliente de SFOS WebAdmin, VPN Portal y Sophos Connect si SSO se ajusta al modelo operativo.

Apoyo a la decisión

La variante correcta MFA depende menos del firewall que de la operación de identidad existente.

• Entorno pequeño con usuarios de firewall locales: La propia función OTP de Sophos suele ser suficiente.
• Entorno de Microsoft 365 con Entra-MFA existente: Valide el MFA externo a través de RADIUS/NPS o Entra-ID SSO para que los usuarios no tengan que mantener dos mundos MFA.
• Muchos proveedores de servicios externos: Grupo de usuarios propio, obligación MFA, plazo claro y revisión periódica.
• Acceso de administrador crítico: MFA más Device Access, combinan red de administración, administración alternativa y registro.
• Muchos usuarios de acceso remoto: Planifique el grupo piloto, el proceso de asistencia técnica, el restablecimiento de tokens y las pruebas de clientes antes de la implementación generalizada.

Si se planifica Microsoft Entra ID directamente como fuente de SSO para VPN Portal o Sophos Connect, Configurar Microsoft Entra ID SSO para Sophos Connect y VPN Portal también es adecuado. Este es un modelo operativo diferente a la función OTP clásica de Sophos y no debe equipararse con el RADIUS-MFA no probado.

Plan MFA

Para entornos de producción, normalmente es mejor activar primero MFA para un grupo piloto pequeño.

Esta orden ha tenido éxito:

1. Preparar usuarios de prueba o grupo piloto.
2. Verifique NTP y la hora del firewall.
3. Habilite MFA para el área de prueba.
4. Registro de prueba con la aplicación Authenticator.
5. Sólo entonces integre grupos de usuarios adicionales.

Se recomienda un grupo de usuarios separado para los proveedores de servicios. Esto hace posible forzar específicamente MFA y eliminar el acceso más tarde más fácilmente.

Para los administradores también se debe planificar:

• ¿Quién es el primer administrador de la prueba?
• ¿Hay un segundo administrador con acceso para trabajar?
• ¿Es posible el acceso a través de una red de gestión o VPN?
• ¿El admin predeterminado está protegido por separado?
• ¿Está documentado cómo se reemplaza una ficha perdida?

Active MFA y configure tokens

Cuando se aclaran los requisitos previos, los grupos y el respaldo, primero se puede activar MFA para un grupo piloto. Sólo después de pruebas exitosas debe incluir usuarios o administradores adicionales.

Activar MFA en el Sophos Firewall

En las versiones actuales de SFOS, la configuración de MFA se encuentra en Authentication > Multi-factor authentication. En interfaces antiguas o según la navegación, el área aún puede aparecer en Configure > Authentication > Multi-factor authentication.

1. Inicie sesión en el WebAdmin del Sophos Firewall.
2. Abra Authentication.
3. Cambie a la pestaña Multi-factor authentication.
4. En One-time password (OTP), seleccione a quién debe aplicarse MFA:
   • No OTP: MFA está desactivado.
   • All users: MFA se aplica a todos los usuarios.
   • Specific users and groups: MFA se aplica solo a usuarios o grupos seleccionados.
5. Active Generate OTP token with next sign-in si los usuarios deben configurar su token ellos mismos en el siguiente inicio de sesión.
6. En Require MFA for, seleccione los servicios para los que se exigirá MFA.
7. Guarde la configuración con Apply.

Las opciones típicas en Require MFA for son:

• User portal
• Web admin console
• VPN portal
• SSL VPN remote access
• IPsec remote access
• Web application firewall

Dependiendo del entorno, MFA se puede aplicar de forma diferente para servicios individuales o grupos de usuarios. Para los administradores, MFA debe aplicarse de manera consistente, pero primero debe probarse de manera controlada.

Si las aplicaciones web se publican a través de Web Server Protection, también se requiere una política de autenticación WAF adecuada. El proceso está en Sophos Firewall Secure WAF con MFA.

Prepárese para la implementación y las operaciones

MFA no es sólo un interruptor en el firewall. Después de la activación, el comportamiento de inicio de sesión, las preguntas de soporte y el cambio de acceso de emergencia. Por lo tanto, antes del lanzamiento general, debe quedar claro quién emite los tokens, quién restablece los tokens perdidos y cómo será la reacción fuera del horario de oficina.

Estos puntos han resultado útiles para el funcionamiento:

• Grupo piloto de prueba con usuarios reales, no solo administradores.
• Documentar un segundo administrador y acceso para romper cristales.
• Informar al servicio de asistencia técnica sobre el comportamiento de contraseña + OTP.
• Establecer el proceso de restablecimiento del token para teléfonos inteligentes nuevos o dispositivos perdidos.
• Verifique Log Viewer y los registros de autenticación después de la implementación.
• Pruebe MFA externo a través de RADIUS con tiempos de espera realistas.
• Verifique las excepciones Device Access y ACL con regularidad.

Especialmente con el acceso remoto, debe probar MFA junto con las reglas, grupos de usuarios y perfiles de cliente de VPN afectados. Un inicio de sesión en WebAdmin que funcione no prueba automáticamente que SSL VPN, IPsec Remote Access o Sophos Connect funcionen igual.

Planificar el respaldo y romper cristales

MFA aumenta la seguridad, pero también puede bloquear administradores legítimos si el token, la hora, el servidor de autenticación o los grupos no coinciden. Es por eso que se necesita un plan alternativo antes de la activación.

Al menos estos puntos deben documentarse:

• ¿Quién tiene un segundo acceso de administrador probado?
• ¿Es posible el acceso desde una red de gestión o administrador VPN?
• ¿La admin local predeterminada está protegida como cuenta de emergencia pero no se utiliza para el uso diario?
• ¿Cómo restablecer un token OTP perdido o roto?
• ¿Quién puede restablecer los tokens para los administradores?
• ¿Cómo reaccionas fuera del horario de oficina?
• ¿Existe una copia de seguridad actual antes del cambio?La alternativa no debe significar que el acceso de administrador desprotegido siga siendo accesible permanentemente desde Internet. Es mejor tener una cuenta de emergencia con documentación clara, un camino de acceso limitado y revisiones periódicas.

MFA para el administrador predeterminado

El usuario local predeterminado admin es un caso especial. MFA para este usuario no se activa directamente en la pestaña Autenticación multifactor.

La ruta del menú es Sistema > Administration > Device access.

Allí puede activar MFA como administrador predeterminado. Sólo debes hacer esto si:

• la hora del sistema es correcta,
• se probó un segundo administrador,
• acceder a las obras a través de una red de gestión fiable,
• y está claro cómo recuperar el acceso administrativo en caso de emergencia.

Lo siguiente se aplica al admin predeterminado: no lo desactive, no lo haga accesible sin protección en Internet y no lo utilice como un usuario normal. Se trata de rotura de cristales o cuenta de emergencia.

Otros administradores no deben asumir que pueden editar o eliminar el token MFA del admin predeterminado como un token de usuario normal. Este acceso debe planificarse y probarse conscientemente a través de la ruta de acceso de su propio dispositivo.

Configurar tokens para usuarios

Una vez activado, el usuario debe configurar su segundo factor. Si Generar token OTP con el siguiente inicio de sesión está activo, el usuario inicia sesión en User Portal o VPN Portal y escanea el código QR con una aplicación Authenticator.

Las aplicaciones adecuadas incluyen:

• Microsoft Authenticator.
• Google Authenticator.
• Sophos Intercept X for Mobile.
• 1Password.
• Bitwarden.
• Otras aplicaciones TOTP compatibles con Authenticator.

El código generado está basado en el tiempo. Si la hora en el firewall o en el teléfono inteligente difiere significativamente, el inicio de sesión fallará.

Si el User Portal está deshabilitado, es posible que los usuarios no puedan configurar sus tokens por sí mismos. En este caso, deberá proporcionar el portal de forma controlada o preparar los tokens de forma administrativa.

En Authentication > Multi-factor authentication > Issued tokens se ve qué usuarios ya han generado o recibido un token. Allí se pueden revisar, eliminar o preparar manualmente tokens si hace falta. Para el admin predeterminado se aplica una regla especial: otros administradores no pueden modificar ni eliminar su token como un token de usuario normal. Ese token se administra mediante el propio flujo de MFA del default admin.

Algoritmo de token y cambio de aplicación

Sophos Firewall admite los algoritmos hash SHA1, SHA256 y SHA512 para tokens OTP. Las versiones de SFOS anteriores a 22.0 usan SHA1 para MFA; a partir de SFOS 22.0, los tokens nuevos o migrados deberían probarse con SHA256 o SHA512. No debe configurarse a ciegas: el algoritmo hash elegido debe ser compatible con la aplicación Authenticator utilizada.

Sophos indica expresamente que la aplicación debe admitir el algoritmo seleccionado. Si una aplicación no soporta correctamente SHA256 o SHA512, el código QR puede escanearse, pero el inicio de sesión aun así fallará. Por eso el algoritmo debe formar parte de la prueba piloto, especialmente si se mezclan Microsoft Authenticator, TOTP en gestores de contraseñas, Google Authenticator o Sophos Intercept X for Mobile.

Estos puntos son importantes para el funcionamiento:

• Ya no programar nuevos tokens con suposiciones de aplicaciones antiguas.
• Utilice una aplicación Authenticator que admita el algoritmo hash seleccionado.
• Si cambia de aplicación o pierde su teléfono inteligente, elimine el token antiguo y regenere el código QR.
• Utilice tokens de hardware únicamente si el algoritmo, el paso de tiempo y el secreto se pueden gestionar correctamente.
• Pruebe un grupo piloto antes de una migración SHA256/SHA512 en lugar de cambiar todos los tokens a la vez.
• En una migración, elimine y regenere de forma controlada los tokens SHA1 existentes.

La antigua aplicación Sophos Authenticator ya no debería planificarse como la nueva aplicación predeterminada; según Sophos, está End of Life desde el 31 de julio de 2022. En muchos entornos, Microsoft Authenticator, Google Authenticator, Sophos Intercept X for Mobile, 1Password o Bitwarden son opciones más realistas. La marca de la aplicación importa menos que la compatibilidad entre TOTP, algoritmo hash, copia de seguridad/restauración y proceso de soporte.

Cuando un usuario cambia de smartphone, el token antiguo no debería seguir existiendo sin control. Es mejor definir un proceso claro: verificar la identidad, eliminar el token antiguo, generar un nuevo código QR, probar el inicio de sesión con OTP correcto e incorrecto y documentar el cambio.

Nota importante sobre contraseñas y tokens

Dependiendo del servicio de Sophos, no hay un campo de formulario separado para el código OTP. Esto siempre genera confusión, especialmente con el VPN Portal o los inicios de sesión de acceso remoto. En estos casos, el usuario suele tener que introducir la contraseña y el código OTP uno tras otro.

Ejemplo:

Contraseña: MiContrasenaSegura
Codigo OTP: 123456
Entrada:    MiContrasenaSegura123456

Esto debe comunicarse claramente a los usuarios antes del lanzamiento. De lo contrario, al usuario le parecerá que la contraseña es incorrecta, aunque solo falte el código OTP.

Este comportamiento debe probarse y documentarse antes de la implementación porque se percibe de manera diferente según el servicio y la máscara de inicio de sesión.

Operación de prueba y control

Una prueba WebAdmin exitosa no es suficiente. Cada superficie de inicio de sesión afectada debe probarse por separado porque el portal, el cliente VPN, el grupo de usuarios y el servidor de autenticación pueden reaccionar de manera diferente.

Prueba de inicio de sesión

Primero se debe probar MFA con un usuario que no sea el único administrador.

Se deben comprobar estos puntos:

• Registro en WebAdmin.
• Registro en VPN Portal.
• Iniciar sesión en el servicio de acceso remoto.
• Comportamiento en caso de código OTP incorrecto.
• Comportamiento después de que caduque un código OTP.
• Acceder con un usuario que no esté en el grupo MFA.
• Inicie sesión con contraseña y código OTP adjunto.
• Acceso a través de reglas ACL programadas.

Solo cuando estas pruebas sean exitosas se podrá implementar MFA en otros grupos.

Matriz de pruebas por servicio

Una prueba MFA no debe consistir únicamente en un inicio de sesión exitoso en WebAdmin. Dependiendo del servicio, se aplican otros portales, grupos, perfiles y archivos de registro. Esta matriz ayuda a examinar los casos más importantes por separado:

• WebAdmin: Inicie sesión como usuario administrador con OTP correcta e incorrecta La OTP correcta permite el acceso, la OTP incorrecta se rechaza y registra limpiamente.
• Predeterminado admin: Pruebe la ruta MFA separada en Sistema > Administration > Device access La cuenta de emergencia está protegida, pero sigue disponible una ruta documentada para romper cristales.
• User Portal: El usuario configura los tokens él mismo El código QR solo aparece para usuarios autorizados, el token funciona al iniciar sesión.
• VPN Portal: El usuario inicia sesión con contraseña y OTP El inicio de sesión funciona con un formato de entrada documentado y es visible en Log Viewer.
• SSL VPN / Sophos Conectar: Importar perfil o volver a conectar MFA se consulta en el cliente real, no solo en el navegador.
• IPsec Acceso remoto: Verificar grupo y método de autenticación MFA aplica al mismo grupo que también está permitido en la configuración de acceso remoto.
• MFA externo vía RADIUS: Prueba push, desafío o token con cliente real El tiempo de espera es suficiente, el comportamiento del desafío coincide con el del cliente, los errores son visibles en el servidor RADIUS.

Cada prueba también debe verificar si Device Access o una regla de ACL de servicio local permite intencionalmente el servicio. Si el token funciona pero se puede acceder al portal desde la red incorrecta, la configuración MFA es solo una parte del problema resuelto.

Registros y control operativo

Después de la implementación, debe verificar si los eventos MFA se pueden rastrear durante la operación. Esto es importante para casos de soporte, revisiones de seguridad y respuesta a incidentes.

Puntos de control útiles:

• Verifique los eventos de autenticación en el Visor de registros.
• Distinga los inicios de sesión fallidos de las contraseñas incorrectas, OTP incorrecta y OTP caducada.
• Documento VPN portal y pruebas de acceso remoto con tiempo y usuario.
• Para RADIUS externo, verifique también el servidor RADIUS, los registros de NPS o los registros del proveedor de identidad.
• Para almacenamiento más prolongado, planifique Central Reporting o Syslog/SIEM.

Para archivos de registro locales y mapeo de servicios, Sophos Firewall Solución de problemas: Services y registros es adecuado. Si los eventos de autenticación y portal se van a evaluar a largo plazo, Sophos Firewall enviar Syslog a SIEM es adecuado.

Después del despliegue, en Sophos Central, Syslog o SIEM no conviene revisar solo los inicios de sesión correctos. Son especialmente relevantes los intentos fallidos repetidos en WebAdmin, User Portal, VPN Portal y SSL VPN, porque muestran si un servicio está expuesto de forma innecesariamente amplia o si los usuarios tienen problemas con el formato de OTP.

Solución de problemas

No se acepta el código OTP

Primero verifique la hora del sistema del firewall y la hora del teléfono inteligente. TOTP depende del tiempo. Incluso una desviación importante puede provocar el rechazo de códigos válidos.

Puede consultar los tokens emitidos en Autenticación > Autenticación multifactor. Si un solo token sigue sin alcanzar la marca, no debe cambiar inmediatamente toda la configuración del MFA. Primero verifique la deriva del tiempo del token, la aplicación utilizada, el algoritmo hash y el paso de tiempo.

El usuario no ve el código QR

El usuario debe ser elegible para MFA e iniciar sesión en el portal correcto. Además, se debe comprobar si se encuentra al usuario a través de la fuente de autenticación esperada.

Si el User Portal está deshabilitado, es posible que el usuario no pueda configurar el token por sí mismo. Luego se debe hacer que el portal sea accesible temporalmente o el token debe crearse administrativamente.

No se puede acceder al portal a través de Device Access

Si los usuarios no pueden configurar su token aunque MFA se haya activado correctamente, no se debe eliminar el token primero. A menudo, no se puede acceder al portal requerido desde la red actual a través de Sistema > Administration > Device access o una regla ACL de servicio local.

Comprueba primero:

• ¿Qué portal se utiliza para la configuración del token?
• ¿De qué zona o fuente proviene el usuario?
• ¿Se permite el acceso intencionadamente o se bloquea accidentalmente?
• ¿Existe una excepción de ACL más limitada en lugar de una versión amplia?

El administrador está bloqueado

En este caso, utilice el acceso alternativo preparado. Si no existe un respaldo, el acceso debe evaluarse a través de la consola, el soporte o las rutas de recuperación, según la situación.

MFA no funciona para acceso remoto

Compruebe si la configuración de acceso remoto utiliza el mismo grupo de usuarios para el que se activó MFA. A menudo, el error no está relacionado con el MFA en sí, sino con diferentes grupos en VPN y reglas de autenticación.

Los perfiles de cliente también deben coincidir con la configuración actual. Después de realizar cambios en VPN Portal, SSL VPN, IPsec Remote Access, Entra SSO o RADIUS, los perfiles de Sophos Connect afectados se deben volver a importar o redistribuir.

El usuario solo ingresa la contraseña

Si no se muestra un campo OTP separado, el usuario debe ingresar la contraseña y el código OTP uno tras otro. Este es uno de los casos de soporte más comunes después de activar Sophos OTP.

El MFA externo no funciona de manera confiable

Para las soluciones MFA basadas en RADIUS, los tiempos de espera, el comportamiento de desafío y los grupos deben encajar perfectamente. Si se utilizan Push-MFA, Call-MFA o respuestas de desafío, debe probar todo el proceso de inicio de sesión con el cliente afectado.

También es importante el límite de cada portal: no todos los inicios de sesión de Sophos soportan igual todos los comportamientos de desafío RADIUS. VPN Portal, SSL VPN, Sophos Connect, WebAdmin y Captive Portal deben probarse por separado con clientes reales. Una prueba RADIUS correcta en la configuración del servidor no basta como prueba del login productivo de Remote Access.

MFA se activó para el grupo equivocado

Si MFA funciona para algunos usuarios y no para otros, primero debes comparar los grupos técnicamente. No solo los nombres para mostrar visibles son relevantes, sino también los grupos realmente importados o coincidentes de AD, LDAP, RADIUS o Entra ID. Un usuario puede autenticarse exitosamente y aun así no terminar en el grupo para el cual se requiere MFA.

Lista de verificación operativa y recomendación

Después de la activación técnica, MFA necesita un proceso operativo simple: ¿Quién restablece los tokens, quién verifica los registros y cómo se verifica que los portales no sean innecesariamente accesibles?

Lista de verificación de operaciones

• Hora del sistema y NTP verificados.
• Grupo piloto definido y probado.
• MFA no se activa directamente para todos los administradores al mismo tiempo.
• Segundo administrador y acceso contra rotura de cristales documentado.
• Device Access y Local Service ACL probados para WebAdmin, User Portal, VPN Portal y SSL VPN.
• Acceso desde redes de origen permitidas y prohibidas probadas.
• Usuario informado sobre el comportamiento de contraseña+OTP.
• Proceso de restablecimiento de token documentado para teléfonos inteligentes perdidos.
• Aplicación Authenticator, algoritmo hash y migración de token documentados.
• Acceso Remoto probado con clientes reales y perfiles actuales.
• Se prueban los tiempos de espera de RADIUS/Entra si se utiliza MFA externo.
• Registros y almacenamiento central revisados.

Recomendación de funcionamiento

MFA debería ser estándar para el acceso administrativo. MFA es particularmente importante para WebAdmin, VPN Portal y todos los usuarios con autorización de acceso remoto.

Para entornos pequeños, la función OTP propia de Sophos suele ser suficiente. En entornos Microsoft 365 o Entra ID, un MFA externo sobre RADIUS puede ser más conveniente porque los usuarios no tienen que aprender un segundo mundo MFA.

Independientemente de la variante MFA, se aplica lo siguiente: primero restrinja el acceso con reglas ACL, pruebe Admin-MFA cuidadosamente, informe a los usuarios sobre la contraseña + token y solo luego implementelo ampliamente.

Preguntas frecuentes