--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 masarati@aero.polimi.it
--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= ati@aero.polimi.it" target=3D"_blank">masarati@aero.polimi.it</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--
-
prune＠lecentre.net