Sincronizar Active Directory con Sophos Central

Sophos Central puede importar usuarios y grupos desde un Active Directory local. Estas identidades se utilizan, entre otros fines, para asignar políticas y asociar dispositivos. Sin embargo, una sincronización sin control puede crear cuentas innecesarias, objetos duplicados o eliminaciones inesperadas.

Microsoft Entra ID se sincroniza mediante un conector separado. Las instrucciones están en Sincronizar Microsoft Entra ID con Sophos Central.

Definir el modelo de fuentes antes de la instalación

Central puede administrar hasta 25 fuentes de directorio por tenant. Para un número mayor se prevé una estructura Central Enterprise. Los usuarios y las direcciones de correo deben ser únicos dentro de un tenant de Central. Un mismo dominio no puede proporcionar usuarios simultáneamente desde varias fuentes AD, Entra ID o Google Directory.

En un Trial, Sophos también limita el número de Directory Objects que pueden crearse o utilizarse, incluidos usuarios, dispositivos y grupos. Por tanto, una importación de prueba incompleta no implica automáticamente un error de filtro. Antes de un piloto se comprueban conjuntamente el alcance del Trial, el número de objetos esperado y el estado de las licencias.

Dentro de un forest pueden seleccionarse varios Child Domains y un tenant también puede sincronizar varios forests. Aun así, Sophos recomienda conectar cada forest a un único tenant de Central. Si el mismo forest se importa en varios tenants o varios forests contienen los mismos usuarios o direcciones de correo, las ejecuciones actualizan alternativamente las mismas identidades aparentes. Central no combina estos registros, por lo que los nombres, atributos y asignaciones de grupos pueden quedar incoherentes.

En cambio, una combinación compatible puede ser útil: AD sincroniza equipos y grupos de equipos, mientras que Entra ID proporciona usuarios y grupos de usuarios para el mismo dominio. Las Shared Mailboxes de un grupo de Microsoft 365 requieren Entra ID o Google Directory. Una Shared Mailbox normal fuera de un grupo de Microsoft 365 puede importarse mediante AD Sync.

Las Shared Mailboxes y Public Folders del mismo dominio que los usuarios necesitan AD Sync Utility junto con Sync users and user groups. Los buzones de grupos de Microsoft 365 no se importan mediante AD Sync. Tampoco se sincroniza una Shared Mailbox sin Delegate. Si permanece un buzón de usuario inactivo con delegación de correo a un buzón activo, AD Sync no lo elimina y puede seguir administrándolo en Central como Shared Mailbox.

Para el mismo dominio o subdominio solo se ejecuta un cliente AD Sync productivo. Tampoco puede haber varios dispositivos AD con el mismo nombre DNS, ya que Central no podría hacerlos coincidir de forma inequívoca. Al cambiar de servidor se detiene la programación anterior antes de que la instancia nueva sincronice en producción.

Si se va a utilizar el Self Service Portal para Sophos Email, Device Encryption o Mobile, el acceso de usuario se activa antes de la primera sincronización del directorio. Así, los usuarios nuevos y existentes reciben la invitación prevista. El procedimiento se explica en Configurar el acceso al Self Service Portal de Sophos Central.

Límites de AD Sync y grupos entre dominios

AD Sync no combina los datos de varios forests o Directory Services en un registro maestro. Por eso, el mismo usuario o dirección de correo no puede existir en más de un forest sincronizado. Los usuarios, direcciones o grupos duplicados pueden actualizarse alternativamente con los datos de su fuente en cada ejecución e incluso cambiar el Directory Owner visible en Central. Los usuarios y correos deben seguir siendo únicos por tenant; los usuarios del mismo dominio no pueden sincronizarse a la vez desde AD y Entra ID ni entregarse en paralelo a varias cuentas Central Admin.

En un grupo con miembros de varios dominios, Central solo importa usuarios del dominio al que pertenece el grupo. Preview and Sync puede mostrar todos los miembros, pero los del otro dominio no se añaden al grupo durante la sincronización productiva. Este comportamiento se prueba en Universal Groups y Child Domains con un miembro de prueba por dominio.

Los usuarios y grupos de usuarios se sincronizan o desactivan conjuntamente. Lo mismo se aplica a dispositivos y grupos de dispositivos. Se admiten como máximo 1'000 filtros por Directory Object; los filtros LDAP adicionales pueden tener hasta 5'000 caracteres. No se admiten componentes de dominio con más de 63 caracteres o que comiencen o terminen con - o _.

Los buzones de grupos de Microsoft 365 requieren Entra ID. AD Sync no admite una Shared Mailbox sin Delegate, varios clientes AD Sync productivos para el mismo dominio o subdominio ni varios dispositivos AD con un nombre DNS idéntico. En cambio, un buzón inactivo delegado a uno activo puede conservarse como Shared Mailbox. Estos límites se tratan como decisiones de diseño antes de la primera ejecución, no se eluden posteriormente ampliando filtros.

Depurar objetos AD inactivos antes de sincronizar

Siempre que sea posible, las cuentas de usuario y los dispositivos inactivos se revisan y eliminan o desactivan directamente en Active Directory. No solo aumentan el inventario de Central, sino que siguen siendo un riesgo de seguridad en la fuente. La depuración también reduce el archivo de sincronización transmitido a Sophos Central y puede acelerar la ejecución.

