https://bugs.openldap.org/show_bug.cgi?id=10065
--- Comment #15 from Ondřej Kuzník ondra@mistotebe.net --- On Mon, Jun 12, 2023 at 01:15:21PM +0000, openldap-its@openldap.org wrote:
You can always make this the first ACL in the list (in your analogy, putting a security guard/gate that checks people even get access to the building):
access to * by <your allowlist expressed as peername/sockname> break by * none
An awful lot of lines of code need to run to parse and interpret the ruleset, and parse and interpret LDAP commands, seems how the ruleset isn't applied until it is presented with a command. I'm not saying there IS anything wrong with that code, I just don't know. And I have the option of putting a proxy in front of it and then I can sleep better.
Slightly off-topic but if you configure ldaps:// and *require* client certs, the session won't get set up to the point of touching anything LDAP related until the client's proved it holds a certificate you trust.
That's more or less what you're using haproxy for? If so, I think you're in the clear even if you don't wish to trust the ACL machinery is being completely and consistently enforced.
Except that rereading the spec, we don't actually get to see the whole DN, just the CN part so that is not viable unless a new field were defined for it.
Yeah, I was worried about that too. Luckily for me at least, My client certificate's DN's only have a single CN - so no information lost. I'm sure this is not true in general. But so long as the CN's are unique, I could use the DN rewriting to fill in all the missing RDNs.
Well, that by itself doesn't sound like enough for the OpenLDAP side, hence the need for a new field.