DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27134>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27134 mod_ldap/util_ldap blindly rebind connection in checkuserid Summary: mod_ldap/util_ldap blindly rebind connection in checkuserid Product: Apache httpd-2.0 Version: 2.0.48 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: mod_ldap AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] *** Overview *** In mod_ldap (util_ldap.c), during util_ldap_cache_checkuserid, ldap connection may be rebound to the checked user dn and still be known to be bound to its original dn or anonymous. Reuse of these connections may later lead to unexpected authentication failures. These problem are particularly annoying with an ldap server that refuse anonymous connection or in which users has no rights to read other users entry. This may also has some security problem since the connection pool may contain bound connection marked as anonymous one. *** Symptoms *** These problems are usually reported as no more good authentication after a failed or even successful previous authentication. Usually the following or a similar error is logged: auth_ldap authenticate: user <username> authentication failed; URI <URI> [User not found][No such object] *** Test case *** To easily trigger such problem, configure an ldap server that give access to the users entry only using an non-anonymous bound connection. Configure users to have no access to other user entry (you are now in the worst case). use the mod_auth_ldap with the following configuration on given URI: AuthType Basic AuthName "LDAP authentication" AuthLDAPEnabled on AuthLDAPBindDN <dn of the only ldap account that have access to all user entry> AuthLDAPBindPassword <password for this account> AuthLDAPURL <appropriate ldap url> AuthLDAPAuthoritative on Than try to access this URI using good and wrong authentication. Access to this URI will quickly became fuzzy and the message above will be reported for valid user with good and bad password. *** Explanation *** Here are the auth_util related steps involved in a mod_auth_ldap authentication: 1) mod_auth_ldap_check_user_id() gets called to check user authentication 2) mod_auth_ldap_check_user_id() retrieve a cached connection from util_ldap_connection_find() 3) util_ldap_connection_find() search for a connection matching the host, port, binddn/bindpw required by util_ldap_connection_find() which have taken these from your httpd configuration 4) if a matching connection is found, it is returned as is, else a non-matching connection is set to be unbound and is returned 5) mod_auth_ldap_check_user_id() provide the retrieved connection to util_ldap_cache_checkuserid() with the username/password provide by the user and the filter provide in your configuration 6) util_ldap_cache_checkuserid() check the user cache for a previous successful authentication of this user, if found, no use of the ldap connection is done 7) if none are found, the ldap connection is open using util_ldap_connection_open() which means bind the connection if it is currently known to be unbound using the binddn/bindpw previously stored by util_ldap_connection_find(), and set it to be known bound, else do nothing ! 8) search the ldap server for the dn of the user based on the provided filter 9) if one and only one record is return, retrieve the provided dn. 10) rebind the connection to the user dn using the provided user password to know if the user password is correct. This is done using, a direct call to an ldap api function called ldap_simple_bind_s(). The known to be bound and binddn of the util_ldap connection structure use for connection caching are not updated by this call which lead to the problem. 11) later, on return from util_ldap_cache_checkuserid, mod_auth_ldap_check_user_id release as is the connection to the cache using a misnamed function called util_ldap_connection_close. 12) if an error has been reported and only if this error is LDAP_SERVER_DOWN, the connection will be unbound (and some retries will be done), avoiding the problem when no server has answer (funny, no?) Has you should have understand, in step 10, the connection is rebound to another user without updating cache information and in step 11, this rebound connection is released to the cache. *** Solution *** To solve this issue, there is two options: 1) Synchronize the cache information of the provided connection with its new required binding, setting it to unbound and use util_ldap_connection_open() to rebound the connection properly which ensure correct util_ldap cache usage 2) Retrieve another connection from cache for the user authentication using util_ldap_connection_find(). Choosing between these option is choosing between keeping the 'search user' connection bound to the AuthLDAPBindDN opposed to using only one connection for authentication. I have seen a patch that use option two, but I am afraid that this patch does not properly release the first connection to the cache using util_ldap_connection_close. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
