Bug 612780 - Support for non-encrypted LDAP authentication
Support for non-encrypted LDAP authentication
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Stephen Gallagher
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-07-08 21:43 EDT by Robert Barnett
Modified: 2010-07-09 07:01 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-07-09 06:56:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robert Barnett 2010-07-08 21:43:14 EDT
I am attempting to centralise authentication for a small number of computers. Fedora 13 requests that either LDAPS or LDAP/TLS must be used. This means that a signed certificate must be used and the domain name for the LDAP server must resolve. This is not practical on a network where the user may prefer to avoid the resolvable DNS host names. 

Why is encryption forced for LDAP whilst NIS is still supported?
Comment 1 Stephen Gallagher 2010-07-09 06:56:13 EDT
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.
Comment 2 Stephen Gallagher 2010-07-09 07:01:13 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.