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.