Chi amministra Microsoft Entra ID conosce bene il problema dei “gruppi nidificati”: per anni non è stato possibile costruire un gruppo dinamico che includesse automaticamente i membri di un altro gruppo. La regola preview memberOf, introdotta proprio per colmare questa lacuna, sta però per essere ritirata. Dal 3 novembre 2026 tutte le configurazioni che la usano smetteranno di aggiornarsi, restando congelate all’ultimo stato elaborato correttamente. Se gestite gruppi dinamici, unità amministrative dinamiche o policy di entitlement management basate su memberOf, è il momento di pianificare la migrazione.

Cos’è (stato) l’operatore memberOf

In anteprima pubblica, memberOf ha permesso di creare gruppi a membership dinamica popolati a partire dall’appartenenza ad altri gruppi, di sicurezza, Microsoft 365 o sincronizzati da Active Directory on-premises. La regola si scriveva nella sintassi avanzata del rule editor, non essendo mai stata supportata dal rule builder grafico:

// Regola per un gruppo dinamico di utenti
user.memberof -any (group.objectId -in ['<groupObjectId>'])

// Regola per un gruppo dinamico di device
device.memberof -any (group.objectId -in ['<groupObjectId>'])

// Più gruppi sorgente contemporaneamente
user.memberof -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>'])

Era possibile usarla per gruppi dinamici veri e propri, per unità amministrative dinamiche e per policy di auto-assignment in Entra ID Governance, con limiti già stringenti in preview: 500 gruppi memberOf per tenant, massimo 50 gruppi sorgente per regola, nessuna combinazione con altri operatori o con altre regole memberOf annidate.

Perché Microsoft la ritira

Durante la preview, Microsoft ha osservato che l’uso di memberOf può rallentare l’elaborazione della membership dinamica per tutti i gruppi del tenant, non solo per quelli che la utilizzano: un singolo gruppo configurato con questo operatore può introdurre ritardi di elaborazione a livello di tenant. Per questo motivo Microsoft ha deciso di ritirare l’operatore dalla preview, pur riconoscendo la validità dello scenario d’uso, e sta sviluppando una soluzione alternativa più scalabile, senza però fornire ancora una data di disponibilità.

Cosa succede dopo il 3 novembre 2026

Le configurazioni che usano ancora memberOf non genereranno errori visibili: semplicemente smetteranno di aggiungere o rimuovere membri quando cambia l’appartenenza ai gruppi sorgente, restando congelate all’ultimo stato noto. È un comportamento subdolo perché non c’è un evento di rottura evidente, solo un progressivo disallineamento tra la realtà organizzativa e ciò che Entra ID applica. Gli effetti possono includere:

• Accessi Teams e SharePoint non più aggiornati per utenti entrati o usciti da un gruppo sorgente
• Targeting delle policy di Conditional Access basato su appartenenze obsolete
• Licenze assegnate tramite group-based licensing non più coerenti con l’organico reale
• Ambiti amministrativi (administrative unit) che non riflettono più la struttura corrente
• Assegnazioni di access package in Entra ID Governance bloccate sullo stato congelato

Come prepararsi: audit prima della deadline

Il primo passo è mappare ogni configurazione che dipende da memberOf. Per i gruppi dinamici, si può esportare l’elenco dall’Entra admin center oppure interrogare Microsoft Graph PowerShell cercando la stringa nella proprietà MembershipRule:

Connect-MgGraph -Scopes "Group.Read.All"

Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" `
    -Property Id, DisplayName, MembershipRule |
    Where-Object { $_.MembershipRule -match 'memberof' } |
    Select-Object Id, DisplayName, MembershipRule

Per le unità amministrative dinamiche e le policy di auto-assignment dell’entitlement management non esiste (ancora) un filtro diretto lato server sulla regola: occorre enumerare gli oggetti e verificare la proprietà della regola dinamica, ad esempio:

# Unità amministrative dinamiche
Get-MgDirectoryAdministrativeUnit -All -Property Id, DisplayName, MembershipRule |
    Where-Object { $_.MembershipRule -match 'memberof' }

# Policy di auto-assignment (Entitlement Management)
Get-MgEntitlementManagementAccessPackageAssignmentPolicy -All |
    Where-Object { $_.AutomaticRequestSettings.RequestAccessForAllowedTargets -ne $null }

Per le policy di entitlement management è comunque consigliabile incrociare l’output con la revisione manuale in Entra ID Governance, dato che la struttura della regola può variare a seconda di come è stata configurata.

Strategie di migrazione

Una volta identificate le configurazioni a rischio, Microsoft indica due strade principali:

• Sostituire la regola con operatori dinamici supportati (ad esempio basati su attributi utente o dispositivo), quando esiste un equivalente funzionale
• Convertire a membership assegnata quando non è possibile replicare la logica di nesting con le regole standard, accettando la gestione manuale o tramite automazione esterna (es. script PowerShell schedulati o Logic App)

In entrambi i casi, prima di considerare chiusa la migrazione bisogna validare concretamente: verificare che la membership finale del gruppo coincida con quella attesa, controllare che le assegnazioni di licenza, gli scope di Conditional Access e i pacchetti di accesso continuino a comportarsi correttamente, ed eliminare le configurazioni ormai inutilizzate invece di lasciarle come debito tecnico silente.

Conclusione

Il ritiro di memberOf è un promemoria di un principio più generale nel cloud amministrato: le funzionalità in preview non vanno mai considerate stabili in produzione, per quanto risolvano un problema reale. Con circa tre mesi di margine dalla data di scrittura di questo articolo al 3 novembre 2026, il momento giusto per l’audit è ora, prima che il “congelamento” silenzioso della membership diventi un problema di accesso scoperto in produzione da un utente che segnala di aver perso l’accesso a un canale Teams.

Fonte: Microsoft Learn – Configure dynamic membership groups with the memberOf operator, con approfondimenti da 4sysops e Petri IT Knowledgebase.