Ir al contenido
Avanet

Configurar Microsoft Entra ID SSO para WebAdmin de Sophos Firewall

Sophos Firewall

Para usar Microsoft Entra ID SSO en WebAdmin hacen falta cuatro ajustes coherentes: un grupo o rol de aplicación de Entra, un perfil local de Device Access, la Web admin console URL exacta como Redirect URI y el servidor de Entra en Administrator authentication methods. Solo esta cadena completa convierte a un usuario autenticado correctamente en Entra en un administrador del firewall con los permisos previstos.

Si el entorno utiliza TACACS+ en lugar de OAuth para la administración central de dispositivos, se aplica el procedimiento separado TACACS+ para administradores de Sophos Firewall. A diferencia de Entra Role Mapping, TACACS+ no asigna automáticamente el perfil local en este flujo.

⚠️ Antes de activarlo: Mantén abierta una sesión local de administrador, prueba el admin local desde la red de gestión y conoce el acceso por consola o Device Console. SSO y Entra MFA no justifican exponer WebAdmin ampliamente en la zona WAN. No des prioridad a Entra en producción hasta que funcionen el inicio de sesión piloto, los permisos y la vía local de recuperación.

WebAdmin SSO en ocho pasos

  1. Comprueba el FQDN de WebAdmin, DNS, certificado, hora del sistema y acceso restringido desde la red de gestión.
  2. Prepara los perfiles de administrador necesarios en Profiles > Device access.
  3. En Microsoft Entra ID, crea una aplicación Single-Tenant propia con un administrador piloto, un rol de aplicación o grupo de seguridad y un Client Secret supervisado.
  4. En Authentication > Servers, crea un servidor de tipo Microsoft Entra ID SSO o amplía el servidor existente.
  5. Establece User type en Administrator y asigna los roles o grupos de Entra a los perfiles locales en el orden correcto.
  6. Registra la Web admin console URL que muestra el firewall como Redirect URI exacta de la aplicación de Entra y completa correctamente Test connection.
  7. Activa el servidor de Entra en Authentication > Services > Administrator authentication methods, desplázalo hacia arriba y selecciona Apply.
  8. En una ventana privada del navegador, prueba por separado un administrador piloto, un usuario sin asignación, los permisos efectivos y el fallback local.

La función está disponible desde SFOS 19.5 GA Build 197. El procedimiento y las limitaciones descritos aquí corresponden a SFOS 22.

Qué controla cada nivel

WebAdmin SSO combina varios controles que pueden confundirse fácilmente:

  • Device Access y Local Service ACL determinan desde qué redes se puede acceder a la consola WebAdmin.
  • Microsoft Entra ID autentica al usuario y proporciona información sobre roles o grupos en el token.
  • Role mapping en el firewall asigna el primer valor coincidente del token a un perfil local de administrador.
  • El perfil de Device Access determina qué menús no puede utilizar el administrador y cuáles puede consultar o modificar.
  • Administrator authentication methods activa el servidor de Entra para el inicio de sesión en WebAdmin.

Una regla de firewall normal no habilita WebAdmin. A la inversa, una página de inicio de sesión accesible tampoco otorga permisos de administrador. Device Access y Local Service ACL en Sophos Firewall explica cómo restringir de forma segura el acceso desde la red.

Si no hay ningún Role mapping coincidente, la autenticación con Entra ID puede completarse correctamente. Sin embargo, SFOS crea la cuenta solo como usuario normal y deniega el acceso a WebAdmin. No se trata de un error del navegador, sino de una asignación inexistente de permisos administrativos.

Grupos de Entra o roles de aplicación

SFOS admite ambas variantes:

  • Los grupos de seguridad son sencillos si la organización ya gestiona los permisos mediante grupos con nombres claros. El nombre del grupo debe coincidir exactamente en el mapping.
  • Los roles de aplicación se aplican específicamente a la aplicación del firewall. En el mapping se utiliza el Value exacto del rol, no solo su nombre para mostrar.

Los roles específicos de la aplicación facilitan la trazabilidad en nuevas integraciones administrativas. Los grupos de seguridad siguen siendo una alternativa adecuada si sus pertenencias ya se aprueban, revisan y documentan correctamente. No conviene mezclar ambos modelos sin control.

