Set Up GDAP

This guide applies when a workspace uses the optional Microsoft CSP app and workflows and needs granular delegated admin privileges (GDAP). CSP and GDAP are not Bifrost built-ins and they are not prerequisites for a shared Teams bot. The separate Microsoft Graph app-only connection can operate after customer application consent without delegated GDAP runtime access.

Caution

This procedure changes access across customer tenants. Use a dedicated provider-owned application, require MFA for interactive operators, and test with a development customer before onboarding production customers.

Start With Discovery

Ask whether GDAP relationships, provider security groups, access assignments, templates, or legacy DAP access already exist. With permission, inventory them read-only through Microsoft Graph and the CSP workspace automation.

For each customer, report the relationship state, expiration, requested roles, access assignments, provider-local group IDs, Bifrost organization mapping, and a reuse, repair, or create recommendation. Never copy a relationship ID or security-group ID from another provider.

Before You Begin

You need:

• An active Microsoft AI Cloud Partner Program account and Partner Center access
• A provider Entra tenant associated with the Partner Center account
• A user who can complete the provider’s Partner Center consent with MFA
• Sufficient Entra and GDAP roles to create applications, service principals, relationships, and role assignments
• A Bifrost platform administrator account
• One development customer tenant for acceptance testing
• A secure secret manager for any client credentials created outside Bifrost

Review Microsoft’s partner security requirements, Partner Center authentication guidance, and Secure Application Model before granting access.

Design Roles and Groups

Create named profiles that correspond to installed capabilities. The exact permissions depend on your workflows; the following is a review framework, not a permission manifest.

Profile	Typical capabilities	Review notes
Foundation	Tenant identity, domains, service-principal checks, organization metadata	Prefer read-only permissions.
Identity administration	Users, groups, memberships, and licenses	Separate read and write variants. Match write permissions to GDAP roles.
Mail and calendar	Mailboxes, messages, calendars, and shared mailboxes	Decide whether delegated or application access is required. Apply mailbox access controls where supported.
Device management	Intune managed devices, configuration, and compliance	Intune permissions and licensing are separate from ordinary Graph directory access.
Exchange administration	Exchange Online PowerShell or app-only Exchange operations	Requires Exchange-specific configuration and an appropriate Exchange role.
Teams deployment	Resolve users and install the provider’s own Teams app	Prefer TeamsAppInstallation.ReadWriteSelfForUser.All and the equivalent team or chat permission only for scopes you support.
Teams history	Read messages outside bot-delivered activities	Optional. Use resource-specific consent where it fits; do not add broad chat permissions to the base profile.

Use the Microsoft Graph permissions reference to verify current permission types and admin-consent requirements.

Map capabilities to Entra roles, then map those roles to provider security groups. Prefer a few stable job-function groups over one group per customer or one broad group for every role. Ask the operator which people should belong to each group; group creation, membership, and access assignments can then be automated through Graph with approval.

Map Customers

1. In the CSP workspace app, refresh the Partner Center customer list.

2. For each managed customer, create or select the corresponding Bifrost organization.

3. Link the Microsoft customer tenant ID to that Bifrost organization.

4. Verify that each tenant ID maps to exactly one organization. Resolve duplicate or stale mappings before enabling events or write workflows.

5. Store the relationship state and last verification time in the tenant-status record.

Mappings are security boundaries. Workflows should set customer scope only after resolving an exact mapping. Unknown or ambiguous tenants should fail closed.

The CSP reference implementation documented list_csp_tenants for Partner Center discovery and link_csp_tenant for storing the organization link and Microsoft integration mapping. Treat these names as workspace-specific, not platform contracts. Use the workspace app and workflows or Bifrost’s integration interface rather than editing IDs into workflow source.

Optional CSP Automation Surface

The reference CSP app and workflows documented these operations. Confirm the workspace version’s names, permissions, and token handling before use; they are not a Bifrost platform contract. Read operations can support discovery; write operations should be proposed with exact parameters and approved before execution.

Workflow	Mode	Purpose
check_microsoft_setup	Read	Confirm the Microsoft CSP and Microsoft connections are configured
list_csp_tenants	Read	List Partner Center customers and merge their Bifrost organization status
get_gdap_status	Read	List GDAP relationships and summarize the best relationship per tenant
link_csp_tenant	Write	Store the customer-to-organization link and upsert the Microsoft mapping
create_gdap_relationship	Write	Create and lock a relationship, then return its customer approval URL
update_gdap_assignments	Write	Synchronize active relationship assignments to the provider’s GDAP template
apply_partner_permissions	Write	Grant selected application roles to the provider’s Microsoft service principal
consent_csp_tenant	Write	Create customer service principals and apply selected delegated and application grants

