Entra ID retira memberOf el 3 de novembre: el grup no donarà error, es quedarà quiet

El 5 d'agost Microsoft va publicar al centre de missatges l'avís MC1448379, titulat «Replace MemberOf rules by November 3, 2026». Es va arxivar com el que sembla: un termini administratiu que llavors quedava a gairebé tres mesos. Avui en queden cinquanta-tres dies, i llegit a l'inrevés diu una cosa força pitjor: si tens una regla memberOf viva en producció, el problema que descriu l'avís no comença al novembre. Ja el tens avui. Ho diu la mateixa documentació de la vista prèvia, en un paràgraf que hi és des del gener.

Què és memberOf i per què va acabar en tants llocs

Entra ID mai no ha sabut fer bé el que a l'Active Directory de tota la vida era trivial: posar un grup dins d'un altre i que l'aplicació de sota ho entengui. L'operador memberOf va ser el pedaç d'això. Permet crear un grup de pertinença dinàmica la regla del qual no parla d'atributs de persona, sinó d'altres grups: user.memberof -any (group.objectId -in ['<id>']). Hi poses els identificadors dels grups origen, i el grup dinàmic s'omple amb els seus membres. I com que és un grup normal a tots els efectes, serveix per assignar llicències, per donar accés a aplicacions i per apuntar-hi una directiva d'Accés Condicional.

