Ir al contenido
Avanet

Sophos Protected Browser: configurar usuarios e inicio de sesión

Cada usuario de Sophos Protected Browser necesita tres elementos: un objeto de usuario en Sophos Central, un método de inicio de sesión adecuado y acceso a Sophos Self Service Portal (SSP). Por tanto, la secuencia segura consiste en elegir el origen de usuarios, aprovisionarlos, configurar el inicio de sesión federado con un proveedor de identidad en la nube, elegir el método de inicio de sesión de Sophos y, solo entonces, habilitar el acceso al SSP.

Requisitos previos, licencia y roles

Antes de realizar el primer cambio, compruebe lo siguiente:

  • Acceso al producto: Protected Browser debe estar disponible en el tenant previsto en My Products > Protected Browser. Aquí no se documenta ninguna SKU independiente ni ningún procedimiento para una licencia de prueba. Si no aparece el menú, deténgase y solicite que se comprueben los derechos del tenant en vez de presuponer una licencia.
  • SSP: Todos los usuarios de Protected Browser necesitan acceso a Sophos Self Service Portal.
  • Origen de usuarios: Los usuarios gestionados manualmente pueden complementar una población respaldada por un directorio, por ejemplo, si no figuran en el servicio de directorio. Sin embargo, los usuarios del mismo dominio no deben sincronizarse simultáneamente desde AD y Entra ID.
  • Rol: Se necesita un Super Admin para verificar un dominio federado y configurar un proveedor de identidad. Un administrador de la consola de Sophos Central configura los orígenes de directorio. También se necesita un Super Admin para asignar un rol administrativo al crear manualmente un usuario. Para un usuario que solo utilice Protected Browser basta el rol User, que únicamente da acceso al SSP. Asignar correctamente los roles administrativos de Sophos Fusion explica estos límites.
  • Piloto: Prepare un solo usuario de prueba con una dirección de correo accesible. En Entra ID, Email y User principal name deben coincidir. Protected Browser no admite Google Directory.

Si utiliza Okta, sincronice primero sus usuarios con Active Directory y después AD con Sophos Central. Las dependencias generales de identidad y ZTNA se tratan en Configurar Sophos ZTNA: visión general y orden; aquí solo se aborda la cadena de usuarios e inicio de sesión necesaria para Protected Browser.

Elegir el origen y aprovisionar usuarios

Opción A: crear usuarios individuales manualmente

Esta opción es adecuada para un piloto pequeño o para personas ausentes del servicio de directorio.

  1. Abra My Environment > Users & Groups.
  2. Haga clic en Add user.
  3. En First and last name, introduzca el nombre sin el nombre de dominio.
  4. En Role, seleccione User para un usuario normal de Protected Browser. Use un rol administrativo solo si la persona va a administrar Central.
  5. Introduzca el Manager si procede.
  6. Añada la dirección de correo y guarde con Save.

El nombre elegido libremente para el usuario piloto no es una clave técnica. Para la invitación y el acceso importa que la dirección de correo sea correcta y accesible.

Opción B: sincronizar Active Directory

La sincronización completa de AD es una tarea de identidad compartida y no se reproduce como otro procedimiento. No obstante, para la decisión sobre Protected Browser son importantes estos límites:

  • El equipo de sincronización debe tener instalado .NET Framework 4.6.2.
  • Se necesitan credenciales de la API de Sophos con el rol Service Principal Active Directory Sync. Limite el acceso al mínimo.
  • Todos los usuarios que se sincronicen necesitan una dirección de correo. El firewall o proxy debe permitir los dominios requeridos por Sophos.
  • Los usuarios y correos deben ser únicos en cada cuenta de Sophos Central. No se admiten varios clientes de AD del mismo dominio o subdominio.
  • Los usuarios y grupos se sincronizan juntos; no es posible sincronizar solo uno de esos tipos de objeto.

Nota operativa: Sophos recomienda eliminar de AD los usuarios y dispositivos inactivos. Un filtro de AD puede impedir su sincronización, pero no elimina el riesgo de seguridad de una cuenta de AD que sigue existiendo. Además, al cambiar bases de búsqueda o filtros, usuarios y grupos de Central ya creados pueden quedar fuera del ámbito y eliminarse de Sophos Central. Revise el ámbito previsto antes del cambio.

Opción C: añadir Microsoft Entra ID

Para Entra ID hacen falta un administrador de la consola de Sophos Central, una suscripción de Microsoft Azure con Entra ID, el permiso Directory.Read.All y una aplicación de Azure. Anote Tenant domain, Application ID, el Value del secreto de cliente y su fecha de caducidad.

