From prune@lecentre.net Fri Dec 7 14:19:22 2012 From: prune@lecentre.net To: openldap-bugs@openldap.org Subject: Re: (ITS#7464) ldap_back_dobind_int breaking binded user Date: Fri, 07 Dec 2012 14:19:21 +0000 Message-ID: <201212071419.qB7EJLD5060885@boole.openldap.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0303716953250113153==" --===============0303716953250113153== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable --20cf307811d03117ef04d043e582 Content-Type: text/plain; charset=3DISO-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 > > > --20cf307811d0eb756704d0342092 > > Content-Type: text/plain; charset=3DISO-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=3Dsimple > binddn=3D"" > credentials=3D"" > mode=3Dself > flags=3Doverride > > (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=3DISO-8859-1 Content-Transfer-Encoding: quoted-printable Setting the timeout to=3DA04294967294 should to the trick for now... but =3D this is really a sort of bug to me as back-ldap should not behave this way =3D when he have no credentials to use...
Surely, closing the connexion =3DA0with the client may be the best soluti= =3D on...


2012/12/6 Pierangelo Masarati <masarati(a)aero.polimi.it>

> --20cf307811d0eb756704d0342092
> Content-Type: text/plain; charset=3D3DISO-8859-1
>
> Actualy I had this before and that did not change anything. I don'=3D 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=3D the
> backend does not support identity assertion).

By backend do you mean the remote server you're trying to proxy?<=3D br>
I see your problem. =3DA0Indeed, when a connection is pruned (in your case because it timed out), information about client's credentials is lost.<=3D br> Back-ldap is working incorrectly, since it falls back to trying to rebind anonymously. =3DA0However, the only other reasonable option could only be to<= =3D br> 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 ide=3D ntity
can be asserted.

You'd need to do something like

idassert-bind bindmethod=3D3Dsimple
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 binddn=3D3D"<authorizing dn= >"
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 credentials=3D3D"<authorizi= ng credentials=3D >"
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 mode=3D3Dself
=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 flags=3D3Doverride

(tested, works fine). =3DA0However, 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. =3DA0This 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=3D do
for the client's identity in c_authz). =3DA0This will live as long as the= =3D
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=3D fixing
it any soon]

p.

--
Pierangelo Masarati
Associate Professor
Dipartimento di Ingegneria Aerospaziale
Politecnico di Milano


--20cf307811d03117ef04d043e582-- --===============0303716953250113153==--