Fourteen Standing Global Admins: Sequencing an Identity Hardening Plan
Litware has 2,400 employees synced from on-premises Active Directory through Entra Connect. Security defaults are disabled and Conditional Access is not used at all; MFA is enforced by an on-premises policy that only applies to VPN logins. An access review found 14 permanent Global Administrators, three of them in the helpdesk team, and no break-glass account exists. A contracting firm needs access to a dev subscription for eight weeks starting Monday, and each contractor has a mailbox in their own tenant. Separately, an application team stores a storage account key in App Service application settings; the last manual 90-day rotation left the application offline for four hours. The security team has Entra ID P2 licences for all staff.
1. Sequence the first 30 days of identity hardening. State what you do first, and what could take the tenant down if done out of order.
Read the worked answer
Order matters more than the list.
- Create two cloud-only break-glass Global Administrator accounts with long random credentials, stored offline, excluded from every Conditional Access policy, and monitored by an alert on any sign-in. This is step one because every later step is a lockout risk.
- Convert standing Global Admins to eligible assignments through PIM. P2 is already licensed. The three helpdesk staff should hold Helpdesk Administrator or User Administrator, not Global Administrator. Keep two permanent admins besides break-glass, no more.
- Write Conditional Access policies in report-only mode first, then enforce: require MFA for all users, require a compliant or hybrid-joined device for the Azure portal and admin portals, and block legacy authentication. Report-only gives you the impact assessment before enforcement; skipping it causes exactly the outage leadership fears.
- Exclude the Entra Connect sync account and service accounts from MFA-enforcing policies so directory synchronization does not stop.
- Add Identity Protection risk-based policies for sign-in and user risk, and issue temporary access passes for recovery scenarios.
The single most dangerous misstep is enforcing a device-compliance policy for admins before break-glass accounts and exclusions exist.
2. Design the contractor access. Justify each control against the eight-week, cross-tenant facts.
Read the worked answer
Onboarding: Entra ID B2B guest invitations, not member accounts in your tenant. Guests authenticate in their own tenant, which means their home organization keeps ownership of credential lifecycle.
Packaging: Entitlement Management access package with a time-bound assignment policy of exactly eight weeks, an approval workflow, and an access review scheduled at week six. The licence dependency is real: access packages require Entra ID Governance or P2 for the users in scope. If that is not available, replicate the intent manually with a calendar-driven removal task and a ticket that cannot be closed by the requester.
Authorization: Azure RBAC on a resource group, not Owner on the subscription. Contributor on the dev resource group is usually sufficient and keeps them out of the control plane.
Conditional Access: require MFA and a compliant device. Contractors' laptops are almost certainly not Intune-enrolled, so either trust MFA from their home tenant via cross-tenant access settings and pair it with terms of use, or accept MFA plus a named location restriction. Choosing the first option is a deliberate decision to extend trust to another tenant's MFA, and should be written down as such.
Offboarding: revocation must be verified, not assumed. Guests can retain token-based access until the token expires.
3. Eliminate the embedded storage key and explain why the previous rotation caused an outage.
Read the worked answer
Why the outage happened: rotation changed the secret in two places that had to be updated in the same instant, the application settings and the storage account. Any gap between them, or any instance holding a cached connection string, fails authentication. Rotation on a schedule with no automated propagation is a planned outage waiting for a maintenance window.
Elimination
- Enable a system-assigned managed identity on the App Service and grant it Storage Blob Data Contributor scoped to the container. Data-plane roles are required; Owner at the subscription will not read a blob.
- Remove the key from application settings and from source control history, not just from the current deployment.
- Set the storage account to disallow shared key access, so the anti-pattern cannot return quietly.
- Put the storage account behind a private endpoint and verify the app's outbound VNet integration path.
- Replace the 90-day rotation calendar with monitoring: alert on 403s from the application and on any role assignment change at the storage scope.
If the same application is later lifted to on-premises or another cloud, managed identity stops being available. Use workload identity federation with a federated credential instead of reintroducing a shared secret.