[Date Prev][Date Next]
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