Weird on-prem authentication issues on AzureAD-Joined Laptops

Question

I’m experiencing an intermittent issue in our hybrid network setup and would love your insights. We have laptops that are AzureAD-joined but not domain-joined, connecting to an on-premises server environment through Zscaler. We also use Windows Hello for Business for user authentication. Here’s the situation:

What happens? After signing in to a laptop (using PIN, password, or biometrics via Windows Hello for Business), Single Sign-On (SSO) to on-premises SMB file shares sometimes fails.

• If signed in with a password, users might see: "The system cannot contact a domain controller to service the authentication request."
• If signed in with PIN or biometrics, a credential prompt appears when accessing the file shares.

Observations:

• The issue appears to be related to missing Kerberos tickets. Running klist shows no TGTs are active when the problem occurs.
• The problem resolves itself after 10-15 minutes without intervention, at which point Kerberos tickets appear, and SSO starts working as expected.
• Running the command nltest /dsgetdc:<domainname> consistently returns a correct domain controller with accurate details, even when the issue is present.

What we’ve checked so far:

• DNS and connectivity: DNS resolution and network access to the domain controllers seem fine.
• Time synchronization: Clocks on the laptops and domain controllers are in sync.
• Credential Guard: Disabled, but no effect.
• Windows Hello for Business configuration: No clear issues found.
• Logs: No significant errors or clues in laptop or domain controller logs.

Our question:

• Has anyone experienced similar issues with Windows Hello for Business in a hybrid environment?
• Are there specific tools, settings, or areas we should focus on to diagnose this further?

Any suggestions or advice would be greatly appreciated. Thanks in advance for your help! 😊

Answer 1

The resolution of this issue took longer than expected due to sickness and the holiday season. However, we’ve now identified the root cause of an intermittent Kerberos authentication issue in our hybrid environment, which occurs when laptops use Zscaler for network access.

The problem arises during startup when the Zscaler Client Connector (ZCC) is still initializing, and ZPA isn’t fully connected. At this point, the system generates a Kerberos ticket request to the Domain Controller (DC) while mounting network drives. Since there’s no line of sight to the DC yet, the client creates a negative cache for the Kerberos request. This cache prevents subsequent Kerberos requests from succeeding, even after ZPA establishes connectivity, until the cache expires (typically 8-10 minutes).

Solution: Zscaler recently introduced a "Clear Kerberos DC" setting in ZCC version 4.5, which automatically clears the Kerberos cache when ZPA connects. We are currently testing this solution with a selected group of users to ensure it resolves the issue without causing unintended side effects.