Android Enterprise Dedicated device in Azure AD Shared device mode – Learn Intune with Joy

With the October service release last month, Microsoft Intune (a.k.a Microsoft Endpoint Manager) introduced a new feature that enables organizations to automatically provision an android device in Azure AD Shared device mode with Android Enterprise Dedicated device enrollment mode.

Today we will look into this new feature, learn the required configurations that need to be created in the environment to support it, and finally see how it works.

So let’s get started.

What is Azure AD Shared Device mode?

As stated in Microsoft’s documentation, Azure AD Shared Device mode enables an organization’s employees, typically Firstline workers, to use organization apps across a pool of devices shared by those employees, providing an optimized experience enabling single sign-on across business applications, virtually making the devices “as theirs” for the duration of their shift. Post shift when the employee signs out (or if the employee forgets, then force sign-out triggered either by shift-end time or a period of inactivity), it removes all the preferences and user data, making the device ready for the next employee to pick up and sign-in to start working on it.

Your business applications, to support Azure AD Shared Device mode, must be made using the Microsoft Authentication Library (MSAL) for its auth functionalities and use the Microsoft Authenticator application to manage user state.

You can check Microsoft’s documentation on how to build applications to support shared device mode for your Firstline Workers. Also, check the easy step-by-step tutorial by Microsoft on how to use shared-device mode in your Android application.

However, application development is not my forte per se and as such, let’s get back to understanding how you can set up an android device in Azure AD Shared Device mode.

It is possible to manually set up an unmanaged Android device in Azure AD Shared Device mode by installing the Microsoft Authenticator app and manually configuring the parameters as can be seen in this reference document.

Note: Azure AD shared device mode only registers the device to Azure AD without any primary user set. No MDM enrollment. Hence, you would find the device object in the Azure AD portal under All devices and not in your MEM Admin Center portal.

I have tried the same on one of my test devices, an unmanaged Motorola G4 Plus model running Android 7.0 and this is how the device comes up under All devices in the Azure AD portal.

The process being manual as it requires an IT Admin with Cloud Device Administrator privilege to register the device, it is not at all functional if you would require to provision devices in bulk.

Except for Corporate Owned Dedicated devices which are without user affinity, all the other Android Enterprise management modes typically belong to use-cases with user affinity.

Thus with the demise of legacy device admin management, Android Enterprise COSU setup turns up as the perfect device platform for Azure AD Shared device mode. It is technically possible to provide an Android device as a Dedicated device [COSU] and silently pushes the Microsoft Authenticator app via Managed Google Play, but it still required the manual configurations within the Authenticator app to be done by an IT Admin to set it up in Azure AD Shared device mode.

Not anymore with the 2010 service release of Microsoft Intune.

Provisioning an Android device in Azure AD Shared Device mode with Android Enterprise Dedicated devices

The new feature streamlines the provisioning of Android devices in Azure AD Shared device mode with a new enrollment type under the category of Android Enterprise Corporate Owned Dedicated devices.

The process is identical to how we set up Dedicated devices [COSU] as KIOSK.

So lets us see what all Admin configuration is required to support the new feature.

Azure AD Shared Device mode – Create the Dedicated device Enrollment Token

In MEM Admin center, navigate to Devices > Android > Android enrollment and click on the Corporate-owned dedicated devices tab. Click on Create profile

Create the enrollment profile as below

Name	Give a suitable name for the enrollment profile
Description	[Optional]
Token type	The corporate-owned dedicated device with Azure AD shared mode (preview)

Post creating the profile, open it to view the QR Code and/or the Enrollment Token which can be provided to the onsite Tech support team to start provisioning the devices.

Create a Dynamic Device Group to contain devices configured as Azure AD Shared Device

It is always a standard approach to create a dynamic device group to contain devices enrolled with a particular enrollment profile, which can be later used to target policies and/or push apps to those devices silently.

Dynamic query: device.enrollmentProfileName -eq "(Enrollment Profile Name)"

Here we will create a dynamic device group to contain all devices provisioned with the enrollment profile as created in the earlier step.