Los filtros LDAP pueden impedir que los usuarios inactivos lleguen a Central y también reducir el archivo de sincronización. Sin embargo, no corrigen el riesgo de una cuenta AD inactiva que sigue existiendo. Por eso, el proceso operativo combina un periodo de inactividad trazable, la aprobación del propietario, la depuración de la fuente y una posterior ejecución de Preview. Los dispositivos se revisan por separado según su antigüedad, último contacto con el dominio y estado de protección antes de eliminar una cuenta de equipo.

Administrar Directory Sources en Central

La vista central se encuentra en Global Settings > Platform > Directory service. Se necesita un rol de Central Admin adecuado para configurar y administrar una fuente. Según el tipo deseado, la página ofrece Add Active Directory, Add Microsoft Entra ID y Add directory service for Google. Desde allí se descarga el software de instalación actual para AD local; Entra ID y Google se autorizan mediante sus conectores cloud correspondientes.

La lista de fuentes muestra para cada entrada el nombre, tipo, dominio, programación y estado. Las advertencias o errores no solo se revisan en esta vista, sino también en Alerts and Reports > Logs > General Logs > Events. Un estado verde de la fuente no basta si la última ejecución está obsoleta o el número de objetos esperado no coincide.

Al hacer clic en el nombre se abren los detalles. Para AD se comprueban especialmente el número de usuarios, grupos, dispositivos, grupos de dispositivos, Public Folders y Shared Mailboxes, además del hostname, la versión del cliente, el dominio, el estado y la hora de la última sincronización. Para Entra ID y Google son prioritarios los números de usuarios y grupos, el estado, la última ejecución y la programación. Tras la configuración inicial y cada cambio de filtro o fuente, estos valores se comparan con una cantidad de referencia conocida.

Según el tipo de fuente, allí también pueden modificarse la configuración y los filtros, purgarse los datos sincronizados y eliminarse la fuente. Son intervenciones diferentes: Purge elimina los datos de directorio importados desde esa fuente, mientras que Delete elimina además la Directory Source. Para AD se detienen previamente las opciones de sincronización y los clientes activos; para Entra ID y Google se utilizan sus respectivos cuadros de diálogo de filtros, purga y eliminación. Antes de cualquier variante se exportan los usuarios, grupos, dispositivos, políticas y buzones afectados y se leen las consecuencias anunciadas en Central. Purge o Delete no son pruebas de conexión sin compromiso y no se confirman sin un plan de reversión.

El nombre y la descripción de una fuente solo pueden modificarse después de desactivarla con Turn off. Tras guardar se reactiva con Turn on y se comprueba. La desactivación interrumpe las actualizaciones, por lo que no se realiza durante un cambio de directorio no revisado. Una vez activada productivamente la sincronización de una fuente, este paso no puede deshacerse sin más. Para una ejecución manual se abre la fuente y se selecciona Synchronize; después se comprueban el estado, la hora y los cambios de objetos.

Planificar Self Service y Shared Mailboxes antes de sincronizar

Si un usuario va a utilizar el Self Service Portal, User Access se activa antes de la primera sincronización del directorio. Así Central puede enviar las invitaciones en el flujo previsto. Activar el acceso más tarde no corrige automáticamente todos los envíos omitidos; por eso, los usuarios piloto, la entrega de correo y el acceso al portal ya se prueban antes de la importación amplia.

En Central, las Shared Mailboxes no siempre tienen atributos completos de usuario. Los usuarios delegados reciben acceso Self Service a la Shared Mailbox asignada y, según el producto licenciado, pueden ver Emergency Inbox y Quarantine Summary. Un Delegate puede recibir así resúmenes de su buzón propio y de la Shared Mailbox. Por eso, las delegaciones y direcciones de entrega se prueban en la práctica después de sincronizar, no se aprueban solo por el número de objetos.

Una Shared Mailbox dentro de un grupo de Microsoft 365 no puede sincronizarse mediante AD local; para ello se utiliza Microsoft Entra ID o Google Directory. AD Sync sí puede importar una Shared Mailbox normal fuera de un grupo de Microsoft 365. Antes de una migración posterior a Entra ID se registra en un inventario de qué tipo de objeto procede cada buzón. De lo contrario, una sincronización AD que continúe tras el cambio de fuente puede eliminar buzones o dejarlos con datos obsoletos.

Antes de la primera sincronización

Defina primero qué directorio es la fuente autoritativa para cada usuario y grupo. Las mismas personas no deben crearse manualmente e importarse simultáneamente desde AD y Entra ID.

Para el primer ciclo, utilice una OU de prueba pequeña con usuarios y grupos representativos. Compruebe:

• direcciones de correo y User Principal Names,
• grupos anidados y pertenencias,
• cuentas deshabilitadas u obsoletas,
• cuentas de servicio y técnicas,
• conflictos de nombres con objetos existentes de Central.

Cada usuario que se sincronice necesita una dirección de correo inequívoca. Muchos procesos de Central la utilizan como identidad y destino de entrega; con Sophos Email, un mensaje dirigido a una dirección sin usuario asignado puede incluso quedar sin entregar. Además, el firewall o proxy debe poder acceder a los dominios y puertos documentados para Central. Una prueba LDAP correcta por sí sola no confirma esta ruta cloud.

Instalar AD Sync Utility

Descargue el software de sincronización actual directamente desde Sophos Central e instálelo en un sistema Windows permanentemente disponible. El sistema necesita acceso de red al controlador de dominio y a los servicios de Sophos requeridos.