Límites importantes antes de empezar:

  • Office 365 GCC High no es compatible con esta sincronización.
  • Solo puede haber un origen de Entra ID por dominio.
  • Los usuarios o correos no deben sincronizarse con varias cuentas de Sophos Central.
  • La sincronización de usuarios de un mismo dominio no debe ejecutarse en paralelo desde AD y Entra ID.
  • Los usuarios y grupos de Central sin correspondencia en Entra ID deben gestionarse manualmente.

Para añadir el origen:

  1. Abra Global Settings > Platform > Directory service.
  2. Haga clic en Add Microsoft Entra ID.
  3. Introduzca el Name, la Description y el Domain del origen.
  4. Haga clic en Next.

La sincronización posterior corresponde al equipo central de identidad, que utilizará los valores de Azure ya comprobados. Si una aplicación existente solo posee el permiso antiguo Microsoft Entra ID Graph Directory.Read.All, debe añadirse Microsoft Graph Directory.Read.All antes de modificar la sincronización.

Configurar el inicio de sesión federado

Use esta sección si los usuarios acceden mediante un proveedor de identidad en la nube. Ejecute los pasos como Super Admin. Antes del cambio, asegúrese de que todos los administradores y usuarios estén asignados a un dominio y tengan un proveedor de identidad. En caso contrario, todavía no habilite el inicio federado.

1. Verificar el dominio federado

  1. Abra Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in.
  2. Haga clic en Verify domains.
  3. En Federated domains, seleccione Add domain.
  4. Introduzca Domain name y Description y haga clic en Save.
  5. En Verify domain ownership, copie con Copy el TXT record mostrado y seleccione Cancel.
  6. Publique el registro TXT en DNS. La propagación puede tardar hasta 24 horas.
  7. Vuelva a Sign-in and Identity > Sophos Sign-in > Verify domains. En el Verification Status correspondiente, haga clic en Verify domain ownership, revise los datos y seleccione Verify.

El paso se completa cuando el dominio aparece en Federated domains con una fecha de verificación. La verificación dura un año y puede repetirse durante ese periodo.

2. Añadir un proveedor de identidad

Abra Global Settings > Access Control > Sign-in and Identity > Federated identity providers y haga clic en Add identity provider. Asigne un nombre sin caracteres especiales como ., @ o #, pues con ellos no se puede guardar la configuración.

Elija la variante adecuada:

  • Microsoft Entra ID: En Type y Vendor, seleccione Microsoft Entra ID; en Configure Entra ID settings, introduzca Tenant ID y, en Configure domains, elija el dominio verificado.
  • OpenID Connect, por ejemplo Okta: Seleccione OpenID Connect y el proveedor. En Configure OpenID Connect settings, introduzca Client ID, Issuer, Authz endpoint y JWKS URL. Después elija el dominio verificado.
  • Microsoft AD FS: Seleccione Microsoft AD FS, el proveedor y AD FS metadata URL. Elija el dominio, guarde con Save y transfiera los valores Entity ID y Callback URL mostrados a la configuración de AD FS.

Puede añadir varios dominios a un proveedor, pero cada usuario solo puede pertenecer a uno. Determine también quién exige MFA:

  • IdP enforced MFA: el proveedor de identidad exige MFA.
  • No IdP enforced MFA: Sophos Central exige MFA después de una autenticación correcta en el IdP.

Haga clic en Save, seleccione el proveedor en la lista y haga clic en Turn on. Central solo permite activarlo si la configuración está completa y los datos son válidos.

3. Elegir el método de inicio de sesión de Sophos

  1. Abra Global Settings > Access Control > Sign-in and Identity > Sophos sign-in settings.
  2. Elija exactamente una opción:
    • Federated credentials only si solo se usa un proveedor de identidad en la nube y no hay usuarios creados manualmente en Sophos Central.
    • Sophos Fusion Admin or Federated credentials si, además del proveedor, existen usuarios creados manualmente.
  3. Haga clic en Save.

La segunda opción no es un modo «más seguro» en general, sino la elección necesaria para una población mixta. Antes de cambiar a más usuarios, documente el modo anterior y pruebe primero el usuario piloto.

Habilitar el acceso al SSP

Elija la modalidad según el despliegue. Para dar acceso a todos los usuarios sincronizados, habilite el acceso general antes de sincronizar el directorio. Si empieza solo un grupo seleccionado, sincronice primero y después envíe específicamente el correo de configuración.

Acceso para todos los usuarios

  1. Abra Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in.
  2. En User Access, active Sophos Fusion Self Service Portal access.

Todos los usuarios, incluidos los sincronizados desde un directorio, reciben acceso al SSP y un correo de bienvenida con información para iniciar sesión.

Acceso solo para usuarios concretos

  1. Abra My Environment > Users & Groups > Users.
  2. Marque los usuarios piloto y haga clic en Email Setup Link.
  3. En Other Emails, elija Sophos Fusion Self Service Welcome/Setup Email.
  4. Haga clic en Save.

