Microsoft and Apple Working Together to Improve Exchange Online Security

We’ve been working for some time with several partners to come up with ways to smoothly transition our many users from Basic authentication to something more secure: OAuth 2.0-based authentication, or ‘Modern authentication’ as we call it.

Today we’re delighted to take the next step along that journey by sharing the work we’ve been doing with Apple to help users of their Mail app switch from Basic auth to Modern auth. To leverage this work and help users make the switch, the Microsoft 365 tenant admin may need to take action to make this transition, so please read carefully.

Several years ago, before OAuth 2.0, Basic authentication was the most common method to connect, primarily because it’s easy to use and was widely supported. But today it’s one of the most common vectors for credential compromise and misuse.

Apple has supported OAuth in iOS and macOS clients for several years, so anyone setting up a new Exchange Online account in the Mail app on these devices should be configured to use Modern auth. The key here is “new.” An Exchange Online account uses Modern auth only if it were added to the device after OAuth support was added to the Mail app.

Even when you upgrade to a newer device, you might still be using Basic auth. When you restore a backup from an old device to a new device or use the built-in migration process to move your data and settings to a new device, your Mail settings will still be configured to use Basic auth.

The difficult challenge of changing the configuration of millions of users using millions of devices requires both the client and the server to work together to provide a smooth transition. So, Apple and Microsoft have worked together to build a solution for our mutual customers.

The solution to a smooth transition lies in OAuth support for something called the Resource Owner Password Credential (ROPC) grant. This grant allows an application to sign in the user by directly handling their password. Given the device already has the users credentials we can use this to our advantage in this one scenario.

Apple will be adding support for this grant and the associated workflow in an upcoming iOS update. A few days after a device is updated, the Mail app will use the credentials it already has in a new flow to authenticate to the Identity Provider (in this case, Azure Active Directory), receive OAuth access and refresh tokens in return, remove the stored Basic auth credentials from the device, and then reconfigure the settings on the account to use OAuth. From then on, the account uses OAuth to authenticate to Exchange Online, and the user doesn’t even have to know this happened.

This is a great benefit, especially if you have many users with many devices using Apple’s Mail app. There are, however, two challenges to making this flow seamless to the user: possible interruption from existing policies and obtaining consent.

Policy Interruption

The first challenge to make the flow seamless for users is when you have configured controls and policies that affect the ability for the Mail app to connect using OAuth. These might be Conditional Access rules and/or a requirement for multi-factor authentication. These things should be checked as they will prevent a seamless switchover. If the code detects user interaction is required, it will not be able to automatically and silently migrate to Modern auth. Instead, the user will receive a prompt to re-enter their password and the ‘normal’ OAuth flow will kick off. The user will be asked to enroll for MFA or use an existing MFA configuration. Assuming they can complete this process, the account will switch to using OAuth.

If you already have Apple Mail clients using OAuth (which you can verify using Azure AD Sign-In reports) then it’s possible your policies will already allow for a smooth transition. However, we encourage you to check them to be sure. You can do this by configuring a new account on an iOS device to see what the first-time setup experience looks like. If there’s more to it than entering a username and password (e.g., if the users need to enroll in MFA or they need to install additional software), that will potentially make this transition require input from your users, and you should communicate that to them now, before the update is applied.

Obtaining Consent

The second challenge is consent. OAuth requires consent to grant apps access to resources. There are essentially three ways to do this:

1. The user can consent (assuming the admin allows users to self-consent to apps)
2. The admin can consent on the user’s behalf
3. The user can request that the admin approve their consent request

In order to switch from Basic auth to Modern auth seamlessly, we’re encouraging all admins with Apple Mail users using Basic auth to grant consent to the Apple Mail app at the tenant level so that users aren’t individually prompted when the switch to Modern auth takes place.

Managed Devices

If you currently use a Mobile Device Management (MDM) solution, and the Mail app profile was pushed to the device, it will NOT be updated using this new ROPC logic. The decision was taken early on that if you use MDM, you probably don’t want anyone changing the device configuration without your consent. So, just use your MDM to make the change to Modern auth (ask your vendor if you don’t know how). Here are the steps for Intune managed iOS devices.

Admin Actions

In the next few days, we will be publishing a Message Center post to all tenants that have iOS/iPadOS Mail users that we know are using Basic auth, and the post will include the current state of admin consent for the Apple Mail client in their tenant. If you need to grant admin consent to enable a smooth transition to Modern auth, then the Message Center post will state that, and contain a link that will lead the admin through the admin consent process, enabling you to add that consent to your tenant. Global Admin, Application Admin, Cloud Application Admin, and Privileged Role Admin can all grant tenant-wide admin consent for delegated permissions.

