This chapter covers Microsoft Entra ID (formerly Azure Active Directory), the foundational identity service for Azure and Microsoft 365. For the AZ-500 exam, understanding Entra ID is critical as it underpins identity security, authentication, authorization, and conditional access. Approximately 30-35% of the exam questions touch on identity topics, with a significant portion directly related to Entra ID configuration, protection, and management. Master this chapter to secure the largest weight on the exam.
Jump to a section
Think of Microsoft Entra ID as a corporate badge system for a multinational company. Each employee (user) receives a badge (identity) that contains their photo, name, and roles (attributes). When an employee wants to enter a building (access a resource), they swipe their badge at a reader (authentication). The reader checks the badge against a central database (Entra ID directory) to verify the badge is valid and not expired. If valid, the reader then checks a list of allowed access levels (conditional access policies) to determine if the employee is permitted to enter that specific building at that time and from that entrance. For example, a junior employee might only have access to the ground floor (low-risk apps) during business hours, while a manager can access the executive floor (high-value resources) only from a specific entrance (trusted device) and after entering a PIN (MFA). The system also logs every swipe attempt (audit logs) and can revoke a badge instantly if an employee is terminated (disable account). This centralized system replaces having separate keys for every door, mirroring how Entra ID provides single sign-on and centralized identity management across all Azure and Microsoft 365 resources.
What is Microsoft Entra ID?
Microsoft Entra ID (Entra ID) is a cloud-based identity and access management (IAM) service. It provides authentication and authorization for users, devices, and applications. Unlike on-premises Active Directory (AD DS), which uses Kerberos and LDAP, Entra ID is REST-based and uses modern protocols like OAuth 2.0, OpenID Connect, and SAML. Entra ID is multi-tenant, meaning it can support multiple organizations (tenants) with isolated directories.
Why Entra ID Exists
Traditional on-premises AD was designed for corporate networks where users and resources are inside a physical perimeter. With cloud services (SaaS, PaaS, IaaS), the perimeter is gone. Entra ID provides a unified identity plane across Azure, Microsoft 365, and thousands of third-party SaaS applications. It enables single sign-on (SSO), multi-factor authentication (MFA), and conditional access to protect resources regardless of location.
How Entra ID Works Internally
Entra ID is built on a distributed, multi-tier architecture. The core components are:
Directory Store: A highly available, replicated database that stores objects (users, groups, devices, applications) and their attributes. Each tenant has its own isolated directory. The directory is partitioned across multiple regions for resilience.
Authentication Service: Handles authentication requests. For cloud-native users, it validates password hashes (cloud-only) or uses password hash sync (PHS), pass-through authentication (PTA), or federation (e.g., AD FS) for hybrid users. It issues tokens (ID tokens, access tokens, refresh tokens) after successful authentication.
Token Service: Issues security tokens. For OAuth 2.0, the token service issues access tokens (JWT) containing claims about the user and app permissions. The token lifetime defaults to 60-90 minutes, configurable via conditional access or token lifetime policies.
Policy Engine: Evaluates conditional access policies during authentication. It checks conditions like user risk, device compliance, location, and application sensitivity before granting access.
Audit and Reporting: Logs all sign-in events, audit logs, and provisioning logs. These are retained for 30 days by default (up to 7 years with Azure Monitor).
Key Components, Values, and Defaults
Tenant: A dedicated instance of Entra ID. Created when signing up for Azure or Microsoft 365. Default domain: .onmicrosoft.com. Custom domains can be added (up to 900 per tenant).
User Types: Cloud-only (created in Entra ID), guest (B2B collaboration), and synced (from on-premises AD via Azure AD Connect).
Groups: Security groups (for permissions) and Microsoft 365 groups (for collaboration). Group types: Assigned (static) and Dynamic (membership based on user attributes). Dynamic groups can take up to 30 minutes to update.
Roles: Built-in roles (e.g., Global Administrator, User Administrator) and custom roles. Global Administrator has full access; there are over 60 built-in roles.
MFA: Available via conditional access or per-user MFA. Per-user MFA is legacy; Microsoft recommends using conditional access MFA. Default MFA methods: Microsoft Authenticator app, SMS, voice call. Number matching for app notifications is enforced since May 2023.
Password Policies: Default password expiration is 90 days for cloud-only users (if not disabled). Password length minimum 8 characters. Complexity requirements: 3 out of 4 (uppercase, lowercase, number, symbol).
Device Registration: Devices can be registered (Azure AD registered) or joined (Azure AD joined or hybrid Azure AD joined). Device identities are used for conditional access device compliance.
Configuration and Verification Commands
PowerShell (AzureAD module) – note: AzureAD module is deprecated; use Microsoft Graph PowerShell SDK.
# Connect to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All","Group.Read.All"
# Get all users
Get-MgUser -All
# Get conditional access policies
Get-MgIdentityConditionalAccessPolicy
# Get sign-in logs
Get-MgAuditLogSignIn -Filter "createdDateTime ge 2023-01-01"Azure CLI
# List users
az ad user list
# List groups
az ad group list
# Get conditional access policies (via REST)
az rest --method get --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies"Entra Admin Center: All configurations can be done via the portal under Azure Active Directory (now Microsoft Entra ID).
Interaction with Related Technologies
Azure AD Connect: Syncs on-premises AD objects to Entra ID. Supports password hash sync, pass-through authentication, and federation. Requires a server with Azure AD Connect installed. Sync interval default is 30 minutes.
Conditional Access: Uses Entra ID as the policy decision point. Policies are evaluated after user authentication. Can enforce MFA, block access, or require compliant device.
Identity Protection: Uses machine learning to detect risky sign-ins and users. Risk levels: low, medium, high. Can be integrated with conditional access to auto-remediate (e.g., force password change).
Privileged Identity Management (PIM): Provides just-in-time (JIT) privileged access to Azure AD roles and Azure resources. Requires activation with MFA and approval.
Enterprise Applications: Represent SaaS apps or custom apps that use Entra ID for authentication. Each app has a service principal in the tenant. Permissions (delegated vs. application) are granted via consent.
Managed Identities: Azure resources (e.g., VMs, App Services) can get an identity in Entra ID to authenticate to other Azure services without storing credentials.
Security Features Specific to Entra ID
Password Protection: Blocks weak passwords and common password patterns. Custom banned password lists can be created. Enforced for cloud-only and synced users.
Smart Lockout: Locks an account after a configurable number of failed sign-ins (default 10) for a configurable duration (default 60 seconds). It uses smart lockout to differentiate between legitimate users and attackers.
Hybrid Identity: For organizations with on-premises AD, Azure AD Connect provides seamless SSO (PHS with seamless SSO) so users don't need to enter passwords again on corporate devices.
Common Misconfigurations and Their Impact
Not enabling MFA for all users: Leaves accounts vulnerable to password spray attacks. Attackers can compromise accounts without MFA.
Overly permissive conditional access policies: Granting access to all apps from any location increases attack surface.
Ignoring guest user access: B2B guests should have limited permissions. Default guest permissions allow them to see other users; this can be restricted.
Using per-user MFA instead of conditional access: Per-user MFA is less flexible and doesn't allow policies based on risk or device state.
Exam-Relevant Details
Tenant ID: A GUID that identifies the Entra ID tenant. Used in OAuth requests.
Authentication methods: Microsoft Authenticator, FIDO2 security keys, Windows Hello for Business, certificate-based authentication (CBA).
Token endpoints: https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
Default token lifetime: Access tokens 60-90 minutes, refresh tokens up to 90 days (if not revoked).
Conditional access conditions: User/group, cloud apps, IP location, device platform, client app, sign-in risk, user risk, device state.
PIM activation duration: Default 1 hour, max 8 hours.
Identity Protection user risk policy: Can block or allow password change. Sign-in risk policy can block or require MFA.
Step-by-Step: Configuring Conditional Access with MFA
Create a policy in the Entra admin center under Security > Conditional Access.
Assign users: Select all users or specific groups. Exclude break-glass accounts.
Target cloud apps: Select Office 365 (or specific apps like Azure Management).
Conditions: Set location (e.g., block access from untrusted countries), device platform, client app.
Grant controls: Require MFA, require compliant device, or require approved client app.
Enable policy: Set to "Report-only" first to test, then "On".
Monitor: Use sign-in logs to see if the policy is applied.
Trap: Candidates often forget that conditional access policies are evaluated after authentication, so if a user fails authentication, the policy is not evaluated. Also, policies apply only to interactive sign-ins, not to background service calls unless configured.
Create Entra ID Tenant
An Entra ID tenant is created automatically when you sign up for Azure or Microsoft 365. You can also create a new tenant from the Azure portal by selecting 'Create a resource' > 'Identity' > 'Microsoft Entra ID'. Provide an organization name and initial domain (e.g., contoso.onmicrosoft.com). Each tenant is isolated with its own directory and endpoints. For the exam, remember that a tenant can have multiple subscriptions but a subscription can only trust one tenant.
Configure Custom Domain
Add a custom domain (e.g., contoso.com) to the tenant. In the portal, go to 'Custom domain names' and add the domain. Then verify ownership by adding a TXT record to your DNS. After verification, you can set the custom domain as primary. Up to 900 custom domains are supported. This step is important for user principal names (UPNs) to match the organization's domain.
Create Users and Groups
Users can be created directly in Entra ID (cloud-only) or synced from on-premises AD via Azure AD Connect. For the exam, know that cloud-only users have passwords stored as hashes in Entra ID. Groups can be assigned (static membership) or dynamic (based on user attributes like department). Dynamic group membership evaluation can take up to 30 minutes. Groups are used to assign permissions and as targets for conditional access policies.
Enable Multi-Factor Authentication
Enable MFA via conditional access for better control. Create a conditional access policy that targets all users or specific groups, selects all cloud apps, and sets grant controls to 'Require multi-factor authentication'. Exclude break-glass accounts. Alternatively, per-user MFA can be enabled (legacy). Microsoft Authenticator is the preferred method; it supports number matching for verification. MFA is a key control to protect against credential theft.
Configure Conditional Access Policy
Conditional access policies are the primary way to enforce access controls. Define conditions such as user/group membership, location (IP ranges or countries), device platform, client app, and sign-in risk. Grant controls include requiring MFA, requiring compliant device, requiring hybrid Azure AD joined device, or requiring approved client app. Session controls include app enforced restrictions. Polices are evaluated in order; if multiple policies apply, all grant controls must be satisfied.
Set Up Identity Protection
Identity Protection (requires Azure AD Premium P2) uses machine learning to detect risky sign-ins and users. Configure user risk policy to block high-risk users or require password change. Configure sign-in risk policy to block or require MFA for medium or high-risk sign-ins. Risk levels are low, medium, high. The service aggregates signals like leaked credentials, atypical travel, and anonymous IP addresses. Integration with conditional access allows automated remediation.
Implement Privileged Identity Management
PIM provides just-in-time privileged access to Azure AD roles and Azure resources. Activate a role for a limited time (default 1 hour, max 8 hours) with approval and MFA. PIM can also require justification and ticket number. Use PIM to reduce standing admin access. For the exam, know that PIM supports both Azure AD roles and Azure RBAC roles. It also provides access reviews to audit privileged access.
Enterprise Scenario 1: Hybrid Identity with Azure AD Connect
A large enterprise with 50,000 on-premises AD users migrates to Microsoft 365. They deploy Azure AD Connect with password hash sync (PHS) and seamless SSO. Users authenticate to Entra ID with their corporate credentials, and passwords are synced every 30 minutes. The organization enables MFA via conditional access for all users accessing Office 365 from outside the corporate network. They also use Azure AD Application Proxy to publish on-premises web apps securely. Common issue: if Azure AD Connect server fails, password changes are not synced until it is restored. They set up a staging server for high availability. Performance: sync of 50,000 objects takes about 30-60 minutes initially; incremental syncs are faster.
Enterprise Scenario 2: B2B Collaboration for Partner Access
A company uses Entra ID B2B to grant external partners access to SharePoint Online and a custom SaaS app. They invite partners via email; each partner gets a guest user object in the tenant. They configure conditional access to require MFA for guests and restrict access to specific IP ranges. They also set guest user permissions to limited (can't see other users). Misconfiguration: if guest user permissions are too broad, partners can enumerate the tenant. They use access reviews to periodically review guest access. Scale: up to 500,000 guests can be added per tenant.
Enterprise Scenario 3: Zero Trust with Conditional Access and Device Compliance
A financial services company enforces Zero Trust by requiring all devices accessing corporate resources to be compliant. They use Microsoft Intune for device management and conditional access to require 'Device to be marked as compliant'. Devices must be enrolled in Intune, have encryption enabled, and have up-to-date antivirus. If a device is not compliant, access is blocked with a message to enroll. They also use session controls to limit download of sensitive files. Problem: if Intune enrollment fails, users cannot access any resources; they set up a grace period for compliance. Performance: conditional access evaluation adds about 1-2 seconds to authentication.
Objective Codes and Exam Focus
AZ-500 objective 1.1: 'Secure Microsoft Entra ID'. This includes configuring MFA, conditional access, identity protection, PIM, and managing Azure AD roles. The exam expects you to know the difference between Azure AD roles and Azure RBAC roles. Also, understand when to use PIM vs. just-in-time VM access.
Common Wrong Answers and Why
'Per-user MFA is more secure than conditional access MFA' – False. Conditional access allows risk-based policies and is more flexible. Per-user MFA is legacy and always prompts for MFA regardless of risk.
'Conditional access policies are evaluated before authentication' – False. Authentication must succeed first; then conditional access evaluates. If authentication fails, policy is not applied.
'Azure AD Connect can sync users without any on-premises AD' – False. Azure AD Connect requires an on-premises AD domain. For cloud-only users, just create them directly.
'PIM is only for Azure AD roles, not Azure resources' – False. PIM can manage both Azure AD roles and Azure RBAC roles (Azure resources) via Azure AD PIM for groups.
'Guest users have the same permissions as members by default' – False. Guest users have restricted permissions by default (can't browse directory, limited profile info).
Specific Numbers and Terms on the Exam
Default token lifetime: 60-90 minutes for access tokens. Refresh tokens up to 90 days.
Smart lockout threshold: 10 failed attempts (default). Lockout duration: 60 seconds (default).
Password expiration: 90 days for cloud-only users (if not disabled).
Dynamic group membership evaluation: Up to 30 minutes.
PIM activation maximum: 8 hours.
Number of custom domains per tenant: 900.
Azure AD Connect sync interval: 30 minutes (default).
Edge Cases and Exceptions
Break-glass accounts: Must be excluded from conditional access and MFA. Usually two accounts with Global Admin role. Need strong passwords and monitoring.
Service principals: Not subject to conditional access policies directly. They use application permissions (app roles) and can be blocked via IP restrictions.
PowerShell authentication: Conditional access policies apply to interactive sign-ins, not to service-to-service calls (e.g., using client credentials flow).
B2B direct connect: For Teams shared channels, uses a different trust model than B2B collaboration.
How to Eliminate Wrong Answers
If the question asks about 'just-in-time access' for Azure AD roles, the answer is PIM, not Azure AD Privileged Identity Management (same thing) or Azure AD Identity Protection.
If the question mentions 'risk-based MFA', the answer is conditional access with sign-in risk policy, not per-user MFA.
If the question says 'sync passwords from on-premises', the answer is password hash sync, not pass-through authentication (which does not sync password hashes).
Entra ID is the cloud identity service; it is not a replacement for on-premises AD DS.
Conditional Access policies are evaluated after authentication; they can require MFA, compliant device, or approved app.
MFA via conditional access is preferred over per-user MFA for granular control.
PIM provides just-in-time privileged access to Azure AD roles and Azure resources.
Identity Protection uses machine learning to detect risky sign-ins and users.
Default token lifetimes: access tokens 60-90 min; refresh tokens up to 90 days.
Azure AD Connect sync interval is 30 minutes by default.
Dynamic group membership can take up to 30 minutes to update.
Break-glass accounts must be excluded from conditional access and MFA.
Smart lockout default: 10 failed attempts, 60-second lockout.
These come up on the exam all the time. Here's how to tell them apart.
Per-User MFA
Enabled per user account (legacy method).
Always prompts for MFA regardless of context.
No risk-based or location-based control.
Cannot exclude break-glass accounts easily.
Less flexible; Microsoft recommends against using it.
Conditional Access MFA
Configured via policies that target users, apps, and conditions.
Can require MFA only for specific conditions (e.g., untrusted locations).
Supports risk-based policies (sign-in risk, user risk).
Can exclude break-glass accounts explicitly.
Recommended approach; integrates with Identity Protection.
Password Hash Sync (PHS)
Synchronizes password hashes from on-premises to Azure AD.
Users authenticate directly against Azure AD.
No on-premises component needed after sync.
Supports seamless SSO (Kerberos delegation).
If on-premises AD is down, users can still authenticate (cached hashes).
Pass-Through Authentication (PTA)
No password hashes stored in Azure AD.
Authentication requests are passed through to on-premises AD via agents.
Requires at least two PTA agents for high availability.
Does not support seamless SSO automatically (needs separate configuration).
If on-premises AD is down, authentication fails (no fallback).
Mistake
Azure AD is the same as on-premises Active Directory in the cloud.
Correct
Azure AD (Entra ID) is fundamentally different: it uses REST APIs, OAuth/OpenID Connect, and does not support Kerberos, LDAP, or Group Policy. It is an identity service for cloud apps, not a directory service for domain-joined machines.
Mistake
Conditional Access policies apply to all sign-ins, including service-to-service calls.
Correct
Conditional Access policies apply only to interactive user sign-ins (user+device). Application authentication using client credentials (app-only) is not subject to conditional access.
Mistake
Password hash sync means passwords are stored in clear text in Azure.
Correct
Password hash sync synchronizes a hash of the password, not the plaintext. The hash is salted and hashed again before storage in Azure AD. Original passwords cannot be retrieved.
Mistake
MFA via conditional access is the same as per-user MFA.
Correct
Per-user MFA forces MFA on every sign-in, while conditional access MFA can be risk-based (e.g., only from untrusted locations). Conditional access is more flexible and recommended.
Mistake
PIM is only for Azure AD roles, not Azure resource roles.
Correct
PIM can manage both Azure AD roles and Azure resource roles (via Azure AD PIM for groups). You can activate RBAC roles like Contributor or Owner on a subscription with JIT.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure AD roles (e.g., Global Administrator) control permissions to manage Entra ID itself, like creating users or resetting passwords. Azure RBAC roles (e.g., Contributor, Owner) control permissions to Azure resources like VMs, storage accounts. Azure AD roles are assigned at the tenant scope; RBAC roles are assigned at a specific scope (subscription, resource group, resource). Both can be managed via PIM for JIT access.
The recommended way is to create a Conditional Access policy that targets all users (including guests) and all cloud apps, and under grant controls select 'Require multi-factor authentication'. Exclude at least two break-glass accounts. Do not use per-user MFA as it is legacy.
Yes. In a conditional access policy, under Conditions > Locations, you can select 'All trusted locations' or 'All untrusted locations', or you can define named locations by IP ranges or countries. Then set grant controls to 'Block access'. This is a common exam scenario.
Default: password must be at least 8 characters, contain 3 of 4 (uppercase, lowercase, number, symbol), and expires every 90 days. Password history: last 24 passwords cannot be reused. You can disable expiration by setting the tenant-wide policy to never expire (using PowerShell).
Identity Protection uses machine learning models that analyze real-time signals such as: impossible travel (user signs in from two distant locations in short time), anonymous IP addresses, leaked credentials, atypical sign-in patterns, and malware-linked IP addresses. Each sign-in gets a risk level: low, medium, high. Policies can automatically respond.
Azure AD registered: personal devices (BYOD) that are registered with an organization's Entra ID but not domain-joined. They have a device identity and can be used for SSO. Azure AD joined: devices owned by the organization that are joined to Entra ID (not on-premises AD). They support SSO and can be managed via Intune. Hybrid Azure AD joined: devices joined to on-premises AD and registered with Entra ID.
Yes, but the AzureAD module is deprecated. Use Microsoft Graph PowerShell SDK (Connect-MgGraph). For example: Get-MgUser to list users, New-MgGroup to create groups. You can also use Azure CLI with 'az ad' commands. Always use the latest Microsoft Graph API.
You've just covered Securing Microsoft Entra ID — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?