Re: Updating ShadowLastChange with slurpd

[Tony Earnshaw <tonye@billy.demon.nl>]

Brian wrote:

> I have forced password expiration on first login by setting
> ShadowLastChange to 0.

Yes.

I can't provide any answer to your problem; I just spotted a single 
mistake further down.

> If a user logs in for the first time to any LDAP client machine or to the
> master itself, they're prompted to change their password immediately and
> the password gets updated immediately.

Yes, the system says it's a root-enforced change on login.

> 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:

> 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.

> access to attrs=userPassword
>      by dn="cn=root,dc=sboss,dc=com"
>      by self write
>      by * auth

Yes.

> access to *
>      by * read

--Tonni

--
Tony Earnshaw

If my mail server refuses your
mail resend to:

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