Entra ID Dynamic Groups - MemberOf Deprecation

[psynegy]

Just a heads up if you haven't seen the announcement - MS are dropping the memberOf rule operator for dynamic groups in November of this year.

 

Quite frustrating that they've not found a way to properly support nested groups across the suite (application assignment for example), but feel the need to take away the only thing that made it tolerable.

[pete]

This breaks our device licensing group (multiple school in the same tenant, but the UI only allows you to specify one group) and our "People allowed to create groups in M365" group.

 

The latter is annoying (I can add a group per school if I really have to), the former is a pain in the backside with 3 months notice.

[psydii]

Oh for goodness sake. This is so stupid of them.

 

The cloud is built to serve Microsoft requirements, not those of their customers.  Fundamental Business (and education) requirements have not actually changed since the likes of ITU in the 1980's  and then Sun, Novell and Microsoft  in the 1990's developed a hierarchical directory services. Nested groups (and the directory tree) allow for mapping the IT administrative model to the actual business structure and the practical foundation of role based access control.  But it's computationally expensive when you scale to 10's of millions of users. 

 

My. Heart. Bleeds. Poor Microsoft needing to worry about a few seconds of additional compute per *customer* per day.  

 

The introduction of that capability greatly simplified the move to cloud for us.  I'm going to have to rebuild a whole load of things now - quite possibly going back on prem for some of it. 

 

Genuinely though, given that complex group membership is a multidimensional array, I wonder if there's actually GPU based optimisation that they could make, and the cost would just vanish inside their gpu compute spend when seen alongside their AI efforts.

[psydii]

