Configure el inicio de sesión único de Microsoft Entra ID para el portal cautivo de Sophos Firewall

Con Microsoft Entra ID SSO para portal cautivo, Sophos Firewall puede autenticar a los usuarios con Microsoft Entra ID a través del navegador antes de que las reglas de firewall basadas en usuarios entren en vigor. Esto es particularmente interesante para redes BYOD, zonas de invitados o socios, dispositivos sin detección transparente de AD o entornos donde STAS no se adapta a todos los clientes.

Es importante diferenciar: Captive Portal no es VPN Portal ni acceso remoto. El usuario ya está en la red local o Wi-Fi y se autentica en el navegador para que la firewall pueda asignar el tráfico posterior a una identidad de usuario. Para acceso remoto con Sophos Connect, el artículo separado Configurar Microsoft Entra ID SSO para Sophos Connect y VPN Portal es el adecuado.

Si Microsoft Entra ID SSO ya está configurado para VPN Portal o Sophos Connect, no hace falta automáticamente un diseño Entra completamente nuevo. En muchos casos se puede reutilizar el mismo objeto de servidor Microsoft Entra ID en la firewall. Captive Portal necesita igualmente la Captive portal URL correcta como Redirect URI, la asignación en Authentication > Services y una prueba separada de la regla de usuario posterior.

Cuando el portal cautivo con Entra ID SSO tiene sentido

El portal cautivo con Entra ID SSO tiene sentido si los usuarios inician sesión con Microsoft 365 de todos modos y el firewall necesita una identidad de usuario para ciertas redes.

Aplicaciones típicas:

• Redes BYOD o WiFi sin unirse a un dominio.
• Invitados o usuarios externos con acceso controlado a algunos destinos.
• Reglas de Internet basadas en el usuario sin STAS o SATC.
• Redes donde la autenticación transparente no es confiable.
• Escenarios de transición en los que se debería reducir la autenticación de AD local.

Para clientes Windows totalmente administrados en un dominio clásico, Captive Portal no es automáticamente la mejor solución. Allí STAS, AD SSO u otros procedimientos transparentes pueden ser más ergonómicos porque los usuarios no tienen que activar activamente un inicio de sesión en el navegador. El portal cautivo es más bien una solución alternativa o especial para dispositivos no administrados.

Portal cautivo separado, portal VPN y portal de usuario

Con Entra ID SSO, los términos del portal se confunden rápidamente. La separación es crucial para la configuración.

• Portal cautivo: Los usuarios de la red local inician sesión mediante el navegador para que se apliquen las reglas basadas en la identidad. Entra ID SSO se utiliza para iniciar sesión en el navegador y asignar el usuario.
• Portal VPN: Los usuarios de acceso remoto descargan Sophos Connect o configuraciones VPN. Entra ID SSO se utiliza aquí para el acceso remoto y el inicio de sesión en el portal.
• Portal de usuario: Este portal contiene funciones para el usuario, como OTP u opciones personales antiguas. Según el entorno, puede seguir siendo relevante para tokens u opciones de usuario.

Una descripción general está disponible en Portales de Sophos: SophosID, Central, soporte y acceso al firewall. Para Captive Portal hay que comprobar sobre todo desde qué zona se puede acceder al servicio local del firewall y qué regla de firewall procesa después el tráfico de usuario real. Configurar y probar Captive Portal en Sophos Firewall explica la configuración clásica sin el procedimiento específico de Microsoft, desde Device Access y DNS hasta la regla de usuario y Live users. Entra ID SSO añade después el App Registration, la Redirect URI y las comprobaciones OAuth/OIDC de este artículo.

Requisitos

Antes de montar conviene aclarar estos puntos:

• Sophos Firewall con una versión SFOS compatible con Microsoft Entra ID SSO.
• Un tenant comercial de Microsoft Entra. Sophos Firewall no admite esta integración SSO para tenants de Microsoft 365 GCC High.
• Microsoft Entra Tenant con permiso para registro de aplicaciones, URI de redireccionamiento, permisos de API, consentimiento de administrador y secreto de cliente.
• FQDN y certificado para el portal cautivo para que los usuarios no vean advertencias innecesarias del navegador.
• Accesibilidad de los puntos finales de inicio de sesión de Microsoft desde la red del cliente afectado.
• Captive Portal está permitido en Administration > Device access para la zona correcta.
• Los usuarios o grupos se mantienen limpios en Microsoft Entra ID.
• Las reglas del firewall utilizan los usuarios o grupos esperados.
• Un usuario de prueba y acceso alternativo están disponibles.
• La hora y NTP en el firewall y los clientes son correctos porque OAuth/OIDC depende del tiempo.
• Si Asignación requerida está activo en Microsoft Entra ID, los usuarios o grupos requeridos se asignan a la aplicación empresarial.

