Hi, I finally managed to setup multi-supplier replication with certificate-based authentication. I now understand why people says it is a complicated stuff and they wish luck to the guy trying to do it. It is actually not that much complicated, once you know what to do. Follow my instructions and see for yourself. Start with reading the documentation (Red Hat Directory Server 11) especially: 9. Configuring Secure Connections 15. Managing Replication and in particular: 9.9.1. Setting up Certificate-based Authentication 15.4. Multi-Supplier Replication 15.6. Configuring Replication Partners to use Certificate-based Authentication In the following examples I'll assume the two hosts are called host1.example.com and host2.example.com you have setup on each host a directory server instance called "ldaptest" with self-signed CA certificate. The root suffix stored in the database is: dc=example,dc=com You have to execute the steps described in 15.6: - create two accounts for both servers - add to the accounts the user certificate - create the replication group - add both server accounts to such group - create the replica entry (dsconf ... replication enable ... --bind-group-dn=<replication group>) - initialize the server using a temporary replication agreement on host1 and a temporary replication manager on host2 (to be more precise on host2 you have to enable replication for the suffix and create the temporary replication manager account [15.4.1 step 3]) - after initialization remove the temporary replication agreement on host1 and the temporary replication manager on host2 - create a replication agreement on both servers that use certificate-based authentication. You do everything as described, but when you create the replication agreement on host1 (as showed in 15.6 step 5/a), things do not work. The error log shows: ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636) - Replication bind with EXTERNAL auth failed: LDAP error 49 (Invalid credentials) the cause is that host2 does not know from which account to retrieve the user certificate. To fix this problem you have to set the parameter CmapLdapAttr in certmap.conf in the following way: 1) Set the parameter CmapLdapAttr to nsCertSubjectDN nsCertSubjectDN is the attribute that will contain the subject DN required to locate the host account. 2) When you create the account for the server and add to such account the client certificate (15.6 step 2/a) add also the attribute nsCertSubjectDN with the value I'm going to describe below. Run the command: certutil -L -d /etc/dirsrv/slapd-ldaptest -n "Server-Cert" | grep "Subject" You will see the subject of the server certificate. Something similar to: CN=host1.example.com,givenName=6562ddf6-4594-4ef7-8b5d-8ae9a32ffa29,O=testing,L=389ds,ST=Queensland,C=AU for such subject the value to assign to the attribute nsCertSubjectDN is: cn=host1.example.com,GIVENnAME=6562ddf6-4594-4ef7-8b5d-8ae9a32ffa29,o=testing,l=389ds,st=Queensland,c=AU That is: you have to flip the case of the attribute type (cn,o,ou,st,c, etc.) Why it is like that and more important why it is not documented I don't know. Once nsCertSubjectDN is set correctly and you create the replication agreement on host1 (as described in 15.6 step 5/a) you will now get this error message in the log: ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=agreement" (host2:636): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. This error is due to the fact that on host2 the replication is still enabled for bind-dn="cn=replication manager,cn=config" you have to disable such replica entry and create a new replica entry with --bind-group-dn=<replication group> similar to the one you did on host1. After you do that the replication should work. Unless it doesn't. If you have created a self signed CA certificate and you are in a timezone with negative offset (GMT-<n>) like in America, then a bug will not make the replication work. Here is what happens. Assume you are in the timezone GMT-4. It's 10:00 and a self signed CA certificate is created while running the command dscreate. Check the validity of the certificate with: certutil -L -d /etc/dirsrv/ssca -n Self-Signed-CA | grep Not the output is something like: Not Before: Tue Mar 08 14:00:00 2022 Not After : Fri Mar 08 14:00:00 2024 As you can see the certificate uses UTC time: 14:00 UTC corresponds to 10:00 GMT-4 Now somewhere in the directory server code the time stored in the CA certificate is assumed to be in local time, therefore since it is 10:00 and the certificate is not valid before 14:00, the replication does not work. In the error log you will see the message: ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=agreement" (host2:636): Unable to acquire replica: permission denied. The bind dn "uid=host1.example.com,ou=people,dc=example,dc=com" does not have permission to supply replication updates to the replica. Will retry later. You can either wait few hours until the certificate becomes valid, or you can change the system clock just before you are running dscreate: date -s "$(date +%:::z) hours" #move the clock backwards dscreate <arguments> date -s "$(( $(date +%:::z) * -1)) hours" #restore the correct time Continuing with the previous example, the CA certificate will be now valid since 10:00 GMT leaving the replication process unaffected by the bug. To resume: add the attribute nsCertSubjectDN with correct value to the host accounts, update the replica entry on host2 after the temporary agreement has done its job, consider changing the system clock when you use the command dscreate. I wish to thank David and William for their help. I have never used 389-ds before and what they said helped me investigate the proper cause of my problems. Cheers. Giacomo Comes System Administrator Arecibo Observatory _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
