Configurar Microsoft Entra ID SSO para Sophos Connect y el Portal VPN

Con Microsoft Entra ID SSO, Sophos Firewall puede autenticar a los usuarios para el Portal VPN y el Acceso Remoto a través de Sophos Connect contra Microsoft Entra ID. Para muchas configuraciones de Microsoft 365, esto es más conveniente que contraseñas locales separadas en el firewall, ya que la identidad, el acceso condicional y el MFA se gestionan centralmente en el proveedor de identidad.

Sin embargo, la ventaja solo es real si toda la cadena está bien planificada: la aplicación Entra, las URIs de redirección, el Portal VPN, Sophos Connect, los métodos de autenticación, los grupos, Device Access y los perfiles de cliente deben coincidir. Este artículo describe el proceso práctico para el Portal VPN, SSL VPN y Acceso Remoto IPsec con Sophos Connect.

Para la configuración general de Sophos Connect, primero consulte Configurar Sophos Connect en Sophos Firewall. Este artículo complementa los pasos específicos de identidad y SSO.

Qué hace Entra ID SSO en el firewall

Sophos Firewall integra Microsoft Entra ID SSO a través de OAuth 2.0 y OpenID Connect. El firewall utiliza Entra ID como servidor de autenticación y puede registrar usuarios para varios servicios.

Para el Acceso Remoto, estos servicios son especialmente relevantes:

• Portal VPN
• SSL VPN a través de Sophos Connect
• Acceso Remoto IPsec a través de Sophos Connect

Para el Portal Cautivo se aplica un proceso diferente: el usuario ya se encuentra en la red local y se autentica en el navegador para que se apliquen reglas basadas en el usuario. Este caso se describe por separado en Configurar Microsoft Entra ID SSO para el Portal Cautivo de Sophos Firewall.

El SSO directo de Microsoft Entra ID no cubre todos los inicios de sesión clásicos del firewall. Para User Portal y Client Authentication Agent, Sophos remite a Microsoft Entra ID Domain Services. Se trata de una arquitectura de directorio independiente compatible con AD o LDAP, no de una opción adicional del objeto de servidor OAuth/OIDC. Por lo tanto, si se necesitan User Portal o CAA, no se debe asumir que la aplicación SSO configurada aquí autentica automáticamente esos servicios.

Es importante la delimitación: el firewall sigue gestionando el VPN, las políticas, la coincidencia de grupos de usuarios y el acceso a través de reglas de firewall. Entra ID gestiona la verificación de identidad, SSO y MFA basado en Entra.

Un servidor Entra ID, varios servicios

El servidor Microsoft Entra ID se crea una vez en Sophos Firewall en Authentication > Servers. Después, el mismo objeto de servidor puede seleccionarse en Authentication > Services para distintos servicios, por ejemplo Portal VPN, SSL VPN, Acceso Remoto IPsec, Captive Portal o inicio de sesión de administradores.

Esto no significa que todos los servicios funcionen automáticamente igual. Cada servicio necesita la Redirect URI correcta, el método de autenticación adecuado y su propio flujo de prueba. Para Portal VPN, SSL VPN y Acceso Remoto IPsec, la URL relevante es VPN portal and remote access URL. Si Captive Portal o WebAdmin también usan Entra ID SSO, sus URLs de servicio deben añadirse a la aplicación Entra y probarse por separado.

El servicio administrativo requiere además roles o grupos de Entra, perfiles locales de permisos y un acceso de emergencia probado. El procedimiento específico se explica en Configurar Microsoft Entra ID SSO para WebAdmin de Sophos Firewall.

Por cada método de autenticación solo puede usarse un servidor Microsoft Entra ID. Por eso, con Sophos Connect Provisioning, Portal VPN, SSL VPN e IPsec deben usar de forma consciente el mismo servidor Entra ID para que el valor de gateway, la Redirect URI y el perfil de cliente coincidan.

