Entra ID Novedades: Linux Broker 2.0.2, aprovisionamiento de AD con Cloud Sync, actualización automática de GSA

La última semana de agosto de 2026 de Microsoft Entra ID trajo un lote de actualizaciones que quizás no tengan el dramatismo de una vulnerabilidad con CVSS 10.0, pero que importan enormemente para las operaciones de identidad del día a día. El tema común: Microsoft continúa estrechando la integración entre Entra ID y los sistemas operativos, los directorios locales y los portales de autoservicio que los usuarios finales utilizan realmente.

Esta semana destacan cinco cambios para los administradores de TI: desde un cambio de arquitectura en el broker de Linux que exige la reinscripción de los dispositivos, hasta una versión preliminar de Cloud Sync que por fin permite empujar usuarios de la nube de vuelta a AD local, pasando por un mecanismo de actualización automática de Global Secure Access que elimina el empaquetado manual del cliente.

Esto es lo que cambió, por qué importa y qué hacer al respecto.

1. Broker de SSO para Linux 2.0.2: Entra Join sustituye al registro de dispositivos

Estado: GA actual (versión 3.0.x en el canal estable) Acción requerida: Sí: los dispositivos existentes deben volver a unirse

Microsoft Single Sign-On para Linux dio un paso arquitectónico significativo con la versión 2.0.2, pasando del registro de dispositivos a la unión de dispositivos (join) para establecer la confianza con Entra ID. Esto no es solo terminología: cambia el alcance de la relación de confianza y lo que el dispositivo puede hacer.

Qué cambió

Las versiones anteriores de Microsoft Identity Broker para Linux usaban el registro de dispositivos, que creaba una confianza limitada a un perfil de usuario individual. La versión 2.0.2 y posteriores usa Entra join, que crea confianza con todo el dispositivo: el mismo modelo que usan Windows y macOS.

Esto importa por dos razones:

1. Preparación para SSO de plataforma: Entra join es un requisito previo para el futuro soporte de SSO de plataforma en Linux. El registro era un callejón sin salida; el join es la base de lo que viene después.
2. Alcance de seguridad: La confianza a nivel de dispositivo significa que las directivas de acceso condicional que evalúan el cumplimiento del dispositivo, los filtros de dispositivo y los controles basados en dispositivos se aplican de forma más coherente en todas las plataformas.

Qué deben hacer los administradores

La actualización no es automática para los dispositivos existentes. Este es el proceso:

1. Habilite la opción correcta: En el centro de administración de Entra, vaya a Dispositivos > Configuración de dispositivos. Asegúrese de que “Los usuarios pueden unir dispositivos a Microsoft Entra ID” esté habilitada para sus usuarios objetivo. La opción anterior “Los usuarios pueden registrar sus dispositivos en Microsoft Entra” ya no es suficiente para los dispositivos Linux con el broker 2.0.2+.

2. Limpie el estado existente del broker: En cada dispositivo Linux afectado, ejecute:

   sudo dsreg --cleanup
   

   Esto elimina todos los datos de registro locales y el material de claves.

3. Reinstale el broker: Actualice el paquete:

   # Ubuntu
   sudo apt update && sudo apt upgrade microsoft-identity-broker
   # RHEL
   sudo dnf update microsoft-identity-broker
   

4. Vuelva a unirse y reinscribirse: Los usuarios deben iniciar sesión de nuevo para establecer la nueva confianza de Entra join y reinscribirse en Intune.

Distribuciones compatibles

*El soporte de Ubuntu 22.04 LTS finaliza en agosto de 2026: identifique los dispositivos afectados en Intune filtrando Todos los dispositivos > Linux y añadiendo la columna de versión del sistema operativo.

Por qué importa

Los escritorios Linux en entornos empresariales suelen ser los últimos en lograr la paridad de identidad. Este cambio acerca Linux a Windows y macOS en cuanto a cómo Entra ID confía en el dispositivo, pero requiere una intervención activa. Las organizaciones con flotas Linux deberían planificar el proceso de re-join ahora, en lugar de esperar a fallos de autenticación después de una actualización automática del broker.

2. Aprovisionamiento de Cloud Sync a AD local: el aprovisionamiento de usuarios entra en versión preliminar

Estado: Aprovisionamiento de grupos GA; aprovisionamiento de usuarios en versión preliminar pública Acción requerida: Evaluar para escenarios de identidad de nube a local

