6.3 Passwordless, Session Control & Entra Kerberos

Passwordless as an identity program (not a single feature)

By this point in Domain 2 you can enable methods and require MFA. Passwordless goes further: users prove identity with something they have + something they are/know locally (device + PIN/biometric) or a hardware key, without transmitting a reusable password to cloud apps.

Microsoft Entra passwordless portfolio (exam map):

SC-300 identity admins are not asked to memorize every Intune CSP for WHfB, but they are expected to know how WHfB fits Entra authentication, how to respond when accounts are compromised, and how Microsoft Entra Kerberos supports hybrid resource access—especially Azure Files identity-based authentication scenarios.

Windows Hello for Business overview for identity admins

Windows Hello for Business is the enterprise passwordless credential for Windows. Unlike consumer “Windows Hello” face/PIN that may unlock a local password, for Business provisions cryptographic credentials tied to the device’s TPM and the user’s identity in Microsoft Entra ID and/or Active Directory, depending on deployment model.

Why WHfB matters on SC-300

• Provides phishing-resistant authentication when deployed correctly (keys bound to device/TPM; PIN is local unlock for the private key, not a network password).
• Integrates with Conditional Access authentication strengths that require phishing-resistant methods.
• Depends on device identity: Microsoft Entra joined or hybrid joined devices are the usual prerequisites for cloud trust / hybrid trust deployment patterns.
• Reduces password reuse and credential theft from phishing pages that harvest UPN+password.

Deployment models (conceptual)

Identity admins should recognize model names and trust directions at a high level:

You do not need to design full PKI on the exam, but if a stem says “Entra joined laptops must use TPM-backed PIN/biometric instead of passwords for Microsoft 365,” Windows Hello for Business (plus methods policy / CA) is the feature family—not SMS MFA alone.

Identity admin checklist for WHfB programs

1. Confirm device join strategy (Entra join vs hybrid join) with endpoint teams.
2. Ensure users can register authentication methods; use TAP for joiners if passwordless-first.
3. Enable related authentication methods and authentication strengths for sensitive apps.
4. Coordinate Intune or Group Policy configuration with device admins (identity exam stops at collaboration boundaries).
5. Validate Conditional Access does not create a dead-end (for example requiring compliant device + WHfB before the device can complete registration—order policies carefully).
6. Plan helpdesk recovery: lost device → disable/wipe device identity + TAP + re-register methods.

WHfB is device-bound. A user with a new laptop must provision Hello again on that device; a FIDO2 key may travel with the user more easily. Enterprises often combine WHfB for daily Windows and FIDO2 for web/admin break-glass flexibility.

Disable accounts and revoke user sessions

Offboarding, insider risk, and account compromise playbooks are high-frequency SC-300 scenarios. Two controls are related but not identical.

Block sign-in (disable account)

On the user object, Block sign-in (account enabled = false) prevents the user from performing new authentications. It is the standard “this identity must not sign in” switch while retaining the object for audit, licensing transitions, and restore-friendly offboarding.

Effects and limits:

• New interactive sign-ins should fail.
• Existing access tokens may remain valid until they expire (often short-lived).
• Existing refresh tokens and sessions may continue to mint access tokens until revoked or invalidated by other controls.
• Synchronized users may also need authoritative disable in on-premises AD so hybrid auth paths cannot succeed against a still-enabled AD account depending on auth method (PHS/PTA/federation).

Revoke sessions / revoke refresh tokens

Microsoft Entra provides Revoke sessions (also described as invalidating refresh tokens) on the user. This forces clients that depend on refresh tokens to reauthenticate. Pair it with block sign-in during compromise response.

Exam algorithm for “user laptop stolen / token theft suspected”:

1. Block sign-in (and disable on-premises if hybrid authoritative).
2. Revoke sessions (refresh tokens).
3. Reset password if passwords exist; revoke/reset MFA methods if the authenticator may be compromised; issue TAP only after identity proofing for legitimate recovery.
4. Review sign-in logs, risky user/sign-in blades, and application audit trails.
5. For devices: disable/wipe Entra device object and involve Intune/endpoint management.

Continuous Access Evaluation (CAE) (covered more in Conditional Access session topics) can critically shorten the window by pushing claim revocations to supporting apps (Exchange, SharePoint, Teams, and expanding workloads) when IP changes, account disable, or password change events occur. Even with CAE, explicit revoke sessions remains a correct admin action in compromise runbooks.

