Microsoft Retiring Legacy Exchange Authentication Methods from October 2024: Are Tenants Ready?

Outlook integrated add-ins are a popular mechanism to extend client functionality to allow access to external data sources. No one knows exactly how many add-ins have been created or how many are in active use within Microsoft 365 tenants, but what we do know is that some tenants will get an unpleasant shock in October 2024 when Microsoft turns off legacy Exchange user identity tokens and callback tokens for Exchange Online tenants. Microsoft says that these legacy methods “no longer provide sufficient support for organizations’ response to threats against email data.”

Both are authentication methods originating from on-premises environments. Microsoft wants to remove as many legacy authentication methods as it can from Microsoft 365. This is part of Microsoft’s Secure Future Initiative, launched by Brad Smith in November 2023. Since then Microsoft has experienced the Midnight Blizzard attack and upped the ante in terms of withdrawing legacy authentication whenever possible, like the withdrawal of Application Impersonation for Exchange Web Services (EWS) announced in March 2024.

The replacement is a technology called Nested App Authentication (NAA), announced in preview on April 9, 2024 (Microsoft also posted to the Technical Community, but it was easy to miss). According to Microsoft, “NAA provides simpler authentication and top tier identity protection through APIs designed specifically for add-ins in Office hosts.”

The Impact on Outlook Add-in Developers

Microsoft’s developer blog makes it seem simple to adopt NAA, listing five steps:

• Register an Entra ID application for use with the add-in. The application will hold consent for the Graph permissions needed by the add-in.
• Update redirect URIs to support trusted brokers.
• Update the add-in’s MSAL.js configuration to allow native bridging.
• Add a fall-back authentication method.
• Test the add-in.

However, the simplicity of Microsoft’s approach understates the work they expect developers of Outlook add-ins will do:

• Review their Outlook integrated add-ins to identify where legacy authentication is used.
• Switch from Exchange user identity tokens and callback tokens to use NAA. The big advantage delivered by NAA is that it’s integrated with Entra ID and supports its advanced set of authentication capabilities.
• Use Graph APIs to access Exchange Online data instead of EWS and the Outlook REST API. Microsoft has already announced that they will block access for EWS to Exchange Online from October 2026.
• Test with multiple versions of Outlook. Microsoft is due to support the classic Outlook client until 2029.
• Contact customers who use the older versions of the add-ins.
• Deliver production-quality code to customers.

Even with help from something like GitHub Copilot, there’s a significant amount of work here. NAA is only just in preview, so a limited amount of practical experience exists of its use with add-ins. Perhaps Microsoft will reveal more information at the Build Conference next week.

Equipped with knowledge or not, the work must be done before Microsoft turns off the legacy authentication methods at a so far indeterminate date sometime in October 2024. The change only affects Exchange Online. Outlook add-ins can continue to use the legacy authentication methods to connect to Exchange on-premises servers. Of course, this creates a further complication for developers who create add-ins used hybrid environments because their code must be able to handle connections to on-premises and cloud servers.

Reviewing Personal Use of Outlook Add-ins

I don’t use many Outlook add-ins myself, and those that I do are produced by Microsoft (Figure 1). I assume that Microsoft will take care of these add-ins in due course.

A quick scan around the internet reveals the presence of many Outlook add-ins created by third parties (here’s an example). I’m not quite as sanguine that all the third party add-ins will have quite the same smooth upgrade. If you’re a tenant administrator, it’s a good idea to ask people what add-ins they use and start to build a list of add-ins in active use.

A Better Future

Everyone wants better security, and we currently suffer from the effects of using technology developed for use in on-premises environments in the more challenging world of cloud systems. Over the long terms, there’s no doubt that technologies like NAA and the Graph are the right way to go will help close holes that attackers could potentially exploit.

The big problem is lack of time. October 2024 will come very quickly and if tenants don’t know that they need to update Outlook add-ins, they’re going to get a hell of a shock when Microsoft disables the legacy authentication methods and add-ins cannot connect to Exchange Online. I’m not sure that every developer reads Microsoft’s developer blog diligently, so it’s entirely possible that some add-ins won’t receive the attention they need before the big turn-off. Allied to the inability to audit the use of Outlook add-ins within a tenant and all the components of a big mess are coming together. I hope that I’m wrong.

