--20cf307811d03117ef04d043e582 Content-Type: text/plain; charset=ISO-8859-1
Setting the timeout to 4294967294 should to the trick for now... but this is really a sort of bug to me as back-ldap should not behave this way when he have no credentials to use... Surely, closing the connexion with the client may be the best solution... 2012/12/6 Pierangelo Masarati <[email protected]> > > > --20cf307811d0eb756704d0342092 > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Actualy I had this before and that did not change anything. I don't think > > this directive is used for this kind of "timeouts"... > > > > I also tried : > > > > *chase-referrals yes (this is default)* > > *rebind-as-user yes (as suggested here)** > > * > > *single-conn yes (default to NO)** > > * > > * > > * > > I also tried some combinings of idassert-bind options with no luck (as > the > > backend does not support identity assertion). > > By backend do you mean the remote server you're trying to proxy? > > I see your problem. Indeed, when a connection is pruned (in your case > because it timed out), information about client's credentials is lost. > Back-ldap is working incorrectly, since it falls back to trying to rebind > anonymously. However, the only other reasonable option could only be to > return a meaningful error (or dropping the connection with the client). > > Things work fine with identity assertion, because in that case the > client's credentials are no longer needed, what counts is that the > client's connection is alive and authenticated, so the client's identity > can be asserted. > > You'd need to do something like > > idassert-bind bindmethod=simple > binddn="<authorizing dn>" > credentials="<authorizing credentials>" > mode=self > flags=override > > (tested, works fine). However, I understood from what you wrote above > that this is not an option. > > I see one quick solution: bail out when the connection is lost and > idassert is not going to take place. This requires a minimal patch. > > An alternative could be to find a decent manner to store the client's > credentials in the frontend's connection with the client (as much as we do > for the client's identity in c_authz). This will live as long as the > client's connection stays alive (something like what we do for paged > results). > > [disclaimer: I'll look into this time permitting; I can't commit to fixing > it any soon] > > p. > > -- > Pierangelo Masarati > Associate Professor > Dipartimento di Ingegneria Aerospaziale > Politecnico di Milano > > --20cf307811d03117ef04d043e582 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Setting the timeout to=A0<span style=3D"color:rgb(80,0,80);font-family:aria= l,sans-serif;font-size:13px">4294967294 should to the trick for now... but = this is really a sort of bug to me as back-ldap should not behave this way = when he have no credentials to use...</span><div> <span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13= px">Surely, closing the connexion =A0with the client may be the best soluti= on...</span></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_qu= ote"> 2012/12/6 Pierangelo Masarati <span dir=3D"ltr"><<a href=3D"mailto:masar= [email protected]" target=3D"_blank">[email protected]</a>></span= ><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"> <br> > --20cf307811d0eb756704d0342092<br> > Content-Type: text/plain; charset=3DISO-8859-1<br> <div class=3D"im">><br> > Actualy I had this before and that did not change anything. I don'= t think<br> > this directive is used for this kind of "timeouts"...<br> ><br> > I also tried :<br> ><br> </div>> *chase-referrals yes (this is default)*<br> > *rebind-as-user yes (as suggested here)**<br> > *<br> > *single-conn yes (default to NO)**<br> > *<br> > *<br> <div class=3D"im">> *<br> > I also tried some combinings of idassert-bind options with no luck (as= the<br> > backend does not support identity assertion).<br> <br> </div>By backend do you mean the remote server you're trying to proxy?<= br> <br> I see your problem. =A0Indeed, when a connection is pruned (in your case<br= > because it timed out), information about client's credentials is lost.<= br> Back-ldap is working incorrectly, since it falls back to trying to rebind<b= r> anonymously. =A0However, the only other reasonable option could only be to<= br> return a meaningful error (or dropping the connection with the client).<br> <br> Things work fine with identity assertion, because in that case the<br> client's credentials are no longer needed, what counts is that the<br> client's connection is alive and authenticated, so the client's ide= ntity<br> can be asserted.<br> <br> You'd need to do something like<br> <br> idassert-bind bindmethod=3Dsimple<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 binddn=3D"<authorizing dn>"<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 credentials=3D"<authorizing credentials= >"<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode=3Dself<br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 flags=3Doverride<br> <br> (tested, works fine). =A0However, I understood from what you wrote above<br= > that this is not an option.<br> <br> I see one quick solution: bail out when the connection is lost and<br> idassert is not going to take place. =A0This requires a minimal patch.<br> <br> An alternative could be to find a decent manner to store the client's<b= r> credentials in the frontend's connection with the client (as much as we= do<br> for the client's identity in c_authz). =A0This will live as long as the= <br> client's connection stays alive (something like what we do for paged<br= > results).<br> <br> [disclaimer: I'll look into this time permitting; I can't commit to= fixing<br> it any soon]<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> p.<br> <br> --<br> Pierangelo Masarati<br> Associate Professor<br> Dipartimento di Ingegneria Aerospaziale<br> Politecnico di Milano<br> <br> </div></div></blockquote></div><br></div> --20cf307811d03117ef04d043e582--
