Lesson 2: Who Can Do What: The Smallest Role for Each Job

Why the smallest role matters in cutover week

In cutover week you will be asked to do the same few jobs again and again: reset a password, get someone back into MFA on a new phone, give an assistant access to a manager's mailbox, sort out a OneDrive or site access problem, or read a sign-in log to see why a login failed. Each of these needs an admin role. The easy request is "just give support Global Administrator for the week". Don't make it.

Think of roles as a key ring. Global Administrator is the master key to every door in the building, including the server room and the safe. If your account gets phished on day three, the attacker has the master key too. A role that fits the job opens one corridor. If it leaks, the damage stays in that corridor, and the audit log shows clearly what you could and could not have done. Microsoft's own SharePoint admin documentation says it plainly: use the roles with the fewest permissions, and keep Global Administrator for emergencies when no other role will do.

The second habit is to date your checks. Role names and permissions change. Write "checked 3 Nov 2026" next to any role you rely on, and check again before the next migration.

The job-to-role map (checked 3 November 2026)

Gotcha: Helpdesk Administrator resets passwords. It does not cover the MFA job. Most of the "I got a new phone" tickets in week one need Authentication Administrator. Ask for both, not for one big role.

Gotcha (Google): only a Super Admin can reset another administrator's password. If the user who is locked out of Google is an admin, the ticket goes up the chain.

Walkthrough 1: read a role's real permissions in Entra

Don't take the table above on trust. Look at the source. In the portal:

1. Sign in at https://entra.microsoft.com.
2. Browse to Entra ID > Roles & admins.
3. Click the role name (don't tick the box next to it).
4. Select Description to see the summary and the full permission list.

The same check in PowerShell is read-only and leaves you a record you can paste into a ticket:

# Read-only scope: lets you list roles, not change them
Connect-MgGraph -Scopes "RoleManagement.Read.All"

# Stop PowerShell cutting the permission list short with "..."
$FormatEnumerationLimit = -1

# Show the role's description and the actions it allows
$role = Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Helpdesk Administrator'"
$role.Description
# -> Can reset passwords for non-administrators and Helpdesk Administrators.
$role.RolePermissions.AllowedResourceActions

# Stamp the check so you know when it was true
"Checked $(Get-Date -Format 'yyyy-MM-dd') by $env:USERNAME"

For Exchange role groups, connect to Exchange Online PowerShell and run Get-RoleGroup -Identity "Recipient Management" | Format-List. In the Exchange admin centre the same list is at Permissions > Admin roles (https://admin.exchange.microsoft.com/#/adminRoles).

Walkthrough 2: read a role in the Google Admin console

The Google tenant stays live during coexistence, so you may still need Google access:

Admin console > Menu > Account > Admin roles
  > select the role (e.g. Help Desk Admin)
  > Privileges  -> what the role can do
  > Admins      -> who holds it directly

Two honest caveats. First, Google's documentation says viewing role assignments needs a super administrator, so support staff often can't run this check themselves. Ask the project team for a screenshot, and date it. Second, the Admins view lists direct assignments only. Someone who gets a role through group membership won't appear there, so check their own user page under Admin roles and privileges.

Walkthrough 3: ask for a missing role the right way

When you hit "You don't have permission", don't ask for "admin rights". Send a request the project team can approve in thirty seconds:

To: Migration project team
Subject: Role request - Authentication Administrator for J. Patel, cutover week

Job:      Require MFA re-registration for staff who got new phones
          (14 tickets open, e.g. INC-20431)
Role:     Microsoft Entra "Authentication Administrator"
Why this: Least-privileged built-in role for resetting auth methods
          of non-admin users. Helpdesk Administrator (which I hold)
          covers passwords only. Checked on Entra ID > Roles & admins,
          3 Nov 2026.
Scope:    Non-admin users; time-limited if you use PIM/expiry
Duration: Cutover week + 2 weeks (to 28 Nov 2026)
Not asking for: Privileged Authentication Admin or Global Admin -
          admin-account resets will come to you.

The request names the job, gives a ticket as evidence, names the exact role, shows why a smaller role won't do, sets an end date, and says what you are not asking for. That last line is what builds trust with the project team.

Best practice: if the project uses time-limited assignments, ask for the role to expire. If it doesn't, put the review date in your own calendar. Roles handed out in cutover week tend to stay for years.

Key takeaways

• Match the role to the job: Helpdesk Administrator for passwords, Authentication Administrator for MFA re-registration, Exchange Recipient Administrator for mailbox permissions, site admin for one site, Reports Reader for logs, and Google Help Desk Admin for non-admin Google passwords.
• Global Administrator is never the answer for routine support. It turns a phished support account into a tenant-wide breach.
• Admin users are a separate case: resetting their methods needs Privileged Authentication Administrator or a Google Super Admin, so escalate those tickets.
• Check a role's live permissions (Entra ID > Roles & admins > role > Description, or Get-MgRoleManagementDirectoryRoleDefinition), and write down the date you checked.
• Ask for a missing role with a request that names the job, the evidence, the role, why a smaller one won't do, the duration, and what you are not asking for.