[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Updating ShadowLastChange with slurpd
Tony Earnshaw said:
>> If they log into the slave and change their password, the updateref
>> passes it back to the master and updates the password, but logging into
>> any LDAP client or master server prompts them to change their newly
>> changed password.
>
> I have no idea about why this is happening to you. Check the record for
> the user on a client or master server after an enforced password change,
> to see if shadowLastChange has been replicated. Use an ldif or GQ or
> similar. However:
Why would every other attribute but this one be replicated?
>> My ACL's on the master and slave are as so:
>>
>> access to attribute=shadowLastChange
>> by dn="cn=root,dc=sboss,dc=com"
>> by self write
>> by * read
>
> 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.
--
Brian