Hey everyone! We've recently set up Single Sign-On (SSO) for our Azure Virtual Desktop (AVD) environments, and our session hosts are configured with Hybrid Azure AD Join. Alongside that, we've been encouraging users to switch to Windows Hello for Business (WHfB) for authentication, and they've all managed to enroll their devices. Now, when they log into their laptops, they can use WHfB easily and it works seamlessly. However, the problem arises when they open the Windows App to start their AVD session. Despite using WHfB, the app often defaults back to requiring a password after logging off, which frustrates users who then forget to choose WHfB again, leading to issues with multi-factor authentication (MFA) in the session hosts. I would have thought the app would remember their authentication preference. Can anyone explain why this is happening?
4 Answers
I haven’t dealt with WHfB specifically on AVD, but I experienced a situation where it wouldn’t work properly because we didn’t have it set up on the hosts, even though it’s enabled on our laptops. Sounds like a similar pain!
Classic Windows Hello issues! It seems inconsistent, right? I had something similar with SQL workloads in VDI where all sorts of certificate issues arose. It might be worth pre-deploying schema validation with Azure DevOps to ease the headaches.
Have you considered enforcing MFA with a Conditional Access policy just for AVD? That could improve the sign-in process a bit, but I haven't tried it with the Windows App specifically. It seems to work fine for browser apps, though.
I’ve tested that approach, but it still prompts users for passwords anyway. It’s a bummer because if they type one in, they get an ‘Auth Method Not Allowed’ error. Not ideal!
This behavior is usually linked to how the Windows App manages cached credentials and how Conditional Access can trigger new authentication contexts. Even when WHfB works, you might end up back at the password prompt due to token issues or session state clears. I'd look into your CA sign-in frequency settings and ensure the app is set up to use Web Account Manager properly. This behavior isn't all that unusual and generally points to some UX inconsistencies rather than an outright misconfiguration.
Sounds frustrating! For us, it involved some tricky reg keys in Intune and enabling Azure Kerberos on AD. Once it was configured correctly, it started to work. Maybe there’s more to configure on your end?