Poor LDAP/AD performance with SSL

Openfire Openfire Support
1

I have a small AD directory with just over 200 objects.

With SSL enabled it take almost 60sec to return 200 objects

without SSL it only takes 1-2 secs

Is anyone else seeing this?

2

I have the same problem. I think that is a problem with ldap connection pooling an SSL - the connection pooling doesn’t work! I don’t know why. I played with the -Dcom.sun.jndi.ldap.connect.pool.* options… Nothing works very well with openfire 3.10.0.

let’s see if I find out something else

Cheers

Robert

3

I fired up wireshark. Things look a little strange, but I’ll do my best to describe what I see.

with ssl:

It looks like a connection reset is performed after almost every searchResEntry was returned. This happened after almost every AD object. Signing into the UI; 4-5 new connections were created. Each time a bind was made, keys had to be reneg, etc. When I clicked the user/groups tab, I saw 100s if not 1000s of connection reset, reneg, binding, etc. it was crazy!

The result was the same with connection pooling enabled and disabled.

OF 3.10 rc1

java 1.8_45

Windows 2012r2

4

I tried a few things too to improve performance, but nothing seemed to work. Keep in mind I’m in no way a coder!

Referring to Connection Pooling Configuration

I didn’t see com.sun.jndi.ldap.connect.pool.protocol set, and it looks like the default is set to plain. I tried setting it using “-Dcom.sunjndi.ldap.connect.pool.protocol=plain ssl” with no luck. I also tried setting it in the code using system.setproperty, but that didn’t seem to make any difference.

Also referencing the java link, I saw this

“There are a couple of environment properties that automatically disqualify a Context instance from using a pooled connection. A Context instance cannot use a pooled connection if it has its"java.naming.ldap.factory.socket” property set to a custom socket factory class, or its “java.naming.security.sasl.callback” property set to a custom callback handler class, or its"com.sun.jndi.ldap.trace.ber" property set to enable protocol tracing."

in the code there is a java.naming.ldap.factory.socket for a custom socket being used, and com.sun.jndi.ldap.trace.ber is used when debug is enabled. I disabled debugging, and comment out the custom ssl socket. still no luck. While googling this, some people dropped the use of JNDI all together, and went with other libraries. Regardless, I’m sure this will be an easy fix for someone that knows what they are doing

1 Like
5

Hi,

thanks for the Java link and the hint to “java.naming.ldap.factory.socket”… This is exactly the problem, openfire use his own socket class: https://github.com/igniterealtime/Openfire/blob/master/src/java/org/jivesoftware /openfire/ldap/LdapManager.java#L496-L501

I try to build my own openfire without the “java.naming.ldap.factory.socket” setting.

I can’t found any issue at System Dashboard - Jive Software Open Source with the SSL pooling problem or “java.naming.ldap.factory.socket”. I will open an issue next days…

Cheers

Robert

6

I think I was able to get this to work.

within ldapmanager

I had to comment out the use of the custom socket SimpleSSLSocketFactory From what I can tell, it looks like this socket is used to accept all ssl certs, ie self signed. So you’ll need to import your ssl into java.

I then had to add

System.setProperty(“com.sun.jndi.ldap.connect.pool.protocol”, “plain ssl”) around line 526

rebuilt and test. That seemed to have done the trick.

1 Like
7

awesome, please open an issue for the openfire developers!

Thanks!

8

It looks like ssl connection pooling is supported with custom sockets per

JNDI/LDAP Service Provider using Comparator interface in the custom socket (15.3.3) . I have no idea how to implement it, but if want to continue to use the custom socket, than you’ll need to modify it a bit to make it work with ssl connection pooling.