Problema de syncrepl do OpenLDAP com políticas de senha

Question

Recentemente eu tenho trabalhado para fazer o slapd syncrepl funcionar usando um backend LDAP (replicação baseada em push). Embora eu tenha obtido resultados fantásticos com o syncrepl fazendo pull based, o push-based está me matando.

Estou tendo problemas com a seguinte saída quando começo o slapd: syncrepl_message_to_entry: rid = 700 mods check (pwdAttribute: valor # 0 inválido por sintaxe)

O que está se concentrando na minha política de senha padrão. Eu tenho visto outras mensagens sobre esse problema semelhante, mas a maioria delas nunca produziu uma resposta, então espero que eu esteja negligenciando algo bastante simples.

Estou executando esta instância slapd (2.4.35) com um banco de dados olc e os seguintes parâmetros relevantes:

objectClass: olcDatabaseConfig
objectClass: oldLDAPConfig    
olcDatabase: {1}ldap
olcDbACLBind: bindmethod=simple binddn="cn=Directory Manager" credentials="xxxxxxx"
olcDbOnErr: continue
oldDbUri: ldap://mysatelliteldapserver
oldSyncrepl: rid=700 provider=ldaps://masterldapserver.mydomain.com:636 bindmethod=simple binddn="cn=Directory Manager" credentials="xxxxxxxx" filter="(objectclass=*)" searchbase="dc=my,dc=base" scope=sub schemachecking=off type=refreshOnly interval=00:00:05:00

Qual deve puxar de "masterldapserver" e empurrar para "mysatelliteldapserver". Isso funciona até atingir minha política de senhas, quando fica:

syncrepl_message_to_entry: rid=700 mods check (pwdAttribute: value #0 invalid per syntax)

Que é totalmente falso. Cheguei até a pré-configurar as políticas de senha no servidor de satélite de destino e, em seguida, reiniciei a replicação.

A fonte mostra claramente:

pwdAttribute: userPassword

Mas voltamos com o valor # 0 (que em outras ocasiões associei isso a um valor "nulo").

Então, a pergunta é: alguém mais passou por isso e alguém tem uma sugestão para algum tipo de correção ou solução alternativa?

Obrigado antecipadamente

    

Answer 1

'value # 0' não é o valor em si. Significa o 0º valor.

Tente alterá-lo para o OID de 'userPassword', ou talvez você não tenha os esquemas certos carregados no escravo para saber o que é userPassword .

    

Answer 2

Eu endosso a resposta do @EJP: ou o consumidor não tem uma opção de compilação (como o suporte a {CRYPT} senhas, que deve estar habilitado como opção de compilação) ou um módulo (como suporte para {SHA256} ou {PDKDF2-SHA*} senha que requer tanto a compilação do módulo quanto a inserção do módulo em cn=config ).

É algo sobre o consumidor perder o suporte para o esquema de hashing usado pelo provedor.