⚠️ El portal cautivo es un área de inicio de sesión en el firewall. Sólo debería ser accesible en las zonas donde realmente se necesita. El acceso al dispositivo y la ACL del servicio local son controles de seguridad aquí, no solo configuraciones de conexión.

Para reforzar los servicios de firewall local, es adecuado Proteger el acceso a Sophos Firewall: configurar el acceso al dispositivo correctamente. En este diseño, MFA se implementa en Microsoft Entra ID, por ejemplo mediante acceso condicional. La MFA local de Sophos Firewall no reemplaza el factor de inicio de sesión de Microsoft con Entra ID SSO. Esto suele ser mejor desde la perspectiva del usuario porque se usa la misma MFA que Microsoft 365, pero se debe planificar y probar cuidadosamente en el inquilino.

Planificar la arquitectura antes de configurar

Antes de la configuración técnica, debe decidir qué tarea debe resolver específicamente el portal cautivo. De lo contrario, rápidamente terminará con un inicio de sesión que funciona pero que no activa una regla de firewall adecuada.

Preguntas de diseño importantes:

• ¿Qué zona utiliza el Portal Cautivo?: El acceso al dispositivo y el origen de las reglas dependen de la zona.
• ¿Qué grupo de usuarios puede iniciar sesión?: El grupo Entra debe coincidir con la regla de firewall posterior.
• ¿Qué objetivos se pueden lograr después de iniciar sesión?: El portal cautivo no reemplaza la segmentación limpia.
• ¿Cuánto tiempo deben ser válidas las sesiones?: Las sesiones demasiado largas diluyen la asignación de usuarios y las sesiones demasiado cortas interrumpen las operaciones.
• ¿Qué sucede en caso de una interrupción de Entra o Internet?: Es necesario que haya un claro respaldo para los empleos críticos.
• ¿Cómo se activa el inicio de sesión?: Los usuarios necesitan una URL de portal cautivo accesible o una redirección limpia.

El portal cautivo no debe usarse como reemplazo de VLAN, zonas o reglas mínimas de firewall. El firewall conoce mejor al usuario después de iniciar sesión, pero la arquitectura de la red aún debe permanecer limpia. Configurar zonas e interfaces de Sophos Firewall es adecuado para la lógica básica de zonas.

Crear servidor Microsoft Entra ID

La configuración consta de dos partes: primero, se prepara el registro de una aplicación en Microsoft Entra ID. Luego, esta aplicación se registra como servidor de autenticación en el firewall de Sophos.

Preparar el registro de la aplicación en Microsoft Entra ID

Se debe crear un registro de aplicación independiente para el firewall en Microsoft Entra ID. Esto significa que los URI de redireccionamiento, los permisos y los secretos del cliente permanecen claramente separados de otras aplicaciones.

Proceso típico:

1. Abra el centro de administración de Microsoft Entra.
2. Abra Registros de aplicaciones > Nuevo registro.
3. Asignar un nombre descriptivo, por ejemplo Sophos-Firewall-SSO.
4. Como regla general, seleccione su propio inquilino como tipo de cuenta admitida.
5. Utilice la Plataforma Web.
6. Anote el ID de la aplicación (cliente) y el ID del directorio (inquilino).
7. Cree un secreto de cliente en Certificados y secretos y guarde inmediatamente el valor del secreto de forma segura.
8. En API permissions > Microsoft Graph > Delegated permissions, añada User.Read.All y Group.Read.All.
9. Solo si va a importar grupos con el asistente del firewall, añada también Group.Read.All en Application permissions.
10. Ejecute Grant admin consent para estos permisos.
11. En Enterprise applications > [aplicación del firewall] > Properties, establezca preferiblemente Assignment required? en Yes y asigne únicamente los usuarios o grupos autorizados.

