Choice Remains Between Outlook Mobile and Exchange ActiveSync Clients

One of the most common questions I am asked concerns mobile email clients. Should Microsoft 365 tenants deploy and use Outlook Mobile or select a client based on the Exchange ActiveSync (EAS) API created by companies like Apple and Samsung instead? I’ve written about this topic before but it’s worth summarizing the current state of the art, so here goes.

OWA for Devices

Ten years ago, Microsoft jettisoned its focus on OWA as the premium client for mobile email connectivity. Trumpeted with some vigor at the 2014 Microsoft Exchange Conference in Austin, OWA for Devices, as the client was known, leveraged the engineering investment to create a high-quality browser-based client. Essentially, OWA for Devices was a wrapper around the full client to allow it to run using the native browser found in all mobile devices.

The OWA for Devices plan allowed Microsoft to bring a wide range of features to mobile devices that couldn’t be built on top of the EAS protocol. It’s worth remembering that Microsoft created EAS to compete with IMAP4 and POP3, so the feature set enabled through the EAS API is limited to basic email and calendaring.

The Acompli Effect

Technical difficulties, poor performance, and the feeling that Microsoft was trying to squeeze a heavyweight client designed for PC browsers into a mobile pot were the fault lines in the OWA for Devices strategy. If you can’t build technology, plan B is often to buy technology, and that led to the Acompli acquisition in late 2014.

Acompli’s signature feature was the focused inbox, or the ability to filter the most important messages into a separate Inbox (actually just a filtered view of Inbox contents). No mobile API supported the processing required to understand what messages were most important to a mailbox’s owner and filter those messages as new mail arrived in the mailbox. Acompli built the necessary infrastructure to copy mailbox contents from Exchange to build an online cache located in Amazon Web Services (AWS) to enable advanced email processing. The Acompli client connected to the processed cache and presented the filtered Inbox view to the user.

Acompli became Outlook Mobile for iOS and Android. The focused inbox became a feature loved or hated by hundreds of millions of users, and Microsoft replaced AWS with equivalent storage and processing based on Azure. Outlook Mobile still fetches cached mailbox content from Azure (now with a customizable synchronization period).

The new Outlook for Windows client exploits the same mechanism to deliver advanced functionality to users who connect to email servers via POP3 and IMAP4. These now-antique connection protocols don’t support many features used by modern email clients, so if the interim processing wasn’t done, the new Outlook for Windows would be restricted to a basic feature set. This simple but salient fact is ignored by those who protest when they discover that Microsoft synchronizes mailbox content to Azure for processing.

Outlook Mobile Continues to Lead

Coming back to the original question, I continue to recommend that organizations focus their mobile email client strategy on Outlook Mobile whenever possible. It’s a solid client for both iOS and Android that easily outpaces EAS-based clients in areas like email features and information protection. The client feature set continues to evolve, with the latest initiative being a new contact editor (MC746321, last updated 5 July 2024, Microsoft 365 roadmap item 384869). Apart from more reliable synchronization of contacts with Exchange Online, the new contact editor (Figure 1) supports enforcement of Intune policies such as preventing copy and pasting data in the editor. Outlook Mobile is better integrated into Intune device management too. In summary, from a corporate IT perspective, Outlook Mobile ticks many boxes. Its advantage over EAS clients in this area is unlikely to diminish.

But life isn’t always simple and corporate IT doesn’t always get to implement their choice. The era of BYOD means that an incredible number of devices connect to Microsoft 365, and it can be hard to move people from a native email client. Old habits die hard. However, I see an increased uptake in Outlook Mobile usage, possibly because features like sensitivity labels have rolled out in more tenants. My view is anecdotal and based on a limited set of data, but it seems like that’s the way things are going ten years after Microsoft choose Acompli as their new mobile email client.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

October 1 Marks the Start

On May 3, Microsoft published its May update describing progress toward their goal of removing basic authentication for seven email connection protocols starting in October 2022. With 150 days to go, Microsoft wants tenants to make sure that they’re prepared for the big turnoff.

Update (September 1): Microsoft is granting tenants the ability to get a three-month extension before retiring basic authentication. See this article for more detail. January 1, 2023 is the new drop-dead date.

