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=netauthzTo: 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 <[email protected]> wrote:
>
>
> --On Friday, February 28, 2020 11:11 PM +0100 Dieter Bocklandt
> <[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>
>