Sin los permisos de API y el consentimiento del administrador correctos, el firewall no puede procesar correctamente los usuarios o grupos después del inicio de sesión de Microsoft. Si Assignment required? permanece en No, todos los usuarios del tenant pueden intentar acceder a los servicios de usuario del firewall; los grupos, las políticas y las reglas del firewall siguen determinando el acceso real. La asignación obligatoria reduce la superficie de inicio de sesión, pero no sustituye una autorización restrictiva en el firewall.

Según Microsoft, la asignación por grupos requiere Entra ID P1 o P2 y no incluye grupos anidados. Por tanto, pruebe con un miembro directo del grupo y no solo con un usuario de un subgrupo.

Crear o reutilizar un servidor Entra ID en Sophos Firewall

Microsoft documenta por separado el registro de aplicaciones, los URI de redireccionamiento, las asignaciones de aplicaciones y Conditional Access. Consulte estas fuentes primarias si cambian las etiquetas o los requisitos del tenant en el portal de Entra.

Dirija Conditional Access a la Enterprise Application y evalúe primero la directiva en modo Report-only con un usuario piloto. Antes de activarla, compruebe el resultado con What If y los registros de inicio de sesión de Entra, y excluya las cuentas de acceso de emergencia documentadas. Mantenga abierta una sesión de administración del firewall y disponible el método de autenticación anterior hasta probar correctamente un usuario permitido, uno denegado y MFA; así se evita un bloqueo por una directiva incorrecta.

La ruta del menú en Sophos Firewall es:

Authentication > Servers

Proceso básico:

1. Abra Add.
2. Seleccione Microsoft Entra ID SSO como Server type.
3. Asignar un nombre descriptivo, por ejemplo Entra-SSO-Firewall.
4. Introduzca Application (client) ID de la aplicación Entra.
5. Introduzca Directory (tenant) ID.
6. Introduzca Client secret.
7. Establezca conscientemente Fallback user group y manténgalo lo más restrictivo posible.
8. Ejecute Test connection.
9. Guardar.

El grupo de reserva se aplica cuando el grupo Entra de un usuario no existe en el firewall. No debe recibir acceso amplio y no es un acceso de emergencia ni una autenticación alternativa durante una interrupción de Entra.

En Redirect URI, indique el FQDN o la dirección IP de producción; el firewall generará las URL de servicio que se deben copiar sin cambios en Entra ID. Test connection comprueba la conectividad de red, los Application permissions y la validación del certificado TLS.

⚠️ Los client secrets son datos de acceso productivos. La fecha de caducidad, la rotación y la responsabilidad deben documentarse. Un secret caducado suele parecer un problema normal de inicio de sesión desde la perspectiva del usuario, pero en realidad es un problema de configuración u operación.

Para rotarlo con poca interrupción, cree un secret nuevo antes de que caduque, introduzca su Value en el firewall y ejecute Test connection seguido de un inicio de sesión en Captive Portal. Mantenga válido el secret anterior como vía de retorno hasta que ambas pruebas finalicen correctamente y solo entonces elimínelo en Entra ID. No incluya valores de secrets en capturas, tickets ni exportaciones de configuración.

Ingrese los URI de redireccionamiento correctamente

Copie sin cambios en la App Registration de Microsoft Entra ID el URI de redireccionamiento generado por el firewall. El protocolo, el nombre de host, el puerto, la ruta e incluso la barra final deben coincidir exactamente. El certificado del portal no forma parte del URI, pero debe ser válido para el mismo nombre de host y de confianza para los clientes.

Sophos Firewall muestra las URL de servicio requeridas en el servidor Entra ID. La URL del portal cautivo es particularmente relevante para este artículo. Si también se utiliza WebAdmin o Acceso Remoto con Entra ID SSO, estos servicios tienen sus propias URL:

• URL de la consola de administración web: Entra ID SSO para WebAdmin Console.
• URL del portal cautivo: Entra ID SSO para portal cautivo en la red local.
• Portal VPN y URL de acceso remoto: Entra ID SSO para VPN Portal y Sophos Connect.

Si el mismo servidor Entra ID ya se usa para Remote Access, se añade la Captive portal URL a las Redirect URIs existentes en la aplicación Entra. Captive Portal debe probarse igualmente por separado, porque el flujo de login, Device Access, la correspondencia de grupos y la regla de firewall posterior tienen errores típicos distintos a Sophos Connect o VPN Portal.

Establecer el método de autenticación del portal cautivo

Después de crear el servidor Entra, el método de autenticación para Captive Portal debe apuntar al servidor correcto.

