Hi All,

  This is loosely related to issue 10065 https://bugs.openldap.org/show_bug.cgi?id=10065, but can be read independently.

I have devised a work-around to slapd's inability to check client names on Client certificates and am in the process of removing a proxy (haproxy) I had in front of my slapd server. I have however come across an annoying compromise and I'm offering here a suggestion on how to remove it.

In particular, with the proxy, I could write rules targeting particular clients that worked, even before their initial "bind" operation by using the "sockname=" pattern in the access control rules. This does not seem possible when slapd talks directly to the clients. before the initial "bind" operation, only the IP address is available to tell clients apart, which are not very reliable. IP addresses are easily spoofed.

It would be much better to use the client certificate to match against the particular client. Currently the client ID on the certificate is passed to the SASL layer with the sasl_setprop(...,SASL_AUTH_EXTERNAL,...) call. There it remains until the client performs a "bind" using the SASL EXTERNAL mechanism. At this point, the EXTERNAL client ID is used to derive a distinguished name by filtering it through the "olcAuthzRegexp". It should be noted that LDAP v3 does not require the client to perform such a bind operation.

My Proposal is to expose the EXTERNAL identity to the ACL rules in a similar way to how the "real" prefix exposes the authentication identity - by creating an "external" prefix.

As such, the matching rules

externalanonymous
externalusers
externalself
externaldn
externaldnattr

Could be used to restrict access to clients, even before or without a bind operation.

To maintain naming consistency, The name passed to SASL could have the "olcAuthzRegexp" mapping applied before the ACL rule is applied. In this case, the "external" identity would be the same as the unprefixed identity, after a bind using SASL EXTERNAL mechanism had occured.

This arrangement would have several advantages including:

*) only exposing the userPassword to the particular client that needs it.
*) enforcing client/IP address associations in a rigorous manner.
*) general ACL rules for operations that do not need a "bind" operation.
*) restricting SIMPLE binds to particular clients.

  Any Thoughts ?

Virus-free.www.avg.com