Microsoft Entra ID agosto de 2026: Vista previa de la sincronización de dispositivos de Cloud Sync, controles de anidamiento de grupos de seguridad, API de exclusión de SMS y más

La primera semana de agosto de 2026 trae un amplio conjunto de actualizaciones de Microsoft Entra ID que abarcan identidad híbrida, seguridad de grupos, migración de autenticación, Conditional Access y federación de identidades de carga de trabajo. La noticia destacada: Entra Cloud Sync finalmente admite la sincronización de dispositivos, eliminando uno de los últimos grandes obstáculos para las organizaciones que migran desde Connect Sync. Analicemos todo lo que los administradores de identidad necesitan saber.

Sincronización de dispositivos de Entra Cloud Sync (versión preliminar pública)

La noticia más importante de esta semana es la versión preliminar pública de la sincronización de dispositivos para Microsoft Entra Cloud Sync. Hasta ahora, las organizaciones que necesitaban sincronizar objetos de equipo de Active Directory con Entra ID para la unión híbrida dependían de Entra Connect Sync. Este era uno de los obstáculos más citados que impedían la migración a la arquitectura nativa de la nube de Cloud Sync.

Qué hace

La sincronización de dispositivos utiliza un trabajo dedicado AD2AADDeviceSync dentro de una configuración existente de Cloud Sync de AD a Entra. Tras la sincronización, los dispositivos pueden unirse de forma híbrida a Microsoft Entra, lo que habilita Conditional Access, el cumplimiento basado en dispositivos y los escenarios de SSO que dependen del estado de unión híbrida.

Requisitos previos

Agente de aprovisionamiento de Microsoft Entra versión 1.1.1107 o posterior
Una configuración de Cloud Sync existente de AD a Microsoft Entra ID
El identificador de inquilino de Entra y un dominio verificado (dominio federado en entornos federados; de lo contrario, *.onmicrosoft.com)
Acceso de Enterprise Admins para la configuración del punto de conexión de servicio (SCP) en cada bosque de AD
Rol de Hybrid Identity Administrator para configurar la sincronización de dispositivos

Cómo habilitarla

Mediante el Centro de administración de Entra:

Inicie sesión como Hybrid Identity Administrator
Vaya a Entra ID → Entra Connect → Cloud sync
Seleccione su configuración de AD a Microsoft Entra ID
Vaya a Propiedades → Conceptos básicos → Editar
Habilite la sincronización de dispositivos → Aplicar

Mediante Microsoft Graph API:

Cree un trabajo de sincronización con templateId establecido en AD2AADDeviceSync:

POST https://graph.microsoft.com/beta/servicePrincipals/{spId}/synchronization/jobs
Content-Type: application/json

{
  "templateId": "AD2AADDeviceSync"
}

Luego inicie el trabajo:

POST https://graph.microsoft.com/beta/servicePrincipals/{spId}/synchronization/jobs/{jobId}/start

También puede aprovisionar dispositivos individuales bajo demanda a través del Centro de administración o Graph API para realizar pruebas.

Atributos de dispositivo sincronizados

Entra Attribute	AD Attribute	Mapping Type
AccountEnabled	userAccountControl	Expression
DeviceId	objectGUID	Direct
DeviceOSType	operatingSystem	Expression
DeviceTrustType	None (always ServerAd)	Expression
DisplayName	displayName, dNSHostName	Expression
OnPremiseSecurityIdentifier	objectSid	Direct
RegisteredOwnerReference	mS-DS-CreatorSID	Once
SourceAnchor	objectGUID	Direct
UserCertificate	userCertificate	Direct

Por qué esto es importante

Microsoft ha sido claro: Cloud Sync es la dirección estratégica para la identidad híbrida. Las versiones de Connect Sync están en retiro progresivo y la versión 2.5.79.0 o posterior es obligatoria a partir del 30 de septiembre de 2026 para seguir sincronizando. Con la sincronización de dispositivos ahora en versión preliminar, el camino de migración finalmente está abierto para las organizaciones que antes no podían migrar debido a las dependencias de la sincronización de dispositivos.

Enfoque de migración: Implemente Cloud Sync en paralelo con Connect Sync, realice una prueba piloto de la sincronización de dispositivos en un subconjunto de OU, valide los flujos de unión híbrida y luego retire Connect Sync gradualmente.

