Bug 45393

Summary: Apache returns 500 Error when no LDAP credentials are supplied
Product: Apache httpd-2 Reporter: Dan Stusynski <dstusynski>
Component: mod_authz_ldapAssignee: Apache HTTPD Bugs Mailing List <bugs>
Severity: normal CC: covener
Priority: P2 Keywords: MassUpdate
Version: 2.2.8   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   

Description Dan Stusynski 2008-07-14 11:07:35 UTC
There seems to be an issue on Windows Apache 2.2.9 when compiled against the MSSDK for LDAP. When a user accesses a authenticated resource and is prompted for credentials, if they do not enter a username and password and instead hit ok at the prompt, Apache returns a 500 error due to a filter error.

Excerpt from the Error Log:
[Mon Jul 14 11:16:04 2008] [debug] mod_headers.c(711): headers: ap_headers_output_filter()
[Mon Jul 14 11:16:08 2008] [debug] mod_authnz_ldap.c(377): [client] [6488] auth_ldap authenticate: using URL ldap://server:389/ou=people,cn=EnterpriseLdap,cn=app,dc=server,dc=subdomain,dc=domain,dc=com, referer: http://server:10080/app/
[Mon Jul 14 11:16:08 2008] [warn] [client] [6488] auth_ldap authenticate: user  authentication failed; URI /app/servlet/Navigation [ldap_search_ext_s() for user failed][Filter Error], referer: http://server:10080/app/

Taken from the Access Log: - - [14/Jul/2008:11:16:08 -0500] "GET /PDMPJL91/servlet/Navigation HTTP/1.1" 500 487 15625

I was slightly curious about this so I recompiled with a few lines of "random" debugging to see what statements where firing and what some variables were being set to in mod_authnz_ldap.c and util_ldap.c.

In mod_authnz_ldap.c's function static void authn_ldap_build_filter(...):
I added a logging statement in the 
if (sent_user != NULL) {
        user = apr_pstrdup (r->pool, sent_user);
to see what the user was being set to in the event this statement was executing. Ther user was logged as "user=[]" and is clearly not NULL which I expected since in fact the if(sent_user != NULL) was executing. I originally didn't expect this statement to execute at all.

The filter eventually gets created by:
        filter = sec->filter;

and is set to the "objectclass=*" (my logs kick out filter=[objectclass=*]). From a quick glance that appears to be a valid filter for the MS ldap_search_ext_s API.

Then when authn_ldap_check_password function gets executed I originally expected the request to error out on the password=NULL and/or the username=NULL check, however, these did not execute. I guess that means the empty user/pass is an empty string as opposed to NULL.

In util_ldap.c the statement:
result = ldap_search_ext_s(ldc->ldap,
                               (char *)basedn, scope,
                               (char *)filter, attrs, 0,
                               NULL, NULL, NULL, APR_LDAP_SIZELIMIT, &res);

in results error code being Filter Error from the logs.

For sanity sake, I tested with Firefox and IE to rule out any odd IE quirk. 

Is this an Apache issue not handling the blank user/pass credentials properly?
Comment 1 Eric Covener 2008-07-14 13:50:06 UTC
I went down this path for another PR (or issue raised on IRC) a few months ago.

The empty userid is permitted by HTTP basic auth, and some LDAP SDKs do support the filter generated such as "attr=" with no value.  I believe I lost the heart to try to change it when both openldap and Tivoli directory server supported the syntax.

if you can find chapter and verse of the LDAP filter syntax that says it's forbidden, mod_authnz_ldap would be able to short-circuit sending the DN search -- otherwise we'd have to add some special-case MSSDK logic to do the same (to prevent the 500, request still forbidden obviously)
Comment 2 Dan Stusynski 2008-07-17 13:18:05 UTC
The additional bug 41435 seems the same as this one I reported (not sure if that is what you were referring to). I tried to decide on a way to modify mod_authnz_ldap.c authn_ldap_build_filter() function to handle this situation but I don't see a way that one can build a valid MS LDAP filter that is 1) valid for syntax and 2) that isn't guaranteed to return any users. Simply using objectclass=* wouldn't work for the use case of 1 LDAP user, nor would the attempt to have a uid=null (a null string) since that gets translated to a literal uid when searching LDAP (as opposed to '\0' or similar C representation).

I'm left thinking that just modifying util_ldap.c as the original poster in that bug mentioned is a decent option while adding a check that the requests user isn't blank (so we only gobble the FILTER_ERROR when a username is blank). For example: 

/* MS LDAP SDK returns a FILTER ERROR when searching for "attr=" 
   attribute=nothing). Check the result error and user length from the request
   and return invalid instead of 500. */
    if ( (result == LDAP_FILTER_ERROR) && (strlen(r->user) <= 0) )
        ldc->reason = "ldap_search_ext_s() to search for user failed";

Place this just after the ldap_search_ext_s() ldap call and before the all encompassing if (result != LDAP_SUCCESS) statement.

Comment 3 Ignasi 2011-01-21 07:27:23 UTC
We have Linux RHEL6 with httpd 2.2.15, and after loged with LDAP username and password, apache return 500 error.

No information available about this error in the server error log.

With the follow configuration:

# vim: syntax=apache

<VirtualHost _default_:443>
    SSLEngine On
    SSLProtocol all -SSLv2
    SSLCipherSuite HIGH:MEDIUM
    SSLCertificateFile /etc/pki/tls/certs/xxx.crt
    SSLCertificateKeyFile /etc/pki/tls/private/xxxxxxxxx.key
    ServerName xxxxxxxxxx
    ServerAlias xxxxxxxxxxxxx
    DocumentRoot /var/www/xxxxxxxx
    # Specific configuration
    <Location /private/status>
        SetHandler server-status
    <Location />
        AuthType Basic
        AuthName "Admin xxxxxx"
        AuthBasicProvider ldap
        AuthzLDAPAuthoritative on
        AuthLDAPURL ldaps://ldap.xxxxxxxx.com/ou=People,dc=xxxxx,dc=com?uid?one
        Require ldap-user xxxx xxxx
    ErrorLog logs/xxxxxxxx-ssl-error_log
    CustomLog logs/xxxxxxxxx-ssl-access_log combined

Modules loaded:


The same configuration works with RHEL5.x and httpd 2.2.3.
Comment 4 Eric Covener 2011-01-21 07:38:15 UTC
Ignasi, don't misapropriate someone elses open bug report.
Comment 5 William A. Rowe Jr. 2018-11-07 21:08:41 UTC
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.