https://bugs.openldap.org/show_bug.cgi?id=10080
--- Comment #2 from Hiroyuki Homma homma@allworks.co.jp --- Created attachment 976 --> https://bugs.openldap.org/attachment.cgi?id=976&action=edit LDIF files to reproduce the issue
I was able to reproduce the issue by creating 3 servers on AWS. (See the attached archive LDIFs.zip)
Remote Server (instead of Active Directory) OS: AlmaLinux 9.2 LDAP: openldap-servers-2.6.2-2.el9 from EPEL repository hostname: dc1 config database: dc1-config.ldif mdb database: dc1-mdb.ldif
Sync Provider OS: AlmaLinux 9.2 LDAP: openldap-servers-2.6.2-2.el9 from EPEL repository config database: ldap1-config.ldif mdb database: ldap1-mdb.ldif
Sync Consumer OS: AlmaLinux 9.2 LDAP: openldap-servers-2.6.2-2.el9 from EPEL repository config database: ldap2-config.ldif
(1) In this configuration, the contents on the "ldap1" server are replicated to the "ldap2" server, but the refresh stage fails with the error "(48) Inappropriate authentication."
(2) When I add "cn=sync,ou=local,ou=users,dc=example,dc=com" to the ID assertion list on the "ldap1" server, ---------------- dn: olcDatabase={2}ldap,cn=config changeType: modify add: olcDbIDAssertAuthzFrom olcDbIDAssertAuthzFrom: dn.exact:cn=sync,ou=local,ou=users,dc=example,dc=com ---------------- the refresh fails with the error "server sent multiple refreshDone messages? Ending session." If the "dc1" server is an Active Directory, then the error is "(12) Critical extension is unavailable," because the Active Directory does not support the ManageDsaIT control (not the Sync Request Control that I mistakenly mentioned in the previous comment).
(3) When I configure the glue overlay explicitly before the syncprov overlay on the "ldap1" server, ---------------- dn: olcOverlay={0}glue,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig olcOverlay: {0}glue
dn: olcOverlay={1}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov ---------------- the refresh stage completes successfully without attempting to search the subordinate database. However, when I modify an entry in the subordinate database on "ldap1" server, slapd crashes by segmentation fault.