1:09 p.m.
Hello.
I successfully setup the chain overlay, so as to push changes from a
slave to a master, with something as:
overlay chain
chain-uri "ldap://ldap1.domain.tld"
chain-idassert-bind bindmethod="simple"
binddn="cn=chain,ou=roles,dc=domain,dc=tld"
credentials="s3cr3t"
mode="self"
chain-idassert-authzFrom "*"
chain-tls start
chain-return-error TRUE
I'm curious, tough, why the slave has to use a proxy identity to
authenticate on the master, instead of reusing original query
credentials. Is there something preventing it, or is just that all
examples I found sofar were using it ?
I was also curious to know if the slapauth tool was usable to test such
kind of proxy setup. Reading the man page, it seems rather adapted to
testing identity mapping through authz-regexp directives.
10:22 p.m.
Guillaume Rousse wrote:
Hello.
I successfully setup the chain overlay, so as to push changes from a
slave to a master, with something as:
overlay chain
chain-uri "ldap://ldap1.domain.tld"
chain-idassert-bind bindmethod="simple"
binddn="cn=chain,ou=roles,dc=domain,dc=tld"
credentials="s3cr3t"
mode="self"
chain-idassert-authzFrom "*"
chain-tls start
chain-return-error TRUE
I'm curious, tough, why the slave has to use a proxy identity to
authenticate on the master, instead of reusing original query
credentials. Is there something preventing it, or is just that all
examples I found sofar were using it ?
First of all, in order to do that, slapd-ldap(5), which implements the
chain capability, should know about the details of syncrepl. Second,
the credentials used for syncrepl need to have broad *read* permissions,
while slapo-chain(5) credentials must have broad *authz* permissions.
One might want to use separate identities in order to craft their
permissions appropriately. The fact that slapo-chain(5) is very useful
in conjunction with sync replication is orthogonal to slapo-chain(5)
design. In fact, it was not designed for this purpose.
I was also curious to know if the slapauth tool was usable to test
such
kind of proxy setup. Reading the man page, it seems rather adapted to
testing identity mapping through authz-regexp directives.
No. In fact, slapauth only tests authz-rgexp mapping, while what you
want is something similar to authz-regexp but specific to slapd-ldap(5),
and thus buried in its internals. Since it results in an RFC 4370
proxied authorization control, it could be interesting to have a
companion of the RFC 4532 who am I? operation that tells how a DSA is
going to authorize when chaining an operation, and what the who am I?
operation returned after chaining. However, I believe this would only
be useful for "maintenance" checking, as the whole purpose of
slapo-chain(5) is to hide the fact that operations are not handled locally.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
1:21 a.m.
Pierangelo Masarati a écrit :
Guillaume Rousse wrote:
> Hello.
>
> I successfully setup the chain overlay, so as to push changes from a
> slave to a master, with something as:
> overlay chain
> chain-uri "ldap://ldap1.domain.tld"
> chain-idassert-bind bindmethod="simple"
> binddn="cn=chain,ou=roles,dc=domain,dc=tld"
> credentials="s3cr3t"
> mode="self"
> chain-idassert-authzFrom "*"
> chain-tls start
> chain-return-error TRUE
>
> I'm curious, tough, why the slave has to use a proxy identity to
> authenticate on the master, instead of reusing original query
> credentials. Is there something preventing it, or is just that all
> examples I found sofar were using it ?
First of all, in order to do that, slapd-ldap(5), which implements the
chain capability, should know about the details of syncrepl. Second,
the credentials used for syncrepl need to have broad *read* permissions,
while slapo-chain(5) credentials must have broad *authz* permissions.
One might want to use separate identities in order to craft their
permissions appropriately. The fact that slapo-chain(5) is very useful
in conjunction with sync replication is orthogonal to slapo-chain(5)
design. In fact, it was not designed for this purpose.
I guess you're
referring to syncrepl for multi-master replication
scenarios, right ? In my case, I'm using slapo-chain to allow my user to
change their password, whereas they only access the slave server.
Meaning I only push user-triggered changes to the master. Sorry if I was
not clear enough.
> I was also curious to know if the slapauth tool was usable to
test
> such kind of proxy setup. Reading the man page, it seems rather
> adapted to testing identity mapping through authz-regexp directives.
No. In fact, slapauth only tests authz-rgexp mapping, while what you
want is something similar to authz-regexp but specific to slapd-ldap(5),
and thus buried in its internals. Since it results in an RFC 4370
proxied authorization control, it could be interesting to have a
companion of the RFC 4532 who am I? operation that tells how a DSA is
going to authorize when chaining an operation, and what the who am I?
operation returned after chaining. However, I believe this would only
be useful for "maintenance" checking, as the whole purpose of
slapo-chain(5) is to hide the fact that operations are not handled locally.
OK,
thanks for the explanation.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
1:38 a.m.
Guillaume Rousse wrote:
> First of all, in order to do that, slapd-ldap(5), which
implements the
> chain capability, should know about the details of syncrepl. Second,
> the credentials used for syncrepl need to have broad *read*
> permissions, while slapo-chain(5) credentials must have broad *authz*
> permissions. One might want to use separate identities in order to
> craft their permissions appropriately. The fact that slapo-chain(5)
> is very useful in conjunction with sync replication is orthogonal to
> slapo-chain(5) design. In fact, it was not designed for this purpose.
I guess you're referring to syncrepl for multi-master replication
scenarios, right ? In my case, I'm using slapo-chain to allow my user to
change their password, whereas they only access the slave server.
Meaning I only push user-triggered changes to the master. Sorry if I was
not clear enough.
No, I was exactly referring to your case. What I mean, if I got you
correctly, is that you'd like to reuse the identity you set in the
syncrepl statement for the slapo-chain(5) you use to automatically
redirect write requests to the master. This could be done, but it
hasn't been done since the use of slapo-chain(5) is, IMHO, orthogonal to
that of syncrepl.
Of course one could think of adding sort of a "chain-replication"
keyword, so that referrals matching a shadow context are chained using
the credentials of the syncrepl stanza (you could file a feature request
for it).
p.
>> I was also curious to know if the slapauth tool was usable to
test
>> such kind of proxy setup. Reading the man page, it seems rather
>> adapted to testing identity mapping through authz-regexp directives.
>
> No. In fact, slapauth only tests authz-rgexp mapping, while what you
> want is something similar to authz-regexp but specific to
> slapd-ldap(5), and thus buried in its internals. Since it results in
> an RFC 4370 proxied authorization control, it could be interesting to
> have a companion of the RFC 4532 who am I? operation that tells how a
> DSA is going to authorize when chaining an operation, and what the who
> am I? operation returned after chaining. However, I believe this
> would only be useful for "maintenance" checking, as the whole purpose
> of slapo-chain(5) is to hide the fact that operations are not handled
> locally.
OK, thanks for the explanation.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
2:06 a.m.
Pierangelo Masarati wrote:
Guillaume Rousse wrote:
> > Hello.
> >
> > I successfully setup the chain overlay, so as to push changes from a
> > slave to a master, with something as:
> > overlay chain
> > chain-uri "ldap://ldap1.domain.tld"
> > chain-idassert-bind bindmethod="simple"
> > binddn="cn=chain,ou=roles,dc=domain,dc=tld"
> > credentials="s3cr3t"
> > mode="self"
> > chain-idassert-authzFrom "*"
> > chain-tls start
> > chain-return-error TRUE
> >
> > I'm curious, tough, why the slave has to use a proxy identity to
> > authenticate on the master, instead of reusing original query
> > credentials. Is there something preventing it, or is just that all
> > examples I found sofar were using it ?
If by "original query credentials" you mean those of the user that first
attempted the write operation that got chained, that user's credentials are no
longer available. That's why you must use a proxy ID that has the authority to
act on the original user's behalf.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3:02 a.m.
Howard Chu wrote:
Pierangelo Masarati wrote:
> Guillaume Rousse wrote:
>> > Hello.
>> >
>> > I successfully setup the chain overlay, so as to push changes from a
>> > slave to a master, with something as:
>> > overlay chain
>> > chain-uri "ldap://ldap1.domain.tld"
>> > chain-idassert-bind bindmethod="simple"
>> > binddn="cn=chain,ou=roles,dc=domain,dc=tld"
>> > credentials="s3cr3t"
>> > mode="self"
>> > chain-idassert-authzFrom "*"
>> > chain-tls start
>> > chain-return-error TRUE
>> >
>> > I'm curious, tough, why the slave has to use a proxy identity to
>> > authenticate on the master, instead of reusing original query
>> > credentials. Is there something preventing it, or is just that all
>> > examples I found sofar were using it ?
If by "original query credentials" you mean those of the user that first
attempted the write operation that got chained, that user's credentials
are no longer available. That's why you must use a proxy ID that has the
authority to act on the original user's behalf.
Also, there is no guarantee the master can auth that user, if the lave
is not just a shadow of the master.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
5:55 a.m.
Howard Chu a écrit :
Pierangelo Masarati wrote:
> Guillaume Rousse wrote:
>> > Hello.
>> >
>> > I successfully setup the chain overlay, so as to push changes from a
>> > slave to a master, with something as:
>> > overlay chain
>> > chain-uri "ldap://ldap1.domain.tld"
>> > chain-idassert-bind bindmethod="simple"
>> > binddn="cn=chain,ou=roles,dc=domain,dc=tld"
>> > credentials="s3cr3t"
>> > mode="self"
>> > chain-idassert-authzFrom "*"
>> > chain-tls start
>> > chain-return-error TRUE
>> >
>> > I'm curious, tough, why the slave has to use a proxy identity to
>> > authenticate on the master, instead of reusing original query
>> > credentials. Is there something preventing it, or is just that all
>> > examples I found sofar were using it ?
If by "original query credentials" you mean those of the user that first
attempted the write operation that got chained, that user's credentials
are no longer available. That's why you must use a proxy ID that has the
authority to act on the original user's behalf.
I was also thinking of such
kind of issue. Thanks for your explanations.
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
5290
days inactive
5293
days old
openldap-software@openldap.org
6 comments
3 participants
participants (3)
-
Guillaume Rousse -
Howard Chu -
Pierangelo Masarati