Manage Microsoft Entra Users and Groups (AZ-104)

Microsoft Entra ID is Azure's cloud identity and access management service: the directory that holds every account and group that signs in to Azure, Microsoft 365, and thousands of other applications. It was formerly called Azure Active Directory (Azure AD); Microsoft renamed it in 2023, but the service and most portal workflows are unchanged. You manage it in the Microsoft Entra admin center (or the Microsoft Entra ID blade of the Azure portal).

A user is an identity for a person (or, in some cases, a service) that needs to sign in. Every user has properties — display name, user principal name (UPN), job title, department, usage location, account enabled — and these properties matter for more than record-keeping: dynamic groups and licensing read them directly.

A group collects users (and, for security groups, devices) so you can manage them together. Instead of granting a role or a license to fifty people one by one, you grant it to a group once and every member inherits it. Most identity decisions come down to two choices: what type of object you create, and how its membership or access is managed.

Entra ID has two user types. A member is an internal account in your directory — typically an employee — whose password you manage in your tenant. A guest is an external person you invite through Microsoft Entra B2B collaboration; the guest signs in with their own identity, so you never manage their password.

You create a member under Users > New user > Create new user, setting the UPN, display name and initial password. You add a guest with New user > Invite external user: you enter their email address and Entra creates the guest object straight away and sends an invitation to redeem.

How a guest signs in

The identity a guest redeems with depends on what they have: a user from another Microsoft Entra organization uses their work account; someone with a personal Microsoft account uses that; and someone with neither (or an identity provider you haven't federated) redeems with an email one-time passcode sent to their address. Until they redeem, the guest object exists in your directory with its invitation state shown as pending acceptance.

UserType is a property, not the account kind. A B2B user from a partner (for example, a subsidiary on its own tenant) can have UserType changed to Member: they still authenticate in their home tenant, but they get member default permissions in yours. Equally, an internal account can be set to Guest to restrict it.

Bulk operations let you create, invite, delete or export many accounts at once from a CSV file instead of clicking through the portal repeatedly. On the Users page you will find Bulk create (member accounts), Bulk invite (guests), Bulk delete, and Download users.

Each one works the same way: download the CSV template, fill in one row per user, and upload it. Keep the template's header rows. Bulk create needs each user's display name, user principal name and initial password (plus whether to block sign-in); Bulk invite needs each external email address and a redirection URL (with an option to send the invitation message); Bulk delete needs the user principal names. The jobs run in the background and report per-row results under Bulk operation results, so you fix failed rows and re-upload.

Groups have their own bulk operations. Open a group and choose Members > Bulk operations to Import members or Remove members from a CSV of user principal names or object IDs, or Download members to export the list (the Groups page also offers Download groups). Use these when a list of people must join or leave an assigned group — they don't apply to dynamic groups, whose members only the rule can change.

Large-scale provisioning is therefore a built-in CSV operation (or Microsoft Graph / PowerShell for automation), not a custom script you must write from scratch.

You manage a user by editing their profile properties, controlling whether they can sign in, and deleting or restoring the account — and where the account is mastered decides where each edit happens.

• Cloud-only users are edited in the Entra admin center (Users > user > Edit properties), with Microsoft Graph, or in bulk. Changing an attribute such as department or usage location is often all you need: dynamic groups and anything they grant follow the attribute.
• Synchronized users (from on-premises Active Directory through Microsoft Entra Connect or Cloud Sync) are mastered on-premises. Their synced attributes are read-only in the cloud — change them in Active Directory and let the next sync carry the change up.
• Block sign-in by setting Account enabled to off. The object, its group memberships, licenses and data stay in place, so it is the right move for a leave of absence or an investigation — unlike deleting, it removes nothing.
• Delete and restore. A deleted user is soft-deleted and stays under Deleted users for 30 days. Restoring it within that window brings back the same object (same object ID) rather than a new account with the same name. After 30 days, or after a permanent delete, it can't be recovered.

Usage location deserves a special mention: it is the property Microsoft 365 uses to decide which services can be licensed to a user (see the licensing section).

A security group controls access; a Microsoft 365 group provides collaboration resources. You assign a security group Azure roles, app access or licenses, and every member inherits them; security groups can contain users, devices, service principals and other groups.

Creating a Microsoft 365 group provisions a group mailbox (a group's own inbox — not an Exchange shared mailbox, which is a different recipient type), a group calendar, a SharePoint site and a OneNote notebook. A Microsoft Teams team isn't created with it; you add one by Teams-enabling the group. Microsoft 365 groups can contain only users and don't support nesting.

Both types can start as assigned and later be switched to dynamic (or back) by changing the Membership type. A few related objects live elsewhere or carry their own rules:

• Mail-enabled security groups and distribution lists are created in the Exchange admin center (or the Microsoft 365 admin center), not the Entra admin center.
• Role-assignable groups (security or Microsoft 365 groups created with “Microsoft Entra roles can be assigned to the group”) can receive directory roles. The setting is fixed at creation, membership must be assigned (never dynamic), and only privileged roles and the group's owners can change its members.
• Governance for Microsoft 365 groups — the naming policy (prefix/suffix and blocked words) and the expiration policy — requires Microsoft Entra ID P1 for the users the policy covers.

Group membership is either assigned — you add and remove each member — or dynamic, where a membership rule evaluates each user's (or device's) attributes and Entra adds and removes members automatically.

You configure dynamic membership by setting the group's Membership type to Dynamic User or Dynamic Device (a rule can't mix users and devices) and writing a rule. It requires a Microsoft Entra ID P1 license for each unique user who is a member of one or more dynamic groups; device members need none.

