[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Contribution: Active Directory Password Cache (ITS#5042)
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