Learn about using 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.

Removing the Share to Teams Outlook Add-in

I’ve never had more than a passing relationship with Microsoft 365 integrated apps (Figure 1). The most I have done is deploy some Outlook add-ins to Exchange Online mailboxes like the Message Header Analyzer.

All of which meant that I probably wasn’t the best person to ask how to remove the Share to Teams Outlook add-in for selected mailboxes. The Share to Teams add-in allows an Outlook user to post a message from Outlook to a one-to-one or group chat or to create a new conversation in a team channel (Figure 2).

Essentially, the add-on signs into Teams for the user and posts the message using a Graph API request. The add-on only works for the user’s home tenant. You can’t use it to post as a guest member to a host tenant. I quite like the add-in but admit that I don’t use it very often. At this point, Share to Teams seems like something that Microsoft had to develop to help people move from email-centric work habits to the chat-based nature of Teams.

Whether Share to Teams helped very much is an open question, but its existence was probably enough to reassure people that it is possible to send information to and from between Outlook and Teams, which has an equivalent Share to Outlook feature to transmit messages in the opposite direction.

Exchange Online App Management Cmdlets

Some research revealed that PowerShell offers a viable solution. The Exchange Online management module contains cmdlets to create, list, remove, and disable apps. For instance, the Get-App cmdlet reveals details of the installed apps for a mailbox:

Get-App -Mailbox lotte.vetler | Format-Table AppId, DisplayName, ProviderName

AppId                                DisplayName             ProviderName
-----                                -----------             ------------
131a8b55-bd40-4fec-b2e6-d68bf5929976 Translator              Microsoft
afde34e6-58a4-4122-8a52-ef402180a878 Polls                   Microsoft Corporation
545d8236-721a-468f-85d8-254eca7cb0da Share to Teams          Microsoft
6b47614e-0125-454b-9f76-bd5aef85ac7b Send to OneNote         Microsoft Corporation
fe93bfe1-7947-460a-a5e0-7a5906b51360 Viva Insights           Microsoft
62916641-fc48-44ae-a2a3-163811f1c945 Message Header Analyzer Stephen Griffin
6046742c-3aee-485e-a4ac-92ab7199db2e Report Message          Microsoft Corporation
c61bb978-adb2-4344-abe9-d599aa75704f EmailTranslator V1.1    Avishkaram
f60b8ac7-c3e3-4e42-8dad-e4e1fea59ff7 Action Items            Microsoft
7a774f0c-7a6f-11e0-85ad-07fb4824019b Bing Maps               Microsoft
a216ceed-7791-4635-a752-5a4ac0a5eb93 My Templates            Microsoft
bc13b9d0-5ba2-446a-956b-c583bdc94d5e Suggested Meetings      Microsoft
d39dee0e-fdc3-4015-af8d-94d4d49294b3 Unsubscribe             Microsoft

The AppId identifier is important because it’s the required value to pass to tell the cmdlet which app to manage.

Scripting Disabling an App

The first task is to identify the set of mailboxes to process. I don’t know why the desire existed to remove the Share to Teams add-in. Perhaps it’s because a division within the company has decided that their users should not use the add-in. Maybe some senior manager took a dislike to the add-in. Or maybe it’s the result of a decision to separate Outlook and Teams communications. For whatever reason, it’s still important to find mailboxes to process. You can do this with the Get-ExoMailbox cmdlet.

Once the targets are identified, it’s a matter of looping through the mailboxes to use the Disable-App cmdlet to turn off the add-in for each mailbox. This code fetches a set of mailboxes based on a value in a custom attribute and checks each to extract the set of enabled apps. If that set includes the Share to Teams app, the Disable-App cmdlet turns Share to Teams off.

