Granualar Delegated Admin Privilege (GDAP)
GDAP is a security feature that provides partners with least-privileged access following the Zero Trust cybersecurity protocol.
Overview
GDAP is a security feature that provides partners with least-privileged access following the Zero Trust cybersecurity protocol. It lets partners configure granular and time-bound access to their customers' workloads in production and sandbox environments. Customers must explicitly grant the least-privileged access to their partners.
For more information on how GDAP works, please refer https://learn.microsoft.com/en-us/partner-center/customers/gdap-introduction
Work 365 Implementation
The diagram below provides an overview of the entities involved in setting up GDAP in Work 365.
Note! non-GDAP relationships have been omitted from this diagram for brevity.
| Entity Name | Description |
|---|---|
| Category | This is a new entity available in v2.0. A category is a label that can be applied to an account. This same label can be used on a GDAP Template to specify default templates for that category. (e.g.: Default GDAP templates by customer segment) |
| Account | This is the standard Dataverse entity, representing a company. |
| Provider | This is the standard Work 365 entity, representing a connection to a provider such as Microsoft Partner Center or other indirect providers such as Ingram, TDSynnex, Pax8, etc |
| Provider Account | This is the standard Work 365 entity, representing the mapping between a customer (aka Tenant) in the provider to the customer in Work 365. |
| GDAP Template | This is a new entity in Work 365 representing a predefined GDAP setup. New requests can be created from this template, or the template can be designated to automatically create GDAP requests when a customer is onboarded. |
| GDAP Request | This is a new entity, representing a GDAP request in Microsoft. A GDAP request encapsulates the directory roles requested and the security groups to which they need to be assigned. |
GDAP Request Lifecycle
The states and state transitions of a GDAP request is illustrated below, along with the triggers that invoke those transitions.
| State | Description | Trigger |
|---|---|---|
| Draft | GDAP requests are created as Draft. These requests are local only and are not yet submitted to Microsoft or to the end customer. In this state, all changes to the request are allowed. | Creation of a GDAP request. |
| Approval Pending | On successful Submit of the request, the status changes to Approval Pending. At this point the GDAP request is submitted to Microsoft and is awaiting customer approval. (see note below). | User clicks Submit button. |
| Active | Once the customer approves the GDAP request, the state changes to Active. The GDAP request is currently enforced and any changes to the request are sync'ed to Partner Center. | Customer approves the GDAP request. |
| Expired | GDAP requests are of a specified duration. If auto-renew is not set, then the GDAP requests expire automatically after the specified duration. | Elapse of Duration days, when Auto-Renew = No |
| Terminated | The partner can terminate the GDAP relationship either via Partner Center or by clicking the Terminate button on the GDAP request. The customer may also choose to terminate the GDAP relationship from the Microsoft 365 admin center. | Partner led termination OR Customer led termination. |
Updated about 1 month ago