Azure AD Joined device is not honoring Windows Hello for Business Config Policy from Intune

Iron Contributor

With the availability of Cloud Kerberos Trust we are now able to deploy WHfB to our Hybrid workforce but we do have a handful of Azure AD Joined devices that we also need to deploy to, all of these devices are enrolled in Intune and our user accounts are all on-prem AD and synced to Azure.

 

When I configured the WHfB policy using the Settings Catalog Configuration Profile and apply it to our test devices, the hybrid one works great - it obtains the settings and I can see the updates to the registry and the Windows UI reflects these settings in the WHfB setup - for example, the PIN Complexity settings were set to minimum 4 and allowed all characters, symbols, etc.

 

However when I applied the same policy to an Azure AD Joined device, the device received the settings, made the registry changes, yet when configuring the PIN, the requirements shown on screen were not what was set in the policy. I tried changing some settings in the policy to see if the updated registry settings would affect the Windows UI but still nothing.

 

Where could this setting be getting overwritten from or, does an AADJ device with an on-prem synced user account need to have the WHfB config set a certain way?

 

We are not making any settings using the other methods of configuring WHfB such as Enrollment, Identity Protection Templace, Account Protection (Endpoint Security) and on-prem Group Policy cannot set WHfB policies on user accounts, only devices so this doesn't apply as it's AADJ.

 

You can see the settings that are applied in the policy and what's reflected in the registry and then what the UI says when setting a PIN.

 

pinsetup.pngREGKeys.pngWHfB Settings Applied.png

11 Replies
Do you have the tenant wide WHfB feature enabled in Intune by any chance?

The one under Device Enrollment? If so, it's Disabled and the rest of the settings match the policy I set. I only thought this one came into play during out of box setup (ie, enrollment) and is the lowest priority so other policies can overwrite it.

Seems about right. I personally never used settings catalog to configure WHfB policies. Either used endpoint security account protection profile or device configuration identity protection profile. Each have their own pros and cons.
I still haven’t figured out the pros and cons to each despite writing out the differences. I have also tried setting the configuration through all methods and the results are the same. The device ignores what is set.
This may require a deep dive into your configuration. Best to open a support case.
I did and they punted me elsewhere after 2 correspondences. That’s why I’m here.
Hi Marc Laflamme, we have the same issue. Where you able to fix the problem?

@Iljasa Redzepi 

 

I did come to a few findings myself (support and documentation were no help)

 

It's not accurately documented and took a lot of digging but basically the 4 places to set WHfB configs (in Intune) don't all write to the same area of the registry. Although everything is written to HKLM\Software\Microsoft\Policies\PassportForWindows, there are sub keys for device and user. 

Windows Enrollment - writes to device

Identity Protection (Config Profile) - writes to user

Settings Catalogue (Config Profile - can write to both user and device

Account Protection (Endpoint Security) - writes to user.

 

If you configure the Windows Enrollment settings as disabled and set your PIN complexity but then enable WHfB using one of the User methods, it will enable WhfB but use the MS Default PIN complexity and settings, ignoring anything set via Enrollment. The only way to use the Enrollment PIN settings is to enable WHfB via device written methods and the only other one is Settings Catalogue.

 

A USER written method will override a DEVICE method (buried in the documents)

 

Also whoever blogged about the Enrollment method only affecting devices during enrollment was wrong. If you set WHfB to Disabled under Enrollment and then set it to Enabled, your devices WILL be enabled.

 

Finally, the biggest hurdle and not documented anywhere, if you have configured the PIN and thus have an existing Hello Container, no matter what changes in a policy, whatever was set when the container was created will be tattooed. This means that if you change a policy (say you originally had a minimum of 4 digits and max of 10 and users set a PIN but then you changed the configuration to have a minimum of 8 and max of 20) when a user selects "Change PIN", it will NOT get this new information. It will only look at the original PIN requirements. The only way to get around this is to either delete the container (certutil.exe -deletehellocontainer) or from the Setup PIN part of Settings, press I forgot my PIN. (I think it just deletes the container and creates a new one but in doing so, reads the current registry settings).

 

That's all I've been able to figure out so far but it's definitely helped shed some light on this topic!

thanks for the fast respons, will check that and update

We're stuck in the same situation as well. AADJ joined - tenant wide setting disabled. Various device policies to specify WHfB along with an adjusted PIN policy but still picks up the default PIN policies.

In the interim we are doing a work around to write the amended PIN policy to the hive below - HKLM\SOFTWARE\Policies\Microsoft\PassportForWork\PINComplexity and this appears to inherit the PIN settings we required. (This is where the local gpo policies write so we decided on this location).