Controles de anidamiento de grupos de seguridad (propiedad disableNesting)

Microsoft agregó discretamente una propiedad disableNesting a los grupos de seguridad en Entra ID, lo que brinda a los administradores una forma de evitar membresías de grupos anidadas en grupos críticos. La función está disponible ahora a través del punto de conexión v1.0 de Graph, aunque la interfaz del Centro de administración de Entra aún no la expone.

Cómo funciona

Cuando disableNesting se establece en true en un grupo de seguridad:

Los usuarios, los principales de servicio y los dispositivos aún pueden agregarse como miembros
Los intentos de agregar otro grupo como miembro se bloquean
El anidamiento se bloquea si cualquiera de los grupos —el grupo de destinoo el grupo miembro potencial— tiene disableNesting establecido en true
La propiedad solo puede establecerse al crear el grupo; no puede actualizarse después de la creación

Ejemplos de Graph API

Crear un nuevo grupo de seguridad con anidamiento deshabilitado:

$RequestBody = @{
    displayName = "Privileged Access Group"
    securityEnabled = $true
    mailEnabled = $false
    mailNickname = "PrivilegedAccess"
    disableNesting = $true
    description = "Security group with nesting disabled"
}
New-MgGroup -BodyParameter $RequestBody

Filtrar grupos con anidamiento deshabilitado:

Get-MgGroup -Filter "securityEnabled eq true and mailEnabled eq false and disableNesting eq true" -All

Leer la propiedad (debe solicitarse explícitamente mediante $select):

GET https://graph.microsoft.com/v1.0/groups/{id}?$select=id,displayName,disableNesting

Nuevo permiso

Microsoft creó un permiso granular Group-NestingSupport.ReadWrite.All específicamente para administrar esta propiedad, junto al permiso más amplio Group.ReadWrite.All.

Casos de uso

Grupos de acceso privilegiado — Evite la escalada oculta mediante cadenas de membresía anidadas
Recursos controlados por normativas o cumplimiento — Simplifique las revisiones de acceso con membresía plana
Grupos de acceso ejecutivo — Garantice una membresía explícita y auditable
Grupos sujetos a revisiones de acceso — Elimine la complejidad en la atestación

API temporal de exclusión para la migración de SMS/voz

El 1 de agosto, Microsoft publicó el procedimiento de exclusión (opt-out) de Graph API en versión beta para la habilitación automática de claves de acceso (passkeys) y el despliegue de la campaña de registro (Registration Campaign). Esto brinda a las organizaciones con sus propios planes de transición una ventana temporal para retrasar los cambios del 1 de septiembre.

Qué hace la exclusión

Establecer optOutSettings.passkeyDynamicMigration en true mediante la Graph API en versión beta excluye temporalmente a su inquilino de:

La habilitación automática de claves de acceso para usuarios de SMS/voz
El comportamiento predeterminado de la campaña de registro que impulsa el registro de claves de acceso

Qué no hace

No evita el retiro el 1 de febrero de 2027 de los SMS/voz proporcionados por Microsoft
No vuelve a habilitar los métodos de SMS/voz retirados
No deshabilita las claves de acceso ni los métodos resistentes a la suplantación de identidad (phishing)
No lo exime de sus propias políticas de Conditional Access

La ventana de exclusión va del 1 de septiembre de 2026 al 1 de febrero de 2027. No hay exclusión posible para el retiro de febrero.

Herramientas de soporte

Microsoft publicó el script de PowerShell entra-sms-voice-usage-analyzer en GitHub para inventariar a los usuarios que aún usan autenticación por SMS/voz. Ejecútelo antes de decidir si usar la exclusión:

# Requires Global Reader, Authentication Policy Administrator, or Security Reader role
# Available at: https://github.com/microsoft/entra-sms-voice-usage-analyzer

Recomendación

Use la exclusión solo si tiene un plan de transición estructurado. Microsoft claramente quiere que los inquilinos adopten las claves de acceso. Si opta por la exclusión, use la ventana extendida para implementar plataformas compatibles con claves de acceso, actualizar Conditional Access para preferir niveles de resistencia a la suplantación de identidad y llevar a cabo campañas de comunicación con los usuarios.

