Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
Date: 13 Nov 2003 13:46:03 -0000
Message-ID: <20031113134603.6100.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 24683] New:  -
    mod_auth_ldap 'remembers' the wrong dn

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=24683>.
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=24683

mod_auth_ldap 'remembers' the wrong dn

           Summary: mod_auth_ldap 'remembers' the wrong dn
           Product: Apache httpd-2.0
           Version: 2.0.44
          Platform: Other
               URL: http://www.rudedog.org/pipermail/auth_ldap/2001-
                    December/043545.html
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: mod_auth_ldap
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: apache-dev@suares.nl


In a module for 1.3, namely auth_mod_ldap from www.rudedog.org, there seems to be a  
bug. The bug is best described at  
http://www.rudedog.org/pipermail/auth_ldap/2001-December/043545.html  
and I quote:  
<quote>  
The problem was happening apparently because in  
ldap_authenticate_basic_user(), when the module binds as the actual user  
trying to authenticate, the boundas flag of the LDAPconnection struct  
was being set to bind_user.  However, the bounddn member was not being  
changed - so it was still set to the AuthLDAPBindDN value from the  
first, initial search bind.  Then on the next authentication by that  
httpd child process, in auth_ldap_find_connection() bounddn is compared  
to the configuration sec->binddn value (AuthLDAPBindDN) and since they  
match, boundas is set to bind_system.  Then finally in  
auth_ldap_connect_to_server() since boundas is now set to bind_system,  
it returns immediately without rebinding - however the LDAP server  
connection at this point is still bound as the last successfully  
authenticated user, and it is as that DN that the directory search is  
being done for the new user.  If that DN doesn't have permissions to see  
the new non-public user that is trying to authenticate, the search fails  
and the new user can't authenticate.  
  
The non-public user would be successful if he/she were the first user to  
authenticate via that httpd child process, because for the very first  
search, it _would_ bind as AuthLDAPBindDN.  What was interesting was  
that if the last user to successfully authenticate on that particular  
httpd child process was the same non-public user currently trying to  
authenticate, the authentication would succeed - because a DN typically  
has permissions to search for and find itself!  
  
The patch basically just ensures that when boundas is set to bind_user,  
bounddn is set to the user's DN, and when boundas is set to bind_none,  
bounddn is set to NULL.  I also added the PID to the debug error output  
for the failed search message.  
</quote>  
  
However, the patch that Brent Putnam wrote, never made it to verison 1.6.0 of the module,  
although the patch is from december 2001.   
  
It seems that the same problem persists in the mod_auth_ldap module distributed with 2.0.44 
(I tried Suse Linux 8.2). 
 
Furthermore, it seems that the problem not only occurs when binding with AuthLdapBindDN, 
but also when binding anonymously. I did various traces of traffic to port 389 and it seems 
that this is the same problem. What happens is that you login succesfully as UserA, but then 
even in another realm, as UserB, you can't login. However, this is ONLY a problem if UserA 
can't see UserB - it seems that in many public directory services, users can see eachother and 
then the problem is not noticed. 
 
Please find the patch in above URL and apply it to the 2.0 code. However, the patch in above 
url didn't work for me, and Brent sent me a modified auth_ldap.c, which I diffed against the 
original. To state clearly onxe again: this is a patch agains auth_ldap.c of the mod_auth_ldap 
module 1.6.0 from rudedog.org, it's NOT a patch against the 2.0 code ! 
 
ace@desktop:/new/home/ace/authldap> cat 
patch_for_auth.ldap.c-1.6.0-by-brent.putnam.patch 
 
334c334 
<       (sec->binddn && l->bounddn && strcmp(sec->binddn, l->bounddn) != 0)) 
--- 
>       (sec->binddn && l->bounddn && strcmp(sec->binddn, l->bounddn) != 0)) { 
336c336,338 
<     else 
--- 
>       free(l->bounddn); 
>       l->bounddn = NULL; 
>     } else 
609c611 
<                        "Search must return exactly 1 entry; found " 
--- 
>                        "{%d} Search must return exactly 1 entry; found " 
611c613 
<                        count, filtbuf, r->uri); 
--- 
>                        (int)getpid(), count, filtbuf, r->uri); 
656d657 
<   sec->ldc->boundas = bind_user; 
663a665,667 
>   } else { 
>   sec->ldc->boundas = bind_user; 
>   sec->ldc->bounddn = strdup(sec->dn); 
 
------ 
 
I hope this is usefull for you. 
Thx in advance for considering fixing the bug! 
 
_Ace

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org