Sophos Mobile: gestionar la conectividad de macOS mediante políticas de dispositivo o de usuario

Este artículo trata de las políticas de Sophos Mobile en Mac gestionados, no de la configuración general de Wi-Fi/VPN de Apple ni de Sophos Endpoint, ZTNA o la configuración de Sophos Firewall. Para instalar el cliente y configurar el acceso remoto en el firewall en lugar de una política de Mobile, consulte Sophos Connect en macOS. El contexto de dispositivo y el de usuario son distintos: que las configuraciones tengan el mismo nombre no significa que la identidad, el acceso a los certificados y el momento en que se aplican sean intercambiables. La mera asignación de un perfil no demuestra que la conexión funcione.

Requisitos previos: asegurar primero el acceso de administración y la vía de recuperación

• Licencia MDM necesaria: Para gestionar los Mac se requiere Sophos Mobile Device Management, ya sea como licencia independiente o incluida en la licencia conjunta Sophos Mobile. Sophos Mobile Threat Defense por sí sola no basta: esta licencia cubre la gestión de Sophos Intercept X for Mobile y Sophos Chrome Security, no la gestión MDM de los Mac. Compruebe en el tenant el derecho de uso de MDM correspondiente antes de crear las políticas.
• Compruebe que el Mac esté registrado en Sophos Mobile, su versión de macOS, las políticas ya asignadas y si la función requerida debe gestionarse para un dispositivo o para un usuario concreto. Los Mac solo tienen un modo de administración en Sophos Mobile, pero admiten políticas de dispositivo, declarativas y de usuario. User Enrollment de Apple para iPhone/iPad privados no es un modo de registro de macOS. Si el Mac se registra manualmente, debe hacerlo el usuario que se va a gestionar e introducir una contraseña de administrador para el perfil de registro; si el registro es automático mediante Apple Business, compruebe si en Assign user to device se ha seleccionado No (sin asignación de usuario durante el registro) o Yes - LDAPS authentication. No deduzca la asignación de usuario a partir de la política de dispositivo.
• Las políticas de dispositivo se aplican a todos los usuarios del Mac. Las políticas de usuario se aplican al usuario que realiza el registro local y a los usuarios de red conocidos por Sophos Mobile a través del directorio LDAP externo del Self Service Portal. Si la política de dispositivo une un Mac al mismo dominio AD que el Self Service Portal, la política de usuario se aplica a todos los usuarios de AD que inicien sesión en ese Mac. Compruébelo con las cuentas previstas antes de una asignación amplia.
• Además de la política de dispositivo de registro, a un Mac se le puede asignar una política de dispositivo adicional, una declarativa y una de usuario. Antes de modificar cualquier payload, identifique los Mac destinatarios, los usuarios y grupos afectados y todas las asignaciones de la política existente: nunca modifique para el piloto una política que ya esté asignada fuera de él. Documente los payloads existentes de Wi-Fi, VPN, proxy y certificados, así como sus responsables; los ajustes contradictorios se tratan, en general, según el valor más restrictivo, con una prioridad especial para las configuraciones declarativas de actualización de software y de aplicaciones. No superponga perfiles existentes mediante asignaciones adicionales sin control.
• Comprobación previa solo para macOS 26 con política de usuario: si aparece el estado Failed to apply the policy, investigue el historial de las configuraciones Restrictions previamente asignadas: la clave obsoleta Allow Time Machine puede persistir en una política antigua asignada aunque ya no sea visible en las opciones de configuración. No exija encontrar la clave en la interfaz actual. Si se sospecha esta causa histórica, detenga el piloto y la evaluación de los payloads de Wi-Fi/VPN/certificados de esa política de usuario: según Sophos, podría no aplicarse toda la política de usuario, no solo la restricción. Coordine la corrección controlada y una nueva comprobación con los responsables de las políticas de seguridad y privacidad de macOS; no modifique sin avisar una política de producción compartida. No es un fallo general de todos los Mac con macOS 26 ni de las políticas de dispositivo.
• Disponga de un acceso independiente al Mac piloto (por ejemplo, otra red operativa y acceso de administrador local). Aclare previamente con los respectivos responsables la SSID, el extremo RADIUS/VPN, DNS, la cadena de confianza de la PKI, el vencimiento de los certificados, la accesibilidad de PAC/proxy y, si procede, la aplicación VPN de terceros. No incluya contraseñas de acceso ni archivos .pfx en tickets o repositorios públicos. Compruebe en el tenant las aprobaciones de producto, licencia y sistema operativo para el entorno concreto; las páginas de configuración no garantizan una compatibilidad universal con todas las versiones de macOS.

