The long delays inserted in by the failpoints in this test factor into the connection pool's analysis of how healthy its pools of open connections are on Windows but less so on Linux. Since all of the connections in this test go out to the same LDAP server, they belong to the same connection pool. When the connection pool detects that several of the connections to a specific host are frequently timing out, it assumes that the host is down and expires the entire pool so that it is not wasting time spamming a downed host with connection requests. When this occurs, both connections that have hit the failpoint directly and those that have not hit the failpoint are closed by the pool.

This sequence of events explains why the test has been occasionally seeing more authentication failures than it expects. The test has no way of deterministically predicting when the connection pool will decide that the LDAP server must be down and will close all connections at will. More importantly, this behavior simply indicates that the connection pool is working as designed and should not be picked up as failures by this test.

To fix this, the test should be redesigned to not expect a deterministic number of successes and failures during auth attempts. Rather, it should simply ensure that the server returns some kind of response roughly within the connection pool's configured timeout and does not crash during long hangs.