Domain 1 of 5 · Chapter 1 of 3

Entra Users and Groups

Users: members, guests, and where accounts come from

Every person and workload that touches your tenant starts as a user object in Microsoft Entra ID[1], and the first thing the exam wants you to know is what that object can do before anyone hands it a role. That baseline is fixed by how the account got into the directory, not by a setting you flip later, and the same origin-decides-the-rules logic carries through groups, licensing, and self-service password reset.

Microsoft Entra ID is the cloud directory behind every Azure subscription (it was renamed from Azure Active Directory / Azure AD; you may still see the old name in older docs and PowerShell module names, but Entra ID is the current name and the only one used below). Everything an administrator grants access to starts with a user object representing a person or a workload that signs in.

Two user types, fixed by origin

A user's type is set by where the account comes from, and it determines the user's baseline directory permissions before any role is added. The figure below contrasts the two types along the three dimensions the exam tests: where the account originates, who owns its credential, and what it can do by default.

  • A member user is native to your tenant. It is either created directly in the cloud, or synced from an on-premises Active Directory by Microsoft Entra Connect. Members can read most directory information and, by default, register applications, create groups, and invite guests[2].
  • A guest user is brought in from another directory through B2B collaboration[3]. A guest signs in with their own home credentials (you never manage their password) and carries a user principal name (UPN) in the form alice_contoso.com#EXT#@yourtenant.onmicrosoft.com. Guests have restricted permissions[2]: they can manage their own profile and read limited directory data, but cannot enumerate the full list of users or groups.

The common misread is that you change what a guest can do by editing the user type. You do not: the type is a property of how the account entered the directory. You expand any user's reach by assigning roles[2] and, separately, you can tighten the default permissions for all members or all guests in the directory's user settings.

Creating and editing users

Create a cloud member user in the portal under Identity > Users > All users > New user > Create new user, or with the CLI. The minimum required properties are the user principal name and a display name:

az ad user create \
  --display-name "Alice Researcher" \
  --user-principal-name alice@contoso.com \
  --password '<initial-password>'

Profile attributes such as Job title, Department, Usage location, and Manager are editable on the user blade after creation. Two attributes carry weight beyond display: Usage location is required before most licenses can be assigned (covered in the licensing section), and attributes like Department are exactly what a dynamic membership rule reads to place the user into groups automatically (covered next).

