This chapter covers Microsoft Entra ID, the cloud-based identity and access management service that is the foundation of Microsoft's identity platform. For the SC-900 exam, approximately 30-35% of questions come from the Identity and Access domain (Objective 2.1), and Entra ID is the core topic within that domain. Understanding Entra ID's architecture, features like Conditional Access, and its role in hybrid identity is critical for passing the exam. This chapter will provide the deep, technical understanding needed to answer any Entra ID question confidently.
Jump to a section
Think of Microsoft Entra ID as a corporate badge system for a large office building. Every employee gets a badge (digital identity) that has their photo, name, department, and a unique ID number. The badge itself is issued by a central security office (the Entra ID tenant) and can be activated or deactivated remotely. When you swipe your badge at a door, the system checks a central database to see if you are still an active employee (account enabled/disabled) and whether your badge has permission to enter that specific area (conditional access). The badge can also carry additional attributes, like "contractor" or "VIP", which grant or restrict access to certain floors. The key difference from a physical badge is that Entra ID is entirely cloud-based and can be used to access not just the building (on-premises resources) but also partner offices (SaaS apps) and home office (Microsoft 365). The security office (Entra ID) manages the lifecycle: when you leave the company, your badge is instantly revoked, and you can no longer access any door. The badge system also supports multi-factor authentication — for example, after swiping, you might need to enter a PIN sent to your phone. This is exactly how Entra ID works: it is the central identity provider that authenticates users and authorizes access to resources based on policies.
What is Microsoft Entra ID?
Microsoft Entra ID (formerly Azure Active Directory) is a cloud-based identity and access management (IAM) service. It is not a directory service in the traditional sense like on-premises Active Directory Domain Services (AD DS). While AD DS is a hierarchical directory that stores objects (users, computers, groups) and is primarily used for authentication and authorization within a Windows domain network, Entra ID is a flat, REST-based directory that provides identity as a service (IDaaS). It is the backbone for authenticating users to Microsoft 365, Azure, and thousands of SaaS applications.
Why Entra ID Exists
The shift to cloud computing required a new identity model. On-premises AD DS assumes a network boundary: users and devices are inside a corporate network, and authentication happens via Kerberos or NTLM. In a cloud-first world, users access resources from anywhere, on any device. Entra ID was built to handle this: it is multi-tenant, highly available, and supports modern authentication protocols like OAuth 2.0, OpenID Connect, SAML, and WS-Federation. It decouples identity from the corporate network, enabling single sign-on (SSO) across millions of SaaS apps.
How Entra ID Works Internally
At its core, Entra ID is a distributed, replicated database that stores identity objects and their attributes. When a user attempts to sign in to an application, the following steps occur:
User initiates sign-in: The user navigates to an application (e.g., portal.office.com). The application redirects the user to the Entra ID sign-in endpoint (login.microsoftonline.com).
Authentication: Entra ID presents a sign-in page. The user enters their username (User Principal Name, UPN) and password. The authentication request is sent over TLS to the nearest Entra ID authentication endpoint. Entra ID validates the credentials against its directory. If password hash synchronization or pass-through authentication is used, it may also validate against on-premises AD DS.
Conditional Access evaluation: After successful authentication, Entra ID evaluates any Conditional Access policies configured for that user and application. This includes checking the user's location, device compliance, sign-in risk, and other conditions. If a policy requires multi-factor authentication (MFA), the user is prompted to provide a second factor.
Token issuance: If all conditions are met, Entra ID issues an access token (a JSON Web Token, JWT) that contains claims about the user (e.g., user ID, roles, groups). The token is sent back to the application. The application validates the token using the public signing keys from Entra ID's OpenID Connect discovery endpoint.
Authorization: The application reads the claims in the token to determine what the user is allowed to do. For example, if the token contains the role 'Global Administrator', the user gets admin privileges.
Key Components and Defaults
Tenant: An Entra ID tenant is a dedicated instance of the directory. Each tenant is isolated from others. A tenant has a default domain (tenantname.onmicrosoft.com) and can have custom domains (e.g., contoso.com). Tenants are created when you sign up for Microsoft 365, Azure, or Dynamics 365.
User objects: Each user has a UPN (e.g., user@contoso.com), an object ID (GUID), and attributes like display name, department, phone number. Users can be cloud-only (created directly in Entra ID) or synchronized from on-premises AD DS using Azure AD Connect.
Group objects: Groups can be security groups (used for permissions) or Microsoft 365 groups (used for collaboration). Groups can be assigned or dynamic. Dynamic group membership is evaluated based on rules like "department equals Sales".
Service principal: A service principal is the identity of an application in Entra ID. It is created when you register an application. It includes credentials (client secret or certificate) and permissions.
- Conditional Access: This is a policy engine that enforces access controls. A policy consists of: - Assignments: Users/groups, cloud apps, conditions (sign-in risk, device platform, location). - Access controls: Grant (require MFA, require compliant device, require approved client app) or Block. - Default: No Conditional Access policies are created by default. You must create them.
Identity Protection: This feature uses machine learning to detect risky sign-ins (e.g., impossible travel, anonymous IP addresses, leaked credentials). It generates a risk level (low, medium, high) and can automatically enforce policies like requiring password change.
Password Hash Synchronization (PHS): This is a feature of Azure AD Connect that synchronizes a hash of the user's password from on-premises AD DS to Entra ID. The actual password is never sent; only the hash. If the user changes their password on-premises, the hash is synchronized within a few minutes (default sync interval is 30 minutes, but can be triggered manually).
Pass-through Authentication (PTA): Instead of storing password hashes in the cloud, PTA validates passwords directly against on-premises AD DS via an agent installed on-premises. This ensures that password policies (like account lockout) are enforced on-premises.
Seamless SSO: When using PHS or PTA, Seamless SSO automatically signs users in when they are on corporate devices connected to the corporate network. It uses Kerberos tickets to silently authenticate users.
Federation: You can federate your on-premises AD DS with Entra ID using Active Directory Federation Services (AD FS). This allows users to sign in using their on-premises credentials without synchronization.
Configuration and Verification Commands
Administrators manage Entra ID through the Azure portal (portal.azure.com), the Microsoft 365 admin center, or programmatically via Microsoft Graph API. Key PowerShell commands:
Connect-MgGraph -Scopes "User.Read.All", "Group.Read.All" – Connect to Microsoft Graph.
Get-MgUser -Filter "startsWith(displayName, 'John')" – Retrieve users.
Get-MgGroup -Filter "groupTypes/any(g:g eq 'Unified')" – Get Microsoft 365 groups.
New-MgConditionalAccessPolicy – Create a Conditional Access policy.
For Azure AD Connect:
- Get-ADSyncConnector – List sync connectors.
- Start-ADSyncSyncCycle -PolicyType Delta – Trigger a delta sync.
Integration with Related Technologies
Entra ID integrates with: - Microsoft 365: Uses Entra ID for authentication. All users in Microsoft 365 are Entra ID users. - Azure: Azure RBAC uses Entra ID identities. Azure resources can be secured using managed identities (an automatically managed service principal in Entra ID). - SaaS apps: Thousands of pre-integrated apps in the Azure AD gallery support SSO via SAML or OpenID Connect. - On-premises AD DS: Via Azure AD Connect, Entra ID can synchronize users, groups, and passwords, enabling hybrid identity. - Microsoft Intune: Device compliance policies are evaluated by Entra ID during Conditional Access. - Microsoft Defender for Identity: Provides identity security posture assessments and detects on-premises identity attacks, feeding risk signals into Entra ID Identity Protection.
Defaults and Timers
Token lifetime: Access tokens default to 1 hour. Refresh tokens can last up to 90 days if not revoked.
Session lifetime: Configurable via Conditional Access session controls. Default is 24 hours for browser sessions.
Password writeback: When enabled, password changes in Entra ID are written back to on-premises AD DS. The default sync interval for password writeback is 2 minutes.
Azure AD Connect sync interval: Default is 30 minutes for directory changes. Delta syncs occur every 30 seconds for password changes if password writeback is enabled.
Grace period for expired passwords: Users can still sign in for 14 days after password expiration if the admin configures it.
Exam-Relevant Numbers
Maximum number of tenants per subscription: 1 (by default, but can have multiple subscriptions under one tenant).
Maximum number of objects in a tenant: 500,000 (free tier), up to 50 million (Azure AD Premium P2).
Number of Conditional Access policies: Up to 250 per tenant.
Number of named locations: Up to 200 per tenant.
Number of risk events retained: 30 days for Identity Protection.
Trap Patterns on the Exam
Entra ID vs. AD DS: Many candidates confuse the two. Entra ID is cloud-based, uses REST APIs, and supports OAuth; AD DS is on-premises, uses LDAP and Kerberos. The exam tests this distinction heavily.
Conditional Access vs. Identity Protection: Conditional Access enforces policies based on conditions; Identity Protection detects and helps remediate risks. They work together but are different.
PHS vs. PTA: PHS stores password hashes in the cloud; PTA does not. PTA requires on-premises agents.
Free vs. Premium features: MFA is available in all tiers, but Conditional Access and Identity Protection require Azure AD Premium P1 or P2.
User Initiates Sign-In
The user navigates to an application, such as the Microsoft 365 portal (portal.office.com). The application, configured to use Entra ID as its identity provider, redirects the user's browser to the Entra ID sign-in endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/authorize. The request includes parameters like client_id (the application's ID), redirect_uri, response_type (code or token), and scope. The user's browser then renders the Entra ID sign-in page.
Authentication Request Processing
The user enters their User Principal Name (UPN) and password. Entra ID receives the credentials via HTTPS POST. It first validates the UPN format and checks if the tenant exists. Then it authenticates against the directory. If password hash synchronization is enabled, Entra ID compares the hash of the entered password with the stored hash. If pass-through authentication is enabled, the request is forwarded to an on-premises PTA agent, which validates against AD DS. If federation is used, the user is redirected to the on-premises AD FS server. On success, Entra ID creates an authentication session.
Conditional Access Evaluation
After successful authentication, Entra ID checks if any Conditional Access policies apply to this sign-in. It evaluates the user, application, and conditions (e.g., location, device state, sign-in risk). If a policy requires multi-factor authentication, the user is prompted to provide a second factor (e.g., a code from the Microsoft Authenticator app). If the device is not compliant (e.g., missing required updates), access may be blocked or limited. The evaluation results in a 'Grant' or 'Block' decision. This step is critical for security and is a key exam topic.
Token Issuance
If all conditions are met, Entra ID generates an access token (a JSON Web Token) containing claims such as the user's object ID, tenant ID, roles, and group memberships. The token is signed with Entra ID's private key. The token is returned to the application via the browser redirect. The application validates the token by checking the signature against Entra ID's public keys (fetched from https://login.microsoftonline.com/{tenant-id}/discovery/v2.0/keys). It also checks the token's expiration (default 1 hour) and audience (must match the application's client ID).
Authorization and Resource Access
The application uses the claims in the access token to authorize the user. For example, if the token includes the role 'Global Admin', the application grants full administrative privileges. The user can now access resources (e.g., SharePoint sites, email, Azure resources) based on the permissions granted to their identity. The application may also use the token to call Microsoft Graph on behalf of the user. The token is cached by the application and refreshed automatically using a refresh token when it expires.
Enterprise Scenario 1: Hybrid Identity with Password Hash Synchronization
A multinational corporation with 50,000 employees uses on-premises Active Directory for user management. They migrate to Microsoft 365 and need to enable SSO. They deploy Azure AD Connect with Password Hash Synchronization. The sync runs every 30 minutes, synchronizing user accounts, groups, and password hashes. Users can sign in to Microsoft 365 using their corporate credentials. The company also enables Seamless SSO so that domain-joined computers automatically authenticate users without prompting. A common issue is that when an on-premises password is reset, the hash synchronization may take up to 30 minutes, causing users to be locked out of cloud services temporarily. To mitigate this, the company configures password writeback, allowing users to reset their passwords from the cloud and have them written back to on-premises AD DS within 2 minutes.
Enterprise Scenario 2: Conditional Access for Remote Workers
A financial services firm requires all remote users to use multi-factor authentication and only allow access from compliant devices. They create a Conditional Access policy: for all cloud apps, if the user is not in the corporate IP range, require MFA and require a device to be marked as compliant by Intune. They also configure a session control to limit sign-in frequency to every 4 hours. The policy is assigned to all users except break-glass accounts. A common misconfiguration is forgetting to exclude emergency access accounts, which can lock out admins. The firm also uses Identity Protection to detect risky sign-ins and automatically block access when risk is high.
Enterprise Scenario 3: Application Integration with Service Principals
A software company develops a custom web app that needs to access Microsoft Graph to read user profiles. They register the app in Entra ID, creating a service principal. They grant the app the 'User.Read.All' application permission (not delegated) and use a client certificate for authentication. The app runs as a background service and authenticates using the certificate. A common issue is that the certificate expires, causing authentication failures. The company implements automated certificate rotation using Azure Key Vault and sets up alerts for expiration. They also ensure that the service principal is granted admin consent for the required permissions, which requires a Global Administrator to approve.
What SC-900 Tests on This Topic
SC-900 Objective 2.1: Describe the basic identity concepts and the capabilities of Microsoft Entra ID. The exam focuses on:
Differentiating between Entra ID and AD DS.
Understanding the features of Entra ID editions (Free, Office 365, Premium P1, Premium P2).
Knowing the authentication methods: PHS, PTA, Federation, Seamless SSO.
Conditional Access policy components (assignments and access controls).
Identity Protection features (risk detection and remediation).
The concept of a tenant and its relationship to subscriptions.
Common Wrong Answers and Why Candidates Choose Them
Confusing Entra ID with AD DS: A question might ask 'Which service provides LDAP authentication in the cloud?' Many candidates answer 'Entra ID', but the correct answer is 'AD DS' because Entra ID does not support LDAP. Candidates choose Entra ID because they know it's the cloud directory.
Thinking Conditional Access requires Premium P2: Actually, Conditional Access is available in Azure AD Premium P1 and P2. P2 adds Identity Protection-based risk conditions. Candidates often assume all advanced features require P2.
Mistaking PHS for PTA: When asked which method stores password hashes in the cloud, candidates may choose PTA because they think 'pass-through' means the password passes through to the cloud. In reality, PTA does not store hashes; PHS does.
Assuming MFA requires a paid license: MFA is available in all editions, including Free, but features like Conditional Access MFA require P1 or P2.
Specific Numbers and Terms That Appear Verbatim
30 minutes: Default sync interval for Azure AD Connect.
1 hour: Default access token lifetime.
500,000: Max objects in free tier.
250: Max Conditional Access policies per tenant.
Seamless SSO: The feature that uses Kerberos for silent authentication.
Password writeback: The feature that writes cloud password changes back to on-premises AD DS.
Edge Cases and Exceptions
Break-glass accounts: Emergency access accounts that should be excluded from Conditional Access policies. The exam tests that you should have at least two.
Guest users: Entra ID B2B collaboration allows external users to access resources. Guest users have a different user type and can be subject to Conditional Access policies.
Device compliance: Conditional Access can require a device to be compliant, but compliance is evaluated by Intune, not Entra ID.
How to Eliminate Wrong Answers
If the question mentions 'on-premises', 'LDAP', 'Kerberos', or 'Group Policy', it's likely about AD DS, not Entra ID.
If the question asks about 'risk-based policies', it involves Identity Protection, which requires Premium P2.
If the question mentions 'tokens' or 'OAuth', it's about Entra ID.
For authentication methods: if it says 'password hash stored in cloud', it's PHS; if it says 'validated on-premises', it's PTA; if it says 'federation server', it's AD FS.
Microsoft Entra ID is a cloud-based identity and access management service, not a directory service like AD DS.
Authentication methods: Password Hash Synchronization (PHS), Pass-through Authentication (PTA), Federation (AD FS).
Conditional Access policies consist of assignments (users, apps, conditions) and access controls (grant or block).
Identity Protection detects risks (e.g., leaked credentials, impossible travel) and allows automated remediation.
Default token lifetime is 1 hour; refresh tokens last up to 90 days.
Azure AD Connect syncs every 30 minutes by default.
MFA is free but Conditional Access requires Premium P1 or P2.
Break-glass accounts should be excluded from Conditional Access policies.
Seamless SSO uses Kerberos for silent authentication on domain-joined devices.
Entra ID supports OAuth 2.0, OpenID Connect, and SAML for modern authentication.
These come up on the exam all the time. Here's how to tell them apart.
Entra ID Free
Maximum 500,000 objects
No Conditional Access
No Identity Protection
Basic MFA (per-user enabled)
No privileged identity management
Entra ID Premium P2
Maximum 50 million objects
Full Conditional Access with risk conditions
Identity Protection with risk detection and automated remediation
Risk-based MFA via Conditional Access
Privileged Identity Management (PIM) for just-in-time access
Mistake
Microsoft Entra ID is the cloud version of Active Directory Domain Services.
Correct
Entra ID is a completely different technology. AD DS is a directory service based on LDAP and Kerberos, used for on-premises network authentication. Entra ID is a REST-based identity service that uses OAuth, OpenID Connect, and SAML. They share the word 'Active Directory' but have different architectures and protocols.
Mistake
Multi-factor authentication requires a paid Entra ID license.
Correct
MFA is available in all editions of Entra ID, including the Free tier. However, advanced features like Conditional Access MFA (where policies require MFA based on conditions) require Azure AD Premium P1 or P2. Per-user MFA (enabled per user) is free.
Mistake
Pass-through Authentication stores the user's password in the cloud.
Correct
PTA does not store any password hashes in the cloud. The password validation request is forwarded to an on-premises agent that validates against AD DS. In contrast, Password Hash Synchronization stores a hash of the password in Entra ID.
Mistake
Conditional Access policies are applied after the user is already signed in.
Correct
Conditional Access policies are evaluated during the authentication process, before a token is issued. If a policy blocks access, the user never receives a token and cannot sign in. It is not a post-authentication step.
Mistake
You need Azure AD Premium P2 to use Conditional Access.
Correct
Conditional Access is available in Azure AD Premium P1 and P2. P2 adds the ability to use sign-in risk and user risk as conditions (from Identity Protection). Basic Conditional Access features (like MFA based on location) are in P1.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Microsoft Entra ID is a cloud-based identity and access management service that uses REST APIs and supports modern authentication protocols like OAuth 2.0 and OpenID Connect. It is designed for cloud and SaaS applications. Active Directory Domain Services (AD DS) is an on-premises directory service that uses LDAP and Kerberos, and it is used for managing users and computers within a corporate network. The exam frequently tests this distinction, so remember: AD DS is on-premises, LDAP/Kerberos; Entra ID is cloud, REST/OAuth.
No, Entra ID does not natively support LDAP. However, you can use Azure AD Domain Services (now part of Microsoft Entra Domain Services) to provide LDAP, Kerberos, and NTLM authentication for cloud-only applications. But the core Entra ID service does not. This is a common exam trap: if a question asks for LDAP, the answer is usually AD DS or Azure AD DS, not Entra ID.
Password Hash Synchronization (PHS) synchronizes a hash of the user's password from on-premises AD DS to Entra ID. The actual password is never sent. Pass-through Authentication (PTA) validates passwords directly against on-premises AD DS via an agent, without storing any password hash in the cloud. PHS is simpler and provides a backup if on-premises is unavailable; PTA enforces on-premises password policies in real-time. The exam asks you to choose based on requirements like 'must not store passwords in cloud' (PTA) or 'must work if on-premises is down' (PHS).
A Conditional Access policy has two main components: Assignments and Access controls. Assignments specify who (users/groups), what (cloud apps), and under what conditions (sign-in risk, device platform, location, client apps). Access controls define what happens: either Grant (require MFA, require hybrid Azure AD joined device, require approved client app, require device to be marked compliant) or Block. The exam expects you to know these components and be able to identify which is an assignment and which is a control.
Identity Protection is a feature of Azure AD Premium P2 that detects potential vulnerabilities and risky sign-ins. It uses machine learning to detect risks like leaked credentials, impossible travel, anonymous IP addresses, and unfamiliar sign-in properties. It generates a risk level (low, medium, high) for users and sign-ins. You can configure Conditional Access policies to respond automatically, e.g., require MFA for medium risk or block access for high risk. It also provides risk reports and remediation actions like forcing a password reset. The exam tests that Identity Protection is a P2 feature and that it feeds risk into Conditional Access.
The default sync cycle for Azure AD Connect runs every 30 minutes. However, password hash synchronization can occur more frequently (every 2 minutes) if password writeback is enabled. You can also trigger a delta sync manually using the PowerShell command 'Start-ADSyncSyncCycle -PolicyType Delta'. The exam may ask about this default value.
A tenant is a dedicated and isolated instance of the Entra ID directory. It is created when you sign up for a Microsoft cloud service like Microsoft 365 or Azure. Each tenant has a default domain (tenantname.onmicrosoft.com) and can have custom domains. All users, groups, and applications within a tenant are isolated from other tenants. The exam tests that a tenant is the boundary for identity management and that you can have multiple Azure subscriptions under one tenant.
You've just covered Microsoft Entra ID — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?