Dynamic Groups: Member of group
Would be good to have the possibility to use membership in other groups as a condition in a dynamic group membership rule.
(user.objectId -memberOf group.objectId)
(user.objectId -notMemberOf group.ObjectId)
Use case 1 - Group Based Licensing.
If the user is member of a group that gives them a E5 license, don't let them be member of a group that gives them E3.
Use case 2 - Exceptions
All users should have a MDM policy applied, accept those of a specific group.
Thank you for your feedback! The feature team is aware of this suggestion and will keep it under consideration. There are technical challenges to overcome in order to make this happen. Please keep the votes coming if this feature matters to you.
Cory Crawford commented
Why are you essentially telling your customers to F off when they are requesting a feature that will improve the lives of just about every AAD administrator out there?
Where is our update?
Jon Sauter commented
@Nick Troyer: The feature you linked to isn't actually what's being requested here. That feature is about nesting groups inside of M365 Groups. This feature request is about using group membership in Group A as a criteria for including or excluding a user from a Dynamic Group B. Hopefully the Azure AD Team understands the ask.
This would be useful for including because you may not want to include everyone from a group by nesting but include people who are members of a group and meet other criteria.
For us it's even more important for excluding members who may already be in a mutually exclusive group.
Nick Troyer commented
Good news - It's actually on their radar: https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=&searchterms=83113
Bad news - Scheduled release is 2022.
Ludwig Eriksson commented
Any updates on this? We need it asap. Is there a plan for implementation?
Jörg Wiesemann commented
we need this feature, where is it?
Steve Shipway commented
Or just implement the ability to have nested groups and this becomes redundant. Really, nested groups is a basic capability but AAD seems to lack it.
Sebastian Lehmann commented
We want to have an update too.
We need this feature also. Its really need to have the attribute memberOf in dynamic groups.
Alex Burgess commented
Seriously, can we get an update on this please!?
This is a much needed feature which has been on request since 2017 and under reveiw for NEARLY 3 YEARS!!
This is still not available. :(
Hernan Lopez commented
We have found a way to overcome this temporarily. We run a scheduled task which gets all group memberships on a given user, and adds each group name as a string on an extendedattribute.
After this we extended the AD sync to include this extendedattribute in the sync, so user has this extendedattribute available on object.
We then run the dynamic group membership rules based on lookup of substring in the extendedattribute.
It has some issues, substrings must be unique, otherwise you would get a much bigger userscope.
Groups must be unique, and the lookup must address the entire group name.
Not ideal, but works
Still under review 3 years later . what a joke MS are .
This is much needed option to create dynamic group based on some org structure.
I also have a group of accounts that don't have MFA enabled, mainly because they are service accounts. I'd like to reuse that group to create a dynamic security group for all MFA enabled Accounts.
Richard Cornell commented
I have a group of accounts that don't have MFA enabled, mainly because they are service accounts. I'd like to reuse that group to create a dynamic group when deciding who has SSPR i.e. all users except those who don't have MFA.
Why is this not a thing? Really.
Really need this. I have users who are part of several groups. I want to automate teams memberships based on the users onprem AD group membership.
CHAUSSADE REMY commented
@Azure AD Team :
News ?? since 2018/04/10 ?
Joe Eaton commented
We need this feature too...
Chad Gross commented
Definitely surprised this isn't currently possible - especially considering back in the early days we had IFMEMBER.exe to use in login scripts, and have been able to target AD GPO preferences by security group membership since Server 2008, and both methods allowed for complex analysis of group membership for proper targeting (Member of A and member of B but not member of C) Admins have been basing policies off of complex group membership for 20 years, and now it's been under review for almost 4 years.