iPadOS (iOS 13+) still not compatible with MAM enforced by Conditional access
Update 11/18/2019: This issue has now been fixed.
I wrote about this before the update dropped, and in my testing since then I am afraid the situation has not improved.
The setup
Create a Conditional access policy for iOS that requires an approved client app. In other words, users cannot use the native mail app (or other third party apps). They must use the approved Microsoft apps such as Outlook. This works perfectly on iPhone and iPad (prior to 13.x).
Now take an iPad, update it to iOS 13+, and it becomes iPadOS rather than just iOS. This means that Azure AD will incorrectly identify it as macOS with certain apps like Safari and the native mail app.
When you go to add a mail profile to the native mail app, you will find that you have open access, and the Conditional access policy is not enforced.
What’s worse, is that you cannot fix this problem simply by adding macOS to the device platforms under Conditions. Attempting to do so will result in an error message, and it will not allow you to Save the policy.
Since the access controls “Require approved client app” and “Require app protection policy” are only supported on Android and iOS, we have no way of enforcing MAM against iPadOS. This is a big problem, and Microsoft needs to figure out how to fix it.
MAM is so attractive precisely because we do not have to manage the device itself. It’s easier from an admin perspective:
- Don’t have to setup an iOS management certificate
- Don’t have to manage enrollment and life-cycle on all those personal devices out there
- Only have to support a single set of apps (don’t have to support native mail and other third party apps)
And it’s easier from an end-user perspective:
- MAM is hands down easier to use–just install the approved app, set a PIN if required, etc.; by contrast the enrollment process for MDM can be grueling and confusing, especially on iOS, where you have to manually leave the Company portal app during the process to enter Settings and complete the management profile installment, then return to the Company portal app to complete other setup tasks–ick!
- The approved / supported apps give the richest and best experience anyway, supporting native features like email encryption, shared mailboxes and calendars, etc.
The new screen…
My MAM policy is setup to target both web browsers and client apps by default. Separately, I added a policy targeting mac and iOS devices that would require device compliance OR an approved app, just to see what would happen. When using Safari to access OWA, I found that there is now an additional screen during the enrollment process that asks you to identify whether the device is an iPad or a Mac. Kind of hokey that the software can’t figure it out for me, but at least it’s a workaround–I assume this is so that the correct compliance policy can be assigned to my device (if you’re doing MDM).
Unfortunately, having identified my device as an iPad, it still will not enforce the MAM policy (instead it compelled me to enroll the device for MDM–even though my policy said to require only approved app OR compliant device). And with that new policy in place, I’m simply pushed down the MDM path, every time, whether I approach it from Safari or the native Apple mail app. It does not respect the MAM requirement.
Therefore, as of today at least, folks who were previously enforcing MAM instead of MDM for iOS devices will have open access on iPadOS–and no possible way to close that hole (except for maybe MDM). It is not possible to create a similar Conditional access policy targeted to macOS, nor is there any other way to make it recognize the device as an iPad and not a Mac. That extra screen didn’t seem to do the trick!
I am not a developer and I don’t pretend to know the solution. But Microsoft and Apple really should get together on this to provide a more seamless experience for users (for both MDM and MAM).
Comments (21)
Hi Alex
Not great news, but I’m not surprised either, as it always takes MS/Apple a while to catch up with what’s actually going on.
However, am I right in saying if you’re blocking Exchange Active sync and legacy clients/protocols in other conditional access policies, then you’re covered, as the Outlook app is the only one that would work anyway?
thanks
No, the native iOS mail app supports modern authentication, it is considered a modern client. I have tested this, you have open access, even with both EAS and legacy protocols disabled. Also, if you are requiring web browsers to respect the approved app condition also (e.g. Edge, managed Intune browser), then that is also left open, since Azure AD perceives the Safari browser on iPad as MacOS.
This is not what I have found. I disabled my MAM policies (to test on other IOS devices), left a policy blocking EAS on all devices, and you can set up the account, but when you try and sync email you just get an email saying that ‘your access to email has been blocked’ as if the device was quarantined. This is good enough, ipad users can try and set it up but native mail won’t work.
The same account works with native mail on an enrolled device (we push the profile down so that is fine).
Hm, that is a different experience than what I have tested. I have EAS disabled but that does not prevent the native mail app from getting email. I can add a mail profile no problem. Open access.
OK tested this again and blocking EAS did not block native mail. Now works without the message…I had not configured the profile manually, for some reason must have been using activesync instead of modern auth so not sure what happened.
Further update – yes indeed the CA policy blocking EAS does not work, however what you can do is enable device quarantine in Exchange Online using set-activesyncorganizationsettings -defaultaccesslevel quarantine.
Now anyone trying to setup naive mail on iPadOS will be allowed to, but their device will be quarantined and they won’t be able to get any mail. So this should work around the problem?
What I am confused about is EAS vs Modern Auth – iOS 12 and later native mail supports modern auth so you can use 2FA, however is that just for the auth part, and then it uses EAS for actually syncing the maibox? It does show as client type: EAS under mobile device details.
@Hal are you “configuring manually” ie entering the server or are you “signing in”? You can still use the native mail in the legacy Active Sync way OR the modern way that supports MFA. Depending on how you configure the mail you will have different results.
So, am I right in saying, as the Apple native mail app is Modern Authentication, you could create a CA policy for macOS, with Modern Auth apps that Grants Access with MFA. This would at least increase the security and require MFA.
Yes you could do that. You can also choose to block certain access. Especially if you do not have other Macs or expect to have other Macs in the environment. Also, you can block just “personal” Mac devices from enrolling, and to allow a corporate device to enroll you would need the device’s ID in advance, and populate that. I can do a write-up on this since there doesn’t appear to be any fix announced yet.
@Alex I haven’t found a better solution. I would have written up this workaround but I don’t have the platform you have :) I have it set up this way in 3 different tenants now. This seems to be the best fix for now.
Agree! I don’t see a better solution yet either. Unless you aren’t supporting any Macs at all, in which case you can block the platform outright.
Thinking about it again, I guess the only problem with this, is that if you are generally allowing the Apple native app, even with MFA, you cant put any App Protection Policies on it for security and DLP purposes.
Sharing my temp fix. I have created enrollment restrictions for personal macOS. I have a conditional access policy that requires macOS to be compliant. If I do not identify the iPad as corporate owned it will not allow a user to configure native mail on the iPad. It is not very intuitive to the user. The user is still able to configure Outlook and will then be managed by MAM. If I do identify the iPad as corporate owned and the user does enroll, they will be able to configure the native mail app. I then have to lean on the Outlook configuration policy and MDM policies.
So I have a way to block the user from using native mail and still be able to get mail through Outlook with MAM, it just isn’t a good flow to the end user.
Thanks for sharing! Yes, I agree it’s not ideal. If there are no MacOS devices in the environment, and there are not expected to be in the near future, another option is to simply block that device platform. But it’s still not a great solution. Compelling the device to become MDM enrolled is the best alternative right now, but it’s the very thing we’d like to avoid with MAM.
You can have macOS in the environment. You just have to identify the macOS as corporate owned and if they are corporate owned they should enroll with MDM. This solution doesn’t compel an iPadOS device to become enrolled, it just breaks their mail if it is configured through the native mail application. If I am telling an iPadOS device that in order to have native mail you have to be compliant but I have enrollment restriction that blocks personal macOS devices from enrolling… it just breaks the native mail.
@Carolyn Billups
i’m kind of new to Azue Intune. If you don’t mind, can you go over your temp fix with screen shots or step by step instructions?
Not sure I can add pictures to this blog but here would be the steps:
1. Go to Device Enrollment > Enrollment restriction > create and deploy device type restriction that blocks personally owned macOS
2. Create a conditional access policy scoped to macOS that requires enrollment.
3. If you want to allow the device to have access to native mail and enroll go to Device Enrollment > Corp device identifiers and add the serial/imei #
Could the new iOS13 native mail app simply be blocked by creating an Exchange Online Device Access rule, to simply block devices of a certain type?
You could do it with Conditional access policies and Intune enrollment restrictions, actually.
Ive just noticed a message in the 365 portal, published 22 Nov:
Follow up to MC191344: Evaluate and update Conditional Access policies after new iPadOS release
MS report that they have addressed the issue, and after my tests, this appears to be correct. When logging into a 365 account using the native mail app on an iPad v 13.2.3 it reports that you cant as its not an approved app.
In the 365 sign-ins I can see its failed on the conditional access policy which is correctly blocking it (Application: iOS Accounts).
Good news!!!
Yes I did have a note at the top of the post there that this has been addressed. It is very good news. Talked to the team at Ignite about this–they are doing it by identifying whether the device supports touch (no Mac currently does, only iOS/iPad OS).