https://bugs.openldap.org/show_bug.cgi?id=10065
--- Comment #13 from Ondřej Kuzník <[email protected]> --- On Mon, Jun 12, 2023 at 12:33:49PM +0000, [email protected] 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? -- You are receiving this mail because: You are on the CC list for the issue.
