[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: bindDN-rewriting - can't get to grips with overlays rwm+relay



Please reply to the address I'm using.  I assume you didn't read my
"vacation" message, then.

> Then it seems that I've misinterpret the way bindDN rewriting works.
>
> I actually thought that it would be possible that an operation on an
> object
> within the rewritten subtree (ou=students,ou=people,ou=swt,ou=wiai,dc=uni-
> bamberg,dc=de) which is started by a user (cn=smbldapadmin,dc=uni-
> bamberg,dc=de (who is not within the subtree which is rewritten)) could be
> internally carried out with the privileges of a different user
> (cn=ldapadmin,dc=uni-bamberg,dc=de).
>
> To make it a bit clearer this are the Users/Objects involved...:
> UsrA: cn=smbldapadmin,dc=uni-bamberg,dc=de
> Obj : cn=A,ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de
> UsrB: cn=ldapadmin,dc=uni-bamberg,dc=de
> Obj' : cn=A,ou=students,dc=uni-bamberg,dc=de
>
> ...and this is what i want my LDAP-Server to do:
> 1. UsrA -> bind to LDAP-Service
> 2. Add Obj (as UsrA) --- internal rewriting ---> Add Obj' (as UsrB)
> 3. process "Add Obj' " internally
> 4. --> if successful "Obj" should be visible to UsrA
>
> Would it be possible to achieve this with the rwm/relay overlay or is
> there
> another overlay that could do that for me?

What you're looking for is authorization.  You want any user
"cn=A,ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" to
authorize as "cn=ldapadmin,dc=uni-bamberg,dc=de".  You should then use
proxyAuthz (RFC4370).

You need to add

authz-policy from

then, in "cn=ldapadmin,dc=uni-bamberg,dc=de", you need to add the attribute

authzFrom:
dn.onelevel:ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de

an your clients need to use the proxyAuthz control; for example

ldapsearch -e '!authzid=dn:cn=ldapadmin,dc=uni-bamberg,dc=de'

Currently, there's no overlay that can do this for you.  You could obtain
something like this using slapd-ldap (possibly with slapo-rwm), by means
of the idassert feature.  This would allow to authorize selected users as
the "cn=ldapadmin,dc=uni-bamberg,dc=de" identity, subjected to
authorization privileges by the remote DSA.

p.