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/