Cuándo es útil Entra ID SSO

Entra ID SSO es adecuado cuando los usuarios ya trabajan con Microsoft 365 y la organización utiliza el Acceso Condicional o Entra-MFA como control de seguridad central.

Razones típicas:

• Los usuarios no deben mantener contraseñas de firewall separadas.
• El MFA debe ejecutarse a través de Entra ID en lugar de Sophos OTP.
• El Acceso Remoto debe estar más vinculado al estado del usuario, grupos y Acceso Condicional.
• El equipo de soporte y seguridad debe gestionar los procesos de identidad centralmente en Entra ID.
• Se deben reducir los usuarios locales del firewall.

No todas las configuraciones deben cambiarse de inmediato. En instalaciones pequeñas sin un modelo de grupos Entra limpio, el MFA propio de Sophos puede ser más sencillo. Para la variante clásica de OTP, consulte Activar MFA para Sophos Firewall WebAdmin, Portal VPN y Acceso Remoto.

Requisitos y limitaciones

Antes de la configuración, se deben cumplir estos puntos:

• Sophos Firewall con una versión de SFOS compatible.
• Tenant de Microsoft Entra con permiso para crear un registro de aplicación.
• FQDN público para el Portal VPN o el acceso remoto.
• Certificado válido para el nombre público.
• El Portal VPN es accesible desde la zona necesaria.
• Sophos Connect 2.4 o posterior en Windows, si se va a utilizar SSO en el cliente.
• Los usuarios o grupos están correctamente presentes en Entra ID.
• El firewall y Entra ID tienen la hora correcta.
• Las URLs de inicio de sesión de Microsoft son accesibles desde los clientes y, dependiendo de la ruta del tráfico, desde el firewall.

Limitaciones importantes:

• Para Sophos Connect SSO, Sophos menciona endpoints de Windows con Sophos Connect 2.4 o posterior.
• Si se utiliza Microsoft Entra ID SSO, se utiliza MFA en el proveedor de identidad. El MFA propio de Sophos Firewall no se puede utilizar adicionalmente para este método de autenticación.
• Solo se puede seleccionar un servidor de Microsoft Entra ID por método de autenticación.
• Los usuarios del mismo dominio no deben sincronizarse simultáneamente a través de AD y Microsoft Entra ID.
• En clústeres HA, actualmente no se debe asumir que Microsoft Entra ID SSO funciona para el WebAdmin del firewall auxiliar.

⚠️ Conditional Access requiere una versión de firmware corregida: En SFOS 21.5 GA Build 171, Sophos Connect podía reutilizar una sesión SSO existente sin volver a comprobar MFA ni otras condiciones de Conditional Access. Desconectar y volver a conectar el túnel VPN no siempre era suficiente. Sophos identifica el problema como NC-167126 y no ofrece una solución temporal oficial. Está corregido a partir de SFOS 21.5 MR2 Build 323 o SFOS 22.0 MR1 Build 490. Si Conditional Access actúa como límite de seguridad, primero se debe actualizar al menos a una de estas versiones. Force SSO re-login reduce el riesgo en sistemas anteriores, pero no sustituye la corrección.

⚠️ Una actualización a SFOS 22 puede activar SSO automáticamente: Si antes de la actualización VPN Portal, Remote Access IPsec o SSL VPN utilizaban Same as firewall en Authentication > Services, SFOS 22.0 o posterior activa automáticamente Microsoft Entra ID SSO para estos servicios. Antes de actualizar se documentan los métodos efectivos. Si se desea Entra SSO, después debe registrarse en la aplicación Entra la VPN portal and remote access URL exacta del objeto de servidor Entra y comprobarla con un inicio de sesión real. No debe utilizarse la URL reverse SSO de Sophos Fusion (antes Sophos Central). Si no se desea SSO, se configura expresamente el método previsto en lugar de aceptar sin comprobar el estado heredado.

