Windows Hello for Business & Zscaler: Solving Kerberos Authentication Delays

The Mysterious 10-Minute Authentication Delay

During a Windows 11 enterprise deployment, we encountered a perplexing issue: users logging in with Windows Hello for Business (WHfB) faced 10-minute delays when accessing DFS shares, followed by sudden resolution. Here’s how we diagnosed and fixed it.

The Root Cause: Kerberos + Zscaler Timing Conflict

Key Findings:

1. Zscaler Private Access (ZPA) took time to establish tunnels to domain controllers.
2. WHfB authentication completed before ZPA was ready.
3. Initial Kerberos requests failed silently, with Windows retrying after 10 minutes (default FarKdcTimeout).

Proof of Concept:
Running this command immediately fixed access:

klist purge_bind  # Forces Kerberos ticket renewal

The Role of FarKdcTimeout in Kerberos Retries

What is FarKdcTimeout?
A Windows Registry value that controls how long Windows waits before retrying failed Kerberos requests. Default: 10 minutes.

Registry Location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Should You Modify It?

• Decrease value (e.g., 5 mins): Faster retries but more network traffic
• Keep default (10 mins): Stable but longer user delays
• Our Solution: Scheduled klist purge_bind (no registry changes)

Note: Modifying FarKdcTimeout requires careful testing.

The Fix: Automated Kerberos Ticket Renewal

Option 1: Scheduled Task (Recommended)

1. Create a PowerShell script (Reset-Kerberos.ps1):

klist purge_bind

2. Deploy via Intune/GPO to run 10 seconds after logon. (Create a scheduled task for this)

Option 2: Adjust FarKdcTimeout (If Needed)

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" -Name "FarKdcTimeout" -Value 0x00000258 -Type DWord

Lessons Learned

1. WHfB + Zscaler can have hidden timing dependencies.
2. Kerberos retries are governed by FarKdcTimeout.
3. Scheduled tasks beat registry hacks for reliability.