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:
>
> 1. 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,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
