Video summary

Microsoft Entra memberOf Retirement: What Admins Must Do

Main summary

Key takeaways

Technology

Entra Chat: Groups changes + what admins must plan for (memberOf retirement)

The episode focuses on group behavior changes in Microsoft Entra (Azure AD) and what administrators should do before upcoming deprecations.

Main topic: retiring memberOf for dynamic groups

Microsoft is retiring the memberOf attribute for dynamic groups.

  • It was previously used/available in public preview, and later became available in production.
  • Deprecation behavior:
    • It will be silently deprecated.
    • Admins may not receive obvious errors, but dynamic groups will stop processing memberOf after the deadline (roughly “around November” / “in ~3 months” per discussion).
  • Key risk:
    • Groups may appear “partly working” because existing members may remain.
    • However, new users may no longer be added, causing confusion about why membership behavior changed.

Recommended admin actions / testing

A community-driven PR/test was mentioned:

  • It scans for dynamic groups using memberOf.
  • It reports which groups need remediation.

Why proactive scanning is recommended: the groups identified “can be forgotten for a long time,” so finding them early helps prevent surprises.

Workarounds if you can’t replace memberOf

If you can’t swap memberOf to other attributes immediately:

  1. Use other user/device attributes for dynamic group rules when possible (preferred).
  2. If no suitable attribute exists:
    • Use PowerShell automation or sync-based attribute stamping.
    • Example approach: use Entra Connect sync rules to set user attributes based on on-prem AD group membership.

Caution: editing and maintaining sync rule logic can be complex and risky if you don’t fully understand the implications.

Dynamic groups performance/behavior considerations (why memberOf got removed)

Speakers described dynamic groups as interesting but sometimes plagued with quirks/performance issues, especially at scale—for example, in tenants where high churn adds/removes thousands of users in a day.

Additional complexity can come from:

  • Rule complexity, including:
    • maintaining KQL-like query logic
    • version changes that affect which users/devices are included
  • Operational hygiene, such as rules not being updated as clients/users evolve over time

Nested groups: limitations across Entra features (GSA, apps, licensing, etc.)

The discussion highlights that many Entra admin scenarios are not fully compatible with nested groups.

What goes wrong

  • Many services treat groups as flat / top-level only, which can cause partial application when nesting is involved.
  • The UI often doesn’t warn, so failures may go unnoticed.

Examples mentioned

  • Global Secure Access (GSA):
    • Nested group membership may apply only to the first level of users.
  • Licensing:
    • Nested membership can result in missing entitlements for nested members when assigning licenses via groups.
  • Conditional Access:
    • Contrasts with nested group support in other services (conditional access may handle nested groups differently).

Mitigation

  • Avoid nested groups; move toward a flat group model.
  • A newer option was mentioned:
    • Create groups with nesting disabled via a “disable nesting” property.
    • Documentation may be limited, but the goal is to prevent future policies from silently breaking.

Sensitivity labels for groups (new governance control)

A newer capability was mentioned:

  • Sensitivity labels for M365 groups (earlier)
  • Beta for security groups (now)

Purpose

  • Apply governance settings such as allow guests in group vs. not.
  • Enforce group behavior via policy.

Notes

  • It’s currently beta.
  • At least one setting is allowed today.
  • Guest handling may not be limited to new membership only—policy enforcement could impact existing membership behavior (wording suggests guests may not “go away” immediately depending on the scenario).

Agents and “dynamic group” inclusion risk

A key operational detail: dynamic groups can include “agent users” (treated as user objects in Entra).

Why it matters

  • If admins use dynamic groups for security/privileged settings or licensing, an unexpected agent user could match the rule and be added.
  • This is described as a ticking bomb risk, especially in tenants where developers/tooling create many agent users.

Security guidance: treat dynamic group rules like a risk surface

A referenced “Maester test” approach classifies dynamic group risk:

  • Determine whether dynamic group attributes are:
    • User-influenced → high risk
    • User-not-influenced → lower risk

Example:

  • Attributes like city can be changed via HR/user processes, meaning group-based security policies may be unsafe if users can manipulate attributes.

Cloud Identity Summit: what the event is and key logistics

The episode also promotes Cloud Identity Summit.

What it is

  • An in-person community event focused on cloud identity topics across management and security tracks.
  • Historically:
    • Originally online due to COVID
    • Later hybrid
    • Now on-site again
  • Emphasis:
    • Attendees/speakers are positioned as approachable
    • Focus is on community discussion, not heavy marketing sessions

Logistics

  • Date: November 3rd
  • Location: Frankfurt
  • Admission: free (mentioned briefly)

The discussion also mentions passkey-related content and Maester sessions tied to future events.

Main speakers / sources

  • Eric Budro — Chief Identity Architect (listed as “Temporary” in subtitles)
  • Gregor — Azure architect from ADSO (speaker name appears as Gregor/Rmling in subtitles)
  • Rene Basil — M365 specialist; Microsoft MVP for M365
  • Thomas — referenced as an organizer/partner (not present due to appointments)

Original video