Elección: ¿qué política y qué dependencias?

Si se configura manualmente Global HTTP proxy con credenciales, el nombre de usuario del proxy debe introducirse en Authentication y la contraseña correspondiente en Password. Aquí, Authentication es un campo de nombre de usuario, no un selector del método de autenticación. Aclare con el responsable del proxy si se necesitan credenciales; no incluya las contraseñas en tickets o repositorios públicos.

Wi-Fi: definir la red y la autenticación

Las siguientes descripciones de campos recogen los ajustes documentados por Sophos, no una conexión cuyo funcionamiento se haya probado en el Mac. Connect automatically conecta el Mac automáticamente cuando la red Wi-Fi está disponible. Hidden network identifica una red que no difunde su SSID. La selección debe corresponder a la red de destino; una SSID oculta no implica una aprobación de seguridad.

Security type define el método de seguridad y la variante Personal o Enterprise. Acordar ambos con el responsable de la red Wi-Fi. Para Personal, introducir la contraseña de Wi-Fi en Password. Para Enterprise, están disponibles Protocols para los protocolos de autenticación y Authentication para la autenticación del cliente:

• En Protocols > Accepted EAP types, definir los tipos EAP que el Mac acepta para la autenticación, de acuerdo con el servicio RADIUS. Para EAP-FAST, se puede configurar una Protected Access Credential (PAC). Esta PAC no es un archivo Proxy Auto-Config. Con TTLS, Internal identity selecciona el protocolo de autenticación del usuario dentro del túnel, no el nombre de usuario.
• Si el método Enterprise elegido utiliza nombre de usuario y contraseña, introducir el nombre de usuario de Wi-Fi en Authentication > User y la contraseña de Wi-Fi en Password. La asignación de la política a un usuario no sustituye estos datos. Según Sophos, Require password on each connect significa que la contraseña se envía en cada autenticación. No deducir de ello que se solicite la contraseña, que se almacene de una forma concreta ni que se transmita en texto claro. No añadir una contraseña de forma generalizada a los métodos basados en certificados.

Outer identity es una identidad de sustitución con la que EAP inicia la autenticación sin revelar las credenciales reales del usuario. Se transmite en texto claro. Por tanto, no utilizar el nombre de usuario real ni datos sensibles. Si el servicio RADIUS necesita un reenvío basado en un realm, la identidad de sustitución debe incluir el realm acordado con el responsable. Sin ese reenvío, puede bastar una identidad simple como anonymous. Siguen siendo aplicables las condiciones de EAP y TLS 1.3 indicadas a continuación.

