Dieter Bocklandt wrote:
Hey Quanah,
Thanks for getting back to me!
So as I understood it, I expected the proxied identity to be the identity that the client successfully authorized as instead of the identity it initially started with. The session tracking request is just there to confirm that piece of information is actually present but not used. That initial identity is also used for ACL evaluation on the producer side, leading to insufficient access (as expected).
To give a maybe more clear example, assume the following users (stripped down to just the relevant attributes in play):
/dn: cn=proxy,ou=System,dc=example,dc=net authzTo: dn:*/ / / /dn: cn=service,ou=System,dc=example,dc=net / /authzTo: dn:uid=user,ou=People,dc=example,dc=net / / / /dn: uid=dieter,ou=People,dc=example,dc=net / / / /and the following idassert config:/ /olcDbIDAssertBind: mode=self flags=override,prescriptive tls_reqcert=never bindmethod=sasl saslmech=plain authcID=proxy credentials=XXXXX /
When I perform an operation like this: ldapmodify -H ldaps://ldapserver -Y PLAIN -U service -X dn:uid=dieter,ou=People,dc=example,dc=net -w servicepassword -f modifications.ldif
I would assume the following takes place:
- The service user binds to the consumer and assumes dieter's identity, which should be the same net effect as binding with dieter's user in the first place.
- The proxy user binds to the provider and assumes dieter's identity
- The provider tries to perform the write, using dieter's identity for ACL evaluation
What actually happens:
- The service user binds to the consumer and assumes dieter's identity
- The proxy user binds to the provider and assumes the service user's identity
- The provider tries to perform the write, using the service user's identity for ACL evaluation
Actually, I spent some more time on this today and I /think/ I might know what's happening here:
Your analysis makes sense. Would have to ask Pierangelo why he wrote it the way he did but it seems that it should use op->o_ndn.
(from servers/slapd/back-ldap/bind.c in master):
line 2222 - 2227:
/if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn;
} else { ndn = op->o_ndn; }/
line 2549 - 2557:
/if ( op->o_tag == LDAP_REQ_BIND ) { ndn = op->o_req_ndn;
} else if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn;
} else { ndn = op->o_ndn; }/
It seems it tries to use op->o_conn->c_ndn if it's not null, which is (correct me if I'm wrong) the original authcID. That value however doesn't change when performing a proxy authorization, while op->o_ndn does properly reflect that. Shouldn't OpenLDAP always use op->o_ndn?
Again, let me know if I can provide more information or tell me if I'm grossly misunderstanding how this is all supposed to work in the first place :)
Thanks! // Dieter
On Wed, 4 Mar 2020 at 23:12, Quanah Gibson-Mount <quanah@symas.com mailto:quanah@symas.com> wrote:
--On Friday, February 28, 2020 11:11 PM +0100 Dieter Bocklandt <dieterbocklandt@gmail.com <mailto:dieterbocklandt@gmail.com>> wrote: > However, we also have a service using SASL proxy authorization, in which > case the authcid is used in the ProxyAuthz instead of the authorized > authzid. > > Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 PROXYAUTHZ > dn="cn=service,ou=system,dc=internal,dc=machines" > Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 > [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] MOD > dn="uid=sys.cp.test,ou=People,dc=internal,dc=machines" > > Am I misunderstanding how this is supposed to work, am I hitting a > certain limitation or maybe a bug? Let me know if you need any more > details! This looks to me like it: a) Logs what the proxied identity is (PROXYAUTHZ dn="cn=service,ou=system,dc=internal,dc=machine") b) Logs what the actual identity making the changes is (USERNAME=cn=enduser,ou=People,dc=example,dc=net) and what IP address it came from (IP=10.243.72.199) so that if questions arise about who made a change, those questions can be answered from the logs. I.e., I see both bits of information provided in the connection operation. What makes you think you are hitting a limitation or a bug? Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>