Downgrading to the previous release of sudo does work around this issue, though the RELRO linker flag is somewhat important for security hardening systems.

The sudo 1.7.4p5-7 security announcement is here: http://rhn.redhat.com/errata/RHBA-2011-1175.html

Why can't I access https://bugzilla.redhat.com/show_bug.cgi?id=709235 ?

Prior to this update, sudo incorrectly searched for the Lightweight Directory Access Protocol (LDAP) configuration in the /etc/nss_ldap.conf file. This bug has been fixed in this update so that sudo now searches the /etc/nslcd.conf file

I can confirm the bug reported by squindler. We face the same problem.

I can confirm this as well, we have the same problem.

I can confirm the bug within RHEL 6.2:

[root@rhel62-01 mnt]# lsb_release -a
LSB Version:    :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 6.2 (Santiago)
Release:        6.2
Codename:       Santiago

[root@rhel62-01 mnt]# rpm -qi sudo
Name        : sudo                         Relocations: (not relocatable)
Version     : 1.7.4p5                           Vendor: Red Hat, Inc.
Release     : 7.el6                         Build Date: Thu 21 Jul 2011 12:23:16 PM CEST
Install Date: Thu 22 Dec 2011 05:06:58 PM CET      Build Host: x86-003.build.bos.redhat.com
Group       : Applications/System           Source RPM: sudo-1.7.4p5-7.el6.src.rpm
Size        : 1098902                          License: ISC
Signature   : RSA/8, Mon 01 Aug 2011 08:10:03 AM CEST, Key ID 199e2f91fd431d51
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.courtesan.com/sudo/
Summary     : Allows restricted root access for specified users
Description :
Sudo (superuser do) allows a system administrator to give certain
users (or groups of users) the ability to run some (or all) commands
as root while logging all commands and arguments. Sudo operates on a
per-command basis.  It is not a replacement for the shell.  Features
include: the ability to restrict what commands a user may run on a
per-host basis, copious logging of each command (providing a clear
audit trail of who did what), a configurable timeout of the sudo
command, and the ability to use the same configuration file (sudoers)
on many different machines.

[root@rhel62-01 mnt]# sudo -V | grep nslc
Configure args: --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/usr --sbindir=/usr/sbin --libdir=/usr/lib64 --docdir=/usr/share/doc/sudo-1.7.4p5 --with-logging=syslog --with-logfac=authpriv --with-pam --with-pam-login --with-editor=/bin/vi --with-env-editor --with-ignore-dot --with-tty-tickets --with-ldap --with-ldap-conf-file=/etc/nslcd.conf --with-selinux --with-passprompt=[sudo] password for %p:  --with-linux-audit
ldap.conf path: /etc/nslcd.conf

