s.hetze(a)linux-ag.de 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. > >Actually, the software was built and tested agains MIT and Heimdal >Kerberos V in the first place, so there is no dependency on AD >whatsoever. The reference to AD is more a marketing issue. I assume >more users looking for an AD password cache than for an Kerberos V >password cache. So I would perfer to keep it. I understand this, and I think it's just fine to advertise it like that, but in the code I'd prefer to avoid, for example, naming all variables after "ad" something. Perhaps s/adpwc/extpwc/ would be a little bit better?

>>3) you should add a (configurable) TTL, so that the cache could >>eventually be notified of an account lockout at the remote server's side. > >I tried to avoid introduction of new attributes for the module. Do you >have any suggestions how this TTL should be stored? Adding pwdPolicy >from ppolicy seems a bit like an overkill to me. Well, that could be a parameter that is provided through the configuration (caching TTL, optional negative caching TTL, and so). It doesn't need to be stored in the entry, or in a subentry, since dynamic configuration would allow to modify it run-time anyway.

>>4) you should add support for dynamic configuration, so that the module >>can fit into the new configuration paradigm for possible release with 2.4. > >I'll look into that. If you need help, please holler. However, I see that for such a simple (from a configuration point of view) module, looking into smbk5pwd should suffice.