Managing Microsoft Entra Users and Groups

Introduction

This lesson opens the first skills area of the AZ-104 study guide, Manage Azure identities and governance, which Microsoft weights at 20–25% of the exam (study guide updated 2026-04-17). Within that area, the first objective is to manage Microsoft Entra users and groups: create users and groups, manage their properties, manage licenses, manage external users, and configure self-service password reset (SSPR).

Every other task an Azure administrator performs depends on identity. A virtual machine cannot be deployed by someone who cannot sign in, and a storage account cannot be reached by a group that does not exist. Before you assign Azure roles in the next lesson, you need to understand the directory objects those roles are assigned to.

By the end of this lesson you will be able to create and organise users and groups, choose between assigned and dynamic membership, apply licenses at scale, invite and constrain guest users, and configure SSPR with the right scope and authentication methods.

Learning objectives

• Distinguish a Microsoft Entra tenant from an Azure subscription and explain how they relate.
• Create cloud users, bulk-create users, and manage user properties and account state.
• Choose the correct group type (Security or Microsoft 365) and membership type (Assigned, Dynamic User, Dynamic Device).
• Assign licenses directly and through group-based licensing, and resolve license errors.
• Invite external (B2B) users and explain what a guest can and cannot do.
• Configure self-service password reset, including scope, methods, registration and writeback.

Tenant, directory and subscription: the foundation

A Microsoft Entra tenant is a dedicated instance of Microsoft Entra ID that your organisation receives when it signs up for a Microsoft cloud service. It holds users, groups, devices and applications, and has a primary domain such as contoso.onmicrosoft.com, to which you can add verified custom domains such as contoso.com.

An Azure subscription is a billing and resource container. Each subscription trusts exactly one tenant for authentication, but one tenant can be trusted by many subscriptions. Moving a subscription to another tenant is possible, but it removes existing Azure role assignments, which is a classic exam trap.

Users

User types and sources

A user object in Entra ID has a user type (Member or Guest) and a source (Entra ID, Invited user, Windows Server AD synchronised from on premises, and so on). Cloud-only users are created directly in the tenant. Synchronised users are created in on-premises Active Directory and copied by Microsoft Entra Connect or Cloud Sync; for those users, most attributes (including the display name and password) are mastered on premises, and you edit them there, not in the portal.

Creating users

In the Microsoft Entra admin center you choose Users > New user > Create new user. You supply a User principal name (UPN, for example maria.lopez@contoso.com), a display name and an initial password (auto-generated or custom). The user must change the password at first sign-in. You can also set job title, department, manager, usage location, and group memberships at creation.

Two other creation paths matter for the exam:

• Bulk create: download a CSV template, fill in one row per user (UPN, display name, initial password, block-sign-in flag) and upload it. Operations run asynchronously, and you review the results file for failures. Bulk invite and bulk delete work in the same way.
• Scripted: Microsoft Graph PowerShell (New-MgUser) or Azure CLI (az ad user create). Both are appropriate when you must create hundreds of users with consistent properties.

