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, then how people sign in (SSO, MFA, passwordless), Conditional Access, and Entra Domain Services for apps that still need a classic domain.

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.

Signing in: SSO, MFA and passwordless

Two words that are easy to mix up:

• Authentication (AuthN): proving who you are. That's what this section and Conditional Access are about.
• Authorization (AuthZ): deciding what you may do once you're known. In Azure that's mostly RBAC (chapter 2).

Single sign-on (SSO)

With single sign-on, a user signs in once with one identity and then opens many applications without signing in again. Entra ID acts as the identity provider: apps trust its tokens through standard protocols like SAML, OpenID Connect and OAuth 2.0.

• Thousands of SaaS apps (Salesforce, ServiceNow…) are ready to configure in the Enterprise applications gallery.
• Your own apps register in App registrations.
• Older on-premises web apps can be published with Entra application proxy (part of Entra Private Access).

Why it matters for security, not just comfort: one strong identity instead of many weak passwords, one place to enforce MFA and Conditional Access, and one account to disable when someone leaves.

Multifactor authentication (MFA)

MFA asks for two or more different kinds of proof:

• Something you know: a password or PIN.
• Something you have: a phone with the Authenticator app, a security key.
• Something you are: a fingerprint or face (biometrics).

There are three ways to turn MFA on in a tenant. Use only one of them:

Separately from your tenant settings, Microsoft itself now requires MFA for everyone who signs in to the Azure portal, CLI, PowerShell and other Azure management tools (chapter 0).

Passwordless authentication

Passwords are the weakest link: they can be guessed, reused and phished. Passwordless methods replace the password with something you have plus a PIN or biometric, so every sign-in is automatically multifactor:

You enable these in Protection → Authentication methods → Policies. Windows Hello, FIDO2 passkeys and certificates are phishing-resistant: a fake website can't reuse them. With Conditional Access you can require exactly that through an authentication strength such as "Phishing-resistant MFA".

Conditional Access

Conditional Access is Entra ID's policy engine. Each policy is an if-then statement: if a sign-in matches these conditions, then block it or grant it with requirements. Policies run after the first factor (the password), and every policy that matches applies.

Things you need to know to work with it safely:

• License: Conditional Access needs P1. Conditions based on sign-in risk and user risk come from Identity Protection and need P2.
• Named locations: your office IP ranges or countries, used to include or exclude locations ("require MFA except from the office").
• Report-only mode: the policy is evaluated and logged in the sign-in logs, but not enforced. Always start here.
• What If tool: simulates a sign-in (user, app, location…) and lists which policies would apply.
• Emergency access ("break-glass") accounts: two cloud-only admin accounts, excluded from your policies, so a bad policy can't lock everyone out.

Microsoft Entra Domain Services

Entra ID is not a classic Active Directory domain: it has no LDAP, no Kerberos/NTLM for old apps, no Group Policy and no domain join in the traditional sense. Many older applications need exactly those. Microsoft Entra Domain Services gives you a managed domain that provides them, without running domain controllers yourself:

• You deploy it into a subnet of a VNet. Microsoft runs two domain controllers for you, and patches and backs them up.
• Users, groups and password hashes are synchronised one way from Entra ID into the managed domain. Users sign in with their existing credentials. (Cloud-only users must change their password once after you enable it, so a hash is generated.)
• VMs in the VNet can domain-join, use LDAP and Kerberos, and receive Group Policy.
• Limits: you get no Domain Admin or Enterprise Admin rights, can't extend the schema, and can't add your own domain controllers.

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, 6 and 7 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

   # Variables for this task
   DOMAIN=$(az rest --url https://graph.microsoft.com/v1.0/domains --query "value[?isDefault].id" -o tsv)
   
   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.
7. Task · needs P1

   Require MFA for admins, without locking anyone out

   Create a Conditional Access policy ca-az104-admins-mfa that requires multifactor authentication for members of az104-admins on all resources. It must run in report-only mode, and it must not apply to your own admin account.

   Then prove, without signing in as Ada, that the policy would apply to her.

   Done when

   • The policy list shows ca-az104-admins-mfa with state Report-only.
   • The What If tool lists the policy under "Policies that will apply" for Ada, and not for Ben.
   Hint

   If the portal won't let you create or turn on the policy, check whether security defaults are still enabled (Overview → Properties → Manage security defaults). In a lab tenant you may turn them off; your Conditional Access policy then takes over. You turn them back on in the chapter 10 cleanup.

   Solution · Portal

   1. Entra admin center → Protection → Conditional Access → Policies → + New policy. Name ca-az104-admins-mfa.
   2. Users: Include → Select users and groups → az104-admins. Exclude → your own admin account (your break-glass safety net).
   3. Target resources: All resources (formerly "All cloud apps").
   4. Grant: Grant access, tick Require multifactor authentication → Select.
   5. Enable policy: Report-only → Create.
   6. Policies → What If: user Ada, target Any resource (or "All resources") → What If. The policy appears under Policies that will apply. Repeat for Ben: it appears under Policies that will not apply with the reason "Users and groups".
   7. Optional: sign in as Ada in a private window, then look at Monitoring → Sign-in logs → her sign-in → Report-only tab: the result shows what would have happened.