Giacomo, In addition to what William provided, you noted that the certificate-authentication failed with "verifycert on" in the certmap.conf file. This option adds an additional layer of security by comparing the certificate presented by the connecting client to a certificate contained in the mapped user/repman entry on the directory server. If the certificate does not exist in the entry or is different, the authentication will fail. Again, failure and success information can be found in the access log. In the following access log failure example , the first line show the mapping failure and reason, the second line shows the BIND dn was blank, and the third line shows err=49 (invalid credentials). [07/Mar/2022:19:01:32.547081217 -0500] conn=11 TLS1.2 failed to map client certificate to LDAP DN (User's LDAP entry doesn't have any certificates to compare) [07/Mar/2022:19:01:32.547126863 -0500] conn=11 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL [07/Mar/2022:19:01:32.547172156 -0500] conn=11 op=0 RESULT err=49 tag=97 nentries=0 wtime=0.054925415 optime=0.000046421 etime=0.054970850 - Client certificate If this is the case in your setup, you will need to import the certificate into a userCertificate;binary attribute in the corresponding user/repman entry. This does not require the directory to be restarted although any change to the certmap.conf file does. David Ritenour Senior Directory Engineer MartinFederal Consulting, LLC 513 Madison Street SE Huntsville, AL 35801 -----Original Message----- From: Giacomo Comes <comes@xxxxxxxx> Sent: Monday, March 7, 2022 1:12 AM To: General discussion list for the 389 Directory server project. <389-users@xxxxxxxxxxxxxxxxxxxxxxx> Subject: [389-users] Re: 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. 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_serv > > er/11/html/administration_guide/using-based_client_authentication#se > > tting_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=MartinFed > > eralLab > > [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=MartinFed > > eralLab > > [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_serv > > er/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@lists.fedora > > project.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.fedorapr > oject.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 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
