cancel
Showing results for 
Search instead for 
Did you mean: 

LDAPS: Nuxeo performing too many bind

Olivier_Salaün
Champ on-the-rise
Champ on-the-rise

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>
1 ACCEPTED ANSWER

Olivier_Salaün
Champ on-the-rise
Champ on-the-rise

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.

View answer in original post

1 REPLY 1

Olivier_Salaün
Champ on-the-rise
Champ on-the-rise

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.

Getting started

Find what you came for

We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.