This guide is to outline how GDAP applies within Atria, as well as the changes introduced by the migration to MG Graph.
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.
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.
Cloud Application Administrator
Domain name 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.
What Application permissions do you require?
What's the GDAP consent process?
What is an Application Consent?
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
Please note - 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
# Windows Azure Service Management API
$AzureGrant = New-Object -TypeName Microsoft.Store.PartnerCenter.Models.ApplicationConsents.ApplicationGrant
($MsGraphgrant, $AzureGrant) -CustomerId
'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 -
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.