Newbie Questions Re Use of SASL with LDAPv3

[Howard Chu]

Geiman Gilbert-GGEIMAN1 wrote:
> Howard,
> 
> Thanks for the responses!  See below for followups.
> 
> gil 

> 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.
> Correct?  

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
>> with:
>>
>> 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?

Correct.
> 
> 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 
versions...)

> 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/