GDAP for Microsoft Partners: Roles, Relationships and Pitfalls

A partner tenant with standing Global Admin on 80 customer tenants is the largest blast radius in the channel. Microsoft retired that model, and every CSP partner now manages customers through scoped, expiring relationships instead. This guide covers how GDAP works, which roles to request, and the pitfalls that show up six months after the rollout looks done.

What GDAP Replaced, and Why DAP Had to Go

Delegated admin privileges (DAP) gave a partner's Admin agents group Global Administrator on every customer tenant at once. One phished technician account, or one stale membership, and the attacker had the whole book of business. Granular delegated admin privileges (GDAP) replaces that with per-customer relationships that carry named Microsoft Entra roles and an expiry date.

Microsoft's introduction page describes it as least-privileged, time-bound access that the customer has to grant explicitly. Partners no longer receive Global Admin on a customer tenant by default; they get lower permissions to read the directory, and anything more has to be requested role by role.

The transition is over. New customers created in Partner Center get a default GDAP relationship instead of DAP, in production since October 10, 2023, with the rollout completed on December 2, 2023, per Microsoft's GDAP FAQ. A partner with only a reseller relationship and no GDAP can still create customers, place orders and download software keys, but can't see users, assign licenses, log support tickets on the customer's behalf, or open any admin center. If your team can't do those things for a tenant today, a missing or expired relationship is the first thing to check.

How a GDAP Relationship Works

The lifecycle has four steps, and each has a number attached. Every figure below comes from Microsoft's GDAP FAQ and setup pages, current as of April 2026.

1. Request. Someone with the Admin agent role in the partner tenant creates a request in Partner Center: a unique name, a duration in days, and a list of Entra roles. The request expires if the customer does nothing for 90 days.
2. Approval. The customer's Global Admin accepts through a personalised link. The relationship then shows up under Granular administration.
3. Assignment. Approval alone grants nothing. The partner has to map security groups from its own tenant to the approved roles. A relationship with no assignments shows a yellow warning icon in Partner Center, and there's a limit of 100 security groups per customer.
4. Expiry. The maximum duration is two years, and permanent relationships aren't possible. Auto extend adds six months at a time until someone disables it, and enabling it on an active relationship doesn't need fresh customer consent.

Two rules trip people up at step 1. Roles can't be added to a relationship after it's created; you make a new one. And every role in a relationship shares the same expiry, so a relationship that mixes day-to-day roles with a rarely used one expires them together.

Role Design: Groups Per Job, Not Global Admin

The old habit was one Admin agents group with everything in it. Microsoft's own guidance now says the opposite: remove partner staff from the Admin agent role, put them in GDAP security groups only, and they can administer services without being able to buy, cancel or resize subscriptions. That matches how role-based access works everywhere else.

Microsoft's role guidance page (updated January 2025) lists the least-privileged role for each task. For a tier-1 help desk the set is small: Service support administrator to open tickets, Help Desk administrator to reset non-admin passwords, User administrator for accounts and groups, License administrator for licenses, Exchange administrator for shared mailboxes, Intune administrator for enrollment, and Security reader to look at policies without changing them. Directory readers and Global reader cover read-only work.

The pattern that scales is one security group per role, so a technician's access is the sum of the groups they're in. The r/msp reply below says the same thing, and adds the point new partners miss: the Admin agents group is a service role, not a place for regular users.

Escalation gets its own path. Microsoft recommends Privileged Identity Management on a GDAP security group, so a senior engineer gets a high-privilege role just in time, with automatic removal. That's the privileged access model applied to customer tenants: nobody holds Global Admin as a standing right, and the audit trail shows who elevated and when.

When a task can't be done any other way, the FAQ's advice is to work with the customer on a time-bound Global Administrator relationship for that job. It also warns against the workaround that looks clever: requesting every Entra role that exists as a substitute for Global Admin. That's the same blast radius with more clicks.

The Pitfalls That Bite Later