Planificar la arquitectura

Antes de la configuración técnica, se debe decidir qué servicios utilizarán SSO.

• Portal VPN: ¿Debería el inicio de sesión en el portal realizarse a través de Entra ID?
• SSL VPN: ¿Debería utilizarse SSL VPN a través de Sophos Connect con Entra SSO?
• Acceso Remoto IPsec: ¿Debería utilizarse Acceso Remoto IPsec a través de Sophos Connect con Entra SSO?
• Archivo de aprovisionamiento: ¿Se utilizará un archivo de aprovisionamiento automático?
• Grupos: ¿Qué grupos de Entra pueden usar VPN?
• MFA: ¿Qué reglas de Acceso Condicional y MFA se aplican para el Acceso Remoto?
• Fallback: ¿Qué sucede si Entra ID o el acceso a Internet a Microsoft no está disponible?

Si se utiliza un archivo de aprovisionamiento, el valor gateway establecido en él debe coincidir con el FQDN o la IP que se utiliza en la configuración de Microsoft Entra ID del firewall como URI de redirección. Después de los cambios en Entra ID o en la configuración del firewall, los usuarios deben importar nuevamente la configuración actualizada.

Antes del cambio, documente Authentication > Services, el orden de servidores, los grupos y políticas VPN, Device Access y los perfiles distribuidos. Mantenga un administrador local independiente de Entra ID como acceso break-glass protegido, supervisado y probado por separado. Debe disponer de las licencias Entra exigidas por las políticas de Conditional Access. Esta integración no admite Microsoft 365 GCC High.

Preparar la aplicación Entra para el firewall

Sophos recomienda una aplicación dedicada. En App registrations > New registration, cree una aplicación Accounts in this organizational directory only con plataforma Web y copie Application (client) ID y Directory (tenant) ID. En API permissions > Microsoft Graph, conceda con Admin Consent los permisos delegados User.Read.All y Group.Read.All; añada Group.Read.All como Application permission solo para importar grupos con SFOS. Cree un Client secret, guarde inmediatamente su Value de forma segura y planifique la caducidad y rotación.

En Enterprise application > Properties, establezca Assignment required? en Yes y asigne solo el grupo piloto/VPN y los administradores necesarios. La asignación es el primer control y la política SSL/IPsec el segundo. Microsoft documenta la asignación de usuarios y grupos y las reglas de Redirect URI. SFOS lee automáticamente los atributos del token; elija un Fallback user group sin amplios derechos de VPN para que la falta de un grupo importado no amplíe el acceso.

La asignación de aplicaciones por grupos requiere Microsoft Entra ID P1 o P2 y no incluye a usuarios que solo pertenezcan mediante un grupo anidado. Sin esa licencia o con grupos anidados, asigne directamente a los usuarios piloto; de lo contrario, Entra rechazará el inicio de sesión aunque la pertenencia al grupo VPN parezca correcta.

Crear un servidor Microsoft Entra ID en el firewall

La ruta del menú es:

Authentication > Servers

Procedimiento en el firewall:

1. Abrir Add.
2. Seleccionar la opción Microsoft Entra ID SSO como Server type.
3. Asignar un nombre de servidor descriptivo.
4. Ingresar Application (client) ID de la aplicación Entra.
5. Ingresar Directory (tenant) ID.
6. Ingresar Client secret.
7. Verificar o establecer manualmente el FQDN de la URI de redirección.
8. Establecer el grupo de fallback.
9. Si se necesita SSO para WebAdmin, planificar la asignación de roles o grupos a perfiles de administrador.
10. Ejecutar Test connection.
11. Guardar.

Para escenarios de SSO solo para VPN, no se necesita una asignación de roles de administrador. En ese caso, el servidor debe planificarse como un servicio de usuario, no como un acceso de administrador general.

⚠️ Los secretos de cliente son credenciales de acceso productivas. La fecha de vencimiento, rotación, responsabilidad y documentación deben aclararse antes del despliegue.

