Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#949519: sudo-ldap: Fails to connect to LDAP : "ldap_sasl_bind_s(): Can't contact LDAP server"
542 views
Skip to first unread message
Jean-Christophe
Jan 21, 2020, 11:50:03 AM1/21/20
to
Sorry, it looks like I forget to paste the presentation of my issue on reportbug.
I used to use sudo-ldap on Stretch to grant some rights to some users on my servers.
I recently upgrade one of these servers to Buster, and now sudo doesn't work anymore.
It's always the same error : "ldap_sasl_bind_s(): Can't contact LDAP server".
Which is interesting is that ldapsearch works when I try something like this :
ldapsearch -x -H ldaps://server2.mydomain.com:636 -b "ou=SUDOers,dc=mydomain,dc=com"
Also ldap.conf and sudo-ldap.conf are identical.
Jean-Christophe
Jan 22, 2020, 9:50:03 AM1/22/20
to
Just for information, I just run a test on a Bullseye VM with sudo-ldap 1.8.29-1 and the issue is still present in this version.
Dennis Filder
Feb 20, 2021, 2:40:02 PM2/20/21
to
Control: tag -1 + moreinfo unreproducible
Jean-Christophe, are you still interested in figuring this out? If so
you need to provide more information. You also don't say what else
you have tried to investigate this.
I tried reproducing your observed behaviour, but it doesn't manifest
here unless I put "TLS_REQCERT allow" into my normal user's ~/.ldaprc
file (which is not a bug, but a misconfiguration).
"ldap_sasl_bind_s(): Can't contact LDAP server" is really just a
generic TLS error which could have a million different causes. Some
ideas what could be going on:
* The certificates may have been generated with outdated TLS
parameters or the server is running outdated configuration options.
I recall that during the move to buster OpenSSL changed its default
settings for what versions of TLS it still allows (TLS_CIPHER_SUITE,
TLS_PROTOCOL_MIN). Give us the output of:
openssl s_client -debug -connect server2.mydomain.com:636 -verify 255 </dev/null
Altering the server config to always use at least TLSv1.2 might
already help. Regenerating the server certificates is worth a try,
too.
* You run "ldapsearch" under the effective user id of "jc", but "sudo"
runs under the effective user id of "root". If you have a file
~jc/.ldaprc with different TLS settings this could explain why the
"ldapsearch" command succeeds, but "sudo -l" fails. What happens if
you run "ldapsearch" under a freshly created user? Please run "sudo
-l" as root and tell us if the error still occurs. If it does then
as root run this command and give us /tmp/sudo-l-strace.gz
strace -f -s 2048 sudo -l |& gzip -9c > /tmp/sudo-l-strace.gz
Also to turn off any initialization mechanisms run your ldapsearch
commands like this:
LDAPNOINIT=1 ldapsearch -x -H ...
Tell us if this changes anything.
Until you can give us something that clearly points to the code of
sudo-ldap doing something it shouldn't we have to assume that this is
due to a misconfiguration.
Regards,
Dennis.
Jean-Christophe, are you still interested in figuring this out? If so
you need to provide more information. You also don't say what else
you have tried to investigate this.
I tried reproducing your observed behaviour, but it doesn't manifest
here unless I put "TLS_REQCERT allow" into my normal user's ~/.ldaprc
file (which is not a bug, but a misconfiguration).
"ldap_sasl_bind_s(): Can't contact LDAP server" is really just a
generic TLS error which could have a million different causes. Some
ideas what could be going on:
* The certificates may have been generated with outdated TLS
parameters or the server is running outdated configuration options.
I recall that during the move to buster OpenSSL changed its default
settings for what versions of TLS it still allows (TLS_CIPHER_SUITE,
TLS_PROTOCOL_MIN). Give us the output of:
openssl s_client -debug -connect server2.mydomain.com:636 -verify 255 </dev/null
Altering the server config to always use at least TLSv1.2 might
already help. Regenerating the server certificates is worth a try,
too.
* You run "ldapsearch" under the effective user id of "jc", but "sudo"
runs under the effective user id of "root". If you have a file
~jc/.ldaprc with different TLS settings this could explain why the
"ldapsearch" command succeeds, but "sudo -l" fails. What happens if
you run "ldapsearch" under a freshly created user? Please run "sudo
-l" as root and tell us if the error still occurs. If it does then
as root run this command and give us /tmp/sudo-l-strace.gz
strace -f -s 2048 sudo -l |& gzip -9c > /tmp/sudo-l-strace.gz
Also to turn off any initialization mechanisms run your ldapsearch
commands like this:
LDAPNOINIT=1 ldapsearch -x -H ...
Tell us if this changes anything.
Until you can give us something that clearly points to the code of
sudo-ldap doing something it shouldn't we have to assume that this is
due to a misconfiguration.
Regards,
Dennis.
Marc Haber
Dec 11, 2021, 3:10:03 AM12/11/21
to
On Sat, Feb 20, 2021 at 08:29:05PM +0100, Dennis Filder wrote:
> Jean-Christophe, are you still interested in figuring this out? If so
> you need to provide more information. You also don't say what else
> you have tried to investigate this.
I intend to close this bug by the end of February 2022 if we don't get
> Jean-Christophe, are you still interested in figuring this out? If so
> you need to provide more information. You also don't say what else
> you have tried to investigate this.
more information.
Greetings
Marc
Marc Haber
Feb 1, 2022, 4:30:03 AM2/1/22
to
packsge sudo-ldap
severity #949519 normal
outlook #949519 close after 2022-02-28
thanks
Lowering severity as this seems to affect just a few users.
Greetings
Marc
severity #949519 normal
outlook #949519 close after 2022-02-28
thanks
Lowering severity as this seems to affect just a few users.
Greetings
Marc
0 new messages