| Summary: | Apache returns 500 Error when no LDAP credentials are supplied | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Dan Stusynski <dstusynski> |
| Component: | mod_authz_ldap | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED LATER | ||
| 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
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) 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 APR_HAS_MICROSOFT_LDAPSDK if ( (result == LDAP_FILTER_ERROR) && (strlen(r->user) <= 0) ) { ldc->reason = "ldap_search_ext_s() to search for user failed"; ldap_msgfree(res); uldap_connection_unbind(ldc); return LDAP_INVALID_CREDENTIALS; } #endif Place this just after the ldap_search_ext_s() ldap call and before the all encompassing if (result != LDAP_SUCCESS) statement. 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>
<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
</Location>
ErrorLog logs/xxxxxxxx-ssl-error_log
CustomLog logs/xxxxxxxxx-ssl-access_log combined
</VirtualHost>
Modules loaded:
auth_basic_module
ldap_module
authnz_ldap_module
The same configuration works with RHEL5.x and httpd 2.2.3.
Ignasi, don't misapropriate someone elses open bug report. 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. |