user.department -eq "Sales"

With that rule, a user whose department becomes Sales is added, and one who transfers out is removed — you manage the attribute, and the group follows.

How rule-managed membership behaves

• You can't add or remove members by hand. To exclude someone, change their attribute or change the rule (for example with -ne or -notIn).
• Converting an assigned group to dynamic keeps the group — same object ID, so its role assignments, app access and license assignments stay — but members who don't match the rule are removed. Converting back to assigned keeps the current members as a static list.
• Validate Rules (on the rule editor) tests chosen users or devices against a rule before you save it, so you can check a change without touching membership.
• Pausing processing stops rule evaluation for the group, so membership freezes and the Members list no longer reflects the rule — it can't be used to preview a new one.

Dynamic isn't the only reason membership can be read-only in the Entra admin center: a group synchronized from on-premises AD is managed there, and a role-assignable group only accepts changes from privileged roles and its owners (and can never be dynamic).

Rule syntax essentials

• Precedence: -and binds before -or, so bracket mixed expressions: user.country -eq "US" -and (user.department -eq "Sales" -or user.department -eq "Marketing").
• Pick the right attribute. Exclude guests with user.userType -eq "Member" (not department); user.accountEnabled -eq true skips blocked accounts; usageLocation (a two-letter licensing code) is a different attribute from country (free text).
• Device rules use device attributes only, such as device.deviceOSType -eq "Windows" — never the owner's user attributes.

A license gives a user a product such as Microsoft 365 E3 or Microsoft Entra ID P1. You assign it directly to a user, or through group-based licensing: assign the product to a group and every member inherits it; when someone leaves the group, the license is released back to the pool automatically.

License assignment is done in the Microsoft 365 admin center under Billing > Licenses (or with Microsoft Graph, for example assignLicense or Set-MgGroupLicense). For a group you pick the subscription and can turn individual apps and services (service plans) on or off for that group — the way to give a group a product minus one of its services. Security groups, mail-enabled security groups and Microsoft 365 groups can all be licensed.

Rules that decide the outcome

• Usage location. A direct assignment fails for a user with no usage location, because services vary by country. With group-based licensing, a user with no usage location inherits the tenant's location instead — fine for a single-country tenant, wrong for users abroad, so set it in the user-creation flow.
• No nested-group inheritance. Only first-level members of the licensed group get the license; members of a group nested inside it don't.
• Direct plus inherited. A user can hold the same product both directly and from one or more groups; it consumes one license, and removing one source leaves the others in force.
• Moving between licensed groups: add the user to the destination group first, confirm the new license applied, then remove them from the old group. Processing is asynchronous, so removing first can leave a gap with no license.

Fixing assignment errors

Errors appear on the product's Errors & issues tab. The common causes are not enough licenses (buy more or free some), a missing usage location (direct assignment), and conflicting service plans — two products whose plans can't coexist, such as Office 365 E1 assigned directly and Office 365 E3 inherited from a group (remove the direct E1, or disable the conflicting plan). Fixing the cause doesn't retry the group assignment by itself: select Reprocess to re-evaluate the affected users. A directory sync or revoking a user's sessions doesn't touch license state, and removing a user from a licensed group needs no Reprocess.

Combine group licensing with a dynamic group (for example user.department -eq "Sales") and new hires are licensed as soon as their attributes match.

You govern B2B guests with two separate controls: External collaboration settings (tenant-wide rules for invitations and guest permissions) and cross-tenant access settings (per-organization rules for other Microsoft Entra tenants).

External collaboration settings

Guest invite settings decide who can invite, from most to least open:

