https://bugs.openldap.org/show_bug.cgi?id=10065
--- Comment #10 from [email protected] --- > I think you're overcomplicating things. Trying to have clients that > ignore the rootDSE isn't going to land well when it's possible to do > things according to the protocol. Firstly, this post was written in reply to Quanah Gibson-Mount who expressed an interest in removing the Cyrus-sasl dependency. I wrote this to explore the possibility. Personally, I have no problem with Cyrus SASL. 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. > 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. >> > 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. > > Be straight to the point and sure, attach/reference things for people > that want to read them if you think it's helpful but I'd always > appreciate a TL;DR in that case. > Noted. > 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. > [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. 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. -- You are receiving this mail because: You are on the CC list for the issue.
