If you have been following along with my blog, you know I have written a few articles on Granular Delegated Admin Privileges or GDAP. If you are unfamiliar with what that is, please check out my first article, which is a high-level overview.
One component of GDAP that may seem overwhelming is choosing the roles you want to apply for the new relationships you are establishing with your customers. It is likely that you have never really tapped into all of the granular AAD roles that are available. In this article, I will be walking through some considerations to help you chose what roles you should be selecting.
Architecture
Its important to understand the architecture of these relationships to set yourself up for success. You can think of the GDAP relationship link as a large bucket of all of the possible permissions you want to have in your customer environments. After the relationship link is established, you then are required to assign these roles to security groups within your organization. This is not a 1:1 relationship. You can create as many sub-buckets as you want with as many security groups as you want. Many of you are likely only utilizing the Admin Agents and Helpdesk Agents groups in Partner Center. I would highly encourage you to explore creating new security groups to support the new architecture we now have. Depending how large your organization is, you may have security groups for each tier of technicians or you could just have security groups broken out by workload (Intune, 365 Licensing, Exchange, etc.).
Permissions
Microsoft has put together this article: https://docs.microsoft.com/en-us/azure/active-directory/roles/delegate-by-task to show the breakdown of permissions per workload. This includes the least prviledged role as well as a role that has that permission set encompassed. There are likely roles in which you would never have to access in certain customer environments, like MFA server for instance. Its good to run through this list and define a baseline of roles you would always want in any customer environment.
If you do not already have access controls defined for users in your environment within Partner Center, I will provide a basic spreadsheet here that can be used as an exercise to see what technicians need rights for certain roles. This will help you decide what your baseline permissions are along with customer specific rights. (ex. you may not need PowerBI access for certain customers so that permission should not be included for those GDAP invitations).
Global Admin Considerations
If you checked out the least privilege doc I linked above from Microsoft, there are still some permissions that have Global Admin as the least prviledged role. This just seems to be on some of the initial configurations like setting up settings around AD Connect. Applying to the Global Administrator role to GDAP kind of defeats the purpose in many ways. There is a Global Reader role that you can leverage which does not give any write capabilities. GDAP gives us access to portals of which never had delegated access like the Security and Compliance center. This should alleviate some of the bad practices going on like sharing MFA across users for a GA account in the customer tenant. If you feel like you need the Global Admin role, I would gate its access behind a specific security group and have that security groups membership be controlled with PIM (Prviledged Access Management). I won’t dive into that fully but here are some highlights:
- Azure AD P2 licensing (Which gives you access to PIM) is open for a free full year trial for Indirect Resellers
- You can create a role-based group in Azure AD and set up eligible members for just-in-time access. (which can be gated by approval). https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/groups-assign-member-owner
- That Security group can be applied against the customer with the Global Administrator rights applied to it
- When a user in your org needs GA rights, they can request temporary membership to that security group and go perform their task in the customer tenant.
This is reducing the attack surface and limiting exposure as much as possible if you chose to still have the GA permission in GDAP.
Final Thoughts
I hope this article provided more targeted guidance on the permissions you would want to set up with GDAP in your customer environments. Keep in mind that not all workloads are supported at the time of this post. Meaning that if you add SharePoint Admin role, for instance, you still won’t have the AOBO link to access that admin center at this time. Its good to keep your DAP relationships along with GDAP until all workloads are supported.
[…] my previous blog post, I talked about the major considerations when adding roles for GDAP relationships. In some […]