Good morning everyone,
I'm pleased to report that I've identified and resolved the issue concerning ppolicy attribute updates on the slave server.
The root cause was the 'readonly on' setting configured on the slave. This option, historically used to prevent direct modify operations on the slave, was being evaluated *before* the attempt to bind to the master server for the ppolicy attribute update. Consequently, the update operation was blocked by the slave's read-only status.
Disabling this 'readonly on' option allowed the modify operations to be successfully forwarded to the master server. To maintain the desired security and control, I have configured specific ACLs on the master server. These ACLs now permit updates *only* on the ppolicy attributes for operations originating from the slave, preventing other standard modify operations against the slave from succeeding via this path.
Everything is now functioning as expected. I wanted to share this resolution in case it could help others who might encounter a similar debugging scenario in the future.
Thanks for your work and patience.
Regards,
On Thu, May 15, 2025 at 2:02 PM Óscar Remírez De Ganuza Satrústegui < oscarrdg@unav.es> wrote:
Good morning,
I'm trying to configure ppolicy_forward_updates to master from slaves on Symas OpenLDAP 2.6.9, so that both successful authentications (ppolicy attribute pwdLastSuccess) and failed authentications (ppolicy attribute pwdFailureTime) get forwarded and written on the master.
Following some documentation [1] [2] I have configured on the slave:
- chain overlay in order to define how to connect to master (credentials,
tls, etc)
- updateref (after syncrepl section), in order to define where to send
updates
- ppolicy_forward_updates, in order to define that ppolicy operations must
be forwarded.
I have also configured lastbind overlay to define desired precision to save pwdLastSuccess, and this is working perfectly on the master server. Both attributes (pwdLastSuccess and pwdFailureTime) are respectively being updated flawlessly when binding to the master server. Syncrepl between master and slave is also working properly, so that they both get replicated to the slave.
But when binding to the slave, the "ppolicy forward updates" functionality is not working and I can not find out why. I have looked at the usual suspects, as ACL permissions on master, connectivity, etc.
But after some debugging I don't see the slave trying to connect to the master (using tcpdump on the slave I can not see any traffic), so I have discarded any problems on the master itself (ACL), and I am guessing that the problem is on the slave part.
When trying to further debug the problem, I can see on the slave server:
- On *successful* auths, when trying to write pwdLastSuccess:
slapd[320250]: send_ldap_result: err=53 matched="" text="operation restricted" slapd[320250]: conn=1002 op=0 ppolicy_bind_response: ppolicy state change failed with rc=53 text=operation restricted slapd[320250]: conn=1002 op=0 RESULT tag=97 err=0 qtime=0.000005 etime=0.000335 text= slapd[320250]: connection_get(23)
- On *failed* auths, when trying to write pwdFailureTime:
slapd[320250]: send_ldap_result: err=49 matched="" text="" slapd[320250]: => mdb_entry_get: ndn: "<<userdn_redacted>>" slapd[320250]: => mdb_entry_get: oc: "(null)", at: "(null)" slapd[320250]: => mdb_entry_get: found entry: "<<userdn_redacted>>" slapd[320250]: send_ldap_result: err=53 matched="" text="operation restricted" slapd[320250]: conn=1003 op=0 ppolicy_bind_response: ppolicy state change failed with rc=53 text=operation restricted slapd[320250]: conn=1003 op=0 RESULT tag=97 err=49 qtime=0.000013 etime=0.000601 text= slapd[320250]: connection_get(23) slapd[320250]: conn=1003 op=1 UNBIND slapd[320250]: conn=1003 fd=23 close
And I am not able to get more detailed information to find out why this operation is restricted.
"ppolicy_bind_response" messages makes me suppose that it is indeed trying to bind somewhere, but I am not seeing any connection trying to be made outside the slave server. Is there some way to check where it is trying to bind?
I don't know where else to look in order to find out what 's wrong.
Anyone have any tips?
Thank you so much for your help.
[1] https://kb.symas.com/en_US/configuration/configuring-ppolicy-for-openldap-25 [2] https://kb.symas.com/en_US/configuration/referrals-and-chaining)
*Oscar Remírez de Ganuza Satrústegui* Technology and IT Operations IT Services
T: +34 948425600 x803130 oscarrdg@unav.es
[image: Universidad de Navarra] http://www.unav.edu/