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

Re: (ITS#6383) Very Slow Query Response

--On November 18, 2009 9:39:02 AM +0000 Bill MacAllister <whm@stanford.edu> 

>> For historical note this was caused by Cyrus-sasl being built
>> incorrectly by the debian packagers when heimdal is used.
> I don't understand why you refer to this finding as historical.

Not a historical finding. As a record for anyone who comes across this ITS 
and wants to know what was found.

> If I
> am reading this correctly you and Howard have found the underlying
> cause.  Now that the problem is understood can you suggest a way for
> us to cause the problem in our test environments?  At this point we
> will really need to convince ourselves that the problem is indeed fixed
> before we try to deploy 2.4 in our production environment again.

To note, first off, this issue was not a bug in OpenLDAP, and the project 
went beyond its scope in tracking down why cyrus-sasl was behaving the way 
it was.  Finding out test cases for you to explore is also beyond the scope 
of the OpenLDAP project when dealing with non-OpenLDAP issues.

However, given what is known, i.e., that the NTLM code path was being 
called during SASL/GSSAPI binds, I would suggest you either set up a number 
of windows boxes that try and do SASL/GSSAPI auth with NTLM to a test 
server, or write a script that does that and run it from multiple systems.

Some reference points:


It also seems it may be possible to use python-ldap to do this.  I don't 
know if it is possible with Net::LDAP or Net::LDAPapi



Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
Zimbra ::  the leader in open source messaging and collaboration