On Wed, Dec 14, 2022 at 09:20:14PM +0100, Stefan Kania wrote:
I now took the example configuration and changed it to my settings:
feature proxyauthz bindconf bindmethod=simple binddn=uid=lloadd,ou=users,dc=example,dc=net
The bind-user exists in the database of the backend-server. If i start the loadbalancer I can see that the connection are established.
[...]
I see the same messages on ldap02, so that's ok
Then I do a search from a different machine:
[...]
root@ldap03:~# ldapsearch -x -D uid=repl-user,ou=users,dc=example,dc=net -w geheim -H ldaps://loadbalancer.example.net:1636 -LLL Proxied Authorization Denied (123) Additional information: not authorized to assume identity
Why do I get different log-entries on the backend-server? And what did I forgot?
[...]
So what's the point I'm missing to get proxyauthz work correctly?
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.
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.
Some future version might be able to hand over some authentication and authorization processing to the host slapd and this would allow us to decide what value to pass in the proxyauthz control but implementation has not started yet. I would be happy to guide anyone willing to implement this.
Regards,