In an environment where consumers are configured to chain writes up to the providers, lastbind configuration fails to honor this which is generally what one would expect. This causes mismatches between the providers and consumers in regards to the database state. Additionally it introduces random serverIDs into the database. In my case, the providers have serverIDs 10, 20, 30 configured but the consumer is generating serverID 1 for the entryCSN. Expectation: consumer does not generate *any* entryCSN value and instead forwards the write op to the provider. Log from consumer: slap_get_csn: conn=1069 op=0 generated new csn=20220610180137.644625Z#000000#001#000000 manage=1
Note that this means in a replicated environment, there's currently no way to configure the system to work correctly with ppolicy+lastbind. The slapo-lastbind overlay is not an option because it tracks a different attribute.
A couple of other things to check on: a) In a delta-syncrepl environment, what happens if an account has first bound to a consumer (causing pwdLastSuccess to populate there) followed by a bind to the provider (causing pwdLastSuccess to populate and replicate). This could cause a collision and REFRESH. Subsequent BIND ops to the provider should result in a mod/replace. Real question is if the first time is a mod/add. b) What happens in a race condition situation (similar to a, but assuming chaining was actually functional).
This sounds somewhat related to my question on openldap-technical about slapo-syncprov on read-only consumers: https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/message/QDHF7YR3QM7OUG5SGWGZDA3NL2TL3X3D/
Enabling this feature in a replicated environment is extremely dangerous as it will cause the consumers to either (a) update a CSN that may not currently be in use causing them to be out of sync with the providers, (b) update a CSN that is in use causing it to be out of sync with the providers, or (c) create a brand new CSN in their local database, causing them to have a mismatch with the providers. None of these situations is good. In my non-prod environment, this is the CSNs on the providers: contextCSN: 20220613043332.710038Z#000000#00a#000000 contextCSN: 20220613063348.624161Z#000000#014#000000 contextCSN: 20220613063341.429488Z#000000#01e#000000 On the consumers where I enabled lastbind, we have: contextCSN: 20220613062500.129913Z#000000#001#000000 contextCSN: 20220613043332.710038Z#000000#00a#000000 contextCSN: 20220613063348.624161Z#000000#014#000000 contextCSN: 20220613063341.429488Z#000000#01e#000000 The #001# CSN was generated by lastbind. So now the consumers have mismatched cookies in comparison to the provider nodes.
(In reply to Michael Ströder from comment #3) > This sounds somewhat related to my question on openldap-technical about > slapo-syncprov on read-only consumers: > > https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/ > message/QDHF7YR3QM7OUG5SGWGZDA3NL2TL3X3D/ Yes, similar issue except that I have forwarding configured. Generally I would say that for ppolicy and lastbind, forwarding should always be enabled (and functional, which it currently is not for lastbind). Even if syncprov is not enabled on the consumers.
Ok, I tracked down why serverID 1 was being picked on the consumers (bad consumer config setting olcServerID 1). However even removing that, we still get a serverID of 0 used instead, which is also not desirable behavior and doesn't change the issues arising in this report.
https://git.openldap.org/openldap/openldap/-/merge_requests/542
head: • fb115157 by Quanah Gibson-Mount at 2022-07-06T20:46:49+00:00 ITS#9863 - Forward lastbind updates if configured • cfa6c07c by Quanah Gibson-Mount at 2022-07-06T20:46:49+00:00 ITS#9863 - Regression test case for pwdLastSuccess RE26: • f080ba08 by Quanah Gibson-Mount at 2022-07-07T15:48:59+00:00 ITS#9863 - Forward lastbind updates if configured • 5fecce1b by Quanah Gibson-Mount at 2022-07-07T15:49:04+00:00 ITS#9863 - Regression test case for pwdLastSuccess
*** Issue 6871 has been marked as a duplicate of this issue. ***