openldap-client vs openldap-sasl-client

[Jan Bramkamp]

On 05/01/2017 11: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 is a authentication API. It allows an application to reuse the 
tested SASL protocol and code. SASL differs from PAM in that it allows 
its authentication mechanisms more possibilities as required to deal 
with X.509 client certificates and Kerberos tickets. Without SASL 
OpenLDAP is limited to password based authentication against passwords 
stored inside the LDAP database as plaintext or salted MD5/SHA1 hashes. 
With SASL you can the supported SASL mechanisms:

* SASL external: Let the transport layer provide authentication. TLS 
protected connections can reuse the client certificate common name and 
map it to a LDAP object. Local connections over UNIX domain sockets can 
use the effective client user and primary group id to search for a 
matching user object inside the LDAP database.

* SASL GSSAPI: Use Kerberos to authenticate against the LDAP service. 
Works great for interactive use if you already have Kerberos deployed. 
Can be used to centralize password storage in the Kerberos KDCs instead 
of the LDAP service while still supporting LDAP simple binds.

In theory you could use a bunch of additional SASL mechs but these are 
the two I have encountered in everyday use.