El área relevante se encuentra en:

Authentication > Services

Para comprobar:

1. Abra el área Firewall authentication methods.
2. Agregue o arrastre el servidor Microsoft Entra ID a la posición correcta.
3. Conserve otros servidores de autenticación únicamente si sirven como respaldo deliberado.
4. Aplique el cambio con Aplicar.
5. Realice un inicio de sesión de prueba con un solo usuario.

Sophos Firewall solo admite un servidor Microsoft Entra ID por método de autenticación. Por tanto, no se pueden apilar varios tenants o aplicaciones Entra en la misma lista Firewall authentication methods.

Si hay varios métodos de autenticación activos en paralelo, debe quedar claro qué servidor es responsable de cada grupo de usuarios. Para un mismo usuario debe utilizarse, siempre que sea posible, una sola fuente de autenticación. En una versión de firmware afectada por NC-167128, el firewall puede rechazar la sesión con no permission si un usuario cambia de Entra ID SSO al inicio de sesión AD local y después reutiliza un token de Entra anterior. Este funcionamiento mixto es más difícil de probar y solo debe utilizarse de forma deliberada y documentada.

Además, debe comprobar en Authentication > Web authentication cómo se abre Captive Portal en el navegador. HTTPS es importante para Entra ID SSO. La opción Use insecure HTTP instead of HTTPS no debe activarse porque el flujo Entra-OAuth a través de HTTP no se admite adecuadamente y sería innecesariamente inseguro.

Lo siguiente es útil para la operación:

1. Abra el portal cautivo en una nueva ventana del navegador.
2. Mantenga abierta la ventana del portal cautivo durante la sesión.
3. Haga que los usuarios cierren sesión conscientemente a través del portal cautivo si se va a cancelar la asociación.
4. Después de iniciar sesión, verifique en Actividades actuales > Usuarios en vivo si el usuario está visible.

Las opciones automáticas de cierre de sesión por inactividad o al cerrar la pestaña del navegador no se aplican actualmente a Microsoft Entra ID SSO. En dispositivos compartidos, la ventana del portal permanece abierta hasta que el usuario cierra sesión expresamente; cerrar una pestaña no se considera un final fiable de la sesión.

Dependiendo de la interfaz y el certificado, la URL estándar https://<Firewall-IP>:8090 también puede ayudar para las pruebas. Un FQDN limpio con un certificado adecuado es mucho más agradable para una operación productiva.

Verifique el acceso al dispositivo y la accesibilidad al portal

Captive Portal es un servicio local del firewall. Una regla de firewall normal por sí sola no permite este acceso. La accesibilidad se controla en Administration > Device access para la zona correspondiente.

Deberías comprobar:

• El portal cautivo solo se permite en las zonas requeridas.
• Esto significa que no es casualidad que WebAdmin y SSH sean ampliamente accesibles.
• El certificado y el FQDN coinciden con la URL del usuario.
• DNS en la red del cliente resuelve correctamente el nombre del portal.
• Las reglas de excepción de ACL de servicio local solo se establecen cuando son realmente necesarias.

Si no se puede acceder al portal cautivo desde una red, no debe crear primero una regla de permiso normal. La causa suele ser el acceso al dispositivo, la ACL del servicio local, el DNS, el certificado o la asignación de zonas incorrecta.

Tener en cuenta el inicio de sesión de Microsoft y el filtro web

El cliente debe acceder a las páginas de inicio de sesión de Microsoft y a los recursos relacionados durante el inicio de sesión. De lo contrario, en redes restrictivas, el flujo de SSO puede detenerse en un punto que a los usuarios les parece un error de firewall o del navegador.

Para comprobar:

• La resolución DNS para dominios de inicio de sesión de Microsoft funciona.
• Se permite HTTPS a puntos finales de inicio de sesión de Microsoft.
• El filtro web, la inspección TLS o el proxy no bloquean la página de inicio de sesión.
• El tiempo en el firewall y el cliente es plausible.
• Las cookies del navegador no quedan inutilizables mediante una política estricta.

En entornos restrictivos, configure como hosts FQDN la lista completa documentada por Sophos para SFOS 22, en lugar de deducirla de unas pocas solicitudes observadas:

• *.aadcdn.microsoftonline-p.com
• *.login.live.com
• login.microsoftonline.com
• *.login.microsoftonline.com
• *.logincdn.msftauth.net
• *.microsoftonline-p.com
• *.microsoftonline.com
• *.msauth.net
• aadcdn.msftauth.net
• login.microsoft.com
• account.activedirectory.windowsazure.com
• *.aadcdn.msauthimages.net
• *.aadcdn.msftauthimages.net
• *.aadcdn.msftauth.net
• browser.events.data.msn.com
• ent-nfc-api.msn.com
• img-s-msn-com.akamaized.net
• ntp.msn.com
• edge-consumer-static.azureedge.net
• msedge.b.tlu.dl.delivery.mp.microsoft.com

Cree los objetos y la regla de forma explícita en SFOS:

1. Vaya a Hosts and services > FQDN host y seleccione Add. Para cada entrada anterior, indique un Name único, introduzca el valor de la lista en FQDN y guarde el objeto.
2. Vaya a Hosts and services > FQDN host group y seleccione Add. Indique un Name, utilice Add new item, añada como miembros todos los hosts FQDN creados en el paso 1 y guarde el grupo.
3. Vaya a Rules and policies > Firewall rules > IPv4, seleccione Add firewall rule > New firewall rule y establezca Action en Accept. Limite Source zones y Source networks and devices al segmento cliente afectado, establezca Destination zones en WAN, seleccione el grupo de hosts FQDN en Destination networks y únicamente DNS y HTTPS en Services. Coloque la regla en la posición necesaria, habilite Log firewall traffic y restrinja usuarios, horario, origen y destino todo lo que permita el flujo de inicio de sesión.

Después de guardar, confirme que cada host FQDN resuelve direcciones actuales y que el grupo contiene los 20 objetos. Genere un inicio de sesión de prueba desde la red cliente delimitada y compruebe que aumenta el contador de coincidencias de esta regla y que su Rule ID y la acción Accept aparecen en Log Viewer. Si el contador permanece en 0, revise la resolución y pertenencia de los objetos, la zona/red de origen, la zona de destino, los servicios y el orden de las reglas antes de ampliar su alcance. El modo Direct Web Proxy requiere además excepciones de URL con expresiones regulares; la lista FQDN por sí sola no las sustituye.

Si el filtro web, un proxy o una inspección TLS entran en vigor antes de iniciar sesión, estos objetivos no deben descifrarse ni bloquearse innecesariamente.

Crear la excepción de Direct Web Proxy

Para Direct Web Proxy, cree la excepción correspondiente como se describe en Excepciones web:

Sobre el origen de los patrones: Esta lista es un ejemplo adaptado basado en la documentación de Sophos para SFOS 22, no una reproducción literal de todos los patrones. El octavo patrón, para msauth.net, figura allí como ^([A-Za-z0-9.-]*\.)?.msauth.net\.?/ (cita de la fuente, no recomendada como modelo para copiar). Aquí se mantiene en su lugar ^([A-Za-z0-9.-]*\.)?msauth\.net\.?/: la adaptación local elimina el punto adicional sin escapar delante de msauth y escapa el punto entre msauth y net. En la sintaxis habitual de las expresiones regulares, un punto sin escapar suele representar cualquier carácter excepto un salto de línea, mientras que \. representa un punto literal. Esto explica únicamente la sintaxis; no es una corrección confirmada por el fabricante ni una prueba de compatibilidad comprobada con el motor de expresiones regulares de Sophos. Los otros 13 patrones permanecen sin cambios. Antes de utilizarlos en producción, se deben comprobar los patrones en la versión de SFOS utilizada con un inicio de sesión de Entra permitido y una URL que no coincida; si el comportamiento no está claro, solicite primero una aclaración a Sophos en lugar de adoptar sin comprobar el patrón llamativo de la fuente.

1. Abra Web > Exceptions y seleccione Add.
2. Introduzca un nombre descriptivo y seleccione URL pattern matches.
3. Utilice Search y Add para cada uno de los siguientes 14 patrones regex de este ejemplo adaptado:

• login\.microsoftonline\.com\.?/
• ^([A-Za-z0-9.-]*\.)?login.live.com\.?/
• aadcdn\.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn\.microsoftonline-p\.com\.?/
• ^([A-Za-z0-9.-]*\.)?login.microsoftonline.com\.?/
• ^([A-Za-z0-9.-]*\.)?logincdn.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msauthimages.net\.?/
• ^([A-Za-z0-9.-]*\.)?msauth\.net\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msftauthimages.net\.?/
• ^([A-Za-z0-9.-]*\.)?microsoftonline\.com\.?/
• ^([A-Za-z0-9.-]*\.)?microsoftonline-p.com\.?/
• ^([A-Za-z0-9.-]*\.)?aadcdn.msftauth.net\.?/
• ^([A-Za-z0-9.-]*\.)?account.activedirectory.windowsazure.com\.?/
• login\.microsoft\.com\.?/