El Active Directory Synchronization Setup Software actual solo funciona en Windows de 64 bits y requiere .NET Framework 4.6.2. Sophos enumera Windows 7, 8.1, 10 y 11, además de Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019, 2022 y 2025. Como Domain Controller, Sophos indica Windows Server 2008 R2 a 2025. Esta compatibilidad del fabricante no sustituye al ciclo de vida de Microsoft: para una instalación productiva nueva se utiliza un sistema operativo de servidor actualmente compatible y parcheado, no Windows 7 ni una versión de Windows Server retirada.

Para acceder a Central se utilizan API Credentials con el rol Service Principal Active Directory Sync, no credenciales generales de Super Admin.

La cuenta de servicio AD recibe únicamente los permisos necesarios para leer los forests y objetos seleccionados. Se documentan la caducidad de la contraseña, el inicio del servicio y la responsabilidad. Una cuenta personal de administrador no es adecuada.

La Utility no puede procesar un dominio si uno de los componentes de su nombre tiene más de 63 caracteres o comienza o termina con - o _. Este límite se comprueba antes de instalar, porque un nombre para mostrar abreviado u otro UPN no corrigen un nombre de dominio AD no válido.

Sophos ha probado hasta 30'000 objetos AD. Por encima de 40'000 registros de usuario, la interfaz puede responder más lentamente. Los entornos mayores necesitan filtros especialmente estrictos y pruebas con tiempos de ejecución realistas.

En cada ejecución, la Utility comprueba si existe una versión más reciente y normalmente realiza automáticamente las actualizaciones posteriores. Las versiones antiguas de AD Sync ya no admiten la autenticación actual de Central y pueden fallar por completo si esta actualización automática no funciona. En ese caso, se descarga el instalador actual en Global Settings > Platform > Directory service y se ejecuta sobre la instalación existente. Después se crean nuevas API Credentials con el rol Service Principal Active Directory Sync y se introducen como Client ID y Client Secret en la Utility. Cada instancia productiva recibe una identidad técnica trazable, una responsabilidad documentada y su propia rotación de secretos.

Al iniciar, la Client ID y el Client Secret se comprueban con Validate credentials. Si la Utility debe comunicarse mediante un proxy, se activa Configure proxy manually y se introduce la dirección. Si el proxy exige autenticación, se añaden Enable proxy authentication, el usuario y la contraseña del proxy. Solo una segunda prueba satisfactoria de las credenciales confirma que funcionan tanto los datos de API como la ruta del proxy.

Esta interfaz de proxy pertenece a Active Directory Synchronization Setup 4.0. Un Trial puede recibir todavía la antigua Sophos Central AD Sync Utility 3.5.4, cuya interfaz no permite introducir datos de proxy. El servicio se ejecuta de forma predeterminada como Local Service y, ante un proxy con autenticación, suele fallar con Failed active directory synchronization, una System.Net.Http.HttpRequestException y CommandLib.HttpRequestCommand+HttpStatusException. Una cuenta de servicio alternativa utilizada para ello necesita Log on as a service, inicio de sesión interactivo y Batch, permisos de lectura en las OU afectadas y control total sobre C:\ProgramData\Sophos\Sophos Cloud AD Sync. Después de cada cambio de esa cuenta se vuelve a configurar la Utility antigua. Siempre que sea posible, en producción se utiliza el software 4.0 actual.

Para el acceso LDAP se utiliza una cuenta de lectura para todo el forest seleccionado. Use LDAP over an SSL connection permanece activado siempre que sea posible. LDAPS suele utilizar TCP 636 y LDAP sin cifrar TCP 389. Debido a LDAP Signing y Channel Binding, el puerto 389 no es una alternativa fiable en entornos Active Directory actuales. Para LDAPS, el Domain Controller necesita un certificado válido y de confianza para el sistema de sincronización.

Si puede demostrarse que el entorno LDAP concreto no admite SSL, se puede desactivar Use Secure LDAP y cambiar el puerto al servicio LDAP sin cifrar. Es una alternativa documentada, no una Best Practice. Las credenciales y los datos de directorio ya no están protegidos por TLS durante el transporte; por eso, la segmentación, la ruta de red y una migración rápida a LDAPS se tratan como un riesgo.

Qué espera la Utility en el forest

Para un forest completo, AD Sync lee en la raíz del árbol de directorio rootDomainNamingContext con el Distinguished Name del dominio raíz del forest y defaultNamingContext con el Distinguished Name del servidor utilizado. En CN=Partitions,CN=Configuration,<rootDomainNamingContext>, la Utility espera entradas para los contextos de nombre relevantes con netBiosName, dnsRoot y nCName. El valor de nCName determina los ámbitos de búsqueda adicionales, siempre que no sea un Distinguished Name superior al servidor indicado en la interfaz de instalación.

Si falta uno de esos atributos o la cuenta de servicio no puede leer la partición Configuration, una prueba de inicio de sesión puede funcionar aunque la detección del forest o la sincronización posterior fallen. En ese caso se comprueban los valores con LDP.exe usando la misma cuenta de servicio antes de modificar filtros u objetos de Central.

Filtrar OU y objetos

Los filtros limitan el alcance de la sincronización. Incluya solo las OU, usuarios y grupos que Sophos Central realmente necesita. Una importación amplia desde la raíz rara vez es adecuada.

Antes de importar, Preview comprueba qué objetos se añadirían, modificarían o eliminarían. Especialmente las eliminaciones no deben aprobarse sin revisión. La vista Preview o Pending Changes puede mostrar incorrectamente caracteres UTF-16 o Double-Byte, por ejemplo, como ???. Aun así, los datos se transmiten a Sophos Central y allí se muestran. Por eso, los nombres en chino, japonés o coreano se comprueban también directamente en Active Directory y después de una sincronización piloto controlada en Central.

