Update: Azure AD has taken a change in how they recognize the browsers so conditional access will now work as expected when creating an iPad conditional access policy and browsing to the modern desktop-class browsing experience on iPadOS. For more information see this article.
Maybe a little overdue, but this week is all about ipadOS in combination with conditional access. At the end of September, Apple released ipadOS. A new platform for iPad. One of the ideas behind ipadOS is to provide “desktop-class browsing with Safari”. That desktop-class browsing is achieved by making sure that the Safari browser on ipadOS will present itself as a Safari browser on macOS. That change introduces a few challenges in combination with conditional access. I know that a lot has been written about this subject already, but looking at the amount of information on my blog about conditional access, and the number of questions I still receive about this subject, I just had to write about this subject. In this post I’ll describe the behavior of ipadOS with conditional access and the challenges that the behavior brings.
The first thing is to identify the behavior. The best and easiest place to look for the behavior is the Safari browser itself. Open the Safari browser and browse to a location that is blocked via conditional access. Click on More details and the Device platform will show macOS as the platform (as shown on the top right).
Another method, from an administrator perspective, is by using the Monitoring > Sign-ins section of Azure Active Directory. That section logs the sign-in status. That information also includes device information of the device that is used for the sign-in. On the bottom right is an example of the information that is shown for devices that are running ipadOS and using the Safari browser. It will be recognized as a device running macOS and using the Safari browser.
So far I’ve only mentioned this behavior for the Safari browser on ipadOS. However, there is more. More components that are behaving in a similar way to provide a desktop-class experience. The complete list of affected components on ipadOS is the following:
- the Safari browser
- the Native mail app
- anything that uses Safari View Controllers
Besides that it’s also good to mention that everything else is not affected by this adjustment. So, all Microsoft apps still work as expected, all other browser still work as expected and basically all other apps (with the Intune SDK integrated, or wrapped) still work as expected.
Now let’s have a look at the challenges that this behavior brings. Those challenges can be categorized in two main categories, 1) managed apps and 2) differentiating between platforms. This first category contains a flow that actually breaks and the second category contains a flow that needs some more attention. Let’s discuss those challenges in a bit more detail.
Category 1: Managed apps
When looking at the first category, we can simply state that we’re limited in options when we want to require a managed app by either using the Require approved client app or the Require app protection policy control. At this moment these controls only work for Android and iOS. That means that we cannot (easily) force a user to use a managed app on ipadOS. Before we could provide a clear message to a user that a managed app must be used, when trying to connect to a cloud app with the Native mail app or the Safari browser.
This is the point were we have to get creative. It’s possible to look at a technical solution by blocking the Native mail app and the Safari browser when accessing the different cloud apps. However, keep in mind that those technical solutions might also impact macOS (see the second category).
At this moment there is no pretty method to force users away from the Safari browser and into using managed apps on ipadOS. Any solution will also impact macOS. Besides the fact that those solutions will also impact macOS, the end-user experience will also be bad. In this case the only option would be to block access from the Safari browser to the different cloud apps. Not pretty. Also, keep in mind what that would mean for the macOS users, as there are no alternatives for macOS users.
The Native mail app is a different story. There are options when already blocking basic authentication and Exchange Active Sync. In that case you’re relying on modern authentication and when you’re relying on modern authentication, for i(pad)OS devices, you’re relying on the iOS Accounts app in Azure AD. Revoking the user grants will remove the access for the user via the Native mail app (for some detailed steps have a look here). Keep in mind that the behavior will not be as pretty as before.
Category 2: Differentiating between platforms
When looking at the second category, we can (and have) to say that we need to be careful when using the Device platforms condition. There are many scenarios available in which an organization might want to differentiating between ipadOS and macOS. In any of those scenarios don’t forget the potential impact.
Both platforms will impact ipadOS. Anything configured for macOS will impact iOS when using the Native mail app or the Safari browser. Anything configured for iOS will impact all other iOS app.
For more information about the impact of ipadOS with conditional access, please refer to this article Action Required: Evaluate and update Conditional Access policies in preparation for iPadOS launch.