4. Seleccione todos los checks y actions para estos patrones.
5. Guarde la excepción.

Confirme que la Web Exception guardada está habilitada. Durante un inicio de sesión de prueba, compruebe en los registros web/proxy que la URL de Microsoft solicitada coincide con el patrón previsto y que se aplica la excepción; si no es así, compare carácter por carácter el nombre de host y la ruta registrados con la expresión regular de una sola barra inversa, y revise el alcance y el orden de la excepción.

Limite la excepción tanto como permitan las redes cliente y el flujo de inicio de sesión de Entra; no debe convertirse en una excepción global para los servicios de Microsoft. Valide ambos sentidos: un inicio de sesión de Entra permitido debe completarse, mientras que una URL de Microsoft no relacionada que no coincida debe seguir la política web y TLS normal. Si esa prueba negativa también queda exceptuada, reduzca el alcance antes del despliegue.

Si la Protección web o la Inspección TLS están activas, el inicio de sesión con un usuario de prueba debe observarse en el visor de registros. A veces, el problema no es el portal cautivo en sí, sino una política web, una excepción TLS o una red de cliente que no llega completamente a los puntos finales de Microsoft.

Probar grupos de usuarios y reglas de firewall

Después de un inicio de sesión exitoso en el portal cautivo, la regla de firewall real debe ver al usuario o grupo en el tráfico. Esta es la prueba práctica más importante.

Proceso típico:

1. Verifique los usuarios en Microsoft Entra ID.
2. Compare UPN, dirección de correo electrónico y membresía de grupo.
3. Marque el grupo Entra en Sophos Firewall.
4. Active Match known users y Use web authentication for unknown users en la regla de usuario.
5. Realice el inicio de sesión en el portal cautivo con el usuario de prueba.
6. Luego, active el tráfico de usuarios reales, por ejemplo HTTPS, a un destino permitido.
7. En el Visor de registros, verifique si el usuario, grupo, zona de origen, red de origen y ID de regla coinciden con la regla esperada.

Un inicio de sesión exitoso en el navegador solo prueba la autenticación. No prueba que se aplique la regla del usuario posterior. Si el contador de reglas permanece en 0 o no hay ningún usuario visible en el visor de registros, debe usar el flujo de La regla de Sophos Firewall no funciona: compruebe las causas.

Correspondencia de grupos y antigua limitación de Primary Group

Para las reglas de usuario, el grupo Entra previsto debe existir en el firewall. Después del inicio de sesión, compruebe en Current activities > Live users y en Log Viewer a qué grupo se ha asignado el usuario y qué Rule ID procesa el tráfico.

En SFOS 20.0 GA Build 222 existía una limitación conocida: con NC-167130, el acceso a Internet mediante un grupo secundario de Entra no funcionaba; la regla debía contener la Primary Group o el usuario individual. Sophos indica SFOS 21.5 MR2 Build 323 y SFOS 22.0 MR1 Build 490 como versiones corregidas. En builds actuales, la Primary Group ya no es un requisito general de diseño.

Por lo tanto, antes de una implementación, debe registrar lo siguiente para cada usuario de prueba:

• Grupo Entra: Se conocen el grupo de destino y la pertenencia del usuario.
• Grupo en Sophos Firewall: El mismo grupo se importa o asigna correctamente.
• Regla de firewall: El grupo previsto está incluido en la condición de usuario o grupo.
• Tráfico de prueba después del inicio de sesión: Log Viewer muestra el usuario, el grupo, la Rule ID y la acción esperada.
• Build antigua afectada: Utilice la Primary Group o una regla de prueba específica para el usuario y planifique la actualización.

Esto no afecta a Sophos Connect VPN con Microsoft Entra ID SSO. Para el acceso remoto, se debe verificar el proceso separado para SSO de Microsoft Entra ID para Sophos Connect y VPN Portal.

Validación después del lanzamiento

Para la validación, no basta con comprobar si aparece la página de inicio de sesión de Microsoft.