Establecer métodos de autenticación

Después de crear el servidor de Microsoft Entra ID, debe asignarse a los servicios correspondientes en Authentication > Services.

Para el Acceso Remoto, estas áreas son relevantes:

• VPN portal authentication methods
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods
• SSL VPN authentication methods

Si se utiliza un archivo de aprovisionamiento, se debe utilizar el mismo servidor de Microsoft Entra ID para el Portal VPN, IPsec y SSL VPN. En los archivos de aprovisionamiento, es importante la misma selección de servidor para los métodos de autenticación, para que el perfil del cliente, el portal y el método de acceso remoto coincidan.

Sin un archivo de aprovisionamiento, SSL VPN y VPN Portal deben seguir utilizando el mismo servidor Microsoft Entra ID; Remote Access IPsec puede utilizar entonces otro objeto de servidor Entra. Con un archivo de aprovisionamiento, VPN Portal, SSL VPN e IPsec deben apuntar al mismo objeto. Esta diferencia debe documentarse expresamente y no deducirse más tarde a partir de un error de tenant en el diálogo SSO.

Después de cada cambio:

1. Seleccionar el servidor en el método correspondiente.
2. Arrastrar el servidor a la posición correcta si hay varios servidores.
3. Ejecutar Apply para cada servicio cambiado.
4. Usar un usuario de prueba antes de desplegar el cambio ampliamente.

Registrar URIs de redirección en Microsoft Entra ID

Para que SSO funcione, las URLs del firewall deben registrarse en la aplicación Entra como URIs de redirección.

Procedimiento:

1. Abrir Authentication > Servers en el firewall.
2. Abrir el servidor de Microsoft Entra ID.
3. Copiar las URLs necesarias:
   • URL de la consola de administración web, si se utiliza SSO para WebAdmin
   • URL del portal cautivo, si se utiliza el Portal Cautivo
   • URL del portal VPN y acceso remoto para el Portal VPN, Acceso Remoto IPsec y SSL VPN
4. Cambiar al portal de Azure en Microsoft Entra ID > App registrations.
5. Abrir la aplicación para Sophos Firewall.
6. En Manage > Authentication, agregar una plataforma web o editar la plataforma web existente.
7. Insertar las URIs de redirección copiadas.
8. Guardar.

Un error común es un nombre de host diferente en el perfil del cliente, URI de redirección, certificado y DNS público. Estos valores deben compararse conscientemente antes del despliegue.

Si no se protege el Acceso Remoto, sino el Portal Cautivo, también se debe verificar el proceso específico del Portal Cautivo: Device Access para la zona del cliente, método de autenticación del Portal Cautivo, grupo de usuarios y coincidencia de reglas de firewall posterior.

Permitir el Portal VPN a través de Device Access

Microsoft Entra ID SSO para Acceso Remoto utiliza el puerto del Portal VPN para comunicarse con el firewall. Para el acceso desde Internet, permita por tanto VPN Portal en la fila WAN de Administration > Device access. Active otras zonas solo cuando los clientes realmente deban alcanzar el portal desde ellas.

Esto no significa que se deba abrir el Portal VPN sin pensar en todo el mundo. El Acceso Remoto es una superficie de ataque accesible públicamente. Para entornos productivos, también se debe verificar:

• certificado público válido
• MFA y Acceso Condicional en Entra ID
• limitación de países o fuentes lo más estrecha posible, si es realista
• registro y revisión de intentos de inicio de sesión
• desactivación clara de usuarios que ya no se necesitan

El endurecimiento de los servicios locales del firewall se describe en Device Access y Local Service ACL en Sophos Firewall.

Si ya se producen muchos inicios de sesión fallidos, orígenes distribuidos o bloqueos de cuentas de Entra, Detectar y contener ataques de fuerza bruta contra VPN Portal combina los logs del firewall con la revisión de Entra, una restricción ACL segura y la comprobación posterior.

