As Apple are getting ready to release iPadOS to the masses on September 30th 2019 there are important matters to take care of. If you have both MacOS and iPads in your enviroment there are difficult choices to be made. We either have to break the user experience on MacOS or ease up on the security on the mobile platform. This post is going to go through a common scenario and also try to explain what you can do to maintain a wanted level of security.

Scenario description

You have a conditional access setup that are working today as this:

  1. You require Compliant Device OR Multifactor on PC and macOS
  2. You require Compliant Device and/or Approved Apps on Android and iOS (the main part being you require approved apps)
  3. You have configured app protection policies on iOS and Android to make sure people can’t store data on private cloud storage and can’t copy / paste large amount of data out of the corporate environment.
  4. You have blocked basic authentication
  5. You have blocked Exchange Active Sync on iOS and Android

In this scenario today all your iPad and iPhone users MUST use either a managed app (like Outlook, Edge, Teams, Word) to access any of your O365 and Azure AD integrated SaaS apps. All good for now.

The problem

Browser access from iPad is seen as Mac Browser access

When you iPad is upgraded to iOS 13 or iPadOS there is a big change in how the iPads present them self to Azure AD. Safari now presents it self as a Mac (MacOS)

Azure AD log – iPad using Safari – shows up as MacOS.

This means we don’t have a way anymore to separate iPads and Macs. And as long as MacOS does not support Intune App Protection (MAM), we have kind of an issue. We can’t require Approved Apps on MacOS. So where does this leave us?

Native Mail App on iPad is seen as Mac

If you have a Conditional Access policy to require Outlook for accessing Exchange Online on iOS, this will no longer apply to iPadOS as that access is seen as MacOS. The main problem about this is that we can’t target MacOS with a “Require Approved Apps” policy.

iOS uses a App calles iOS Accounts to facilitate modern authentication. This access is presented as MacOS instead of iOS.

This means that even though  I have successfully been able to block users from using native mail up until today, that is not so straightforward anymore. I want to enforce my users to use Outlook Mobile for all email access on iPads. If you already are blocking your users from giving consent to new Oauth Apps, this issue is not existing if nobody has given consent to this application (iOS Accounts) on behalf of the organisation.

Trying to remediate

Blocking Mac Browser in Conditional Access

So the first thing I did to try to remediate this was to block Browser access from MacOS. This might not be a good idea if you have a lot of Macs in your environment. There are many O365 Services that are only available through the browser. So what is going to be unavailable to your Mac Users? Some examples:

  • Portal.office.com
  • Delve
  • Planner
  • Stream
  • PowerBi
  • Sharepoint
  • myprofile.microsoft.com (where you set up your MFA information )
  • myapps.microsoft.com
  • Any SaaS app in Azure AD accessed through a browser ++

Some of these can be solved by using the Microsoft Teams app. If you add a tab for Sharepoint, Stream and PowerBI, it seems like you are able to access those services somehow. But other services like MyApps and Delve are blocked. My conclusion is that if you have extensive usage of MacOS in your enviroment, you must either start using a Virtual Windows 10 to allow your users to still have access to the necessary services or open your door for unprotected browser access on your iPads.

Blocking the Native Mail App

So I have already setup my tenant to block both Basic authentication and Exchange Active Sync, so that is already taken care off. I am presuming that you allow app consent to your users or that this has been consented to at one time in your organisation.