Importante para Wi-Fi Enterprise: Sophos Mobile exige previamente una configuración Client certificate en la misma política para Identity certificate y una configuración Root certificate para Trusted certificates. Además, el payload de Wi-Fi tiene su propio campo Proxy para ajustes manuales o PAC, distinto de Global HTTP proxy. El certificado de cliente también está disponible para otras configuraciones de esa misma política, pero no para otras políticas; vuelva a cargarlo en ellas. Apple describe, a nivel de plataforma, que una identidad SCEP puede vincularse a un servicio dentro del mismo perfil de configuración; sin embargo, su ejemplo concreto de Wi-Fi EAP-TLS utiliza un certificado de AD. Esto no demuestra que Sophos Mobile ofrezca una identidad SCEP en su campo de Wi-Fi Identity certificate ni que distribuya esa vinculación: la ayuda de Sophos para Wi-Fi señala en cambio la configuración Client certificate como requisito previo. No planifique una dependencia de SCEP para la primera asignación ni para el Wi-Fi de producción. Considere esa variante como vía operativa solo después de demostrar la vinculación efectiva en su propio tenant y en el Mac piloto gestionado, además de un inicio de sesión EAP/RADIUS correcto; si no puede demostrar ni la selección ni la vinculación distribuida, descarte esa vía. Para EAP-TTLS/PEAP/EAP-FAST, configure Outer identity sin datos sensibles del usuario; según Sophos, es obligatoria con TLS 1.3. Establezca conjuntamente el mínimo y el máximo de TLS, o deje ambos vacíos.

VPN: acordar el proveedor, la autenticación y el proxy

Connection name es el nombre de la conexión que ve el usuario en el Mac, no el nombre de la política. La lista de campos de Sophos incluye en Connection type las opciones Cisco AnyConnect, Cisco Legacy AnyConnect, IPsec (Cisco), F5, Check Point y Custom SSL/TLS. Custom SSL/TLS está destinado a proveedores cuya aplicación de App Store proporciona la conexión VPN. Esta lista no supone una aprobación de todas las combinaciones de proveedor y macOS. La aplicación necesaria debe estar ya instalada; aclarar con el proveedor su identificador Reverse-DNS real.

Utilizar las siguientes opciones solo en la medida en que el tipo de conexión elegido y el proveedor las ofrezcan y las necesiten. Si el proveedor especifica propiedades de conexión propias, introducir cada Key y Value mediante Add en Third-party settings. No copiar propiedades de otra VPN. Group es un grupo que puede ser necesario para la autenticación VPN, no un grupo de dispositivos para asignar la política.

Definir por separado la autenticación de usuario y de dispositivo con el responsable de la VPN:

• En User authentication, elegir entre Password y Certificate. El campo correspondiente Password contiene la contraseña de la VPN y Certificate, el certificado para la autenticación del usuario de la VPN.
• Con Device authentication = Keys (Shared Secret)/Group name, aparecen Group name, Keys (Shared Secret), Use hybrid authentication y Request password. Introducir los datos de autenticación indicados por el responsable en Group name y Keys (Shared Secret). Seleccionar Use hybrid authentication y Request password solo según sus requisitos, no como solución general a problemas de conexión.
• Con Device authentication = Certificate, aparecen Certificate e Including user PIN. Seleccionar el certificado de dispositivo necesario en la lista Certificate. Including user PIN incluye el PIN del usuario en la autenticación del dispositivo. La fuente no especifica cuándo se solicita el PIN ni cómo se almacena.

Proteger las contraseñas de la VPN y los secretos compartidos como las demás credenciales. Los campos de certificado siguen sin demostrar una vía de vinculación SCEP; comprobar la identidad y la autenticación reales en el contexto de usuario o dispositivo previsto.

En el Proxy propio de la VPN, No proxy significa que no se configura ningún proxy para esa conexión. Con Manually, aparecen Server and port, Authentication y Password. Introducir ahí la dirección y el puerto del proxy y, si son necesarios, el nombre de usuario y la contraseña del proxy. Authentication también es aquí el campo de nombre de usuario. Con Automatic, aparece Proxy server URL para la URL del servidor que contiene los ajustes del proxy. Es un ajuste de esta conexión VPN, no un cambio en Global HTTP proxy.

Provider type distingue App proxy, un túnel VPN a nivel de aplicación, de Packet tunnel, un túnel VPN a nivel de red. Acordar la opción adecuada con el proveedor. No deducir de ella que el túnel sea dividido o completo; siguen siendo necesarias la planificación del tráfico y la comprobación de DNS y rutas en el piloto.

