Entra ID retira memberOf el 3 de noviembre: el grupo no dará error, se quedará quieto

El 5 de agosto Microsoft publicó en el centro de mensajes el aviso MC1448379, titulado «Replace MemberOf rules by November 3, 2026». Se archivó como lo que parece: un plazo administrativo que entonces quedaba a casi tres meses. Hoy quedan cincuenta y tres días, y leído al revés dice algo bastante peor: si tienes una regla memberOf viva en producción, el problema que describe el aviso no empieza en noviembre. Ya lo tienes hoy. Lo dice la propia documentación de la vista previa, en un párrafo que lleva ahí desde enero.

Qué es memberOf y por qué acabó en tantos sitios

Entra ID nunca ha sabido hacer bien lo que en el Active Directory de toda la vida era trivial: meter un grupo dentro de otro y que la aplicación de abajo lo entienda. El operador memberOf fue el parche a eso. Permite crear un grupo de pertenencia dinámica cuya regla no habla de atributos de persona, sino de otros grupos: user.memberof -any (group.objectId -in ['<id>']). Tú metes ahí los identificadores de los grupos origen, y el grupo dinámico se puebla con sus miembros. Y como es un grupo normal a todos los efectos, sirve para asignar licencias, para dar acceso a aplicaciones y para apuntar una directiva de Acceso Condicional.

Eso explica el éxito. Y explica también por qué el inventario que va a hacer casi todo el mundo esta semana se va a quedar corto: el operador no vive en un sitio, vive en tres. Grupos de pertenencia dinámica, unidades administrativas dinámicas y políticas de auto-asignación de la gestión de derechos (los paquetes de acceso). Los tres se retiran a la vez y ninguno de los otros dos sale en la misma pantalla que los grupos.

Lo que pasa el 3 de noviembre no es un error

Esta es la frase que hay que leer despacio, porque es la que decide el riesgo. Microsoft dice que, después del 3 de noviembre, las configuraciones que sigan usando memberOf dejan de actualizarse y se quedan «en su último estado conocido». No dice que fallen. No dice que se vacíen. No hay error, no hay alerta, no hay un grupo en rojo en ninguna consola. La pertenencia que tenga tu grupo el día del corte es la que va a tener en diciembre y en febrero. Conviene además leer el calendario con cuidado: el aviso habla de una retirada «a partir de principios de noviembre», así que el día exacto en el que tu tenant deja de recalcular no está garantizado, sólo la fecha en la que hay que tenerlo resuelto.

El aviso enumera dónde se nota: acceso a equipos de Teams y sitios de SharePoint, direccionamiento de directivas de Acceso Condicional, licenciamiento basado en grupo, asignaciones de paquetes de acceso y ámbito de las unidades administrativas. Traducido a la semana del 4 de noviembre: la persona que entra ese día no recibe su licencia ni queda dentro de las políticas que le tocan; la que se va el día 5 conserva la pertenencia al equipo de Teams, con sus documentos, y sigue contando en el ámbito que tuviera. Y hay un tercer caso, el más frecuente y el que nadie mira: el que cambia de departamento y acumula los dos.

El párrafo que lleva en la letra pequeña desde el 27 de enero

Fuimos a la página de la vista previa en Microsoft Learn a buscar los límites del operador, y en la lista de limitaciones hay esto, sin ningún destacado alrededor: «La pertenencia de un grupo dinámico memberOf no se actualiza automáticamente cuando se elimina un grupo hijo o cuando se quitan miembros de un grupo hijo. Los usuarios o dispositivos afectados siguen siendo miembros del grupo dinámico memberOf hasta que se modifica la regla.» El historial público de la documentación pone fecha a ese párrafo: entró el 27 de enero de 2026, en un cambio titulado «Add important note about memberOf behavior when source group is deleted». Seis meses antes del anuncio de retirada.

Léelo otra vez. El sentido «quitar» no funciona. Añadir sí: metes a alguien en el grupo origen y aparece. Sacarlo, no, hasta que un humano toque la regla. El estado congelado que el aviso anuncia para el 3 de noviembre lleva documentado desde enero, y no ocurre a ratos: ocurre siempre, en la única dirección que importa para la seguridad. La retirada no introduce el fallo. Lo hace permanente y lo extiende también a las altas.

