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: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ldap/ldap/session_options.asp 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: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ldap/ldap/ldap_search_ext_s.asp 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.
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?
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 server.
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.
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?
FWIW, It seems that this issue has already been fixed on trunk: http://svn.apache.org/viewvc?view=rev&revision=517788 http://svn.apache.org/viewvc?view=rev&revision=586077 http://svn.apache.org/viewvc?view=rev&revision=509237
A committer needs to propose these modifications for backport.
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.
Thank you for pointing out the pending fix in trunk.
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.
If no one beats me to it, I will backport the apr-util bits later today.
Please do; I'll move forward with apr/apr-iconv packages and watch for this to be wrapped up.
Will, please backport it if you can. I am busy for a few hours now.
Backported to apr-util 1.2.x in r595268 and r595271. http://svn.apache.org/viewvc?view=rev&revision=595268 http://svn.apache.org/viewvc?view=rev&revision=595271 Testing is appreciated and any feedback welcome. Thanks for using the Apache HTTP Server.
(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 debugging: ----------------------------------------------------------------- Lightweight-Directory-Access-Protocol LDAPMessage searchRequest(2) "ou=System" wholeSubtree messageID: 2 protocolOp: searchRequest (3) searchRequest 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 requests. 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.
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.