Deploy Apps that support Azure AD Shared Device mode

Currently, Microsoft Teams and Microsoft Managed Home Screen are the only two Microsoft apps that support the Azure AD Shared Device mode.

You would need to Approve the apps from Managed Google Play and Sync for the apps to show up in Intune, and then deploy them to the dynamic device group as created earlier with the assignment set to Required.

If you are already managing Android Enterprise devices with Microsoft Intune, you already have the binding established between your Intune tenant and Managed Google Play. You can either visit the Managed Google Play portal or you can even Add apps from the Managed Google Play store from within the MEM Admin Center portal.

For the illustration purposes of this blog post, I have deployed the below three apps

• Microsoft Teams
• Managed Home Screen
• Microsoft Kaizala

Microsoft Kaizala does not support Azure AD Shared Device mode. I have deployed it to place it within a customer-facing folder (more on this later) and specify it as one of the apps for the Multi-App Kiosk profile.

Once you are done with deploying the apps, you would need to create an App Configuration policy for the Managed Home Screen app to support Azure AD Shared device mode.

Configuring Managed Home Screen to support Azure AD Shared Device mode

On a device enabled with Azure AD Shared device mode, the Managed Home Screen enables the end-user with the below functions.

• Sign-in screen to enter credentials and sign in at the start of their shift to start working

• Create a Session PIN at the beginning of the session, just immediately post sign-in, that lasts for the duration of their signed-in session, and can be used throughout the session to consent permissions, rather than needing to use credentials.

• Automatic sign-out after a period of pre-defined inactivity by the IT admin or

• Customer-facing folder on the Managed Home Screen enables the logged-in user to share the device with another person without the fear of accidental leakage of sensitive information since you cannot exit the folder post-launch without confirming credentials.

• Display a custom privacy statement link on the Sign-In screen along with the default Microsoft privacy statement link, to be displayed to the user.

You can configure the Managed Home Screen to support Azure AD Shared device mode using an App Configuration policy from Intune. Note that while creating the App Configuration profile, choose

Device enrollment type	Managed device
Platform	Android Enterprise
Profile type	Fully Managed, Dedicated, and Corporate-Owned Work Profile Only

For configuring the settings, you can either choose to use Configuration Designer for UI experience or go the Pro route creating a JSON of the configuration. Either way, you can check all the supported configuration and their associated value from here.

Note that not all settings are available to be configured with the Configuration Designer. You may as well want to go for the JSON if you are looking to configure settings like enabling and configuring a Customer-facing folder.

My sample JSON config is as below build with reference to Microsoft default

{
"kind": "androidenterprise#managedConfiguration",
"productId": "app:com.microsoft.launcher.enterprise",
"managedProperty": [
{
"key": "signin_screen_branding_logo",
"valueString": "https://www.anoopcnair.com/wp-content/uploads/2020/08/HowToManage-Devices.png"
},
{
"key": "custom_privacy_statement_url",
"valueString": "https://www.anoopcnair.com/author/Joymalyabr/"
},
{
"key": "custom_privacy_statement_title",
"valueString": "Joymalya's Privacy Agreement"
},
{
"key": "enable_PIN_to_resume",
"valueBool": true
},
{
"key": "auto_signout_time_to_give_user_notice",
"valueInteger": 60
},
{
"key": "inactive_time_to_signout",
"valueInteger": 300
},
{
"key": "enable_auto_signout",
"valueBool": true
},
{
"key": "enable_session_PIN",
"valueBool": false
},
{
"key": "enable_corporate_logo",
"valueBool": true
},
{
"key": "signin_screen_wallpaper",
"valueString": "https://avante.biz/wp-content/uploads/Asus-wallpaper-HD-for-zenfone-5/Asus-wallpaper-HD-for-zenfone-595.jpg"
},
{
"key": "signin_type",
"valueString": "AAD"
},
{
"key": "enable_mhs_signin",
"valueBool": true
},
{
"key": "show_device_info_setting",
"valueBool": true
},
{
"key": "show_managed_setting",
"valueBool": true
},
{
"key": "exit_lock_task_mode_code",
"valueString": "8992"
},
{
"key": "virtual_home_type",
"valueString": "float"
},
{
"key": "show_virtual_home",
"valueBool": true
},
{
"key": "screen_orientation",
"valueInteger": 1
},
{
"key": "icon_size",
"valueInteger": 2
},
{
"key": "wallpaper",
"valueString": "default"
},
{
"key": "managed_folders",
"valueBundleArray": [
{
"managedProperty": [
{
"key": "folder_name",
"valueString": "Customer Folder"
},
{
"key": "is_customer_facing",
"valueBool": true
},
{
"key": "applications",
"valueBundleArray": [
{
"managedProperty": [
{
"key": "package",
"valueString": "com.microsoft.mobile.polymer"
}
]
}
]
}
]
}
]
}
]
}

