Intune

iOS Device Management via Microsoft Intune using Apple Business Manager (ABM)/Apple School manager(ASM)- Full Guide

The entire demonstration of this post which illustrates a deep dive on iOS device management using ABM/ASM via Intune can be found below-

Enrollment Methodologies for iOS device to Intune

• There are various modes of enrolling an iOS device to Intune. We should select the mode on the basis of type of device(Corporate or Personal) and the kind of enrollment experience we wish to have.

• As seen below we can categorize iOS device enrollment to Intune into 4 broad types. Each of these enrollment techniques offer a different experience and are suited for different purpose.

In this article we are going to understand Apple Device Enrollment to Microsoft Intune in detail.

Background/Need of ADE enrollment

• ADE is a program for bulk iOS device enrollment and is equivalent to – Autopilot for iOS | Samsung’s KME / Google’s Zero-touch enrollment for Android Enterprise
• Devices like iPhones and iPads can be shipped directly to users and enrolled to Intune as a part of oobe setup. Devices can be purchased from Apple reseller or existing devices can be converted.
• The admin can control the oobe of the device by streamlining the experience and accepting the defaults.
• ADE is used for Corporate Bulk Enrollment, Supervised mode and devices with/without user affinity
• Even mobile no. can be collected | Everything can be managed.

Apple introduced supervised mode in iOS 5.
An iOS device in supervised mode can be managed with more controls like silent app installation, restricted access to apps, lockable MDM enrollment, Kiosk mode, activation lock bypass, turning off AirDrop or preventing access to App Store. etc.
Support for unsupervised DEP devices was deprecated in iOS 11. Now DEP configured devices should always be supervised.

Comparison with Autopilot

Autopilot(for Windows) and ADE (for iOS) pretty much serves the same purpose. Lets do a quick comparison between both of them to get a better understanding.

Understanding the Background Flow

The background flow behind an ADE enrollment is not very well documented. Lets understand the same below via few diagrams.

Understanding the components:

In the below diagram we have few blocks. Lets understand each of them first.

• ABM/ASM: This is owned by Apple. Think of this like an Autopilot service but instead its owned by Apple. Devices communicate with this service over the internet.
• Intune : Microsoft’s MDM SaaS service in Azure
• Mobile Device: The user’s iOS device which we are trying to enroll to Intune
• Apple Activation Service: Cloud hosted service. This service is responsible for activating an iOS device when it connects to the internet. (For Analogy- Like a Windows devices checks in with WuFB service hosted in cloud to receive updates). Similarly Apple Activation service is another service to which the iOS devices checkin in order to get themselves activated.

Step 1-

• The mobile device in the diagram has a serial number which needs to be uploaded to ABM/ASM portal(Analogy- Just like in case of Windows Autopilot, we upload the hardware hash/Serial no. of Windows device to Autopilot service). This step has to be done by the admin. In this step the admin is uploading the serial number of all the devices to his company’s ABM instance.

Step 2-

• Now in the diagram we see, there are some devices present inside the ABM/ASM block. These were the devices purchased and uploaded in the previous step.

Step 3-

• Now lets say we want to use ABM/ASM with Intune(we have an option of using ABM with any MDM). There needs to be a relationship and trust established between my ABM instance and my Intune portal so that both can talk with each other. (Analogy- There are so many different tenants in Intune. ABM doesn’t know which is our Intune tenant. Hence we need to setup a trust to our tenant). We do that by creating a MDM server in our ABM instance. This MDM server is going to contain information on where our Intune tenant is. However our Intune tenant doesn’t know where the ABM instance is- hence in the Intune console we create a ADE token via which Intune can reference ABM.

Like i have an ABM istance, every company will have their own ABM instance. Like i have an Intune tenant, every company will have their own Intune tenant. Hence by creating an MDM server(in ABM) and ADE token(in INtune) and linking them both i can ensure that my ABM instance is communicating with my Intune tenant) Analogy-> This is similar to how we do the integration between Apple and Intune for setting up of APNs

