Hi Stépane,
ah ok, while my socket has the same access mode, the directory (/run/saslauthd ) itself belongs to root but has group execution access for group sasl - this is why I need the group access right:
# ls -la saslauthd/ total 4 drwx--x--- 2 root sasl 100 Jun 16 18:43 . drwxr-xr-x 31 root root 1000 Aug 9 08:00 .. srwxrwxrwx 1 root root 0 Jun 16 18:43 mux -rw------- 1 root root 0 Jun 16 18:43 mux.accept -rw------- 1 root root 4 Jun 16 18:43 saslauthd.pid
also my saslauthd runs like this:
/usr/sbin/saslauthd -a ldap -r -m /var/run/saslauthd -n 5
You should be able to test if it is an access issue by running openldap as root for a test or check if the entire path to the mux is really accessible under whatever user your openldap runs as ( also try using for example: nc -U /run/saslauthd/mux under the relevant user to see if it really works )
Hope that helps and kind regards
René
On 06.08.22 15:13, Stéphane Veyret wrote:
Hi René,
Thank you for your suggestion. Unfortunately, it does not seem to work this way with Gentoo.
Ubuntu (which may work different in this regard as your Gentoo) you absolutely have to do:
usermod -a -G sasl openldap
in order for the mux socket of saslauthd to be available by openldap
There is no sasl group in Gentoo. The mux socket belongs to root but is writable by everyone :
# ll /run/saslauthd/ total 4 srwxrwxrwx 1 root root 0 1 août 08:17 mux -rw------- 1 root root 0 1 août 08:17 mux.accept -rw------- 1 root root 5 1 août 08:17 saslauthd.pid
apparmor/SELinux etc. relevant part on your system that prevents those
I do not have apparmor nor selinux installed on this system.
testsaslauthd -u user@domain -p password
work correctly, then an {SASL}user@domain entry in the userPassword field should suffice for the passthrough authentication after having
Yes, and all examples I found on the Internet seemed quite simple. That’s why I am surprise that I cannot make it work on my server.