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

Re: Updating ShadowLastChange with slurpd



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