Permitir URLs de inicio de sesión de Microsoft

Los clientes y las rutas de firewall afectadas deben poder alcanzar los endpoints de Microsoft Entra ID. Esto incluye varias URLs de inicio de sesión y CDN de Microsoft, como login.microsoftonline.com, login.microsoft.com, *.login.live.com, *.msauth.net y otros dominios de Azure/Microsoft Online.

En entornos restrictivos, no se debe descubrir durante el despliegue que las páginas de inicio de sesión, JavaScript o los endpoints de tokens están bloqueados. Es recomendable:

• Utilizar la lista de permitidos para el inicio de sesión de Microsoft Entra completa para Hosts FQDN y excepciones de proxy.
• Nombrar correctamente los Hosts FQDN o los Grupos de Hosts FQDN.
• Establecer conscientemente una regla de firewall para DNS y HTTPS.
• En caso de un proxy web directo, verificar también las excepciones web.
• Activar el registro hasta que el inicio de sesión SSO funcione de manera estable.

Con un Direct Web Proxy, la regla Allow hacia el FQDN Host Group no es suficiente por sí sola. El artículo enlazado sobre la lista de permitidos contiene los patrones URL exactos y explica el procedimiento en Web > Exceptions. Limite la excepción a los patrones de login y CDN necesarios.

Verificar grupos y permisos de VPN

SSO por sí solo no otorga acceso a VPN. El usuario también debe estar permitido en la configuración de Acceso Remoto correspondiente.

Importar grupos de Entra de forma selectiva

Para importar grupos, la aplicación del firewall necesita el permiso de Microsoft Graph Group.Read.All como Application permission y el correspondiente Admin Consent. A continuación, en Authentication > Servers, se abre Assistant for importing groups para el servidor Entra. En lugar de importar todos los grupos sin revisión, el asistente puede filtrar, por ejemplo, por Display name o Description.

Durante la importación se pueden asignar Surfing quota, Access time, Network traffic y Traffic shaping a todos los grupos o a grupos concretos. Estas políticas solo se asignan cuando el grupo las necesita realmente. La hora del firewall y de Microsoft Entra ID debe estar sincronizada; de lo contrario, la propia importación puede fallar.

Si el grupo Entra existe en el firewall, SFOS asigna el usuario a ese grupo. Si no existe, se aplica el Fallback user group configurado en el servidor Entra. Esto también se aplica cuando el servidor Entra se utiliza en Firewall authentication methods; el Default group de esa sección no sustituye al grupo de respaldo. Después de la importación, el nuevo grupo también debe autorizarse en la política IPsec o SSL VPN correspondiente.

Para verificar:

• El grupo Entra se ha importado al firewall o se ha mapeado correctamente.
• El grupo está seleccionado en Acceso Remoto IPsec bajo Allowed users and groups.
• El grupo está seleccionado en SSL VPN bajo Policy members.
• Las reglas de firewall permiten el tráfico desde la zona VPN solo a los destinos necesarios.
• El usuario no solo está autenticado, sino que también recibe la política esperada.

Si el túnel está conectado pero no fluye tráfico, a menudo no es SSO la causa, sino las reglas, el enrutamiento, DNS o NAT. Para el análisis, consulte Probar reglas de firewall con Log Viewer, Policy Test y Packet Capture.

Verificar UPN, correo electrónico y coincidencia de grupos

Con Microsoft Entra ID SSO, se debe verificar especialmente la identidad del usuario y la coincidencia de grupos. Un inicio de sesión puede ser exitoso en el proveedor de identidad y aun así estar mal asignado en el firewall si el UPN, la dirección de correo electrónico, el grupo importado o la identificación local del usuario no coinciden.

Esto es especialmente relevante en entornos donde los usuarios tienen valores históricos diferentes:

