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 ")
Resulting in one user with the password changed in the provider and in only one of the consumers.
Have you found the same problem? Maybe is there something wrong in our setup?
Thanks a lot.
------------------------------ Manolo García Arquitecte de Solucions Universitat Oberta de Catalunya
689 88 30 93 | mgarciaal@uoc.edu
[image: Universitat Oberta de Catalunya]
--On Thursday, March 16, 2023 11:12 AM +0100 Manolo Garcia Alvarez mgarciaal@uoc.edu 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:
Thta's not high volume or a large amount of users (just to note). You didn't provide any information on the version of OpenLDAP in use, which is critical information.
--Quanah
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,
openldap-technical@openldap.org
-
Manolo Garcia Alvarez -
Ondřej Kuzník -
Quanah Gibson-Mount