Step 4–

• Once the MDM server is created, the admin will assign all the devices(uploaded in Step 1) to a MDM server. All the iOS devices in ABM instance donot have to be assigned to the same MDM server. Once the assignation is done, a sync happens between ABM and Intune service. Now the device details of all the iOS devices which were assigned to the MDM server are going to be sent to the Intune service. Now if i go to Intune, i’ll be able to see all the devices(which were assigned to the linked MDM server in ABM)

Step 5-

• Now in Intune we have the device. Next step is creating something called a ADE profile.
• Why do we need it–> The end goal here is customizing the oobe of the iOS device and enrolling it to Intune. For us to customize the oobe, there has to be a profile which is going to contains the setting on which screens should be made visible to the device during oobe. That setting is contained in the ADE profile.(Analogy- The ADE profile is equivalent to an Autopilot profile which is assigned to a Windows device)

ADE profile<=>Profile that contains the oobe settings which the device must follow<=> Each device must be assigned with an ADE profile in order to enroll successfully.
We can have multiple ADE profiles in our tenant and assign them to respective devices if we want different devices to have different oobe experience.

Step 6-

• Once an ADE profile is assigned to device, now a sync runs again and Intune service informs ABM about which ADE profile (and its settings) has been assigned to which device.
• Now ABM knows that Device 1 has Profile 1 assigned to it and Device 2 has Profile 2 assigned to it and the settings contained in Profile 1 and Profile 2.

Sync Schedule:
The admin can initiate a sync from the Intune portal every 15 min. When a sync is initiated, Intune goes to ABM and fetches the details of the device assigned to the relevant MDM server.
By default, Intune syncs with ABM every 12 hours(which is a delta sync) and there is a Full Sync every 7 days.
Every time a ADE profile is assigned/removed from a device from the Intune portal the same info is synced to ADE immediately and automatically.

Step 7- User Powers on the device

Now the end user powers on the device. The first 4 screen that the user sees is standard where he has to select the Language and Location as seen below and then connect to the internet

Now lets take a look over a new diagram as seen below to understand the next steps

Step 8-

• The moment the device is connected to the internet, it reaches out to the Apple Activation Service, in order to get itself activated.
• For the device activation to happen there should be open internet connectivity.

Step 9-

• Now the device identifies that its not a normal device(which would undergo a normal oobe) but a special device which has a special kind of profile assigned to it. After the device has got activated, it reaches out to the relevant ABM instance and the device is told that has a Profile and MDM assigned. The devices gets the address of the MDM service(which in this case is our Intune tenant)

Step 10-

• Now the device is activated and it knows that it needs to go to a MDM. The device now also knows the Intune endpoint where it is supposed to go to. Hence now the device goes to the Intune service and downloads the ADE profile which contains the oobe settings and undergoes the same.

• The device now gets the below screen after receiving the ADE profile.

• Now the device undergoes a customized oobe. Whichever screens were made visible to the device as per the ADE profile (like Appleid, Location Service etc), those screen are going to be shown to the device.

• Below screenshot shows the various oobe screens that can be configured in the ADE profile. As an admin, we have an option of either showing these screens, or hiding them.

• Now if the configuration permits, Company Portal app gets downloaded, user signs into it and selects the category and finishes the enrollment process.

Summarizing the Flow:

Important: Understanding the Uniqueness in ADE Enrollment Flow:

• In case of Windows, the device first gets AAD Registered/AAD Joined and then Intune enrolled(if MDM scope for Autoenrollment is set and if the user is licensed for Intune). However in case of ADE enrollment, the flow is different.

In this case, the device gets enrolled to Intune first and the AAD Registration happens later!!

So its possible to have an iOS device ADE enrolled to Intune, but not AAD Registered. This would usually happen if the user has not signed into the Company Portal- Typically in case of devices without User affinity where there is no user associated with the device.

