MS Graph and Partner GDAP - access customer tenant via graph

[Leon-anspired]

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.

[JanoschUlmer]

@aconn21 : Thanks for the feedback, seems this cmdlet works a bit different than the ones I did test so far. Unfortunately I do not know any comprehensive documentation that explains where "AccessAsUser" is sufficient, given GDAP permissions are granted, and where additional explicit permissions are required. Honestly, I'm also not that deep into understanding Graph 🙂

[rvdwegen]

My understanding from Kelvin/Mikey O'Toole and practical testing right now is that all the permission grants need to be given on both sides for some functionality to work correctly. The graph AccessAsUser grant does appear to give some unknown level of access but it doesn't seem to correspond with the GDAP role assigned to the refreshtoken account for example. Given the untransparent nature of what AccessAsUser gives permission to I've chosen to just mass consent all permissions for now.

Edit:

And I just noticed in the Partner Center roadmap that the powershell module will also cease functioning at the end of March..

[JanoschUlmer]

@rvdwegen : Thanks for calling out - the Partner Center Powershell itself will continue to work, actually this is only about the functionality in the module that relies on this retired Exchange App ID (New-PatrtnerAccessToken -Module ExchangeOnline). I did actually call out that this wording is confusing, but it seems it still slipped through.

[rvdwegen]

That's good to hear. I was wondering why it didn't come up in any communication.

[JanoschUlmer]

@Leon-anspired , @KoenHalfwerk , @sansbacher , @EliK  - please check out this other thread created by @rvdwegen on a different approach for Exchange Online PowerShell where I just could confirm this will also be supported. So App-Only is not the only option as mentioned by me in this thread before.

This is using delegated permissions and is better aligned to the common approach used for other PowerShell modules when it comes to GDAP & Secure App Model: Retirement of the Legacy Exchange Online Public Cl... - Microsoft Partner Community

[Leon-anspired]

Thank you for that! That makes me much happier. Pretty much is how we have our automations setup.

[EliK]

We have one test tenant that we removed out DAP relationship and had it working fine with GDAP for a while. We have the a multitenant app consented with delegated permissions. Now this stopped working. I am able pull basic info from the tenants environment, but I'm not getting the full admin privileges I should be getting (its set in GDAP to Global Admin) For instance, I can pull users guids and user principal names but i can no longer pull the account enabled property. below is the code i have been testing with, accoutEnabled is blank. this exact code works for costumers where we left the DAP relationship in place.

Invoke-RestMethod -Headers $GraphHeaders -Uri "https://graph.microsoft.com/v1.0/users?`$select=id,userPrincipalName,accountEnabled&`$top=3"

Other endpoint like exchange rest API seem to still work. Seems like its graph specific that we lost some permissions to.

[rvdwegen]

What do you get when you Connect-MgGraph with your access token and do Ge-MgContext?

[EliK]

see below. I checked the token as well, i should have dir read write all.

[JanoschUlmer]

@EliK : Don't have an idea what may cause this - just tried to repro this and it shows up OK:

What kind of permissions/grants have you configured for MSGraph? I do use the same as @rvdwegen has in the last post. 

[EliK]

see below, these are the permissions granted in the customer tenant for the app. Maybe I can try re-creating the GDAP relationship. Not sure at this point.

[EliK]

I requested a new relationship, mirrored exactly what was already there, and now its working. Thanks!

[rvdwegen]

That's the permissions the Enterprise Application has in the customer/test tenant right?

If that's the case that is way more than what @JanoschUlmer suggested here, Solved: Re: MS Graph and Partner GDAP - access customer te... - Page 2 - Microsoft Partner Community

[sansbacher]

No, I don't think that screenshot of App permissions is from the Customer Tenant Enterprise App, I think it is from @EliK 's own (CSP) Tenant App Registration.

When I look at MY App Registration (in our Tenant) I see that same long list of API Permissions (or many/most of them).

BUT when I look at a CUSTOMER's Azure AD (with GDAP in place), under Enterprise Apps I see the same-named App (with same App ID) and it only has the 5 permissions Janosch mentions in his original post, that you linked to (2x Graph, 2x AAD, and 1x Azure Service).