$TargetAppId = "545d8236-721a-468f-85d8-254eca7cb0da"  # Id for the Share to Teams app
$TargetAppName = "Share to Teams"
[int]$RemovedApps = 0
[array]$Mbx = Get-ExoMailbox -Filter {CustomAttribute9 -eq 'NoApp'} -RecipientTypeDetails UserMailbox
ForEach ($M in $Mbx) {
    Write-Host ("Checking mailbox {0} for the {1} app" -f $M.displayName, $TargetAppName)
    [array]$InstalledApps = Get-App -Mailbox $M.Alias | `
         Where-Object {$_.Enabled -eq $true} | Select-Object -ExpandProperty AppId
    If ($InstalledApps -contains $TargetAppId) {
        Write-Host ("Disabling app for {0}" -f $M.displayName) -ForegroundColor Yellow
        Disable-App -Identity $TargetAppId -Mailbox $M.Alias -Confirm:$False 
        $RemovedApps++
    } Else {
        Write-Host ("App {0} not installed for {1}" -f $TargetAppName, $M.displayName)
    }
}
Write-Host ("Removed {0} instances of the {1} app from {2} scanned mailboxes" -f $RemovedApps, $TargetAppName, $Mbx.count)

Disabling Outlook Add-ins Isn’t Immediate

It usually takes several hours before Outlook picks up the newly disabled status for the add-in. The app data is cached within the service and refreshed periodically. That refresh must happen before clients can detect the change. There’s nothing you can do to accelerate the process, so consume some of your favorite beverage and chill out.

Learn more about how the Office 365 applications really work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Time to Consider How to Handle Outlook Add-Ins for New Clients

A recent Practical365.com article about user submissions of suspicious email caused me to think. Not about the proposal because it’s obvious that allowing people to report suspicious messages that Exchange Online delivers to their inboxes is a good idea.

After all, if someone receives an email that looks like malware, smells like phishing, and has a faint hint of spam, it’s probably not a good thing. And if it gets to a mailbox, it’s a failure of Exchange Online Protection (EOP) or whatever email cleansing service the message passed through en route. Reporting this kind of message to their administrator or Microsoft for further analysis is right and proper. Everyone benefits when Microsoft receives copies of messages that get past the EOP tests.

Customizable Notification Messages

The article explains how Exchange Online now allows organizations to customize the messages displayed when people report bad email. It’s a nice feature that allows organizations to reassure people that something happens when they take the time to report a problem. No one likes their efforts to disappear into a black hole. Figure 1 is an example of a customized message sent to people in my tenant when an administrator reviews a reported message. The format of the message contains corporate branding to reassure the recipient about its source.

The End of COM Add-ins

But the goodness of being able to create customized notification messages for reporting bad email is not what caused me to think. My attention was drawn to the assertion that the Report Message/Report Phish add-ins will stop working at some point in the future. These add-ins allow users to report messages as junk mail or phishing and have been around for a while. Their long-term replacement is a built-in Report message button that can report messages as either phishing or junk. In other words, a consolidation of add-ins.

At this point, you might wonder why I focus on such an arcane subject. Does it matter if Microsoft decides to replace some Outlook add-ins? Of course, it doesn’t, except when it’s a pointer to a change that might affect customer organizations and ISVs. The older Outlook (for Windows) add-in model is COM-based. Many such examples of these add-ins exist, whether built by ISVs or in-house.

Monarch and OWA Don’t Use COM

But Microsoft is heading to a common Outlook base, aka “One Outlook” or Project Monarch, with the aim of delivering a unified client on as many platforms as possible. The Monarch client is based on OWA and cannot use COM add-ins. Instead, the new Outlook add-in model uses JavaScript or HTML. Monarch is currently in preview with Office Insiders and, like OWA, receives frequent updates. We don’t know when Monarch will transition to become the next version of Outlook for Windows. Given the current state of play, this probably won’t happen in 2023. But 2024?

This brings me to the point of this note: Microsoft is updating its Outlook add-ins to move away from COM. Is the same happening for the add-ins created by ISVs or in-house development? With its knowledge of where the Outlook puck is going, Microsoft has first-mover advantage here, but the fact that it’s making the change should signal a warning to tenant administrators and architects that it’s time to understand what COM-based add-ins are in use and the plans to evolve them to work with the new Outlook, or even with today’s OWA client.

ISVs know what’s happening and will have plans to evolve their products. I wonder if the same attention is paid for in-house code. Given the longevity of the current Outlook for Windows architecture, it’s possible that some add-ins are in situ that no one wearing an administrator hat knows much about. It would be a shame if an obscure but necessary add-in surfaced to disrupt future deployment plans, so do yourself a favor and check now.

Keep up to date with developments like Project Monarch by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.