SFOS evalúa los mappings de arriba abajo y utiliza la primera coincidencia. Por tanto, las asignaciones Full Access y Read-only deben excluirse mutuamente. Si se detecta un solapamiento, corrige primero las asignaciones de Entra y vuelve a probar ambos roles. El orden del mapping no debe utilizarse como modelo de permisos.

Planificar el ejemplo y los requisitos previos

El siguiente ejemplo utiliza valores de documentación. Sustitúyelos por los de tu entorno:

  • FQDN de WebAdmin: fw01.example.com
  • Aplicación de Entra: Sophos Firewall - FW01 - WebAdmin
  • Rol de aplicación Full Access: sfosAdminFull
  • Rol de aplicación Read-only: sfosAdminReadOnly
  • Perfil local Full Access: Administrator
  • Perfil local Read-only: Entra-WebAdmin-ReadOnly

example.com es un dominio reservado para ejemplos. El FQDN de producción debe resolver al firewall correcto desde la red de gestión y coincidir con el certificado de WebAdmin utilizado. Para mantener separados los ciclos de permisos y cambios, lo más claro es usar una aplicación de Entra propia con su propio objeto de servidor en el firewall para cada integración WebAdmin. Es posible compartir una aplicación, pero eso vincula a administradores, usuarios VPN y usuarios de portales a las mismas asignaciones de aplicación.

Antes del cambio también debe cumplirse lo siguiente:

  • Un segundo administrador local o el admin local funciona con independencia de Entra ID.
  • La contraseña, la vía de recuperación y el acceso por consola de la cuenta de emergencia están documentados. Si aún no se ha probado este procedimiento, Restablecer la contraseña de administrador de Sophos Firewall ayuda a prepararlo de forma segura.
  • La sesión actual del administrador permanece abierta durante el cambio.
  • El firewall tiene la hora correcta y puede acceder a los endpoints necesarios de Microsoft mediante DNS y HTTPS.
  • El FQDN de WebAdmin utiliza un certificado de confianza con la cadena completa.
  • WebAdmin solo es accesible desde redes de gestión, mediante VPN o desde orígenes permitidos expresamente.
  • El propietario y la fecha de caducidad del Client Secret están documentados.
  • Los usuarios de un mismo dominio no se sincronizan simultáneamente mediante Active Directory y Microsoft Entra ID. Ambos servidores pueden existir, pero antes del cambio debe estar claro qué directorio administra esos usuarios en el firewall.

Configurar la hora del sistema y NTP e Importar y asignar certificados ofrecen ayuda con la hora y los certificados.

Preparar los perfiles de Device Access

Los perfiles se crean antes de cambiar a SSO para que cada valor de Entra apunte de inmediato a permisos definidos. Configurar de forma segura administradores y perfiles en Sophos Firewall explica el diseño general y la validación segura de perfiles de administrador locales; aquí solo se describe la asignación específica de Entra.

Para el acceso completo puede utilizarse el perfil integrado Administrator. Debe limitarse al menor número de personas necesario. Para operaciones, auditoría o helpdesk suele ser mejor un perfil propio:

  1. Abre Profiles > Device access.
  2. Selecciona Add.
  3. Introduce, por ejemplo, el nombre Entra-WebAdmin-ReadOnly.
  4. Establece cada menú necesario en Read-only.
  5. Deja en None las áreas que no se necesiten.
  6. Concede Read-write solo donde la función requiera realmente permisos de escritura.
  7. Guarda el perfil y vuelve a contrastarlo con las tareas reales del equipo.

Un nombre Read-only no convierte por sí solo el perfil en solo lectura. Los ajustes None, Read-only y Read-write de la matriz de permisos determinan el acceso efectivo. Los submenús se pueden configurar con mayor precisión al desplegarlos.

Preparar la aplicación de Entra y los roles de administrador

Si ya existe una aplicación de Entra bien documentada para VPN o Captive Portal, el mismo servidor de Entra ID también puede utilizarse para WebAdmin. La Redirect URI, los roles de administrador y las pruebas siguen siendo específicos de cada servicio. Entra ID SSO para Sophos Connect y el Portal VPN explica la base común de aplicación y servidor; para los usuarios locales del navegador se aplica el procedimiento independiente Entra ID SSO para Captive Portal.

