Introduction
In the previous blog post the implementation and configuration of Intune on Windows devices was explained. In this part of the blog post I will describe the possibilities that Intune has, regarding to Mobile Application Management (MAM) and Mobile Device Management on Apple devices, including modern authentication.
Like Part I of this blog post, a fictitious scenario was created in which a company is working fully in the Microsoft cloud. This company wants to give their employees not only internally but also externally access to company data, regardless of the device their using. Of course, the company wants to ensure that company data can only be consulted if the devices are secure and meet the company’s security policy. For example, it needs to be prevented that a jailbroken device and/or native email clients, that does not support modern authentication, can access company data.
This blog post will describe the following steps:
Apple configuration in Intune
- Installation of the Apple push certificate
Configuration and compliance settings
- Configure the device compliancy settings
- Configure the iOS device compliancy policies
- Create conditional access policies
- Create application protection policies
How does the end user experience look like?
- User experience with the native email client
- User experience with the Outlook app
- Installation of the Intune Company Portal App
After a successful implementation and configuration of Intune on Apple devices, the result presented in figure 1 is derived, i.e. denying or granting access to company data when an employee is trying to get hold of these data by using, respectively, a non-compliant or compliant device.
Figure 1. User experience when accessing data on a Non-Compliant Apple device (left) and on a compliant Apple device (right).
Apple configuration in Intune
Before one can configure device compliance, compliance policies and conditional access policies in Intune, the Apple Push Certificate configuration must be setup. Please see the detailed steps below.
Apple Push Certificate
The Apple push certificate is required when managing mobile iOS devices. Keep in mind that an Apple ID is required for this configuration. Open the Azure Portal -> Intune -> Device Enrollment -> Apple Enrollment -> Apple MDM Push certificate (figure 2).
Figure 2. Configuration of the Apple Push Certificate.
Create the Intune signing request (IntuneCSR) and download this file onto the pc and select “Download your CSR“. Next click on “Create your MDM push certificate” and enter the Apple ID to create an Apple MDM push certificate. In the Apple Push Certificates Portal select “Choose File” and upload the IntuneCSR displayed in figure 3 and 4.
Figure 3. Download the Intune certificate signing request and create an Apple MDM push certificate.
Figure 4. Upload the certificate signing request.
When the file is valid the certificate can be downloaded (figure 5).
Figure 5. Download the Apple Push Certificate.
Next upload the downloaded Apple MDM push certificate in the portal, please see figure 6, and click on “Upload”.
Figure 6. Upload the MDM Push Certificate in the Intune portal.
After the configuration has been successfully performed, make sure that the status of the Push Certificate is “Active“, see figure 7.
Figure 7. Status of the MDM Push Certificate.
Important! Keep in mind that the certificate needs to be renewed once a year.
Configuration and compliance settings
Device Compliance Settings
For the configuration regarding to the Device Compliancy settings please see my previous post, Protect your data with Microsoft Intune – Part I: https://woutervisser.net/2019/02/13/protect-your-data-with-microsoft-intune-part-i/
iOS Device Compliancy Policies
Device compliance policies are used to ensure that the device which is used to access company data is compliant to the company security policy. If the device does not comply to this policy, access to company data can be prevented. In the current example a device compliancy policy will be created for iOS.
On the iOS devices the policy is configured in a way that access from a jailbroken device will be blocked, the minimum iOS version must be 11.1.3, the user must use a password to unlock mobile device and the use of simple passwords is not allowed. To do this open the Azure Portal -> Intune -> Device Compliance-> Policies -> Create Policy (figure 8).
Figure 8. Create Device Compliance Policy.
Give the policy a name and select “iOS” as the platform. The next configuration of the device compliancy policy is the email setting. If this setting is set to “Require”, then devices that do not have an email profile managed by Intune will be considered as non-compliant. In this case this feature is not used. Therefore, make sure that it is set to “Not configured”. To do this open the Settings -> Email (figure 9).
Figure 9. Device Compliancy Policy – Settings – Email.
In the fictional scenario it must be prevented that jailbroken devices can have access to company data. Therefore, the configuration will block such devices. To configure this setting go to Device Health and select “Block” (jailbroken devices). The “Require the device to be at or under the Device Threat Level” setting is in this case set to “Not Configured” (figure 10).
If one is willing to use the Device Threat Level functionality, it must be configured in relation to the threat Defense services. Devices which then will exceed the threat level will get marked as non-compliant (this compliance check is only supported for devices with iOS 8.0 and above).
Figure 10. Device Compliancy Policy – Settings – Device Health.
Under the device properties configuration, it is possible to select the minimum and maximum iOS version. Also, the minimum and maximum iOS build version can be configured. In this case only a minimum iOS version of 11.1.3 Devices is required and devices with a lower iOS version will not be marked as compliant. To do so open the Device Properties (figure 11).
Figure 11. Device Compliancy Policy – Settings – Device Properties.
The security configuration that will apply can be configured under System Security. A various set of settings such as block simple passwords, password expiration, minimum password length and password type can be configured by the System Security. In this case the settings were configured as follows; a password is required to unlock mobile devices, simple passwords will be blocked, minimum password length is 6, password type is numeric, the password expiration days is set to 90 and the number of previous passwords to prevent reuse is set to 5. These settings are shown in figure 12.
Figure 12. Device Compliancy Policy – Settings – System Security.
Also, two actions can be configured to inform an employee when his/her device is not compliant. In this fictious scenario, the employee will be notified via an email. Therefore, notification templates must be created. The first notification will be sent 24 hours after non-compliance. In this notification the user will be notified that actions must be taken to make the device compliant within three days. After three days the device will be automatically marked as non-compliant. To do so open the Actions for noncompliance -> Add (figure 13). The required steps for making notification templates can be found in my previous blog: Protect your data with Microsoft Intune – Part I: https://woutervisser.net/2019/02/13/protect-your-data-with-microsoft-intune-part-i/
Figure 13. Device Compliancy Policy – Actions for noncompliance.
Click “OK” and then “Create” to create the policy. The last step of this configuration is to assign the device compliancy policy to the correct group. To do so open the Azure Portal -> Intune -> Device Compliance-> Policies -> IOS Device Compliancy Policy – Assignments (figure 14).
Figure 14. Device Compliancy Policy – Assignments.
Conditional Access Policies
Conditional access policies will be used to control if devices and apps are granted access to company data such as email. In the fictional scenario a device must be compliant to the conditional access policies before granting access to company data.
Create a Conditional Access Policy for iOS
In the Device compliance policy, a few settings are configured to which the device must comply before access to company resources is provided. An example of a setting to which the device should comply is that the device must have minimal iOS 11.1.3 installed. In the conditional access policy, it is configured that the device may access company data, but only if it meets the configured conditional access policy requirements. In the conditional access policy, it can be configured that only approved client applications, such as the Outlook app, may access company data. To create the conditional access policy, go the Azure Portal -> Intune -> Conditional Access -> New Policy (figure 15).
Figure 15. Create new Conditional Access Policy.
Give the policy a name and Select Users and Groups -> select Users and groups then select the Azure AD Group to which this policy applies. In this case no groups are excluded (figure 16).
Figure 16. Conditional Access Policy – Select Users and groups.
In the next step it is possible to select which cloud applications one wants to include or exclude from the conditional access policy. In this fictious scenario, all cloud applications are selected without excluding any apps. This means that conditional access is applied to all available cloud applications. Go to Cloud Apps (figure 17).
Figure 17. Conditional Access Policy – Cloud Apps.
This conditional access policy will be applied to a specific platform, namely iOS. Go to Conditions -> Device Platforms, click configure “Yes”, followed by “Select device platforms” and include only “iOS”, to make this policy specific for Apple iOS devices (no exclusions were made), please see figure 18.
Figure 18. Conditional Access Policy – Conditions – Device Platforms.
In this case no Locations and Device state are configured. Under the Client apps select the client apps to which the policy should apply to as shown in figure 19.
Figure 19. Conditional Access Policy – Conditions – Client apps.
Only compliant Apple devices can get access to company data. Go to Access Controls -> Grant -> “Grant access” select “Require device to be marked as compliant” and “Require approved client app”. This means that the device must be Intune compliant and the device must use approved client apps. Finally, select “Require all the selected controls”. If the device is non-compliant, the user will be prompted to make the device compliant. Save the configuration and do not forget to enable the policy (figure 20)!
Figure 20. Conditional Access Policy – Conditions – Grant.
Client Application Protection Policies
By using client application protection policies, it is possible to configure protection per application to make these more secure. In this case, for example, it is possible to prevent employees from making backups from their device using iTunes and/or iCloud. In addition, one can also prevent copying data from a certain app or only allow this if the data remains within the approved client applications. It can also be configured that an employee must first enter a code before he/she gains access to the application. Using application protection policies, gives one the opportunity to make (mobile) apps much safer. How that can be configured is explained in the steps below.
Create Application Protection Policy for iOS
Open the Azure Portal -> Intune -> Client Apps -> App Protection Policies -> Create Policy.
Type in the policy name, select iOS as the platform and select the applications that must fall under this policy (figure 21).
Figure 21. Application Protection Policy – Create Policy – Apps.
Next, select Settings -> Data Protection and click on “block” backup Org data to iTunes and iCloud backups, send Org data to other apps “All Apps”, receive data from other apps “All Apps”, save copies of Org data “Block”, allow user to save copies to selected services select “OneDrive for Business” and “SharePoint”, restrict cut, copy and paste between other aps “Policy managed apps with paste in”, encrypt Org data “Require”, sync app with native contacts app “Enable”, printing Org data “Enable” and third party keyboards “Disable” (figure 22).
Figure 22. Application Protection Policy – Create Policy – Settings – Data protection.
Next configure the access requirement settings, select Settings -> Access requirements and configure this as follows; pin for access “Require”, PIN type “Numeric”, simple PIN “Block”, select minimum PIN length “6”, PIN reset after number of days “Yes”, number of days “90” and App PIN when device PIN is set “Enable” (figure 23).
Figure 23. Application Protection Policy – Create Policy – Settings – Access requirements.
The conditional launch settings also contain some access protection features and gives the opportunity to undertake immediate actions in case devices do not meet the given values. Select Settings -> Conditional launch. In this scenario it is configured as follows; minimum OS version “11.1.3” action – “Warn”, max PIN Attempts “5” action – “Reset PIN”, offline grace period “720” (minutes) action – “Block access”, offline grace period “90” (days) action – wipe data and jailbroken/rooted devices action – “Block access” (figure 24).
Figure 24. Application Protection Policy – Create Policy – Settings – Conditional launch.
After the policy is created it is time to assign the policy to the correct group. Open the policy and select Assignments -> Include (figure 25).
Figure 25. Assign the Application Protection Policy to a group.
The result: Accessing company data from an Apple device
All these configuration steps will ultimately result in denying or granting access to company data from an Apple device. Figure 26 shows the user experience when an employee wants to configure email in the native email client on iOS.
Figure 26. Non-Compliant Apple device and/or with native email client.
As presented in figure 26, the employee cannot successfully configure company email in the native email app on iOS, because the device and/or email client is not allowed to access company resources. To access company resources the employee must make sure that the device is compliant with the polices as configured in this post. Also, the employee needs to make use of the Microsoft Outlook email app. If the device is compliant and the Outlook app is installed, the employee can access company data as shown in figure 27.
Figure 27. Compliant Apple device in combination with the Outlook app.
Installation of the Intune Company Portal App
The configuration of the Company Portal in Intune is described in my previous blog: https://woutervisser.net/2019/02/13/protect-your-data-with-microsoft-intune-part-i/
After completing the configuration of the Company Portal, one has the possibility to use the Company Portal app on iOS. This can be found and downloaded in the Apple Store. The Company Portal app provides the possibility to make apps available for the employees to use. Apps that are pushed from Intune will appear in the Company Portal app of the employee. Please see figure 28 for the installation and signing in to the Company Portal app in iOS. In case the device is fully managed within Intune Mobile Device Management, it is also possible to wipe company data in the event that an employee loses his/her device(s).
Figure 28. Installation of the Company Portal app on iOS.
As previously indicated, in the next blog post I will describe the steps required for the configuration of Intune on Android devices, including conditional access policies.
Everything Cloud 