• Nombre principal de usuario: max.muster@example.com suele ser el nombre de inicio de sesión esperado.
• Dirección de correo electrónico: m.muster@example.com puede ser diferente y causar confusión durante la asignación o el inicio de sesión en el portal.
• Nombre para mostrar: Max Muster es legible para las personas, pero no sirve como identificador técnico.
• Grupo: VPN-Users debe importarse al firewall y utilizarse en la configuración de Acceso Remoto correcta.

El formato de inicio de sesión también es importante al migrar desde Active Directory local a Entra ID. AD suele utilizar sAMAccountName@domain, mientras que Entra ID utiliza UserPrincipalName@domain. SFOS trata cadenas diferentes como objetos de usuario distintos, aunque pertenezcan a la misma persona. Siempre que sea posible, el formato se alinea antes de la migración. Si se utilizan nombres distintos deliberadamente, se crean duplicados; los antiguos usuarios de AD solo se eliminan después de verificar reglas, grupos, informes y el nuevo inicio de sesión de Entra.

El antiguo problema conocido NC-157635 provocaba que los inicios de sesión en el portal SSL VPN o IPsec fallaran cuando la dirección de correo electrónico y el UPN eran diferentes. Sophos lo corrigió en SFOS 21.0 MR2 Build 349, 21.5 MR1 Build 261 y 22.0 EAP0 Build 274. La comprobación de los atributos del usuario sigue siendo útil cuando solo hay problemas con determinadas cuentas, ya que permite detectar objetos de usuario locales o permisos de grupo que no coinciden.

Proceso de verificación práctica:

1. Abrir el usuario de prueba en Microsoft Entra ID.
2. Comparar UPN y dirección de correo electrónico.
3. Verificar si el usuario es miembro del grupo VPN planificado.
4. En el firewall, abrir el grupo importado y verificar si el usuario aparece como se espera.
5. En Authentication > Services, verificar si el servidor de Microsoft Entra ID correcto está seleccionado para el Portal VPN, SSL VPN e IPsec.
6. Realizar un inicio de sesión de prueba y verificar Log Viewer y oauth_sso_vpn.log.

Si solo se ven afectados usuarios individuales, es más probable que sea un problema de atributos o grupos que un error general del servidor Entra ID. Si todos los usuarios se ven afectados, primero verifique Tenant ID, Client ID, Client Secret, URIs de redirección, hora y endpoints de Microsoft.

Para las reglas de usuario después de un inicio de sesión VPN exitoso, además: La regla de firewall debe ver al usuario o grupo en el tráfico real. Si el túnel está activo, pero la regla de usuario planificada no coincide, consulte el análisis en La regla de Sophos Firewall no coincide: Verificar causas.

Introducir MFA y Conditional Access de forma controlada

Limite la política a la Enterprise Application del firewall y empiece con usuarios piloto o modo Report-only. Compruebe MFA y cada condición con un caso permitido y otro denegado en los registros Entra. Microsoft recomienda planificar y evaluar las políticas antes de aplicarlas.

Mantenga al menos dos cuentas de emergencia Entra cloud-only, separadas, supervisadas y excluidas de Conditional Access. No sustituyen al administrador local independiente de Internet, Entra y la aplicación, ni deben asignarse a la VPN solo para probar una omisión. Consulte Manage emergency access accounts.

Probar Sophos Connect y aprovisionamiento

Para Sophos Connect: Después de la configuración de Entra ID o después de cambios en la configuración de SSO, la configuración del cliente debe importarse nuevamente.

Proceso de prueba:

1. Instalar el cliente actual de Sophos Connect en Windows.
2. Importar la configuración de aprovisionamiento o VPN adecuada.
3. Verificar si la opción SSO es visible y seleccionable en el cliente.
4. Iniciar sesión con Entra ID.
5. Activar MFA o Acceso Condicional según lo planeado y comprobar el resultado en los registros de inicio de sesión de Entra.
6. Verificar el estado del túnel.
7. Verificar IP de VPN, DNS, objetivos internos y coincidencia de reglas de firewall.
8. En un dispositivo compartido, probar un inicio de sesión SSO forzado nuevamente.

