GDAP frequently asked questions

Someone with the Admin agent role at a partner organization can create a GDAP relationship request.

Yes. GDAP relationship requests expire after 90 days.

No. Permanent GDAP relationships with customers aren't possible for security reasons. The maximum duration of a GDAP relationship is two years. You can set Auto extend to Enabled to extend an admin relationship by six months, until terminated or auto extend being set to Disabled.

No. GDAP relationship doesn't support subscriptions purchased through enterprise agreements.

Yes. A GDAP relationship can auto extend by six months until terminated or auto extend set to Disabled.

• If the GDAP relationship with your customer expires, request a GDAP relationship again.
• You can use GDAP relationship analytics to track GDAP relationship expiration dates and prepare for their renewal.

To extend or renew a GDAP relationship, a partner or customer must set Auto extend to Enabled. Learn more at Manage GDAP Auto extend and API.

Yes. If GDAP is active, it can be extended.

Say a GDAP is created for 365 days with auto extend set to Enabled. On the 365th day, the End Date effectively updates by 180 days.

Yes. You can auto extend any active GDAP.

No. Customer consent isn't required to set auto extend to Enabled against an existing active GDAP.

No. Granular permissions that are assigned to security groups continue as-is.

No. You can't auto extend the admin relationship with a Global Administrator role.

The Expiring Granular Relationships page is only available to partner users with the Global Administrators and Admin Agent roles. This page helps filter GDAPs expiring across different timelines, and helps update auto extend (enable/disable) for one or more GDAPs.

No. There's no change to a customer's existing subscriptions when a GDAP relationship expires.

Refer to Troubleshoot Microsoft Entra multifactor authentication issues and Can't use Microsoft Entra multifactor authentication to sign in to cloud services after you lose your phone or the phone number changes for guidance.

A partner must request the Privileged authentication administrator Microsoft Entra role when creating the first GDAP.

• This role enables a partner to reset a password and the authentication method for an admin or nonadmin user. The Privileged authentication administrator role is part of the roles set up by Microsoft Led Tool and is planned to be available with Default GDAP during Create Customer flow (planned for September).
• The partner could have the customer admin try Reset the password.
• As a precaution, the partner must set up SSPR (Self-service password reset) for their customers. For more information, see Let people reset their own passwords.

• Within a partner organization, people with the Admin agent role receive a termination notification.
• Within a customer organization, people with the Global admin role receive a termination notification.

Yes. Partners can see when a customer removes GDAP in the Partner Center activity logs.

No. GDAP is an optional capability for partners who want to manage their customer's services in a more granular and time-bound way. You can choose which customers you want to create a GDAP relationship with.

The answer depends on how you want to manage your customers.

• If you want your partner users to be able to manage all customers, you can put all of your partner users into one security group and that one group can manage all of your customers.
• If you prefer to have various partner users managing various customers, assign those partner users to separate security groups for customer isolation.

Yes. Indirect resellers (and indirect providers and direct-bill partners) can create GDAP relationship requests at Partner Center.

As part of GDAP setup, ensure that security groups created in partner tenant with partner users are selected. Also ensure the desired Microsoft Entra roles are assigned to the security group. Refer Assign Microsoft Entra roles.

Customers can now exclude CSPs from conditional access policy so that partners can transition to GDAP without getting blocked.

• Include users - This list of users typically includes all of the users an organization is targeting in a Conditional Access policy.
• The following options are available to include when creating a Conditional Access policy:
• Select users and groups
• Guest or external users (preview)
• This selection provides several choices that can be used to target Conditional Access policies to specific guest or external user types and specific tenants containing those types of users. There are several different types of guest or external users that can be selected, and multiple selections can be made:
• Service provider users, for example a Cloud Solution Provider (CSP).
• You can specify one or more tenants for the selected user types, or you can specify all tenants.
• External partner access - Conditional Access policies that target external users might interfere with service provider access, for example granular delegated admin privileges. For more information, see Introduction to granular delegated admin privileges (GDAP). For policies that are intended to target service provider tenants, use the Service provider user external user type available in the Guest or external users selection options.
• Exclude users - When organizations both include and exclude a user or group, the user or group is excluded from the policy, as an exclude action overrides an include action in policy.
• The following options are available to exclude when creating a Conditional Access policy:
• Guest or external users
• This selection provides several choices that can be used to target Conditional Access policies to specific guest or external user types and specific tenants containing those types of users. There are several different types of guest or external users that can be selected, and multiple selections can be made:
• Service provider users, for example a Cloud Solution Provider (CSP)
• One or more tenants can be specified for the selected user types, or you can specify all tenants. For more information, see:
• Graph API Experience: Beta API with the new external user type information
• Conditional access policy
• Conditional access external users