SCEP: comprobar los extremos, la identidad y las claves

URL contiene la dirección web del servidor de la CA. %_SCEPPROXYURL_% hace referencia a la URL del servidor en la pestaña SCEP de la página Sophos setup. Challenge es la dirección web desde la que se obtiene una contraseña de challenge del servidor SCEP, no la contraseña en sí. %_CACHALLENGE_% hace referencia a la URL de challenge en esa misma pestaña. CA name debe ser un nombre que la CA reconozca; puede servir, por ejemplo, para distinguir distintas instancias de CA. Acordar el valor adecuado con la PKI, sin presuponer un nombre universal ni la obligación de introducirlo.

Para añadir un Subject Alternative Name, seleccionar primero el tipo en Type of Subject Alternative Name y después introducir el valor en Value of Subject Alternative Name. Sophos describe RFC 822 name como una dirección de correo electrónico válida, DNS name como el nombre DNS del servidor de la CA y Uniform resource identifier como una URL completamente cualificada del servidor de la CA. No sustituir sin indicarlo estas descripciones del servidor de la CA por suposiciones generales sobre SAN. Aclarar con la PKI el tipo y el valor para la finalidad prevista del certificado; no demuestran una vinculación de identidad con Wi-Fi o VPN. Si se utiliza una identidad de usuario de AD, AD user logon name designa el User logon name registrado en AD, es decir, el User Principal Name (UPN). Los datos de SAN y AD no son un requisito general para todos los certificados de Mac.

Retries define el número de reintentos cuando el servidor SCEP responde con pending. Retry delay es el tiempo entre esos reintentos, en segundos. No es un intervalo de renovación ni garantiza que la emisión se complete tras ese tiempo de espera. Key size indica el tamaño de la clave pública del certificado emitido y debe coincidir con el tamaño configurado en el servidor SCEP. La configuración SCEP también dispone de Allow export from keychain. Esta opción permite a los usuarios exportar la clave privada del certificado desde el llavero. Como en el caso del certificado de cliente cargado, activarla solo si existe una necesidad expresamente aprobada.

SCEP y claves: Las variables de los extremos hacen referencia a los ajustes SCEP descritos anteriormente. Tras sustituir los marcadores, el valor de Subject debe ser un nombre X.500 válido: CN=%_USERNAME_% representa a un usuario y CN=%_DEVPROP(SerialNumber)_%, a un Mac. No deduzca que existe una identidad de dispositivo adecuada por haber elegido una política de usuario. Compruebe la confianza en la CA, la vigencia del certificado, la exportación de la clave, la fecha de vencimiento y el procedimiento de nueva emisión antes de establecer la primera dependencia; un certificado raíz no sustituye a uno de cliente. Añada una configuración Root certificate independiente para cada raíz adicional.

Otros payloads de dispositivo: AirPrint añade la IP de la impresora y el Resource path (por ejemplo, ipp/print) a la lista de AirPrint. Directory service une el Mac a un dominio AD cuando se asigna la política; la cuenta de unión debe tener permiso para añadir equipos y la OU debe ser correcta. Advertencia: cambiar la asignación de UID, User-GID o Group-GID puede impedir que los usuarios accedan a archivos creados anteriormente. No cambie esas asignaciones como prueba de red; planifique por separado la unión a AD y su reversión con los responsables de AD y de los Mac.

Directory service: definir las cuentas, el directorio de inicio y los permisos

En General settings, acordar los datos para la unión a AD con los responsables de AD:

• Domain host name contiene el nombre de host DNS del dominio AD al que se unirá el Mac. No introducir aquí la dirección de un servidor DNS ni el controlador de dominio definido por separado en Preferred DC server.
• AD administrator name y Password contienen el nombre y la contraseña de la cuenta utilizada para conectarse al servidor AD. Esta cuenta de unión debe tener permiso para añadir dispositivos a la base de datos de AD. No incluir la contraseña en tickets o repositorios públicos.
• Organizational unit define la unidad organizativa (OU) de AD en la que se añadirá el equipo que se une al dominio. Acordar el valor de OU aprobado con los responsables de AD; este campo no determina la asignación de usuarios o grupos ni el directorio de inicio.