Sophos describe este problema de Preview como una limitación que se corregirá en una versión futura de AD Sync Utility. Hasta que la versión utilizada lo haya resuelto de forma demostrable, seguirá siendo necesario revisar la fuente y el resultado posterior a la sincronización.

Base DN y LDAP filter cumplen tareas diferentes. Base DN limita la búsqueda a OU seleccionadas; la pertenencia a una OU no se expresa de forma fiable solo con un filtro LDAP normal. LDAP filter limita atributos o grupos dentro de ese espacio. Ambos se mantienen por Domain porque Child Domains no heredan la configuración de Parent Domain; los filtros de usuarios y grupos también son independientes.

En la pestaña AD Filters, Search Bases y LDAP Query Filters se introducen por separado para cada dominio y, si es necesario, por separado para usuarios y grupos. Una Search Base para una OU de Finance puede ser, por ejemplo:

OU=Finance,DC=myCompany,DC=com

Un filtro de usuarios para miembros de un grupo puede ser:

memberOf=CN=testGroup,DC=myCompany,DC=com

Sin un filtro de grupos adicional, Central sigue detectando todos los grupos a los que pertenecen esos usuarios. Si también debe limitarse la selección de grupos a uno concreto, se añade, por ejemplo, CN=testGroup como filtro de grupos. Un cambio de filtro puede sacar del alcance usuarios y grupos sincronizados previamente y eliminarlos de Central; por eso siempre se realiza una vista previa completa.

Sophos utiliza estos filtros como punto de partida:

Benutzer: (&(objectCategory=person)(objectClass=user)(!sAMAccountType=805306370)(!userAccountControl:1.2.840.113556.1.4.803:=2))
Gruppen:  (&(objectCategory=group)(objectClass=group))

El filtro de usuarios incluye personas con la clase user, pero excluye objetos de equipo mediante sAMAccountType=805306370 y cuentas desactivadas mediante el bit correspondiente de userAccountControl. Los filtros adicionales se combinan con estas condiciones básicas para cada dominio y se prueban primero con LDP.exe.

Sophos limita la configuración a 1'000 filtros por objeto de directorio y a 5'000 caracteres por filtro LDAP adicional. Los usuarios solo pueden sincronizarse junto con los grupos de usuarios, y los dispositivos solo junto con los grupos de dispositivos. En grupos entre dominios, la vista previa muestra todos los miembros, pero Central solo importa usuarios del dominio al que pertenece el grupo. Estos grupos deben probarse expresamente antes de la sincronización en producción.

El resultado esperado se verifica con Microsoft LDP.exe: Search Base de AD Sync corresponde a Base DN y la expresión LDAP a Filter. Así se distingue si Sophos omite el objeto o si ya falta en la consulta de directorio. Algunas comparaciones pueden distinguir mayúsculas.

Los filtros basados en lastLogon o lastLogonTimestamp se utilizan con precaución. lastLogon suele ser más reciente, pero no se replica entre Domain Controllers; para obtener un valor fiable habría que consultar todos ellos. lastLogonTimestamp sí se replica, pero puede estar desactualizado. Sophos recomienda eliminar las cuentas y dispositivos inactivos en la fuente en lugar de depender únicamente de un filtro temporal.

Si aun así lastLogonTimestamp debe utilizarse como filtro transitorio, primero se fija una fecha de corte UTC y se convierte a Windows FILETIME mediante un conversor LDAP/Active Directory FILETIME fiable. La fecha de ejemplo de Sophos, 1 de diciembre de 2020 a las 00:01, da 132581431640000000. En Active Directory Synchronization Setup > AD Filters, se introduce en Custom Filters la expresión LDAP adicional:

(lastLogonTimestamp>=132581431640000000)

El valor de ejemplo no se adopta sin cambios. Se elige conscientemente una fecha de corte propia, se convierte correctamente y se documenta junto con la zona horaria y la aprobación del cambio. Después se ejecuta Preview and Sync, se revisan los usuarios incluidos y excluidos y solo entonces se autoriza la ejecución productiva.

AD Sync solo crea grupos con más de un miembro. Por tanto, un grupo vacío o con exactamente un miembro no aparece como objeto esperado en Central. Los usuarios o correos duplicados en varios forests no se combinan; por ello, el origen de un objeto puede cambiar entre ejecuciones. Siempre que sea posible, cada forest se sincroniza con un único tenant de Central.

Exclude disabled user accounts está activado de forma predeterminada. Para sincronizar Shared Mailboxes, esta opción debe permanecer activada. Si se desactiva, Central puede crear objetos de buzón duplicados para Shared Mailboxes. Las cuentas de usuario normales desactivadas deben depurarse en la fuente en cualquier caso, no reintroducirse mediante una sincronización más amplia.

Los interruptores de tipos de datos tienen dependencias concretas:

• Sync users and user groups sincroniza ambos conjuntamente e incluye las Shared Mailboxes normales. Si se desactiva, esta fuente AD no puede sincronizar Shared Mailboxes ni Public Folders.
• Sync public folders requiere además Sync users and user groups, porque los Public Folders se tratan como objetos de buzón.
• Para los dispositivos, Sync devices y Sync organizational units se activan conjuntamente durante el funcionamiento normal. En una configuración inicial pueden importarse primero únicamente las OU para preparar las políticas antes que los dispositivos.
• Si más adelante solo se desactiva Sync organizational units, los dispositivos permanecen activos, pero las OU anteriores aparecen como Custom Groups. Si solo queda activa la sincronización de OU, los dispositivos dejan de asignarse a los grupos de Central.

