Sincronización Identidad Híbrida Entra Cloud-Only Privilegiado Huérfano: El Punto Ciego de la Auditoría Híbrida

Sincronización Identidad Híbrida Entra Cloud-Only Privilegiado Huérfano Explicados

Sincronización identidad híbrida Entra cloud-only privilegiado huérfano: los dos puntos ciegos que cubre este artículo son las cuentas cloud-only que ostentan un rol privilegiado de Microsoft Entra y que nunca entran en el perímetro de gobernanza Tier 0 on-premises, y los usuarios sincronizados huérfanos que Entra Connect deja atrás después de que su cuenta on-premises es eliminada. Ambos se cuelan entre las grietas del pipeline de sincronización que mantiene la mayoría de los objetos fluyendo limpiamente entre el Active Directory on-premises y Microsoft Entra ID, y ambos son puntos ciegos de auditoría propios de los entornos híbridos, no de uno u otro lado por separado.

El primero es la cuenta cloud-only privilegiada: un usuario creado directamente en Entra ID, nunca sincronizado desde el AD on-premises, y que ostenta un rol de Microsoft Entra activo o elegible para PIM. El segundo es el usuario sincronizado huérfano: un objeto que Entra Connect sincronizó en su momento desde AD, cuya cuenta origen on-premises ha sido eliminada o excluida del alcance de sincronización, pero cuyo objeto Entra ID nunca se elimina limpiamente. Ninguno de los dos aparece en las auditorías que la mayoría de las organizaciones híbridas ya ejecutan, porque esas auditorías están construidas alrededor de un solo lado del límite de sincronización — una revisión de tiering on-premises escanea el AD, e incluso una auditoría de seguridad de Entra ID amplia suele asumir que cada identidad todavía tiene una contraparte on-premises activa.

Cuentas cloud-only privilegiadas: una brecha deliberada que las auditorías on-premises no ven

Mantener las cuentas Tier 0 fuera de la sincronización de directorio no es un error — es una recomendación documentada por Microsoft. La propia guía de Microsoft afirma claramente que « Las cuentas de administrador Tier 0 se usan solo para cuentas AD on-premises. Este tipo de cuentas normalmente no se sincronizan con Microsoft Entra ID en la nube », y por separado que « Las cuentas de Administrador global (y otros grupos privilegiados) deben ser cuentas cloud-only sin vínculos con el Active Directory on-premises » (Secure access practices for administrators in Microsoft Entra ID).

El punto ciego no es la arquitectura — es la brecha de gobernanza que se abre a su alrededor. Una revisión de tiering on-premises (ya sea una auditoría manual frente a un modelo como el modelo de tiering de Active Directory, o una herramienta como PingCastle escaneando el AD) no tiene ninguna visibilidad sobre las asignaciones de roles de Entra ID, sencillamente porque una cuenta cloud-only nunca existió on-premises. Si el programa de gobernanza del lado cloud no se ha construido con el mismo rigor — asignación elegible PIM en lugar de acceso permanente, Conditional Access que exija MFA y un dispositivo conforme en la activación, y revisiones de acceso periódicas — un Administrador global cloud-only puede quedar con una asignación activa permanente, sin aplicación de MFA y sin registro de activación, invisible para ambas mitades del programa de auditoría a la vez.

Esa brecha lleva asociada una superficie de ataque concreta. SyncJacking es una técnica de toma de control mediante hard-match, confirmada por el Microsoft Security Response Center como un problema de escalada de privilegios de severidad Importante, en la que un atacante que controla atributos de un objeto AD on-premises puede forzar a Entra Connect a hacer hard-match de ese objeto con un usuario cloud-managed existente — incluido uno privilegiado — y tomar el control de su source of authority. La técnica « no deja rastro en los registros de AD on-premises y solo un rastro mínimo en los registros de Entra ID » (Semperis: Syncjacking Could Enable Entra ID Account Takeover).

