[sudo-users] sudo & LDAP
Doug Goldstein
cardoe at gentoo.org
Tue Mar 6 13:07:31 EST 2007
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
(IP=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
(IP=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.
More information about the sudo-users
mailing list