This is more or less the same issue as the SO article in LDAP server to LDAP client password sync issue, however, I can provide a little bit more info ...
- I have an slapd server on a Raspberry acting as LDAP server
- another Raspi, the client is configured to get its login credentials also from this LDAP server
The problem is, when I change the user password of some LDAP user on the LDAP server with e.g.
ldappasswd -x -D uid=user1,ou=users,dc=mydomain,dc=net -a <<OLDPWD>> -s <<NEWPWD>> -w <<OLDPWD>>
then the new password is in effect for binding, e.g.:
ldapwhoami -x -W -D uid=user1,ou=users,dc=mydomain,dc=net
on the LDAP server works with the new password, but not with the old. Also, if I request the user details with:
ldapsearch -x -W -D uid=user1,ou=users,dc=mydomain,dc=net -b "uid=user1,ou=users,dc=mydomain,dc=net"
then the user's attributes show that the password in the attribute userPassword
actually has changed.
Everything ok so far.
However, on the LDAP client (other Raspi), I can still login using the old password while the new password gives me an "error on authenticating".
I know some internal databases (name services) are cached using nscd
(name service caching daemon). Using this, I can invalidate the local database cache on the LDAP client with:
nscd -i passwd
nscd -i group
However, this only invalidates data found normally in /etc/passwd
and /etc/group
. But the (cached??) LDAP password is not invalidated.
I assume the problem is merely on the LDAP client side, because the password change seems to work instantly when working on the LDAP server.
So my question is: who/what caches the old LDAP password on the LDAP client? And how can I force the new LDAP password to come into effect on all LDAP clients, in other words: how can I invalidate all cached LDAP passwords on the LDAP clients?
Oh dammit, my own fault:
I overlooked that I had a network issue so that the LDAP server would not be reachable by the LDAP client, although I could login to the server, so I did not realize that they did not see each other. In this case (server not reachable) the LDAP client would use the cached password. This is not a bug, but an important feature. Without this, login would not be possible when the LDAP server cannot be reached, e.g. for working offline.
As soon as I amended the network settings so that the LDAP server could be seen from the client, everything started working as expected!