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