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,