Això explica l'èxit. I explica també per què l'inventari que farà gairebé tothom aquesta setmana es quedarà curt: l'operador no viu en un lloc, viu en tres. Grups de pertinença dinàmica, unitats administratives dinàmiques i polítiques d'auto-assignació de la gestió de drets (els paquets d'accés). Tots tres es retiren alhora i cap dels altres dos no surt a la mateixa pantalla que els grups.

El que passa el 3 de novembre no és un error

Aquesta és la frase que cal llegir a poc a poc, perquè és la que decideix el risc. Microsoft diu que, després del 3 de novembre, les configuracions que continuïn fent servir memberOf deixen d'actualitzar-se i es queden «en el seu últim estat conegut». No diu que fallin. No diu que es buidin. No hi ha error, no hi ha alerta, no hi ha cap grup en vermell a cap consola. La pertinença que tingui el teu grup el dia del tall és la que tindrà al desembre i al febrer. A més convé llegir el calendari amb cura: l'avís parla d'una retirada «a partir de principis de novembre», així que el dia exacte en què el teu tenant deixa de recalcular no està garantit, només la data en què cal tenir-ho resolt.

L'avís enumera on es nota: accés a equips de Teams i llocs de SharePoint, direccionament de directives d'Accés Condicional, llicenciament basat en grup, assignacions de paquets d'accés i àmbit de les unitats administratives. Traduït a la setmana del 4 de novembre: la persona que entra aquell dia no rep la seva llicència ni queda dins de les polítiques que li toquen; la que se'n va el dia 5 conserva la pertinença a l'equip de Teams, amb els seus documents, i continua comptant a l'àmbit que tingués. I hi ha un tercer cas, el més freqüent i el que ningú mira: el que canvia de departament i acumula tots dos.

El paràgraf que és a la lletra petita des del 27 de gener

Vam anar a la pàgina de la vista prèvia a Microsoft Learn a buscar els límits de l'operador, i a la llista de limitacions hi ha això, sense cap destacat al voltant: «La pertinença d'un grup dinàmic memberOf no s'actualitza automàticament quan s'elimina un grup fill o quan es treuen membres d'un grup fill. Els usuaris o dispositius afectats continuen sent membres del grup dinàmic memberOf fins que es modifica la regla.» L'historial públic de la documentació posa data a aquell paràgraf: hi va entrar el 27 de gener de 2026, en un canvi titulat «Add important note about memberOf behavior when source group is deleted». Sis mesos abans de l'anunci de retirada.

Llegeix-ho un altre cop. El sentit «treure» no funciona. Afegir sí: poses algú al grup origen i apareix. Treure'l, no, fins que un humà toqui la regla. L'estat congelat que l'avís anuncia per al 3 de novembre fa des del gener que està documentat, i no passa a estones: passa sempre, en l'única direcció que importa per a la seguretat. La retirada no introdueix la fallada. La fa permanent i l'estén també a les altes.

La comprovació no costa res i la pots fer avui: agafa un grup memberOf, agafa algú que traguessin del grup origen fa mesos —un canvi d'equip, una reorganització, un projecte que es va acabar— i mira si continua dins del grup dinàmic. Compte amb el cas que no serveix de prova: qui té el compte esborrat desapareix igualment, perquè ja no és membre de res. Els que busques són els que continuen treballant a l'empresa. Si hi continuen, ja saps què tens: gent que consumeix una llicència que pagues i que conserva un accés que algú va donar per retirat. És el mateix patró del qual parlem quan una dada del directori resulta valer com a credencial, al post sobre el telèfon de la fitxa d'SSPR: el permís real no és el que figura a la matriu de rols, és el que es deriva de com es calcula la pertinença.

Per què es retira: el peatge el pagaven tots

La raó que dona Microsoft és inusualment concreta, i mereix citar-se: durant la vista prèvia van observar que fer servir memberOf pot alentir el processament de pertinença dinàmica de tots els grups del tenant, no només del grup que el fa servir. A l'avís del centre de missatges ho rematen: n'hi ha prou de tenir una regla amb l'operador.

Això és lectura nostra i no del document: ens sembla la raó més honesta que es pot donar per matar una funció. No la maten perquè ningú no la faci servir, la maten perquè qui la fa servir cobra el peatge a la resta del seu propi tenant. Si alguna vegada has vist un grup dinàmic trigant a omplir-se i ho has arxivat mentalment com a «coses d'Azure», aquí tens una explicació candidata. No diem que sigui la teva; diem que ara hi ha un lloc on mirar. Microsoft afegeix que continua desenvolupant una alternativa que cobreixi el mateix escenari amb l'escalabilitat adequada, i no dona data. Planificar el novembre comptant amb això seria repetir exactament l'error que ens ha portat fins aquí.

«Vista prèvia» mai no va voler dir «beta que va bé»

La mateixa pàgina que documenta l'operador obre la llista de limitacions així: «Aquesta vista prèvia només s'hauria de fer servir en entorns de prova, ja que pot afectar el processament de grups dinàmics del tenant. Aquestes limitacions s'estan abordant i es publicaran novetats quan estiguin disponibles.» Aquella segona frase, la promesa, és exactament el que la retirada cancel·la. I continua: màxim 500 grups memberOf per tenant, que compten a més dins de la quota total de 15.000 grups dinàmics; màxim 50 grups membre per grup; només hi entren els membres directes del grup origen, així que niar de debò continua sense funcionar; no es pot encadenar un memberOf dins d'un altre; no es pot combinar amb altres regles ni amb altres operadors; no apareix al constructor de regles, cal escriure-la en sintaxi avançada; i només és al núvol públic.

Amb aquesta llista al davant, la pregunta interessant no és per què el retiren, sinó per què va entrar en tants llocs en producció, i la resposta no és que ningú no llegís: resolia un dolor real que Entra ID continua sense resoldre. La lletra petita d'una vista prèvia mai no va ser «pot tenir errors»: és «pot desaparèixer, i el pla B és teu». Nosaltres no quedem fora d'aquesta frase, i la regla que ens apliquem és la que recomanem: si una funció en vista prèvia sosté un permís, una llicència o un accés, o té sortida escrita o no entra en producció. Sobretot aquí, que és el lloc on viu la teva identitat i no una aplicació més.

El que faríem aquesta setmana

1. Inventaria els tres llocs, no només els grups. Exporta els grups de pertinença dinàmica des del centre d'administració d'Entra i busca memberOf dins de la regla de pertinença. Després, amb Microsoft Graph PowerShell, repassa les unitats administratives dinàmiques i les polítiques d'auto-assignació de paquets d'accés. És la recomanació literal del mateix Microsoft, i és on es perd la meitat de la feina: qui només miri la pantalla de grups es deixarà dues famílies senceres.
2. Fes el mapatge invers, que és la feina de debò. Per a cada regla trobada, escriu què en penja: quina llicència, quina directiva d'Accés Condicional i si hi entra com a inclusió o com a exclusió, quin equip de Teams amb el seu SharePoint al darrere, quin paquet d'accés. Cap exportació no et dona aquest mapa; cal construir-lo a mà i és el que més triga. També és l'única cosa que converteix «tenim 40 grups» en «tenim 40 grups i tres apaguen l'MFA».
3. Mesura el deute abans de tocar res. Compara la pertinença actual de cada grup dinàmic amb la del grup origen. El que hi sobra són els que s'han quedat enganxats per la limitació que ja existeix. Aquest número —quantes persones conserven un accés que es va donar per retirat, i quantes llicències s'estan pagant per elles— és el que cal ensenyar a direcció, i és la diferència entre «una tasca tècnica» i «un pressupost aprovat».
4. Tria el substitut amb els ulls oberts. Les dues sortides són un operador suportat sobre un atribut real (department, jobTitle, un extensionAttribute) o passar el grup a pertinença assignada i alimentar-lo amb automatització. La primera és millor, però muda el problema a un altre lloc: si la regla depèn de department, ara depens que Recursos Humans escrigui bé aquell camp el dia que algú canvia de lloc. Canvies un problema de pertinença per un de qualitat de la dada. És un canvi bo; cal dir-ho en veu alta i posar-hi responsable.
5. En canviar la regla, mira qui SURT. La validació natural és comprovar que els de sempre continuen dins, i aquesta no troba res. La llista de baixes en aplicar la regla nova és on apareixen alhora els que estaven enganxats i els errors que acabes d'introduir, i cal revisar-la persona a persona. Si pots, valida la pertinença amb el grup desconnectat de llicències i directives, i reconnecta després.
6. Posa't una data pròpia abans que la de Microsoft. El 3 de novembre cau en dimarts. Una migració de pertinences que es valida el mateix dia que caduca la funció no es valida: es creuen els dits. Nosaltres posaríem el tall a mitjans d'octubre, amb dues setmanes de marge per veure un cicle sencer d'altes i baixes funcionant amb la regla nova. I amb aquesta foto al davant, aprofita per revisar què més apunta a aquests grups, que és la conversa que de debò importa: quins controls compta Entra i quins no.

El que no afirmem

No sabem quants tenants fan servir memberOf i no ho estimem: Microsoft no publica aquesta dada. Això tampoc no afecta els grups dinàmics en general —els que van per atributs continuen igual—, només les configuracions que fan servir aquell operador als tres llocs citats. No hem verificat els límits en cap tenant de client: surten de la documentació del fabricant, igual que les citacions. No diem que Microsoft faci malament de retirar-lo; amb la raó que dona, retirar-lo és el correcte, i el descàrrec estava escrit. I no és assessorament de llicenciament: no venem llicències de Microsoft ni de ningú, així que el que et recomanem aquí no ens canvia la factura.

Nota de fonts

Tot el que aquest post afirma sobre la retirada surt de tres fonts públiques, consultades l'11 de setembre de 2026. La primera és l'avís del centre de missatges de Microsoft 365 MC1448379, «Microsoft Entra ID: Replace MemberOf rules by November 3, 2026», publicat el 5 d'agost de 2026, del qual procedeixen la data, la classificació com a canvi major que afecta operacions d'usuari i d'administrador, la frase que n'hi ha prou amb una sola regla amb l'operador per afectar el processament del tenant, la llista d'escenaris impactats i el calendari de desplegament, que diu literalment «Retirement (Worldwide): Beginning in early November 2026». La segona és la pàgina de Microsoft Learn «Configure dynamic membership groups with the memberOf operator in the Entra Admin Center (preview)», amb data de document del 4 d'agost de 2026 i última actualització del 5 d'agost de 2026, d'on surten les citacions literals —l'avís de retirada, el paràgraf de les limitacions sobre membres retirats d'un grup fill, l'advertiment de fer servir la vista prèvia només en entorns de prova i el text de «Migrate before the preview ends»—, la sintaxi de la regla, els requisits de llicència P1 o P2 i rol d'Administrador d'usuaris, i tots els límits numèrics: 500 grups memberOf per tenant, quota total de 15.000 grups dinàmics, 50 grups membre per grup, només membres directes, sense encadenar, sense combinar amb altres regles ni operadors, sense constructor de regles i només al núvol públic. Les citacions es reprodueixen aquí en la nostra traducció; l'original és en anglès. La tercera és l'historial públic de la documentació al repositori MicrosoftDocs/entra-docs de GitHub, d'on surt la data del paràgraf de les limitacions: el canvi titulat «Add important note about memberOf behavior when source group is deleted» està datat el 27 de gener de 2026, i el que hi afegeix l'advertiment d'entorns de prova, el 14 de novembre de 2025. És lectura NOSTRA, i no del document: que l'estat congelat ja estigui passant avui en el sentit de qui surt del grup origen; que a l'Accés Condicional cap de les dues direccions no avisi i que l'exclusió tingui més radi de dany; que la raó del peatge al tenant sigui l'explicació més honesta possible; la lectura de què significa «vista prèvia»; i els sis punts de la llista, inclosa la data de tall de mitjans d'octubre. No donem cap xifra d'adopció, de cost ni de nombre de tenants afectats, perquè no la tenim. La fotografia de portada és «Office Desk Computer», publicada a rawpixel sota llicència Creative Commons CC0 1.0 i retallada per a aquest ús.