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.
You have a conditional access setup that are working today as this:
- You require Compliant Device OR Multifactor on PC and macOS
- You require Compliant Device and/or Approved Apps on Android and iOS (the main part being you require approved apps)
- 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.
- You have blocked basic authentication
- 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.
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)
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.
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:
- myprofile.microsoft.com (where you set up your MFA information )
- 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:
- Go to Azure AD – Enterprise Applications and search of iOS Accounts and click it to open it.
- Under Users and Groups you can see if you have any users assigned to the app
- Under Permissions click on User Consent to see how many users have given consent to the app and who.
- Now to take control of this click on Review Permissions on the top of this blade
- 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:
- 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)
- In PowerShell I have used the following commands (from the side-window) to remove assigned users and remove all delegated permission
- 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.
- 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.
- If you click on the first option in side-window you have the PowerShell script to remove all users assigned to the application.
- 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.
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
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.