Full_Name: Harlan Stenn
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (63.155.158.122)
openldap-thread-check.m4 seems to hand-code an equivalent of AC_ARG_WITH()
processing for the with_yielding_select stuff. This code has at least one typo
and at least one bug; it does not work in the case where one is
cross-compiling.
Before I go and submit a patch that would convert this macro to using
AC_ARG_WITH, I figured I should ask to see why things were done the way they
were.
--_b67832eb-f95f-44fc-96d8-4e1d626f474b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
First of all thank you for your quick answer.
=20
Before I posted the question I've read the man pages several times trying t=
o understand how slapd-meta runs. I don't speak english very well (as you c=
an see) so it's probably that i've don't understand it completly.
=20
As I've tried to explain in my question=2C I used idassert-bind before and =
it runs ok=2C but I don't understand why I've to use an administrative acco=
unt to connect the proxy with the targets if I only want to passthrough the=
credentials of the user that was authenticated on the proxy. So I tried to=
use rebind-as-user thinking it was the solution but as you say this is for=
another use.
=20
Only for confirm what I'm doing. Is this the correct directive for what I'm=
trying to do?
idassert-bind mode=3Dself bindmethod=3Dsimple binddn=3D"cn=3Dadminuser=2Cou=
=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" credentials=3D"password of admin user"
=20
Regards
=20
> Date: Fri=2C 28 Feb 2014 21:23:52 +0100
> From: pierangelo.masarati(a)polimi.it
> To: theedgeu2(a)live.com
> CC: openldap-its(a)openldap.org
> Subject: Re: (ITS#7807) rebind-as-user in slapd-meta not running
>=20
> On 02/28/2014 11:00 AM=2C theedgeu2(a)live.com wrote:
> > Full_Name: Angel Martinez
> > Version: 2.4.39
> > OS: Red Hat Linux 6.4
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (217.71.18.36)
> >
> >
> > I'm trying to configure a LDAP proxy with slapd-meta.
> >
> > I have several suffixs over several instances that shares the same user
> > accounts. It's posible that one user had access to several targets.
> >
> > The targets are:
> >
> > * Users: ou=3Dusers=2C dc=3Dtest=2C dc=3Dcom (here resides all accounts=
)
> >
> > * Target1: ou=3Dtarget1=2C dc=3Dtest=2C dc=3Dcom
> >
> > * Target2: ou=3Dtarget2=2C dc=3Dtest=2C dc=3Dcom
> >
> > These 3 suffix are on 3 differents instances.
> >
> > The instances where target1 and target2 are also have another suffix: o=
u=3Dusers=2C
> > dc=3Dtest=2C dc=3Dcom. This suffix is replicated from the first instanc=
e (Users)
> >
> > Normally=2C the users connect throught the proxy=2C but sometimes will =
connect
> > directly to the others instances.
> >
> > Basically this is the slapd.conf of the proxy:
> >
> > database meta
> > chase-referrals yes
> > rebind-as-user yes
> >
> > suffix "ou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom"
> > uri "ldap://192.168.1.34:3891/ou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom"
> >
> > suffix "ou=3Dtarget1=2Cdc=3Dtest=2Cdc=3Dcom"
> > uri "ldap://192.168.1.34:3892/ou=3Dtarget1=2Cdc=3Dtest=2Cdc=3Dcom"
> >
> > suffix "ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom"
> > uri "ldap://192.168.1.34:3893/ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom"
> >
> > When a user connects to the proxy with cn=3Duser1=2Cou=3Dusers=2Cdc=3Dt=
est=2Cdc=3Dcom=2C the
> > user is validated against the first target (ou=3Dusers) and can search =
over this
> > suffix=2C but if this user try to search something over other target (f=
or example
> > ou=3Dtarget1) the proxy does not use the credentials of the user and do=
an
> > anonymous bind to target1=2C so the search doesn't run.
> >
> > I thought that rebind-as-user resolve this but doesn't run.
> >
> > I've tried using idassert-bind mode=3Dself bindmethod=3Dsimple
> > binddn=3D"cn=3Dadminuser=2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" credentia=
ls=3D"password" and runs
> > ok=2C but I prefer not to use an administrative account to connect the =
proxy with
> > the targets.
> >
> > Is there something I'm missing?
>=20
> Yes=2C you did not read slapd-meta(5) man page. rebind-as-user is used i=
n=20
> a totally different context. What you need is idassert-bind.
>=20
>=20
> Please direct further conversation to <openldap-technical(a)openldap.org>.=
=20
> This ITS will be closed.
>=20
> p.
>=20
>=20
> --=20
> Pierangelo Masarati
> Associate Professor
> Dipartimento di Scienze e Tecnologie Aerospaziali
> Politecnico di Milano
=
--_b67832eb-f95f-44fc-96d8-4e1d626f474b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'><br>First of all thank you for y=
our quick answer.<BR> =3B<BR>Before I posted the question I've read the=
man pages several times trying to understand how slapd-meta runs. I don't =
speak english very well (as you can see) so it's probably that i've don't u=
nderstand it completly.<BR> =3B<BR>As I've tried to =3Bexplain in m=
y question=2C I used idassert-bind before and it runs ok=2C but I don't und=
erstand why I've to use an administrative account to connect the proxy with=
the targets if I only want to passthrough the credentials of the user that=
was authenticated on the proxy. So I tried to use rebind-as-user thinking =
it was the solution but as you say this is for another use.<BR> =3B<BR>=
Only for confirm what I'm doing. Is this the correct directive for what I'm=
trying to do?<BR>idassert-bind mode=3Dself bindmethod=3Dsimple binddn=3D"c=
n=3Dadminuser=2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" credentials=3D"password =
of admin user"<BR> =3B<BR>Regards<BR> =3B<BR><div>>=3B Date: Fri=
=2C 28 Feb 2014 21:23:52 +0100<br>>=3B From: pierangelo.masarati(a)polimi.i=
t<br>>=3B To: theedgeu2(a)live.com<br>>=3B CC: openldap-its(a)openldap.org<=
br>>=3B Subject: Re: (ITS#7807) rebind-as-user in slapd-meta not running<=
br>>=3B <br>>=3B On 02/28/2014 11:00 AM=2C theedgeu2(a)live.com wrote:<br=
>>=3B >=3B Full_Name: Angel Martinez<br>>=3B >=3B Version: 2.4.39<b=
r>>=3B >=3B OS: Red Hat Linux 6.4<br>>=3B >=3B URL: ftp://ftp.openl=
dap.org/incoming/<br>>=3B >=3B Submission from: (NULL) (217.71.18.36)<b=
r>>=3B >=3B<br>>=3B >=3B<br>>=3B >=3B I'm trying to configure a=
LDAP proxy with slapd-meta.<br>>=3B >=3B<br>>=3B >=3B I have sever=
al suffixs over several instances that shares the same user<br>>=3B >=
=3B accounts. It's posible that one user had access to several targets.<br>=
>=3B >=3B<br>>=3B >=3B The targets are:<br>>=3B >=3B<br>>=3B =
>=3B * Users: ou=3Dusers=2C dc=3Dtest=2C dc=3Dcom (here resides all accou=
nts)<br>>=3B >=3B<br>>=3B >=3B * Target1: ou=3Dtarget1=2C dc=3Dtest=
=2C dc=3Dcom<br>>=3B >=3B<br>>=3B >=3B * Target2: ou=3Dtarget2=2C d=
c=3Dtest=2C dc=3Dcom<br>>=3B >=3B<br>>=3B >=3B These 3 suffix are o=
n 3 differents instances.<br>>=3B >=3B<br>>=3B >=3B The instances w=
here target1 and target2 are also have another suffix: ou=3Dusers=2C<br>>=
=3B >=3B dc=3Dtest=2C dc=3Dcom. This suffix is replicated from the first =
instance (Users)<br>>=3B >=3B<br>>=3B >=3B Normally=2C the users co=
nnect throught the proxy=2C but sometimes will connect<br>>=3B >=3B dir=
ectly to the others instances.<br>>=3B >=3B<br>>=3B >=3B Basically =
this is the slapd.conf of the proxy:<br>>=3B >=3B<br>>=3B >=3B data=
base meta<br>>=3B >=3B chase-referrals yes<br>>=3B >=3B rebind-as-u=
ser yes<br>>=3B >=3B<br>>=3B >=3B suffix "ou=3Dusers=2Cdc=3Dtest=
=2Cdc=3Dcom"<br>>=3B >=3B uri "ldap://192.168.1.34:3891/ou=3Dusers=
=2Cdc=3Dtest=2Cdc=3Dcom"<br>>=3B >=3B<br>>=3B >=3B suffix "ou=3Dt=
arget1=2Cdc=3Dtest=2Cdc=3Dcom"<br>>=3B >=3B uri "ldap://192.168.1.=
34:3892/ou=3Dtarget1=2Cdc=3Dtest=2Cdc=3Dcom"<br>>=3B >=3B<br>>=3B >=
=3B suffix "ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom"<br>>=3B >=3B uri =
"ldap://192.168.1.34:3893/ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom"<br>>=3B =
>=3B<br>>=3B >=3B When a user connects to the proxy with cn=3Duser1=
=2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom=2C the<br>>=3B >=3B user is valida=
ted against the first target (ou=3Dusers) and can search over this<br>>=
=3B >=3B suffix=2C but if this user try to search something over other ta=
rget (for example<br>>=3B >=3B ou=3Dtarget1) the proxy does not use the=
credentials of the user and do an<br>>=3B >=3B anonymous bind to targe=
t1=2C so the search doesn't run.<br>>=3B >=3B<br>>=3B >=3B I though=
t that rebind-as-user resolve this but doesn't run.<br>>=3B >=3B<br>>=
=3B >=3B I've tried using idassert-bind mode=3Dself bindmethod=3Dsimple<b=
r>>=3B >=3B binddn=3D"cn=3Dadminuser=2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dco=
m" credentials=3D"password" and runs<br>>=3B >=3B ok=2C but I prefer no=
t to use an administrative account to connect the proxy with<br>>=3B >=
=3B the targets.<br>>=3B >=3B<br>>=3B >=3B Is there something I'm m=
issing?<br>>=3B <br>>=3B Yes=2C you did not read slapd-meta(5) man page=
. rebind-as-user is used in <br>>=3B a totally different context. What =
you need is idassert-bind.<br>>=3B <br>>=3B <br>>=3B Please direct fu=
rther conversation to <=3Bopenldap-technical(a)openldap.org>=3Bt=3B. <br>>=
=3B This ITS will be closed.<br>>=3B <br>>=3B p.<br>>=3B <br>>=3B=
<br>>=3B -- <br>>=3B Pierangelo Masarati<br>>=3B Associate Professor=
<br>>=3B Dipartimento di Scienze e Tecnologie Aerospaziali<br>>=3B Poli=
tecnico di Milano<br></div> </div></body>
</html>=
--_b67832eb-f95f-44fc-96d8-4e1d626f474b_--
