On Mon, Jun 16, 2025 at 10:55:27AM +0000, Gianluca Ramunno wrote: > Hello, > > I would need help with the openldap backsock backend. > > In the company I work for, we have a portal for authentication > (Authelia) that uses an LDAP server to actually authenticate the users > and to retrieve the information about the groups they belong to. > > In a short time, we will need to change the LDAP server which contains > the users' database. > > To have a smooth transition between the old and the new LDAP server we > are trying to implement an LDAP proxy using openldap+backsock backend > + a python concurrent server that listens on the UNIX socket what will > be used by the backsock backend. The LDAP proxy should try to > authenticate to the new LDAP server and in case of failure with error > 49 should try to authenticate to the old one. In case of another > failure with error code 49 the LDAP proxy should return error 49 to > Authelia. Otherwise it would return 0 and the list of groups the user > belongs to. > > Now the issue. > > We noticed that the backsock backend closes the UNIX socket after > every operation (bind, search, unbind...). We implemented a prototype > of the python concurrent server that serves each request on the socket > by forking a new child. When we started writing this server, we > thought that the UNIX socked would have been kept open from the bind > operation through other ops like a search until the final unbind. > Instead, the actual behaviour of the backsock backend prevents > establishing a correlation between a (successful) bind - i.e. a > successful authentication - and a subsequent operation (e.g., a > search). How to fix this? Did we miss something? > > If we modify the backsock backend to keep open the UNIX socket at the > end of the bind op until the next bind or unbind and to use the open > socket with the search op, would this be a (thread) safe modification?
Hi Gianluca, the sockets are meant to be ephemeral, to access the context about what client issued this request, you want to enable the optional slapd-sock extensions (like connid and/or binddn). You might also be able to implement what you need with remoteauth overlay on the "new" server? Potentially the rwm overlay depending on your full requirements. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
