Full_Name: Sylvain Viollon Version: 2.3 OS: FreeBSD 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.204.228.114) I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) having the following attribute : authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) He can successfully authenticate, but not become an user listed by the search (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the last user returned by the search. In source, I read the file 'servers/slapd/saslauthz.c'. The filter 'sasl_sc_smatch' said if the wanted user is in the search result. In this function, there is a test : if ( sm->match == 1 ) { sm->match = -1; return 0; } I have removed the line : sm->match = -1; Which make the match to fail if there is an entry in the search return after the good one. Like every DN have to be unique, there is no multiple solution, and validation would not be discarded for that. I didn't know if it's a good solution, but it's work. Openldap 2.2 and 2.4 seems to have the same problem.
sylvain@pilotsystems.net wrote: > Full_Name: Sylvain Viollon > Version: 2.3 > OS: FreeBSD 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.204.228.114) > > > > I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, > having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) > having the following attribute : > > authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) > > He can successfully authenticate, but not become an user listed by the search > (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the > last user returned by the search. > > In source, I read the file 'servers/slapd/saslauthz.c'. The filter > 'sasl_sc_smatch' said if the wanted user is in the search result. In this > function, there is a test : > > if ( sm->match == 1 ) { > sm->match = -1; > return 0; > } > > I have removed the line : > > sm->match = -1; > > Which make the match to fail if there is an entry in the search return after the > good one. Like every DN have to be unique, there is no multiple solution, and > validation would not be discarded for that. I didn't know if it's a good > solution, but it's work. > > As far as I remember, that test is intended to prevent mapping when the search returns more than one entry. This makes perfectly sense, otherwise a SASL identity (or an authorization identity) would be arbitrarily mapped to one of the matching entries. So mapping is intended to succeed if and only if exactly one identity can be resolved. If the behavior you're experiencing is consistent with the above, there is no evidence of a bug in OpenLDAP software. If it's not, please detail. Otherwise, this ITS will be closed. p. Unless Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
ando@sys-net.it wrote: > sylvain@pilotsystems.net wrote: >> Full_Name: Sylvain Viollon >> Version: 2.3 >> OS: FreeBSD 5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.204.228.114) >> >> >> >> I have an directory with some users in ou=people,dc=pilotsystems,dc=net branch, >> having a custom class krbUser ; and a user (cn=auth,dc=pilotsystems,dc=net) >> having the following attribute : >> >> authzTo: ldap:///ou=people,dc=pilotsystems,dc=net??sub?(objectClass=krbUser) >> >> He can successfully authenticate, but not become an user listed by the search >> (with PROXYAUTHZ). Running slapd in debug-mode I saw that he can only become the >> last user returned by the search. >> >> In source, I read the file 'servers/slapd/saslauthz.c'. The filter >> 'sasl_sc_smatch' said if the wanted user is in the search result. In this >> function, there is a test : >> >> if ( sm->match == 1 ) { >> sm->match = -1; >> return 0; >> } >> >> I have removed the line : >> >> sm->match = -1; >> >> Which make the match to fail if there is an entry in the search return after the >> good one. Like every DN have to be unique, there is no multiple solution, and >> validation would not be discarded for that. I didn't know if it's a good >> solution, but it's work. >> >> > As far as I remember, that test is intended to prevent mapping when the > search returns more than one entry. This makes perfectly sense, > otherwise a SASL identity (or an authorization identity) would be > arbitrarily mapped to one of the matching entries. So mapping is > intended to succeed if and only if exactly one identity can be resolved. That test is only supposed to prevent mapping when doing an authzRegexp mapping of a single SASL userID to a DN. When looking up authzFrom/authzTo it is supposed to allow multiple results. Interestingly, it looks like slap_sasl_match isn't even used for authzRegexp mapping any more. Something is definitely broken here. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
hyc@symas.com wrote: > ando@sys-net.it wrote: >> As far as I remember, that test is intended to prevent mapping when the >> search returns more than one entry. This makes perfectly sense, >> otherwise a SASL identity (or an authorization identity) would be >> arbitrarily mapped to one of the matching entries. So mapping is >> intended to succeed if and only if exactly one identity can be resolved. > > That test is only supposed to prevent mapping when doing an authzRegexp > mapping of a single SASL userID to a DN. When looking up > authzFrom/authzTo it is supposed to allow multiple results. > Interestingly, it looks like slap_sasl_match isn't even used for > authzRegexp mapping any more. Something is definitely broken here. > This behavior was changed in rev 1.126 of saslauthz.c. I believe the relevant portions of that patch need to be reverted. e.g. patch -R: diff -u -r1.125 -r1.126 --- saslauthz.c 26 Apr 2004 19:47:02 -0000 1.125 +++ saslauthz.c 26 Apr 2004 20:47:08 -0000 1.126 @@ -772,14 +802,26 @@ { smatch_info *sm = o->o_callback->sc_private; - if (rs->sr_type != REP_SEARCH) return 0; + if ( rs->sr_type != REP_SEARCH ) { + if ( rs->sr_err != LDAP_SUCCESS ) { + sm->match = -1; + } + return 0; + } + + if ( sm->match == 1 ) { + sm->match = -1; + return 0; + } if (dn_match(sm->dn, &rs->sr_entry->e_nname)) { sm->match = 1; - return -1; /* short-circuit the search */ + + } else { + sm->match = -1; } - return 1; + return 0; } /* @@ -984,7 +1026,7 @@ op.o_bd->be_search( &op, &rs ); - if (sm.match) { + if (sm.match == 1) { rc = LDAP_SUCCESS; } else { rc = LDAP_INAPPROPRIATE_AUTH; -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
changed notes changed state Open to Test moved from Incoming to Software Bugs
changed notes
changed state Test to Closed
moved from Software Bugs to Archive.Software Bugs
fixed in HEAD/RE23