También en esta modalidad, los usuarios elegidos reciben un correo de bienvenida con la información de acceso.

Validar con un usuario piloto

Compruebe la cadena en el mismo orden en que la configuró:

  1. El usuario aparece exactamente una vez en My Environment > Users & Groups > Users y tiene el correo esperado.
  2. Con inicio federado, el dominio figura en Federated domains con fecha de verificación y el proveedor está activo.
  3. En Sophos sign-in settings está guardado el modo adecuado para la población.
  4. El piloto recibe el correo de bienvenida del SSP y puede usar la ruta de acceso descrita.
  5. Solo tras este resultado se habilita el mismo método para más usuarios.

No amplíe el despliegue si falta algún resultado. Compruebe primero el componente inmediatamente anterior; que el dominio esté verificado no demuestra, por ejemplo, que el proveedor esté activo ni que se haya concedido acceso al SSP.

Resolución de problemas por síntoma

El dominio federado aún no se puede verificar

Compruebe que el registro TXT copiado se publicó exactamente en la zona DNS correcta. Espere el tiempo documentado de hasta 24 horas y vuelva a iniciar Verify domain ownership. La ausencia de fecha de verificación no justifica continuar con la activación del IdP.

No se puede guardar o activar el proveedor

Si falla el guardado, quite del nombre caracteres como ., @ o #. Si Turn on no está disponible, la configuración está incompleta o contiene datos no válidos. Según el tipo, revise Tenant ID, los endpoints OIDC o AD FS metadata URL, y el dominio elegido.

La prueba de conexión de Entra indica una ID de cliente no válida

Compruebe que se introdujo la Application ID de la aplicación de Azure como Client ID. Sophos también señala como posible causa el inicio de sesión de usuario deshabilitado en Microsoft Entra ID Admin Center. Corrija primero ambos puntos; no cree de forma preventiva otro origen para el mismo dominio.

Faltan usuarios o aparecen duplicados

En AD, compruebe primero que la cuenta está activa, tiene correo y está dentro de la base de búsqueda o filtro. En Entra ID, los objetos de Central existentes deben tener correspondencia. Pueden surgir duplicados si el UPN sincronizado no coincide con el inicio de sesión del usuario en el endpoint. Corrija primero el origen, el UPN y la asignación de correo, en lugar de habilitar el SSP para ambos objetos.

El usuario no recibe el correo de bienvenida del SSP

Compruebe qué modalidad se usó. Para el acceso general, Sophos Fusion Self Service Portal access debe estar activo; para el piloto dirigido, debe haberse guardado Sophos Fusion Self Service Welcome/Setup Email para ese usuario. Revise después su dirección de correo. Si todo es correcto y el mensaje no llega, aquí termina el diagnóstico verificado: escale la entrega en vez de modificar a ciegas valores de acceso o roles.

Retorno seguro y baja

Aquí no se documentan un procedimiento general para retirar Protected Browser ni una reversión completa tras un cambio de federación. Proceda de forma limitada y reversible:

  1. Antes del cambio, anote el valor actual de Sophos sign-in settings y el ámbito del piloto.
  2. Si el piloto no puede iniciar sesión, detenga el despliegue. Mientras exista una sesión administrativa funcional, restaure en el mismo diálogo el modo anterior documentado y guárdelo.
  3. Pruebe de nuevo la ruta anterior. No elimine el dominio federado ni el proveedor hasta revisar sus dependencias fuera de esta guía.
  4. En una baja de AD, elimine los usuarios y dispositivos inactivos del directorio autoritativo. Excluirlos de la sincronización reduce los datos transferidos, pero no elimina la cuenta de AD inactiva ni su riesgo.
  5. Este procedimiento no ofrece una reversión verificada para revocar el SSP a usuarios individuales o a todos. Deténgase y confirme el procedimiento actual en el tenant o con Sophos Support, sin adivinar una acción de eliminación o desactivación.

Funcionamiento continuo

Compruebe periódicamente:

  • Dominio federado: supervise la fecha; la verificación dura un año y puede renovarse antes.
  • Entra ID: documente la caducidad del secreto de cliente. Antes de cambios, confirme el permiso de Microsoft Graph Directory.Read.All.
  • AD: busque y elimine periódicamente cuentas y dispositivos inactivos del directorio autoritativo. Revise los filtros para evitar eliminaciones involuntarias de Sophos Central.
  • Cobertura de identidad: confirme que cada administrador y usuario afectado siga asignado exactamente a un dominio y un proveedor válido.
  • Acceso al SSP: en cada alta, cambio o baja, compruebe que origen, modo de inicio y acceso al SSP sigan siendo coherentes.
  • Piloto antes de cambios amplios: pruebe primero cualquier cambio de origen, dominio, IdP o modo con un usuario limitado y despliegue solo tras obtener el resultado esperado.