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.riten...@martinfed.com> 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 <co...@naic.edu> > > Sent: Friday, March 4, 2022 12:47 AM > > To: 389-users@lists.fedoraproject.org > > 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 h...@martinfed.com- (855) 212-1810 , and destroy > > the original message and any such files. > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > 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@lists.fedoraproject.org > > 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@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
