Repairing Vendor Integrations Under GDAP: What the MSP Does, What the Vendor Builds

Back in October 2022, the warning went out that GDAP would break vendor integrations. This is the repair guide. It applies to vendors whose integrations use delegated access into downstream customer tenants through the partner relationship. If your integration asks each customer tenant for consent individually, none of this affects you.

What makes the vendor scenario different from fixing your own scripts is that the work splits across two parties: the MSP has prerequisites to configure in their own environment, and the vendor has a consent workflow to build into their product. Skip either half and the integration breaks. (MSPs repairing their own first-party automations should follow the companion guide for internal automations instead, which shares several prerequisite steps.)

Timing matters: as of early May 2023, Microsoft's stated plan was to begin auto-transitioning relationships to GDAP on May 22, 2023. If that schedule held, late May 2023 is when most readers discovered their integrations had stopped. Getting ahead of it beats debugging it.

What GDAP actually removed#

Partner access to customer tenants traditionally ran on Delegated Access Permissions (DAP), which meant Global Administrator access to every downstream tenant. An app registration built on the Secure Application Model only needed its service principal added to the Admin Agents group in Partner Center, and refresh tokens and access tokens flowed into every customer environment. Years of automation workflows were built on this. Because no further steps were ever required, the model earned the name pre-consent.

GDAP's entire purpose is the extra layers of security protecting partners and their customers against supply chain attacks, and pre-consent did not survive the redesign. Applications now require explicit consent in each downstream customer tenant. The consolation is an on-behalf-of consent model that grants consent in bulk rather than per customer. The catch is a setup with several more steps, and plenty of room for confusion. Hence this playbook.

The MSP's half: prerequisites in the partner environment#

Vendors should hand their MSP partners this exact list, because the consent workflow fails without it.

A service account dedicated to the integration#

First, the partner sets up a new service account just for this integration, named something like YourCompany@mspdomain.com. A dedicated account matters because tying the integration to a regular user means it breaks the day that user leaves the organization. The account requirements:

• Global Administrator initially. The account needs the GA role when access tokens are acquired in later steps. It does not need standing GA rights, so the recommended pattern is Privileged Identity Management (PIM) (opens in new tab), making the account eligible for the role on demand and shrinking the attack surface.
• MFA, enforced through Conditional Access or per-user MFA settings. It must be Microsoft's MFA; a third party like Duo will not work.
• Membership in the Admin Agents group in Azure AD.

Direct the MSP to store this account's password and MFA token in a documentation tool like IT Glue or Hudu, so more than one person can reach it if needed.

GDAP relationships with the right roles, plus a security group#

The partner also needs a GDAP relationship in place for every customer the integration touches. Partners new to GDAP can start with what GDAP is, a GDAP checklist, and using PIM with GDAP.

The roles scoped into those relationships carry two separate requirements:

1. Consent capability. Using the on-behalf-of consent model to grant the application rights into downstream tenants requires the relationship to include one of these Azure AD roles: Global Admin, Privilege Role Admin, or Cloud Application Admin.
2. Permission coverage. The relationship must also include roles that encompass the integration's API permissions. An integration that reads Intune configuration profiles needs the Intune Administrator role in the relationship, and so on per workload.

This means vendors must tell MSPs exactly which roles their GDAP relationships need. Vague documentation here turns into helpdesk tickets later.

The other key step: the partner assigns a security group to each GDAP relationship, with the integration's service account as a member. The group can be integration-specific or an existing one. This example uses a group named GDAP_SG1 containing the service account:

In Partner Center, that security group must be assigned to each GDAP relationship with at least one of these permissions: Global Admin, Application Admin, or Cloud Application Admin.

The vendor's half: build the consent workflow#

Whether the integration is new or existing, the MSP prerequisites above come first. The vendor's own work then breaks into three pieces: an onboarding flow built on the Secure Application Model, customer discovery, and automated consent.

An onboarding flow built on the Secure Application Model#

The app needs a front end that walks an MSP through the Secure Application Model process (opens in new tab). Programmatically, that flow should:

• Create an app registration in the partner's tenant
• Create and store the app registration's secret key, client ID, and partner tenant ID
• Generate and store a refresh token

The partner signs in during this flow with the service account created earlier. The permissions added to the app registration should be everything the integration needs to function.

Discover the partner's downstream customers#

With the secrets stored, the vendor can generate an access token, attach it as an authorization header, and pull the partner's downstream customer tenants. Store the customer tenant IDs; they become variables in the consent calls. Several APIs return the list:

• Get customers (Partner Center REST API) (opens in new tab)
• List contracts (Microsoft Graph v1.0) (opens in new tab)
• List delegatedAdminCustomers (Microsoft Graph v1.0) (opens in new tab), which requires the partner to hold a Microsoft Lighthouse license

Consent on behalf of each customer#

Microsoft built an API for consenting on behalf of downstream customers (opens in new tab), replacing the one-customer-at-a-time alternative. The call uses an access token generated from the app registration created in the partner's tenant through the Secure Application Model. The body carries the application ID, the application name, and the list of all application grants that make up the integration:

Each enterprise application ID represents a Microsoft workload. Most integrations will interact primarily with the Microsoft Graph workload. The workload IDs:

Once consent completes, the vendor can acquire access tokens into downstream customer environments and call APIs for those tenants' data, the same as before GDAP.

Permission updates mean re-consent#

Adding permissions to the integration later requires re-consenting across all customers: revoke the existing consent, then re-add it through the same steps with the new scope in the request body. The removal endpoint lives in the same documentation: remove consent (opens in new tab).

Two background jobs to schedule#

• New-customer sweep. Partners add customers continually, so build an automated job that periodically looks for new tenant IDs and runs the consent workflow against them.
• Refresh token renewal. The partner refresh token lasts 90 days, so a second job needs to renew it on schedule. Microsoft's secure-app-model samples on GitHub (opens in new tab) cover the pattern.

Secret handling is the vendor's biggest responsibility#

A vendor offering no self-hosting option is holding the keys to its partners' customer environments, and managing those application secrets demands real care. Encryption at rest and in transit are table stakes. A breach of those secrets or refresh tokens would let an attacker run the same workflow the integration uses to operate in downstream customer tenants. The damage is bounded by the integration's scoped permissions and the GDAP roles available to the service account, so the blast radius is smaller than the DAP-era equivalent, but in our view it still warrants the highest level of attention.

Is on-behalf-of consent worth it over per-tenant consent?#

Both vendors and MSPs should weigh the on-behalf-of model described here against plain per-tenant consent.

The case for on-behalf-of:

• Onboarding time drops sharply for both sides. Compare logging in to every single customer tenant against one setup wizard and one sign-in.
• Permission updates can be re-consented automatically across all customers, instead of asking the partner to redo consent everywhere by hand.

The case against:

• Every prerequisite in this playbook has to be done, and the GDAP relationships must keep the roles the integration needs. Per-tenant consent sidesteps GDAP entirely, which can mean a smoother customer experience and fewer helpdesk calls.
• The vendor carries far more operational overhead: many more stored secrets, a dedicated Secure Application Model setup flow, token refresh jobs, and a consent automation job.

Reference material#

Microsoft's official document on the transition: DAP to GDAP Application Consent and OBO (PDF) (opens in new tab)