From comments here: https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-february-2021-update/bc-p/2118379/emcs_t/S2h8ZW1haWx8bWVudGlvbl9zdWJzY3JpcHRpb258S0tYMk9XODFFSjA3SFh8MjExODM3OXxBVF9NRU5USU9OU3xoSw#M29487

Is there any update on for patching WinRM client so that it is no longer necessary to enable WinRM basic authentication to send the Oauth header for the ExchangeOnline PS Module v2 commands?

Because of this continued issue, we have to make company wide changes to our intune policies for WinRM to allow basic authentication just for a couple of Exchange admins.

Is this even on MS roadmap? Is MS working of a solution to this issue?

Nino Bilic
Microsoft
Monday

No, this is currently not on the roadmap. There are discussions about it, but nothing is currently committed.

It is best, though, to keep that separate from the subject at hand, because that particular problem is not related to the Basic auth disablement (as you pointed out, OAUTH is used to authenticate to the service in that scenario, it is a local machine requirement).

@Nino Bilic thanks very much for the response. At least I know now!

The reason for raising it here is i don't think it is a totally separate issue. my limited understanding was the Exchange Powershell module v2 WinRM workaround was primary necessary to enable the use of the old commands which still used Exchange PowerShell while enabling modern auth for connection?

Other modules like AzureAD and the MSgraph new EXO commands seem to deal just fine without it. So I would infer its a problem caused by Modern Auth and not having full MS graph PowerShell commands for Exchange?

I assume it is going to be fixed at some point by either patching WinRM or moving all Exchange commands to MSgraph? I assume either is a big headache and can't be done overnight.

I am aware that Basic Auth isn't really used for Auth, and the WinRM basic auth is only required to send the Oauth header. However, as the WinRM setting is contained in intune templates, the solution does mean lessening the orgs security for this setting. Lowering the organization security in one place so it can be improved somewhere else is not an ideal solution. I know some orgs that will not even permit it.

However, the point i was trying to make was that there isn't a great deal of visibility around what path MS is taking to solve the issue long term or what the timescales might be.