On a moderately busy server, we regularly (usually every 5 Minutes) see this:
WARN [org.ldaptive.pool.BlockingConnectionPool:882] - org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@3150f6a8 failed validation
Some lines before that, we see this:
DEBUG [org.ldaptive.pool.SearchValidator:100] - validation failed for search request ... org.ldaptive.LdapException: javax.naming.OperationNotSupportedException: [LDAP: error code 53 - authentication required]; remaining name ''
We can see the err=53 in LDAP log as well. This looks like this:
conn=24903 op=21 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
conn=24903 op=21 SRCH attr=1.1
conn=24903 op=21 SEARCH RESULT tag=101 err=53 nentries=0 text=authentication required
The funny thing is, this IdP and this LDAP usually get an err=0 for the same valdiation request. So for conn=1234 this would not fail. However, this particular conn=24903 has exactly before this err=53 the following in LDAP log:
conn=24903 op=20 BIND dn="uid=user1,dc=example,dc=org" method=128
conn=24903 op=20 RESULT tag=97 err=49 text=
This seems to suggest that any connection from the LDAP pool where some user failed to authenticate beforehand will not be usable afterwards. And worse, the connection validatation seems to re-use the respective latest credentials, instead of the service credentials that are configured in ldap.properties.