Jun 03 2022 06:15 AM
Jun 03 2022 06:15 AM
I have a configuration policy setup for personally owned work profile Android devices. I've tried various password types (not using Device Default as read that is going away) so now have it as "Password Required" but the personal side still has key Android features disabled, which it should never do on a Personally owned device.
How do we configure this so nothing is changed on personal side other than just requiring the device have any sort of password setup?
Jun 03 2022 08:04 PM - edited Jun 03 2022 08:08 PM
Jun 04 2022 06:09 AM
Hi @luvsql, Also make sure that you check the Password settings below Work profile settings:
These settings apply at the device level (the personal profile).
Remove every value or set is as you require. Then check Required password type. The default is At least numeric. Change this to what you want.
When you configure a work profile, new settings for your work profile become available and you can configure these settings by going to (on Android)
One of the important settings is called Use one Lock. When a personally-owned profile is enabled, "One Lock" is configured by default to combine device and work profile passcodes. This makes it more easy for users because now they can use the device passcode and don't need to enter a new pin when switching to work profile.
If you want to know more about this, then check out my blog. I think it will help you: Android Enterprise Personally owned devices with a work profile and device PIN (allthingscloud.blog)
Also did a video around the end-user experience on personal Android devices with work profiles. You can find the video in my blog or jump right to it.
@Moe_Kinani hope you don't mind me jumping in ;)
Jun 06 2022 05:51 AM
Jun 06 2022 08:06 AM - edited Jun 06 2022 08:06 AM
Have you tried Low Security Biometric from Compliance Policy not Restrictions Config Policy?
Jun 06 2022 08:07 AM
Jun 06 2022 08:25 AM
Jun 06 2022 08:33 AM
@Moe_Kinani Unfortunately there is no option "Not configured" for password types. You have to choose something. However, when I have the password type set to just "Required" why would that disabled swipe and pattern? That is the core of the issue.
Jun 06 2022 10:10 AM - edited Jun 06 2022 10:13 AM
I was pointing about ‘Not Configure’ if you use Compliance Policy not Restriction Policy.
For the same screenshot you attached, have you tried Low Security Biometric instead of password? As I mentioned at the beginning, password will disable swipe and Pattern options as it counted insecure.
Jun 06 2022 10:17 AM
Jun 06 2022 10:44 AM - edited Jun 06 2022 10:44 AM
Can you change the config policy to Low Security Biometric instead of Required?
Jun 06 2022 10:55 AM
Jun 06 2022 11:19 AM - edited Jun 06 2022 12:27 PM
@luvsql did you by any chance configured a device compliance policy for Android Enterprise - Personally-owned work profile? If you did. Can you check the system security part? Compliance policies have precedence over configuration profiles. If you did configure this, then set the settings to Not Configured. These setting apply at the device level. f you only need to require a password at the Personally-Owned Work Profile level, then the configuration policy should be enough.
If you require a password to unlock the device (with a compliance policy) , then you disable swipe at the device level, because these methods are not considered safe.
I will update my blog with this information. I have a device setup, and I can confirm that I only have to enter a pin when opening apps in my work profile. The personal profile, is set to swipe but I can also use patterns. I'll also upload a video showing the user experience.
Hope this helps.
Jun 06 2022 11:34 AM
@Oktay Sari Yes and it's set to Low security biometric. These are personally owned devices so we should not be messy with these users own settings. We should be able to have requirements for the work profile to whatever we need and require any kind of password for personal, which I did have set but config policy only has "Password Required" and Compliance doesn't so you have to pick something.
Jun 06 2022 11:51 AM - edited Jun 06 2022 12:06 PM
Just to be clear, When you create a compliance policy, you can choose between 2 profile types:
Option 1 is for corporate owned devices, and option 2 will target personal devices.
When you choose option 2 and require passwords, the documentation tells you this:
This setting applies at the device level. If you only need to require a password at the Personally-Owned Work Profile level, then use a configuration policy. See Android Enterprise device configuration settings.
So if you don't want this to happen on personal devices, then set it to Not Configured here, and configure your configuration policy to require a PIN when the user opens the apps in the work profile.
If you are dealing with corporate devices, you can configure a compliance policy for Fully managed, dedicated, and corporate owned work profile.
I know it can be very confusing and perhaps even worrying, but this is how it works. When you configure App protection policies for example, With Windows Information Protection Without enrollment, you can require the user to set-up windows hello on their personal devices, before they can access corporate data.
So yes, some of these setting you configure, apply at the device level and outside the work profile. This is documented at different locations but here's an example for the compliance policy. Android Enterprise compliance settings in Microsoft Intune | Microsoft Docs
Jun 06 2022 12:15 PM
Jun 06 2022 12:42 PM - edited Jun 06 2022 12:55 PM
@luvsql, So you do need a password on personal devices to meet compliance. Ok, I've again checked the configuration and can confirm I have a working scenario. I'm willing to show you my test tenant configuration and test device setup if you thing that it can help you out.
When I require a password from within the compliance policy and set this to Low security biometric like this:
And configure the configuration profile password settings like this: Required password type: Device default.
Please note: The default in your configuration policy is At least numeric, so check this. In theory, It should also work if you had set this to Low security biometric. (the same as the compliance policy).
Then the user experience is:
Swipe is disabled because it is not a password. Pattern is still working. It's better then not having a password. You are requiring a password with the compliance policy so it's logical that swipe (no password) is disabled. But it's only disabled when the user sets a pattern or PIN, or something else.
I think the logic behind this is this: If swipe would have been left enabled, the device could become non compliant again, had the user decided to switch back to swipe. I know it's a user decision, but still, It does seem logical to go this way. And it's still a user decision right? Because the user can still choose to not set a pattern, or pin. But then the device is not compliant, and I guess, your conditional access policy blocks non compliant devices.
Can you check your config or try to setup a new one for a test device?
Again, I'm willing to show you my test tenant configuration and test device setup if you thing that it can help you out. Just send me a DM.
Hope this helps.