Note: Applications specified within the Customer Facing Folder(s) need to be deployed to the device as required and included in the Multi-App KIOSK config profile to run within Managed Home Screen.

Here you can see I have specified Kaizala (com.microsoft.mobile.polymer) as the app within the customer-facing folder.

Once you have created the configuration profile, assign it to the same dynamic device group as created earlier.

Create a Multi-App KIOSK profile to allow apps to run within Managed Home Screen

Now we need to create a Multi-App KIOSK Profile to enable Managed Home Screen to further lock down the device and show the end-user only the applications they need to work with. Now, this is a fairly simple task of creating a device restrictions configuration profile to customize the device experience.

Below is a reference snap for the Multi-App KIOSK configuration profile I have created for the purpose of this blog to showcase an Android Enterprise Dedicated device in Azure AD Shared device mode.

You can also add some password restrictions and other settings that you feel are required/applicable for a dedicated device scenario. Once done, you need to assign the profile to the same dynamic device group that you created earlier.

There is one more configuration item left to be created, but we will skip it for now.

At this point, we are good enough to start with device provisioning.

Azure AD Shared Device mode with Android Enterprise Dedicated devices – Device Provisioning Experience

The provisioning flow is similar to the Dedicated device enrollment that we do for a KIOSK setup, with few extra steps which are required to accommodate the following additional activities

• Install the required apps (Microsoft Intune and Microsoft Authenticator)
• Register the device into Azure AD Shared Device mode

Below is a numbered sequence of stages showing my test device going through the provisioning as an example.

Note that during the device provisioning, only the Microsoft Intune and Microsoft Authenticator apps are installed. Post provisioning, you will be presented with the device’s default android launcher initially.

Managed Home Screen and other apps along with config policies as deployed get enforced with a little bit of delay. This is because of the time taken for the device object to become a member of the dynamic device group.

How would you confirm that the device setup succeeded?

Open the Microsoft Authenticator app on the device post provisioning is completed and you would see that the device is in Azure AD Shared Device mode as shown below.

As I mentioned, you need to wait for a little bit of time just after completing the device provisioning to actually experience and start taking benefits of the Azure AD Shared device mode. This is because there is a little delay that happens for the device object in Azure to get associated to the dynamic device group to which rest of the policies and apps are deployed from Intune.

The Managed Home Screen launches automatically post-install and the device is now ready for use. 

Azure AD Shared Device mode – End-user experience

When the user picks up an Android Enterprise Dedicated device in Azure AD Shared mode from a pool of devices to be shared within a group of workers, to begin working, the user needs to first Sign-In using corporate credentials.

Further, the IT Admin can enable and require the worker to set the current session PIN which is actually helpful as the same can be used instead of requiring full credentials to resume back to a session or to provide consent to permission requests during the shift (work-time).

Once this is done, the worker is presented with the MHS Home Screen with the apps that are required for work.

Note that the Sign-In on the MHS screen triggers a device-wide sign-in and as such apps that support the Azure AD Shared Device mode will automatically sign in the currently logged-in user upon launch.

MHS Configuration allows the IT Admin to define the maximum inactivity period after which the current session will get terminated automatically.

