Identify the core features and objects of Microsoft 365 services
Microsoft Entra ID, Conditional Access, and SSO
CoreUnderstand cloud identity, scalable access assignments, adaptive policy evaluation, SSO, and evidence-led troubleshooting for failed and risky sign-ins.
Aligned to the current AB-900 guide, verified July 22, 2026.
Why this matters
AB-900 expects you to distinguish identity proof from access decisions and know where to investigate failed or risky sign-ins.
Must Know
- Microsoft Entra ID manages identities, groups, devices, applications, roles, authentication, and access signals for Microsoft 365.
- Authentication proves who the user is; authorization determines which resources and actions that identity may access.
- MFA requires more than one factor. Conditional Access evaluates signals and decides whether to require a control, limit a session, or block access.
- SSO reduces repeated sign-ins but does not grant application assignment or resource permission.
- Sign-in logs show authentication details, Conditional Access results, device/location context, and risk; use them before changing policy.
- A risky sign-in concerns one authentication event; a risky user concerns the likelihood that the identity is compromised.
- Direct user assignment suits exceptions; group assignment scales application and policy access.
Compare and Distinguish
- Authentication vs authorization: identity proof vs permission to a resource.
- MFA/authentication-method policy vs Conditional Access: which methods can be used vs when access requires or blocks a control.
- Failed authentication vs MFA issue vs Conditional Access block vs risky sign-in: wrong or rejected identity proof vs challenge failure vs policy decision vs successful/attempted activity with compromise signals.
- Sign-in risk vs user risk: risk attached to one authentication event vs risk attached to the identity across evidence.
- User assignment vs group assignment: individual exception/control vs scalable membership-based access.
- SSO vs broad access: fewer repeated prompts vs no automatic permission to every application.
Scenario examples
- Scenario: A user enters the correct password but never completes the Authenticator prompt. Think: Inspect authentication details for an MFA failure, not merely the password or application permission.
- Scenario: Authentication succeeds but SharePoint access is denied by a device rule. Think: Review Conditional Access evaluation and resource authorization; this is not a failed first factor.
- Scenario: A successful sign-in comes from an unfamiliar location. Think: Review risky sign-in details, related detections, device/IP history, and user confirmation before blindly disabling a broad policy.
- Scenario: Every payroll employee needs one enterprise app. Think: Assign the app to a maintained security group rather than creating many direct assignments.
Exam traps
- Conditional Access normally evaluates after primary authentication; a policy block is not proof that the password was wrong.
- A risky sign-in can succeed and still require investigation; a failed sign-in is not automatically risky.
- SSO does not bypass application assignment, consent, or resource permission.
- A group scales access but does not make every member an administrator.
Key takeaways
- Entra authenticates identities; Conditional Access evaluates context; resource permissions authorize actions.
- Sign-in record first: status → authentication details → Conditional Access → risk evidence.
- Groups scale access; risky sign-in and risky user answer different questions.
How it works
- A sign-in begins with primary authentication. Entra then evaluates risk and applicable Conditional Access policies. A policy can require another control such as MFA or a compliant device before a token is issued.
- Authentication details show which methods and steps were attempted; the Conditional Access tab shows which policies applied and their results. A successful first factor can therefore still end in a policy block or incomplete MFA.
- Entra ID Protection uses detections such as atypical travel, suspicious IP behavior, leaked credentials, or token anomalies to calculate risk. Administrators validate context and evidence, then mark activity safe/compromised or use remediation such as password reset, MFA, session revocation, or a risk-based policy.
Objects and administrative surfaces
- Users, groups, devices, authentication methods, Conditional Access policies, sign-in logs, risky users, risky sign-ins, and risk detections — Microsoft Entra admin center.
- My Sign-ins lets a user review their own recent activity and authentication information.
- Application assignment and service-principal access — Enterprise applications in the Microsoft Entra admin center.
When to use it
- Use Conditional Access when access requirements depend on user, application, device, location, client, or risk context.
- Use group-based assignment when a role or department should receive the same app/resource access; use direct assignment for a documented exception.
- Investigate a risk detection before dismissing or confirming it, unless immediate containment is required by strong evidence.
Security and governance implications
- Deploy Conditional Access in report-only mode and stages, protect emergency-access accounts, and avoid locking every administrator out.
- Prefer phishing-resistant authentication where supported and limit weaker methods according to organizational needs.
- Use risk-based self-remediation where appropriate, but contain and revoke sessions when evidence indicates active compromise.
Troubleshooting signals
- Find the exact sign-in by user, application, time, and correlation ID. Read failure reason/additional details, authentication details, Conditional Access results, device/location, and risk fields.
- For MFA, check method registration, attempted method, challenge result, authentication-method policy, and whether Conditional Access required the challenge.
- For risk, review risky sign-ins, risky users, risk detections, related sign-ins, device/IP/location history, and Defender incidents; contact the user through a trusted channel if appropriate.
- Change or disable a policy only after identifying the policy and condition responsible; use report-only/What If evidence and narrow corrections where possible.
More detail
- Microsoft Entra ID stores users, groups, devices, application identities, roles, and access relationships. It provides authentication, single sign-on, Conditional Access, and identity-protection signals used across Microsoft 365.
- Authentication methods include passwords, Microsoft Authenticator, phishing-resistant FIDO2 security keys/passkeys, certificate-based authentication, Temporary Access Pass, text message (SMS), voice, and other supported methods. MFA requires factors from different categories; a second password is not a second factor.
- Conditional Access is Microsoft’s Zero Trust policy engine. A policy targets users or workload identities and resources, evaluates conditions such as device, location, client, or risk, and applies controls such as require MFA, require compliant device, block, or session restrictions. All applicable policies must be satisfied.
- SSO lets an authenticated user access integrated applications without repeatedly entering credentials. SSO improves experience and centralizes access decisions, but the application still requires assignment/consent and resource authorization.
- A user object represents one identity and suits an exception or individual accountability. A security group provides scalable membership for application access, Conditional Access scoping, and permissions. A Microsoft 365 group is collaboration-oriented and also supplies shared resources; use only distinctions that match the task.
- Sign-in risk estimates the probability that a specific authentication request is not authorized by the identity owner. User risk estimates the probability that the identity itself is compromised. Entra ID Protection generates risk detections and risky sign-in/user reports that administrators investigate or remediate through risk-based policy.
- The sign-in log shows status, application, device, location, authentication details, Conditional Access evaluation, and risk context. This evidence distinguishes an invalid credential, an incomplete MFA challenge, a policy block, and a successful but suspicious sign-in.
Ready for the quiz?
- Why are MFA and Conditional Access not the same thing?
- How can authentication succeed while SharePoint access is denied?
- What is the difference between a risky sign-in and a risky user?
- Why does SSO not mean access to every application?
- Which sign-in log evidence should you review before changing a broad policy?
Related objectives
- D1.3.a — Understand features and capabilities of Microsoft Entra ID
- D1.3.b — Understand conditional access policies
- D1.3.c — Understand the purpose and benefits of SSO
- D1.3.d — Identify the appropriate security object to use in an organization (users and groups)
- D1.3.e — Identify the appropriate tools to troubleshoot common sign-in issues (multifactor authentication [MFA], conditional access, and risky sign-ins)