In this post, I will delve into the topic of Android Enterprise Dedicated Devices in Azure AD Shared device mode. With the October service release, Microsoft Intune (a.k.a. Microsoft Endpoint Manager) introduced a new feature. This feature allows organizations to automatically provision an Android device in Azure AD Shared device mode using the Android Enterprise (AE) Dedicated device enrollment mode.
Microsoft Endpoint Manager customers can now enrol their Android devices as Android Enterprise (AE) dedicated devices.
This feature enables end-users to have single sign-on and single sign-out access across all participating applications on the device. For an application to be part of Azure AD Shared mode, it must integrate with Azure AD’s MSAL library.
Azure AD shared mode customers can secure corporate data with Conditional Access based on device compliance in this release. They can also customize the sign-in experience with Managed Home Screen, allowing for session PINs and automatic sign-out timers.
Today, we will investigate this new feature, learn the required configurations in the environment to support it, and finally, see how it works.
So let’s get started.
- Android Enterprise: An ultimate use-case guide for the different management modes available with Intune [3]
- Evolution of Android management for Enterprise use | Deep Dive with Joy
- 9 myths regarding the use of Android in Enterprise
- Understanding Android Management with Intune | Android Enterprise
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. This provides 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), all the preferences and user data are removed, making the device ready for the next employee to pick up and sign in to start working on it.
To support Azure AD Shared Device mode, your business applications must use the Microsoft Authentication Library (MSAL) for their auth functionalities and 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 Microsoft’s easy step-by-step tutorial on how to use shared-device mode in your Android application.
However, application development is not my forte, so let’s return to understanding how to set up an Android device in Azure AD Shared Device mode.
As seen in this reference document, 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.
Note: Azure AD shared device mode only registers the device to Azure AD without any primary user set. There is no MDM enrollment. Hence, you will find the device object under All Devices in the Azure AD portal, not your MEM Admin Center portal.
I have tried the same on one of my test devices, an unmanaged Motorola G4 Plus model. Android 7.0
This is how the device comes up under All Devices in the Azure AD portal.
The process is manual as it requires an IT Admin with Cloud Device Administrator privileges to register the device, so it is not functional if you need to provision devices in bulk.
All the other Android Enterprise management modes typically belong to use cases with user affinity except for Corporate-Owned Dedicated devices without user affinity.
Thus, with the demise of legacy device admin management, the Android Enterprise COSU setup is 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 push the Microsoft Authenticator app via Managed Google Play. However, an IT admin must manually configure the Authenticator app to set it up in Azure AD Shared device mode.
Not anymore with the 2010 service release of Microsoft Intune.
Provisioning Android Devices: Using 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 Android Enterprise Corporate Owned Dedicated devices category.
The process is identical to how we set up Dedicated devices [COSU] as KIOSK.
So, let us see what Admin configuration is required to support the new feature.
Azure AD Shared Device Mode – Create the Dedicated Device Enrollment Token
In the 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 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) |
After creating the profile, open it to view the QR Code and/or the Enrollment Token, which the onsite Tech support team can use to start provisioning the devices.
Create a Dynamic Device Group to Contain Devices Configured as Azure AD Shared Devices
Creating a dynamic device group to contain devices enrolled with a particular enrollment profile is always a standard approach. This group can later silently target policies and/or push apps to those devices.
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 made in the earlier step.
Deploy Apps that Support Azure AD Shared Device Mode
Microsoft Teams and Microsoft Managed Home Screen are the only two Microsoft apps supporting 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 already manage Android Enterprise devices with Microsoft Intune, the binding is established between your Intune tenant and Managed Google Play. You can visit the Managed Google Play portal or add apps from the Managed Google Play store within the MEM Admin Center portal.
For the illustration purposes of this blog post, I have deployed the three apps.
Sl.No. | Apps Name |
---|---|
1. | Microsoft Teams |
2. | Managed Home Screen |
3. | 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 have deployed the apps, you must 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
The Managed Home Screen enables the end-user to use the below functions on a device enabled with Azure AD Shared device mode.
- 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, immediately post sign-in, that lasts for their signed-in session. It can be used throughout the session to consent permissions rather than credentials.
- Automatic sign-out after a period of pre-defined inactivity by the IT admin or
- The customer-facing Folder on the Foldered 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, and the default Microsoft privacy statement link will be displayed to the user.
Using an App Configuration policy from Intune, you can configure the Managed Home Screen to support Azure AD Shared device mode. 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 |
To configure the settings, you can use Configuration Designer for the UI experience or go the Pro route, creating a JSON of the configuration. Either way, you can check all the supported configurations and associated values from here.
Note that not all settings can be configured with the Configuration Designer. If you want to configure settings like enabling and configuring a Customer-facing folder, you may as well use JSON.
My sample JSON config is as below build regarding 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) must be deployed to the device as required and included in the Multi-App KIOSK config profile to run within the Managed Home Screen.
Here, you can see I have specified Kaizala (com.microsoft.mobile.polymer
) as the app within the customer-facing Folder.
Once Folderve creates the configuration profile, assign it to the same dynamic device group created earlier.
Create a Multi-App KIOSK Profile to Allow Apps to Run within a Managed Home Screen
We need to create a Multi-App KIOSK Profile to enable the Managed Home Screen. This will lock down the device further and show the end-user only the applications they need to work with. Creating a device restrictions configuration profile to customize the device experience is simple.
Below is a reference snap for the Multi-App KIOSK configuration profile I created for this blog, which showcases 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 must assign the profile to the same dynamic device group you created earlier.
One more configuration item is 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 we do for a KIOSK setup, with a few extra steps 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.
Note that during device provisioning, only the Microsoft Intune and Microsoft Authenticator apps are installed. After provisioning, you will initially be presented with the device’s default Android launcher.
Managed Home Screen, other apps, and config policies, as deployed, get enforced with a slight delay. This is because it takes the device object time to become a member of the dynamic device group.
How Would You Confirm that the Device Setup Succeeded?
After provisioning is completed, open the Microsoft Authenticator app on the device, and you will see that it is in Azure AD Shared Device mode, as shown below.
As I mentioned, you need to wait a little bit after completing the device provisioning to actually experience and start taking advantage of the Azure AD Shared device mode. This is because there is a little delay in getting the device object in Azure associated with the dynamic device group to which the rest of the policies and apps are deployed from Intune.
The Managed Home Screen launches automatically after installation, 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, the user must first sign in using corporate credentials to begin working.
Further, the IT Admin can enable and require the worker to set the current session PIN, which is helpful as it can be used instead of requiring full credentials to resume 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 required apps for work.
Note that the sign-in on the MHS screen triggers a device-wide sign-in, and apps that support the Azure AD Shared Device mode will automatically sign in to the user who is currently logged in 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 enable end-user notification with a defined timer to notify them of inactivity and when auto sign-out will happen. The end user can either Resume to continue with the current session or Sign out.
Customer Facing Folder is an anoFoldereature 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.
Suppose the other user tries to exit from the Folder to accFolderps outside the Folder, and iFolder is not contained. In that case, there is a potential risk of data leakage due to the device being in Azure AD Shared device mode, meaning all apps that support it are signed in device-wide.
Thankfully, that is not the case. To exit from a Customer Facing Folder, the person must provide the current session PIN, which should only be known to the user currently signed in.
If you try Exit from a Customer-Facing Folder, you either resume the session by providing the current session PIN or have the option to Switch users, which will then sign out the current user, clearing the session data to begin the next session.
To end the session (at the end of shift or break), a signed-in user can sign out from any app supporting 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 the Managed Home Screen if the IT Admin has enabled it.
This completes the end-user experience, but…
Remember I mentioned that there is one more configuration item left, but we skipped it anyway? Now, it’s 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 device compliance without user affinity. One reason is that Built-in Compliance, enforced by default to all enrolled devices in Intune, checks for three base criteria.
- Enrolled user exists
- Has a compliance policy assigned
- Is active
Since provisioning a user-less device does not involve a real user account, you can understand that such a device will never satisfy the above and will 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.
However, this behaviour has changed with Dedicated devices in 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 them 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.
After the compliance policy assignment, check the device status in the MEM Admin Center portal after some time. You should see it below.
Notice that the other two Android Enterprise devices enrolled as Dedicated devices (default) are not being evaluated for compliance as usual. However, the device enrolled with the Dedicated device in Azure AD Shared device mode is being evaluated for compliance. Also, notice that the Enrolled by user UPN is NONE, confirming this scenario is still without user affinity.
How is device compliance being evaluated without a user-affinity device?
By checking the device compliance state in detail, I found out that the device compliance is being evaluated based on the System account instead since there is no user account associated with the device. That’s a nice twist.
Since all applications supporting Azure AD Shared device mode must use the Microsoft Authentication Library (MSAL) for auth and the Microsoft Authenticator application to manage user state, 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 must 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
- The end-user experience of using a device in Azure AD Shared device mode.
I hope this will 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 be notified of new posts and join 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.
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced IT service professional with almost five years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect at Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He was awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his blog site, MDM Tech Space, at https://joymalya.com
Hello Joymalya,
I had a question regarding sign in, can we have PIN instead of Azure Ad credentials for every user that signs in to the device?
if yes, can you explain how?
Regards,
Shashank
For the dynamic device group, which is based on querying the enrollmentprofile name:
What happens if you delete the enrollment profile?
Does the dynamic device group stop working?
I don’t think so. Because the Azure AD devices will still have the enrollment profile record details embedded in the device records? But I will let Joy to confirm this 🙂
Is Outlook supported now under this Shared with MFA enrollment type?
As I know, currently only Teams and Managed Home Screen are the two apps that supports the MSAL global sign-off feature.
However, the best way to check if outlook works would be to test!
Outlook is not supported
This feature is definitely not fit for enterprise. Microsoft Edge leaves the browsing history and cached data for all users. Teams shows the previous user’s chat for a brief moment whilst they are being signed out for the new user. Applications appear, disappear and then reappear from the Managed Home Screen without any explanation. Outlook stays logged in for the previous user as well, exposing all their emails to the world.
Etc etc.
Hi
Is MFA supported in this solution?
Hi,
Is there a way to clear all Edge/Browser data when you open a new session on the device ?
I have been trying to make it work for days now but I can’t.
Thanks in advance,
Under Device Configuration (the one targeted to these devices) > Applications > Add Edge to the section to Clear Local Cache
However, doesn’t seem to work for Sharepoint and OneDrive.
Def doesn’t seem like a very secure solution for enterprise…..leaving previous users data lying around
Hello
When the users are inside the MHS every app they open it seems like it opens in full screen, which means when they use applications they can not see the clock, battery % or the date.
Any idea how to fix that?
Hello!
When the users log in the Manged home screen and tries to open any application it seems like it get open in fullscreen, meaning they will not see the clock,date or the battery % it completly vanish.
Anyone know how to fix this?
HI Anoop
Thanks for your blog, All tested and configured properly , But unfortunately MHS login / sign In Option is not appearing even after 4-5 hours. What could be the issue ?
Thanks for the guide, have setup Shared Device enrolment for testing, but noticing the following issue after sign-in to MHS. When loading any app that should leverage the AAD account it attempts auto sign-in and then prompts with the following error. The same error occurs if I then try to manually sign-in too.
“To use your work or school account with this app, you must install the Microsoft Company Portal app. Tap ‘Go to store’ to continue”
The above is true for sign-in attempts to ‘Teams, Outlook, Edge, Microsoft 365’ apps
Checked AAD Sign-in logs and it was a conditional access policy causing the restriction. Removed myself and tested again and the apps are working as designed now with SSO
How do I allow normal apps like calling, TXT/SMS etc?
Great article but I need some help please.
I need to still be able to join a Wifi network, change settings, make phone calls and send txt. Is there a way to still allow that?
Need it to sign in but not be that locked down, users will need to use Microsoft apps and MFA.
So I need the Microsoft apps to sign in automatically as well, that is also not working for me.
Also comes up with “Intune Company portal is required for the device” when I try to open Outlook.
Company portal already installed.
Great article. I would like to present with our custom agreement for users to agree on sign-in as explained here https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/terms-of-use. Is it possible to do that with managed home screen? Thanks in advance
Like the others above, is there a way to make calls of text messages?