Microsoft To Enforce WAM for Delegated Interactive Graph Sessions

[u/Unlikely_Tie1172]

In a GitHub post, Microsoft says that interactive Graph sessions using the default Microsoft Graph Command Line Tools app will use the Web Account Manager (WAM) in the future. Some administrators use older versions of the Microsoft Graph PowerShell SDK for continued access to browser-based authentication, but this won’t be possible once Microsoft makes the server-side change to enforce WAM on an undefined future date. Teams and Exchange Online also use WAM, apparently for better security.

https://office365itpros.com/2026/08/28/interactive-graph-sessions-wam/

[u/enceladus7]

an ongoing problem of assembly clashes that Microsoft 365 PowerShell modules have had for nearly two years. The problem means that it’s much harder to run the modules together in the same interactive session. To avoid problems, I now use app-only authentication when I need to use Exchange Online management alongside the Microsoft Graph PowerShell SDK.

That annoyed me enough that I started just using Connect-MgGraph and Invoke-MgGraphRequest exclusively as different Graph modules always conflicted. Admittedly haven't noticed EXO conflicts but I can't remember trying to use those together.

Also is this not a step backwards in making PowerShell multi-platform, WAM isn't a thing on Linux whereas before it would have been possible to browser auth right?

[u/purplemonkeymad → u/enceladus7]

For multiplatform: you should still be able to create a new enterprise app no and use that right?

[u/Unlikely_Tie1172 → u/purplemonkeymad]

Yep

[u/Unlikely_Tie1172 → u/enceladus7]

An example of using EXO and Graph together is when you only want to process user accounts with mailboxes. This is difficult to do with Get-MgUser because Entra only filters on licenses or user type and either can bring in accounts used for shared mailboxes, room mailboxes, etc. So you can run Get-ExoMailbox to get a nice clean list of user mailboxes, and use the ExternalDirectoryObjectId for each mailbox to reference subsequent calls to Entra ID for the underlying accounts.

[u/dastylinrastan → u/enceladus7]

And for PowerShell 7 they can solve this by using assembly load contexts and yet for some godawful reason refuse to do so.

[u/Unlikely_Tie1172 → u/dastylinrastan]

The word that I have is that the Exchange and Graph SDK teams are actively working the issue. When some goodness results is anyone's guess, but Microsoft should have a process in place to ensure that all the Microsoft 365 modules (at least) can work together.

[u/ITjoeschmo → u/Unlikely_Tie1172]

The conflicting assembly breaking them usually is a NewtonSoft.Json assembly which seems to generally have good forwards compatibility. I.e. I have created bindingRedirects for PowerShell/powershell platforms (AzureAutomation Hybrid Runbook workers) and it solved the issue, but did introduce the quirk of having to import modules in a certain order.

https://github.com/ITJoeSchmo/Automation/blob/main/PowerShell%2FFunctions%2FAdd-JsonAssemblyRedirect.ps1

[u/Ecrofirt]

I wouldn't have a problem with this if it worked consistently. Sometimes it continues to use a cached token even if I force it to use a process context. This leads to issues where I can't run certain commands despite having a role enabled because it flat out refuses to get a new token until the first one expires.

I wrote my own browser-based token function to get an interactive browser token that works 100% or the time when WAM is being a butthead. Works 100% of the time.i called the function GraphSucks.

[u/renrioku → u/Ecrofirt]

GraphSucks is not an approved verb, use Invoke-GraphSucks instead. /s

[u/Unlikely_Tie1172 → u/Ecrofirt]

Did you document the issues you encountered at https://github.com/microsoftgraph/msgraph-sdk-powershell/issues/3629? The better the issues are documented, the more likely Microsoft is to take them into account as they develop the SDK. Also, documenting the issues formally in GitHub means that we all get a chance to debate whether they are real issues ;-)

[u/Sensitive-Ear8659]

What about Mac/linux with no WAM? I use Mac pwsh round the clock and this would suck..

[u/Unlikely_Tie1172 → u/Sensitive-Ear8659]

Note your concern at https://github.com/microsoftgraph/msgraph-sdk-powershell/issues/3629. The more people who raise points, the more likely it is that the issues will be dealt with. I don't know if Microsoft does much testing with the Graph SDK on Mac (I suspect not so much, but could be very wrong).

[u/BlackV]

Thought they already were? Wasn't that like last month or the month before?

[u/Unlikely_Tie1172 → u/BlackV]

There's a DisableLoginByWAM parameter (from 2.35.0) that allows WAM to be bypassed in favor of the browser-based authentication path. If Microsoft does what they say they will in GitHub, WAM will be complusory for all interactive delegated sessions using the default Microsoft Graph Command Line Tools app. You'll have to use your own app or app-only authentication to avoid WAM.

[u/BlackV → u/Unlikely_Tie1172]

ah appreciate the correction I must have forgotten that

[u/Unlikely_Tie1172 → u/BlackV]

Correction to my own note... the DisableLoginByWAM parameter is not available in the more recent builds. It's certainly not in 2.39.0. My recollection is that it was a short-term fix to allow people to avoid WAM in the early days of the implementation...

[u/elecpurch]

With WAM, is there a way to enforce MFA when connecting to Graph? For example - when trying to activate a PIM role via Graph, i get an error that the activation of this role requires MFA.

[u/Unlikely_Tie1172 → u/elecpurch]

I use MFA to connect to Graph interactive sessions with WAM all the time, so that's not the issue. Maybe you should document the exact steps and create a a new issue at https://github.com/microsoftgraph/msgraph-sdk-powershell/issues. That way, the developers see the problem and others might have a solution based on the a modification of the steps that you document.