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.

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.

By now, everyone should be convinced that using basic authentication for connections to Exchange Online is a bad idea. Microsoft has been pushing to remove basic authentication for quite a while, with announcements at the Ignite 2019 conference setting the stage. At that time, Microsoft said they would remove support for:

• Exchange Web Services (EWS – following an earlier announcement in July 2019).
• Exchange ActiveSync (EAS).
• IMAP4.
• POP3.
• Remote PowerShell.

The logic for choosing these protocols is that they are the set most exploited by attackers. After clients replace basic authentication with modern authentication for connections, attackers have a lot less attack surface to target.

A Change in Plan

Microsoft’s original plan was to remove support for basic authentication using these protocols in October 2020. The Covid-19 pandemic interfered with the ability of many organizations to do the necessary preparation for the deprecation and in April 2020, Microsoft was forced to push the date out to mid-2021.

Now, Microsoft is changing its approach. The basic principles are:

• Expanding the set of protocols covered in the program.
• Disabling basic authentication when it’s not used.
• Leaving tenants who use basic authentication alone for the moment and giving 12 months’ notice for deprecation when the basic authentication removal program restarts.

Let’s dive into some detail.

Expanded Target Protocol Set

The set of protocols has increased to include:

• MAPI (Messaging Application Programming API): The API Exchange Server is built on.
• RPC (Remote Procedure Call). MAPI over RPC is known as Outlook Anywhere and uses basic authentication. MAPI over HTTP supports both basic or modern authentication.
• OAB (Offline Address Book).
• SMTP AUTH (see below).

Outlook desktop clients (Windows) already consume EWS to access information like free/busy data and MailTips. This change closes off potential vulnerabilities in Microsoft’s own client to align better with the work already done to support modern authentication IMAP4 and POP3 clients. There is no good reason for Outlook clients to connect to Exchange Online using anything but modern authentication. Microsoft is not including AutoDiscover in the protocol set. The logic here is that AutoDiscover only ever informs clients where to go to access user data; the protocol can never access user data, so it is of little use to attackers. Microsoft says that they will consider disabling basic authentication for AutoDiscover in the future, once the battle to eliminate basic authentication for the other protocols is won.

Use It or Lose It

Instead of a big-bang turn-off on a nominated date, Microsoft will disable basic authentication for protocols when tenants do not use this capability “to prevent potential misuse”. Microsoft notes that many organizations don’t realize what protocols are in active use, so they will measure the use of basic authentication within tenants and use that information to disable basic authentication for unused protocols. Tenants will receive a message center notification in the Microsoft 365 admin center 30 days before a protocol is blocked.

Extended Notice Before Blocks Descend

For an undefined period, basic authentication will not be disabled when it is in active use by tenants. Eventually, the period of tolerance for basic authentication will lapse and Microsoft will move into a more active closedown phase. However, Microsoft says they will provide at least 12 months’ notice to tenants before blocking basic authentication for protocols in active use.

SMTP AUTH

SMTP AUTH is the client submission protocol used by applications or devices to submit outbound email to Exchange for processing. Many PowerShell scripts use the Send-MailMessage cmdlet to send messages via SMTP AUTH. As noted in July 2020, Microsoft has already disabled SMTP AUTH for new tenants (don’t these folks send email via PowerShell?) and is now including SMTP AUTH in the overall program rather than handling it separately.

What Happens Next

If your organization uses the affected protocols, you need to build a plan to reduce and then remove the usage for basic authentication. This might involve client upgrades, software changes, and perhaps firmware upgrades to devices which connect to Exchange Online (notably to use SMTP AUTH). You’ll get a 12 month notice of deprecation when Microsoft restarts its basic authentication removal program.

If your organization doesn’t use the affected protocols, this fact will be picked up by Microsoft’s analysis and you’ll receive message center notifications to say that Microsoft is going to disable basic authentication for one or more protocols. Thirty days later, Microsoft will enforce the block. The potential exists that someone might overlook the notification, and in this case, Microsoft says that they are working on a self-service procedure to reenable protocols in the Microsoft 365 admin center. It’s a good idea to enable the integration between the message center and Planner to make sure you don’t miss important notifications.

In some respects, it’s sad that Microsoft has delayed removing basic authentication for vulnerable connection protocols. I suspect that the reason is rooted in analysis of telemetry from tenants around the world which concluded that implementing the block as planned in mid-2021 would be too disruptive. It’s easy to argue that Microsoft should plough ahead and make the change, but the consequences of blocking connections across many unprepared organizations might generate a severe interruption in service. Tenants would be less vulnerable to attack with the block in place, but stopping people from working is perhaps too big a price to pay for a general-purpose service.

Shifting dates like this is a great reminder of the value of a book with updated content to track developments. The Office 365 for IT Pros eBook covers updates so you don’t have to sweat.

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.