Howard, Thanks for the responses! See below for followups. gil -----Original Message----- From: Howard Chu [mailto:hyc@xxxxxxxxxxxxxxx] Sent: Wednesday, June 07, 2006 4:23 PM To: Geiman Gilbert-GGEIMAN1 Cc: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx 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/
