https://bugs.openldap.org/show_bug.cgi?id=10065
--- Comment #11 from Ondřej Kuzník ondra@mistotebe.net --- On Mon, Jun 12, 2023 at 11:00:29AM +0000, openldap-its@openldap.org wrote:
Secondly, My comments were based on the openLDAP clients. I have observed that if you specify a mechanism with the -Y switch, they do not do a query for the available mechanisms. If this behavior is non-standard, we all have a problem.
Right, I didn't notice. Still worth keeping slapd consistent in what gets exposed in rootDSE vs. what's accepted is what I meant. (Even our) clients are free to disregard at their own peril.
The relevant capabilities exist in the PROXY protocol already and somehow I can't see any reference to that in your analysis.
Yes I did mention it. << Additional TLS related information in the protocol packet could be decoded and an "authid" constructed with that information. The ssf could also be derived from the reported ciphers. >>
I must have misunderstood it, proposing that we just accept the certificate DN as the starting point, reading your suggestion as trying to construct it based on something like the reported IP address etc. (p.s.: and going by the below it seems I did read it correctly the first time?)
with a wall of unnecessary text that is in part inflammatory that you just lob at the ticket, this didn't help[0].
Sorry, I meant no offense. I wrote the "wall of unnecessary text" after my first post was completely misunderstood. Still, better to say too much than too little. I am not involved in the OpenLDAP project and don't know how things work around here. It seemed like something that should go in a bug report so that's what I did. Again - sorry.
No offense taken, just that that approach didn't make we *want* to take it seriously which might have happened with others reading this too.
You are welcome to implement relevant bits of the PROXY protocol to inject the reported authid/session existence into the connection when provided and post it for review. It might not be the easiest part of slapd to get started in but should be doable given you've looked into it already.
I'll give it some thought but am seriously pressed for time at the moment.
Sure, at the very least we have some analysis in place for whoever feels so inclined.
[0]. For one, the whole first paragraph painting ACLs as insecure while ignoring the fact that everything that you propose should be achievable with an ldaps:// listener that requires a client certificate to be provided at the time of TLS negotiation. That way it is the same gatekeeper to ACL machinery as your proxy would. That's not hard to audit, test or maintain, leaving ACLs to implement any remaining policy that would be there regardless.
I'm sure that would work, because that is exactly how I have my system configured at the moment. I have four clients and slapd listens on four sockets and I can identify the client by the name of the socket. The proxy is still there mind you. The clients connect over TLS.
The drawback there was that olcAuthzRegexp works on DNs whereas the socket is distinguished by the peername or sockname. I can't rewrite the sockname to something more readable so the ruleset looks UGLY. Also, having one socket per client is not very scalable. Using the proxy protocol seemed to be a much better approach - until I found it's weakness.
Wait a minute, so are you using the DN or identity of the sockname? You can always prepend a few ACL rules to screen clients accordingly, but using sockname to distinguish clients probably isn't the best idea. You might be better off running several servers each dedicated to its network if network identity is the only way you can distinguish them.
I don't think encoding the reported sockname to authzid when accepting a connection on ldapp:// would be accepted. You might be better off just writing an ACI module there.
Again - please do not take offense. In these situations, I always try to stay focused on what I am trying to achieve. I.e. better software for all.
All is well.