I now took the example configuration and changed it to my settings:
--------------------- TLSCertificateFile /opt/symas/etc/openldap/example-net-cert.pem TLSCertificateKeyFile /opt/symas/etc/openldap/example-net-key.pem TLSCACertificateFile /opt/symas/etc/openldap/cacert.pem pidfile /var/symas/run/slapd.pid argsfile /var/symas/run/slapd.args loglevel 256 modulepath /opt/symas/lib/openldap moduleload lloadd.la backend lload listen "ldap://:1389 ldaps://:1636" feature proxyauthz TLSShareSlapdCTX true bindconf bindmethod=simple network-timeout=5 tls_cacert="/opt/symas/etc/openldap/cacert.pem" tls_cert="/opt/symas/etc/openldap/example-net-cert.pem" tls_key="/opt/symas//etc/openldap/example-net-key.pem" binddn=uid=lloadd,ou=users,dc=example,dc=net credentials=geheim tier roundrobin backend-server uri=ldaps://ldap01.example.net starttls=critical retry=5000 max-pending-ops=50 conn-max-pending=10 numconns=10 bindconns=5 backend-server uri=ldaps://ldap02.example.net starttls=critical retry=5000 max-pending-ops=50 conn-max-pending=10 numconns=10 bindconns=5 database monitor ---------------------
The bind-user exists in the database of the backend-server. If i start the loadbalancer I can see that the connection are established.
-------ldap01----------- Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 fd=46 ACCEPT from IP=192.168.56.40:38674 (IP=0.0.0.0:636) Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 fd=46 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 op=0 BIND dn="uid=lloadd,ou=users,dc=example,dc=net" method=128 Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 op=0 BIND dn="uid=lloadd,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256
------------------------
I see the same massages on ldap02, so that's ok
The 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 ------------
The uid=repl-user has read permission to all objects and attributes.
On ldap01 I see:
---------ldap01------------- Dez 14 21:09:13 ldap01 slapd[550]: conn=1371 op=0 BIND dn="uid=repl-user,ou=users,dc=example,dc=net" method=128 Dez 14 21:09:13 ldap01 slapd[550]: conn=1371 op=0 BIND dn="uid=repl-user,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256 Dez 14 21:09:13 ldap01 slapd[550]: conn=1371 op=0 RESULT tag=97 err=0 qtime=0.000033 etime=0.015255 text= -----------------------------
on ldap02
--------ldap02---------- Dez 14 21:09:13 ldap02 slapd[300]: conn=1306 op=1 SEARCH RESULT tag=101 err=123 qtime=0.000044 etime=0.000235 nentries=0 text=not authorized to assume identity Dez 14 21:09:13 ldap02 slapd[300]: conn=1306 op=1 do_search: get_ctrls failed ------------------------
Why do I get different log-entries on the backend-server? And what did I forgot?
When I do a ldapsearch with uid=lloadd I get:
------------------- root@ldap03:~# ldapsearch -x -D uid=lloadd,ou=users,dc=example,dc=net -w geheim -H ldaps://loadbalancer.example.net:1636 -LLL dn: dc=example,dc=net objectClass: domain objectClass: dcObject dc: example
------------------- That's the only object the user has permissions to read.
log from ldap01 -------------------- Dez 14 21:14:04 ldap01 slapd[550]: conn=1381 op=0 BIND dn="uid=lloadd,ou=users,dc=example,dc=net" method=128 Dez 14 21:14:04 ldap01 slapd[550]: conn=1381 op=0 BIND dn="uid=lloadd,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256 Dez 14 21:14:04 ldap01 slapd[550]: conn=1381 op=0 RESULT tag=97 err=0 qtime=0.000021 etime=0.008984 text= --------------------
and log from ldap02 -------------------- Dez 14 21:14:04 ldap02 slapd[300]: conn=1308 op=1 SRCH base="dc=example,dc=net" scope=2 deref=0 filter="(objectClass=*)" Dez 14 21:14:04 ldap02 slapd[300]: conn=1308 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000022 etime=0.002048 nentries=1 text= --------------------
That's also ok, I think . The final version should be that the binduser uid=lloadd will not see anything.
So what's the point I'm missing to get proxyauthz work correctly?
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,
Am 15.12.22 um 13:10 schrieb Ondřej Kuzník:
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.
Ok, thank you, I will take a look at it. Up to now I only using authz-regexp together with Kerberos.
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?
I normaly have different clients with different users and different ACLs to access the DIT.
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.
I would like to help and test :-)
Regards,
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,
Am 15.12.22 um 14:24 schrieb Ondřej Kuzník:
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).
Ok, that's the part I understand :-). My user uid=lloadd opend the connections to my backend-server. I can see that inside the logs. It's clear My uid=repl-user sends a request to my loadbalancer(LB). The LB sends the request over one of the opend connections as uid=repl-user, but the backend-server can't authenticate uid=repl-user that's where the authz-policy should work. Also clear. What is still not clear: How do I configure it? Maybe it's because I'm not a native English speeker, its sometimes hard for me to understand. I understand that the default for authz-policy is "none". The manpage said activate it if you need it. So I used the following ldif: -------------- dn: cn=config changetype: modify replace: olcAuthzpolicy olcAuthzpolicy: any -------------- Or do i have to set it inside the database for my object?
Then I changed the uid=lloadd to: ----------------------- dn: uid=lloadd,ou=users,dc=example,dc=net objectClass: account objectClass: simpleSecurityObject objectClass: top uid: lloadd userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$MTIz.. authzFrom: ldap:///dc=example,dc=net??sub?(uid=*) -----------------------
But still not working. I also try it with "authzTo", but same result. As I read in man slapd.conf. At the beginning I just whant to get it working, then comes the security part. So I allow all uids.
On Thu, Dec 15, 2022 at 03:02:00PM +0100, Stefan Kania wrote:
dn: cn=config changetype: modify replace: olcAuthzpolicy olcAuthzpolicy: any
Or do i have to set it inside the database for my object?
This is a global setting so that's the correct place.
Then I changed the uid=lloadd to:
dn: uid=lloadd,ou=users,dc=example,dc=net objectClass: account objectClass: simpleSecurityObject objectClass: top uid: lloadd userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$MTIz.. authzFrom: ldap:///dc=example,dc=net??sub?(uid=*)
But still not working. I also try it with "authzTo", but same result. As I read in man slapd.conf. At the beginning I just whant to get it working, then comes the security part. So I allow all uids.
Should be authzTo if you're adding it to the lloadd's identity, are you sure uid=lloadd,ou=users,dc=example,dc=net has 'auth' (+x) access to dc=example,dc=net and the uid attribute on the subtree?
Regards,
Am 15.12.22 um 16:38 schrieb Ondřej Kuzník:
Should be authzTo if you're adding it to the lloadd's identity, are you sure uid=lloadd,ou=users,dc=example,dc=net has 'auth' (+x) access to dc=example,dc=net and the uid attribute on the subtree?
Thank you for the push in right direction I added an ACL: olcAccess: {0}to attr=uid by dn.exact=uid=lloadd,ou=users,dc=example,dc=net auth by * break
But I forgot, that the uid=lloadd could not enter any of my OUs. My security-paranoia leads me to disallow everything for everybody in the first place, so I have to open the path to my users :-) Now I got:
-------------------------- Dez 15 17:35:10 ldap02 slapd[321]: conn=1004 op=2 PROXYAUTHZ dn="uid=repl-user,ou=users,dc=example,dc=net" Dez 15 17:35:10 ldap02 slapd[321]: conn=1004 op=2 SRCH base="dc=example,dc=net" scope=2 deref=0 filter="(objectClass=*)" Dez 15 17:35:10 ldap02 slapd[321]: conn=1004 op=2 SEARCH RESULT tag=101 err=0 qtime=0.000018 etime=0.005746 nentries=56 text= -------------------------
Thank's a lot for your patience and all your help.
--On Thursday, December 15, 2022 3:02 PM +0100 Stefan Kania stefan@kania-online.de wrote:
dn: cn=config changetype: modify replace: olcAuthzpolicy olcAuthzpolicy: any
Since you only need it to be possible for the lloadd user to assume other identities, I'd use a policy of 'to' instead of 'any'.
--Quanah
Am 15.12.22 um 17:56 schrieb Quanah Gibson-Mount:
--On Thursday, December 15, 2022 3:02 PM +0100 Stefan Kania stefan@kania-online.de wrote:
dn: cn=config changetype: modify replace: olcAuthzpolicy olcAuthzpolicy: any
Since you only need it to be possible for the lloadd user to assume other identities, I'd use a policy of 'to' instead of 'any'.
--Quanah
Thank you, I will change it. Setting it to "any" was just an act of desperation ;-) To get it work.Now comes security and fine tuning
Stefan Kania stefan@kania-online.de schrieb am 15.12.2022 um 18:55 in
Nachricht 4c04e864-2b72-c9d2-96b9-036c11f58bbc@kania-online.de:
Am 15.12.22 um 17:56 schrieb Quanah Gibson-Mount:
--On Thursday, December 15, 2022 3:02 PM +0100 Stefan Kania stefan@kania-online.de wrote:
dn: cn=config changetype: modify replace: olcAuthzpolicy olcAuthzpolicy: any
Since you only need it to be possible for the lloadd user to assume other identities, I'd use a policy of 'to' instead of 'any'.
--Quanah
Thank you, I will change it. Setting it to "any" was just an act of desperation ;-) To get it work.Now comes security and fine tuning
Once you have a transition from "working" to "no longer working" it's easier to find out what you might have done wrong, rather than starting with a state "not working" ;-)
openldap-technical@openldap.org
-
Ondřej Kuzník -
Quanah Gibson-Mount -
Stefan Kania -
Ulrich Windl