<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Kenneth Holter wrote: <blockquote cite="mid:c25f25140805130727p20901700tbc0128bfbabd696a@mail.gmail.com" type="cite"> <div>We're going for the TLS based solution. However, I'd like a better understanding of SASL, so let me post these questions:</div> <ul> <li>What can SASL be used for besides Kerberos integration? </li> </ul> </blockquote> 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). <blockquote cite="mid:c25f25140805130727p20901700tbc0128bfbabd696a@mail.gmail.com" type="cite"> <ul> <li>The RHDS documentation says that TLS can be used as an authentication mechanism, but doesn't provide much details.</li> </ul> </blockquote> 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). <blockquote cite="mid:c25f25140805130727p20901700tbc0128bfbabd696a@mail.gmail.com" type="cite"> <ul> <li>How can I check if SASL is enabled on my LDAP server (RHDS)?</li> </ul> </blockquote> 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). </body> </html>