By now, there should be no need to rehearse the logic behind the move. Basic authentication for email is a major vector for the compromise of user accounts. Attackers use techniques like password sprays to penetrate accounts using the flimsy protection afforded by basic authentication and proceed to wreak havoc. Business email compromise (BEC) leading to financial loss is only one of the joys available following account penetrations.

Five Big Points to Understand

Among the nuggets in Microsoft’s post, I noted five important points:

• They have already disabled basic authentication in millions of tenants that were not using the affected protocols. “Millions” is the keyword here. It demonstrates the scale and scope of this effort and the size of Exchange Online.
• Disabling of basic authentication for Exchange Web Services (EWS), Remote PowerShell, POP3, IMAP4, MAPI over RPC, Exchange ActiveSync, and the Exchange Offline Address Book (OAB) commences on October 1. Remember the scale of Exchange Online? It will take time for Microsoft to work through all the Office 365 data center regions to turn off the protocols for millions of tenants. They anticipate completion at the end of 2022, but protocol disablement could come to your tenant at any time after October 1, so you need to be prepared.
• No one gets to vote when Microsoft blocks basic authentication for their tenant. Selection is random. It just happens.
• SMTP AUTH is an exception and support of basic authentication for this protocol continues for now. But that’s no reason to ignore the bright lights signaling that Microsoft is likely to disable basic authentication for SMTP AUTH soon. Microsoft isn’t saying when they will proceed, but you should start to upgrade scripts and devices which send email using SMTP AUTH connections to Exchange Online as soon as possible.
• Apple devices running recent operating systems that use Exchange ActiveSync to connect the native Apple Mail app to Exchange Online mailboxes can use modern authentication. However, the configuration of the connection to Exchange must specify modern authentication. If a new device copies an existing configuration from an old device (for example, when someone updates an old iPhone to the latest model), the configuration might specify basic authentication. These devices won’t be able to connect to Exchange Online after Microsoft blocks basic authentication. Read this article for more information and consider auditing Apple device connections to identify the devices still using basic authentication.

Use Authentication Policies to Block Protocols

Another important point is that authentication policies are available to block basic authentication for selected protocols now. You can be proactive and block protocols like POP3 and IMAP4 that attackers love using to compromise accounts. It’s a good step to take to stop people using old and vulnerable clients.

A tenant administrator might be lulled into a false sense of security because they’ve deployed Azure AD conditional access policies to protect user accounts, or because they’ve disabled protocols like POP3 and IMAP4 for mailboxes through the Set-CasMailbox cmdlet. These are good steps to take, but they only kick on after an account successfully authenticates – and that might be too late. Blocking protocols with authentication policies stops attackers from authenticating (and knowing that they have valid credentials), meaning that attempted attacks come to a crashing halt.

Time to Get Going

When this post appears, it will be 147 days until 1 October. Three days have slipped away since Microsoft posted its blog. If you’ve had other things on your plate and haven’t progressed the preparation for the big basic authentication turn-off, it’s time to get going.

Make sure that you’re not surprised about changes that appear inside Exchange Online and other Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Ongoing Threat Underlines Need to Remove Basic Authentication from Exchange Online

By now, the realization that Microsoft will remove basic authentication for many email connection protocols in October 2022 should have sunk into the minds of everyone involved in running Exchange Online. It’s a big project which will require upgrading email clients to use modern authentication to connect to mailboxes. The continuing activities of groups using password spray attacks against Office 365 tenants such as DEV-0343 (reported by the Microsoft Threat Intelligence Center on October 11) underline the real threat which exists for accounts when basic authentication is supported for protocols like Exchange ActiveSync. The report also notes that “Office 365 accounts with multifactor authentication (MFA) enabled are resilient against password sprays.”

Apple iOS Mail App and Modern Authentication

The Apple iOS mail app is a popular email client for both Exchange Server and Exchange Online. Despite being an iPhone user, I prefer Outlook mobile. It’s a better mail client for Exchange Online as it supports features like delegated access, sensitivity labels, and shared mailboxes.

The Apple iOS mail app uses EAS to connect to Exchange, and EAS is one of the protocols that won’t support basic authentication after October 2022. Checking Apple’s documentation, we learn that Apple has made arrangements to upgrade devices running iOS 14 and iPadOS 14 to use modern authentication automatically (Figure 1).

