Hi Kurt,
On Mon, Aug 06, 2007 at 12:55:11PM -0700, Kurt Zeilenga wrote:
>2) you could try to rework the overlay to avoid any specific
reference
>to Active Directory, since your cache should apply to any remote
>system
>implementing Kerberos V. It could be abstracted even more, to act
>as a
>replacement of saslauthd, by allowing it to auth via LDAP, pam and
>more,
>not just Kerberos.
s/to act as a replacement/to defer external authentication to saslauthd
or the like/
In slapd(8), we deferred verification against external password
stores to saslauthd
via the {SASL} userPassword mechanism, thus avoiding needing to
implement
and support each possible external password store (such as a KDC).
This module
should likewise avoid supporting (some subset of) external passwords
stores.
saslauthd(8) can easily be extended (or replaced) to support additional
password stores as needed. As provided in Cyrus SASL today, it
supports both
LDAP and Kerberos as external password stores.
I don't see the benefit of delegating the password cache mechanism to
saslauthd or a possible replacement. Wouldn't I have to implement each
possible password store anyway?
If I understand it correct, the {SASL} userPassword mechanism delegates
authentication to saslauthd.
saslauthd can easily authenticate against Kerberos and AD and it is
possible let it cache the password for its own authentication purposes.
If I want the sambaNTPassword attribute to be available (to be able to
run samba as a NT4 PDC independent of AD ) or if I want to have the
password additionally cached as MIT Kerberos credential, I would need
to implement both individually one way or another.
So why not going the short way and let the overlay module do this?
Regards,
Sebastian