InTune password policy for personal disabling pattern and swipe options

[luvsql]

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?

[#2]

Spoiler

It has been awhile when I used this setting, but I think when you choose require password for Work profile - then you choose require for password type- MSFT will disable Pattern option, as it counted not a secure method.

You can choose Low Security Biometric which should allow swipe pattern options. 
Check screenshot attached!
Hope this helps!

Moe

[#3]

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)

• Settings
• Search for Work Profile
• Click on Work Profile settings

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 😉 

[#4]

Great points. Thanks Oktay!

[#5]

If we can't change the One Lock setting to be disabled, then any setting we set for the work profile overrides the settings for the personal side. I've tried multiple types (Device Default which I've read is being deprecated, at least numeric then just to required) but any setting still has the swipe and pattern disabled on the personal side.

Is the only way to have a personal side untouched and a work profile configured by having the user manually disabling the One Lock option?

[#6]

Have you tried Low Security Biometric from Compliance Policy not Restrictions Config Policy?

[#7]

What would that do to users that have devices that don't use biometrics and only a PIN? Since this is a Personally Owned Device, Intune should not be changing or disabling ANY personal settings at all.

[#8]

PIN should be covered under Low Security Biometric. Here is the link from Android documentation-

https://android-developers.googleblog.com/2018/06/better-biometrics-in-android-p.html

Another option you can do, to not configure the setting and leave it Not Configure. I use that for BYOD macOS so user will not be prompted to change their passwords.

Moe

[#9]

@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. 

[#10]

@luvsql 

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. 

[#11]

I changed the Compliance Policy to be "low biometric" and the Configuration Policy for the personal to just "Required" sync'd the device and the swipe and pattern are still disabled.

[#12]

Can you change the config policy to Low Security Biometric instead of Required?

[#13]

Changed to Low Security Biometric on Config Policy, sync'd device, still disabled.

[#14]

@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.

[#15]

@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. 

[#16]

@luvsql , Here's the video : https://youtu.be/62-gl0dMaTA PS, the PIN I use here is Donald Duck's birthday I use for testing  (There is no audio in this video)

Just to be clear, When you create a compliance policy, you can choose between 2 profile types:

1. Fully managed, dedicated, and corporate owned work profile
2. Personally-owned work profile

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

[#17]

But we NEED the phone to have a password on the device to pass a basic compliance check.

[#18]

@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.

Regards,

Oktay