[sudo-users] sudo & LDAP
Doug Goldstein
cardoe at gentoo.org
Wed Mar 7 18:30:34 EST 2007
Galen Johnson wrote:
> I was under the impression that the sudo ldap module didn't support ldaps.
It supports TLS but not 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/
>
>
--
Doug Goldstein <cardoe at gentoo.org>
http://dev.gentoo.org/~cardoe/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: </pipermail/sudo-users/attachments/20070307/9988a4f5/attachment.bin>
More information about the sudo-users
mailing list