Configuring the Secure App Model for PowerShell / API / Graph scripting with GDAP for Partners

[sansbacher]

Hi whomever may find this!

With the old MS Partner Community Forums going read-only as of March 8th, 2023 I thought I'd post a few useful links here in case someone is searching and unable to post on the old forums.

The 2 main GDAP related threads on the old forum that feature info on getting Secure App Model to work with GDAP and the Exchange Online V3 PowerShell module (with the ExO automation App ID: a0c73c16-a7e3-4564-9a95-2bdf47383716 being retired eventually) are:

MS Graph/Secure App and GDAP

Exch Online V3 and Secure App

These are both long threads, lots of info in a meandering kind of way. They disappeared after June 30th, 2023 - so these are links to the Internet Archive's WaybackMachine. But they're how we worked it all out - so useful background.

So the best place to find current, step-by-step instructions for getting things to work is this post:

My Automations Break with GDAP: The Fix!

It appears Nick has collected up all the info from the above 2 links, tested it, and made a fairly complete blog post, so start there. (note: for the ExO V3 stuff you must use the Customer's initial onmicrosoft.com domain for things to work properly) Big thanks to him!

Nick has 2 additional posts that may be of interest as well. One on Leveraging APIs for unattended Automation. And one on Updating the GDAP Consents across all your Customers.

For some background info you can check out some of these links:

• The code leverages the The Secure App Model. It can be implemented in PowerShell.
• Setting it up involves a few steps. But many (most?) of us likely followed Kelvin's post on CyberDrain (or Gavsto has a simple introduction too) ... originally. Though still useful background info these links have lots of outdated info, eg. they still reference Msol and AzureAD commands, but you can still mostly use them to follow along. There's also a post about securely storing secrets, like the RefreshTokens.
  • For CURRENT info, use the link above for GDAP + Secure App Model.
  • Msol/MSOnline doesn't work with GDAP and AzureAD uses the old AzureAD Graph which is also being retired (use MS Graph instead, which works with GDAP).
  • Remember: RefreshTokens are good for 90 days, redeem them for an AccessToken which is good for 60 mins. After 60 mins get another one. Before 90 days are up, get an AccessToken (which always includes a new RefreshToken) and save it instead of the old one. You can repeat that forever. But you may need to restart the process if the account you used initially changes its password - so use a dedicated account.
• For: Exchange Online and the Exchange Online Management V3 module and you can refer to the posts in this forum, since there are mistakes and omissions in the official MS docs.
  • Main error: use the original .onmicrosoft.com domain as the CustomerTenantID when connecting with Connect-ExchangeOnline
  • If you use their public customer.com or their TenantID (Guid) it will work inconsistently, and you'll have problem writing (reading may work)
• The Secure App Model mainly uses Delegated permissions, see: App-Only vs Delegated Permissions and there's more info here.
  • Any Graph API calls will list Permissions needed depending on if you're using Delegated or Application, with GET /users/{id} for example. We generally use Delegated since we're accessing on behalf of Customers. 
  • You'll need to ensure your Secure App Registration has the required Graph permissions AND so does your customer Consent.

Hopefully that helps someone!

   --Saul

[Edited to add the WaybackMachine links and Nick's new posts]

[#2]

Hi @sansbacher ,

thank you very much for the summary.

[#3]

Excellent post!

For Exchange you can also talk directly to Exchange REST. An important pitfall there is the existence of the "anchor mailbox" concept. Usually that's either the environments system mailbox (for example to enable Unified Audit logs) or the mailbox of whatever resource you're trying to make a change to.

The system anchor mailbox in any given tenant is almost identical, the only difference is the TLD. The TLD for the mailbox will always be the initial onmicrosoft domain.

"UPN:SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}@$($OnMicrosoft)"

[#4]

Thanks @rvdwegen92 ,

Yes I'm aware that you can directly connect to ExO using REST - that's how the new ExO V3 module does it (if you install it and look at the code you'll see some of how it works). And also how Kelvin's CIPP back-end API connects to Exch Online.

However I imagine if someone is doing that they A) already know how to connect and B) have specific purposes: generally trying to create some kind of larger automated system, using APIs entirely and not relying on PowerShell at all. (CIPP uses PowerShell, but it could just as easily be written in Node/JS for example if it uses only REST APIs)

I think for the average scripter trying to automate some aspects of AAD, Azure, ExO, etc using the Secure App Model they are probably looking at using existing PowerShell modules due to likely familiarity with them plus re-using existing code. I do for any of my ExO scripts, just simpler.

For anyone writing a full app using APIs - I'd definitely recommend using the ExO REST APIs! 🙂

   --Saul

[#5]

Thank you for sharing. Maybe you know why this error occurs when connecting msol

Connect-MsolService: IDX10703: Unable to decode the 'header':

[#6]

@SimonasPikelis , the old MSOnline / Msol module does not work with GDAP. You'll need to migrate to MS Graph.

   --Saul

[#7]

@sansbacher

But as I know, MS Graph does not have tools for setting up per-user MFA (to check or to set Enable, Enforce, Disable status). So I still use MSOnline module for that. And this is not working without DAP.

[#8]

Hi @bKeski,

That is correct, as of now this cannot be done via MS Graph.

Nevertheless, the old PowerShell modules will been discontinued until March 2024:

https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-new-feature-and...

[#9]

@bKeski 

You really shouldn't be using per user MFA anymore.

[#10]

@bKeski ,

Correct, and as others have noted: Per-User MFA isn't yet fully available in the MS Graph API, though parts of it are in the beta end-point:

https://learn.microsoft.com/en-us/graph/api/resources/userregistrationdetails?view=graph-rest-beta

You can add your voice to speed this up:

https://feedbackportal.microsoft.com/feedback/idea/12d10bfb-10e3-ec11-a81b-000d3a03dba2

Sadly, while the MS Online and Azure AD Graph based modules will be deprecated March 30th, 2024 [and "Once these modules are deprecated, they will continue to work for a minimum of six (6) months before being retired"], they are currently not receiving any new features:

https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/important-azure-ad-graph-retire...

I assume this means making them work with GDAP - they only support DAP.

So while they may continue to work throughout most of 2024 they won't work for Partners using GDAP (which is now required) since they rely upon DAP. I don't have an answer for that.

Maybe @JillArmour can dig into things on the Microsoft side of things and see what we're supposed to do: we must use GDAP not DAP, but that means using MS Graph, but it doesn't support Per-User MFA actions, and the older MSOnline module relies upon the older Azure AD Graph which doesn't support GDAP. So we're stuck.

And Per-User MFA is still supported, even if it's not the ideal way of managing MFA.

   --Saul

[#11]

@ManishaDas would you be able to help here? Thank you kindly. 🙂

[#12]

@sansbacher 

Do you have any articles about using Get-MsalToken instead of the partner center powershell module? Ps7 doesn't play well with the az and partnercenter modules togeather.

Is this an abandonware? · microsoft/Partner-Center-PowerShell · Discussion #400 · GitHub

[#13]

So, the MSAL.PS repository (Get-MsalToken is from that) was archived on Sep 22, 2023
https://github.com/AzureAD/MSAL.PS

Booo

[#14]

@jonwbstr24 ,

Yes, I'm not sure I would put much stock in Microsoft's desire (or willingness) to update and support various PowerShell modules these days (with 2 exceptions: the auto/machine-generated MgGraph module, which "works" but isn't really user-friendly. And the ExchangeOnlineManagement module, currently at V3 -- which is generally pretty good) ... the PartnerCenter and other modules are either not maintained or are deprecated (and will likely stop working entirely when AzureAD Graph is retired).

I would suggest making direct REST API calls, which can be done in PowerShell, for example:

$body = @{
	"grant_type"    = "refresh_token"
	"refresh_token" = $RefreshToken
	"client_id"     = $ClientId
	"client_secret" = $ClientSecret
	"resource"      = "https://api.partnercenter.microsoft.com"
}
$response = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantId/oauth2/token" -Method Post -Body $body -ContentType "application/x-www-form-urlencoded"

This is how Kelvin's CIPP app works (the source-code for the back-end API will show you some examples using PowerShell - including authenticating to Partner Center, Graph, and even API access to Exch Online. Or you can use any language (I've mainly switched to JavaScript/Node). Nick's T-Minus365 site I linked to above has some examples as well, look for the REST API / Invoke-RestMethod sections. 

Unless the community is going create a module, or fork and maintain existing modules, you're better off making yourself a collection of a few scripts/functions (eg, to redeem an RefreshToken for an AccessToken, make API calls with the AccessToken, and perform a "get-all" for when there's more than one page of results, and some functions to provision the GDAP App Consent, etc) than relying upon a PowerShell module that may work now, but may not in the future...

--Saul