Yes. Regardless of the support plan you have, the least privileged role for partner users to be able to create support tickets for their customer is Service support administrator.

No. The partner can't currently terminate a GDAP in Approval Pending status. It would expire in 90 days if the customer takes no action.

Only after 365 days (clean-up) after the GDAP relationship terminates or expires, are you able to reuse the same name to create a new GDAP relationship.

Yes. A partner can manage their customers across regions without creating new partner tenants per customer region. It's applicable only to the customer management role provided by GDAP (Admin Relationships). Transaction role and capabilities are still limited to your authorized Territory.

No. A service provider can't be part of multitenant organization, they're mutually exclusive.

1. Ensure that GDAP is set up properly, including how you grant permissions for security groups.
2. Ensure that your granular Security group permissions are correct.
3. Refer to the Security Copilot FAQ for help.

For more information about APIs and GDAP, see the Partner Center developer documentation.

Yes. We recommend that partners use the beta GDAP APIs for production and later switch to APIs v.1 when they become available. Although there's a warning, "Use of these APIs in production applications isn't supported," that generic guidance is for any beta API under Graph and isn't applicable to the beta GDAP Graph APIs.

Yes. You can create GDAP relationships by using APIs, which enables partners to scale this process. But creating multiple GDAP relationships isn't available at Partner Center. For information about APIs and GDAP, see the Partner Center developer documentation.

The API works for one security group at a time, but you can map multiple security groups to multiple roles at Partner Center.

Make individual calls for each resource. When making a single POST request, pass only one resource and its corresponding scopes. For example, to request permissions for both https://graph.windows.net/Directory.AccessAsUser.All and https://graph.microsoft.com/Organization.Read.All, make two different requests, one for each.

Use the provided link to search for the Resource name: Verify first-party Microsoft applications in sign-in reports - Active Directory. For example, to find the Resource ID 00000003-0000-0000-c000-000000000000 for graph.microsoft.com:

This error usually occurs when an incorrect identifier is used in the query filter. To resolve it, make sure you're using the enterpriseApplicationId property with the correct resource ID, not the resource name.

• Incorrect request For enterpriseApplicationId, don't use a resource name like graph.microsoft.com.
• Correct request Instead, for enterpriseApplicationId, use the resource ID, such as 00000003-0000-0000-c000-000000000000.

For example, Earlier in graph.microsoft.com resource only the "profile" scope was consented. Now we need to add profile and user.read also. To add new scopes to a previously consented application:

1. Use the DELETE method to revoke the existing application consent from the customer's tenant.
2. Use the POST method to create new application consent with the extra scopes.

Concatenate the required scopes using a comma followed by a space. For example, "scope": "profile, User.Read"

1. Confirm that the 'displayName' and 'applicationId' properties in the request body are accurate and match the application you're trying to consent into the customer tenant.
2. Ensure that you're using the same application to generate the access token that you're attempting to consent into the customer tenant. For example: If the application ID is "12341234-1234-1234-12341234," the "appId" claim in the access token should also be "12341234-1234-1234-12341234."
3. Verify that one of the following conditions is met:

• You have an active Delegated Admin Privilege (DAP), and the user is also a member of the Admin Agents Security group in the partner tenant.
• You have an active Granular Delegated Admin Privilege (GDAP) relationship with the Customer tenant with at least one of the following three GDAP roles, and you completed the Access Assignment:
  • Global Administrator, Application Administrator, or Cloud Application Administrator Role.
  • The partner user is a member of the Security Group specified in the Access Assignment.

• To manage Azure with per-customer access partitioning (which is the recommended best practice), create a security group (such as Azure Managers) and nest it under Admin agents.
• To access an Azure subscription as an owner for a customer, you can assign any Microsoft Entra built-in role (such as Directory readers, the least privileged role) to the Azure Managers security group. For the steps to set up Azure GDAP, see Workloads supported by granular delegated admin privileges (GDAP).

Yes. For information about how to restrict a user's administrator permissions by assigning least privileged roles in Microsoft Entra, see Least privileged roles by task in Microsoft Entra.

We recommend assigning the Service support administrator role. To learn more, see Least privileged roles by task in Microsoft Entra.

