Retirada del operador de regla memberOf para grupos dinámicos de Entra ID: qué se rompe el 3 de noviembre

Retirada del operador de regla memberOf de grupos dinámicos en Entra ID: en qué consiste

La retirada del operador de regla memberOf para grupos dinámicos de Entra ID llega el 3 de noviembre de 2026 — a partir de esa fecha, cualquier configuración que todavía lo use deja de actualizarse. memberOf es un operador de regla de pertenencia dinámica, lanzado en vista previa pública, que permite que un grupo dinámico, una unidad administrativa dinámica o una política de asignación automática de gestión de derechos se pueble a partir de los miembros de otros grupos. En lugar de escribir reglas por atributo (departamento, puesto, atributos de extensión), un administrador podía apuntar un grupo dinámico a hasta 50 grupos de seguridad, grupos de Microsoft 365 o grupos sincronizados on-premises "origen" y hacer que Entra ID incorporara automáticamente sus miembros directos.

El 5 de agosto de 2026, Microsoft publicó el mensaje MC1448379 en el Centro de mensajes, anunciando el fin de la vista previa de memberOf. Según la documentación oficial de Microsoft Learn, después del 3 de noviembre de 2026, cualquier grupo de pertenencia dinámica, unidad administrativa dinámica o política de asignación automática de gestión de derechos que todavía use memberOf deja de actualizarse y se congela en su último estado conocido. Microsoft lo plantea como una limitación de escalabilidad y fiabilidad, no como una corrección de seguridad — pero el impacto operativo golpea a los equipos de identidad de la misma forma que lo haría un error: en silencio y con fecha límite. Es el mismo patrón de "tranquilo en la superficie, roto por debajo" que cubrimos cuando un certificado de firma SAML de Entra expirado rompió el inicio de sesión federado en todo el tenant: el desencadenante es un cambio del lado de Microsoft, pero el radio de impacto depende por completo de si has seguido tu propia configuración.

Cómo funciona — y por qué Microsoft lo retira

Una regla memberOf se escribe en la sintaxis de regla avanzada de grupos dinámicos de Entra (no es compatible con la interfaz del generador de reglas — solo con el editor de reglas en bruto):

user.memberof -any (group.objectId -in ['<sourceGroupObjectId>'])

o para grupos dinámicos basados en dispositivos:

device.memberof -any (group.objectId -in ['<sourceGroupObjectId>'])

Se pueden listar varios grupos origen en la misma regla (-in ['<groupId1>', '<groupId2>']), y el grupo dinámico resultante puede usarse para la asignación de aplicaciones, el destino de Acceso condicional, o la asignación de licencias por grupo — en cualquier lugar donde funcione un grupo normal.

Según las propias limitaciones de vista previa de Microsoft, la función siempre estuvo estrechamente acotada: un límite de 500 grupos dinámicos que usan memberOf por tenant (contabilizado dentro de la cuota global de 15.000 grupos dinámicos), un límite de 50 grupos origen por regla, solo miembros directos (sin anidamiento transitivo — los miembros de un grupo anidado dentro de un grupo origen no se incorporan), sin encadenar un grupo dinámico memberOf dentro de otro, y sin combinar memberOf con ninguna otra cláusula de regla. Se requería licencia Microsoft Entra ID Premium P1 o P2 y al menos el rol de Administrador de usuarios solo para configurarlo.

El motivo de la retirada, según las indicaciones de migración de Microsoft, es la escalabilidad: usar memberOf "puede afectar el procesamiento de pertenencia dinámica en todo un tenant incluso con una sola regla memberOf". Una sola regla podía ralentizar la evaluación de grupos dinámicos no relacionados en todo el tenant — por lo que Microsoft indica explícitamente que el operador "no se recomienda para uso en producción", pese a que tenants reales lo adoptaron en producción durante la vista previa.

Microsoft afirma estar "continuando el desarrollo de una solución alternativa" con escalabilidad adecuada, pero no se ha comprometido con ninguna función de reemplazo ni fecha — las indicaciones de migración actuales apuntan a los operadores de regla existentes o a la pertenencia asignada (estática), no a un sustituto directo.

Detección: encuentra cada regla memberOf antes de que se congele

