1

Microsoft will end support for basic authentication in Exchange Online remote powershell October 13th, 2020.

Server-to-server communication can be done using the System.Management.Automation.Runspaces.WSManConnectionInfo class with basic authentication. What is the supported way for an on-premise daemon application to run remote powershell in Exchange Online when basic authentication is no longer supported?

Tore Olav Kristiansen
  • 185
  • 1
  • 13

2 Answers2

4

If you don't want to rewrite your remote PowerShell code to use the new V2 Exchange Online Management module shown by @stukey above, you can use an alternative workaround by using ADAL (or a similar library) to fetch an access token from AzureAD, then use the token as password when constructing your PSCredential.

If you add ?BasicAuthToOAuthConversion=true to the connection URI, the server will then pull the token from the basic auth header and use modern authentication with the token instead.

The workaround is outlined here and semi-documented by Microsoft here.

khellang
  • 17,550
  • 6
  • 64
  • 84
  • Not sure if that makes sense. By that I mean that Basic Auth will be disabled completely _including Remote PowerShell_. So this works, yes, but still until they switch off Basic Auth. You can check this now by disabling Basic Auth manually. So only using EXO PS V2 Module seems like valid solution. – Petr Abdulin Jan 24 '22 at 12:44
  • @PetrAbdulin It makes a lot of sense. We're running this in production across many customers with Basic auth already turned off. If you decompile the EXO V2 PowerShell module, you'll see that this is the exact way Microsoft works around the lack of "modern" authentication in the remote PS stack. I'd love for you to test/verify this and come back and prove me wrong – khellang Jan 24 '22 at 22:15
  • Are you sure it is really disabled? So basically it's like this for me: 1. use `New-AuthenticationPolicy` to create new policy (have BasicAuth disabled for all by default), 2. assign policy to user in test. User in test is unable to auth with this approach, able to auth using EXO V2 module. I'm sure no expert here, so maybe I'm missing something. – Petr Abdulin Jan 25 '22 at 14:59
  • 1
    Of course. When it's disabled, authentication fails. When switching to the workaround in this answer, it works. As I said, the "workaround" here is exactly what Microsoft is doing internally in the EXO V2 PowerShell module - it has to work :) – khellang Jan 26 '22 at 11:24
  • 1
    Here's a screenshot of the decompiled source from `NewExoPSSession` in `Microsoft.Exchange.Management.ExoPowershellGalleryModule.dll` from the `ExchangeOnlineManagement` PowerShell module: [Imgur](https://i.imgur.com/QeQkvMt.png) – khellang Jan 26 '22 at 12:21
  • Yeah, I know, I've tested using the workaround, but I did made a mistake in PS script, so it failed bacause of that. Because of your confidence I took another attempt and found my mistake! Many thanks! – Petr Abdulin Jan 27 '22 at 14:06
2

Assuming your daemon application is using a Service Account ID without MFA, then you can utilise the new V2 Exchange Online Management PowerShell module to connect to EXO using Modern Auth. It handles everything for you, so you can still initiate a connection using your Service Account username and password credentials, and the module will use those creds to get a token from Azure AD and then authenticate to EXO using Modern Auth. Works great if your Service Account creds are managed by a separate password vault solution. If you can’t use credentials-based auth, then Microsoft are working on an update to the EXO module that will allow you to authenticate to EXO using a registered Azure AD app together with certificate-based auth. That should be coming soon...

stukey
  • 126
  • 1
  • 1
  • 5