(ITS#9180) Update slapo-memberOf man page about replication

2020-03-09 Thread quanah 
Full_Name: Quanah Gibson-Mount
Version: 2.4.49
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.128.236)


After discussion with Howard, slapo-memberOf should be replication compatible on
REFRESH as long as the dangling option is set to ignore.

The man page should be updated to reflect this, although I want to do some
testing to confirm with how it behaves when refint is set to TRUE as well.

Re: (ITS#9179) back-ldap SASL proxy authorization

2020-03-09 Thread ondra 
On Mon, Mar 09, 2020 at 07:47:17AM +, dieterbockla...@gmail.com wrote:
> When using SASL proxy authorization in conjunction with the identity assertion
> feature of back-ldap, the authentication ID is asserted instead of the 
> expected
> authorization ID. A small concrete example (only referencing the relevant
> attributes):

Hi Dieter,
can you post actual configuration, or even better, a script that could
be used in ./tests/data/regressions?

Just before you do that, I've recently set up the same and if you have
your back-ldap to use SASL binds, the code seems to be checking for
simple identity is there before it decides to use proxyauthz. Adding a
stanza like 'binddn=cn=unused' to the idassert-bind option has worked as
a workaround for now.

Let me know if that helps in your case. Haven't had a chance to figure
out what needs changing, so the regression script would be useful.

Regards,

-- 
Ondřej Kuzník
Senior Software Engineer
Symas Corporation   http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP

(ITS#9179) back-ldap SASL proxy authorization

2020-03-09 Thread dieterbocklandt 
Full_Name: Dieter Bocklandt
Version: 2.4.49
OS: CentOS 7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.85.78.248)


When using SASL proxy authorization in conjunction with the identity assertion
feature of back-ldap, the authentication ID is asserted instead of the expected
authorization ID. A small concrete example (only referencing the relevant
attributes):

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 bindmethod=sasl
saslmech=plain authcID=proxy credentials=X  

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

Looking a bit deeper into this, I believe the following piece of code causes
this behavior:

(from servers/slapd/back-ldap/bind.c in master):

line  - 2227:

if ( !BER_BVISNULL( >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( >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? 

Regards,
Dieter