• When the device is at the desktop screen and the user has NOT logged into the Company portal app-> At this point the device is already Intune enrolled. We can see an entry of this device in the Intune portal. However at this state the device is NOT AAD Registered. If we go to the device’s record in Intune we will see that the device has an IntunedeviceID, hence the device is enrolled to Intune. The device also has followed the naming convention as per the ADE profile and is Compliant to Intune. Its last checkin time has also updated. However its AzureADDeviceid is 000000000-0000-0000 as seen above.

• When the user logs into the Company portal-> At this point the AAD Registration happens and the AAD record gets created. At this screen the UDA(user device registration) happens and the Primary UPN is updated in the portal. After this the AzureADDeviceID is populated in the portal.

Hence, AzureADDeviceID for the device is created after the user has logged into the Company portal app and the UDA has established. The IntunedeviceID and AzureADDeviceID will always be different for the device.

Collaborating the Flow with Device Side Console LOGS:

FLOW AS PER THE LOGS:

Device getting Activated

Device getting info. of the MDM and reaching out to MDM URL

MDM profile downloading and installing

Company Portal app being installed

CP app getting launched in Single app mode(Guided Access)

How to collect console logs from an iOS device using macOS:

The article below from Apple enlists the steps for collecting the Console logs of an iOS device using macOS.

https://support.apple.com/en-in/guide/console/cnsl1012/mac

Understanding the Console Logs:

• As seen in the console logs below, we can clearly see the device reaching out to the Apple Activation Service and getting Activated. There might be errors in this stage in case of any issues with network connectivity.

• Also in the Console logs we can see the device is reaching out to the Intune Service endpoint and downloading the ADE profile. The profile contains the items which are to be skipped in the oobe while provisioning which can be seen in the logs.
• By looking at the logs in this step we can confirm the oobe screens that the device is receiving from Intune. If the device is receiving a screen which it should not, checking this log should be the starting point.

• Once the profile has been downloaded, the same is installed and logged as seen below. If there are any issues with the MDM profile installation during enrollment, this log would reflect the same.

• As seen below, once the device is enrolled, we can see the device now starts communicating with the Intune service at a regular endpoint. If there are any issues with the policy delivery from Intune due to network constraints, this log should reflect the same.

• We can see the Tenantid as well, in the logs to which the device is reaching out while communicating.

• Now if there are any ‘Required’ Applications deployed to this device, the same would start getting downloaded and installed automatically which is logged. The log contains the bundleid of the application as seen below. If there are any errors while app delivery/installation, the same would be logged here with an bundleid and error code which can be used for troubleshooting.

• If we are using Guided Access Mode, we can see the same getting logged as well as shown below

ADE Enrollment Methodologies to Intune

There are various ways by which an iOS device can be enrolled to Intune using ADE. As an admin we have an option of making many kinds of ADE profiles- each targeted for a specific usecase. The below diagram illustrates the various options available while creating an ADE profile.

User Affinity with Company portal

• The first way of our modern way to do DEP enrollment where MFA, change of user password at first sign-in are supported.
• Using this method, the Company Portal should not be deployed to the devices or users (as ‘Required). The DEP profile will download it automatically.
• With this method the user will need to add his Apple ID to download the Intune Company portal and complete the enrollment.
• The downside of this method is that after the user adds his Apple ID and the Intune Company Portal is installed there is nothing that will force the user to open the company portal to complete the enrollment.
• Also, some Admins don’t like to have his users to have personal accounts (Personal Apple ID) on Corporate devices which the user might enter in the oobe screen.

User Affinity with Company Portal through VPP

• This is method will allow the Admins to push the Intune Company Portal with the ADE enrollment profile and will not require the final user to add his\her Apple ID on the device.
• This way the Admin may have full control on what apps are install on the device, and he also can allow or block the App Store, and still be able to deploy apps to the device.
• Using this method, the Company Portal should not be deployed to the devices or users as required, the ADE profile will download it automatically.

User Affinity with Company Portal through VPP and Single app mode