According to @JanoschUlmer , he added "the permissions scopes explicitly in the [3] grants, it does not take over the permissions set for the app [registration] in the Partner [tenant]. Above mentioned [5] permissions should be sufficient - while they mention "Read" and not ReadWrite, you will get also write permission based on the [API] permissions the calling user [aka App Registration in your tenant] has - since it is delegated auth and "AccessAsUser" permissions."

As far as I know: if you are trying to do something with a Customer and are lacking permissions you need to add the appropriate API Permissions to Your CSP App Registration. We may need to add additional Grants (to the New-PartnerCustomerApplicationConsent) if there's a new SERVICE we're trying to access (right now only Graph, AAD, and Azure are listed, but Exch Online works. But if some other MS service doesn't we may need to add basic Read permissions to the Grant for Consent) which would show up in the Customer's Enterprise App.

This is my understanding, happy to be corrected if I'm wrong. I don't think this changes anything, I just mostly want to be clear - and for someone to correct me if I'm wrong! 🙂

-Saul

[EliK]

Agree, its more than what's needed. This was my first tenant I was testing with months ago. I did cut down on the permissions after this one 🙂

[JanoschUlmer]

@sansbacher Thank you Saul for this great summary. Yes, I can confirm that this new approach became a requirement ~early October. 

I agree that that it is time to give up on MSOnline (and also AzureAD module) - MgGraph is the new recommended option. 

[Leon-anspired]

Only problem is msgraph still cannot return the subscriptions in a tenant. So stuck with msonline till it's available, if it ever becomes available...

Get anspired!
Leon Black

Leon Black - Director/Chief Operating Officer
Tel: 02 4380 8383 | w: anspired.com.au
unit 4 9-11 Hereford St, Berkeley Vale, Central Coast, 2261
Please be aware of the increase in cybercrime and fraud. If you receive an email purporting to be from someone at anspired which seeks to direct a payment to bank details which differ from those which we have already given you it is unlikely to be genuine. Please do not reply to the email or act on any information contained in it but contact us immediately via phone on 1300anspired(1300267747)

[sansbacher]

Doesn't it? I admit that I've not switched over to MS Graph (since the MgGraph module seems to be nothing but a million thin wrappers over every. single. API. end-point. without any real "PowerShell-ish organization") but I've definitely used the PartnerCenter API to access Subscriptions a CSP Customer has. And I know the PartnerCenter PS Module will return that info too. Such as:

https://learn.microsoft.com/en-us/powershell/module/partnercenter/get-partnercustomersubscription?view=partnercenterps-3.0

Is there no direct direct replacement for Get-AzureADSubscribedSku? I have scripts that pull all of a Customer's Licenses (whether resold by us under CSP, or they purchased themselves) and I use that command. Would this not return the same info?

https://learn.microsoft.com/en-us/graph/api/subscribedsku-list?view=graph-rest-1.0&tabs=http

(perhaps without directly mapping Offers/Products/etc)

Or maybe the lack of 100% 1:1 coverage of AAD Graph to MS Graph is why the old one has been allowed to remain for so long after they said it would be turned off?

--Saul

[Leon-anspired]

Unfortunately it does not.

Get-PartnerCustomerSubscription is only available for Direct CSP, so thats no good.

subscribedSku's in MSGraph is the same as

Get-MsolAccountSku.

No details about the specific subscriptions that make up the license.

I.e. one direct case is non profits that get 10 free M365 BP licenses. So we need to separate the ones provided from MS for free and bill the additional ones. So we do that via the subscription ID.

What is missing from graph is the equivalent to

Get-Msolsubscription

Which returns the individual subscriptionID's and their quantities etc. Along with if its a trial and the start/end dates etc.

SubscribedSku - license expiry data/ next life cycle date is not available in this api response. · Issue #17500 · microsoftgraph/microsoft-graph-docs · GitHub

Seems the advise is to keep using get-msolsubscription 😞 I want to move everything to msgraph though.

[KoenHalfwerk]

Just use the grap (or mg graph)

$token = Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com/"

$headers = @{Authorization = ("bearer {0}" -f $token.token) }

Invoke-RestMethod -Uri ('https://graph.microsoft.com/beta/subscribedSkus/') -Headers $headers