Microsoft ya ha publicado una mitigación a nivel de plataforma. Según la propia documentación de solución de problemas de Microsoft: « A partir del 1 de julio de 2026, Microsoft Entra ID aplica automáticamente el endurecimiento de seguridad del hard match », bloqueando un hard match siempre que la cuenta cloud objetivo ya tenga establecido onPremisesObjectIdentifier, ostente un rol de Entra privilegiado activo, o sea elegible para uno (Microsoft Entra Connect: Troubleshoot errors during synchronization — InvalidHardMatch). Ese endurecimiento protege la vía de toma de control — no hace nada por cerrar la brecha de gobernanza que permitió que existiera un admin cloud-only sin supervisar, que es precisamente lo que abordan las secciones de detección y remediación de este artículo. También vale la pena combinar esta revisión del lado del acceso con las cuentas de acceso de emergencia que cada tenant mantiene para un verdadero escenario break-glass — ver higiene de cuentas break-glass de Entra ID para saber cómo deben (y no deben) delimitarse específicamente.

Usuarios sincronizados huérfanos: qué ocurre cuando Entra Connect no elimina una cuenta on-premises eliminada

En el otro lado del límite, eliminar un usuario en el AD on-premises no garantiza que su gemelo en Entra ID desaparezca. Dos mecanismos documentados dejan objetos sincronizados atrás:

Protección contra eliminación accidental. Microsoft Entra Connect viene con la protección contra eliminación activada por defecto, con un tope de 500 eliminaciones de objetos por ciclo de exportación. Si una limpieza masiva on-premises, un movimiento de OU, o un filtro de sincronización roto provoca que se eliminen más del umbral en una sola ejecución, la exportación simplemente se detiene — el Synchronization Service Manager reporta stopped-deletion-threshold-exceeded en el paso Export, y cada una de esas eliminaciones queda sin aplicar en Entra ID hasta que un administrador la revisa y reanuda el job (Microsoft Entra Connect Sync: Prevent accidental deletes). En la práctica, esto significa que una sola superación del umbral pasada por alto puede dejar decenas de cuentas on-premises eliminadas todavía completamente activas y con apariencia de sincronizadas en la nube.

Exclusión de alcance sin conversión. Cuando un objeto se saca del alcance de sincronización (un cambio de filtro de OU/grupo, por ejemplo) en lugar de eliminarse directamente, Entra Connect hace un soft-delete del objeto Entra ID y cambia DirSyncEnabled a False — pero, según la propia documentación de Microsoft, « este proceso, sin embargo, no convierte el objeto en cloud managed, sigue considerándose un objeto sincronizado desde el Active Directory on-premises », y sigue siendo elegible para un nuevo hard-match más adelante (Microsoft Entra Connect: Troubleshoot errors during synchronization). Un usuario en este estado no está ni limpiamente eliminado ni es genuinamente cloud-native — es un objeto a medio migrar para el que la mayoría de las revisiones de acceso no tiene una categoría clara, en un espíritu similar a las cuentas privilegiadas obsoletas que las auditorías on-premises ya señalan, salvo que esta es invisible desde el lado AD porque el objeto origen ya ha desaparecido.

Detección: encontrar cuentas cloud-only privilegiadas y cuentas sincronizadas huérfanas

La propiedad onPremisesSyncEnabled del recurso user de Microsoft Graph es el ancla de ambas comprobaciones: devuelve true para un objeto activamente sincronizado, false para un objeto que estuvo sincronizado pero ya no lo está, y null para un objeto que nunca se ha sincronizado — es decir, genuinamente cloud-native.

Consultar Microsoft Graph para candidatos a huérfano

Para extraer directamente la lista de candidatos huérfanos / SOA revertida, Microsoft documenta esta consulta de Graph:

GET https://graph.microsoft.com/v1.0/users?$count=true&$filter=OnPremisesSyncEnabled ne true and OnPremisesImmutableId ne null

(Fuente: How to audit and monitor User Source of Authority (SOA) in Microsoft Entra ID.) Los filtros avanzados sobre onPremisesSyncEnabled pueden requerir la cabecera ConsistencyLevel: eventual y $count=true para devolver resultados de forma fiable.

Cruzar roles privilegiados con el estado de sincronización

Para el lado cloud-only privilegiado, cruce las asignaciones de roles (elegibles PIM y activas) con el estado de sincronización:

