Sophos Mobile: usuarios, autoservicio y conexión con AD

Orientación basada en documentación: no es un procedimiento operativo validado en producción. Este texto distingue la vista People de Mobile de la gestión de identidades en Sophos Fusion. Los menús y requisitos siguientes describen lo documentado, no un comportamiento confirmado en un tenant de producción; antes de aprobar su uso operativo deben comprobarse por separado los cambios y la disponibilidad según la edición.

Aclarar primero las responsabilidades y la edición

Mobile no crea identidades: la lista de People refleja las cuentas de Fusion pertinentes. Si una cuenta no aparece, no significa necesariamente que se haya eliminado o que aún no se haya creado: comprobar primero la edición y las asignaciones. La creación y edición de cuentas, la creación de grupos y la pertenencia a ellos siguen siendo responsabilidad de Fusion. El acceso general al autoservicio de Fusion debe distinguirse de la configuración de SSP de Mobile, que determina los grupos autorizados y las opciones de inscripción. La asignación de un grupo a una configuración de SSP de Mobile no concede roles administrativos.

Asignar el autoservicio de Mobile de forma controlada

Antes de reasignar un grupo o pulsar Apply para LDAP, comprobar la licencia y edición reales del tenant (solo MDM o Sophos Mobile combinado frente a solo MTD), la función efectiva de Administrator de Mobile con permiso de escritura de ajustes y la autorización del cambio. Un grupo de usuarios del SSP de Mobile no concede funciones administrativas; Helpdesk y Read-only no pueden guardar ajustes. Registrar la configuración previa aprobada y prever un piloto autorizado con restauración observada antes de la aprobación operativa; esto no establece un procedimiento de desactivación o reversión de LDAP.

1. Comprobar la edición, la existencia de la cuenta de Fusion y la asignación de dispositivos prevista para un usuario piloto. En la versión completa, tener en cuenta por separado las asignaciones de aplicaciones de Apple Business; no extrapolar a Threat Defense este motivo adicional para aparecer en People.

2. Comprobar en Fusion el grupo de usuarios previsto y sus miembros, o gestionarlos mediante el proceso correspondiente de Fusion. No «crear» el grupo en Mobile People.

3. Abrir Setup > Self Service Portal. En Self Service Portal configurations, abrir la configuración prevista para editarla o seleccionar Create y definir Name para una nueva. La configuración completa de plataformas queda deliberadamente fuera de este procedimiento de asignación: preparar el tipo de dispositivo, la propiedad, el paquete de inscripción, los textos, el límite de dispositivos y las acciones seguras siguiendo la guía de Avanet para configurar Mobile SSP antes de asignar el grupo; la asignación no sustituye estos requisitos.

   Solo después de las comprobaciones de asignación, edición y Default descritas a continuación, en User groups > Add, seleccionar el grupo piloto previsto. Antes de Save, limitar estrictamente el grupo y las acciones, ya que guardar puede activar permisos para usuarios ya asignados. Seleccionar Save en Edit Self Service Portal configuration; después utilizar las flechas junto a la configuración en Self Service Portal configurations para comprobar y, si procede, cambiar su prioridad. Antes de asignar el grupo, comprobar si ya está vinculado a una configuración de SSP de Mobile: un mismo grupo no puede estar asignado a varias configuraciones. Planificar previamente cualquier cambio de asignación, en lugar de añadir el grupo a una segunda configuración. En la configuración prevista, comprobar qué tipos de dispositivos se pueden inscribir y qué acciones sobre dispositivos están disponibles en esa edición. La asignación del grupo por sí sola no limita el despliegue a ese grupo: la configuración siempre presente Default se aplica, con la prioridad más baja, a los usuarios que no tienen otra configuración de SSP aplicable. Por tanto, comprobar también los tipos de dispositivos y las acciones permitidas en Default. Si un usuario pertenece a varios grupos con configuraciones aplicables, prevalece la de mayor prioridad; revisar las prioridades de las demás configuraciones aplicables antes del piloto. La mera pertenencia a un grupo no demuestra que el usuario pueda iniciar sesión en el portal ni que la inscripción de un dispositivo vaya a funcionar.

4. Antes de un despliegue amplio, comprobar las opciones de inscripción y las acciones sobre dispositivos realmente disponibles con una cuenta piloto autorizada y con un usuario excluido del grupo destinatario que no tenga ninguna otra configuración de SSP aplicable; si coinciden varios grupos, probar además con un usuario que pertenezca a varios de ellos. Verificar para la cuenta piloto autorizada el inicio de sesión real en el autoservicio y, tras una inscripción de prueba, la asignación del dispositivo en People. No dar por hecho que al usuario excluido se le denegará el acceso al portal: comprobar si Default sigue permitiendo inscripciones o acciones. No afirmar que el acceso está limitado al grupo destinatario hasta haber comprobado las configuraciones efectivas y los resultados del piloto. Si hay discrepancias, diagnosticar por separado la identidad y la pertenencia a grupos en Fusion y la configuración y prioridad de SSP de Mobile; no modificar asignaciones de producción solo por la presencia de una entrada en la lista.

LDAP para cuentas de AD en el aprovisionamiento automático de dispositivos (versión completa)

