Microsoft Entra: memberOf non arriverà alla General Availability
Introduzione
Microsoft ha deciso di interrompere la public preview dell’operatore memberOf utilizzato nelle dynamic membership rule di Microsoft Entra ID. La particolarità dell’annuncio è che la funzionalità non raggiungerà la General Availability nella forma attuale: dopo un periodo trascorso in preview, Microsoft ne terminerà il supporto operativo il 3 novembre 2026 e chiede agli amministratori di sostituire le configurazioni che ancora la utilizzano.
L’operatore memberOf era stato introdotto per consentire di determinare dinamicamente l’appartenenza a un gruppo, a una administrative unit o a determinate policy di Microsoft Entra Entitlement Management partendo dall’appartenenza ad altri gruppi. Durante la preview, tuttavia, molti amministratori e Microsoft stessa hanno rilevato problemi di scalabilità e prestazioni che possono influire sull’elaborazione delle dynamic membership rule anche oltre gli oggetti che utilizzano direttamente questo operatore. Con questa ultima novità, ha quindi scelto di non portare l’attuale implementazione in GA e sta lavorando a una soluzione alternativa per coprire gli stessi scenari con un modello più affidabile.
La scadenza richiede attenzione soprattutto nei tenant in cui memberOf, pur essendo rimasto una funzionalità in public preview, è stato utilizzato in processi operativi. Dal 3 novembre 2026, i dynamic membership groups e le dynamic administrative unit che dipendono da questa regola smetteranno di aggiornare la propria membership e rimarranno nell’ultimo stato noto. Per le automatic assignment policies di Entitlement Management, invece, Microsoft indica che le policy interessate verranno messe in quarantena e che l’elaborazione delle assegnazioni si interromperà finché memberOf non verrà rimosso dalla regola.
Il rischio quindi non riguarda soltanto una configurazione che smette di funzionare; infatti, un gruppo la cui membership rimane congelata può continuare a essere utilizzato da Conditional Access, group-based licensing, Teams, SharePoint, applicazioni o altri processi che si affidano a Microsoft Entra ID per determinare utenti e dispositivi interessati. Per questo motivo, se si fa uso di questo operatore, conviene a tutti individuare le configurazioni basate su memberOf con sufficiente anticipo e verificare anche tutte le dipendenze che utilizzano quegli oggetti.
L’operatore memberOf non passerà quindi dalla public preview alla General Availability nella forma attuale. Microsoft terminerà la preview il 3 novembre 2026: entro quella data è necessario individuare e migrare le configurazioni che lo utilizzano per evitare membership o assegnazioni che non riflettono più lo stato reale del tenant.
A cosa serve l’operatore memberOf in Microsoft Entra ID
L’operatore memberOf è stato introdotto in public preview per consentire di costruire una membership dinamica partendo dall’appartenenza ad altri gruppi. Invece di valutare direttamente un attributo dell’utente o del dispositivo, come department, country o deviceOSType, la regola può verificare se l’oggetto appartiene a uno o più gruppi Microsoft Entra. Una regola per gli utenti può avere, ad esempio, questa forma:
user.memberof -any (group.objectId -in ['<groupObjectId>'])
Per i dispositivi il principio è analogo:
device.memberof -any (group.objectId -in ['<groupObjectId>'])
L’operatore può fare riferimento a security group, Microsoft 365 group e gruppi sincronizzati da Active Directory locale. Nel caso dei security group, tuttavia, vengono considerati solamente i membri diretti: l’appartenenza non viene espansa ricorsivamente attraverso eventuali gruppi annidati. Microsoft documenta inoltre altre limitazioni della preview, tra cui un massimo di 50 gruppi sorgente per ogni dynamic group e l’impossibilità di combinare memberOf con altre regole oppure utilizzare un gruppo dinamico basato su memberOf come sorgente di un ulteriore gruppo dello stesso tipo.
Queste caratteristiche hanno reso memberOf interessante in scenari nei quali un gruppo dinamico doveva aggregare la popolazione proveniente da gruppi già esistenti. Allo stesso tempo, Microsoft ha rilevato durante la preview che il suo utilizzo può rallentare l’elaborazione della dynamic membership anche per altri gruppi presenti nello stesso tenant. È questa una delle motivazioni indicate nella documentazione per la chiusura della preview.
L’operatore memberOf è rimasta una funzionalità in public preview. Nella documentazione Microsoft, e anche nella pagina di Configure Rules durante la creazione di gruppi dinamici, viene specificato che la preview non è destinata all’utilizzo in produzione e ne raccomanda l’uso solamente negli ambienti di test. Nei tenant in cui è stata comunque inserita in processi produttivi, la verifica delle dipendenze deve essere effettuata con particolare attenzione.
Dopo il salvataggio della regola, Microsoft Entra elabora la membership del gruppo. Nell’esempio seguente il processo risulta completato con stato Succeeded e il gruppo dinamico contiene i tre utenti presenti nei gruppi sorgente. Questo controllo è particolarmente utile con memberOf, perché la funzione Validate rules non supporta questo operatore.
Quali configurazioni sono interessate
La modifica non riguarda solamente i dynamic group, infatti la documentazione Microsoft aggiornata include tre aree distinte: dynamic membership groups, dynamic administrative unit e automatic assignment policies di Entitlement Management. Il comportamento dopo la scadenza non è descritto esattamente nello stesso modo per tutti e tre gli scenari, dettaglio importante soprattutto durante la fase di assessment.
Configurazione | Utilizzo di memberOf | Dal 3 novembre 2026 | Indicazione Microsoft |
Dynamic membership groups | La membership viene derivata dall’appartenenza a uno o più gruppi sorgente | La membership smette di aggiornarsi e rimane nell’ultimo stato noto | Sostituire la regola con operatori supportati oppure passare ad assigned membership |
Dynamic administrative unit | La membership dinamica dell’administrative unit utilizza una regola contenente memberOf | La membership smette di aggiornarsi e rimane nell’ultimo stato noto | Utilizzare una regola supportata oppure convertire l’administrative unit ad assigned membership e verificare anche lo scope amministrativo |
Entitlement Management automatic assignment policy | La membership rule determina automaticamente chi deve ricevere un access package | La policy viene messa in quarantena; l’elaborazione non aggiunge e non rimuove assegnazioni finché memberOf non viene eliminato | Ricostruire la regola con attributi supportati oppure predisporre un metodo alternativo di assegnazione |
Per i dynamic membership groups la conseguenza può propagarsi a servizi che consumano il gruppo senza essere direttamente coinvolti nella regola. Se, per esempio, un utente viene rimosso dal gruppo sorgente dopo la scadenza, il gruppo dinamico basato su memberOf potrebbe continuare a contenerlo perché la membership non viene più ricalcolata. Lo stesso vale in senso opposto per un nuovo utente che dovrebbe entrare nel gruppo.
Tra i possibili effetti, potremmo trovare una situazione di accesso obsoleto verso Teams e SharePoint, target di Conditional Access non più aggiornati e assegnazioni di licenze basate sui gruppi che non rispecchiano più la popolazione prevista. Questi servizi continuano a utilizzare il gruppo che ricevono da Microsoft Entra ID; il problema risiede nella membership ormai congelata a monte.
Nel caso delle dynamic administrative unit il rischio assume una forma leggermente diversa. Le administrative unit vengono utilizzate per delimitare lo scope amministrativo all’interno di Microsoft Entra ID; una membership non aggiornata può quindi lasciare nello scope oggetti che avrebbero dovuto uscirne oppure impedire che nuovi utenti o dispositivi entrino nello scope previsto. Microsoft raccomanda esplicitamente di verificare, dopo la sostituzione della regola, sia la membership sia lo scope amministrativo risultante.
Per le automatic assignment policies di Entitlement Management la documentazione è ancora più esplicita: dal 3 novembre le policy che contengono memberOf vengono messe in quarantena. La policy rimane presente, ma il relativo assignment processing si interrompe e non vengono aggiunte o rimosse assegnazioni fino alla rimozione di memberOf dalla regola. Le automatic assignment policies che non utilizzano questo operatore non sono interessate dalla modifica.
Cosa significa “ultimo stato noto”
Il termine “ultimo stato noto” può essere facilmente interpretato come una semplice interruzione della modifica della configurazione, mentre l’effetto è diverso. Il gruppo o l’administrative unit non vengono automaticamente eliminati e la regola non scompare: è l’elaborazione dinamica della membership basata su memberOf che non continua a riconciliare il contenuto con i gruppi sorgente.
Supponiamo, per esempio, che il 3 novembre un dynamic group contenga 350 utenti derivati da due security group. Se nei giorni successivi dieci utenti vengono rimossi dai gruppi sorgente e cinque nuovi utenti vengono aggiunti, il gruppo basato su memberOf non deve essere considerato una rappresentazione affidabile della nuova situazione. Le applicazioni e le policy che continuano a utilizzare quel gruppo possono quindi lavorare su una membership ormai obsoleta.
Questo comportamento è particolarmente delicato per le esclusioni o inclusioni di sicurezza. Un gruppo utilizzato come target di una Conditional Access policy, ad esempio, va analizzato anche dal punto di vista delle conseguenze della permanenza o dell’assenza di un’identità nella membership, senza limitare la verifica alla correttezza formale della regola dinamica.
Come individuare memberOf nel tenant
La prima attività da fare dovrebbe essere un inventario delle configurazioni esistenti. L’obiettivo iniziale non è modificare immediatamente le regole, bensì capire dove viene utilizzato memberOf e quali servizi dipendono dagli oggetti individuati. Ci sono indicazioni differenti per gruppi, administrative unit e Entitlement Management, che vedremo nei paragrafi successivi.
Dynamic membership groups
Per i gruppi dinamici si raccomanda di esportare i dynamic membership groups dal Microsoft Entra admin center e individuare le membership rule che contengono memberOf. Nei controlli manuali il punto da cercare è la sintassi avanzata della regola, dove possono comparire espressioni come user.memberof oppure device.memberof.
Microsoft Graph espone la proprietà membershipRule dell’oggetto group, per cui nei tenant con molti gruppi è possibile automatizzare l’inventario recuperando i gruppi e analizzando questa proprietà. È preferibile eseguire inizialmente questa attività in sola lettura e conservare l’output dell’assessment, includendo almeno nome e ID del gruppo, regola corrente e dipendenze conosciute. Microsoft Graph documenta sia membershipRule sia membershipRuleProcessingState tra le proprietà utilizzabili per identificare i gruppi dinamici.
Una volta individuato il gruppo, l’analisi deve proseguire oltre la membership rule ed occorre capire dove quel gruppo viene consumato: assegnazioni applicative, licenze, Conditional Access, Teams, SharePoint, access package o altri processi interni possono trasformare una semplice regola dinamica in una dipendenza molto più ampia.
Dynamic administrative unit
Per le administrative unit si raccomanda l’utilizzo di Microsoft Graph PowerShell per individuare quelle dinamiche la cui membershipRule contiene memberOf. La proprietà è disponibile direttamente sull’oggetto administrative unit insieme a membershipType e membershipRuleProcessingState.
Dal Microsoft Entra admin center è inoltre possibile aprire Entra ID > Roles & admins > Admin units, selezionare l’administrative unit e consultare Membership rules per le unità configurate con membership dinamica. La verifica deve comprendere anche gli eventuali ruoli amministrativi assegnati con scope sull’unità, perché dopo la migrazione è necessario accertarsi che la nuova membership produca lo stesso perimetro amministrativo previsto.
Entitlement Management automatic assignment policies
Infine, per Entitlement Management, Microsoft ha aggiunto alla documentazione una procedura specifica basata su Microsoft Graph PowerShell. Lo script ufficiale, disponibile alla pagina Find automatic assignment policies that use the memberOf attribute recupera le access package assignment policies, seleziona quelle di tipo automatico e cerca memberOf nelle relative membership rule.
Le automatic assignment policies di Microsoft Entra Entitlement Management richiedono una licenza Microsoft Entra ID Governance oppure Microsoft Entra Suite.
Ad ogni modo, l’operazione è descritta come read-only e può generare un file CSV utilizzabile come evidenza dell’assessment. Il controllo è particolarmente utile negli ambienti in cui gli access package sono numerosi, perché l’esistenza di una policy basata su memberOf può non essere evidente partendo solamente dall’elenco degli access package. Per semplicità, vi riporto lo script di seguito:
Connect-MgGraph -Scopes "EntitlementManagement.Read.All"
$outputPath = ".\memberof-auto-assignment-policies.csv"
$columns = 'AccessPackageName','AccessPackageId','CatalogId','PolicyName','PolicyId','MembershipRule'
$results = New-Object System.Collections.Generic.List[object]
$uri = 'https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentPolicies?$expand=accessPackage&$top=50'
while ($uri) {
$page = Invoke-MgGraphRequest -Method GET -Uri $uri
foreach ($policy in $page.value) {
# Automatic assignment policies are the policies that have automaticRequestSettings.
if (-not $policy.automaticRequestSettings) { continue }
foreach ($target in @($policy.specificAllowedTargets)) {
if ([string]$target.'@odata.type' -notlike '*attributeRuleMembers*') { continue }
$rule = [string]$target.membershipRule
if ($rule -match '(?i)memberof') {
$results.Add([pscustomobject]@{
AccessPackageName = $policy.accessPackage.displayName
AccessPackageId = $policy.accessPackage.id
CatalogId = $policy.accessPackage.catalogId
PolicyName = $policy.displayName
PolicyId = $policy.id
MembershipRule = $rule
})
}
}
}
$uri = $page.'@odata.nextLink'
}
if ($results.Count -eq 0) {
# Write a headings-only file so that there's always a report of the scan result.
$columns -join ',' | Set-Content -Path $outputPath -Encoding UTF8
Write-Output "No automatic assignment policies use the memberOf attribute. Created an empty report at $outputPath."
} else {
$sorted = $results | Sort-Object AccessPackageName
$sorted | Select-Object $columns |
Export-Csv -Path $outputPath -NoTypeInformation -Encoding UTF8
Write-Output "Found $($results.Count) automatic assignment policies that use the memberOf attribute. Created a report at $outputPath."
$sorted | Format-Table AccessPackageName, PolicyName, MembershipRule
}
Prima di modificare una regola, registrate anche le dipendenze dell’oggetto interessato. Per un dynamic group non è sufficiente sapere che contiene memberOf: occorre verificare se viene utilizzato per Conditional Access, licensing, applicazioni, Teams, SharePoint o altri processi. Questo consente di confrontare il comportamento prima e dopo la migrazione.
Come sostituire memberOf
Microsoft non ha annunciato, al momento della verifica di questo articolo, un sostituto diretto che possa essere applicato automaticamente a tutte le configurazioni basate su memberOf. La documentazione, alla pagina Migrate before the preview ends, indica che continueranno a sviluppare una soluzione alternativa pensata per coprire questi scenari con requisiti migliori di scalabilità e affidabilità, ma chiede comunque ai clienti di migrare le configurazioni esistenti prima del 3 novembre 2026.
Per un dynamic membership group, la prima possibilità consiste nel riscrivere la membership attraverso proprietà supportate dell’utente o del dispositivo. Se il gruppo sorgente rappresentava, per esempio, un reparto aziendale già identificabile tramite department, potrebbe essere possibile modellare direttamente la condizione con una regola basata su tale attributo. Lo stesso principio può essere applicato ad attributi come paese, tipo di utente o extension attribute, purché il dato utilizzato sia affidabile e venga mantenuto correttamente nel lifecycle dell’identità.
La migrazione non deve però partire dall’idea che ogni gruppo basato su memberOf abbia necessariamente un equivalente basato su attributi. In alcuni ambienti il gruppo sorgente può rappresentare una decisione organizzativa o un processo autorizzativo che non esiste come proprietà dell’utente. In questi casi Microsoft indica come alternativa la conversione ad assigned membership oppure, per Entitlement Management, la pianificazione di un diverso metodo di assegnazione.
Per le regole che possono essere ricostruite con attributi, conviene evitare di introdurre condizioni più complesse del necessario. Microsoft raccomanda, per le dynamic membership rules, di privilegiare operatori efficienti come -eq, -startsWith, -endsWith e -in quando esprimono correttamente la condizione richiesta, riducendo invece l’uso di -match, -contains e combinazioni ridondanti che possono aumentare il tempo di elaborazione.
Non esiste necessariamente una conversione uno-a-uno tra una regola basata su memberOf e una regola basata sugli attributi. Prima di scegliere la nuova logica occorre ricostruire il motivo per cui i gruppi sorgente rappresentavano la popolazione desiderata e verificare che gli attributi alternativi descrivano realmente lo stesso insieme di utenti o dispositivi.
Come verificare la migrazione
La sostituzione della regola dovrebbe essere trattata come una modifica del modello di accesso e non come una semplice operazione sintattica. Prima di rimuovere memberOf, è utile acquisire la membership corrente e utilizzarla come riferimento, sapendo però che anche la configurazione precedente presenta alcune limitazioni documentate. Dopo l’applicazione della nuova regola bisogna verificare la popolazione risultante e le dipendenze che consumano il gruppo o l’administrative unit.
Area da verificare | Controllo dopo la migrazione | Perché è necessario |
Dynamic group | Confrontare membership prevista e membership risultante, includendo utenti o dispositivi che devono entrare e uscire | Una regola formalmente valida può produrre una popolazione diversa da quella precedente |
Conditional Access | Verificare inclusioni ed esclusioni che utilizzano il gruppo migrato | Una differenza nella membership modifica direttamente il target della policy |
Group-based licensing | Controllare assegnazione e rimozione delle licenze per utenti campione | La nuova membership può modificare gli utenti coperti dal licensing |
Teams, SharePoint e applicazioni | Validare l’accesso con utenti rappresentativi | Il gruppo può essere utilizzato come livello di autorizzazione a valle |
Dynamic administrative unit | Confrontare membri e scope dei ruoli amministrativi | La membership determina il perimetro su cui operano gli amministratori scoped |
Entitlement Management | Controllare le access package assignments dopo la sostituzione della regola |
|
Per i dynamic group è inoltre opportuno concedere al servizio il tempo necessario per ricalcolare la membership prima di considerare concluso il test. La popolazione iniziale o l’elaborazione dopo una modifica alla regola può richiedere fino a 24 ore, in funzione delle dimensioni e delle caratteristiche del tenant. Lo stato di elaborazione e la data dell’ultimo aggiornamento possono essere controllati nella pagina di overview del gruppo.
Il rollout dovrebbe quindi iniziare dagli oggetti meno critici oppure da una copia controllata della logica esistente, quando lo scenario lo consente. Per i gruppi utilizzati in Conditional Access, nell’assegnazione di licenze o per l’accesso a risorse aziendali, il confronto tra vecchia e nuova membership va completato prima di spostare definitivamente le dipendenze.
Conclusioni
La fine della public preview di memberOf non comporta semplicemente la scomparsa di una funzionalità dal portale Microsoft Entra. Il rischio principale deriva dal fatto che le configurazioni rimaste attive possono continuare a esistere pur senza rappresentare più correttamente le variazioni di membership che avvengono nel tenant.
La scadenza del 3 novembre 2026 lascia il tempo per eseguire un assessment ordinato, ma rende poco prudente rimandare l’inventario. Come abbiamo visto nell’articolo, la prima attività consiste nell’individuare dynamic membership groups, dynamic administrative unit e automatic assignment policies che contengono memberOf; successivamente va ricostruito il motivo per cui la regola era stata utilizzata e, soprattutto, quali servizi dipendono dall’oggetto (ecco perché documentare è importante!).
Dove gli stessi criteri possono essere rappresentati attraverso attributi affidabili, la regola può essere ricostruita utilizzando gli operatori supportati. Negli scenari in cui la membership dei gruppi sorgente esprime una logica che non può essere tradotta in attributi, sarà invece necessario valutare assigned membership o un diverso processo di assegnazione. Microsoft ha comunque dichiarato che continuerà a lavorare per consegnarci una una soluzione alternativa per gli scenari coperti da memberOf, ma la documentazione attuale ci suggerisce comunque di completare la migrazione delle configurazioni esistenti prima della fine della preview.
