Hey everyone! I'm setting up Azure AD Join (AADJ) PCs and trying to enable access to on-prem resources like SMB. Here's the situation I'm facing: When a user logs into an AADJ PC with their email and password, everything works fine — they access the desktop and mapped drives without any extra authentication. However, if they log in using a PIN, the mapped drives are disconnected, and they get an error saying, "The system cannot contact a domain controller to service the authentication request."
This issue doesn't occur on domain-joined PCs where users can log in with either PIN or password, so it seems to be a problem with Windows Hello for Business (WHfB) and AD. I've tried following Microsoft's guides on setting up cloud trust, but it's still not functioning as expected. While I could have users log in with their email and password to cache credentials for each mapped drive, that's not ideal. I've come across suggestions that importing a domain certificate might work, but I'm uncertain if it's a long-term solution. Has anyone successfully resolved this issue? Any specific steps I should follow? Thanks in advance!
5 Answers
Have you set up Kerberos cloud trust? If not, check out the Microsoft documentation. It’s essential for WHfB to function correctly with on-prem resources. Also, ensure your policy retrieves the Kerberos ticket upon logon.
For me, combining WHfB with Cloud Kerberos Trust worked like a charm, assuming everything else is configured correctly. Don't give up; you’re almost there!
I’ve had it set up without any issues, but we missed some Intune configuration. Make sure you have the Group Policy (or Intune config) for 'Use Cloud Trust For On Prem Auth' enabled, and 'Use Windows Hello For Business' set to true. If you enabled the policy after the initial WHfB setup, you might need to reset the Windows Hello containers for it to start working properly.
I checked my Intune settings and reset the Windows Hello container, but I’m still stuck with the same issue.
Don't forget that if the user had WHfB enrolled before you set up these configurations, you might need to run the command 'certutil /deletehellocontainer' to re-enroll them. Remember, only standard users can be used; domain or enterprise admins are exempt from cloud Kerberos.
Make sure you’re using a KDC Proxy if you don't have a direct line-of-sight to a domain controller. That might solve your connection issues.
I’ve already enabled that policy, but I'm still encountering the same problems.