MS Graph and Partner GDAP - access customer tenant via graph

Question

I am trying to get some scripting ready for Granular Delegated Admin permissions that we are all forced to change to this year from DAP and really struggling to work out how to get this working to access customer tenants.

I have created an app in our CSP tenant with relevant permissions. Has relevant graph permissions (like directory.read.all) and partner center user impersonation.

Global admin has granted consent.

I can generate access tokens and connect to the graph for our own tenant. Along with querying contracts etc to get a list of all our customer tenants etc. However it seems impossible to connect to a customer MSGraph when using GDAP.

For a tenant that is still on DAP, I can use

https://login.microsoftonline.com/\<customer tenant ID>/oauth2/v2.0/token

To get an access token and then the graph will respond their tenant.

But if I do the same for a tenant that has GDAP, I get:

"error": {
"code": "Authorization_IdentityNotFound",
"message": "The identity of the calling application could not be established.",
"innerError": {
"date": "2022-05-30T11:24:11",
"request-id": "aa4d75a5-03ed-4f5a-811d-e09e63e346ed",
"client-request-id": "aa4d75a5-03ed-4f5a-811d-e09e63e346ed"
}

The Azuread App service principal is in the group which has been given access to the tenant.
User management role so can access the msgraph to get a list of users. But just get the above error.

Struggling to find anything online and not sure where to go from here.

Hope someone has some insight into how to make this work.

Answer 1

I'm sure most everyone has solved this but I'm putting some answers here for posterity as I know that as of late '23, not every MSP has been forced over to GDAP.

One existing answer mentioned GDAP but didn't provide much clarity or practical guidance.

Basically, you need to change how your registered application gets permissions to operate on client tenants. The conversion process works fine but involves jumping through hoops and some trial and error. Here's an overview of the process and some notes at end.

Overview of Steps

1. Create a service account and group in your own tenant.
   • Call the service acct something like gdap-automations@[MspTenantDomain].
   • Call the group something like grpGdap (or whatever).
2. Add the service account to the group Agent Admins in your MSP tenant AAD.
3. Log in as the service account to make sure MFA is configured (MFA is required).
4. Give the service account Global Admin role temporarily (use PIM for this ideally so the role falls off automatically - it's not needed long term).
5. Modify your registered application by adding the equivalent Delegated permissions, corresponding to those that you may have added in the past as "Application" permissions. You don't need to delete the existing ones, but the Application level permissions won't do anything for us in the GDAP model, just the Delegated permissions.
6. Go into Microsoft Partner Center, select a random customer, and select "Admin Relationships". You'll probably have an existing relationship here, but it will likely be insufficient for what we need. Create a new Admin Relationship. Call it GDAP or something.
7. Set the relationship to Auto-Extend, set expiration to 90 days or more, add the Entra permissions of Cloud App Admin or Application Administrator (at least).
8. Add the custom group from step 1b to this relationship.
9. Get the invitation URL for this new relationship and then grant it by logging into the customer tenant as a global admin (just like you may have done to grant your delegated admin permissions in the past).
10. Now that the admin relationship is active, you need to run some PowerShell scripts as a POC, or just start modifying your application to work as follows:

• Get a refresh and access token from Partner Center using the service account we built in Step 1a.
• Use the access token to register an application in the customer tenant mirroring your own automation application. This will create the registration and propagate the same API permissions (as long as they are delegated not application, remember? App-style perms will not show up in the created app).
• Use the refresh token to request an access token on the customer tenant.
• Use this access token when making Graph API calls against the customer tenant.

Some References

Good, clear examples of the code in ste p 10 in PowerShell can be found here: https://tminus365.com/my-automations-break-with-gdap-the-fix/

While the above link has some really good instructions, I found that reading the Microsoft info alongside it helped me understand what was going on a little better. This page in particular was helpful: https://learn.microsoft.com/en-us/partner-center/developer/gdap-and-secure-application-model

Powershell vs. REST

So all the PowerShell stuff in step 10 is a good PoC, but if you have an app where you're using Graph REST API it's pretty easy to convert over. The POST request to get a token uses the same endpoint as you used to use: https://login.microsoftonline.com/{{tenant}}/oauth2/v2.0/token

but the body of the request changes slightly:

• the value of the grant_type property will now be "refresh_token".
• you'll need a new property named "refresh_token" whose value is the refresh token from step 10a.
• Other properties like client_id, client_secret, and scope are the same.

The access token returned from this request will now be fed into your other existing requests for tasks like getting users from customer tenants. You just replace the token you had been using earlier with this new access token. Everything should work assuming you got your API permissions correct for the calls you're making.

Pitfalls

• Make sure the registered automation application in your own tenant has a defined redirect URI. If this hasn't been set up, you'll get the error message telling you to do it when trying to run the PowerShell script for the Partner Center stuff. Just go to your app registration, Overview, and there should be a link there named "Add redirect URI" or similar. Add app type of Web, and then just use http://localhost:8400 or whatever.
• Make sure your registered application is using Delegated API permissions, not Application API permissions. Only the delegated perms will propagate to the app registration that gets created in the client tenant.
• Make sure your Admin Relationship has Cloud App Admin or App Admin permissions - this is what lets us create the application in the client tenant.

I wouldn't be surprised if I've missed something, but hopefully this helps someone else. Of course, your application should have some mechanism to save the refresh token and keep it updated on a regular basis to avoid having to go through the sign-in process with the service account multiple times.

Answer 2

Thanks for reaching out to us , first we would like to know how you are generating access token ?

Could you please try acquiring access token through PowerShell ,
you need to install Partner Center PowerShell module first then

step -1

Install-Module -Name PartnerCenter -AllowClobber -Scope CurrentUser
ref doc- https://learn.microsoft.com/en-us/powershell/partnercenter/install?view=partnercenterps-3.0#install-the-partner-center-powershell-module

step - 2

New-PartnerAccessToken
-AccessToken <String>
-ApplicationId <String>
[-Credential <PSCredential>]
[-Environment <EnvironmentName>]
-Scopes <String[]>
[-Tenant <String>]
[<CommonParameters>]
ref doc - https://learn.microsoft.com/en-us/powershell/module/partnercenter/new-partneraccesstoken?view=partnercenterps-3.0 .

step - 3
When you get the access token ,GDAP is mainly available for beta version , for confirmation you can check the API -Get https://graph.microsoft.com/beta/tenantRelationships/delegatedAdminRelationships

ref docs - https://github.com/microsoftgraph/microsoft-graph-docs/blob/main/api-reference/beta/api/tenantrelationship-post-delegatedadminrelationships.md

Answer 3

As above, token is being retrieved via MSGraph. (same as doing the powershell module, same error either way, just doing it in graph).
https://login.microsoftonline.com/<customer tenant ID>/oauth2/v2.0/token

The issue is nothing related to the refresh token, its related to accessing a customer tenant. You have provided info about connecting to our partner tenant (which is not an issue)

The issue is that with DAP disabled, and GDAP enabled, there is no automatic pre-consent of the azureAD application in our customer tenants, so we cannot connect to their tenant and run the commands that we need. And this needs to work before DAP is removed as its a critical function.

I can run commands fine on our own tenant, but we need to get to our customer tenants. That is the issue.

Thats when we get
code": "Authorization_IdentityNotFound",
"message": "The identity of the calling application could not be established.",

If we enable DAP, the pre-consent happens and everything works. As soon as we remove DAP and go back to GDAP, all fails.