Basic Authentication Deprecation Can Stop Exchange Online Scripts Working

October Deadline Looming

On May 16, Microsoft announced an update for scripts used for public folder migration to use modern authentication. With just 136 days to go before Microsoft starts the final turn-off of basic authentication for seven email connectivity protocols, including PowerShell, it’s evidence that even Microsoft has to do work to prepare for the transition of basic authentication PowerShell.

Exchange Online Remote PowerShell Still Used with Basic Authentication

This brings me to the sad fact that many who use PowerShell to interact with Exchange Online still use Remote PowerShell (RPS) with basic authentication. Among the reasons why this situation exists are:

• Lack of awareness that Microsoft will disable basic authentication for PowerShell in remaining tenants starting on October 1. Once Microsoft removes basic authentication from a tenant, scripts that attempt to connect using basic authentication will fail.
• Lack of visibility for scripts running within the tenant. Scripts might have been created and implemented without the knowledge of administrators, or maybe even by previous administrators who might not have documented their work.
• Lack of time and serendipity. For example, it’s common to find that people include commands to connect to different services in their PowerShell profile. If the profile is more than a year old, it’s likely to use outdated connectivity.

In addition, if you search for “How to connect to Exchange Online with PowerShell” in blogs, articles, and books, you’ll probably find that the recommended method is to run the New-PSSession cmdlet to connect to Microsoft Exchange. Anyone checking out best practices in this area can be forgiven if they come away from a search with the impression that this is the best method. The only problem is that it creates a Remote PowerShell session using basic authentication, just like people have done for a decade.

Exchange Online Management Module

Microsoft introduced the Exchange Online Management module in 2019. At the time, the big headline was the creation of nine REST-based cmdlets designed to replace the set most likely to experience problems in cloud environments. The new cmdlets like Get-ExoMailbox and Get-ExoMailboxStatistics are faster and more tolerant of network issues and I was happy to talk about the cmdlets at the Ignite 2019 conference.

The new module also supported modern authentication. From version 2.0.3 onward, the module supports certificate-based authentication. The RPS cmdlets have a dependency on WinRM. Microsoft is removing the WinRM dependency by upgrading the RPS cmdlets. Substantial progress has been made in the preview version of the module and the most heavily used of the RPS cmdlets no longer depend on WinRM.

Work is ongoing to complete the upgrade for the remainder of the RPS cmdlets and hopefully, Microsoft will make the preview module that includes the upgraded RPS cmdlets generally available soon. The work to upgrade the remaining RPS cmdlets doesn’t have to be completed by October because Microsoft is not deprecating the WinRM connection when it turns off basic authentication for Exchange Online connections.

Note that if you use the preview version of the module, you must include the UseRPSSession parameter to load all the RPS cmdlets. If you don’t, Exchange only loads the upgraded RPS cmdlets. For more information about the different combinations of PowerShell and authentication supported by Exchange Online, see this blog post.

Call to Action: Avoid Basic Authentication PowerShell

The need for action is real. If tenants don’t check Exchange Online scripts to make sure that they connect to Exchange Online using modern authentication, they’ll have problems sometime after October 1 when scripts stop working. Because the Connect-ExchangeOnline cmdlet loads the old RPS cmdlets when it runs, the work to upgrade scripts is straightforward. That is, if you can find all the scripts that need to be updated.

While you’re making sure that scripts connect properly, take the time to check that any connections made to the security and compliance endpoint do so through the Connect-IPPSSession cmdlet.

You can go ahead and convert old cmdlets like Get-Mailbox to their upgraded equivalents to gain extra performance and stability, but this work doesn’t have to be done now (and will take substantially more effort in terms of coding and testing). The immediate priority is to make sure that scripts continue to connect and function after October.

Remember Azure AD Too

PowerShell developers have an even closer date to focus on. Microsoft plans to introduce a new license management platform for Microsoft 365 on 26 August 2022. That’s only a hundred days away before scripts that use cmdlets from the Azure AD and Microsoft Online Services (MSOL) modules for license management cease to work. It’s the first step along the path toward full depreciation of the modules in late 2022 or early 2023.

Limited time exists to validate that Exchange Online scripts work with modern authentication. No one wants to be the person who fails to take the necessary steps to update scripts, or to take the call when people discover that important scripts stop working.

---

Learn about exploiting Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.