• Abrir la URL del portal cautivo desde la red del cliente: El navegador muestra el inicio de sesión de Entra esperado o la redirección de Sophos.
• Iniciar sesión con usuario permitido: Inicio de sesión exitoso, el usuario aparece en el firewall.
• Iniciar sesión con usuario no permitido: El acceso está comprensiblemente denegado.
• Prueba de regla de grupo: El usuario de prueba cumple con la regla de usuario esperada.
• Tráfico de usuarios después de iniciar sesión: regla de firewall correcta que coincide con la referencia del usuario.
• Flujo de sesión: Después de un tiempo de espera, deberá iniciar sesión nuevamente.
• Inicio de sesión de Microsoft bloqueado: El visor de registros o los registros web muestran un motivo comprensible.
• Escenario alternativo: Pruebe el método de autenticación anterior documentado; el fallback user group por sí solo no permite autenticarse durante una interrupción de Entra.

Especialmente con las redes BYOD, debes realizar pruebas con múltiples navegadores y dispositivos. Los modos de navegación privada, las cookies de terceros bloqueadas, los inicios de sesión guardados antiguos o varias cuentas de Microsoft en el mismo dispositivo pueden producir resultados diferentes.

Reversión segura

Antes de realizar cambios, anote el orden de Authentication > Services > Firewall authentication methods, la configuración de Authentication > Web authentication y las reglas de firewall afectadas. Una captura o una exportación de la configuración evita tener que reconstruir el estado anterior de memoria.

Si el inicio de sesión con Entra interrumpe el servicio, restaure primero el método de autenticación anterior en su posición original. Devuelva solo Match known users y Use web authentication for unknown users a los valores registrados antes del despliegue. Después, compruebe un inicio de sesión con el método anterior, Current activities > Live users y tráfico real que deba coincidir con la regla.

No elimine de inmediato la aplicación Entra, el objeto de servidor, los grupos importados ni el secreto de cliente: también pueden utilizarlos WebAdmin, VPN Portal o Remote Access. Quite la Captive portal URL de la App Registration únicamente tras confirmar que ningún servicio ni otro nodo del firewall la utiliza.

Solución de problemas

No se puede acceder al portal cautivo

Primero verifique Administration > Device access para la zona afectada. Luego verifique el DNS, el certificado, el FQDN del portal, la ACL del servicio local y la asignación de zonas. Si el acceso va al propio firewall, una regla de firewall normal no es el primer punto de control.

El inicio de sesión de Microsoft se inicia pero no regresa

Compare el URI de redireccionamiento, el FQDN, el certificado y el puerto. La URL exacta que utiliza Sophos Firewall para el portal cautivo debe almacenarse en Microsoft Entra ID. Las reglas de inspección proxy o TLS también pueden interferir con la devolución.

Cuando Microsoft muestra el error AADSTS50011, el URI de redireccionamiento en el registro de la aplicación generalmente no coincide con la URL que utiliza el firewall. Luego se deben comparar exactamente el protocolo, FQDN, puerto y ruta.

Aparece un error interno después de iniciar sesión en Microsoft

Un 500 Internal Server Error o un error genérico similar después de un inicio de sesión exitoso en Microsoft a menudo indica una falta de permisos de Microsoft Graph, una falta de consentimiento del administrador o un problema con el secreto del cliente. Luego debe verificar los permisos de API, el consentimiento del administrador, la validez del secreto y la asignación de la aplicación empresarial en Microsoft Entra ID.

Si oauth_sso_captive.log muestra en cambio x509: certificate signed by unknown authority, primero se lee la cadena de certificados de Microsoft alcanzada por el firewall y solo se importa desde una fuente de confianza una CA raíz o intermedia cuya ausencia se haya confirmado:

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

Después se vuelve a ejecutar Test connection. Solo si la cadena de CA ya está corregida y el error persiste, el reinicio local en el nodo del servicio Captive SSO documentado por Sophos es un último paso opcional durante una ventana de mantenimiento:

service oauth_sso_captive:restart -ds nosync

A continuación se repiten Test connection y un nuevo inicio de sesión en Captive Portal. El reinicio del servicio no sustituye la verificación de certificados ni un Admin Consent ausente.

El nombre de usuario y la contraseña no funcionan directamente