Antes de la unión a AD, decidir con los responsables de AD y de los Mac si se necesita un directorio de inicio local con una cuenta móvil o un directorio de inicio exclusivamente de red. Si se selecciona Create mobile account, macOS crea la cuenta en el primer inicio de sesión con conexión al servidor AD; después, es posible iniciar sesión con las credenciales de AD incluso sin conexión a ese servidor. Con Require confirmation before creating a mobile account, el usuario decide si se crea la cuenta móvil, por lo que su creación no está garantizada. Para las cuentas móviles, es obligatorio Force local home folder: el perfil del usuario se almacena en el volumen de arranque. Si se desactiva esta opción, se utilizan directorios de inicio exclusivamente de red. Por tanto, no activar las cuentas móviles de forma generalizada para todos los Mac. Si se utiliza Use UNC path from Active Directory, macOS monta el directorio de inicio indicado en la cuenta de usuario de AD; acordar con los responsables el protocolo de montaje adecuado en Network protocol y comprobar el acceso en el piloto.

Default user shell define el shell de línea de comandos del usuario. Si el campo se deja vacío, según Sophos se utiliza /bin/bash. Es un valor predeterminado documentado para el campo, no la adopción de un valor predeterminado de macOS sin especificar; acordar el shell deseado con los responsables de los Mac.

En Mapping, los atributos de AD se asignan a los siguientes identificadores de macOS:

• UID attribute asigna un atributo de AD al identificador único del usuario en macOS.
• User GID attribute asigna un atributo de AD al identificador del grupo principal de una cuenta de usuario de macOS.
• Group GID attribute asigna un atributo de AD al identificador de grupo de una cuenta de grupo de macOS. Esta asignación no concede privilegios de administrador local; para ello se utiliza Domain administrator groups.

Antes de la asignación, contrastar las correspondencias existentes y aprobadas con los responsables de AD y de los Mac. No presuponer un atributo de AD universal ni que sea seguro dejar vacíos estos campos de asignación. El riesgo descrito anteriormente para el acceso a los archivos existentes sigue siendo aplicable a los cambios posteriores.

En Administrative, obtener la aprobación de las siguientes decisiones antes de la asignación:

