[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapsearch and sasl

I think this topic is drifting into a General discussion. But rather than lose the context I'll answer a bit more here.

James Wilde wrote:

The primary purpose of SASL is to perform authentication. Encryption is an optional feature, and is only supported by a subset of SASL mechanisms.



The water gets even murkier.  I have been labouring under the delusion
that it is ldap which does the authentication.  That is, one sends a
query from the client machine to the ldap server saying does this person
exist with this password (and, secondarily, does she have authorisation
to log in to this client)?

Or is the authentication we are talking about here that the client is
authorised to send such a query to the ldap server?

Or, yet another alternative, does the nss_ldap/pam_ldap/sasl combination
on the client convert the ldap query to a sasl query which is sent to
sasl on the server, which in turn asks the ldap server?  If so, it seems
a long way round.

Sometimes it is a long way 'round; generally that means you're configuration is bad. But unless you keep a very clear idea of what entities are authenticating and how, it's easy to get lost in the murk.

When an LDAP client issues an LDAP Bind request to an LDAP server, the LDAP server does whatever is necessary to evaluate that authentication request. There's more than one Method for LDAP Bind. The most common used today are Simple Bind and SASL Bind. For a Simple Bind, the client provides a DN and a plaintext password; the LDAP server typically looks up the entry corresponding to the DN and does some crunching to compare the provided password with whatever authentication key is stored in the entry.

For a SASL Bind, the LDAP client generally sends a SASL mechanism name, a username, and some type of credential which may be a password but more often is something else. The LDAP server receives these items and calls the SASL library to evaluate them. The SASL library will return success or failure, and so the LDAP server will accept or reject the authentication attempt.

Note that SASL is not a network protocol in itself. There is no SASL Query, there is no "SASL on the server" to send to. There are SASL messages which are carried in some other protocol's data stream - e.g., SMTP, LDAP, IMAP, etc...

Generally pam_ldap and nss_ldap are just LDAP clients. pam_ldap tries to authenticate a user to a Unix system by performing an LDAP Bind request. If the Bind succeeds in authenticating the user to the LDAP server, then PAM considers the user successfully authenticated to the Unix machine. Whether SASL is involved or not just depends on whether the pam_ldap module is configured to do a SASL Bind or not.

That's the very general, basic overview. For OpenLDAP there are a number of twists:

OpenLDAP generally evaluates Simple Binds using the userPassword attribute in a user's Entry. Originally the userPassword attribute was just a plaintext string, but with RFC2307 came the notion of "password mechanisms" to specify other kinds of non-plaintext passwords. E.g., a value "{CRYPT}abcdefghijklm" would take the password provided in the Bind request, crunch it using Unix crypt, and compare the result to "abcdefghijklm" to validate the password. One of the mechanisms that can be supported is "{SASL}<username>" which actually means: hand the password off to the SASL library to check if it matches the SASL user <username>. So this provides a method to use your SASL user database to satisfy Simple Bind requests even though they come in with a DN and not a username.

From the opposite direction, OpenLDAP slapd includes an internal SASL plugin which the SASL library can invoke instead of using its regular database (sasldb2) to retrieve user and password information. This means you can use your LDAP user database to satisfy SASL Bind requests even though they come in with a simple Username and not a DN. OpenLDAP also includes another SASL plugin that other SASL-enabled servers can invoke for the same purpose. (This module is called ldapdb; it has recently been adopted by the Cyrus SASL project so it will no longer be part of the OpenLDAP distribution.) For password-based SASL mechanisms (like DIGEST-MD5), I consider this the preferred way to use SASL with OpenLDAP. For distributed authentication systems like Kerberos, it's not really an issue.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support