Downloaded apache 2.0.44 for WinNT. Installed it and configured it to support webDAV, uncomment the dav and davfs loadmodule lines. Configured Apache to support webDAV on one directory. Confirmed webDAV was working. Then configured the same directory to require a valid user, by adding the lines to support for the utils_ldap module, and the mod_auth_ldap module. Then configured the appropriate LDAP directives as shown:- LDAPSharedCacheSize 200000 LDAPCacheEntries 1024 LDAPCacheTTL 600 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 600 DavLockDB "C:/temp/DavLock" <Directory "C:/Program Files/Apache Group/Apache2/htdocs/dav"> AuthType Basic AuthName "WebDAV Auth to LDAP server" AuthLDAPEnabled on AuthLDAPURL "ldap://169.192.1.31:2890/ou=People,o=jpmchase,o=jpmc?uid? one" AuthLDAPAuthoritative on Options -Indexes Dav On <LimitExcept GET HEAD OPTIONS> allow from all require valid-user </LimitExcept> </Directory> Now when ever I access the dav directory Apache prompts for the username and password, after inputting them it crashes. This is repeatable and the application event viewer reports The application, , generated an application error The error occurred on 3/25/2003 @ 16:22: 7.108 The exception generated was c0000005 at address 77957d70 (ldap_result) The error log reports [Tue Mar 25 16:24:14 2003] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Tue Mar 25 16:24:14 2003] [notice] Parent: Created child process 644 [Tue Mar 25 16:24:14 2003] [notice] Child 644: Child process is running [Tue Mar 25 16:24:15 2003] [notice] Child 644: Acquired the start mutex. [Tue Mar 25 16:24:15 2003] [notice] Child 644: Starting 250 worker threads I then created another directory called test and didn't configure this for webdav support, but did have it protected. When accessing it with a browser it asked for my username and password and then again crashed with the same error.
Hmmm.... mod_auth_ldap worked fine for me back at 2.0.43. It no longer does at 2.0.45 (I skipped 2.0.44) -- see comments on bug #18756.
P.S. My error log shows the same basic thing and with LogLevel of debug only manages to show that it is attempting the authentication when this occurs.
Can you confirm whether this bug still exists in v2.1.0-dev?
I just tested it with the current 2.1 CVS version. (Same true for 2.0.49) It still crashes. It is compiled&linked against the MS ldap libraries. What is the correct way to build apache 2.x with the Netscape/iPlanet ldap SDK ? Just copying it to the srclib/ldap does not seem to have any effect. Here the callstack I'm able to show: WLDAP32! 77942d58() WLDAP32! 7794b622() WLDAP32! 7794eb91() util_ldap_cache_checkuserid(request_rec * 0x00826580, util_ldap_connection_t * 0x007e14d8, const char * 0x00809560, const char * 0x008095c0, int 1, char * * 0x008095d0, const char * 0x0866dec4, const char * 0x00827edc, const char * * 0x0866debc, const char * * * 0x0866deac) line 817 + 13 bytes mod_auth_ldap_check_user_id(request_rec * 0x00826580) line 331 + 85 bytes ap_run_check_user_id(request_rec * 0x00826580) line 69 + 78 bytes ap_process_request_internal(request_rec * 0x00826580) line 193 + 9 bytes ap_process_request(request_rec * 0x00826580) line 244 + 9 bytes ap_process_http_connection(conn_rec * 0x00822898) line 253 + 9 bytes ap_run_process_connection(conn_rec * 0x00822898) line 42 + 78 bytes ap_process_connection(conn_rec * 0x00822898, void * 0x00822478) line 177 worker_main(long 499) line 774 _threadstartex(void * 0x008222d8) line 212 + 13 bytes KERNEL32! 77e7438b()
Line 817 in my util_ldap.c code is this: if (LDAP_SUCCESS != (result = util_ldap_connection_open(r, ldc))) { If this is the case, then the trace is bombing out on the call to util_ldap_connection_open(), which doesn't make sense. I assume that it's bombing out with util_ldap_connection_open. Is it the same in your snapshot? I want to check whether we're talking about the same code.
Yep, it's on the very same line. I have now rebuilt apache with the most current platform SDK from MS, and now it does no longer crash. According to Jess, it will work with the MS SDK Spring 2003 Is there a way to detect the version of the SDK and throw an error if it's "too old" ? André
Quite probably - though currently apr-util only exports the type of LDAP client library being used, not the version of the library being used. Perhaps this suggestion should be posted to the apr@apr.apache.org mailing list, in other words suggest that an attempt to build apr-util against a too-old version of the LDAP library would either generate a #warning for throw an #error. This isn't an httpd thing though, it's an apr-util thing.
Is it possible to provide a test for the version of the MS library that no longer works? I don't have access to an MS build environment :(
Marking this as fixed, as the problem seems to be with old Microsoft SDKs and not httpd...
the same problem has been experienced on apache 2.0.53 official binary release for windows , so if the SDK is the problem , the process of building the official windows releases needs to be checked over
What's the status of this issue? Is it something specific to the Microsoft LDAP library? Any idea what can be done (if anything?) to fix it in mod_auth_ldap, if so?
*** Bug 35015 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > What's the status of this issue? It's still a potential problem. > Is it something specific to the Microsoft LDAP > library? It's a problem, when you have a older Microsoft LDAP SDK installed, when auth_ldap is build against a old version, then it can crash at runtime. When you use a new SDK, then it runs fine. > Any idea what can be done (if anything?) to fix it in mod_auth_ldap, > if so? I think the only correct way would be to detect the version of the SDK and if it's too old, then stop the build process. >According to Jess, it will work with the MS SDK Spring 2003 No idea how to check the version... André
This is still happening with 2.0.55 MSI installer - is there any chance of a version compiled against the correct LDAP libraries for those of us who need binaries?
We're seeing this as well with 2.0.55 MSI package. Is anyone working on a fresh 2.0.56? build
I think there's no way to find out the SDK version. But there may be a workaround: Let's say you want to ensure that the Windows Server 2003 SP1 SDK is used. Then first find a function that is new in Windows Server 2003 SP1, e.g. NetDfsMove. Then try to compile a file using such a function. Here's an example for such a file: #include <Windows.h> #include <Lm.h> #include <LmDfs.h> int main(int argc, char* argv[]) { NET_API_STATUS (NET_API_FUNCTION *dummy)(LPWSTR, LPWSTR, ULONG) = NetDfsMove; return 0; } You don't even have to try to link it; trying to compile it is enough. If it compiles, fine, if not, then the SDK is too old. It would be great if a new Apache version that fixes this could be released soon - it seems some people have been waiting for it a long time now, and not everyone is capable of compiling Apache.
Hi, Any chance of someone with a working mod_auth_ldap.so binary attaching it to this bug (assuming it's just this binary that is affected). The 2.0.55 win32 released binaries still exhibit this bug. Thanks, Ralph.
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.