[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