[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#4488) back-ldap uses proxyAuthz for idassert when protocol is not LDAPv3



Full_Name: Pierangelo Masarati
Version: HEAD,re24,re23
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (131.175.154.56)
Submitted by: ando


There appears to be some inconsistency in the way the protocol is set by proxy
backends.  The error discussed here is a symptom of that.  The proxy backends
use the same protocol version used by the client; however, some LDAP extensions
are not allowed if the protocol version is not LDAPv3.

For example, newSuperior in modrdn; this is handled by changing the protocol
version if newSuperior is being used.  This is incorrect first of all because I
think the protocol version should not be changed after the connection has been
established and bind occurred.  Moreover, if the client bound as LDAPv2+, the
frontend wouldn't allow it to perform operations that are LDAPv3.

The identity assertion is not caught here because it is actually used by the
proxy to implement a certain feature; but it can only be used if the connection
between the proxy and the remote DSA is LDAPv3.

I've fixed this by adding a "protocol-version" directive that allows to enforce
the version of connections between proxy and remote DSAs.  By default, all
connections occur via LDAPv3; if set to 2, they occur via LDAPv2+, and LDAPv3
features are not used (this is only partially implemented, though).  If set to
0, the protocol version is inferred from that used by the client.

Although not directly suffering from this issue, as idassert is not implemented
yet, back-meta has been modified accordingly.  In that case, different protocol
versions can be set for each target DSA.

p.