3.2 Groups & Custom Security Attributes

Groups as the unit of scale

Managing access user-by-user does not scale. Microsoft Entra ID groups are how identity administrators assign applications, Conditional Access scope, licenses (group-based licensing), Microsoft 365 collaboration resources, and many governance packages. SC-300 tests whether you can pick the right group type, the right membership model, and—when built-in attributes are not enough—custom security attributes for richer targeting.

Security groups versus Microsoft 365 groups

Exam bias: if the scenario is only about granting access to an enterprise application or scoping Conditional Access, choose a security group unless the scenario explicitly needs Microsoft 365 collaboration artifacts. If the scenario emphasizes Team / shared site / group mailbox, choose a Microsoft 365 group.

Microsoft 365 groups can be used for some access scenarios, but security groups remain the cleaner mental model for pure authorization constructs on the exam.

Assigned versus dynamic membership

Assigned membership

• Administrators or group owners add and remove members explicitly.
• Predictable and simple for small, stable populations (break-glass exclusion group, VIP CA exclusion with strict change control, project app pilots).
• Does not auto-correct when people change department or leave a project—governance (access reviews) becomes important.

Dynamic user membership

• You write a membership rule based on user attributes.
• Entra continuously evaluates the rule and adds/removes users as attributes change.
• Ideal for “all users in Department equals Finance,” “all members with jobTitle contains Intern,” or “userType equals Guest” patterns.

Dynamic device membership

• Rules evaluate device attributes (for example OS type, displayName patterns, device ownership).
• Used for device-targeted access and management patterns.
• Microsoft 365 groups do not support dynamic device membership—that is a frequent distractor.

Dynamic membership rules — concepts you must know

Dynamic rules use a simple expression language. Conceptual building blocks:

• Properties: department, jobTitle, companyName, usageLocation, userType, extension attributes, and more.
• Operators: equals, notEquals, startsWith, endsWith, contains, match (regex-style patterns in supported forms), and logical -and / -or.
• Direct reports rule patterns and other advanced constructions appear in docs; for SC-300, focus on attribute equality/contains and logical combination.
• Processing: rule changes trigger re-evaluation; large tenants can take time to recompute membership.

Example conceptual rules (illustrative):

• (user.department -eq "Finance") — all Finance users.
• (user.department -eq "Finance") -and (user.usageLocation -eq "US") — Finance in the United States only.
• (user.userType -eq "Guest") — all guest users (often for CA or governance targeting).

Design tips the exam rewards:

• Prefer stable authoritative attributes (HR-synced department) over free-text fields users can change themselves.
• Avoid overlapping dynamic groups that fight each other for mutually exclusive license SKUs without a clear design.
• Remember that dynamic membership requires appropriate Entra ID licensing (historically Entra ID P1 for dynamic groups)—know that dynamic groups are a premium capability in enterprise designs.

Nested groups and limits awareness

Nesting means putting a group inside another group so membership is transitive for some evaluation engines.

Key awareness points for SC-300 (not a deep combinatorial math exercise):

• Security group nesting is commonly used in on-premises AD thinking, but cloud resource assignment engines do not all honor nesting the same way.
• Group-based licensing does not support nested groups for license assignment—the user must be a direct member of the licensed group for licenses to apply via that feature.
• Some application assignments and Conditional Access evaluations expect direct membership depending on configuration; when in doubt, exam items often steer you to direct membership for licensing and critical access.
• Deep nesting increases troubleshooting difficulty (“why does this user have access?”).

Practical rule: use nesting sparingly in cloud-first designs; prefer dynamic rules or clear single-purpose groups for licensing and CA.

Group ownership, visibility, and self-service

Beyond type and membership:

• Owners can manage membership (for assigned groups) without being Global Administrators—aligns with least privilege.
• Visibility / privacy settings on Microsoft 365 groups affect discovery and guest access patterns.
• Access reviews (later domain) can target group membership to clean up assigned groups over time.
• PIM for Groups can make membership eligible rather than permanent for privileged groups—advanced governance, but know groups are a PIM target later.

Custom security attributes

Custom security attributes in Microsoft Entra ID let administrators define tenant-specific attributes beyond the built-in user schema. They are designed for governed, filterable metadata used in authorization and operational scenarios.

Building blocks

Why not just use department or extensionAttribute1?

Built-in attributes and on-premises extension attributes are often already overloaded by HR and Exchange. Custom security attributes provide:

• Separation of concerns — security/governance data separate from mail nickname or department.
• Delegated administration — attribute sets can be managed by specific roles without granting full user admin rights.
• Governed catalog — definitions are explicit, typed, and auditable.
• Authorization scenarios — applications and policies can make decisions based on attributes such as Clearance=Secret, ContractType=VendorManaged, or DataBoundary=EU without inventing shadow databases.

Lifecycle of using custom security attributes

1. Plan attribute sets (for example ProjectGovernance, Clearance, CostCenterSecurity).
2. Define attributes with types and allowed values where appropriate.
3. Assign values to users (or other objects) as part of joiner/mover processes.
4. Consume in apps, administrative unit filters, custom claims/apps, automation, or reporting.
5. Audit and review who can assign sensitive attributes—attribute assignment is itself a privileged operation class.

Custom security attributes are not a replacement for groups. Groups still express collections for assignment. Attributes express descriptive facts that many systems can filter on. Often you combine both: a dynamic group rule cannot always express every custom-security-attribute scenario the same way apps can via Graph filters—know them as complementary tools.

Governance and authorization scenarios (exam framing)

Expect scenario questions like:

• “Finance users should automatically get the Finance apps group” → dynamic security group on department.
• “We need a Team with SharePoint for Project Orion” → Microsoft 365 group.
• “Only direct members should receive E5 via group-based licensing” → no nested groups for that license group.
• “We must tag users with a regulated clearance level managed by the security team only” → custom security attribute set with delegated permissions, not a free-text department field.
• “Exclude a small set of emergency accounts from a CA policy” → small assigned security group, tightly controlled.

Common traps

• Using a Microsoft 365 group when only a security principal is required (or vice versa when collaboration is required).
• Expecting dynamic device membership on Microsoft 365 groups.
• Assuming nested groups receive group-based licenses.
• Writing dynamic rules on non-authoritative attributes users can edit arbitrarily.
• Treating custom security attributes as ungoverned notes fields—definitions and assignment rights matter.

Master group type, membership model, nesting limits, and custom security attributes as a single toolkit for scalable access design on SC-300.