<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
On 4/2/2013 12:23 PM, Stephen Gallagher wrote:<br>
<blockquote type="cite">On Tue 02 Apr 2013 02:40:45 PM EDT, Wes
Modes wrote:<br>
>> See options ldap_tls_cacert, ldap_tls_cacertdir etc in
man<br>
>> sssd-ldap.<br>
<br>
> Oh no, that's bad news for me, as I never could get TLS
working on<br>
> my OpenLDAP server!<br>
<br>
<br>
Based on the error you're seeing there, it sounds like TLS *is*<br>
working, but you don't have a proper trust relationship. Most
likely,<br>
this means the server certificate is self-signed. There are two
ways<br>
to solve this: the correct way and the easy way.<br>
</blockquote>
<br>
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).<br>
<br>
First I tried the easy way and was excited to find that I was able
to connect to ssh with an LDAP user. Woot.<br>
<blockquote type="cite"><br>
The correct way:<br>
Get a copy of the public key for the self-signed server
certificate<br>
and drop it on the client machine(s) then point the ldap_cacert at
the<br>
file.<br>
</blockquote>
<br>
Next I tried the correct way. I'm interpretting that to mean: Get
a copy of the public key for the self-signed cert <i>on the LDAP
server</i> and put it on the server running sssd, then point
ldap_cacert in sssd.conf to that cert, right?<br>
<br>
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.<br>
<br>
Great. Now I can use ssh to disallow login and restrict LDAP users
to sftp.<br>
<br>
Thank you for the help.<br>
<br>
<blockquote type="cite"><br>
The easy way:<br>
Set the option 'ldap_tls_reqcert = allow' in the domain section of<br>
sssd.conf. This will tell SSSD to blindly accept the certificate
and<br>
use it for encryption. This will provide you with encryption<br>
protecting your authentications, but unlike the correct way it
will<br>
leave you open to a man-in-the-middle attack (if someone managed
to<br>
get you to connect to a different LDAP server, the client would<br>
blindly trust it and send the password along.<br>
<br>
<br>
The reason we do not allow non-TLS/SSL connections for
authentication<br>
is because the LDAP protocol requires that the passwords are sent
in<br>
plaintext within the protocol message, making it absolutely
trivial to<br>
steal passwords with a simple network sniffer like tcpdump or<br>
wireshark/ethereal.<br>
<br>
I'd suggest trying out the easy way above first so you can finish<br>
testing out SSSD, then go back and implement the correct way once<br>
you're comfortable with the rest of the system.<br>
</blockquote>
<br>
-- <br>
Wes Modes<br>
Systems Designer, Developer, and Administrator<br>
University Library ITS<br>
University of California, Santa Cruz<br>
<br>
</body>
</html>