[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
- From: hyc@symas.com
- Date: Sat, 15 May 2010 18:20:30 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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/