• This is a very secured method because after we install the Enrollment Profile, Company Portal will be installed via VPP but while we are on the home page waiting for the Company Portal to be installed the device will be lockdown avoiding any unwanted downloads from the final user.
• After the Intune Company Portal gets installed, it will open automatically and the user will not be able to exit the app until he/she completes the enrollment and pass compliance.
• Once the Company Portal gets installed the device will enter in Single App Mode with the Company portal, which means that we won’t be able to go outside of the Company Portal app until we complete the Enrollment and the device is compliant.
• If we use this method and select to show the apple ID in the oobe screen as set in the ADE profile, the time from the Welcome screen ,to the installation of the Intune Company Portal can take longer due to all the information that the Apple ID used must download to the device.
• The below Pop-up is not an error, is just telling that the Guided Access App (the Intune Company Portal) is not available, this is expected.

However as on 2024, this is not a supported flow by Apple for iOS/iPadOS automated device enrollment (ADE).
In the first half of calendar year 2024, we’re removing the ability and functionality for the “Run Company Portal in Single App Mode until authentication” setting.
Devices will not be able to enroll through this method and you will not be able to save new enrollment profiles with this setting configured.

User Affinity with Apple Setup Assistant

• This is a Legacy method of enrollment to ABM
• This method lets us chose if we want our device to be Supervised or not, as a part of ADE enrollment. (Even though now the support for unsupervised ADE devices is not deprecated and the device has to be Supervised)
• In this method Intune Company Portal is not mandatory. However if customers want to make use of Azure’s features like Conditional Access then they would need the Company Portal app.

Special Modes in ADE Enrollment:

1- Guided Mode:

• We can set the configuration of ‘Run Company Portal in Single app mode’ to ‘Yes’ to turn the Guided Access.
• This mode ensures that the end device is stuck at the below screen until Company Portal app is downloaded and installed
• After Company Portal is installed the same is launced automatically and the end user cannot exit the same- thus forcing him to loginto the app.

Advantages of using Guided Access: Using this mode forces the end user to download/install/launch and register using Company Portal app. hence this is a subtle way of ensuring that the devices get AAD Registered and the end user cannot bypass the process.

2- Await Final Configuration: (ESP for iOS!!)

• We can think of this mode as ESP for iOS devices(similar to Windows)
• This MDM command is sent and devices are locked in ‘Awaiting final config’ state until admin specified settings (commands for apps) are installed before releasing the end user to the home screen.
• Critical for delivering a secure provisioning experience where the most important policies(and apps) are on the device as soon as the end user hits the home screen ensuring the device is protected upto the org’s standards.
• This is a 1 time oobe experience during device’s setup.
• In this phase, Intune computes the assignment of the device and pushes settings. Once done, the device is released to home screen.
• The time at this screen- Depends on no. of policies deployed + If user is part of huge security group

Advantages of using Await Configuration: Implementing this feature ensures that until all the needed Security policies +App installation initiation is done, the device is not released to the home screen. Hence the user cannot bypass any security measures.

If this setting is not enforced, the user can go to the home screen and install apps which are restricted OR open websites in the browser which are blocked as per the policy. He would be able to do so until the policy from Intune comes down which might take a while- thus providing a window of opportunity to a malicious user.

Microsoft Recommended Method of Corporate iOS Device Enrollment

• The Microsoft recommended method of doing ADE enrollment is via ‘Setup Assistant with Modern Authentication‘.
• The configuration for the same should be as shown below.

This recommendation has been documented by Microsoft below articles:
●https://techcommunity.microsoft.com/t5/intune-customer-success/move-to-setup-assistant-with-modern-authentication-for-automated/bc-p/3193803#M3192

●https://techcommunity.microsoft.com/t5/intune-customer-success/transforming-the-ios-ipados-ade-experience-in-microsoft-intune/ba-p/4013312

ADE Enrollment Guide from Microsoft

There is a wonderful guide in Microsoft’s documentation on how we can get started with the configuration for ADE enrollment via Intune. It enlists the different options and a comparison between all the methods. Kindly refer below for the same-

https://learn.microsoft.com/en-us/mem/intune/fundamentals/deployment-guide-enrollment-ios-ipados

