Microsoft Plans Automatic Upgrade of Apple Mail App Profiles

Upgrade Mail App Profiles for Modern Authentication

Last year I wrote about the need to upgrade the Apple iOS Mail app on some devices to deal with Microsoft’s phasing out of basic authentication. This isn’t because the Apple client doesn’t know how to support OAuth authentication flows (the necessary code is available from iOS 12 on). Instead, it’s because the user profiles for the Mail app are old and specify basic authentication. In fact, because Apple makes it so easy to transfer data and settings from an old to a new device, they have faithfully transferred many old mail profiles to spanking new iPhone 11, 12, and 13 devices over the last few years.

Microsoft very badly wants to remove basic authentication for Exchange connection protocols. They’re making good progress. In line with their plan to remove basic authentication for all tenants on 1 October 2022, Microsoft has already disabled basic authentication in many Microsoft 365 tenants. In other tenants, where some protocols (like ActiveSync are actively using basic authentication), they are busily disabling unused protocols, like POP3 and IMAP4.

The SMTP AUTH protocol remains an exception to allow customers more time to upgrade devices and code which use the protocol to send email via Exchange Online. If you’ve got some PowerShell scripts that send emails, it’s time to upgrade them to use the Microsoft Graph API or the Microsoft Graph PowerShell SDK.

Starting the Upgrade

Today, Microsoft shared its plans to help Microsoft 365 tenants upgrade iOS and macOS devices with mail app profiles still configured for basic authentication. As you might expect, Apple devices are popular with the Microsoft 365 user base, and there could be tens of millions of devices that need to update their mail app profile.

Message center posts will appear over the next few days to inform tenant administrators what they should do. If you don’t see a notification in the Microsoft 365 message center, it means that Microsoft’s telemetry can’t detect the presence of any Apple devices in your tenant.

The ROPC Flow

Microsoft and Apple have cooperated to make the iOS mail app request a profile upgrade. Microsoft’s post says that an upcoming Apple iOS update will include the necessary code to invoke the ROPC workflow and make the switchover for iOS and iPadOS devices. A later update will handle MacOS.

Update (July 11): Apple has disclosed that the profile update will happen in an iOS 15.6 update.

The updates will happen in waves. When an upgrade wave kicks off, if a device detects that its mail app profile is set to use basic authentication, it invokes a processing flow called Resource Owner Password Credentials (ROPC). This is an OAuth 2.0 grant which takes advantage of the fact that the iOS clients have cached user credentials (username and password) to request OAuth credentials (access and refresh tokens).

If permitted, the ROPC flow signs in as the user to acquire the OAuth tokens. This happens silently, without user knowledge, and with no manual intervention required. It’s a terrific way to upgrade large quantities of clients without forcing users to recreate their mail profiles and resynchronize their mailbox. Although Microsoft’s documentation warns against using ROPC, this scenario is a good example of where the use of a seldom-deployed and warned-against mechanism is justified.

If everything goes to plan, the millions of Apple devices which connect to Exchange Online today via ActiveSync using basic authentication today will switch over to begin using modern authentication seamlessly (without disturbing users). And once clients start using modern authentication, other possibilities become available, like controlling device access through conditional access policies. It’s all goodness.

MDM Devices

An important exception is for Mobile Device Management (MDM) solutions. If you use an MDM to push a mail app profile to devices, the ROPC logic does not update the mail app profile. Microsoft decided that if an organization uses an MDM, it’s best to use the MDM to make the change to the mail app profile. Here are the steps to update the email app for iOS and iPadOS devices with Intune.

Time for Administrator Action

To allow automatic updates to happen, Microsoft 365 tenant administrators must act. Specifically, they must allow the upgrade magic to happen by granting consent for the Azure AD app used by Apple to gain access to user data and synchronize via ActiveSync. This app is created the first time an iOS or macOS device creates a profile using modern authentication. Alternatively, you can create the app by clicking the link provided by Microsoft in their blog. Part of the process is to grant administrator consent for the permissions needed by Apple to use the ROPC flow (Figure 1).

