Re: back-meta ignoring binddn ?

["Pierangelo Masarati" <ando@sys-net.it>]

> Pierangelo Masarati wrote:
>
>>As a consequence, if you
>>bind to server A as X and X gets resolved to server B,
>>your bind is propagated there; other targets get bound
>>anonymously.
>>
>
> So there is no way to bind to serverC as X as well ?

nope.

>
>>Note that back-meta does not (yet?)
>>support auth proxying.
>>
>>
>
> Not sure what you mean by auth proxying - is that what I'm trying to do
> ?

It's what you need: a pool of servers that trust each other
and share client's identity after successful bind to either
of the pool members

>
>>If you need to bind to each remote server as an
>>applicative identity, you may exploit the pseudorootdn
>>feature.  For all those remote servers that have
>>valid pseudorootdn and pseudorootpw config directives,
>>when binding as rootdn to the back-meta, the bind gets
>>propagated to the remote servers with these administrative
>>identities (which should be remote administrative
>>identities).
>>
>>
>
> I don't think that will help me, I need to bind as non-rootdn.

Note that back-meta rootdn does not have any specific
privilege except on local ACLs (but not on remote server
ACLs) and pseudorootdn identity mapping capability.
Moreover, the pseudorootdn on the remote host does not
need to be rootdn there, it can be any administrative
identity, with specifically tailored privileges.

>
>>In case, an appropriate setup
>>of subordinate back-metas should work for you,
>>
>>
>>
>
> What would that look like ?  One back-meta subordinate of another
> back-meta ?
> Should I change back-ldap to back-meta at serverB & serverC ?

Sorry, I meant back-ldap.  You should try to stack
subordinate back-ldap instances on your proxy server
to exploit back-ldap auth proxying capability.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it