Northwind: Legacy Auth Block, Break-Glass Accounts, and a 30-Day Admin MFA Deadline
Northwind has 6,500 users. Everyone holds Microsoft Entra ID P1; only 400 P2 licenses exist, held by IT and finance approvers. Last month an engineer enforced a Conditional Access policy blocking legacy authentication for all users except two break-glass accounts. Within a day, 220 finance users lost access to an on-premises ERP whose connector authenticates with each user's own credentials over IMAP, and 60 warehouse scanners stopped syncing. The two break-glass accounts are cloud-only Global Administrators excluded from every policy, sharing one long password stored in a shared mailbox. Management wants phishing-resistant MFA for all directory role holders within 30 days. The helpdesk currently cannot issue Temporary Access Passes.
1. Restore service to the ERP users and the scanners without weakening the legacy authentication block. How do you prove which sign-ins are affected?
Read the worked answer
Prove first, change second. In Entra sign-in logs, filter Client app = Other clients and Status = failure, then open a failing event and read the Conditional Access tab to confirm the policy name. This separates 'blocked by my new policy' from unrelated breakage.
Then triage by identity type, not by user:
- ERP connector authenticating as each user: the block is working as designed. Excluding 220 finance users would re-open basic auth for those accounts and is a security regression. The fix is on the application side - modern authentication for the connector. Until it ships, use a short, dated exclusion scoped to the connector's identity, not to the humans, and record the exception with an expiry.
- Scanners: these typically cannot do modern auth. Give them a dedicated service identity in a group excluded from the policy, constrain that identity with a named location matching the warehouse egress IPs so it cannot be used from anywhere else, strip any other entitlement from it, and treat the exclusion as a compensating control with a hardware-refresh plan.
Verification: after the change, re-run the same sign-in query. Successes under 'Other clients' should exist only for the excepted service identities. Before rolling to the full population next time, run the policy in report-only mode for a week and use What If against the service identities you already know about - those two steps would have caught both cohorts.
2. Assess the break-glass account design. What do you keep, what do you change, and why?
Read the worked answer
Keep: two cloud-only accounts, permanently assigned Global Administrator, excluded from every Conditional Access policy. That is the intended pattern - a break-glass account must still work when Conditional Access, MFA, and federation are broken, so it must not itself depend on them.
Change:
- Shared password in a mailbox is the real defect. Anyone with mailbox access is a Global Administrator, and there is no non-repudiation. Replace with unique, long, randomly generated credentials stored out-of-band (sealed envelope in a physical safe, or FIDO2 keys in a dual-custody process) under a documented emergency procedure.
- Add detection, not just prevention. These accounts should have zero routine sign-ins. Alert on any successful sign-in to them, and on any change to their credentials or role assignments.
- Do not put them in PIM. An eligible assignment must be activated first, which defeats the purpose when the activation path itself is broken. Permanent active assignment is correct precisely because it is the fallback.
- Verify the authentication path. If the tenant uses federation or certificate-based auth, confirm the break-glass account's authentication does not traverse that infrastructure (for example, cloud-only account with password hash sync unaffected).
Test the procedure quarterly, including 'can we still sign in if Conditional Access is misconfigured and the FIDO2 key is unavailable'.
3. Can the phishing-resistant MFA deadline be met with only 400 P2 licenses? Design the rollout and name the bootstrap trap.
Read the worked answer
Yes - P2 is not the constraint. Conditional Access authentication strengths and Temporary Access Pass are P1 capabilities. The 400 P2 licenses are irrelevant to this requirement.
Design:
- Create a Conditional Access policy targeting directory roles (or a dedicated admin group) with grant = Require authentication strength: Phishing-resistant MFA. This strength accepts FIDO2, Windows Hello for Business, and certificate-based authentication. Microsoft Authenticator phone sign-in does not satisfy it.
- Exclude the break-glass accounts.
- Run in report-only for one to two weeks to size the population that would fail, then enforce.
- Enroll methods: issue FIDO2 keys to admins who cannot use WHfB, and start a registration campaign so admins are nudged.
The bootstrap trap: a new or recovering admin has no phishing-resistant method yet, and Temporary Access Pass is not phishing-resistant, so the policy blocks them from registering one - a deadlock. Resolve it with a small onboarding group excluded from the phishing-resistant policy but still subject to normal MFA, with TAP restricted to single use and a short lifetime, plus an alert whenever a TAP is issued. Remove users from that group as soon as registration completes.
Also delete stale per-user MFA settings and confirm no legacy 'require MFA' baseline policy conflicts; two overlapping policies produce confusing failures during cutover.