Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

2.1.5. Password Protection, Entra Kerberos, and Session Revocation

💡 First Principle: Even in a passwordless-forward tenant, passwords persist somewhere — so you harden what remains (ban guessable passwords everywhere, including on-prem), bridge old protocols to new identity (Entra Kerberos), and keep a kill switch for live sessions (revocation).

Microsoft Entra Password Protection rejects bad passwords at change time: a Microsoft-curated global banned list plus your custom banned password list (company name, product names, local sports teams), evaluated with fuzzy matching (l33t substitutions, case). The distinctive part is on-premises enforcement: DC agents plus a proxy service extend the same policy into Active Directory password changes — the proxy makes outbound-only connections, and the design keeps working if connectivity drops (agents use the last downloaded policy). Audit mode lets you measure impact before Enforce. Smart lockout complements it, locking out guessing attempts while trying to keep the legitimate user (familiar location/device) unlocked.

Microsoft Entra Kerberos answers a narrower riddle: cloud-authenticated (even passwordless) users who still need Kerberos tickets — classically for Azure Files shares or on-prem AD resources during passwordless sign-in. A Kerberos server object representing your AD domain is published in on-premises AD and synchronized to Entra ID, which lets Entra ID act as a KDC. Be precise about the ticket flow, because it is the detail that separates the two cases: for on-premises resources Entra ID issues a partial TGT carrying only the user's SID, and the device trades that partial TGT with a domain controller for a fully formed TGT — so line of sight to a DC is still required. What Entra Kerberos removes is the need for an on-premises password, not the need for a domain controller. For Azure Files, Entra ID is the KDC for the storage account itself, so no DC contact is involved. Exam tell: "users sign in with security keys but must access on-premises file shares / Azure Files with AD permissions" → enable Entra Kerberos.

Disable + revoke is the offboarding pair from Phase 1 made operational: disable the account (blocks new sign-ins), then revoke sessions (Revoke-MgUserSignInSession / "Revoke sessions" in the portal), which invalidates refresh tokens and forces reauthentication everywhere at next token refresh; CAE-capable workloads cut even faster. For hybrid users, disable in AD and let sync propagate — or disable in both places for immediacy.

⚠️ Exam Trap: The password protection proxy needs only outbound connectivity, and DC agents keep enforcing from cached policy when offline — answers requiring inbound ports or claiming "AD password changes fail when the proxy is down" are wrong.

Reflection Question: A terminated admin's account is disabled, but a colleague reports the admin's laptop still syncing mail 30 minutes later. List the exact next action and the two mechanisms that determine how fast it bites.

See how it connects
Alvin Varughese
Written byAlvin Varughese
Founder18 professional certifications