• Preferred DC server define el controlador de dominio de AD con el que macOS contacta primero. Si el campo se deja vacío, macOS elige el controlador según la información del sitio de AD y la capacidad de respuesta de los controladores. Acordar la elección con el equipo de AD; introducir un controlador no implica una vinculación exclusiva con él.
• Restrict DDNS limita las interfaces de red para las que macOS utiliza DNS dinámico. De forma predeterminada, macOS utiliza DDNS para todas las interfaces de red. Para limitarlo, introducir los nombres BSD de las interfaces previstas y pulsar Enter después de cada entrada. Sophos cita en0 como ejemplo de un puerto Ethernet integrado; no deducir de ello cuál es la interfaz adecuada en cada Mac. Identificar las interfaces reales del Mac piloto y acordar los registros DNS deseados con el equipo de AD/DNS. Este ajuste limita DDNS; no desactiva ninguna interfaz ni ningún túnel VPN.
• Rotación de la contraseña de la cuenta de equipo: Password trust interval in days afecta a la cuenta de equipo de AD, no a la contraseña del usuario. Un campo vacío implica un cambio automático cada 14 días; 0 impide los cambios automáticos. Acordar el intervalo con los responsables de la operación de AD; no establecer 0 como solución rápida a un problema de conexión.
• Protección de LDAP: Packet signing / Packet encryption comparten una descripción: Allow deja a macOS decidir si las conexiones LDAP se firman y/o cifran; Disable desactiva ambas protecciones; Require exige siempre firma y cifrado; SSL/TLS utiliza siempre LDAP sobre SSL/TLS. No deducir de ello que todos los valores estén disponibles en ambos campos: comprobar las opciones reales en el tenant y definir la protección requerida con el equipo de AD. No reducir la protección para conseguir un inicio de sesión satisfactorio.
• Límites del inicio de sesión: Multi-domain authentication permite iniciar sesión a los usuarios de todos los dominios del bosque de AD. Esto amplía el alcance del inicio de sesión; no es la aplicación de la política de usuario del Self Service Portal descrita anteriormente. Con Namespace = Forest, puede haber usuarios con el mismo nombre en distintos dominios; el inicio de sesión se realiza como DOMAIN\name. Con Domain, la compatibilidad con espacios de nombres está desactivada y los nombres de inicio de sesión deben ser únicos. Registrar previamente los dominios y las cuentas permitidos; la elección de nombres no sustituye la aprobación del alcance del inicio de sesión.
• Privilegios de administrador local: los miembros de los grupos de AD indicados en Domain administrator groups reciben privilegios de administrador en el Mac. Distinguir estos privilegios de los permisos de la cuenta de unión para añadir un equipo. Introducir únicamente grupos aprobados como DOMAIN\group y respetar las mayúsculas y minúsculas. Registrar para el piloto qué cuentas deben seguir siendo usuarios estándar y cuáles deben recibir privilegios de administrador local.

Asignar el piloto y comprobar el resultado