Sin grupos OU preparados, los nuevos dispositivos sincronizados reciben inicialmente las Default Policies. Después del piloto de OU se activan conjuntamente ambos interruptores de dispositivos y se comprueban tanto la asignación como la política aplicada realmente.

En grupos muy grandes también importa el atributo AD member. Desde 1'500 entradas, Active Directory usa Range Retrieval como member;range=0-1499 y vacía el atributo simple member. Si el grupo ya superaba 1'500 objetos antes del primer Sync, puede faltar en Central o mostrar una cifra errónea. Siempre que sea posible se limita a menos de 1'500 usuarios y se comprueba con LDP.exe.

Coincidencia de usuarios y alias de correo

Central compara los usuarios de AD con los existentes mediante el Domain Login en formato DOMAIN\user o mediante el atributo mail. El nombre para mostrar procede de Display name y los alias de correo adicionales, de proxyAddresses. Si hay coincidencia, el objeto existente de Central se convierte en objeto administrado por el directorio; si no, se crea un usuario nuevo. Preview and Sync muestra las coincidencias en Users to Modify y los objetos nuevos en Users to Add.

Un objeto sincronizado por otro Directory Service no se crea como segundo usuario si hay coincidencia, pero puede recibir una dirección de correo adicional desde AD. En cambio, un usuario manual y un usuario AD con el mismo nombre pueden seguir como objetos separados si no coinciden el inicio de sesión y el correo. El nombre para mostrar no es una clave de coincidencia.

En Preview and Sync, las coincidencias de Users to Modify y las identidades nuevas de Users to Add se revisan individualmente. Una asignación incorrecta se rechaza en lugar de aceptar toda la propuesta mediante Approve Changes and Continue. El cambio de usuario manual a objeto administrado por AD también se identifica por el icono de directorio.

Si se elimina un usuario de AD, el comportamiento de Central depende de sus relaciones. Los administradores y los usuarios con un dispositivo o inicio de sesión asignado permanecen como usuarios normales de Central. En cambio, un usuario puro sin dispositivo, inicio de sesión ni rol privilegiado puede eliminarse automáticamente. Por la misma razón de protección, los cambios en la dirección de correo de un Central Admin no se adoptan ciegamente desde AD. Por eso se revisan por separado los roles de administrador y las relaciones con dispositivos antes de una baja.

Si debe cambiarse la dirección de correo principal de un administrador gestionado por el directorio o eliminarse su objeto de Central tras borrarlo de AD, su rol se retira de forma controlada antes de la siguiente sincronización. Después se puede volver a asignar el rol necesario. Durante el proceso siempre se mantiene un segundo Super Admin funcional como vía de recuperación.

Nombre incorrecto por inicios de sesión solapados

Si el usuario A también tiene por error el inicio de sesión del dispositivo del usuario B, AD Sync puede asignar inicialmente ambos logins a A y, al procesar después a B, renombrar el registro existente como B. Por eso, en Logins del usuario afectado se eliminan todas las asignaciones ajenas y se vuelve a sincronizar. No se corrige simplemente el nombre mientras persista el login incorrecto.

No se puede asignar un rol a un usuario de AD

Primero se busca la dirección de correo en My Environment > Users & Groups > Users. Si hay duplicados, se documentan los inicios de sesión de los objetos que no se utilizarán, se eliminan allí mediante Edit logins y se añaden al usuario correcto. Solo entonces se guarda el rol y se comprueba el envío de la configuración. Si la dirección sigue bloqueada en todo el tenant, no se continúa eliminando, sino que se resuelve el conflicto mediante soporte.

Interpretar correctamente los grupos anidados

La página del usuario puede mostrar, además del grupo AD directo, grupos superiores anidados como linked groups. Esto no significa automáticamente que el usuario sea miembro directo de todos los grupos mostrados. Para analizar permisos y políticas se comprueban por separado la pertenencia directa en AD, el anidamiento y la política de Central aplicada realmente.

Asignar el inicio de sesión de Mac al usuario sincronizado

AD Sync importa un login como NETBIOSDOMAIN\user, mientras que un Mac suele notificarlo como MACNAME\user. Central puede crear así un segundo objeto de usuario automáticamente. Después de revisar los dispositivos afectados se depura ese objeto y se asigna MACNAME\user al usuario sincronizado desde AD. Para un despliegue amplio se prueba el Domain Override previsto por Sophos en lugar de realizar correcciones manuales.

Sincronizar equipos y grupos OU

El descubrimiento admite equipos y servidores Windows. Sophos asocia un dispositivo protegido con el objeto AD mediante FQDN y hostname y lo mueve al grupo OU sincronizado. Por tanto, un equipo asignado manualmente a un grupo puede volver a la estructura AD en la siguiente sincronización.

Se crea un objeto nuevo de dispositivo o grupo cuando Central todavía no conoce una entrada con el mismo ObjectGUID de AD. Si el nombre de un grupo AD nuevo coincide con el de un grupo existente, Central utiliza el Distinguished Name para el grupo nuevo. No se admiten varios registros AD con el mismo DN.

Para la coincidencia deben concordar FQDN y hostname. Si existe un dispositivo de Central con el dominio y hostname adecuados, pero con otros datos almacenados, la sincronización actualiza esa información y lo mueve al grupo AD correspondiente. Si hay dos dispositivos con el mismo FQDN, se desasocia el objeto vinculado hasta ese momento y se conecta el registro nuevo. Por eso se depuran los hostnames duplicados antes de sincronizar, en lugar de tratar la nueva vinculación resultante como una pérdida aleatoria de dispositivos.

