[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange



Michael Ströder wrote:
> Howard Chu wrote:
>> Michael Ströder wrote:
>>> While I agree that slapo-ppolicy is the better solution in the long run I
>>> see no reason why to not set both attributes at the server's side to
>>> make older LDAP clients happy.
>>
>> This is not a realistic use case. smbk5pwd was written starting in 2004;
>> pam_ldap started supporting LDAP password policy long before then.
>
> Yes, pam_ldap supports enforcing the password policy probably by correcty
> handling the response controls. Grepping through the source of recent versions
> it seems to me it does not read attribute pwdChangedTime nor does nss_ldap.

Because clients don't need to read the value. Since password modification is 
all managed on the server, it's an irrelevant detail on the client.

>> Anyone running LDAP clients (pam_ldap, nss_ldap) older than that has far
>> worse problems to worry about.
>
> AFAICS nss_ldap cannot deliver the correct value for 'shadowLastChange' when
> someone or something invokes a call like this
>
> getent shadow michael

Nobody does that. Normal users don't even have read permission to do that.

> 'pwdChangedTime' is of syntax Generalized Time whereas 'shadowLastChange' is
> Integer with seconds since epoch. In theory nss_ldap could convert it. But
> AFAICs it doesn't. Also if an older client would search for
> (shadowLastChange<=<value>) this wouldn't work either.

You've just proven the point why shadowLastChange is problematic. The encoded 
value is in *minutes* since the epoch. All of the shadow values were poorly 
defined to begin with (talking about /etc/shadow, not just RFC2307), 
inconsistent with common Unix practice, and most people don't understand them 
anyway. They have no role in an LDAP-enabled environment, all they do is 
perpetuate confusion.

>> This ITS will be closed.
>
> Well, you're the OpenLDAP boss and free to refuse anything you want. But
> personally I don't understand your strong objections.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/