Newbie Questions Re Use of SASL with LDAPv3
hyc at highlandsun.com
Wed Jun 7 20:12:51 EDT 2006
Geiman Gilbert-GGEIMAN1 wrote:
> Thanks for the responses! See below for followups.
> First question: Why do you need to support both Simple and SASL Binds?
> [Gil] One of the customer requirements is to use "normal" (i.e.,
> UNIX-like) plaintext password authentication via LDAP. This is because
> not all LDAP servers that the system will have to connect to will
> support SASL. However, I also want to provide the option for a more
> secure scheme, which is where DIGEST comes in. And it seems as though
> SASL is the best way to support that. If PAM is going to be used for
> the Linux-level logins, then based on what you say below it sounds like
> only one of these two methods can be supported for those logins.
Yes, you configure pam_ldap to use one or the other.
> Then at the application level, as long as the LDAP API supports both
> simple and SASL, I'm assuming I can query the LDAP server for the
> "supportedSASLMechanisms" to determine if DIGEST (or any SASL options)
> are supported, and make a decision as to which type of authentication to
> use based on the response to that query. Do you see any problems with
> this approach?
That is the generally recommended approach, but it misses an essential
consideration: what is the actual need for secrecy on the transaction?
The point of using SASL/DIGEST-MD5 is to prevent plaintext credentials
from being exposed on the wire. When faced with a server that only
supports Simple Binds over cleartext connections, sometimes the correct
decision is not to talk to that server at all.
>> The current plan is to use OpenLDAP and either Cyrus or GNU SASL. A
>> PAM vendor has not been chosen yet, but I'm looking at PADL.
>> Having read as much as I can digest on each of these mechanisms, I
>> still have the following questions I'm hoping someone on this list can
>> help me
>> 1) What form should the "userPassword" attribute in the "posixAccount"
>> entry be stored in? Plain text? Will the SASL functionality at the
>> LDAP server do the MD5 hash when DIGEST is used? Are 2 "userPassword"
>> attributes required?
> Your question seems to assume that SASL will use LDAP for its password
> store. That's probably a smart thing to do, but it is not the default
> behavior for SASL. But yes, if you're going to configure SASL to
> retrieve its secrets from LDAP, then you must configure LDAP to store
> userPassword's in plain text.
> [Gil] I assume nothing needs to be done differently on the client side
> of things regardless of whether LDAP is used to store the authentication
> secret or another database is used. Is this a correct assumption?
> I also assume when you say "you must configure LDAP to store
> userPasswords in plain text", that such configuration would be a
> standard function of any SASL-aware LDAP server. In other words, is it
> safe to assume that any LDAP server that advertises itself as SASL-aware
> would support the ability to do this type of configuration (without any
> form of proprietary enhancements)?
It is never safe to assume anything about arbitrary LDAP servers, you'll
have to read their respective documentation. Generally you may assume
that Cyrus-SASL and OpenLDAP play well together since a number of people
are active on both projects. (As long as you're using recent enough
> If the LDAP server needs to store the DIGEST secrets in a separate
> database but still use the "userPassword" attribute in the posixAccount
> entry for the simple bind, will this present any problems? Again, does
> this imply that anything needs to be done differently on the client
> side, or will the server's implementation strategy along these lines be
> transparent to the client?
In the case of OpenLDAP there is no problem here. I can't say anything
about how other servers handle it. But it's an internal server
implementation detail, it should not be visible from the client.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
More information about the Cyrus-sasl