On 4/2/2013 12:23 PM, Stephen Gallagher wrote:
On Tue 02 Apr 2013 02:40:45 PM EDT, Wes Modes wrote:
>> See options ldap_tls_cacert, ldap_tls_cacertdir etc in man
>> sssd-ldap.

> Oh no, that's bad news for me, as I never could get TLS working on
> my OpenLDAP server!


Based on the error you're seeing there, it sounds like TLS *is*
working, but you don't have a proper trust relationship. Most likely,
this means the server certificate is self-signed. There are two ways
to solve this: the correct way and the easy way.

I've wanted my ldap server to use TLS since I set it up, but struggled with getting it to work (and maybe also understanding just how it did work).

First I tried the easy way and was excited to find that I was able to connect to ssh with an LDAP user.  Woot.

The correct way:
Get a copy of the public key for the self-signed server certificate
and drop it on the client machine(s) then point the ldap_cacert at the
file.

Next I tried the correct way.  I'm interpretting that to mean:  Get a copy of the public key for the self-signed cert on the LDAP server and put it on the server running sssd, then point ldap_cacert in sssd.conf to that cert, right?

Previously I was using an IPSCA-signed cert for *.mydomain.com.  But just to simplify things and since I don't completely understand how ssl/tls uses certs, I went back to the cert that was installed with OpenLDAP (/etc/ssl/openldap2.4/ldap.pem) and copied it over to the sssd server restarting both services.  After that I was able to connect.

Great. Now I can use ssh to disallow login and restrict LDAP users to sftp.

Thank you for the help.


The easy way:
Set the option 'ldap_tls_reqcert = allow' in the domain section of
sssd.conf. This will tell SSSD to blindly accept the certificate and
use it for encryption. This will provide you with encryption
protecting your authentications, but unlike the correct way it will
leave you open to a man-in-the-middle attack (if someone managed to
get you to connect to a different LDAP server, the client would
blindly trust it and send the password along.


The reason we do not allow non-TLS/SSL connections for authentication
is because the LDAP protocol requires that the passwords are sent in
plaintext within the protocol message, making it absolutely trivial to
steal passwords with a simple network sniffer like tcpdump or
wireshark/ethereal.

I'd suggest trying out the easy way above first so you can finish
testing out SSSD, then go back and implement the correct way once
you're comfortable with the rest of the system.

--
Wes Modes
Systems Designer, Developer, and Administrator
University Library ITS
University of California, Santa Cruz