Understanding GDAP and Its Operational Impact

You’ve likely heard that Microsoft has changed its Delegated Admin Privileges (DAP) authentication control to Granular Delegated Admin Privileges (GDAP). The transition is well underway, but many service providers have not begun the process and still have many questions.

In this blog, we’ll summarize all the essential information you should know about moving to GDAP.

What Is Granular Delegated Admin Privileges (GDAP)?

Formerly, service providers managed their tenants through Delegated Access Privileges (DAP). DAP allowed administrators to assign roles and permissions to users, defining their access levels to various resources, applications, or data. However, DAP typically provided broader access controls and lacked granularity in specifying permissions for individual resources or actions. This has led to a less secure situation where providers have had too much access to each tenant. This can be an uncomfortable situation for the tenant and can also lead to problems with compliance where least-privilege access is required.

Granular Delegated Access Privileges (GDAP) represents an advancement over DAP. GDAP enables administrators to delegate access privileges at a more granular level, allowing them to define specific permissions for individual resources, actions, or data elements within an application or system.

Source: Microsoft

Some key differences between DAP and GDAP include:

• Access Control Precision: While DAP provides more general access control at the role or group level, GDAP offers a higher degree of precision by allowing administrators to define specific permissions for individual resources or actions. GDAP enables administrators to finetune access privileges, granting users precise levels of authorization based on their needs and responsibilities.

• Flexibility and Customization: DAP often relies on predefined roles or groups with predetermined access rights. In contrast, GDAP allows for more flexibility and customization, empowering administrators to define access permissions tailored to the unique requirements of different resources, applications, or data elements. This granularity ensures that access is precisely aligned with business needs and security requirements.

• Reduced Over-Privilege Risks: DAP can sometimes result in over-privileged access, where users have more permissions than necessary to perform their specific tasks. GDAP mitigates this risk by providing a more detailed approach, ensuring that users only have access to the specific resources and actions they require, reducing the overall attack surface and potential security vulnerabilities.

What Problems Are Addressed By GDAP?

Traditional DAPs may lack the necessary granularity to meet stringent security and compliance requirements. GDAP addresses this by allowing administrators to assign access permissions at a more detailed level, ensuring that sensitive data or critical actions are adequately protected and comply with relevant regulations.

Furthermore, DAP's broader access controls can sometimes lead to human errors when granting permissions. GDAP helps minimize such errors by enabling administrators to define precise access rights for individual resources, reducing the risk of accidental or unauthorized access.

Finally, With the increasing emphasis on data privacy, organizations need to ensure that access to sensitive data is strictly controlled. GDAP allows administrators to grant access to specific data elements or attributes, safeguarding privacy and reducing the exposure of sensitive information.

What Does This Mean For Me?

Transitioning from Delegated Access Privileges (DAP) to Granular Delegated Access Privileges (GDAP) becomes essential when organizations need enhanced security, stricter compliance adherence, robust data governance, optimized resource allocation, or secure collaboration. GDAP's access controls provide organizations with the ability to assign precise permissions, ensuring the right individuals have access to the right resources while mitigating security risks and maintaining data privacy. By embracing GDAP, organizations can elevate their access control capabilities to meet the evolving demands of modern data environments.

If you’re looking for guidance on how to make the transition to GDAP, we’ve got you covered. Register for our webinar where we’ll provide you with a detailed breakdown of GDAP and how to navigate this new security control.

When Is This Change Mandatory?

This has been a moving target for an extended amount of time since GDAP was first released by Microsoft. Most recently, Microsoft set a date of May 22, 2023 as the required transition date. However, that has since been suspended unless you are in specific regions or countries. We will update you with the best available information as this becomes known.

Implementation and Migration

There are several options for the transition, including some existing migration tools:

• Microsoft has a bulk migration tool that can be easily utilized to migrate existing DAP relationships to GDAP relationships

• CIPP also offers a migration tool (as of this writing, it is still available)

Manual implementation is also an option and offers the most control and flexibility. Manually configuring GDAP requires:

1. Obtaining permissions to manage a customer’s service

• This is done by creating an Admin relationship through the Microsoft Partner Center and defining what roles are included in the relationship. Once this is configured and accepted by the customer, it will show on your Administer page.

