Uploaded image for project: 'Identity Provider'
  1. Identity Provider
  2. IDP-1441

BlockingConnectionPool: failed validation

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.4.3
    • Fix Version/s: 4.0.1
    • Component/s: Authentication, LDAP
    • Labels:
      None
    • Operating System:
      Linux
    • Java Version:
      Oracle Java 8
    • Servlet Container:
      Apache Tomcat 8.5

      Description

      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.

       

        Attachments

          Activity

            People

            Assignee:
            dfisher@vt.edu Daniel W Fisher
            Reporter:
            martin.haase@daasi.de Martin Haase
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 days, 2 hours
                2d 2h