Entra ID SSO es un navegador y un flujo OAuth/OIDC. Los usuarios no inician sesión directamente en el firewall con credenciales clásicas, sino que son redirigidos a Microsoft. Si un cliente o flujo solo admite nombre de usuario y contraseña sin redirección del navegador, este método no sirve.

MFA no aparece o aparece de manera diferente a lo esperado

Con Entra ID SSO, MFA se controla en Microsoft Entra ID. El firewall local MFA no es el punto de control correcto para este flujo de SSO. Si se requiere MFA, debe verificar el acceso condicional, los grupos de usuarios, las exclusiones y los usuarios de prueba en Microsoft Entra ID.

El usuario ve no permission o es rechazado después de una operación prolongada

Este error coincide con NC-167128 en SFOS 21.0 GA Build 169: si el mismo usuario utiliza primero Entra ID SSO, después AD local en la red interna y finalmente vuelve a usar el token de Entra anterior, puede aparecer no permission. El problema está corregido a partir de SFOS 21.5 MR2 Build 323 o SFOS 22.0 MR1 Build 490.

En la versión afectada, primero se deben borrar las cookies del navegador. Si el problema aparece en Sophos Connect, se debe ejecutar Force SSO re-login; la ruta se explica en Configurar Microsoft Entra ID SSO para Sophos Connect y VPN Portal. A largo plazo, es más limpio utilizar siempre Entra ID o AD local para el mismo usuario y actualizar a una versión de firmware corregida.

El inicio de sesión funciona, pero la regla de usuario no coincide

Entonces el portal cautivo probablemente ya no sea el único problema. Verifique la zona de origen, la red de origen, el grupo de usuarios, la posición de la regla y el visor de registros. A menudo, una regla más general está por encima de la regla del usuario o el tráfico proviene de una red diferente a la esperada.

Compruebe además que el grupo Entra previsto esté importado y que el usuario esté asignado a él en el firewall. Solo en SFOS 20.0 GA Build 222, afectado por NC-167130, la regla debe contener la Primary Group o el usuario individual para resolver este error.

Sólo los usuarios individuales se ven afectados

Compare UPN, dirección de correo electrónico, nombre para mostrar, membresía de grupo y grupo importado. Con Entra ID SSO, no debe asumir que el nombre visible y el identificador técnico son idénticos. Si la dirección de correo electrónico y el UPN divergen históricamente, es fácil que surjan errores de mapeo.

¿Qué registros ayudan?

Para Captive Portal con Entra ID SSO, oauth_sso_captive.log es especialmente relevante. También ayudan Log Viewer con el módulo Authentication, access_server.log y, según el problema posterior, los registros web, de firewall o de autenticación. La correspondencia de los archivos más importantes se encuentra en Solución de problemas de Sophos Firewall: servicios y registros.

Lista de verificación

• El caso de uso del portal cautivo es claro: BYOD, invitados, dispositivos no administrados o respaldo.
• El FQDN y el certificado del portal cautivo están limpios.
• Se documenta la aplicación Microsoft Entra ID con URI de redireccionamiento, ID de cliente, ID de inquilino y secreto de cliente.
• Se establecen los permisos de Microsoft Graph API y el consentimiento del administrador.
• Las asignaciones de aplicaciones empresariales se marcan si Asignación requerida está activo.
• Client Secret tiene fecha de vencimiento, propietario y proceso de rotación.
• El firewall tomó el control del URI de redireccionamiento del portal cautivo y lo ingresó exactamente en Entra ID.
• Authentication > Services utiliza el servidor Entra correcto para Captive Portal.
• Authentication > Web authentication utiliza HTTPS y la configuración adecuada de la ventana del navegador.
• Administration > Device access solo permite Captive Portal en las zonas requeridas.
• Se puede acceder a los puntos finales de inicio de sesión de Microsoft desde la red del cliente.
• El filtrado web y la inspección TLS no bloquean el flujo de SSO.
• MFA y acceso condicional se planifican y prueban en Microsoft Entra ID.
• Se ha comprobado la correspondencia entre el grupo de Entra y el grupo del firewall.
• El grupo Entra previsto está importado y se evalúa realmente para el usuario de prueba.
• El usuario de prueba puede iniciar sesión y luego alcanzar la regla de firewall esperada.
• El visor de registros muestra el usuario, el ID de la regla y la acción.
• oauth_sso_captive.log y access_server.log son ​​conocidos por sus casos de soporte.
• Se documenta el respaldo en caso de falla de Entra o Portal.

Preguntas frecuentes