Las OU se sincronizan antes que los dispositivos para poder preparar primero las políticas en los grupos previstos. Los dispositivos y grupos sincronizados no pueden reorganizarse permanentemente en Central en contra de la estructura AD. Una jerarquía de más de 40 niveles se combina en el nivel 40.

Los dispositivos y grupos sincronizados pueden moverse o eliminarse en Central, pero no editarse como objetos locales. Estos cambios manuales no son permanentes: la siguiente sincronización restaura la estructura AD o vuelve a crear el objeto. Si se elimina un dispositivo protegido en AD, Central lo mueve en la siguiente ejecución a un grupo no estructurado y retira la marca de dispositivo administrado por AD. Los cambios de nombre, detalles del sistema operativo o estructura OU también se adoptan en el siguiente ciclo, incluido el movimiento y la eliminación de grupos.

Las políticas de grupos creados manualmente se conservan. Sin embargo, los dispositivos administrados por AD se mueven de esos grupos al grupo sincronizado y allí reciben inicialmente las Default Policies si no se asignó previamente una política adecuada. Una política de un grupo superior se hereda en un grupo anidado mientras este no tenga una asignación propia. Por eso primero se sincronizan las OU, después se asignan las políticas y solo entonces se importan los dispositivos.

Sophos no ofrece actualmente una API para Directory Devices y Device Groups sincronizados desde AD. Las automatizaciones no deben suponer que pueden administrar toda esta estructura mediante API como si fueran grupos normales de Central.

My Environment > Unmanaged devices muestra en vistas separadas equipos y servidores conocidos por AD que no tienen agente Sophos. Los paquetes de protección necesarios están disponibles en My Environment > Installers. Esta vista de inventario no instala protección; cada dispositivo esperado permanece en el proceso de despliegue o de excepciones hasta que se instala el agente o se aprueba una excepción documentada.

Programación y supervisión

El horario de sincronización debe ajustarse al ritmo de cambios de la organización. Después de cada ciclo, compruebe estado, errores y cambios de objetos. Un servicio iniciado correctamente no demuestra que todos los objetos se hayan sincronizado bien.

Resuelva rápidamente avisos sobre credenciales, conectividad, atributos ausentes o conflictos de objetos. La operación necesita un responsable y un sustituto identificados.

En la primera ejecución y después de cada cambio de filtro se inicia manualmente Preview and Sync. La vista previa se revisa en busca de objetos nuevos, modificados y que se eliminarán, y solo después se confirma con Approve Changes and Continue. Una ejecución manual puede tardar hasta 15 minutos. Si solo se desean ejecuciones manuales controladas, se selecciona Never. Only sync when manually initiated en la programación.

Los Runtime Logs se encuentran en:

C:\ProgramData\Sophos\Sophos Cloud AD Sync\Logs\

Rotan en siete archivos diarios. Un log necesario se copia o renombra antes de la siguiente rotación. Un Email Alert Medium suele contener solo el resumen; la causa concreta se busca en el log del mismo periodo.

Al sustituir el servidor AD Sync nunca se ejecuta simultáneamente una segunda instancia no controlada. Primero se detiene la programación en el servidor anterior. Después se instala la Utility actual en el nuevo servidor, se compara la configuración de filtros existente y se comprueba con Preview and Sync. La programación solo se activa allí después de una ejecución manual correcta y, a continuación, se elimina la instalación antigua.

Eliminación y reconstrucción

Eliminar un objeto del directorio de origen o excluirlo mediante un filtro puede afectar al objeto correspondiente de Central y a sus asignaciones de políticas. Antes de un cambio masivo, lea y documente las acciones anunciadas en la interfaz.

Eliminar la configuración de sincronización o los datos sincronizados no es un paso normal de diagnóstico. Compruebe primero asociaciones de dispositivos, pertenencias a grupos y posibles duplicados. Una reconstrucción sin análisis puede reproducir los mismos problemas.

Antes de seleccionar Purge data, detenga todas las instancias AD Sync en ejecución o copiadas y revise los filtros; de lo contrario, los datos reaparecerán. Purge no se puede deshacer. Los dispositivos administrados y sus usuarios asociados, y los administradores, no se eliminan aunque originalmente procedieran de AD.

Purgar datos AD sincronizados

El procedimiento comienza en Global Settings > Platform > Directory service. Allí se abre el nombre de la fuente AD, se detiene con Turn off y se selecciona Purge data. En el diálogo se elige conscientemente el ámbito que se eliminará:

• Users and user groups elimina además las Shared Mailboxes y Public Folders sincronizados.
• Devices and device groups elimina el inventario sincronizado de dispositivos y grupos, salvo los objetos protegidos indicados por Sophos.

Después de confirmar que la acción es irreversible, se selecciona nuevamente Purge data. Central elimina el inventario elegido y no vuelve a sincronizar ese tipo de datos desde la fuente detenida. Si se eliminaron todos los datos AD, los usuarios, dispositivos y grupos deberán administrarse a partir de entonces de forma manual o mediante una fuente nueva y claramente delimitada. Por ejemplo, Microsoft Entra ID puede asumir los usuarios y grupos de usuarios.