1. Anyone in the organization can invite guest users, including guests and non-admins (the default — so guests can invite other guests).
2. Member users and users assigned to specific admin roles can invite guest users, including guests with member permissions.
3. Only users assigned to specific admin roles can invite guest users (for example the Guest Inviter role).
4. No one in the organization can invite guest users, including admins.

Guest user access decides what guests can see in the directory:

Collaboration restrictions hold an allow list or a deny list of email domains for invitations — the tool for partners identified only by email domain, including those without a Microsoft Entra tenant.

Cross-tenant access settings

Cross-tenant access settings configure B2B collaboration (and B2B direct connect) per Microsoft Entra organization, added by tenant ID or domain, separately for inbound and outbound, and down to which users, groups and applications are allowed; they can also trust a partner's MFA and device claims. Use them when the rule must apply to one specific Entra organization rather than to an email domain.

Guest lifecycle

• Resend invitation for a guest whose state is still pending acceptance.
• Reset redemption status for a guest who already redeemed but whose sign-in identity changes (new email or identity provider). They redeem again with the new identity while keeping the same object ID, group memberships and app assignments — no need to delete and re-invite.
• Change UserType to Member when a partner's users should get member default permissions without becoming internal accounts.

Self-service password reset (SSPR) lets users reset a forgotten password or unlock their account at aka.ms/sspr without the help desk. You configure it under Microsoft Entra ID > Password reset.

Scope

Properties sets SSPR to None, Selected (one group — the usual pilot) or All. B2B guests from another Microsoft Entra organization reset their password under their home tenant's SSPR policy, not yours; guests using personal Microsoft accounts (Outlook.com, Hotmail) can't use Microsoft Entra SSPR at all.

Methods and registration

• Number of methods required to reset: one or two.
• Methods: Microsoft Authenticator, software OATH tokens, hardware OATH tokens (in preview for SSPR), SMS, voice call and email one-time passcode. Microsoft Authenticator and OATH tokens together count as a single method, so with two required a user needs another method as well.
• Require users to register when signing in prompts unregistered users at sign-in. Only with it on can you set the number of days before users are asked to reconfirm their information: 0–730, where 0 means never.
• Notifications: Notify users on password resets emails the user after their own reset; Notify all admins when other admins reset their passwords alerts Global Administrators.

Administrators follow a different policy. By default, accounts holding a Microsoft Entra admin role get a fixed, stronger two-gate policy (two methods, no security questions) that the Password reset settings don't change. Microsoft documents narrow exceptions: a one-gate policy applies during the first 30 days of a trial subscription, or when no custom domain is configured and Microsoft Entra Connect isn't synchronizing identities; and SSPR for administrators can be switched off entirely through the tenant's authorization policy. Test your SSPR configuration with a non-admin account; an admin's experience tells you nothing about the user policy. (Security questions are a legacy method that admin accounts can never use.)

Password writeback sends a password changed or reset in the cloud back to on-premises Active Directory, and it is what lets users whose passwords are managed on-premises use SSPR. Without it, any user mastered on-premises — whether the tenant uses federation, pass-through authentication or password hash synchronization — is told to contact an administrator.

Password hash sync is not a writeback prerequisite — writeback works with federation and pass-through authentication too. You turn on writeback in Microsoft Entra Connect (or Cloud Sync) and then, under Password reset > On-premises integration, set Enable password write back for synced users; that switch can also turn writeback off temporarily without reconfiguring Connect. On the same page, Allow users to unlock accounts without resetting their password lets a user unlock a locked on-premises account and keep the current password — it only works while writeback is on.

Writeback needs Microsoft Entra ID P1 or P2 or Microsoft 365 Business Premium; Microsoft 365 Business Standard doesn't include it.

Basic user and group management works on Microsoft Entra ID Free; automation and hybrid features need a paid tier. P2 includes everything in P1, and Microsoft 365 Business Premium includes Microsoft Entra ID P1.

When a scenario asks for the lowest-cost option, find the cheapest tier that covers every required feature — paying for P2 when nothing needs a P2-only capability is not the lowest cost.

Microsoft Entra ID is a flat, cloud, multi-tenant directory reached over HTTPS with modern protocols (OAuth 2.0, OpenID Connect, SAML); on-premises Active Directory Domain Services uses LDAP and Kerberos with domain controllers, forests, organizational units (OUs) and Group Policy. Entra ID has no OUs and no Group Policy — you scope management with groups and administrative units instead.

Many organizations run both and synchronize them with Microsoft Entra Connect or Cloud Sync. That is why the lifecycle and SSPR rules above depend on where an account is mastered: synced accounts are edited on-premises, and their passwords reach the cloud through hash sync and return through writeback.