2. Customer approval

• Customers must first remove any DAP roles before they can approve a GDAP relationship. Otherwise, DAP may override GDAP. The customer can then approve the GDAP request from an invitation link sent by email.

3. Assigning Azure AD roles

• You can then assign Azure AD roles to security groups and grant those groups granular delegated admin privileges. This can be done from the admin relationships section for each customer in the Partner Center. Simply add/remove groups and select which groups you want to grant permissions to. Those groups will then show in the security group section, where you can sign Azure AD roles. All users assigned to the security group can now administer services from their service management page.

4. Least privileged roles by task

• It’s important to understand which least privileged built-in role can be used for each permission. This list is extensive and can be located here.

While there are several methods of accomplishing this manually, one of the easiest ways to implement this change is through a nested groups method. Simply assign a new group to each available role. You can then create new groups per position and nest the groups that are required within. For example, if you have a Technician II that requires Intune Admin and Exchange Admin, you can create a “Technician II” group and make that group members of the “Intune Admin” and “Exchange Admin” groups. This allows for ease of management and never needing to access the roles directly after the initial setup.

Finally, there’s also a path for termination both from the partner and customer side. Both sides can terminate the relationship when it no longer meets their needs. Please see Microsoft's guidance here on partner termination.

What Other Challenges May I Face?

Transitioning not only affects internal access controls but also has a significant impact on external integrations with third-party services and applications. Migrating from DAP to GDAP involves careful consideration of this impact. Organizations must assess compatibility, establish trust, address compliance considerations, update contractual agreements, and provide necessary training and support to external partners. By aligning external integrations with GDAP, organizations can ensure secure data sharing, maintain compliance, and foster effective collaboration while leveraging the enhanced access control capabilities of GDAP.

Some specific problems with external integrations may include:

• When migrating to GDAP, organizations need to ensure that their external integrations align with the new access control framework. GDAP may introduce changes in the way permissions are granted and managed, requiring updates and modifications to existing integration points. Organizations must assess the compatibility of their external systems and applications to ensure seamless integration with GDAP. The transition may also require adjustments in the external integration workflow to accommodate the new access controls and ensure that data is shared securely and compliantly.

• Migrating to GDAP may require organizations to establish new trust relationships with external partners. External entities must understand and adhere to the access policies defined under GDAP to ensure secure collaboration and data sharing. Clear communication and collaboration are essential to align external integrations with the updated access control framework, fostering trust and enabling efficient workflows.

• As the migration to GDAP impacts external integrations, it is crucial to provide training and support to external partners or users who interact with the organization's systems. This ensures that they understand the new access controls, guidelines, and processes associated with GDAP. Offering comprehensive documentation, training sessions, and ongoing support helps external parties seamlessly adapt to the updated integration workflows.

GDAP and Huntress MDR for Microsoft 365

Integrating with Huntress MDR for Microsoft 365 (general availability coming soon) requires GDAP to be already implemented in your environment. 

If you have yet to make this change, we have detailed instructions specifically for using a dedicated service account to perform the integration. This support article walks through the process of what roles and permissions the account must have in addition to conditional access requirements.

A Word on Conditional Access

Conditional access policies are like gatekeepers for resources. If someone wants to access a resource, they must complete an action to do so. In most cases, this is used to enforce MFA. Additionally, this can include the type and strength of the MFA as well as consider multiple additional factors such as the user, location, and application.

‍

Huntress MDR for Microsoft 365 requires Microsoft MFA specifically to be configured for the service account used to create the integration. It also requires its own policy and exclusions from existing policies, including tenant policies. For guidance on setting up these policies for Huntress, please see our support article here. 

More Information and Resources

• Browse Microsoft’s Partner Center page on GDAP: https://learn.microsoft.com/en-us/partner-center/gdap-introduction
• Look into CIPP! CIPP has some great resources on GDAP, the transition, and Microsoft 365 in general: https://docs.cipp.app/
• Be sure to check out our June 14 webinar, Understanding the Operational Impact of GDAP, for steps you can take as a service provider to ensure a smooth transition: https://www.huntress.com/resources/webinar/understanding-the-operational-impact-of-gdap
  
  

Special thanks to Topher Lyons and Todd Wolpert for their contributions to this writeup.