https://bugs.openldap.org/show_bug.cgi?id=10065
--- Comment #13 from Ondřej Kuzník ondra@mistotebe.net --- On Mon, Jun 12, 2023 at 12:33:49PM +0000, openldap-its@openldap.org wrote:
Wait a minute, so are you using the DN or identity of the sockname?
All the sockets have the same DN because they all come form haproxy and so, identify the haproxy uid. the sockname is the only thing I can use.
can always prepend a few ACL rules to screen clients accordingly, but using sockname to distinguish clients probably isn't the best idea. You
Yeah, it feels like a kludge - but it works. It didn't sit well with me relying of the ACLs to deny access, attribute by attribute to a potential bad actor. It's like letting criminals into the building because you are "pretty sure" all the filing cabinets are locked.
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
That is what I meant by "easy to manage, test and audit" as no further ACL processing (potentially granting access) is done for your potential bad actors.
might be better off running several servers each dedicated to its network if network identity is the only way you can distinguish them.
Well, I wanted to use the TLS client certificate to distinguish them. This is what I do in the haproxy ruleset. I also enforce the IP address but the certificate is much stronger authentication.
I think we're on the same page now, you want to use the DN of the client certificate but can't (yet) and propose acting on the PP2_SUBTYPE_SSL* TLVs, at the very least PP2_TYPE_SSL and PP2_SUBTYPE_SSL_CN.
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.
I don't think encoding the reported sockname to authzid when accepting a connection on ldapp:// would be accepted.
I wouldn't even suggest it. I would have preferred to run proxy protocol over an IPC socket but that wasn't supported and I didn't want to court controversy by suggesting it should be, so I tried a TCP socket listening on localhost. It's reasonably efficient and reasonably secure.
But all things considered, it seems to me, the best path forward is to decode the TLS information passed from haproxy and if possible, construct an authid in the same form as that constructed for non-proxied TLS connections.
What is preventing you from exposing slapd to your clients directly?