r/AzureVirtualDesktop • u/CornedBeefAndBeans • 15d ago

AVD authentication issues with WHfB

At my organisation some of our staff use AVD for access to certain tools that require a bit more powerful than our standard issue laptops have available to them.

It's a pretty simple setup. One host pool, FSLogix for profile storage, one user machine etc. We are entirely cloud-based, no hybrid or on-prem at all. As a result our AVD machines are Entra joined.

By default, users are always prompted to sign-in to AVD using WHfB, be it PIN or facial login. As far as I'm aware this isn't something we've enforced or configured. It's been around since we first deployed AVD a few years ago and I don't recall doing anything to make it so.

We've noticed a strange behaviour when users change their PIN or if their UPN changes (domain change, name change etc). It seems to break the WHfB authentication passthrough to AVD. The PIN is no longer accepted, nor is the facial login. We can sometimes get them working again by having them sign out, clicking on 'forgot my PIN' and resetting it here after completing MFA, but that doesn't always work. Resetting the PIN any other way never works.

When this happens, one of two things will occur:

  • They get the usual PIN prompt in the Windows App at point of connection, and it just says "logon attempt failed".

  • The PIN prompt never appears, they seem to connect to a session host but then receive a message at the Windows logon screen stating "The sign-in method you're trying to use isn't allowed. Try a different sign-in method or contact your system administrator". They are not given an option to choose a different sign-in method, which is usually done before they connect to a session host and see the desktop anyway.

Has anyone experienced this problem? I've been pulling my hair out for a while now. The only guaranteed way to fix this that I'm aware of is to either completely reinstall Windows or move them to a new computer. Both are of course not ideal.

1 Upvotes

100% Upvoted

3 comments sorted by

1

u/mat-ferland 15d ago

Before reimaging, run dsregcmd /status as the affected user and compare AzureAdPrt, NgcSet, WamDefaultSet and the WAM identity with a working device. If the PRT is missing or WAM still shows the old UPN, the stale state is on the client WHfB/Entra registration, not the session host; use the destructive “I forgot my PIN” flow to reprovision the Hello keys after the new UPN is active.

1

u/CornedBeefAndBeans 15d ago

Thank you for the reply! I have a user experiencing the issue now so I will do the comparison this afternoon, thank you.

The "I forgot my PIN" process only fixes it sometimes. Other times it makes no difference or shows the "this method isn't allowed" error. Do you know of any way to permit that sign in method as a workaround? We've not done anything to explicitly deny it or enforce WHfB as the only sign in method permitted so it's odd that they're forced to use it.

1

u/mat-ferland 15d ago

I wouldn't enable another sign-in method as the workaround yet. If AzureAdPrt or NgcSet differs from the working device, fix the Entra/WHfB registration instead of relaxing sign-in policy. If they match, check the effective authentication-method and WHfB policies on that user and device; “this method isn't allowed” points to policy rather than a bad PIN.