User objectMembernative to your tenantOriginCloud-created or synced (Entra Connect)CredentialYou manage the passwordDefault permissionsRead most directory data;create groups, register appsGuestB2B from another directoryOriginInvited via B2B collaborationCredentialHome credentials (#EXT# UPN)Default permissionsRestricted; cannot enumerateall users or groups
User type is fixed by origin: a member is native to the tenant, a guest is invited via B2B. Origin sets the credential owner and default permissions.

Groups: type decides members, membership decides how

A group is a container you grant access to once, and every group is defined by answering two independent questions: what can be inside it (group type) and how members get there (membership type). Building on the users you can now create, the right group for a scenario and the membership mechanism that keeps it accurate both fall out of those two answers.

Question 1: group type

There are two group types you manage in the Entra admin center, and the type fixes which objects may be members:

  • A Security group manages access to shared resources, roles, and applications. Its members can be users, devices, service principals, and other groups[4] (nesting). When you nest a security group inside another, only the direct members of the parent gain access to the parent's resources.
  • A Microsoft 365 group provides collaboration (a shared mailbox, calendar, and SharePoint site) and its members can be users only[4] (no devices or service principals). People outside your organization can be added as members.

The practical test: need to gate a resource, assign a role, or attach licenses? Security group. Need a team workspace? Microsoft 365 group.

Question 2: membership type

Membership type controls how the member list is maintained, independent of the group type above:

  • Assigned: you add and remove each member by hand. This is the only membership type whose list a group owner can edit[2]; a group owner cannot change the members of a dynamic group because those are governed by a rule, not by people.
  • Dynamic User: an attribute rule (for example user.department -eq "Sales") automatically adds and removes users as their attributes change.
  • Dynamic Device: the same idea for device objects, using device attributes.

Two constraints are heavily tested. First, a single group is dynamic for users OR devices, but not both: you cannot mix[4], and a device rule may only reference device attributes. Second, dynamic membership is a premium feature: it requires Microsoft Entra ID P1[5] for every user in scope, and editing a dynamic rule requires the Groups Administrator, Intune Administrator, or User Administrator role.

A few groups cannot be managed in the Entra admin center at all: groups synced from on-premises AD[4] must be managed on-premises, and distribution lists and mail-enabled security groups are managed in Exchange or the Microsoft 365 admin center.

Need a shared mailboxor team site?YesNoMicrosoft 365 groupmembers: users onlySecurity groupusers, devices, service principals, groupsMembership should trackan attribute?NoYes (P1)Assignedowner can edit membersDynamic (User OR Device)rule-driven, not both
Choosing a group: type (purpose) first, then membership (how members are maintained). Dynamic membership requires Entra ID P1.

Licenses and self-service password reset

Two administrator chores live here, licensing users at scale and letting them recover their own passwords, and both have a premium-vs-free line the exam likes to probe. Building on the users and groups you now manage, each chore turns on whether the tenant carries the premium tier.

Assigning licenses

Paid Microsoft cloud services (Microsoft 365, Enterprise Mobility + Security, Entra ID P1/P2) consume one license per user. You assign a license one of two ways:

  • Direct assignment: attach the product license to the individual user.
  • Group-based licensing: attach the license to a security group, and Entra ID automatically licenses every member, removing the license when a member leaves the group[6]. This is the scaling pattern: pair it with a dynamic group and licensing tracks org structure with no scripting.

Two facts are mandatory. First, the user's Usage location must be set before a license can be assigned: Microsoft licenses are subject to regional availability. Second, group-based licensing requires Microsoft Entra ID P1[6] (or a qualifying Microsoft 365 / Office 365 plan) for every user who benefits, and you must hold at least one license for each unique member of a licensed group.

There is one current-events catch the exam reflects: since September 1, 2024, the Microsoft Entra admin center and the Azure portal no longer expose license assignment in their UI[6]. License assignment for both users and groups is now done in the Microsoft 365 admin center, or programmatically via Microsoft Graph and PowerShell: the API path was never removed.

Self-service password reset (SSPR)

Self-service password reset lets a user reset or unlock their own password[7] with no help-desk involvement. The flow is gated on three checks: the user is enabled for SSPR, the user has registered enough authentication methods, and, for hybrid accounts, the reset can reach wherever the password actually lives.

A user must register at least one authentication method[7], chosen from Microsoft Authenticator, OATH tokens, SMS, voice call, email OTP, and security questions. The administrator policy sets how many registered methods the reset itself requires: a value of one or two[7]. Accounts holding an Azure administrator role are exempt from the relaxed setting and are forced onto a stronger two-method policy.

The free-vs-premium line: SSPR is available on Microsoft Entra ID Free[5] for cloud users. But SSPR password writeback, which pushes a cloud-initiated reset back down to the on-premises Active Directory for a federated, pass-through-auth, or password-hash-synced user, requires Entra ID P1[5]. Without writeback, a hybrid user whose password is mastered on-premises is told to contact their administrator rather than being allowed to reset.

Finally, distinguish three operations that the names blur: a password reset recovers a forgotten password (the SSPR scenario), a password change updates a password the user already knows, and password writeback is the hybrid mechanism that carries either of those back to on-premises AD: it is not a third end-user action.

SSPR enabledfor the user?Enough methodsregistered (1 or 2)?Password on-prem+ writeback (P1)?YesYesYes / cloud-onlyUser resets passwordno help deskNoNoOn-prem, no writebackContact administratorSSPR cannot complete
SSPR succeeds only when the user is enabled, has the required methods registered, and the reset can reach the password's master (cloud, or on-prem with P1 writeback).

Exam-pattern recognition

The questions in this area are almost always 'pick the correct object / setting for this requirement,' and the distractors are the adjacent option you just ruled out. Building on the mechanics above, the AZ-104 stem shapes for this topic and the answer each points to come down to spotting that one telling phrase.

Pattern 1: group type vs membership type

"Users in the Sales department must automatically gain access to a set of resources as they join the department, with no manual upkeep. Which group should you create?"

The phrase 'automatically … as they join' is the dynamic-membership tell, and 'access to resources' (not a mailbox) is the security-group tell, so the answer is a security group with Dynamic User membership. Watch the distractors: a Microsoft 365 group is wrong because the requirement is resource access, not collaboration; an Assigned security group is wrong because it needs manual upkeep. If the stem adds 'this is a trial / free tenant,' dynamic membership becomes unavailable because it requires Entra ID P1[5].

Pattern 2: who can edit membership

"A group owner reports they cannot add a member to a group. Why?"

The answer is that the group's membership type is Dynamic, not Assigned: a group owner can only edit members of an Assigned group[2]. The membership of a dynamic group is set entirely by its rule; to change who is in it, you change attributes or the rule (and editing the rule needs an administrator role).

Pattern 3: licensing prerequisites and location

"You try to assign a license to a new user and the assignment fails / the option is missing. What do you do?"

Two answers cover most variants. If the assignment fails, set the user's Usage location: it is required before a license can be assigned. If the license-assignment UI is missing from the Azure / Entra portal, that is by design since September 1, 2024: assign the license in the Microsoft 365 admin center[6] (or via Graph/PowerShell). For 'license a whole department efficiently,' the answer is group-based licensing on a security group, which also requires P1 for each benefiting user.

Pattern 4: SSPR and writeback

"Cloud users can reset their passwords, but synced on-premises users cannot. What must you enable?"

Enable SSPR password writeback, and note it requires Entra ID P1[5]. Plain SSPR works for cloud users on the Free tier; the moment the password is mastered in on-premises AD, the reset must be written back, and that capability is the premium piece. A separate variant, 'a guest using a personal Microsoft account such as Outlook.com cannot use SSPR,' is expected behavior: those accounts recover through their own Microsoft account[7], not your tenant.

Pattern 5: member vs guest defaults

"An external partner needs to collaborate. How do you give them access without creating a password for them?"

Invite them as a B2B guest; they authenticate with their home credentials and you scope them with roles and group membership. The trap answer is creating a member account, which forces you to manage a credential and grants broad default member permissions[2] the partner shouldn't have.

Security group vs Microsoft 365 group

DimensionSecurity groupMicrosoft 365 group
Primary purposeManage access to resources, roles, and appsCollaboration (shared mailbox, calendar, SharePoint, Teams)
Allowed member typesUsers, devices, service principals, groups (nested)Users only
Membership typesAssigned, Dynamic User, or Dynamic DeviceAssigned or Dynamic User
Used for group-based licensingYes (licenses attach to security groups)No
Created by default byMember users (unless restricted)Member users (unless restricted)
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

A user's member-or-guest type is fixed by origin, not by a setting

A member user is native to your tenant (created in the cloud or synced from on-premises Active Directory by Entra Connect); a guest user is invited from another directory through B2B collaboration and signs in with their own home credentials. The type is decided by how the account entered the directory and is not something you toggle on the user. You widen or narrow a user's actual access by assigning roles, not by changing the type.

1 question tests this
Invite external collaborators as B2B guests so you never manage their password

When an outside partner needs access, invite them as a B2B guest rather than creating a member account. The guest authenticates against their own home tenant or identity provider, so you issue no credential and reset no password, and you scope them with roles and group membership. A guest's UPN takes the form alice_contoso.com#EXT#@yourtenant.onmicrosoft.com, and by default guests have restricted directory permissions.

Trap Creating a member account for an external partner: it forces you to manage a credential and grants the broad default member permissions a partner shouldn't have.

Guest users get restricted directory permissions by default

By default a guest can manage their own profile and read only limited directory data; they cannot enumerate the full list of users or groups the way a member can. Members, by contrast, can read most directory information and by default register applications, create groups, and invite other guests. You can tighten these defaults for all members or all guests in the directory's user settings.

Security groups gate access; Microsoft 365 groups enable collaboration

Pick a security group to manage access to resources, roles, and applications: its members can be users, devices, service principals, and even other groups (nesting). Pick a Microsoft 365 group when the need is a shared workspace (mailbox, calendar, SharePoint), but note its members can be users only. The decisive test is the requirement: resource or role access points to a security group, a team workspace points to a Microsoft 365 group.

Trap Choosing a Microsoft 365 group to control access to a resource: that group type is for collaboration, and only a security group can be used for group-based licensing.

1 question tests this
Only a security group can hold non-user members

A security group's membership can include users, devices, service principals, and nested groups, which is why it is the vehicle for assigning resource access and roles. A Microsoft 365 group accepts users only: no devices or service principals. When a scenario needs a group of devices (for example to target Intune policy through dynamic device membership), the group must be a security group.

Trap Trying to add devices to a Microsoft 365 group: that type takes users only, so a device group must be a security group.

2 questions test this
Assigned vs dynamic membership decides who maintains the member list

Assigned membership means an administrator or group owner adds each member by hand; dynamic membership uses an attribute rule to add and remove members automatically as their attributes change. Choose Assigned for a fixed, hand-picked roster and dynamic when membership should track an attribute such as department. Dynamic keeps the roster accurate without manual upkeep but trades away the ability to pin or exclude an individual outside the rule.

A group owner can edit members only when membership is Assigned

Group ownership lets you manage a group's properties and its membership, but the membership part applies only to Assigned groups. A dynamic group's members are governed entirely by its rule, so even the owner cannot add or remove a member directly: you change membership by changing user attributes or the rule itself. Editing a dynamic membership rule additionally requires the Groups Administrator, Intune Administrator, or User Administrator role.

Trap Assuming a group owner can add a member to any group: for a dynamic group the rule controls membership and the owner cannot override it.

1 question tests this
A dynamic group targets users OR devices, never both

When you create a dynamic membership group you choose Dynamic User or Dynamic Device, and a single group cannot do both. A device rule may reference only device attributes: you cannot build a device group from the device owners' attributes. If a requirement mixes users and devices, you need two separate dynamic groups.

Trap Building one dynamic group whose rule mixes user and device attributes: Entra ID requires the membership target to be users only or devices only.

2 questions test this
Dynamic membership requires Microsoft Entra ID P1

Attribute-rule (dynamic) group membership is a premium feature: it requires Microsoft Entra ID P1 for every user in scope of the rule. Assigned membership works on the free tier. In a scenario set in a trial or free tenant, automatic department-based membership is unavailable, so the answer falls back to an Assigned group plus manual upkeep, or acquiring P1.

Trap Proposing dynamic membership in a free/trial tenant: dynamic groups need Entra ID P1 and aren't available on the free tier.

3 questions test this
Set a user's Usage location before assigning any license

A license cannot be assigned to a user until that user has a Usage location set, because Microsoft licenses are subject to regional availability. If a direct license assignment fails for a freshly created user, the missing Usage location attribute is the usual cause. Set it on the user profile, then assign the license.

Use group-based licensing to keep licenses in step with membership

Group-based licensing attaches one or more product licenses to a security group; Entra ID then licenses every member automatically and removes the license when a member leaves the group. Pair it with a dynamic group and licensing tracks org structure with zero scripting. It works on security groups only, and you must hold at least one license for every unique member of a licensed group.

Group-based licensing requires Entra ID P1 for each benefiting user

Group-based licensing itself is a premium capability: you need Microsoft Entra ID P1 (or a qualifying Microsoft 365 / Office 365 plan such as Business Premium or Office 365 E3) for every user who benefits from it. This is separate from the product licenses being assigned: the P1 entitlement pays for the automation, while the product licenses cover the services the members consume.

License assignment moved out of the Azure portal on September 1, 2024

Since September 1, 2024 the Microsoft Entra admin center and the Azure portal no longer expose license assignment in their UI; assignment for both users and groups is done in the Microsoft 365 admin center. The change is UI-only: Microsoft Graph and PowerShell still assign licenses programmatically. If a question says the license-assignment option is missing from the Azure portal, that is expected, not a bug.

Trap Looking for the license-assignment blade in the Entra/Azure portal: it was removed in September 2024; assign licenses in the Microsoft 365 admin center or via Graph/PowerShell.

SSPR needs at least one registered method; the policy requires one or two to reset

Self-service password reset lets users reset or unlock their own password with no help-desk call, but each user must first register authentication methods: choices include Microsoft Authenticator, OATH tokens, SMS, voice call, email OTP, and security questions. The administrator policy sets how many registered methods a reset requires, a value of one or two. A user who has registered fewer than the required number cannot use SSPR and must contact an administrator.

7 questions test this
Administrator accounts are forced onto a stronger two-method SSPR policy

Even if the tenant SSPR policy requires only one method for ordinary users, accounts holding an Azure administrator role are subject to a stronger two-gate password reset policy and cannot use the relaxed single-method setting. This is automatic and not configurable down: Microsoft enforces it because admin accounts are higher-value targets.

Trap Assuming a one-method SSPR policy applies to administrators: admin-role accounts are always held to the stronger two-method reset policy.

5 questions test this
SSPR is free, but password writeback to on-premises AD requires P1

Self-service password reset is available on Microsoft Entra ID Free for cloud-managed users. SSPR password writeback, which pushes a cloud-initiated reset back down to on-premises Active Directory for a federated, pass-through-auth, or password-hash-synced user, requires Microsoft Entra ID P1. Without writeback, a hybrid user whose password is mastered on-premises is told to contact their administrator instead of resetting.

Trap Expecting plain SSPR to reset a synced on-premises user's password: that needs SSPR password writeback, which requires Entra ID P1.

4 questions test this
Reset, change, and writeback are three different password operations

A password reset recovers a forgotten password (the SSPR scenario, where the user proves identity with registered methods); a password change updates a password the user already knows and is signed in with; password writeback is the hybrid mechanism that carries either operation back to on-premises AD. It is not a separate end-user action. Conflating reset with writeback is the usual source of confusion in hybrid scenarios.

Personal Microsoft accounts used as guests cannot use Entra SSPR

A guest who signs in with a personal Microsoft account (Outlook.com, Hotmail) cannot use your tenant's Entra SSPR; they recover through their own Microsoft account instead. B2B guests from a partner Microsoft Entra tenant or self-service sign-up users, by contrast, can reset using the email they registered, subject to the partner tenant's own SSPR policy. So SSPR support for a guest depends on what kind of account backs them.

Trap Expecting your tenant's SSPR policy to reset a personal-Microsoft-account guest's password: those accounts recover through their own Microsoft account, not your tenant.

Bulk user creation uses a fixed CSV template with four required fields

Bulk user creation in the Microsoft Entra admin center downloads a CSV template whose only required values are Name, User principal name, Initial password, and Block sign in (Yes/No). Extra columns you add are ignored and not processed, and a bulk operation can fail if it doesn't complete within about an hour, so split very large imports into smaller batches.

4 questions test this
Use -in for multiple values and minimize -match/-contains for fast dynamic groups

When a dynamic membership rule tests one property against several values, the single -in operator (for example user.department -in ["Sales","Marketing"]) is more efficient than chaining many -or/-eq expressions. Microsoft advises minimizing the -match and -contains operators as much as possible for better dynamic group processing times; prefer -eq or -startsWith where you can.

5 questions test this
Manage Entra users with New-MgUser, Get-MgUser, and Update-MgUser

In the Microsoft Graph PowerShell SDK, New-MgUser creates a user (its PasswordProfile parameter takes a hash table such as @{Password='...'}), Update-MgUser edits an existing user's properties, and Get-MgUser piped to Update-MgUser bulk-updates a filtered set. Connect-MgGraph must request the User.ReadWrite.All scope to create or modify users.

Trap Passing PasswordProfile as a string, or requesting only User.Read.All (read-only) when you need to write.

8 questions test this
External collaboration settings decide who may invite guests

Guest invitations are governed in External collaboration settings: you can restrict them so only users assigned to specific admin roles can invite, and the built-in Guest Inviter role grants invite rights (even when that restriction is on) without other user-management privileges. Collaboration restrictions can allow or block invitations to specific named domains (for example only fabrikam.com).

Trap Assigning User Administrator just to let someone invite guests when the least-privilege Guest Inviter role suffices.

4 questions test this
Pilot SSPR with the Selected scope and force registration at sign-in

Self-service password reset can be enabled for None, Selected, or All users; choose Selected and pick one security group to pilot it before a wider rollout. Turning on 'Require users to register when signing in' prompts users to supply authentication contact info at next sign-in, and the re-confirmation interval accepts 0 to 730 days (0 means users are never asked to re-confirm).

Trap Leaving SSPR set to All when only a pilot group is intended.

5 questions test this

Also tested in

References

  1. Create, invite, and delete users (Microsoft Entra ID)
  2. Default user permissions in Microsoft Entra ID
  3. What is Microsoft Entra B2B collaboration?
  4. Learn about groups, group membership, and access (Microsoft Entra)
  5. Microsoft Entra licensing
  6. What is group-based licensing in Microsoft Entra ID?
  7. Self-service password reset deep dive (Microsoft Entra ID)