Hi Pierangelo,
On Tue, Aug 07, 2007 at 11:41:58AM +0200, Pierangelo Masarati wrote:
s.hetze@linux-ag.de wrote:
- 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?
Renaming the variables is no problem. What would you say extpwc stands for? I can imagine to call the module krb5pwc and head the README "Kerberos V/Active Directory Password Cache"
- 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.
If I understand it correct, you suggest to let the cached password expire after some configurable time. To achieve this, I would need to keep a timestamp when the password was cached. Is there any other way than to add an attribute holding this timestamp? ... Actually, I could make this feature depend on the {ad|krb5}pw-cache-mode=any and use the sambaPwdLastSet attribute.
- 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.
Thanx for your offer, and I agree to look into the existing overlays (again ;-) That's the fun with free software!
Regards,
Sebastian