What is GDAP?

Granular Delegated Administrative Privileges (GDAP) is a security model of access that allows partners to configure granular and time-bound access to their customers' workloads in production and sandbox environments. Companies delegate individuals to be Partner Administrators. These Partner Administrators can specify access for a user to be able to perform functions for each customer. These users will have access based on what they do (workload) for each customer. Also, access is granted for up to two years, not ‘perpetual’, as in DAP. In other words, access will be "granular" or specific with over 73 roles and is time-based depending on the activities the user needs to perform.

What is Microsoft planning to do?

Microsoft is taking steps to protect access to customer data as part of their commitment to increase the security of their ecosystem. A major part of this initiative is the transition from Delegated Admin Privileges (DAP) to Granular Delegated Admin Privileges (GDAP). Starting November 1^st 2023, Microsoft will no longer grant DAP for new customer creation and will instead grant GDAP with default roles when a new customer tenant is created. Furthermore, there are many options to tailor the individual permissions to the specific job role defined by the customer. For more information, you can also check the GDAP Enablement | New GDAP milestone dates page of our documentation.

Impacted Audience & Products

The impacted audience includes direct-bill partners, indirect providers, indirect resellers, and control panel vendors transacting through the Cloud Solution Provider program. Also, GDAP may exist between the distributor with the end customer, as well as between the indirect reseller with the end customer.

Therefore, you will need to transition to GDAP if you:

• Perform any function as an administrator on behalf of your customers. (This may include people in support, operations, sales, etc.).

• Have the ability to provide access to other users.

It is evident that the transition to GDAP will affect almost all partners who resell Microsoft products.

Additionally, the following Microsoft products are impacted by the introduction of GDAP.

• All Microsoft 365, Microsoft Dynamics 365, Microsoft Power Platform, and Microsoft Azure.

What do you need to do?

Microsoft is providing guidance and best practices for how to transition while it is developing a DAP to GDAP bulk transition tool. Our recommendation for partners is to start transitioning now and manually audit the existing DAP connections to enable the transition to GDAP. We suggest not waiting for the bulk transition tool to be live, as this tool will not grant the user the same legacy Global Admin role. Inherent roles set with the transition tool will be set to least privileged. This will reduce your level of access compared with the new granular roles. Microsoft will be allowing all partners to transition. Consequently, we highly recommend moving away from the current DAP model (which gives admin agents standing or perpetual global admin access) to a fine-grained delegated access model. The fine-grained delegated access model reduces the security risk to customers and the impact on them as well. It also gives you control and flexibility to restrict access per customer at the workload level of your employees who are managing your customers' services and environments.

Assigning GDAP roles via the BSS Platform

With the introduction of GDAP from Microsoft, you can find, two new non-compulsory fields on BSS called Azure AD Roles for GDAP and GDAP duration in days on each Microsoft instance, where you can assign as many GDAP roles as you wish. These GDAP roles will be used to create a specific GDAP relationship between an indirect provider with the customer when synchronizing a new customer to an existing Microsoft tenant, for the first time. Therefore, those fields are addressed to new customers of your BSS organization and existing Microsoft Partner Center customers that have transitioned to your organization and have no previous (active or inactive) GDAP relationship with you.

Open

More specifically:

• The first highlighted field, called Azure AD Roles for GDAP is multi-selectable and contains most of the Azure AD roles introduced by Microsoft that are also supported by our platform, so that the BSS user is able to select which roles suit them best, without imposing any GDAP role on them. By default, the field is empty without predefined roles.

  • Next to the aforementioned field, an informative tooltip informs the BSS user that the roles will only apply to newly synced existing tenants without an established GDAP relationship:

    Open

    

     

• The second highlighted field, called GDAP duration in days, is essentially a numerical field with manual fill-in in which the BSS user can specify the number of days the defined GDAP roles will be in effect. The minimum number of days: is 1, whereas the maximum number of days is 730. By default, the field is empty without predefined numeric values.

  • Next to the aforementioned field, an informative tooltip icon exists where it informs the BSS user about the relevant of the duration of the days with regards to the GDAP role(s) expiration:
    
    