MC1223829: Aplicación mejorada de Conditional Access para exclusiones de recursos

Microsoft está cerrando una brecha en la aplicación de Conditional Access en la que las aplicaciones que solicitan solo ámbitos de referencia (baseline) con al menos una exclusión de recursos no se procesaban correctamente. El despliegue comenzó a principios de agosto y debería completarse a mediados de agosto de 2026.

Evaluación del impacto

La mayoría de los inquilinos no notarán ningún cambio. Sin embargo, si tiene aplicaciones que se ajustan al perfil —que solicitan ámbitos de referencia con al menos una exclusión—, es posible que encuentren la aplicación de Conditional Access por primera vez. Compruebe si MC1223829 apareció en el Centro de mensajes de su inquilino.

Acciones del administrador

Haga un inventario de las políticas de CA con exclusiones de recursos (especialmente “Todas las aplicaciones en la nube” con exclusiones específicas)
Use la herramienta What If para simular inicios de sesión en recursos excluidos
Prefiera políticas explícitas dirigidas a aplicaciones en lugar de “Todas las aplicaciones con exclusiones” cuando se necesite una aplicación diferente
Documente las políticas específicas de recursos para evitar omisiones encubiertas (shadow bypass)

Refuerzo de las credenciales federadas de GitHub y GitLab

Microsoft publicó nuevas guías sobre cómo reforzar las credenciales federadas utilizadas por GitHub Actions y GitLab CI para la federación de identidades de carga de trabajo de Entra ID. Esto es importante para cualquier organización que use la federación OIDC para habilitar implementaciones de Azure sin secretos desde canalizaciones de CI/CD.

Recomendaciones clave

Restrinja el ámbito de la federación: Limite las credenciales de identidad federada a repositorios y ramas específicos, no a organizaciones enteras. Una coincidencia de asunto amplia como repo:myorg:* es peligrosa; use repo:myorg/myapp:ref:refs/heads/main en su lugar.

Aplique el principio de mínimo privilegio: Conceda a las aplicaciones de CI federadas solo los permisos de Graph que necesitan (por ejemplo, Application.ReadWrite.OwnedBy en lugar de Application.ReadWrite.All).

Use Conditional Access para identidades de carga de trabajo: Cree políticas de CA que permitan cargas de trabajo federadas sin MFA interactivo, pero restrinjan la emisión a emisores y notificaciones (claims) conocidos.

Patrón de GitHub Actions

Configure un registro de aplicación de Entra con una credencial de identidad federada:

Emisor: https://token.actions.githubusercontent.com
Asunto: repo:{owner}/{repo}:ref:refs/heads/{branch}
Audiencia: api://AzureADTokenExchange

El flujo de trabajo de GitHub Actions solicita un token OIDC, lo intercambia con Entra ID por un token de acceso y lo usa para llamar a Microsoft Graph o Azure Resource Manager — sin necesidad de secretos almacenados.

Global Secure Access: rangos de IP de salida y coexistencia con DCA

Dos nuevas actualizaciones de documentación ayudan a las organizaciones que implementan Global Secure Access junto con sus herramientas de seguridad existentes.

Rangos de IP de salida

Microsoft ahora publica rangos de IP de salida (egress) dedicados para GSA. Deben:

Marcarse como ubicaciones de confianza/conocidas en Defender for Cloud Apps
Incorporarse a las listas de permitidos de firewalls y proxies
Usarse en ubicaciones con nombre de Conditional Access para políticas basadas en la red

Guía de coexistencia con DCA

La nueva documentación explica cómo GSA y Defender for Cloud Apps pueden coexistir sin doble proxy. Esto es fundamental para las organizaciones que usan ambas soluciones: sin una configuración adecuada, DCA puede tratar las IP de salida de GSA como tráfico externo, perdiendo visibilidad de la TI en la sombra (shadow IT) y eficacia del control de sesiones.

Acción del administrador: Importe los rangos de IP de salida de GSA en DCA como ubicaciones corporativas y luego verifique que las políticas integradas de CA + DCA incluyan correctamente el tráfico de GSA.

Aprovisionamiento SCIM: autenticación sin secretos con federación de identidades de carga de trabajo

