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:

(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> wrote:


--On Friday, February 28, 2020 11:11 PM +0100 Dieter Bocklandt
<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>