In case at least one GDAP role has been selected on the multi-selected menu, the GDAP duration should be checked before saving the instance so that the duration filled in is within the boundaries set by Microsoft, [1,730]. If the GDAP duration is outside the limits or not filled in when at least one role is introduced, a warning message appears upon saving the instance, stating that the: 'Instance cannot be saved. GDAP duration in days is not within the allowed boundaries set by Microsoft.'.

Automatic Creation of GDAP Roles in the MPC

Once the BSS Microsoft instance is saved with both the GDAP fields (Azure AD Roles for GDAP, GDAP duration in days) populated, the system stores this information since it will be used once an unsynchronized customer gets synchronized to an existing tenant who has not already established a GDAP relationship with the specific CSP.

Once this trigger event is activated, a link called GDAP link is dispatched via a BSS systemic email notification in the form of a GDAP relationship request in order for the end customer to log in to the Microsoft Admin Portal (via the embedded link inside the email) and accept the request in order for the final accepted relationship to be dispatched to Microsoft via an API call and establish the relationship between the systems, which is called GDAP relationship. This series of small and easy actions is what allows the roles to be created inside the MPC for the specific BSS account, just once (only for the first time). As a result, the approved GDAP relationship is essential between the intercommunication of the BSS, the Microsoft Admin Portal, and the Microsoft Partner Center for the automatic creation and assignment of the GDAP roles per customer/tenant.

In the two following sections, you can find an analysis of how the GDAP link, the GDAP relationship request, and the final GDAP relationship are formed and dispatched.

Creation of the GDAP Relationship Name

The GDAP relationship name is unique across both platforms for the same tenant. Therefore the formula for the generation of a unique GDAP name each time is the following:

GDAP relationship name = {microsoft primary domain name}_{BSSID}_{GDAP creation date in format YYYYMMDD}

So the GDAP relationship name consists of the following:

• The Microsoft tenant’s primary domain name prefix (e.g., when a customer’s domain name is: customername23.onmicrosoft.com, our system uses only the customername23 for the GDAP name.

• The BSS ID of the respective BSS account that is being synchronized & for whom the GDAP relationship will be established.

• The date that the relationship was established, in the format YYMMDD (year/month/day).

Once the relationship name is formed per each customer/tenant, the creation of the GDAP link is initiated.

Creation of the GDAP Link

The automatic creation of the GDAP link is based on the following two parts:

• The formula that was analyzed above for the GDAP Relationship Name.

• The GDAP roles specified and the GDAP duration (in days) that were both configured on the respective BSS Microsoft instance.

Therefore, once the GDAP link has both the aforementioned points available, it gets automatically created and dispatched via a systemic notification email to the end customer for approval.

Email Notification with the GDAP Link

Once the GDAP link has been created, an email containing the GDAP link is automatically dispatched to the respective email of the BSS account & the email of their primary contact, in order for them to accept interworks as their indirect provider (CSP). This systemic email notification, which is editable (by navigating to BSS Setup > Administration > Notifications > Customer Notifications > Accounts) and is triggered when a new MS customer is created or when syncing to an existing MS tenant for the first time, resides under the system notifications of Accounts since the notification is sent when a tenant is synchronized.

The account name displayed on the email is the name of the account corresponding to the end customer for which the GDAP relationship is created. It includes the GDAP relationship link created for the end customer that has been just synced either to an existing Microsoft tenant or to a new Microsoft tenant.

Managing the GDAP Relationship Pending Request(s)

The end customer will be able to see the GDAP relationship pending request on their Microsoft Admin Center in order to either approve or reject it.

However, the provider/reseller may view the GDAP relationship requests (which can be under the status: Active/Pending/Deactivated) of their end customers on their Microsoft Partner Center, as seen below. The GDAP link is unique per customer & may only be accepted by them once. Once it is accepted, it will no longer be a working link, and it will no longer appear on the Microsoft Partner Center as a link.

An example of a pending GDAP relationship request follows, and this is how it is displayed on an indirect provider’s or indirect reseller’s Microsoft Partner Center.

After the approval of the GDAP relationship request, the relationship becomes established between the three platforms, BSS, Microsoft Admin Center, and Microsoft Partner Center, and the GDAP roles are automatically assigned to the specific end customer/tenant and are active for the specified duration.

Table of Contents