En una aplicación compartida, asigna todos los grupos autorizados de administradores, VPN y portales antes de activar Assignment required y prueba después todos los servicios utilizados. Una aplicación WebAdmin dedicada con su propio objeto de servidor de Entra resulta más clara si los permisos administrativos, las rotaciones de secretos y los despliegues deben ser independientes.

Para una integración nueva, la configuración actual de Sophos incluye:

  1. En Microsoft Entra ID > App registrations, crea una aplicación Single-Tenant propia para el firewall.
  2. Añade los permisos delegados de Microsoft Graph User.Read.All y Group.Read.All.
  3. Para importar grupos, añade también Group.Read.All como Application Permission.
  4. Concede Admin Consent para los permisos.
  5. En Certificates & secrets, crea un Client Secret, guarda inmediatamente su Value de forma segura y supervisa la fecha de caducidad.
  6. En App roles, crea sfosAdminReadOnly y, solo si se necesita, sfosAdminFull.
  7. En Users and groups de la Enterprise Application correspondiente, asigna el administrador piloto o un grupo piloto controlado al rol adecuado.
  8. En una aplicación WebAdmin dedicada, activa Assignment required como control de acceso adicional y asigna únicamente los administradores piloto o grupos de administradores previstos. Se trata de una recomendación de seguridad de Avanet, no de un requisito técnico de SFOS.

En lugar de roles de aplicación pueden utilizarse grupos de seguridad específicos, como SFOS-FW01-WebAdmin-Full y SFOS-FW01-WebAdmin-ReadOnly. Los grupos generales de TI o Microsoft 365 son demasiado amplios para los permisos de administrador del firewall y dificultan las revisiones posteriores.

El proveedor de identidad aplica MFA en este inicio de sesión. Sophos Firewall MFA no se puede añadir al mismo flujo de Entra SSO. Por tanto, Conditional Access debe probarse específicamente para la aplicación del firewall, no solo de forma general para Microsoft 365. MFA para Sophos Firewall explica las diferencias con Sophos OTP.

Configurar el servidor de Entra ID en el firewall

En Authentication > Servers, abre un servidor de Microsoft Entra ID existente o crea uno nuevo con Add > Microsoft Entra ID SSO.

Configurar el servidor y la Redirect URI

  1. Introduce un Server name inequívoco.
  2. Pega el Application (client) ID de App Registration.
  3. Pega el Directory (tenant) ID.
  4. Introduce el Value del Client Secret guardado anteriormente.
  5. Elige de forma consciente el fallback user group. Controla los servicios de usuario y no sustituye a un perfil de administrador.
  6. En Redirect URI, comprueba o establece manualmente el FQDN de WebAdmin.
  7. Copia completa la Web admin console URL mostrada.

No construyas por tu cuenta la Redirect URI a partir del nombre de host, el puerto y una supuesta ruta de callback. En la aplicación de Entra, abre App registrations > Application > Authentication > Add a platform > Web y añade exactamente la URL que muestra SFOS.

Al editar un firewall individual mediante Sophos Central, el nombre de host del firewall debe establecerse manualmente. La URL de Central Reverse SSO que se muestra automáticamente no es la Redirect URI de WebAdmin del appliance.

A continuación, ejecuta Test connection. La prueba comprueba la conexión de red, los permisos de la aplicación y la validación del certificado TLS. Mientras falle, no cambies la autenticación de los administradores.

Asignar roles o grupos a perfiles

  1. Establece User type en Administrator. El ajuste User solo activa servicios de usuario y no basta para WebAdmin.
  2. En Role mapping, selecciona el Identifier type:
    • Roles para el valor exacto del rol de aplicación, por ejemplo sfosAdminReadOnly;
    • Groups para el nombre exacto del grupo de Entra.
  3. En Value, introduce sin cambios el valor del rol o el nombre del grupo.
  4. En Profile, selecciona el perfil local, por ejemplo Entra-WebAdmin-ReadOnly.
  5. Añade más mappings y revisa conscientemente su orden.
  6. Guarda la configuración.

Las asignaciones se evalúan de arriba abajo y se aplica la primera coincidencia. Por tanto, las pertenencias a sfosAdminFull y sfosAdminReadOnly deben excluirse mutuamente. Si un usuario pertenece a ambas, corrige primero la asignación de Entra y vuelve a probar el piloto, en lugar de utilizar el orden como regla de permisos. Aun así, documenta el orden de la lista porque determina el perfil efectivo si se produce una coincidencia múltiple inesperada.