There is no status or dialog when you complete the flow using the Message Center link; you’ll simply return to the admin center, but you can verify that the flow completed successfully.

There are two ways to check if anyone has granted consent for the Apple Mail app in your tenant: the Azure Portal and using PowerShell.

Let’s start with the Azure Portal.

1. In the left-hand pane of the Azure Active Directory admin center, select Enterprise applications.
2. Look for either Apple Internet Accounts or iOS Accounts entries in the application list (both names have been used over the life of the app, it’s the same app no matter the name). If it’s not there, no one has ever used the Apple Mail app with OAuth in your tenant. If it is there, click it.

Once you are looking at the Overview page of Apple/iOS entry, in the left hand pane, click Permissions.

If you have already granted admin consent, you’ll see entries when the Admin consent view is showing. If you have not granted admin consent yet, this list will be empty.

Now, there are two possible sets of admin consent permissions you might see. You might see ‘legacy’ Office 365 Exchange Online EWS and EAS permissions, or you might see the ‘new’ Microsoft Graph EWS and EAS permissions. Or you might see just EAS, or just EWS. Why the differences?

 

The simple explanation is there is currently a mismatch between the permissions the app asks for dynamically, and those configured in the Apple Mail app registration itself:

• If you see EAS Graph permissions and are logged in as an admin when you consented on your iOS device and checked the box for ‘And consent for my entire organization too’ – you’ll likely have the EAS Graph admin consent permissions showing.
• If you consented using the admin consent flow or used the big blue button in the Azure portal, you’ll see the Exchange Online permissions.
• If you did the same on macOS, you’ll see the EWS permissions (iOS uses ActiveSync (EAS), macOS uses Exchange Web Services (EWS) to connect to Exchange).

Is this an issue? No, not at all. It’s a result of Apple updating their apps with the new permissions before the app registration itself – and that at some point the app registration itself will have to be updated to match. It does not cause any issues, both permission sets are interchangeable at this point in time, so it’s something you can ignore.

Now, if you don’t see either, and the Admin consent list is empty, admin consent has not been granted. You can see if any users have granted consent themselves when you select the User consent view.

The nice thing here is you can grant admin consent yourself to the app, for the whole tenant, using the big blue “Grant admin consent…” button. That will kick off the admin consent flow, which is identical to what the link in the Message Center post will do. There will be only two dialogs (log in and the admin/organization consent confirmation) and then you’re done. As you should always with any consent dialog, pay close attention to the details and check for the verified publisher badge, and once happy, choose to Accept.

If you are super keen to grant consent right away to get it done, and have the right permissions – this link will do the same thing – the flow will ask you to authenticate, to accept the request, and then it will return you to the Microsoft 365 admin center.

As we showed above, you can use the Azure Portal to confirm consent was granted, but you can also use PowerShell. The AppId used by Apple client is f8d98a96-0999-43f5-8af3-69971c7bb423.

Using Microsoft Graph PowerShell (it requires the Microsoft.Graph.Applications and Microsoft.Graph.Identity.SignIns modules):

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'” }

Or you can do it using Azure AD PowerShell, where it requires just the AzureAD module:

Connect-AzureAD
Get-AzureADServicePrincipal -Filter “appId eq ‘f8d98a96-0999-43f5-8af3-69971c7bb423′” | Get-AzureADServicePrincipalOAuth2PermissionGrant -All $true | ? { $_.ConsentType -eq “AllPrincipals” }

If this all seems a bit complicated, think of it like this:

To summarize once more, we’re going to send all admins that have Apple Mail users with Basic auth a Message Center post in the next few days. Admins will get one of two posts:

1. You need to grant admin consent; here’s a URL to do that easily
2. You do NOT need to grant admin consent (because it already exists). No actions for the admin.

If you don’t get a Message Center post, it’s because we don’t think you have any Apple Mail clients using Basic auth. Which means, there’s nothing for you to do at this time.

The code to automatically migrate accounts to Modern auth will appear in an upcoming Apple iOS update. So, encourage users to keep their devices up to date (which is always a good idea anyway).

We’ll provide an update in the future about when this feature will be enabled on macOS. And when it is enabled, the same outcome as above will apply – the app will attempt to migrate the account from Basic to Modern auth with minimal user interaction.

If your devices are using certificate-based authentication, they will be unaffected when Exchange Online turns off Basic auth in Exchange Online later this year. Only devices authenticating directly using Basic auth will be affected.

If you have users using the Apple Mail app and you want them to seamlessly transition to Modern auth, grant admin consent for them. You can switch those users from Basic auth to Modern auth today by simply asking users to remove and re-add their account in the Mail app.

Exchange Online Team & Apple Mail Team