Microsoft Entra Cloud Sync ha estado ampliando sus capacidades durante todo 2026: sincronización de dispositivos, aplicación de grupos de AD y ahora la dirección inversa: aprovisionar usuarios desde Entra ID hacia Active Directory Domain Services local.

Qué está disponible

Cómo funciona

El aprovisionamiento de Entra a AD de Cloud Sync usa el mismo agente de aprovisionamiento ligero y el mismo servicio de orquestación en la nube que la sincronización de AD a Entra, pero en sentido inverso. El flujo de configuración en el centro de administración de Entra (Entra ID > Entra Connect > Cloud Sync) le guía a través de cinco secciones:

1. Filtros de ámbito — elija todos los grupos de seguridad, grupos seleccionados o usuarios específicos
2. Asignación de atributos — asigne atributos de Entra a atributos de AD DS
3. Prueba — valide con aprovisionamiento bajo demanda para un solo usuario o grupo
4. Propiedades predeterminadas — revise y ajuste la configuración predeterminada
5. Habilitar — active la configuración y comience a sincronizar

Requisitos previos

• Rol Administrador de identidad híbrida como mínimo
• Agente de aprovisionamiento de Entra instalado en el entorno local
• Esquema de AD DS con el atributo msDS-ExternalDirectoryObjectId (Windows Server 2016+)
• Para los miembros de grupos: los usuarios deben tener cuentas de AD con onPremisesObjectIdentifier coincidente

Limitaciones que debe conocer

• Los miembros de grupos aprovisionados a AD deben tener cuentas de AD (incluidos los usuarios elegibles administrados en la nube)
• Los usuarios sincronizados aún requieren que su onPremisesObjectIdentifier coincida con su objectGUID en el AD de destino
• Las pruebas de grupos bajo demanda se limitan a cinco miembros
• Los valores nulos no se envían de forma predeterminada (se requiere participación explícita para la limpieza de atributos)

Por qué importa

Este es un paso significativo para las organizaciones que avanzan hacia la gestión de identidades cloud-first. Antes, si quería administrar usuarios en Entra ID y que aparecieran en AD local, sus opciones eran limitadas. Con la capacidad bidireccional de Cloud Sync, Entra ID ahora puede servir como fuente de identidad autoritativa y, al mismo tiempo, poblar AD para aplicaciones heredadas, servidores de archivos locales o sistemas basados en Kerberos que requieren cuentas de AD.

El tutorial para aprovisionar grupos a AD DS y la guía de configuración para el aprovisionamiento de Entra a AD ofrecen instrucciones paso a paso.

3. Actualización automática de Global Secure Access mediante Windows Update

Estado: A partir de noviembre de 2026 Acción requerida: Actualice las reglas de detección; decida sobre la exclusión

Si gestiona implementaciones del cliente de Global Secure Access (GSA) en endpoints Windows, noviembre de 2026 trae un cambio bienvenido: el cliente GSA se actualizará automáticamente mediante Windows Update.

Qué cambió

La versión 2.32.294 del cliente GSA es la versión actual para Windows (x64 y ARM). Principales novedades:

• Función “Prefer local network” para un enrutamiento optimizado
• Creación de túneles más rápida
• Correcciones de errores y mejoras

Pero la noticia más importante es el cambio en el mecanismo de entrega. A partir de noviembre de 2026, los clientes Windows elegibles recibirán automáticamente las actualizaciones de GSA mediante Windows Update, lo que elimina la necesidad de que los administradores descarguen, empaqueten e implementen manualmente cada nueva versión.

Versiones mínimas para la actualización automática

Qué deben hacer los administradores

1. Actualice las reglas de detección: Si usa Intune u otras herramientas de gestión de endpoints, actualice las reglas de detección para comprobar versiones mayores o iguales a las versiones mínimas indicadas. Así se garantiza que los clientes actualizados automáticamente se reconozcan como conformes.

2. Decida sobre la exclusión: Si su organización necesita controlar manualmente las actualizaciones del cliente GSA, use el parámetro de exclusión durante la instalación:

   GlobalSecureAccessInstaller.exe /quiet /norestart EnableWindowsUpdates=0
   

3. Tenga en cuenta la exclusión del conector: Esta actualización automática se aplica solo al cliente GSA. Las instalaciones del Conector de Entra Private Network no se actualizan automáticamente: los administradores deben seguir descargando y actualizando los conectores manualmente desde el centro de administración de Entra.

