[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#7464) ldap_back_dobind_int breaking binded user
--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--