[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