Offboarding sequence (identity slice)

1. Block sign-in.
2. Revoke sessions.
3. Remove group memberships / access packages / app assignments per HR timing (some orgs retain mailbox convert flows first).
4. Remove licenses after data disposition rules allow.
5. Delete or convert account per retention policy (soft-delete awareness from earlier chapters).

Do not delete first if you still need a clean revoke/audit trail and restore options; blocking + revoking is the immediate security pair.

Microsoft Entra Kerberos authentication for hybrid identities

Kerberos is the ticket-based authentication protocol of on-premises Active Directory. Cloud identities historically did not “speak Kerberos” to Azure file shares without bridge technologies. Microsoft Entra Kerberos (also discussed in Microsoft docs as cloud Kerberos trust patterns for certain scenarios) lets Entra ID issue Kerberos ticket material for hybrid identities so users can access resources such as Azure Files with identity-based authentication using their Entra identity alignment to on-premises AD identities.

Why SC-300 includes Entra Kerberos

Identity admins design access to file shares and hybrid resources without forcing every workload through legacy VPN+AD-only patterns. Azure Files supports identity-based auth over on-premises AD DS, Microsoft Entra Domain Services, and Microsoft Entra Kerberos for hybrid user accounts (feature details and OS/client prerequisites evolve—learn the when/why, not every PowerShell switch).

Hybrid identity prerequisites (conceptual)

For Entra Kerberos with hybrid users, expect exam assumptions such as:

• Users are synchronized hybrid identities (on-premises AD ↔ Entra).
• Devices and clients support the Entra Kerberos authentication path for the resource.
• Azure storage account is configured for the Microsoft Entra Kerberos identity source for file shares (alongside proper share-level and NTFS/file permissions models).
• Kerberos ticket encryption and proper configuration are handled per Microsoft guidance (identity admin collaborates with Azure storage/admin teams).

Entra Kerberos is not:

• A replacement for Conditional Access on Microsoft 365 web apps.
• The same thing as Seamless SSO (which uses a different computer account / Kerberos pattern for domain-joined SSO to Entra-authenticated apps).
• A reason to keep passwords forever—passwordless users can still participate in modern access patterns when device and method prerequisites are met.

Seamless SSO versus Entra Kerberos (do not conflate)

Exam stems that mention Azure Files + hybrid users + cloud Kerberos point to Entra Kerberos configuration for the storage identity source—not “enable Security defaults.”

Session control touchpoints for identity admins

Passwordless and Kerberos sit beside session controls you will deepen in Conditional Access:

• Sign-in frequency — how often users must reauthenticate.
• Persistent browser session — whether browser sessions persist.
• Continuous Access Evaluation — near real-time enforcement for supported services.
• Application-enforced restrictions / Conditional Access app control — session limitations for browser access (Defender for Cloud Apps integrations).

For this section, remember the operational core: passwordless reduces credential theft, block+revoke contains sessions, and Entra Kerberos modernizes hybrid file access.

End-to-end scenario practice

Scenario A — Passwordless pilot: Enable Authenticator passwordless and FIDO2 in methods policy for Pilot group; deploy WHfB on Entra joined laptops with endpoint team; issue TAP for registration week; Conditional Access requires phishing-resistant strength for payroll app; Security defaults off.

Scenario B — Compromise: User reports unusual MFA prompts. Block sign-in, revoke sessions, reset password, revoke MFA methods, review risk detections, re-enable only after TAP-based re-registration and device compliance check.

Scenario C — Azure Files: Hybrid users need SMB access to Azure Files using identity. Configure storage for Microsoft Entra Kerberos, ensure hybrid identities and permissions, validate client access—do not answer “create cloud-only users with local share passwords” if identity-based hybrid access is the requirement.

Common traps

• Choosing disable only and forgetting revoke sessions on token theft questions.
• Confusing Seamless SSO with Entra Kerberos for Azure Files.
• Treating WHfB as “just a PIN password” rather than TPM-backed keys.
• Enabling passwordless methods without a TAP/recovery path.
• Assuming CAE means you never need to click Revoke sessions.

Closing the authentication methods chapter

/practice/azure-sc-300Practice questions with detailed explanations