In this blog, I will explain how to create an App Protection Policy in Intune for iOS/iPadOS in detail, there are four steps explained in this blog let's deep dive into each step and the settings involved.
Table Of Contents Step 1: Select the Device Type and Targeted App Step 2: Create a Data Protection Policy Step 3: Access Requirements Step 4: Conditional Launch
Step 1: Select the Device Type and Targeted App
Sign in to Manage Endpoint Manager Admin Center (Intune Admin Portal) and navigate to Apps from the left side panel and select App Protection Policy under Policy, tap on Create Policy this gives a drop-down list to choose the OS, select iOS/iPadOS
This will take you to the Create Policy page provide a Name for the policy Description and you can see Platform is already selected as per our previous input, tap on Next to move forward.
Provide a name that is relevant and can be understood easily and a description of the policy
Define the device type Unmanaged and Managed devices
Select the device type for which this policy needs to be applied, if you select Target to apps on all device types as Yes, the policy will be applied to managed and unmanaged devices, if you select No you can find an option to select which device type the policy is applied Unmanaged or Managed.
Note: Applying an app protection policy to MAM and MDM devices will provide better security
Here I have selected Yes as an option because I need this App Protection Policy on Both managed and unmanaged devices for better security
Now you can select on which app the policy is to be applied whether All Apps, All Microsoft Apps, Core Microsoft Apps, or selected apps, let's see what is the difference between each of these.
Selected Apps: If you are targeting this policy select an application that is available from the list that can be selected to apply the policy
All Apps: This includes all Microsoft and Partner apps that have integrated with Intune SDK, when this is selected, the policy is applied to all the available apps
All Microsoft Apps: This includes all Microsoft Apps integrated with Intune SDK but no Partner Apps, you can see from the below picture the apps listed are only Microsoft Apps
Core Microsoft Apps: This includes Apps such as O365 Apps (Outlook, Excel, OneDrive, Word, Office, OneNote, PowerPoint), Edge, and SharePoint. Teams and Todo
Depending on your needs, select the application for which the policy should be deployed, in my case I have selected All Apps and tapped on Next to continue the policy creation.
Step 2: Create a Data Protection Policy
Now let's create Data Protection Policy for these selected apps that will take you to the Data Protection page which provides settings for Data Loss Prevention (DLP) Controls, such as cut, copy-paste, and save-as restrictions. This will help to determine how users interact with data.
Each Option under Data protection is explained in detail which will help you to select the right settings as per your needs at the end I will share the settings that have been selected for illustration purposes in this blog.
Backup org data to iTunes and iCloud Backups, select Block if you don't want to allow users to back up their Work data to iTunes and iCloud. Select Allow if you allow users to back up work data to iTunes and iCloud.
Send Org data to other apps we can specify what apps can receive the data below are the options available to select the data transfer between apps
All apps: Allow sending org data to any app
None: Do not allow sending org data to any app, if the user tries to transfer or open the data will be encrypted and unreadable
Policy-managed apps: Only allow the exchange of data with other policy-managed apps
Note: It may be possible for users to transfer content via the Open-in or Share extensions to unmanaged apps on unenrolled devices or even enrolled devices that support sharing to unmanaged apps. Data transferred through Intune is encrypted and unreadable by unmanaged apps.Policy-managed apps with OS sharing: Sending org data to other policy-managed apps and sending org documents to other MDM-managed apps is allowed only on enrolled devices
Note: This applies only to MDM-enrolled devices. When applied to an unenrolled device, this setting has the same effect as the Policy managed app's value. If the sending app has the IntuneMAMUPN and IntuneMAMOID configured, users, will be able to send unencrypted content via Open-in or Share extensions to any application that supports the iOS MDM allow Open from Managed to Unmanaged setting.Policy-managed apps with Open-In/Share filtering: Only allow sending org data to other policy-managed apps and only display policy-managed apps in OS Open-In/Share dialogs. Filtering the Open-In/Share dialog requires both the app(s) acting as the source and the app(s) capable of opening this file/document to have the Intune SDK for iOS version 8.1.1 or higher.
Note: It is possible for users to transfer content via Open-in or Share extensions to unmanaged apps if the app supports Intune private data types. By default, Intune encrypts all data transferred and prevents unmanaged apps from accessing it.Select apps to exempt this allows you to provide an exception for apps to open org data from the unmanaged apps, tap on Select to add the APP for an exception, enter the App URL Value and tap OK to continue, for more details on how to find the URL and add exception please find my blog explaining How to create exceptions to the Intune App Protection Policy (APP)
You can see by default there are some apps exempted
Name | Value |
Default | ​skype;app-settings;calshow;itms;itmss;itms-apps;itms-appss;itms-services; |
App / Service Names | Description |
skype | Skype |
app-settings | Device Setting |
itms; itmss; itms-apps; itms-appss; itms-services | App Store |
calshow | Native Calendar |
Select universal links to exempt by this the exempted Universal Link can be opened either directly by the associated application or by an unmanaged web browser instead of the protected web browser specified by the Restrict web content transfer with other apps settings
When a universal link is clicked, the user is directed directly to the application associated with that link rather than to the protected browser specified in the setting Restrict web content transfer with other apps...By default, there are some links available to Add a link to the exempt universal link tap on Select and Enter the link (to determine the correct link for the exemption you need to reach out application developer for each application)) tap on ok to complete.
Select managed universal links by this the universal link mentioned will be opened using the managed application instead of the protected browser specified by the Restrict web content transfer with other apps settings
By default, there is a list of universal links available to Add a link tap on Select and enter the Link (to determine the correct link for the exemption you need to reach out application developer for each application) tap on ok to complete.
Save copies of org data When you select Allow, the work data can be saved to the device's local storage, which will violate the DLP policy. To restrict that, it is recommended to set it to Block and specify the apps the user can use to save the data Allow user to save copies to selected services (in my case I selected Onedrive and Sharepoint).
The setting is supported by Microsoft Excel, OneNote, Outlook, PowerPoint, and Word. It can also be supported by third-party apps and LOB applications.
This setting is only configurable when the setting Send org data to other apps is set to Policy managed apps, Policy managed apps with OS sharing or Policy managed apps with Open-In/Share filtering.
This setting will be "Allow" when the setting Send org data to other apps is set to All apps.
When the setting Send org data to other apps is set to None, this setting will be "Block" with no allowed service locations.
Transfer Telecommunication Data to, when a user selects a hyperlinked phone number in an app, and a dialer app will open with the number prefilled. In this setting, select how this type of content transfer should be handled when initiated by a policy-managed app. There are three options available for the setting
None, do not transfer this data between apps: When a phone number is detected, do not transfer communication data
A specific dialer app: When a phone number is detected, allow a specific dialer app to initiate contact.
Any dialer app: When a phone number is detected, any dialer app can be used to initiate contact.
Note: Intune SDK 12.7.0 or later is required for this setting. As a workaround, if your apps rely on dialer functionality and are not using the correct Intune SDK version, consider adding "tel;telprompt" as a data transfer exemption. The exemption can be removed once the apps support the correct Intune SDK version.If you are selecting the option A specific dialer app, you need to provide a dialer app URL schema, here I have given tel for iOS native dialer schema you can find more details from this Link, for other supported dialers you need to get the App URL schema from the app developer.
Receive data from other apps these settings allow or restrict the data flow from other apps to managed apps, there are four different options available
All Apps: this will allow receiving data from any apps top policy-managed apps
None: Don't allow data transfer from any app even policy-managed apps
Policy-managed apps: Only allow data transfer from policy-managed apps
All apps with incoming org data: this setting will allow data transfer from any app, by treating the incoming data as organization data without a user identity. the received data will be marked with the Intune MDM enrolled user's identity as defined by the IntuneMAMUPN setting.
Note: Currently, only MDM-enrolled devices can access All apps with incoming Org data. When this setting is targeted to an unenrolled device, the Any apps value applies. If you are selecting Policy managed apps you need either select Allow or Block in Open data into the org document, If you wish to allow the app to share data between accounts you need to select Allow from the option.
If you don't allow the sharing of data between accounts through the Open option or any other option you need to select Block while selecting the block option you can either allow users to open data from selected services like One Drive for Business, Sharepoint, etc.
Restrict Cut, Copy and paste between other apps, this option limits users from cut copy and pasting data from Policy managed apps according to the options selected
Blocked: Users are not allowed to cut, copy and paste actions between policy managed or any other apps
Policy-managed apps: Users are allowed to cut, copy and paste between policy-managed apps
Policy-managed apps with paste-in: this will allow users to cut & copy from any apps and paste them into a policy-managed app
Any App: Users are allowed to cut, copy and paste between any apps with no restriction
Note: Requires app to have Intune SDK version 9.0.14 or later.Cut and copy character limit for any app You can specify how many characters can be copied or cut from Org data and accounts. The specified number of characters can be shared with any application regardless of the Restrict cut, copy, and paste settings, by default the value is 0
Third-party Keyboard you can select Block to restrict users using third-party keyboards for policy-managed apps, to allow you can select Allow
Note: Apps will have keyboard restrictions in all areas. This restriction will affect personal accounts for apps that support multiple identitiesNow we have completed the data transfer restriction.
Encryption
Encrypt Org data, by default the value Required, this will enable encryption on work data in the app, iOS/iPadOS device-level encryption is enforced by Intune to protect app data while the device is locked. Applications may also optionally encrypt app data using the Intune APP SDK,256-bit AES encryption is applied to app data by Intune APP SDK.
It is recommended to keep encryption as Required for better security
Note: This setting may require the user to set up and use a device PIN to access their device. To access this app, the user is prompted to set a device PIN if there is no PIN on the device and encryption is required.Functionality
Sync policy-managed app data with native apps or add-ins, when set to Block, will ensure policy-managed apps don't save data to the device's native apps (like Contacts, Calendar, and widgets) or prevent add-ins from being used within them, and when set to Allow the policy managed app can save data to native apps or use add-ins if those features are supported and enabled.
Note: Contacts synced directly from the app to the native Contacts app will be removed when you perform a selective wipe to remove work or school data from the app. Data that has been synced from the native Contacts app to an external source cannot be wiped. Currently, this only applies to Outlook for iOSPrinting org data if the value is set to Allow users can print Org data and when set to Block will restrict users from printing Org data from the protected apps.
Restrict web content transfer with other apps will specify how web content is to be opened from policy-managed Apps this can be either opened by the below three options
Any App: Allow web links to open in any apps
Edge: Allow web content to open only in Edge
Unmanaged Browser: Web content should only be opened in unmanaged browsers defined by the "Unmanaged browser protocol" settings.
If you are selecting an Unmanaged browser you need to specify an unmanaged browser protocol like http/https
Org data notifications will specify if the work data can be notified like other app notifications on the device, this policy will impact local devices and any other wearables connected to the device for example smartwatch
Blocked: Notifications should not be shared, but if they are not supported by the application, they will be allowed.
Block org Data: Avoid sharing organization data in notifications, for example.
"You have new mail"; "You have a meeting".
If not supported by the application, notifications will be allowed.
Allow: Allows the sharing of organization data in notifications.
Step 3: Access Requirements
Here we will set up requirements for accessing apps at work, including PINs and credentials.
PIN for access: If you want users to use a PIN for accessing the policy-managed app set the option to Require, users will be prompted to set up a pin for the first time they use the app, the app required a PIN either online or offline
PIN Type: There is the option of defining if the user can use a Numeric or Passcode. Passcodes can be defined with at least one alphabetical letter or a special character, while numerical requirements require only numbers.
Simple PIN: Allow users to use simple PIN sequences such as 1234, 1111, abcd or aaaa. To prevent them from using simple sequences, select Block. A three-character sliding window is used to check simple sequences. As long as the Block is configured, 1235 or 1112 will not be accepted as PINs, but 1122 will be.
Select minimum PIN length: Specify the minimum number of digits in a pin, by defaults is set to 4, this can be set to 16 characters or a digit
Touch ID instead of PIN for access (iOS 8+/iPadOS) setting this to Allow will allow users to use touch ID instead of a PIN to access the app. If you set this Block User need to provide the PIN to access the App
Override biometrics with PIN after timeout is set to Required user needs to provide the pin after specific timeout which is set in the Timeout (minutes of inactivity) section, in my case I have set the Timeout(minutes of inactivity) to 15 minutes when the device is inactive for 15 minutes next time when user open up the app, the user will be prompted to enter the PIN this will override the use of biometric, the Timeout(minutes of inactivity) value should be always greater than Recheck the access requirements after (minutes of inactivity)
Face ID instead of PIN for access (iOS 11+/iPadOS) if set to Allow users can use the Faced ID instead of PIN to access the apps
PIN reset after number of days, setting this to yes will request the user to change their PIN from the specified Number of days by default this is set to 90 days but this can be changed as required.
App PIN when device PIN is set if this is set to Require the user need to provide a PIN for the managed application even if the device has a PIN set on an MDM enrolled device.
Work or school account credentials for access are set to require access to the policy-managed app may require work or school credentials. If a PIN or biometric method is also set to required for access to the app, the work or school account credentials will take the precedence
Recheck the access requirements after (minutes of inactivity) setting will check the access requirement if the policy-managed app is inactive for a specified number of minutes.
Step 4: Conditional Launch
To set security requirements during sign-in, we can configure the conditional launch settings of your access protection policy. There are two conditions one is App Condition which defines the access requirements to the policy-managed app if the settings and values are not met by the user then the Action will be taken as per the settings, and the other one is Device Condition which defines the access requirements to the policy managed app if the settings and values are met by device then the action will be taken as per the settings.
Conditional launch works on three aspects Setting, Value for the setting, and if that is not met what Action should be taken. Let's take a look at how we can secure the policy-managed app access using Conditional Launch. Now let's see what are the settings available.
App Condition
Maximum PIN attempts: The number of attempts required for the user to correctly enter their PIN before an action is taken is specified. If the user cannot successfully enter their PIN after the maximum number of PIN attempts, the user must reset their PIN after successfully logging into their account and completing a multi-factor authentication (MFA) challenge if required.
By default, the value is 5 you can change it according to the security recommendation or as per the requirement
Reset PIN this will ask the user to reset the pin if the user enters the pin wrong for the number of times as per the value, in my case, it's set to 5.
Wipe Data The user account associated with the application will be wiped from the device if the provided values are not met.
Note: This setting can be entered multiple times, with each instance supporting different actionsOffline grace period setting specifies the number of minutes for the policy-managed apps can run offline (without check-in to Intune) before the access requirements for the app are rechecked.
Block access (minutes) setting defines how long the apps that are managed by policy can run offline for a certain amount of time. You can specify how long (in minutes) before the access requirements for the app are rechecked. Once the configured period expires, the app blocks access to work or school data until network access is restored. The offline grace period timer is shared among all apps in the app protection policy. The value is default set to 720 minutes (12 hours).
Note: When the offline grace period timer is configured to be less than the default value, users may experience more frequent interruptions as the policy is refreshed. If you choose a value less than 30 minutes, the user may be interrupted every time the application is launched or resumed, so this is not recommended.Wipe days(days) setting defines how many days Once the app has been running offline for the specified number of days (defined by the admin) in the Value field, the user will need to reconnect to the network and re-authenticate. Once the user has successfully authenticated, the offline interval will reset, allowing the user to access their data. Users who fail to authenticate will have their accounts and data wiped from the app. This is checked for each app individually based on the last check-in with iTunes. By default, the value is set to 90 days. Administrators can define the days based on their security policies or recommendations.
Note: This setting can be entered multiple times, with each instance supporting different actionsMin App Version allows you (admin) to specify the minimum application version and create a policy with a minimum version targeting one app as apps often have different versioning schemes (for example, an Outlook version policy). There can be multiple instances of this entry, each supporting a different action.iOS app bundle version formats (major.minor or major.minor.patch) are supported by this policy setting.
Warn A notification appears if the app version on the device does not meet the requirements. It is possible to dismiss this notification.
Block Access When the app version on the device does not meet the requirement, the user is blocked from access.
Wipe Data When the app version on the device does not meet the requirement, the user account associated with the app is wiped from the device.
Note: This setting can be entered multiple times, with each instance supporting different actionsMin SDK Version setting will let the admin specify the minimum value for the Intune SDK version, Create a policy with a minimum SDK version targeting one app as apps often have different SDK versions (for example, an Intune SDK version policy for Outlook).
Block Access will block users from accessing organization data if the apps Intune app protection policy SDK version doesn't meet the requirement
Wipe Data will wipe users account associated with the app from the device if the apps Intune app protection policy SDK version doesn't meet the requirement
Note: This setting can be entered multiple times, with each instance supporting different actionsDisabled Account for this setting specific Value is not required when an account is disabled in Azure AD then the policy will take action accordingly
Block access setting will block the access for the user when the user account is disabled in Azure AD
Wipe data will perform a selective wipe of the user account and data from the app with the account is associated when the account is in a disabled state in Azure AD
Device Conditions
Maximum OS Version In this setting three Actions can let you set the maximum iOS/iPadOS operating system to use the apps mentioned in the app protection policy. When the value is set three actions that can be taken, for example, in my settings, I had set the value to 16.0 iOS / iPadOS version
Warn this action will warn the user with a notification.
Block Access the user will be blocked from accessing organizational data if the value is not met
Wipe Data the user account that is associated with the application will be wiped
You can set the values as per the security recommendation or requirement, this policy-setting format supports either major.minor, major.minor.build, major.minor.build.revision.and this setting can be set to multiple times for different values and different action
For example
If the value is set to 16.0 and warn when a user sign-in to an app under app protection policy with the user account and the device OS is running 16.0 the user will receive a warning notification
If the value is set to 16.1 and block access when a user sign-in to an app under app protection policy with the user account and the device OS is running 16.1 the user will be blocked from accessing the organization data using the app
If the value is set to 16.2 and wipe data when a user sign-in to an app under app protection policy with the user account and the device OS is running 16.2 the account will be wiped on the specific appMinimum OS Version setting will let you set the minimum iOS/iPadOS operating system to use the apps mentioned in the app protection policy. When the value is set three actions that can be taken, for an example in my settings I had set the value to 14.8 iOS / iPadOS version
Warn this action will warn the user with a notification.
Block Access the user will be blocked from accessing organizational data if the value is not met
Wipe Data on the user account
You can set the values as per the security recommendation or requirement, this policy-setting format supports either major.minor, major.minor.build, major.minor.build.revision.and this setting can be set to multiple times for different values and different action
For example
If the value is set to 15 and warn when a user sign-in to an app under app protection policy with the user account and the device OS is running 15 the user will receive a warning notification
If the value is set to 14.8 and block access when a user sign-in to an app under app protection policy with the user account and the device OS is running 14.8 the user will be blocked from accessing the organization data using the app
If the value is set to 14.1 and wipe data when a user sign-in to an app under app protection policy with the user account and the device OS is running 14.1 the account will be wiped on the specific appDevice Model setting will let you set specific models to access organization data and take action as per the settings and the values are not case sensitive. Intune would take action on end-user devices based on a simple match of device model strings specified in Intune for Application Protection Policies. Whether a device match depends entirely on what it reports. We recommend that you (the IT administrator) test this setting based on a variety of device manufacturers and models, and target a small group of users, to ensure that it performs as intended. Not configured is the default value.
Allow specified (Block non-specified) this action will let the devices models specified in the value access organizational data and block other device models
Allow specified (Wipe non-specified) this action will let the devices models specified in the value access organizational data and wipe other device models
For example, I entered the device model values as iPad13,7 for iPad Pro 11-inch 5th Gen and iPhone14,4 for iPhone 13-Mini, you can find the model, and you can find an iOS/iPadOS model identifier in this 3rd party GitHub repository.
Jailbroken or rooted device settings will take action when the user tries to access organization data using an app under the App protection policy from a jailbroken or rooted device, there are two actions available.
Block Access this will block users from accessing organization data from a jailbroken or rooted device
Wipe Data this will wipe the user account associated with the application from a jailbroken or rooted device
Maximum allowed device threat level setting will allow us to specify the maximum threat level acceptable to access the organization's data using the app from a mobile device. App protection policy can take advantage of Intune MTD (Mobile Threat Defense) connector this is how this setting will define the threat level of the device. Threats are determined by the chosen MTD (Mobile Threat Defense) vendor app on the end user device. The values can be either set to Secured, Low, Medium, or High
Secure: This is the highest level of security. The device can't have any threats present while still accessing company resources. If any threats are found the device is considered non-compliant
Low: If only low-level threats are present, the device is compliant. The device becomes non-compliant at any level higher than that.
Medium: A device is compliant if the threats found on the device are low or medium level. If high-level threats are detected, the device is determined as noncompliant.
High: This level is the least secure and allows all threat levels. Mobile Threat Défense is used here for reporting purposes. Devices are required to have the MTD app activated with this setting.The action can be set to Block Access or Wipe data
Block Access: The user account associated with the app will be blocked from accessing the organization's data if the threat level determined by the MDT (Mobile Threat Defense) is not met for example if the value is set to secure and MDT vendor app identify a threat in the end-user device the user won't be able to use the app to access organization data.
Wipe Data: The user account associated with the app is wiped from the device if the threat level determined by the MDT (Mobile Threat Defense) is not met.
Primary MDT Service This setting will define which MTD vendor should be used on the end-user device, this is required if there are multiple MTD connectors configured in Intune, as a prerequisite you should set the Max allowed device threat level settings for this setting to be applicable. We can only set Values for that and no action for thisitemsSkype setting.
There are two values available
Microsoft Defender for Endpoint if the MTD connector is configured for MDE specify that for providing device threat level information
Mobile Threat Defense (Non-Microsoft) if the MTD connector is configured for non-Microsoft MDT specify the non-Microsoft MTD for providing device threat level information
Step 5: Assignments
Now the policy is created, the next step is to assign the policy by adding a security group, Tap on Add Group -> Select the group you want to deploy the policy and tap on Select
This will add the group to the Policy and tap on Finish and this will take you to the review and Create page review the settings and tap on Create to complete the policy creation and assignment
Conclusion
In this article, you learned about settings related to app protection policy for iOS/iPadOS and the blog will help you understand each setting its values, and actions and create the best settings that match your environment security needs or requirement
In case you have not yet read my blog on app protection policy, here is the link. It will help you understand the app protection policy and how it works.
Comments