[sudo-users] sudo & LDAP

Galen Johnson Galen.Johnson at sas.com
Wed Mar 7 08:49:19 EST 2007


I was under the impression that the sudo ldap module didn't support ldaps.

=G= 

-----Original Message-----
From: sudo-users-bounces at courtesan.com [mailto:sudo-users-bounces at courtesan.com] On Behalf Of Doug Goldstein
Sent: Wednesday, March 07, 2007 1:37 AM
To: Chan Wilson; sudo-users at sudo.ws
Subject: Re: [sudo-users] sudo & LDAP

Chan Wilson wrote:
> It's a certificate problem.  Sudo w/LDAPS enforces the certificate 
> chain.  Most LDAPS installations are lacking a few critical details.
> 
> I ran into this exact problem.  I'd supply more hints, but my notes 
> are buried at the moment...

Interestingly enough, I tried openssl s_client -tls1 -connect
marble.internal.company.com:389 -showcerts -state -CAfile /etc/ssl/certs/cacert.org.pem

And it failed the handshake, so this does make sense.

However, I further tested this (and I'll post the logs tomorrow when I'm at the machine.) by removing --with-ldap from sudo and cranking up the logging for nss_ldap. nss_ldap is able to establish a TLS connection just fine and work via sudo. It also works via "id". I compile sudo with --with-ldap and when sudo hands off the query to nss_ldap, nss_ldap is unable to establish a TLS connection.

I'm starting to think the problem is in the OpenLDAP libraries and it sharing a SSL context when it shouldn't be shared. Or not properly handling locking. I'm not sure exactly but I plan on cross-posting tomorrow to the OpenLDAP mailing list.

