Kenneth Holter wrote:
We're going for the TLS based solution. However, I'd like a better understanding of SASL, so let me post these questions:
SASL is a pluggable authentication framework, so it is a bit abstract when you read about it.
In theory you can use SASL to support any authentication mechanism you can think of
(smart cards, fingerprint scanners, etc etc). In practice, in the context of LDAP it is typically
used for Kerberos or as Rich pointed out one of the challenge-response authentication
mechanisms that prevent plaintext password exposure, such as Digest-MD5. To be honest
I'm not sure how much of either of these is widely deployed. I only ever see SSL/TLS
in the wild, outside of hard core Kerberos shops.

SASL was originally developed to allow
pluggable authentication to be added to protocols that had either no authentication at all,
or very weak support for authentication (IMAP and SMTP for example). In the
context of LDAP its value is less clear because LDAP already had well developed
support for SSL and cert-based auth, that for the most part removes the need for SASL.
In addition, since the LDAP server is generally itself the authoritative authentication
service, the pluggable SASL server mechanisms really don't make sense most of
the time (because the LDAP server doesn't want or need to ask any other entity
to take its authentication decisions for it).
There are two different ways to use TLS to facilitate authentication :
1) Use plain text passwords but with TLS protecting the traffic from eavesdropping, and providing
a way for clients to trust servers. This is what is used 99% of the time.
2) Cert-based authentication (similar to SSH keys if you've used that) where the DS authenticates
the client based on crypto, derived from the client being in possession of a suitable certificate.
This is used mostly in high security environments (with hardware tokens for example).
There's a way to get the list of supported SASL mechanisms from the rootDSE.
Another way is to attempt a SASL BIND operation with a client and see if it succeeds.
I can dig out the details on these later if you can't track them down with Google, if
I have some spare time...

>From memory, the server always has the EXTERNAL (SSL) and digest mechanisms enabled.
Kerberos will be enabled if the machine is suitably configured (has Kerberos installed, configured
correctly, rubber chicken held above the console while chanting prayers to the security gods, etc).