Most GDAP problems don't show up at rollout. They show up at renewal, during an incident, or the first time a technician tries something the model doesn't cover.

The one that surprises technicians most is content access. GDAP works at the admin-center level, and some workloads don't expose everything through it. The r/msp thread below is a good example: a partner running a least-privilege setup found that folder-level SharePoint permissions inside a customer site couldn't be managed through the relationship, and the replies list Purview and app consent requests as similar gaps. The workable answers were moving special permissions to their own sites, using just-in-time SharePoint administrator rather than Global Admin, or a documented service account in the customer tenant that the customer approves.

None of those gaps are a reason to go back to standing Global Admin. They're a reason to write down, per workload, which path a technician takes when the relationship isn't enough. That list belongs in the same place as your client offboarding checklist, because termination is the other moment GDAP matters: when a customer or partner ends the relationship, the security groups lose access immediately, and Global Admins on the customer side get the notification.

Rolling It Out Across Every Tenant

Partner Center creates relationships one customer at a time, and there's no template. For a partner with a few dozen tenants that's a morning of clicking; for a few hundred it's a project. Three routes exist.

Microsoft 365 Lighthouse has a GDAP setup wizard with role templates you can save and reapply, and it's open to indirect resellers and direct-bill partners. Lighthouse itself needs a GDAP or DAP relationship per tenant, and its requirements page (updated April 2026) caps managed tenants at 2,500 licensed users in the same geographic region as the partner. The Partner Center APIs let you create relationships in bulk, which is how Microsoft answers the "10,000 customers" question in its own FAQ. Community tooling such as CIPP wraps the same APIs with an invite wizard and per-role groups, which is why so many of the r/msp threads on GDAP are also CIPP threads.

Whichever route you take, the sequence for an existing customer with Azure is fixed: create GDAP for both Microsoft 365 and Azure, assign Entra roles to security groups for both, confirm GDAP takes precedence, and only then remove DAP. Azure access runs through a security group such as Azure Managers nested under Admin agents with Directory readers, and skipping that step is how partners lose the subscription mid-migration.

Put the relationship expiry dates into the same review as your identity and access audits. Partner Center has an Expiring Granular Relationships page for exactly this, and the GDAP relationship analytics report shows the end dates across the book.

What to Do This Week

Pull the list of active relationships and sort by end date. Find every one that includes Global Administrator, because none of those can auto extend, and decide whether the role still needs to be there. Check the default relationships on customers created since late 2023 for missing group assignments. Then write the per-workload escalation list, so the next SharePoint permissions ticket has an answer before a technician reaches for a Global Admin account.

GDAP is the access model Microsoft's channel now runs on, and it rewards the partners who design roles per job, keep Global Admin behind just-in-time elevation, and treat expiry as a scheduled event. Next, read how IAM tools handle the same problem inside a single company.

FAQ

How long can a GDAP relationship last?
Two years at most, per Microsoft's GDAP FAQ. Permanent relationships aren't allowed. With auto extend enabled, the end date moves out by six months at a time until it's disabled or the relationship is terminated. Relationships that include the Global Administrator role can't auto extend.

What is the difference between DAP and GDAP?
DAP gave the partner's Admin agents group Global Administrator on every customer tenant it was linked to. GDAP is per customer, per role and time-bound, and the customer approves it explicitly. Where both exist, GDAP permissions take precedence. New customers have been created with a default GDAP relationship instead of DAP since late 2023.

Can I add roles to an existing GDAP relationship?
No. Roles can't be added after a relationship is created. Create a new relationship with the extra roles and have the customer approve it. Security group assignments within the approved roles can be changed at any time.

Which GDAP roles does a help desk need?
Microsoft's role guidance lists Service support administrator for tickets, Help Desk administrator for password resets, User administrator, License administrator, Exchange administrator, Intune administrator and Security reader as the tier-1 set. Read-only work uses Directory readers or Global reader.