[Auth_ldap] False negatives from auth_ldap 1.6.0

[Joe Formoso]

On Tue, 22 Feb 2005, Dave Carrigan wrote:

> You need to bump up logging on your ldap server to see what the server
> logs say at this time. This will tell you a) if the search term is
> really what auth_ldap claims it was and b) what exactly the directory is
> returning to auth_ldap to make it think it didn't get a result.
----------
	I confess that I thought the problem was with auth_ldap, since a
lot of other services that user our LDAP server never showed a problem,
but it in fact seems to be a problem with our iPlanet server.
Specifically, it seems to be a problem with long-running persistent
connections.  A doctored section of the LDAP log file runs thus:

-------------------------------------
[22/Feb/2005:19:53:18 -0500] conn=15451573 op=44 SRCH base="ou=people,o=foo.bar,o=foo" scope=2 filter="(&(objectClass=*)(uid=user1))" attrs=ALL
[22/Feb/2005:19:53:18 -0500] conn=15451573 op=44 RESULT err=0 tag=101 nentries=0 etime=0
[22/Feb/2005:19:53:21 -0500] conn=15451573 op=45 SRCH base="ou=people,o=foo.bar,o=foo" scope=2 filter="(&(objectClass=*)(uid=user1))" attrs=ALL
[22/Feb/2005:19:53:21 -0500] conn=15451573 op=45 RESULT err=0 tag=101 nentries=0 etime=0
[22/Feb/2005:19:56:20 -0500] conn=15451573 op=46 SRCH base="ou=people,o=foo.bar,o=foo" scope=2 filter="(&(objectClass=*)(uid=user2))" attrs=ALL
[22/Feb/2005:19:56:20 -0500] conn=15451573 op=46 RESULT err=0 tag=101 nentries=0 etime=0
-------------------------------------

	The "conn" indicates a particular connection ID, and "op"
indicates how many operations have happened on this particular
connection.  There's one line indicating the search (labeled "SRCH") and
one for the result (labeled "RESULT").  The "nentries" indicates the
number of entries returned.
	For all these examples (and all the other ones I could find for
this particular connection), the number of entries returned is 0,
despite the fact that I can confirm that, using this base, scope, and
filter, there is a unique entry that matches.
	So, my current theory is that iPlanet is timing out the
connection, but rather than it being closed or returning some meaningful
error, it's giving false negatives for any and all searches being run on
it.  Which is obviously insane and rude, but there you are.

	So, a followup: is anybody out there using auth_ldap against an
iPlanet/SunONE 5.x LDAP server?  If so, have you ever seen this problem?
And, further, is there a workaround?  The web app we're using this with
isn't heavily used, so we could turn off persistent connections to the
LDAP server (forcing a new bind for every user authentication) without taking
a real performance hit.  Assuming that's possible.

	Many thanks for any suggestions.


					--Joe

-----
Joe Formoso (jformoso at stevens-tech.edu),
  Senior Systems Administrator, IT Department, Stevens Institute of Technology