IT Admin can also decide to enable end-user notification with a defined timer to notify of inactivity and the time in which the auto sign-out will happen. End-user can decide to either Resume to continue with the current session or Sign-Out.

Customer Facing Folder is another feature that the IT Admin needs to configure and enable.

This feature allows the currently signed-in user to quickly share the device with another person without the fear of leaking sensitive information.

If the other user tries to exit from the folder to access apps outside the folder, and if this is not contained, there is a potential risk of data leakage due to the device being in Azure AD Shared device mode meaning all app that supports it are signed-in device-wide.

Thankfully, that is not the case, as to exit from a Customer Facing Folder, the person would require to provide the current session PIN which should only be known to the user who is currently signed in.

If you try Exit from a Customer Facing Folder, you either get to resume with the session providing the current session PIN or you have the option to Switch user which will then sign-out the current user clearing the session data to begin the next session.

To end the session (at end of shift or break), a signed-in user can choose to sign-out from any app that supports Azure AD Shared Device mode. The sign-out from the app triggers a device-wide sign-out clearing session data and returning the device to the Sign-In screen.

Current signed-in users can also choose to end the session and sign-out from the Managed Settings screen of Managed Home Screen if enabled by IT Admin.

This completes the end-user experience, but…

Remember I mentioned that there is one more configuration item left but we skipped it anyway. It’s now the time to reveal the main twist in the plot…

Compliance Policy to evaluate device compliance of a Dedicated device in Azure AD Shared Device mode

Yes, you heard it right! We all know that Intune does not evaluate compliance for devices without user affinity. One reason would be the Built-in Compliance as enforced upon by default to all enrolled devices in Intune, checks for three base criteria

• Enrolled user exists
• Has a compliance policy assigned
• Is active

Since there is no real user account involved in provisioning a user-less device, you can understand that such a device will never satisfy the above and would always turn up as Non-compliant.

As such, by design, the Built-In policy stays as Not evaluated (and the overall compliance state) for a device without user affinity.

But now there is a change to this behavior with Dedicated devices with Azure AD Shared device mode as mentioned in the Microsoft Tech community feature release note.

You can create a compliance policy to evaluate

• SafetyNet device attestation level required
• Device Password requirements
• Encryption of data storage on the device

and assign to the dynamic device group containing your Dedicated devices enrolled in Azure AD Shared device mode.

Below is the sample test compliance policy I used.

Post compliance policy assignment is done, check back in the MEM Admin Center portal after some time for the device status and you should see as shown below.

Notice the other two Android Enterprise devices enrolled as Dedicated devices (default) is not being evaluated for compliance as usual. But the device enrolled with the Dedicated device in Azure AD Shared device mode is getting evaluated for compliance. Also notice that Enrolled by user UPN is NONE confirming that this is still a without user-affinity scenario.

How device compliance is being evaluated a without user-affinity device? 

By checking the device compliance state in detail, I found out that the device compliance is being evaluated upon the System account instead since there is no user account associated with the device. That’s really a nice twist.

Since all applications to support Azure AD Shared device mode must use the Microsoft Authentication Library (MSAL) for auth and the Microsoft Authenticator application to manage user state, as such you can have Conditional Access protecting the employee sign-in activities, further strengthening your Zero-Trust stance.

The End

This blog was intended to showcase

• the necessary configuration items that is required to be configured in the MEM Admin Center to support Azure AD Shared device mode with Android Enterprise Dedicated devices.

• the device provisioning experience of an Azure AD shared device mode with Android Enterprise Dedicated devices enrollment, and

• the end-user experience of using a device in Azure AD Shared device mode.

I hope this would help you to test the Android Enterprise Dedicated device in Azure AD Shared device mode.

Well, that was all for today. Do check out my other blogs on different Intune topics here.

Stay tuned to this blog site. Subscribe to get notified of new posts and be a member of the How To Managed Devices (HTMD) community.

Use the HTMD Forum to post your queries related to Intune/SCCM and get expert advice and answers from the HTMD community.