We are also experiencing this issue with 2.4.40 when we try to create
a replica from the primary.

our current workaround is to exclude the pwdPolicy objectclass:

olcSyncrepl: {0}rid=000
  provider=ldap://127.0.0.1:389
  type=refreshAndPersist
  retry="5 5 300 +"
  searchbase="dc=chi,dc=braintreepayments,dc=com"
  attrs="*,+"
  filter="(!(objectClass=pwdPolicy))"
  bindmethod=simple
  binddn="cn=admin,dc=chi,dc=braintreepayments,dc=com"
  credentials=openldaptest
  schemachecking=off

moved from Incoming to Software Bugs

howard to investigate

The bug report makes no sense.

(In reply to mozo@mozo.jp from comment #0)
> As LDIF backend tries to store the values for the attributes in "prettified"
> form and the value is transferred verbatim in wire,  replication of
> pwdAttribute
> (1.3.6.1.4.1.42.2.27.8.1.1) ends up with the following error:
> 
> > syncrepl_message_to_entry: rid=001 mo cheheck (pwdAttribute: value #0 invalid
> per syntax)
> 
> The validation causing the error itself is done in the following part in
> servers/slapd/modify.c:
> 
>             /*
>              * check that each value is valid per syntax
>              *  and pretty if appropriate
>              */
>             for ( nvals = 0; !BER_BVISNULL( &ml->sml_values[nvals] );
> nvals++ )
> {
>                 struct berval pval;
> 
>                 if ( pretty ) {
>                     rc = ordered_value_pretty( ad,
>                         &ml->sml_values[nvals], &pval, ctx );
>                 } else {
>                     rc = ordered_value_validate( ad,
>                         &ml->sml_values[nvals], ml->sml_op );
>                 }
> 
>                 if( rc != 0 ) {
>                     snprintf( textbuf, textlen,
>                         "%s: value #%ld invalid per syntax",
>                         ml->sml_type.bv_val, (long) nvals );
>                     *text = textbuf;
>                     return LDAP_INVALID_SYNTAX;
>                 }
> 
>                 if( pretty ) {
>                     ber_memfree_x( ml->sml_values[nvals].bv_val, ctx );
>                     ml->sml_values[nvals] = pval;
>                 }
>             }
> 
> where pwdAttribute has the corresponding prettifier assigned to its schema
> (servers/slapd/overlays/ppolicy.c), which eventually is fed with the value in
> prettified form that will effectively make slap_bv2ad() in attrPretty() fail.

attrPretty will only fail if the item it's passed has not been defined
in the schema.

> 
>         {
>             Syntax *syn;
>             MatchingRule *mr;
> 
>             syn = ch_malloc( sizeof( Syntax ));
>             *syn = *ad_pwdAttribute->ad_type->sat_syntax;
>             syn->ssyn_pretty = attrPretty;
>             ad_pwdAttribute->ad_type->sat_syntax = syn;
> 
>             mr = ch_malloc( sizeof( MatchingRule ));
>             *mr = *ad_pwdAttribute->ad_type->sat_equality;
>             mr->smr_normalize = attrNormalize;
>             ad_pwdAttribute->ad_type->sat_equality = mr;
>         }
> 
> The replication works fine for other such attributes that have the same
> syntax
> (OID, 1.3.6.1.4.1.1466.115.121.1.38) like objectClass because those
> attributes
> are accompanied by the validators as well as prettifiers which validate the
> value both in prettified and OID form.  For instance, objectClass has the
> corresponding validator oialalidate() besides the prettifier
> objectClassPretty().

The code you quoted from slapd/modify.c clearly shows that if a prettifier is defined, then the validator is ignored, therefore it is irrelevant.

So again, this only fails if the schema element in question is not defined, which means you have a configuration error. Closing this ITS.