Apple Mail App Clients Might Need Upgrading for Modern Authentication

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 Client and Modern Authentication

The Apple email client for iOS 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 mail client 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).

Apple documentation about OAuth support in iOS for Exchange Online
Figure 1: Apple documentation about OAuth support in iOS for Exchange Online

The good thing is that Apple has done the work to make sure that its mail client 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 client 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).

Filtering the Azure AD sign-in logs to find legacy Exchange ActiveSync connections
Figure 2: Filtering the Azure AD sign-in logs to find legacy Exchange ActiveSync connections

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.

Details of an Azure AD sign-in record for an iOS device using modern authentication
Figure 3: Details of an Azure AD sign-in record for an iOS device using modern authentication

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).

Focusing in on iOS devices using Exchange ActiveSync
Figure 4: Focusing in on iOS devices using Exchange ActiveSync

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.

Apple's Service Principal registered in Azure AD to enable Exchange ActiveSync access
Figure 5: Apple’s Service Principal registered in Azure AD to enable Exchange ActiveSync access

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.

25 Replies to “Apple Mail App Clients Might Need Upgrading for Modern Authentication”

  1. Apple Internet Accounts app appears in times of iOS 14 if I remember correctly. And from the older one it was signed by Apple, so the developer name and app itself is valid for tenants which are set to allow only apps from trusted developers.

  2. In our tenant, modern auth is enabled now, basic auth is still allowed. I’ve removed the account from a users iphone and added it again. It still connects through Exchange ActiveSync. Can you “force” the Iphones to use modern auth?

      1. i did this with a test user and test iphone. after removing and adding the account to ios mail app, it’s still connecting through Exchange ActiveSync unfortunately. I’ll ask a small group of user to do it, and we’ll see if it works then.

      2. That’s interesting – the iOS mail app has code built into it to check if it should use modern authentication and use it if possible. If you can, please document your findings with the test group and let me know. I can pass the information on to some people who are extremely interested in this topic…

      3. Remember too that the phone will continue to use Exchange ActiveSync to connect to Exchange Online. The question is whether it is using modern authentication or basic authentication. The Azure AD sign-in data will tell you that.

      4. In such case, I also check if you have some MDM in place enforcing Legacy Auth (seen in project). Next, if it is inly Online or Hybrid where autodiscover or other pointing somewhere else (quite often when Hybrid components are without modern auth). And last also, if you have older phone which was setup before iOS 12 to delete records for 365 in KeyChain (offer basic sooner then it should be on fresh iOS 12 and newer).

      5. If you have an MDM in place, that’s certainly a fantastic way to apply modern authentication across the complete client set. Unfortunately, there are a bunch of tenants out there who don’t use MDM and (based on the numbers who read the articles telling about the deprecation of basic authentication) don’t know what will happen in October 2022. Hence the ongoing effort to educate and inform people…

      6. Hello Tony, I tested it again with another user. he has removed his email account and added it again, on a newer iphone. I can see a login from “Apple Internet Accounts” during the setup. After that, I can see new logins to ExchangeOnline using “Browser”. I can send you a screenshot if you’re interested.

      7. Yes. His logins are using “Browser” which is one of the two modern auth protocols that you can see in Azure AD sign-in logs.

      8. Hmmm… they should be under mobile clients. Can you share a screenshot on OneDrive and I will grab it and see if someone who might know what’s going on can say what’s happening.

        Are any clients configured to use modern authentication showing up under mobile clients?

      9. I think I’ve figured it out. The first sign in invokes a web page to get consent for access. Subsequent sign-ins appear under Mobile Apps and Desktop devices. I have updated the post with a new Figure 3 to show an example of such a record.

  3. Is there any reason your code sample uses Get-CASMailbox rather than Get-EXOCASMailbox? The latter may be faster and more efficient for larger tenants.

    1. No reason. You can use either.

      But… Get-ExoCASMailbox has a problem with the filter used to find mailboxes with device partnerships.

      Get-ExoCASMailbox : Error while querying REST service. HttpStatusCode=400
      ErrorMessage={“error”:{“code”:”BadRequest”,”message”:”Invalid filter clause”,”innererror”:{“message”:”Invalid filter
      clause”,”type”:”Microsoft.Exchange.Admin.OData.Core.ODataServiceException”}}}}
      At line:1 char:15
      + … rray]$Mbx = Get-ExoCASMailbox -Filter “HasActiveSyncDevicePartnership …

      I’ll tell the engineers.

      1. Change the following line:

        [array]$Mbx = Get-CASMailbox -Filter “HasActiveSyncDevicePartnership -eq ‘$true'” | Get-ExoMailbox

        …to the following and it should work:

        [array]$Mbx = Get-EXOCASMailbox -Filter “HasActiveSyncDevicePartnership -eq True” | Get-EXOMailbox

        The only change is modifying ‘$true’ to True. I’ll also tell the Engineering team about this behavior.

      2. This syntax also works…

        [array]$Mbx = Get-EXOCASMailbox -Filter “HasActiveSyncDevicePartnership -eq $True” | Get-EXOMailbox

  4. >>>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.

    I greatly prefer Outlook Mobile as well, but I find myself needing to configure iOS Mail for my users as well, because without the user’s Exchange contacts populating in the IOS Contacts app, Caller ID doesn’t work.

    I originally tried syncing Outlook Mobile contacts to the iPhone contacts, but since that’s only a one-way sync, users would inevitably create their contacts in iOS rather than Exchange. After a year of this I just gave up and decided to configure both iOS Mail and OM on all my devices.

  5. @Tony: I see that the api permissions granted to the IOS Account registration in your screen caps show the MS Graph API is used. I’ve just gone and given admin consent to IOS Account in my tenant and its using the Windows Azure Active Directory APIs – the old ones that are going to not be supported come June 2022.

    Can’t for the life of me see how i can flip that so the MS Graph is used instead. Even tried it on a temp office 365 trial tenant and had the same issue when i gave consent as an admin to the app being used.

    Anything google searches is throwing my way is not working – including have a standard user attempt to use the app initially and then giving admin consent to the consent request that come up with my admin account.

    Anyone got an ideas?

      1. Yep – don’t think I have much choice.

        And this is in 2 tenants – our main work one that has had IOS native mail clients being used for a number of years as well as an office 365 E5 trial tenant that had NEVER had IOS Accounts/Apple Internet Account registered until I connected and gave admin consent on the first attempt earlier today.

        Thanks anyway – off to deal with MS Support i guess.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.