Lesson 02 — Microsoft Entra ID: Users, Groups & Identities
Why You Need to Understand This
Every RBAC role assignment, every managed identity, every service calling the Azure API — all of it resolves against Microsoft Entra ID (formerly Azure Active Directory). Entra ID is not just a directory; it is the authentication and identity plane for the entire Azure control surface. RBAC says what a principal can do; Entra ID determines who the principal is.
In the exam, roughly half of all identity questions hinge on knowing the difference between identity object types: member user vs. guest, service principal vs. managed identity, app registration vs. enterprise application. In production, conflating these leads to over-privileged service accounts, unrotated secrets, and hybrid sync failures that take hours to diagnose.
The Tenant as an Identity Boundary
Recall from Lesson 01 that a tenant is the top-level container. From an identity perspective, the tenant is the trust boundary: every identity object (user, group, service principal, managed identity) has exactly one home tenant. Authentication decisions made by Entra ID are always relative to a tenant.
User Types: Members, Guests, and Hybrid Accounts
Member users vs. Guest users
| Property | Member User | Guest User (B2B) |
|---|---|---|
| Home tenant | This tenant — the object was created here | Another tenant or external IdP — invited via B2B |
| Default permissions | Can read directory objects (users, groups) by default | Highly restricted directory read permissions by default |
| UPN format | user@contoso.com | user_externaldomain.com#EXT#@contoso.onmicrosoft.com |
| Licensing | Requires a license in this tenant | 5:1 external guest ratio — 5 guests per P1/P2 license |
| Typical use case | Employees, internal service accounts | Contractors, partners, vendor access to Azure resources |
UPN vs. email address — a critical distinction
The User Principal Name (UPN) is the login identifier Entra ID uses for authentication. It looks like an email address (jsmith@contoso.com) but it is not necessarily the same as the user's email address. When users sign into the Azure portal or any Microsoft service, they authenticate with their UPN — the email address in Exchange may differ. This distinction becomes critical in hybrid environments.
corp.local, contoso.internal. These cannot be used as UPNs in Entra ID because they are not verifiable internet domains. Before syncing users from on-prem AD, you must either add a routable UPN suffix (e.g. contoso.com) to the on-prem forest and update user accounts, or configure Alternate Login ID so users sign in with their email attribute instead of UPN. Failing to do this is one of the most common hybrid identity deployment mistakes.
On-premises sync: Entra Connect Sync
Microsoft Entra Connect Sync (formerly Azure AD Connect) is the agent installed on a domain-joined Windows Server that synchronises identities from on-prem Active Directory to Entra ID. Understanding the sync model is essential for hybrid environments.
| Authentication Method | How it works | When to use |
|---|---|---|
| Password Hash Sync (PHS) | Hash of the password hash is synced to Entra ID. Auth happens in the cloud — no on-prem dependency for sign-in. | Default and recommended for most organisations. Provides leaked credential detection via Identity Protection. |
| Pass-Through Authentication (PTA) | Entra ID passes credentials to an on-prem PTA agent for validation. Password never leaves on-prem. | Organisations with strict policy that passwords must not leave on-premises, but no ADFS infrastructure. |
| Federation (ADFS) | Entra ID trusts an on-prem ADFS farm as the authentication authority. Entra ID defers auth entirely to ADFS. | Complex claims requirements, smartcard auth, organisations already invested in ADFS. Highest complexity, highest risk of outage. |
Groups: Security, Microsoft 365, and Dynamic Membership
Security groups vs. Microsoft 365 groups
| Property | Security Group | Microsoft 365 Group |
|---|---|---|
| Purpose | RBAC role assignments, policy targeting, app assignments, group-based licensing | Collaboration: shared mailbox, calendar, Teams, SharePoint site |
| Can be used for Azure RBAC? | Yes — the primary group type for RBAC | Yes — but only when the group is mail-enabled security type or the M365 group is used directly |
| Can contain guest users? | Yes | Yes |
| Can be nested in other groups? | Yes — Azure RBAC respects nested group inheritance | No — M365 groups cannot be nested |
| Dynamic membership | Yes (requires P1) | Yes (requires P1) |
Assigned vs. Dynamic membership
Assigned membership means group members are added and removed manually by an administrator or group owner. Simple, but operationally expensive at scale.
Dynamic membership uses a rule expression to automatically add or remove users (or devices, for device groups) based on their Entra ID attributes. The group membership is continuously evaluated and updated — no manual intervention required.
Dynamic rule syntax examples:
# All Finance department members (not guests)
(user.department -eq "Finance") -and (user.userType -eq "Member")
# All users with a US usage location who have a job title containing "Engineer"
(user.usageLocation -eq "US") -and (user.jobTitle -contains "Engineer")
# All enabled accounts in the Sales department
(user.department -eq "Sales") -and (user.accountEnabled -eq true)
# Device rule: all Windows 10/11 devices enrolled via Intune
(device.deviceOSType -eq "Windows") -and (device.managementType -eq "MDM")Nested groups and Azure RBAC
Azure RBAC does evaluate nested group membership. If Group A is a member of Group B, and Group B has the Contributor role on a subscription, then users in Group A are effective Contributors on that subscription through transitive membership. This is the correct behaviour and differs from some other systems (e.g., on-prem AD RBAC evaluation varies by application).
Service Principals: Application Identities
A service principal is an identity for an application or service in your Entra ID tenant. When an application needs to call Azure APIs, Microsoft Graph, or any Entra-protected resource, it authenticates as a service principal — not as a human user.
App Registration vs. Enterprise Application
This is one of the most confusing conceptual distinctions in Entra ID, and it appears on the exam:
| Object | What it is | Where it lives |
|---|---|---|
| App Registration | The application definition — defines what the app is, what permissions it requests, redirect URIs, token lifetimes | The tenant where the app is registered (the developer's tenant) |
| Enterprise Application (Service Principal) | The instantiation of the app in a specific tenant — this is what is actually used for authentication and permission grants | Every tenant where the app is consented to. A multi-tenant app has one App Registration but an Enterprise Application in every tenant that uses it. |
Client credentials: secret vs. certificate
| Credential Type | How it works | Production recommendation |
|---|---|---|
| Client Secret | A generated string value, like a password. Sent directly in the token request. Has an expiry (max 24 months). | Avoid in production. Secrets leak into logs, environment variables, and source code. Requires active rotation management. |
| Client Certificate | The app signs the token request with a private key; Entra ID validates using the registered public key. The private key never leaves the application environment. | Preferred when service principals must be used. Store the certificate in Azure Key Vault and use the Key Vault reference in your application. |
| Federated Credential (OIDC) | No credential at all — an external identity provider's token (e.g. GitHub Actions OIDC token) is exchanged for an Entra ID access token via Workload Identity Federation. | Best practice for CI/CD pipelines. Zero long-lived credentials. No rotation required. |
Managed Identities: The Right Way to Authenticate Azure Resources
A managed identity is a service principal whose lifecycle and credentials are fully managed by Azure. You never see the credential. You cannot export it. Azure rotates it automatically. This eliminates the entire credential management problem.
System-assigned vs. User-assigned
| Property | System-assigned | User-assigned |
|---|---|---|
| Creation | Enabled directly on an Azure resource (VM, Function App, etc.) | Created as a standalone Azure resource first, then assigned to one or more resources |
| Lifecycle | Tied to the resource — deleted when the resource is deleted | Independent lifecycle — deleting the resource does not delete the identity |
| Scope of use | One resource only — cannot be shared | Can be assigned to multiple resources simultaneously |
| Entra ID object | Creates a service principal in the tenant, auto-deleted with resource | Creates a service principal in the tenant, persists until the managed identity resource is deleted |
| Best for | Single VM or App Service with a unique identity requirement | Multiple resources sharing the same identity (e.g. a fleet of VMs needing Key Vault access) |
How managed identity authentication works (IMDS)
When code running on an Azure resource (VM, App Service, Function App, AKS pod) needs an access token, it calls the Azure Instance Metadata Service (IMDS) — a non-routable REST endpoint available from within every Azure resource:
GET http://169.254.169.254/metadata/identity/oauth2/token
?api-version=2018-02-01
&resource=https://vault.azure.net
Metadata: trueIMDS returns an access token for the managed identity's service principal. The application uses this token to authenticate to Key Vault, Storage, or any other Entra-protected resource — with zero credentials in the application code or configuration.
Entra ID License Tiers and What Each Unlocks
Understanding the license tier gates is essential both for the exam and for production architecture decisions. Many governance features require Premium licensing.
| Feature | Free | P1 | P2 |
|---|---|---|---|
| User and group management | ✓ | ✓ | ✓ |
| SSO (up to 10 apps) | ✓ | ✓ | ✓ |
| MFA per-user (basic) | ✓ | ✓ | ✓ |
| Dynamic group membership | ✗ | ✓ | ✓ |
| Conditional Access policies | ✗ | ✓ | ✓ |
| Group-based application assignment | ✗ | ✓ | ✓ |
| Self-service password reset (hybrid) | ✗ | ✓ | ✓ |
| Identity Protection (risky sign-in policies) | ✗ | ✗ | ✓ |
| Privileged Identity Management (PIM) | ✗ | ✗ | ✓ |
| Access Reviews | ✗ | ✗ | ✓ |
| Entitlement Management | ✗ | ✗ | ✓ |
Hands-On: Create, Inspect, and Assign Identities
Work through these steps in portal.azure.com. Use a non-production tenant or a Visual Studio subscription if available.
- Create a member user: Navigate to Microsoft Entra ID → Users → New user → Create new user. Set a UPN, display name, and temporary password. Note the UPN format — it uses your tenant's verified domain. Assign no roles.
-
Create a dynamic security group: Go to Groups → New group. Select Security type and Dynamic User membership type. Add the rule:
(user.department -eq "Engineering"). Save and observe that the member list shows "No members" until user department attributes are set — this is intentional and expected behaviour. -
Create an App Registration: Navigate to App registrations → New registration. Give it a name (e.g.
app-demo-01). Accept defaults. After creation, note the Application (client) ID and Directory (tenant) ID. Go to Certificates & secrets → New client secret — add one with a short expiry. Then go to Enterprise applications and find the corresponding Enterprise Application that was auto-created. This is the service principal object. - Assign a system-assigned managed identity to a VM: Open a VM → Security → Identity → System assigned. Toggle the Status to On and Save. Azure creates a service principal in Entra ID with the same name as the VM. Verify by going to Entra ID → Enterprise applications → All applications and searching for the VM name — the managed identity service principal will appear there.
- Grant the managed identity Key Vault access: Navigate to a Key Vault → Access control (IAM) → Add role assignment. Select Key Vault Secrets User. In the Members step, choose Managed identity and select your VM's identity. The VM can now read secrets from Key Vault using the IMDS endpoint — no stored credentials anywhere.
Check Your Understanding
Click any option to see immediate feedback. These questions reflect real exam reasoning and production decision-making.
1. A service running on a VM needs to read secrets from Azure Key Vault. What identity approach should you use?
2. Your on-prem AD syncs users to Entra ID via Entra Connect. A user's UPN in on-prem AD is jsmith@corp.local (a non-routable domain). What must you configure for this user to sign into Azure?
.local domain cannot be verified, so Entra Connect cannot sync the UPN as-is. The correct fix is to add a routable suffix (e.g. contoso.com) to the on-prem AD forest, update user UPNs in AD, and allow Connect to sync them — or enable Alternate Login ID so users authenticate with their email attribute. Creating shadow accounts (C) creates a management nightmare with two identities per person.3. What is the fundamental difference between a system-assigned and user-assigned managed identity?
4. You need to control Azure resource access for 500 developers using dynamic group membership based on their department attribute. What license tier is required?
5. You register an application in Entra ID so it can call Microsoft Graph API. What objects are created in the tenant?
6. You want a CI/CD pipeline to authenticate to Azure without storing any long-lived credentials. What is the recommended approach in 2026?
Also read: Managed identities for Azure resources overview and Workload Identity Federation. These three articles cover 80% of the identity questions in AZ-104.
This lesson covered the identity object model. There is much more to explore — ask your teacher to go deeper on any of these:
- Walk me through configuring Workload Identity Federation for a GitHub Actions pipeline end-to-end.
- What happens to a synced user's attributes if the Entra Connect sync service goes offline for 3 days?
- How does Entra ID B2B differ from B2C — and when would you use each for a partner access scenario?
- Explain how Conditional Access policies interact with managed identities — can you apply CA to a managed identity?