Connect-MgGraph -Scopes "User.ReadWrite.All"
$pwd = @{ Password = "Temp#2026-xyz!"; ForceChangePasswordNextSignIn = $true }
New-MgUser -DisplayName "Maria Lopez" -UserPrincipalName "maria.lopez@contoso.com" `
  -MailNickname "maria.lopez" -AccountEnabled -PasswordProfile $pwd -UsageLocation "ES"

az ad user create --display-name "Maria Lopez" \
  --user-principal-name maria.lopez@contoso.com \
  --password 'Temp#2026-xyz!' --force-change-password-next-sign-in true

Managing user properties

Properties are grouped into profile information (name, job title, department, manager, company), contact information, and settings such as Block sign in and Usage location. Two properties deserve special attention:

• Usage location is a two-letter country code. It is mandatory before a license can be assigned, because some services are not licensable everywhere. A missing usage location is the most common cause of a license assignment failure for a cloud user.
• Account enabled / Block sign in disables the account without deleting it. Use this when an employee leaves; deleting is a separate step.

Deleted users go to the Deleted users list and are recoverable for 30 days, after which they are permanently removed. Restoring a user brings back the object and its group memberships, but you should verify licences afterwards.

Administrators can reset a user's password, revoke sessions, view sign-in logs and authentication methods, and assign directory roles from the user's page. Remember that directory roles (Global Administrator, User Administrator, and so on) control Entra ID itself, whereas Azure roles control Azure resources; the two systems are separate and the next lesson explains the difference.

Worked example: onboarding 40 interns

Scenario. Contoso hires 40 interns for the summer in its Madrid office. Each needs an account, a Microsoft 365 license, membership in the "Interns" group, and an administrator must be able to cut off access quickly when the summer ends.

Reasoning, step by step.

1. Forty users is too many to enter individually, so use Bulk create with the CSV template. Set the UPN suffix to contoso.com (a verified domain).
2. The CSV template has no usage location column for the license, so after the upload you set Usage location = ES for all 40 users. Because licensing requires it, doing this through a script or by making the group dynamic with a usage-location rule avoids 40 manual edits.
3. Create a security group Interns with Assigned membership and add all 40 users (upload a CSV of members or use a script).
4. Assign the Microsoft 365 license to the group, not to each user (group-based licensing).
5. At the end of the summer, select all interns in the portal and choose Block sign in (or remove them from the group, which also removes the license).

Solution. Bulk create, set usage location, one assigned group, group-based licensing.

Why other choices are weaker. Creating users one at a time is slow and error-prone. Assigning licenses individually forces 40 separate operations at hire and again at exit. A dynamic group would be better only if an attribute such as department -eq "Intern" were reliably populated, and the scenario does not guarantee that.

Groups

Group types

Both can be used for Azure RBAC and licensing. A Microsoft 365 group can contain only users (no devices, and no nesting of other groups), while security groups can also contain other groups (nesting), devices and service principals. Note that group-based licensing does not support nested groups: only direct members of the licensed group receive the license. This is a frequent exam detail.

Membership types

A group is either assigned or dynamic; you cannot mix. Dynamic membership requires Microsoft Entra ID P1 (or Governance/Suite equivalents) for each user who is a member of a dynamic group. Rule syntax uses the form (user.department -eq "Finance") and (user.accountEnabled -eq true). Rules are re-evaluated automatically; processing is not instantaneous, and large changes can take minutes to hours.

You can also designate a group as Microsoft Entra role-assignable (isAssignableToRole). Such a group must be created that way; the setting cannot be changed afterwards, membership must be Assigned, and only privileged administrators can manage it. This protects groups that grant directory roles from being modified by a lower-privileged owner.

Managing group properties and owners

A group has owners (who can manage membership) and members (who receive access). Owners do not automatically become members. Delegating ownership to a team lead lets them manage membership without holding an admin role. Deleted Microsoft 365 groups can be restored for 30 days.

Worked example: choosing assigned or dynamic

Scenario. Fabrikam wants every employee whose department is "Finance" to have access to a storage account and to receive Power BI licensing. Employees move between departments several times per year, and HR already keeps the department attribute accurate.

Reasoning. The requirement is attribute-driven and changes often. A dynamic user group with rule user.department -eq "Finance" automatically adds transfers in and removes transfers out. You then assign the Azure role and the license to that single group.

Solution. Dynamic User security group, rule on department, license assigned to the group.

Why not Assigned. Someone would need to update membership at each transfer, and a missed removal leaves a former finance employee with access, a least-privilege failure.

Licenses

Direct and group-based assignment

Microsoft Entra ID, Microsoft 365 and Enterprise Mobility + Security products are licensed per user. You can assign a license to a user directly or to a group. With group-based licensing, every user who is a member (direct member only; nesting is not supported) receives the license set, and removal from the group removes it.

Requirements and behaviours:

• The user must have a usage location set.
• Licenses contain service plans that you can turn off individually, for instance disabling Yammer inside an E5 SKU.
• If there are not enough licenses, or two assigned licenses conflict (for example overlapping service plans), the user shows a license error in the group's Licenses > Processing view. Fix the root cause and use Reprocess to retry.
• Where a user receives the same product both directly and through a group, the group assignment is inherited alongside; you can later remove the direct one safely.

Worked example: license error after a transfer

Scenario. After a reorganisation, 12 users in group Sales-Europe show "Usage location is not set". The group has a Microsoft 365 E3 license.

Reasoning. Group-based licensing silently skips users it cannot license. The error panel on the group lists them. The fix is to set each user's usage location (via bulk edit or script), then select Reprocess on the group.

Solution. Set usage location, reprocess. No change to the group or license is needed.

Why other fixes fail. Adding more licenses does nothing, because the problem is not capacity. Re-creating the group is unnecessary and loses role assignments tied to it.

External users

B2B collaboration

Microsoft Entra External ID B2B collaboration lets you invite people from other organisations to use your resources while they keep their own credentials. An invited user is created as a Guest object (user type = Guest, source = Invited user). The invitation can go to a work email, a Microsoft account, or a Google or other federated account. After redemption, the guest authenticates at their home identity provider; your tenant never stores their password.

You invite through Users > New user > Invite external user, by bulk invite with a CSV, or by script (New-MgInvitation). You may add a personal message and choose whether to send the email. Guests can be added to groups and assigned Azure roles like members.

By default, guests have restricted directory permissions: they see limited information about other users and groups. The tenant's External collaboration settings control:

• who may invite guests (admins only, admins plus the Guest Inviter role, members, or even guests),
• the guest user access level (most restrictive: limited access to properties and memberships of directory objects),
• collaboration restrictions: allow or block specific domains.

Passwords and MFA for guests

Because a guest's identity lives in their home tenant, your administrators cannot reset a guest's password when the guest is homed elsewhere; password reset is the home organisation's responsibility. Multifactor authentication can be required through Conditional Access in your tenant, and cross-tenant access settings can trust the home tenant's MFA claims so guests are not prompted twice.

Worked example: giving an auditor temporary access

Scenario. An external auditor from Adatum needs read access to one resource group for three weeks. Adatum uses its own Entra tenant.

Reasoning. Invite the auditor's work email as a guest. Add the guest to a security group Auditors-External, assign the Reader role on the resource group to that group, and set an access review or a calendar reminder to remove the guest. The auditor signs in with Adatum credentials, so you create no password and have none to reset.

Solution. B2B guest, group membership, Reader on the resource group.

Why not create a member account. A member account for an external person is a license cost, a password to manage, and a security risk once the engagement ends.

Self-service password reset (SSPR)

SSPR lets users reset or unlock their own accounts without calling the help desk. Configuration is under Protection > Password reset in the Entra admin center.

Key settings:

Important behaviours:

• Administrator accounts always use a strong two-gate policy defined by Microsoft; the tenant's settings for methods do not weaken it.
• SSPR for cloud-only users works with the licenses your tenant has; password writeback for hybrid users requires the licensing and the sync agent. Check the current Microsoft licensing page, because the lists of included features by license change over time.
• Users must have registered the required number of authentication methods before they can reset. If they have not, they are blocked and must contact an administrator.
• Only one group can be selected for SSPR scope at a time, so plan one group containing nested groups for each wave of rollout.

Worked example: pilot rollout

Scenario. Northwind plans SSPR for 5,000 users. The security team insists on two methods, no security questions, and a pilot before general rollout. Some users are synchronised from on-premises AD, and their passwords must also change on premises.

Reasoning, step by step.

1. Create a security group SSPR-Pilot with 100 volunteers.
2. Set SSPR to Selected and choose that group.
3. Require 2 methods; enable mobile app notification, mobile app code, and email; disable security questions.
4. Enable registration at sign-in so volunteers register methods.
5. For synchronised users, enable password writeback in Entra Connect and in the SSPR on-premises integration pane.
6. After the pilot, switch scope to All (or to a group of all employees).

Solution. Selected scope with pilot group, two methods without questions, registration enforced, writeback enabled for hybrid users.

Why not set "All" immediately. A tenant-wide change with unregistered users would produce a flood of blocked users and help-desk calls; a pilot reveals the gaps before they affect everyone.

Common pitfalls and exam tips

Exam tip: When a question says "assign a license" to a cloud user and the assignment fails, think usage location first.

Exam tip: "Automatically add or remove users based on an attribute" means a dynamic group; it needs Entra ID P1, and it applies to security or Microsoft 365 groups, but never to role-assignable groups.

Exam tip: A guest's password cannot be reset by your admins if the guest's home directory is another tenant.

Pitfall: Believing group-based licensing covers nested groups. It does not; only direct members are licensed.

Pitfall: Confusing Entra directory roles with Azure RBAC roles. User Administrator lets you manage users; it grants no access to a virtual machine.

Pitfall: Forgetting the 30-day recovery window for deleted users. After 30 days the object is gone permanently.

Pitfall: Enabling SSPR "Selected" with a group but not requiring registration, so no user can complete a reset.

Mini case study: Tailwind Traders

Tailwind Traders has 1,200 employees in three countries. Requirements from the CIO:

1. New hires in the Logistics department get Microsoft 365 E3 and access to a shared storage account automatically.
2. Three external freight consultants need access for six months, with access removed afterward.
3. Users must be able to reset their own passwords with at least two methods; legacy on-premises accounts must stay in sync.
4. The service desk must not be able to grant themselves new Azure access.

Design and commentary.

• Requirement 1 is attribute-based and recurring: create a dynamic user security group with user.department -eq "Logistics". Assign the license to the group and later the Azure role (next lesson) to the same group. Confirm each user has a usage location, or add a rule that includes user.usageLocation -ne null for the license-bearing group.
• Requirement 2: invite the consultants as guests, add them to an assigned group, and schedule an access review with a six-month end date. No local passwords are created.
• Requirement 3: SSPR set to All after a pilot, two methods (authenticator app and email), password writeback enabled for the synchronised accounts.
• Requirement 4: give the service desk the Helpdesk Administrator or Password Administrator directory role, scoped appropriately, and no Azure role at subscription scope. Directory roles do not confer Azure resource permissions, so the desk cannot grant itself Azure access (unless a Global Administrator elevates, which is audited).

Result. Dynamic group plus group-based licensing, guest accounts with expiry, a piloted SSPR rollout with writeback, and least-privilege directory roles.

Key terms

• Tenant: dedicated Microsoft Entra ID instance holding identities and apps.
• UPN: user principal name, the sign-in name in email format.
• Usage location: country code required before licensing a user.
• Dynamic group: group whose membership is computed from a rule.
• Group-based licensing: assigning licenses to a group; direct members only.
• B2B guest: external user invited to your tenant, authenticating at home.
• SSPR: self-service password reset.
• Password writeback: syncing a cloud password change to on-premises AD.

Summary checklist

• I can explain the tenant-subscription relationship and the effect of moving a subscription to another tenant.
• I can create users singly, in bulk, and by script, and I know which properties are mandatory for licensing.
• I can choose Security versus Microsoft 365 groups and Assigned versus Dynamic membership.
• I know group-based licensing ignores nested groups and how to reprocess license errors.
• I can invite guests, restrict who may invite, and explain why admins cannot reset a guest's home password.
• I can configure SSPR scope, methods, registration and writeback.

Official sources

• AZ-104 study guide: https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/az-104 (opens in a new tab)
• AZ-104 learning path, manage identities and governance: https://learn.microsoft.com/en-us/training/paths/az-104-manage-identities-governance/ (opens in a new tab)
• Microsoft Entra self-service password reset: https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr (opens in a new tab)
• Microsoft Entra B2B collaboration: https://learn.microsoft.com/en-us/entra/external-id/faq (opens in a new tab)