Antes de purgar se buscan y detienen todas las copias de AD Sync Utility y sus programaciones. Los filtros por sí solos no impiden que los datos vuelvan si una segunda instancia sigue sincronizando. Después se comprueban los administradores restantes, los dispositivos administrados y sus usuarios asignados, ya que Central no elimina estas excepciones.

Migrar de AD a Microsoft Entra ID

Sophos permite trasladar la sincronización de usuarios y grupos de un dominio desde AD a Entra ID. Deben existir ya fuentes AD y Entra adecuadas para el mismo dominio, y los usuarios de ambas fuentes deben coincidir de forma fiable. Los usuarios AD sin coincidencia pueden eliminarse de Central durante la migración.

Entra ID no sincroniza equipos ni grupos de equipos. Si siguen siendo necesarios, AD permanece activo para dispositivos mientras Entra ID proporciona usuarios y grupos del mismo dominio. Public Folders y asignaciones existentes de Shared Mailbox tienen más restricciones y se comprueban por separado antes de migrar.

La migración comienza con una exportación y una lista comparativa, no cambiando inmediatamente el origen. Si los usuarios coinciden entre AD y Entra ID, Central actualiza el objeto existente y conserva los buzones asociados. Los usuarios que no coincidan pueden eliminarse junto con su asignación de buzón; los nuevos usuarios de Entra se crean. Los grupos de usuarios sin coincidencia permanecen, pero dejan de actualizarse.

Las Shared Mailboxes y Public Folders requieren atención especial. Central conserva las Shared Mailboxes anteriores de AD con el último estado recibido, pero deja de actualizarlas mediante AD. Pueden aparecer además nuevas Shared Mailboxes de Entra. Los Public Folders también permanecen con su último estado. Si después de la migración se sigue utilizando la antigua sincronización AD local para estos objetos, las Shared Mailboxes pueden eliminarse inesperadamente debido a los distintos tipos de objeto.

Después se comprueban los usuarios, grupos, políticas, asignaciones de dispositivos, Shared Mailboxes, Public Folders y duplicados. Si AD sigue activo para dispositivos, Sync devices y Sync organizational units se mantienen funcionando conjuntamente.

Requisitos y decisión de migración

AD y Entra ID deben representar el mismo dominio. Antes de la migración se comparan los usuarios mediante direcciones de correo inequívocas y otros rasgos de identidad coincidentes para que Central actualice las cuentas existentes en lugar de eliminarlas y recrearlas. El conector de Entra y sus permisos de aplicación se preparan por completo antes de desactivar la fuente AD.

Public Folders, equipos y grupos de equipos siguen procediendo únicamente de AD. Por eso se decide para cada dominio si basta Entra ID o si AD debe continuar en paralelo para dispositivos y estructuras OU. Las Shared Mailboxes también se registran por separado en el inventario según sean objetos de AD, Entra o grupos de Microsoft 365.

Utilizar únicamente Microsoft Entra ID

Esta opción es adecuada si Central ya no necesita actualizar desde el AD local ni dispositivos y grupos de dispositivos ni Public Folders.

1. Ejecutar la última sincronización AD y comprobar usuarios, grupos, buzones y errores.
2. En Global Settings > Platform > Directory service, abrir la fuente AD y desactivarla con Turn off.
3. Configurar mediante Add Microsoft Entra ID la fuente Entra para el mismo dominio y conceder los permisos de aplicación exigidos.
4. Iniciar la sincronización Entra y comparar usuarios, grupos y Shared Mailboxes con la lista exportada.
5. Solo después de aprobar el resultado, desinstalar el software local AD Sync Setup y revocar sus API Credentials tras una revisión documentada.

La desactivación de la fuente antigua es una migración controlada, no un restablecimiento para troubleshooting. Si se producen eliminaciones inesperadas, no se sigue sincronizando mediante activaciones y desactivaciones repetidas, sino que primero se analiza el informe de coincidencias.

Utilizar Microsoft Entra ID y AD en paralelo

Esta variante utiliza Entra ID para usuarios, grupos de usuarios y Shared Mailboxes modernas, mientras AD proporciona dispositivos y grupos de dispositivos.

1. Ejecutar por completo el AD Sync existente y validar el inventario inicial.
2. En AD Sync Utility, limitar la selección a Sync devices y Sync organizational units; en el futuro AD ya no proporcionará usuarios ni grupos de usuarios.
3. Desactivar temporalmente la fuente AD en Central mediante Turn off.
4. Añadir Microsoft Entra ID para el mismo dominio, sincronizar y validar usuarios, grupos y Shared Mailboxes.
5. Reactivar la fuente AD con Turn on, sincronizar manualmente y comprobar que se siguen actualizando los dispositivos y grupos sin volver a importar usuarios desde AD.

Ambas fuentes reciben propietarios, programaciones y magnitudes de aceptación propias. Un estado verde en ambos conectores no demuestra que sus ámbitos de objetos estén correctamente separados.

Efectos en usuarios, grupos, buzones y dispositivos

Cuando los usuarios coinciden, Entra ID actualiza el objeto existente de Central y se conserva la información de buzón asociada. Un usuario AD sin registro Entra correspondiente puede eliminarse de Central junto con su asignación de buzón. Los nuevos usuarios de Entra se crean como nuevos usuarios de Central con los datos de buzón disponibles.

Los grupos de usuarios coincidentes se actualizan. Los grupos AD sin equivalente en Entra permanecen visibles en Central, pero dejan de recibir cambios de AD. Los grupos nuevos de Entra se crean. Que esos grupos permanezcan no demuestra que la sincronización siga funcionando; por eso se comprueban por separado las asignaciones de políticas y las pertenencias.

