Skip to content
Notifications
Clear all

Has anyone tried the granular delegated admin privileges (GDAP) with a MSP? Feedback?

2 Posts
2 Users
0 Reactions
9 Views
(@davidh)
Honorable Member
Joined: 3 months ago
Posts: 410
Topic starter   [#26070]

Having recently completed a migration from the legacy Delegated Admin Privileges (DAP) model to Granular Delegated Admin Privileges (GDAP) for a multi-tenant Managed Service Provider (MSP) operation, I have compiled a detailed analysis of the architectural implications, operational overhead, and security posture changes. The transition is non-trivial and fundamentally alters the partner-tenant relationship model, moving from a persistent, all-or-nothing access paradigm to a time-bound, least-privilege framework.

**Initial Implementation and Configuration Observations:**
The core process involves establishing a GDAP relationship with each customer tenant, which is a significant departure from the automatic DAP relationship. This requires the creation of security groups within the partner tenant, mapping them to specific Azure AD built-in roles (e.g., Helpdesk Administrator, Exchange Administrator, Intune Administrator), and then inviting the customer to approve the relationship with a defined duration (maximum 2 years). The PowerShell module `PartnerCenter` is essential for automation at scale.

A representative script snippet for initiating a relationship and assigning roles:
```powershell
# Establish a new GDAP relationship
$gdapRelationship = New-PartnerCustomerAgreement -CustomerId $customerTenantId -AgreementType "MicrosoftPartnerAgreement"

# Create a security group for tiered admin roles
$adminGroup = New-AzureADMSGroup -DisplayName "GDAP-Helpdesk-Admins" -SecurityEnabled $true -MailEnabled $false -MailNickname "notSet"

# Assign a built-in directory role to the group
$roleDefinition = Get-AzureADMSRoleDefinition -Filter "displayName eq 'Helpdesk Administrator'"
New-AzureADMSRoleAssignment -DirectoryScopeId '/' -PrincipalId $adminGroup.Id -RoleDefinitionId $roleDefinition.Id

# Link the group to the GDAP relationship (conceptual step, often via Partner Center API/Portal)
```
The administrative burden shifts from the customer to the partner, who must now meticulously design and maintain a role-based access control (RBAC) matrix across all client tenants.

**Operational Challenges and Performance Impact:**
* **Consent Fatigue:** While superior for security, obtaining formal consent for each GDAP relationship and its subsequent renewals introduces a new workflow dependency and potential point of failure in service delivery timelines.
* **Role Granularity Limitations:** The available Azure AD built-in roles, while more granular than DAP, may not perfectly align with common MSP service tiers. For instance, there is no built-in role that provides *only* conditional access policy read-and-analyze permissions without broader security administrative rights. This often forces a choice between over-permissioning or constructing custom roles, which adds complexity.
* **Cross-Tenant Management Overhead:** Tools that previously relied on the implicit, tenant-wide admin access of DAP (such as some RMM or PSA integrations) require significant re-engineering to authenticate and operate under the context of a specific GDAP relationship and its assigned roles. This has a measurable impact on the performance of automated scripts and dashboard aggregation across tenants.
* **Auditing and Observability:** The audit logs become more explicit, clearly showing actions performed under a specific GDAP relationship. However, correlating these logs across dozens of relationships and aggregated into a single SIEM requires careful planning of log ingestion pipelines and field mappings.

**Security and Cost Optimization Verdict:**
From a security architecture perspective, GDAP is a substantial improvement. It enforces time-based access reviews (via relationship expiry) and materially reduces the attack surface by eliminating standing, global administrator access. From a cost perspective, the investment is primarily in initial setup labor and ongoing identity governance administration. There are no direct licensing costs for GDAP itself, but the operational cost of managing this more complex model is non-zero and must be factored into service delivery pricing.

I am particularly interested in feedback from other MSPs who have operationalized this at scale (>50 customer tenants). What patterns have emerged for role grouping? How are you handling the consent and renewal workflow automation? Have you encountered significant performance latency in cross-tenant PowerShell or Graph API operations when using GDAP credentials compared to the old DAP model?


Data over dogma


   
Quote
(@adrianm)
Estimable Member
Joined: 3 months ago
Posts: 146
 

Thanks for sharing your detailed observations, they're really helpful for someone like me just starting to look at this transition. The point about it fundamentally altering the partner-tenant relationship model is especially striking.

I'm curious, with everything being time-bound now, what's been your experience with renewal workflows? Do you have automation in place to handle the 2-year renewal cadence for dozens or hundreds of tenants, or is that still a manual headache? The shift to least-privilege sounds great for security, but I can imagine the operational overhead growing quickly.


still learning


   
ReplyQuote