{"id":3294,"date":"2022-06-17T03:05:08","date_gmt":"2022-06-17T02:05:08","guid":{"rendered":"https:\/\/www.sebae.net\/blog\/microsoft-and-apple-working-together-to-improve-exchange-online-security\/"},"modified":"2022-06-17T03:05:08","modified_gmt":"2022-06-17T02:05:08","slug":"microsoft-and-apple-working-together-to-improve-exchange-online-security","status":"publish","type":"post","link":"https:\/\/www.sebae.net\/blog\/microsoft-and-apple-working-together-to-improve-exchange-online-security\/","title":{"rendered":"Microsoft and Apple Working Together to Improve Exchange Online Security"},"content":{"rendered":"
\n

We\u2019ve 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 \u2018Modern authentication\u2019 as we call it.<\/p>\n

Today we\u2019re delighted to take the next step along that journey by sharing the work we\u2019ve 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<\/strong>.<\/p>\n

Some Background<\/span><\/h1>\n

Several years ago, before OAuth 2.0, Basic authentication was the most common method to connect, primarily because it\u2019s easy to use and was widely supported. But today it\u2019s one of the most common vectors for credential compromise and misuse.<\/p>\n

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

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.<\/p>\n

The difficult challenge of changing the configuration of millions<\/em> of users using millions<\/em> 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.<\/p>\n

The Solution<\/span><\/h1>\n

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.<\/p>\n

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<\/strong> Basic auth credentials from the device, and then reconfigure the settings on the account to use OAuth. <\/strong>From then on, the account uses OAuth to authenticate to Exchange Online, and the user doesn\u2019t even have to know this happened.<\/p>\n

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

Policy Interruption<\/span><\/h2>\n

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 \u2018normal\u2019 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.<\/p>\n

If you already have Apple Mail clients using OAuth (which you can verify using Azure AD Sign-In reports<\/a>) then it\u2019s 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\u2019s 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.<\/p>\n

Obtaining Consent<\/span><\/h2>\n

The second challenge is consent. OAuth requires consent<\/em> to grant apps access to resources. There are essentially three ways to do this:<\/p>\n

    \n
  1. The user can consent (assuming the admin allows users to self-consent to apps)<\/li>\n
  2. The admin can consent on the user\u2019s behalf<\/em><\/li>\n
  3. The user can request that the admin approve their consent request<\/li>\n<\/ol>\n

    In order to switch from Basic auth to Modern auth seamlessly, we\u2019re encouraging all admins with Apple Mail users using Basic auth to grant consent to the Apple Mail app at the tenant level<\/strong> so that users aren\u2019t individually prompted when the switch to Modern auth takes place.<\/p>\n

    Managed Devices<\/span><\/h3>\n

    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\u2019t 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\u2019t know how). Here<\/a> are the steps for Intune managed iOS devices.<\/p>\n

    Admin Actions<\/span><\/h3>\n

    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.<\/p>\n

    There is no status or dialog when you complete the flow using the Message Center link; you\u2019ll simply return to the admin center, but you can<\/em> verify<\/em> that the flow completed successfully.<\/strong><\/p>\n

    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.<\/p>\n

    Let\u2019s start with the Azure Portal.<\/p>\n

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

      \"AppleOuathConsent01.jpg\"<\/span><\/p>\n

      Once you are looking at the Overview<\/strong> page of Apple\/iOS entry, in the left hand pane, click Permissions<\/strong>.<\/p>\n

      If you have already granted admin consent, you\u2019ll see entries when the Admin consent<\/strong> view is showing. If you have not granted admin consent yet, this list will be empty.<\/p>\n

      Now, there are two possible sets of admin consent permissions you might see. You might see \u2018legacy\u2019 Office 365 Exchange Online EWS and EAS permissions, or you might see the \u2018new\u2019 Microsoft Graph EWS and EAS permissions. Or you might see just EAS, or just EWS. Why the differences?<\/p>\n

      \"AppleOuathConsent02.jpg\"<\/span><\/p>\n

      \u00a0<\/p>\n

      \"AppleOuathConsent03.jpg\"<\/span><\/p>\n

      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:<\/p>\n