Activar Entra SSO para administradores

El servidor de Entra ID solo se convierte en un método de inicio de sesión de WebAdmin cuando se asigna al servicio de administradores:

  1. Abre Authentication > Services.
  2. Ve a Administrator authentication methods.
  3. Selecciona el servidor de Microsoft Entra ID.
  4. Desplaza el servidor hacia arriba en la lista.
  5. Conserva la autenticación local existente como fallback deliberado para administradores locales.
  6. Selecciona Apply.

Solo se puede seleccionar un servidor de Microsoft Entra ID por método de autenticación. Los ajustes de Administrator authentication methods no se aplican al superadministrador predeterminado admin. Por tanto, esta cuenta sigue siendo un acceso local de emergencia y no se sustituye mediante un Role mapping de Entra.

Probar de forma segura el inicio de sesión y los permisos

Completar correctamente el diálogo de Entra no basta para aprobar la prueba. El firewall debe aplicar el perfil correcto, rechazar a un usuario no autorizado y seguir ofreciendo una vía local de recuperación.

Prueba positiva con administradores piloto

  1. Mantén abierta la sesión local de administrador existente.
  2. Abre el FQDN de WebAdmin documentado en una ventana privada del navegador.
  3. Inicia sesión mediante Entra ID con el administrador piloto Read-only.
  4. Completa Entra MFA y Conditional Access según lo previsto.
  5. Comprueba que solo se muestran los menús autorizados y que las acciones de escritura no están disponibles.
  6. En Authentication > Users, comprueba que la cuenta se haya creado como administrador con el perfil esperado.
  7. Si se necesita Full Access, prueba un administrador piloto independiente con el rol Full Access.

No realices la prueba Full Access con la misma cuenta que también debe recibir Read-only. Dos cuentas de prueba inequívocas muestran si los roles, el orden del mapping y los perfiles locales están realmente separados.

Prueba negativa y de fallback

  • Un usuario no asignado a la Enterprise Application no debe poder completar correctamente el flujo SSO.
  • Un usuario asignado pero sin mapping no debe obtener acceso a WebAdmin.
  • Un administrador Read-only no debe poder guardar cambios de configuración.
  • El admin local debe seguir funcionando desde la red de gestión prevista.
  • El acceso desde una red no permitida ya debe fallar en Device Access o Local Service ACL.

Si el usuario de la prueba negativa obtiene acceso, la asignación, la pertenencia al grupo o el orden del mapping son incorrectos. Detén la fase piloto; no eludas el problema de permisos con un rol más amplio ni exponiendo WebAdmin a la WAN.

Operación, retirada de permisos y HA

Entra SSO traslada la identidad y MFA al proveedor de identidad. Los permisos de administrador efectivos a nivel local deben seguir controlándose en el firewall.

Completar los cambios de rol de forma consciente

Cuando un usuario de Entra se convierte en administrador del firewall, SFOS aplica el cambio en el siguiente inicio de sesión. El proceso inverso no es automático: si un administrador se degrada a usuario normal en Entra, el objeto local de administrador permanece inicialmente en el firewall.

Procedimiento seguro para una degradación:

  1. Confirma un segundo administrador local y la vía de recuperación.
  2. Retira el rol o grupo de administrador en Entra, o adapta la asignación de la aplicación.
  3. En Authentication > Users, elimina de forma controlada el objeto local de administrador afectado.
  4. Permite un nuevo inicio de sesión solo si el usuario debe seguir utilizando servicios de usuario. SFOS vuelve a crear la cuenta como usuario según el token actual.
  5. Realiza una prueba negativa de un nuevo inicio de sesión en WebAdmin y no des por hecho que las sesiones existentes terminan automáticamente.

Si la cuenta ya no debe utilizar ningún servicio del firewall, no vuelvas a asignarla. La mera retirada de un grupo no debe documentarse como revocación inmediata de permisos locales de administrador que ya están activos.

Supervisar el secreto, los logs y los cambios

  • Supervisa la fecha de caducidad del Client Secret, con un responsable y antelación suficiente.
  • Revisa los Entra Sign-in Logs por aplicación, usuario, MFA y Conditional Access.
  • Utiliza oauth_sso_webadmin.log en el firewall para el flujo SSO de WebAdmin.
  • Rastrea los cambios de administradores, perfiles y autenticación mediante el Audit Trail.
  • Revisa conjuntamente de forma periódica los grupos de administradores, los roles de aplicación y los perfiles de Device Access.

