There have been a few mobile apps in the news lately that many organizations would like to avoid having installed on devices accessing their corporate data. Traditionally, especially for companies that have been using Configuration Manager for endpoint management for many years, the first thing that comes to mind is leveraging software inventory to find where those apps are installed. This kind of strategy usually starts with thinking like “what apps are on my devices?” And then deciding “what should we do about it?”. It’s a reactive way of thinking. Your devices already have the malicious software on them while you’re planning what to do about it after you find it. You’re putting out fires.
Modern endpoint management with Microsoft Intune requires a different approach and a different way of thinking. It’s different for several reasons:
- Using traditional inventory-based reporting to track down and respond to issues is reactive, it’s putting out fires. Modern management with Intune is proactive—it’s about pushing policies that put conditions in place so you’re not dependent on reviewing inventory results to know what’s going on.
- Another twist with mobile device inventories is that the gathered inventory information can vary. It varies by platform (iOS, Android, etc.) and it also varies by enrollment method (personal, corporate).
- Lastly, even if you could always get the information you wanted from mobile device software inventory with Intune, there’s no way to force a software inventory to run on demand. That means the data you’re looking at might be several days old.
Rather than relying on software inventory reports to tell us what’s going on after the fact, a better approach might start with thinking like, “what do we need to do to ensure these apps don’t get installed, aren’t even available to be installed, or block access to corporate data until those apps are off users’ devices?”. In other words, proactively create conditions to start with “what do we do about it” if an app is installed rather than trying to inventory every device in your enterprise and chase them down one by one. Think zero trust. Assume that these apps are already in your enterprise and someone is going to try to install them. Now, what do we do about it?
Intune can help here, and I’ll show you how for both Android and iOS devices.
Protect Android Enterprise devices
There are a few fully supported ways to enroll Android Enterprise devices associated with users into Intune as of the time of this writing: Android Enterprise Work Profile and Android Enterprise Fully Managed. Corporate-owned devices with a work profile enrollment is in public preview with Intune service release 2007, and many (not all) of the same capabilities for fully managed will eventually apply there, and we’re not concerned with COSU kiosk-type devices right now.
Personal devices with work profile. Users with these devices will have both a personal profile accessing the public Google Play Store and a work profile that can only get the apps you approve from the Managed Google Play Store integrated with Intune. Work profiles use a managed Google Play account automatically provisioned from Intune. If a user switches to their personal profile, they install apps there and not in the work profile. Device configuration profiles can be used to configure how the different profiles (personal and work) share data. So, between approving the apps that can be installed in the work profile from the Managed Google Play Store, Android Enterprise Configuration Profiles, and App Protection Policies for Android, you should have these BYOD work profile devices covered. We can’t, in fact we don’t want to, manage or inventory what gets installed in the personal profile.
That leaves Corporate-owned, fully managed user devices. By default, just like with Android Enterprise Work Profile devices, users can only get apps from the Managed Google Play Store that you, as the admin, approve. On fully managed Android Enterprise devices, we can use Intune to silently install approved apps on users’ devices without any user interaction—we can also delete them.
However, unlike work profiles, with fully managed devices, you can allow users to install apps from the public Google Play Store in addition to the ones you’ve approved in the Managed Google Play Store. You can also allow users to add their personal accounts to those fully managed devices that would otherwise only have a managed Google account associated with them.
If those settings are enabled, they enable apps that you haven’t approved, including allegedly malicious apps, to be installed on fully managed devices accessing your corporate data.
What’s in and out of the Managed Google Play Store
Clearly we don’t want a possibly malicious app to be present in our Managed Google Play Store so let’s start protecting your enterprise by approving the malicious app you’re trying to keep off users’ devices. Yes, I said approve it. Once you’ve approved the app and sync’d the Managed Google Play store with Intune, we’re going to deploy it too—by creating an uninstall deployment assignment for all Android Enterprise devices.
Once you’ve done that, the app will automatically be uninstalled from those fully managed devices. However, if a user has added a personal Google account to their fully managed device, they’ll still be able to see and install the app from the public Play Store. Intune will automatically uninstall the app again if they try that. If you’ve allowed users to see all apps in the Managed Google Play Store, then the account used to view apps is the enterprise organizational account. In that case, users won’t see apps that you’ve configured for uninstall because apps set for uninstall deployments are hidden from view. You can’t see them to install them. Win-win:
And that’s pretty much all there is to it for Android Enterprise devices. Remember to leverage device configuration profiles and app protection policies for those BYOD Android Enterprise Work Profile devices to keep personal and corporate data separate. You control what they can install in the work profile from the Managed Google Play Store and personal device data is really none of our business.
For fully managed devices, you’ll hopefully now feel better about allowing users to install publicly available apps as well as what you approve in the Managed Google Play store. This will make your users happy and you’ll be able to sleep at night knowing you can control what’s available to install and that you can delete any app you don’t want on those company devices—all without inventorying anything.
It’s not quite as easy with iOS/iPadOS so there’s a lot more to talk about next.
How to handle restricted iOS apps with Intune
Next let’s go over the options available for dealing with restricted apps installed on iOS/iPadOS devices. These options aren’t as cut and dry as those we get with Android Enterprise Fully Managed devices where we can automatically uninstall or hide specific apps from being installed from the Managed Google Play Store.
Intune can’t be used to silently uninstall iOS apps unless they are managed by the service. That means they must have been pushed by Intune or installed from the Intune Company Portal. I’m assuming you haven’t deployed the app you’re trying to block, but if you have, just go push an uninstall deployment and you’re done. Otherwise, no need to worry, there’s still a lot we can do to protect your enterprise from users running malicious apps on devices that access your corporate data. Here’s a quick list and I’ll go into detail on each afterwards:
- Have the Intune service report any devices that have prohibited devices installed on them.
- Install the malicious app so that it’s managed and then we can push an uninstall command to it.
- Block access to corporate resources using Azure AD Conditional Access until users uninstall prohibited apps.
You can use device restriction policies for iOS supervised devices to block app installation from the App Store or block App Store from the home screen and that’s pretty straight forward to do. For the purposes of this post, I’m focusing on iOS unsupervised devices only.
Devices with restricted apps report
Using an iOS/iPadOS device restrictions profile, you can list the apps that you want to prohibit installation on your managed devices. Based on these policies, managed iOS devices will alert the Intune service if they have restricted apps installed on them. Notice I didn’t say installed on your supervised devices or installed on iOS devices enrolled using corporate enrollment methods. Any managed iOS device will do.
Yes, devices enrolled using the company portal app will show up as personally enrolled devices in the MEM admin center portal. No, Intune is not inventorying apps on personal devices, the policy just tells devices to looks for specific, prohibited Apple app bundle IDs and to let us know if it finds one. This behavior doesn’t apply to personal devices that aren’t enrolled for management and are only targeted by app protection policies.
This process really has nothing to do with inventory, we’re just telling the company-managed device to let us know if it has a prohibited app installed on it. And that’s the end of the action. You can view what devices have prohibited apps installed, but you can’t really do much else via the devices with restricted apps report.
To let Intune know which apps to report on, you’ll need a few bits of information about the app: the public app store URL, the app bundle ID, and its name. You can also add an optional publisher name. The information is pretty easy to get.
Search the public Apple app store for the iOS/iPadOS app you want to prohibit. Browse to https://www.apple.com/ios/app-store/ and search for the app. You can also just use your internet search engine of choice and search for “itunes <app name>” and that will get you in the neighborhood pretty quickly.
From there, you’ll be able to grab most of the information you need. The app store URL, the name of the app and the publisher. What about the bundle ID? That’s the tricky part.
If you’re looking for a Microsoft app, there’s a list of bundle IDs in the public documentation. Finding a non-Microsoft Apple App Bundle ID requires a little more work. The easy way to do it is to just use a website that gives you the ID. There’s a few out there that will allow you to search for an app by name and provide you the bundle ID.
Another, and better in my opinion, way to get the bundle Id requires a little more work. See the app ID at the end of the app store url? That’s how Apple identifies the app in the app store and is what the app bundle ID is associated with. To find the bundle ID, append the app ID to this url and hit enter. A small text file will get downloaded when you do:
https://itunes.apple.com/lookup?id=<your app ID goes here>
Here’s the one for TikTok for example:
https://itunes.apple.com/lookup?id=835599320
Once the .txt file downloads, open it up, scroll to the bottom and find the bundleID value. That’s what we’re after. It should look something like “bundleId”:”com.zhiliaoapp.misically”. The part we’re after is com.zhiliaoapp.musically . That’s the bundle ID for TikTok.
Now you’ve got all the information you need to add TikTok to your list of prohibited apps. Rinse and repeat for any of the apps you want to put on your restricted apps list, complete the remainder of the device restrictions profile, and deploy it to your users of managed iOS/iPadOS devices. Device profiles that use the restricted app settings should be assigned to groups of users.
Devices that have prohibited apps installed on them will show as failed for the device restrictions policy. To see which app triggered the failure, you have to look in the devices with restricted apps report.
In just a few minutes you’ll start to see devices tell on themselves in the devices with restricted apps report. You can find that under Devices –> Monitor –> Devices with restricted apps. Busted.
It can take around an hour for the restricted apps report to update after the device restrictions policy has been applied. If you’re testing this, your patience will be rewarded.
And that’s it.
That’s all Intune is going to do about devices that report restricted apps have been installed. It’s up to you to do something about it. Or maybe that’s all you need to do if you just want a report to see if an app that has been in the news lately is in use in your organization. It’s an easy way to report on that kind of thing without affecting your end users.
Install and then uninstall the prohibited app
Intune can uninstall only apps that are deployed through the mobile device management (MDM) channel. So, the next best thing after reporting that you could do is to create a device group containing the exported list of all devices that have reported the prohibited app is installed and then have Intune install the app on those devices. That will prompt the user to allow Intune to manage the app—and in turn, allow Intune permission to silently uninstall the app at a later date of your choosing. You can read more about that here: Intune can’t uninstall apps that are installed from Apple App Store. This is what users will see if you try to push TikTok to a device you already know has it via the restricted apps report:
How confident are you that your users are going to agree to letting you manage TikTok and their app data when they might already know it’s a prohibited app? Yeah, I’m not confident either. Trust no one.
And no, you can’t make the app required to specific user groups and also assign to uninstall for all users. If there’s a required/uninstall conflict, required is going to win. Don’t believe me? Read this: How conflicts between app intents are resolved.
I think it’s probably better to block access to corporate data until users uninstall the apps themselves.
Block access to corporate resources
You can use device compliance policy settings to be completely sure that users are not accessing your corporate resources with devices that have restricted apps installed. This of course assumes that you have an Azure AD conditional access policy set up to only allow corporate resource access to compliant devices.
The process is simple. Just create an iOS device compliance policy and add the restricted apps information in the Device Security section. We’ve already talked through how to find the bundle ID so by now this should be a breeze to configure.
Take note of the order the app information is in. The left column is for the app name and the right column is the bundle ID. That’s opposite of how we did it for the device restrictions profile.
Once deployed, the iOS compliance policy will have the device check for those restricted apps. If they’re found, the device will be marked non-compliant and the apps that triggered the non-compliance will be detailed in the trusty devices with restricted apps report. The user will be prompted to uninstall those restricted apps to once again bring their device back into compliance.
Once the user uninstalls the restricted apps, the device will be back in compliance and fall off the devices with restricted apps report in about an hour. No need to wait for another inventory to run days later.
And that’s how you handle restricted app installation on managed iOS devices—without relying on device inventory data.
You’ve seen my blog; want to follow me on Twitter too? @JeffGilb