# Usuarios con un rol Entra activo o elegible que nunca se sincronizaron desde on-premises
Get-MgUser -Filter "onPremisesSyncEnabled eq null" -ConsistencyLevel eventual -CountVariable c -All |
    Where-Object { (Get-MgUserMemberOf -UserId $_.Id) -match "RoleAssignable" }

Remediación

Cerrar la brecha cloud-only privilegiada

1. Extender la gobernanza Tier 0 a las cuentas cloud-only privilegiadas. Cada cuenta cloud-only con un rol Entra activo o elegible debería tener: asignación elegible PIM (no permanente), una política de Conditional Access que exija MFA y un dispositivo conforme/administrado en la activación (muchos tenants tienen brechas aquí — ver brechas de cobertura de política base de Conditional Access), y su inclusión en la misma revisión de acceso periódica que el Tier 0 on-premises — ver higiene de grupos anidados y asignables a roles para el equivalente del lado de los grupos de esta misma brecha.
2. Mantener la excepción reducida. Las únicas cuentas que deberían quedar completamente fuera del escrutinio de PIM y Conditional Access son las verdaderas cuentas de acceso de emergencia break-glass — dos, cloud-only, monitorizadas, según la guía de Microsoft (ver higiene de cuentas break-glass). Todo lo demás etiquetado como «cloud-only porque el Tier 0 no debe sincronizarse» sigue necesitando un propietario y una cadencia de revisión.

Limpiar los usuarios sincronizados huérfanos

3. Ajustar la protección contra eliminación accidental en lugar de elevarla a ciegas. Confirme que el umbral de eliminación de exportación (Enable-ADSyncExportDeletionThreshold) está configurado deliberadamente para su entorno, dirija la notificación de detención a un buzón monitorizado, y trate cada evento stopped-deletion-threshold-exceeded como un disparador de investigación antes de reanudar la exportación — reanudar sin revisar es lo que convierte un cambio de configuración en decenas de huérfanos activos.
4. Reconciliar el estado de sincronización obsoleto de forma programada. Consulte onPremisesSyncEnabled = false con un onPremisesLastSyncDateTime antiguo, confirme contra el AD on-premises si el objeto origen todavía existe, y restaure el mapeo o desaprovisione formalmente el objeto cloud — no lo deje en ese estado a medio migrar.
5. Conectar las eliminaciones a un proceso de baja gobernado. Los Lifecycle Workflows de Microsoft Entra ID Governance pueden disparar tareas de deshabilitar/quitar acceso/programar eliminación a partir de una señal autorizada (feed de RR. HH. o atributo AD) en lugar de depender únicamente de la exportación de sincronización para propagar una baja — esto captura el caso en que la exportación falla silenciosamente.

Prepararse para el endurecimiento del hard-match

6. Planificar el endurecimiento del hard-match ahora, no el 1 de julio de 2026. Cualquier proceso que dependa de volver a emparejar una cuenta cloud privilegiada o elegible PIM con un objeto on-premises (recuperación de bosque, runbooks de migración de tenant) quedará bloqueado por defecto una vez que el endurecimiento de Microsoft entre en vigor. Pruebe sus runbooks de recuperación con la solución alternativa documentada — retirar temporalmente el rol o la elegibilidad, completar el hard-match, y luego restaurarlo — antes de necesitarlo bajo la presión de un incidente.

Cómo lo detecta EtcSec

Las comprobaciones de Entra ID de EtcSec señalan directamente ambos lados de esta brecha: HYBRID_CLOUD_ONLY_PRIVILEGED saca a la luz usuarios cloud-only con un rol privilegiado, y HYBRID_ORPHANED_CLOUD_USER saca a la luz objetos cuyo estado de sincronización indica un probable huérfano. Estas comprobaciones se combinan con UNRESOLVED_PRIVILEGED_MEMBERS (asignaciones de roles privilegiados que referencian a un principal que ya no se resuelve), PA_ADMIN_STALE_ACCOUNT (cuentas administrativas sin actividad reciente), y PA_GLOBAL_ADMIN_NOT_MFA (Administradores globales sin MFA aplicado), de modo que una cuenta cloud-only privilegiada no solo se detecta, sino que se verifica con el mismo listón de higiene de acceso que cualquier otra identidad Tier 0.