Encryption is forced for LDAP authentication because without it, any user's password can be trivially discovered through the use of network packet sniffing (such as with wireshark). It is incredibly insecure, and what we are doing is helping you to protect you from yourself.

There are ways that you can set up authentication with LDAP using self-signed certificates. The easiest way to do so is to simply set up the self-signed certificate on the LDAP server and then configure your clients with the option 'ldap_tls_reqcert = never' in your [domain/<domainname>] second of the /etc/sssd/sssd.conf

Setting ldap_tls_reqcert to 'never' means that the SSSD should blindly accept the server certificate for authentication (and identity, if you also set ldap_id_use_start_tls = true or are using an LDAPS URI), even if it is expired or the hostname doesn't match, etc. This will gain you an encrypted tunnel for the authentication and protect your passwords, without the necessity of buying a signed certificate or configuring DNS.


As for the availability of NIS, SSSD has no control over that at this time. However, when we do start supporting a NIS backend, I guarantee you that we will NOT be supporting the shadow map. If you want to authenticate against NIS with SSSD, we will force you to do so through some safe mechanism like Kerberos.

Also, just for one additional comment:

NIS passwords in the shadow map are at least hashed, so that if you have them enabled, it still requires a dictionary attack to actually determine what that password is (not that this is terribly difficult these days).

LDAP authentication sends the password cleartext over the wire, so if you aren't using an encrypted tunnel, it's trivially easy to read. No dictionary attack or brute-force required.