Manage Microsoft Entra users and groups.

What Problem Does Identity Solve?

Before any person or application can create a virtual machine, read a storage blob, or even view the Azure portal, Azure needs to answer two questions: "Who are you?" (authentication) and "What are you allowed to do?" (authorization). The service that answers the first question is Microsoft Entra ID.

Microsoft Entra ID is Microsoft's cloud-based identity and access management service. It stores objects such as users, groups, and applications inside a tenant (also called a directory). When you sign up for Azure, Microsoft 365, or Dynamics 365, a tenant is created automatically. A tenant is a dedicated, trusted instance of Microsoft Entra ID that your organization controls. Every Azure subscription trusts exactly one Microsoft Entra tenant for authentication.

Tenants, Subscriptions, and the Relationship Between Them

A single tenant can be trusted by many subscriptions, but a subscription can trust only one tenant at a time. Think of the tenant as the company badge system and subscriptions as individual cost centers inside the company. Everyone shows the same badge, but charges go to different cost centers depending on where the work happens.

Key numeric limits for tenants:

• A single user can belong to a maximum of 500 Microsoft Entra tenants (as a member or guest).
• A single identity can create a maximum of 200 tenants.
• A tenant can have up to 5,000 managed domain names.
• The default directory object quota is 50,000 objects for tenants without a verified domain, and 300,000 objects for tenants with at least one verified domain.

💡 Exam Trap: A non-admin user can create a maximum of 250 Microsoft Entra resources (users, groups, applications, service principals). Both active resources and soft-deleted resources (within the 30-day recovery window) count toward this quota. Deleted objects that are past the 30-day window count at one-quarter value for an additional 30 days.

User Accounts: Types and Sources

Microsoft Entra ID supports several types of user accounts. Understanding the differences is essential for exam questions that ask "which account type should you use?"

Cloud identity - A user account created and managed entirely within your Microsoft Entra tenant. The account's source of authority is the Entra directory itself. You create cloud identities using the Azure portal, Azure CLI, PowerShell, or Microsoft Graph API.

Synced identity (hybrid identity) - A user account that originates in an on-premises Active Directory Domain Services (AD DS) forest and is synchronized to Microsoft Entra ID using Microsoft Entra Connect (formerly Azure AD Connect) or Microsoft Entra Cloud Sync. The on-premises AD DS remains the source of authority for most attributes. Password hash synchronization, pass-through authentication, or federation determines how the user proves their identity to the cloud.

Guest user (external identity) - A user from outside your tenant who has been invited through Microsoft Entra External ID (B2B collaboration). Guest users authenticate against their home identity provider (another Entra tenant, a Microsoft account, Google, or a one-time passcode) and are represented in your directory with a UserType of Guest.

UserType vs. Source

The UserType property can be either Member or Guest. The Source property indicates where the account originates (your directory, an external Entra tenant, a Microsoft account, etc.). These two properties are independent. An external user can be changed from Guest to Member, and an internal user can theoretically be marked as Guest (though this is uncommon). The exam tests this distinction.

💡 Exam Trap: UserType (Member vs. Guest) is independent from how the user authenticates. You can invite an external user and change their UserType to Member, giving them the same default directory permissions as internal users. Conversely, a user created inside the tenant can be set to Guest.

Default Permissions: Members vs. Guests

Member users and guest users have different default permissions within the directory.

Member users can: register applications, read all directory information (users, groups, applications), manage their own profile photo and phone number, change their own password, and invite B2B guests.

Guest users have restricted directory permissions by default. They can manage their own profile, change their own password, and retrieve some information about other users, groups, and apps. They cannot enumerate the full list of users, groups, or other directory objects.

Three levels of guest access restriction can be configured:

1. Same access as members - Guests have the same directory read permissions as members.
2. Limited access (default) - Guests are blocked from enumerating users, groups, and other objects but can see membership of non-hidden groups.
3. Most restrictive - Guests can only see their own profile; they cannot see other users, groups, or group memberships.

These settings are configured in External collaboration settings within the Entra admin center.

Creating Users: Portal, CLI, and PowerShell

Creating a cloud user via Azure CLI:

az ad user create \
 --display-name "Ioana Popescu" \
 --user-principal-name ioana@contoso.com \
 --password "T3mpP@ss123!" \
 --mail-nickname ioana \
 --force-change-password-next-sign-in true

Creating a cloud user via Azure PowerShell (Microsoft Graph module):

$passwordProfile = @{
 Password = "T3mpP@ss123!"
 ForceChangePasswordNextSignIn = $true
}

New-MgUser -DisplayName "Ioana Popescu" `
 -UserPrincipalName "ioana@contoso.com" `
 -PasswordProfile $passwordProfile `
 -AccountEnabled `
 -MailNickname "ioana"

Bulk Operations

