sudo-ldap not working with ldaps

I found the solution, the correct directive to specificy a CA certificate file for sudo-ldap is:

TLS_CACERTFILE /path/to/cacert.pem

So my ldap.conf now figures so:

BASE dc=aldu,dc=net
URI ldaps://ldap.aldu.net
TLS_CACERT /etc/ssl/cacert.pem
TLS_CACERTFILE /etc/ssl/cacert.pem

SUDOERS_BASE ou=sudoers,dc=aldu,dc=net

It's absolutely redundant, so I think it would be nice to make sudo-ldap reading CA certificate path from TLS_CACERT directive instead of TLS_CACERTFILE.

Founded another issue: when doing `sudo' as ldap user, SSL still doesn't work:

ldapuser@myhost:~$ sudo ls
LDAP Config Summary
===================
uri ldaps://ldap.aldu.net/
ldap_version 3
sudoers_base ou=sudoers,dc=aldu,dc=net
binddn (anonymous)
bindpw (anonymous)
ssl (no)
===================
ldap_set_option(LDAP_OPT_X_TLS_CACERTFILE,"/etc/ssl/certs/AlduNetworkCA.pem")
ldap_initialize(ld,ldaps://ldap.aldu.net/)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind_s()=81 : Can't contact LDAP server

While the same as local user:

localuser@host:~$ sudo ls
LDAP Config Summary
===================
uri ldaps://ldap.aldu.net/
ldap_version 3
sudoers_base ou=sudoers,dc=aldu,dc=net
binddn (anonymous)
bindpw (anonymous)
ssl (no)
===================
ldap_set_option(LDAP_OPT_X_TLS_CACERTFILE,"/etc/ssl/certs/AlduNetworkCA.pem")
ldap_initialize(ld,ldaps://ldap.aldu.net/)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_bind() ok

Permissions on CA certificate are ok, ldapsearches too. If I do `sudo' as ldap user with `ldap' instead of `ldaps' it runs fine again.

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Hello,

we have the same problem here...

Configuration:
=================
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.10
DISTRIB_CODENAME=karmic
DISTRIB_DESCRIPTION="Ubuntu 9.10"

$ dpkg -l | grep sudo
rc sudo 1.7.0-1ubuntu2 Provide limited super user privileges to specific users
ii sudo-ldap 1.7.0-1ubuntu2 Provide limited super user privileges to specific users

$ sudo cat /etc/ldap/ldap.conf
BASE dc=multiexportfoods,dc=com
URI ldaps://fds.multiexportfoods.com:636
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
TLS_REQCERT never

sudoers_base ou=SUDOers,dc=multiexportfoods,dc=com
=================

running command "sudo -l" I have this output:

==============
$sudo -l
[sudo] password for victor:
Sorry, user victor may not run sudo on server.
==============

Nota.: changing the "sudoers_debug" option on /etc/ldap/ldap.conf to
sudoers_debug 2
sudoers_debug 5
sudoers_debug 20
sudoers_debug 50

no make differ !!! :(
on others words, debug not work.

more info:

the ldaps work fine, because I can authenticate users with it:
$getent passwd victor
victor:x:5555:55555:Victor Hugo dos Santos,,,:/home/victor:/bin/bash

I read notes that the problem is "only" with ldaps... and if I configure ldap (without SSL), so works !!!
but, in my company this isn't a option.

saludos

Thank you for updating us with this. Marking Confirmed, Medium.

Hi guys, sorry I haven't checked on this in a while. I don't know if it will help since I don't know much about ldap(s), but have a look at the "SSL connections failure" section at https://wiki.ubuntu.com/DebuggingOpenldap which may be able to provide the developers with more debugging information. Also, can you confirm what version of Ubuntu you are using, since this hasn't been stated and has this been tested in Lucid? If not would this be possible, as it may already have been fixed. Thank you guys.

I can confirm this bug existed in karmic and still exists in lucid, and has gotten worse since /etc/sudo-ldap.conf is now a symbolic link to /etc/ldap/ldap.conf. Not knowing this, I tried to edit /etc/sudo-ldap.conf and change ldaps to ldap, accidentally turning off encryption for all NSS/PAM LDAP activity including passwords!

The page linked above is only partially relevant, since it deals with connection debugging with ldapsearch, which works just fine with ldaps in this case. I did the gnutls-client part and got the following:

Processed 1 CA certificate(s).
Resolving 'mail....de'...
Connecting to '172.16.6.1:636'...
- Certificate type: X.509
 - Got a certificate list of 1 certificates.
 - Certificate[0] info:
  - subject `C=DE,ST=NRW...,CN=mail....de,<email address hidden>', issuer `C=DE,ST=NRW,...,CN=....de,EMAIL=admin@...de', RSA key 2048 bits, signed using RSA-SHA, activated `2009-11-30 13:22:21 UTC', expires `2010-11-30 13:22:21 UTC', SHA-1 fingerprint `a4f903c0b1169e02172136933781cca3f5c9ca72'
- The hostname in the certificate matches 'mail....de'.
- Peer's certificate is trusted
- Version: TLS1.1
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

Looks like a perfect conection, I think.

I set "SUDOERS_DEBUG 2" in /etc/sudo-ldap.conf and found out the problem. First, sudo-ldap failed to verify the server certficate, despite I had specified a CA cert. Second, it ignored the option to not verify the certificate as well.

A closer look at the manpage of sudo-ldap reveals that the standard ldap.conf and sudo-ldap use different options for the same thing. Standard ldap.conf uses TLS_CACERT, while sudo-ldap uses TLS_CACERTFILE. Standard is TLS_REQCERT (yes/no), while sudo-ldap uses TLS_CHECKPEER (yes/no).

I now have TLS_CACERT as well as TLS_CACERTFILE and it works.

I don't know whether the standards have changed recently and sudo-ldap in lucid is ahead of time, but this should be unified in any case.

Thanks for providing that information. Hopefully this should have enough information now for a developer to take a look at it and begin working on this, so I have marked it Triaged and will let them handle it from here. Thanks again for reporting this to us and good luck! :)

I was seeing this same behavior on Lucid and was able to correct this after several steps, the last step seemed to be most important:

1. Create local account with necessary permissions. Login as that user.
2. install and run nscd (using 'sudo apt-get install nscd' and '/etc/init.d/nscd restart')
3. Added the additional line in my ldap.conf 'tls_cacert' (add whichever one was not there - not sure if this step is even necessary)
4. Add the line 'session required pam_mkhomedir.so skel=/etc/skel/' to /etc/pam.d/common-session. This creates the user's home directory and seems to affect the sudo functionality.

I now have no difficulty opening an ssh session to the box as an LDAP user and using sudo. I am still using a local /etc/sudoers (not the updated ldap version of sudoers).

--paklids

Sorry if my last comment was not applicable. I didn't realize this was specifically for users of sudo-ldap. My challenge and corresponding fix may, however, be helpful.
--paklids

Hi all,
I'm not using sudo-ldap as it's apparenlty screwed up as well. Another way around is to use the NOPASSWD option in your sudoers file. Yeah it sucks. A user will be able to sudo without a password. They've already authenticated as their real selves in order to get in and it gets around the LDAP account problem.