Thank you for your answer. Indeed the issue was certmap.conf not configured properly. I have set CmapLdapAttr to the attribute name nsCertSubjectDN and added such attribute with the appropriate value to the host1/2 accounts. However now I have encountered another error: in the host1 error log I see: 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. and in the host2 error log I see: ERR - NSMMReplicationPlugin - multimaster_extop_StartNSDS50ReplicationRequest - conn=5 op=3 replica="dc=example,dc=com": Unable to acquire replica: error: permission denied My guess at this point is that the issue is with the user certificate. If I enable in certmap.conf verifycert on then I'm back with the error I had before (Invalid credentials) Is there a way to see in the log the content of the user certificate that host1 is using to connect to host2? Giacomo On Mon, Mar 07, 2022 at 12:34:40AM +0000, William Brown wrote: > Thanks David! This is absolutely correct :) > > > On 5 Mar 2022, at 00:34, David Ritenour <d.ritenour@xxxxxxxxxxxxx> wrote: > > > > Hello Giacomo, > > > > Per the error log, it appears that the certificate is not mapping to the desired user entry. Make sure your certmap.conf file is properly configured per Section 9.9.1 found here: > > https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/using-based_client_authentication#setting_up_certificate-based_authentication > > > > Restart the directory after modifying the certmap.conf file. > > > > Also, it is helpful to look at the access log and follow the conn=xxxx for the connection. > > > > Here is a certificate-based authentication failure example (RHEL 7): > > # grep $(grep "SSL connection from" access|tail -1|cut -f3 -d' ') access > > [04/Mar/2022:09:00:02.932646113 -0500] conn=21 fd=4098 slot=4098 SSL connection from 192.168.150.189 to 192.168.150.187 > > [04/Mar/2022:09:00:02.986129181 -0500] conn=21 TLS1.2 256-bit AES; client CN=mfed-rh7ds1.martinfederal.local,DC=martinfed,DC=local; issuer CN=dev-IntermediateCA1.martinfederal.local,OU=pki-tomcat,O=MartinFederalLab > > [04/Mar/2022:09:00:02.986149974 -0500] conn=21 TLS1.2 failed to map client certificate to LDAP DN (Cert mapping function failed) > > [04/Mar/2022:09:00:02.986643636 -0500] conn=21 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL > > [04/Mar/2022:09:00:02.986749253 -0500] conn=21 op=0 RESULT err=49 tag=97 nentries=0 wtime=0.053972758 optime=0.000109274 etime=0.054077979 - Client certificate mapping failed > > [04/Mar/2022:09:00:02.987740508 -0500] conn=21 op=1 UNBIND > > [04/Mar/2022:09:00:02.987760181 -0500] conn=21 op=1 fd=4098 closed - U1 > > > > Here is a successful certificate-based authentication connection (RHEL 7) with properly configured certmap.conf: > > # grep $(grep "SSL connection from" access|tail -1|cut -f3 -d' ') access > > [04/Mar/2022:09:13:14.980664619 -0500] conn=3 fd=4098 slot=4098 SSL connection from 192.168.150.189 to 192.168.150.187 > > [04/Mar/2022:09:13:15.021509726 -0500] conn=3 TLS1.2 256-bit AES; client CN=mfed-rh7ds1.martinfederal.local,DC=martinfed,DC=local; issuer CN=dev-IntermediateCA1.martinfederal.local,OU=pki-tomcat,O=MartinFederalLab > > [04/Mar/2022:09:13:15.022228628 -0500] conn=3 TLS1.2 client bound as cn=repman_mfed-rh7ds4-doe.martinfederal.local,cn=config > > [04/Mar/2022:09:13:15.022313670 -0500] conn=3 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL > > [04/Mar/2022:09:13:15.022446873 -0500] conn=3 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.041625548 optime=0.000136346 etime=0.041760960 dn="cn=repman_mfed-rh7ds4-doe.martinfederal.local,cn=config" > > > > Good luck. > > > > David Ritenour > > Senior Directory Engineer > > 513 Madison Street SE > > Huntsville, AL 35801 > > > > > > -----Original Message----- > > From: Giacomo Comes <comes@xxxxxxxx> > > Sent: Friday, March 4, 2022 12:47 AM > > To: 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > Subject: [389-users] multi-supplier replication with certificate-based authentication > > > > ** WARNING: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > > > Hi, > > I'm trying to setup multi-supplier replication with certificate-based authentication. > > The only documentation I have found on the subject is: > > https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/configuring_replication_partners_to_use_certificate-based_authentication > > however it doesn't seems to be complete. > > > > I have been doing my test with openSUSE 15.3 and RHEL/CentOS 8 with SELinux disabled. > > > > Attached there are a couple of scripts (dmtest-init and dmtest-agmt) that will help you reproduce my setup so you can tell me what I'm missing or doing wrong. > > > > For testing you need two (virtual) machines and their ip addresses. > > A minimum text/server installation will do. > > > > Run on the first machine: > > ./dmtest-init <IP1> <IP2> > > > > The script will configure /etc/hosts so that the machine with IP1 can be reached as host1.example.com and the other as host2.example.com. > > 389-ds will be installed if not present. > > A new ds instance will be created, started (password is: password) and configured. > > /etc/openldap/ldap.conf is configured appropriately. > > group1 and user1 are created. > > > > Now run on the second machine the same command: > > ./dmtest-init <IP1> <IP2> > > the script will setup the second machine in the same way but with the following differences: > > The CA database is imported with rsync from host1. > > A new Server-Cert is created using the CA certificate from host1. > > group1 and user1 are not created. They should appear on host2 after host1 will replicate his database. > > A temporary replication manager account is created. > > > > At this point the following commands should work on both machines: > > > > ldapsearch -H ldaps://host1.example.com -D "cn=Directory Manager" -w password > > ldapsearch -H ldaps://host2.example.com -D "cn=Directory Manager" -w password > > > > Binding with a user certificate should also work: > > openssl req -subj "/DC=com/DC=example/OU=people/UID=user1" -newkey rsa:2048 -nodes -keyout cert.key -new -out cert.csr > > certutil -C -d /etc/dirsrv/ssca -f /etc/dirsrv/ssca/pwdfile.txt -a -i cert.csr -o cert.crt -c Self-Signed-CA > > LDAPTLS_CERT=$PWD/cert.crt LDAPTLS_KEY=$PWD/cert.key ldapsearch -H ldaps://host1.example.com -D "uid=user1,ou=people,dc=example,dc=com" > > > > The next step is the replication setup. Run on host1: > > ./dstest-agmt > > this script will: > > - create the group repl_server for nsds5ReplicaBindDNGroup > > - create accounts for both hosts > > - add the client certificates to the corresponding accounts > > - add both accounts to the group repl_server > > - create the replica entry > > - create the replication agreement (with bootstrapt parameters) > > > > These are essentially the steps described in the RedHat Directory Server 11 documentation: 15.6 > > > > Now a look at /var/log/dirsrv/slapd-ldaptest/errors shows that the replication bind with the bootstrap parameters works (group1 and user1 are now present on host2) but the replication bind with EXTERNAL auth fails. > > > > - ERR - slapi_ldap_bind - Error: could not bind id [(anon)] authentication mechanism [EXTERNAL]: error 49 (Invalid credentials) > > - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636) - Replication bind with EXTERNAL auth failed: LDAP error 49 (Invalid credentials) () > > - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636): Replication bind with SIMPLE auth resumed > > > > Clearly there is something wrong with the client certificate setup, but I could not figure out what. > > Any help is appreciated. > > > > Giacomo Comes > > > > This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email and any such files in error and that any use, dissemination, forwarding, printing or copying of this email and/or any such files is strictly prohibited. If you have received this email in error please immediately notify hr@xxxxxxxxxxxxx- (855) 212-1810 , and destroy the original message and any such files. > > _______________________________________________ > > 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 > > -- > Sincerely, > > William Brown > > Senior Software Engineer, > Identity and Access Management > SUSE Labs, Australia > _______________________________________________389-users mailing list -- 389-users@lists.fedoraproject.orgTo unsubscribe send an email to 389-users-leave@lists.fedoraproject.orgFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.orgDo not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ 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
