OneConnect with NTLM Causes Cross-User Authentication Failures
An intranet virtual server vs_intranet on BIG-IP 15.1 uses an HTTP profile and a OneConnect profile, with a pool of six IIS servers. The application uses NTLM authentication and sets an application session cookie. About 12% of users are intermittently prompted to authenticate again, and a smaller number report seeing another employee's name in the page header. IIS logs show requests where the NTLM Authorization header and the application cookie do not belong to the same user. OneConnect statistics show roughly 4,000 reused server-side connections during the same period. The virtual server has no source-IP persistence and no NTLM-specific iRule. The application owner says the backend cannot be changed to Kerberos this quarter. Peak concurrency is 8,000 users, and the IIS servers are sized for about 25,000 simultaneous TCP connections. The current monitor is a simple HTTP GET /health, and all six members are green.
1. What is the likely root cause, and how would you prove it?
Read the worked answer
OneConnect multiplexes multiple client requests onto a reused server-side TCP connection. NTLM authenticates the connection, not just the request: the server ties the authenticated security context to that TCP session. When BIG-IP reuses a connection authenticated as user A for a request from user B, IIS sees the NTLM header and cookie from different contexts, which produces re-authentication prompts and, in the worst case, returns user A's content to user B. The 4,000 reused connections and the mismatched IIS log entries are consistent with this.
Confirm by correlating a support case with tcpdump on the client and server VLANs: the client-side source IP changes while the server-side connection tuple stays the same. Check tmsh show ltm profile oneconnect and the pool member connection counts. Also verify that no iRule disables OneConnect for authorization headers. The simple HTTP monitor is not related, but it would not detect an authentication-layer failure.
2. What fix would you apply, and what trade-offs and capacity checks are involved?
Read the worked answer
The safest fix is to disable OneConnect on vs_intranet. That removes multiplexing and gives each client flow its own server-side connection, which NTLM requires. The trade-off is connection count: 8,000 concurrent users could approach 8,000 or more server connections, still below the 25,000 the IIS servers can handle, so capacity is acceptable. If you need to keep OneConnect for non-authenticated content, split the application onto two virtual servers, or use an iRule with ONECONNECT::reuse disable for the NTLM paths.
Be careful with header-based matching: the first request in an NTLM handshake has no Authorization header, so matching only on Authorization is unreliable. Match on the URL or disable reuse for the whole virtual server. Do not try to solve this with source-IP persistence; it does not guarantee that the same server-side connection is used. After the change, monitor server-side connection counts and IIS worker process limits.
3. What incident-response and validation steps follow from the cross-user page exposure?
Read the worked answer
Treat the cross-user page as a potential data exposure incident. Preserve BIG-IP and IIS logs, record the affected support IDs and timestamps, and notify the security team. Invalidate the application sessions and, if the application supports it, force re-authentication. Review whether any user saw data they were not entitled to; the page header alone may indicate a broader leak.
On the BIG-IP, confirm the fix by capturing traffic for a sample of users and verifying that the server-side connection changes when the client or NTLM context changes. Compare X-Forwarded-For with the IIS cs-username field for a day. Add a synthetic test that logs in as two users concurrently and checks that neither sees the other's name. Finally, review other virtual servers with OneConnect and NTLM or connection-oriented authentication, because the same pattern may exist elsewhere.