La comprobación no cuesta nada y la puedes hacer hoy: coge un grupo memberOf, coge a alguien a quien sacaran del grupo origen hace meses —un cambio de equipo, una reorganización, un proyecto que terminó— y mira si sigue dentro del grupo dinámico. Ojo con el caso que no sirve de prueba: quien tiene la cuenta borrada desaparece igual, porque ya no es miembro de nada. Los que buscas son los que siguen trabajando en la empresa. Si siguen dentro, ya sabes lo que tienes: gente que consume una licencia que pagas y que conserva un acceso que alguien dio por retirado. Es el mismo patrón del que hablamos cuando un dato del directorio resulta valer como credencial, en el post sobre el teléfono de la ficha de SSPR: el permiso real no es el que figura en la matriz de roles, es el que se deriva de cómo se calcula la pertenencia.

Por qué se retira: el peaje lo pagaban todos

La razón que da Microsoft es inusualmente concreta, y merece citarse: durante la vista previa observaron que usar memberOf puede ralentizar el procesamiento de pertenencia dinámica de todos los grupos del tenant, no sólo del grupo que lo usa. En el aviso del centro de mensajes lo rematan: basta con tener una regla con el operador.

Esto es lectura nuestra y no del documento: nos parece la razón más honesta que se puede dar para matar una función. No la matan porque nadie la use, la matan porque quien la usa le cobra el peaje al resto de su propio tenant. Si alguna vez has visto un grupo dinámico tardando en poblarse y lo has archivado mentalmente como «cosas de Azure», aquí tienes una explicación candidata. No decimos que sea la tuya; decimos que ahora existe un sitio donde mirar. Microsoft añade que sigue desarrollando una alternativa que cubra el mismo escenario con la escalabilidad adecuada, y no da fecha. Planificar noviembre contando con eso sería repetir exactamente el error que nos trajo hasta aquí.

«Vista previa» nunca quiso decir «beta que va bien»

La misma página que documenta el operador abre la lista de limitaciones así: «Esta vista previa sólo debería usarse en entornos de prueba, ya que puede afectar al procesamiento de grupos dinámicos del tenant. Estas limitaciones se están abordando y se publicarán novedades cuando estén disponibles.» Esa segunda frase, la promesa, es exactamente lo que la retirada cancela. Y sigue: máximo 500 grupos memberOf por tenant, que cuentan además dentro de la cuota total de 15.000 grupos dinámicos; máximo 50 grupos miembro por grupo; sólo entran los miembros directos del grupo origen, así que anidar de verdad sigue sin funcionar; no se puede encadenar un memberOf dentro de otro; no se puede combinar con otras reglas ni con otros operadores; no aparece en el constructor de reglas, hay que escribirla en sintaxis avanzada; y sólo está en nube pública.

Con esa lista delante, la pregunta interesante no es por qué lo retiran, sino por qué entró en tantos sitios en producción, y la respuesta no es que nadie leyera: resolvía un dolor real que Entra ID sigue sin resolver. La letra pequeña de una vista previa nunca fue «puede tener fallos»: es «puede desaparecer, y el plan B es tuyo». Nosotros no estamos fuera de esa frase, y la regla que nos aplicamos es la que recomendamos: si una función en vista previa sostiene un permiso, una licencia o un acceso, o tiene salida escrita o no entra en producción. Sobre todo aquí, que es el sitio donde vive tu identidad y no una aplicación más.

Lo que haríamos esta semana

1. Inventaría los tres sitios, no sólo los grupos. Exporta los grupos de pertenencia dinámica desde el centro de administración de Entra y busca memberOf dentro de la regla de pertenencia. Después, con Microsoft Graph PowerShell, repasa las unidades administrativas dinámicas y las políticas de auto-asignación de paquetes de acceso. Es la recomendación literal del propio Microsoft, y es donde se pierde la mitad del trabajo: quien sólo mire la pantalla de grupos se va a dejar dos familias enteras.
2. Haz el mapeo inverso, que es el trabajo de verdad. Para cada regla encontrada, escribe qué cuelga de ella: qué licencia, qué directiva de Acceso Condicional y si entra como inclusión o como exclusión, qué equipo de Teams con su SharePoint detrás, qué paquete de acceso. Ninguna exportación te da ese mapa; hay que construirlo a mano y es lo que más tarda. También es lo único que convierte «tenemos 40 grupos» en «tenemos 40 grupos y tres de ellos apagan el MFA».
3. Mide la deuda antes de tocar nada. Compara la pertenencia actual de cada grupo dinámico con la del grupo origen. Lo que sobra son los que se quedaron pegados por la limitación que ya existe. Ese número —cuántas personas conservan un acceso que se dio por retirado, y cuántas licencias se están pagando por ellas— es lo que hay que enseñar a dirección, y es la diferencia entre «una tarea técnica» y «un presupuesto aprobado».
4. Elige el sustituto con los ojos abiertos. Las dos salidas son un operador soportado sobre un atributo real (department, jobTitle, un extensionAttribute) o pasar el grupo a pertenencia asignada y alimentarlo con automatización. La primera es mejor, pero muda el problema a otro sitio: si la regla depende de department, ahora dependes de que Recursos Humanos escriba bien ese campo el día que alguien cambia de puesto. Cambias un problema de pertenencia por uno de calidad del dato. Es un cambio bueno; hay que decirlo en voz alta y ponerle dueño.
5. Al cambiar la regla, mira quién SALE. La validación natural es comprobar que los de siempre siguen dentro, y esa no encuentra nada. La lista de bajas al aplicar la regla nueva es donde aparecen a la vez los que llevaban pegados y los errores que acabas de introducir, y hay que revisarla persona a persona. Si puedes, valida la pertenencia con el grupo desconectado de licencias y directivas, y reconecta después.
6. Ponte una fecha propia antes que la de Microsoft. El 3 de noviembre cae en martes. Una migración de pertenencias que se valida el mismo día que caduca la función no se valida: se cruza los dedos. Nosotros pondríamos el corte a mediados de octubre, con dos semanas de margen para ver un ciclo entero de altas y bajas funcionando con la regla nueva. Y con esa foto delante, aprovecha para revisar qué más apunta a esos grupos, que es la conversación que de verdad importa: qué controles cuenta Entra y cuáles no.