> 
> --chan
> 
> 
> On 3/6/07, *Doug Goldstein* <cardoe at gentoo.org 
> <mailto:cardoe at gentoo.org>> wrote:
> 
>     Doug Goldstein wrote:
>     > Hi all,
>     >
>     > Currently I'm having an issue with sudo & ldap. I'm running on a
>     Gentoo
>     > system against OpenLDAP 2.3.30 and sudo-1.6.8_p12
>     >
>     > The issue is that every user attempting to user sudo results in the
>     > following in the logs:
>     >
>     > [sudo] nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
>     > ....
>     > [sudo] nss_ldap: could not search LDAP server - Server is unavailable
>     >
>     > However my server is there an available. Every other use of
>     nss_ldap is
>     > working on that box. When the user attempts to run sudo they get the
>     > following error:
>     >
>     > sudo: uid 5000 does not exist in the passwd file!
>     >
>     > However, running a simple "id" results in:
>     >
>     > uid=5000(doug) gid=100(users) groups=100(users),500(svnusers)
>     >
>     > Now Gentoo has sudo configure it's LDAP settings in
>     /etc/ldap.conf.sudo
>     > and I have the following configuration:
>     >
>     > uri ldap://gravel.internal.company.com
>     ldap://marble.internal.company.com
>     > ldap_version 3
>     > ssl start_tls
>     > tls_cacertdir /etc/ssl/certs/
>     > tls_checkpeer yes
>     > sudoers_debug 2
>     > sudoers_base ou=SUDOers,dc=company,dc=com
>     >
>     > I ran the sudoers2ldif file and imported it into
>     > ou=SUDOers,dc=company,dc=com. I also added an ACL to slapd that
>     allows *
>     > to read that ou.
>     >
>     > Running sudo --help as root provides the following:
>     >
>     > LDAP Config Summary
>     > ===================
>     > uri          ldap://gravel.internal.company.com
>     > ldap://marble.internal.company.com
>     > ldap_version 3
>     > sudoers_base ou=SUDOers,dc=company,dc=com
>     > binddn       (anonymous)
>     > bindpw       (anonymous)
>     > bind_timelimit  30
>     > timelimit    30
>     > ssl          start_tls
>     > ===================
>     > ldap_set_option(LDAP_OPT_X_TLS_CACERTDIR,"/etc/ssl/certs/")
>     > ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT,0x01)
>     > ldap_set_option(LDAP_OPT_TIMELIMIT,0x1e)
>     > setting bind_timelimit to 30
>     > ldap_initialize(ld,ldap://gravel.internal.company.com
>     > ldap://marble.internal.company.com)
>     > ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
>     > ldap_start_tls_s() ok
>     > ldap_bind() ok
>     > found:cn=defaults,ou=SUDOers,dc=company,dc=com
>     > ldap search
>     >
>     '(|(sudoUser=root)(sudoUser=%root)(sudoUser=%root)(sudoUser=%bin)(sudoUser=%daemon)(sudoUser=%sys)(sudoUser=%adm)(sudoUser=%disk)(sudoUser=%wheel)(sudoUser=%floppy)(sudoUser=%dialout)(sudoUser=%tape)(sudoUser=%video)(sudoUser=ALL))'
> 
>     > ldap search 'sudoUser=+*'
>     > user_matches=0
>     > host_matches=0
>     > sudo_ldap_check(0)=0x44
>     > usage: sudo -K | -L | -V | -h | -k | -l | -v
>     > usage: sudo [-HPSb] [-p prompt] [-u username|#uid]
>     >             { -e file [...] | -i | -s | <command> }
>     >
>     >
>     > So root appears to read the file and parse it properly, however
>     the normal
>     > users on the box do not provide any of that debugging info which
>     makes me
>     > believe it's not parsing the file at all.
>     >
>     > If anyone has any insight or any suggestions it'd be much
>     appreciated. The
>     > issue lives in Gentoo's bugzilla at
>     > http://bugs.gentoo.org/show_bug.cgi?id=107634
>     >
>     > --
>     > Doug Goldstein
>     >
> 
> 
>     Interestingly enough, these tests were performed on the box called
>     "gravel". Which is my master LDAP machine. I copied these configs
>     over to
>     "marble" and didn't change a thing. This machine is a syncrepl
>     consumer of
>     "gravel" with the same ACL configuration.
> 
>     Performing the same test, root and any user defined in /etc/passwd will
>     work without a hitch and pull the SUDOer config from LDAP. Users
>     that are
>     visible only through getent passwd (i.e. exist only in LDAP) will still
>     error out. However the resultant error is different. It's closer to
>     what's
>     expected.
> 
>     $ sudo --help
>     sudo: please use single character options
>     LDAP Config Summary
>     ===================
>     uri          ldap://gravel.internal.company.com
>     ldap://marble.internal.company.com
>     ldap_version 3
>     sudoers_base ou=SUDOers,dc=company,dc=com
>     binddn       (anonymous)
>     bindpw       (anonymous)
>     bind_timelimit  30
>     timelimit    30
>     ssl          start_tls
>     ===================
>     ldap_set_option(LDAP_OPT_X_TLS_CACERTDIR,"/etc/ssl/certs/")
>     ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT,0x01)
>     ldap_set_option(LDAP_OPT_TIMELIMIT,0x1e)
>     setting bind_timelimit to 30
>     ldap_initialize(ld,ldap://gravel.internal.company.com
>     ldap://marble.internal.company.com)
>     ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
>     ldap_start_tls_s(): -11: Connect error
>     usage: sudo -K | -L | -V | -h | -k | -l | -v
>     usage: sudo [-HPSb] [-p prompt] [-u username|#uid]
>                 { -e file [...] | -i | -s | <command> }
> 
>     Now it appears that for users that are looked up via NSS_LDAP that
>     TLS is
>     failing.. Looking at the slapd log I get the following..
> 
>     Mar  6 13:05:47 [slapd] >>> slap_listener(ldap://)
>     Mar  6 13:05:47 [slapd] daemon: listen=7, new connection on 43_
>     Mar  6 13:05:47 [slapd] daemon: added 43r (active) listener=(nil)_
>     Mar  6 13:05:47 [slapd] conn=550 fd=43 ACCEPT from
>     IP=192.168.1.25:58008 <http://192.168.1.25:58008>
>     (IP= 0.0.0.0:389 <http://0.0.0.0:389>)_
>     Mar  6 13:05:47 [slapd] daemon: epoll: listen=7 active_threads=0
>     tvp=zero_
>     Mar  6 13:05:47 [slapd] daemon: activity on 1 descriptor_
>     Mar  6 13:05:47 [slapd] daemon: activity on:
>     Mar  6 13:05:47 [slapd] 43r
>     Mar  6 13:05:47 [slapd] _
>     Mar  6 13:05:47 [slapd] daemon: read active on 43_
>     Mar  6 13:05:47 [slapd] connection_get(43)_
>     Mar  6 13:05:47 [slapd] connection_get(43): got connid=550_
>     Mar  6 13:05:47 [slapd] connection_read(43): checking for input on
>     id=550_
>     Mar  6 13:05:47 [slapd] ber_get_next on fd 43 failed errno=11 (Resource
>     temporarily unavailable)_
>     Mar  6 13:05:47 [slapd] daemon: epoll: listen=7 active_threads=0
>     tvp=zero_
>     Mar  6 13:05:47 [slapd] do_extended_
>     Mar  6 13:05:47 [slapd] do_extended: oid=1.3.6.1.4.1.1466.20037_
>     Mar  6 13:05:47 [slapd] conn=550 op=0 STARTTLS_
>     Mar  6 13:05:47 [slapd] send_ldap_extended: err=0 oid= len=0_
>     Mar  6 13:05:47 [slapd] send_ldap_response: msgid=1 tag=120 err=0_
>     Mar  6 13:05:47 [slapd] conn=550 op=0 RESULT oid= err=0 text=_
>     Mar  6 13:05:47 [slapd] daemon: activity on 1 descriptor_
>     Mar  6 13:05:47 [slapd] daemon: activity on:
>     Mar  6 13:05:47 [slapd] 43r
>     Mar  6 13:05:47 [slapd] _
>     Mar  6 13:05:47 [slapd] daemon: read active on 43_
>     Mar  6 13:05:47 [slapd] connection_get(43)_
>     Mar  6 13:05:47 [slapd] connection_get(43): got connid=550_
>     Mar  6 13:05:47 [slapd] connection_read(43): checking for input on
>     id=550_
>     Mar  6 13:05:47 [slapd] daemon: epoll: listen=7 active_threads=0
>     tvp=zero_
>     Mar  6 13:05:47 [slapd] daemon: activity on 1 descriptor_
>     Mar  6 13:05:47 [slapd] daemon: activity on:
>     Mar  6 13:05:47 [slapd] 43r
>     Mar  6 13:05:47 [slapd] _
>     Mar  6 13:05:47 [slapd] daemon: read active on 43_
>     Mar  6 13:05:47 [slapd] connection_get(43)_
>     Mar  6 13:05:47 [slapd] connection_get(43): got connid=550_
>     Mar  6 13:05:47 [slapd] connection_read(43): checking for input on
>     id=550_
>     Mar  6 13:05:47 [slapd] connection_read(43): TLS accept failure error=-1
>     id=550, closing_
>     Mar  6 13:05:47 [slapd] connection_closing: readying conn=550 sd=43 for
>     close_
>     Mar  6 13:05:47 [slapd] connection_close: conn=550 sd=-1_
>     Mar  6 13:05:47 [slapd] daemon: removing 43_
>     Mar  6 13:05:47 [slapd] conn=550 fd=43 closed (TLS negotiation failure)_
>     Mar  6 13:05:47 [slapd] daemon: epoll: listen=7 active_threads=0
>     tvp=zero_
>     Mar  6 13:05:47 [slapd] daemon: activity on 1 descriptor_
>     Mar  6 13:05:47 [slapd] daemon: activity on:
>     Mar  6 13:05:47 [slapd] _
>     Mar  6 13:05:47 [slapd] daemon: epoll: listen=7 active_threads=0
>     tvp=zero_
>     Mar  6 13:05:49 [slapd] daemon: activity on 1 descriptor_
>     Mar  6 13:05:49 [slapd] daemon: activity on:
>     Mar  6 13:05:49 [slapd] _
>     Mar  6 13:05:49 [slapd] >>> slap_listener(ldap://)
>     Mar  6 13:05:49 [slapd] daemon: listen=7, new connection on 43_
>     Mar  6 13:05:49 [slapd] daemon: added 43r (active) listener=(nil)_
>     Mar  6 13:05:49 [slapd] conn=551 fd=43 ACCEPT from
>     IP=192.168.1.25:58010 <http://192.168.1.25:58010>
>     (IP=0.0.0.0:389 <http://0.0.0.0:389>)_
>     Mar  6 13:05:49 [slapd] daemon: epoll: listen=7 active_threads=0
>     tvp=zero_
>     Mar  6 13:05:49 [slapd] daemon: activity on 1 descriptor_
>     Mar  6 13:05:49 [slapd] daemon: activity on:
>     Mar  6 13:05:49 [slapd] 43r
>     Mar  6 13:05:49 [slapd] _
>     Mar  6 13:05:49 [slapd] daemon: read active on 43_
>     Mar  6 13:05:49 [slapd] connection_get(43)_
>     Mar  6 13:05:49 [slapd] connection_get(43): got connid=551_
>     Mar  6 13:05:49 [slapd] connection_read(43): checking for input on
>     id=551_
>     Mar  6 13:05:49 [slapd] ber_get_next on fd 43 failed errno=11 (Resource
>     temporarily unavailable)_
>     Mar  6 13:05:49 [slapd] daemon: epoll: listen=7 active_threads=0
>     tvp=zero_
>     Mar  6 13:05:49 [slapd] do_extended_
>     Mar  6 13:05:49 [slapd] do_extended: oid=1.3.6.1.4.1.1466.20037_
>     Mar  6 13:05:49 [slapd] conn=551 op=0 STARTTLS_
>     Mar  6 13:05:49 [slapd] send_ldap_extended: err=0 oid= len=0_
>     Mar  6 13:05:49 [slapd] send_ldap_response: msgid=1 tag=120 err=0_
>     Mar  6 13:05:49 [slapd] conn=551 op=0 RESULT oid= err=0 text=_
>     Mar  6 13:05:49 [slapd] daemon: activity on 1 descriptor_
>     Mar  6 13:05:49 [slapd] daemon: activity on:
>     Mar  6 13:05:49 [slapd] 43r
>     Mar  6 13:05:49 [slapd] _
>     Mar  6 13:05:49 [slapd] daemon: read active on 43_
>     Mar  6 13:05:49 [slapd] connection_get(43)_
>     Mar  6 13:05:49 [slapd] connection_get(43): got connid=551_
>     Mar  6 13:05:49 [slapd] connection_read(43): checking for input on
>     id=551_
>     Mar  6 13:05:49 [slapd] daemon: epoll: listen=7 active_threads=0
>     tvp=zero_
>     Mar  6 13:05:49 [slapd] daemon: activity on 1 descriptor_
>     Mar  6 13:05:49 [slapd] daemon: activity on:
>     Mar  6 13:05:49 [slapd] 43r
>     Mar  6 13:05:49 [slapd] _
>     Mar  6 13:05:49 [slapd] daemon: read active on 43_
>     Mar  6 13:05:49 [slapd] connection_get(43)_
>     Mar  6 13:05:49 [slapd] connection_get(43): got connid=551_
>     Mar  6 13:05:49 [slapd] connection_read(43): checking for input on
>     id=551_
>     Mar  6 13:05:49 [slapd] connection_read(43): TLS accept failure error=-1
>     id=551, closing_
>     Mar  6 13:05:49 [slapd] connection_closing: readying conn=551 sd=43 for
>     close_
>     Mar  6 13:05:49 [slapd] connection_close: conn=551 sd=-1_
>     Mar  6 13:05:49 [slapd] daemon: removing 43_
>     Mar  6 13:05:49 [slapd] conn=551 fd=43 closed (TLS negotiation failure)_
>     Mar  6 13:05:49 [slapd] daemon: epoll: listen=7 active_threads=0
>     tvp=zero_
>     Mar  6 13:05:49 [slapd] daemon: activity on 1 descriptor_
>     Mar  6 13:05:49 [slapd] daemon: activity on:
> 
> 
>     So TLS negotiation is failing for users that are looked up via
>     nss_ldap..
>     Which seems like it's banging heads with nss_ldap and/or pam_ldap when
>     sudo attempts to establish a TLS connection.
> 
>     Any ideas at all would be helpful.
> 
>     ____________________________________________________________
>     sudo-users mailing list < sudo-users at sudo.ws
>     <mailto:sudo-users at sudo.ws>>
>     For list information, options, or to unsubscribe, visit:
>     http://www.sudo.ws/mailman/listinfo/sudo-users
> 
> 


--
Doug Goldstein <cardoe at gentoo.org>
http://dev.gentoo.org/~cardoe/




More information about the sudo-users mailing list