1. Delimite primero el piloto: compruebe el inventario de los Mac designados expresamente y los usuarios afectados, la pertenencia a grupos, los tipos de políticas y asignaciones existentes y que funcione el acceso alternativo. Si ya existe una política, identifique todos los dispositivos y grupos a los que está asignada; si también está asignada fuera del piloto o no está claro su alcance, no la modifique. Antes de sustituir una política de dispositivo o de usuario macOS existente, compare todos sus payloads y dependencias y prepare una vía de recuperación del mismo tipo para esos dispositivos concretos. Use una asignación de grupo solo si puede controlar tanto sus miembros actuales como las futuras incorporaciones; en caso contrario, seleccione dispositivos individuales.
2. En Policies > macOS, utilice Create para crear una política de prueba nueva y aislada del tipo adecuado; si hace una copia, úsela solo como política nueva e independiente, sin asignaciones heredadas. Antes de intervenir por primera vez en los payloads, compruebe que esta política de prueba no esté asignada a ningún dispositivo ni grupo ajeno al piloto autorizado. Mantenga intacta la política de producción ampliamente asignada. Establezca el nombre, la descripción y el nombre de la organización; con Add configuration > Root certificate, cree primero la configuración raíz para Wi-Fi Enterprise. En ella, seleccione Upload a file, elija el certificado raíz X.509 público preparado con codificación PEM o DER y pulse Open. Tras cargarlo, guarde la configuración raíz con Apply. Si se autentica con certificado, cree después Client certificate en la misma política. En esta configuración de Client certificate, seleccione la acción Upload a file en File y elija el archivo PKCS #12 (.pfx) preparado. Active Allow export from keychain solo si la exportación de la clave privada es expresamente necesaria. Después configure Wi-Fi. Añada configuraciones VPN/proxy solo cuando haya resuelto sus dependencias específicas. Si procede, configure SCEP por separado: la guía general de Sophos para crear políticas menciona un SCEP renewal interval a nivel de política cuando se añade SCEP, pero las listas de campos SCEP de macOS no incluyen tal campo de configuración. Compruebe en el tenant si el intervalo de la política está realmente disponible para el tipo de macOS elegido; aclare con la PKI la fecha de vencimiento y el procedimiento de nueva emisión. No trate SCEP como fuente del campo de Wi-Fi Identity certificate sin demostrarlo por separado. Para finalizar, guarde la política con Save en Edit policy; registre el alcance del piloto, los payloads y el estado original para poder volver atrás.
3. Seleccione el triángulo azul de la política de prueba aislada y Assign; en Select devices elija exclusivamente los Mac piloto inventariados o el grupo de dispositivos previamente comprobado y delimitado, y pulse Finish. Antes de finalizar, coteje de nuevo los destinos seleccionados con el inventario; después compruebe las asignaciones reales y deténgase si aparece un grupo de destino inesperado. La selección de este paso no evita que se modifique una política que ya estuviera ampliamente asignada. En esta ruta de macOS no hay un programador Now/Date para la asignación.
4. En el Mac piloto, compruebe los perfiles asignados en System Settings / System Preferences > Profiles dentro del contexto correcto. Los cambios en la política de dispositivo surten efecto en la siguiente sincronización del dispositivo; los de la política de usuario, en el siguiente inicio de sesión del usuario afectado. Un cambio en las políticas de macOS no requiere el paso manual Update devices habitual en iOS. Registre el estado de asignación/tarea y lo que muestra el perfil local, pero no lo considere una prueba de funcionamiento.
5. Compruebe el funcionamiento, no solo el estado del perfil: con el usuario previsto, contraste la SSID y la conexión Wi-Fi y, para Enterprise-EAP, la cadena de confianza del servidor esperada y la identidad de cliente utilizada con el equipo de RADIUS/PKI. Establezca activamente la VPN y compruebe DNS, rutas y destinos accesibles y no accesibles frente al plan de túnel dividido/completo; para proxy/PAC, pruebe un acceso HTTP(S) real y la vía de autenticación. Compruebe los certificados por huella digital, vigencia y finalidad en el llavero correspondiente. Pruebe también con un segundo usuario si importa el efecto sobre todo el dispositivo o los usuarios de AD. Realice una impresión de prueba con AirPrint y pruebe el inicio de sesión en AD solo si se introducen realmente esos payloads. Para Directory service, comprobar el primer inicio de sesión con conexión al servidor AD mediante una cuenta de AD aprobada y el acceso al directorio de inicio local o de red elegido; si se utiliza UNC, comprobar también el montaje esperado. Si se ha previsto una cuenta móvil, comprobar su creación efectiva, incluida la confirmación del usuario si corresponde, y después volver a iniciar sesión sin conexión al servidor AD. Mantener el acceso local independiente durante estas pruebas. Comprobar con el equipo de AD/DNS el controlador de dominio con el que se ha contactado realmente y los registros DDNS efectivos frente a la selección acordada y el conjunto de interfaces previsto. Si el controlador o algún registro DNS no son los esperados, detener el despliegue y aclarar la causa con estos responsables. Comprobar también los privilegios esperados de usuario estándar y de administrador y, cuando lo requieran los límites del inicio de sesión, utilizar una cuenta de prueba autorizada para este fin, ajena al conjunto de dominios o cuentas permitidos, para comprobar que se rechaza el inicio de sesión. Comprobar con el equipo de AD la protección LDAP acordada en la conexión real y contrastar el intervalo efectivo de rotación de la contraseña de la cuenta de equipo; verificar por separado un cambio de contraseña que venza más adelante, sin darlo por validado a partir del primer inicio de sesión. Si el acceso al directorio de inicio, el alcance del inicio de sesión, la protección o los privilegios no son los esperados, detener el despliegue e involucrar a los responsables de AD y de los Mac.
6. Permita otra tanda de equipos piloto solo después de comprobar la conexión, un nuevo inicio de sesión y la sincronización de la administración. Planifique la rotación de certificados con un período de solapamiento: compruebe primero la nueva confianza y la nueva identidad y solo después retire la CA o la autenticación anterior. La elección de una CA para la inspección TLS del firewall y los perfiles de red generales de Apple quedan fuera de esta decisión sobre políticas de macOS en Mobile.

