On 05/01/2017 12:04, Matthew Seaman wrote:
On 01/05/17 10:43, Kurt Jaeger wrote:
Hi!
[openldap-client vs openldap-sasl-client and libreoffice etc]
Yes and yes it sucks. The "solution" is to build your own repo and set
the right flags to always use the same LDAP client port. With binary
packages and the speed of modern x86_64 systems I for one no longer see
removing SASL support from OpenLDAP as useful enough to justify the
complexity.
The other question is: What's the use of SASL anyway ? I've seen it
for years in mailserver setups, etc, and it always caused trouble.
SASL effectively gets you a number of new authentication mechanisms.
Most of these are ways of proving you know a secret without sending the
actual secret (ie. password) over the net in plain text, but I think it
also adds the ability to use client TLS certificates for authentication.
IIRC.
I don't see much value in the extra mechanisms for secure login over
unencrypted links nowadays. Pretty much everything I'm using currently
already requires TLS for good security reasons, so there's no real
downside to using plain LOGIN over the encrypted channel. Plus the
'proof of knowledge' authentication mechanisms have a big downside: they
need the secret stored in the LDAP database in plain text, or in some
locally reversible encryption. With LOGIN over TLS, I can use salted
password hashes in much the same way as Unix passwords.
SASL would be worth it for TLS client certificate functionality, if
that's the only way to enable that.
SASL external is required by OpenLDAP to extract authentication data
from TLS client certificates and not all SASL mechs require plaintext
passwords inside the database to avoid leaking the credentials over the
wire e.g. SASL SCRAM (RFC 5802). You can also use SASL to authenticate
against PAM.
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
