Stop Cloning Admin Agents: How to Pick a GDAP Role Baseline That Holds Up

The hardest part of GDAP is not creating the relationship. It is the dropdown that follows: a list of granular Azure AD roles most MSPs have never had to think about, because DAP handed everyone Global Admin and called it a day. If you need the background on what GDAP is in the first place, start with the high-level overview. This post is about the decision that comes after: which roles to request, and how to structure them so the granularity actually means something. Everything here reflects GDAP as it stood in March 2022.

Think in buckets, not checkboxes#

The architecture rewards a moment of planning. The GDAP relationship link is the large bucket: every permission you could possibly want in that customer's environment. Once the relationship is established, you assign those roles to security groups inside your own organization, and that mapping is not one-to-one. You can carve as many sub-buckets as you want with as many security groups as you want.

Most partners have only ever used the Admin Agents and Helpdesk Agents groups in Partner Center. We would push hard against recreating that pattern. Depending on the size of your organization, build security groups per technician tier, or break them out by workload: Intune, 365 licensing, Exchange, and so on. The groups are the mechanism that turns a pile of granted roles into actual least privilege.

Build the baseline from Microsoft's least-privilege map#

Microsoft maintains a breakdown of which Azure AD role is least privileged for each admin task (opens in new tab), alongside broader roles that encompass each permission set. Run through that list and define a baseline: the roles you would always want in any customer environment.

Two things fall out of that exercise:

• Some roles you will simply never need in certain environments, MFA Server being an obvious example. Leave them out.
• Some rights are customer-specific. If a customer has no Power BI footprint, the Power BI permission has no business being in that customer's GDAP invitation.

If you have never defined access controls for your Partner Center users, a simple matrix works: technicians down one axis, roles across the other, and an honest answer in each cell about who needs what. That exercise produces both your baseline and your per-customer exceptions.

The Global Admin problem#

Work through the least-privilege documentation and you will notice a handful of tasks still list Global Administrator as the minimum role, mostly initial configuration jobs like setting up AD Connect. Requesting Global Admin through GDAP defeats much of the point of GDAP.

Our recommendation, in order:

1. Reach for Global Reader first. It grants no write capability, and GDAP opens portals that delegated administration never reached before, including the Security and Compliance Center. That alone should retire some bad habits, like a shared customer-tenant GA account with MFA codes passed between techs.
2. If you genuinely need GA, gate it. Put the Global Administrator role on its own dedicated security group and control that group's membership with PIM (Privileged Identity Management). The key points:

• Azure AD P2 licensing, which includes PIM, was open as a free full-year trial for indirect resellers as of March 2022.
• You can create a role-assignable group in Azure AD and configure eligible members for just-in-time access, optionally gated by approval. Microsoft documents the pattern here: assign eligible group members and owners (opens in new tab).
• That security group gets applied against the customer with Global Administrator rights attached.
• When someone in your org needs GA, they request temporary membership, do the task in the customer tenant, and the membership expires.

The result: the GA permission can still exist in your GDAP relationship, but the attack surface around it shrinks to the hours someone has actively claimed it.

Keep DAP until the gaps close#

One caveat that matters as of March 2022: not every workload supported GDAP yet. Adding the SharePoint Admin role, for instance, did not yet produce the admin-on-behalf-of link into that admin center. Until coverage completes, keep your DAP relationships running alongside GDAP rather than cutting over early and stranding your techs.