Newbie Questions Re Use of SASL with LDAPv3

Wed Jun 7 19:47:56 EDT 2006

Howard,

Thanks for the responses!  See below for followups.

gil 

-----Original Message-----
From: Howard Chu [mailto:hyc at highlandsun.com] 
Sent: Wednesday, June 07, 2006 4:23 PM
To: Geiman Gilbert-GGEIMAN1
Cc: cyrus-sasl at lists.andrew.cmu.edu
Subject: Re: Newbie Questions Re Use of SASL with LDAPv3

Geiman Gilbert-GGEIMAN1 wrote:
> I have no previous experience with LDAP, SASL, or PAM, but I have read

> a whole lot of material from the net about each of these and still 
> have some confusion.  (I need to quickly create software requirements 
> for a system to start using these....)  I have a Linux-based system
that 
> needs to start authenticating user logins via LDAP.  There are two 
> types of logins that need to be supported:  (1) the Linux login 
> itself, and (2) a login from a proprietary application suite that runs

> in the Linux environment.  The plan is to use PAM for the Linux-level 
> logins, and to use an LDAP API to do the application-level logins 
> (using the bind operation).  I need to support two authentication 
> mechanisms for each type of login:  (1) the "simple" LDAP 
> authentication mechanism (i.e., password sent in the clear), and (2) 
> DIGEST-MD5 using SASL.  The user account information in the LDAP 
> server will be stored in a "posixAccount" entry.

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?  

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? 

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

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)?

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?

> 
> 2) How should the PAM configuration be set up to allow both LDAP 
> simple and DIGEST-MD5 authentication to be used?

pam_ldap only uses one type of Bind. There is no reason to configure
pam_ldap to support both at once.
> 
> 3) Does RFC 3112 have any impact on these scenarios?  What is the 
> intent of this RFC relative to how SASL authentication works?

I know of no LDAP servers that implement this RFC. I would say it has no
impact today.
> 
> 4) I see LOTS of posts on various mailing lists talking about problems

> getting PAM to work with SASL and LDAP.  In general, can all 3 
> mechanisms be made to play nicely together to support both simple and 
> DIGEST authentication for Linux logins and logins from application 
> programs?  Or are there known limitations/problems with this type of 
> combination?

Again, the requirement to support both Simple and SASL binds in pam_ldap
makes no sense. Just configure pam_ldap to use SASL and forget about
Simple binds.

> 5) I have found a lot of material (HowTo's, etc.) that talk about each

> of these 3 technologies individually (LDAP, SASL, and PAM), but 
> nothing that actually describes how these would be used in 
> combination.  Is there a good reference someone knows about that would

> discuss how to integrate these 3 things to work together?

The intersection of these three topics is very tiny. pam_ldap uses
libldap. If libldap was built with SASL support, pam_ldap can be
configured to use it, end of story. Since pam_ldap is just an LDAP
client, there's very little to do here.

On the server side, setting up LDAP with SASL may be slightly more
involved, but PAM is not part of the picture at all. On the OpenLDAP
side, you just need to add appropriate authz-regexp's in slapd.conf to
map SASL user IDs to LDAP DNs. If you're storing SASL secrets in LDAP
and using other SASL-enabled servers, you will also need to configure
them to use the ldapdb auxprop. Both of these are simple steps, already
covered in the respective packages' documentation.

> Thanks,
> gil

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