AB-900 lesson 3: sign-in and access

Signing in to Microsoft 365 is a two-stage decision in Microsoft Entra ID: first the user proves who they are (authentication), then policies and permissions decide what that identity may reach (authorisation). Conditional access policies run after the first factor succeeds and can allow the sign-in, demand extra proof such as multifactor authentication (MFA), or block it. Every attempt is written to the sign-in logs, which is the first place to look when someone is locked out.

Identities as security objects

Microsoft Entra ID is the directory behind Microsoft 365. Two objects do most of the work. A user is one identity that signs in. A group collects users so that access, licences and policies can be assigned once instead of per person. Security groups and Microsoft 365 groups can be used to grant access; distribution groups only deliver mail. Choosing the appropriate security object is usually a matter of scale: one person, use the user; many people with the same need, use a group.

Authentication methods

Authentication is the proof of identity. A password is the weakest common method. Stronger options include the Microsoft Authenticator app, passkeys (FIDO2), Windows Hello for Business, and certificate-based authentication. Microsoft describes Windows Hello for Business, passkeys and FIDO2 security keys, and certificate-based authentication as phishing-resistant, because a fake sign-in page cannot capture a reusable secret. SMS codes, voice calls and one-time codes work as second factors but are more exposed to phishing. See MFA, passwordless and passkeys for the method details.

MFA means combining at least two different kinds of proof, such as something known (password) and something held (phone or key). Single sign-on (SSO) is a different idea: after one successful sign-in the user reaches many applications without entering credentials again, so there are fewer passwords to lose and one central place to revoke access. The topic page on SSO, SAML and OAuth goes deeper.

Conditional access: the decision point

The figure above follows one attempt from left to right. Conditional access policies are if-then statements. The “if” part uses signals: who the user is or which group they are in, the application, device state, location, and sign-in risk. The “then” part is a decision: block access, or grant access with requirements such as MFA, a compliant device, or an approved authentication strength. Policies can be tested in report-only mode before being enforced. Conditional access needs Microsoft Entra ID P1, which Microsoft 365 Business Premium also includes, and risk-based policies need Entra ID P2. Read conditional access explained for examples of common policies.

Zero Trust in this picture

Zero Trust is the design philosophy and conditional access is one of its enforcement engines. The three principles map directly: verify explicitly (check user, device, location and risk on every request), use least-privilege access (give only the access needed), and assume breach (limit blast radius and watch for abuse). The page on Zero Trust expands each principle.

Authentication vs authorisation

An exam scenario that says the user could sign in but cannot open a document is an authorisation problem. A user who never reaches the app is an authentication or conditional access problem.

Worked example: a blocked sign-in from home

A 150-person company has a policy that requires a compliant device for the finance application. A finance clerk reports being blocked when working from a personal laptop at home, while the office desktop works. The admin does not guess. In the Microsoft Entra admin center the admin opens the sign-in logs, finds the failed attempt, and selects the Conditional Access tab to see which policy applied and what it required. The log shows the compliant-device requirement was not met, so the fix is to enrol the device or use a managed one, not to reset the password. If the log had instead shown a risky sign-in, the next place to look would be the risky sign-ins report in Microsoft Entra ID Protection, described in Entra ID Protection. If the user had failed MFA, the sign-in log would show the authentication requirement not satisfied.

Easy to confuse

Key points

• Authentication proves identity; authorisation decides access.
• Conditional access evaluates signals after first-factor sign-in and then allows, requires extra controls, or blocks.
• Phishing-resistant methods include Windows Hello for Business, passkeys and certificate-based authentication.
• Zero Trust principles: verify explicitly, least privilege, assume breach.
• Start sign-in troubleshooting with the Entra sign-in logs and their Conditional Access details.

Check yourself

This lesson continues domain one of the course, which carries 30 to 35% of the exam. The recap page Microsoft 365 core features explained gives the identity features as one table, and the cheat sheet fits the decision flow on one page.