This consent overwrites any previous consent granted to the Apple app. The resulting set of permissions are what’s needed to allow both iOS and macOS mail clients to function.

If administrators don’t grant consent, they force users into a bad place. They will be prompted to consent when the device attempts to migrate their mail app profile. Some users might understand what to do, others might not. If consent is blocked, or the admin must approve consent, the device enters a no-man’s land where it’s stuck until consent becomes available (usually the admin relents).

Granting Consent to Allow the Flow to Work

Two ways are available to grant consent. The easiest method is to select Apple’s Azure AD in the Azure AD admin center and grant consent to allow the app to use the three Graph permissions it needs. By granting consent on behalf of the organization, Apple devices can access and synchronize email data.

For historical reasons, the name of the Azure AD app is either iOS accounts (as shown in Figure 2) or Apple Internet Accounts. In both cases, the app and its service principal have the same identifier (f8d98a96-0999-43f5-8af3-69971c7bb4230).

The delegated permissions (so apps run with a user present) are:

• EWS.AccessAsUser.All
• EAS.AccessAsUser.All.

The two permissions cover Exchange Web Services (macOS) and Exchange ActiveSync (iOS and iPadOS). Microsoft’s post explains that you might see different permissions in use and makes the point that this arises because of the different ways apps ask for permission. The important thing is to have sufficient permission in place to allow the ROPC flow to proceed without users seeing any dialogs prompting them for consent.

If you don’t want to use the Azure AD admin center, you can set the necessary consent through this link.

Granting consent across the organization is a single step to allow the ROPC flow to work without user intervention. However, many organizations do not like granting tenant-wide consent to applications in this manner. Instead, they prefer to define a set of Graph permissions that they are happy for users to consent to on an account-by-account basis.

Azure AD defines the permissions for which users can grant consent in the Consent and permissions section of the Azure AD admin center (Figure 3). Select the option to allow user consent for apps from verified publishers (this includes Apple) and then select the Permission classifications tab to add the necessary permissions.

Organizations can only allow users to consent to delegated permissions. Azure AD calls the selected permissions low-impact, but each tenant defines the set of permissions which meet this criterion, so you can add the three permissions required to allow ActiveSync to work (Figure 4).

Microsoft shows how to check that the right permissions are in place with PowerShell. Unhappily, they don’t explain what you want to see. In the example below, we use the Microsoft Graph PowerShell SDK to sign in with appropriate permissions to read app details from Azure AD. We then query the set of enterprise apps to find the Apple iOS Accounts app, and then check its permissions. The set of permissions include those for EAS and EWS, so it’s all good.

Connect-MgGraph -Scopes "Application.Read.All, Directory.Read.All"
Get-MgServicePrincipal -Filter "appId eq 'f8d98a96-0999-43f5-8af3-69971c7bb423'" | % {Get-MgOAuth2PermissionGrant -Filter "clientId eq '$($_.Id)' and consentType eq 'AllPrincipals'" } | Format-Table ConsentType, Scope

ConsentType   Scope
-----------   -----
AllPrincipals User.Read
AllPrincipals EAS.AccessAsUser.All EWS.AccessAsUser.All

If the necessary permissions are in place, you don’t need to do anything else.

Don’t Block Consent

Whatever you do, don’t block consent as it will degenerate the RPOC flow into flood of dialogs prompting users for consent they didn’t know they had to give. Everyone is concerned about tenant security, and no one likes giving consent to allow access to user data. However, a clear choice exists here. Give consent and your Apple devices can reconfigure their mail profiles to handle modern authentication with a minimum of fuss. The alternative is to not grant consent and prepare for a world of unhappiness for users and administrators alike.

Microsoft will disable basic authentication for Exchange Online connectivity protocols starting in and around 1 October 2022. That train has left the station and is hurdling along the line to your tenant. It’s up to you how to manage its arrival. Read the Microsoft blog, understand the consequences of the plans they have made with Apple, and then grant consent for the Apple app. You know it makes sense.