LDAPS: Nuxeo performing too many bind

[Olivier_Salaün]

Hello,

While setting up our Nuxeo LTS2015 Test server we've realized that Nuxeo does not have a proper LDAPS client behavior (whereas it's fine wile using the LDAP protocol). Our LDAP servers logs show Nuxeo performing a new LDAP Bind for each Search operation. This was observed while doing a User search from the Admin>User and Groups menu. This leads to bad LDAP search performances and overloads the LDAP server. I provide details below with OpenLDAP log samples and our LDAP configuration file.

Is this a known problem of Nuxeo with LDAPS servers? (I could not find anything related in your bug tracker)

Is there a workaround?

Another option for us would be to use STARTTLS over LDAP, but I could not find any documentation related to Nuxeo and STARTTLS. Is STARTTLS implemented in Nuxeo? If so, is there a related documentation?

Here is what we find in our unsecured LDAP server logs when configured in Nuxeo; please note the connexion ID (conn=) that remains the same in all log entries :

Feb  8 14:58:26 vmldap-pro3 slapd[1757]: conn=51353 op=86 SRCH base="ou=people,dc=univ-rennes1,dc=fr" scope=1 deref=3 filter="(&(&(objectClass=person)(uid=*))(displayName=redon))"
Feb  8 14:58:26 vmldap-pro3 slapd[1757]: conn=51353 op=87 SRCH base="ou=people,dc=univ-rennes1,dc=fr" scope=1 deref=3 filter="(&(&(objectClass=person)(uid=*))(uid=redon))"
Feb  8 14:58:26 vmldap-pro3 slapd[1757]: conn=51353 op=88 SRCH base="ou=people,dc=univ-rennes1,dc=fr" scope=1 deref=3 filter="(&(&(objectClass=person)(uid=*))(mail=redon))"
Feb  8 14:58:26 vmldap-pro3 slapd[1757]: conn=51353 op=89 SRCH base="ou=people,dc=univ-rennes1,dc=fr" scope=1 deref=3 filter="(&(&(objectClass=person)(uid=*))(sn=*redon*))"

Here is what we find in our secured LDAPS server logs when configured in Nuxeo; please note the connexion ID (conn=) that is different in all log entries :

Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116702 op=1 SRCH base="ou=people,dc=univ-rennes1,dc=fr" scope=1 deref=3 filter="(&(&(objectClass=person)(uid=*))(displayName=redon))"
Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116707 op=1 SRCH base="ou=people,dc=univ-rennes1,dc=fr" scope=1 deref=3 filter="(&(&(objectClass=person)(uid=*))(mail=redon))"
Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116711 op=1 SRCH base="ou=people,dc=univ-rennes1,dc=fr" scope=1 deref=3 filter="(&(&(objectClass=person)(uid=*))(sn=*redon*))"
Feb  8 15:39:52 vmldap-pro2 slapd[14842]: conn=1116977 op=1 SRCH base="ou=grouper,dc=univ-rennes1,dc=fr" scope=1 deref=3 filter="(&(cn=mredon)(&(&(objectClass=groupOfNames))(cn=*)))"

An additional research in the LDAPS server log on one connexion ID confirms that Nuxeo performs a single LDAP Search query before Unbinding :

Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116702 fd=425 ACCEPT from IP=129.20.123.2:36256 (IP=0.0.0.0:636)
Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116702 fd=425 TLS established tls_ssf=128 ssf=128
Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116702 op=0 BIND dn="XX" method=128
Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116702 op=0 BIND dn="XX" mech=SIMPLE ssf=0
Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116702 op=0 RESULT tag=97 err=0 text=
Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116702 op=1 SRCH base="ou=people,dc=univ-rennes1,dc=fr" scope=1 deref=3 filter="(&(&(objectClass=person)(uid=*))(displayName=redon))"
Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116702 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116702 op=2 UNBIND
Feb  8 15:39:43 vmldap-pro2 slapd[14842]: conn=1116702 fd=425 closed

An extract from our default-ldap-users-directory-bundle.xml configuration file:

  <extension target="org.nuxeo.ecm.directory.ldap.LDAPDirectoryFactory"
    point="servers">

    <!-- Configuration of a server connection

      A single server declaration can point to a cluster of replicated
      servers (using OpenLDAP's slapd + sluprd for instance). To leverage
      such a cluster and improve availability, please provide one
      <ldapUrl/> tag for each replica of the cluster.
    -->
    <server name="default">

      <ldapUrl>ldaps://ldap.univ-rennes1.fr:636</ldapUrl>
      <bindDn>XX</bindDn>
      <bindPassword>XX</bindPassword>
   
      <retries>5</retries>
    </server>

  </extension>

  <extension target="org.nuxeo.ecm.directory.ldap.LDAPDirectoryFactory"
    point="directories">

    <directory name="ldapUserDirectory">
      <server>default</server>
      <schema>user</schema>
      <idField>username</idField>
      <passwordField>password</passwordField>

      <searchBaseDn>ou=people,dc=univ-rennes1,dc=fr</searchBaseDn>
      <searchClass>person</searchClass>
      <searchScope>onelevel</searchScope>
      <substringMatchType>subany</substringMatchType>
      <readOnly>true</readOnly>
      <cacheEntryName>ldap-user-entry-cache</cacheEntryName>
      <cacheEntryWithoutReferencesName>ldap-user-entry-cache-without-references</cacheEntryWithoutReferencesName>

      <missingIdFieldCase>lower</missingIdFieldCase>
      <querySizeLimit>200</querySizeLimit>
      <queryTimeLimit>0</queryTimeLimit>
      <creationBaseDn>ou=people,dc=example,dc=com</creationBaseDn>
      <creationClass>top</creationClass>
      <creationClass>person</creationClass>
      <creationClass>organizationalPerson</creationClass>
      <creationClass>inetOrgPerson</creationClass>

      <rdnAttribute>uid</rdnAttribute>
      <fieldMapping name="username">uid</fieldMapping>
      <fieldMapping name="password">password</fieldMapping>
      <fieldMapping name="firstName">givenName</fieldMapping>
      <fieldMapping name="lastName">sn</fieldMapping>
      <fieldMapping name="company">supannEtablissement</fieldMapping>
      <fieldMapping name="email">mail</fieldMapping>
      <fieldMapping name="displayName">displayName</fieldMapping>

      <references>
        <inverseReference field="groups" directory="multiGroupDirectory"
          dualReferenceField="members" />
      </references>

    </directory>

[Olivier_Salaün · Accepted solution]

Thank you to Pierre Bouvret for providing the solution: As described in the Java/JNDI documentation: To allow both plain and SSL connections to be pooled, set the "com.sun.jndi.ldap.connect.pool.protocol" system property to the string "plain ssl". How strange this default JNDI setup...

I can confirm it fixes our problem; there is now a reasonable amount of LDAPS bind.