This post is part of a mini-series that explains how Microsoft Customers, Azure AD Tenants, Azure Subscriptions and Cloud Solution Providers all work together.
It is aimed at anyone who wishes to purchase Azure resources from a Cloud Solution Provider (CSP) such as NewOrbit, as well as Microsoft Partners who wish to understand the relationship between CSPs and Customers better.
This is an immensely confusing topic that often stumps people who have spent years working with Azure - even as Partners.
I focus on explaining the concepts rather than being 100% technically correct. This means some of the detail is glossed over or simplified.
This series focuses on Partners providing Azure to Customers, but the Microsoft 365 side is inherently linked to this so there will be some straying into that area as well.
Granular Delegated Access Privileges - GDAP - allows Customers to give a Partner just enough permissions to the Customer’s Tenant to do their job. The permissions are granular, time-limited and can be assigned to individual users on the Partner’s side.
GDAP is not directly related to Azure at all, but can be used to make some Azure-related tasks easier.
GDAP is intimately linked to Foreign Principals. GDAP only applies when a Partner user accesses the Customer’s environment using the Foreign Principal access method. GDAP has no effect on Lighthouse or Guest Accounts.
When to use it
GDAP undoubtedly has major benefits for Partners who provide Microsoft 365 to Customers, as they can get granular access to the Customer’s Tenant without having to be a Global Administrator.
Cloud Solution Providers don’t need GDAP at all to provide Azure, but it can make some things easier, as we will see below.
GDAP should be used anywhere where a partner would have previously used Delegated Access Privileges - DAP. DAP is now deprecated and should not be used.
What can GDAP do
Assigning Permissions to Azure resources
The biggest benefit we have seen is from the Directory Reader role. With that permission, the Partner user can see (read-only) the list of all the users in the Customer’s Tenant. This in turn means the Partner can assign permissions to Azure resources to any of those users.
This, in turn, significantly simplifies the initial setup of a new Azure subscription: When a Cloud Solution Provider creates a new Azure Subscription, initially only the Partner’s Foreign Principal has access to it. Before GDAP, the Customer had to go through a somewhat elaborate process to give themselves access to the subscription. Often, this had to be done by an MSP providing the M365, which just delayed everything.
With GDAP, the Partner can just request “Directory Reader” access and will then be able to assign one or more of the Customer’s users access to the subscription. This is a huge time-saver.
Create Key Vaults
Key Vaults are quite special in that they can belong to a different Tenant to the one the Azure Subscription belongs to. If a Lighthouse user creates a Key Vault, it will belong to the Partner’s Tenant, not the Customer’s Tenant.
Key Vaults can be created by a Partner using Foreign Principal access. With GDAP Directory Reader access, the Partner can also assign permissions to the Key Vault - something you can’t do without GDAP.
Guest Inviter
There are some aspects of managing Azure that is best done by a “real” user in the Customer’s Tenant and not through Lighthouse or even the Foreign Principal. Most of those things can be done by a Guest User. In essence, this is a user in the Customer’s Tenant that is actually a user in the Partner’s Tenant.
If the Partner requests the “Guest Inviter” as well as the “Directory Reader” role through GDAP, the Partner can create those Guest Users and give them access to the Azure Subscription without bothering the Customer.
What can GDAP not do
Lighthouse
It would really nice if GDAP also applied to access via Lighthouse. Given that the Foreign Principal and the Lighthouse access are conceptually very similar (both involves a user from the Partner’s getting direct permission to Azure resources belonging to the the Customer’s Tenant, albeit in different ways) it would make sense if GDAP applied to both.
Alas, this is not the case.
Creating a Service Principal
If a Partner asks for the “Application Developer” role through GDAP, they can create a Service Principal. However, the Foreign Principal cannot be the owner of the Service Principal, which means the Partner cannot create or view any keys for the Service Principal. That makes this a non-starter.
The Partner can, of course, ask for the “Cloud Application Administrator” role, which can also create Service Principals. But that role is a lot more powerful than “Application Developer”, allowing the Partner to manage all Service Principals in the Tenant and should not be given out lightly.
Azure DevOps
Creating Azure DevOps organizations can only be by a “Member” user in the Customer’s Tenant. Guest Users cannot do it and GDAP does not help with this.
Setting it up
Microsoft has good documentation on this, so I will only stress a few key points here.
- The Partner has to request a GDAP relationship in addition to the normal “reseller relationship”. This is done in the Partner Center.
- The Customer can manage (and delete) both the reseller and the GDAP relationship in the Admin center under Home -> Settings -> Partner Relationships.
- The GDAP relationship exists between the Partner and the Customer. After it has been established, the Partner in addition has to assign specific security groups to be allowed to use this particular GDAP relationship. The neat thing about this is that this means the Partner can easily control exactly which user gets which permissions to each Customer’s Tenant.
- If you have no GDAP relationship with a Customer, any user in the
AdminAgentsgroup can access the Customer’s Azure Subscription. As soon as you set up a GDAP relationship, Partner users must also be assigned to one ore more those GDAP relationships as mentioned above. Any user in the AdminAgents group who has not been assigned to any of the GDAP relationships for that Customer will get an error message when they try to access the Customer’s Azure Subscription! This means that experimenting with GDAP may break things for other users, so be careful. - GDAP relationships are time limited so will eventually expire.
A warning
Microsoft’s documentation shows an illustration where you, as a Partner, set up a security group for each Customer and then assign that group to the GDAP relationship with that Customer. That is nice. However, they then also suggest you add those groups to the AdminAgent security group, which is required to be able to use those GDAP relationships. In practice, this means that every user in every one of those “Customer groups” will have access to all Azure subscriptions from all Customers, not just the ones you wanted them to have access to. (This is not true when there is an active GDAP relationship with a Customer as that will break the login - but remember that GDAP relationships expire.)
Now, this is not new - it has always been the case that any user in the AdminAgent group can access any Azure Subscription from any Customer and I talk about it more in the Foreign Principal post. Microsoft’s diagram in the linked article also explicitly shows this.
Nonetheless, on a cursory reading that article might have encouraged you to extend the use of Foreign Principal access to more users, due to its very obvious benefits. I know that was my reaction when I first saw it. Alas, that is not a good idea and you should still prefer Lighthouse and Guest Users for most things.
Conclusion
GDAP is great news for Customers. In the past, there was a binary choice between giving a Customer no access to their Tenant - or giving them Global Admin access. Now, the Customer can control exactly which permissions they want the Partner to have to their Tenant.
For Cloud Solution Providers who only provide Azure to their Customers, GDAP is a nice-to-have but is not a game changer. You can only use GDAP with Foreign Principal access and, as we know, Foreign Principal access should be kept to a minimum as it is not possible to make it granular enough.
Nonetheless, GDAP simplifies the initial setup of a new Azure subscription and is very welcome for that reason alone.
