BlockingConnectionPool: failed validation
Description
Environment
Activity
Daniel Fisher May 27, 2020 at 5:33 AM
Daniel Fisher May 15, 2020 at 2:18 PM
I'm going to use this issue to track this functionality into v4.
Daniel Fisher May 15, 2020 at 12:15 AMEdited
The problem here is that pool validation occurs by default on the rootDSE and your directory isn't allowing those authenticated connections to perform that search.
In my experience that's uncommon and you may find it easier to simply relax that particular ACL.
However, the software fix in IDPv3 is to use a passivator that returns the connection to a state that is allowed to execute the search.
See ldap-authn-config.xml
Then add a reference to the passivator in the bindConnectionPool
Scott Cantor January 13, 2020 at 1:50 PM
Every last detail of how authentication and use of the attribute resolver are configured, basically.
The most likely workaround is using JAAS to configure the LDAP module instead of native LDAP authentication. I use JAAS, so to the extent that I can promise it's not broken, that's the only real promise I can make.
Martin Hitschel January 13, 2020 at 1:47 PM
Scott, can you please be more specific here? Which configuration samples are needed, and what are the alternatives - if not the UnboundID stuff?
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.