On Thu, Mar 16, 2023 at 10:12:41AM +0100, Manolo Garcia Alvarez wrote:
Hello.
We're having some problems with replication and password changes. Let me explain... In our institution we are using Shibboleth to provide SSO to the users. The credentials are stored in OpenLDAP, but due to the high demand (100 auths/second) and the high volume (more than 700K users), we had to split it in three servers:
- one is the producer, which receives all of the changes (both data and
password changes),
- two are the consumers, sync'd with the producer via syncrepl.
The two consumers are behind a load balancer and are used to perform the BINDs and the user lookup.
The problem that we are facing is that in some cirscunstances (maybe high load, high traffic?) the syncrepl lasts more than expected, and that causes the next situation:
- an user changes its password, the object changes its modifyTimestamp
to T1 2. before the syncrepl gets to replicate that change, the user tries to authenticate with the new password, the balancer assigns one of the consumers (say C1), tries to bind, but the password is not yet changed, so it fails recording one pwdFailureTime and updating its modifyTimestamp to T2 3. when syncrepl tries to update the object in C1, T2 is older than T1 so it refuses to change the object ("dn_callback : new entry is older than ours cn=XXXXX,dc=acces,dc=uoc,dc=edu ours 20230313155537.264968Z#000000#00d#000000, new 20230313155506.235663Z#000000#00b#000000 ")
Hi Manolo, this sounds wrong, is the host a provider or a consumer? Plain or deltasync? If it's a provider a.k.a. has multiprovider (formerly mirrormode) set, you need the replication to be mutual. If it's just a consumer, you should set up chaining so that password failures aren't stored locally but forwarded to the provider and you won't hit this.
Regards,