Recuperación si se pierde la conexión o se asigna al grupo equivocado

1. Detenga el despliegue y registre todas las cuentas, los dispositivos, los grupos y las versiones de perfil realmente afectados; use el acceso independiente para comparar el perfil actual con la última combinación que funcionaba. Antes de cada corrección, vuelva a comprobar todas las asignaciones tanto de la política de prueba como de la de recuperación. No elimine de inmediato la única conexión o CA que todavía permite a Sophos Mobile acceder al Mac.
2. En macOS, no dé por disponible la acción genérica Uninstall policy: según la ayuda de administración de Sophos, solo se permite para políticas de dispositivo Android, de contenedor Knox y de dispositivo iOS. Solo si se ha demostrado que la política de prueba está asignada exclusivamente al piloto, corrija sus payloads y espere a la sincronización del dispositivo o al inicio de sesión del usuario. En caso contrario, no modifique ninguna política con asignaciones fuera del piloto: delimite primero el alcance con los responsables y utilice el acceso independiente. Como alternativa, asigne una política preparada y funcional del mismo tipo exclusivamente a los Mac piloto afectados; compruebe antes también sus asignaciones y payloads, no edite una política de producción compartida para recuperarse ni lance ninguna acción global sobre grupos o de Unassign. Al sustituir una política previamente asignada, compruebe sus dependencias y el contexto efectivo de usuario/dispositivo. Eliminar localmente una política de usuario no es una recuperación duradera: se vuelve a asignar en el siguiente inicio de sesión. No elimine el perfil de registro para revertir el cambio: esto anula el registro del Mac y requiere privilegios de administrador.
3. Antes de retirar una CA raíz antigua, compruebe todos los certificados Wi-Fi/VPN y SCEP/de cliente que dependen de ella, así como la vía alternativa que funciona; si se ha cambiado la asignación de AD/UID, no arriesgue los permisos de archivos alternando perfiles a ciegas. Demuestre en el mismo Mac piloto que se han restablecido la conexión de red, el inicio de sesión, la cadena de certificados y la sincronización con Sophos Mobile. Si el Mac sigue sin acceso de administración, recurra al soporte local de Mac/red/PKI con los valores anteriores y posteriores documentados.

Alcance de la validación: Aquí no se ha validado en laboratorio ninguna combinación de macOS y tenant. Esta guía documental condicionada no exige una prueba general en tenant/laboratorio antes de publicarse. Antes de un despliegue de producción en el entorno concreto o de afirmar que la conexión funciona, compruebe en un Mac piloto autorizado la edición/licencia, versión de macOS, alcance de la política y asignación del usuario en Apple Business, sincronización e inicio de sesión, confianza PKI, Wi-Fi EAP y la identidad de cliente realmente utilizada. Para usar SCEP como identidad de Wi-Fi, debe demostrarse en el tenant propio si la identidad emitida puede seleccionarse en el campo de Sophos Identity certificate o si realmente queda vinculada de otra forma al perfil Wi-Fi distribuido; compruebe también la identidad/huella digital en el llavero de dispositivo/usuario correcto y un inicio de sesión EAP/RADIUS satisfactorio con ese certificado concreto en el Mac piloto gestionado. La mera emisión del certificado o instalación del perfil no basta. Para usar SCEP como identidad VPN también deben demostrarse la selección o vinculación distribuida, el llavero y contexto de usuario correctos y un inicio de sesión VPN satisfactorio con el certificado esperado en el Mac piloto; la ayuda de Sophos para VPN menciona campos de certificado, pero no describe cómo vincular SCEP. La vinculación SCEP con Wi-Fi/VPN sigue sin resolverse y no es una vía operativa sin un piloto autorizado que demuestre su funcionamiento. Antes de usarla en producción, pruebe en el dispositivo la aplicación/proveedor/autenticación VPN, la rotación de certificados, el acceso independiente y la sustitución y recuperación de políticas.