Poking around it looks to me that they we can expect to see them allow nest group for apps. licences and 365 Groups/Teams (removing the final limitations I'm grumbling about).... or they are going to re-introduce the memberof capability for dynamic groups but now requiring an Entra ID P3 licence  for $$$ 

 

I fear it will be the latter.

[psynegy]

Where have you seen that? I haven't found anything that says they plan to do anything other than remove the functionality...

[Olliedawg]

On 06/08/2026 at 10:34, pete said:

This breaks our device licensing group (multiple school in the same tenant, but the UI only allows you to specify one group) and our "People allowed to create groups in M365" group.

 

The latter is annoying (I can add a group per school if I really have to), the former is a pain in the backside with 3 months notice.

 

That's also what it will break for us.

[psydii]

1 hour ago, psynegy said:

Where have you seen that? I haven't found anything that says they plan to do anything other than remove the functionality...

I’m a skeptic of “Past performance is no indicator of future behaviour” when it comes to decisions Microsoft make.  
 

the language used about the retirement says they are still developing solutions to the problem this feature eliminatd.  This has happened before and in those cases  where they did indeed have something in the works, they followed one of two paths: “remove the final restrictions on the feature that should have already had this functionality” or “relaunch this very same feature under a new name and charge for it”

[foofighterjim]

Just to be clear, from what I understand (and please correct me if I am wrong), they are only removing the ability to create dynamic groups based of the "member of" other groups. This does not prevent you from nesting groups, for example you could have a dynamic group for users of school x and another for users of school y, they could then be nested together in a separate "assigned" group for all users, you could even skip this requirement by making the all users group a dynamic group with the same query used for the aforementioned groups. We used nested groups for everything from Configuration Profiles to App Assignments and don't have any issues with deployments.

 

It could just be my use case, but I really don't see this as much of an issue.

[psynegy]

3 hours ago, psydii said:

I’m a skeptic of “Past performance is no indicator of future behaviour” when it comes to decisions Microsoft make.  
 

the language used about the retirement says they are still developing solutions to the problem this feature eliminatd.  This has happened before and in those cases  where they did indeed have something in the works, they followed one of two paths: “remove the final restrictions on the feature that should have already had this functionality” or “relaunch this very same feature under a new name and charge for it”

They've only given themselves 3 months to do it though - in which time customers will be forced find other ways to satisfy this requirement. If in October they go "it's all solved, for a fee", but all their customers have already found other workarounds, that probably wouldn't be the smartest business decision ever.

 

It was interesting in some of what I was reading that a number of people were actively against the concept of nested groups for security reasons(?)... Not sure I totally understand the reasoning behind that personally, but there we go.

 

"Adding support for nested groups is one of the #1 requests from many orgs. Hopefully they never allow it."

 

Seems very strange to me!

 

38 minutes ago, foofighterjim said:

Just to be clear, from what I understand (and please correct me if I am wrong), they are only removing the ability to create dynamic groups based of the "member of" other groups. This does not prevent you from nesting groups, for example you could have a dynamic group for users of school x and another for users of school y, they could then be nested together in a separate "assigned" group for all users, you could even skip this requirement by making the all users group a dynamic group with the same query used for the aforementioned groups. We used nested groups for everything from Configuration Profiles to App Assignments and don't have any issues with deployments.

 

It could just be my use case, but I really don't see this as much of an issue.

That is correct - there are some places in Entra that do not support that method of nesting groups, like App Registration Assignments, where the members of nested groups are ignored.

 

 

For us, it's actually PaperCut that's the issue - we import groups from Entra ID, but it does not retrieve members of nested groups, so to satisfy a setting targeting KS3, we flatten Y7, Y8, Y9 into a "KS3 - Dynamic" group using memberof feature. It's just a way of making administration far easier. You are a Y7, therefore are in KS3, therefore are a Student, therefore are part of the School - why would we want to manage membership of each level separately when it's so much simpler this way round.

[mavhc]

I made all my entra groups using a combination of school/site/job title, and staff vs student

 

(job = "teacher" or job = "ta" or job ="head") and (site = "site1") etc

[psydii]

On 07/08/2026 at 16:09, mavhc said:

I made all my entra groups using a combination of school/site/job title, and staff vs student

 

(job = "teacher" or job = "ta" or job ="head") and (site = "site1") etc

Our nested groups reflect the org chart.  Or more accurately, the last accurate org chart created was actually built from the our role groups structure! The challenge is for some "departments" the 2ic is in "middle management", and for others they are not, in some departments the slt with responsibility wants to be a full part of Team with access to everything and all the departmental emails etc, and others do not.  So rules based on standard fields don't work for us, where nested groups do. And to be fair for departmental groups/teams (in general) we never did use dynamic groups because it was hard for helpdesk to parse since the rules only exposed group guids rather than human readable names. But there are a few places where it was quicker to use than writing a bespoke script to map role group membership to team membership. 

In a well managed system, nested groups improve security. They are the foundation of RBAC in Windows and SE-Linux like security systems: 

"The use of RBAC to manage user privileges (computer permissions) within a single system or application is widely accepted as a best practice. A 2010 report prepared for NIST by the Research Triangle Institute analyzed the economic value of RBAC for enterprises and estimated benefits per employee from reduced employee downtime, more efficient provisioning, and more efficient access control policy administration" https://en.wikipedia.org/wiki/Role-based_access_control#:~:text=The use of,control policy administration

 

They build off the basic admim/security principal that you don't assign rights to a user you assign rights to a group.  You constrain the modification of "ACLs" or their equivalent to contain references to groups, and only groups created for the purpose of providing access to that resource e.g. resource_SharePoint_SiteName_FolderName_Owner/Editor/Reviewer.* The only members of that group are role groups that match your **actual** org structure e.g. where SiteName would typically be that of a working party / team / cross functional group etc etc. You'd have a number of  rolegroup_Dept/Team/WorkingPartyName_Leader  groups  that are say,  grouped together in other role groups, say, role_HeadsOfDepartment_members,  and that role is a member of various resource groups granting them access to say, certain minutes, budgets, teams, distribution groups, control, printers, and event platforms.

 

Management of them is pretty easy provided you have robust controls on group management - key is being able to respond to requests very swiftly, while also managing lifecycle.  We provision via a script which emails details into the service desk, from where  owner of the ticket creates/updates the Configuration Items in the CMDB. The ticket/CI reference is written back out to the group and the group guid is recorded in the CMDB.  Reminders are set for groups that have limited life expectancy (e.g. project/working parties or things that occur annually but with a changing cast) - this also actually ties nicely into data minimisation principals of GDPR, and allowing us to know who has access to what.  People are discouraged from sharing files with individuals or handfuls of individuals via the sharing interface. Of course they still do****, but those that follow the correct pattern and have resource groups (or dedicated teams if appropriate) are much happier because "it just works" and they don't have to remember to add or remove new people as staffing changes around the org.

 

On the IT admin side - licence and software deployment and Just-in-Time/PIM are particular areas where this structure should be super powerful. (using Defender sensitive entity tags on role groups that are in resource groups are used for PIM so any changes get flagged for review by the security "team"**)

 

* 365 groups actually implement this with the concept of "owner" "member" and "guest", and SharePoint and Exchange have always(***) supported ad nested groups.

** In small-ish environments this would likely be the same tech who added the user to the role group - but seeing that change flagged in defender gives them pause for thought - did they just over-privilege that individual? It also  alerts other admins - many eyes on a change reduces the chance of mistakes going unnoticed.

*** Well since at least 2007 anyway
**** I actually caught someone recreating the role/resource group concept  in SharePoint the other day. They'd used Claude to solve a collaboration issue, and Claude basically had them re-implement resource groups inside a SharePoint site they managed. I only found out when I declined a request to allow Claude access to our 365 tenant, and as I did so the user appeared at my door and said "Claude told me you'd say no. Don't worry about it, we used PowerShell to get it done, its pretty cool, but could you just help troubleshoot the last bit?"

[mavhc]

Yeah, need to define roles/job titles precisely, and you end up using groups as well when someone has multiple roles, but the problem of not being able to use OU hierarchy for certain things is the main cause of the entire mess, and probably why they got rid of it for Entra