Re: LDAP and TLS certificates

"Todd C. Miller" <[email protected]>
Newsgroups gmane.comp.tools.sudo.user
Message-ID <[email protected]>
On Tue, 25 Sep 2018 11:15:06 -0400, "David Magda" wrote:

> On my Debian 8 ("jessie") system, I had the following in
> /etc/sudo-ldap.conf (which is a link to /etc/ldap/ldap.conf):
>
> 	TLS_CACERT	/etc/ssl/certs/ca-certificates.crt
> 	TLS_REQCERT	never
> 	URI		ldap://some.IP/
>
> I then changed the "ldap://" to "ldaps://" and got the following output
> (debug level 2):
>
> 	sudo: ldap_sasl_bind_s(): Can't contact LDAP server

ldaps:// will connect to port 636 which your ldap server may not
be configured to use.

> I tried going back to "ldap://" and using
>
> 	SSL start_tls
>
> and got:
>
> 	sudo: ldap_start_tls_s(): Connect error
>
> After some fiddling, I added:
>
> 	TLS_CHECKPEER	no
>
> and things worked.
>
> So sudoers.ldap(8) [1] mentions TLS_CHECKPEER, but ldap.conf(5) [2]
> mentions TLS_REQCERT; the OpenLDAP folks make no mention of the CHECKPEER
> [3]. It is a bit confusing given that CHECKPEER seems to be a sudo-ism,
> but since "SUDO" is not in the name, it gives the impression that it is an
> "universal" option. Ditto for the "SSL", also a sudo-ism. Can a note be
> added to each option in the manual page noting it as such?

The sudo ldap.conf settings are similar to those used by nss_ldap
and pam_ldap.  Unfortunately, different LDAP libraries use different
configuration setting names so these don't always match.

> In general, can sudo(8) check for the presence of "TLS_REQCERT", and if
> its value is "never" or "allow", act as if "TLS_CHECKPEER" is "no"? (The
> other options are "try" and "demand | hard"; see [2].)

Yes, sudo should be able to support that.  I'll add it to the list
for 1.8.27.

 - todd
____________________________________________________________
sudo-users mailing list <[email protected]>
For list information, options, or to unsubscribe, visit:
https://www.sudo.ws/mailman/listinfo/sudo-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.