En Advanced Shell, el siguiente comando de solo lectura muestra las entradas más recientes del servicio SSO de WebAdmin:

tail -n 200 /log/oauth_sso_webadmin.log

Servicios y logs de Sophos Firewall explica la asignación general de archivos de log y los accesos de lectura seguros.

Tener en cuenta la limitación de HA

En un clúster HA, Entra ID SSO no funciona actualmente para WebAdmin del dispositivo Auxiliary. Por tanto, el acceso directo al peer, la recuperación y el mantenimiento requieren un procedimiento local. Asignar un rol de Entra a HAProfile no elimina esta limitación del producto.

Antes de una prueba HA, documenta ambas vías de gestión, las credenciales locales y los roles. Después de un cambio de rol, vuelve a probar por separado el acceso al Primary, la gestión local del peer y SSO.

Solución de problemas

El inicio de sesión de Entra funciona, pero WebAdmin deniega el acceso

Normalmente falta un mapping de administrador adecuado. Comprueba User type: Administrator, el tipo de identificador, el valor exacto del rol o el nombre del grupo y el perfil asignado. En Authentication > Users, una cuenta creada como usuario normal demuestra que no ha coincidido ningún mapping de administrador.

El administrador recibe el perfil equivocado

Role mapping se evalúa de arriba abajo. Comprueba las pertenencias a grupos y los roles de aplicación de la cuenta, elimina las asignaciones duplicadas y vuelve a probar el orden con un nuevo inicio de sesión. No amplíes simplemente los permisos del perfil restrictivo.

La redirección termina en una página de error

Compara carácter por carácter la Web admin console URL del firewall con la Redirect URI de App registrations > Authentication > Web. El FQDN, puerto, ruta, DNS y certificado de WebAdmin forman parte de una misma prueba. Al configurar mediante Central, no utilices la URL de Reverse SSO.

Test connection falla

Comprueba el acceso a login.microsoftonline.com y graph.microsoft.com, DNS, hora del sistema, Tenant ID, Client ID, Client Secret, permisos de Microsoft Graph y Admin Consent. Una nueva Redirect URI no corrige un secreto caducado.

Si oauth_sso_webadmin.log muestra x509: certificate signed by unknown authority, puede faltar una CA raíz o intermedia para la cadena de certificados de Microsoft presentada realmente. Lee la cadena desde Advanced Shell del firewall para ver lo que recibe el propio firewall:

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

Un equipo de prueba puede servir de comparación, pero no demuestra qué cadena ve el firewall. Importa únicamente una CA cuya ausencia se haya comprobado y desde una fuente de confianza. No utilices un certificado de servidor como CA ni reinicies un servicio SSO como primer paso de diagnóstico.

SSO funciona en el Primary, pero no en el Auxiliary

Es una limitación documentada de HA. WebAdmin del Auxiliary requiere un acceso local probado. Un nuevo rol de Entra, una habilitación más amplia de Device Access u otra Redirect URI no resuelven esta limitación.

Lista de comprobación

  • Funcionan el admin local, un segundo administrador y el acceso por consola.
  • WebAdmin solo es accesible desde las redes de gestión o los orígenes previstos.
  • FQDN, DNS, certificado y hora del sistema son correctos.
  • App Registration, permisos, Admin Consent y caducidad del secreto están documentados.
  • En una aplicación WebAdmin dedicada, Assignment required está activado y solo se asigna el grupo piloto de administradores; en una aplicación compartida se incluyen y prueban todos los grupos autorizados de administradores, VPN y portales.
  • Los perfiles de Device Access contienen los permisos previstos.
  • User type: Administrator y Role mapping están ordenados correctamente.
  • La Web admin console URL exacta está registrada como Redirect URI de Entra.
  • Test connection se completa correctamente.
  • Entra está activado en Administrator authentication methods.
  • Se han superado las pruebas Read-only, Full Access, negativa y de fallback local.
  • Se han revisado los Entra Sign-in Logs y oauth_sso_webadmin.log.
  • La retirada de permisos, la rotación del secreto y la limitación de HA están documentadas operativamente.