• To reduce the gap between Microsoft Entra roles available in Partner Center API versus UI, a list of nine roles are available in Partner Center UI in July 2024.
• Under Collaboration:
  • Microsoft Edge Administrator
  • Virtual Visits Administrator
  • Viva Goals Administrator
  • Viva Pulse Administrator
  • Yammer Administrator
• Under Identity:
  • Permissions Management Administrator
  • Lifecycle Workflows Administrator
• Under Other:
  • Organizational Branding Administrator
  • Organizational Messages Approver

No. The least privileged role for partner users to be able to create support tickets for their customer is the Service support administrator. Therefore, to be able to create support tickets for the customer, a partner user must be in a security group and assigned to that customer with that role.

For information about all the roles, see Microsoft Entra built-in roles. For information about workloads, see Workloads supported by granular delegated admin privileges (GDAP).

Many roles are used for Microsoft 365 Admin Center. For more information, see Commonly used Microsoft 365 admin center roles.

Yes. Create a security group, assign approved roles, and then assign partner tenant users to that security group.

Read-only access to customer's subscriptions is provided by the Global reader, Directory reader, and Partner tier 2 support roles.

We recommend you remove the partner agents from the Admin agent role and add them to a GDAP security group only. That way, they can administer services (service management and log service requests, for example), but they can't purchase and manage subscriptions (change quantity, cancel, schedule changes, and so on).

The security groups assigned to the relationship lose access to that customer. The same thing happens if a customer terminates a DAP relationship.

Yes. Removing the GDAP relationships with a customer doesn't terminate the partners' reseller relationship with the customer. Partners can still purchase products for the customer and manage Azure budget and other related activities.

No. All roles in a GDAP relationship have the same time to expiration: the duration that was chosen when the relationship was created.

No. You don't need GDAP to fulfill orders for new and existing customers. You can continue to use the same process to fulfill customer orders in Partner Center.

GDAP relationships are per-customer. You can have multiple relationships per customer. Each GDAP relationship can have different roles and use different Microsoft Entra groups within your CSP Tenant. In Partner Center, role assignment works at customer-to-GDAP relationship level. If you want to multicustomer role assignment, you can automate using APIs.

GDAP guest admins are unable to manage their own security information at My Security-Info. Instead, they need the assistance of the tenant admin they're a guest in for any security info registration, update, or deletion. Organizations can configure cross-tenant access policies to trust the MFA from the trusted CSP tenant. Otherwise GDAP guest admins are limited to only methods registerable by the tenants admin (which is SMS or Voice). To learn more, see Cross-tenant access policies.

Align to the Guiding principle of Zero Trust: Use least privilege access:

• We recommend using a least-privileged role by task and workload tasks Workloads supported by granular delegated admin privileges (GDAP) supported by GDAP.
• When it's necessary to work around listed known issues, work with your customer to request a time-bound Global Administrator role.
• We don't recommend replacing the Global Administrator role with all possible Microsoft Entra roles.

Yes. During the transition period, DAP and GDAP will coexist, with GDAP permissions taking precedence over DAP permissions for Microsoft 365, Dynamics 365, and Azure workloads.

DAP and GDAP coexist during the transition period. However, eventually GDAP is replacing DAP to ensure that we provide a more secure solution for our partners and customers. We recommend that you transition your customers to GDAP as soon as possible to ensure continuity.

There are no changes to the existing DAP relationship flow while DAP and GDAP coexist.

DAP is currently granted when a new customer tenant is created. On September 25, 2023, Microsoft no longer grants DAP for new customer creation and instead grants Default GDAP with specific roles. The default roles vary by partner type, as shown in the following table:

Partners can implement Privileged Identity Management (PIM) on a GDAP security group in the partner's tenant to elevate the access of a few high-privilege users, just in time (JIT) to grant them high-privilege roles like Password admins with automatic removal of access. Until January 2023, it was required that every Privileged Access Group (former name for the PIM for Groups feature) had to be in a role-assignable group. This restriction is now removed. Given this change, it's possible to enable more than 500 groups per tenant in PIM, but only up to 500 groups can be role-assignable. Summary:

• Partners can use both role-assignable and non-role-assignable groups in PIM. This option effectively removes the limit on 500 groups/tenant in PIM.
• With the latest updates, there are two ways to onboard group to PIM (UX-wise): from the PIM menu or from the Groups menu. Regardless of the way you choose, the net result is the same.
  • Ability to onboard role-assignable/non-role-assignable groups through PIM menu is already available.
  • Ability to onboard role-assignable/non-role-assignable groups through Groups menu is already available.
