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

Universidad de Navarra


--

Oscar Remírez de Ganuza Satrústegui
Technology and IT Operations
IT Services

T: +34 948425600 x803130
oscarrdg@unav.es

Universidad de Navarra


Este mensaje puede contener información confidencial. Si usted no es el destinatario o lo ha recibido por error, por favor, bórrelo de sus sistemas y comuníquelo a la mayor brevedad al remitente. Los datos personales incluidos en los correos electrónicos que intercambie con el personal de la Universidad de Navarra podrán ser almacenados en la libreta de direcciones de su interlocutor y/o en los servidores de la Universidad durante el tiempo fijado en su política interna de conservación de información. La Universidad de Navarra gestiona dichos datos con fines meramente operativos, para permitir el contacto por email entre sus trabajadores/colaboradores y terceros. Puede consultar la Política de Privacidad de la Universidad de Navarra en la dirección: https://www.unav.edu/aviso-legal

 

This email message may contain confidential information. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments.  The personal information included in email messages exchanged with employees of the University of Navarra may be stored in the database of your interlocutor and/or the servers of the University for the time-period stipulated by its internal information storage policy. The University stores such data for purely administrative purposes, to facilitate e-mail contact between its employees and third parties. The University of Navarra Privacy Policy may be accessed at https://www.unav.edu/aviso-legal      

 

Antes de imprimir este mensaje o sus documentos anexos, asegúrese de que es necesario. Proteger el medio ambiente está en nuestras manos.
Before printing this e-mail or attachments, be sure it is necessary. 
It is in our hands to protect the environment.