Lo que no afirmamos

No sabemos cuántos tenants usan memberOf y no lo estimamos: Microsoft no publica ese dato. Esto tampoco afecta a los grupos dinámicos en general —los que van por atributos siguen igual—, sólo a las configuraciones que usan ese operador en los tres sitios citados. No hemos verificado los límites en ningún tenant de cliente: salen de la documentación del fabricante, igual que las citas. No decimos que Microsoft haga mal en retirarlo; con la razón que da, retirarlo es lo correcto, y el descargo estaba escrito. Y no es asesoramiento de licenciamiento: no vendemos licencias de Microsoft ni de nadie, así que lo que te recomendemos aquí no nos cambia la factura.

Nota de fuentes

Todo lo que este post afirma sobre la retirada sale de tres fuentes públicas, consultadas el 11 de septiembre de 2026. La primera es el aviso del centro de mensajes de Microsoft 365 MC1448379, «Microsoft Entra ID: Replace MemberOf rules by November 3, 2026», publicado el 5 de agosto de 2026, del que proceden la fecha, la clasificación como cambio mayor que afecta a operaciones de usuario y de administrador, la frase de que basta una sola regla con el operador para afectar al procesamiento del tenant, la lista de escenarios impactados y el calendario de despliegue, que dice literalmente «Retirement (Worldwide): Beginning in early November 2026». La segunda es la página de Microsoft Learn «Configure dynamic membership groups with the memberOf operator in the Entra Admin Center (preview)», con fecha de documento del 4 de agosto de 2026 y última actualización del 5 de agosto de 2026, de donde salen las citas literales —el aviso de retirada, el párrafo de las limitaciones sobre miembros quitados de un grupo hijo, la advertencia de usar la vista previa sólo en entornos de prueba y el texto de «Migrate before the preview ends»—, la sintaxis de la regla, los requisitos de licencia P1 o P2 y rol de Administrador de usuarios, y todos los límites numéricos: 500 grupos memberOf por tenant, cuota total de 15.000 grupos dinámicos, 50 grupos miembro por grupo, sólo miembros directos, sin encadenar, sin combinar con otras reglas ni operadores, sin constructor de reglas y sólo en nube pública. Las citas se reproducen aquí en nuestra traducción; el original está en inglés. La tercera es el historial público de la documentación en el repositorio MicrosoftDocs/entra-docs de GitHub, de donde sale la fecha del párrafo de las limitaciones: el cambio titulado «Add important note about memberOf behavior when source group is deleted» está fechado el 27 de enero de 2026, y el que añade la advertencia de entornos de prueba, el 14 de noviembre de 2025. Es lectura NUESTRA, y no del documento: que el estado congelado ya esté ocurriendo hoy en el sentido de quienes salen del grupo origen; que en Acceso Condicional ninguna de las dos direcciones avise y que la exclusión tenga más radio de daño; que la razón del peaje al tenant sea la explicación más honesta posible; la lectura de qué significa «vista previa»; y los seis puntos de la lista, incluida la fecha de corte de mediados de octubre. No damos ninguna cifra de adopción, de coste ni de número de tenants afectados, porque no la tenemos. La fotografía de portada es «Office Desk Computer», publicada en rawpixel bajo licencia Creative Commons CC0 1.0 y recortada para este uso.