On Thu, Dec 15, 2022 at 01:43:41PM +0100, Stefan Kania wrote: > Am 15.12.22 um 13:10 schrieb Ondřej Kuzník: >> Hi Stefan, >> the backends are refusing the lloadd's identity (in your case >> uid=lloadd,ou=users,dc=example,dc=net) the permission to act as a proxy >> for the users in question. You should define a policy on the backends >> that allows this: you can do so using the authz-policy and >> authzTo/authzFrom attributes, see the slapd manpage for how they work. > > Ok, thank you, I will take a look at it. Up to now I only using authz-regexp > together with Kerberos.
That's also used and the two should work together just fine. >> Note that since this control is added to every (non-bind) request we >> proxy, requests with this control present will end up with two and will >> be rejected by the backend, lloadd does not have a policy engine of any >> sort so it cannot decide whether it should be allowed or not, the only >> case exempt from this is if a client uses lloadd's own identity. > > So that means, at the moment it's not possible to identify as an other user > as the bind-user from the lloadd configuration to the backend-server? It's not possible inside lloadd but when lloadd uses an identity A and a client binds with identity B, then sends an operation to it, what the backend receives is an operation with proxyauthz carrying B over a connection bound to A. If authz-policy says that's allowed, normal processing is done with B's identity (you can use the prefix "real" to check A's identity in ACLs if needed, see man slapd.access). > I normaly have different clients with different users and different ACLs to > access the DIT. Yeah, that's fine and usually the reason to use "feature proxyauthz". Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
