[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Strange TLS issue while upgrading from openldap 2.3 to 2.4

Le 28/06/2012 01:41, Quanah Gibson-Mount a écrit :

--On Wednesday, June 27, 2012 3:31 PM +0200 Guillaume Rousse
<guillomovitch@gmail.com> wrote:


Sorry, I'm not a Zimbra admin, and I may have been confusing in my
explanations. The problem occurs with Zimbra acting as an LDAP client
against an external LDAP server, performing a bind operation for
authenticating users, with the following behaviour:

Zimbra against on openldap 2.3.x server, with TLS on port 389: OK
Zimbra against on openldap 2.4.x server, on port 636: OK
Zimbra against on openldap 2.4.x server, with TLS on port 389: 30s delay


Ok, so what you are saying is:

You upgraded your OS to CentOS6

You use external auth

The external auth from CentOS6 to your own LDAP server shows a 30 second
delay on closing.

Almost :)
I upgraded the OS of the machine running the LDAP server, the zimbra server didn't change. So, that's the external auth from a RHEL 5.8 system running Zimbra 7, against a Centos 6.2 system running OpenLDAP 2.4.24. 


That sounds like a bug in Java/JNDI.  I did see some 30 second issues
with RHEL6, but it was with initiating a connection, not closing it.
Indeed. I don't see why either the ldap server or the ldap client would need to perform any DNS query once the connection has been accepted, and the TLS negociation was successful. 


You can see more about that at
<https://stomp.colorado.edu/blog/blog/2011/06/29/on-rhel-6-ssh-dns-firewalls-and-slow-logins/>


I would note that JNDI behavior varies based on startTLS vs SSL on port
636 as well.
Interesting. We tried the workaround, on both side (openldap server, then zimbra server), without any behaviour change.
The only thing I'm unsure, tough, is about the moment where a change in resolver configuration has an effect. As the resolver is technicaly a part of the glibc, and can never get reloaded, I guess it uses the file timestamp to detect file modification and reload it immediatly.
Also, I'll try to find some other example of java-based applications acting as LDAP client, in our environement 
--
BOFH excuse #443:

Zombie processes detected, machine is haunted.