Chapter 1

Microsoft Entra ID: users, groups and access

Everything in Azure starts with an identity. Before you can give someone access to a VNet or a storage account, that person (or app) must exist in Microsoft Entra ID. This chapter covers users, groups, licenses, guests and self-service password reset.

Tenants and subscriptions

A tenant is one dedicated instance of Entra ID for one organisation. It has a default domain like contoso.onmicrosoft.com and can have extra custom domains (like contoso.com) after you prove ownership with a DNS TXT or MX record.

The relationship between tenants and subscriptions is a classic exam topic:

• A subscription trusts exactly one tenant for sign-in. All RBAC role assignments in the subscription point to identities in that tenant.
• A tenant can have many subscriptions.
• You can move a subscription to another tenant ("Change directory"). When you do, all RBAC role assignments are deleted, and managed identities and Key Vault access must be fixed afterwards.

Entra ID editions

Many exam questions are really asking "which license do you need?" Remember the features that need P1, because they come up most:

A handy way to remember: P1 = automation and control (dynamic groups, group licensing, Conditional Access, SSPR). P2 = risk and privileged access (Identity Protection, PIM).

Users

There are two ways to look at a user: where it comes from and what type it is.

• Cloud-only user: created directly in Entra ID. You manage everything in Entra.
• Synchronized user: created in on-premises Active Directory and synced with Entra Connect or Entra Cloud Sync. Most properties (name, department, password) must be changed on-premises, not in the portal.
• Member vs Guest: the userType property. Members are "inside" the organisation; guests are external collaborators with fewer default permissions (for example, guests can't browse the full directory by default).

Important user properties for the exam:

• User principal name (UPN): the sign-in name, like ada@contoso.com. The domain part must be a verified domain in the tenant.
• Usage location: the country where the user works. A license cannot be assigned without it, because not every service is available in every country.
• Job info like department, jobTitle, companyName: often used in dynamic group rules.
• Manager: used by some workflows and by access reviews.

You can create users in the portal one at a time, with bulk create (download a CSV template, fill it in, upload it), with Microsoft Graph PowerShell (New-MgUser), with the Azure CLI (az ad user create) or through the Graph API. Bulk operations also exist for invite, delete and "download users".

When you delete a user, it goes to Deleted users for 30 days. Within that time you can restore it with all group memberships and licenses intact. After 30 days it is permanently removed.

Administrative units

An administrative unit (AU) is a container for users, groups or devices that lets you scope a directory role to part of the organisation. Example: the Benelux helpdesk gets the Helpdesk Administrator role scoped to the "Benelux" AU, so they can reset passwords only for Benelux users. Without AUs, directory roles apply to the whole tenant.

Directory roles you should know

Directory roles control what you can do in Entra ID itself (users, groups, settings). They are not the same as Azure RBAC roles like Owner or Contributor, which control Azure resources. Use the least privileged role that does the job:

Groups

Groups make administration scale: you give access, licenses or apps to a group once, and people inherit it by being a member. Groups have two settings that matter most.

Group type

• Security group: for access to resources (Azure RBAC, apps, file shares) and for licenses. Can contain users, devices, service principals and other groups.
• Microsoft 365 group: for collaboration. Comes with a shared mailbox, calendar, SharePoint site and optionally a Team. Contains users only (no devices, no nested groups).

Membership type

• Assigned: you add and remove members by hand (or a group owner does).
• Dynamic user: membership is calculated from a rule on user properties, for example (user.department -eq "IT") and (user.usageLocation -eq "NL"). You cannot add members manually.
• Dynamic device: a rule on device properties, for example (device.deviceOSType -eq "Windows"). Only for security groups.

A group's membership type can be changed later (assigned ↔ dynamic), but a group can't hold users and devices in one dynamic rule. Dynamic rules re-evaluate automatically when user properties change, which can take some minutes.

Other group settings worth recognising: group owners can manage membership without an admin role; "Microsoft Entra roles can be assigned to the group" must be set at creation time and can't be changed later; and group expiration and naming policies apply to Microsoft 365 groups.

Licenses

Licenses (Entra ID P1/P2, Microsoft 365 E3/E5 and so on) are bought per tenant and then assigned to users. There are two ways:

• Direct assignment: per user. Fine for a handful of people.
• Group-based licensing (needs P1): assign the license to a group, and every direct member gets it. You can also disable individual service plans inside a license (for example, assign Microsoft 365 E3 without Exchange). Combine with a dynamic group and licensing becomes fully automatic.

When group licensing fails for a user, the group shows an error state. The usual reasons are:

• Not enough licenses left in the tenant.
• Usage location missing on the user. Always set it when you create users.
• Conflicting service plans (two licenses that contain mutually exclusive plans).

External users (B2B)

B2B collaboration lets people from other organisations use their own identity (their work account, a Microsoft account, Google, or a one-time email passcode) to access your apps and resources. In your tenant they appear as a guest user object.

The invitation flow works like this:

1. An admin or allowed user invites the external email address (portal, bulk CSV, PowerShell or Graph).
2. Entra ID creates a guest user object with userType = Guest and sends an invitation email.
3. The person redeems the invitation by signing in with their own account and accepting the consent prompt. The guest object's state changes from Pending acceptance to Accepted.
4. You can now add the guest to groups, apps and Azure RBAC roles like any other user.

You control B2B in External Identities → External collaboration settings:

• Guest user access: how much of the directory guests can see (same as members, limited, or most restricted).
• Guest invite settings: who may invite (everyone, members only, only admins and the Guest Inviter role, or nobody).
• Collaboration restrictions: an allow list or a deny list of domains. You can use one or the other, not both.

A separate area, cross-tenant access settings, controls trust with specific other Entra tenants: whether you trust their MFA and device compliance claims, and which users and apps may collaborate inbound or outbound.

Self-service password reset (SSPR)

SSPR lets users reset their own forgotten password, which saves the helpdesk a lot of calls. You configure it under Protection → Password reset. The settings, in the order the portal shows them:

• Properties: who is enabled. None, Selected (exactly one group, nested groups count) or All. Use Selected to pilot.
• Authentication methods. Choose how many methods are required to reset (1 or 2) and which are available: Microsoft Authenticator notification or code, email, mobile phone (SMS or call), office phone, and security questions. Security questions can be used for SSPR only, never for MFA, and they are the weakest option.
• Registration. "Require users to register when signing in" (Yes/No), and the number of days before users must reconfirm their information (0–730).
• Notifications. Notify users when their password is reset; notify all admins when another admin resets.
• On-premises integration. Password writeback through Entra Connect or Cloud Sync, so that a reset in the cloud also changes the on-premises AD password. Needs P1.

Two behaviours surprise people:

• Administrators always have SSPR enabled, regardless of the setting above, and they must use two methods (no security questions). This is a separate, stronger policy you can't weaken.
• Users register SSPR and MFA methods on the same page (combined registration at aka.ms/mysecurityinfo). The actual reset happens at aka.ms/sspr or via the "Forgot my password" link on the sign-in page.

Self-check

You create two users and two groups. The group az104-admins is the one you give Azure permissions to in chapter 2, so keep it.

1. Task

   Find out which Entra ID edition you have

   Find your tenant's license edition. Steps 4 and 6 need P1. If you have Free, start a free 30-day Entra ID P2 trial (P2 includes P1), or skip those steps.

   Done when

   • You know whether you have Free, P1 or P2.
   Solution · Portal

   Microsoft Entra admin center → Overview: the License field. For a trial: Billing → Licenses → All products → Try / Buy (or the Microsoft 365 admin center → Billing → Purchase services).

2. Task

   Create two users

   Create these cloud users. Use a password you'll remember for Ada; you need it for the SSPR test.

   UPN	Display name	Department	Usage location
   az104-ada@<your domain>	Ada (AZ-104)	IT	your country
   az104-ben@<your domain>	Ben (AZ-104)	Finance	your country

   Done when

   • Both users show in All users with the right department and usage location.
   Solution · Portal

   1. Users → All users → New user → Create new user.
   2. Basics: UPN and display name; choose or auto-generate a password.
   3. Properties: set Department and Usage location.
   4. Review + create. Repeat for Ben.
   Solution · Azure CLI

   DOMAIN=$(az rest --url https://graph.microsoft.com/v1.0/domains --query "value[?isDefault].id" -o tsv)
   az ad user create --display-name "Ada (AZ-104)" --user-principal-name az104-ada@$DOMAIN --password '<choose-a-strong-password>'
   az ad user create --display-name "Ben (AZ-104)" --user-principal-name az104-ben@$DOMAIN --password '<choose-a-strong-password>'
   
   # az ad user create has no department flag, so set it through Microsoft Graph
   az rest --method PATCH --url "https://graph.microsoft.com/v1.0/users/az104-ada@$DOMAIN" \
     --body '{"department":"IT","usageLocation":"NL"}'
   az rest --method PATCH --url "https://graph.microsoft.com/v1.0/users/az104-ben@$DOMAIN" \
     --body '{"department":"Finance","usageLocation":"NL"}'

3. Task

   Create the group az104-admins

   Create a security group with assigned membership called az104-admins. You are the owner and Ada is a member. Chapter 2 gives this group Azure permissions.

   Done when

   • The group's Members shows Ada and Owners shows you.
   Solution · Portal

   Groups → All groups → New group: Group type Security, name az104-admins, Membership type Assigned. Under Owners add yourself, under Members add Ada. Create.

   Solution · Azure CLI

   az ad group create --display-name az104-admins --mail-nickname az104-admins
   az ad group member add --group az104-admins --member-id $(az ad user show --id az104-ada@$DOMAIN --query id -o tsv)
   az ad group owner add  --group az104-admins --owner-object-id $(az ad signed-in-user show --query id -o tsv)

4. Task · needs P1

   Create a group that fills itself

   Create a security group az104-dept-it that automatically contains every user whose department is IT, including future hires. Before saving, test your rule against Ada and Ben.

   Optional: assign your trial license to this group, then remove Ada's usage location and see what the group reports.

   Done when

   • After a few minutes Ada is a member, Ben isn't.
   • You notice you can't add members by hand. Why not?
   Hint

   Membership type Dynamic User. The rule uses the property user.department.

   Solution · Portal

   1. Groups → New group: type Security, name az104-dept-it, Membership type Dynamic User.
   2. Add dynamic query: property department, operator Equals, value IT. Rule text: (user.department -eq "IT").
   3. Tab Validate rules: add Ada and Ben and check the result. Save → Create.
   4. Optional: Billing → Licenses → All products → your license → Assign → group az104-dept-it.
   Solution · Azure CLI (through Graph)

   az rest --method POST --url https://graph.microsoft.com/v1.0/groups --body '{
     "displayName": "az104-dept-it", "mailNickname": "az104-dept-it",
     "mailEnabled": false, "securityEnabled": true,
     "groupTypes": ["DynamicMembership"],
     "membershipRule": "(user.department -eq \"IT\")",
     "membershipRuleProcessingState": "On" }'

5. Task

   Invite a guest

   First find out who is allowed to invite guests in your tenant and whether there is a domain allow/deny list (just look, don't change). Then invite another email address of your own (a personal Outlook or Gmail) as a B2B guest and redeem the invitation.

   Done when

   • The guest shows User type: Guest and Invitation state: Accepted.
   Solution · Portal

   1. External Identities → External collaboration settings: read Guest invite settings and Collaboration restrictions.
   2. Users → New user → Invite external user: enter the email, Review + invite.
   3. Open the mail, click Accept invitation, sign in and accept the consent prompt.
   Solution · Azure CLI (through Graph)

   az rest --method POST --url https://graph.microsoft.com/v1.0/invitations --body '{
     "invitedUserEmailAddress": "<your-other-email>",
     "inviteRedirectUrl": "https://myapps.microsoft.com",
     "sendInvitationMessage": true }'

6. Task · needs P1

   Turn on self-service password reset for a pilot group

   Enable SSPR only for members of az104-admins. Users need one method, either email or the Authenticator app notification, and must register when they sign in.

   Test it (optional, 5 min): sign in as Ada in a private window, register methods, sign out, then reset her password yourself.

   Done when

   • The Password reset Properties show Selected → az104-admins.
   • (Optional) Ada reset her own password.
   Solution · Portal

   1. Protection → Password reset → Properties: Selected, group az104-admins. Save.
   2. Authentication methods: number required 1; tick Email and Mobile app notification. Save.
   3. Registration: require users to register when signing in = Yes. Save.
   4. Test: private window → https://myaccount.microsoft.com as Ada (MFA registration is also asked) → sign out → https://aka.ms/sspr.