Break-Glass Accounts, PIM, and a Service Account That Cannot Do MFA
Contoso has 1,400 Microsoft Entra ID user accounts and a single Entra ID P2 tenant. Sixty engineers hold the User Access Administrator role permanently at subscription scope, and last quarter's review found 12 role assignments nobody could justify. The security team wants just-in-time elevation and has drafted these requirements: (1) privileged roles activate for a maximum of four hours with manager approval; (2) any account that has not signed in for 30 days must lose its assignment automatically; (3) legacy authentication protocols must be blocked for everyone except two break-glass accounts; (4) the break-glass accounts must never be subject to Conditional Access but must raise an alert when used. A scheduled PowerShell task on a Windows Server 2022 VM signs in as [email protected] every night at 02:00 and has been failing since the legacy-auth block was piloted. The identity team insists that excluding svc-backup from the policy is the fastest fix.
1. The identity team proposes excluding [email protected] from the legacy authentication block. Evaluate that proposal and recommend an approach that satisfies requirement 3 without creating a permanent exception.
Read the worked answer
What the policy is actually doing. A Conditional Access policy that blocks legacy authentication targets client apps that cannot perform interactive MFA (POP, IMAP, SMTP AUTH, older Office clients, some Exchange ActiveSync clients). A scheduled task authenticating with a stored username and password is exactly the pattern the policy exists to eliminate, so the failure is a design problem in the workload, not a policy defect.
Why the exclusion is the wrong fix. An excluded account becomes a standing, MFA-free entry point. The credential is almost certainly stored in the script or a config file on the VM, so anyone who can read that file or compromise the VM inherits whatever the account can do, indefinitely and invisibly. Excluding it also silently makes the account invisible to every future policy that includes the legacy-auth control.
Recommended path. Give the VM a system-assigned managed identity and grant it the minimum RBAC the job needs (for example Backup Operator on the recovery services vault, or Storage Blob Data Contributor scoped to one container). Replace the stored credential with Connect-AzAccount -Identity. Managed identity token acquisition is not blocked by the legacy-auth policy, and there is no password to rotate, leak, or store.
If a user account must stay temporarily. Use workload identity federation or a Key Vault-held certificate; if a user account is unavoidable, exclude a dedicated group that contains only that account, scope the exclusion to the legacy-auth policy only (never all policies), alert on sign-ins from that account, and put an expiry date on the exception.
First step. Confirm the failure really is policy-driven: a Conditional Access block returns a specific failure reason in the sign-in log, and a wrong password or a disabled account looks different. Recommend remediating the workload before touching the policy.
2. Sixty permanent User Access Administrator assignments must become just-in-time, and inactive holders must lose access automatically. Design the PIM and access review configuration and explain the ordering constraint.
Read the worked answer
Ordering constraint first. PIM for Azure resources only governs assignments made through PIM. A permanent active assignment created with New-AzRoleAssignment sits outside PIM entirely and is unaffected by PIM role settings, so configuring settings before converting the assignments changes nothing. The sequence is: inventory, clean up, convert, then configure.
1. Inventory. Export assignments with Get-AzRoleAssignment and correlate with sign-in activity. Remove the 12 unjustified assignments outright, and question whether User Access Administrator at subscription scope is needed at all: it can grant any role, so it is effectively owner-equivalent. Where possible, move to a narrower role at resource-group or management-group scope.
2. Convert. For each remaining assignment, remove the active assignment and create an eligible one through PIM, or make the assignment eligible directly. Consider placing the holders in a role-assignable group and making the group eligible; this reduces per-user churn and gives the access review a single object to review.
3. Configure role settings at subscription (or management group) scope: maximum activation duration 4 hours, require justification, require approval with named approvers and a sensible approval timeout, require MFA on activation, and enable notifications to admins when a role is activated.
4. Requirement 2 is not a PIM role setting. PIM offers assignment start and end dates, which is time-based, not activity-based. Inactivity removal comes from access reviews: a recurring monthly review of the eligible group or role, configured to remove access automatically when reviewers do not respond or when a user is flagged as inactive, with the result applied automatically. Validate the inactive-user option available in your tenant before promising it, and fall back to a scheduled job that reads sign-in logs and deletes eligible assignments after 30 days of no sign-in.
5. Prove it. Log Analytics alerts on role activation outside business hours, and a monthly report of who activated what.
3. Requirement 4 says the break-glass accounts must never be blocked by Conditional Access but must alert when used. Describe the concrete configuration and the operational risks you would raise with the security team.
Read the worked answer
Account design. Two cloud-only accounts in the tenant's initial .onmicrosoft.com domain, so they do not depend on Active Directory Connect, federation, or a custom domain. Permanent Global Administrator, no PIM (PIM activation depends on a working sign-in path, which is exactly what may be broken), long randomly generated passwords split between two custodians, and FIDO2 keys stored separately offline. Do not license them for anything that could expire; an unlicensed account is not a recovery path.
Conditional Access. Put both accounts in one dedicated group and add that group to the Exclude list of every Conditional Access policy. Exclusions are per-policy, so the real operational risk is a new policy shipped next quarter without the exclusion, locking out the recovery path silently. Mitigate with a documented checklist item, an alert on any Conditional Access policy add/update in the audit log, and a periodic test that the accounts can still sign in.
Alerting. Create an alert rule on the SigninLogs table where UserPrincipalName is one of the two accounts, and a second alert on AuditLogs for changes to the break-glass group membership and for directory role changes. Route both to the SOC on-call channel, not to a shared mailbox.
Risks worth stating explicitly. An excluded account has no MFA enforcement, so if the password leaks and the FIDO2 key is not required by other means, the tenant is wide open; consider requiring phishing-resistant authentication through a separate policy rather than blanket exclusion if the tooling allows. Also, these accounts will never appear in PIM activation reports, so they must be covered by the sign-in alert above or their use is effectively unmonitored.