[root@rhel62-01 mnt]# nslcd --debug
nslcd: DEBUG: add_uri(ldap://(ldap://LDAP SERVER)
nslcd: /etc/nslcd.conf:142: unknown keyword: 'SUDOERS_BASE'

[root@rhel62-01 mnt]# nslcd --debug
nslcd: DEBUG: add_uri(ldap://LDAP SERVER)
nslcd: /etc/nslcd.conf:141: unknown keyword: 'sudoers_base'
[root@rhel62-01 mnt]#


Is there any chance to have this fixed soon? It delays our migration to RHEL 6 in many cases

Also having the same problem, same version, same everything... We need Sudo LDAP working for our project, it is essential, please Red Hat fix it!!

i can confirm the problem,
upgrading to last sudo makes you mandatory to use

sudoers directive in nslcd.conf
but nslcd is unable to restart

i fixed the problem by changing configuration just before start
of nslcd and then putting back sudoers directive in nscld.conf
bug this is a cheap workaround

(In reply to comment #9)
> i can confirm the problem,
> upgrading to last sudo makes you mandatory to use
> 
> sudoers directive in nslcd.conf
> but nslcd is unable to restart
> 
> i fixed the problem by changing configuration just before start
> of nslcd and then putting back sudoers directive in nscld.conf
> bug this is a cheap workaround

I simply downgraded sudo (to p5-5).

The problem here is really in the nss-pam-ldapd package, and its failing to start even though it doesn't recognise some configuration options. If you apply the following patch to the nss-pam-ldapd.spec you can build it without this checking and be able to share the /etc/nslcd.conf between several different daemons without breaking nslcd.

I've built a new RPM and SRPM for nss-pam-ldapd that you are welcome to use as the base. You can find them at:
http://danielhall.me/shared/rpms/nss-pam-ldapd/

--- nss-pam-ldapd.spec.orig	2012-01-12 15:53:01.926469560 +1100
+++ nss-pam-ldapd.spec	2012-01-12 15:48:00.021942827 +1100
@@ -50,7 +50,7 @@
 autoreconf -f -i
 
 %build
-%configure --libdir=/%{_lib} --disable-pam
+%configure --libdir=/%{_lib} --disable-pam --disable-configfile-checking
 make %{?_smp_mflags}
 
 %check

(In reply to comment #11)
> The problem here is really in the nss-pam-ldapd package, and its failing to
> start even though it doesn't recognise some configuration options. If you apply
> the following patch to the nss-pam-ldapd.spec you can build it without this
> checking and be able to share the /etc/nslcd.conf between several different
> daemons without breaking nslcd.
> 
> I've built a new RPM and SRPM for nss-pam-ldapd that you are welcome to use as
> the base. You can find them at:
> http://danielhall.me/shared/rpms/nss-pam-ldapd/
> 
> --- nss-pam-ldapd.spec.orig 2012-01-12 15:53:01.926469560 +1100
> +++ nss-pam-ldapd.spec 2012-01-12 15:48:00.021942827 +1100
> @@ -50,7 +50,7 @@
>  autoreconf -f -i
> 
>  %build
> -%configure --libdir=/%{_lib} --disable-pam
> +%configure --libdir=/%{_lib} --disable-pam --disable-configfile-checking
>  make %{?_smp_mflags}
> 
>  %check

This patch works for me (built from the SRPM). This is a seriousproblem, especially if sites do auto updates - suddunly updating from 6.1 to 6.2 breaks all your management stuff!

I don't think /etc/nslcd.conf is the best location for 'sudoers_base'. Some installs will not be using nslcd (for example where sssd is in use) but may still be using LDAP for sudo. The previous version of sudo looked in /etc/nss_ldap.conf for this config, however I don't think that is an appropriate location either (for the same reason as above). Sudo reads its LDAP related config directly from whichever file is nominated in the ' --with-ldap-conf' compile switch. Perhaps sudo needs its own config file in future e.g. /etc/sudo_ldap.conf

(In reply to comment #13)
> I don't think /etc/nslcd.conf is the best location for 'sudoers_base'. Some
> installs will not be using nslcd (for example where sssd is in use) but may
> still be using LDAP for sudo. The previous version of sudo looked in
> /etc/nss_ldap.conf for this config, however I don't think that is an
> appropriate location either (for the same reason as above). Sudo reads its LDAP
> related config directly from whichever file is nominated in the '
> --with-ldap-conf' compile switch. Perhaps sudo needs its own config file in
> future e.g. /etc/sudo_ldap.conf

 putting in a complete separate file will make necessary to copy the other ldap configuration parameters in that file also or sudo will have to look in more than one file to known where the ldap server is located.

Why should the sudo_ldap configuration move form the /etc/ldap.conf file at all.

This file, at least as far as I know, is for LDAP (usually openldap) API based configurations.  All all of these different configuration files seem to do is make administration of a system more difficult that it ought to be.  Given /etc/ldap.conf supports all the required options, why can't / don't other config files (/etc/nss_ldap.conf /etc/nslcd.conf /etc/sssd.conf) can't just have something like use_ldap = true then source their relevant config from /etc/ldap.conf.  Sure specifics can/should be stored in service specific configs vs convoluting /etc/ldap.conf, not using ldap.conf "just because" is arbitrary at best.

Given how widely LDAP is used it seems a pretty major oversight that sudo could have been modified in such a way and made its way through QA and into stable release - and further to be patched or related packages patched to remedy the situation ... this situation doesn't instill much confidence in Redhat QA of package testing and release.

How do we get a consensus on the topic to have the direction to walk into?
We have bz for why we went away from /etc/ldap.conf in the first place.

This breaks rhel6.0/6.1 to 6.2 upgrades that utilize nslcd/sudo/ldap .
This might also hit environments and migrations for which we might request 6.2.z .

IanB's suggestion of sudo_ldap.conf is the best I've seen all year.  It would be nice to have a documented sudo-specific file going forward rather than having sudo reference a daemon's configuration file when that daemon may not be in use.  

The LDAP server will need to be specified in more than one file, but that is already the case with /etc/nslcd.conf vs. /etc/sssd/sssd.conf.  It could be problematic to try and keep programs from different upstream sources compatible with each others' configuration files, as this bz demonstrates.

Having each application point to a different file is definitely a good idea. To prevent having to put the same config in all those files you could simply symlink them all to the same file. That way admins that require a different config for sudo, which is possible, can simply replace the symlink with the config file.

The only issue I have with that is that its entirely not obvious and could cause all sorts of problems with automated setups if they don't check for the existence of the symlink.

Yes it does break the RHEL update but its already broken for 6.2 without downgrading sudo or applying my fix. The upgrade from 6.{0,1} to 6.2 was broken with the change to sudo anyway.

Why is everyone rushing to put every component into its own config file?  This increases the complexity of LDAP deployment, increases the systems administrators' job of management, and effectively provides a disincentive to try to go this route.  I think we should be discussing how to use fewer config files, not more.  

Consider, that to use LDAP for authn/authz on EL 6.x, you already need to have an /etc/pam_ldap.conf, since that is the compiled default location where pam_ldap.so looks for its config.  So now you need two files, /etc/pam_ldap.conf, and /etc/nslcd.conf.  Except, that you also need a config file for the OpenLDAP Clients, which is /etc/openldap/ldap.conf.  Okay, so now you've got three files.  Yuck.

Has anyone tried to compile nslcd without strict parsing, and also recompile pam_ldap, such that the default configs for these could both live in /etc/nslcd.conf....or wherever?  Symlinks can then be used to link to /etc/ldap.conf, or /etc/openldap/ldap.conf, as needed?

Anyway, just a thought....but I sure hope this is fixed soon.  It would be great to have a working sudo-in-ldap solution, yet again, for RHEL/CentOS.  I am even now trying to deploy this to my organization, and I'm building my own RPMs for a local yum repo, etc, etc.  This shouldn't have to happen...

hi guys,
are there any plan on fixing this issue.It s blocking in order to patch our servers since we heavily rely on ldap and sudo in our infrastructure....

Hi all who are affected by this in their environments,

the best way to ensure this bz gets the attention it deserves is for you to open a customer center case, illustrate how many systems are affected and how it affects you.  This bugzilla is for the technical discussion, for setting appropriate priorities and informations on when this might get fixed the customer center seems more appropriate.

I am setting severity to high, based on the affected environments we already know about.

Hello,

as I see it the current version is broken and none of those who installed it AND use ldap can use it.  At least not without editing the nslcd.conf before the start of nslcd. I also assume that no one really cleaned the previous configuration and remove the entries from /etc/nss_ldap.conf. Thos who don't use ldap do not have a problem.

My suggestion would be to revert this behavior for now so the installations that are out there work again. I don't think changing the configuration within a major release is a good idea. 

I would suggest that for the next release RedHat should decide what they want.
1. High flexability
Using a special configuration for evey client who can connect to LDAP. This would mean admins would have to put the same configuration into a lot of files. Keeping this information synced is probably the major problem. On the other hand it would allow the different clients to use completely different LDAP servers.
2. Easy maintenance
One configuration file for all or insource of a central file. This would negate the risk of configurations getting out of sync (pam asking differen ldap servers than sudo)

Hello,
 I'm going to fix this by introducing a sudo specific config file for the sudoers-in-LDAP configuration, /etc/sudo-ldap.conf. I won't use the attached patch as it is a bit controversial. I don't think that nslcd will drop it's strict parsing or implement an option to disable it in runtime.

If someone has serious objections against this, please let me know. I think it's the most acceptable way to resolve this issue.

Created attachment 566888 [details]
default sudo-ldap.conf

In my mind : making a new file with same config, without integrating with standard tools like authconfig will create problems also.

The users will have to manually edit this file.

What about changing the sudo code to read 2 files :
   the standard file 
   the sudo specific parameters file 

This will work with any version and all changes made by standard tools will work.
Maybe some people will not like this, but the integration with configuration tools work. A single place to change de ldap uri and connection parameters.

I'd much prefer to see a hierarchical approach to LDAP configuration where the core OpenLDAP provider features are spec'd in ldap.conf then other services using LDAP can include ldap.conf and extend upon the base provided options.

The assortment of LDAP specific configs is beginning to get just a bit crazy in 6.2 - we now have 
 /etc/ldap.conf
 /etc/openldap/ldap.conf
 /etc/sssd/sssd.conf
 /etc/nslcd.conf
 /etc/pam_ldap.conf
 /etc/nss_ldap.conf
AND
 /etc/sudo-ldap.conf

Setting the LDAP server in so many places makes a misconfiguration way too easy, and is the essence of bad redundancy given how core LDAP is to many organisations.

There is a minor convenience that we can at least symlink /etc/ldap.conf, /etc/openldap/ldap.conf, /etc/pam_ldap.conf & /etc/sudo-ldap.conf but this really isn't ideal ... 

but, just my 2c.

Why is this still broken?  It's been about 4 months now, and this should be considered a BLOCKER seeing as how it can cause some major breakage.  This is where a source distro really shines - none of my Gentoo machines have this problem, and if they did I could fix it without having to wait for some upstream maintainer to get around to it.

If people can't agree on a new solution, at least everyone seems to agree that the older version is "better" because it's not broken.  Just roll the config location back to the previous version's until a more appropriate place for this configuration can be agreed upon.  This is utter nonsense.

Any update on this issue, I cannot find the package sudo-1.7.4p5-8.el6

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
* Sudo now uses a separate file, /etc/sudo-ldap.conf, for configuring LDAP sudoers sources.

(In reply to comment #30)
> Any update on this issue, I cannot find the package sudo-1.7.4p5-8.el6

Hello,
 the fix should be a part of the 6.3 release of RHEL.

I think this huge issue, in my deployment is about 30 server RedHat. Some 5 some 6.
Each time have different issue with sudo centralize deployment. I think the best way to go stop create temporary solution  like nss_ldap sudo_ldap and so on.
Currently on Fedora 16 is have support of suroers inside sssd on location one filter line no more 10 file to config. I am third day trying resolve this issue on of boxes, which should take in most 20 min of time.

[root@xxxxxxx pam.d]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.2 (Santiago)


[root@xxxxxxx pam.d]# /usr/sbin/nslcd -d
nslcd: DEBUG: add_uri(ldaps://xxxxxxx:636/)
nslcd: /etc/nslcd.conf:21: option TLS_CHECKPEER is deprecated (and will be removed in an upcoming release), use tls_reqcert instead
nslcd: DEBUG: ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT,0)
nslcd: DEBUG: ldap_set_option(LDAP_OPT_X_TLS_CIPHER_SUITE,"TLSv1")
nslcd: DEBUG: ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT,3)
nslcd: DEBUG: ldap_set_option(LDAP_OPT_X_TLS_CACERTFILE,"/etc/openldap/cacerts/authconfig_downloaded.pem")
nslcd: /etc/nslcd.conf:35: unknown keyword: 'sudoers_base'
[root@xxxxxx pam.d]# vim /etc/openldap/ldap.conf 


Man Page

 sudo_provider (string)

            This is an experimental feature, please use http://fedorahosted.org/sssd to report any issues.

           The SUDO provider used for the domain. Supported SUDO providers are:

           “ldap” for rules stored in LDAP. See sssd-ldap(5) for more information on configuring LDAP.

           “none” disables SUDO explicitly.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1,11 @@
-* Sudo now uses a separate file, /etc/sudo-ldap.conf, for configuring LDAP sudoers sources.+Cause:
+Sudo used the /etc/nslcd.conf for configuring the LDAP sudoers sources but the script parsing of this file by the nslcd daemon caused it to terminate when it encountered a sudo specific keyword. 
+
+Consequence:
+No proper way to have both the nslcd daemon running and the LDAP sudoers sources configured.
+
+Fix:
+Sudo now uses a separate file, /etc/sudo-ldap.conf, for configuring LDAP sudoers sources.
+
+Result:
+Sudo uses it's own file for configuring the sudoers LDAP source and does not interfere with any other program.

/etc/sudo-ldap.conf is an unfortunate naming choice, given that we already have the newly-minted /etc/pam_ldap.conf. Those of us migrating LDAP client configurations from RHEL-5 are spinning...

I built rpm with --ldap-config-file /etc/sudo-ldap.conf tested and right now working sudo with SSL
If some body interesting test and update  here link.

ftp://ftpsrv01.networklab.ca/centos/6/RPMS/x86_64/


LDAP Config Summary
===================
uri              ldaps://xxxxxx:636/
ldap_version     3
sudoers_base     ou=SUDOers,dc=xxxxx,dc=xxxx
binddn           uid=xxxxxx,ou=People,dc=xxxxx,dc=xxxxx
bindpw           xxxxxxx
ssl              on
tls_checkpeer    (no)
tls_cacertfile   /etc/openldap/cacerts/authconfig_downloaded.pem
===================
sudo: ldap_initialize(ld, ldaps://xxxxxxxx:636/)
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: tls_checkpeer -> 0
sudo: ldap_set_option: tls_cacertfile -> /etc/openldap/cacerts/authconfig_downloaded.pem
sudo: ldap_set_option: tls_cacert -> /etc/openldap/cacerts/authconfig_downloaded.pem
sudo: ldap_set_option(LDAP_OPT_X_TLS, LDAP_OPT_X_TLS_HARD)
sudo: ldap_sasl_bind_s() ok

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0905.html