15-Second Web Page Latency during Kerberos Fallback to NTLM Transparent Auth
A hardcoded 15-second socket timeout in the FortiOS WAD proxy daemon's auth_ntlm module blocks HTTP worker threads during Kerberos ticket negotiation failure, stalling external web page loads for non-domain and cross-forest enterprise clients.
Technical Root Cause Analysis
In enterprise proxy environments configured with Active Directory authentication schemes, FortiOS explicit proxy and transparent proxy policies utilize SPNEGO (Negotiate) challenges with Kerberos as the primary mechanism and NTLM as a fallback.
When a client browser initiates an HTTP request, the WAD worker process responds with HTTP/1.1 401 Unauthorized: WWW-Authenticate: Negotiate. In environments where the client is non-domain-joined, lacks DNS reachability to the Kerberos Key Distribution Center (KDC), or where the Service Principal Name (SPN) for HTTP/proxy-vip.corp.local is missing, the client fails to obtain a Ticket Granting Service (TGS) ticket.
Instead of immediately declining the Kerberos exchange and presenting an NTLMSSP challenge, the auth_ntlm state machine invokes a synchronous socket read call with a hardcoded 15,000ms timeout waiting for the Kerberos GSSAPI blob. During this 15-second window, the WAD worker thread halts completely. Because modern web browsers open 6–8 concurrent TCP connections for sub-resources, client sessions experience compounding hangs of 15 to 45 seconds per page load.
Affected Firmware & Blast Radius Matrix
| FortiOS Branch | Vulnerable Builds | Confirmed Clean Build | Status & Workaround |
|---|---|---|---|
| FortiOS 7.2 | 7.2.3 – 7.2.6 | 7.2.7+ | Apply Kerberos timeout override CLI |
| FortiOS 7.4 | 7.4.0 – 7.4.1 | 7.4.2+ | Decoupled asynchronous authentication engine |
| FortiOS 7.0 | 7.0.9 – 7.0.12 | 7.0.13+ | Disable Kerberos or register complete SPNs |
Platform Impact: FortiGate 60F to 400F appliances running explicit web proxy or transparent proxy authentication with Active Directory integration.
Step 01: Free Verification CLI (Safe Read-Only)
Execute these diagnostic commands to inspect active WAD authentication sessions and measure worker thread latency:
Diagnostic Commands
# 1. Inspect the active WAD proxy authentication sessions and auth cache
diagnose wad auth list
# 2. Display WAD worker process statistics, connection counts, and latency
diagnose test application wad 1000
# 3. Check memory and CPU consumption across active proxy workers
diagnose sys top-mem 10
# 4. View active authentication scheme configuration
show authentication schemeRemediation & Workaround Steps (Teaser Preview)
Step-by-step remediation procedures available in the interactive Ferrite platform:
Frequently Asked Questions
When Kerberos ticket exchange fails, WAD enters an unbuffered socket wait loop governed by a hardcoded 15-second timeout in auth_ntlm before returning an NTLMSSP challenge to the browser.
Users on non-domain endpoints (macOS, iOS, unmanaged laptops) or users accessing proxy services across untrusted domain forests where Kerberos tickets cannot be minted.
Yes. If your environment does not require Kerberos Single Sign-On, switching the authentication scheme to pure NTLM or SAML 2.0 completely bypasses the 15-second timeout.