[Date Prev][Date Next]
RE: more authentication questions..
Yes, my general idea was to use DIGEST-MD5 (for obvious security reasons) to log users into LDAP using the password that is stored within the directory.
It appears as if they only way I could do this would be to write a pwcheckd on my local machine that logs into the LDAP server, and returns userPassword to SASL, who then authenticates and authorizes the user. Although the cyrus docs and your fourth paragraph both seem to indicate that DIGEST-MD5 can only work from SASLdb. (Why this is I'm not certain, it seems as if the realm is the only magical part of a digest-auth)
Is this correct, or is there something I am missing? Please point me toward any documentation I might be overlooking.
I currently have 2.0.7 compiled and running with cyrus-sasl 1.5.24 (and openssl 0.9.6 thrown in as well). I've read up on digest auth (both the SASL rfc, and the original HTTP rfc), and I'm convinced it is the only way to do secure-enough authenticaion without resorting to SSL.
Thank you for your time.
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, January 09, 2001 6:27 PM
To: Jeff Costlow
Subject: Re: more authentication questions..
LDAP "simple" authentication uses userPassword values stored in
the directory. There are numerous schemes supported, including
ones which refer the server to external authentication services
(UNIX, Kerberos, SASL).
SASL authentication provides a variety of mechanisms. Some
mechanisms require external authentication services (e.g.
Kerberos), others require access to mechanism specific secrets
(e.g. DIGEST-MD5), and others (PLAIN, LOGIN) only require a
method to verify the asserted password is correct. In the
latter case, Cyrus SASL can be configured to use external
authentication services such as UNIX, Kerberos, and SASLdb.
Cyrus SASL can also be configured to verify asserted passwords
via a password check daemon. Though (IIRC) the original pwcheckd
was designed to verify against UNIX shadow passwords, one can
(and folks have) write a pwcheckd that verifies against external
services such as SQL databases and LDAP directories.
I note that an LDAP-aware pwcheckd would only make sense where
you used LDAP as your authentication service and wanted non-LDAP
services to authenticate against LDAP via SASL/PLAIN. However,
such a configuration has significant security drawbacks.
If you want to use DIGEST-MD5, you currently need to use
the Cyrus SASLdb for secret storage. This allows multiple
services hosted on the same machine to share DIGEST-MD5
secrets, but does not address sharing of secrets between
services hosted on multiple systems. We're working with
Cyrus folks to address this issue.
If you want a common, distributed, secure authentication service,
I recommend Kerberos V (MIT or Heimdal) and use of GSSAPI [which
LDAP supports via SASL/GSSAPI].
At 05:41 PM 1/9/01 -0800, Jeff Costlow wrote:
>I have read some of the threads about authentication, particularly this one form september 2000:
>http://www.openldap.org/lists/openldap-software/200009/msg00180.html called "SASL docs?"
>If I understand correctly, I currently have to maintain my password list twice -- once in the SASL db, and once in the LDAP db.
>So if the above is true, has someone come up with a method so that when a user updates his password in LDAP, the password gets updated in SASL? Or is that a 2.1 feature?
If using SASLdb storage, update via saslpasswd.
If using LDAP storage, update via ldappasswd.
I recommend using SASLdb over LDAP storage as it supports DIGEST-MD5.
>And as long as I am asking questions, is anyone currently working on doing a complete dump to a replicated server rather than transferring db files (which doesn't work so well when your linux box uses gdbm, and your bsd box uses dbm, etc...)
slapcat / slapadd