4. La gestión de identidad de autoservicio se traslada a cloud.microsoft

Estado: Despliegue mundial a finales de noviembre de 2026 Acción requerida: Actualice las directivas de red

El dominio de gestión de identidad de autoservicio de Microsoft Entra se está consolidando bajo el espacio de nombres cloud.microsoft. La migración de myaccount.microsoft.com a myaccount.cloud.microsoft está prevista para un despliegue mundial a finales de noviembre de 2026.

Qué deben hacer los administradores

• Permita *.cloud.microsoft en las directivas de red — los firewalls, proxies y directivas de red de acceso condicional deben actualizarse antes del despliegue de noviembre
• Los usuarios no necesitan hacer nada — está prevista una redirección automática desde la URL antigua
• Sin cambios de autenticación — el comportamiento de inicio de sesión sigue siendo el mismo

Esto forma parte de la consolidación más amplia de servicios de Microsoft bajo el dominio cloud.microsoft, tras movimientos similares de otros servicios de Microsoft 365.

5. Generación mejorada de sAMAccountName para usuarios híbridos

Estado: Disponible (configuración a nivel de dominio) Acción requerida: Evalúe si su organización necesita un control explícito del sAMAccountName

La nueva documentación aclara cómo los administradores pueden controlar la generación de sAMAccountName para usuarios híbridos obteniéndolo del atributo onPremisesSamAccountName.

Cómo funciona

• Comportamiento predeterminado (actual): el sAMAccountName se genera a partir de mailNickname para todos los usuarios híbridos
• Comportamiento mejorado (participación explícita): el sAMAccountName se obtiene de onPremisesSamAccountName, lo que da a los administradores un control explícito
• Configuración a nivel de dominio: se habilita por dominio, no por usuario
• Impacto de la migración: al habilitarse, los usuarios híbridos existentes se actualizan durante el siguiente ciclo de sincronización
• Usuarios solo de nube: continúan usando la generación basada en mailNickname (sin cambios)

Por qué importa

Las organizaciones con convenciones de nomenclatura específicas o aplicaciones heredadas que dependen de formatos concretos de sAMAccountName ahora disponen de un mecanismo para garantizar la coherencia al gestionar identidades híbridas a través de Entra ID. Antes, la generación automática podía producir valores de sAMAccountName que no coincidían con las expectativas locales.

Actualizaciones adicionales de documentación

Esta semana se observaron varias actualizaciones menores de documentación:

• Aclarada la guía de inicio de sesión de Arc: Habilitar el inicio de sesión de Arc une una máquina a Entra ID, algo pensado para máquinas que NO estén planificadas para unirse a otro dominio (AD local o Entra Domain Services). Confirme los planes de unión a dominio antes de habilitarlo.
• Revisados los ID de aplicación de las directivas de consentimiento: Se actualizaron los ID de aplicación de Apple Mail, Spark Email, eM Client, Android-Samsung, Android-Mail y Thunderbird. Los administradores que gestionan directivas de consentimiento granular deben actualizar sus configuraciones.
• Herramienta What If de acceso condicional: Se actualizó el UserId de ejemplo en los ejemplos de documentación. Sin cambios en el comportamiento del producto.

Fechas clave a tener en cuenta

• 1 de septiembre de 2026: Las claves de acceso (passkeys) pasan a ser la opción predeterminada en Entra ID; comienza la habilitación automática para usuarios de SMS/voz
• 5 de octubre de 2026: Comienza la campaña de registro de SSPR
• 26 de octubre de 2026: Las propiedades de posicionamiento CSS personalizadas se retiran a nivel mundial en la personalización de Entra ID
• 3 de noviembre de 2026: El operador de reglas MemberOf se retira en grupos dinámicos, unidades administrativas y gestión de derechos
• 9 de noviembre de 2026: Aplicación de SSPR: solo se aceptan métodos registrados explícitamente
• Noviembre de 2026: Comienza la actualización automática del cliente GSA mediante Windows Update
• Finales de noviembre de 2026: Despliegue mundial de myaccount.cloud.microsoft
• 1 de febrero de 2027: La autenticación por SMS/voz alojada por Microsoft se retira por completo (sin opción de exclusión)

Siga a Kevin en X en https://x.com/kkaminsk para obtener actualizaciones y análisis diarios sobre Microsoft Entra.