[Bug] - Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration - v3.2

[hasibravo]

We have deployed the OIB Windows Hello for Business configuration profile to Windows devices. Our intended use case is only to allow users to use Windows Hello for Business for local Windows sign-in and device unlock.

After deployment, users are being prompted to use Windows Hello / facial recognition / fingerprint in other authentication scenarios, such as RDP sessions, intranet sign-in, and Microsoft 365 / Azure web portals.

In some of these scenarios, Windows Hello authentication is not supported or does not complete successfully, so users have to cancel and manually choose username/password instead. This is causing user confusion and service desk calls.

Could you please confirm if this behaviour is expected when deploying the OIB WHfB profile?

Also, is there a recommended OIB configuration for organisations that want WHfB only for Windows sign-in/unlock, without users being prompted for Windows Hello/biometrics in other authentication flows?

Note: I haven't deployed the following config yet
Win - OIB - SC - Windows Hello for Business - D - Cloud Kerberos Trust - v3.5

Thank you

[Petrucci914]

It is an authentication method just like anything else, so that will be the default method for most things. I imagine it is IT mostly using RDP? They can use a different method when prompted if they want.

Do you have Cloud Trust enabled for Kerberos to work with Entra-joined devices? Even if you are Hybrid I generally deploy it because it is easy and will be there when you start doing Entra-join.

[hasibravo]

Thanks for your reply. At the moment we are hybrid joined and we have not deployed the OIB Cloud Kerberos Trust profile yet.

Our current WHfB rollout was mainly intended for local Windows sign-in and device unlock. We understand from your response that Windows Hello may be offered as a general authentication method once enabled.

We will review and pilot the Cloud Kerberos Trust configuration separately before broader deployment, especially to confirm behaviour with on-prem Kerberos resources and Entra-joined scenarios.

Thanks for the clarification.