Today, while wanting to check some settings in our Exchange Online environment, I ran into an issue where the New-ExoPSSession command let failed with the following error: Create Powershell Session is failed using OAuth. It took me some time to figure out what was causing this issue, and I’m documenting it here for future reference.

TL;DR; – The solution was to modify the set the MDM Security Baseline in Microsoft Endpoint Manager and set the “Client basic authentication” setting under Remote Management to “Not Configured”

Some more details below,

While wanting to start a PowerShell session to Exchange Online using the Exchange Online PowerShell V2 module (EXO V2), I ran into the issue that after providing my Userid, password and approve with the MFA request, I was presented with the following error: New-ExoPSSession : Create Powershell Session is failed using OAuth.

After some searches on the internet I ended up at the Prerequisites for the EXO V2 module, which describes the following:

WinRM needs to allow Basic authentication (it’s enabled by default). We don’t send the username and password combination, but the Basic authentication header is required to send the session’s OAuth token, since the client-side WinRM implementation has no support for OAuth.

Wait, what? – so the module doesn’t use basic authentication (userid/password) but requires it to be enabled.

I quickly checked the configuration using the following command: winrm get winrm/config/client/auth

Based on the documentation I tried to update the setting Basic to true, but that failed because the setting was coming from a GPO. But wait a minute, my machine in Azure AD joined, and I’m not using GPO technology.

I am doing some security configuration though on my Modern Workplace, and the first place to start is the Security Baseline, I quickly found the following setting, Client basic authentication which is set to “Disabled” by default.

After modifying this setting to “Not configured” and syncing the policy using the Company portal I got another result when requesting the WinRM settings.

With this setting now set to basic, I tried again to connect to Exchange Online, this time with an expected result.

Conclusion

This article serves as a note for myself in case I drop into this issue again in the future, and hopefully it helped you if you ran into this issue and found my blogpost.

Be careful though when implementing exceptions for the baseline, especially in large environments this might be a reason to create a different baseline for people administering the environment and not giving this exception to all your users. Even better would be to not let administrators perform these tasks from their own workstations but require the usage of Privileged Access Workstations. I’m realistic though, and consider that scenario Utopia for many environments today.