The Azure portal supports bulk operations through CSV upload. You can bulk create, bulk invite, bulk delete, and bulk download users. The CSV template is downloadable from the portal and must follow the exact column format provided.

# Bulk invite guest users from a CSV via Azure CLI
az ad user invite-batch --file invitations.csv

For PowerShell, bulk creation is typically handled by looping through a CSV:

$users = Import-Csv -Path ".\newusers.csv"
foreach ($user in $users) {
 $passwordProfile = @{
 Password = $user.Password
 ForceChangePasswordNextSignIn = $true
 }
 New-MgUser -DisplayName $user.DisplayName `
 -UserPrincipalName $user.UPN `
 -PasswordProfile $passwordProfile `
 -AccountEnabled `
 -MailNickname $user.MailNickname
}

Deleted Users and the Soft-Delete Window

When you delete a user in Microsoft Entra ID, the account enters a soft-deleted state for 30 days. During this window the user can be restored with all group memberships and role assignments intact. After 30 days, the deletion becomes permanent and the account cannot be recovered.

💡 Exam Trap: Restoring a soft-deleted user restores the user object and its direct group memberships. However, any Azure RBAC role assignments at the subscription or resource group level are also preserved. The exam sometimes implies that role assignments are lost on delete; they are not, provided the user is restored within the 30-day window.

Groups in Microsoft Entra ID

Groups simplify permission management. Instead of assigning a role to 50 individual users, you assign it to one group that contains those 50 users.

Microsoft Entra ID supports two group types and two membership types:

Group Types:

1. Security group - Used to manage access to shared resources. Security groups can be assigned Azure RBAC roles, Entra directory roles (if the group is role-assignable), and application permissions.
2. Microsoft 365 group - Provides collaboration by giving members access to a shared mailbox, calendar, files (SharePoint), OneNote notebook, and Planner. Microsoft 365 groups can only have users (not other groups, service principals, or devices) as members.

Membership Types:

1. Assigned - Members are manually added and removed by an administrator or group owner.
2. Dynamic User - Membership is determined automatically by rules based on user attributes (department, jobTitle, city, etc.). When a user's attributes change, they are automatically added to or removed from matching dynamic groups.
3. Dynamic Device - (Security groups only) Membership is determined by device attributes such as deviceOSType or deviceOSVersion.

💡 Exam Trap: Microsoft 365 groups do not support Dynamic Device membership. Only Security groups can have Dynamic Device membership. Microsoft 365 groups support Assigned and Dynamic User membership only.

Dynamic Group Membership Rules

Dynamic membership rules use a property-based syntax. Here is an example that adds all users in the Marketing department with a jobTitle containing "Manager":

(user.department -eq "Marketing") and (user.jobTitle -contains "Manager")

Common operators: -eq, -ne, -contains, -startsWith, -match (regex), -in, -notIn.

The rule is evaluated whenever a user attribute changes. There can be a processing delay; Microsoft does not guarantee real-time evaluation.

A tenant can have a maximum of 15,000 dynamic groups and dynamic administrative units combined.

💡 Exam Trap: Dynamic group rules are evaluated by the system; users do not choose to join dynamic groups. If a question asks "how to ensure all members of the Finance department automatically get access to Resource X," the answer is a dynamic security group with a rule like (user.department -eq "Finance"), combined with a role assignment on the group.

Role-Assignable Groups

A role-assignable group is a special security group or Microsoft 365 group that can be assigned Microsoft Entra directory roles (such as Global Administrator or User Administrator). When you create a group, you must enable the isAssignableToRole property at creation time; it cannot be changed later.

Limits:

• A maximum of 500 role-assignable groups per tenant.
• Only users can be owners and members of role-assignable groups (not service principals or other groups).

Administrative Units

An administrative unit (AU) is a container in Microsoft Entra ID that restricts the scope of a directory role to a defined subset of users, groups, or devices. For example, you can create an AU called "Europe Employees," place European users in it, and assign a User Administrator role scoped only to that AU. The administrator can manage users inside the AU but not users outside it.

AUs do not affect Azure RBAC; they are a Microsoft Entra directory concept only. AUs support both assigned and dynamic membership.

Self-Service Password Reset (SSPR)

Self-Service Password Reset (SSPR) allows users to reset their own passwords without calling a helpdesk. SSPR can be enabled for None, Selected (a specific group), or All users. It requires at least one authentication method (email, phone, app notification, security questions, etc.), and you can require one or two methods.

💡 Exam Trap: SSPR and multi-factor authentication (MFA) registration can be combined into a unified registration experience. If a question mentions "combined registration," it refers to users registering their authentication methods once for both SSPR and MFA.

How Users and Groups Connect to the Next Section

Users and groups are the security principals that receive role assignments. Before you can control who has access to an Azure subscription or a specific virtual machine, you need identities to assign roles to. The next section covers exactly how those role assignments work through Azure RBAC.