New LDAP password on LDAP server does not synch to the LDAP client-CodePudding

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?

CodePudding user response：

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!