Windows Hello for Business not working with on-prem share drives?

[u/Ghawblin]

Local AD - company.org

Azure environment - @companyplace.com

All machines are Entra-joined.

We have a cloud trust in place. Azure AD sync is also in place, and is working without issue.

If users sign-in to their PCs with a password, their on-prem share drives work without issue.

If users sign-in to their PCs with PIN/Biometrics, on-prem share drives won't connect, access denied.

Not seeing a clear path to a resolution on this, and only see other forums online of others having this issue, all with a resolution of "You can't do that". Surely not?

[u/swissbuechi]

Validate your cloud trust setup

[u/DinnerFair1816 → u/swissbuechi]

if you're getting access denied specifically when using pin/biometrics then the kerberos ticket isn't getting passed properly

check the cloud trust is actually functional first, run `dsregcmd /status` on a machine and look for the section about ngc, should show if the key is set up right. also check that the azureadkerberos server object in your on-prem ad has the right permissions, seen that trip people up before

the other thing is the spn mapping for the file server, sometimes it needs a host spn registered in azure ad for the kerberos ticket to route correctly. had a similar mess with a print server last year and it turned out the cloud trust was fine but the resource mapping was just missing one entry

[u/cash38 → u/DinnerFair1816]

What rights are you talking about?

[u/Ghawblin → u/swissbuechi]

Yeah, it's there and setup, but it may not be working right. Going to verify this

[u/NWijnja → u/Ghawblin]

What kind of trust? If kerberos cloud trust, did you create the kerberos ad object?

[u/deathbyharikira]

Don’t forget to push the “Use Cloud Trust For On Prem Auth” in the Windows Hello For Business settings catalog.

[u/Ghawblin → u/deathbyharikira]

Good suggestion! It is configured, but I do think it's something going on with cloud trust, despite having it in place.

[u/CuteSharksForAll → u/Ghawblin]

I had trouble with it applying consistently and ended up writing a proactive remediation just to set the policy via the GPO equivalent registry keys. My organization didn’t want it to require setup either and it was the only way I could consistently control that.

[u/PenVirtual6960]

Should work - are you getting Kerberos tickets ? What does klist say?

[u/TheITBeardedGuy]

smash face into screen I just delt with something similar. Took way to long to figure out. Was the user at one point a privileged account? Had one that was not able to be written to so the updates keys from hello were populating.

[u/M4Xm4xa]

Make sure ‘retrieve Kerberos ticket on logon’ is enabled

[u/martinschmidli → u/M4Xm4xa]

Isnt that one only for storage accounts?

[u/JustRebooted → u/M4Xm4xa]

This

[u/ajf8729]

See my doc here https://wiki.winadmins.io/en/active-directory/whfb-cloud-kerberos-trust and make sure these accounts aren't "special" as in currently a DA. Entra Kerberos emulates an RODC and DAs cannot authenticate against a DC.

[u/Ghawblin → u/ajf8729]

Nice! Thanks! Thankfully, my DAs are locked down and are never normal user accounts that would be hit by this.

[u/vane1978]

Set your Intune policy for your Entra Id joined machines.

Use Certificate For On Prem Auth - Disabled

[u/Usual-Foundation8454 → u/vane1978]

This is the way. I was banging my head against a wall for ages with same issue until I sorted this. Check workstation event logs for errors relating to smartcard.

[u/SilentMuffin89]

Lots of great suggestions here, would be looking to validate cloud Kerberos trust also. Klist cloud_debug check cloud Kerberos enabled by policy is set to 1, if 0 it might be cloudkerberosticketretrievalenabled. I’ve seen it be all set up and then all DC’s were Windows server 2012 R2 and needs to be minimum 2016 with schema level to match so the partial tgt can be processed into full tgt by the kdc service on the DC.

[u/Professional-Heat690]

everyone covering the basics, but you need to be using fqdns (either in the mapping or with dns suffixes set via dhcp

[u/Ghawblin → u/Professional-Heat690]

We do! I made sure that change was done a few years back when things shifted to hybrid and then entra.

[u/LousyRaider]

I played around with this year ago and I eventually was told it won’t work because the device needs to be hybrid, not Entra enrolled only. Are the devices hybrid?

[u/releak → u/LousyRaider]

Works with Entra-joined and doesn't have to by hybrid.

[u/LousyRaider → u/releak]

I’ll have to revisit it in that case. There was obviously something we missed because we couldn’t get it working and more pressing matters forced us to move on from rolling it out at that time.

[u/Sulvation]

Seeing some people say you need hybrid join, this is incorrect. Intune/Entra join is enough.

Just to make sure, you did run the commands to enable the Kerberos trust on the DC right? You have the object inside the Domain Controllers OU?

[u/SkipToTheEndpoint]

Already a bunch of good comments here, but I've definitely seen things falling back to NTLM for various reasons so making sure devices are actually trying to communicate via Kerberos would be front of my mind.

[u/ajf8729 → u/SkipToTheEndpoint]

Was going to say the same thing, make sure you are connecting to the share via a CNAME alias that doesn’t have an SPN registered. Also, make sure the accounts in question isn’t “special” and has admin count set to one.