Para la última prueba, abrir el menú superior derecho del cliente Sophos Connect, seleccionar Force SSO re-login y confirmar con OK. Solo entonces el siguiente usuario tendrá que iniciar sesión con sus propias credenciales de Entra. Desconectar el túnel de forma normal no es equivalente. En dispositivos Windows compartidos, este paso también forma parte de un cambio de usuario correcto con firmware actual.

Registre para cada prueba la hora, el usuario, el tipo de VPN y el resultado esperado. Aplicación, usuario, resultado MFA/Conditional Access y código de error en Entra deben corresponder con oauth_sso_vpn.log o el módulo Authentication de Log Viewer. Antes del despliegue pruebe en su entorno: piloto asignado y usuario no asignado en el portal; cada perfil SSL/IPsec utilizado con IP VPN, DNS y solo destinos autorizados; usuario sin grupo VPN; Force SSO re-login en un equipo compartido; e inicio del administrador break-glass por su ruta restringida. No son pruebas que afirmemos haber ejecutado.

Para la instalación del cliente en Windows, consulte Instalar el cliente Sophos Connect en Windows. Para SSL VPN con Sophos Connect, consulte además Configurar Sophos SSL VPN con Sophos Connect en Windows.

Rollback conservando el estado

No retire la autenticación anterior hasta validar piloto y rollback; conserve los perfiles antiguos de forma controlada. Si SSO falla, entre con el administrador local y restaure en Authentication > Services los servidores y su orden documentado para VPN Portal, SSL VPN e IPsec, pulsando Apply en cada servicio. Reimporte el perfil antiguo en un equipo piloto y pruebe portal, túnel, DNS y un destino interno autorizado.

No elimine la aplicación Entra, el servidor nuevo, los grupos importados ni el secret hasta que acceso y registros confirmen la recuperación. Si Device Access se amplió solo para SSO, restáurelo después para no bloquear simultáneamente la ruta VPN recuperada.

Operación y seguridad

Entra ID SSO desplaza la seguridad de inicio de sesión más hacia el proveedor de identidad. Esto es bueno si Entra ID se gestiona correctamente. Es problemático si los grupos, el Acceso Condicional o los secretos de la aplicación se gestionan de manera descuidada.

En operación, estos puntos deben verificarse regularmente:

• El secreto de la aplicación no expira inesperadamente.
• Los grupos Entra solo contienen usuarios autorizados.
• El Acceso Condicional se aplica para el Acceso Remoto.
• Los accesos de emergencia y de respaldo están documentados.
• El Portal VPN es accesible solo en la medida necesaria.
• Las versiones de Sophos Connect están actualizadas.
• Los perfiles de cliente antiguos se retiran después de los cambios.
• Los registros se verifican temprano en caso de problemas de inicio de sesión.

Para el lado del cliente, también debe existir un proceso de actualización propio. El artículo Verificar y actualizar de manera segura la versión del cliente Sophos Connect resume qué temas de Windows, macOS, SSO, OTP y aprovisionamiento deben verificarse antes de un despliegue.

Solución de problemas

El botón SSO no es utilizable en el cliente Sophos Connect

Si el cliente informa que SSO no está configurado, primero pruebe la conexión al servidor de Microsoft Entra ID en el firewall. Luego, en Authentication > Services, verifique si el servidor Entra ID está configurado correctamente para SSL VPN o IPsec y el Portal VPN.

El usuario no puede iniciar sesión en el Portal VPN

Entonces, SSO puede funcionar en general, pero falta el permiso de VPN. Verifique si el grupo Entra está incluido en la configuración de Acceso Remoto IPsec bajo Allowed users and groups o en SSL VPN bajo Policy members.

