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

Re: Updating ShadowLastChange with slurpd

Brian wrote:

This should *not* be "by self write". The system should update the
shadowLastChange attribute automatically (at least, I just confirmed
that this happens on RedHat ES3/Openldap 2.1.23); the user should at the
most only be able to read it.


I agree with you that this is subject to abuse if the user knows about it.
 However I can confirm that under RH ES 2.1/OpenLDAP 2.0.27-2.7.3 that if
this is not set this way, the user is unable to update the attribute when
they change their passwords themselves.  The object is never updated and
they're perpetually prompted to change their passwords.  Or at least,
that's what I've observed.

Interesting. I'd deinstalled the 2.0.27 server/clients, kept the 2.0.27
ldap libs for the dependencies, and installed 2.1.23 to /usr/local from
source. What I saw I and did to the shadow attribute I did with GQ.
Changed shadowLastChange from some 5-figure value to 0, user force-changed password, shadowLastChange was changed to 12376 (yesterday). That ACL is read-only on this machine. I did it again, and the 0 was changed to 12377. Checked this with another user, also 12377 after the change.

But I can't see what LDAP has to do with it. It's purely the receptacle.
ldd on different binaries doesn't give much of a clue, either.

--Tonni

--
Tony Earnshaw

If my mail server refuses your
mail resend to:

billy at billy.demon.nl
http: www.billy.demon.nl