El riesgo no es la retirada en sí — es no saber qué grupos dinámicos, unidades administrativas y paquetes de acceso dependen silenciosamente de memberOf hoy. Como el operador era exclusivo de la vista previa y nunca se expuso en la interfaz del generador de reglas, los objetos afectados pueden pasar fácilmente desapercibidos en una revisión de consola rutinaria; la forma fiable de encontrarlos es una consulta específica de Microsoft Graph. Si todavía no realizas una revisión estructurada de la configuración de Entra ID, nuestra guía para auditar la seguridad de Microsoft Entra ID cubre el proceso de revisión más amplio en el que encaja este paso de detección.

Ejemplo de PowerShell de Graph, adaptado de las indicaciones de migración resumidas por office365itpros.com:

Connect-MgGraph -Scopes GroupMember.Read.All

[array]$Groups = Get-MgGroup -Filter "groupTypes/any(c:c eq 'dynamicmembership') and (startsWith(membershipRule,'user.memberOf') or startsWith(membershipRule,'device.memberOf'))" -All

Connect-MgGraph -Scopes AdministrativeUnit.Read.All

[array]$DynamicAdminUnits = Get-MgDirectoryAdministrativeUnit -Filter "membershipType eq 'Dynamic' and (startsWith(membershipRule,'user.memberOf') or startsWith(membershipRule,'device.memberOf'))" -All

$Uri = "https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentPolicies"
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PsObject | Select-Object -ExpandProperty Value
$Data | Where-Object {$_.automaticRequestSettings}

La última consulta devuelve todas las políticas de asignación automática; cada resultado necesita después una revisión manual de sus criterios automaticRequestSettings en busca de lógica basada en memberOf, ya que la API no expone un filtro directo para ello.

Remediación: migra antes del 3 de noviembre de 2026

Las indicaciones de migración de Microsoft se dividen en tres frentes:

1. Grupos de pertenencia dinámica — Exporta los grupos dinámicos identificados arriba, reemplaza memberOf por un operador de regla compatible (reglas basadas en atributos de usuario o dispositivo) donde se pueda expresar la misma población de esa forma, o convierte el grupo a pertenencia asignada (estática). Valida que la pertenencia del grupo resultante coincide con lo esperado antes de eliminar la regla anterior.
2. Unidades administrativas dinámicas — Mismo patrón: reemplaza la regla basada en memberOf por lógica compatible, o convierte a pertenencia asignada. Como las unidades administrativas acotan permisos administrativos delegados, valida tanto la pertenencia resultante como el alcance administrativo — una unidad administrativa ampliada es un riesgo de escalada de privilegios de la misma familia que la exposición de administradores globales permanentes que cubrimos en Acceso privilegiado en Azure, no solo un grupo obsoleto.
3. Políticas de asignación automática de gestión de derechos — Reemplaza los criterios basados en memberOf por operadores basados en atributos compatibles donde exista un equivalente. Donde no exista, las indicaciones de Microsoft son explícitas: los equipos deben planificar un método de asignación alternativo antes de la fecha límite — no hay un reemplazo equivalente garantizado.

Para cada objeto que toques, valida los efectos posteriores antes de la fecha límite, no después: la asignación de licencias por grupo, el destino de Acceso condicional y el acceso a Teams/SharePoint a través de grupos de Microsoft 365 leen todos de la misma pertenencia que se congela el 3 de noviembre de 2026. Un usuario sin licencia o con licencia de más, o una política de Acceso condicional que excluye en silencio a un equipo que creció después de la congelación, es el tipo de brecha que sale a la luz semanas después durante una revisión de acceso — no el primer día.

Cómo lo detecta EtcSec

EtcSec señala los grupos dinámicos con reglas de pertenencia demasiado amplias o de alto riesgo mediante la comprobación AZ_GROUP_DYNAMIC_RULE_BROAD, que saca a la luz las configuraciones de pertenencia dinámica — incluidas las reglas basadas en memberOf — que merece la pena revisar antes de que se salgan de alcance o, como en este caso, dejen de actualizarse por completo. EtcSec también verifica la cobertura de licencias Entra ID P1/P2 (AZ_NO_P2_LICENSE), ya que memberOf y la mayoría de sus sucesores compatibles requieren licencia Premium para configurarse y mantenerse.