On Thu, Jul 27, 2023 at 03:17:41PM +1000, Sean Gallagher wrote:
> Hi All,
> 
> 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.

Hi Sean,
I'm not sure what you're trying to achieve here. Why do you want to
distinguish different kinds of anonymous clients? The usual answer to
this is to have ACLs that prevent them from doing anything except a
Bind, during/after which they have (a proposed) identity that is part of
ACL processing.

If you need to distinguish different "anonymous" clients from each other
and give some additional access, you might have to define your own
dynacl module that lets you define arbitrary logic, pretty sure even
inspecting the connection/TLS session state.

Regards,

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

Reply via email to