La semana del 15 al 18 de agosto de 2026 trae un conjunto de actualizaciones de documentación centradas en Microsoft Entra ID. Aunque no hay lanzamientos importantes de productos esta semana, dos actualizaciones destacan por su importancia operativa para los administradores de identidad: una nueva experiencia de migración guiada para las políticas de filtrado web de Global Secure Access de V1 a V2, y requisitos más estrictos para las credenciales de identidad federada flexibles de GitHub que ahora exigen claims inmutables de repositorio. Cuatro actualizaciones de documentación adicionales completan la semana, que cubren las limitaciones de las políticas de fuerza de autenticación con cuentas MSA, el comportamiento de corrección del bloqueo de dispositivos en ID Protection, la sincronización de sAMAccountName para Domain Services y los identificadores de planes de servicio de ESU de Windows 10 en la referencia de licencias. Aquí está el desglose completo.
1. Experiencia de migración guiada para el filtrado web de GSA de V1 a V2
Microsoft publicó un nuevo artículo de procedimientos que documenta la experiencia de migración guiada para transicionar las políticas de filtrado de contenido web (V1) de Global Secure Access al modelo de objetos de filtrado web (V2). Esta es la contraparte operativa del artículo conceptual de V2 publicado el 12 de agosto, y brinda a los administradores una ruta concreta, paso a paso, para mover sus políticas existentes sin reconstruirlas desde cero.
Qué cambió entre V1 y V2
El modelo V2 introduce cambios estructurales en la forma en que funciona el filtrado web en Global Secure Access:
- Una sola política por perfil de seguridad: V1 permitía múltiples políticas de filtrado de contenido web vinculadas a un solo perfil de seguridad. V2 consolida esto en una sola política que contiene múltiples reglas, cada una con su propia acción.
- Acción predeterminada: las políticas V1 no tenían una acción predeterminada: solo actuaban cuando una regla coincidía. Las políticas V2 siempre producen un resultado porque definen una acción predeterminada que se aplica cuando ninguna regla coincide.
- Destinos FQDN: el tipo de destino FQDN independiente se elimina en V2. Los FQDN ahora se expresan como destinos de URL, siguiendo la lógica de coincidencia de URL.
- Nombre de la característica: “Web Content Filtering” se convierte en “Web Filtering” en V2.
Cómo funciona la migración guiada
La experiencia de migración aparece como un banner en la página Security Profiles del centro de administración de Entra cuando su inquilino es elegible. Los perfiles de seguridad se clasifican en tres grupos:
- Perfiles elegibles: tienen al menos una política V1 vinculada y ninguna política V2 existente. Estos se pueden migrar automáticamente.
- Perfiles no elegibles: ya contienen una política V2 junto con políticas V1. Estos requieren manejo manual: o bien elimina la política V2 primero y luego migra, o bien maneja la migración manualmente.
- Sin migración necesaria: perfiles sin políticas V1 vinculadas. No se requiere ninguna acción.
Cuando inicia la migración, esta procesa todos los perfiles elegibles en una sola operación. Para cada perfil elegible, la migración:
- Crea una nueva política de filtrado web V2 habilitada
- Agrega cada política V1 vinculada como una regla bajo la política V2, preservando sus destinos, acción y prioridad
- Vincula la nueva política V2 al perfil de seguridad y elimina los vínculos de las políticas V1, lo que garantiza que no haya brechas de aplicación durante la transición
La acción de migración se deshabilita después de ejecutarse una vez para evitar migraciones duplicadas.
Advertencias importantes
- El comportamiento de evaluación difiere entre perfiles: debido a que V1 y V2 evalúan las políticas de manera diferente, el resultado combinado en múltiples perfiles de seguridad podría cambiar después de la migración. Revise su estructura de políticas antes de migrar.
- Las referencias de Conditional Access siguen siendo válidas: los perfiles de seguridad se referencian por GUID en los controles de sesión de Conditional Access, y estas referencias funcionan sin problemas en la transición de V1 a V2.
- Las políticas V1 aún se pueden editar: después de la migración, las políticas V1 existentes se pueden editar o eliminar, pero no se pueden crear nuevas políticas V1 una vez que existan políticas V2 en un perfil. Para volver a la creación de políticas V1, elimine todas las políticas V2 del perfil.
- Requisitos previos: se requiere el rol de Global Secure Access Administrator.
Esta guía de migración es lectura esencial para cualquier organización que use el filtrado de contenido web de GSA. Incluso si aún no está listo para migrar, comprender el modelo V2 y sus diferencias con V1 le ayudará a planificar su estrategia de transición.
2. Las credenciales de identidad federada flexibles de GitHub ahora requieren claims inmutables de repositorio
Microsoft actualizó la documentación en vista previa para las credenciales de identidad federada flexibles (FIC) para exigir que las configuraciones de GitHub coincidan con el claim sub más al menos un claim inmutable: repository_id o repository_owner_id. Este endurecimiento cierra una brecha de seguridad en la que la confianza federada podía estar vinculada a nombres mutables de repositorio y propietario en lugar de identificadores permanentes.
Por qué es importante
Los nombres de repositorio y propietario de GitHub pueden reutilizarse. Si un repositorio se renombra o se elimina una cuenta, otro repositorio o cuenta puede tomar el mismo nombre. Las credenciales de identidad federada que se basan únicamente en identificadores de sujeto basados en nombres (repo:owner/repo:ref:refs/heads/main) siguen siendo vulnerables a este escenario de reutilización.
Los identificadores inmutables — repository_id y repository_owner_id — son ID numéricos permanentes asignados por GitHub que nunca cambian y nunca se reutilizan, incluso si los nombres cambian. Al exigirlos en las configuraciones de FIC flexibles, Microsoft garantiza que la confianza federada permanezca vinculada al repositorio original independientemente de los cambios de nombre.
Cómo se ve la configuración
Una expresión FIC flexible de GitHub ahora se ve así:
claims['sub'] matches 'repo:contoso/contoso-repo:ref:refs/heads/*' and claims['repository_id'] eq '456789'
Para vincular adicionalmente la credencial a un propietario específico:
claims['sub'] matches 'repo:contoso/contoso-repo:ref:refs/heads/*' and claims['repository_id'] eq '456789' and claims['repository_owner_id'] eq '123456'
Operadores compatibles por claim:
sub:eqymatchesjob_workflow_ref:eqymatchesrepository_id:eqrepository_owner_id:eq
Este requisito se aplica independientemente de si sub usa un formato basado en nombres, personalizado o inmutable. Los ejemplos de Portal, Microsoft Graph y CLI se han actualizado para reflejar el nuevo requisito con languageVersion: 1.
Contexto más amplio: migración MC1447671
Esta actualización de documentación complementa el aviso anterior del Centro de mensajes MC1447671 del 5 de agosto de 2026, que recomendaba a las organizaciones migrar las credenciales de identidad federada de GitHub Actions a formatos de sujeto inmutables. Datos clave de ese aviso:
- Los repositorios creados después del 15 de julio de 2026 usan automáticamente el formato de sujeto predeterminado inmutable (incluye
owner_idyrepo_idcon delimitador@) - Los repositorios creados antes del 15 de julio de 2026 mantienen el formato basado en nombres a menos que se opte por el formato inmutable en la configuración de OIDC
- Los cambios de nombre y las transferencias de repositorios después del 15 de julio de 2026 pasan automáticamente al formato inmutable
- Enfoque de migración: cree una segunda credencial federada junto a la existente, pruebe y luego elimine la credencial anterior
El requisito de FIC flexible agrega una capa adicional de seguridad sobre la migración de sujetos inmutables al validar los claims inmutables directamente en la expresión de coincidencia de claims, en lugar de depender únicamente del formato del sujeto.
Si su organización usa GitHub Actions con credenciales de identidad federada de Entra, revise sus configuraciones ahora y asegúrese de que incluyan los claims inmutables de repositorio requeridos.
3. Las políticas de fuerza de autenticación no se pueden aplicar a usuarios externos autenticados con MSA
La documentación actualizada de Entra ID aclara que las políticas de fuerza de autenticación actualmente no se pueden aplicar a usuarios externos que se autentican a través de cuentas personales de Microsoft (MSA). Los administradores deben usar el control de concesión de MFA en Conditional Access en lugar de las políticas de fuerza de autenticación cuando necesiten aplicar autenticación multifactor para estos usuarios externos.
Esta es una aclaración de documentación de una limitación existente, no un comportamiento de producto recién introducido. Sin embargo, es importante para las organizaciones que usan políticas de fuerza de autenticación con escenarios de colaboración B2B en los que los usuarios externos se autentican a través de cuentas personales de Microsoft (Outlook.com, Hotmail, etc.). Si ha configurado políticas de fuerza de autenticación esperando que se apliquen a todos los usuarios externos, verifique que sus invitados autenticados con MSA estén cubiertos por una política separada de control de concesión de MFA.
4. Revisado el comportamiento de corrección del bloqueo de dispositivos en ID Protection
La documentación de Identity Protection se ha actualizado para corregir el comportamiento descrito cuando un dispositivo de Entra se deshabilita como parte de la corrección. La guía revisada establece que deshabilitar un dispositivo de Entra:
- Bloquea la emisión de nuevos tokens para ese dispositivo
- Revoca las sesiones de usuario asociadas con el dispositivo
- Solicita al usuario que inicie sesión nuevamente
La documentación anterior también mencionaba la revocación de tokens de actualización vinculados al dispositivo; ese lenguaje se ha eliminado. Esta es una corrección de documentación, no un cambio de comportamiento. El comportamiento real de corrección no ha cambiado; la documentación ahora describe con mayor precisión lo que sucede.
Esta actualización refina la entrada del 14 de agosto “Attacker-Added Device Remediation”, donde el artículo de Identity Protection Policies reemplazó el término “Device disablement” por “Attacker-added device”. Si ha documentado el alcance de la corrección internamente (para runbooks o materiales de capacitación), actualice esas referencias para eliminar el lenguaje de revocación de tokens de actualización.
5. Guía de sincronización de sAMAccountName para Entra Domain Services
La documentación de sincronización ahora incluye una guía mejorada para sincronizar el atributo sAMAccountName con Microsoft Entra Domain Services. La página actualizada describe el flujo de sincronización y enlaza a una guía dedicada para configurar sAMAccountName en escenarios de Domain Services.
Esta es una adición de documentación para una capacidad existente. Las organizaciones que usan Entra Domain Services y necesitan valores del atributo sAMAccountName para compatibilidad con aplicaciones heredadas o cargas de trabajo dependientes de LDAP deben consultar la guía actualizada.
6. Planes de servicio de ESU de Windows 10 agregados a la referencia de licencias
La referencia de planes de servicio de licencias de Entra ID se actualizó el 14 de agosto de 2026 para agregar los identificadores de planes de servicio de Extended Security Updates (ESU) de Windows 10 a las entradas de Windows 365 Enterprise y Windows 365 Shared Use. La tabla de referencia y el CSV descargable se han actualizado en consecuencia.
Los administradores que usan la referencia de licencias para la coincidencia de planes, la asignación de licencias basada en scripts o los informes deben descargar la referencia actualizada y actualizar cualquier asignación interna que incluya planes de Windows 365. No se requiere ninguna acción administrativa más allá de usar los datos de referencia actualizados.
Resumen
La semana del 15 al 18 de agosto de 2026 se caracteriza por el refinamiento de la documentación más que por nuevos lanzamientos de productos. Los elementos destacados son la guía de migración de filtrado web de GSA de V1 a V2, que brinda a los administradores una ruta concreta para transicionar sus políticas, y el requisito de claims inmutables de FIC flexible de GitHub, que fortalece la seguridad de la identidad federada para las implementaciones de GitHub Actions.
Aunque las actualizaciones de documentación pueden parecer menos impactantes que los lanzamientos de funciones, a menudo tienen consecuencias operativas reales. La guía de migración de GSA determina cómo las organizaciones transicionan su arquitectura de filtrado web, y el requisito de FIC de GitHub cambia qué configuraciones de confianza son válidas. Ambas merecen atención de los administradores de identidad que gestionan estas cargas de trabajo.
Para una cobertura continua de los cambios de Microsoft Entra ID, siga https://x.com/kkaminsk y vuelva aquí para actualizaciones semanales.
Este artículo se basa en las actualizaciones de documentación de Microsoft Learn, los resúmenes diarios de Entra.News y los anuncios del M365 Message Center del 15 al 18 de agosto de 2026. Para la página oficial de lanzamientos y anuncios de Microsoft Entra, visite learn.microsoft.com/en-us/entra/fundamentals/whats-new.