The good thing is that Apple has done the work to make sure that the iOS mail client (and its MacOS counterpart) can use modern authentication to connect to Exchange Online. Everything seems sunny, until you learn that some of the information presented in the documentation is incorrect (Apple has been informed and is apparently in the process of refreshing their content. In a nutshell, the correct position is that if an account for Exchange was created on an iOS or iPadOS email app before Apple added support for OAuth (iOS 12), the connection uses basic authentication. This is logical because basic authentication was the only connection possible at the time.

To move to modern authentication, users must remove their Exchange account from the mail app configuration and re-add Exchange to the mail app. When the mail app running on iOS 12 or above adds an Exchange account, it detects that modern authentication is available and will use it. It’s not enough to upgrade to the latest version of iOS as this action preserves the mail app configuration. Likewise, if you buy a new iOS device and restore your settings on that device from an iCloud backup of the old device, the restore preserves the mail app configuration.

Azure AD Sign in Logs and EAS

Some organizations block basic authentication using Azure AD conditional access policies and Microsoft has already blocked basic authentication for connection protocols in some tenants. If either scenario applies, you don’t need to worry because clients using EAS connections must use modern authentication.

However, if your organization currently allows basic authentication for EAS, it’s a good idea to identify Apple devices using EAS to understand if some action is required before Microsoft flips the switch in October 2022. No one wants to be handling a bunch of calls from annoyed users who suddenly discover that they can’t get to their mailbox.

One way of identifying problem connections is to filter the Azure AD sign in log to find records of connections made using Exchange ActiveSync (Figure 2).

The sign-in data only goes back 30 days, but it is very useful in proving the need for users to remove and readd Exchange to the iOS mail app to enable modern authentication. For instance, if you follow these steps, you can see a change in EAS connection when accounts sign in:

• Find a user who shows up with a legacy EAS connection.
• Have them remove their Exchange Online mailbox from the iOS mail app (using IOS 12 or later) and readd the mailbox to the mail app.
• Wait 30 minutes or so and check the sign-in data. There should be no new legacy EAS connections for the account because the iOS mail app now uses modern authentication.

When iOS devices use modern authentication, the Azure AD sign in records will appear under the Mobile Apps and Desktop clients category. Figure 3 shows an example of a sign-in record using modern authentication for an iPhone.

It’s possible that you might see the first sign-in after changing authentication modes logged as a browser. This is likely caused by the use of a web page to gather consent for access.

Device Partnerships and Registered Devices

Sign in logs are informative about who uses EAS (or other legacy protocols) to connect. We can expand the data by interrogating Exchange to discover the characteristics of the iOS devices used to connect. To allow for perform basic mobile device Sign in data tells you who uses EAS (or other legacy protocols) to connect. To allow for perform basic mobile device management, Exchange registers mobile devices used to connect to mailboxes. PowerShell can extract data about devices known to Exchange to better understand the usage of iOS devices. This data tells us more about the kind of devices used, their operating system, and when they first synchronized. The last is a critical piece of information.

The first step is to look for mailboxes with a device partnership. When a user connects their mailbox to a mobile device with EAS, it creates a device partnership (a link between the mailbox and mobile devices). You can find mailboxes with device partnerships using the Get-ExoCASMailbox cmdlet.

Exchange Online doesn’t clean up details of obsolete device partnerships, so there’s likely some debris to be filtered. I found mailboxes with device partnerships going back to iPhone 6s models which first synchronized with Exchange in October 2015.

The current iteration of Outlook mobile doesn’t use device partnerships. However, Outlook mobile does register mobile devices used with mailboxes, including entries for when Outlook mobile connects to shared mailboxes.

Finding Affected Apple Devices

The basic approach to retrieve information about mobile device usage with PowerShell is:

• Find the set of mailboxes to examine.
• For each mailbox, see if it has any registered mobile devices.
• For each mobile device, retrieve the statistics for the device’s interaction with Exchange (like the status of the last synchronization).

This code does the job. Finding mailboxes with Get-ExoCASMailbox returns only devices with device partnerships; if you use Get-ExoMailbox, you’ll process mailboxes both with and without device partnerships. The data extracted includes both Apple and Android devices. We’ll apply a filter later to refine the items for iOS clients which deserve investigation, but it’s good to have the full data set available for reporting and other purposes.

# Extract Exchange Online mobile device information
$Report = [System.Collections.Generic.List[Object]]::new() 
Write-Host "Finding mailboxes with EAS device partnerships..."
[array]$Mbx = Get-EXOCASMailbox -Filter “HasActiveSyncDevicePartnership -eq $True” | Get-EXOMailbox
# to check all mailboxes use
# [array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
If ($Mbx.Count -eq 0) { Write-Host "No mailboxes with EAS partnerships found - exiting" ; break }
ForEach ($M in $Mbx) {
   Write-Host "Processing devices for" $M.DisplayName
   [array]$Devices = Get-MobileDevice -Mailbox $M.UserPrincipalName
   If ($Devices.Count -gt 0) { 
    ForEach ($Device in $Devices) {
     If ($Device.DeviceType -ne "TestActiveSyncConnectivity") { 
      $DeviceStats = Get-MobileDeviceStatistics -Identity $Device.Guid.toString()
      $DaysSince = "N/A" # Compute number of days since last successful synchonization
      If ([string]::IsNullOrWhiteSpace($DeviceStats.LastSuccessSync) -eq $False) {
         $DaysSince = (New-TimeSpan $DeviceStats.LastSuccessSync).Days }
      $ReportLine = [PSCustomObject]@{
         Mailbox        = $M.UserPrincipalName
         Name           = $M.DisplayName
         "Device Name"  = $Device.FriendlyName
         "Device OS"    = $Device.DeviceOS
         "Device Type"  = $Device.DeviceType
         "Device Model" = $DeviceStats.DeviceModel
         "Device UA"    = $DeviceStats.DeviceUserAgent
         "Device ID"    = $DeviceStats.DeviceId
         "Client"       = $DeviceStats.ClientType
         "Version"      = $Device.ClientVersion
         "First Sync"   = $Device.FirstSyncTime
         "Last Sync"    = $DeviceStats.LastSuccessSync 
         "Days Since"   = $DaysSince }
     $Report.Add($ReportLine) } # End if
    } # End Foreach Devices
   } # End if
} # End Foreach Mailbox

To refine the set, we look for records logged for the EAS client. It’s also a good idea to ignore devices that have not synchronized in a while as these records might be for obsolete devices that the user has replaced. For example, a filter matching for devices running the EAS client with a successful synchronization less than or equal to 60 days ago with a device operating system like “iOS” will produce a set of records for iOS devices:

# Filter for iOS devices
[array]$EASDevices = $Report | ? {$_.Client -eq "EAS" -and $_."Days Since" -le 60 -and $_."Device OS" -like "*iOS*"}

You can then export the data to a CSV file or view it with Out-GridView to understand how many devices you need to investigate (Figure 4).

Apple released iOS 12 to customers on September 17, 2018. Any device which first synchronized with Exchange Online before that date uses basic authentication (look at the “First Sync” field in the report). If a user configured an iOS device running iOS 12 or later after that date, they should use modern authentication. Any Microsoft 365 account configured for multi-factor authentication uses modern authentication.

Apple’s iOS Accounts App

Using modern authentication with Apple devices requires an Azure AD service principal (enterprise app) named iOS accounts. Apple uses the service principal to gain consent to retrieve account information and access user mailboxes with EAS with the Microsoft Graph APIs (Figure 5). The first time an iOS device attempts to use OAuth for authentication, the process creates the service principal in Azure AD and seeks consent for the permissions used to access data. Unless the organization allows users to consent to grant permissions to apps (a really bad idea), an administrator must grant consent. The administrator consent covers all users in the organization.

You can also check for the presence of the app using PowerShell. As shown in Figure 3, the app name is “iOS accounts.” In other tenants, I know that the app name is “Apple Internet Accounts”. I have no knowledge of why two names are used, but you can check both by looking for the application identifier, which is the same in both cases:

Get-AzureADServicePrincipal -All $True | ? {$_.AppId -eq "f8d98a96-0999-43f5-8af3-69971c7bb423" }
ObjectId                             AppId                                DisplayName
--------                             -----                                -----------
666b66b2-daae-482c-b844-857a7977c327 f8d98a96-0999-43f5-8af3-69971c7bb423 iOS Accounts

A Point on the Road to Modern Authentication

Reporting usage of Apple devices with Exchange Online mailboxes is a starting point for investigation rather than a definitive set of accounts to update. Combining analysis of Azure AD data with information about iOS devices first synchronized with Exchange Online should create a list of accounts for you to check.

Dealing with mobile devices is just one of the bumps on the road to eliminate basic authentication and its inherent weaknesses against attacks. It’s nice to have some data to begin the work to prepare mobile devices now using basic authentication for the brave new world of modern authentication. And remember, it’s not just iOS; all email clients which use EAS should be examined to make sure that they can use modern authentication.

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new development as they happen.

Covid-19 Changing the Game

We live in fast-changing times. The results of the Covid-19 pandemic are being felt in many ways. Many people are working from home, conferences are being rescheduled until next year or going virtual, and Microsoft is being forced to reschedule planned developments in Office 365. Some things, like increasing the membership limit for Teams to 10,000 are being accelerated. Others, like the plan to remove basic authentication for five Exchange Online connection protocols, are being pushed out.

Basic Authentication is Still Bad

Basic authentication is bad for Exchange Online because it is a vulnerability often used as an attack vector. I strongly supported the original plan to remove basic authentication for ActiveSync, PowerShell, Exchange Web Service, and especially POP3 and IMAP4 in October 2020.

All the signs from Microsoft were that the Exchange product group wanted to make this happen and would hold the line. But pandemics have a funny habit of changing things, and so the product group has been forced to postpone removing basic authentication for the famous five protocols until some time in the second half of 2021.

Second Half of 2021

The lack of a definite target date is because no one know when the world will resume normal working. No doubt Microsoft wants to set a date that’s sooner rather than later, but for now July 1, 2021 is a good target date for planning.

In the meantime, new Office 365 tenants won’t get the chance to develop a bad habit because Microsoft is disabling basic authentication for the five protocols by default in those tenants. And in October 2020, they’ll get some satisfaction by disabling the protocols in tenants with no recorded use of basic authentication (in other words, Microsoft’s telemetry only records connections using modern authentication in the tenant).

Updates Coming for Affected Protocols

Updated 30 April 2020:

Microsoft is rolling out support for OAuth 2.0 support for SMTP AUTH and IMAP4 to allow developers to upgrade clients that use these now ancient (but beloved in parts) protocols. Support for POP3 is also in the works.

OAuth support is especially important for SMTP AUTH connections (used by applications and appliances to send email via Exchange Online). Although I can see how programmers will update POP3 and IMAP4 email clients to keep them working with Exchange Online, I have a harder job imagining how device manufacturers will get to update all the multi-function devices that send email like job completion notifications, Which is why Microsoft is holding to the line that they don’t plan to disable SMTP AUTH (for now).

Remote PowerShell will also be updated, and anyone using PowerShell to work with Exchange Online today is advised to start using the Exchange Online Management module, which supports MFA and OAuth. More work is needed to allow PowerShell scripts to run in unattended mode. That’s expected to appear in a future update for the module quite soon.

The Podcast Blues

The funny thing is that I was sure in my own mind that this would not happen and said so quite passionately when Paul Robichaux and I recorded episode 18 of our Office 365 Exposed podcast last night. I’ll have to see if Paul can edit those words out as he tweaks the recording for release…

Tracking dates is hard, especially inside an environment like Office 365 changes all the time. Subscribe to the Office 365 for IT Pros eBook and let us do the heavy lifting of date checking.

Basic Auth is Really Dead

Microsoft’s message to Exchange Online administrators has been consistent for months: Basic Auth is dead for Exchange connections. Well, maybe as in Monty Python’s Spamalot, Basic Auth “is not dead yet,” but it’s well on the way there. Microsoft still plans to turn off basic auth for seven protocols, including Exchange Web Services, Exchange ActiveSync, POP3, IMAP4, and Remote PowerShell on October 13, 2020.

Gathering Data About Basic Auth Connections

In an informative February 25 post, Microsoft sought to assuage the fears of some customers that applications and devices will cease working and won’t be able to connect to Exchange Online. One piece of good news is Microsoft’s decision to remove the requirement for an Azure Active Directory premium license to see the Sign-in report in the Azure AD portal. Although a tenant can generate a large amount of sign-in data over the seven-day rolling window used by the report, it’s easy to apply a filter to focus on the problematic sign-ins that still use basic auth (Figure 1).

I generated a batch of basic auth connections by signing into PowerShell without multi-factor authentication. The report picked up the sign-ins but didn’t identify them as originating from PowerShell (no user agent string reported).

Microsoft’s advice is to download the sign-in data to Excel and use its filtering and grouping capabilities to interrogate and understand your tenant’s risk profile due to basic auth. Understanding where basic auth connections originate, the applications involved, and the accounts used are of great assistance when building conditional access policies to block traffic.

Although some extra detective work might be needed to understand exactly where traffic comes from, the sign-in report is a useful tool to highlight the volume of basic auth connections that exist in a tenant and who’s responsible for those connections.

Upgrade Outlook

Microsoft took the opportunity to update Office 365 tenants about common clients and what needs to be done to keep connections going after October 13.

Outlook desktop (Windows and Mac) uses Exchange Web Services to connect to services like AutoDiscover, so if you have old Outlook clients connected to Exchange Online that use Basic Auth, those clients need to be upgraded before October 2020 or they’ll stop working. In some respects, this might be a very good thing in forcing the upgrade to modern Outlook clients. My advice is to avoid Outlook 2013, which is now quite an old client, and move users to Outlook 2016 at a minimum.

Check the Tenant Exchange Online Configuration

It’s possible that some Office 365 tenants are still configured to use basic auth, especially if the tenant was created before August 1, 2017 and no one switched the Exchange Online configuration over to use modern authentication. If you see a lot of basic auth connections reported and you know that the Outlook client base is relatively new, it’s worth checking the value of the OAuth2ClientProfileEnabled setting in the configuration. This should be True to instruct Outlook 2013 and later clients to connect with modern authentication:

Get-OrganizationConfig | Format-Table Name, OAuth2ClientProfileEnabled -AutoSize

Name                              OAuth2ClientProfileEnabled
----                              --------------------------
Office365itpros.onmicrosoft.com                         True

If the value is False, you can update the configuration by running the Set-OrganizationConfig cmdlet and set OAuth2ClientProfileEnabled to $True.

Updating the configuration will affect all clients connecting to the tenant. It’s wise to understand the connection profile for clients before you switch – but do so before October.

IMAP4 and POP3

Microsoft says that they have completed work on modern authentication for these obsolete access protocols and are rolling out the code within Exchange Online. They make the point that modern authentication has been available for IMAP4 in Outlook.com for some years, which begs the question why it’s taken so long to appear in the commercial service.

Documentation for developers is being completed, which will allow companies who write the IMAP4 and POP3 clients people use to connect to Exchange Online mailboxes to upgrade their code before October.

Some work will be needed to test and deploy updated clients. With that in mind, the question must be asked if it is time to retire these protocols and use something more modern. Remember, IMAP4 and POP3 were created at a time when a separate protocol was needed (SMTP) to send messages. These protocols can only download messages. OWA is a good replacement for PCs while Outlook Mobile should replace mobile clients that use IMAP4 and POP3.

I don’t underestimate the pain and disruption caused when users are forced to switch clients, but we have arrived at a crunch point where the need for security trumps personal preference for antiquated protocols.

SMTP

Microsoft says that they are nearly finished work to implement modern authentication for SMTP. When Microsoft switches off basic auth for SMTP, this is likely to disrupt connectivity for apps which use SMTP to access email. For now, Microsoft is not changing SMTP AUTH connections because of the impact on devices which use these connections to send email. It is unclear how many manufacturers would be able to upgrade the software running on these devices to use modern authentication, especially for older devices.

PowerShell

Lots of PowerShell scripts that automate important processes run with basic auth. Microsoft’s plan for non-interactive scripts is to support certificate-based authentication to replace passwords passed to scripts via strings included in the script or read in from a text file. The new REST-based Exchange Online management module helps (especially with the latest update), but it only offers replacements for nine of the hundreds of Exchange cmdlets.

Remember that many scripts used with Office 365 interact with multiple endpoints (Exchange Online, SharePoint Online, Teams, Azure Active Directory, and so on). The work to move non-interactive scripts away from basic auth to modern authentication should not be underestimated.

Work to Do

October 13, 2020 seems like a long time away. It is, unless you’ve got multiple client families and devices using basic auth to connect to Exchange Online now. If that’s the case, work needs to happen now. Unless of course you want to see the flow of email stop dead when basic auth is eradicated.

The Office 365 for IT Pros eBook contains lots of good advice about Exchange Online, SharePoint Online, Planner, OneDrive for Business, Teams, and many other topics. Subscribe to receive monthly updates with the most current advice and guidance.

Microsoft Announces Deprecation of Basic Auth for Multiple Connection Protocols

Following the introduction of protocol authentication policies for Exchange Online last year (also available for Exchange 2019), the Exchange development group has moved to reduce the attack surface available to hackers by announcing the deprecation of basic auth connections for a set of mailbox protocols from October 2020. The affected protocols are:

• Exchange Web Services (previously announced in July 2019).
• Exchange ActiveSync (EAS).
• IMAP4.
• POP3.
• Remote PowerShell.

Deprecation is due to happen on October 13, 2020. The usual approach inside Office 365 is that the cut-off doesn’t happen immediately but can occur at any point without warning after the announced date. When the axe descends, clients running any of the listed protocols won’t be able to connect to Exchange Online using basic auth. Customers therefore have just over a year to prepare for the change.

Update: Microsoft has pushed the deprecation date out to mid-2021.

The Challenge of Mobile Clients

The biggest issue is likely to be with mobile clients. Microsoft licenses ActiveSync (EAS) to many mobile device vendors to enable connectivity from clients like the iOS mail app to Exchange. Microsoft argues that it’s time for customers to move to clients that support modern authentication and point to Outlook Mobile for iOS and Android as the logical choice for anyone with an Exchange Online mailbox. The big advantage of Outlook Mobile is that you get more features delivered for these clients, such as the recent support delivered for dark mode and shared mailboxes.

Although it’s true that Outlook Mobile has more than 100 million users, the facts remains that this number counts both consumer and commercial customers and there’s way more Exchange Online mailboxes in use. The last active number for Office 365 seats was 180 million (April) and that’s likely to be past 200 million now. Given the mobile nature of email, roughly 50% of the Exchange Online community might use a client today that depends on basic auth for EAS, IMAP4, or POP3.

I’m sure Microsoft has been in touch with its EAS licensees with an update for the new connectivity rules. It’s then up to licensees to update the mail apps for their devices to support modern authentication (Apple already has for iOS 11 onward). However, just because a mail app proclaims its support for modern authentication, software must still be checked out against Office 365 to make sure that everything works as expected across all client versions on all device families (some folks have run into problems with the iOS app).

Time to Go for IMAP4 and POP3

Microsoft says that they will update their POP3 and IMAP4 connections to support modern authentication soon. This will help, but tenants will still have to validate that any IMAP4 and POP3 clients still in use can connect,. including applications where IMAP4 or POP3 is used to send messages. I recommend that tenants take the opportunity to move users on from these now-ancient email protocols to something that’s more secure and functional, even if it means ripping Thunderbird and other clients out of user hands. They’ll be better for the experience.

Upgrading to a more functional email client is one thing; upgrading an application that uses IMAP4 to fetch messages from Exchange Online is another. Microsoft has committed to update the IMAP4 protocol for Exchange Online to support OAuth and say that they will make an announcement when this support is available. Upgrading an application will involve code changes, so now’s a good time to collect a roster of applications that will need to be updated. On the other side of the coin, the SMTP AUTH protocol used by many applications and devices to send messages is not being changed.

Of course, if you feel adventurous, you could upgrade apps to use the Microsoft Graph REST API instead of IMAP4. I suspect that this won’t happen as the work involved is likely to be more onerous (especially testing) than upgrading an IMAP4 connection to support modern authentication.

Remote PowerShell

Exchange has used Remote PowerShell since Exchange 2010 (more software to hit the ropes in October 2020) and people are very accustomed to making remote connections to work with mailboxes and other Exchange objects through PowerShell. The issues involved in Remote PowerShell for Exchange Online are not limited to basic auth, but at least MFA-enabled connections are available.

Discovering Basic Auth Connections

Microsoft says that they will deliver a tool to allow Office 365 tenant administrators to discover who’s using basic auth to connect to their mailboxes. No details of the tool are yet available.

A Good Change

Overall, getting rid of insecure basic auth connections is a very good idea. The only downside is the work that Office 365 tenants must do to identify what usage basic auth has inside their environment and then come up with plans to remove the dependency. At least there’s plenty of time to do the work.

For more information about Exchange Online, read the Office 365 for IT Pros eBook. Our earliest editions focused on Exchange Online, but we’ve got much broader coverage across Office 365 now.