Re-read Graph and Bifrost after every write. A workflow execution status of success does not prove customer approval, propagation, or a usable grant. Never permit an access token, refresh token, authorization code, or client secret in a workflow result or execution variable.

Create a GDAP Relationship

Microsoft Graph exposes the GDAP relationship APIs. The relationship lifecycle includes creation, customer approval when required, activation, role assignment, and expiration.

1. Define a relationship name and duration. Use the shortest duration that fits the provider’s operating model and renewal process.

2. Select the least-privilege Microsoft Entra roles needed by the customer’s installed capabilities.

3. Create the GDAP relationship through the CSP workspace automation or the documented Microsoft API path.

4. Send or present Microsoft’s approval link if customer approval is required.

5. A customer administrator reviews and approves the invitation in Microsoft 365 admin center. Poll the relationship until it becomes active; do not treat creation or lockForApproval as customer approval.

6. Assign provider security groups to the approved roles.

7. Verify the assignments through Microsoft Graph, then run a read-only API test in the customer’s context.

Use a Portable GDAP Template

A GDAP template should contain role IDs and logical group references, not IDs copied from another provider tenant. During installation:

1. Select or create the provider’s security groups.
2. Store their provider-local object IDs in setup data.
3. Select a verified relationship as the source only when importing an existing role design.
4. Review the resulting template before applying it to another customer.

Never ship a hard-coded relationship ID or provider security-group ID in a reusable Bifrost Solution.

Establish Customer Consent

Customer consent is separate from the GDAP relationship. The exact path depends on whether you are a direct provider, indirect provider, or control panel vendor.

1. If using a CSP/GDAP provisioning path, confirm the customer relationship is active and the assigned roles cover the provisioning action.

2. Create or locate the provider application’s service principal in the customer tenant.

3. Apply the reviewed customer permission profile.

4. Grant admin consent through the provider’s approved CSP/GDAP flow or have a customer administrator complete the consent screen.

5. Re-read the service principal and OAuth permission grants in the customer tenant.

6. Run one read-only capability test. Run write acceptance tests only with an explicit test object and approval.

Control panel vendors should also review Microsoft’s customer consent APIs. Do not assume that delegated administration automatically grants every application permission. Microsoft Graph’s relationship approve action is for the documented indirect-provider scenario; it is not a way to silently approve an ordinary customer’s invitation.

Verification Checklist

Complete these checks for the provider:

• The CSP workspace automation’s connection, when used, reports healthy.
• Partner Center customer discovery returns the expected development tenant.
• Configured application permissions match the selected profiles.
• No token, authorization code, or client secret appears in workflow results or logs.

Complete these checks for each customer:

• Tenant ID maps to exactly one Bifrost organization.
• GDAP relationship is active and not close to expiration.
• Security-group role assignments match the template.
• Customer service principal exists and grants match the intended profile.
• A read-only Graph request succeeds in customer scope after application consent. It does not require a delegated GDAP token at runtime.
• Each installed write capability passes a controlled acceptance test.

Operations

Monitor connection health, relationship expiration, permission drift, customer removal, and failed tenant-scoped requests. Re-run verification after any change to permissions, GDAP roles, provider groups, the Entra application, or an installed Solution.

When offboarding a customer:

1. Disable event subscriptions and scheduled writes.
2. Remove the Bifrost tenant mapping.
3. Remove or expire the GDAP relationship and assignments.
4. Revoke customer consent and remove the enterprise application when no other approved integration needs it.
5. Retain only the audit evidence required by your policy.

Common Failures

Symptom	Likely cause	Check
Provider connection succeeds but no customers appear	Wrong Partner Center account, missing relationship, or token audience	Provider tenant, account role, and Partner Center connection
Partner Center returns customers but GDAP status is empty	Wrong provider tenant, missing delegated relationship permission, stale authorization, or no Graph-visible relationships	Token tenant and audience, current consent, and Partner Center relationship inventory
Customer appears but Graph calls fail	Missing customer service principal or application consent; a GDAP role may block provider-side provisioning	Application grants, then relationship assignments when provisioning is in scope
A write call returns forbidden	Read profile was installed or GDAP role is insufficient	Workflow capability matrix
A relationship exists but is unusable	It is pending approval, expired, or has no group assignments	Relationship status and access assignments
Setup works only for the original provider	Provider tenant IDs, relationship IDs, or group IDs were hard-coded	Solution config and setup tables
Workflow results contain access tokens	Sensitive values were returned or captured as ordinary variables	Workflow outputs and execution-variable capture

Continue With Teams

If the provider will deploy a shared bot, continue with Set Up a Shared Microsoft Teams Bot. The bot can reuse customer tenant mappings but has a separate identity, Teams package, event source, and permission profile.