Re: Contribution: Active Directory Password Cache (ITS#5042)

[s.hetze@linux-ag.de]

Hi Pierangelo,


On Tue, Aug 07, 2007 at 11:41:58AM +0200, Pierangelo Masarati wrote:
> s.hetze@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?

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"

> 
> >>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.
> 

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.

> >>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.

Thanx for your offer, and I agree to look into the existing overlays
(again ;-)
That's the fun with free software!


Regards,

  Sebastian