Cutting 14 permanent Global Administrators down to four without breaking consent or on-call alerting
Northwind Logistics runs one Microsoft 365 E3 tenant with 2,800 licensed users on a single verified domain. An external audit found 14 Global Administrators, all permanently assigned, with no approval evidence. The 22-agent tier-1 service desk needs to reset passwords, revoke sessions, and read sign-in logs for end users. A four-engineer identity team must grant tenant-wide admin consent to third-party SaaS apps roughly twice a month. Operations wants service-health incidents and Message Center posts emailed to an on-call distribution list, but the on-call rota includes contractors who must not receive any directory role. The CISO has mandated no more than four permanent Global Administrators, time-bound and approved access for every other admin role, and full attribution of privileged actions. No Entra ID P2 add-ons are currently purchased.
1. Which roles do you assign to the service desk and to the identity team, and how is each assignment delivered? Justify each choice.
Read the worked answer
Map each task to a permission, then to the smallest role that carries it.
- Password reset and session revocation for end users → Helpdesk Administrator. It explicitly cannot reset passwords for privileged administrators, which is exactly the guardrail you want on a 22-person tier-1 team.
- Read sign-in logs → Reports Reader. Do not assume it comes bundled with Helpdesk Administrator; it is a separate role and the most commonly over-granted one.
- Tenant-wide app consent → Cloud Application Administrator, not Global Administrator. It covers routine third-party SaaS consent without directory-wide control.
Delivery: every assignment is PIM eligible, not active, with MFA at activation, a written justification, and approval by the identity lead. Team members administer from a separate cloud-only account (for example adm-<name>@) so privileged work never shares a session with email and browsing - this is what makes 'attributable to a named person' true rather than aspirational.
Licensing catch to raise now: PIM is an Entra ID P2 feature, and Microsoft 365 E3 includes Entra ID P1 only. The CISO's time-bound-access mandate cannot be met for those 26 administrators without P2 or Entra ID Governance licences. No amount of role hygiene substitutes for the licence, so surface this before designing further.
2. The four-permanent-GA rule appears to conflict with the identity team's monthly consent task. How do you resolve it, and what should you watch for when removing the ten surplus administrators?
Read the worked answer
The conflict disappears once you separate permanent from eligible.
- Keep exactly four permanent Global Administrators: two break-glass cloud-only accounts (excluded from every Conditional Access policy, credentials split and sealed, sign-in alerts on use) and two senior administrators.
- The identity team gets Cloud Application Administrator as an eligible PIM role for routine consent.
- Cloud Application Administrator cannot consent to Microsoft Graph application permissions or high-privilege Graph app roles. For those, add Privileged Role Administrator as an eligible role with a second approver - it can grant consent to any delegated or application permission without carrying Global Administrator's blast radius.
Removal sequence for the ten surplus GAs: export all role assignments first, then check each account's sign-in and privileged activity for 30 days before removal. Look specifically for automation, runbooks, and vendor support accounts that authenticate as those people - those break silently weeks later. Require a reason code on removal and record it.
Watch for: role assignments made directly rather than through groups; service principals with high-privilege Graph permissions held by the same people; and PIM role settings that allow self-approval, which quietly recreates permanent access. Add a quarterly access review of privileged roles so the number cannot creep back to 14.
3. How do you deliver service-health and Message Center notifications to the on-call rota without giving contractors an admin role?
Read the worked answer
Treat notification as a setting, not a role.
- Message Center: Microsoft 365 admin center → Health → Message center → Preferences → add the on-call distribution list as an additional recipient. Recipients get the digest by email and gain no portal access.
- Service health: Health → Service health → Customize/Preferences → add the same distribution list for incident and advisory notifications.
- Automation, for a rota that includes contractors: register an app with the Office 365 Service Communications API (
ServiceHealth.Read.Allapplication permission) and have a Power Automate flow query incidents and post to the on-call channel or trigger the paging tool. The permission sits on the app registration, so no person - contractor or employee - holds a standing directory role, and every read is attributable to the flow.
Do not assign Service Support Administrator to contractors just so they can see service health. That role also exposes Message Center content and creates a standing privileged identity for people outside the organisation.
Verification: confirm the distribution list is mail-enabled and external senders are blocked, then test by raising a benign support request. Notification paths are only real when they have been fired once on purpose.