• For more information, see Privileged Identity Management (PIM) for Groups (preview) - Microsoft Entra.

GDAP is generally available with support for all Microsoft commercial cloud services (Microsoft 365, Dynamics 365, Microsoft Azure, and Microsoft Power Platform workloads). For more information about how DAP and GDAP can coexist and how GDAP takes precedence, search this FAQ for the How do GDAP permissions take precedence over DAP permissions while DAP and GDAP coexist? question.

You can perform this action with APIs.

No. Your PEC earnings aren't affected when you transition to GDAP. There are no changes to PAL with the transition, ensuring that you continue to earn PEC.

• If a partner's customer has DAP only and DAP is removed, PEC isn't lost.
• If a partner's customer has DAP, and they move to GDAP for Microsoft 365 and Azure simultaneously, and DAP is removed, PEC isn't lost.
• If the partner's customer has DAP, and they move to GDAP for Microsoft 365 but keep Azure as-is (they don't move to GDAP) and DAP is removed, PEC isn't lost, but access to the Azure subscription is lost.
• If an RBAC role is removed, PEC is lost, but removing GDAP doesn't remove RBAC.

When the user is part of both the GDAP security group and the DAP Admin agents group and the customer has both DAP and GDAP relationships, GDAP access takes precedence at the partner, customer, and workload level.

For example, if a partner user signs in for a workload and there's DAP for the Global admin role and GDAP for the Global reader role, the partner user only gets Global reader permissions.

If there are three customers with GDAP roles assignments to only GDAP security group (not Admin agents):

The following table describes what happens when a user signs in to a different customer tenant.

DAP and GDAP aren't eligible association types for Solutions Partner designations. aDisabling or transitioning from DAP to GDAP doesn't affect your attainment of Solutions Partner designations. Also, renewal of legacy competency benefits or Solutions Partner benefits isn't affected. To view the other partner association types eligible for Solutions Partner designation, see Partner Center Solutions Partner designations.

Regarding the relationship between Azure Lighthouse and DAP/GDAP, think of them as decoupled parallel paths to Azure resources. Severing one shouldn't affect the other.

• In the Azure Lighthouse scenario, users from the partner tenant never sign-in to the customer tenant and don't have any Microsoft Entra permissions in the customer tenant. Their Azure RBAC role assignments are also kept in the partner tenant.
• In the GDAP scenario, users from the partner tenant sign-in to the customer tenant. The Azure RBAC role assignment to the Admin agents group is also in the customer tenant. You can block the GDAP path (users can no longer sign in) while the Azure Lighthouse path is unaffected. Conversely, you can sever the Lighthouse relationship (projection) without affecting GDAP. For more information, see the Azure Lighthouse documentation.

Managed Service Providers (MSPs) enrolled in the Cloud Solution Provider (CSP) program as indirect resellers or direct bill partners can now use Microsoft 365 Lighthouse to set up GDAP for any customer tenant. Because there are a few ways that partners are managing their transition to GDAP already, this wizard lets Lighthouse partners adopt role recommendations specific to their business needs. It also lets them adopt security measures like just-in-time (JIT) access. MSPs can also create GDAP templates through Lighthouse to easily save and reapply settings that enable least-privileged customer access. For more information, and to view a demo, see the Lighthouse GDAP setup wizard. MSPs can set up GDAP for any customer tenant in Lighthouse. To access customer's workload data in Lighthouse, a GDAP or DAP relationship is required. If GDAP and DAP coexist in a customer tenant, GDAP permissions take precedence for MSP technicians in GDAP-enabled security groups. For more information on requirements for Microsoft 365 Lighthouse, see Requirements for Microsoft 365 Lighthouse.

The correct sequence to follow for this scenario is:

1. Create a GDAP relationship for both Microsoft 365 and Azure.
2. Assign Microsoft Entra roles to security groups for both Microsoft 365 and Azure.
3. Configure GDAP to take precedence over DAP.
4. Remove DAP.

The following sequence could result in losing access to Azure subscriptions:

1. Remove DAP. You don't necessarily lose access to an Azure subscription by removing DAP. But at this time, you can't browse the customer's directory to do any Azure RBAC role assignments (such as assigning a new customer user as subscription RBAC contributor).
2. Create a GDAP relationship for both Microsoft 365 and Azure together. You might lose access to the Azure subscription at this step as soon as GDAP is set up.
3. Assign Microsoft Entra roles to security groups for both Microsoft 365 and Azure

You regain access to Azure subscriptions after Azure GDAP setup completes.

