Bug 37814 - auth_ldap built with the Microsoft LDAP SDK will not work at all with Openldap 2.2.x.
Summary: auth_ldap built with the Microsoft LDAP SDK will not work at all with Openlda...
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_auth_ldap (show other bugs)
Version: 2.0.55
Hardware: PC Windows Server 2003
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: PatchAvailable
Depends on:
Reported: 2005-12-06 23:36 UTC by Andy Wang
Modified: 2007-12-05 17:58 UTC (History)
3 users (show)

patch to force 2147483647 size limit when microsoft LDAPSDK is used (1.66 KB, patch)
2006-02-02 21:52 UTC, Andy Wang
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Wang 2005-12-06 23:36:15 UTC
OpenLDAP 2.2.x strictly enforces the sizelimit on a search.  The size limit in
the LDAP RFC is limited to a maximum of (2^31)-1 (i.e. a signed int).  The max
sizelimit with Microsoft's SDK is (2^32) -1  which is out of spec and openldap
2.2.x will error out when an unlimited search request comes in.
The size limit for MS's LDAP library is documented here:

I tried to modify util_ldap to do a ldap_set_option to set the sizelimit on
windows to a more sane value and unfortunately it doesn't work.  The reason is
that the util_ldap code uses ldap_search_ext_s and it accepts a SizeLimit
argument which overrides the session options.  This is documented at:

I can only theorize that Microsoft is defaulting to some library default rather
than the session value (which openldap defaults to).

I have a couple of ideas to solve the problem programmatically (rather than
rebuilding with the iplanet SDK, which may have distribution restrictions, or
the openldap sdk, which may have other complexities involed as i don't know that
it was ever intended for windows deployment).

All of apache's usage of ldap_search_ext_s passes in NULL's for the arguments
that above and beyond ldap_search_s' arguments.  Why not just use ldap_search_s?
 This will use the session limit.  The other option is to use a wrapper search
function which uses #if clauses to pass in a sane SizeLimit on windows, and keep
the normal behavior with other SDKs.
Comment 1 John P. Petrakis 2005-12-29 00:27:00 UTC
This also happens with Apache 2.2.0... running slapd -d 3 indicates the same
"invalid size limit" problem.  Has your programmatic approach worked for you?
Comment 2 Andy Wang 2006-02-02 21:52:17 UTC
Created attachment 17574 [details]
patch to force 2147483647 size limit when microsoft LDAPSDK is used

Patch to force 2147483647 size limit on ldap_search_ext_s calls in util_ldap.c
when microsoft LDAPSDK is used.

This allowed apache on windows to authenticate against an openldap 2.2.x
Comment 3 Andy Wang 2007-11-14 10:11:39 UTC
I've gotten a number of pings on this offline.  Is there anyway I can convince
an Apache dev to look at this bug and consider a real fix for this?  My patch
isn't the most elegant, but it's functional (I haven't done real C code in years
now), so I'm thinking that an Apache dev might have come up with something prettier.
Comment 4 Milo Chan 2007-11-14 10:14:52 UTC
I have encountered this problem with httpd 2.2.6, so it has never been resolved
by Apache or by Microsoft.  Can this patch or something similar be integrated?
Comment 6 Davi Arnaut 2007-11-14 10:51:11 UTC
A committer needs to propose these modifications for backport.
Comment 7 Davi Arnaut 2007-11-14 10:58:16 UTC
Also already fixed in the 2.2.x branch of httpd:


This is a apr-util bug now, revision r586077 needs to be backported.
Comment 8 Milo Chan 2007-11-14 11:10:09 UTC
Thank you for pointing out the pending fix in trunk.
Comment 9 Andy Wang 2007-11-14 11:26:00 UTC
Davi, thanks for the thorough explanation.  I noticed the change to
APR_LDAP_SIZELIMIT but didn't see that defined anywhere in the APR bundled with
Apache 2.2.x, so I was confused.  Now this makes alot more sense.  Once again,
thanks much for clearing it up.  Should I file a new bug against Apache 2.2.x to
request the APR fix backported, or is someone already on it?  Personally, I
don't care if this doesn't get fixed in 2.0, and I really don't expect you guys
to fix it in 2.0 either.
Comment 10 Davi Arnaut 2007-11-14 11:29:32 UTC
If no one beats me to it, I will backport the apr-util bits later today.
Comment 11 William A. Rowe Jr. 2007-11-14 11:57:42 UTC
Please do; I'll move forward with apr/apr-iconv packages and watch for this
to be wrapped up.
Comment 12 Davi Arnaut 2007-11-14 12:11:02 UTC
Will, please backport it if  you can. I am busy for a few hours now.
Comment 13 Davi Arnaut 2007-11-15 03:35:14 UTC
Backported to apr-util 1.2.x in r595268 and r595271.


Testing is appreciated and any feedback welcome.

Thanks for using the Apache HTTP Server.
Comment 14 Ryan Carpenter 2007-12-05 16:19:33 UTC
(In reply to comment #7)
> Also already fixed in the 2.2.x branch of httpd:
> http://svn.apache.org/viewvc?view=rev&revision=527105
> This is a apr-util bug now, revision r586077 needs to be backported.

I'm running Apache 2.2.6 (from a binary distribution on Windows) and I'm still 
seeing this error. The following is the translated LDAP searchRequest from the 
packet sniffer I used to view the traffic to and from my LDAP server during 

	LDAPMessage searchRequest(2) "ou=System" wholeSubtree
		messageID: 2
		protocolOp: searchRequest (3)
				baseObject: ou=System
				scope: wholeSubtree (2)
				derefAliases: derefAlways (3)
				sizeLimit: 4294967295
				timeLimit: 0
				typesOnly: False
				Filter: (&(objectclass=*)(uid=test))
				attributes: 0 items

Note that the offending sizeLimit value is still there. This is causing a 
failure with both OpenLDAP, as well as likely being a problem with ApacheDS. I 
can't tell for sure that this is the case, since the error message returned 
from ApacheDS 1.0.2 is the cryptic "The server will disconnect!", rather than 
the informative "invalid size limit" returned by OpenLDAP. However, given this 
is a known issue with other LDAP servers and the fact that the rest of the 
request looks good, it's likely the cause. ApacheDS 1.5.1 reacts quit badly, 
as well. However, instead of returning an error it doesn't return at all, 
hanging the request that initiated the LDAP call, and causing Apache and 
ApacheDS to simply ping each other back and forth with TCP PSH and ACK 

The above LDAP search request came from an install of the binary distribution 
of Apache 2.2.6 from the apache_2.2.6-win32-x86-openssl-0.9.8e.msi. It's 
running on Windows XP Professional 2002 SP 2. I see the following entry in the 
change logs which came with the distribution:

     *) mod_ldap: Remove the hardcoded size limit parameter for
          ldap_search_ext_s and replace it with an APR_ defined
          value that is set according to the LDAP SDK being used.
          [David Jones ]

Nevertheless, it doesn't seem to have resolve the size limit problem on 
Windows. Shouldn't this have been included in the 2.2.6 release? I see there 
are some comments in the thread here about the "pending" change, but based on 
the entry for the change logs with the 2.2.6 release it appears to me that 
this issue shouldn't be reoccurring in that version. Any feedback on why this 
is still occuring would be appreciated.
Comment 15 Eric Covener 2007-12-05 17:58:52 UTC
The fix for not passing -1 for the sizelimit to MSSDK requires the recently
released apr-util 1.2.12.  

httpd 2.2.6 was released before apr-util 1.2.12; the next httpd release will
pick up this apr-util version (or later).

The quoted change from David Jones is not the fix for this issue, this addressed
other SDKS that didn't accept -1.