Implement authentication and access management Study Guide — SC-300

Implement Authentication and Access Management (25–30%)

The largest SC-300 domain. Microsoft's skills list gives it 25–30% (the section heading in the same study guide says 20–25%, so treat it as at least an equal share). It covers how users prove who they are, the Conditional Access engine that decides what happens next, risk-based policies, and Global Secure Access.

The examples continue with Northwind: 2,000 staff, Microsoft 365, a few on-premises apps, and admins who keep getting phished.

Authentication Methods

Methods are enabled per group in the authentication methods policy.

TAP defaults: default and minimum lifetime 1 hour, maximum 8 hours, one-time use off, length 8 (allowed 10 minutes to 30 days). Only users in the TAP policy can sign in with one. Authentication Administrators issue TAPs to members; Privileged Authentication Administrators also to admins.

Example: a Northwind new hire receives a TAP from the helpdesk on day one.

Helpdesk issues TAP (1 h) ─▶ new hire signs in at aka.ms/mysecurityinfo ─▶ registers passkey ─▶ never had a password

Takeaway: "bootstrap passwordless" or "lost all methods" means TAP.

MFA, SSPR and Password Protection

• Security defaults are all-or-nothing baseline MFA; Conditional Access (P1) replaces them with targeted policies. Per-user MFA is legacy.
• SSPR: choose the number of methods (1 or 2) and which methods. Admins always get a stricter two-gate policy. Synced users need password writeback (Connect Sync or Cloud Sync) for resets to reach AD.
• Password protection: global banned list plus your custom banned list; deploy the proxy service and DC agents to enforce it on AD. Smart lockout stops brute force.
• Revoke sessions (user page or Revoke-MgUserSignInSession) invalidates refresh tokens; combine with disabling the account.

Example: Sydney staff reset passwords in the cloud but their PCs still want the old one.

SSPR in cloud ──✗ no writeback──▶ on-prem AD unchanged   → enable password writeback

Takeaway: a cloud reset that "doesn't work on-premises" is always writeback.

Conditional Access Building Blocks

IF  assignments (users / groups / roles / workload identities, target resources, conditions)
    conditions: user risk, sign-in risk, device platform, locations, client apps, filter for devices, authentication flows
THEN grant controls: block, or require MFA / authentication strength / compliant or hybrid-joined device /
                     approved app / app protection policy / terms of use / risk remediation
AND  session controls: sign-in frequency, persistent browser, app enforced restrictions,
                       Conditional Access App Control, CAE customisation, token protection

• Templates create common policies (block legacy auth, MFA for admins).
• Report-only evaluates and logs without enforcing; the What If tool simulates one sign-in.
• Authentication strengths choose which methods satisfy MFA (built-in: Multifactor authentication, Passwordless MFA, Phishing-resistant MFA).
• Device-enforced restrictions = require compliant or hybrid joined device; app-enforced restrictions let SharePoint/Exchange limit unmanaged-device sessions.