Hello all. I am working on getting OpenLDAP 2.0 working for the CMU campus here. I CVS downloaded the source in early December and have it compiled and running on my desktop machine. I am working on getting Kerberos authentication working, and ran into what I'd have to call a bug. It has to do with a client such as ldapsearch uses ldap_kerberos_bind_s() and how the server binds your DN using do_bind(). When a client uses ldap_kerberos_bind_s() it first binds with an authmethod LDAP_AUTH_KRBV41 (the "ldapserver" ticket), and then again with LDAP_AUTH_KRBV42 (the "x500dsa" ticket). On the server, in the function servers/slapd/back-ldbm/bind.c ldbm_back_bind() the first bind does all of the leg work of checking the krbName and returns 0 to the calling function servers/slapd/bind.c do_bind() The second bind on the server simply sends a SUCCESS message back to the client and returns a non-zero code back to do_bind(), with the comment "stop front end from sending result". When do_bind() was called, it first cleared any previous bindings and then if the backend bind returns 0 it will store the requested DN in the connection. The bug is that the second (LDAP_AUTH_KRBV42) binding in ldbm_back_bind() always returns a non-zero code to do_bind(), so the DN binding from the first binding was erased and not stored the second time. The result is a connection that has NO binding: you are unauthenticated. I am curious as to why the second binding wants to send the SUCCESS message itself and return !0, instead of returning 0 and letting do_bind() return SUCCESS (and set the DN binding). -Mark Adamson adamson@cmu.edu PS My first day of reading/posting to this group. Pardon any inproprieties.
At 06:17 PM 1/27/00 GMT, adamson@andrew.cmu.edu wrote: > When a client uses ldap_kerberos_bind_s() it first binds with an >authmethod LDAP_AUTH_KRBV41 (the "ldapserver" ticket), and then again >with LDAP_AUTH_KRBV42 (the "x500dsa" ticket). On the server, in the >function The current protocol specs require the server to forget any existing LDAP authorization upon receipt of a bind request. This runs counter to the implementation of ldap_kerberos_bind_s() which submits to independent bind requests. To provide backwards compatibility, the server (do_bind) needs to be modified to handle DSA bind such the server doesn't forget the prior authorization. > I am curious as to why the second binding wants to send the SUCCESS >message itself and return !0, instead of returning 0 and letting >do_bind() return SUCCESS (and set the DN binding). Because this would allow anyone to bind as anything. The success of the second bind should restore the previous "forgotten" authorization.
changed notes changed state Open to Feedback
changed state Feedback to Closed
See ITS#443 for additional information.