Las Shared Mailboxes y Public Folders existentes que antes procedían de AD se conservan con el último estado de AD, pero ya no se actualizan. Esas Shared Mailboxes siguen apareciendo en Mailboxes, aunque después del cambio pueden no tener usuarios asignados. Las nuevas Shared Mailboxes de Entra pueden aparecer como objetos de usuario y en Mailboxes, también sin la asignación de Delegate conocida de AD. Por eso se vuelven a validar el acceso delegado y los resúmenes de cuarentena. Si la antigua sincronización AD continúa sin control después de la migración, los distintos tipos de objeto pueden eliminar Shared Mailboxes existentes.

En el modelo solo Entra, los dispositivos y grupos AD anteriores permanecen inicialmente en Central, pero dejan de actualizarse desde el directorio. En el modelo paralelo, AD sigue sincronizándolos. Entra ID no proporciona equipos, grupos de equipos ni Public Folders. Este efecto se documenta expresamente en la decisión de migración para no interpretar por error un inventario estancado como una sincronización actual.

Transferir endpoints existentes a un dominio AD nuevo

Si solo cambia el dominio AD mientras se mantienen el nombre del equipo y el SID, no es necesario reinstalar el agente de Sophos. Su machine_id permanece. Primero se cambia la configuración de AD Sync al dominio nuevo en Global Settings > Platform > Directory service, se validan las credenciales y se sincronizan usuarios, grupos, OU y dispositivos. Solo después se permite que los endpoints hagan check-in en Central.

Debido al nuevo FQDN, Central desasocia la relación AD anterior y busca el objeto de dispositivo adecuado en el dominio nuevo. Si lo encuentra, vuelve a vincular el mismo objeto Endpoint y, con la sincronización de OU activa, lo mueve al grupo correcto. En cambio, los inicios de sesión de usuario cambian, por ejemplo, de OLDDOMAIN\jsmith a NEWDOMAIN\jsmith y pueden generar duplicados.

La aceptación comprueba el dominio nuevo, el grupo OU, las políticas aplicadas y la asignación de usuarios. Solo después se eliminan los objetos obsoletos de dispositivo, usuario, grupo o directorio del dominio anterior.

Problemas habituales

El usuario aparece dos veces

Compare orígenes, dirección de correo, UPN y objetos creados manualmente. No elimine precipitadamente ninguno mientras tenga dispositivos o políticas asociados.

Falta un grupo nuevo

Compruebe filtros OU y de grupos, pertenencias anidadas, última sincronización correcta y atributos del directorio.

0000208D, NO_OBJECT o «The object does not exist»

Este error suele aparecer cuando un Custom Filter sigue apuntando a una OU que se ha eliminado de Active Directory. El mensaje no indica el nombre de la OU eliminada. Por eso, en Define Filters se comparan todos los filtros AD con la estructura actual del directorio y solo se eliminan las referencias a objetos que ya no existen. Después se ejecuta una nueva vista previa y se revisan las eliminaciones previstas.

0xFFFE o 0xFFFF en Preview and Sync

Si Active Directory contiene caracteres con los valores hexadecimales no válidos 0xFFFE o 0xFFFF, la ejecución manual puede detenerse en Preview and Sync. Primero se busca el atributo de origen afectado y se corrige en la fuente. Si esto no es posible a corto plazo, Sophos indica Sync on Schedule - automatic (within next 2-3 minutes) como solución temporal específica, ya que esa ejecución omite la vista previa. No es una corrección permanente: inmediatamente después se revisan en Central y en el log el alcance, el resultado y los objetos nuevos y eliminados.

endpoint_user_sessions.user_match_id al eliminar un login

Error syncing record: Error deleting login junto con una referencia de clave foránea a endpoint_user_sessions.user_match_id puede aparecer si AD eliminó o desactivó a un usuario, pero Central no puede borrar el login asociado debido a una sesión existente. El resto de la sincronización continúa y puede finalizar correctamente. Si la entrada se repite, se documentan el usuario, el login y la hora y se solicita a Sophos Support que lo depure en Central; purgar o reconstruir toda la sincronización sería desproporcionado.

La sincronización permanece desactualizada

Compruebe servicio Windows, cuenta de servicio, contraseña, DNS, proxy, reglas de firewall y estado de sincronización de Central. Incluya registros y marcas de tiempo en un ticket de soporte.

Desde AD Sync Client 5.x, el Audit Log ya no muestra la Client ID de las API Credentials como Modified by en las acciones de Directory Sync, sino el GUID del cliente AD Sync registrado en Sophos. Esto se aplica a acciones Create, Update y Delete. Por tanto, un GUID no indica automáticamente un atacante desconocido; se correlaciona con la instancia de sincronización, la programación y la hora del log.

Se solicitan repetidamente credenciales LDAP

NeedADCredsException junto con The LDAP server is unavailable no implica necesariamente una contraseña incorrecta. Se comprueban Domain Controller, formato DOMAIN\username, permisos de lectura y puerto. LDAPS usa normalmente TCP 636 y el Domain Controller debe presentar allí un certificado fiable. Un puerto escuchando no demuestra que TLS funcione.

Escalación a Sophos Support

Un caso reproducible incluye descripción, Tenant y licencia, periodo exacto, versión AD Sync, todos los logs, capturas relevantes y la IP pública del sistema al recopilar. Los casos Partner necesitan además la asignación correcta del cliente MSP. Remote Assistance solo se activa para ese caso y con aprobación interna.

Preguntas frecuentes