Device Enrollment Workflow

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

MS Intune: Device Enrollment Workflow for Android, IOS Devices

Below is the workflow categorized into 18 steps that run in the background
whilst the devices are being enrolled into MS-Intune:

Begin:
1. For enrollment, user has to first download the Company Portal for Android and
IOS. Once installed, user will launch CP.

2. Login will start and with the login, CP will automatically note the OS of the
device, Make and Model of the device, Time Stamp of login. These 3
attributes will help us for log capturing.

3. Now, if the device is connected to the internet, CP would look for APNS (Apple
Push Notification Services) for IOS Devices OR GCMS (Google Cloud Messaging
Services) for Android Devices. Concurrently, CP itself will verify the integrity of
the app installed by checking for the right/supported version installed on the
device.

Note: Google Cloud Messaging, deprecated April 10 2018, has been deactivated and
removed from Google's APIs. For equivalent functionality, use Firebase Cloud Messaging
(FCM), which inherits the reliable and scalable GCM infrastructure, plus many new features. If
you are an existing GCM user who has not yet migrated your system, see the Migration
Guide: https://developers.google.com/cloud-messaging/android/android-migrate-fcm

4. User will now see the Sign-In screen

5. User clicks on Sign-In and then CP connects to MS Graph Service in backend,


which will display the appropriate page to enter the UPN (User Principal Name) of
the user. User enters UPN

6. Authentication process would happen to check if the user has entered right UPN.
As Azure Cloud have multiple tenants/domains in the cloud, user has to be
directed to the right tenant/domain out of many in the cloud. This entire process
for finding the right home tenant for the user is referred to as HRD (Home
Realm Discovery). Then authentication is done.

7. If the CP Branding is configured in the Home Tenant, user will see it, and user
will be prompted to enter the Password

8. Once the Credentials are entered, they would be either sent to Azure AD or
ADFS (Active Directory Federation Services) for Authentication depending
on the configuration.

9. If it is with Azure AD then it would go to a service running in Azure Cloud called


Azure STS (Secure Token Service) for authentication.
Else, Azure will redirect the user to ADFS, ADFS to DC (Domain Controller),
DC will do the Authentication, DC will redirect to ADFS, ADFS at last will redirect
to Azure AD.
If Authentication fails, user will get a prompt accordingly, Authentication
successful workflow continues.
SAML (Secure Assertion Markup Language) is the protocol used throughout
whilst the user was being redirected from Azure AD to ADFS and vice a versa.

10. Independent of the authentication mechanism used i.e ADFS or Azure AD, it is
always Azure AD that will issue the token to the device AT, RT PRT, FRT,
MRRT.
AT: Access Token
RT: Refresh Token
PRT: Primary Refresh Token
MRRT:

11. Tokens/Certificates are saved in Device’s Keychain

12. Work Place Join (WPJ) happens now

13. WPJ also known as Azure AD Registration (Device gets registered to Azure,
applicable for Win, Android, IOS, MAC). Device ID is generated; Device Entry is
generated in Azure Portal. Enrollment will commence.

14. Azure will send the Discovery Urls to the device that was set in MDM Scope
from Intune Portal.

15. PKCS Generator component of the device (irrespective of the OS) will create
Certificate. This certificate has 2 attributes Public Key and Private Key. This
certificate will be sent to Intune Service

16. Intune Service will Stamp the Certificate, after performing few checks for–
License, Enrollment Restrictions.

17. Now, Stamped Certificate is sent back to Device, Public Key becomes the
Intune DeviceID. Intune DeviceID is always generated by Device and NOT
Intune.

18. Intune generates certificate SC_Online_Issuing Certificate sent to the device,


for communication between Device and Intune is done via this Certificate.
Compliance is marked – Yes or No in Intune Portal.

Note: Above workflow is similar for Android, IOS, MAC OS and Windows too except for
the Windows device without CP application.
Flowchart for Device Enrollment Workflow

1 10

User launches CP Azure AD issues token-


AT,RT,PRT,MRRT to device

2 11
Login process begins > OS, Make- Tokens/Certs are saved in
Model, Time Stamp Captures for log Device's Keychain
analysis

3 12
Internet connected, device will look WPJ happens
for APNS (IOS)/GCM or FCM for
Android Services

4 13
Sign-In page displayed Device ID generated > device
entry in Azure Portal >
Enrollment commences

5 14
User clicks Sign-In>CP connects to MDM Scope > Discovery Urls from
MS Graph Service > UPN entered Intune sent to device

6 15
HRD process PKCS generator generates cert. >
cert sent to Intune

7 16
CP Branding displayed > Password Intune stamps the cert. after few
entered checks

8 17
Credentials sent for authentication to Stamped cert. sent to device >
Azure AD or ADFS Intune DeviceID created

9 18
If Azure AD > Azure STS for Intune generates
authentication SC_Online_Issuing cert. > cert.
OR sent to device > Compliance
ADFS > DC > Azure AD for marked Yes or No in Intune Portal
authentication

You might also like