https://bugs.openldap.org/show_bug.cgi?id=10065
--- Comment #12 from sean@teletech.com.au --- (In reply to Ondřej Kuzník from comment #11)
On Mon, Jun 12, 2023 at 11:00:29AM +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.
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 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.