Recommendation and Recent Change

• Lets assume that our ADE profile has the configuration of “Enroll with User Affinity” + “Select where users must authenticate” setting is set to “Setup Assistant” + “Install Company Portal” is set to “No” as seen below-

• Now after the device has been enrolled with the above configuration, lets say that the admin decides that the users now should have Company Portal app on their devices or the end user decides to install Company Portal app on his own (to make use of features like Conditional Access policy)
• Changing the “Install Company Portal” is set to “Yes” wont work on the existing devices unless we factory reset the device and download the ADE profile again.
• In such cases, the only option is to Deploy an app configuration policy from Intune and then deploying the Company portal app which we are going to see below.

Scenario:

Lets assume we don’t have any app configuration policy, and the device was enrolled with the ADE profile(“Enroll with User Affinity” + “Select where users must authenticate” setting is set to “Setup Assistant” + “Install Company Portal” is set to “No”). Now lets say that the user downloads the Company Portal app from the app store and logs into it, below would be the experience.

Device is already enrolled with ADE and has an MDM profile installed, however when we download and login to the Company Portal app- a confusion is created. The Company Portal thinks that this is a fresh enrollment and it downloads and tries to install a new MDM profile. The installation of the new MDM profile fails as we cannot have multiple at the same time and hence the user cannot register himself with the company portal application.

Now lets take a look over the device’s behavior:

Solution:

• We will have to create a corresponding App Configuration policy to send down alongside the Company Portal application to the device group containing the device.

The same has been documented in Microsoft’s official documentation below-
https://learn.microsoft.com/en-us/mem/intune/apps/app-configuration-policies-use-ios#configure-the-company-portal-app-to-support-ios-and-ipados-devices-enrolled-with-automated-device-enrollment

Scenario (with the above solution implemented):

Now we have an iOS device which has been enrolled with ADE profile with setting- “Enroll with User Affinity” + “Select where users must authenticate” setting is set to “Setup Assistant” + “Install Company Portal” is set to “No”. Also the above app configuration policy has been deployed to a dynamic device group containing the device.

Lets take a look over the end device’s behavior with the above setting in place:

Now lets take a look over the device’s behavior:

Hence as we can see above, by using the App Configuration policy, the AAD Registration of the device now happens successfully using the Company Portal application

• The above solution is to be used when the ADE profile has the setting- “Enroll with User Affinity” + “Select where users must authenticate” setting is set to “Setup Assistant” + “Install Company Portal” is set to “No”
• Deploying the app configuration policy is to be followed for existing devices.
• For new devices, we should create a new ADE profile and set the “Install Company Portal” option to “Yes”.

Migrating ADE devices to Intune

If we have Corporate devices enrolled to a 3rd party MDM and want to migrate to Intune, the below blog shares some tips that we must keep in mind before doing the migration.

https://techcommunity.microsoft.com/t5/intune-customer-success/migrating-ade-ios-devices-to-intune/ba-p/1898028

Useful Materials and Links:

https://poemtomdm.fr/2023/02/26/enroll-a-corporate-macos-device-in-intune-through-apple-business-manager/
https://blog.innofactor.com/en/configure-integration-between-apple-dep-and-microsoft-intune
https://www.youtube.com/watch?v=GQ6ltOlky8&list=PLsQvWCqkfYgQd4Sr8l08mX7tMRyCBy7P
https://www.youtube.com/watch?v=J_7p61EN45w&t=198s
https://developer.apple.com/business/documentation/MDM-Protocol-Reference.pdf
httpswww.ibm.comdocsenmaas360topic=configurator-converting-non-dep-ios-11-devices-dep
https://support.apple.com/en-in/guide/apple-configurator-2/cad99bc2a859/mac
https://discussions.apple.com/thread/251112916
https://support.apple.com/en-in/guide/apple-business-manager/axm402206497/web

I hope this article was helpful in learning about the background and need of ADE enrollment as well as the flow that happens under the hood during its provisioning.!