Skip to main content

Microsoft Online - How does GDAP apply to Atria?

Objective​

This guide is to outline how GDAP applies within Atria, as well as the changes introduced by the migration to MG Graph.

What's GDAP?​

GDAP is a change introduced by Microsoft which improved security by Microsoft Partner Center. To sum this up, you require individual "Relationships" with each tenant in the Partner Center. Instead of having one "Delegated Admin Permission" you now require "Granular" permissions to each tenant.

This enables you to control and select individual permission(s) to each tenancy, instead of having "Admin agent" permissions over the tenant, you can now be specific on the access roles.

For more information on this topic, please see Microsoft's documentation: Granular Delegated Admin Privileges (GDAP) Introduction | Microsoft Learn

What GDAP permissions do I need to provide?​

As of posting, Atria currently requires the below roles to function for full functionality. You can at your own risk reduce these permissions, but you may see errors when interacting with certain aspects of the platform. Now that GDAP has been introduced, we have reduced the scope of the permissions we require. Previously we only required AdminAgents, but within the new GDAP model we now need the below permissions.

  • Authentication Administrator
  • Billing administrator
  • Cloud Application Administrator
  • Directory Writers
  • Domain name administrator
  • Exchange administrator
  • Global reader
  • Groups administrator
  • License administrator
  • Password administrator
  • User Administrator

If you'd like to discuss a combination of which permissions are needed for your implementation or configuration, please contact our support team.

Some of these permissions (Such as Domain Name Administrator) are only required if you are running federation, so this list can be shortened depending on your implementation, or only certain roles being required for a subset of your tenants individual GDAP consents.

Microsoft has started automatically moving Customers to the new GDAP methodology of permissions, an example of this is below. As you can see, this list does not contain all of the permissions that Atria requires. This works for some user management scenarios, but as soon as Exchange Online is interacted with you will start experiencing errors.

GDAP

What Application permissions do you require?​

For Application Permissions, we now require only Impersonation permissions. This is due to a difference in the permissions and authentication structure as outlined. We've updated our scripts that create applications, and would recommend creating a new application for this. This is outlined in our KB here - Configure Resellers with their own Partner Center connection

For more information about the GDAP consent process, see Microsoft's documentation here - Obtain granular admin permissions to manage a customer's service

For a quick runthrough of what we've done on our end for an example, see the below Scribe:

Application consent is a new feature Microsoft have introduced as well as the GDAP changes. This means the Application we use for Authentication needs to be whitelisted within the Customers Tenant itself to be allowed to authenticate. This is done through a new PowerShell Cmdlet. For more information, see here - New-PartnerCustomerApplicationConsent (PartnerCenter) | Microsoft Learn

An example of this cmdlet is below, which grants the Directory access and user impersonation grants to an application

info

If you are on Atria v15.16 or newer, this is done programatically during provisioning.

#MS Graph Grant
$MSGraphgrant = New-Object -TypeName Microsoft.Store.PartnerCenter.Models.ApplicationConsents.ApplicationGrant
$MSgraphgrant.EnterpriseApplicationId = "00000003-0000-0000-c000-000000000000"
$MSGraphgrant.Scope = "Directory.AccessAsUser.All"

# Windows Azure Service Management API
$AzureGrant = New-Object -TypeName Microsoft.Store.PartnerCenter.Models.ApplicationConsents.ApplicationGrant
$AzureGrant.EnterpriseApplicationId = "797f4846-ba00-4fd7-ba43-dac1f8f63013" $AzureGrant.Scope = "user_impersonation"

New-PartnerCustomerApplicationConsent -ApplicationId 'xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx' -ApplicationGrants @ ($MsGraphgrant, $AzureGrant) -CustomerId 'f1c5e45f-7dea-4863-a55d-b5a5479201df' -DisplayName 'CPV Web App'

I haven't heard about GDAP until now and I am unable to provision in Atria - What are my next steps?​

Atria requires these permissions as described, so you will start seeing errors regarding Application Consent being required or even the generic "Rest Request Failed" if you are on an older version. You will need to upgrade to our latest version as of posting for support.

Here's the link to our KB on how to upgrade your platform - Updating Atria

The GDAP Process is per tenant. This means that the permissions and security group mapping need to be completed for all customers individually. Fortunately, at this time Microsoft has provided a mass migration tool which eables you to select all customers and choose permissions for each. This will be the easiest way to mass upgrade the permissions for your customers.

Once the permissions have been completed; If you are still having issues, plase go through the below.

  1. Once you are on 15.16, please make sure that the GDAP Permissions are correct.
  2. If the GDAP permissions are correct, please confirm that the Permissions are assigned to a Security Group that the Atria Service Account is in.
  3. If the permissions are all correct, please try reprovisioning the Azure AD Service.
  4. If the Sync process is failing on Exchange with another Consent error - Please wait up to 24 hours for the GDAP permissions to be correctly applied - We (Automate) are currently looking into ways we can improve this; but unfortunately this seems to be waiting for permissions to apply.