La conexión LDAP de Mobile documentada se refiere a cuentas de usuario de Fusion procedentes de Active Directory. Durante el aprovisionamiento automático de iPhone, iPad y Mac gestionados mediante Apple Business, dispositivos Android con Google zero-touch o dispositivos Android con Samsung KME, Mobile autentica al usuario contra AD solo si se elige la vía de inicio de sesión con AD. Según el tipo de dispositivo, también están documentados el uso de credenciales de Fusion y, para los iPhone y iPad de Apple Business, el inicio de sesión federado; un perfil de Apple Business puede asimismo inscribir dispositivos sin autenticación de usuario, en cuyo caso no se asigna automáticamente un usuario. Esto no es una vía alternativa para crear cuentas de Fusion. Sophos documenta esta página de LDAP para la versión completa de Mobile; la navegación de People de Threat Defense consultada aquí no incluye una página LDAP equivalente. Esto no permite afirmar de forma general que Threat Defense jamás pueda utilizar AD desde un punto de vista técnico: hay que comprobar la disponibilidad en el tenant concreto antes de extrapolar este procedimiento.

Antes de cualquier cambio en el piloto, asegurarse de que la cuenta de usuario de Fusion procede de AD, que el correo electrónico de Fusion coincide con el atributo mail de AD, que el servidor de directorio admite LDAPS y que el firewall permite las conexiones entrantes necesarias desde las direcciones de Sophos correspondientes a la región de Fusion hacia el servidor AD. Para la vía de inicio de sesión con AD, configurar la sincronización de AD en Fusion; Sophos recomienda ejecutarla periódicamente. Tras cualquier cambio de identidad, volver a comprobar que el correo de Fusion coincide con el atributo mail de AD, ya que la autenticación falla si difieren. La sincronización y sus efectos no se han probado aquí en un tenant. LDAP utiliza TCP 636. Primero determinar la región en Fusion mediante My Products > Mobile: aparece en el primer componente de la URL de la barra de direcciones, justo después de smc-user-if-cloudstation-. Solo como ejemplo: smc-user-if-cloudstation-eu-west-1.prod.hydra.sophos.com indica eu-west-1; para la regla utilizar la región real del tenant. Inmediatamente antes de aplicar la regla del firewall, consultar las direcciones de origen actuales de esa región en la lista de Sophos para conexiones AD y SCEP. Consulta en vivo limitada: este enlace externo sirve exclusivamente para comprobar las direcciones actuales durante el cambio del firewall, porque Sophos mantiene sus direcciones de nube; la configuración se explica aquí. Permitir conexiones entrantes solo desde esos orígenes regionales de Sophos al servidor AD previsto por TCP 636, restringiendo origen y destino, sin acceso ilimitado. No copiar direcciones de otra región. TCP 443 corresponde a la función SCEP independiente, no a un requisito adicional de LDAP. Utilizar una cuenta sin permisos de escritura en el directorio para el bind LDAP. Sin una conexión LDAP configurada, los usuarios que sigan la vía de configuración con autenticación de usuario mediante credenciales de Fusion necesitan una invitación al Fusion Self Service Portal y activar su cuenta; esto no excluye la inscripción en Apple Business sin autenticación de usuario.

Para seguir la ruta documentada de la versión completa, abrir Setup > Sophos setup > LDAP connection, seleccionar Configure external LDAP y, en la página Server details, introducir en el campo Primary URL la dirección IP o el nombre del servidor de directorio principal. Opcionalmente, introducir en el campo Secondary URL la dirección IP o el nombre de un segundo servidor de directorio; Sophos Mobile lo utiliza como respaldo cuando el servidor principal no está disponible. Sophos indica los formatos <domain>\<user name> y <user name>@<domain>.<domain code> para el usuario de bind; introducir el usuario de bind en User y su contraseña en Password en Server details. Después pasar a la página Search base e introducir allí el nombre distinguido (DN) del objeto de la base de búsqueda. Este objeto determina el punto de partida de la búsqueda LDAP en el directorio. Guardar con Apply. Para iniciar sesión con AD, seleccionar además expresamente Yes - LDAPS authentication en Assign user to device del perfil de Apple Business utilizado para iOS o macOS; en la configuración de inscripción de KME, seleccionar User authentication. Google zero-touch asigna usuarios automáticamente solo en la vía con autenticación: los ajustes de inscripción Zero-touch tienen la casilla User authentication; al desmarcarla se inscribe un dispositivo sin usuario y sin asignación de usuario. En macOS, Yes - LDAPS authentication también admite el correo y la contraseña de Fusion; seleccionarlo no demuestra por sí solo que se usaron credenciales de AD. Configurar la conexión LDAP por sí solo no cambia el perfil de Apple Business a la vía de inicio de sesión con AD. Durante la configuración de un dispositivo piloto, comprobar la autenticación elegida, la correcta asociación del correo electrónico y la posterior asignación en Mobile. Guardar la conexión no demuestra por sí solo que la inscripción haya funcionado. Antes de modificar o desactivar la conexión, comprobar la dependencia de los aprovisionamientos ya planificados mediante Apple Business, zero-touch y KME de la vía de AD, y documentar el estado previo de la conexión y las reglas del firewall; este texto no ofrece un procedimiento para revertir cambios en cuentas de Fusion.

Comprobaciones pendientes para su aprobación

Aprobación operativa pendiente: no se han validado en laboratorio la edición y las acciones visibles en un tenant real, la autorización de grupos para el SSP de Mobile, el inicio de sesión y la asignación de dispositivos en pruebas, ni la conexión LDAP y una reversión segura. La asignación de dispositivos Mobile, que se trata por separado al eliminar un usuario de Fusion, queda fuera de esta guía; no debe deducirse de la eliminación de la cuenta que el dispositivo se haya desconectado o eliminado.