After more investigation on the iOS Account app issue I have realized that the Conditional Access way of blocking this described bellow didn’t work as expected. We need to revoke all user grants and take control of this Enterprise Application in our tenant. Also if you want to immediately kick out all your existing users, you need to revoke their Azure AD Refresh tokens. So lets start:

  1. Go to Azure AD – Enterprise Applications and search of iOS Accounts and click it to open it.
  2. Under Users and Groups you can see if you have any users assigned to the app
  3. Under Permissions click on User Consent to see how many users have given consent to the app and who.

  4. Now to take control of this click on Review Permissions on the top of this blade
  5. A side window will open and you have 4 options. Have a look at the different options and PowerShell commands that you can use. I have done the following:
    1. Go back to App Properties – Enabled users to sign-in = NO, User Assignment required = Yes, Visible to users = No (NB: This will not kick out users already signed in for quite some time, so I am doing more now)
    2. In PowerShell I have used the following commands (from the side-window) to remove assigned users and remove all delegated permission
      1. If you click on the second option in side-window you will have the PowerShell script to revoke all permissions granted to the application. Copy the code and run from PowerShell.
      2. You will also find the PowerShell script to revoke all refresh tokens for all users assigned to the application – I suggest you run this if you have many users and want to kick them out instantly.
      3. If you click on the first option in side-window you have the PowerShell script to remove all users assigned to the application.
    3. Now we have no users assigned – no delegation on the application and no users with an active token. Users Native email application will ask for password, and when they try to sign in again they will be blocked.

DO NOT REMOVE THE APPLICATION FROM AZURE AD IF YOU ALLOW YOUR USERS TO SELF SERVICE OAUTH APPS. THAT WILL ALLOW USERS TO APPROVE THE APP AGAIN.

To remediate this specific situation, there is a easy workaround, and  that is to block iOS Accounts from MacOS. Go to Azure AD -> Conditional Access and create a new Policy. Under users and Groups, select All Users. Under Cloud Apps, click on Select App and search for iOS Accounts. If the it is not there, nobody in your org has been able to configure that yet. My suggestion is that you use an iOS device and setup native mail app on that one device to get the app visible in your tenant. 

When you have the app selected. Go to conditions, select All Devices and under Grant select Block Access.

Another and preferred option from a security perspective is to remove the existing apps from your Azure AD (Under Enterprise Apps), and also remove the end users rights to consent to new Oauth applications. Just be aware of the impact of this choice, as it also removes the users possibility for using their corporate identity to logon to 3rd Party apps that are not already onboarded by your company.

Summary

To start, I just want to say, that this scenario or list of issues are no way a exhaustive list, this is just what I have discovered after a couple of hours of testing. It is very plausible that more apps would announce themselves as MacOS too. This situation right now is not good as long as you have MacOS devices in your environment and you are relying on Intune App Protection on your mobile devices. There is no good solution today, but you have some choices to what you can do to remediate some of this. I truly hope Microsoft comes up with a solution as soon as possible. Customers using only App Protection is probably the one that would hurt the most. I understand that Apple did this to make webpages looks the same on Mac and iPad so that iPad would be seen as a even more viable option as a Enterprise Tablet device, but it breaks a lot of the Conditional Access features we have today. Suggestions and comments on this topic is greatly appreciated.
If you want the official information, you can find the support article from Microsoft here: https://support.microsoft.com/en-us/help/4521038/action-required-update-conditional-access-policies-for-ipados

 

(3113)

comments
  • Carolyn Billups
    Posted at 19:41 September 16, 2019
    Carolyn Billups
    Reply
    Author

    In my test with blocking iOS accounts via a CA policy – when looking at the sign in logs iOS Accounts shows failure but mail was still pulled down to the native app with no problem.

    Failure reason:

    Device Authentication Required – DeviceId -DeviceAltSecId claims are null OR no device corresponding to the device identifier exists.

    This test user had previously accepted iOS on another device so that could play a part.

    In my testing so far the only applications showing up as macOS are through the browser and the native mail app. All other applications Outlook, SharePoint, Teams, My Apps, Delve, Excel, Word, OneNote are coming through as iOS.

    • Carolyn Billups
      Posted at 20:39 September 16, 2019
      Carolyn Billups
      Reply
      Author

      Correction: Once I removed and added email back to the native app it pulled down the mail but didn’t sync any new mail.

      • Jan Ketil Skanke
        Posted at 13:47 September 17, 2019
        Jan Ketil Skanke
        Reply
        Author

        Article is updated to remove access for the application it self. The Conditional access option did not work as expected. If your have Microsoft Cloud App Security you could also just Ban the app in MCAS as that would also effectively block users from using it.

  • Leave a Reply

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