If you have Azure subscriptions without DAP that you manage as an owner, when you add GDAP for Microsoft 365 to that customer, you might lose access to the Azure subscriptions. To avoid lost access, move the customer to Azure GDAP at the same time that you move the customer to Microsoft 365 GDAP.

No. Relationships, once accepted, aren't reusable.

If you have an existing reseller relationship with the customer, you still need to establish a GDAP relationship in order to manage their Azure subscriptions.

1. Create a security group (for example, Azure Managers) in Microsoft Entra.
2. Create a GDAP relationship with the directory reader role.
3. Make the security group a member of the Admin Agent group. After you do these steps, you can manage your customer's Azure subscription by way of AOBO. You can't manage the subscription by way of CLI/Powershell.

Yes. You can create an Azure plan even if there's no DAP or GDAP with an existing reseller relationship. But in order to manage that subscription, you need DAP or GDAP.

As partners transition from DAP to GDAP, they must ensure the following are in place to see Company details:

• An active GDAP relationship.
• Any of the following Microsoft Entra roles are assigned: Global Administrator, Directory Readers, Global Reader. Refer to grant granular permissions to security groups.

When a CSP logs into their customer's Azure portal (portal.azure.come) using their CSP credentials and a GDAP relationship exists, the CSP notices that their username is "user_" followed by some number. It doesn't display their actual username as in DAP. It's by design.

Partners must explicitly grant granular permissions to security groups in the Default GDAP.
As of October 10, 2023, DAP is no longer available with reseller relationships. The updated Request Reseller Relationship link is available in Partner Center UI, and the API contract "/v1/customers/relationship requests" property URL returns the invitation URL to be sent to the admin of the customer tenant.

Yes, partners must explicitly grant granular permissions to security groups in the Default GDAP to manage customer.

Partners with reseller relationship only without DAP or GDAP can create customers, place and manage orders, download software keys, manage Azure RI. They can't view customer company details, can't view users or assign licenses to users, can't log tickets on behalf of customers, and can't access and administer product specific admin centers (For example, Teams admin center.)

For a partner or CPV to access and manage a customer tenant, their app's service principal must be consented in customer tenant. When DAP is active, they must add the app's service principal to the Admin Agents SG in the partner tenant. With GDAP, partner must ensure their app is consented in customer tenant. If the app uses delegated permissions (App + User) and an active GDAP exists with any of the three roles (Cloud Application Administrator, Application Administrator, Global Administrator) consent API can be used. If the app uses application only permissions, it must be manually consented to, either by the partner or customer having any of the three roles (Cloud Application Administrator, Application Administrator, Global Administrator), using tenant-wide admin consent URL.

If you see the following error:

"We're unable to validate your 'Create new GDAP relationship' request at this time. Be advised anonymous connections aren't allowed for this service. If you believe you received this message in error, try your request again. Select to learn about actions you can take. If the issue persists, contact support and reference message code 715-123220 and Transaction ID: guid."

Change how you connect to Microsoft to let the identity verification service run properly. It helps ensure that your account isn't compromised and is compliant with regulations to which Microsoft must adhere.

Things you can do:

• Clear your browser cache.
• Turn off tracking prevention on your browser or add our site to your exception/safe list.
• Turn off any Virtual Private Network (VPN) program or service that you might be using.
• Connect directly from your local device rather than through a virtual machine (VM).

If after trying the previous steps, you're still unable to connect, we suggest consulting with your IT Help Desk to check your settings to see if they can help identify what is causing the issue. Sometimes, the issue is in your company's network settings. Your IT administrator would need to address the problem for example, by safe listing our site or make other network setting adjustments.

• Restricted (Direct Bill): New GDAP (Admin Relationships) CANNOT be created. Existing GDAPs and their role assignments CAN be updated.
• Suspended (Direct Bill/Indirect Provider/Indirect Reseller): New GDAP CANNOT be created. Existing GDAPs and their role assignments CANNOT be updated.
• Restricted (Direct Bill) + Active (Indirect Reseller): For Restricted Direct Bill: New GDAP (Admin Relationships) CANNOT be created. Existing GDAPs and their role assignments CAN be updated. For Active Indirect Reseller: New GDAP CAN be created, existing GDAPs and their role assignments CAN be updated. When offboarded new GDAP can't be created, existing GDAP and their role assignments can't be updated.

Yes. The current release of GDAP supports all products: Microsoft 365, Dynamics 365, Microsoft Power Platform, and Microsoft Azure.