Solo algunos usuarios no pueden iniciar sesión

Entonces, primero verifique UPN, dirección de correo electrónico, membresía de grupo y grupo importado en el firewall. Especialmente para usuarios con direcciones de correo electrónico diferentes, nombres cambiados o cuentas migradas, la identificación técnica puede ser diferente a la esperada.

Microsoft informa un tenant o aplicación incorrecta

Entonces, a menudo no coinciden los métodos de autenticación, la aplicación Entra, Tenant ID o la selección del servidor en el firewall. Especialmente con varios servidores Entra ID, se debe verificar si el Portal VPN, SSL VPN e IPsec utilizan el mismo servidor esperado.

La redirección o el inicio de sesión termina en una página de error

Comparar FQDN, certificado, DNS público, URI de redirección y valor de gateway del archivo de aprovisionamiento. Incluso pequeñas discrepancias en el nombre de host, puerto o ruta pueden interrumpir el flujo OAuth/OIDC.

Test connection falla con un error x509

Si oauth_sso_vpn.log muestra el error x509: certificate signed by unknown authority, puede faltar una CA raíz o intermedia en la cadena de certificados hacia Microsoft Entra ID. El problema conocido NC-176806 se corrigió en SFOS 22.0 MR2 Build 546; otras cadenas de certificados incompletas o errores TLS siguen siendo posibles.

En la Advanced Shell se puede comprobar la cadena proporcionada por Microsoft:

openssl s_client -connect login.microsoftonline.com:443 -showcerts

1. Comprobar la cadena de certificados y el emisor en la salida.
2. Obtener únicamente la CA raíz o intermedia que falta de una fuente de confianza. No importar un certificado de servidor como CA.
3. Añadir y aplicar la CA en Certificates > Certificate Authority.
4. Abrir el servidor Entra ID en Authentication > Servers y volver a ejecutar Test connection.
5. Solo si la prueba sigue fallando y es aceptable una breve interrupción de los inicios VPN SSO en curso, reiniciar el servicio VPN SSO en la Advanced Shell:

service oauth_sso_vpn:restart -ds nosync

Después, volver a ejecutar Test connection. El reinicio del servicio es un último paso opcional, no la primera medida ante un error x509.

La importación de grupos no funciona

Verificar la hora del firewall, datos del tenant, permisos de la aplicación, secreto del cliente y accesibilidad de los endpoints de Microsoft. Si los grupos locales existentes no coinciden con los grupos Entra, se debe decidir si se limpian, mapean o gestionan manualmente.

La conexión está activa, pero los sistemas internos no son accesibles

Entonces, probablemente la autenticación ya no sea el error principal. Verificar IP de VPN, DNS, reglas de firewall, NAT, enrutamiento y sistema de destino. En el Log Viewer debería ser visible qué regla afecta el tráfico desde la zona VPN.

Lista de verificación

• La aplicación Entra con Client ID, Tenant ID y Client Secret está documentada.
• Las URIs de redirección para el Portal VPN y el Acceso Remoto están registradas en Entra ID.
• FQDN público, certificado y gateway de aprovisionamiento coinciden.
• El Portal VPN está permitido conscientemente bajo Device Access.
• Las URLs de inicio de sesión de Microsoft son accesibles.
• Los servicios de autenticación utilizan el servidor Entra ID correcto.
• Los grupos de VPN están importados y permitidos en las políticas de SSL/IPsec.
• UPN, dirección de correo electrónico y membresía de grupo se verificaron con un usuario de prueba.
• Sophos Connect 2.4 o posterior está en uso en Windows.
• Los perfiles de cliente se importaron nuevamente después de los cambios.
• Entra-MFA y Acceso Condicional se verificaron con un usuario de prueba.
• oauth_sso_vpn.log, Log Viewer y registros del servidor de acceso son conocidos para la solución de problemas.

Preguntas frecuentes