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:
* What can SASL be used for besides Kerberos integration?
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).
* The RHDS documentation says that TLS can be used as an
authentication mechanism, but doesn't provide much details.
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).
* How can I check if SASL is enabled on my LDAP server (RHDS)?
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).