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 <[email protected]
> <mailto:[email protected]>> wrote:
>
>
>
> --On Friday, February 28, 2020 11:11 PM +0100 Dieter Bocklandt
> <[email protected] <mailto:[email protected]>> 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>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
