Categories
Endpoint Manager Intune MAM Microsoft 365 security

Intune MAM Exemptions – Discovering URL Protocols

In Microsoft Intune you can create a secure container where the data in your apps cannot leak outside of. That is, you can restrict copy/paste outside of the supported apps and restrict opening the data in a different app.

But sometimes you need to open the data in a different app and with the Intune Mobile Application Management (MAM) policy (also known as App Protection Policy, APP) in place you are restricted from doing so.

On Android adding the exception for apps is easy – its part of the URL to the app in the Google Play Store. For example to allow data to be sent to Google Maps you would look up the app URL (https://play.google.com/store/apps/details?id=com.google.android.apps.maps&hl=en&gl=us) and exempt the app in Intune MAM policy by using the ID value, so com.google.android.apps.maps in this case.

On iOS this is next to impossible. Microsoft in their article on this subject at iOS/iPadOS app protection policy settings – Microsoft Intune | Microsoft Docs and Data transfer policy exceptions for apps – Microsoft Intune | Microsoft Docs suggest this is done by contacting the app developer. I have had no success doing this, as often the app first line support has no idea what you are asking.

So here is how to get the URL Protocol, or more correctly speaking, the URL Scheme for the app. I think the first battle is in working out the correct terminology!

To get the information you need you have to have access to the ipa file that is the app on the iOS device. I use iMazing for this and my steps here are for the PC, but a Mac version is also available. iMazing is available for purchase on a per device basis but works on a short trial basis which might be enough time to do this for some of your obvious apps – buying a license to allow you do this as new apps get used or older apps change their schemes is a good investment.

Once iMazing is installed you need to plug in your iPhone/iPad to your PC. Ensure the apps you need are installed on the device.

An iPhone Displayed in the iMazing App

In the middle-right column there is an option called Manage Apps. This lists the library of apps you have on the device and the option to download the app to your PC. I am going to work through the process of getting the URL Scheme for Cisco WebEx Meet, which is the app Microsoft have in their documentation as well, as you can see from my app library below there appears to be two apps called “Webex Meet” – so lets see what is going on.

Viewing apps in iMazing

For each app you need to determine the URL Scheme/URL Protocol for, download the app by clicking the “cloud + down arrow” icon to the right of the app.

Downloading an app in iMazing

You will need to login to the Apple account ID used by the iOS device to complete this step.

Once I have downloaded the app the version number is displayed. I had previously downloaded Webex Meet 41.3.2 and the new download is version 41.3.3. So this is why I see multiple versions. The trashcan icon can be used to clean up your download folder. The arrow icon bottom right will give you an option to update all the downloaded apps to their latest version is new versions are available as well.

Once you have downloaded the app you can export the .ipa file for the app. This is done via the same arrow button bottom right. It will export the .ipa file for the selected app to a folder of your choosing.

Exporting the .ipa file for the selected app

Choose the folder to export to and then open that folder in Windows Explorer

The downloaded .ipa files in Windows Explorer

You can see the exported Webex Meet 41.3.3.ipa file in this folder, and the previously downloaded, and renamed, file as well. This rename is the next step. The .ipa file is just a ZIP compressed file, so add .zip to the end of the file name and open the compressed file. Don’t extract the contents of the file, as we are only looking for a single file in all the contents.

Inside the compressed file, navigate into Payload > AppName.app and find info.plist. Copy this file only out of the compressed file.

Inside the compressed .ipa file looking for info.plist

Once you have the info.plist file outside of the compressed folder, open this file in Notepad.

info.plist in Notepad

Now to search for the URL Scheme in this file. Search for CFBundleURLSchemes, and unfortunately you may see more than one of these. We know from the Microsoft documentation that they say the URL Protocol for WebEx is wbx and we see this value as a <string> under <array> under <dict> where <key> is CFBundleURLSchemes

CFBundleURLSchemes in the info.plist file

The <string> value is the URL Scheme, and so for WebEx is is wbx. The value is found under Key=CFBundleURLName, Key=CFBundleURLSchemes, String=. At this point it is all down to testing on the device. So add the most likely string to Intune MAM policy exceptions and wait for that to sync to the phone (browse to about:intunehelp in Edge Browser on the device) and click View Intune App Status

Then select an app, for example Outlook, from the scroller at the top and scroll down to ProtocolExclusions near the bottom – once your new addition is listed here you can test to see if you can open the new app from a link in the source app:

For example, in the above I have the following URL Schemes added as well as some I am still testing:

  • zoomus = Zoom
  • gmeet = Google Meet
  • bjn (or bjn-intunemam or bjn-a2m) = BlueJeans
  • mobilepassplus = Mobile Pass+ from Thales
  • com.mimecast.mobile.saml = Mimecast
  • pdfe-callback (or pdfe2int1 or pdfefile) = PDF Expert

It is still a bit hit and miss once you have info.plist, but you have a list of values for the URL Protocol that you can test against now.

Categories
android Apple AutoPilot Deployment Endpoint Manager Graph Intune iOS

What Is The Value of enrollmentProfileName

In Microsoft EndPoint Manager there are a few different device registration scenarios that make use of a property called device.enrollmentProfileName. To find and apply other settings (apps, config, etc) to these devices later on you need to have a Dynamic Device Group based on this property. The problem is the value of the property is not available to view in PowerShell or the Endpoint Manager portal.

This value is used by AutoPilot, Apple Business Manager devices (aka DEP) and Android Fully Managed device profiles.

So how can I see what a devices value is so I can create a group to contain that device. I need to use the Graph Explorer.

In the Graph Explorer, using the Beta endpoint, I can get data for my device using the query https://graph.microsoft.com/beta/devices/{objectId}

This gets BETA endpoint graph data, which includes enrollmentProfileName. The version 1.0 endpoint does not return enrollmentProfileName in the response.

If you have never used the Graph Explorer before, here are the steps to get this info:

Open the Graph Explorer from https://developer.microsoft.com/en-us/graph/graph-explorer

Click Sign In button to the left, and once signed in, select Beta (highlighted) and paste in the query replacing /me with /devices/{objectID}

Graph Explorer to look for a device properties (beta endpoint)

You may not have permissions (consent) to view the data you need, so you might need to click on Modify Permissions tab (also highlighted above) to request and approve consent to access the data. This consent may need administrator approval depending upon your security settings in Azure AD.

Click Run Query button and view the results in the Response Preview section below:

Response to a Device query in the Graph

The value of enrollmentProfileName will be the profile the device was enrolled under, at the time of enrollment. Its possible that the profile was renamed or deleted since the device was enrolled, or that you have many profiles, and so actually working out which profile the device is under can be tricky.

Also a top tip – don’t name your profiles all starting with “Test”. In the tenant where the above screenshots where taken from we found DEP profiles called “Test…” and AutoPilot profiles called “Test…”, so creating dynamic device groups where the device.enrollmentProfileName -contains “Test” was returning too many devices!

Categories
Advanced Threat Protection Azure Active Directory Azure AD Deployment EM+S Endpoint Manager Intune mcas mdatp MDM Microsoft Cloud App Security Microsoft Defender Advanced Threat Protection Mobile Device Management Web Application Proxy

Blocking Apps With a Low Reputation

One of the benefits of Microsoft 365 is the interaction across many products and features to create services that otherwise you might not have available to you or need to implement unrelated and unconnected additional software and maybe client agents as well.

Recently announced is an interaction between Windows Defender (client AV and other security protections on Windows 10), Microsoft Cloud App Security – MCAS (cloud based reverse proxy for cloud app protection), Microsoft Defender Advanced Threat Protection (cloud service for analysing activity on end compute devices and determining if the activity could be malicious or warrant further investigation) and Microsoft Endpoint Protection Manager (recently renamed from Microsoft Intune) for pushing the settings needed to enable all of this. This interaction is to take apps that your users are browsing to, read the discovered app score and if the score is too low then to tag the app as unsanctioned and push the URLs for this app to the client (via MDATP) and have Windows Defender block access to the app shortly afterwards.

Client Experience

So lets take a look at what this looks like from the users perspective and then how to set it up. First on the left if Microsoft Edge (either the old or the new version) and Firefox on the right. The action is the viewing of a URL that is unsanctioned. This particular app that I chose is an news agency and I browsed to the site directly. If the site is browsed indirectly (say via an embedded advert or graphic) then a different view will appear.

image image

Making This Work

Now lets see what we needed to put together to make this work. First Intune (Endpoint Manager) for the settings on the client, then MDATP for the interaction with MCAS and then MCAS for the app protection:

Endpoint Manager (Intune)

For this protection feature we need to ensure that you have a Device Configuration policy for Windows 10 or later that sets both Endpoint Protection and Device Restrictions in place. These two policies need to be in place and scoped to all the users that you want to protect.

The first policy is an Endpoint Protection policy, and you may have one of these already configuring Windows Defender on your Windows 10 endpoints. You need to make sure that the Microsoft Defender Exploit Guard and then the Network Filtering policy is set to Enable. This is supported in Windows 10 1709 and later, and I have seen this break outbound network connectivity on Windows 10 version 1703 machines that had the Microsoft Firewall disabled (where it did not break later versions of Windows).

image

Save and apply this policy.

Create a second Device Configuration policy, again for Windows 10 or later and for Device Restrictions this time. For this policy select Microsoft Defender Antivirus and then Enable the Real-Time Monitoring option, the Cloud Delivered Protection option also to Enabled, for Prompt users before sample submission, select Send all data without prompting and for Submit samples consent select Send all samples automatically. These are shown in the following two screenshots, both showing the same set of settings, but as its quite a long list the second picture is scrolled down.

image image

Again save and apply this policy. Now wait for it to download to your client machines, or in the MDM settings on Domains and Accounts, click Sync to speed this process up.

MDATP

Next you need to set up the interaction between MCAS and MDATP. This is done in the Settings > Advanced Features. Here ensure that Custom Network Indicators is enabled. This ensures that machines can be set to allow or block URLs. This feature requires Windows 10 version 1709 and later as well and an up to date version of the antimalware platform. The network protection in block mode, which is also listed as a requirement, is what we have enabled above.

You also need to make sure that the integration with Microsoft Cloud App Security (MCAS) is enabled. Again, a list of client requirements is displayed along with the requirement that you are running EMS E5 licences for all targeted users.

image

If you don’t have the MCAS or EMS E5 licence then you can add the URLs and other indicators directly into MDATP via Settings > Indicators > URLs/Domains. It is here the MCAS pushes the URLs that the client will block against, and so any way of pushing data into the indicators in MDATP will generate the same result.

MCAS

In MCAS we need to set up the pushing of unsanctioned apps to MDATP and configure unsanctioned apps either manually or automatically.

To push the status of unsanctioned apps click the cog to the top right and choose Settings. Select Microsoft Defender ATP and ensure that Block unsanctioned apps is enabled here.

image

Finally we can go to the Discovered Apps portal in MCAS. If you recently enabled the integration between MDATP and MCAS then this list of apps on the Discover > Discovered Apps will be empty. This will populate over time and store up to 90 days of information on the cloud apps your users are browsing.

image

On the report, possibly called the “Win10 Endpoint Users” report, which is client data from MDATP, click on the Score column to sort the list from 0 upward and see the apps that users are browsing that MCAS scores with a low rating. Click the app name to get the stats on why the app gets a low score.

Under the Actions column click the “no entry” sign, which tags an app as unsanctioned. Once you do this, this app will be blocked in Windows 10 that is under the scope of the Intune policy created above within 2 hours (allowing 8 hours for Intune to sync the new settings in the first instance).

To automatically unsanction any app with a low score (for example 0 to 3) then select Policies from the Control menu. Create a new App Discovery Policy by clicking the Create Policy option. This new policy will have a name like “Unsanction Apps With A Low Score” and the policy setting will be Risk Score equals 0-2. It will apply to All Continuous Reports. Decide if you want to be alerted to this app running and finally select Tag app as unsanctioned.

image

Shortly after you create this rule apps that fall into the category will be tagged as unsanctioned. Before you enable this rule it would be wise to check the list of apps with the same score as shown under the Discovery reports that meet your score to ensure that it would not be business impacting immediately (unless you need that to happen). For example at the time of writing this 3,095 apps where shown as scoring #2 and below and 14 apps of score #2 and below that had been viewed by end users in our company over the last 30 days. In the Continuous reports you can click any app and see who is using it and who would be impacted by blocking it.

I recommend individually unsanctioning an app for testing purposes. You can get the URL for the app by clicking the app name in MCAS and then you can browse this from a end user device that is under the scope of your MDATP deployment and your policy Intune deployment. This takes about 2 hours to take effect first time around. The automated rule to tag apps as unsanctioned automatically takes a bit longer and therefore harder to test.

Once users then access these unsanctioned apps they appear as alerts in MDATP as well. On the Alerts Queue you get a “Connection to a blocked cloud application was detected”. For example I got the following during writing this blog because when my screen-shooting software was capturing the above Firefox image it decided to follow the URL and now I see that snagit32.exe was blocked from making a connection to a blocked cloud application

image

image

Reversing The Changes

Added to this blog 1 year later after seeing this process in use!

Once a app is tagged as unsanctioned it will remain unsanctioned. It is not possible to view the app in MCAS becuase users are not visiting it anymore, and MCAS has a filter for 30, 60 or 90 days. If you delete the URL from the Indicators node in MDATP (renamed Microsoft Defender for Endpoints since this article was written) then the URL is written back again shortly afterwards, as the app is still unsanctioned in MCAS.

Therefore you should check occasionally the MCAS policy you created, click “End and preview results” in the filter and look for unsanctioned apps that should no-longer be blocked.

From this Select app filters screen modify the filter, which you are not going to save at the end, to add a new filter row for “app tag”, “equals” and “unsanctioned”. Change the top filter to 0-10 and not 0-2 or whatever you selected. You will see this:

Here I can see two apps that are now set to 5 (yellow icon) that are also unsanctioned, becuase in the past they were in the scope of my filter. Click the red banned icon to unsanction the app and confirm the dialog as shown:

Once you are finished clearing apps you can cancel the edits to the filter as you dont need to save these changes, they are only here to find higher scoring unsanctioned apps. You cannot make a new MCAS filter to automatically unsanction them when outside of the range you set above as MCAS only allows you to sanction or unsanction, not to clear a previous setting.

In a few minutes the indicators in MDATP will be removed and this will sync down to the client and release this app in a few hours.