La documentación de aprovisionamiento SCIM se actualizó para incluir autenticación sin secretos mediante federación de identidades de carga de trabajo. Esto se alinea con el anuncio de abril de 2026 sobre el traslado de las aplicaciones de aprovisionamiento SCIM a métodos de autenticación modernos.

Qué cambió

Los clientes SCIM ahora pueden autenticarse en Entra ID mediante credenciales federadas en lugar de secretos de cliente de larga duración. El protocolo SCIM en sí no cambia — lo que cambia es cómo se autentica el motor de aprovisionamiento:

Registre una aplicación de Entra con una credencial de identidad federada (por ejemplo, OIDC de GitHub)
La carga de trabajo SCIM obtiene un token OIDC del IdP externo
Lo intercambia por un token de acceso de Entra mediante el intercambio de tokens
El aprovisionamiento SCIM continúa con tokens de corta duración y sin secretos

Esto elimina un riesgo significativo: las integraciones SCIM suelen ejecutarse como principales de servicio con secretos de cliente que nunca se rotan.

Nueva serie sobre arquitectura de estates de inquilinos

Microsoft publicó una serie de arquitectura de estates de inquilinos en siete partes que cubre:

Inquilinos principales — La autoridad de identidad central
Inquilinos de producción en colaboración — Escenarios de producción multiinquilino
Inquilinos aislados para sistemas críticos — Cuándo separarlos
Aislamiento de socios comerciales — Patrones de B2B e identidades externas
Inquilinos de no producción — Estrategias de desarrollo/pruebas/ensayo (staging)
Identidad híbrida — Conexión de AD local con Entra ID

Es lectura esencial para cualquier organización con topologías de inquilinos complejas.

MC1435782: Retiro de las propiedades personalizadas de posicionamiento CSS

Una notificación formal del Centro de mensajes (MC1435782) confirma el cronograma de retiro de las propiedades personalizadas de posicionamiento CSS en la personalización de marca de la empresa:

21 de julio de 2026: Los inquilinos que aún no usan propiedades de posicionamiento ya no podrán configurarlas
26 de octubre de 2026: Las propiedades de posicionamiento se retiran a nivel mundial
Más adelante en 2027: Se planea el retiro completo del CSS personalizado

Propiedades afectadas: position (top/right/bottom/left/z-index), margin, transform, opacity, overflow, filter, pointer-events, clip-path, mix-blend-mode, translate

Revise su configuración de personalización de marca mediante Graph Explorer y elimine las propiedades afectadas antes de la fecha límite de octubre.

Resumen de acciones

Change	Action Required	Timeline
Cloud Sync device sync	Evaluate for Connect Sync migration	Preview now
Security group disableNesting	Apply to privileged groups	Available now
SMS/voice opt-out API	Set if you have a transition plan	Before Sept 1, 2026
MC1223829 CA enforcement	Check affected apps	Mid-August 2026
GitHub/GitLab hardening	Audit and restrict federation scope	Immediate
GSA egress IPs	Import into DCA and firewalls	Before GSA deployment
SCIM workload identity	Migrate from static secrets	Per integration
CSS positioning retirement	Remove affected properties	Before Oct 26, 2026

Qué significa esto para su organización

Agosto de 2026 continúa el impulso implacable de Microsoft hacia la identidad nativa de la nube, la autenticación resistente a la suplantación de identidad y la identidad de carga de trabajo sin secretos. La versión preliminar de la sincronización de dispositivos de Cloud Sync es el titular para los equipos de identidad híbrida: finalmente elimina la objeción de “no podemos migrar por los dispositivos”. Los controles de anidamiento de grupos de seguridad y las guías de refuerzo de la federación de identidades de carga de trabajo demuestran el compromiso de Microsoft de dar a los administradores las herramientas para aplicar el mínimo privilegio tanto en identidades humanas como no humanas.

Si todavía usa Connect Sync, ahora es el momento de empezar a planificar seriamente su migración a Cloud Sync. Y si aún no ha comenzado el despliegue de claves de acceso, la API de exclusión temporal le da una ventana — pero úsela con prudencia, porque febrero de 2027 es una fecha límite inamovible sin excepciones.

Siga a @kkaminsk en X para recibir actualizaciones diarias de Microsoft Entra ID e información sobre seguridad de identidad.